On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
[...]
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.
That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.
I guess that is what Rob was objecting to!?
yeah, thats right.
So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.
What I am trying to propose here is,
Lets have power-sequence framework (similar to V1 of this series),
with,
pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
here is, all future code should be using this new
binding, so that we can deprecate the
drivers/mmc/core/pwrseq
pwrseq_arche: The usecase which I am dealing with today, which is more
complex in nature.
Then the respective drivers can add their drivers (if needed) based on
complexity.
comments ??
MMC Power Seq :
It is based on platform_device/platform_driver approach,
We recently converted MMC to this. It's has a clear benefit as you can
rely on the behaviour from the driver core and PM core. So, it simply
avoids duplication of code.
Agreed.
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.
As stated, using a platform device + driver would simplify this, as
you wouldn't need an API but only a driver. I guess.
Exactly.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
