Date: Mon, 07 Feb 2000 21:20:34 +0100
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
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?
Interesting point, something needs to change, but probably
not how you have suggested, see below.
I'm currently setting the value just prior to calling
pci_alloc_consistent.
Why not just setting the mask to 24bits? Since playback is what
most people care for, and having separate masks for both directions
(BMDMA controllers) allows playback still to work on archs that
cannot have 24bit only memory (alpha was such a case until at least
one week ago...)
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");
}
if (pci_dma_supported(pdev, ess_record_dma_mask)) {
driver->record_enabled = 1;
} else {
driver->record_enabled = 0;
printk("ESS: Record disabled on this platform.\n");
}
Then you just return something like EOPNOTSUPP from all calls
into your driver which try to do a record operation.
I don't like doing it at pci_alloc_consistent() time. And for other
drivers, you'd "find out" about the issue during pci_map_single() et
al. Typically during the latter calls you are in an interrupt handler
or similar, and there error recovery is much more complicated.
So, put another way:
1) pci_alloc_consistent() should only fail due to memory exhaustion
and driver bugs.
2) pci_map_*() should only fail due to driver bugs or instances of
complete system failure (for example, some other buggy driver
does not do the unmap calls, and thus eats up all of the
DMA mapping resources until none are left).
Does this work for you? If so, I'll work on adding the interfaces
to the ABI.
Later,
David S. Miller
davem@redhat.com
-
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/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:15 EST