From mboxrd@z Thu Jan 1 00:00:00 1970 From: chris@printf.net (Chris Ball) Date: Sat, 22 Feb 2014 19:11:57 +0000 Subject: [PATCH RFC 07/31] mmc: sdhci: push card_tasklet into threaded irq handler In-Reply-To: <20140222190536.GI21483@n2100.arm.linux.org.uk> (Russell King's message of "Sat, 22 Feb 2014 19:05:36 +0000") References: <20140219094322.GR21483@n2100.arm.linux.org.uk> <20140219095212.GT21483@n2100.arm.linux.org.uk> <20140219105011.GU21483@n2100.arm.linux.org.uk> <20140220105903.GY21483@n2100.arm.linux.org.uk> <20140221103710.GB21483@n2100.arm.linux.org.uk> <8638jbvw91.fsf@void.printf.net> <20140222190536.GI21483@n2100.arm.linux.org.uk> Message-ID: <86ppmft11e.fsf@void.printf.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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