On Nov 8, 2012, at 7:03 PM, Philip Rakity <prakity@xxxxxxxxxx> wrote: > Don't know enough about the device tree to help. Originally I suggested a quirk simular to what you are suggesting but it was felt to be too specific since the bits in caps2 achieve the same effect. Maybe your board specific code can check if the regulator is capable of switching and can be turned on and off. Not sure how to do the later. Checking the usage count does not help. You want exclusive access. Mark Brown might know how to do this else perhaps the regulator framework needs extending. upon reflection you can configure the regulator supply with the name of the specific device. That should make it exclusive to the mmc subsystem. In the general case I do not know how one can test for this (in say sdhci.c). > > ----- Reply message ----- > From: "Daniel Drake" <dsd@xxxxxxxxxx> > To: "Philip Rakity" <prakity@xxxxxxxxxx> > Cc: "Johan Rudholm" <jrudholm@xxxxxxxxx>, "Chris Ball" <cjb@xxxxxxxxxx>, "linux-mmc@xxxxxxxxxxxxxxx" <linux-mmc@xxxxxxxxxxxxxxx> > Subject: UHS-I voltage switching on OLPC XO-1.75 > Date: Thu, Nov 8, 2012 19:52 > > > > On Thu, Nov 8, 2012 at 12:48 PM, Philip Rakity <prakity@xxxxxxxxxx> wrote: > > This is already there. Use broken caps and in the board code clear out the > > nits in caps2. > > There is no board code; we're working with device tree. So I'm still > not exactly clear on the best way to work this. > > Maybe something like this: "sdhci,disable-1-8v" property in the device > tree, would trigger the sdhci-pxa2 code to: > 1. sdhci_readl() to retrieve caps and caps1 > 2. Drop the 1.8v flag from caps1 > 3. Set the BROKEN_CAPS quirk > > It would work but I'm not too fond of it, and I can't really think of > an approach I do like (except maybe having a specific "1.8v broken" > sdhci quirk). > > Daniel ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -- 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
