'drm_vblank_init()' can fail. So handle this (unlikely) error.

Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6cbf3d70ac3904489c7194c895225c4103aebb96.1520885192.git.christophe.jaillet@wanadoo.fr

Put an empty line between the variable declarations and the code, and
use tabs for alignment.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305144919.2881-3-ville.syrjala@linux.intel.comAcked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch adds support for AUO G104SN02 V2 800x600 10.4" panel to DRM
simple panel driver.
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: NStefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1513430016.1930.4.camel@googlemail.com

Fixes the following sparse warnings:

drivers/gpu/drm/panel/panel-ilitek-ili9322.c:182:12: warning:
 symbol 'ili9322_inputs' was not declared. Should it be static?
drivers/gpu/drm/panel/panel-ilitek-ili9322.c:343:28: warning:
 symbol 'ili9322_regmap_config' was not declared. Should it be static?

Also change ili9322_inputs to 'const char * const' to avoid
chackpatch warning.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1514948938-19996-1-git-send-email-weiyongjun1@huawei.com

emtrion is a system integrator and manufacturer of embedded systems.

Website: https://www.emtrion.deSigned-off-by: NJan Tuerk <jan.tuerk@emtrion.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123125600.41562-3-jan.tuerk@emtrion.com

Add SPDX identifiers to OriseTech OTM8009a panel driver.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180119110516.4916-1-philippe.cornu@st.com

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f80a5dd350b057d925d36f5857b5724c88da50df.1516636902.git.baruch@tkos.co.il

This adds support for the Kaohsiung Opto-Electronics.,
TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be
supported by the simple panel driver.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1517766571-409-5-git-send-email-jagan@amarulasolutions.com

Add support for the optional power-supply.

Note: A "dummy regulator" is returned by devm_regulator_get()
if the optional regulator is not present in the device tree,
simplifying the source code when enabling/disabling the regulator.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NYannick Fertré <yannick.fertre@st.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205094532.23547-3-philippe.cornu@st.com

Some boards use a dedicated voltage regulator for this panel.
Add & document this related optional power-supply property.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NYannick Fertré <yannick.fertre@st.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205094532.23547-2-philippe.cornu@st.com

Convert the sharp lq123p1jx31 from using a fixed mode to specifying a
display timing with min/typ/max values. This allows us to capture the
timings set forth in the datasheet as well as the additional values that
we've cleared with the display vendor to avoid interference with the
digitizer on the Samsung Chromebook Plus (kevin).

A follow-on patch will specify the override mode for kevin devices.

Changes in v2:
 - None
Changes in v3:
 - None

Cc: Doug Anderson <dianders@chromium.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Tested-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208174855.55620-6-seanpaul@chromium.org

In preparation for a new subnode section in a follow-on patch, add
explicit headings to the existings sections for simple-panel.

Changes in v2:
 - Added
Changes in v3:
 - None

Cc: Doug Anderson <dianders@chromium.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208174855.55620-3-seanpaul@chromium.org

Add a note in the documentation explaining when it's appropriate to use
the display-timings subnode on its own, as well as the preferred name to
use (panel-timing).

Changes in v3:
 - Added

Cc: Doug Anderson <dianders@chromium.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208174855.55620-2-seanpaul@chromium.org

This patch adds Raydium Semiconductor Corporation RM68200 5.5" 720x1280
TFT LCD panel driver (MIPI-DSI video mode).
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302153222.4377-3-philippe.cornu@st.com

The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
TFT LCD panel connected using a MIPI-DSI video interface.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302153222.4377-2-philippe.cornu@st.com

