Date: Sun, 02 Sep 2012 10:15:29 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org, Luiz Otavio O Souza <loos.br@gmail.com> Subject: Re: spibus access serialization Message-ID: <1346602529.1140.563.camel@revolution.hippie.lan> In-Reply-To: <A0F87D2D-B916-4FB5-9FDF-62807DED9A7E@bsdimp.com> References: <B54C4C9A-76F4-45CC-94C3-628DDF901051@gmail.com> <A0F87D2D-B916-4FB5-9FDF-62807DED9A7E@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2012-09-02 at 08:47 -0600, Warner Losh wrote: > On Sep 2, 2012, at 6:37 AM, Luiz Otavio O Souza wrote: > > > Hi, > > > > I've some embedded systems with spi devices that share the same spibus and because of that i'm working to get some kind of access serialization on spibus and also protection to devices which need a series of spi transfers to achieve some goal. > > > > The SPI usage (with all the patches applied) goes like this: > > > > /* Wait until the spibus is free. When free, acquire the bus and select the device */ > > SPIBUS_ACQUIRE_BUS(spibus, device); > > Does it do this with a sleep? > > > /* Program the CPLD to read data from NAND */ > > SPIBUS_TRANSFER(spibus, device, &cmd); > > > > /* Read 'n' bytes from CPLD */ > > SPIBUS_TRANSFER(spibus, device, &cmd); > > > > /* Release the spibus and deselect the device */ > > SPIBUS_RELEASE_BUS(spibus, device); > > > > While today everything is done inside SPIBUS_TRANSFER(). > > > > The patch spibus-01.diff adds the bus methods and the default methods. > > > > The spibus-02-devices.diff adds the needed glue to all spi devices (dev/flash/at45d.c, dev/flash/mx25l.c, arm/lpc/ssd1289.c, mips/atheros/pcf2123_rtc.c). As the default methods are just nops, there are no functional changes. > > > > On spibus-03-controllers.diff we finally add the serialization methods to spi controllers (mips/atheros/ar71xx_spi.c and arm/lpc/lpc_spi.c) and change the device CS to happen on bus acquire and release and not on start and end of each transfer. > > > > The spi controller on arm/at91/at91_spi.c wasn't changed because looks like it will be need to move the device CS control from the controller and use it as a GPIO pin. I need to read more of at91 code before i can suggest some change there. Until there it will work just as now (no serialization and selecting/deselecting the device within each transfer). > > The at91_spi controller controls which CS line is asserted. So long as you don't change the bits in the registers, it will stay asserted. I think it can fit with this scheme. I'll have to take a closer look. All my AT91 devices have only one chip on the spi bus. Unfortunately, the atmel SPI controller will de-assert the chip select when the transmit register (or PDC) runs out of data. It's a bug that may only affect rm9200; I haven't checked the errata and docs for the sam9 series to see if they fixed it. The way to fix the problem is indeed to take over the handling of chip selects in the driver, by taking the pins away from the device and managing them as GPIOs. Doing that is on my to-do list, but I've been waiting for some resolution of the "how do we manage device/gpio pin setup across the atmel SoC family" questions. This auto-deassert in rm9200 is also the bug that causes us to run the SPI bus at roughly 1/20th of its rated speed, to ensure that we never get a spurios chip de-select in the middle of a transfer due to momentary PDC bus starvation. Speaking of SPI bus speed, that's the other wart in our SPI support. We need a speed limit member in the spi request structure, so that drivers of individual devices on the bus can indicate the limit for their specific devices. I'd be happy to see that get added sooner rather than later, even if it takes a while to get all the low-level drivers supporting it. I think the new field in the struct should indicate the fastest speed in Hz that the device can handle the bus running, with zero meaning no limit. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1346602529.1140.563.camel>