On 9/2/20 6:49 PM, Peter Maydell wrote: > On Wed, 2 Sep 2020 at 17:35, Philippe Mathieu-Daudé <f4...@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 >