Select DRM_PANEL, since the MXSFB driver depends on it. Otherwise,
we get the following error when compiling:

drivers/built-in.o: In function `mxsfb_probe':
core.c:(.text+0x9ce9c): undefined reference to `drm_panel_attach'
core.c:(.text+0x9cff0): undefined reference to `drm_panel_detach'
drivers/built-in.o: In function `mxsfb_panel_connector_destroy':
core.c:(.text+0x9d614): undefined reference to `drm_panel_detach'
drivers/built-in.o: In function `mxsfb_create_output':
core.c:(.text+0x9d68c): undefined reference to `of_drm_find_panel'
make: *** [Makefile:962: vmlinux] Error 1
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Reported-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add new driver for the MXSFB controller found in i.MX23/28/6SX .
The MXSFB controller is a simple framebuffer controller with one
parallel LCD output. Unlike the MXSFB fbdev driver that is used
on these systems now, this driver uses the DRM/KMS framework.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Allows MXM DCB modification to be handled on GM20x and newer boards.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I suspect the version bump is just to signify that the table now specifies
pad macro/links instead of SOR/sublinks.

For our usage of the table, just recognising the new version is enough.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Commit aeefb368 ("drm/exynos: gsc: add device tree support and remove
usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only
be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use
the same HW IP block.

But added the dependency as depends on !VIDEO_SAMSUNG_EXYNOS_GSC which is
not correct since Kconfig expressions are not boolean but tristate. So it
will only evaluate to 'n' if VIDEO_SAMSUNG_EXYNOS_GSC=y but will evaluate
to 'm' if VIDEO_SAMSUNG_EXYNOS_GSC=m.

This means that both the V4L2 and DRM drivers can be enabled if the former
is enabled as a module, which isn't what we want since otherwise 2 drivers
could attempt to use the hardware at the same time.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Trivial fixes to spelling mistakes "precalser" to "prescaler"
in dev_err messages
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Fix exynos_drm_gem_create() error messages to include flags and size when
flags and size are invalid.
Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Use core helpers to generate infoframes and generate vendor frame if necessary.

Changelog:
- changed 'ret >= 0' checks to '!ret'
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

David found another issue with priority bumping from mmioflips, where we
are accessing the requests concurrently to them being retired and freed.
Whilst we are skipping the dependency if has been submitted, that is not
sufficient to stop the dependency from disappearing if another thread
retires that request. To prevent we can either employ the struct_mutex (or a
request mutex in the future) to serialise retiring before it is freed.
Alternatively, we need to keep the dependencies alive using RCU whilst
they are being accessed via the DFS.

[ 1746.698111] general protection fault: 0000 [#1] PREEMPT SMP
[ 1746.698305] Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core coretemp crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei i915 e1000e ptp pps_core i2c_hid
[ 1746.698750] CPU: 1 PID: 6716 Comm: kworker/u8:2 Not tainted 4.9.0-rc6-CI-Nightly_816+ #1
[ 1746.698871] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016
[ 1746.699125] Workqueue: events_unbound intel_mmio_flip_work_func [i915]
[ 1746.699266] task: ffff880260a5e800 task.stack: ffffc90000f6c000
[ 1746.699361] RIP: 0010:[<ffffffffa006595d>]  [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
[ 1746.699632] RSP: 0018:ffffc90000f6fcd8  EFLAGS: 00010206
[ 1746.699724] RAX: dead0000000000f8 RBX: ffff8801f64b2bf0 RCX: ffff8801f64b2c10
[ 1746.699842] RDX: dead000000000100 RSI: 0000000000000000 RDI: ffff8801f64b0458
[ 1746.699972] RBP: ffffc90000f6fd68 R08: ffff88026488dc00 R09: 0000000000000002
[ 1746.700090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000400
[ 1746.700195] R13: ffffc90000f6fcf0 R14: ffff88020955aa40 R15: ffff88020955aa68
[ 1746.700307] FS:  0000000000000000(0000) GS:ffff88026dc80000(0000) knlGS:0000000000000000
[ 1746.700435] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1746.700532] CR2: 0000000002a69e90 CR3: 0000000002c07000 CR4: 00000000003406e0
[ 1746.700635] Stack:
[ 1746.700682]  ffff880260a5e880 ffffc90000f6fd50 ffffffff810af69a ffffc90000f6fd28
[ 1746.700827]  ffff88020955a628 ffff8801e1eaebf0 0000000000000020 0000000000000000
[ 1746.700947]  00000196af1edc96 ffff88025dfa4000 ffff8801f0b030a8 ffffc90000f6fcf0
[ 1746.701071] Call Trace:
[ 1746.701117]  [<ffffffff810af69a>] ? dequeue_entity+0x25a/0xb50
[ 1746.701260]  [<ffffffffa00516be>] fence_set_priority+0x7e/0x80 [i915]
[ 1746.701406]  [<ffffffffa0051a15>] i915_gem_object_wait_priority+0x85/0x160 [i915]
[ 1746.701599]  [<ffffffffa008ccd7>] intel_mmio_flip_work_func+0x47/0x2b0 [i915]
[ 1746.701717]  [<ffffffff81094c4d>] process_one_work+0x14d/0x470
[ 1746.701809]  [<ffffffff81094fb3>] worker_thread+0x43/0x4e0
[ 1746.701888]  [<ffffffff81094f70>] ? process_one_work+0x470/0x470
[ 1746.701969]  [<ffffffff81094f70>] ? process_one_work+0x470/0x470
[ 1746.702072]  [<ffffffff8109a4d5>] kthread+0xc5/0xe0
[ 1746.702152]  [<ffffffff81771c59>] ? _raw_spin_unlock_irq+0x9/0x10
[ 1746.702234]  [<ffffffff8109a410>] ? kthread_park+0x60/0x60
[ 1746.702318]  [<ffffffff81772272>] ret_from_fork+0x22/0x30
[ 1746.702387] Code: 89 42 08 48 8b 45 88 48 89 55 c0 4c 89 6d c8 4c 8d 70 d8 4d 8d 7e 28 4d 39 ef 74 72 49 8b 1e 48 8b 13 48 39 d3 48 8d 42 f8 74 3e <48> 8b 10 8b 52 38 41 39 d4 7e 26 48 8b 50 30 48 8b 78 28 48 8d
[ 1746.702921] RIP  [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.703027]  RSP <ffffc90000f6fcd8>

Fixes: 27745e82 ("drm/i915/execlists: Use a local lock for dfs_link access")
Fixes: 9a151987 ("drm/i915: Add execution priority boosting for mmioflips")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161128143649.4289-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit 92117f0b)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Currently, we have an active reference for the request until it is
retired. Though it cannot be retired before it has been executed by
hardware, the request may be completed before we have finished
processing the execute fence, i.e. we may continue to process that fence
as we free the request.

Fixes: 5590af3e ("drm/i915: Drive request submission through fence callbacks")
Fixes: 23902e49 ("drm/i915: Split request submit/execute phase into two")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161125131718.20978-3-chris@chris-wilson.co.uk
(cherry picked from commit 48bc2a4a)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Some monitors will have noise or even no sound after
applying the patch 6014ac12.

In patch 6014ac12, it will reset the cts value to 0 for HDMI.
However, we need to disable Enable CTS or M Prog bit. This is
the initial setting after HW reset.

Fixes: 6014ac12 ("drm/i915/audio: set proper N/M in modeset")
Signed-off-by: NLibin Yang <libin.yang@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478853988-139842-1-git-send-email-libin.yang@intel.com
(cherry picked from commit 60abfbb8)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The i915_next_seqno read value is to be the next seqno used by the
kernel. However, in the conversion to atomics ops for gt.next_seqno, in
commit 28176ef4 ("drm/i915: Reserve space in the global seqno during
request allocation"), this was changed from a post-increment to a
pre-increment. This increment was missed from the value reported by
debugfs, so in effect it was reporting the current seqno (last
assigned), not the next seqno.

Fixes: 28176ef4 ("drm/i915: Reserve space in the global seqno during request allocation")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81209Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161124094752.19129-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 9607ae79)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

i915_hws_info() has not been kept upto date (missing new engines) and so
I consider it to be unused. HWS is included in the error state, which
would be an avenue to retrieving it if required in future (possibly via
i915_engine_info). As it is currently oopsing with an rpm testcase, just
remove it.

Fixes: 3b3f1650 ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98838Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161124093401.18852-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit 30576a2c)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Looks like we're only initializing dev_priv->atomic_cdclk_freq
at resume and commit times, not at init time. Let's do that as
well.

We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in
hsw_compute_linetime_wm() on account of populating
intel_state->cdclk from dev_priv->atomic_cdclk_freq.
Previously we were mispopulating intel_state->cdclk with
dev_priv->cdclk_freq which always had a proper value at init
time and hence the WARN_ON() didn't trigger.

Cc: <stable@vger.kernel.org> # 4.6+: 14676ec6 drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
Cc: <stable@vger.kernel.org> # 4.6+
Cc: Matthew Auld <matthew.auld@intel.com>
Reported-by: NMatthew Auld <matthew.auld@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902
Fixes: 14676ec6 ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1480428837-4207-1-git-send-email-ville.syrjala@linux.intel.comTested-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
(cherry picked from commit 6a259b1f)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When we end up not recomputing the cdclk, we need to populate
intel_state->cdclk with the "atomic_cdclk_freq" instead of the
current cdclk_freq. When no pipes are active, the actual cdclk_freq
may be lower than what the configuration of the planes and
pipes would require from the point of view of the software state.

This fixes bogus WARNS from skl_max_scale() which is trying to check
the plane software state against the cdclk frequency. So any time
it got called during DPMS off for instance, we might have tripped
the warn if the current mode would have required a higher than
minimum cdclk.

v2: Drop the dev_cdclk stuff (Maarten)

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: bruno.pagani@ens-lyon.org
Cc: Daniel J Blueman <daniel.blueman@gmail.com>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Joseph Yasi <joe.yasi@gmail.com>
Tested-by: NPaul Bolle <pebolle@tiscali.nl>
Tested-by: Joseph Yasi <joe.yasi@gmail.com> (v1)
Cc: <stable@vger.kernel.org> # v4.6+
Fixes: 1a617b77 ("drm/i915: Keep track of the cdclk as if all crtc's were active.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit e0ca7a6b)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Someone forgot to make skl_write_{plane,cursor}_wm() static when
removing the prototypes from the header. Sparse isn't pleased.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Lyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: e62929b3 ("drm/i915/gen9+: Program watermarks as a separate step during evasion, v3.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479846113-24745-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NLyude <lyude@redhat.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit d9348dec)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Since the submit/execute split in commit d55ac5bf ("drm/i915: Defer
transfer onto execution timeline to actual hw submission") the
global seqno advance was deferred until the submit_request callback.
After wedging the GPU, we were installing a nop_submit_request handler
(to avoid waking up the dead hw) but I had missed converting this over
to the new scheme. Under the new scheme, we have to explicitly call
i915_gem_submit_request() from the submit_request handler to mark the
request as on the hardware. If we don't the request is always pending,
and any waiter will continue to wait indefinitely and hangcheck will not
be able to resolve the lockup.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98748
Testcase: igt/gem_eio/in-flight
Fixes: d55ac5bf ("drm/i915: Defer transfer onto execution timeline to actual hw submission")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161122144121.7379-3-chris@chris-wilson.co.uk
(cherry picked from commit 3dcf93f7)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

On i.MX6SX the physical memory is placed above the 2GB mark, so the GPU
linear window has to be moved for the GPU to work at all. This doesn't
mix with the FAST_CLEAR feature, as the TS unit doesn't take the linear
window offset into account and will corrupt memory when used with a
non-zero offset.

Move the linear window if it's necessary for the GPU to work, but avoid
announcing FAST_CLEAR support to userspace in this case.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Tested-by: NMarek Vasut <marex@denx.de>

The dumper is only a debugging aid so we don't want to invoke the OOM
killer if buffer for the potentially large GPU state can't be vmalloced.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

The object internal SG table must not be returned, as the caller
will take ownership of the returned table.

Construct a new table from the object pages and return this one
instead.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

Vivante GPUs with HALTI0 feature support a DRAW_INSTANCED command in the
command stream to draw a number of instances of the same geometry.

The information that has been figured out about the command can be found
here: https://github.com/etnaviv/etna_viv/blob/master/rnndb/cmdstream.xml#L270

This command is not allowed currently by the DRM driver because it
was not known before. This patch enables parsing it in command
streams and allows using it by userspace drivers.
Signed-off-by: NWladimir J. van der Laan <laanwj@gmail.com>
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

This adds the required boilerplate to allow direct mmap of exported
etnaviv BOs.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>

The Amlogic Meson Display controller is composed of several components :

DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
   | vd1   _______     _____________    _________________     |               |
D  |-------|      |----|            |   |                |    |   HDMI PLL    |
D  | vd2   | VIU  |    | Video Post |   | Video Encoders |<---|-----VCLK      |
R  |-------|      |----| Processing |   |                |    |               |
   | osd2  |      |    |            |---| Enci ----------|----|-----VDAC------|
R  |-------| CSC  |----| Scalers    |   | Encp ----------|----|----HDMI-TX----|
A  | osd1  |      |    | Blenders   |   | Encl ----------|----|---------------|
M  |-------|______|----|____________|   |________________|    |               |
___|__________________________________________________________|_______________|

VIU: Video Input Unit
---------------------

The Video Input Unit is in charge of the pixel scanout from the DDR memory.
It fetches the frames addresses, stride and parameters from the "Canvas" memory.
This part is also in charge of the CSC (Colorspace Conversion).
It can handle 2 OSD Planes and 2 Video Planes.

VPP: Video Post Processing
--------------------------

The Video Post Processing is in charge of the scaling and blending of the
various planes into a single pixel stream.
There is a special "pre-blending" used by the video planes with a dedicated
scaler and a "post-blending" to merge with the OSD Planes.
The OSD planes also have a dedicated scaler for one of the OSD.

VENC: Video Encoders
--------------------

The VENC is composed of the multiple pixel encoders :
 - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
 - ENCP : Progressive Video Encoder for HDMI
 - ENCL : LCD LVDS Encoder
The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
tree and provides the scanout clock to the VPP and VIU.
The ENCI is connected to a single VDAC for Composite Output.
The ENCI and ENCP are connected to an on-chip HDMI Transceiver.

This driver is a DRM/KMS driver using the following DRM components :
 - GEM-CMA
 - PRIME-CMA
 - Atomic Modesetting
 - FBDev-CMA

For the following SoCs :
 - GXBB Family (S905)
 - GXL Family (S905X, S905D)
 - GXM Family (S912)

The current driver only supports the CVBS PAL/NTSC output modes, but the
CRTC/Planes management should support bigger modes.
But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
a second time.

The Device Tree bindings makes use of the endpoints video interface definitions
to connect to the optional CVBS and in the future the HDMI Connector nodes.

HDMI Support is planned for a next release.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

The DT binding for tildc is not consistent with the driver code: there
are two options - 'max-width' and 'max-pixelclock' specified in the
documentation which are parsed as 'ti,max-width' and
'ti,max-pixelclock' respectively.

Make the driver code consistent with the binding.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NJyri Sarha <jsarha@ti.com>

We should wait for the last frame to complete before shutting things
down also on LCDC rev 1.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Configure video mode to HW in enable() call back. There is no reason
to do it before that. This makes PM functions way easier because there
is no HW context to save when screen is for instance blanked. This
patch removes mode_set_nofb() call back from tilcdc.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Load palette at the end of mode_set_nofb(). Moving the palette loading
to mode_set_nofb() saves us from storing and restoring of framebuffer
addresses in dma registers that were just recently written there.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add timeout wait for palette loadind to complete. We do not want to
hang forever if palette loaded interrupt does not arrive for some
reason.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The LCDC revision 2 documentation also mentions the mandatory palette
for true color modes. Even if the rev 2 LCDC appears to work just fine
without the palette being loaded loading it helps in testing the
feature.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Set LCDC_PALETTE_LOAD_MODE bit-field with new tilcdc_write_mask()
instead of tilcdc_set(). Setting a bit-fields with tilcdc_set() is
fundamentally broken.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add tilcdc_write_mask() for handling register field wider than one bit
and mask values for those fields.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Failed tilcdc_crtc_create() error handling was broken, this patch
should fix it.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).

Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Revision 1 LCDC support also sync lost errors and can benefit from
sync lost recovery routine.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Adds drm bride support for attaching drm bridge drivers to tilcdc. The
decision whether a video port leads to an external encoder or bridge
is made simply based on remote device's compatible string. The code
has been tested with BeagleBone-Black with and without BeagleBone
DVI-D Cape Rev A3 using ti-tfp410 driver.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

Add very basic ti-tfp410 DVI transmitter driver. The only feature
separating this from a completely dummy bridge is the EDID read
support trough DDC I2C. Even that functionality should be in a
separate generic connector driver. However, because of missing DRM
infrastructure support the connector is implemented within the bridge
driver. Some tfp410 HW specific features may be added later if needed,
because there is a set of registers behind i2c if it is connected.

This implementation is tested against my new tilcdc bridge support
and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
is also updated.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Acked-by: NRob Herring <robh@kernel.org>

Recover from sync lost error flood by resetting the LCDC instead of
turning off the SYNC_LOST error IRQ. When LCDC starves on limited
memory bandwidth it may sometimes result an error situation when the
picture may have shifted couple of pixels to right and SYNC_LOST
interrupt is generated on every frame. LCDC main reset recovers from
this situation and causes a brief blanking on the screen.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
or a reset is in progress we bail early but never seem to actually
release the lock.

Fixes: 7f1847eb ("drm/i915: Simplify checking of GPU reset_counter in display pageflips")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161128103648.9235-1-matthew.auld@intel.comReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.7+
(cherry picked from commit ddbb271a)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

On the DMA mapping error path, sg may be NULL (it has already been
marked as the last scatterlist entry), and we should avoid dereferencing
it again.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: e2273302 ("drm/i915: avoid leaking DMA mappings")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/20161114112930.2033-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>
(cherry picked from commit b17993b7)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>