drm/panel: simple: Support simple VGA panels

Message ID 20180716092339.9736-1-linus.walleij@linaro.org
State New
Headers show
Series
  • drm/panel: simple: Support simple VGA panels
Related show

Commit Message

Linus Walleij July 16, 2018, 9:23 a.m.
The need to support some straight-forward VGA panels that are
not adhering to any standard like DPI arise in the ARM RTSM VE
Real-Time Systems Model Virtual Executive. This emulator (which
is not QEMU) does not model any bridge or panel other than
displaying whatever the user defines that they have.

Currently a fake "DPI panel" is used for this with the old
FBDEV driver, but this is wrong as it is not conforming to any
MIPI DPI standards. However the resolution chosen there is
standard VGA, and we can cover this with the simple panel
by simply adding the most common VGA resolutions as a kind
of "simple panel".

In difference from other cases where "simple panel" might be
hiding something more complex (such as a panel driver or bridge)
this case is actually applicable, since we are running inside
a simulation with no real hardware on the output.

Cc: devicetree@vger.kernel.org
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

---
 .../display/panel/video-graphics-array.txt    | 21 ++++++
 drivers/gpu/drm/panel/panel-simple.c          | 66 +++++++++++++++++++
 2 files changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/video-graphics-array.txt

-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Rob Herring July 16, 2018, 10:50 p.m. | #1
On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>

> The need to support some straight-forward VGA panels that are

> not adhering to any standard like DPI arise in the ARM RTSM VE

> Real-Time Systems Model Virtual Executive. This emulator (which

> is not QEMU) does not model any bridge or panel other than

> displaying whatever the user defines that they have.

>

> Currently a fake "DPI panel" is used for this with the old

> FBDEV driver, but this is wrong as it is not conforming to any

> MIPI DPI standards. However the resolution chosen there is

> standard VGA, and we can cover this with the simple panel

> by simply adding the most common VGA resolutions as a kind

> of "simple panel".

>

> In difference from other cases where "simple panel" might be

> hiding something more complex (such as a panel driver or bridge)

> this case is actually applicable, since we are running inside

> a simulation with no real hardware on the output.

>

> Cc: devicetree@vger.kernel.org

> Cc: Sudeep Holla <sudeep.holla@arm.com>

> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> Cc: Liviu Dudau <liviu.dudau@arm.com>

> Cc: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

> ---

>  .../display/panel/video-graphics-array.txt    | 21 ++++++

>  drivers/gpu/drm/panel/panel-simple.c          | 66 +++++++++++++++++++

>  2 files changed, 87 insertions(+)

>  create mode 100644 Documentation/devicetree/bindings/display/panel/video-graphics-array.txt

>

> diff --git a/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt

> new file mode 100644

> index 000000000000..193d24ebe052

> --- /dev/null

> +++ b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt

> @@ -0,0 +1,21 @@

> +Video Graphics Array


VGA is more a controller interface than a panel...

> +

> +This binding is for simple panels using the standardized VGA resolutions

> +defined by de facto standards beginning with the IBM PS/2 in 1987.

> +

> +Required properties:

> +- compatible: should be "video-graphics-array"

> +

> +This binding is compatible with the simple-panel binding, which is specified

> +in simple-panel.txt in this directory.

> +

> +Example:

> +

> +panel {

> +       compatible = "video-graphics-array";

> +       port {

> +               vga_panel_in: endpoint {

> +                       remote-endpoint = <&foo>;

> +               };

> +       };

> +};

> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c

> index cbf1ab404ee7..db4db5a3f75e 100644

> --- a/drivers/gpu/drm/panel/panel-simple.c

> +++ b/drivers/gpu/drm/panel/panel-simple.c

> @@ -2069,6 +2069,69 @@ static const struct panel_desc winstar_wf35ltiacd = {

>         .bus_format = MEDIA_BUS_FMT_RGB888_1X24,

>  };

>

> +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?

Why don't you just define a 'vga-connector' node and IIRC, you can
just force the standard modes from userspace with DRM. Maybe you need
some flag to force a connection in the emulator and perhaps some fake
EDID data to set a default mode. There's also some other cases of
"transparent" bridges which don't have any driver.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Michal Vokáč July 17, 2018, 7:05 a.m. | #2
On 16.7.2018 11:23, Linus Walleij wrote:
> The need to support some straight-forward VGA panels that are

> not adhering to any standard like DPI arise in the ARM RTSM VE

> Real-Time Systems Model Virtual Executive. This emulator (which

> is not QEMU) does not model any bridge or panel other than

> displaying whatever the user defines that they have.

> 

> Currently a fake "DPI panel" is used for this with the old

> FBDEV driver, but this is wrong as it is not conforming to any

> MIPI DPI standards. However the resolution chosen there is

> standard VGA, and we can cover this with the simple panel

> by simply adding the most common VGA resolutions as a kind

> of "simple panel".

> 

> In difference from other cases where "simple panel" might be

> hiding something more complex (such as a panel driver or bridge)

> this case is actually applicable, since we are running inside

> a simulation with no real hardware on the output.

> 

> Cc: devicetree@vger.kernel.org

> Cc: Sudeep Holla <sudeep.holla@arm.com>

> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> Cc: Liviu Dudau <liviu.dudau@arm.com>

> Cc: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

> ---

>   .../display/panel/video-graphics-array.txt    | 21 ++++++

>   drivers/gpu/drm/panel/panel-simple.c          | 66 +++++++++++++++++++

>   2 files changed, 87 insertions(+)

>   create mode 100644 Documentation/devicetree/bindings/display/panel/video-graphics-array.txt

> 

> diff --git a/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt

> new file mode 100644

> index 000000000000..193d24ebe052

> --- /dev/null

> +++ b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt

> @@ -0,0 +1,21 @@

> +Video Graphics Array

> +

> +This binding is for simple panels using the standardized VGA resolutions

> +defined by de facto standards beginning with the IBM PS/2 in 1987.

> +

> +Required properties:

> +- compatible: should be "video-graphics-array"

> +

> +This binding is compatible with the simple-panel binding, which is specified

> +in simple-panel.txt in this directory.

> +

> +Example:

> +

> +panel {

> +	compatible = "video-graphics-array";

> +	port {

> +		vga_panel_in: endpoint {

> +			remote-endpoint = <&foo>;

> +		};

> +	};

> +};

> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c

> index cbf1ab404ee7..db4db5a3f75e 100644

> --- a/drivers/gpu/drm/panel/panel-simple.c

> +++ b/drivers/gpu/drm/panel/panel-simple.c

> @@ -2069,6 +2069,69 @@ static const struct panel_desc winstar_wf35ltiacd = {

>   	.bus_format = MEDIA_BUS_FMT_RGB888_1X24,

>   };

>   

> +static const struct drm_display_mode video_graphics_array_modes[] = {

> +	{

> +		/*

> +		 * This is the most standardized "vanilla" VGA mode there is:

> +		 * 640x480 @ 60 Hz

> +		 */

> +		.clock = 27175,

> +		.hdisplay = 640,

> +		.hsync_start = 640 + 16,

> +		.hsync_end = 640 + 16 + 96,

> +		.htotal = 640 + 16 + 96 + 48,

> +		.vdisplay = 480,

> +		.vsync_start = 480 + 10,

> +		.vsync_end = 480 + 10 + 2,

> +		.vtotal = 480 + 10 + 2 + 33,

> +		.vrefresh = 60,

> +		.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,

> +	},

> +	{

> +		/* SVGA 800x600 @60 Hz */

> +		.clock = 40000,

> +		.hdisplay = 800,

> +		.hsync_start = 800 + 40,

> +		.hsync_end = 800 + 40 + 128,

> +		.htotal = 800 + 40 + 128 + 88,

> +		.vdisplay = 600,

> +		.vsync_start = 600 + 1,

> +		.vsync_end = 600 + 1 + 4,

> +		.vtotal = 600 + 1 + 4 + 23,

> +		.vrefresh = 60,

> +		.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,

> +	},

> +	{

> +		/* XGA 1024x768 @60 Hz */

> +		.clock = 65000,

> +		.hdisplay = 1024,

> +		.hsync_start = 1024 + 24,

> +		.hsync_end = 1024 + 24 + 136,

> +		.htotal = 1024 + 24 + 136 + 160,

> +		.vdisplay = 768,

> +		.vsync_start = 768 + 3,

> +		.vsync_end = 768 + 3 + 6,

> +		.vtotal = 768 + 3 + 6 + 29,

> +		.vrefresh = 60,

> +		.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,

> +	},

> +};

> +

