linux.git/include/drm, branch v4.14.124

drm: disable uncached DMA optimization for ARM and arm64

2019-03-13T21:03:23+00:00

[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]

The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
for some buffers, both the CPU and the GPU use uncached mappings,
removing the need for DMA snooping and allocation in the CPU caches.

The use of uncached GPU mappings relies on the correct implementation
of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
will use cached mappings nonetheless. On x86 platforms, this does not
seem to matter, as uncached CPU mappings will snoop the caches in any
case. However, on ARM and arm64, enabling this optimization on a
platform where NoSnoop is ignored results in loss of coherency, which
breaks correct operation of the device. Since we have no way of
detecting whether NoSnoop works or not, just disable this
optimization entirely for ARM and arm64.

Cc: Christian Koenig 
Cc: Alex Deucher 
Cc: David Zhou 
Cc: Huang Rui 
Cc: Junwei Zhang 
Cc: Michel Daenzer 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Will Deacon 
Cc: Christoph Hellwig 
Cc: Robin Murphy 
Cc: amd-gfx list 
Cc: dri-devel 
Reported-by: Carsten Haitzler 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Christian König 
Reviewed-by: Alex Deucher 
Link: https://patchwork.kernel.org/patch/10778815/
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin

drm/edid: VSDB yCBCr420 Deep Color mode bit definitions

2018-11-10T15:48:35+00:00

commit 9068e02f58740778d8270840657f1e250a2cc60f upstream.

HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct
definitions in the header for the mask to work correctly.

Fixes: e6a9a2c3dc43 ("drm/edid: parse ycbcr 420 deep color information")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893
Cc:  # v4.14+
Signed-off-by: Clint Taylor 
Reviewed-by: Jani Nikula 
Reviewed-by: Shashank Sharma 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/1538776335-12569-1-git-send-email-clinton.a.taylor@intel.com
Signed-off-by: Greg Kroah-Hartman

drm: Add DP PSR2 sink enable bit

2018-08-03T05:50:42+00:00

[ Upstream commit 4f212e40468650e220c1770876c7f25b8e0c1ff5 ]

To comply with eDP1.4a this bit should be set when enabling PSR2.

Signed-off-by: José Roberto de Souza 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi 
Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-1-jose.souza@intel.com
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/syncobj: Stop reusing the same struct file for all syncobj -> fd

2018-03-28T16:24:47+00:00

commit e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31 upstream.

The vk cts test:
dEQP-VK.api.external.semaphore.opaque_fd.export_multiple_times_temporary

triggers a lot of
VFS: Close: file count is 0

Dave pointed out that clearing the syncobj->file from
drm_syncobj_file_release() was sufficient to silence the test, but that
opens a can of worm since we assumed that the syncobj->file was never
unset. Stop trying to reuse the same struct file for every fd pointing
to the drm_syncobj, and allocate one file for each fd instead.

v2: Fixup return handling of drm_syncobj_fd_to_handle
v2.1: [airlied: fix possible syncobj ref race]
v2.2: [jekstrand: back-port to 4.14]

Reported-by: Dave Airlie 
Signed-off-by: Chris Wilson 
Tested-by: Dave Airlie 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Jason Ekstrand 
Tested-by: Clayton Craft 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: prefer XBGR2101010 for addfb ioctl

2018-03-15T09:54:30+00:00

commit c20bb155c2c5acb775f68be5d84fe679687c3c1e upstream.

Nouveau only exposes support for XBGR2101010. Prior to the atomic
conversion, drm would pass in the wrong format in the framebuffer, but
it was always ignored -- both userspace (xf86-video-nouveau) and the
kernel driver agreed on the layout, so the fact that the format was
wrong didn't matter.

With the atomic conversion, nouveau all of a sudden started caring about
the exact format, and so the previously-working code in
xf86-video-nouveau no longer functioned since the (internally-assigned)
format from the addfb ioctl was wrong.

This change adds infrastructure to allow a drm driver to specify that it
prefers the XBGR format variant for the addfb ioctl, and makes nouveau's
nv50 display driver set it. (Prior gens had no support for 30bpp at all.)

Signed-off-by: Ilia Mirkin 
Cc: stable@vger.kernel.org # v4.10+
Acked-by: Ben Skeggs 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20180203191123.31507-1-imirkin@alum.mit.edu
Signed-off-by: Greg Kroah-Hartman

