Re: [PATCH 0/4] Check clock connection between STM32L4x5 RCC and peripherals

[Peter Maydell <peter.maydell@linaro.org>]

On Tue, 7 May 2024 at 19:59, Inès Varhol <ines.varhol@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-philmd@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