On 11/4/26 9:47 AM, Clément Le Goffic wrote:
Hello Clement,
U-Boot on RSIP is not using the timer, so shouldn't SCP start the timer, since
it also starts all of its users ? That way the timer is only started when it is
really needed.
[...]
The SCP isn't using it either. The timer is needed by the AP and the RT cores
and is always needed whichever SW component start on the system.
TFA on Ironhide even start it here (I consider to remove it once this land):
https://github.com/ARM-software/arm-trusted-firmware/blob/v2.15.0/plat/renesas/rcar_gen5/bl31_plat_setup.c#L161-L171
If AP and RT cores use the timer as a shared resource, and SCP is the
coordinator of shared resources on this system, then I would argue it is
task of the SCP to set up that shared resource, i.e. the timer.
SCP doesn't start by itself all of its user, it is U-boot on RSIPM that sends the
"start" request.
SCP is the SCMI server it just react to SCMI requests. A "start generic
counter" SCMI requests doesn't exist. Hence do it here.
U-Boot (client) sends a request to the SCP to start the first user of
the timer, so SCP should take care of configuring the system correctly
for that first user, i.e. enable the timer.
The generic counter is the platform counter, U-boot on RSIPM should start all
what is needed for the platform to work as a bootloader would do.
U-Boot driver model is explicitly designed to not start unnecessary
parts and boot as quickly as possible.
Why not start the timer using the SCP when there are actual users of the
timer ?
--
Best regards,
Marek Vasut
