On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
The key point here is DT maintainer (Rob) doesn't agree with adding new node
On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
[...]yeah, thats right.
That would be nice. Although, to do that you would have to allow someI think we should attempt to get both MMC and USB power seqHow the new kernel compatibles old dts? If we do not need toWe had an agreement that keep mmc's pwrseq framework unchanging.Why 2 separate approach for same problem ?
Unless Ulf and rob both agree to change.
And I see this as possible duplication of code/functionality :)
consider this problem, the mmc can try to use power sequence library
too in future.
come on one agreement, so that it can be reused.
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!?
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 ??
for power sequence at dts.