[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [RFC] A clock framework in QEMU.
Date: Thu, 2 Jun 2016 12:01:39 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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,

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]