linux.git/drivers/gpu/drm/panel/panel-simple.c, branch v5.8

drm: panel: simple: Delay HPD checking on boe_nv133fhm_n61 for 15 ms

2020-07-26T16:53:56+00:00

On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
a small spike on the HPD line right when you power the panel on. The
picture looks something like this:

+--------------------------------------
|
|
|
Power ---+
+---
|
++ |
+----+| |
HPD -----+ +---------------------------+

So right when power is applied there's a little bump in HPD and then
there's small spike right before it goes low. The total time of the
little bump plus the spike was measured on one panel as being 8 ms
long. The total time for the HPD to go high on the same panel was
51.2 ms, though the datasheet only promises it is < 200 ms.

When asked about this glitch, BOE indicated that it was expected and
persisted until the TCON has been initialized.

If this was a real hotpluggable DP panel then this wouldn't matter a
whole lot. We'd debounce the HPD signal for a really long time and so
the little blip wouldn't hurt. However, this is not a hotpluggable DP
panel and the the debouncing logic isn't needed and just shows down
the time needed to get the display working. This is why the code in
panel_simple_prepare() doesn't do debouncing and just waits for HPD to
go high once. Unfortunately if we get unlucky and happen to poll the
HPD line right at the spike we can try talking to the panel before
it's ready.

Let's handle this situation by putting in a 15 ms prepare delay and
decreasing the "hpd absent delay" by 15 ms. That means:
* If you don't have HPD hooked up at all you've still got the
hardcoded 200 ms delay.
* If you've got HPD hooked up you will always wait at least 15 ms
before checking HPD. The only case where this could be bad is if
the panel is sharing a voltage rail with something else in the
system and was already turned on long before the panel came up. In
such a case we'll be delaying 15 ms for no reason, but it's not a
huge delay and I don't see any other good solution to handle that
case.

Even though the delay was measured as 8 ms, 15 ms was chosen to give a
bit of margin.

Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
Signed-off-by: Sam Ravnborg
Link: https://patchwork.freedesktop.org/patch/msgid/20200716132120.1.I01e738cd469b61fc9b28b3ef1c6541a4f48b11bf@changeid

drm/panel-simple: fix connector type for newhaven_nhd_43_480272ef_atxl

2020-06-21T07:49:53+00:00

Add connector type for newhaven_nhd_43_480272ef_atxl, as
drm_panel_bridge_add() requires connector type to be set.

Signed-off-by: Tomi Valkeinen 
Cc: stable@vger.kernel.org # v5.5+
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20200609102809.753203-1-tomi.valkeinen@ti.com

drm/panel-simple: fix connector type for LogicPD Type28 Display

2020-06-21T06:23:09+00:00

The LogicPD Type28 display used by several Logic PD products has not
worked since v5.6.

The connector type for the LogicPD Type 28 display is missing and
drm_panel_bridge_add() requires connector type to be set.

Signed-off-by: Adam Ford 
Fixes: 0d35408afbeb ("drm/panel: simple: Add Logic PD Type 28 display support")
Cc: Adam Ford 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.6+
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20200615131934.12440-1-aford173@gmail.com

drm/panel-simple: Support hpd-gpios for delaying prepare()

2020-05-09T20:11:45+00:00

People use panel-simple when they have panels that are builtin to
their device.  In these cases the HPD (Hot Plug Detect) signal isn't
really used for hotplugging devices but instead is used for power
sequencing.  Panel timing diagrams (especially for eDP panels) usually
have the HPD signal in them and it acts as an indicator that the panel
is ready for us to talk to it.

Sometimes the HPD signal is hooked up to a normal GPIO on a system.
In this case we need to poll it in the correct place to know that the
panel is ready for us.  In some system designs the right place for
this is panel-simple.

When adding this support, we'll account for the case that there might
be a circular dependency between panel-simple and the provider of the
GPIO.  The case this was designed for was for the "ti-sn65dsi86"
bridge chip.  If HPD is hooked up to one of the GPIOs provided by the
bridge chip then in our probe function we'll always get back
-EPROBE_DEFER.  Let's handle this by allowing this GPIO to show up
late if we saw -EPROBE_DEFER during probe.  NOTE: since the
gpio_get_optional() is used, if the "hpd-gpios" isn't there our
variable will just be NULL and we won't do anything in prepare().

Signed-off-by: Douglas Anderson 
Reviewed-by: Stephen Boyd 
Reviewed-by: Linus Walleij 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20200507143354.v5.3.I53fed5b501a31e7a7fa13268ebcdd6b77bd0cadd@changeid

panel: simple: Add BOE NV133FHM-N62

2020-05-09T19:57:50+00:00

All info I could find about this panel show that it behaves the same
as the BOE NV133FHM-N61.  However, it definitely appears to be a
unique panel because reading the EDID shows "NV133FHM-N62".  We'll add
a string match for the new panel but until we find something unique
about it we'll just point at the N61's structures.

Signed-off-by: Douglas Anderson 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20200508155859.3.I525ebd471f5340a6a369af7bde06ef04174d2f41@changeid

panel: simple: Fix size and bpp of BOE NV133FHM-N61

2020-05-09T19:57:02+00:00

The BOE NV133FHM-N61 is documented in the original commit to be a
13.3" panel, but the size listed in our struct doesn't match.
Specifically:

  math.sqrt(30.0 * 30.0 + 18.7 * 18.7) / 2.54 ==> 13.92

Searching around on the Internet shows that the size that was in the
structure was the "Outline Size", not the "Display Area".  Let's fix
it.

Also the Internet says that this panel supports 262K colors.  That's
6bpp, not 8bpp.

Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61")
Signed-off-by: Douglas Anderson 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20200508155859.1.I4d29651c0837b4095fb4951253f44036a371732f@changeid

drm/panel: panel-simple: fix AUO G101EVN010 connector/panel type

2020-05-04T19:44:27+00:00

The AUO G101EVN010 is a 18-bit LVDS panel, not a parallel panel, as
indicated by the current bus_format.

Fix the bus_format to MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, and also set the
connector_type to LVDS.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Sam Ravnborg 
[updated patch subject]
Link: https://patchwork.freedesktop.org/patch/msgid/20200417114043.25381-1-tomi.valkeinen@ti.com

panel: simple: Add Ivo M133NWF4 R0

2020-04-25T17:54:50+00:00

The InfoVision Optoelectronics M133NWF4 R0 panel is a 13.3" 1920x1080
eDP panel, add support for it in panel-simple.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20200420215728.1927434-2-bjorn.andersson@linaro.org

panel: simple: Add BOE NV133FHM-N61

2020-04-25T15:41:43+00:00

The BOE NV133FHM-N61 panel is a 13.3" 1920x1080 eDP panel, add support
for it in panel-simple.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Sam Ravnborg 
[add boe_nv133fhm_n61_modes in alphabetical order]
Link: https://patchwork.freedesktop.org/patch/msgid/20200420215742.1927498-2-bjorn.andersson@linaro.org

drm: panel: Set connector type for LP120UP1

2020-04-25T14:43:04+00:00

The LP120UP1 is a eDP panel, set the connector type accordingly.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20200416164404.2418426-1-enric.balletbo@collabora.com