drm: Allow determining if current task is output poll worker

2018-03-15T09:54:29+00:00

commit 25c058ccaf2ebbc3e250ec1e199e161f91fe27d4 upstream.

Introduce a helper to determine if the current task is an output poll
worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish.  The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.

v2: Expand kerneldoc to specifically mention deadlock between
    output poll worker and autosuspend worker as use case. (Lyude)

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Alex Deucher 
Reviewed-by: Lyude Paul 
Signed-off-by: Lukas Wunner 
Link: https://patchwork.freedesktop.org/patch/msgid/3549ce32e7f1467102e70d3e9cbf70c46bfe108e.1518593424.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman

x86/gpu: add CFL to early quirks

2018-02-22T14:42:18+00:00

commit 33aa69ed8aacd92dea12671e52eb3ca6ac2d7a49 upstream.

CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
allow the memory region to be stolen, otherwise we could have RAM being
arbitrarily overwritten if for example we keep using the UEFI framebuffer,
depending on how BIOS has set up the e820 map.

Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
Signed-off-by: Lucas De Marchi 
Cc: Rodrigo Vivi 
Cc: Anusha Srivatsa 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: David Airlie 
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
Cc: x86@kernel.org
Cc:  # v4.13+ 0890540e21cf drm/i915: add GT number to intel_device_info
Cc:  # v4.13+ 41693fd52373 drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5
Cc:  # v4.13+
Reviewed-by: Rodrigo Vivi 
Acked-by: Jani Nikula 
Acked-by: Ingo Molnar 
Signed-off-by: Rodrigo Vivi 
Link: https://patchwork.freedesktop.org/patch/msgid/20171213200425.2954-1-lucas.demarchi@intel.com
Signed-off-by: Greg Kroah-Hartman

drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5

2018-02-22T14:42:18+00:00

commit 41693fd5237397d3c61b311af0fda1f6f39297c2 upstream.

See Mesa commit 9c588ff

Cc: Matt Turner 
Cc: Rodrigo Vivi 
Signed-off-by: Anuj Phogat 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi 
Link: https://patchwork.freedesktop.org/patch/msgid/20170920203126.1323-1-anuj.phogat@gmail.com
Signed-off-by: Greg Kroah-Hartman

drm/i915: add GT number to intel_device_info

2018-02-22T14:42:18+00:00

commit 0890540e21cf1156b4cf960a4c1c734db4e816f9 upstream.

Up to Coffeelake we could deduce this GT number from the device ID.
This doesn't seem to be the case anymore. This change reorders pciids
per GT and adds a gt field to intel_device_info. We set this field on
the following platforms :

   - SNB/IVB/HSW/BDW/SKL/KBL/CFL/CNL

Before & After :

$ modinfo drivers/gpu/drm/i915/i915.ko | grep ^alias | wc -l
209

v2: Add SNB & IVB (Chris)

v3: Fix compilation error in early-quirks (Lionel)

v4: Fix inconsistency between FEATURE/PLATFORM macros (Ville)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson 
Link: https://patchwork.freedesktop.org/patch/msgid/20170830161208.29221-2-lionel.g.landwerlin@intel.com
Signed-off-by: Greg Kroah-Hartman

drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

2017-12-05T10:26:37+00:00

commit 9271c0ca573e02a360b636ecd8cb408852f4e9f6 upstream.

Apparently some sinks look at the YQ bits even when receiving RGB,
and they get somehow confused when they see a non-zero YQ value.
So we can't just blindly follow CEA-861-F and set YQ to match the
RGB range.

Unfortunately there is no good way to tell whether the sink
designer claims to have read CEA-861-F. The CEA extension block
revision number has generally been stuck at 3 since forever,
and even a very recently manufactured sink might be based on
an old design so the manufacturing date doesn't seem like
something we can use. In lieu of better information let's
follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.

The alternative would of course be to always set YQ=0. And if
we ever encounter a HDMI 2.0+ sink with this bug that's what
we'll probably have to do.

Cc: Jani Nikula 
Cc: Eric Anholt 
Cc: Neil Kownacki 
Reported-by: Neil Kownacki 
Tested-by: Neil Kownacki 
Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20171108152504.12596-1-ville.syrjala@linux.intel.com
Acked-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman