Attention is currently required from: Andrey Petrov, Eric Lai, Kapil Porwal, Nick Vaccaro, Paz Zcharya, Subrata Banik.
Tim Van Patten has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/78388?usp=email )
Change subject: {commonlib, libpayload}: Add "has_fw_splash_screen" entry ......................................................................
Patch Set 2:
(2 comments)
Commit Message:
https://review.coreboot.org/c/coreboot/+/78388/comment/f0751d52_1c084a72 : PS1, Line 13: This information is useful for overriding the kernel command-line : argument fw_splash. If fw_splash=1, the kernel will skip modeset because : the splash screen has already been rendered by the firmware.
As long as fw_splash is a valid argument which can be overridden, I don't see a problem.
`fw_splash` is not a valid argument. The linux kernel does not support it.
as I said earlier, this CL has no relation about how this information can be useful by payload/DC/crosos. We are just keeping this information handy.
This is dead code if there's no consumer of the information. Specifically, depthcharge doesn't use it, but passes it along via kernel command line arguments, which the kernel doesn't recognize or use either.
The only reason it's being added is as a workaround to inform user space (frecon) that the display is initialized. However, that's also unnecessary, since we should be using a `cros_config` value to indicate this feature instead. Further, this is all temporary until the necessary kernel CLs exist to query the HW directly to prevent re-initialization.
https://review.coreboot.org/c/coreboot/+/78388/comment/422c98ea_3ac7fee3 : PS1, Line 18: The payload (e.g., deptcharge) does not : have any other way to determine whether the firmware has initiated : screen rendering.
The payload doesn't actually care either though. […]
PSR is actually not a very good example, since that's a hack as well. See b/287462135, where we've asked AMD to transition to doing all of that work in the kernel (where it belongs), because these types of fixes require expensive and slow FW uprevs to add (ad eventually revert).
We should avoid adding new kernel command line parameters for the same reason, if possible. Changes to them are slow, expensive, and difficult to coordinate across multiple boards and vendors.
-
Tim Van Patten (Code Review)