On Thu, Dec 1, 2016 at 11:28 PM, Matt Ranostay <matt@ranostay.consulting> wrote: > > > >>> On Dec 1, 2016, at 22:57, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> >>> On 2 December 2016 at 07:17, Matt Ranostay <matt@ranostay.consulting> wrote: >>> Some devices need a logic level low instead of high to be in the >>> off state. >>> >>> Cc: Tony Lindgren <tony@xxxxxxxxxxx> >>> Cc: Ulf Hansson <ulf.hansson@xxxxxxxxxx> >>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting> >>> --- >>> .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++ >>> drivers/mmc/core/pwrseq_simple.c | 15 +++++++++++---- >>> 2 files changed, 13 insertions(+), 4 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt >>> index 703a714201d8..bea306d772d1 100644 >>> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt >>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt >>> @@ -22,6 +22,8 @@ Optional properties: >>> the reset-gpios (if any) are asserted >>> - post-power-on-delay-ms : Delay in ms after powering the card and >>> de-asserting the reset-gpios (if any) >>> +- invert-off-state: Invert the power down state for the reset-gpios (if any) >>> + and pwrdn-gpios (if any) >> >> We already have DT bindings to describe GPIO pins as active high or >> low. I think we should be able to use that instead, don't you think? > > Ah issue is we are using inverse logic in the power down from anything else. But I guess we could read the gpios active high and low stats from device tree and deduce it from that > BTW this quirkiness is which why me and Lindgren went the route of an another pwrseq driver versus hacking the pwrseq-simple initially... In any case we can change the active high or low in the gpio descriptors but doesn't change the timing we need or the inverse state for power down. Thanks, Matt > >> >> [...] >> >> 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
