[U-Boot] spi subystem maintainer?
Mike Frysinger
vapier at gentoo.org
Thu Aug 18 22:50:52 CEST 2011
On Thursday, February 17, 2011 00:04:35 Mike Frysinger wrote:
> 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:
> > >> 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 ?
seems this stalled because you guys instead took a queue+flush approach in
your spi bus. but ive come across another hardware bus which (sounds like it)
has the same limitations -- the ICH SPI controller from intel. you have to
program into its hardware registers the command, the optional address, and
whether you're going to be reading/writing afterwards. they needed to drop
the SPI_XFER_{START,END} flags just like you in order to make things work.
further, while talking to people, it isnt as big of a deal as i had originally
thought. the overhead from polling the SPI flash does go up slightly, but
really only like by one byte on the bus (and the overhead to setup/bring down
the transfer, but that's fairly minuscule).
so what i'm thinking is that since no other flags have materialized, we punt
the SPI_XFER_{BEGIN,END} and make the API more Linux like. when i looked
through the source, i couldnt find any other consumers that'd be adversely
affected.
any other thoughts on the matter ?
-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/20110818/8c3ec1bf/attachment.pgp
More information about the U-Boot
mailing list