Re: [PATCH 2/3] spi: spi-gpio: Delete references to non-GENERIC_BITBANG

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Wed, Feb 14, 2018 at 7:53 PM, Trent Piepho <tpiepho@xxxxxxxxxx> wrote:
> On Wed, 2018-02-14 at 16:01 +0000, Mark Brown wrote:
>> On Mon, Feb 12, 2018 at 01:45:31PM +0100, Linus Walleij wrote:
>>
>> > The non-generic bitbang was a feature where a platform could optimize
>> > SPI bit-banging by inlining the routines to hammer GPIO lines into
>> > the GPIO bitbanging driver as direct register writes using a custom
>> > set of GPIO library calls.
>> > It does not work with multiplatform concepts, violates everything
>> > about how GPIO is made generic and is just generally a bad idea,
>> > even on legacy system. Also there is no single user in the entire
>> > kernel (for good reasons).
>>
>> It's not expected that users should go upstream and it doesn't seem
>> helpful to delete without replacement.  The original idea was to allow
>> things like setting multiple GPIOs at once if there were calls for that,
>> now that gpiolib has support for that we should at least convert to it
>> before removing the hook.
>
> This ability really does make a difference.  I wrote a bit-banged JTAG
> driver a powerpc embedded device.  Using the int based gpiolib, I could
> get about a 1 MHz clock.  By allowing one to define a wrapper that
> could take compiled in gpio settings, I could get that clock up to
> something like 20 MHz.  The device had to load an FPGA image via JTAG
> when it started, so this was something like 5 seconds of boot time that
> would become almost two minutes without the ability to do GPIOs really
> fast.  That's the difference between a product appearing to customers
> as quick compared to what they expect vs pathetic.
>
> Of course this never made it into the upstream kernel.  It only worked
> on that specific product.
>
> The biggest win was due to locking.  gpiolib needs each gpio set/get to
> be atomic vs other gpio consumers, so you end up with locks around each
> call.  This is huge overhead when a gpio only needs a single machine
> instruction.  I could tell the wrapper to lock the gpios at the start
> of a JTAG op and unlock after and reduce this overhead by orders of
> magnitude.

I'm dropping this patch for now, we could revisit it and look at the
new gpiolib API for driving multiple lines with single register writes.

I remember I actually pushed SPI as an example I wanted to see
converted when we implemented that API :/

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html