Re: [spi-devel-general] spi_mmc bus concurrency fix

[Hans Eklund <hans-9ai+6vhHfRGzQB+pC5nmwQ@public.gmane.org>]

Hi again.

Lets move on.

I have not solved the roots to the problem. I´ve not been given time to 
fiddle with the framework internals. Im not sure im the man to do that 
in the end. But, I have managed to get MMC/SD cards running concurrently 
with m25p80 spi flash driver. No fix to either the master
driver or the framework. Both reading and writing and card init works. 
No multiple block writing yet though. All done vs uClinux 2008R1-RC8 
(kernel 2.6.22) and my old spi_mmc driver which implemented a separate 
block layer. Written and tested mostly within the Blackfin uClinux 
community.

About the fix: In short i predefine a sequence of transfers in a single 
message matching the MMC/SD protocol, simply assuming it will work, 
checking the tokens and if tokens looked fine return with a smile. It 
seem to work. It is the only way to get atomicity on the bus for now. It 
is surley best to patch up the drivers/mmc/host/mmc_spi.c code and use 
that driver from now on, putting my old spi_mmc driver on the shelf.

Bryan, Mike and other Blackfin-uClinux developers:

What is the status on the drivers/mmc/host/mmc_spi.c when connected to 
the Blackfin spi master? Mike pointed out that my old spi_mmc should be 
obsoleted(with all rights), with that statement I got the feeling the 
"new" mainline driver was tested to some extent, correct? I would need a 
test/develop environment to move on with this. I´ll try to backport the 
mmc_spi found in 2.6.24 to fit 2008R1-RC8 as a start, or do you have any 
other suggestions?

I hope i get the attention of Jan Nikitenko and Hans-Peter Nilsson on 
this subject also as they seem to have been a part of the mmc_spi driver 
developing.

/regards
Hans Eklund,
Rubico AB,
Sweden.

David Brownell skrev:
> On Thursday 28 February 2008, Phil Wilshire wrote:
>> I agree, I did have some concerns about the callback issue.
>> It also looks like we have enough people + momentum on this problem to
>> get a fix in good time. So I'll wait to see what happens.
> 
> Actually, I'm not sure I'd agree on that.  Folk want a fix,
> but nobody (including me!) has sent something that's quite
> mergeable yet.
> 
> I think part of the solution may be what someone (Brian?)
> observed:  that growing the mid-layer to handle some of the
> queue management functions should help, no matter what
> eventual solution is adopted.
> 
> That might be as little as providing a default "add to queue"
> and "take from queue" mechanism and starting to phase it into
> use in the various master controller drivers.  When they use
> that scheme, it should be easy to splice in alternative queue
> management policies (notably:  "only spi_mmc can access the
> bus for now") without changing the controller drivers.
> 
> So it'd be really nice if someone could come up with a patch
> like that to help get some forward motion ... unless there's
> a better suggestion for how to move forward?
> 
> - Dave
> 
>