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@xxxxxxxxxx> <http://printf.net/> -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
