qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 0/8] Add device STM32L4x5 RCC


From: Peter Maydell
Subject: Re: [PATCH v5 0/8] Add device STM32L4x5 RCC
Date: Fri, 23 Feb 2024 15:07:40 +0000

On Mon, 19 Feb 2024 at 20:09, Arnaud Minier
<arnaud.minier@telecom-paris.fr> wrote:
>
> This patch adds the STM32L4x5 RCC (Reset and Clock Control) device and is part
> of a series implementing the STM32L4x5 with a few peripherals.
>
> Due to the high number of lines, I tried to split the patch into several 
> independent commits.
> Each commit compiles on its own but I had to add temporary workarounds in 
> intermediary commits to allow them to compile even if some functions are not 
> used. However, they have been removed once the functions were used. Tell me 
> if this is ok or if I should remove them.
>
> Also, the tests are not very exhaustive for the moment. I have not found a 
> way to test the clocks' frequency from the qtests, which limits severely the 
> exhaustiveness of the tests.

Where you have a device connected to an output clock that produces some
useful behaviour dependent on the clock frequency it is given (eg if
it is a timer device that has a timer count register you can read or
which will fire an interrupt or set a status bit after a certain time),
you can do something like:
 * configure the RCC for a given frequency
 * advance the simulation time with clock_step()
 * check that the device connected to that clock has changed
   in the way you expect it to

But you're right that we don't have any handy way to look specifically
at the outputs of a clock-controller to check the frequency they're set to.
It would probably be possible to add one, but we'd need to enhance
the qtest protocol to add a "for the Clock specified by this QOM path,
return the period it's currently set to".

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]