On 21/02/23 01:02:p, Heinrich Schuchardt wrote:
On 23.02.21 12:43, Asherah Connor wrote: For which architectures does the fw_cfg device exist?
It it is only ARM and X86, than I am missing such a dependency on CONFIG_CMD_QFW.
Right now we have:
arch/arm/Kconfig: ... config ARCH_QEMU ... imply CMD_QFW
I think we also want this:
arch/x86/cpu/qemu/Kconfig config QEMU ... imply CMD_QFW
This is my first time using Kconfig and I'll admit I'm not too certain where things go.
If these numbers are constants, why should they be copied to platform data? This only increases code size.
I think there is nothing wrong with using constants here.
Okay, excellent. I'll fold those into drivers/misc/qfw_pio.c and get rid of the qfw_pio_plat struct entirely.
ARM yield is meant to be used on multi-threaded systems to indicate that the thread can be swapped. Why would we need it in U-Boot which is single-threaded?
Can't we simply use
while (be32_to_cpu(dma.control) & ~FW_CFG_DMA_ERROR);
with no command in the loop for all architectures?
Good question. This code originated here, where the original (x86-only) driver used pause:
https://gitlab.denx.de/u-boot/u-boot/-/commit/f60df20aa966c3de850afafe3cce70...
When porting to Arm I used the equivalent.
While U-Boot is single-threaded, the architecture that executes this instruction is always QEMU, and -- at a guess -- it might be that pause/yield here lets QEMU finish its part of the DMA faster.
I've run the QEMU tests on arm(64)/x86(_64) without the yield or pause and they still pass. It might be simply unnecessary, so I'll remove for now in favour of simplicity and less arch-specific code.
Best,
Asherah