On Mon, Dec 4, 2023 at 3:39 AM Javier Martinez Canillas <javierm@xxxxxxxxxx> wrote: > > 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? I can take it. Do we need this in 6.7 and stable? Rob
