i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1503167300-17334-4-git-send-email-arvind.yadav.cs@gmail.com
Link: https://patchwork.freedesktop.org/patch/msgid/60db0ba6ddce08444299533e97c9adec3b3ef1bb.1503311145.git.arvind.yadav.cs@gmail.com

i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1503167300-17334-3-git-send-email-arvind.yadav.cs@gmail.com

i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1503167300-17334-2-git-send-email-arvind.yadav.cs@gmail.com

It's dead code, the core handles all this directly now.

The only special case is nouveau and tda988x which used one function
for both legacy modeset code and -nv50 atomic world instead of 2
vtables. But amounts to exactly the same.

v2: Rebase over the panel/brideg refactorings in stm/ltdc.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Peter Senna Tschudin <peter.senna@collabora.com>
Cc: Martin Donnelly <martin.donnelly@ge.com>
Cc: Martyn Welch <martyn.welch@collabora.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Alison Wang <alison.wang@freescale.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Yannick Fertre <yannick.fertre@st.com>
Cc: Philippe Cornu <philippe.cornu@st.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Yakir Yang <kuankuan.y@gmail.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Romain Perier <romain.perier@collabora.com>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rongrong Zou <zourongrong@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Hai Li <hali@codeaurora.org>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-tegra@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: zain wang <wzz@rock-chips.com>
Cc: Baoyou Xie <baoyou.xie@linaro.org>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-8-daniel.vetter@ffwll.chAcked-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NArchit Taneja <architt@codeaurora.org>
Tested-by: Philippe Cornu <philippe.cornu@st.com> (on stm)
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NShawn Guo <shawnguo@kernel.org>
Acked-by: NShawn Guo <shawnguo@kernel.org>
Acked-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NVincent Abriou <vincent.abriou@st.com>

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
	- VIC for 4K modes for HDMI 1.4 sinks
	- S3D information for S3D modes
  As CEA-861-F has already defined VICs for 4K videomodes, this
  patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
  until the mode is 3D.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
	- Do not send VICs in both AVI-IF and HDMI-IF
	  send only one of it.
V4: Rebase
V5: Added r-b from Neil.
    Addressed review comments from Ville
    - Do not block HDMI vendor IF, instead check for VIC while
      handling AVI infoframes
V6: Rebase
V7: Rebase
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

With the include directives under include/drm/ fixed, this flag is
no longer needed.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1493009447-31524-21-git-send-email-yamada.masahiro@socionext.com

Trivial fix to spelling mistake "configutation" to "configuration"
in dev_err message
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

cec_read() is non-atomic in the presence of other I2C bus transactions
to the same device.  This presents a problem when we add support for
the TDA9950 CEC engine part - both drivers can be trying to access the
device.

Avoid the inherent problems by switching to i2c_transfer() instead,
which allows us to perform more than one bus transaction atomically.

As this means we will be using I2C transactions rather than SMBUS, we
have to check that the host supports I2C functionality.
Tested-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Some TDA998x contain several different I2C devices - there is the HDMI
encoder, and there is a TDA9950 CEC engine.  These two share the same
interrupt signal.

In order to allow a driver for the CEC engine to work, we need to be
able to share the interrupt with the CEC driver, so convert the handler
and registration to allow this to happen.
Tested-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Disabling the pre-filter block of the TDA998x saves 40mW and the colour
conversion block saves 15mW.  As we always disable these two blocks, we
can power these sections of the chip down to save 55mW of unnecessary
power consumption.
Tested-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Rather than storing the DPMS mode (which will always be on or off) use a
boolean to store this instead.
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

