* io-domain voltages as regulators? @ 2014-08-03 22:18 Heiko Stübner 2014-08-04 14:46 ` Mark Brown 2014-08-11 7:44 ` Linus Walleij 0 siblings, 2 replies; 6+ messages in thread From: Heiko Stübner @ 2014-08-03 22:18 UTC (permalink / raw) To: linux-arm-kernel Hi Mark, Linus, I'd like to clarify what the appropriate way to handle pin output voltages is. On the Rockchip SoCs the voltage for some groups of pins can be set between 3.3V and 1.8V ... like the MMC/SD pins who need this to support UHS mode cards. In [0] when talking about something different, Linus Walleij described a similar case as "I think we need to have a discussion with Mark Brown on how to handle this. We have previously had the case of MMC/SD level-shifters, where a certain setting gives a certain level of signals out, and another setting gives another level. Like two discrete levels. So we modeled that as a regulator provider inside the pin control driver eventually, see sh-pfc/pfc-sh73a0.c" As this sound like exactly the thing I'm trying to solve, is handling this via a regulator the correct general way? Thanks Heiko [0] https://lkml.org/lkml/2014/5/28/147 ^ permalink raw reply [flat|nested] 6+ messages in thread
* io-domain voltages as regulators? 2014-08-03 22:18 io-domain voltages as regulators? Heiko Stübner @ 2014-08-04 14:46 ` Mark Brown 2014-08-11 7:44 ` Linus Walleij 1 sibling, 0 replies; 6+ messages in thread From: Mark Brown @ 2014-08-04 14:46 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 04, 2014 at 12:18:40AM +0200, Heiko St?bner wrote: > As this sound like exactly the thing I'm trying to solve, is handling this via > a regulator the correct general way? My first thought is that it seems sensible if it's used as a regulated supply in a context where just a plain regulator might be used like MMC/SDIO type things. If it's only setting logic levels for I/O pins but isn't something that's being dynamically managed or really visible to software (it's just a board design thing) then it might not be worth it but if it might be controlled by changing an external regulator then using the same API seems like it might be sensible. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140804/237364a3/attachment.sig> ^ permalink raw reply [flat|nested] 6+ messages in thread
* io-domain voltages as regulators? 2014-08-03 22:18 io-domain voltages as regulators? Heiko Stübner 2014-08-04 14:46 ` Mark Brown @ 2014-08-11 7:44 ` Linus Walleij 2014-08-11 12:46 ` Ulf Hansson 1 sibling, 1 reply; 6+ messages in thread From: Linus Walleij @ 2014-08-11 7:44 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 4, 2014 at 12:18 AM, Heiko St?bner <heiko@sntech.de> wrote: [Adding Ulf Hansson to this discussion...] > Hi Mark, Linus, > > I'd like to clarify what the appropriate way to handle pin output voltages is. > On the Rockchip SoCs the voltage for some groups of pins can be set between > 3.3V and 1.8V ... like the MMC/SD pins who need this to support UHS mode > cards. This is called "vqmmc" in the mmc/sd subsystem. grep for mmc_set_signal_voltage() in drivers/mmc/core/* In drivers/mmc/core/core.c, you find: mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc"); Which gets the regulator to set the signal voltage, if such a regulator is specified for the host. Very simple and straight-forward, and handled by the MMC core. > In [0] when talking about something different, Linus Walleij described a > similar case as > > "I think we need to have a discussion with Mark Brown on how to > handle this. > We have previously had the case of MMC/SD level-shifters, where > a certain setting gives a certain level of signals out, and another setting > gives another level. Like two discrete levels. > So we modeled that as a regulator provider inside the pin control > driver eventually, see sh-pfc/pfc-sh73a0.c" > > As this sound like exactly the thing I'm trying to solve, is handling this via > a regulator the correct general way? Ithinkso. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 6+ messages in thread
* io-domain voltages as regulators? 2014-08-11 7:44 ` Linus Walleij @ 2014-08-11 12:46 ` Ulf Hansson 2014-08-12 15:13 ` Doug Anderson 0 siblings, 1 reply; 6+ messages in thread From: Ulf Hansson @ 2014-08-11 12:46 UTC (permalink / raw) To: linux-arm-kernel On 11 August 2014 09:44, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Aug 4, 2014 at 12:18 AM, Heiko St?bner <heiko@sntech.de> wrote: > > [Adding Ulf Hansson to this discussion...] > >> Hi Mark, Linus, >> >> I'd like to clarify what the appropriate way to handle pin output voltages is. >> On the Rockchip SoCs the voltage for some groups of pins can be set between >> 3.3V and 1.8V ... like the MMC/SD pins who need this to support UHS mode >> cards. > > This is called "vqmmc" in the mmc/sd subsystem. > > grep for mmc_set_signal_voltage() in drivers/mmc/core/* > > In drivers/mmc/core/core.c, you find: > > mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc"); > > Which gets the regulator to set the signal voltage, if such > a regulator is specified for the host. > > Very simple and straight-forward, and handled by the MMC core. > >> In [0] when talking about something different, Linus Walleij described a >> similar case as >> >> "I think we need to have a discussion with Mark Brown on how to >> handle this. >> We have previously had the case of MMC/SD level-shifters, where >> a certain setting gives a certain level of signals out, and another setting >> gives another level. Like two discrete levels. >> So we modeled that as a regulator provider inside the pin control >> driver eventually, see sh-pfc/pfc-sh73a0.c" >> >> As this sound like exactly the thing I'm trying to solve, is handling this via >> a regulator the correct general way? > > Ithinkso. Just to confirm, I fully agree with the above said. You may also find a good example in the mmci host driver for how to make use of the vqmmc regulator. Kind regards Uffe ^ permalink raw reply [flat|nested] 6+ messages in thread
* io-domain voltages as regulators? 2014-08-11 12:46 ` Ulf Hansson @ 2014-08-12 15:13 ` Doug Anderson 2014-08-13 6:22 ` Yuvaraj Cd 0 siblings, 1 reply; 6+ messages in thread From: Doug Anderson @ 2014-08-12 15:13 UTC (permalink / raw) To: linux-arm-kernel Hi, On Mon, Aug 11, 2014 at 5:46 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 11 August 2014 09:44, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Mon, Aug 4, 2014 at 12:18 AM, Heiko St?bner <heiko@sntech.de> wrote: >> >> [Adding Ulf Hansson to this discussion...] >> >>> Hi Mark, Linus, >>> >>> I'd like to clarify what the appropriate way to handle pin output voltages is. >>> On the Rockchip SoCs the voltage for some groups of pins can be set between >>> 3.3V and 1.8V ... like the MMC/SD pins who need this to support UHS mode >>> cards. >> >> This is called "vqmmc" in the mmc/sd subsystem. >> >> grep for mmc_set_signal_voltage() in drivers/mmc/core/* >> >> In drivers/mmc/core/core.c, you find: >> >> mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc"); >> >> Which gets the regulator to set the signal voltage, if such >> a regulator is specified for the host. >> >> Very simple and straight-forward, and handled by the MMC core. >> >>> In [0] when talking about something different, Linus Walleij described a >>> similar case as >>> >>> "I think we need to have a discussion with Mark Brown on how to >>> handle this. >>> We have previously had the case of MMC/SD level-shifters, where >>> a certain setting gives a certain level of signals out, and another setting >>> gives another level. Like two discrete levels. >>> So we modeled that as a regulator provider inside the pin control >>> driver eventually, see sh-pfc/pfc-sh73a0.c" >>> >>> As this sound like exactly the thing I'm trying to solve, is handling this via >>> a regulator the correct general way? >> >> Ithinkso. > > Just to confirm, I fully agree with the above said. > > You may also find a good example in the mmci host driver for how to > make use of the vqmmc regulator. Yuvaraj also submitted patches for dw_mmc: 4401241 New [1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators 4401261 New [2/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc 4401281 New [3/3] mmc: dw_mmc: Support voltage changes He seems to have dropped these patches on the floor and I had review feedback on them, but I think they're in the right direction. ^ permalink raw reply [flat|nested] 6+ messages in thread
* io-domain voltages as regulators? 2014-08-12 15:13 ` Doug Anderson @ 2014-08-13 6:22 ` Yuvaraj Cd 0 siblings, 0 replies; 6+ messages in thread From: Yuvaraj Cd @ 2014-08-13 6:22 UTC (permalink / raw) To: linux-arm-kernel On Tue, Aug 12, 2014 at 8:43 PM, Doug Anderson <dianders@chromium.org> wrote: > Hi, > > On Mon, Aug 11, 2014 at 5:46 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >> On 11 August 2014 09:44, Linus Walleij <linus.walleij@linaro.org> wrote: >>> On Mon, Aug 4, 2014 at 12:18 AM, Heiko St?bner <heiko@sntech.de> wrote: >>> >>> [Adding Ulf Hansson to this discussion...] >>> >>>> Hi Mark, Linus, >>>> >>>> I'd like to clarify what the appropriate way to handle pin output voltages is. >>>> On the Rockchip SoCs the voltage for some groups of pins can be set between >>>> 3.3V and 1.8V ... like the MMC/SD pins who need this to support UHS mode >>>> cards. >>> >>> This is called "vqmmc" in the mmc/sd subsystem. >>> >>> grep for mmc_set_signal_voltage() in drivers/mmc/core/* >>> >>> In drivers/mmc/core/core.c, you find: >>> >>> mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc"); >>> >>> Which gets the regulator to set the signal voltage, if such >>> a regulator is specified for the host. >>> >>> Very simple and straight-forward, and handled by the MMC core. >>> >>>> In [0] when talking about something different, Linus Walleij described a >>>> similar case as >>>> >>>> "I think we need to have a discussion with Mark Brown on how to >>>> handle this. >>>> We have previously had the case of MMC/SD level-shifters, where >>>> a certain setting gives a certain level of signals out, and another setting >>>> gives another level. Like two discrete levels. >>>> So we modeled that as a regulator provider inside the pin control >>>> driver eventually, see sh-pfc/pfc-sh73a0.c" >>>> >>>> As this sound like exactly the thing I'm trying to solve, is handling this via >>>> a regulator the correct general way? >>> >>> Ithinkso. >> >> Just to confirm, I fully agree with the above said. >> >> You may also find a good example in the mmci host driver for how to >> make use of the vqmmc regulator. > > Yuvaraj also submitted patches for dw_mmc: > > 4401241 New [1/3] mmc: dw_mmc: use mmc_regulator_get_supply > to handle regulators > 4401261 New [2/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc > 4401281 New [3/3] mmc: dw_mmc: Support voltage changes > > He seems to have dropped these patches on the floor and I had review > feedback on them, but I think they're in the right direction. I have not dropped these patches.I am trying out [3/3] mmc: dw_mmc: Support voltage changes without extra state machine as Seungwon Jeon suggested. I will post the next version soon. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-08-13 6:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-08-03 22:18 io-domain voltages as regulators? Heiko Stübner 2014-08-04 14:46 ` Mark Brown 2014-08-11 7:44 ` Linus Walleij 2014-08-11 12:46 ` Ulf Hansson 2014-08-12 15:13 ` Doug Anderson 2014-08-13 6:22 ` Yuvaraj Cd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox