lkml.org 
[lkml]   [2000]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: pci_alloc_consistent
First Thomas Sailer <sailer@ife.ee.ethz.ch> wrote:
> I've looked at pci_alloc_consistent and friends. My gripe with it
> is that dma_mask is not really a per device thing, ESS Solo1 for
> example can address 32bits for playback, but only 24bits for
> recording. So shouldn't it be a parameter to pci_alloc_consistent
> instead of being an element of pci_dev?

This would also satisfy my gripe about non-PCI devices (i.e. pci_dev==NULL).
Maybe something like:

void *dma_alloc_consistent(struct pci_dev *pci, long size,
dma_addr_t *dmap, unsigned long mask);

#define pci_alloc_consistent(pci, size, dmap) \
dma_alloc_consistent(pci, size, dmap, pci->dma_mask)
#define isa_alloc_consistent(size, dmap) \
dma_alloc_consistent(NULL, size, dmap, 0xFFFFFF);
That way we have the same nice pci_alloc_consistent interface (for
most things), we have a way to override dma_mask for weird
devices like the Solo1, and we can support non-PCI busses that
don't have the ISA 16-Meg limitation.

David S. Miller wrote:
> What you really want to do in this situation is probe the PCI
> implementation for what is supported.
>
> By this I mean something like:
>
> if (pci_dma_supported(pdev, ess_playback_dma_mask)) {
> driver->playback_enabled = 1;
> } else {
> driver->playback_enabled = 0;
> printk("ESS: Playback disabled on this platform.\n");
> }

That's a good idea too, but you still have the problem of wanting to
allocate pages for the playback pool from a larger set than the
recording pool.

-Mitch

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans