[PATCH] drm/panel: simple: Support simple VGA panels

[Linus Walleij]

On Tue, Jul 17, 2018 at 12:50 AM Rob Herring <robh at kernel.org> wrote:
> On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij <linus.walleij at linaro.org> wrote:

> > +Video Graphics Array
>
> VGA is more a controller interface than a panel...

I don't know what else to call it though, other than formulating someting
bureaucratic like
"Video Graphics Array Display Resolutions"

Or should I use the abbreviation:
"VGA Display Resolutions" rather?

The Wikipedia article "display resolution"
https://en.wikipedia.org/wiki/Display_resolution
just calls these three resolutions "VGA", "SVGA " and "XGA".

> > +static const struct drm_display_mode video_graphics_array_modes[] = {
> > +       {
> > +               /*
> > +                * This is the most standardized "vanilla" VGA mode there is:
> > +                * 640x480 @ 60 Hz
>
> Don't we have standard VESA timings already defined as well as timings
> that can be calculated based on resolution and refresh rate (called
> CVT IIRC). Why duplicate here?

They are inside drivers/gpu/drm/drm_edid.c
all in static const arrays and enumerated by the index in the
DMT spec taken out of XFree86. (drm_dmt_modes[])

I don't know. It is quite encapsulated into that EDID driver and
doesn't seem very reusable. To pick out a few from inside EDID
seems pretty daunting. I'd like to hear what the DRM folks think
about that.

> Why don't you just define a 'vga-connector' node

Because this is not a VGA connector, it is just the VGA resolution.
In other circumstances I do use it.

I think you most often have to use that connector with the dumb
VGA DAC bridge though, as the VGA connector is analog and
what comes out of a display controller is digital. So it needs to
make some kind of sense here.

In a way (as we discussed before) the whole panel-simple.c thing
is a bit bogus, as it is probably in most cases hiding a bridge or
a dumb DAC or at least a VGA connector or similar that should've
been properly modeled, but in this case I am more certain that it is
actually the right choice.

I guess I could try to use the dumb VGA bridge and the VGA
connector, and it indeed falls back to VGA resolutions if no DDC
channel is available but if I go in and say there is a DAC bridge
and VGA connector I am essentially lying.

> and IIRC, you can
> just force the standard modes from userspace with DRM.

I guess you mean the kernel command line arguments, lest
there will be no boot console.

Apart from being a user experience horror story, that requires
a VGA connector bridge, as per above. (It's the EDID code that
does that command line parsing.) And that requires lying about
having a VGA connector bridge.

But I can surely lie if everyone thinks that is the best idea :D

> Maybe you need
> some flag to force a connection in the emulator and perhaps some fake
> EDID data to set a default mode.

This device tree I'm creating is for ARM RTSM which is a proprietary
ARM tool.

Sudeep at ARM says it does not emulate any DAC bridge such
as found in the Versatile Express machine family. It just expects
to have the right resolution parameters written into the registers
of the PL111, which in turn of course can only get it from a
panel or bridge driver of some sort.

The way those emulators work (AFAICT) is that they simply monitor
register writes to the resolutions parameters to scale the emulator
display window and then they read out the RGB data into that
window, pixel by pixel, from the indicated memory area.
It works for them.

In QEMU, we had the same problem. It didn't support proper reporting
of fake EDID on these platforms either, because of not properly
modeling the hardware it was emulating, instead relying on the register
reads as above. Since it is open source I could
simply fix it:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04651.html
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04652.html
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04653.html

After this, the QEMU for Versatile Express can properly use the
bridge.

I do try to be gritty and thorough! :D

I don't really know what RTSM is and I can't run it myself. I just
have to support it in the refactoring to use DRM for the ARM
Versatile Express machines. I cannot change its source code.

> There's also some other cases of
> "transparent" bridges which don't have any driver.

Yeah I think they mostly use panel-simple.c in the DRM
case don't they? We come full circle.

Yours,
Linus Walleij