On 17 September 2013 10:16, Guennadi Liakhovetski <g.liakhovet...@gmx.de> wrote: > (adding Mark to cc) > > On Tue, 17 Sep 2013, Ulf Hansson wrote: > >> On 16 September 2013 22:57, Guennadi Liakhovetski <g.liakhovet...@gmx.de> >> wrote: >> > Hi Ulf >> > >> > On Mon, 16 Sep 2013, Ulf Hansson wrote: >> > >> >> According to the eMMC/SD/SDIO specs the VDD voltage level must not be >> >> changed >> >> during the initialization, without a complete power cycle of the card. >> >> >> >> Before this patchset, some host drivers were trying to change voltage >> >> level >> >> at MMC_POWER_ON state, which is also what the protocol layer advised them >> >> to. >> >> This was not correctly done and is the reason to why quite messy code in >> >> the protocol layer has been needed, to handle a re-initialization >> >> sequence, >> >> typically triggered from a power_restore or resume. >> >> >> >> I have tried to make each patch in the patchset as small and separate as >> >> possible, surely the is room for improvments. Any suggestions are >> >> appreciated. >> >> >> >> An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host >> >> to tell the protocol layer that the host is able to perform a complete >> >> power >> >> cycle. Thus the protocol layer will try to negotiate the lowest possible >> >> VDD >> >> voltage level between the card and host. >> >> Hi Guennadi, >> >> > >> > I've got a question to this one. You mean a power cycle of a card, right? >> >> Correct! >> >> > What if the card power is supplied by a regulator. How do you tell whether >> > you can power cycle it or not? Maybe you can theoretically switch that >> > regulator - sometimes. On other occasions other users might be preventing >> > it from really powering off. Do you really need a guarantee, that every >> > time you issue a power down .set_ios() the card will really be switched >> > off? I don't see how this can be possible in my example? >> >> Yes, we need a guarantee to be able to conform to the specs. >> >> In one of my cases I am also using a regulator, but from a board >> configuration point of view I know I am the only user on this >> regulator, thus I can be sure I can switch it off when I want. >> >> I see your point though, and I am not sure how to adapt to this >> configuration. I suggest you to not set the MMC_CAP2_FULL_PWR_CYCLE >> for that mmc host - unless you can find a way to make sure you can cut >> and restore power when needed. > > So, do I understand correctly, that if we get a regulator exclusively and > it is capable of changing status (REGULATOR_CHANGE_STATUS) and it is not > always on, then we can assume, that every call to regulator_enable() / > regulator_disable() with a suitable use count _will_ switch power off or > on? Maybe then we could adjust mmc_regulator_get_supply() accordingly - > first try to get the regulator exclusively, if it fails, try shared. If > succeeded and the conditions are satisfied - set the new PWR_CYCLE flag.
For SD and SDIO cards, that would be enough - but not for eMMC since we have both VCC and VCCQ. If you want to change voltage level for eMMC, both VCC and VCCQ must be possible to power cycle, unless you have a hw-reset wire connected to the eMMC which is implemented by a host->ops callback. This complicates things for SD/SDIO as well, while trying to setup the conditions for when to set the PWR_CYCLE flag. BTW, thanks for bringing up this discussion! I have been thinking a bit around this as well. :-) Kind regards Ulf Hansson > > Thanks > Guennadi > >> Kind regards >> Ulf Hansson >> >> > >> > Thanks >> > Guennadi >> > >> >> >> >> >> >> Ulf Hansson (7): >> >> mmc: core: Let mmc_power_up|cycle take ocr as parameter >> >> mmc: core: Let mmc_set_signal_voltage take ocr as parameter >> >> mmc: core: Remove unnecessary retry mechanism at SDIO attach >> >> mmc: core: Cleanup code for setting ocr mask for SDIO >> >> mmc: core: Move cached value of the negotiated ocr mask to card >> >> struct >> >> mmc: core: Prevent violation of specs while initializing cards >> >> mmc: core: Collect common code for card ocr validation >> >> >> >> drivers/mmc/core/core.c | 66 +++++++++++++++++-------------------- >> >> drivers/mmc/core/core.h | 6 ++-- >> >> drivers/mmc/core/mmc.c | 29 +++++----------- >> >> drivers/mmc/core/sd.c | 41 +++++++---------------- >> >> drivers/mmc/core/sdio.c | 82 >> >> ++++++++++++++-------------------------------- >> >> include/linux/mmc/card.h | 1 + >> >> include/linux/mmc/host.h | 1 - >> >> 7 files changed, 79 insertions(+), 147 deletions(-) >> >> >> >> -- >> >> 1.7.9.5 > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