tda998x_audio_get_eld() is needlessly complex - the connector associated
with the encoder is always our own priv->connector.  Remove this
complexity, but ensure that there are no races when copying out the ELD.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Group the TDA998x audio functions together rather than split between
two different locations in the file, keeping like code together.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Separate out the connector initialisation from the rest of the drivers
initialisation.
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Group the TDA998x connector functions and funcs structures together
before the encoder support, rather than scattered amongst the rest of
the file.  This keeps like code together.
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The naming of tda998x_encoder_set_config() is a left-over from when
TDA998x was a slave encoder.  Since this is part of the initialisation,
drop the _encoder from the name, and move it near tda998x_bind().
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Correct two references to tda998x_connector_get_modes() which were
incorrectly referring to tda998x_encoder_get_modes().
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Check for audio support by the attached sink by consulting the EDID
prior to enabling audio over the TMDS link.  We must consult the EDID
after calling drm_helper_probe_single_connector_modes(), as this can
use an override EDID, or load a replacement EDID.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The CEA 861B specification indicates the situations when we are able to
send each infoframe based on the version of the EDID's CEA extension.
Update the tda998x driver to follow the CEA specification wrt sending
of infoframes.

Since we only support the generation of AVI version 2, this limits us
to CEA extension version 3, so we treat CEA extension version 2 as
CEA 861 (no infoframes, no audio.)
Tested-by: NRobin Murphy <robin.murphy@arm.com>
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Avoid a race between programming audio and an in-progress mode set.
A mode set is complex, and disables the ability to send infoframes
to the sink, and is disruptive to audio - we have to mute the audio
FIFO while doing a mode set.

If an attempt is made to start up the audio side, we will undo the
audio FIFO mute before the mode set has completed.

Move the lock so that we prevent audio interfering with an in-progress
mode set.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Avoid a racy access to the mode clock by storing the current mode clock
during a mode set under the audio mutex.  This allows us to access it
from the audio path in a safe way.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

As priv->audio_params can now be changed at run time, we need to be more
careful about how we deal with a mode set.  We must take the audio lock
while checking if there's a valid audio configuration.

However, it's slightly worse than that - during mode set, we mute the
audio, and it must not be unmuted until we have finished the mode set.
It is possible that the audio side may start while a mode set is in
progress, so take the audio_mutex lock around the whole mode setting
procedure.
Tested-by: NJon Medhurst <tixy@linaro.org>
Acked-by: NJon Medhurst <tixy@linaro.org>
Tested-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

We will need the audio mutex initialised in all cases, so lets move this
to be early, rather than only being initialised for the DT case.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Connectors shouldn't be registered until the rest of the whole device
is set up, so that consistent state is presented to userspace.

As such, remove the calls to drm_connector_register() and
drm_connector_unregister() from tda998x, as these are now handled by
drm_dev_(un)register() itself.

To work with this change, the mali-dp and hdlcd bind and unbind
sequences have to be reordered, to ensure that the componentised
encoder/connector is bound before drm_dev_register() registers all
connectors. Similarly, the device must be unregistered before the
component is unbound.

Altogether, this allows other drivers using tda998x to be
de-midlayered, and to have less racy initialisation of their components.

Splitting this commit into three (one per driver) isn't possible without
intermediate breakage, so it is all squashed together here.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

We get 1 warning when building kernel with W=1:
drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: warning: no previous prototype for 'tda998x_audio_digital_mute' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks this function with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477127682-3615-1-git-send-email-baoyou.xie@linaro.org

This reverts commit 6a2925ea.

commit 6a2925ea
Author: Brian Starkey <brian.starkey@arm.com>
Date:   Mon Jul 25 11:55:48 2016 +0100

    drm/i2c: tda998x: don't register the connector

[seanpaul]
Patch isn't fully baked, and still causing problems. Revert
until this is sorted.
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NSean Paul <seanpaul@chromium.org>

The connector shouldn't be registered until the rest of the whole device
is set up, so that consistent state is presented to userspace.

As drm_dev_register() now registers all of the connectors anyway,
there's no need to explicitly do it in individual drivers so remove
the calls to drm_connector_register()/drm_connector_unregister().

This allows componentised drivers to use tda998x without having racy
initialisation.
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469444148-19003-1-git-send-email-brian.starkey@arm.com
Link: http://patchwork.freedesktop.org/patch/msgid/545C835D.1050008@arm.com

Register ASoC HDMI codec for audio functionality and adds device tree
binding for audio configuration.

With the registered HDMI codec the tda998x node can be used like a
regular codec node in ASoC card configurations. HDMI audio info-frame
and audio stream header is generated by the ASoC HDMI codec. The codec
also applies constraints for available sample-rates based on Edid Like
Data from the display. The device tree binding document has been
updated [1].

