From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH] spi: bcm2835: transform native-cs to gpio-cs on first spi_setup Date: Tue, 07 Apr 2015 09:43:36 -0600 Message-ID: <5523FB28.5050202@wwwdotorg.org> References: <1428340592-3196-2-git-send-email-kernel@martin.sperl.org> <5523487B.70501@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Brown , Lee Jones , linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Martin Sperl Return-path: In-Reply-To: Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On 04/06/2015 11:45 PM, Martin Sperl wrote: > >> On 07.04.2015, at 05:01, Stephen Warren 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 happened. 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? -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html