| Message ID | 20180716092339.9736-1-linus.walleij@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | drm/panel: simple: Support simple VGA panels | expand |
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
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
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
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
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
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
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 */ }
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