Re: hw/clock: What clock rate for virt machines?

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

On Wed, 2 Sep 2020 at 17:35, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> Peter said "'clock' is basically meaningless for virt machines",
>
> I understand and agree. But how to make that explicit/obvious in
> the code, when a device expects a clock frequency/period?

When a particular *device* needs a clock, then presumably
it has a defined purpose for it, and we can pick a
frequency for it then.

> See for example hw/riscv/virt.c, it uses the following (confusing
> to me) in virt_machine_init():
>
>    serial_mm_init(system_memory, memmap[VIRT_UART0].base,
>        0, qdev_get_gpio_in(DEVICE(mmio_plic), UART0_IRQ), 399193,
>        serial_hd(0), DEVICE_LITTLE_ENDIAN);

In this case, the board has a model of a 16550A UART on it,
which uses its input clock to determine what the actual baud
rate is for particular guest settings of the divisor registers.
So we need to look at:
 * what does guest software expect the frequency to be?
 * what is a "good" frequency which gives the guest the best
   possible choices of baud rate?
and also at whether we need to tell the guest the frequency
via a device tree or other mechanism.

In some devices the input clock genuinely doesn't affect the
guest-visible behaviour, in which case we can pick an arbitrary
or conventional value, or just implement the device to work OK
without a clock connected.

Note also that we don't have to make a single decision for the
whole board -- we can run different devices with different clocks
if that makes sense.

Incidentally the serial.c API seems to be slightly confused
about the difference between setting the baudbase as a value
in bps (ie the traditional 9600, 115200, etc values) or a
frequency (where 115200 bps corresponds to a 1.8432MHz clock,
apparently). Luckily nobody uses the serial_set_frequency()
function :-)

thanks
-- PMM