Re: [PATCH v3] drm/gma500: depend on framebuffer

[Patrik Jakobsson <patrik.r.jakobsson@gmail.com>]

On Tue, Apr 12, 2022 at 3:48 AM James Hilliard
<james.hilliard1@gmail.com> wrote:
>
> On Mon, Apr 11, 2022 at 3:27 AM Patrik Jakobsson
> <patrik.r.jakobsson@gmail.com> wrote:
> >
> > On Sun, Apr 10, 2022 at 10:05 PM James Hilliard
> > <james.hilliard1@gmail.com> wrote:
> > >
> > > On Sun, Apr 10, 2022 at 1:52 PM Patrik Jakobsson
> > > <patrik.r.jakobsson@gmail.com> wrote:
> > > >
> > > > On Sun, Apr 10, 2022 at 9:40 PM James Hilliard
> > > > <james.hilliard1@gmail.com> wrote:
> > > > >
> > > > > On Sun, Apr 10, 2022 at 1:36 PM Patrik Jakobsson
> > > > > <patrik.r.jakobsson@gmail.com> wrote:
> > > > > >
> > > > > > On Sat, Apr 9, 2022 at 6:23 AM James Hilliard <james.hilliard1@gmail.com> wrote:
> > > > > > >
> > > > > > > Select the efi framebuffer if efi is enabled.
> > > > > > >
> > > > > > > This appears to be needed for video output to function correctly.
> > > > > > >
> > > > > > > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> > > > > >
> > > > > > Hi James,
> > > > > > EFI_FB is its own driver and not needed by gma500 to drive its
> > > > > > hardware. What makes you think it's required?
> > > > >
> > > > > I wasn't getting any HDMI video output without it enabled for some reason,
> > > > > I assume it is doing some sort of initialization needed by gma500
> > > > > during startup.
> > > >
> > > > Then it sounds like you might just be using EFI_FB and not gma500. Can
> > > > you provide the kernel log with drm.debug=0x1f set on kernel
> > > > command-line.
> > >
> > > Seems efifb loads first and then hands off to gma500
> >
> > That is how it normally works but efifb shouldn't change the state of
> > the currently set mode so shouldn't affect gma500.
> > From the logs I can see that you have LVDS (internal panel), HDMI and
> > DP (3 displays in total) connected. This sounds wrong. Your version of
> > gma500 (Cedarview) doesn't support more than 2 crtcs/pipes. This might
> > be a problem.
>
> Yeah, there's a bug there with the connector status, only DVI-D-1 is actually
> connected, I have DP-2 and LVDS-1 turned off in weston.

Ok, but are the connectors physically connected to anything?
Regardless of what you do in Weston, the connectors shouldn't be
getting modes if they aren't used. LVDS might be from VBIOS but I'm
not sure where the DP modes come from. It would help if you also
provide kernel logs with drm.debug=0x1f when the outputs doesn't work
so I have something to compare with.