Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
On Fri, 2015-01-30 at 11:37 +0100, Marek Szyprowski wrote: > Hello, > > On 2015-01-29 11:56, Javier Martinez Canillas wrote: > > On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski > > wrote: > >>> Also, I wonder whether we could extend the mmc-pwrseq to cover your > >>> case? Did you consider that as an option? > >> > >> I didn't consider mmc-pwrseq yet. For me it looked straightforward to > > I agree with Ulf that using mmc-pwrseq would be a good solution and in > > fact I think the pwrseq_simple [0] driver will fit your use case since > > it supports a reset GPIO pin which is what many WLAN chips attached to > > a SDIO interface use. > > Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the > hardware and it mmc-pwrseq-simple cannot be used directly. > > Although the signal is called RSTN (on Odroid U3 schema), the eMMC card > gets resetted not on low line level, but during the rising edge. This RSTN > line is also pulled up by the external resistor. However, the strangest > thing is the fact that the default SoC configuration (which is applied > during hw reset) for this GPIO line is input, pulled-down. The SoC > internal pull-down is stronger than the external pull up, so in the end, > during the SoC reboot the RSTN signal is set to zero. Later bootloader > disables the internal pull-down. > > To sum up - to perform proper reboot on Odroid U3/XU3, one need to set > RSTN to zero, wait a while and the set it back to 1. > To achieve this with mmc-pwrseq-simple, I would need to modify the power_off > callback to toggle reset line to zero and back to one. This however might > not be desired to other sd/mmc cards used with mmc-pwrseq-simple. > > I can also provide separate mmc-pwrsrq-odroid driver, which will be very > similar to mmc-pwrseq-simple. Apart from the initial odd setup of the SoC pins this is the standard H/W reset operation specified by Jedec 4.4: * pull the reset line down for at least 1us * pull the line up again * Wait at least 200us before sending commands (sdhci_pci_int_hw_reset also implements this). I'm not sure what the determining factor is for a pwrseq driver vs. it being part of the mmc core would be. But if you do a pwrseq driver it shouldn't be board specific e.g. call it mmc-pwrseq-emmc4.4 instead of -odroid? -- Sjoerd Simons Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
On 30 January 2015 at 11:37, Marek Szyprowski wrote: > Hello, > > On 2015-01-29 11:56, Javier Martinez Canillas wrote: >> >> On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski >> wrote: Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? >>> >>> >>> I didn't consider mmc-pwrseq yet. For me it looked straightforward to >> >> I agree with Ulf that using mmc-pwrseq would be a good solution and in >> fact I think the pwrseq_simple [0] driver will fit your use case since >> it supports a reset GPIO pin which is what many WLAN chips attached to >> a SDIO interface use. > > > Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the > hardware and it mmc-pwrseq-simple cannot be used directly. > > Although the signal is called RSTN (on Odroid U3 schema), the eMMC card > gets resetted not on low line level, but during the rising edge. This RSTN > line is also pulled up by the external resistor. However, the strangest > thing is the fact that the default SoC configuration (which is applied > during hw reset) for this GPIO line is input, pulled-down. The SoC > internal pull-down is stronger than the external pull up, so in the end, > during the SoC reboot the RSTN signal is set to zero. Later bootloader > disables the internal pull-down. > > To sum up - to perform proper reboot on Odroid U3/XU3, one need to set > RSTN to zero, wait a while and the set it back to 1. > > To achieve this with mmc-pwrseq-simple, I would need to modify the power_off > callback to toggle reset line to zero and back to one. This however might > not be desired to other sd/mmc cards used with mmc-pwrseq-simple. > > I can also provide separate mmc-pwrsrq-odroid driver, which will be very > similar to mmc-pwrseq-simple. > > Ulf - which approach would you prefer? To me this seems like a quite generic eMMC hw-reset thing, thus we should maybe add a new pwrseq "driver" for it. In principle you need to toogle a GPIO in the ->pre_power_on() callback, right? And you are also proposing to register a restart handler from the ->alloc() callback!? I suppose this should work nicely. Kind regards Uffe > > >> >>> implement >>> it just like card detect or write-protection gpio pins. I already noticed >>> that >>> there is code for some mmc host driver, which perform mmc hardware reset. >>> If >>> you >>> think that extending pwrseq is the better approach, I will try to update >>> my >>> patches. This will add reboot handler to mmc-pwrseq then. The only >>> question >>> is >> >> I don't think that adding a reboot handler to mmc-pwrseq is needed. >> AFAICT the call chain is: >> >> sys_reboot() -> kernel_restart() -> device_shutdown() -> >> mmc_bus_shutdown() -> _mmc_suspend() -> mmc_power_off() -> >> mmc_pwrseq_power_off() -> struct mmc_pwrseq_ops .power_off >> >> So since the pwrseq_simple already asserts the reset GPIO in >> .power_off, it should be enough to ensure the eMMC will be reset to >> its default configuration for the iROM to work properly. >> >> It also asserts the GPIO pin in .pre_power_on and de-asserts in >> .post_power_on which should be needed as well for the other case you >> mentioned when a broken bootloader left the emmc card in some unknown >> state. > > > emergency_restart() doesn't call device_shutdown(), so I think it still > makes > sense to add real reset handler to mmc-pwrseq to ensure that power_off will > be called even during emergency_restart(). > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
Hello, On 2015-01-29 11:56, Javier Martinez Canillas wrote: On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski wrote: Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? I didn't consider mmc-pwrseq yet. For me it looked straightforward to I agree with Ulf that using mmc-pwrseq would be a good solution and in fact I think the pwrseq_simple [0] driver will fit your use case since it supports a reset GPIO pin which is what many WLAN chips attached to a SDIO interface use. Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the hardware and it mmc-pwrseq-simple cannot be used directly. Although the signal is called RSTN (on Odroid U3 schema), the eMMC card gets resetted not on low line level, but during the rising edge. This RSTN line is also pulled up by the external resistor. However, the strangest thing is the fact that the default SoC configuration (which is applied during hw reset) for this GPIO line is input, pulled-down. The SoC internal pull-down is stronger than the external pull up, so in the end, during the SoC reboot the RSTN signal is set to zero. Later bootloader disables the internal pull-down. To sum up - to perform proper reboot on Odroid U3/XU3, one need to set RSTN to zero, wait a while and the set it back to 1. To achieve this with mmc-pwrseq-simple, I would need to modify the power_off callback to toggle reset line to zero and back to one. This however might not be desired to other sd/mmc cards used with mmc-pwrseq-simple. I can also provide separate mmc-pwrsrq-odroid driver, which will be very similar to mmc-pwrseq-simple. Ulf - which approach would you prefer? implement it just like card detect or write-protection gpio pins. I already noticed that there is code for some mmc host driver, which perform mmc hardware reset. If you think that extending pwrseq is the better approach, I will try to update my patches. This will add reboot handler to mmc-pwrseq then. The only question is I don't think that adding a reboot handler to mmc-pwrseq is needed. AFAICT the call chain is: sys_reboot() -> kernel_restart() -> device_shutdown() -> mmc_bus_shutdown() -> _mmc_suspend() -> mmc_power_off() -> mmc_pwrseq_power_off() -> struct mmc_pwrseq_ops .power_off So since the pwrseq_simple already asserts the reset GPIO in .power_off, it should be enough to ensure the eMMC will be reset to its default configuration for the iROM to work properly. It also asserts the GPIO pin in .pre_power_on and de-asserts in .post_power_on which should be needed as well for the other case you mentioned when a broken bootloader left the emmc card in some unknown state. emergency_restart() doesn't call device_shutdown(), so I think it still makes sense to add real reset handler to mmc-pwrseq to ensure that power_off will be called even during emergency_restart(). Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
Hello, On 2015-01-29 11:56, Javier Martinez Canillas wrote: On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski wrote: Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? I didn't consider mmc-pwrseq yet. For me it looked straightforward to I agree with Ulf that using mmc-pwrseq would be a good solution and in fact I think the pwrseq_simple [0] driver will fit your use case since it supports a reset GPIO pin which is what many WLAN chips attached to a SDIO interface use. implement it just like card detect or write-protection gpio pins. I already noticed that there is code for some mmc host driver, which perform mmc hardware reset. If you think that extending pwrseq is the better approach, I will try to update my patches. This will add reboot handler to mmc-pwrseq then. The only question is I don't think that adding a reboot handler to mmc-pwrseq is needed. AFAICT the call chain is: sys_reboot() -> kernel_restart() -> device_shutdown() -> mmc_bus_shutdown() -> _mmc_suspend() -> mmc_power_off() -> mmc_pwrseq_power_off() -> struct mmc_pwrseq_ops .power_off So since the pwrseq_simple already asserts the reset GPIO in .power_off, it should be enough to ensure the eMMC will be reset to its default configuration for the iROM to work properly. I think that I had to add reset handler, because device_shutdown() was not called if reset was triggered from magic sysrq, but I will check it again. It also asserts the GPIO pin in .pre_power_on and de-asserts in .post_power_on which should be needed as well for the other case you mentioned when a broken bootloader left the emmc card in some unknown state. weather to use it always when mmc-pwrseq has been enabled or only if some additional property like 'reset-on-reboot' has been provided. Having a reset GPIO is optional AFAIK so I don't think there is a need for an additional "reset-on-reboot" propery. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland Best regards, Javier [0]: FYI, these are the relevant commits in linux-next: fe1922d5d4d0 mmc: pwrseq_simple: Add support for a reset GPIO pin ec2017f2491f mmc: pwrseq: Initial support for the simple MMC power sequence provider fe1686658f9c mmc: pwrseq: Document DT bindings for the simple MMC power sequence 1b745e8a4627 mmc: core: Initial support for MMC power sequences Ok, I will check it. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
Hello Marek, On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski wrote: >> Also, I wonder whether we could extend the mmc-pwrseq to cover your >> case? Did you consider that as an option? > > > I didn't consider mmc-pwrseq yet. For me it looked straightforward to I agree with Ulf that using mmc-pwrseq would be a good solution and in fact I think the pwrseq_simple [0] driver will fit your use case since it supports a reset GPIO pin which is what many WLAN chips attached to a SDIO interface use. > implement > it just like card detect or write-protection gpio pins. I already noticed > that > there is code for some mmc host driver, which perform mmc hardware reset. If > you > think that extending pwrseq is the better approach, I will try to update my > patches. This will add reboot handler to mmc-pwrseq then. The only question > is I don't think that adding a reboot handler to mmc-pwrseq is needed. AFAICT the call chain is: sys_reboot() -> kernel_restart() -> device_shutdown() -> mmc_bus_shutdown() -> _mmc_suspend() -> mmc_power_off() -> mmc_pwrseq_power_off() -> struct mmc_pwrseq_ops .power_off So since the pwrseq_simple already asserts the reset GPIO in .power_off, it should be enough to ensure the eMMC will be reset to its default configuration for the iROM to work properly. It also asserts the GPIO pin in .pre_power_on and de-asserts in .post_power_on which should be needed as well for the other case you mentioned when a broken bootloader left the emmc card in some unknown state. > weather to use it always when mmc-pwrseq has been enabled or only if some > additional property like 'reset-on-reboot' has been provided. > Having a reset GPIO is optional AFAIK so I don't think there is a need for an additional "reset-on-reboot" propery. > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > Best regards, Javier [0]: FYI, these are the relevant commits in linux-next: fe1922d5d4d0 mmc: pwrseq_simple: Add support for a reset GPIO pin ec2017f2491f mmc: pwrseq: Initial support for the simple MMC power sequence provider fe1686658f9c mmc: pwrseq: Document DT bindings for the simple MMC power sequence 1b745e8a4627 mmc: core: Initial support for MMC power sequences -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
Hello, On 2015-01-28 15:24, Ulf Hansson wrote: On 28 January 2015 at 14:59, Marek Szyprowski wrote: There are boards (like Hardkernel's Odroid boards) on which eMMC card's reset line is connected to GPIO line instead of the hardware reset logic. In case of such boards, if first stage of bootloader is loaded from such eMMC card, before performing system reboot, additional reset of eMMC card is required to properly boot the whole system again. This patch adds code for handling reset gpio lines defined in device tree. I don't follow the above sequence. Can you try to elaborate and describe for what exact scenario we require the hardware reset to be done? Odroid boards uses multi stage bootloaders. The very first stage is in SoC ROM. That code loads next stages (called bl1, bl2, tz) from either eMMC or SD card (depending on jumper configuration or some card detect pins). This ROM code is very simple and assumes that the mmc card has been reset to the default configuration. However, eMMC card is not being reset by the board 'reboot' logic. Instead the nreset line from emmc card is connected to gpio line of SoC. Thus to perform full system reboot procedure, before triggering reboot inside the SoC, one need to manually toggle nreset line of this emmc card to 'zero' for a while. Only then the card is put back to the default state, so ROM code is able to read bootloaders from it. My patch adds code for managing gpio line connected to nreset signal of emmc card. It registers reset handler, which is being triggered from Linux reboot code. This handler toggles such gpio line before the final reboot is triggered. My patch also provides a function for registering as a mmc host hw_reset callback, so it can be used to reset mmc card before initializing it with kernel driver (this is already implemented), which also might help to get it working if broken bootloader left the emmc card in some unknown/broken state (already observed such issue, but it has been fixed finally by patching bootloader). Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? I didn't consider mmc-pwrseq yet. For me it looked straightforward to implement it just like card detect or write-protection gpio pins. I already noticed that there is code for some mmc host driver, which perform mmc hardware reset. If you think that extending pwrseq is the better approach, I will try to update my patches. This will add reboot handler to mmc-pwrseq then. The only question is weather to use it always when mmc-pwrseq has been enabled or only if some additional property like 'reset-on-reboot' has been provided. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
Hello! Ulf Hansson wrote: > On 28 January 2015 at 14:59, Marek Szyprowski > wrote: >> There are boards (like Hardkernel's Odroid boards) on which eMMC card's >> reset line is connected to GPIO line instead of the hardware reset >> logic. In case of such boards, if first stage of bootloader is loaded >> from such eMMC card, before performing system reboot, additional reset >> of eMMC card is required to properly boot the whole system again. This >> patch adds code for handling reset gpio lines defined in device tree. > > > I don't follow the above sequence. Can you try to elaborate and > describe for what exact scenario we require the hardware reset to be > done? The Odroid board can either 'boot' from the eMMC or from a SD card. By 'boot', I mean that the iROM in the SoC either sources the bootloader data (BL1, BL2, trustzone, etc.) from eMMC or SD card. Let's take a board that is configured to boot from eMMC. If we reboot that board without doing a hw reset to the eMMC, then the iROM won't be able to read the bootloader when the board comes up again. Hence the need to do this reset during the kernel reboot procedure. Doing this during kernel initialization is already too late. With best wishes, Tobias > Also, I wonder whether we could extend the mmc-pwrseq to cover your > case? Did you consider that as an option? > > Kind regards > Uffe > >> Signed-off-by: Marek Szyprowski >> --- >> Documentation/devicetree/bindings/mmc/mmc.txt | 35 + >> drivers/mmc/core/core.c | 2 + >> drivers/mmc/core/host.c | 11 +++ >> drivers/mmc/core/slot-gpio.c | 101 >> +- >> include/linux/mmc/slot-gpio.h | 7 ++ >> 5 files changed, 139 insertions(+), 17 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt >> b/Documentation/devicetree/bindings/mmc/mmc.txt >> index 438899e8829b..c952cdea0201 100644 >> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >> @@ -21,6 +21,9 @@ Optional properties: >>below for the case, when a GPIO is used for the CD line >> - wp-inverted: when present, polarity on the WP line is inverted. See the >> note >>below for the case, when a GPIO is used for the WP line >> +- reset-gpios: Specify GPIO for hardware reset of a card, see gpio binding >> +- reset-inverted: when present, polarity on the reset line is inverted. See >> + the note below for the case, when a GPIO is used for the reset line >> - max-frequency: maximum operating clock frequency >> - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on >>this system, even if the controller claims it is. >> @@ -43,22 +46,24 @@ Optional properties: >> - dsr: Value the card's (optional) Driver Stage Register (DSR) should be >>programmed with. Valid range: [0 .. 0x]. >> >> -*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers >> line >> -polarity properties, we have to fix the meaning of the "normal" and >> "inverted" >> -line levels. We choose to follow the SDHCI standard, which specifies both >> those >> -lines as "active low." Therefore, using the "cd-inverted" property means, >> that >> -the CD line is active high, i.e. it is high, when a card is inserted. >> Similar >> -logic applies to the "wp-inverted" property. >> - >> -CD and WP lines can be implemented on the hardware in one of two ways: as >> GPIOs, >> -specified in cd-gpios and wp-gpios properties, or as dedicated pins. >> Polarity of >> -dedicated pins can be specified, using *-inverted properties. GPIO polarity >> can >> -also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an >> ambiguity >> -in the latter case. We choose to use the XOR logic for GPIO CD and WP lines. >> -This means, the two properties are "superimposed," for example leaving the >> +*NOTE* on CD, WP and RESET polarity. To use common for all SD/MMC host >> +controllers line polarity properties, we have to fix the meaning of the >> +"normal" and "inverted" line levels. We choose to follow the SDHCI >> +standard, which specifies both those lines as "active low." Therefore, >> +using the "cd-inverted" property means, that the CD line is active high, >> +i.e. it is high, when a card is inserted. Similar logic applies to the >> +"wp-inverted" and "reset-inverted" property. >> + >> +CD, WP and RESET lines can be implemented on the hardware in one of two >> +ways: as GPIOs, specified in cd-gpios and wp-gpios properties, or as >> +dedicated pins. Polarity of dedicated pins can be specified, using >> +*-inverted properties. GPIO polarity can also be specified using the >> +OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity in the latter case. >> +We choose to use the XOR logic for GPIO CD and WP lines. This means, the >> +two properties are "superimposed," for example leaving the >> OF_GPIO_ACTIVE_LOW flag clear and specifying the respec
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
On 28 January 2015 at 14:59, Marek Szyprowski wrote: > There are boards (like Hardkernel's Odroid boards) on which eMMC card's > reset line is connected to GPIO line instead of the hardware reset > logic. In case of such boards, if first stage of bootloader is loaded > from such eMMC card, before performing system reboot, additional reset > of eMMC card is required to properly boot the whole system again. This > patch adds code for handling reset gpio lines defined in device tree. I don't follow the above sequence. Can you try to elaborate and describe for what exact scenario we require the hardware reset to be done? Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? Kind regards Uffe > Signed-off-by: Marek Szyprowski > --- > Documentation/devicetree/bindings/mmc/mmc.txt | 35 + > drivers/mmc/core/core.c | 2 + > drivers/mmc/core/host.c | 11 +++ > drivers/mmc/core/slot-gpio.c | 101 > +- > include/linux/mmc/slot-gpio.h | 7 ++ > 5 files changed, 139 insertions(+), 17 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt > b/Documentation/devicetree/bindings/mmc/mmc.txt > index 438899e8829b..c952cdea0201 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc.txt > +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > @@ -21,6 +21,9 @@ Optional properties: >below for the case, when a GPIO is used for the CD line > - wp-inverted: when present, polarity on the WP line is inverted. See the > note >below for the case, when a GPIO is used for the WP line > +- reset-gpios: Specify GPIO for hardware reset of a card, see gpio binding > +- reset-inverted: when present, polarity on the reset line is inverted. See > + the note below for the case, when a GPIO is used for the reset line > - max-frequency: maximum operating clock frequency > - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on >this system, even if the controller claims it is. > @@ -43,22 +46,24 @@ Optional properties: > - dsr: Value the card's (optional) Driver Stage Register (DSR) should be >programmed with. Valid range: [0 .. 0x]. > > -*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers > line > -polarity properties, we have to fix the meaning of the "normal" and > "inverted" > -line levels. We choose to follow the SDHCI standard, which specifies both > those > -lines as "active low." Therefore, using the "cd-inverted" property means, > that > -the CD line is active high, i.e. it is high, when a card is inserted. Similar > -logic applies to the "wp-inverted" property. > - > -CD and WP lines can be implemented on the hardware in one of two ways: as > GPIOs, > -specified in cd-gpios and wp-gpios properties, or as dedicated pins. > Polarity of > -dedicated pins can be specified, using *-inverted properties. GPIO polarity > can > -also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an > ambiguity > -in the latter case. We choose to use the XOR logic for GPIO CD and WP lines. > -This means, the two properties are "superimposed," for example leaving the > +*NOTE* on CD, WP and RESET polarity. To use common for all SD/MMC host > +controllers line polarity properties, we have to fix the meaning of the > +"normal" and "inverted" line levels. We choose to follow the SDHCI > +standard, which specifies both those lines as "active low." Therefore, > +using the "cd-inverted" property means, that the CD line is active high, > +i.e. it is high, when a card is inserted. Similar logic applies to the > +"wp-inverted" and "reset-inverted" property. > + > +CD, WP and RESET lines can be implemented on the hardware in one of two > +ways: as GPIOs, specified in cd-gpios and wp-gpios properties, or as > +dedicated pins. Polarity of dedicated pins can be specified, using > +*-inverted properties. GPIO polarity can also be specified using the > +OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity in the latter case. > +We choose to use the XOR logic for GPIO CD and WP lines. This means, the > +two properties are "superimposed," for example leaving the > OF_GPIO_ACTIVE_LOW flag clear and specifying the respective *-inverted > -property results in a double-inversion and actually means the "normal" line > -polarity is in effect. > +property results in a double-inversion and actually means the "normal" > +line polarity is in effect. > > Optional SDIO properties: > - keep-power-in-suspend: Preserves card power during a suspend/resume cycle > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c > index 1be7055548cb..b556c3b5d83d 100644 > --- a/drivers/mmc/core/core.c > +++ b/drivers/mmc/core/core.c > @@ -2520,6 +2520,7 @@ void mmc_start_host(struct mmc_host *host) > mmc_power_off(host); > else > mmc_power_up(host, host->ocr_avail); >
