Re: [PATCH 1/1] hw/timer/sse-timer: Add CNTFRQ reset property

[Peter Maydell]

On Thu, 14 Sept 2023 at 23:42, Joe Komlodi <komlodi@google.com> wrote:
>
> This can have a non-zero reset value, and cause the kernel to complain
> about a CNTFRQ mismatch if TF-A (or firmware in general) does not
> initialize it (because it expects the value to be non-zero out of
> reset).
>
> To fix this, we'll just add an object property that people can use to
> initialize the CNTFRQ reset value.

I'm a bit confused -- you talk about TF-A, but as far as I'm
aware the only use of this timer device is in the ARMSSE,
which is used only on M-profile boards.

Also, since this device is a sysbus device, there's not much
point adding the property without also adding code in the
ARMSSE etc that sets the property appropriately. On its
own this patch will do nothing.

Plus, it is firmware's job to set the value of this register:
in real hardware it is always zero on reset. For the A-profile
in-core CNTFRQ we set a non-zero reset value because in a
lot of use cases QEMU is effectively emulating firmware
and then directly booting Linux. I'm not so sure those cases
apply for M-profile boards?

If we do want to follow a similar approach to the A-profile
CPU timer, rather than having a separate property that must
be set, it would be neater for the timer to ask the counter
for the frequency -- the SSE timer is run from the SSE counter,
and the counter has a Clock input and can call clock_get_hz()
to get its frequency.

thanks
-- PMM