qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 01/10] hw/core/clock-port: introduce clock po


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v4 01/10] hw/core/clock-port: introduce clock port objects
Date: Tue, 25 Sep 2018 15:00:53 +0100

On 25 September 2018 at 14:59, Damien Hedde <address@hidden> wrote:
>
>
> On 9/25/18 11:42 AM, Peter Maydell wrote:
>> Having a ClockPort which ClockIn and ClockOut are derived
>> from seems a bit heavyweight. When would you want to operate on
>> a generic ClockPort rather than either a ClockIn or ClockOut ?
>> Why would you want the name (canonical_path) to be different
>> at the input and output ends -- is it possible to simplify
>> to just having the output end keep the name string ?
>
> Here the canonical path is the full qom's canonical path. It is cached
> in the state to avoid recomputing it when needed. It is only used for
> log/trace purpose (without it, log is useless and calling
> object_get_canonical_path at every log seemed too costly to me).
> A connected ClockOut and ClockIn do not have the same (qom) parent,
> their canonical path is different.
> For example, in the zynq platform, there are 2 uarts, each one having a
>  "refclk" input. There is also a clock controller (slcr) having 2
> outputs "uart0_ref_clk" and "uart1_ref_clk". We end up with something
> like this concerning canonical path:
> + output "[...]/slcr/uart0_ref_clk" drives input "[...]/uart0/refclk"
> + output "[...]/slcr/uart1_ref_clk" drives input "[...]/uart1/refclk"
>
> Right now, I log a line for every end (output and input) when the clock
> frequency change, which lead to a kind-of-duplicate log line (names
> differ, but clock frequencies are obviously the same). I could only log
> at the output end and drop the canonical path for the input or pust the
> path in both objects.
>
> Anyway it is easily possible to drop the ClockPort common ancestor. A
> user never operates on it.

I think that would be preferable -- having the debug logging
drive the object hierarchy setup seems like the tail wagging
the dog to me.

thanks
-- PMM



reply via email to

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