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>

Creating a property that doesn't have a name makes no sense to me. Don't
allow it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180302132544.12491-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
identified needing this workaround.
This patch adds the corresponding version to enable a single iteration for
this specific version.

Fixes: be41fc55 ("drm: bridge: dw-hdmi: Handle overflow workaround based on device version")
Acked-by: NArchit Taneja <architt@codeaurora.org>
[narmstrong: s/identifies/identified and rebased against Jernej's change]
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1519386277-25902-1-git-send-email-narmstrong@baylibre.com

Use positive logic for better readability. This also eliminates one
of_node_put() call, making the code shorter.
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NArchit Taneja <archit@cradlewise.com>
Link: https://patchwork.freedesktop.org/patch/msgid/61c56895d44117d80e7d82f04e729e29c60fadbd.1519327370.git.baruch@tkos.co.il

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer dereference problem.

- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the return of a NULL
pointer when an invalid DRM device type is encountered.  The
return of NULL was removed with BUG() from drm_minor_get_slot().
Signed-off-by: NJoe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: NSteven Sistare <steven.sistare@oracle.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220191157.100960-3-joe.moriarty@oracle.com

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.

- drivers/gpu/drm/drm_vblank.c
Null pointer checks were added to return values from calls to
drm_crtc_from_index().  There is a possibility, however minute, that
crtc->index may not be found when trying to find the struct crtc
from it's assigned index given in drm_crtc_init_with_planes().
3 return checks for NULL where added with a call to
WARN_ON(!crtc).
Signed-off-by: NJoe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: NSteven Sistare <steven.sistare@oracle.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220191157.100960-2-joe.moriarty@oracle.com

Move the plane clip rectangle handling into
drm_atomic_helper_check_plane_state(). Drivers no longer
have to worry about such mundane details.

v2: Convert armada, rcar, and sun4i as well
v3: Resolve simple_kms_helper conflict

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org> #msm
Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-5-ville.syrjala@linux.intel.com
Acked-by: Liviu Dudau <liviu.dudau@arm.com> #hdlcd,malidp
Acked-by: Philipp Zabel <p.zabel@pengutronix.de> #imx,mtk
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com> #vmwgfx
Acked-by: Neil Armstrong <narmstrong@baylibre.com> #meson
Acked-by: Shawn Guo <shawnguo@kernel.org> #zte

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Since armada isn't atomic we'll use crtc->enabled and crtc->mode instead
of the stuff under crtc_state.

Once everyone agrees on how the clip rectangle gets set up we can
move the code into drm_atomic_helper_check_plane_state().

Cc: Dave Airlie <airlied@redhat.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-4-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NDave Airlie <airlied@redhat.com>

As armada isn't an atomic driver trying to pass a non-populated
crtc->state to drm_atomic_helper_check_plane_state() will end in tears.
Construct a temporary crtc state a la drm_plane_helper_check_update()
and pass that instead. For now we just really need crtc_state->enable
to be there.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-3-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NDave Airlie <airlied@redhat.com>

Since we aren't in atomic context replace this long udelay with a
usleep_range.
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1519475894-11701-1-git-send-email-stefan.wahren@i2se.com

The IN_FORMATS blob allows the kernel to advertise to userspace which
format/modifier combinations are supported, per plane. Use this to
advertise that we support both T_TILED and linear.

v2:
  - Only advertise T_TILED for RGB (Eric)
  - Actually turn on allow_fb_modifiers (Eric)
Signed-off-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/170828/

The readl_poll_timeout() return value is 0 in case of success
so it is better to detect errors without taking care of the
return value sign.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180204213624.18288-1-philippe.cornu@st.com

After we acquired all generic modeset locks in drm_modeset_lock_all, it's
unsafe acquire any other so just mark acquisition as done.

Atomic drivers shouldn't use drm_modeset_lock_all.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180221152331.9212-1-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NHarry Wentland <harry.wentland@amd.com>

Add support for the COLOR_RANGE property on planes. This property
selects whether the input YCbCr data is to treated as limited range
or full range.

On most platforms this is a matter of setting the "YUV range correction
disable" bit, and on VLV/CHV we'll just have to program the color
correction logic to pass the data through unmodified.

v2: Rebase

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-9-ville.syrjala@linux.intel.com

Bring us forward from the stone age and switch our default YCbCr->RGB
conversion matrix to BT.709 from BT.601. I would expect most matrial
to be BT.709 these days.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Acked-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-8-ville.syrjala@linux.intel.com

Add support for the COLOR_ENCODING plane property which selects
the matrix coefficients used for the YCbCr->RGB conversion. Our
hardware can generally handle BT.601 and BT.709.

CHV pipe B sprites have a fully programmable matrix, so in theory
we could handle anything, but it doesn't seem all that useful to
expose anything beyond BT.601 and BT.709 at this time.

GLK can supposedly do BT.2020, but let's leave enabling that for
the future as well.

v2: Rename bit defines to match the spec more closely (Shashank)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-7-ville.syrjala@linux.intel.com

On GLK the plane CSC controls moved into the COLOR_CTL register.
Update the code to progam the YCbCr->RGB CSC mode correctly when
faced with an YCbCr framebuffer.

The spec is rather confusing as it calls the mode "YUV601 to RGB709".
I'm going to assume that just means it's going to use the YCbCr->RGB
matrix as specified in BT.601 and doesn't actually change the gamut.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-6-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).

On CHV pipe B we were actually doing the right thing already because we
progammed the custom CSC matrix to do expect limited range input. Now
that well pre-expand the data out with the color correction unit, we
need to change the CSC matrix to operate with full range input instead.

This should make the sprite output of the other pipes match the sprite
output of pipe B reasonably well. Looking at the resulting pipe CRCs,
there can be a slight difference in the output, but as I don't know
the formula used by the fixed function CSC of the other pipes, I don't
think it's worth the effort to try to match the output exactly. It
might not even be possible due to difference in internal precision etc.

One slight caveat here is that the color correction registers are single
bufferred, so we should really be updating them during vblank, but we
still don't have a mechanism for that, so just toss in another FIXME.

v2: Rebase
v3: s/bri/brightness/ s/con/contrast/ (Shashank)
v4: Clarify the constants and math (Shashank)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: "Tang, Jun" <jun.tang@intel.com>
Reported-by: N"Tang, Jun" <jun.tang@intel.com>
Cc: stable@vger.kernel.org
Fixes: 7f1f3851 ("drm/i915: sprite support for ValleyView v4")
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-5-ville.syrjala@linux.intel.com

Include color_enconding and color_range in the plane state dump.

v2: Add kerneldoc (danvet)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jyri Sarha <jsarha@ti.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219202846.10628-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NHarry Wentland <harry.wentland@amd.com>

Add a standard optional properties to support different non RGB color
encodings in DRM planes. COLOR_ENCODING select the supported non RGB
color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
the value ranges within the selected color encoding. The properties
are stored to drm_plane object to allow different set of supported
encoding for different planes on the device.

v2: Add/fix kerneldocs, verify bitmasks (danvet)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJyri Sarha <jsarha@ti.com>
[vsyrjala v2: Add/fix kerneldocs, verify bitmasks]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219202823.10508-1-ville.syrjala@linux.intel.comAcked-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which
is compatible to 32-bit SoCs, so allow building DRM driver for
arm64 architecture.
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-14-jernej.skrabec@siol.net