[PATCH V2 - RESEND] SPI: BCM2835: allow arbitrary GPIO to act as SPI-chip_select

[Mark Brown]

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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20150325/1f5b19cc/attachment.sig>