Date: Wed, 5 Sep 2012 08:26:46 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-arch@freebsd.org, Luiz Otavio O Souza <loos.br@gmail.com> Subject: Re: spibus access serialization Message-ID: <FA449B6B-3687-4A8B-9559-8C62226D2B14@bsdimp.com> In-Reply-To: <1346683262.1140.582.camel@revolution.hippie.lan> 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> <1346683262.1140.582.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 3, 2012, at 8:41 AM, Ian Lepore wrote: > 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. >>=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 >=20 > 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. >=20 > 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. I think a full test for this serialization might be the ENC28J60 SPI = Ethernet module. You can get one here on ebay: = http://www.ebay.com/itm/Mini-ENC28J60-Ethernet-LAN-Network-Module-For-51-A= VR-STM32-LPC-/140843724204?pt=3DBI_Electrical_Equipment_Tools&hash=3Ditem2= 0caf0adac for < $5.00. There are Linux drivers available, and the datasheet for = this item appears to be fairly complete. This board would be easy to = connect to the SPI bus of the G45 board you are getting with standard = jumpers. I recently bought a bunch on Amazon for about $5.00. If you = could support this on a board that also had a dataflash, you'd be sure = that the spi system was good. However, in looking at it, we'd need to beef up the at91 gpio stuff a = bit, since it needs an interrupt line and a reset line. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FA449B6B-3687-4A8B-9559-8C62226D2B14>