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>

If there is another bridge after analogix_dp, then the connector object
should not be created. This fixes following timeouts on Exynos5420-based
Chromebook2 Peach-PIT board during boot:

exynos-dp 145b0000.dp-controller: AUX CH cmd reply timeout!
exynos-dp 145b0000.dp-controller: AUX CH enable timeout!
exynos-dp 145b0000.dp-controller: AUX CH enable timeout!
exynos-dp 145b0000.dp-controller: AUX CH enable timeout!
exynos-dp 145b0000.dp-controller: AUX CH enable timeout!
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305085741.18896-4-m.szyprowski@samsung.com

Enabling runtime power management early in analogix_dp_bind() causes following
kernel NULL pointer dereference:

Unable to handle kernel NULL pointer dereference at virtual address 000007d8
pgd = 28ffa2e4
[000007d8] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 6 PID: 69 Comm: kworker/6:1 Not tainted 4.16.0-rc1-00062-ge25751974ba8 #3622
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
PC is at analogix_dp_resume+0x8/0xc0
LR is at pm_generic_runtime_resume+0x2c/0x38
pc : [<c0531b98>]    lr : [<c0543fec>] psr: a0000113
sp : ee13fbd8  ip : 0000001a  fp : 00000001
r10: ee0eb080  r9 : c0552bd8  r8 : c0fb1d98
r7 : eebb1010  r6 : eeae9808  r5 : 00000000  r4 : d4850415
r3 : ee0ed010  r2 : b2d05e00  r1 : 00000000  r0 : 00000000
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment none
Control: 10c5387d  Table: 2000406a  DAC: 00000051
Process kworker/6:1 (pid: 69, stack limit = 0x913205b4)
Stack: (0xee13fbd8 to 0xee140000)
...
[<c0531b98>] (analogix_dp_resume) from [<c0543fec>] (pm_generic_runtime_resume+0x2c/0x38)
[<c0543fec>] (pm_generic_runtime_resume) from [<c054ffb4>] (__genpd_runtime_resume+0x2c/0x8c)
[<c054ffb4>] (__genpd_runtime_resume) from [<c0552d24>] (genpd_runtime_resume+0x14c/0x258)
[<c0552d24>] (genpd_runtime_resume) from [<c0547798>] (__rpm_callback+0x134/0x214)
[<c0547798>] (__rpm_callback) from [<c0547898>] (rpm_callback+0x20/0x80)
[<c0547898>] (rpm_callback) from [<c0546ff4>] (rpm_resume+0x3a0/0x734)
[<c0546ff4>] (rpm_resume) from [<c05475ec>] (__pm_runtime_resume+0x64/0x9c)
[<c05475ec>] (__pm_runtime_resume) from [<c053b95c>] (__device_attach+0x8c/0x134)
[<c053b95c>] (__device_attach) from [<c053ad08>] (bus_probe_device+0x88/0x90)
[<c053ad08>] (bus_probe_device) from [<c05390d0>] (device_add+0x3a8/0x580)
[<c05390d0>] (device_add) from [<c06764c4>] (i2c_register_adapter+0xd4/0x3ec)
[<c06764c4>] (i2c_register_adapter) from [<c05321c8>] (analogix_dp_bind+0x2a0/0x410)
[<c05321c8>] (analogix_dp_bind) from [<c0528e90>] (exynos_dp_bind+0x9c/0x12c)
[<c0528e90>] (exynos_dp_bind) from [<c0535bc4>] (component_bind_all+0xfc/0x258)
[<c0535bc4>] (component_bind_all) from [<c0522ee8>] (exynos_drm_bind+0x15c/0x28c)
[<c0522ee8>] (exynos_drm_bind) from [<c0536378>] (try_to_bring_up_master+0x1b8/0x29c)
[<c0536378>] (try_to_bring_up_master) from [<c05364fc>] (component_add+0xa0/0x170)
[<c05364fc>] (component_add) from [<c0528fe4>] (exynos_dp_probe+0x64/0xb8)
[<c0528fe4>] (exynos_dp_probe) from [<c053debc>] (platform_drv_probe+0x50/0xb0)
[<c053debc>] (platform_drv_probe) from [<c053bd18>] (driver_probe_device+0x2b8/0x4a0)
[<c053bd18>] (driver_probe_device) from [<c0539e4c>] (bus_for_each_drv+0x44/0x8c)
[<c0539e4c>] (bus_for_each_drv) from [<c053b970>] (__device_attach+0xa0/0x134)
[<c053b970>] (__device_attach) from [<c053ad08>] (bus_probe_device+0x88/0x90)
[<c053ad08>] (bus_probe_device) from [<c053b258>] (deferred_probe_work_func+0x3c/0x168)
[<c053b258>] (deferred_probe_work_func) from [<c014352c>] (process_one_work+0x1d0/0x7bc)
[<c014352c>] (process_one_work) from [<c0143b84>] (worker_thread+0x34/0x4dc)
[<c0143b84>] (worker_thread) from [<c014a30c>] (kthread+0x128/0x164)
[<c014a30c>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
Exception stack(0xee13ffb0 to 0xee13fff8)
ffa0:                                     00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e2800e37 eafee601 e92d4070 e1a05000 (e59067d8)
---[ end trace bf6046013df7cab2 ]---

This oops happens, because analogix_dp_bind() calls drm_dp_aux_register()
which registers i2c adapter. I2C core tries to runtime get i2c host
device during registration. This ends in analogix_dp_resume(), but dp
context is NULL there. dp context is set in exynos_dp_bind() after
executing analogix_dp_bind(). Fix this issue by postponing enabling runtime
power management after drm_dp_aux_register().
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305085741.18896-3-m.szyprowski@samsung.com

The bridge does not need to be powered in analogix_dp_bind(), so
remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp()
as well as their power-off counterparts.

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>
[the patch originally just removed the power_on portion, seanpaul removed
the power off code as well as improved the commit message]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180305085741.18896-2-m.szyprowski@samsung.com

Most of the time we only need the dma addresses.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NRoger He <Hongbo.He@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-2-christian.koenig@amd.com
Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-3-christian.koenig@amd.com
Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-4-christian.koenig@amd.com
Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-5-christian.koenig@amd.com
Link: https://patchwork.freedesktop.org/patch/msgid/BN6PR12MB18262C0DE9B5F07B9A42EAE7F2C60@BN6PR12MB1826.namprd12.prod.outlook.com

Unpin the GEM object only after freeing the sg table.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NRoger He <Hongbo.He@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180227115000.4105-1-christian.koenig@amd.com

Reject requests to add properties/enums with an overly long name.
Previously we would have just silently truncated the string and exposed
it userspace.

v2: drm_property_create() returns a pointer
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302140300.31110-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>