* Tony Lindgren <[email protected]> [121022 10:11]: > * Haojian Zhuang <[email protected]> [121022 03:11]: > > On Sat, Oct 20, 2012 at 3:13 AM, Tony Lindgren <[email protected]> wrote: > > > * Haojian Zhuang <[email protected]> [121018 02:08]: > > >> Add pinconf generic support with POWER SOURCE, BIAS PULL. > > > ... > > > > > >> + case PIN_CONFIG_POWER_SOURCE: > > >> + if (pcs->psmask == PCS_OFF_DISABLED > > >> + || pcs->psshift == PCS_OFF_DISABLED) > > >> + return -ENOTSUPP; > > >> + data &= pcs->psmask; > > >> + data = data >> pcs->psshift; > > >> + *config = data; > > >> + return 0; > > >> + break; > > > > > > Hmm, only slightly related to this patch, mostly a generic > > > question to others: Do others have any mux registers with > > > status bits for things like PIN_CONFIG_POWER_SOURCE? > > > > > > I could use PIN_CONFIG_POWER_SOURCE for controlling the PBIAS > > > for omap MMC. But there's also a status bit that needs to be > > > checked for that. I think there was some other similar mux > > > register for USB PHY that has a status register. > > > > > > So I'm wondering should the checking for status bit be handled > > > in the pinctrl consume driver? Or should we have some bindings > > > for that? > > > > > > > Do you mean that the status register only exists in USB PHY controller or > > MMC controller? > > The status register is in the MMC PBIAS register that is mux > related otherwise. From OMAP4470_ES1.0_PUBLIC_TRM_vE.pdf, > Table 19-599. CONTROL_PBIASLITE: > > Bits > 26 MMC1_PWDNZ > 25 MMC1_PBIASLITE_HIZ_MODE > 24 MMC1_PBIASLITE_SUPPLY_HI_OUT > 23 MMC1_PBIASLITE_VMODE_ERROR then this bit needs to clear.. > 22 MMC1_PBIASLITE_PWRDNZ > 21 MMC1_PBIASLITE_VMODE ..after VMODE bit is set to 3V > > > If so, could we use regulator framework in USB PHY or MMC driver? > > Yes we could use regulator framework for that that. Or just read the > status in the MMC driver for that bit if nobody else has mixed > mux-regulator needs like this. > > The sequence is MMC specific, so from that point of view it would > make sense to have the logic in the MMC driver.
Well it turns out the VMODE_ERROR bit is not just for VMODE, it's a comparator that can also triggers for the other invalid states for CONTROL_PBIASLITE pinconf register. So hiding VMODE_ERROR into a regulator would be wrong. For now, VMODE best handled using PIN_CONFIG_POWER_SOURCE and let the MMC driver do the checking using the pinconf API. Regards, Tony _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
