Re: [RFC PATCH] of/platform: Disable sysfb if a simple-framebuffer node is found

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux