Update the panel to allow setting the rotation value in device tree.
Tested on an Odroid Go Advance, where the panel is by default rotated 270
degrees.

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/SN6PR06MB534253E1CFDEA6917230F57BA57A9@SN6PR06MB5342.namprd06.prod.outlook.com

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/panel/panel-sitronix-st7701.c:42: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst

Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210602143300.2330146-22-lee.jones@linaro.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210602143300.2330146-23-lee.jones@linaro.org

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c:33: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Eric Anholt <eric@anholt.net>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210602143300.2330146-21-lee.jones@linaro.org

The PM Runtime docs specifically call out the need to call
pm_runtime_dont_use_autosuspend() in the remove() callback if
pm_runtime_use_autosuspend() was called in probe():

> Drivers in ->remove() callback should undo the runtime PM changes done
> in ->probe(). Usually this means calling pm_runtime_disable(),
> pm_runtime_dont_use_autosuspend() etc.

We should do this. This fixes a warning splat that I saw when I was
testing out the panel-simple's remove().

Fixes: 3235b0f2 ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210517130450.v7.1.I9e947183e95c9bd067c9c1d51208ac6a96385139@changeid

The dev_info():s in the DSI driver are very talkative,
depromote these to dev_dbg().

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210313230913.4108256-1-linus.walleij@linaro.org

It doesn't make sense to go out to the bus and read the EDID over and
over again. Let's cache it and throw away the cache when we turn power
off from the panel. Autosuspend means that even if there are several
calls to read the EDID before we officially turn the power on then we
should get good use out of this cache.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.18.If050957eaa85cf45b10bcf61e6f7fa61c9750ebf@changeid

I don't believe that it ever makes sense to read the EDID when a panel
is not powered and the powering on of the panel is the job of
prepare(). Let's make sure that this happens before we try to read the
EDID. We use the pm_runtime functions directly rather than directly
calling the normal prepare() function because the pm_runtime functions
are definitely refcounted whereas it's less clear if the prepare() one
is.

NOTE: I'm not 100% sure how EDID reading was working for folks in the
past, but I can only assume that it was failing on the initial attempt
and then working only later. This patch, presumably, will fix that. If
some panel out there really can read the EDID without powering up and
it's a big advantage to preserve the old behavior we can add a
per-panel flag. It appears that providing the DDC bus to the panel in
the past was somewhat uncommon in any case.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.17.Ibd31b8f7c73255d68c5c9f5b611b4bfaa036f727@changeid