> +static const struct panel_desc video_graphics_array = {

> +	.modes = video_graphics_array_modes,

> +	.num_modes = ARRAY_SIZE(video_graphics_array_modes),

> +	.bpc = 8,

> +	/*

> +	 * Some typical 4:3 aspect ratio VGA monitor surely has these dimensions

> +	 * of 40x30 mm.

I am sure it has not :) s/mm/cm or add a zero.

Michal

> +	 */

> +	.size = {

> +		.width = 400,

> +		.height = 300,

> +	},

> +	.bus_format = MEDIA_BUS_FMT_RGB888_1X24,

> +};

> +

>   static const struct of_device_id platform_of_match[] = {

>   	{

>   		.compatible = "ampire,am-480272h3tmqw-t01h",

> @@ -2286,6 +2349,9 @@ static const struct of_device_id platform_of_match[] = {

>   	}, {

>   		.compatible = "winstar,wf35ltiacd",

>   		.data = &winstar_wf35ltiacd,

> +	}, {

> +		.compatible = "video-graphics-array",

> +		.data = &video_graphics_array,

>   	}, {

>   		/* sentinel */

>   	}

> 


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij July 17, 2018, 7:47 a.m. | #3
On Tue, Jul 17, 2018 at 12:50 AM Rob Herring <robh@kernel.org> wrote:
> On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij <linus.walleij@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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring July 17, 2018, 2:02 p.m. | #4
On Tue, Jul 17, 2018 at 1:47 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>

> On Tue, Jul 17, 2018 at 12:50 AM Rob Herring <robh@kernel.org> wrote:

> > On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij <linus.walleij@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.


It's not a panel either. A connector is something with variable
resolution. A panel is fixed resolution. Which do you want?

> 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.


Yes, the kernel command line is another way. But if you aren't using
fbcon, then userspace is the way.

> 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.


Because you have to set the resolution on the kernel command line? I'm
open to having a default resolution for the connector in DT.

> 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.


So putting *anything* in DT is a lie...

> 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


Having a way to set the default display resolution in QEMU would be
nice. I've hacked around that when using virgl.

> 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.


LVDS does. VGA doesn't.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Liviu Dudau July 18, 2018, 1:21 p.m. | #5
On Tue, Jul 17, 2018 at 08:02:46AM -0600, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 1:47 AM Linus Walleij <linus.walleij@linaro.org> wrote:

> >

> > On Tue, Jul 17, 2018 at 12:50 AM Rob Herring <robh@kernel.org> wrote:

> > > On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij <linus.walleij@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.

> 

> It's not a panel either. A connector is something with variable

> resolution. A panel is fixed resolution. Which do you want?

> 

> > 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.

> 

> Yes, the kernel command line is another way. But if you aren't using

> fbcon, then userspace is the way.

> 

> > 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.

> 

> Because you have to set the resolution on the kernel command line? I'm

> open to having a default resolution for the connector in DT.

> 

> > 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.

> 

> So putting *anything* in DT is a lie...


A long time ago I've tried to sorted this problem by creating a virtual
DRM encoder/connector that read the OF data to provide the EDID info.
Linaro has adopted the patches for a while, but it has never made it
into mainline because there was not enough interest for this "fake"
encoder/connector.

If interested in this solution I can try to revive the patches and make
another attempt at upstreaming them

https://git.linaro.org/landing-teams/working/arm/kernel-release.git/commit/?h=latest-armlt&id=9a93df172b2987c5a8e0efcefb2abdfebd1a3d68
https://git.linaro.org/landing-teams/working/arm/kernel-release.git/commit/?h=latest-armlt&id=15283f7be4b1e586702551e85b4caf06531ac2fc

Best regards,
Liviu

> 

> > 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

> 

> Having a way to set the default display resolution in QEMU would be

> nice. I've hacked around that when using virgl.

> 

> > 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.

> 

> LVDS does. VGA doesn't.

> 

> Rob


-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij July 29, 2018, 7:36 p.m. | #6
On Tue, Jul 17, 2018 at 4:02 PM Rob Herring <robh@kernel.org> wrote:
> On Tue, Jul 17, 2018 at 1:47 AM Linus Walleij <linus.walleij@linaro.org> wrote:

> > On Tue, Jul 17, 2018 at 12:50 AM Rob Herring <robh@kernel.org> wrote:

> > > On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij <linus.walleij@linaro.org> wrote:


> > > 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.

>

> It's not a panel either. A connector is something with variable

> resolution. A panel is fixed resolution. Which do you want?


OK I get it, I think... it makes a lot of sense.

For an emulated machine it's pretty much up to the sophistication
of the emulation. But variable is the best answer I assume.

> > 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.

>

> Because you have to set the resolution on the kernel command line? I'm

> open to having a default resolution for the connector in DT.


OK seems like that old virtual encoder that Liviu dug up is something
we should dust off and use then.

> > 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.

>

> So putting *anything* in DT is a lie...


The virtual encoder seems like telling the truth so I should
work on that.

> Having a way to set the default display resolution in QEMU would be

> nice. I've hacked around that when using virgl.


QEMU is pretending to not provide a resolution, but
an emulated monitor identified over I2C with EDID.

For the Vexpress emulation we connected the SII9022
DVI encoder hw/display/sii9022.c to the QEMU DDC/EDID
channel provider in hw/i2c/i2c-ddc.c.

This thing provides a conjured EDID blob to the DRM
EDID logic when using Linux.

It currently returns a simple 21" LCD VGA monitor probably
resulting in 1024x768 resolution.

By extending and refactoring this code, we could provide
a more ealborate "monitor" down to the emulator. The type of
monitor implies the resolution.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt
new file mode 100644
index 000000000000..193d24ebe052
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/video-graphics-array.txt
@@ -0,0 +1,21 @@ 
+Video Graphics Array
+
+This binding is for simple panels using the standardized VGA resolutions
+defined by de facto standards beginning with the IBM PS/2 in 1987.
+
+Required properties:
+- compatible: should be "video-graphics-array"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Example:
+
+panel {
+	compatible = "video-graphics-array";
+	port {
+		vga_panel_in: endpoint {
+			remote-endpoint = <&foo>;
+		};
+	};
+};
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..db4db5a3f75e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2069,6 +2069,69 @@  static const struct panel_desc winstar_wf35ltiacd = {
 	.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct drm_display_mode video_graphics_array_modes[] = {
+	{
+		/*
+		 * This is the most standardized "vanilla" VGA mode there is:
+		 * 640x480 @ 60 Hz
+		 */
+		.clock = 27175,
+		.hdisplay = 640,
+		.hsync_start = 640 + 16,
+		.hsync_end = 640 + 16 + 96,
+		.htotal = 640 + 16 + 96 + 48,
+		.vdisplay = 480,
+		.vsync_start = 480 + 10,
+		.vsync_end = 480 + 10 + 2,
+		.vtotal = 480 + 10 + 2 + 33,
+		.vrefresh = 60,
+		.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+	},
+	{
+		/* SVGA 800x600 @60 Hz */
+		.clock = 40000,
+		.hdisplay = 800,
+		.hsync_start = 800 + 40,
+		.hsync_end = 800 + 40 + 128,
+		.htotal = 800 + 40 + 128 + 88,
+		.vdisplay = 600,
+		.vsync_start = 600 + 1,
+		.vsync_end = 600 + 1 + 4,
+		.vtotal = 600 + 1 + 4 + 23,
+		.vrefresh = 60,
+		.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+	},
+	{
+		/* XGA 1024x768 @60 Hz */
+		.clock = 65000,
+		.hdisplay = 1024,
+		.hsync_start = 1024 + 24,
+		.hsync_end = 1024 + 24 + 136,
+		.htotal = 1024 + 24 + 136 + 160,
+		.vdisplay = 768,
+		.vsync_start = 768 + 3,
+		.vsync_end = 768 + 3 + 6,
+		.vtotal = 768 + 3 + 6 + 29,
+		.vrefresh = 60,
+		.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+	},
+};
+
+static const struct panel_desc video_graphics_array = {
+	.modes = video_graphics_array_modes,
+	.num_modes = ARRAY_SIZE(video_graphics_array_modes),
+	.bpc = 8,
+	/*
+	 * Some typical 4:3 aspect ratio VGA monitor surely has these dimensions
+	 * of 40x30 mm.
+	 */
+	.size = {
+		.width = 400,
+		.height = 300,
+	},
+	.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct of_device_id platform_of_match[] = {
 	{
 		.compatible = "ampire,am-480272h3tmqw-t01h",
@@ -2286,6 +2349,9 @@  static const struct of_device_id platform_of_match[] = {
 	}, {
 		.compatible = "winstar,wf35ltiacd",
 		.data = &winstar_wf35ltiacd,
+	}, {
+		.compatible = "video-graphics-array",
+		.data = &video_graphics_array,
 	}, {
 		/* sentinel */
 	}