From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Thu, 17 Feb 2011 00:04:35 -0500 Subject: [U-Boot] spi subystem maintainer? In-Reply-To: References: <9A3702C1-3ED1-4F24-A0BC-CA7DAEA46182@kernel.crashing.org> <201102150336.29776.vapier@gentoo.org> Message-ID: <201102170004.37088.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday, February 15, 2011 18:10:47 Kumar Gala wrote: > On Feb 15, 2011, at 2:36 AM, Mike Frysinger wrote: > > On Thursday, February 03, 2011 05:36:38 Kumar Gala wrote: > >> On Feb 2, 2011, at 3:30 AM, Reinhard Meyer wrote: > >>> Dear Stefano Babic: > >>>> On 02/02/2011 08:23 AM, Kumar Gala wrote: > >>>>> Wanted to see if anyone had input on how to deal with the SPI > >>>>> controller on some of our newer parts. It expects command & data > >>>>> xfer's to happen together. However our current code does not call > >>>>> spi_xfer() that way. > >>>> > >>>> Which is your concrete case ? spi_xfer is responsible to setup the > >>>> controller and to start the transfer, and everything could be done > >>>> inside this function. What do you mean exactly with command and data ? > >>> > >>> I think he refers to the common "problem" that many SPI devices > >>> require CS to stay low during both "phases" of issuing the > >>> read/write command and transfering the actual data. > >>> > >>> Current u-boot code calls spi_xfer() two times. > >>> > >>> Hardware controlled CS often go high between both calls, which > >>> requires you to (at least) use GPIO controlled CS, or, even worse, > >>> use bitbang SPI (in cases where the SPI pin assignment is in groups, > >>> not individually). > >> > >> That's correct, and with the newer FSL controller's we dont have direct > >> control over the CS. I'm thinking we need to have the command and > >> response dealt with in a single call to spi_xfer instead of what we seem > >> > >> to do all over the place today: > >> ret = spi_xfer(spi, 8, &cmd, NULL, flags); > >> if (ret) { > >> > >> debug("SF: Failed to send command %02x: %d\n", cmd, ret); > >> return ret; > >> > >> } > >> > >> if (len) { > >> > >> ret = spi_xfer(spi, len * 8, NULL, response, > >> SPI_XFER_END); if (ret) > >> > >> debug("SF: Failed to read response (%zu bytes): > >> %d\n", len, ret); > >> > >> } > >> > >> Needs to turn into something like: > >> ret = spi_xfer(spi, 8 + len * 8, &cmd, response, flags | SPI_XFER_END) > > > > this should be easier in my sf branch as i unified a bunch of the > > functions. but while this will probably work for the main commands, how > > is this supposed to work for the status polling ? that function is > > fundamentally based around setting up a transfer/command and then > > continuously shifting out a single result and checking it before > > shifting out another. for your controller, the only way to make it work > > is to do the full transaction every time. > > Probably have to do a transaction every time. looking at the Linux driver, it seems to do just that. i guess if Linux is getting by with a stricter API, then there shouldnt be a problem for U-Boot either. i dont suppose anyone knows of devices that are problematic in Linux or would be broken in U-Boot by this API change in general ? this assumes of course that the SPI API as used in Linux works for you ? > Do you have a tree for these changes? Do you expect them to be in place > for release after v2011.03 the sf branch of my blackfin tree. if no one gives me any feedback (i posted the patches on the list a while ago), i guess i'll see about merging post the next release. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20110217/67e718d7/attachment.pgp