On Thu, Jan 15, 2026 at 08:57:10AM +0100, Thomas Zimmermann wrote: > Coreboot implements framebuffer support via simple-framebuffer. Provide a > dedicated DRM driver. Keep the simple-framebuffer code for now. > > For each firmware's provided framebuffer, we prefer a dedicated DRM driver > tailored towards the platform's feature set. The coreboot framebuffer > device currently creates a simple-framebuffer device for the provided > framebuffer aperture. But simple-framebuffer is for DeviceTree nodes; not > for coreboot. The simple-framebuffer infrastructure should be phased out > for non-DT use cases. Coreboot is one of the final users of the code > (besides n64). > > Patches 1 to 5 start by fixing problems in the coreboot framebuffer > implementation. There is a possible dangling pointer, the memory is > marked as busy, the device hierarchy is incorrect, and a few minor things. > > Patches 6 to 9 prepare the coreboot support for use by external drivers. > Specifically, structures for the entries os the coreboot payload table > have to be exported. > > Patches 10 to 12 add corebootdrm, a DRM driver for the new > coreboot-framebuffer platform device. Corebootdrm follows the pattern > established by similar drivers. It also uses the same sysfb helpers. It > is therefore fairly small. With patch 11, it has feature parity with > simpledrm on the old simple-framebuffer. Patch 12 adds support for panel- > orientation flags that coreboot makes available.
What would you suggest to submit the patches (e.g., which patches submit through which tree)? Do they have build-time dependencies?
