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

[chris@printf.net (Chris Ball)]

Hi Russell,

On Sat, Feb 22 2014, Russell King - ARM Linux wrote:
>> > 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.

Ah, I guess I chose the wrong mail to reply to -- I'm talking about
merging the five patch mini-series that descends from this mail
straight away, not the 31 patch RFC.

> 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?

Sounds like an improvement.  Splitting up set_ios sounds cleaner than
using a "changes" field to me.  Thanks,

- Chris.
-- 
Chris Ball   <chris@printf.net>   <http://printf.net/>