From: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
To: Peter Chen <hzpeterchen@gmail.com>, robh+dt@kernel.org
Cc: Peter Chen <peter.chen@nxp.com>,
gregkh@linuxfoundation.org, stern@rowland.harvard.edu,
ulf.hansson@linaro.org, broonie@kernel.org, sre@kernel.org,
shawnguo@kernel.org, dbaryshkov@gmail.com, dwmw3@infradead.org,
mark.rutland@arm.com, devicetree@vger.kernel.org,
k.kozlowski@samsung.com, linux-usb@vger.kernel.org,
oscar@naiandei.net, pawel.moll@arm.com, arnd@arndb.de,
linux-pm@vger.kernel.org, festevam@gmail.com,
s.hauer@pengutronix.de, stephen.boyd@linaro.org,
linux-kernel@vger.kernel.org, troy.kisky@boundarydevices.com,
stillcompiling@gmail.com, p.zabel@pengutronix.de,
mail@maciej.szmigiero.name, mka@chromium.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 0/8] power: add power sequence library
Date: Wed, 31 Aug 2016 13:46:30 +0530 [thread overview]
Message-ID: <3a45793f-18d9-0688-d2ab-ef79432c473c@linaro.org> (raw)
In-Reply-To: <20160829111045.GB3736@b29397-desktop>
On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
>> On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
>>> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
>>>> Hi all,
>>>>
>>>> This is a follow-up for my last power sequence framework patch set [1].
>>>> According to Rob Herring and Ulf Hansson's comments[2], I use a generic
>>>> power sequence library for parsing the power sequence elements on DT,
>>>> and implement generic power sequence on library. The host driver
>>>> can allocate power sequence instance, and calls pwrseq APIs accordingly.
>>>>
>>>> In future, if there are special power sequence requirements, the special
>>>> power sequence library can be created.
>>>>
>>>> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
>>>> two hot-plug devices to simulate this use case, the related binding
>>>> change is updated at patch [1/6], The udoo board changes were tested
>>>> using my last power sequence patch set.[3]
>>>>
>>>> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
>>>> need to power on itself before it can be found by ULPI bus.
>>>>
>>>> [1]http://www.spinics.net/lists/linux-usb/msg142755.html
>>>> [2]http://www.spinics.net/lists/linux-usb/msg143106.html
>>>> [3]http://www.spinics.net/lists/linux-usb/msg142815.html
>>> (Please ignore my response on V2)
>>>
>>> Sorry being so late in the discussion...
>>>
>>> If I am not missing anything, then I am afraid to say that the
>>> generic library
>>> implementation in this patch series is not going to solve many of
>>> the custom
>>> requirement of power on, off, etc...
>>> I know you mentioned about adding another library when we come
>>> across such platforms, but should we not keep provision (or easy
>>> hooks/path)
>>> to enable that ?
>>>
>>> Let me bring in the use case I am dealing with,
>>>
>>>
>>> Host
>>> |
>>> V
>>> USB port
>>> ------------------------------------------------------------
>>> |
>>> V
>>> USB HUB device (May need custom on/off seq)
>>> |
>>> V
>>> =============================
>>> | |
>>> V V
>>> Device-1 Device-2
>>> (Needs special power (Needs special power
>>> on/off sequence. on/off sequence.
>>> Also may need custom Also, may need custom
>>> sequence for sequence for
>>> suspend/resume) suspend/resume)
>>>
>>>
>>> Note: Both Devices are connected to HUB via HSIC and may differ
>>> in terms of functionality, features they support.
>>>
>>> In the above case, both Device-1 and Device-2, need separate
>>> power on/off sequence. So generic library currently we have in this
>>> patch series is not going to satisfy the need here.
>>>
>>> I looked at all 6 revisions of this patch-series, went through the
>>> review comments, and looked at MMC power sequence code;
>>> what I can say here is, we need something similar to
>>> MMC power sequence here, where every device can have its own
>>> power sequence (if needed).
>>>
>>> I know Rob is not in favor of creating platform device for
>>> this, and I understand his comment.
>>> If not platform device, but atleast we need mechanism to
>>> connect each device back to its of_node and its respective
>>> driver/library fns. For example, the Devices may support different
>>> boot modes, and platform driver needs to make sure that
>>> the right sequence is followed for booting.
>>>
>>> Peter, My apologies for taking you back again on this series.
>>> I am OK, if you wish to address this in incremental addition,
>>> but my point is, we know that the current generic way is not
>>> enough for us, so I think we should try to fix it in initial phase only.
>>>
>> Rob, it seems generic power sequence can't cover all cases.
>> Without information from DT, we can't know which power sequence
>> for which device.
>>
> Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
> for each library, and choose pwrseq library according to compatible
> string first, if there is no compatible string for this library, just
> use generic pwrseq library.
>
Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??
With above approach, I kind of agree on it, but I have couple
of comments,
- How DTS looks like now ?? Can you put example here ?
- Should we merge MMC power sequence in next series ?
We also can take this as an incremental change, to avoid further
delay :)
- Lets also add suspend/resume callback to struct pwrseq
There are some comments I have on the patches,
I will respond directly on respective patches, it would be useful
for next series.
And Sorry for delayed response.
--
Thanks,
Vaibhav
next prev parent reply other threads:[~2016-08-31 8:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-15 9:13 [PATCH v6 0/8] power: add power sequence library Peter Chen
2016-08-15 9:13 ` [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic " Peter Chen
2016-09-01 8:03 ` Vaibhav Hiremath
2016-09-02 1:00 ` Peter Chen
2016-09-06 6:04 ` Vaibhav Hiremath
2016-08-15 9:13 ` [PATCH v6 2/8] power: add " Peter Chen
2016-08-22 6:51 ` Peter Chen
2016-08-22 10:23 ` Sebastian Reichel
2016-08-23 1:25 ` Peter Chen
2016-09-01 8:02 ` Vaibhav Hiremath
2016-09-02 1:29 ` Peter Chen
2016-08-15 9:13 ` [PATCH v6 3/8] binding-doc: usb: usb-device: add optional properties for power sequence Peter Chen
2016-08-15 9:13 ` [PATCH v6 4/8] usb: core: add power sequence handling for USB devices Peter Chen
2016-08-22 6:53 ` Peter Chen
2016-08-22 16:09 ` Alan Stern
2016-08-23 3:10 ` Peter Chen
2016-08-23 15:37 ` Alan Stern
2016-09-01 8:02 ` Vaibhav Hiremath
2016-09-02 1:30 ` Peter Chen
2016-08-15 9:13 ` [PATCH v6 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node Peter Chen
2016-08-15 9:13 ` [PATCH v6 6/8] ARM: dts: imx6qdl: Enable usb node children with <reg> Peter Chen
2016-08-15 9:13 ` [PATCH v6 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property Peter Chen
2016-08-15 9:13 ` [PATCH v6 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line Peter Chen
2016-08-23 10:32 ` [PATCH v6 0/8] power: add power sequence library Vaibhav Hiremath
2016-08-24 8:53 ` Peter Chen
2016-08-29 11:10 ` Peter Chen
2016-08-31 8:16 ` Vaibhav Hiremath [this message]
2016-08-31 9:52 ` Peter Chen
2016-08-31 16:58 ` Vaibhav Hiremath
2016-09-02 1:10 ` Peter Chen
2016-09-06 10:18 ` Vaibhav Hiremath
2016-09-09 8:47 ` Ulf Hansson
2016-09-19 7:39 ` Vaibhav Hiremath
2016-09-19 7:46 ` Peter Chen
2016-09-19 8:17 ` Vaibhav Hiremath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a45793f-18d9-0688-d2ab-ef79432c473c@linaro.org \
--to=vaibhav.hiremath@linaro.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=dbaryshkov@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw3@infradead.org \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hzpeterchen@gmail.com \
--cc=k.kozlowski@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=mark.rutland@arm.com \
--cc=mka@chromium.org \
--cc=oscar@naiandei.net \
--cc=p.zabel@pengutronix.de \
--cc=pawel.moll@arm.com \
--cc=peter.chen@nxp.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=sre@kernel.org \
--cc=stephen.boyd@linaro.org \
--cc=stern@rowland.harvard.edu \
--cc=stillcompiling@gmail.com \
--cc=troy.kisky@boundarydevices.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).