a
On Friday 02 September 2016 06:40 AM, Peter Chen wrote:
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:
veOn 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.
I think we should attempt to get both MMC and USB power seq
come on one agreement, so that it can be reused.
MMC Power Seq :
It is based on platform_device/platform_driver approach,
USB Power seq :
We are trying to propose library approach, with compatible string match.
We should try to have one approach.
- 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.
Yeup. Sure.
--
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
