Info on LDM, domain system and SOCs
Hi all
I'm looking the Linux Driver Model (LDM) and the PM issues.
I see the LDM is only "bus-oriented".
Is there an "official" reason why it doesn't track clock and voltage?
In a SOCs usually there is more than one clock therefore it could be useful track not only the clock (as already done by the linux/clock.h) but also the relationship between clock-and-device.
For this reason I'm working on a generic framework domain (to track clocks and voltage with the same API) and the relationship between domains and devices.
The basic idea is something like:
struct device_driver {
...
domain_ret_t (*domain_notifier)(struct domain_event * event, struct
device* dev);
};
struct device {
...
struct dev_dmn_info clk;
struct dev_dmn_info vltg;
};
And in the future it tries to have a dynamic power management with all the info the system has on each device (bus_type, parent_device, clock_parent, voltage_parent).
Do you think is it a good idea? (if no why?)
Did somebody do something like that? (if no why?)
Ciao
Francesco
Quoted 5 lines · ext Francesco VIRLINZI
Hi all
I'm looking the Linux Driver Model (LDM) and the PM issues.I see the LDM is only "bus-oriented".
Is there an "official" reason why it doesn't track clock and voltage?
Check the clock framework used by OMAP and other SoCs
Signature · 4 lines
Cheers, Igor Igor Stoppa <[email protected]> (Nokia Multimedia - CP - OSSO / Helsinki, Finland)
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.
Igor Stoppa ha scritto:
Quoted 12 lines · ext Francesco VIRLINZI
Quoted 7 lines
Hi all
I'm looking the Linux Driver Model (LDM) and the PM issues.I see the LDM is only "bus-oriented".
Is there an "official" reason why it doesn't track clock and voltage?Check the clock framework used by OMAP and other SoCs
Quoted 4 lines · Francesco VIRLINZI
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.
/Amit
--
Amit Kucheria, Linux developer
Amit Kucheria ha scritto:
Quoted 8 lines · Francesco VIRLINZI
Quoted 6 lines
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.
Quoted 4 lines
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...
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.
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
And this information are available in user space (I think this information could help a power manager in user space)
Francesco
Quoted 4 lines
/Amit
--
Amit Kucheria, Linux developer
Hi,
Quoted 13 lines · ext Francesco VIRLINZI
Amit Kucheria ha scritto:
Quoted 8 lines · Francesco VIRLINZI
Quoted 6 lines
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.Quoted 4 lines
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.
Quoted 6 lines
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
Quoted 7 lines
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..
Quoted 8 lines
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.
Quoted 9 lines
For example in my platform I can do something like:
# ls /sys/domains/pll1_clk/comms_clk/devices/ # ssc-0 ssc-1 ssc-2This means in my platform there are
- a parent clockpll1_clk
- a child clockcomms_clk
- three devices (ssc-0 ssc-1 ssc-2) undercomms_clk
How is this different from the current cases?
Quoted 2 lines
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.
Signature · 4 lines
Cheers, Igor Igor Stoppa <[email protected]> (Nokia Multimedia - CP - OSSO / Helsinki, Finland)
Quoted 13 lines · Francesco VIRLINZI
Amit Kucheria ha scritto:
Quoted 8 lines · Francesco VIRLINZI
Quoted 6 lines
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.Quoted 4 lines
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.
Quoted 6 lines
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 struct is going to be platform/arch dependent. The access methods to the framework are independent though - clk_enable, _disable, _register, _unregister, etc.
Quoted 3 lines
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.
I agree. The main reason currently being that PC platforms don't care about it.
Quoted 11 lines
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.
As Igor pointed out in another reply, power domain and voltage domain information could be added to clock framework. For an example, see the voltage framework patches posted to linux-arm-kernel a few months ago. Those could be merged into the clock framework. You can also lookup PowerOP discussions on linux-pm for some background.
Quoted 9 lines
For example in my platform I can do something like:
# ls /sys/domains/pll1_clk/comms_clk/devices/ # ssc-0 ssc-1 ssc-2This means in my platform there are
- a parent clockpll1_clk
- a child clockcomms_clk
- three devices (ssc-0 ssc-1 ssc-2) undercomms_clk
The only thing new that I see here is that you export the clock tree to sysfs. That shouldn't be too hard to do with the existing framework.
Quoted 2 lines
And this information are available in user space (I think this information
could help a power manager in user space)
Why would you want that, except for debugging during development?
Regards,
Amit