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. > > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
