Re: [PATCH v8 1/3] Runtime Interpreted Power Sequences

[Srinivas KANDAGATLA <srinivas.kandagatla@st.com>]

On 16/11/12 08:31, Alex Courbot wrote:
> 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.
Ok I agree. I was thinking more of to fit few things specific to our
chip via power-seqs.
>
> 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.
Yes, There is a level of abstraction (aka sysconf) in our case.. again
it is not mainlined yet.
>
> 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.
yep.

thanks,
srini
>
> Alex.
>
>