Rob Herring <robh@xxxxxxxxxx> writes: Hello Rob, > On Fri, Dec 1, 2023 at 4:21 AM Javier Martinez Canillas [...] >> >> I don't have a better idea than this patch but maybe Thomas or Sima do? >> > >> > At SUSE, we've carried such a patch in our repos for some time. It works >> > around the double-framebuffer problem in a similar way. [1] >> > >> >> Thanks for the information. I see that your patch is basically mine but >> doing it unconditionally while this one only does the sysfb_disable() if >> a "simple-framebuffer" DT node has been found. >> >> > As Javier mentioned, we do track the framebuffer ranges for EFI/VESA/OF >> > framebuffers in the graphics aperture helpers. Fbdev has done this for >> > decades, and the current codebase extends and harmonizes this >> > functionality among fbdev and DRM drivers. >> > >> > WRT DT vs EFI: AFAIK the EFI support on affected platforms looks at the >> > DT to set up the EFI framebuffer. So IMHO the DT is the authoritative >> > source on the framebuffer. >> > >> >> Agreed. Sima Vetter also mentioned on IRC that they think this patch is >> the least bad option. Rob, Ard any thoughts? Maybe we can land this as >> a fix and then figure how this could be better handled in the long term? > > What about moving the DT setup code here to sysfb? Then we just setup > the right thing up front. > Right now sysfb is pretty platform agnostic, in the sense that just looks at the screen_info global struct and uses it to add the platform data that contains the firmware provided framebuffer. How the screen_info was filled (e.g: by the Linux EFI stub using the GOP or the x86 early boot code using VESA) is transparent to sysfb. For this reason adding platform specific logic there, like finding OF nodes, is not desirable. I also suggested to Thomas to move the DT setup code to sysfb but he said that would be the wrong approach for the reason mentioned above. Please correct me Thomas if I'm misremembering here. > However, there might be one other issue with that and this fix. The DT > simplefb can have resources such as clocks and regulators. With > fw_devlink, the driver won't probe until those dependencies are met. > So if you want the framebuffer console up early, then you may want to > register the EFI framebuffer first and then handoff to the DT simplefb > when it probes (rather than registering the device). > > But I agree, probably better to take this patch now and have those > quirks instead of flat out not working. > If we do that what's the plan? Are you thinking about merging this patch through your OF tree or do you want to go through drm-misc with your ack? > Rob > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
