lkml.org 
[lkml]   [2012]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 1/3] Runtime Interpreted Power Sequences
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.
>
>



\
 
 \ /
  Last update: 2012-11-16 10:41    [W:0.051 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site