[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPDyKFpVNeSrsAjabSOgr6p0dWPiQr4C=jUhO26dcyYOXdXFyw@mail.gmail.com>
Date: Wed, 30 Nov 2016 15:39:43 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Javier Martinez Canillas <javier@...hile0.org>,
Matt Ranostay <matt@...ostay.consulting>
Cc: "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
Tony Lindgren <tony@...mide.com>,
Mark Rutland <mark.rutland@....com>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Subject: Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
On 30 November 2016 at 14:11, Javier Martinez Canillas
<javier@...hile0.org> wrote:
> Hello Matt,
>
> On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay
> <matt@...ostay.consulting> wrote:
>> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
>
> [snip]
>
>>
>>
>>>> +- pwndn-gpio: contains a power down GPIO specifier.
>>>> +- reset-gpio: contains a reset GPIO specifier.
>>>> +
>>>
>>> I wonder if we really need a custom power sequence provider for just
>>> this SDIO WiFI chip though. AFAICT the only missing piece in
>>> mmc-pwrseq-simple is the power down GPIO property, so maybe
>>> mmc-pwrseq-simple could be extended instead to have an optional
>>> powerdown-gpios property and instead in the Marvell SD8787 DT binding
>>> can be mentioned which mmc-pwrseq-simple properties are required for
>>> the device.
>>>
>>
>> The reason we didn't do that is we need delay between the two
>> assertions/desertions of GPIOs. It wouldn't seems good practice to
>> hack the pwrseq-simple for this...
>>
>
> Yes, I noticed that. I wouldn't say that it would be a hack for the
> pwrseq-simple since it already has a "post-power-on-delay-ms" DT
> property, so AFAICT it would just be adding a "pre-power-on-delay-ms"
> property for your use case.
>
> It would also be more consistent since it would support a delay for
> pre and post power callbacks. It would also make you avoid hardcoding
> the 300 msec wait, in case other device has a similar need but with a
> different wait time.
>
> In summary, I think that devices having a power (or power down) and
> enable GPIO, and needing to wait between the GPIO toggling are common.
> So I would prefer to make pwrseq-simple usable for these instead of
> adding device specific power sequence providers. But it's just my
> opinion and not my call :-)
This is a good idea. Please try out this approach.
[...]
Kind regards
Uffe
Powered by blists - more mailing lists