Commit Graph

873793 Commits

Author SHA1 Message Date
Ville Syrjälä
25f899544f drm/i915: Nuke 'mode' argument to intel_get_load_detect_pipe()
We always pass mode==NULL to intel_get_load_detect_pipe(). Remove
the pointless function argument.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029132323.18113-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2019-10-30 18:04:27 +02:00
Nathan Chancellor
5ab5e4e60a drm/amd/display: Add a conversion function for transmitter and phy_id enums
Clang warns:

../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2520:42:
error: implicit conversion from enumeration type 'enum transmitter' to
different enumeration type 'enum physical_phy_id'
[-Werror,-Wenum-conversion]
        psr_context->smuPhyId = link->link_enc->transmitter;
                              ~ ~~~~~~~~~~~~~~~~^~~~~~~~~~~
1 error generated.

As the comment above this assignment states, this is intentional. To
match previous warnings of this nature, add a conversion function that
explicitly converts between the enums and warns when there is a
mismatch.

See commit 828cfa2909 ("drm/amdgpu: Fix amdgpu ras to ta enums
conversion") and commit d9ec5cfd5a ("drm/amd/display: Use switch table
for dc_to_smu_clock_type") for previous examples of this.

v2: use PHYLD_UNKNOWN for the default case.

Fixes: e0d08a40a6 ("drm/amd/display: Add debugfs entry for reading psr state")
Link: https://github.com/ClangBuiltLinux/linux/issues/758
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:07:13 -04:00
zhong jiang
5e8f5477f9 drm/amd/display: remove redundant null pointer check before kfree
kfree has taken null pointer into account. hence it is safe to remove
the unnecessary check.

Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:07:13 -04:00
Alex Deucher
46203a508f drm/amdgpu/gmc10: properly set BANK_SELECT and FRAGMENT_SIZE
These were not aligned for optimal performance for GPUVM.

Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tianci Yin <tianci.yin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:07:13 -04:00
Le Ma
361d66edc5 drm/amdgpu: fix no ACK from LDS read during stress test for Arcturus
Set mmSQ_CONFIG.DISABLE_SMEM_SOFT_CLAUSE as W/R.

Signed-off-by: Le Ma <le.ma@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:07:13 -04:00
HaiJun Chang
897110eed5 drm/amdgpu: fix gfx VF FLR test fail on navi
Cp wptr in wb buffer is outdated after VF FLR.
The outdated wptr may cause cp to execute unexpected packets.
Reset cp wptr in wb buffer.

Signed-off-by: HaiJun Chang <HaiJun.Chang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:07:13 -04:00
Le Ma
bff77e86a3 drm/amdgpu: bypass some cleanup work after err_event_athub (v2)
PSP lost connection when err_event_athub occurs. These cleanup work can be
skipped in BACO reset.

v2: squash in missing include (Alex)

Signed-off-by: Le Ma <le.ma@amd.com>
Reviewed-by: Hawking Zhang <hawking.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:06:52 -04:00
Le Ma
8baaadba73 drm/amdgpu: clear UVD VCPU buffer when err_event_athub generated
The err_event_athub error will mess up the buffer and cause UVD resume hang.

Signed-off-by: Le Ma <le.ma@amd.com>
Reviewed-by: Hawking Zhang <hawking.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:06:51 -04:00
Jiange Zhao
b4def3744b drm/amdgpu/SRIOV: SRIOV VF doesn't support BACO
SRIOV VF doesn't support BACO.

Only PF with BACO capability can do it.

Signed-off-by: Jiange Zhao <Jiange.Zhao@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:06:51 -04:00
Geert Uytterhoeven
44b582b32a drm/amdgpu: Remove superfluous void * cast in debugfs_create_file() call
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter.  Remove it, as the cast prevents
further compiler checks.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:06:51 -04:00
YueHaibing
e4b116a2c0 drm/amdgpu: remove set but not used variable 'adev'
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1221:24: warning: variable adev set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:488:24: warning: variable adev set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:547:24: warning: variable adev set but not used [-Wunused-but-set-variable]

It is never used, so can removed it.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:06:51 -04:00
Alex Sierra
ef66915653 drm/amdkfd: bug fix for out of bounds mem on gpu cache filling info
The bitmap in cu_info structure is defined as a 4x4 size array. In
Acturus, this matrix is initialized as a 4x2. Based on the 8 shaders.
In the gpu cache filling initialization, the access to the bitmap matrix
was done as an 8x1 instead of 4x2. Causing an out of bounds memory
access error.
Due to this, the number of GPU cache entries was inconsistent.

Signed-off-by: Alex Sierra <alex.sierra@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:06:51 -04:00
Yong Zhao
533bfcaea1 drm/amdkfd: Delete duplicated queue bit map reservation
The KIQ is on the second MEC and its reservation is covered in the
latter logic, so no need to reserve its bit twice.

Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:06:51 -04:00
Yong Zhao
55695b36c1 drm/amdkfd: Delete unnecessary pr_fmt switch
Given amdkfd.ko has been merged into amdgpu.ko, this switch is no
longer useful.

Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30 11:06:51 -04:00
Imre Deak
a8ddac7c9f drm/i915: Avoid HPD poll detect triggering a new detect cycle
For the HPD interrupt functionality the HW depends on power wells in the
display core domain to be on. Accordingly when enabling these power
wells the HPD polling logic will force an HPD detection cycle to account
for hotplug events that may have happened when such a power well was
off.

Thus a detect cycle started by polling could start a new detect cycle if
a power well in the display core domain gets enabled during detect and
stays enabled after detect completes. That in turn can lead to a
detection cycle runaway.

To prevent re-triggering a poll-detect cycle make sure we drop all power
references we acquired during detect synchronously by the end of detect.
This will let the poll-detect logic continue with polling (matching the
off state of the corresponding power wells) instead of scheduling a new
detection cycle.

Fixes: 6cfe7ec02e ("drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112125
Reported-and-tested-by: Val Kulkov <val.kulkov@gmail.com>
Reported-and-tested-by: wangqr <wqr.prg@gmail.com>
Cc: Val Kulkov <val.kulkov@gmail.com>
Cc: wangqr <wqr.prg@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028181517.22602-1-imre.deak@intel.com
2019-10-30 16:31:38 +02:00
Chris Wilson
a06375a9ac drm/i915/gt: Always track callers to intel_rps_mark_interactive()
During startup, we may find ourselves in an interesting position where
we haven't fully enabled RPS before the display starts trying to use it.
This may lead to an imbalance in our "interactive" counter:

<3>[    4.813326] intel_rps_mark_interactive:652 GEM_BUG_ON(!rps->power.interactive)
<4>[    4.813396] ------------[ cut here ]------------
<2>[    4.813398] kernel BUG at drivers/gpu/drm/i915/gt/intel_rps.c:652!
<4>[    4.813430] invalid opcode: 0000 [#1] PREEMPT SMP PTI
<4>[    4.813438] CPU: 1 PID: 18 Comm: kworker/1:0H Not tainted 5.4.0-rc5-CI-CI_DRM_7209+ #1
<4>[    4.813447] Hardware name:  /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017
<4>[    4.813525] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
<4>[    4.813589] RIP: 0010:intel_rps_mark_interactive+0xb3/0xc0 [i915]
<4>[    4.813597] Code: bc 3f de e0 48 8b 35 84 2e 24 00 49 c7 c0 f3 d4 4e a0 b9 8c 02 00 00 48 c7 c2 80 9c 48 a0 48 c7 c7 3e 73 34 a0 e8 8d 3b e5 e0 <0f> 0b 90 66 2e 0f 1f 84 00 00 00 00 00 80 bf c0 00 00 00 00 74 32
<4>[    4.813616] RSP: 0018:ffffc900000efe00 EFLAGS: 00010286
<4>[    4.813623] RAX: 000000000000000e RBX: ffff8882583cc7f0 RCX: 0000000000000000
<4>[    4.813631] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888275969c00
<4>[    4.813639] RBP: 0000000000000000 R08: 0000000000000008 R09: ffff888275ace000
<4>[    4.813646] R10: ffffc900000efe00 R11: ffff888275969c00 R12: ffff8882583cc8d8
<4>[    4.813654] R13: ffff888276abce00 R14: 0000000000000000 R15: ffff88825e878860
<4>[    4.813662] FS:  0000000000000000(0000) GS:ffff888276a80000(0000) knlGS:0000000000000000
<4>[    4.813672] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[    4.813678] CR2: 00007f051d5ca0a8 CR3: 0000000262f48001 CR4: 00000000003606e0
<4>[    4.813686] Call Trace:
<4>[    4.813755]  intel_cleanup_plane_fb+0x4e/0x60 [i915]
<4>[    4.813764]  drm_atomic_helper_cleanup_planes+0x4d/0x70
<4>[    4.813833]  intel_atomic_cleanup_work+0x15/0x80 [i915]
<4>[    4.813842]  process_one_work+0x26a/0x620
<4>[    4.813850]  worker_thread+0x37/0x380
<4>[    4.813857]  ? process_one_work+0x620/0x620
<4>[    4.813864]  kthread+0x119/0x130
<4>[    4.813870]  ? kthread_park+0x80/0x80
<4>[    4.813878]  ret_from_fork+0x3a/0x50
<4>[    4.813887] Modules linked in: i915(+) mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul btusb btrtl btbcm btintel snd_hda_intel snd_intel_nhlt snd_hda_codec bluetooth snd_hwdep snd_hda_core ghash_clmulni_intel snd_pcm e1000e ecdh_generic ecc ptp pps_core mei_me mei prime_numbers
<4>[    4.813934] ---[ end trace c13289af88174ffc ]---

The solution employed is to not worry about RPS state and keep the tally
of the interactive counter separate. When we do enable RPS, we will then
take the display activity into account.

Fixes: 3e7abf8141 ("drm/i915: Extract GT render power state management")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191030103827.2413-1-chris@chris-wilson.co.uk
2019-10-30 13:23:00 +00:00
Mika Kuoppala
811bb3db25 drm/i915/tgl: Add gam instdone
This has been asked from us already. Prepare for the next
time.

Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029163841.5224-2-mika.kuoppala@linux.intel.com
2019-10-30 09:15:27 +00:00
Mika Kuoppala
e50dbdbfd9 drm/i915/tgl: Add SFC instdone to error state
On debugging media workload hangs, sfc instdone
might prove useful in future. Be prepared.

Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029163841.5224-1-mika.kuoppala@linux.intel.com
2019-10-30 09:15:27 +00:00
Lucas De Marchi
b3545e0868 drm/i915/tgl: add support to one DP-MST stream
This is the minimum change to support 1 (and only 1) DP-MST monitor
connected on Tiger Lake. This change was isolated from previous patch
from José. In order to support more streams we will need to create a
master-slave relation on the transcoders and that is not currently
working yet.

v2: remove unused macro and use REG_FIELD_PREP() (Ville)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029035049.5907-1-lucas.demarchi@intel.com
2019-10-29 17:44:53 -07:00
Dave Airlie
57c2af791b Merge tag 'topic/mst-suspend-resume-reprobe-2019-10-29-2' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
UAPI Changes:

Cross-subsystem Changes:

Core Changes:
* Handle UP requests asynchronously in the DP MST helpers, fixing
  hotplug notifications and allowing us to implement suspend/resume
  reprobing
* Add basic suspend/resume reprobing to the DP MST helpers
* Improve locking for link address reprobing and connection status
  request handling in the DP MST helpers
* Miscellaneous refactoring in the DP MST helpers
* Add a Kconfig option to the DP MST helpers to enable tracking of
  gets/puts for topology references for debugging purposes

Driver Changes:
* nouveau: Resume hotplug interrupts earlier, so that sideband
  messages may be transmitted during resume and thus allow
  suspend/resume reprobing for DP MST to work
* nouveau: Avoid grabbing runtime PM references when handling short DP
  pulses, so that handling sideband messages in resume codepaths with the
  DP MST helpers doesn't deadlock us
* i915, nouveau, amdgpu, radeon: Use detect_ctx for probing MST
  connectors, so that we can grab the topology manager's atomic lock

Note: there's some amdgpu patches that I didn't realize were pushed
upstream already when creating this topic branch. When they fail to
apply, you can just ignore and skip them.

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a74c6446bc960190d195a751cb6d8a00a98f3974.camel@redhat.com
2019-10-30 09:51:03 +10:00
Chris Wilson
a0e047156c drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.

The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.

Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.

The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.

We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.

Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-29 21:02:52 +00:00
Dave Airlie
8c84b43f17 Fix a build warning at mixer driver
- it fixes a build warning message, 'static' is not at beginning
   of declaration [-Wold-style-declaration], by moving static keyword.
 -----BEGIN PGP SIGNATURE-----
 
 iQGzBAABCgAdFiEEaNgt5qhas/jh16fIAgVwiH27uaUFAl22350ACgkQAgVwiH27
 uaX4jAv7BXxBo4ZUCcS5lACuE/75rn7xnxJ3lBFolNaWXCudaWGf48SPHHkSq/9Q
 UM0gYs8szMzCupT8ueQfw62xQraQ6G65JJIMm16a5wPUau2mCOtkrflkFKxaAZCQ
 LKIYRhrmSTsK3ysUh0Q60D2Us/I6RuCDbp2yMHOm/1cwXCZwDblwlAcvsdaYPdDZ
 RhQ1vJBC06KPaehv7QlLgBz4BeMGubzk8vR0IPnTK5T3ieooGr9x5vTDx3NTOg27
 /q1Zd4NQWdustXCMyB8JOrzTlmfIh0PUL6q0Nd9Taf/I0I/zGOyaXXbw5brxi849
 UnkH5+zFDG8zfwRiASJkMG8mJRdhK/eRyCkM1MjCsu3Ag5ZkSCdEiGy4WUxosTsC
 EGeAsLr7KnFt40rwHHJwP+A3GEfAlSkdUPW9FT7IzFzPDuJm87eMu3c8SaZulqEU
 ycDvXoxLfaoao3IUBwI+BwFSZ6evWrlL3sVFPnYyaujxYy2vfPTolSZvyC8W00Jd
 s+3z2T9w
 =TA+Z
 -----END PGP SIGNATURE-----

Merge tag 'exynos-drm-next-for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next

Fix a build warning at mixer driver
- it fixes a build warning message, 'static' is not at beginning
  of declaration [-Wold-style-declaration], by moving static keyword.

Signed-off-by: Dave Airlie <airlied@redhat.com>

# gpg: Signature made Mon 28 Oct 2019 10:31:25 PM AEST
# gpg:                using RSA key 020570887DBBB9A5
# gpg: Can't check signature: public key not found
From: Inki Dae <daeinki@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028123434.30034-1-daeinki@gmail.com
2019-10-30 06:35:20 +10:00
Dave Airlie
a24e4b09dc drm-misc-next for 5.5:
UAPI Changes:
 -syncobj: allow querying the last submitted timeline value (David)
 -fourcc: explicitly defineDRM_FORMAT_BIG_ENDIAN as unsigned (Adam)
 -omap: revert the OMAP_BO_* flags that were added -- no userspace (Sean)
 
 Cross-subsystem Changes:
 -MAINTAINERS: add Mihail as komeda co-maintainer (Mihail)
 
 Core Changes:
 -edid: a few cleanups, add AVI infoframe bar info (Ville)
 -todo: remove i915 device_link item and add difficulty levels (Daniel)
 -dp_helpers: add a few new helpers to parse dpcd (Thierry)
 
 Driver Changes:
 -gma500: fix a few memory disclosure leaks (Kangjie)
 -qxl: convert to use the new drm_gem_object_funcs.mmap (Gerd)
 -various: open code dp_link helpers in preparation for helper removal (Thierry)
 
 Cc: Chunming Zhou <david1.zhou@amd.com>
 Cc: Adam Jackson <ajax@redhat.com>
 Cc: Sean Paul <seanpaul@chromium.org>
 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Cc: Kangjie Lu <kjlu@umn.edu>
 Cc: Mihail Atanassov <mihail.atanassov@arm.com>
 Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
 Cc: Thierry Reding <treding@nvidia.com>
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEHF6rntfJ3enn8gh8cywAJXLcr3kFAl2xxiYACgkQcywAJXLc
 r3mJowf/U9ANPuvF+lahI6IVKpE4KD8Pz+73uNhjmxq5TnmcA7eNJ2pb8HO38tU2
 lkchhaQEGZR96nVL962DkegEDu8p08RpYYwKv8r+sDV+zw/aviN/ANLSmTVtZ//m
 wzgUI7zIqF1WxKdFEzNmQVuY0hYd4fWBn6kGvw1jS/6xL2/3KR6hKVigBZwkICSt
 /ZiCZyxA7HhAlqzasn+PqGkuLVYv6NvFu4Ug6YG4nBOh57IrKmGt1a6cEUjGsHFf
 6Ets5wTPu2ydMRvY+v6rUDDRj6JJQph7Lv4hVKtg13FerJ1+OQ7xjhu4gIk1oNl/
 7zIgRWMVZj79ksMXyk6zgFD2rZAF3w==
 =Fm3U
 -----END PGP SIGNATURE-----

Merge tag 'drm-misc-next-2019-10-24-2' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

drm-misc-next for 5.5:

UAPI Changes:
-syncobj: allow querying the last submitted timeline value (David)
-fourcc: explicitly defineDRM_FORMAT_BIG_ENDIAN as unsigned (Adam)
-omap: revert the OMAP_BO_* flags that were added -- no userspace (Sean)

Cross-subsystem Changes:
-MAINTAINERS: add Mihail as komeda co-maintainer (Mihail)

Core Changes:
-edid: a few cleanups, add AVI infoframe bar info (Ville)
-todo: remove i915 device_link item and add difficulty levels (Daniel)
-dp_helpers: add a few new helpers to parse dpcd (Thierry)

Driver Changes:
-gma500: fix a few memory disclosure leaks (Kangjie)
-qxl: convert to use the new drm_gem_object_funcs.mmap (Gerd)
-various: open code dp_link helpers in preparation for helper removal (Thierry)

Cc: Chunming Zhou <david1.zhou@amd.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kangjie Lu <kjlu@umn.edu>
Cc: Mihail Atanassov <mihail.atanassov@arm.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024155535.GA10294@art_vandelay
2019-10-30 06:11:47 +10:00
Matt Roper
5451646467 drm/i915: Provide more information on DP AUX failures
We're seeing some failures where an aux transaction still shows as
'busy' well after the timeout limit that the hardware is supposed to
enforce.  Improve the error message so that we can see exactly which aux
channel this error happened on and what the status bits were during this
case that isn't supposed to happen.

v2:
 - Make timeout a const variable so that the timeout & message will
   match if we decide to change it in the future.  (Lucas)
 - Don't bother testing intel_dp->aux.name for NULL.  (Lucas)

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029173102.9451-1-matthew.d.roper@intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2019-10-29 12:54:11 -07:00
Dave Airlie
60845e34f0 Merge tag 'drm-next-5.5-2019-10-25' of git://people.freedesktop.org/~agd5f/linux into drm-next
drm-next-5.5-2019-10-25:

amdgpu:
- BACO support for CI and VI asics
- Quick memory training support for navi
- MSI-X support
- RAS fixes
- Display AVI infoframe fixes
- Display ref clock fixes for renoir
- Fix number of audio endpoints in renoir
- Fix for discovery tables
- Powerplay fixes
- Documentation fixes
- Misc cleanups

radeon:
- revert a PPC fix which broke x86

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025221020.203546-1-alexander.deucher@amd.com
2019-10-30 05:46:09 +10:00
José Roberto de Souza
0f9ed3b2c9 drm/i915/display/cnl+: Handle fused off DSC
DSC could be fused off, so not all GEN10+ platforms will support it.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-5-jose.souza@intel.com
2019-10-29 12:12:49 -07:00
José Roberto de Souza
ee595888e1 drm/i915/display/icl+: Check if DMC is fused off
Check if DMC is fused off and handle it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-4-jose.souza@intel.com
2019-10-29 12:12:48 -07:00
José Roberto de Souza
7a40aac1d7 drm/i915/display: Check if FBC is fused off
Check if FBC is fused off and handle it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-3-jose.souza@intel.com
2019-10-29 12:12:47 -07:00
José Roberto de Souza
74393109a8 drm/i915/display: Handle fused off HDCP
HDCP could be fused off, so not all GEN9+ platforms will support it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-2-jose.souza@intel.com
2019-10-29 12:12:45 -07:00
José Roberto de Souza
a20e26d842 drm/i915: Add two spaces before the SKL_DFSM registers
The next patches are going to touch this registers so here already
fixing it for older registers and make it consistent with most of
the other registers in this file.

Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-1-jose.souza@intel.com
2019-10-29 12:12:44 -07:00
Lionel Landwerlin
bf96b51508 drm/i915/perf: ensure selftests select valid format
Gen12 only support a single report format :
I915_OA_FORMAT_A32u40_A4u32_B8_C8

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 00a7f0d715 ("drm/i915/tgl: Add perf support on TGL")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029142826.20014-1-lionel.g.landwerlin@intel.com
2019-10-29 18:58:07 +00:00
Rob Herring
83b8a6f242 drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
Commit c40069cb7b ("drm: add mmap() to drm_gem_object_funcs")
introduced a GEM object mmap() hook which is expected to subtract the
fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
a fake offset.

To fix this, let's always call mmap() object callback with an offset of 0,
and leave it up to drm_gem_mmap_obj() to remove the fake offset.

TTM still needs the fake offset, so we have to add it back until that's
fixed.

Fixes: c40069cb7b ("drm: add mmap() to drm_gem_object_funcs")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024191859.31700-1-robh@kernel.org
2019-10-29 13:29:21 -05:00
Steven Price
9e62b885f7 drm/panfrost: Simplify devfreq utilisation tracking
Instead of tracking per-slot utilisation track a single value for the
entire GPU. Ultimately it doesn't matter if the GPU is busy with only
vertex or a combination of vertex and fragment processing - if it's busy
then it's busy and devfreq should be scaling appropriately.

This also makes way for being able to submit multiple jobs per slot
which requires more values than the original boolean per slot.

Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025134143.14324-3-steven.price@arm.com
2019-10-29 13:01:51 -05:00
Steven Price
221bc77914 drm/panfrost: Use generic code for devfreq
Use dev_pm_opp_set_rate() instead of open coding the devfreq
integration, simplifying the code.

Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025134143.14324-2-steven.price@arm.com
2019-10-29 13:01:36 -05:00
Matt Roper
6a3552527d drm/i915/tgl: Add AUX B & C to DC_OFF_POWER_DOMAINS
Our TGL CI platforms are running into cases where aux transactions have
failed to complete or declare a timeout well after the timeout limit
that the hardware is supposed to enforce.  From the logs it appears that
these failures arise when aux transactions happen after we've entered
DC6:

  <7> [622.523650] [drm:skl_enable_dc6 [i915]] Enabling DC6
  <7> [622.523685] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02
  ...
  <3> [622.535753] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.547745] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.559746] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.571744] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.583743] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.583780] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp_aux_ch not done status 0xad400bff
  <7> [622.863725] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110

On TGL AUX B & C are in PG1 (managed by the DMC firmware) rather
than PG3 as they were on ICL, so allowing DC6 means the DMC firmware
might shut off the power wells behind our backs when we're trying to use
them.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025230623.27829-6-matthew.d.roper@intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-10-29 10:50:34 -07:00
Matt Roper
47c41af706 drm/i915: Drop unused AUX register offsets
We reference DP AUX registers via the DP_AUX_CH_CTL() and
DP_AUX_CH_DATA() macros that calculate all the register offsets for us
automatically; there's no need to explicitly define every offset in
i915_reg.h if they're never going to be used by the driver code.

v2: Apparently GVT was directly using these raw definitions in a couple
    places.  Switch GVT code over to using our preferred macros.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>  #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20191026051226.30807-1-matthew.d.roper@intel.com
2019-10-29 10:48:53 -07:00
Chris Wilson
b79029b2e8 drm/i915/gt: Make timeslice duration configurable
Execlists uses a scheduling quantum (a timeslice) to alternate execution
between ready-to-run contexts of equal priority. This ensures that all
users (though only if they of equal importance) have the opportunity to
run and prevents livelocks where contexts may have implicit ordering due
to userspace semaphores. However, not all workloads necessarily benefit
from timeslicing and in the extreme some sysadmin may want to disable or
reduce the timeslicing granularity.

