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

["Philippe Mathieu-Daudé" <f4bug@amsat.org>]

On 9/2/20 6:49 PM, Peter Maydell wrote:
> 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?

QEMU is supposed to model machine with no knowledge of the guest,
but the virt case is a particular one indeed... as it has to know
it is virtualized.

>  * what is a "good" frequency which gives the guest the best
>    possible choices of baud rate?

I'll think about it...

> and also at whether we need to tell the guest the frequency
> via a device tree or other mechanism.

Now I understand why the virt machines are so complicated...
Many dynamic information to provide to the guest.

> 
> 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.

I'm not sure all physical devices could work, but let's try this
way.

> 
> 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 :-)

Yes, it is a mess, I'm trying to not give up cleaning it.

Note, some boards correctly set the frequency:

musicpal, omap1 based, kzm, pxa2xx, boston.

lasi / jazz use an unlikely 8MHz clock.

For ppc405 I'm not sure this is an odd case:
  99MHz / 248 = 399193.54838709677419354838

Thanks!

> 
> thanks
> -- PMM
>