Date: Mon, 03 Sep 2012 08:41:02 -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: <1346683262.1140.582.camel@revolution.hippie.lan> 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 Sun, 2012-09-02 at 13:38 -0600, Warner Losh wrote: > > 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. > > Yes, that's been fixed (which is why I didn't think it would be a > problem, but it is). > > > 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. > > 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. Hmmm, if the workaround is needed only on rm9200 hardware, then there are only two choices for where the chip select pins live (PIOA or PIOD banks). I think it should be possible to sniff out whether the chip select pins have been configured to PIOAn or PIODn by reading the periphid registers, so we could potentially get the SPI code fixed without solving the difficult problem of managing pin assignments across different SoCs in the family. I should have sam9 hardware arriving in a couple weeks, then I'll be able to make changes and test that they work on rm9200 and sam9. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1346683262.1140.582.camel>