Questions about clocks emulation

Questions about clocks emulation

[Arnaud Minier]

Hi all,

I tried to implement the RCC (Reset and Clock Control) for the STM32L4x5_SoC but ran into some problems regarding clock emulation in Qemu.
In this SoC, it is possible to change the source of several clocks used for devices like the CPU, the USART, and approximately every other device on the SoC.
This change can be made at runtime by writing into a specific register.
I tried to model this by using the clocks in hw/core/clock.c by I noticed that it is not possible to change a clock's source once it has been assigned (see clock_set_source()).
It prevents me from implementing a clock tree similar to the one on the hardware.

Is this limitation there for some reason or has it simply not been implemented?

Thanks,
Arnaud Minier

Re: Questions about clocks emulation

[Philippe Mathieu-Daudé]

Hi Arnaud,

(Cc'ing Peter and Luc)

On 12/12/23 14:05, Arnaud Minier wrote:
> Hi all,
> 
> I tried to implement the RCC (Reset and Clock Control) for the STM32L4x5_SoC but ran into some problems regarding clock emulation in Qemu.
> In this SoC, it is possible to change the source of several clocks used for devices like the CPU, the USART, and approximately every other device on the SoC.
> This change can be made at runtime by writing into a specific register.
> I tried to model this by using the clocks in hw/core/clock.c by I noticed that it is not possible to change a clock's source once it has been assigned (see clock_set_source()).

Ouch.

I thought this was what connect_mux_sources() what doing (see
hw/misc/bcm2835_cprman.c) but it is only called (along the
clock_set_source() calls) from the realize() handler.

> It prevents me from implementing a clock tree similar to the one on the hardware.
> 
> Is this limitation there for some reason or has it simply not been implemented?

There is a /* changing clock source is not supported */ comment in
clock_set_source(), so likely not implemented :)

IIUC the only issue is how to update the src->children qlist.

> Thanks,
> Arnaud Minier
> 

Re: Questions about clocks emulation

[Luc Michel]

Hi,

On 20:13 Wed 13 Dec     , Philippe Mathieu-Daudé wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> Hi Arnaud,
> 
> (Cc'ing Peter and Luc)
> 
> On 12/12/23 14:05, Arnaud Minier wrote:
> > Hi all,
> > 
> > I tried to implement the RCC (Reset and Clock Control) for the STM32L4x5_SoC but ran into some problems regarding clock emulation in Qemu.
> > In this SoC, it is possible to change the source of several clocks used for devices like the CPU, the USART, and approximately every other device on the SoC.
> > This change can be made at runtime by writing into a specific register.
> > I tried to model this by using the clocks in hw/core/clock.c by I noticed that it is not possible to change a clock's source once it has been assigned (see clock_set_source()).
> 
> Ouch.
> 
> I thought this was what connect_mux_sources() what doing (see
> hw/misc/bcm2835_cprman.c) but it is only called (along the
> clock_set_source() calls) from the realize() handler.

From a clock user API standpoint, we made the choice to hardwire the
clock tree, as it is in fact hardwired in the chip you are trying to
model (physical connections insides the chip do not "change" when you
write to a register). Things are usually implemented using muxes, clock
dividers and such between PLLs and devices. This is the approach you
should adopt when implementing your clock tree. As Philippe mentioned
you can have a look at hw/misc/bcm2835_cprman.c which is a real world
example of a clock tree implementation (in the Raspberry PI SoC).

> 
> > It prevents me from implementing a clock tree similar to the one on the hardware.
> > 
> > Is this limitation there for some reason or has it simply not been implemented?
> 
> There is a /* changing clock source is not supported */ comment in
> clock_set_source(), so likely not implemented :)
> 
> IIUC the only issue is how to update the src->children qlist.

IIRC from a clock API implementation standpoint, there were some serious
questions about dynamic reconfiguration of the clock tree. But I can't
remember the details (maybe some issues about migration?). But again,
the API in its current form should be enough to catch your need. If you
have a specific pattern you think is not expressible with the current
API, please expose it precisely so we can see how to fix that.

Thanks

-- 
Luc

> 
> > Thanks,
> > Arnaud Minier
> > 
> 

--