As of commit 5186421c ("drm: Introduce epoch counter to
drm_connector") the drm_get_edid() function calls
drm_connector_update_edid_property() for us. There's no reason for us
to call it again.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.16.Icb581b0273d95cc33ca38676c61ae6d7d2e75357@changeid

When I added support for the hpd-gpio to simple-panel in commit
48834e60 ("drm/panel-simple: Support hpd-gpios for delaying
prepare()"), I added a special case to handle a circular dependency I
was running into on the ti-sn65dsi86 bridge chip. On my board the
hpd-gpio is actually provided by the bridge chip. That was causing
some circular dependency problems that I had to work around by getting
the hpd-gpio late.

I've now reorganized the ti-sn65dsi86 bridge chip driver to be a
collection of sub-drivers. Now the GPIO part can probe separately and
that breaks the chain. Let's get rid of the old code to clean things
up.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.10.I40eeedc23459d1e3fc96fa6cdad775d88c6e706c@changeid

In commit 3235b0f2 ("drm/panel: panel-simple: Use runtime pm to
avoid excessive unprepare / prepare") we started using pm_runtime, but
my patch neglected to add the proper pm_runtime_disable(). Doh! Add
them now.

Fixes: 3235b0f2 ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare")
Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.1.I9e6af2529d6c61e5daf86a15a1211121c5223b9a@changeid

Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms before the panel will assert HPD
(AKA "panel ready"). The above means that we should avoid turning a
panel off if we're going to turn it on again shortly.

The above becomes a problem when we want to read the EDID of a
panel. The way that ordering works is that userspace wants to read the
EDID of the panel _before_ fully enabling it so that it can set the
initial mode correctly. However, we can't read the EDID until we power
it up. This leads to code that does this dance (like
ps8640_bridge_get_edid()):

1. When userspace requests EDID / the panel modes (through an ioctl),
   we power on the panel just enough to read the EDID and then power
   it off.
2. Userspace then turns the panel on.

There's likely not much time between step #1 and #2 and so we want to
avoid powering the panel off and on again between those two steps.

Let's use Runtime PM to help us. We'll move the existing prepare() and
unprepare() to be runtime resume() and runtime suspend(). Now when we
want to prepare() or unprepare() we just increment or decrement the
refcount. We'll default to a 1 second autosuspend delay which seems
sane given the typical delays we see for panels.

A few notes:
- It seems the existing unprepare() and prepare() are defined to be
  no-ops if called extra times. We'll preserve that behavior but may
  try to remove it in a future patch.
- This is a slight change in the ABI of simple panel. If something was
  absolutely relying on the unprepare() to happen instantly that
  simply won't be the case anymore. I'm not aware of anyone relying on
  that behavior, but if there is someone then we'll need to figure out
  how to enable (or disable) this new delayed behavior selectively.
- In order for this to work we now have a hard dependency on
  "PM". From memory this is a legit thing to assume these days and we
  don't have to find some fallback to keep working if someone wants to
  build their system without "PM".

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.7.I9e8bd33b49c496745bfac58ea9ab418bd3b6f5ce@changeid

Fix the following coccicheck warning:
drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:217:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:189:8-16: WARNING:
use scnprintf or sprintf

Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1617069288-8317-1-git-send-email-tiantao6@hisilicon.com

Disable TE for Droid 4 panel, since implementation is currently
broken. Also disable it for N950 panel, which is untested.

Reported-by: Tony Lindgren <tony@atomide.com>
Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Fixes: 4c1b935f ("drm/omap: dsi: move TE GPIO handling into core")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210227214542.99961-1-sebastian.reichel@collabora.com

Panel power sequence says timing T8 (time from link idle to turn on
the backlight) should be at least 50 ms.  This is what the .enable
delay in simple-panel is for, so set it.  NOTE: this overlaps with the
80 ms .prepare_to_enable delay on purpose.  The data sheet says that
at least 80 ms needs to pass between HPD going high and turning on the
backlight and that at least 50 ms needs to pass between the link idle
and the backlight going on.  Thus it works like this on the system in
front of me:
* In bridge chip pre_enable call drm_panel_prepare()
* drm_panel_prepare() -> panel_simple_prepare()
* Wait for HPD GPIO to go high.
* Start counting for 80 ms (store in prepared_time)
* In bridge chip enable, train link then call drm_panel_enable()
* drm_panel_enable() -> panel_simple_enable()
* panel_simple_enable() does hardcoded 50 ms delay then enforces 80 ms
  from HPD going high (in case the bridge took less than 30 ms to
  enable / link train).
* drm_panel_enable() -> backlight_enable().

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210222081716.1.I1a45aece5d2ac6a2e73bbec50da2086e43e0862b@changeid

This panel is quite similar to the similarly named N116BGE panel (the
nominal timings are, in fact identical).  However, let's add a new
entry because the full range of clocks listed for N116BGE aren't
supported for N116BCA-EA1, at least according to the datasheet.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.5.I3c01f3aab8335cb509da7009d8938c1a27a266dc@changeid

On an Innolux N116BCA panel that I have in front of me, sometimes HPD
simply doesn't assert no matter how long you wait for it. As per the
very wise advice of The IT Crowd ("Have you tried turning it off and
on again?") it appears that power cycling is enough to kick this panel
back into a sane state.

>From tests on this panel, it appears that leaving it powered off for a
while stimulates the problem. Adding a 6 second sleep at the start of
panel_simple_prepare_once() makes it happen fairly reliably and, with
this delay, I saw up to 3 retries needed sometimes. Without the 6
second sleep, however, the panel came up much more reliably the first
time or after only 1 retry.

While it's unknown what the problems are with this panel (and probably
the hardware should be debugged), adding a few retries to the power on
routine doesn't seem insane. Even if this panel's problems are
attributed to the fact that it's pre-production and/or can be fixed,
retries clearly can help in some cases and really don't hurt.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.3.I6916959daa7c5c915e889442268d23338de17923@changeid

If a panel has an hpd_absent_delay specified then we know exactly how
long the maximum time is before HPD must be asserted.  That means we
can use it as a timeout for polling the HPD pin instead of using an
arbitrary timeout.  This is especially useful for dealing with panels
that periodically fail to power on and need to be retried.  We can
detect the problem sooner.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.2.I183b1817610d7a82fdd3bc852e96d2985df9623f@changeid

If the HPD signal never asserts in panel_simple_prepare() and we
return an error, we should unset the enable GPIO and disable the
regulator to make it consistent for the caller.

At the moment I have some hardware where HPD sometimes doesn't assert.
Obviously that needs to be debugged, but this patch makes it so that
if I add a retry that I can make things work.

Fixes: 48834e60 ("drm/panel-simple: Support hpd-gpios for delaying prepare()")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.1.I33fcbd64ab409cfe4f9491bf449f51925a4d3281@changeid

A recent patch renaming MIPI_DSI_MODE_EOT_PACKET to
MIPI_DSI_MODE_NO_EOT_PACKET brought to light the
misunderstanding in the current MCDE driver and all
its associated panel drivers that MIPI_DSI_MODE_EOT_PACKET
would mean "use EOT packet" when in fact it means the
reverse.

Fix it up by implementing the flag right in the MCDE
DSI driver and remove the flag from panels that actually
want the EOT packet.

Suggested-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Fixes: 5fc537bf ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Fixes: 899f24ed ("drm/panel: Add driver for Novatek NT35510-based panels")
Fixes: ac1d6d74 ("drm/panel: Add driver for Samsung S6D16D0 panel")
Fixes: 435e06c0 ("drm/panel: s6e63m0: Add DSI transport")
Fixes: 8152c2bf ("drm/panel: Add driver for Sony ACX424AKP panel")
Link: https://patchwork.freedesktop.org/patch/msgid/20210304004138.1785057-1-linus.walleij@linaro.org

The panel is able to work when dsi clock is non-continuous, thus
the system power consumption can be reduced using such feature.

Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags.

Also the flag actually becomes necessary after
commit c6d94e37 ("drm/bridge/synopsys: dsi: add support for non-continuous HS clock")
and without it the panel only emits stripes instead of output.

Fixes: c6d94e37 ("drm/bridge/synopsys: dsi: add support for non-continuous HS clock")
Cc: stable@vger.kernel.org # 5.10+
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Christopher Morgan <macromorgan@hotmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210206135020.1991820-1-heiko@sntech.de


Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Use getter and setter functions, for platform_device structures and a
mipi_dsi_device structure.

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209211304.1261740-1-Julia.Lawall@inria.fr

The Innolux n116bge panel has an eDP connector and 3*6 bits bus format.

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210109130951.3448435-1-heiko@sntech.de

The "max-brightness" is a standard backlight property that
we need to support for the Samsung GT-I8190 Golden because
the display will go black if we crank up the brightness
too high.

As the platform needs this ability to give picture this is
a regression fix along with the addition of the property
to the GT-I8190 device tree.

Cc: Stephan Gerhold <stephan@gerhold.net>
Fixes: 9c3f0a0d ("drm/panel: s6e63m0: Implement 28 backlight levels")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201214222210.238081-1-linus.walleij@linaro.org

Drop unneeded includes.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-74-tomi.valkeinen@ti.com

Add a panel database to the driver instead of reading propertes from DT
data. This is similar to panel-simple, and I believe it's more future
safe way to handle the panels.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-73-tomi.valkeinen@ti.com

We have a useless 'if' in the dsicm_bl_update_status(), a left over from
the conversion to DRM model. Drop the if.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-72-tomi.valkeinen@ti.com

Set the column & page address once during setup, instead of relying the
DSI host driver to set those.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-61-tomi.valkeinen@ti.com

Simplify the code by moving code from _dsicm_enable_te() into
dsicm_power_on().

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-57-tomi.valkeinen@ti.com

Use the common MIPI_DCS_GET_ERROR_COUNT_ON_DSI define instead of
driver's own.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-56-tomi.valkeinen@ti.com

The panel driver is no longer using any OMAP specific APIs, so
let's move it into the generic panel directory.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-40-tomi.valkeinen@ti.com

There is a copy and paste bug so it didn't return the correct error
code.

Fixes: b2152121 ("drm: panel: add Khadas TS050 panel driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/X9NEfmgGilaXJs2R@mwanda

The panel uses the same driver IC and has the same resolution but a
slightly different default mode. It seems it can work with the same
init sequence.

Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/8855b4fc681c675182ce33e0a6cba46bab2bac43.1605688147.git.agx@sigxcpu.org

This can be used to use different modes for differnt panels via OF
device match.

Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/2580dba34c95a8159c1bdfd07604fbb8dbd0ad8c.1605688147.git.agx@sigxcpu.org

We've seen some (non permanent) burn in and bad white balance
on some of the panels. Adding this bit from a vendor supplied
sequence fixes it.

Fixes: 72967d56 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/8451831b60d5ecb73a156613d98218a31bd55680.1605688147.git.agx@sigxcpu.org

Less code and easier probe deferral debugging.

Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/36405038d93eb148f3e8ed8e5ea70de8e87afd78.1605688147.git.agx@sigxcpu.org

This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to work
with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
It provides a MIPI DSI interface to the host, a built-in LED backlight
and touch controller.

The init values was taken from the vendor source tree, comments were added to the
know values but most of the init table is undocumented.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
[narmstrong: call drm_panel_remove if mipi_dsi_attach fails]
Link: https://patchwork.freedesktop.org/patch/msgid/20201204081949.38418-3-narmstrong@baylibre.com

The DSI version of the panel behaved instable and close
scrutiny of the vendor driver from the Samsung
GT-S8190 shows a different initialization sequence for
the DSI mode panel than the DPI mode panel.

Make the initialization depend on whether we are in
DSI or DPI mode and handle the differences.

After this the panel on the GT-I8190 becomes much more
stable.

Also spell out some more custom DCS commands found in
the vendor source code to cut down a bit on magic
where we can.

Fixes: f0aee45f ("drm/panel: s6e63m0: Fix init sequence")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Stephan Gerhold <stephan@gerhold.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20201205122229.1952980-1-linus.walleij@linaro.org

I forgot to add these when posting up the support for BOE
NV110WTM-N61.  Add them now.

Fixes: a96ee0f6 ("drm: panel: simple: Add BOE NV110WTM-N61")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201201125554.v2.1.I8a7bfc0966e803ab91001c9e6d01a736950c4981@changeid

In commit 131f909a ("drm: panel: simple: Fixup the struct
panel_desc kernel doc") I transitioned the more deeply nested
kerneldoc comments into the inline style.  Apparently it is desirable
to continue the job and move _everything_ in this struct to inline.
Let's do it.

While doing this, we also add a short summary for the whole struct to
fix a warning when we run with extra warnings, AKA:
  scripts/kernel-doc -v -rst drivers/gpu/drm/panel/panel-simple.c

The warning was:
  drivers/gpu/drm/panel/panel-simple.c:42: warning: missing initial short description on line:
   * struct panel_desc

Suggested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201201125822.1.I3c4191336014bd57364309439e56f600c94bb12b@changeid

Add support for the BOE NV110WTM-N61 panel.  The EDID lists two modes
(one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of
them here.

Note that the panel datasheet requires 80 ms between HPD asserting and
the backlight power being turned on.  We'll use the new timing
constraints structure to do this cleanly.  This assumes that the
backlight will be enabled _after_ the panel enable finishes.  This is
how it works today and seems a sane assumption.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201109170018.v4.4.I71b2118dfc00fd7b43b02d28e7b890081c2acfa2@changeid