Messages in this thread | | | Date | Mon, 7 Feb 2000 14:11:51 -0800 | From | "David S. Miller" <> | Subject | Re: pci_alloc_consistent |
| |
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/
| |