Commit Graph

62866 Commits

Author SHA1 Message Date
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
Alex Deucher
28e82af499 drm/amdgpu/powerplay: add support for BACO on VegaM
This adds BACO support for VegaM 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
1b0575bdc4 drm/amdgpu/powerplay: add support for BACO on polaris
This adds BACO support for Polaris 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
f07fb0244f drm/amdgpu/powerplay: add support for BACO on Iceland
This adds BACO support for Iceland 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
cefada559b drm/amdgpu/powerplay: add support for BACO on tonga
This adds BACO support for Tonga.

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
42e547efe2 drm/amdgpu/powerplay: add core support for pre-SOC15 baco
This adds core support for BACO on pre-vega 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
5d934ac0d0 drm/amdgpu: add new SMU 7.1.3 registers for BACO
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
9fc00ea774 drm/amdgpu: add new SMU 7.1.2 registers for BACO
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
c74c524e7c drm/amdgpu: add new SMU 7.0.1 registers for BACO
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
c06a91c0f8 drm/amdgpu: add new BIF 5.0 register for BACO
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
8763eb7ae9 drm/amdgpu: add new BIF 4.1 register for BACO
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
5337aae9b5 drm/amdgpu/soc15: add support for baco reset with swSMU
Add support for vega20 when the swSMU path is used.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-15 15:55:31 -04:00
Alex Deucher
31fa2991f4 drm/amdgpu: remove in_baco_reset hack
It was a vega20 specific hack.  Check if we are in reset
and what reset method we are using.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-15 15:51:39 -04:00
Alex Deucher
f5fda6d89a drm/amdgpu: simplify ATPX detection
Use the base class rather than the specific class and drop
the second loop.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-15 15:51:39 -04:00
Alex Deucher
897483d8a0 drm/amdgpu: move gpu reset out of amdgpu_device_suspend
Move it into the caller.  There are cases were we don't
want it.  We need it for hibernation, but we don't need
it for runtime pm, so drop it for runtime pm.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-15 15:51:39 -04:00
Alex Deucher
803cc26d5c drm/amdgpu: move pci_save_state into suspend path
for amdgpu_device_suspend.  This follows the logic
in the resume path.

Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-15 15:51:39 -04:00
Alex Deucher
1489d17940 Revert "drm/radeon: Fix EEH during kexec"
This reverts commit 6f7fe9a93e.

This breaks some boards.  Maybe just enable this on PPC for
now?

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205147
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-15 15:51:31 -04:00
Hersen Wu
e70bd049d0 drm/amdgpu/display: fix build error casused by CONFIG_DRM_AMD_DC_DCN2_1
when CONFIG_DRM_AMD_DC_DCN2_1 is not enable in .config,
there is build error. struct dpm_clocks shoud not be
guarded.

Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-15 15:51:25 -04:00
Hersen Wu
71a0df4be6 drm/amdgpu/display: hook renoir dc to pplib funcs
enable dc get dmp clock table and set dcn watermarks
via pplib.

Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-15 15:51:18 -04:00