Message-ID: <20160831095220.GA11938@b29397-desktop>
Date:   Wed, 31 Aug 2016 17:52:20 +0800
From:   Peter Chen <hzpeterchen@...il.com>
To:     Vaibhav Hiremath <vaibhav.hiremath@...aro.org>
Cc:     robh+dt@...nel.org, Peter Chen <peter.chen@....com>,
        gregkh@...uxfoundation.org, stern@...land.harvard.edu,
        ulf.hansson@...aro.org, broonie@...nel.org, sre@...nel.org,
        shawnguo@...nel.org, dbaryshkov@...il.com, dwmw3@...radead.org,
        mark.rutland@....com, devicetree@...r.kernel.org,
        k.kozlowski@...sung.com, linux-usb@...r.kernel.org,
        oscar@...andei.net, pawel.moll@....com, arnd@...db.de,
        linux-pm@...r.kernel.org, festevam@...il.com,
        s.hauer@...gutronix.de, stephen.boyd@...aro.org,
        linux-kernel@...r.kernel.org, troy.kisky@...ndarydevices.com,
        stillcompiling@...il.com, p.zabel@...gutronix.de,
        mail@...iej.szmigiero.name, mka@...omium.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v6 0/8] power: add power sequence library

On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
> 
> 
> 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 ?

The dts is the same with current version.

>  - Should we merge MMC power sequence in next series ?
>    We also can take this as an incremental change, to avoid further
>    delay :)

We had an agreement that keep mmc's pwrseq framework unchanging.
Unless Ulf and rob both agree to change.

>  - Lets also add suspend/resume callback to struct pwrseq
> 

Why suspend/resume can't do at related driver's suspend/resume API? 

> 
> There are some comments I have on the patches,
> I will respond directly on respective patches, it would be useful
> for next series.
> 

Thanks.

-- 

Best Regards,
Peter Chen

Powered by blists - more mailing lists