aboutsummaryrefslogtreecommitdiff
path: root/hw/core/qdev-clock.c
AgeCommit message (Collapse)Author
2021-02-15clock: Add ClockEvent parameter to callbacksPeter Maydell
The Clock framework allows users to specify a callback which is called after the clock's period has been updated. Some users need to also have a callback which is called before the clock period is updated. As the first step in adding support for notifying Clock users on pre-update events, add an argument to the ClockCallback to specify what event is being notified, and add an argument to the various functions for registering a callback to specify which events are of interest to that callback. Note that the documentation update renders correct the previously incorrect claim in 'Adding a new clock' that callbacks "will be explained in a following section". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc@lmichel.fr> --- v2->v3: used 'unsigned int' instead of 'int' for parameters and struct fields containing an event mask, as suggested by Philippe; fixed events argument to qdev_init_clock_in() with NULL callback pointer in npcm7xx_adc.c (spotted by Hao)
2020-10-22hw/core/qdev-clock: add a reference on aliased clocksLuc Michel
When aliasing a clock with the qdev_alias_clock() function, a new link property is created on the device aliasing the clock. The link points to the aliased clock and use the OBJ_PROP_LINK_STRONG flag. This property is read only since it does not provide a check callback for modifications. The object_property_add_link() documentation stats that with OBJ_PROP_LINK_STRONG properties, the linked object reference count get decremented when the property is deleted. But it is _not_ incremented on creation (object_property_add_link() does not actually know the link). This commit increments the reference count on the aliased clock to ensure the aliased clock stays alive during the property lifetime, and to avoid a double-free memory error when the property gets deleted. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Luc Michel <luc@lmichel.fr> Message-Id: <20201020091024.320381-1-luc@lmichel.fr> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-10-16hw/qdev-clock: Display error hint when clock is missing from devicePhilippe Mathieu-Daudé
Instead of directly aborting, display a hint to help the developer figure out the problem (likely trying to connect a clock to a device pre-dating the Clock API, thus not expecting clocks). Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Message-Id: <20201012095804.3335117-4-f4bug@amsat.org>
2020-08-28hw/qdev-clock: Avoid calling qdev_connect_clock_in after DeviceRealizePhilippe Mathieu-Daudé
Clock canonical name is set in device_set_realized (see the block added to hw/core/qdev.c in commit 0e6934f264). If we connect a clock after the device is realized, this code is not executed. This is currently not a problem as this name is only used for trace events, however this disrupt tracing. Add a comment to document qdev_connect_clock_in() must be called before the device is realized, and assert this condition. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200803105647.22223-5-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-08-28hw/qdev-clock: Uninline qdev_connect_clock_in()Philippe Mathieu-Daudé
We want to assert the device is not realized. To avoid overloading this header including "hw/qdev-core.h", uninline the function first. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200803105647.22223-4-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-05-15qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-04-30qdev-clock: introduce an init array to ease the device constructionDamien Hedde
Introduce a function and macro helpers to setup several clocks in a device from a static array description. An element of the array describes the clock (name and direction) as well as the related callback and an optional offset to store the created object pointer in the device state structure. The array must be terminated by a special element QDEV_CLOCK_END. 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> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Message-id: 20200406135251.157596-5-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-30qdev: add clock input&output support to devices.Damien Hedde
Add functions to easily handle clocks with devices. Clock inputs and outputs should be used to handle clock propagation between devices. The API is very similar the GPIO API. This is based on the original work of Frederic Konrad. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200406135251.157596-4-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>