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

[Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On Wed, Mar 25, 2015 at 05:13:13PM +0100, Martin Sperl wrote:
> > On 25.03.2015, at 16:16, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]