[PATCH RFC 07/31] mmc: sdhci: push card_tasklet into threaded irq handler

[Russell King - ARM Linux]

On Sat, Feb 22, 2014 at 06:27:06PM +0000, Chris Ball wrote:
> Hi,
> 
> On Fri, Feb 21 2014, Russell King - ARM Linux wrote:
> > On Thu, Feb 20, 2014 at 04:48:58PM +0530, Viresh Kumar wrote:
> >> Nothing wrong in that, only right.. Do you want me to float a patch for
> >> this or you can get that done along with your series?
> >
> > I'll send a follow-up mini-series of five patches for it.  It shouldn't
> > depend all that much on the bigger series - and I think the first two
> > patches could well do with going into -rc.
> 
> Thanks.  Since testing resources might be scarce, and it looks like
> Viresh is in favor of the series, any objections to putting these in
> mmc-next straight away rather than waiting for test results to come in?

The series needs to be re-ordered to avoid patch 7 breaking sdhci-spear.
I'll send out a new series appropriately ordered.  I'm continuing to do
more to this driver as time permits.

One thing which I've toyed with is passing a "changes" field in struct
mmc_ios, so that host drivers can know what's changed and avoid resetting
the power, clocks, etc on every set_ios call.  Another thing I've toyed
with is the idea of splitting set_ios up into several sub-calls which
the core only calls with the various changes.

One of my reasonings for the second idea is that with the variability
in hosts, particularly with how they deal with the application of power,
it would be a good idea to allow hosts which do the "turn power on,
send 74 clocks" automonously avoid having to deal with the power_up
transition.

It also means that hosts aren't having to work out if the timings have
changed, or the clocks, or anything else.

What are your thoughts on that?

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".