Part of this patch has been inspired by Jean Francoise's "drm/i2c: tda998x:
Add support of a DT graph of ports"-patch [2]. There may still be some
identical lines left from the original patch and some of the ideas
have come from there.

[1] Documentation/devicetree/bindings/display/bridge/tda998x.txt
[2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/095255.htmlSigned-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Define struct tda998x_audio_params in include/drm/i2c/tda998x.h and
use it in pdata and for tda998x_configure_audio() parameters. Also
updates tda998x_write_aif() to take struct hdmi_audio_infoframe *
directly as a parameter.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

The driver has been converted to use drm_bridge instead of
drm_i2c_slave_encoder. We can now move it to the bridge folder.

Create a separate folder since we already have a couple of files and
expect more when we support audio and ADV7533.

Rename the driver to adv7511_drv.c. This will come in handy later
when the driver module will need to be built from multiple object
files.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>

We don't want to use the old i2c slave encoder interface anymore.

Remove that and make the i2c driver create a drm_bridge entity instead.
Converting to bridges helps because the kms drivers don't need to
exract encoder slave ops from this driver and use it within their
own encoder/connector ops.

The driver now creates its own connector when a kms driver attaches
itself to the bridge. Therefore, kms drivers don't need to create
their own connectors anymore.

The old encoder slave ops are now used by the new bridge and connector
entities.

The of_node member in drm_bridge is accessible only when CONFIG_OF is
enabled. The driver anyway only works only when OF is available. Make
the driver depend on OF in its Kconfig.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>

Use shiny new drm_crtc_force_disable() instead of open coding the same.
No functional change intended.

Cc: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/ec7d5c06e2a21dfb8f9fc9413d3e6df86d6aa1fb.1465392124.git.lukas@wunner.de

Choose between atomic or non atomic connector dpms helper. If tda998x
is connected to a drm driver that does not support atomic modeset
calling drm_atomic_helper_connector_dpms() causes a crash when the
connectors atomic state is not initialized. The patch implements a
driver specific connector dpms helper that calls
drm_atomic_helper_connector_dpms() if driver supports DRIVER_ATOMIC
and otherwise it calls the legacy drm_helper_connector_dpms().

Fixes commit 9736e988 ("drm/i2c: tda998x: Add support for atomic
modesetting").
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Removed dummy mode_fixup.
Signed-off-by: NCarlos Palminha <palminha@synopsys.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455118167-12178-3-git-send-email-palminha@synopsys.com

Removed dummy mode_fixup.
Signed-off-by: NCarlos Palminha <palminha@synopsys.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455118167-12178-2-git-send-email-palminha@synopsys.com

Since drm_property_create_range can be failed in memory pressure,
it needs to be checked and return -ENOMEM.
Signed-off-by: NInsu Yun <wuninsu@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454025276-13465-1-git-send-email-wuninsu@gmail.com

Fix this typo, consequently used over both files :)
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NArchit Taneja <architt@codeaurora.org>

This register includes a counter which is decremented by the chip on I2C
failures. Also, it is reset when powering down.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NArchit Taneja <architt@codeaurora.org>

The interrupts for EDID_READY or DDC_ERROR were never enabled in this
driver, so reading EDID always timed out when chip was powered down and
interrupts were used. Fix this and also remove clearing the interrupt
flags, they are cleared in POWER_DOWN mode anyhow (unlike the interrupt
enable flags) according to docs and my tests.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: NArchit Taneja <architt@codeaurora.org>

An encoder is associated with a connector by the DRM core as a result of
setting up a configuration. Drivers using the atomic or legacy helpers
should never set up this link, even if it is a static one.

While at it, try to catch this kind of error in the future by adding a
WARN_ON() in drm_mode_connector_attach_encoder(). Note that this doesn't
cover all the cases, since drivers could set this up after attaching.
Drivers that use the atomic helpers will get a warning later on, though,
so hopefully the two combined cover enough to help people avoid this in
the future.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Mark yao <mark.yao@rock-chips.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1447694393-24700-1-git-send-email-thierry.reding@gmail.com