Date: Fri, 27 May 2016 01:26:21 -0400 From: Patrick Kelsey <pkelsey@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-embedded@freebsd.org" <freebsd-embedded@freebsd.org> Subject: Re: spibus: migrate to bus acquire/release semantics Message-ID: <CAD44qMWj-QFtcgYkQksH2_RkPyuacJMC9fmm4gZ_gm6X1fRa_Q@mail.gmail.com> In-Reply-To: <CAJ-VmomT=tfs4-vQt9MCQMu9P4SROOzmLEg_cxmh8vVSV3Vk3Q@mail.gmail.com> References: <CAJ-VmomT=tfs4-vQt9MCQMu9P4SROOzmLEg_cxmh8vVSV3Vk3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 26, 2016 at 10:00 PM, Adrian Chadd <adrian@freebsd.org> wrote: > hi, > > Here's the first part of the work needed to bring mmcspi into the > tree. It also fixes concurrent SPI controller accesses for a variety > of controllers which currently don't consistently implement it - > AR71xx spi doesn't, but brcm2835 spi does. > > https://reviews.freebsd.org/D6588 > > I'd appreciate some feedback and testing. > > Now, this doesn't implement it for all of the controllers, only the > simple ones. The broadcom and other arm ones aren't migrated, because > CS is asserted in a variety of different ways there. Now, it's not a > /huge/ deal, it just means that CS isn't asserted for the entirety of > a transaction set. For mmcspi (which I think assumes this is the > case), we may have to add a controller ivar that indicates if it > supports it or not, so mmcspi and other devices can implement it > appropriately. > > Another good example of this would be an LCD controller. Ideally you'd do > this: > > * acquire SPI bus > * assert command line > * do SPI transaction, with CS asserted > * deassert command line, assert data line > * do SPI transaction, with CS asserted > * release SPI bus > > Now, CS doesn't have to be asserted between transactions, but the > command/data commands have to happen together like that. > > Thanks! > > Thanks for continuing to work on this. One thing mmcspi requires is the ability to control chip select state on a per-SPI-transfer basis, because correct initialization requires providing at least 74 clocks to the device with both CS and MOSI set to high. That means initialization requires: acquire bus clock out enough 0xff with CS high to meet the requirement release bus The mmcspi driver is written so that CS will remain asserted across however many individual SPI-transfers it takes to execute a given MMC/SD command. It is not entirely clear whether this is required. I only had access to the simplified spec, which omits SPI timing diagrams found in the full spec, and possibly further related discussion. Based on the range of goofy behaviors I observed in the set of cards I tested with, I was motivated to be conservative with the treatment of CS during MMC/SD command execution. If it is the case that holding CS asserted during the entire MMC/SD command execution is truly required in some or all cases, then if the underlying SPI controller doesn't support that, I don't think there is anything the mmcspi driver can do other than print a warning. Aside from whether holding CS asserted across all of the individual transfers that the mmcspi driver issues during execution of a single MMC/SD command is truly required, I think this is a useful level of control to have in the interface. There are certainly SPI devices out there that do specific things on low-to-high transitions of CS and thus can require such care. One example is the LTC2440 analog-to-digital converter, which will exit serial-data-out mode and start a new conversion on a low-to-high CS transition. It also so happens that with this device, you detect end-of-conversion by checking the first bit clocked out of it. This encourages a driver implementation that does an 8-bit read to check end of conversion (for bus efficiency), then reads the remaining 24 bits if the end of conversion flag is set in the initial 8 bits retrieved. If CS can't be held high across the final 8-bit poll read and subsequent 24-bit rest-of-result read, the device will change modes and the conversion data will be lost. Without CS control across transactions, the fallback would be for completion polling to take 4 times as long as it needs to as 32-bit reads would always have to be used. -Patrick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD44qMWj-QFtcgYkQksH2_RkPyuacJMC9fmm4gZ_gm6X1fRa_Q>