[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
- Re: [Qemu-devel] [PATCH v4 05/10] docs/clocks: add device's clock documentation, (continued)
- [Qemu-devel] [PATCH v4 03/10] qdev-monitor: print the device's clock with info qtree, damien . hedde, 2018/09/17
- [Qemu-devel] [PATCH v4 08/10] hw/misc/zynq_slcr: add clock generation for uarts, damien . hedde, 2018/09/17
- [Qemu-devel] [PATCH v4 06/10] sysbus: add bus_interface_clock feature to sysbus devices, damien . hedde, 2018/09/17
- [Qemu-devel] [PATCH v4 09/10] hw/char/cadence_uart: add clock support, damien . hedde, 2018/09/17
- [Qemu-devel] [PATCH v4 07/10] hw/misc/zynq_slcr: use standard register definition, damien . hedde, 2018/09/17
- [Qemu-devel] [PATCH v4 01/10] hw/core/clock-port: introduce clock port objects, damien . hedde, 2018/09/17
- [Qemu-devel] [PATCH v4 02/10] qdev: add clock input&output support to devices., damien . hedde, 2018/09/17
- Re: [Qemu-devel] [PATCH v4 00/10] Clock framework API., Peter Maydell, 2018/09/19
- Re: [Qemu-devel] [PATCH v4 00/10] Clock framework API., Damien Hedde, 2018/09/21