On 7/24/2012 7:35 AM, Wolfgang Denk wrote:
Dear Arnd,
In message [off-list ref] you wrote:
quoted
quoted
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.
quoted
quoted
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