Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis <alistair23@gmail.com>]

On Fri, Aug 20, 2021 at 8:36 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Fri, Aug 20, 2021 at 1:43 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Hi Alistair,
> >
> > On Thu, Aug 19, 2021 at 07:10:00PM +1000, Alistair Francis wrote:
> > > On Thu, Aug 19, 2021 at 4:38 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > >
> > > > > These are the EINVAL strace tells me in the not working case:
> > > > >
> > > > > prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > ioctl(5, FBIOPUT_VSCREENINFO, 0x4ce8e0) = -1 EINVAL (Invalid argument)
> > > > >
> > > > > I'm guessing it's related to FBIOPUT_VSCREENINFO then, is that
> > > > > something that could be added to the DRM emulation?
> > > >
> > > > If it turns out FBIOPUT_VSCREENINFO is the culprint it would also be
> > > > good to know why we see EINVAL.
> > > > One way is to sprinkle a number of printk's in fb_set_var(),
> > > > then you can see how far you get before it fails.
> > >
> > > Thanks for the help.
> > >
> > > I see this line:
> > >
> > > ret = info->fbops->fb_check_var(var, info);
> > >
> > > in fb_set_var()
> > >
> > > returning early.
> >
> > Super, then next step is to annotate drm_fb_helper_check_var()
> > to see where it fails.
> > Try this and let us know the result.
>
> Thanks!
>
> After adding some prints, I realised there are already some in there
> that are disabled by default. After enabling them I see this:
>
> "fbdev emulation doesn't support changing the pixel clock, value of
> pixclock is ignored"
>
> and
>
> "fb requested width/height/bpp can't fit in current fb request
> 260x1408-32 (virtual 260x23936) > 334x1405-32"
>
> which returns EINVAL.
>
> This is where I'm confused though. The values 334 and 1405 are taken
> from the vendor and in the working fbdev driver they are using the
> same values.
>
> I tried to add a similar print to mxsfb_check_var() for the working
> version, to check what the values are, but there doesn't seem to be
> any equivalent of fb->width and friends.

I dug into this some more.

In the working mxsfb and non-working fbdev emulation the userspace
software sets:

xres: 260
yres: 1408
xres_virtual: 260
yres_virtual: 23936

That passes the old mxsfb_check_var() and works.

While that fails the new fbdev emulation check. Even increasing the
width and height from 334x14085 to 260x23936 doesn't help as I get a
range of other errors and no display. Just removing the check also
doesn't work and results in kernel panics.

It seems there is some difference in handling the resolutions between
the mxsfb driver and the fbdev emulation on the new DRM driver. I'm
just not sure what the difference is.

Alistair