[PATCH] spi: bcm2835: transform native-cs to gpio-cs on first spi_setup
swarren at wwwdotorg.org
Tue Apr 7 08:43:36 PDT 2015
On 04/06/2015 11:45 PM, Martin Sperl wrote:
>> On 07.04.2015, at 05:01, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> I believe the bcm283x have 2 types of SPI controller. There is 1
>> instance of the HW that this driver controls (SPI0), and that has CS0,
>> CS1. There are two instances of a different SPI HW block (SPI1, SPI2),
>> and those each have CS0, CS1, CS2. At least, that's my interpretation of
>> the table that shows the pinctrl module's per-pin alternate function values.
> Yes and no - SPI1 and SPI2 are a totally different beasts as these are
> "auxiliar devices" that have 2x2 word fifos, no DMA and minimal interrupt
> support and use a distinct register layout compared to SPI0.
> See BCM2835 Arm Peripherials page 20-27 for details.
> Essentially these are intended to get used for low speed devices or devices
> that run short transfers (<4-8 bytes)
> So these devices would need a totally separate SPI driver, which this driver
> does not and can not handle...
That's exactly what I said.
>> Should that be an error? Not being able to find the gpiochip implies the
>> code can't manipulate the CS lines at all, I think?
> Will add an dev_warn_once and contine without optimizations - the code
> still does check for the cs_gpio, so we would run without it?
> It could just be a rename of the pinctrl driver that would trigger this.
> You want it as an error?
If the rest of the driver is expected to always check whether
spi->cs_gpio is valid or not, and support the gpio-is-not-valid case, I
guess it's OK for that case *not* to error out.
I think we should at least warn to indicate that something unexpected
Shouldn't spi->cs_gpio be set to e.g. -1 if the pinctrl device can't be
found, so that the rest of the driver does know that the GPIO is invalid?
More information about the linux-rpi-kernel