leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
948,892 Commits 2 Branches 0 Tags
94dea151bf3651c01acb12a38ca75ba9d26ea4da
Commit Graph

68034 Commits

Author SHA1 Message Date
Gerd Hoffmann
b4b1c66927 drm/vram: drop verify_access 
Not needed any more.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-11-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
5a8b7cf93c drm/vram: switch vram helper to &drm_gem_object_funcs.mmap() 
Wire up the new drm_gem_ttm_mmap() helper function,
use generic drm_gem_mmap for &fops.mmap and
delete dead drm_vram_mm_file_operations_mmap().

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-10-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
231927d939 drm/ttm: add drm_gem_ttm_mmap() 
Add helper function to mmap ttm bo's using &drm_gem_object_funcs.mmap().

Note that with this code path access verification is done by
drm_gem_mmap() (which calls drm_vma_node_is_allowed(()).
The &ttm_bo_driver.verify_access() callback is is not used.

v3: use ttm_bo_mmap_obj instead of ttm_bo_mmap_vma_setup

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-9-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
12067e0e89 drm/ttm: rename ttm_fbdev_mmap 
Rename ttm_fbdev_mmap to ttm_bo_mmap_obj.  Move the vm_pgoff sanity
check to amdgpu_bo_fbdev_mmap (only ttm_fbdev_mmap user in tree).

The ttm_bo_mmap_obj function can now be used to map any buffer object.
This allows to implement &drm_gem_object_funcs.mmap in gem ttm helpers.

v3: patch added to series

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-8-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
24e25ea6d7 drm/ttm: factor out ttm_bo_mmap_vma_setup 
Factor out ttm vma setup to a new function.
Reduces code duplication a bit.

v2: don't change vm_flags (moved to separate patch).
v4: make ttm_bo_mmap_vma_setup static.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-7-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
eee9a2e0ad drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPS 
DEFINE_DRM_GEM_SHMEM_FOPS is identical
to DEFINE_DRM_GEM_FOPS now, drop it.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-6-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
1bf01e1e35 drm/shmem: drop VM_IO 
VM_IO is wrong here, shmem uses normal ram not io memory.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-5-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
5da932604d drm/shmem: drop VM_DONTDUMP 
Not obvious why this is needed.  According to Deniel Vetter this is most
likely a historic artefact dating back to the days where drm drivers
exposed hardware registers as mmap'able gem objects, to avoid dumping
touching those registers.  shmem gem objects surely don't need that ...

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-4-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
0be8958936 drm/shmem: switch shmem helper to &drm_gem_object_funcs.mmap 
Switch gem shmem helper to the new mmap() workflow,
from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap.

v2: Fix vm_flags and vm_page_prot handling.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-3-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Gerd Hoffmann
c40069cb7b drm: add mmap() to drm_gem_object_funcs 
drm_gem_object_funcs->vm_ops alone can't handle everything which needs
to be done for mmap(), tweaking vm_flags for example.  So add a new
mmap() callback to drm_gem_object_funcs where this code can go to.

Note that the vm_ops field is not used in case the mmap callback is
present, it is expected that the callback sets vma->vm_ops instead.

Also setting vm_flags and vm_page_prot is the job of the new callback.
so drivers have more control over these flags.

drm_gem_mmap_obj() will use the new callback for object specific mmap
setup.  With this in place the need for driver-speific fops->mmap
callbacks goes away, drm_gem_mmap can be hooked instead.

drm_gem_prime_mmap() will use the new callback too to just mmap gem
objects directly instead of jumping though loops to make
drm_gem_object_lookup() and fops->mmap work.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-2-kraxel@redhat.com
 2019-10-17 13:59:16 +02:00
Ville Syrjälä
d4a415dcda drm/i915: Fix MST oops due to MSA changes 
The MSA MISC computation now depends on the connector state, and
we do it from the DDI .pre_enable() hook. All that is fine for
DP SST but with MST we don't actually pass the connector state
to the dig port's .pre_enable() hook which leads to an oops.

Need to think more how to solve this in a cleaner fashion, but
for now let's just add a NULL check to stop the oopsing.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Fixes: 0c06fa1560 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015190538.27539-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
 2019-10-17 13:57:00 +03:00
Tvrtko Ursulin
05488673a4 drm/i915/pmu: Support multiple GPUs 
With discrete graphics system can have both integrated and discrete GPU
handled by i915.

Currently we use a fixed name ("i915") when registering as the uncore PMU
provider which stops working in this case.

To fix this we add the PCI device name string to non-integrated devices
handled by us. Integrated devices keep the legacy name preserving
backward compatibility.

v2:
 * Detect IGP and keep legacy name. (Michal)
 * Use PCI device name as suffix. (Michal, Chris)

v3:
 * Constify the name. (Chris)
 * Use pci_domain_nr. (Chris)

v4:
 * Fix kfree_const usage. (Chris)

v5:
 * kfree_const does not work for modules. (Chris)
 * Changed is_igp helper to take i915.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016093802.12483-1-tvrtko.ursulin@linux.intel.com
 2019-10-17 10:50:47 +01:00
Khaled Almahallawy
eb8de23c95 drm/i915/tgl: Enable DDI/Port G 
In TGL there we are missing the initialization of port G.
Do the same as for other ports.

Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008220905.18278-1-khaled.almahallawy@intel.com
 2019-10-16 16:53:27 -07:00
Sebastian Andrzej Siewior
f86cf71944 drm/i810: Refer to `PREEMPTION' in comment 
The dependency has been changed from `PREEMPT' to `PREEMPTION'. Reflect
this change in the comment.

Use `PREEMPTION' in the comment.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015191821.11479-29-bigeasy@linutronix.de
 2019-10-16 21:57:59 +02:00
Chris Wilson
972c646f1c drm/i915: Move swizzle_bit under i915_ggtt 
The HW performs swizzling as part of its fence tiling inside the Global
GTT. We already do the probing of the HW settings from the GGTT setup,
complete the picture by storing the information as part of the GGTT. The
primary benefit is the consistency of our probe routines do not break
the i915_ggtt encapsulation.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016143234.4075-2-chris@chris-wilson.co.uk
 2019-10-16 19:42:19 +01:00
Chris Wilson
e9d4c9245f drm/i915: Store i915_ggtt as the backpointer on fence registers 
Now that i915_ggtt knows everything about its own paths to perform mmio,
we can use that as our primary backpointer for individual fence
registers. This reduces the amount of pointer dancing we have to perform
on the common paths, but more importantly finishes our fence register
encapsulation.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016143234.4075-1-chris@chris-wilson.co.uk
 2019-10-16 19:41:36 +01:00
Chris Wilson
eca0b72089 drm/i915: Do initial mocs configuration directly 
Now that we record the default "goldenstate" context, we do not need to
emit the mocs registers at the start of each context and can simply do
mmio before the first context and capture the registers as part of its
default image. As a consequence, this means that we repeat the mmio
after each engine reset, fixing up any platform and registers that were
zapped by the reset (for those platforms with global not context-saved
settings).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111723
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111645
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016090749.7092-1-chris@chris-wilson.co.uk
 2019-10-16 19:35:37 +01:00
Chris Wilson
0a544a2a72 drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request 
As preempt-to-busy leaves the request on the HW as the resubmission is
processed, that request may complete in the background and even cause a
second virtual request to enter queue. This second virtual request
breaks our "single request in the virtual pipeline" assumptions.
Furthermore, as the virtual request may be completed and retired, we
lose the reference the virtual engine assumes is held. Normally, just
removing the request from the scheduler queue removes it from the
engine, but the virtual engine keeps track of its singleton request via
its ve->request. This pointer needs protecting with a reference.

v2: Drop unnecessary motion of rq->engine = owner

Fixes: 22b7a426bb ("drm/i915/execlists: Preempt-to-busy")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-1-chris@chris-wilson.co.uk
(cherry picked from commit b647c7df01)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2019-10-16 10:57:33 -07:00
Chris Wilson
4f2a572eda drm/i915/userptr: Never allow userptr into the mappable GGTT 
Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to
invalidate userptr objects which also happen to be pulled into GGTT
mmaps. That is when we unbind the userptr object (on mmu invalidation),
we revoke all CPU mmaps, which may then recurse into mmu invalidation.

We looked for ways of breaking the cycle, but the revocation on
invalidation is required and cannot be avoided. The only solution we
could see was to not allow such GGTT bindings of userptr objects in the
first place. In practice, no one really wants to use a GGTT mmapping of
a CPU pointer...

Just before Daniel's explosive lockdep patches land in v5.4-rc1, we got
a genuine blip from CI:

<4>[  246.793958] ======================================================
<4>[  246.793972] WARNING: possible circular locking dependency detected
<4>[  246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G     U
<4>[  246.794003] ------------------------------------------------------
<4>[  246.794017] kswapd0/145 is trying to acquire lock:
<4>[  246.794030] 000000003f565be6 (&dev->struct_mutex/1){+.+.}, at: userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[  246.794250]
                  but task is already holding lock:
<4>[  246.794263] 000000001799cef9 (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe6/0x2a0
<4>[  246.794291]
                  which lock already depends on the new lock.

<4>[  246.794307]
                  the existing dependency chain (in reverse order) is:
<4>[  246.794322]
                  -> #3 (&anon_vma->rwsem){++++}:
<4>[  246.794344]        down_write+0x33/0x70
<4>[  246.794357]        __vma_adjust+0x3d9/0x7b0
<4>[  246.794370]        __split_vma+0x16a/0x180
<4>[  246.794385]        mprotect_fixup+0x2a5/0x320
<4>[  246.794399]        do_mprotect_pkey+0x208/0x2e0
<4>[  246.794413]        __x64_sys_mprotect+0x16/0x20
<4>[  246.794429]        do_syscall_64+0x55/0x1c0
<4>[  246.794443]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[  246.794456]
                  -> #2 (&mapping->i_mmap_rwsem){++++}:
<4>[  246.794478]        down_write+0x33/0x70
<4>[  246.794493]        unmap_mapping_pages+0x48/0x130
<4>[  246.794519]        i915_vma_revoke_mmap+0x81/0x1b0 [i915]
<4>[  246.794519]        i915_vma_unbind+0x11d/0x4a0 [i915]
<4>[  246.794519]        i915_vma_destroy+0x31/0x300 [i915]
<4>[  246.794519]        __i915_gem_free_objects+0xb8/0x4b0 [i915]
<4>[  246.794519]        drm_file_free.part.0+0x1e6/0x290
<4>[  246.794519]        drm_release+0xa6/0xe0
<4>[  246.794519]        __fput+0xc2/0x250
<4>[  246.794519]        task_work_run+0x82/0xb0
<4>[  246.794519]        do_exit+0x35b/0xdb0
<4>[  246.794519]        do_group_exit+0x34/0xb0
<4>[  246.794519]        __x64_sys_exit_group+0xf/0x10
<4>[  246.794519]        do_syscall_64+0x55/0x1c0
<4>[  246.794519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[  246.794519]
                  -> #1 (&vm->mutex){+.+.}:
<4>[  246.794519]        i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915]
<4>[  246.794519]        i915_address_space_init+0x9f/0x160 [i915]
<4>[  246.794519]        i915_ggtt_init_hw+0x55/0x170 [i915]
<4>[  246.794519]        i915_driver_probe+0xc9f/0x1620 [i915]
<4>[  246.794519]        i915_pci_probe+0x43/0x1b0 [i915]
<4>[  246.794519]        pci_device_probe+0x9e/0x120
<4>[  246.794519]        really_probe+0xea/0x3d0
<4>[  246.794519]        driver_probe_device+0x10b/0x120
<4>[  246.794519]        device_driver_attach+0x4a/0x50
<4>[  246.794519]        __driver_attach+0x97/0x130
<4>[  246.794519]        bus_for_each_dev+0x74/0xc0
<4>[  246.794519]        bus_add_driver+0x13f/0x210
<4>[  246.794519]        driver_register+0x56/0xe0
<4>[  246.794519]        do_one_initcall+0x58/0x300
<4>[  246.794519]        do_init_module+0x56/0x1f6
<4>[  246.794519]        load_module+0x25bd/0x2a40
<4>[  246.794519]        __se_sys_finit_module+0xd3/0xf0
<4>[  246.794519]        do_syscall_64+0x55/0x1c0
<4>[  246.794519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[  246.794519]
                  -> #0 (&dev->struct_mutex/1){+.+.}:
<4>[  246.794519]        __lock_acquire+0x15d8/0x1e90
<4>[  246.794519]        lock_acquire+0xa6/0x1c0
<4>[  246.794519]        __mutex_lock+0x9d/0x9b0
<4>[  246.794519]        userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[  246.794519]        __mmu_notifier_invalidate_range_start+0x85/0x110
<4>[  246.794519]        try_to_unmap_one+0x76b/0x860
<4>[  246.794519]        rmap_walk_anon+0x104/0x280
<4>[  246.794519]        try_to_unmap+0xc0/0xf0
<4>[  246.794519]        shrink_page_list+0x561/0xc10
<4>[  246.794519]        shrink_inactive_list+0x220/0x440
<4>[  246.794519]        shrink_node_memcg+0x36e/0x740
<4>[  246.794519]        shrink_node+0xcb/0x490
<4>[  246.794519]        balance_pgdat+0x241/0x580
<4>[  246.794519]        kswapd+0x16c/0x530
<4>[  246.794519]        kthread+0x119/0x130
<4>[  246.794519]        ret_from_fork+0x24/0x50
<4>[  246.794519]
                  other info that might help us debug this:

<4>[  246.794519] Chain exists of:
                    &dev->struct_mutex/1 --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem

<4>[  246.794519]  Possible unsafe locking scenario:

<4>[  246.794519]        CPU0                    CPU1
<4>[  246.794519]        ----                    ----
<4>[  246.794519]   lock(&anon_vma->rwsem);
<4>[  246.794519]                                lock(&mapping->i_mmap_rwsem);
<4>[  246.794519]                                lock(&anon_vma->rwsem);
<4>[  246.794519]   lock(&dev->struct_mutex/1);
<4>[  246.794519]
                   *** DEADLOCK ***

v2: Say no to mmap_ioctl

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111744
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111870
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190928082546.3473-1-chris@chris-wilson.co.uk
(cherry picked from commit a4311745bb)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2019-10-16 10:56:50 -07:00
Ville Syrjälä
0336ab5808 drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin 
The first come first served apporoach to handling the VBT
child device AUX ch conflicts has backfired. We have machines
in the wild where the VBT specifies both port A eDP and
port E DP (in that order) with port E being the real one.

So let's try to flip the preference around and let the last
child device win once again.

Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: Masami Ichikawa <masami256@gmail.com>
Tested-by: Torsten <freedesktop201910@liggy.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966
Fixes: 36a0f92020 ("drm/i915/bios: make child device order the priority order")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011202030.8829-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 41e35ffb38)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2019-10-16 10:56:50 -07:00
Chris Wilson
128260a41e drm/i915/execlists: Refactor -EIO markup of hung requests 
Pull setting -EIO on the hung requests into its own utility function.
Having allowed ourselves to short-circuit submission of completed
requests, we can now do the mark_eio() prior to submission and avoid
some redundant operations.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-4-chris@chris-wilson.co.uk
(cherry picked from commit 0d7cf7bc15)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2019-10-16 10:55:36 -07:00
Chris Wilson
5f65d5a6e4 drm/i915/selftests: Teach timelines to take intel_gt as its argument 
The timelines selftests are [mostly] hardware centric and so want to use
the gt as its target.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016113840.1106-1-chris@chris-wilson.co.uk
 2019-10-16 18:20:18 +01:00
Chris Wilson
bb3d4c9d63 drm/i915/selftests: Teach workarounds to take intel_gt as its argument 
The workarounds selftests are hardware centric and so want to use the gt
as its target.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016114902.24388-1-chris@chris-wilson.co.uk
 2019-10-16 18:20:05 +01:00
Chris Wilson
3b05c4f832 drm/i915/selftests: Teach guc to take intel_gt as its argument 
The guc selftests are hardware^W firmare centric and so want to use the
gt as its target.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016115311.12894-1-chris@chris-wilson.co.uk
 2019-10-16 18:19:46 +01:00
Chris Wilson
1357fa8136 drm/i915/selftests: Teach execlists to take intel_gt as its argument 
The execlists selftests are hardware centric and so want to use the gt
as its target.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016120249.22714-1-chris@chris-wilson.co.uk
 2019-10-16 18:19:29 +01:00
Matt Roper
943682e3bd drm/i915: Introduce Jasper Lake PCH 
The Jasper Lake PCH follows ICP/TGP's south display behavior and is
identical to MCC graphics-wise except that it does not use the unusual
(port C -> TC1) pin mapping that MCC does.

Also, it turns out the extra PCH ID that we had previously thought was a
form of MCC is actually a second ID for JSP (i.e., port C uses the port
C pins instead of the TC1 pins).

v2:
 - Also update the port masks (not just the pin table) in
   mcc_hpd_irq_setup.  (Vivek)

v3:
 - Break jsp_hpd_irq_setup out into its own function for clarity.
   (Vivek)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015162854.30546-1-matthew.d.roper@intel.com
 2019-10-16 07:53:20 -07:00
Matt Roper
fcb9bba47f drm/i915/ehl: Don't forget to set TC long detect function 
Since EHL's MCC PCH reuses one of the TC pins we need to supply a TC
long detect function when handling the interrupts.

Fixes: 53448aed7b ("drm/i915/ehl: Port C's hotplug interrupt is associated with TC1 bits")
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015161131.21239-1-matthew.d.roper@intel.com
Reviewed-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
 2019-10-16 07:41:26 -07:00
Ville Syrjälä
3abe897787 drm/i915: Prepare the mode readout for hw vs. uapi state split 
Prepare the mode readout for the uapi vs. hw state split.
We'll want to do all readout into the hw state.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190927131432.15978-4-ville.syrjala@linux.intel.com
 2019-10-16 16:21:23 +02:00
Ville Syrjälä
de3b67afc0 drm/i915: Prepare the connector/encoder mask readout for hw vs. uapi state split 
Prepare the connector/encoder mask readout for the uapi vs. hw
state split. We'll want to do all readout into the hw state.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190927131432.15978-2-ville.syrjala@linux.intel.com
 2019-10-16 16:20:24 +02:00
Ville Syrjälä
4078c983fe drm/i915: Switch intel_legacy_cursor_update() to intel_ types 
Prefer the intel_ types in intel_legacy_cursor_update() over the
drm_ types. Should make it easier to adapt this to the uapi vs. hw
state split.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190927131432.15978-1-ville.syrjala@linux.intel.com
 2019-10-16 16:20:12 +02:00
Ville Syrjälä
993254292b drm/i915: Refactor timestamping constants update 
Once we do the hw vs. uapi split we can no longer use
drm_atomic_helper_calc_timestamping_constants() as it'll
consult the uapi state instead of the hw state.

So let's just update the vblank timestamping constants whenever
we update the scanline offset. We use both to convert the hw
scanline count to something which matches the software timing
values.

First I thought to put these into intel_crtc_vblank_on() but
we may want to get the scanline counter value before that (eg.
from some early tracepoints), so let's stick to updating them
a bit earlier than intel_crtc_vblank_on().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191007114943.29307-3-ville.syrjala@linux.intel.com
 2019-10-16 15:58:30 +02:00
Chris Wilson
2229adc813 drm/i915/execlist: Trim immediate timeslice expiry 
We perform timeslicing immediately upon receipt of a request that may be
put into the second ELSP slot. The idea behind this was that since we
didn't install the timer if the second ELSP slot was empty, we would not
have any idea of how long ELSP[0] had been running and so giving the
newcomer a chance on the GPU was fair. However, this causes us extra
busy work that we may be able to avoid if we wait a jiffie for the first
timeslice as normal.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016100851.4979-1-chris@chris-wilson.co.uk
 2019-10-16 14:05:45 +01:00
Lowry Li (Arm Technology China)
f61714cd5b drm/komeda: Adds output-color format support 
Sets output color format according to the connector formats and
display supported formats. Default value is RGB444 and only force
YUV format which must be YUV.

Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015091019.26021-1-lowry.li@arm.com
 2019-10-16 17:54:49 +08:00
Chris Wilson
8574685547 drm/i915/selftests: Drop stale struct_mutex 
A lately added test was missed when applying the struct_mutex removal
patches. Do so now.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015085911.10317-1-chris@chris-wilson.co.uk
 2019-10-16 09:54:28 +01:00
Lowry Li (Arm Technology China)
f9204ad9cd drm/komeda: Set output color depth for output 
Set color_depth according to connector->bpc.

Changes since v1:
 - Fixed min_bpc is effectively set but not used in
komeda_crtc_get_color_config().

Changes since v2:
 - Align the code.

Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Reviewed-by: Mihail Atanassov <mihail.atanassov@arm.com>
Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191012065030.12691-1-lowry.li@arm.com
 2019-10-16 16:12:38 +08:00
Lowry Li (Arm Technology China)
f15886fa7d drm/komeda: Adds layer horizontal input size limitation check for D71 
Adds maximum line size check according to the AFBC decoder limitation
and special Line size limitation(2046) for format: YUV420_10BIT and X0L2.

Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190924080022.19250-3-lowry.li@arm.com
 2019-10-16 16:05:00 +08:00
Lowry Li (Arm Technology China)
2b2510da43 drm/komeda: Add line size support 
On D71, we are using the global line size. From D32, every
component have a line size register to indicate the fifo size.

So this patch is to set line size support and do the line size
check.

Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190924080022.19250-2-lowry.li@arm.com
 2019-10-16 16:04:56 +08:00
Thomas Zimmermann
7d79aa8628 drm/vboxvideo: Replace struct vram_framebuffer with generic implemenation 
The vboxvideo driver's struct vram_framebuffer stores a DRM framebuffer
with an assiciated GEM object. This functionality is also provided by
generic code. Switch vboxvideo over.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011134808.3955-4-tzimmermann@suse.de
 2019-10-16 09:58:59 +02:00
Thomas Zimmermann
1a74ccfac5 drm/vboxvideo: Switch to drm_atomic_helper_dirty_fb() 
The vboxvideo driver provides struct drm_framebuffer_funcs.dirty_fb from
its own implementation. Switch over to drm_atomic_helper_dirty_fb() and
handle screen updates in the primary plane's atomic_update function.

With dirty_fb out of the way, we can further replace struct vbox_frammebuffer
with generic code.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011134808.3955-3-tzimmermann@suse.de
 2019-10-16 09:58:53 +02:00
Thomas Zimmermann
2695eae1f6 drm/vboxvideo: Switch to generic fbdev emulation 
There's nothing special about vboxvideo's fbdev emulation that is
not provided by the generic implementation. Switch over and remove
the driver's code.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011134808.3955-2-tzimmermann@suse.de
 2019-10-16 09:58:30 +02:00
Biju Das
cfbcf6eb67 drm: rcar-du: lvds: Add r8a774b1 support 
The LVDS encoders on RZ/G2N SoC is similar to R-Car M3-N. Add support for
RZ/G2N (R8A774B1) SoC to the LVDS encoder driver.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
 2019-10-16 00:28:32 +03:00
Biju Das
47968ea96a drm: rcar-du: Add R8A774B1 support 
Add support for the R8A774B1 DU (which is very similar to the R8A77965 DU
except that it lacks TCON and CMM); it has one RGB output, one LVDS output
and one HDMI output.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
 2019-10-16 00:28:30 +03:00
Geert Uytterhoeven
3986457110 drm: rcar_lvds: Fix color mismatches on R-Car H2 ES2.0 and later 
Commit 5cca30ebe0 ("drm/rcar-du: Add LVDS_LANES quirk") states
that LVDS lanes 1 and 3 are inverted on R-Car H2 ES1 only, and that the
problem has been fixed in newer revisions.

However, the code didn't take into account the actual hardware revision,
thus applying the quirk also on newer hardware revisions, causing green
color reversals.

Fix this by applying the quirk when running on R-Car H2 ES1.x only.

Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: 5cca30ebe0 ("drm/rcar-du: Add LVDS_LANES quirk")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
 2019-10-16 00:27:54 +03:00
Jacopo Mondi
0a370db816 drm: rcar-du: kms: Expand comment in vsps parsing routine 
Expand comment in the 'vsps' parsing routine to specify the LIF
channel index defaults to 0 in case the second cell of the property
is not specified to remain compatible with older DT bindings.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
 2019-10-16 00:27:54 +03:00
Ahzo
ed4766022f drm/amd/display: add NULL checks for clock manager pointer 
This fixes kernel NULL pointer dereferences on shutdown:
RIP: 0010:build_audio_output.isra.0+0x97/0x110 [amdgpu]
RIP: 0010:enable_link_dp+0x186/0x300 [amdgpu]

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Ahzo <Ahzo@tutanota.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
 2019-10-15 15:55:32 -04:00
Alex Deucher
97c002be41 drm/amdgpu: enable BACO reset for SMU7 based dGPUs (v2) 
Use BACO to reset the GPU if supported on SMU7 based
dGPUs.

v2: don't use baco on CI parts

Reviewed-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
 2019-10-15 15:55:32 -04:00
Alex Deucher
2a113c74ec drm/amdgpu/powerplay: wire up BACO to powerplay API for smu7 
Wire up the powerplay callbacks for for BACO for smu7 devices.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
 2019-10-15 15:55:31 -04:00
Alex Deucher
912a0bf574 drm/amdgpu/powerplay: split out common smu7 BACO code 
Several of the BACO functions are common across smu7-based
asics.  Split the common code out.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
 2019-10-15 15:55:31 -04:00
Alex Deucher
56f68f18e0 drm/amdgpu/powerplay: add support for BACO on CI 
This adds BACO support for CI asics.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
 2019-10-15 15:55:31 -04:00
Alex Deucher
da28d1c026 drm/amdgpu/powerplay: add support for BACO on Fiji 
This adds BACO support for Fiji asics.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
 2019-10-15 15:55:31 -04:00