qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API.


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API.
Date: Fri, 23 Jun 2017 13:47:26 +0100

On 23 June 2017 at 13:38, KONRAD Frederic <address@hidden> wrote:
> Le 06/23/2017 à 11:51 AM, Peter Maydell a écrit :
>> As an aside, I still find it very odd that you get a clock
>> object for both an input clock and an output clock. I feel
>> like we should have one end owns the clock object and the
>> other just has a reference to it of some kind.
>
>
> The point is beeing able to bind/unbind clocks inside the device
> to model a clock selector for example. So you just bind/unbind
> the input and output clocks.

I don't see why this needs both 'input clock' and 'output
clock' to be separate objects. What I have in mind is:

Device A:
  has-a clock C1

Device B:
  has-a clock C2

Device C: (a clock selector)
  clock inputs CI1, CI2
  has-a clock C3

Each device "owns" its output clock objects, but input
clocks are just pointers to the clock object owned by the
device at the other end. In the board you wire up CI1 to C1,
and CI2 to C2 (using link properties I guess).
Then in device C you can implement the clock switching by
some kind of bind(s->CI1, &s->C3) call because you have
pointers to all the relevant clock objects.

As I understand it your current implementation makes not
just the output clocks C1 C2 C2 be clock objects, but also
the inputs CI1 CI2, so effectively each link from a clock
source to a clock sink has two objects involved.

thanks
-- PMM



reply via email to

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