From owner-freebsd-arch@FreeBSD.ORG Mon Sep 3 14:41:18 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2159810657A8 for ; Mon, 3 Sep 2012 14:41:18 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 97D168FC14 for ; Mon, 3 Sep 2012 14:41:17 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q83Ef51b035656 for ; Mon, 3 Sep 2012 08:41:11 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q83Ef2JG040298; Mon, 3 Sep 2012 08:41:02 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Warner Losh In-Reply-To: <3C91462E-1423-4AFC-B4C7-6239E698A98E@bsdimp.com> References: <1346602529.1140.563.camel@revolution.hippie.lan> <3C91462E-1423-4AFC-B4C7-6239E698A98E@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 03 Sep 2012 08:41:02 -0600 Message-ID: <1346683262.1140.582.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, Luiz Otavio O Souza Subject: Re: spibus access serialization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 14:41:18 -0000 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