The timeslicing mechanism can be compiled out^W^W disabled (but should
DCE!) with

	./scripts/config --set-val DRM_I915_TIMESLICE_DURATION 0

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029091632.26281-1-chris@chris-wilson.co.uk
2019-10-29 16:23:55 +00:00
Janusz Krzysztofik
4ec37538a6 drm/i915: Rename "inject_load_failure" module parameter
Commit f2db53f14d ("drm/i915: Replace "_load" with "_probe"
consequently") deliberately left the name of the module parameter
unchanged as that would require a corresponding change on IGT size.
Now as the IGT side change has been submitted, complete the switch to
the "probe" nomenclature.

Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029102036.6326-3-janusz.krzysztofik@linux.intel.com
2019-10-29 15:37:57 +00:00
Janusz Krzysztofik
dd6e38dfc1 drm/i915: Fix i915_inject_load_error() name to read *_probe_*
Commit 50d84418f5 ("drm/i915: Add i915 to i915_inject_probe_failure")
introduced new functions unfortunately named incompatibly with rules
established by commit f2db53f14d ("drm/i915: Replace "_load" with
"_probe" consequently").  Fix it for consistency.

Suggested-by: Michał Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029102036.6326-2-janusz.krzysztofik@linux.intel.com
2019-10-29 15:37:57 +00:00
Thierry Reding
fa6661b7aa drm/tegra: Optionally attach clients to the IOMMU
If a client is already attached to an IOMMU domain that is not the
shared domain, don't try to attach it again. This allows using the
IOMMU-backed DMA API.

Since the IOMMU-backed DMA API is now supported and there's no way
to detach from it on 64-bit ARM, don't bother to detach from it on
32-bit ARM either.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:37 +01:00
Thierry Reding
2e8d8749f6 drm/tegra: Support DMA API for display controllers
If a display controller is not attached to an explicit IOMMU domain,
which usually means that it's connected to an IOMMU domain controlled by
the DMA API, make sure to map the framebuffer to the display controller
address space. This allows us to transparently handle setups where the
display controller is attached to an IOMMU or setups where it isn't. It
also allows the driver to work with a DMA API that is backed by an
IOMMU.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:36 +01:00
Thierry Reding
d972d62476 drm/tegra: falcon: Clarify address usage
Rename paddr -> iova and vaddr -> virt to make it clearer how these
addresses are used. This is important for a subsequent patch that makes
a distinction between the physical address (physical address of the
system memory from the CPU's point of view) and the IOVA (physical
address of the system memory from the device's point of view).

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:36 +01:00
Thierry Reding
20e7dce255 drm/tegra: Remove memory allocation from Falcon library
Having to provide allocator hooks to the Falcon library is somewhat
cumbersome and it doesn't give the users of the library a lot of
flexibility to deal with allocations. Instead, remove the notion of
Falcon "operations" and let drivers deal with the memory allocations
themselves.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:36 +01:00
Thierry Reding
06867a362d gpu: host1x: Set DMA mask based on IOMMU setup
If the Tegra DRM clients are backed by an IOMMU, push buffers are likely
to be allocated beyond the 32-bit boundary if sufficient system memory
is available. This is problematic on earlier generations of Tegra where
host1x supports a maximum of 32 address bits for the GATHER opcode. More
recent versions of Tegra (Tegra186 and later) have a wide variant of the
GATHER opcode, which allows addressing up to 64 bits of memory.

If host1x itself is behind an IOMMU as well this doesn't matter because
the IOMMU's input address space is restricted to 32 bits on generations
without support for wide GATHER opcodes.

However, if host1x is not behind an IOMMU, it won't be able to process
push buffers beyond the 32-bit boundary on Tegra generations that don't
support wide GATHER opcodes. Restrict the DMA mask to 32 bits on these
generations prevents buffers from being allocated from beyond the 32-bit
boundary.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:35 +01:00
Thierry Reding
af1cbfb9bf gpu: host1x: Support DMA mapping of buffers
If host1x_bo_pin() returns an SG table, create a DMA mapping for the
buffer. For buffers that the host1x client has already mapped itself,
host1x_bo_pin() returns NULL and the existing DMA address is used.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:35 +01:00
Thierry Reding
b78e70c04c gpu: host1x: Allocate gather copy for host1x
Currently when the gather buffers are copied, they are copied to a
buffer that is allocated for the host1x client that wants to execute the
command streams in the buffers. However, the gather buffers will be read
by the host1x device, which causes SMMU faults if the DMA API is backed
by an IOMMU.

Fix this by allocating the gather buffer copy for the host1x device,
which makes sure that it will be mapped into the host1x's IOVA space if
the DMA API is backed by an IOMMU.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:35 +01:00
Thierry Reding
ab4f81bfc2 gpu: host1x: Add direction flags to relocations
Add direction flags to host1x relocations performed during job pinning.
These flags indicate the kinds of accesses that hardware is allowed to
perform on the relocated buffers.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:34 +01:00
Thierry Reding
44156eee91 gpu: host1x: Clean up debugfs on removal
The debugfs files created for host1x are never removed, causing these
files to be left dangling in debugfs. This results in a crash when any
of these files are accessed after the host1x driver has been removed,
as well as a failure to create the debugfs entries when they are added
again on driver probe.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:34 +01:00
Thierry Reding
80327ce3d4 gpu: host1x: Overhaul host1x_bo_{pin,unpin}() API
The host1x_bo_pin() and host1x_bo_unpin() APIs are used to pin and unpin
buffers during host1x job submission. Pinning currently returns the SG
table and the DMA address (an IOVA if an IOMMU is used or a physical
address if no IOMMU is used) of the buffer. The DMA address is only used
for buffers that are relocated, whereas the host1x driver will map
gather buffers into its own IOVA space so that they can be processed by
the CDMA engine.

This approach has a couple of issues. On one hand it's not very useful
to return a DMA address for the buffer if host1x doesn't need it. On the
other hand, returning the SG table of the buffer is suboptimal because a
single SG table cannot be shared for multiple mappings, because the DMA
address is stored within the SG table, and the DMA address may be
different for different devices.

Subsequent patches will move the host1x driver over to the DMA API which
doesn't work with a single shared SG table. Fix this by returning a new
SG table each time a buffer is pinned. This allows the buffer to be
referenced by multiple jobs for different engines.

Change the prototypes of host1x_bo_pin() and host1x_bo_unpin() to take a
struct device *, specifying the device for which the buffer should be
pinned. This is required in order to be able to properly construct the
SG table. While at it, make host1x_bo_pin() return the SG table because
that allows us to return an ERR_PTR()-encoded error code if we need to,
or return NULL to signal that we don't need the SG table to be remapped
and can simply use the DMA address as-is. At the same time, returning
the DMA address is made optional because in the example of command
buffers, host1x doesn't need to know the DMA address since it will have
to create its own mapping anyway.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:34 +01:00
Thierry Reding
7edd7961e5 drm/tegra: Simplify IOMMU group selection
All the devices that make up the DRM device are now part of the same
IOMMU group. This simplifies the handling of the IOMMU attachment and
also avoids exhausting the number of IOMMUs available on early Tegra
SoC generations.

Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29 15:04:34 +01:00