All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Hedde <damien.hedde@greensocs.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, berrange@redhat.com,
	ehabkost@redhat.com, alistair@alistair23.me,
	mark.burton@greensocs.com, marcandre.lureau@redhat.com,
	qemu-arm@nongnu.org, pbonzini@redhat.com,
	edgar.iglesias@gmail.com
Subject: Re: [PATCH v6 1/9] hw/core/clock: introduce clock objects
Date: Tue, 3 Dec 2019 16:14:58 +0100	[thread overview]
Message-ID: <9f79bf28-ad1a-4df1-76b4-8ecef780bb0f@greensocs.com> (raw)
In-Reply-To: <50c7d986-1630-e75c-acbd-24330e961dbb@redhat.com>



On 11/25/19 2:37 PM, Philippe Mathieu-Daudé wrote:
> On 9/4/19 2:55 PM, Damien Hedde wrote:
>> Introduce clock objects: ClockIn and ClockOut.
>>
>> These objects may be used to distribute clocks from an object to several
>> other objects. Each ClockIn object contains the current state of the
>> clock: the frequency; it allows an object to migrate its input clock
>> state
>> independently of other objects.
>>
>> A ClockIn may be connected to a ClockOut so that it receives update,
>> through a callback, whenever the Clockout is updated using the
>> ClockOut's set function.
>>
>> This is based on the original work of Frederic Konrad.
>>
>> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>   Makefile.objs         |   1 +
>>   hw/core/Makefile.objs |   1 +
>>   hw/core/clock.c       | 144 ++++++++++++++++++++++++++++++++++++++++++
>>   hw/core/trace-events  |   6 ++
>>   include/hw/clock.h    | 124 ++++++++++++++++++++++++++++++++++++
>>   5 files changed, 276 insertions(+)
>>   create mode 100644 hw/core/clock.c
>>   create mode 100644 include/hw/clock.h
>>
>> diff --git a/hw/core/trace-events b/hw/core/trace-events
>> index ecf966c314..aa940e268b 100644
>> --- a/hw/core/trace-events
>> +++ b/hw/core/trace-events
>> @@ -34,3 +34,9 @@ resettable_phase_hold_end(void *obj, int needed)
>> "obj=%p needed=%d"
>>   resettable_phase_exit(void *obj, const char *type) "obj=%p(%s)"
>>   resettable_phase_exit_end(void *obj, uint32_t count) "obj=%p
>> count=%" PRIu32
>>   resettable_count_underflow(void *obj) "obj=%p"
>> +
>> +# hw/core/clock-port.c
> 
> "# clock.c"
> 

Oups, I missed this one in the renaming.

>> +
>> +struct ClockIn {
>> +    /*< private >*/
>> +    Object parent_obj;
>> +    /*< private >*/
>> +    uint64_t frequency;
>> +    char *canonical_path; /* clock path cache */
>> +    ClockOut *driver; /* clock output controlling this clock */
>> +    ClockCallback *callback; /* local callback */
>> +    void *callback_opaque; /* opaque argument for the callback */
>> +    QLIST_ENTRY(ClockIn) sibling;  /* entry in a followers list */
>> +};
>> +
>> +struct ClockOut {
>> +    /*< private >*/
>> +    Object parent_obj;
>> +    /*< private >*/
>> +    char *canonical_path; /* clock path cache */
>> +    QLIST_HEAD(, ClockIn) followers; /* list of registered clocks */
>> +};
> 
> Can we keep the structure definitions opaque in hw/core/clock.c?
> If so, clock_get_frequency() can't be inlined anymore.
> 

I think so. Apart from the monitor command (and the inline), nothing
requires the structure fields. I suppose we can add a function to access
or print the fields to be used by the monitor.

I don't have a opinion on this.

Damien



  reply	other threads:[~2019-12-03 15:26 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-04 12:55 [Qemu-devel] [PATCH v6 0/9] Clock framework API Damien Hedde
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 1/9] hw/core/clock: introduce clock objects Damien Hedde
2019-11-25 13:07   ` Philippe Mathieu-Daudé
2019-11-25 13:37   ` Philippe Mathieu-Daudé
2019-12-03 15:14     ` Damien Hedde [this message]
2019-12-02 13:42   ` Peter Maydell
2019-12-03 15:28     ` Damien Hedde
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 2/9] hw/core/clock-vmstate: define a vmstate entry for clock state Damien Hedde
2019-11-25 13:05   ` Philippe Mathieu-Daudé
2019-12-02 13:44   ` Peter Maydell
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 3/9] qdev: add clock input&output support to devices Damien Hedde
2019-11-25 13:30   ` Philippe Mathieu-Daudé
2019-12-03 15:35     ` Damien Hedde
2019-12-02 14:34   ` Peter Maydell
2019-12-04  9:05     ` Damien Hedde
2019-12-04  9:53       ` Philippe Mathieu-Daudé
2019-12-04 11:58         ` Damien Hedde
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 4/9] qdev-monitor: print the device's clock with info qtree Damien Hedde
2019-12-02 14:35   ` Peter Maydell
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 5/9] qdev-clock: introduce an init array to ease the device construction Damien Hedde
2019-12-02 15:13   ` Peter Maydell
2019-12-04 11:04     ` Damien Hedde
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 6/9] docs/clocks: add device's clock documentation Damien Hedde
2019-12-02 15:17   ` Peter Maydell
2019-12-04 12:11     ` Damien Hedde
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 7/9] hw/misc/zynq_slcr: add clock generation for uarts Damien Hedde
2019-12-02 15:20   ` Peter Maydell
2019-12-04 12:51     ` Damien Hedde
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 8/9] hw/char/cadence_uart: add clock support Damien Hedde
2019-12-02 15:24   ` Peter Maydell
2019-12-04 13:35     ` Damien Hedde
2019-09-04 12:55 ` [Qemu-devel] [PATCH v6 9/9] hw/arm/xilinx_zynq: connect uart clocks to slcr Damien Hedde
2019-12-02 15:34   ` Peter Maydell
2019-12-03 14:59     ` Damien Hedde
2019-12-03 15:29       ` Philippe Mathieu-Daudé
2019-12-02 16:15 ` [PATCH v6 0/9] Clock framework API Peter Maydell
2019-12-04 16:40   ` Damien Hedde
2019-12-04 20:34     ` Philippe Mathieu-Daudé
2019-12-05  9:36       ` Damien Hedde
2019-12-05  9:59         ` Philippe Mathieu-Daudé
2019-12-05 10:21           ` Dr. David Alan Gilbert
2019-12-05 10:44             ` Philippe Mathieu-Daudé
2019-12-05 10:56               ` Dr. David Alan Gilbert
2019-12-05 11:01                 ` Philippe Mathieu-Daudé
2019-12-06 12:46                   ` Cleber Rosa
2019-12-06 13:48                     ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f79bf28-ad1a-4df1-76b4-8ecef780bb0f@greensocs.com \
    --to=damien.hedde@greensocs.com \
    --cc=alistair@alistair23.me \
    --cc=berrange@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mark.burton@greensocs.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.