On Tue, 7 May 2024 at 19:59, Inès Varhol <ines.var...@telecom-paris.fr> wrote: > > Among implemented STM32L4x5 devices, USART, GPIO and SYSCFG > have a clock source, but none has a corresponding test in QEMU. > > This patch makes sure that all 3 devices create a clock, > have a QOM property to access the clock frequency, > and adds QTests checking that clock enable in RCC has the > expected results. > > Philippe Mathieu-Daudé suggested the following : > ".. We could add the clock properties > directly in qdev_init_clock_in(). Seems useful for the QTest > framework." > > However Peter Maydell pointed out the following : > "...Mostly "frequency" properties on devices are for the case > where they *don't* have a Clock input and instead have > ad-hoc legacy handling where the board/SoC that creates the > device sets an integer property to define the input frequency > because it doesn't model the clock tree with Clock objects." > > You both agree on the fact that replicating the code in the > different devices is a bad idea, what should be the > alternative?
I think we should use the approach discussed in the review comments on Philippe's patch https://patchew.org/QEMU/20240508141333.44610-1-phi...@linaro.org/ where if we're running a qtest then the core clock code creates a QOM property which is the clock period; the test code can then use that. thanks -- PMM
