On 7/24/2012 7:35 AM, Wolfgang Denk wrote: > Dear Arnd, > > In message <201207241319.45101.a...@arndb.de> you wrote: >> >>> I'm trying to implement a driver that can do both DMA and PIO, and it would >>> be >>> nice if the user was able to select the mode (on a per-bus basis) using the >>> DT. >>> The PIO mode can reduce the overhead in some cases and therefore be better >>> choice than the DMA (for example when most transfers move only very few >>> data, or >>> when board-specific hardware properties kick in). >>> >>> I was thinking about using some "manf,use-pio" DT property, but I haven't >>> found >>> any such example yet, so I wonder if this is a good idea.
I think it's okay to have such a property, especially in the case where there are specific hardware reasons for choosing PIO on that bus. It would be even better to have a property that describes the specific hardware situation that leads to the conclusion. The conclusion is "use PIO", whereas the situation might be "expected transfer length = 4". Some such "situations" might apply to specific slaves, and thus might better be described in a child node, with the information processed in the child driver and passed to the bus driver through a callback - but that probably has tricky API implications. The thing to avoid is properties that can't easily be tied to some objectively-true aspect of the system. Write down what it is that causes the choice, then consider describing that in a property, letting the driver make the final decision based on that information. >>> >> >> What kind of device is this? We are currently working on the dmaengine >> binding, so an easy way to do this would be (one that binding is complete) >> to either provide or not provide the channel description depending on >> what you want to do with the device. This is clearly a hack but might >> fit your use case without adding any ugly code to the kernel. >> >> Another option would be to make it a runtime configuration option, >> e.g. through sysfs, but that again depends a lot on what device you >> are talking about. > > At least in my example of the x86 system a sysfs interface would not > help, as the kernel would crash during bootup before I can run user > space code. > > Best regards, > > Wolfgang Denk > _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss