Date: Fri, 27 May 2016 08:50:17 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Patrick Kelsey <pkelsey@freebsd.org> Cc: "freebsd-embedded@freebsd.org" <freebsd-embedded@freebsd.org> Subject: Re: spibus: migrate to bus acquire/release semantics Message-ID: <CAJ-VmokmKpkbaEZTBa7chZUZgppnxzeLodAn7s5ObOL6Oyo7ow@mail.gmail.com> In-Reply-To: <CAD44qMWj-QFtcgYkQksH2_RkPyuacJMC9fmm4gZ_gm6X1fRa_Q@mail.gmail.com> References: <CAJ-VmomT=tfs4-vQt9MCQMu9P4SROOzmLEg_cxmh8vVSV3Vk3Q@mail.gmail.com> <CAD44qMWj-QFtcgYkQksH2_RkPyuacJMC9fmm4gZ_gm6X1fRa_Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 May 2016 at 22:26, Patrick Kelsey <pkelsey@freebsd.org> wrote: > > > 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. Hi, Right. I think warner mentioned something about devices that wanted and devices that didn't want this kind of behaviour. Ian has suggested that we implement it as a per-acquire flag, so the SPI user can determine how they'd like to do things. I'd like to do that after doing the initial conversion, and then likely after I implement some ivars that expose spibus capabilities. So, my (vague) plan is to get this patchset into -HEAD, as it's one enormous API churn that should be a no-op with the current users, and then add ivars for the bus capabilities so things like mmcspi can decide whether they're going to get what they need out of it, and then start porting more of the mmcspi patchset. What hardware were you testing on? I have some mmcspi hardware here, but I'd rather first verify that this works on the original hardware for this project before trying to adapt it to work on the $10 AR9331 part I have.. Thanks! -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokmKpkbaEZTBa7chZUZgppnxzeLodAn7s5ObOL6Oyo7ow>