Re: [PATCH v6 0/8] power: add power sequence library

[Peter Chen]

On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
> >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.
> 
> How would consumer driver get the power sequence ?
> You must point to right power sequence driver.
> For example, in the above example, Device-1, should
> get handle to pwrseq-1, and Device-2 to pwrseq-2.

According to compatible string at device's of_node, we will have a list
for power sequence libraries which has index (or name), and matches
compatible string.

> 
> >>  - 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.
> 
> Why 2 separate approach for same problem ?
> And I see this as possible duplication of code/functionality :)

How the new kernel compatibles old dts? If we do not need to
consider this problem, the mmc can try to use power sequence library
too in future.

> 
> >>  - Lets also add suspend/resume callback to struct pwrseq
> >>
> >Why suspend/resume can't do at related driver's suspend/resume API?
> 
> Nope...
> The pwrseq library would have taken ownership of resources, so
> related driver cannot suspend the device. Again it is architecture
> specific, but we should have provision to handle this.
> 
> The system I am dealing with today, does need suspend/resume
> callback. To be precise, suspend is close to off state for some devices or
> they could enter standby or different low power state, but to do that,
> we need same resource as used for ON/OFF functionality.
> 

Ok, I will have API for suspend/resume. You can implement it at your own
library or generic one.

-- 

Best Regards,
Peter Chen