On 21/02/19 06:02:p, Heinrich Schuchardt wrote:
> drivers/misc/qfw.c should be converted to the driver model instead of
> initializing the driver in arch_early_init_r() on qemu-arm and
> qemu_chipset_init() on qemu-x86.
>
> Cf. https://u-boot.readthedocs.io/en/latest/driver-model/index.html
>
> Please, coordinate the change with Simon.
Understood. I've played around a little bit with the DM and it
shouldn't be too hard to convert. Probably the biggest question in my
mind is, should it be slotted into UCLASS_MISC? Or do we create a qfw
uclass?
I am also a little unsure on the division of responsibilities and
configuration as we move this to DM.
Right now, drivers/misc/qfw.c handles the QFW "protocol" entirely on its
own, and it's the responsibility of arch/x86/cpu/qemu/qemu.c (and
arch/arm/mach-qemu/qemu.c in this patch series) to mediate the
communication between the QFW handler and the actual platform; i.e. on
x86 we use PIO (and we simply must assume it is present if the config is
enabled), and on Arm we use MMIO (and we use DT to detect and
configure).
In other words, on x86 including QFW means we need to just try PIO,
whereas on Arm including QFW means we let the DM handle it if the node
appears. I'll try to make this work in code and hopefully someone can
guide me a little on the Kconfig.
> Should cmd/qfw.c be enhanced to show if the ramfb device is present?
Yes, once ramfb support is implemented, but I think that should come in
a later patch series. We will initialise ramfb if we detect an
"etc/ramfb" entry in the qfw list, like here:
=> qfw list
bios-geometry
bootorder
etc/acpi/rsdp
etc/acpi/tables
etc/boot-fail-wait
etc/ramfb
etc/smbios/smbios-anchor
etc/smbios/smbios-tables
etc/table-loader
etc/tpm/log
opt/test
vgaroms/vgabios-ramfb.bin
=>
Including information on how much we allocated for the ramfb, where we
placed it, etc. will be a job for a future "qfw ramfb" command.
Best,
Asherah
