On 11 May 2015 at 16:01, Ben Hutchings <ben.hutchings@xxxxxxxxxxxxxxx> wrote: > On Mon, 2015-05-11 at 10:54 +0200, Ulf Hansson wrote: >> On 6 May 2015 at 15:49, Ben Hutchings <ben.hutchings@xxxxxxxxxxxxxxx> wrote: >> > On Wed, 2015-05-06 at 10:44 +0200, Ulf Hansson wrote: >> >> On 6 May 2015 at 03:38, Ben Hutchings <ben.hutchings@xxxxxxxxxxxxxxx> wrote: >> >> > On Tue, 2015-05-05 at 10:47 +0200, Ulf Hansson wrote: >> >> >> On 5 May 2015 at 10:35, Ben Dooks <ben.dooks@xxxxxxxxxxxxxxx> wrote: >> >> >> > On 05/05/15 10:56, Ulf Hansson wrote: >> >> >> >> On 30 April 2015 at 14:32, Ben Hutchings <ben.hutchings@xxxxxxxxxxxxxxx> wrote: >> >> >> >>> Implement voltage switch, supporting modes up to SDR-50. >> >> >> >>> >> >> >> >>> Based on work by Shinobu Uehara, Rob Taylor, William Towle and Ian Molton. >> >> >> >>> >> >> >> >>> This uses two voltage regulators, one external and one on the pfc. >> >> >> >> >> >> >> >> Why two? If there is a parent child relation ship, that should be >> >> >> >> handled through the regulator tree, right!? Please elaborate. >> >> >> > >> >> >> > The card main power is separate from the IO line voltages. >> >> >> > >> >> >> > To get to the high-speed, card power is left at 3.3V and the IO >> >> >> > voltage is changed to 1.8V. >> >> >> > >> >> >> > In the systems we have the power gate is separate from the controls >> >> >> > for the IO but not integrated into the MMC controller itself. >> >> > >> >> > In this case, there are *three* regulators: >> >> > >> >> > 1. External regulator for card power (VDD pin): "vmmc" >> >> > 2. External regulator for pull-up voltage for the data pins: "vqmmc" >> >> >> >> Is this really a regulator and not just about changing a pinctrl setting? >> > >> > Looking at the Lager board, the pull-up voltage appears to be controlled >> > by the external PMIC (DA9063), which is signalled using GPIOs (I don't >> > know why, when it's also connected to I2C). >> >> Okay, thus we should have a regulator for it. >> >> > >> >> The reason why I wonder, is because there are several other mmc host >> >> driver's the use a specific pinctrl state for this. >> >> >> >> > 3. Internal regulator for input(?) level on the data pins: >> >> > "vqmmc_ref" (I'm open to suggestions of a better name) >> > >> > This one is implemented in the pinctrl (pfc) block. >> >> I understand this as we should have a specific UHS pinctrl state, >> instead of a regulator. Right? > > That was another option I considered, but I didn't see anything in the > pinctrl API that would allow changing the pin configuration dynamically. > (And sh_mobile_sdhi doesn't explicitly do anything with pinctrl at the > moment.) > > Now that you mention pinctrl states, I can see that might be a good way > to handle this. Since the states are identified by strings, does that > mean it's OK to add a driver-specific state such as "sh-pfc-1.8v" and > not add it to the common pinctrl headers? Yes, we already have other drivers doing it like that. Depending on what SoC this driver is used for, maybe you want this state to be optional though. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
