Date: Mon, 3 Sep 2012 10:06:21 -0300 From: Luiz Otavio O Souza <loos.br@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Ian Lepore <freebsd@damnhippie.dyndns.org>, freebsd-arch@freebsd.org Subject: Re: spibus access serialization Message-ID: <6583C0FF-CC67-4C92-AD5F-87878703AA22@gmail.com> In-Reply-To: <3C91462E-1423-4AFC-B4C7-6239E698A98E@bsdimp.com> References: <B54C4C9A-76F4-45CC-94C3-628DDF901051@gmail.com> <A0F87D2D-B916-4FB5-9FDF-62807DED9A7E@bsdimp.com> <1346602529.1140.563.camel@revolution.hippie.lan> <3C91462E-1423-4AFC-B4C7-6239E698A98E@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 2, 2012, at 4:38 PM, Warner Losh wrote: >=20 > On Sep 2, 2012, at 10:15 AM, Ian Lepore wrote: >=20 >> 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: >>>=20 >>>>=20 >>>> 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). >>>=20 >>> 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. >>=20 >> 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. >=20 > Yes, that's been fixed (which is why I didn't think it would be a = problem, but it is). >=20 >> 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. >=20 > That's the question still, alas. I've been looking at how FDT does it = in Linux land, and they punt on this issue. We'll likely have to put = some effort into defining these things with atmel's FDT efforts. Their = FDT comes close by defining groups, but doesn't seem to take it down to = the individual pin to signal mapping. >=20 > Otherwise we'll have to fall back to arrays of pins that somehow get = associated with the device... >=20 >> 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. >=20 > Yes. The SAM9 processors have a new bit, CSAAT, which forces the line = to be asserted until you deassert it, not just during data transfers. A = quick grep of the code indicates that we don't use it, but I haven't = checked in detail... Hmm. I was thinking that using CSAAT was the only way to control the CS = pin from GPIO, but i didn't knew that CSAAT was something new (i was = reading the SAM9260 datasheet). Now I have no idea how to overcome that on older chips. >=20 >> 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. >=20 > Yes. And SPI mode too. These items should be programmed when the bus = is requested, imho, but perhaps there's a reason not to do this. The actual patch is just one piece of Patrick Kelsey's work on MMC/SD = SPI driver = (http://freebsd.1045724.n5.nabble.com/PATCH-MMC-SD-SPI-mode-driver-td55540= 34.html) which include new methods to limit the SPI speed for a device. I'm breaking the patch in smaller parts so it can be easily reviewed. Luiz=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6583C0FF-CC67-4C92-AD5F-87878703AA22>