aboutsummaryrefslogtreecommitdiff
path: root/hw/rtc/pl031.c
AgeCommit message (Collapse)AuthorFilesLines
2024-02-27pl031: Update last RTCLR value on write in case it's read backJessica Clarke1-0/+1
The PL031 allows you to read RTCLR, which is meant to give you the last value written. PL031State has an lr field which is used when reading from RTCLR, and is present in the VM migration state, but we never actually update it, so it always reads as its initial 0 value. Cc: qemu-stable@nongnu.org Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240222000341.1562443-1-jrtc27@jrtc27.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-12-30hw/rtc: Constify VMStateRichard Henderson1-3/+3
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231221031652.119827-50-richard.henderson@linaro.org>
2022-02-28rtc: Have event RTC_CHANGE identify the RTC by QOM pathMarkus Armbruster1-1/+2
Event RTC_CHANGE is "emitted when the guest changes the RTC time" (and the RTC supports the event). What if there's more than one RTC? Which one changed? New @qom-path identifies it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <87a6ejnm80.fsf@pond.sub.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-02-28qapi: Move RTC_CHANGE back out of target schemaPeter Maydell1-1/+1
This commit effectively reverts commit 183e4281a30962, which moved the RTC_CHANGE event to the target schema. That change was an attempt to make the event target-specific to improve introspection, but the event isn't really target-specific: it's machine or device specific. Putting RTC_CHANGE in the target schema with an ifdef list reduces maintainability (by adding an if: list with a long list of targets that needs to be manually updated as architectures are added or removed or as new devices gain the RTC_CHANGE functionality) and increases compile time (by preventing RTC devices which emit the event from being "compile once" rather than "compile once per target", because qapi-events-misc-target.h uses TARGET_* ifdefs, which are poisoned in "compile once" files.) Move RTC_CHANGE back to misc.json. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Greg Kurz <groug@kaod.org> Message-Id: <20220221192123.749970-2-peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2022-01-28rtc: Move RTC function prototypes to their own headerPeter Maydell1-1/+1
softmmu/rtc.c defines two public functions: qemu_get_timedate() and qemu_timedate_diff(). Currently we keep the prototypes for these in qemu-common.h, but most files don't need them. Move them to their own header, a new include/sysemu/rtc.h. Since the C files using these two functions did not need to include qemu-common.h for any other reason, we can remove those include lines when we add the include of the new rtc.h. The license for the .h file follows that of the softmmu/rtc.c where both the functions are defined. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-11-15hw/rtc/pl031: Send RTC_CHANGE QMP eventEric Auger1-1/+9
The PL031 currently is not able to report guest RTC change to the QMP monitor as opposed to mc146818 or spapr RTCs. This patch adds the call to qapi_event_send_rtc_change() when the Load Register is written. The value which is reported corresponds to the difference between the guest reference time and the reference time kept in softmmu/rtc.c. For instance adding 20s to the guest RTC value will report 20. Adding an extra 20s to the guest RTC value will report 20 + 20 = 40. The inclusion of qapi/qapi-types-misc-target.h in hw/rtl/pl031.c require to compile the PL031 with specific_ss.add() to avoid ./qapi/qapi-types-misc-target.h:18:13: error: attempt to use poisoned "TARGET_<ARCH>". Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20210920122535.269988-1-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-18pl031: Use timer_free() in the finalize function to avoid memleaksGan Qixin1-0/+8
When running device-introspect-test, a memory leak occurred in the pl031_init function, this patch use timer_free() in the finalize function to fix it. ASAN shows memory leak stack: Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf5621cfc in timer_new_full qemu/include/qemu/timer.h:523 #3 0xaaabf5621cfc in timer_new qemu/include/qemu/timer.h:544 #4 0xaaabf5621cfc in timer_new_ns qemu/include/qemu/timer.h:562 #5 0xaaabf5621cfc in pl031_init qemu/hw/rtc/pl031.c:194 #6 0xaaabf6339f6c in object_initialize_with_type qemu/qom/object.c:515 #7 0xaaabf633a1e0 in object_new_with_type qemu/qom/object.c:729 #8 0xaaabf6375e40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153 #9 0xaaabf5a95540 in qdev_device_help qemu/softmmu/qdev-monitor.c:283 #10 0xaaabf5a96940 in qmp_device_add qemu/softmmu/qdev-monitor.c:801 #11 0xaaabf5a96e70 in hmp_device_add qemu/softmmu/qdev-monitor.c:916 #12 0xaaabf5ac0a2c in handle_hmp_command qemu/monitor/hmp.c:1100 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210112112705.380534-2-ganqixin@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-24qdev: set properties with device_class_set_props()Marc-André Lureau1-1/+1
The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-19pl031: Expose RTCICR as proper WC registerAlexander Graf1-5/+1
The current PL031 RTCICR register implementation always clears the IRQ pending status on a register write, regardless of the value the guest writes. To justify that behavior, it references the ARM926EJ-S Development Chip Reference Manual (DDI0287B) and indicates that said document states that any write clears the internal IRQ state. It is indeed true that in section 11.1 this document says: "The interrupt is cleared by writing any data value to the interrupt clear register RTCICR". However, later in section 11.2.2 it contradicts itself by saying: "Writing 1 to bit 0 of RTCICR clears the RTCINTR flag." The latter statement matches the PL031 TRM (DDI0224C), which says: "Writing 1 to bit position 0 clears the corresponding interrupt. Writing 0 has no effect." Let's assume that the self-contradictory DDI0287B is in error, and follow the reference manual for the device itself, by making the register write-one-to-clear. Reported-by: Hendrik Borghorst <hborghor@amazon.de> Signed-off-by: Alexander Graf <graf@amazon.com> Message-id: 20191104115228.30745-1-graf@amazon.com [PMM: updated commit message to note that DDI0287B says two conflicting things] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-24hw: Move PL031 device from hw/timer/ to hw/rtc/ subdirectoryPhilippe Mathieu-Daudé1-0/+344
The PL031 is a Real Time Clock, not a timer. Move it under the hw/rtc/ subdirectory. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20191003230404.19384-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>