Hi Asherah, On Fri, 19 Feb 2021 at 18:14, Asherah Connor <a...@kivikakk.ee> wrote: > > 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?
Probably create a uclass. I expect there are operations and some private data. We also need to think about testing, since all uclasses need a sandbox test. > > 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. The cros_ec driver has different transports for the actual comms, so it might be useful as an example. > > > > 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. What is a ramfb? Regards, Simon
