On Thu, 12 Jan 2023 at 13:15, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
>
> Hi
>
> Am 12.01.23 um 11:45 schrieb Daniel Vetter:
> > On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 12.01.23 um 10:59 schrieb Daniel Vetter:
> >>> On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote:
> >>>> Hi
> >>>>
> >>>> Am 11.01.23 um 16:41 schrieb Daniel Vetter:
> >>>>> This one nukes all framebuffers, which is a bit much. In reality
> >>>>> gma500 is igpu and never shipped with anything discrete, so there should
> >>>>> not be any difference.
> >>>>>
> >>>>> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> >>>>> ---
> >>>>> drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> >>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
> >>>>> index cd9c73f5a64a..9b0daf90dc50 100644
> >>>>> --- a/drivers/gpu/drm/gma500/psb_drv.c
> >>>>> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> >>>>> @@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> >>>>> * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we
> >>>>> * might be able to read the framebuffer range from the device.
> >>>>> */
> >>>>> - ret = drm_aperture_remove_framebuffers(true, &driver);
> >>>>> + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver);
> >>>>
> >>>> This does not work. The comment just above the changed line explains why.
> >>>> The device uses shared memory similar to other integrated Intel chips. The
> >>>> console is somewhere in a 16 MiB range, which has been stolen by the BIOS
> >>>> from main memory. There's only a 1 MiB memory range on the device to program
> >>>> the device. Unless you want to refactor as described, this call has to cover
> >>>> the whole memory for now.
> >>>
> >>> Uh. So it's maybe not so pretty, but what if I just call both functions?
> >>
> >> That's ways more ugly IMHO.
> >>
> >>> That way we get the vga handling through the pci one, and the "make sure
> >>> there's no fb left" through the other one. Plus comment of course.
> >>>
> >>> Otherwise we'd need to somehow keep the vga stuff in the non-pci paths,
> >>> and that just feels all kinds of wrong to me.
> >>
> >> With your patch applied, aperture_detach_devices() does all the work of
> >> removing. I'd add the following internal functions:
> >>
> >> static void aperture_detach_head(bool is_primary)
> >> {
> >> /*
> >> * lengthy comment here
> >> */
> >> if (is_primary)
> >> sysfb_disable()
> >> }
> >>
> >> static void aperture_detach_tail(bool remove_vga)
> >> {
> >> if (remove_vga) {
> >> aperture_detach_devices(VGA_PHYS_)
> >> vga_remove_vgacon()
> >> }
> >> }
> >>
> >> And call both of them at the beginning/end of
> >> aperture_remove_conflicting_devices() and
> >> aperture_remove_conflicting_pci_devices().
> >>
> >> You'd still need to primary argument to
> >> aperture_remove_conflicting_devices(), but there will be no code duplication
> >> with the aperture helpers and the purpose of each code fragment will be
> >> clearer.
> >
> > Yeah I don't want the primary argument. Aside from this one case here it's
> > not needed. Also by pushing this special case into the one driver that
> > needs it we keep it contained, instead of spreading it all around.
> > Inflicting a parameter on every (and in total we have a lot of callers of
> > this stuff) just because of gma500 does not seem like a good idea to me.
>
> Unfortunately, vgacon and vgaarb require a PCI device. I don't like the
> proposal, but maybe it's the best for now. So go ahead if you like. I do
> expect that this needs additional work in future, however.
>
> Just some more thoughts.
>
> Grep for drm_aperture_remove_framebuffers(). Within DRM there are really
> just 10 drivers calling this function (vs. 12 callers of
> drm_aperture_remove_conflicting_pci_framebuffers()). In fbdev, there are
> many callers of the PCI helper (~40) and apparently only 3 for the
> non-PCI one. The other drivers are panels, USB, MIPI, etc and don't
> interact with the system framebuffer. Compared to the overall number of
> drivers, we have surprisingly few 'traditional graphics cards' in DRM.
This is largely historical. fbdev is from the 90s, when we had the
huge explosion in largely pci graphics cards, because that was the
place where all the growth and hence drivers were. 80% of these
companies/chipe all died within a short few years.
kms otoh had the huge growth in the 2010s, where there was the tail
end of the SoC mobile explosion, so that's where we have tons of
drivers. If you look at staging there's a pile more fbdev drivers for
SoC, but many of these never got beyond the "vendor hacked some stuff
together and shipped it" stage. So that's probably why they lack
polish like fw -> driver handover (most of these just booted directly
to the driver in real products).
> Another thing is that gma500 and the other 9 drivers simply don't bother
> to get the framebuffer range. They should be reworked to fetch the
> configured framebuffer from the device and release that region only. The
> practical impact is close to zero, so it hasn't happened.
I think that's ok, because trying to figure out the real fb means you
need fairly complete hw state readout (otherwise there's no
motivation), and i915 is the only driver that ever really did that.
Just for fw driver removal "nuke everything" gets the job done.
-Daniel
> Best regards
> Thomas
>
>
> > -Daniel
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
