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

From: Trent Piepho <tpiepho@impinj.com>
To: "broonie@kernel.org" <broonie@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>
Cc: "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH 2/3] spi: spi-gpio: Delete references to non-GENERIC_BITBANG
Date: Wed, 14 Feb 2018 18:53:43 +0000	[thread overview]
Message-ID: <1518634423.25567.42.camel@impinj.com> (raw)
In-Reply-To: <20180214160122.GE12658@sirena.org.uk>

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.