On Mon, 9 May 2022 at 18:56, Richard Henderson
<richard.henderson@linaro.org> wrote:
I'm not 100% sure how this "Other configuration control register" should be
handled, but
definitely not like this.
I see you're putting control of this register into loongarch_qemu_read in
target/loongarch/cpu.c. Which, I suppose is fair, because this is documented
as part of
the 3A5000 cpu documentation. But then you split out all of the devices which
are *also*
documented as part of the cpu into the board configuration.
This reminds me of the memory-mapped interface that the armv7m cpu has with its
own
registers. I believe that you need to model this similarly, where you will
have a device
that represents the cpu, and then instantiates all of the devices that are
listed in the
Loongson 3A5000 TRM -- call this ls3a to match the ls7a name you have for the
7A1000
bridge device.
When there is a write to the ls3a "Other function configuration register", the
ls3a will
need to communicate the changes to the various bits to its various sub-devices.
I do not
think it unreasonable to have direct function calls between the components.
Peter, do you have any advice from the armv7m side?
Nothing concrete. I'm not sure that we'd structure the armv7m stuff the way
we have now if we were writing it from scratch, but it's functional enough.
(In particular, if MMIO regions were part of Device rather than SysBusDevice
then I'd be tempted to suggest that CPUs with MMIO-mapped registers should
directly own their MemoryRegions for them. But they aren't, so we can't do
that.)