This fixes bad color output.  When I was first testing the device I
had the DPI hardware set to 666 mode, but apparently in the refactor
to use the bus_format information from the panel driver, I failed to
actually update the panel.
Signed-off-by: NEric Anholt <eric@anholt.net>
Fixes: e8b6f561 ("drm/panel: simple: Add the 7" DPI panel from Adafruit")
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180309233332.1769-1-eric@anholt.net

Using the hint from the plane state, we turn on the background color
to avoid display corruption from planes blending with the background.

Changes from v1:
 - Use needs_bg_fill from plane state
Signed-off-by: NStefan Schake <stschake@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1520556817-97297-5-git-send-email-stschake@gmail.com

We need to reference it from the CRTC to make a decision for enabling
background color fill.
Signed-off-by: NStefan Schake <stschake@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1520556817-97297-4-git-send-email-stschake@gmail.com

Considering a single plane only, we have to enable background color
when the plane has an alpha format and could be blending from the
background or when it doesn't cover the entire screen.

Changes from v1:
 - Drop unrelated change
 - Move needs_bg_fill to plane state
Signed-off-by: NStefan Schake <stschake@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1520556817-97297-3-git-send-email-stschake@gmail.com

Alpha formats in DRM are assumed to be premultiplied, so we should be
setting the PREMULT bit in the plane configuration for HVS.

Changes from v1:
 - Use correct has_alpha
Signed-off-by: NStefan Schake <stschake@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1520556817-97297-2-git-send-email-stschake@gmail.com

Instead of using timer and spinlocks, use delayed_work and
mutexes for rockchip psr. This allows us to make blocking
calls when enabling/disabling psr (which is sort of important
given we're talking over dpcd to the display).

Cc: Caesar Wang <wxt@rock-chips.com>
Cc: 征增 王 <wzz@rock-chips.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305222324.5872-3-enric.balletbo@collabora.com

There's a race between when bridge_disable and when vop_crtc_disable
are called. If the flush timer triggers a new psr work between these,
we will operate eDP without power shutdowned by bridge_disable. In this
case, moving activate/deactivate to enable/disable bridge to avoid it.

Cc: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Nzain wang <wzz@rock-chips.com>
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305222324.5872-2-enric.balletbo@collabora.com

The HDMI vpll clock should be enabled when bind() is called. So move the
clk_prepare_enable of that clock to bind() function and add the missing
clk_disable_unprepare() required in error handling path and unbind().

Fixes: 12b9f204 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302175757.28192-5-enric.balletbo@collabora.com

In bind the clk_prepare_enable of the HDMI pclk is called before adding the
i2c_adapter. So it should be the other way around in unbind, first remove
the i2c_adapter and then call the clk_disable_unprepare.

Fixes: 412d4ae6 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302175757.28192-4-enric.balletbo@collabora.com

Add missing error handling in bind().

Fixes: 412d4ae6 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
[moved clk_disable_unprepare reordering in unbind to separate patch]
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302175757.28192-3-enric.balletbo@collabora.com

In bind()'s error handling path call destroy functions instead of
cleanup functions for encoder and connector and reorder to match how is
called in bind().

In unbind() call the connector and encoder destroy functions.
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302175757.28192-2-enric.balletbo@collabora.com

Replace the ad-hoc iturbt_709 property with the new standard
COLOR_ENCODING property. Compiles, but not tested.

v2: Fix typos (Ilia)

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: nouveau@lists.freedesktop.org
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220134816.15229-1-ville.syrjala@linux.intel.comReviewed-by: NIlia Mirkin <imirkin@alum.mit.edu>
Acked-by: Ben Skeggs <bskeggs@redhat.com> #irc

We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.

This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.

Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP, Versatile and
Integrator/CP we get a nice console as default with this code.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180307215819.15814-1-linus.walleij@linaro.org

The following happens when connection a DVI output driven
from the SiI9022 using a DVI-to-VGA adapter plug:

i2c i2c-0: sendbytes: NAK bailout.
i2c i2c-0: sendbytes: NAK bailout.

Then no picture. Apparently the I2C engine inside the SiI9022
is not smart enough to try to fall back to DDC I2C. Or the
vendor have not integrated the electronics properly. I don't
know which one it is.

After this, the I2C bus seems stalled and the first attempt to
read the status register fails, and the code returns with
negative return value, and the display fails to initialized.

Instead, retry status readout five times and continue even
if this fails.

Tested on the ARM Versatile Express with a DVI-to-VGA
connector, it now gives picture.

Introduce a helper struct device *dev variable to make
the code more readable.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305101702.13441-1-linus.walleij@linaro.org

We want to cut down the default bpp to 16 on the RealView so
we can have a 1024x768 framebuffer console by default. The
memory bandwidth limitations makes this not work with the
PL111 default of 32bpp.

This builds on top of the earlier patches making the
framebuffer default bpp a per-variant variable.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302090948.6399-4-linus.walleij@linaro.org

The PL110, Integrator and Versatile boards strongly prefer to
use 16 BPP even if other modes are supported, both to keep down
memory consumption and also to easier find a good match to
supported resolutions with consideration taken to the memory
bandwidth of the platforms.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302090948.6399-2-linus.walleij@linaro.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180307084316.23623-1-linus.walleij@linaro.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180307084316.23623-1-linus.walleij@linaro.org

This fixes up the .mode_valid() vtable entry documentation
by copyediting the documentation from the .mode_valid()
documentation in the drm_modeset_helper_vtables.h file.

Fixes: 40275dc4 ("drm: simple_kms_helper: Add mode_valid() callback support")
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180227101109.6088-1-linus.walleij@linaro.org

It's better if we explain a bit that this pertains to
non-programmable VGA DAC bridges.
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302091426.8463-1-linus.walleij@linaro.org

Add reverse iterator for_each_oldnew_plane_in_state_reverse to
compliment the for_each_oldnew_plane_in_state way or reading plane
states.

The plane states are required to be read in reverse order for
amd drivers, cause the z order convention followed in linux is
opposite to how the planes are supposed to be presented to DC
engine, which is in common to both windows and linux.

V2: fix compile time errors due to -Werror flag.
Signed-off-by: NShirish S <shirish.s@amd.com>
Signed-off-by: NPratik Vishwakarma <Pratik.Vishwakarma@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1520392203-6885-1-git-send-email-shirish.s@amd.com

Pimp drm_property_type_valid() to check for more fails with the
property flags. Also make the check before adding the property,
and bail out if things look bad.

Since we're now chekcing for more than the type let's also
change the function name to drm_property_flags_valid().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-6-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The property flags are part of the uabi and we have 32 bits for them.
Pass them around as u32 internally as well, instead of a signed int.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-5-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DRM_MODE_PROP_PENDING is not used anywhere (except printed out
by libdrm proptest/modetest).

This seems to be yet another thing blindly copied from xrandr.
Quoting from the protocol spec:
"If 'pending' is TRUE, changes made to property values with
 RRChangeOutputProperty will be saved in the pending property value
 and be automatically copied to the current value on the next
 RRSetCrtcConfig request involving the named output. If 'pending' is
 FALSE, changes are copied immediately."

So it was some kind of early idea for atomic property updates.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-4-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Enum values >63 with a bitmask property is a programmer error. WARN
when someone is attempting this.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-3-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Trying to add enum values to non-enum/bitmask properties is a
programmer mistake. WARN to make sure the developers notice
their mistake.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-2-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the property already has the enum value WARN and bail.
Replacing enum values doesn't make sense to me.

Throw out the pointless list_empty() while at it.

Cc: Daniel Vetter <daniel@ffwll.ch>
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>