Hi,


On 2024/2/5 16:24, Thomas Zimmermann wrote:

Hi

Am 02.02.24 um 16:23 schrieb Sui Jingfeng:

quoted

Hi,


On 2024/2/2 19:58, Thomas Zimmermann wrote:

quoted

Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
the Linux device hierarchy and lets Linux handle dependencies among
devices. For example, the graphics hardware won't be suspended while
the firmware device is still active.

This is a very nice benefit, I can't agree more!

Because the backing memory of the firmware framebuffer occupied
belongs to the graphics hardware itself. For PCIe device, the
backing memory is typically the dedicated VRAM of the PCIe GPU.
But there are some exceptions, for example, the gma500. But I
think this can be fixed in the future, as majority(>99.9%) PCIe
GPU has the a dedicated VRAM.


For ARM and ARM64 platform device, the backing memory of the
firmware framebuffer may located at the system RAM. It's common
that the display controller is a platform device in the embedded
world. So I think the sysfb_parent_dev() function can be extended
to be able to works for platform device in the future.

The current approach has been taken from efifb. It would already not 
work reliably with gma500 or ARM SoCs. So there's no immediate loss of 
functionality AFAICT. But with the patchset now have a correct device 
hierarchy and PM for simpledrm, vesafb et al.

In the long term, I want to employ some of the logic in vgaarb that 
detects the firmware default device. That needs additional work, though.

Good ideas, try to be impressive.
I probably could help to test if I'm online.

Best regards
Thomas

quoted