On Tue, Dec 13, 2016 at 12:01 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > On 9 December 2016 at 19:09, Rob Herring <robh@xxxxxxxxxx> wrote: >> On Fri, Dec 02, 2016 at 01:06:47AM -0800, Matt Ranostay wrote: >>> On Fri, Dec 2, 2016 at 12:28 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >>> > On 2 December 2016 at 08:22, Matt Ranostay <matt@ranostay.consulting> wrote: >>> >> >>> >> >>> >>> On Dec 1, 2016, at 23:13, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >>> >>> >>> >>>> On 2 December 2016 at 07:17, Matt Ranostay <matt@ranostay.consulting> wrote: >>> >>>> Add optional device-post-power-on parameters to disable post_power_on >>> >>>> function from being called since this breaks some device. >>> >>>> >>> >>>> Cc: Tony Lindgren <tony@xxxxxxxxxxx> >>> >>>> Cc: Ulf Hansson <ulf.hansson@xxxxxxxxxx> >>> >>>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting> >>> >>>> --- >>> >>>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++ >>> >>>> drivers/mmc/core/pwrseq_simple.c | 7 +++++++ >>> >>>> 2 files changed, 9 insertions(+) >>> >>>> >>> >>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt >>> >>>> index bea306d772d1..09fa153f743e 100644 >>> >>>> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt >>> >>>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt >>> >>>> @@ -24,6 +24,8 @@ Optional properties: >>> >>>> 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) >>> >>>> +- disable-post-power-on : Avoid post_power_on function from being called since >>> >>>> + this breaks some devices >>> >>> >>> >>> This is a bit weird. I would like to avoid this, if possible. >>> >>> >>> >>> Perhaps if you simply describe the sequence in detail for your device >>> >>> we can figure out the best option together. >>> >> >>> >> Yeah I know it is a bit weird but we need to keep that reset pin high for at least some time after pre power on. So any case it would be another property >>> > >>> > This went offlist, please resend. >>> > >>> > Moreover, please try to describe the sequence you need in detail >>> > according to your HW spec. >>> > >>> >>> Yeah oops.... >>> >>> So basically we need to drive the reset and powerdown lines high with >>> a 300 milliseconds delay between both... >>> can't have the reset line low with post power on (pretty sure but >>> would need a delay anyway), and we need both reset + powerdown line >>> set low on powerdown. >>> >>> So the power down sequence would need to be reversed for this >>> application in pwrseq-simple. >> >> This sounds like you need a device specific sequence to me. Otherwise, >> write a language to describe any power control waveforms rather than >> trying to bolt on more and more properties. (Don't really go write a >> language.) > > Actually this isn't so device specific. The cw1200 wifi chip which is > being used with ux500 SoCs has a very similar sequence. Allow me to > check the details and get back. Ok. It would be good to have something common than a bunch of one-off solutions for sure. > > Anyway, my point is that I think we can figure out a common sequence > to support these kind required sequences. That is to me preferred over > adding a new (two to support cw1200) device specific pwrseq driver. > > 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
