[PATCH v8 1/3] Runtime Interpreted Power Sequences
Alex Courbot
acourbot at nvidia.com
Fri Nov 16 19:31:04 EST 2012
Hi Srinivas,
On Friday 16 November 2012 15:58:29 Srinivas KANDAGATLA wrote:
> Hi Alex,
> I am looking forward for this feature to be mainlined,
*cough* Ack *cough* :)
> but I have
> comment on the way the types are tied up to power seq infrastructure.
> I know your use case are limited to using type "delay", "pwm" and "gpio"
> and "regulator", However there are instances where the devices can be
> powered up or reset by writing to special registers or sysconfs or
> something else.
> So My suggestion would be to make these type register them selfs
> dynamically with the power_seq infrastructure so that in future this can
> be extended to other types as-well.
> This trivial change can make a lot of difference for the future chips
> which do thing bit differently.
> ST Microelectronics chips fit it in these category and I guess other
> Vendors have this similar chips.
The current implementation is (purposedly) minimal and will certainly be
extended. There are other aspects of regulators for instance that should also
be controllable (voltage comes to mind). And I am totally open to supporting
new kinds of resources as usage broadens. For this first version I just wanted
to introduce the feature and minimize the impact should anything (DT
bindings?) need to change.
I am a little bit skeptical about the purpose of directly accessing registers
(or any part of the address space) from power sequences. It should at least be
possible to involve some kind of abstraction. Not necessarily one of the
currently supported types - but at least something.
The reason is that I'd like to try and avoid direct references to resources
within sequences as much as possible to make them reusable. If your system has
two identical devices, you should not need to duplicate their sequences just
to change a register range from the few steps that make use of it. If you can
do the same job with, say, a regulator, you can just give it a name, get it at
runtime using regulator_get() and define it outside of the sequence, in our
device node.
Of course there might be scenarios where you really need to access a register
and there is no way to do otherwise, in this case I am open to discussion. But
before resorting to this I'd like to make that the existing abstraction cannot
cover the case already.
Alex.
More information about the devicetree-discuss
mailing list