On Wed, Feb 19, 2014 at 03:18:08PM +0530, Viresh Kumar wrote: > On 19 February 2014 15:13, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > > On Wed, Feb 19, 2014 at 11:43:19AM +0530, Viresh Kumar wrote: > >> Adding ST people as well who have access to boards and are working on SPEAr. > >> > >> On 18 February 2014 23:27, Russell King - ARM Linux > >> <linux@xxxxxxxxxxxxxxxx> wrote: > >> > 1) You're controlling the card power GPIO via the insertion/removal > >> > interrupt handler? What's wrong with using a vmmc regulator for > >> > that, which will be controlled via the MMC subsystem as required? > >> > >> Haven't explored that earlier.. Maybe its possible but no idea. > >> The requirements were like this: > >> - We may or maynot need a GPIO for controlling power > >> - If we need it, we may need to disable/enable power with card removal/ > >> insertion Or we may need to keep it enabled for ever.. > > > > So how is this any different from any other system which controls power to > > the MMC/SD socket? > > I am not claiming it to be different. I am just saying these were the > requirements > and I am not sure if they were satisfied with vmmc regulator. It might > be exactly > same in all other platforms. Are you aware that power control to the card is part of the MMC/SD/SDIO spec - and part of the protocol talking to the card? Hence why the mmc layer has support for its control built-in. If you don't want to use a regulator, then the right way to do this is to use the set_ios callback and check the power field - anything which is not MMC_POWER_OFF should result in power to the card being turned on. -- 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". -- 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
