[PATCH V2 - RESEND] SPI: BCM2835: allow arbitrary GPIO to act as SPI-chip_select
broonie at kernel.org
Wed Mar 25 09:54:41 PDT 2015
On Wed, Mar 25, 2015 at 05:13:13PM +0100, Martin Sperl wrote:
> > On 25.03.2015, at 16:16, Mark Brown <broonie at kernel.org> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: Digital signature
More information about the linux-rpi-kernel