Info on LDM, domain system and SOCs

Info on LDM, domain system and SOCs

[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?

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

Re: Info on LDM, domain system and SOCs

[Igor Stoppa]

On Wed, 2007-09-05 at 13:54 +0000, ext Francesco VIRLINZI wrote:
> 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

-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)

Re: Info on LDM, domain system and SOCs

[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.


Igor Stoppa ha scritto:
> On Wed, 2007-09-05 at 13:54 +0000, ext Francesco VIRLINZI wrote:
>   
>> 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
>
>   

Re: Info on LDM, domain system and SOCs

[Amit Kucheria]

On 9/10/07, Francesco VIRLINZI <francesco.virlinzi@st.com> 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.

/Amit
--
Amit Kucheria, Linux developer

Re: Info on LDM, domain system and SOCs

[Francesco VIRLINZI]

Amit Kucheria ha scritto:
> On 9/10/07, Francesco VIRLINZI <francesco.virlinzi@st.com> 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...

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
> /Amit
> --
> Amit Kucheria, Linux developer
>   

Re: Info on LDM, domain system and SOCs

[Igor Stoppa]

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@st.com> 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@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)

Re: Info on LDM, domain system and SOCs

[Amit Kucheria]

On 9/24/07, Francesco VIRLINZI <francesco.virlinzi@st.com> wrote:
> Amit Kucheria ha scritto:
> > On 9/10/07, Francesco VIRLINZI <francesco.virlinzi@st.com> 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 struct is going to be platform/arch dependent. The access
methods to the framework  are independent though -  clk_enable,
_disable, _register, _unregister, etc.

> 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.

> 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.

> 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

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.

> 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