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

drm/panel: Fix auo, kd101n80-45na horizontal noise on edges of panel

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

Fine tune the HBP and HFP to avoid the dot noise on the left and right edges.

Signed-off-by: Jitao Shi 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20200714123332.37609-1-jitao.shi@mediatek.com

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

drivers: drm: panel: Add ASUS TM5P5 NT35596 panel driver

2020-05-07T19:54:06+00:00

This adds support for TMP5P5 NT35596 1080x1920 video
mode panel that can be found on some Asus Zenfone 2
Laser (Z00T) devices.

This panel seems to only be found in this device
and we have no straightforward way of actually
getting the correct model number, as no schematics
are released publicly.

Signed-off-by: Konrad Dybcio 
Signed-off-by: Sam Ravnborg 
[fixed checkpatch warnings]
Link: https://patchwork.freedesktop.org/patch/msgid/20200506210957.344590-2-konradybcio@gmail.com

drm: panel: add MODULE_LICENSE to panel-visionox-rm69299.c

2020-05-07T19:41:33+00:00

Add MODULE_LICENSE() to the panel-visionox-rm69299 driver
to fix a build warning.

WARNING: modpost: missing MODULE_LICENSE() in drivers/gpu/drm/panel/panel-visionox-rm69299.o

Signed-off-by: Randy Dunlap 
Fixes: c7f66d32dd43 ("drm/panel: add support for rm69299 visionox panel")
Cc: Harigovindan P 
Cc: Matthias Kaehlcke 
Cc: Thierry Reding 
Cc: Sam Ravnborg 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sam Ravnborg 
[added fixes: tag]
Link: https://patchwork.freedesktop.org/patch/msgid/bbb7b3b3-9968-9a1f-8ef6-2e8e3be998f6@infradead.org

drm/panel: add support for rm69299 visionox panel

2020-05-06T18:54:47+00:00

Add support for Visionox rm69299 panel.

Signed-off-by: Harigovindan P 
Reviewed-by: Matthias Kaehlcke 
Signed-off-by: Sam Ravnborg 
[fix checkpatch warnings, added sentinel ]
Link: https://patchwork.freedesktop.org/patch/msgid/20200421045508.21137-2-harigovi@codeaurora.org