[Qemu-devel] [RFC] A clock framework in QEMU.

[Qemu-devel] [RFC] A clock framework in QEMU.

[KONRAD Frederic]

Hi,

We would like to have a way to have a clock tree inside QEMU:
   * models can have clock outputs and/or clock inputs.
   * changing the clock rate of propagates in the clock tree through
     callbacks which will be implemented in the model (eg: like qemu_irq)
   * would be nice to be able to visualize the rate of a clock in the
     monitor.

There is already an implementation in QEMU (in omap*) but:
   * it's not generic/usable in the whole QEMU tree.
   * it's not using QOM.

So the proposition are either to construct one new framework or to 
extract and reuse the old one:
   * new types must be created eg: qemu_clk_in, qemu_clk_out.
   * I think it shouldn't use qemu_irq (because this is confusing) but
     maybe use a simple qom link to bound them.
   * The model which have the clock input will need to implement the
     clock update/enable/disable callback.

So for example PLL or some clock gate units will just have one input and 
some outputs.
Then the outputs can be controlled by the output callbacks (for example
the input rate change or the clock is gated).

Does that makes sense?
Do you have any opinion about that?

Thanks,
Fred

Re: [Qemu-devel] [RFC] A clock framework in QEMU.

[KONRAD Frederic]

Hi Peter,

Do you agree with this? I think you are the hw/*/omap* maintainer?

Thanks,
Fred

Le 31/05/2016 à 21:08, KONRAD Frederic a écrit :
> Hi,
>
> We would like to have a way to have a clock tree inside QEMU:
>   * models can have clock outputs and/or clock inputs.
>   * changing the clock rate of propagates in the clock tree through
>     callbacks which will be implemented in the model (eg: like qemu_irq)
>   * would be nice to be able to visualize the rate of a clock in the
>     monitor.
>
> There is already an implementation in QEMU (in omap*) but:
>   * it's not generic/usable in the whole QEMU tree.
>   * it's not using QOM.
>
> So the proposition are either to construct one new framework or to
> extract and reuse the old one:
>   * new types must be created eg: qemu_clk_in, qemu_clk_out.
>   * I think it shouldn't use qemu_irq (because this is confusing) but
>     maybe use a simple qom link to bound them.
>   * The model which have the clock input will need to implement the
>     clock update/enable/disable callback.
>
> So for example PLL or some clock gate units will just have one input and
> some outputs.
> Then the outputs can be controlled by the output callbacks (for example
> the input rate change or the clock is gated).
>
> Does that makes sense?
> Do you have any opinion about that?
>
> Thanks,
> Fred
>

Re: [Qemu-devel] [RFC] A clock framework in QEMU.

[Peter Maydell]

On 2 June 2016 at 10:18, KONRAD Frederic <fred.konrad@greensocs.com> wrote:
> Hi Peter,
>
> Do you agree with this? I think you are the hw/*/omap* maintainer?

The in-master OMAP stuff is pretty ancient and not a good
pattern for anything. You could have a look at the omap3
clocktree stuff that's in the qemu-linaro tree; that is
also now quite old but it is a bit more featured. (It
probably isn't actually something worth copying as such
but it might suggest required features.) I agree that
clock tree modelling ought to be more generic than what
we have today.

thanks
-- PMM

Re: [Qemu-devel] [RFC] A clock framework in QEMU.

[Edgar E. Iglesias]

On Tue, May 31, 2016 at 09:08:14PM +0200, KONRAD Frederic wrote:
> Hi,

Hi Fred,


> We would like to have a way to have a clock tree inside QEMU:
>   * models can have clock outputs and/or clock inputs.
>   * changing the clock rate of propagates in the clock tree through
>     callbacks which will be implemented in the model (eg: like qemu_irq)
>   * would be nice to be able to visualize the rate of a clock in the
>     monitor.

This sounds good to me. Allthough it may be obvious, you may want
to be explicit (in future docs) in that clock pin toggles are not
going to be modelled. Only meta-information about frequencies.


> There is already an implementation in QEMU (in omap*) but:
>   * it's not generic/usable in the whole QEMU tree.
>   * it's not using QOM.
> 
> So the proposition are either to construct one new framework or to extract
> and reuse the old one:
>   * new types must be created eg: qemu_clk_in, qemu_clk_out.
>   * I think it shouldn't use qemu_irq (because this is confusing) but
>     maybe use a simple qom link to bound them.
>   * The model which have the clock input will need to implement the
>     clock update/enable/disable callback.

It'll be easier to comment on this when you have some RFC code but it may
be enough with a clk_update callback. A freq of 0 is a disabled clock.
I may be stating the obvious again but note that devices may have
multiple clk inputs and multiple clock outputs. It would be nice if
these are named aswell (and not just indexed).

Thanks and best regards,
Edgar


> So for example PLL or some clock gate units will just have one input and
> some outputs.
> Then the outputs can be controlled by the output callbacks (for example
> the input rate change or the clock is gated).
> 
> Does that makes sense?
> Do you have any opinion about that?

Re: [Qemu-devel] [RFC] A clock framework in QEMU.

[KONRAD Frederic]

Le 02/06/2016 à 12:01, Edgar E. Iglesias a écrit :
> On Tue, May 31, 2016 at 09:08:14PM +0200, KONRAD Frederic wrote:
>> Hi,
>
> Hi Fred,
>
>
>> We would like to have a way to have a clock tree inside QEMU:
>>   * models can have clock outputs and/or clock inputs.
>>   * changing the clock rate of propagates in the clock tree through
>>     callbacks which will be implemented in the model (eg: like qemu_irq)
>>   * would be nice to be able to visualize the rate of a clock in the
>>     monitor.
>
> This sounds good to me. Allthough it may be obvious, you may want
> to be explicit (in future docs) in that clock pin toggles are not
> going to be modelled. Only meta-information about frequencies.

Yes I'll explicit that.

>
>
>> There is already an implementation in QEMU (in omap*) but:
>>   * it's not generic/usable in the whole QEMU tree.
>>   * it's not using QOM.
>>
>> So the proposition are either to construct one new framework or to extract
>> and reuse the old one:
>>   * new types must be created eg: qemu_clk_in, qemu_clk_out.
>>   * I think it shouldn't use qemu_irq (because this is confusing) but
>>     maybe use a simple qom link to bound them.
>>   * The model which have the clock input will need to implement the
>>     clock update/enable/disable callback.
>
> It'll be easier to comment on this when you have some RFC code but it may
> be enough with a clk_update callback. A freq of 0 is a disabled clock.
> I may be stating the obvious again but note that devices may have
> multiple clk inputs and multiple clock outputs. It would be nice if
> these are named aswell (and not just indexed).

The omap clock structure have some kind of disabled member. But I agree 
it makes sense to say that a zero frequence is a disabled clock.

Thanks,
Fred

>
> Thanks and best regards,
> Edgar
>
>
>> So for example PLL or some clock gate units will just have one input and
>> some outputs.
>> Then the outputs can be controlled by the output callbacks (for example
>> the input rate change or the clock is gated).
>>
>> Does that makes sense?
>> Do you have any opinion about that?
>