Hi, On Mon, 2007-09-24 at 11:14 +0000, ext Francesco VIRLINZI wrote: > Amit Kucheria ha scritto: > > On 9/10/07, Francesco VIRLINZI <francesco.virlinzi@xxxxxx> wrote: > > > >> If you mean the <include/linux/clk.h>, I already saw it. > >> I think it's good but it isn't enough. > >> I want track also the devices on a clock to be able to notify (for each > >> device) if a clock changes. > >> > > > > You should propose these changes to the clock framework. Designing a > > new framework is unlikely to be accepted in the kernel easily since a > > lot of platforms are using the clock framework already. > > > Hi > I'm sorry but this is really what I don't want to do. > I think the problem is really this. > > In the kernel there are a several clock struct... one for each > architecture... The clk fw interface is common; implementation is of course platform/architecture specific > A lot of them have no relation with the linux driver model... and they > aren't showed under /sys/... > This means there is a physical clock network not aware by the kernel. > > For this reason I don't want "write-a-new" or "extend-an-existent" clock > framework.. > > I'm working on a domain framework arch independent (a kind of ancestor > of all the clock framework) > able to track the domain relationship and also the device-on-domain > relationship. > This framework should go under <root>/drivers/base/... > The basic idea is to create a base code for all the architectures to > simplify (I hope) > the clocks managements in the SOCs. Integration of power domains in the LDM could be easily obtained by modelling a buf for each power domain. > For example in my platform I can do something like: > > # ls /sys/domains/pll1_clk/comms_clk/devices/ > # ssc-0 ssc-1 ssc-2 > > This means in my platform there are > - a parent clock pll1_clk > - a child clock comms_clk > - three devices (ssc-0 ssc-1 ssc-2) under comms_clk How is this different from the current cases? > And this information are available in user space (I think this information > could help a power manager in user space) I can hardly see a userspace power manager be able to handle low latencies involved in clock gating. Unless you are referring to unlocking vs. enabling bypass mode for PLLs when their usecount reaches 0. -- Cheers, Igor Igor Stoppa <igor.stoppa@xxxxxxxxx> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm