Phil Terry wrote: > Say I'm writing a sound card, video card, widget card, etc., driver. > > My driver gets loaded by virtue of detecting the card/device (via of, > pci, usb, platform, whatever bus mechanisms). > > My driver would benefit from using a generic DMA device so it uses the > internal api to look for one and uses the API of that device to request > a channel for its use. I don't care what channel I get, I don't need a > fixed, reserved channel of the DMA device as specified in the dts I just > need an unused channel. If no channels are available or I'm in a system > with no generic DMA service available I can either fall back to > processor copying or refuse to load.
The audio device example was not about using the DMA engine for generic memory copying; it was about an audio device that is hardwired to a certain DMA channel. There is no way to do audio without using that specific channel. > If the dts/of/boot loader tells the kernel its a fsl soc then it knows > how to work out which one and what level, and therefore knows what > devices, such as the DMA device are present. All you'd be doing then is moving the device trees into the kernel. The dtc syntax is a convenient way of expressing the information that has to live *somewhere*. > Quite why we are using a 20 year old spec, which was never finished, and > ceased to be a formal spec 10 years ago as the "new" way forward is a > puzzle to me as well. Probably because there was already code there to support it. :-P It's not that bad in most respects, though unlike some, I don't think we need to stick dogmatically to the exact way that Open Firmware(tm) did everything. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
