On Wed, Mar 25, 2015 at 05:13:13PM +0100, Martin Sperl wrote: > > On 25.03.2015, at 16:16, Mark Brown <broonie@xxxxxxxxxx> wrote: > > This appears to be open coding the core spi_set_cs() support for GPIOs, > > why are we not just setting cs_gpio and letting the core take care of > > things? > In principle yes - the problem is that the core method is not exported. > If you agree to export it then I will create a patch using that. > Maybe even exporting it in that patch). There is no need for it to be exported, as I said you simply need to set cs_gpio and it will be used. > The problem with the core framework as is is that it currently does > not support handling multiple spi_transfers in the irq-handler itself. > Instead we have to wake up the worker-thread to handle the next > spi_transfer which will - at some point - will trigger another irq, > where the overhead is again 5-6us until the spi-irq-handler runs. > This obviously adds unnecessary overhead. We've been round this loop repeatedly, as we've discussed improving the framework is a good idea. > Keeping it as is means we can easily backport(=copy) it to the kernel > that the RPI foundation maintains and that gets lots of exposure and > testing. The thing to do here is to get this code upstream, supporting out of tree code isn't particularly persuasive here - people commonly try to use their out of tree requirements as a reason to merge code that's got problems upstream and I don't want people to get the idea that this is an argument that's going to work.
Attachment:
signature.asc
Description: Digital signature
