Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/25372 )
Change subject: sdm845: Add QUPv3 FW load & config ......................................................................
Patch Set 76:
(1 comment)
https://review.coreboot.org/#/c/25372/6/src/mainboard/google/cheza/qupv3_con... File src/mainboard/google/cheza/qupv3_config.c:
https://review.coreboot.org/#/c/25372/6/src/mainboard/google/cheza/qupv3_con... PS6, Line 18: struct se_cfg se_mappings[QUPV3_SE_MAX] =
This will violate HPG sequence requirement provided to us by the HW team which says that we have to […]
But this is only a problem if we try to load different firmware onto the same QUP instance, right? That should normally not happen. The only way that would happen is if we have an RW update after shipping where we need to fix a problem with some QUP blob already loaded by RO firmware. If that ever happens, we can add code to re-run the common QUP initialization, and run all the driver init functions again afterwards. (coreboot is single-threaded anyway so there's never really an ongoing QUP transfer at the time we're doing anything else.)