aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-11-19drm/i915/perf: workaround register corruption in OATAILPTRLionel Landwerlin2-2/+9
After having written the entire OA buffer with reports, the HW will write again at the beginning of the OA buffer. It'll indicate it by setting the WRAP bits in the OASTATUS register. When a wrap happens and that at the end of the read vfunc we write the OASTATUS register back to clear the REPORT_LOST bit, we sometimes see that the OATAILPTR register is reset to a previous position on Gen8/9 (apparently not the case on Gen11+). This leads the next call to the read vfunc to process reports we've already read. Because we've marked those as read by clearing the reason & timestamp dwords, they're discarded and a "Skipping spurious, invalid OA report" message is emitted. The workaround to avoid this OATAILPTR value reset seems to be to set the wrap bits when writing back OASTATUS. This change has no impact on userspace, it only avoids a bunch of DRM_NOTE("Skipping spurious, invalid OA report\n") messages. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 19f81df2859eb1 ("drm/i915/perf: Add OA unit support for Gen 8+") Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117130124.829979-1-lionel.g.landwerlin@intel.com
2020-11-19drm/vc4: kms: Split the HVS muxing check in a separate functionMaxime Ripard1-3/+15
The code that assigns HVS channels during atomic_check is starting to grow a bit big, let's move it into a separate function. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-5-maxime@cerno.tech
2020-11-19drm/vc4: kms: Rename NUM_CHANNELSMaxime Ripard1-3/+3
The NUM_CHANNELS define has a pretty generic name and was right before the function using it. Let's move to something that makes the hardware-specific nature more obvious, and to a more appropriate place. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-4-maxime@cerno.tech
2020-11-19drm/vc4: kms: Remove useless defineMaxime Ripard1-1/+0
NUM_OUTPUTS isn't used anymore, let's remove it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-3-maxime@cerno.tech
2020-11-19drm/vc4: kms: Switch to drmm_add_action_or_resetMaxime Ripard1-2/+2
Even though it was pointed in the review by Daniel, and I thought to have fixed it while applying the patches, but it turns out I forgot to commit the fixes in the process. Properly fix it this time. Fixes: dcda7c28bff2 ("drm/vc4: kms: Add functions to create the state objects") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-2-maxime@cerno.tech
2020-11-19drm/vc4: hdmi: Block odd horizontal timingsMaxime Ripard2-0/+15
The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels per clock cycle, and cannot deal with odd timings. Let's reject any mode with such timings. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201029122522.1917579-2-maxime@cerno.tech
2020-11-19drm/vc4: hdmi: Make sure our clock rate is within limitsMaxime Ripard1-0/+15
The HDMI controller cannot go above a certain pixel rate limit depending on the generations, but that limit is only enforced in mode_valid at the moment, which means that we won't advertise modes that exceed that limit, but the userspace is still free to try to setup a mode that would. Implement atomic_check to make sure we check it in that scenario too. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201029122522.1917579-1-maxime@cerno.tech
2020-11-19drm/ttm: fix DMA32 handling in the global page poolChristian König1-0/+22
When we have mixed DMA32 and non DMA32 device in one system it could otherwise happen that the DMA32 device gets pages it can't work with. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/401317/
2020-11-19mm: introduce vma_set_file function v5Christian König6-14/+8
Add the new vma_set_file() function to allow changing vma->vm_file with the necessary refcount dance. v2: add more users of this. v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup, add comments why we drop the reference on two occasions. v4: make it clear that changing an anonymous vma is illegal. v5: move vma_set_file to mm/util.c Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2) Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Link: https://patchwork.freedesktop.org/patch/399360/
2020-11-19Merge tag 'drm/sun4i-dma-fix-pull-request' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-misc-fixesMaxime Ripard1-1/+7
Fix for drm/sun4i shared with arm-soc This patch is a preliminary fix that will conflict with subsequent work merged through arm-soc. Signed-off-by: Maxime Ripard <maxime@cerno.tech> # gpg: Signature made Wed 18 Nov 2020 09:51:53 AM CET # gpg: using EDDSA key 5C1337A45ECA9AEB89060E9EE3EF0D6F671851C5 # gpg: Good signature from "Maxime Ripard <maxime.ripard@anandra.org>" [unknown] # gpg: aka "Maxime Ripard <mripard@kernel.org>" [unknown] # gpg: aka "Maxime Ripard (Work Address) <maxime.ripard@bootlin.com>" [unknown] # gpg: aka "Maxime Ripard (Work Address) <maxime@bootlin.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: BE56 75C3 7E81 8C8B 5764 241C 254B CFC5 6BF6 CE8D # Subkey fingerprint: 5C13 37A4 5ECA 9AEB 8906 0E9E E3EF 0D6F 6718 51C5 From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201118090455.sznrgpduuytlc22k@gilmour.lan
2020-11-19drm/i915/gvt: Remove incorrect kerneldoc markingChris Wilson1-1/+1
Just a normal comment, not a kerneldoc function description. drivers/gpu/drm/i915/gvt/handlers.c:1666: warning: Function parameter or member 'vgpu' not described in 'bxt_ppat_low_write' drivers/gpu/drm/i915/gvt/handlers.c:1666: warning: Function parameter or member 'offset' not described in 'bxt_ppat_low_write' drivers/gpu/drm/i915/gvt/handlers.c:1666: warning: Function parameter or member 'p_data' not described in 'bxt_ppat_low_write' drivers/gpu/drm/i915/gvt/handlers.c:1666: warning: Function parameter or member 'bytes' not described in 'bxt_ppat_low_write' Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201103204307.15723-1-chris@chris-wilson.co.uk
2020-11-19Merge tag 'gvt-fixes-2020-11-17' of https://github.com/intel/gvt-linux into drm-intel-fixesRodrigo Vivi3-3/+6
gvt-fixes-2020-11-17 - Temporarily disable VFIO edid on BXT/APL (Colin) - Fix emulated DPCD for version 1.2 (Tina) - Fix error return when failing to take module reference (Xiongfeng) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117023918.GB23899@zhen-hp.sh.intel.com
2020-11-19drm/i915/gt: Remember to free the virtual breadcrumbsChris Wilson1-0/+1
Since we allocate some breadcrumbs for the virtual engine, and the virtual engine has a custom destructor, we also need to free the breadcrumbs after use. Fixes: b3786b29379c ("drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs") 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/20201118133839.1783-1-chris@chris-wilson.co.uk (cherry picked from commit 45e50f48b7907e650cfbbc7879abfe3a0c419c73) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-11-19drm/i915: Handle max_bpc==16Ville Syrjälä1-1/+2
EDID can declare the maximum supported bpc up to 16, and apparently there are displays that do so. Currently we assume 12 bpc is tha max. Fix the assumption and toss in a MISSING_CASE() for any other value we don't expect to see. This fixes modesets with a display with EDID max bpc > 12. Previously any modeset would just silently fail on platforms that didn't otherwise limit this via the max_bpc property. In particular we don't add the max_bpc property to HDMI ports on gmch platforms, and thus we would see the raw max_bpc coming from the EDID. I suppose we could already adjust this to also allow 16bpc, but seeing as no current platform supports that there is little point. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2632 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201110210447.27454-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 2ca5a7b85b0c2b97ef08afbd7799b022e29f192e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-11-18drm/i915/gt: Remember to free the virtual breadcrumbsChris Wilson1-0/+1
Since we allocate some breadcrumbs for the virtual engine, and the virtual engine has a custom destructor, we also need to free the breadcrumbs after use. Fixes: b3786b29379c ("drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs") 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/20201118133839.1783-1-chris@chris-wilson.co.uk
2020-11-18drm/via: fix assignment in if conditionBernard Zhao1-3/+4
Fix check_patch.pl warning: ERROR: do not use assignment in if condition + if ((HALCYON_HEADER2 == (cmd = *buf)) && ERROR: do not use assignment in if condition + if (HALCYON_HEADER2 == (cmd = *buf)) Signed-off-by: Bernard Zhao <bernard@vivo.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201118114021.105502-1-bernard@vivo.com
2020-11-18drm/amd/display: Always get CRTC updated constant values inside commit tailRodrigo Siqueira1-1/+2
We recently improved our display atomic commit and tail sequence to avoid some issues related to concurrency. One of the major changes consisted of moving the interrupt disable and the stream release from our atomic commit to our atomic tail (commit 6d90a208cfff ("drm/amd/display: Move disable interrupt into commit tail")) . However, the new code introduced inside our commit tail function was inserted right after the function drm_atomic_helper_update_legacy_modeset_state(), which has routines for updating internal data structs related to timestamps. As a result, in certain conditions, the display module can reach a situation where we update our constants and, after that, clean it. This situation generates the following warning: amdgpu 0000:03:00.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) WARNING: CPU: 6 PID: 1269 at drivers/gpu/drm/drm_vblank.c:722 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x32b/0x340 [drm] ... RIP: 0010:drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x32b/0x340 [drm] ... Call Trace: ? dc_stream_get_vblank_counter+0x57/0x60 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x20 [drm] drm_get_last_vbltimestamp+0xad/0xc0 [drm] drm_reset_vblank_timestamp+0x63/0xd0 [drm] drm_crtc_vblank_on+0x85/0x150 [drm] amdgpu_dm_atomic_commit_tail+0xaf1/0x2330 [amdgpu] commit_tail+0x99/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] amdgpu_dm_atomic_commit+0x11/0x20 [amdgpu] drm_atomic_commit+0x4a/0x50 [drm] drm_atomic_helper_set_config+0x7c/0xc0 [drm_kms_helper] drm_mode_setcrtc+0x20b/0x7e0 [drm] ? tomoyo_path_number_perm+0x6f/0x200 ? drm_mode_getcrtc+0x190/0x190 [drm] drm_ioctl_kernel+0xae/0xf0 [drm] drm_ioctl+0x245/0x400 [drm] ? drm_mode_getcrtc+0x190/0x190 [drm] amdgpu_drm_ioctl+0x4e/0x80 [amdgpu] __x64_sys_ioctl+0x91/0xc0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... For fixing this issue we rely upon a refactor introduced on drm_atomic_helper_update_legacy_modeset_state ("Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()") which decouples constant values update from drm_atomic_helper_update_legacy_modeset_state to a new helper. Basically, this commit uses this new helper and place it right after our release module to avoid a situation where our CRTC struct gets wrong values. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1373 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1349 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-18drm/i915: Enable bigjoinerVille Syrjälä1-3/+0
Enough plumbing should be in place to throw the bigjoiner switch. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-16-manasi.d.navare@intel.com
2020-11-18drm/i915: Add bigjoiner state dumpVille Syrjälä1-0/+4
Add a big of bigjoiner information to the state dump. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-15-manasi.d.navare@intel.com
2020-11-18drm/i915: Fix cursor src/dst rectangle with bigjoinerVille Syrjälä1-2/+4
We can't call drm_plane_state_src() this late for the slave plane since it would consult the wrong uapi state. We've alreayd done the correct uapi->hw copy earlier, so let's just preserve the unclipped src/dst rects using a temp copy across the intel_atomic_plane_check_clipping() call. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-14-manasi.d.navare@intel.com
2020-11-18drm/i915: Disable legacy cursor fastpath for bigjoinerVille Syrjälä1-1/+3
The legacy cursor fastpath code doesn't deal with bigjoiner. Disable the fastpath for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-13-manasi.d.navare@intel.com
2020-11-18drm/i915: Add debugfs dumping for bigjoiner, v3.Maarten Lankhorst1-1/+24
Dump debugfs and planar links as well, this will make it easier to debug when things go wrong. v4: * Rebase Changes since v1: - Report planar slaves as such, now that we have the plane_state switch. Changes since v2: - Rebase on top of the new plane format dumping Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-12-manasi.d.navare@intel.com
2020-11-18drm/i915: Add bigjoiner aware plane clipping checksMaarten Lankhorst4-24/+80
We need to look at hw.fb for the framebuffer, and add the translation for the slave_plane_state. With these changes we set the correct rectangle on the bigjoiner slave, and don't set incorrect src/dst/visibility on the slave plane. v2: * Manual rebase (Manasi) v3: * hw.rotation instead of uapi.rotation (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-11-manasi.d.navare@intel.com
2020-11-18drm/i915: Get the uapi state from the correct plane when bigjoiner is usedVille Syrjälä3-21/+46
When using bigjoiner userspace is only controlling the "master" plane, so use its uapi state for the "slave" plane as well. hw.crtc needs a bit of magic since we don't want to copy that from the uapi state (as it points to the wrong pipe for the "slave " plane). Instead we pass the right crtc in explicitly but only assign it when the uapi state indicates the plane to be logically enabled (ie. uapi.crtc != NULL). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-10-manasi.d.navare@intel.com
2020-11-18drm/i915: Add planes affected by bigjoiner to the stateVille Syrjälä1-0/+42
Make sure both the bigjoiner "master" and "slave" plane are in the state whenever either of them is in the state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-9-manasi.d.navare@intel.com
2020-11-18drm/i915: Add crtcs affected by bigjoiner to the stateVille Syrjälä1-0/+25
Make sure both crtcs participating in the bigjoiner stuff are in the state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-8-manasi.d.navare@intel.com
2020-11-18drm/i915: HW state readout for Bigjoiner caseManasi Navare4-101/+230
Skip iterating over bigjoiner slaves, only the master has the state we care about. Add the width of the bigjoiner slave to the reconstructed fb. Hide the bigjoiner slave to userspace, and double the mode on bigjoiner master. And last, disable bigjoiner slave from primary if reconstruction fails. v3: * Fix the ddi_get_config slave error (Ankit Nautiyal) v2: * Unsupported bigjoiner config for initial fb (Ville) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> [vsyrjala: * Don't do any hw->uapi state copy for bigjoiner slave * We still have hw.mode so no need to pass it in * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-7-manasi.d.navare@intel.com
2020-11-18drm/i915/dp: Master/Slave enable/disable sequence for bigjoinerManasi Navare2-25/+118
Enabling is done in a special sequence and so should plane updates be. Ideally the end user never notices the second pipe is used. This way ideally everything will be tear free, and updates are really atomic as userspace expects it. This uses generic modeset_enables() calls like trans port sync but still has special handling for disable since for slave we should not disable things like encoder, plls that are not enabled for slave. Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> [vsyrjala: Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-6-manasi.d.navare@intel.com
2020-11-18drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slaveManasi Navare6-115/+108
Make vdsc work when no output is enabled. The big joiner needs VDSC on the slave, so enable it and set the appropriate bits. So remove encoder usage from dsc functions. Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-5-manasi.d.navare@intel.com
2020-11-18drm/i915: Try to make bigjoiner work in atomic checkMaarten Lankhorst3-10/+175
When the clock is higher than the dotclock, try with 2 pipes enabled. If we can enable 2, then we will go into big joiner mode, and steal the adjacent crtc. This only links the crtc's in software, no hardware or plane programming is done yet. Blobs are also copied from the master's crtc_state, so it doesn't depend at commit time on the other crtc_state. v6: * Enable dSC for any mode->hdisplay > 5120 v5: * Remove intel_dp_max_dotclock (Manasi) v4: * Fixes in intel_crtc_compute_config (Ville) v3: * Manual Rebase (Manasi) Changes since v1: - Rename pipe timings to transcoder timings, as they are now different. Changes since v2: - Rework bigjoiner checks; always disable slave when recalculating master. No need to have a separate bigjoiner pass any more. - Use pipe_mode instead of transcoder_mode, to clean up the code. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> [vsyrjala: * hskew isn't a thing * Do the dsc compute if bigjoiner is enabled, not the other way around] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-4-manasi.d.navare@intel.com
2020-11-18drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.Maarten Lankhorst7-20/+76
Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-18drm/i915: Copy the plane hw state directly for Y planesVille Syrjälä3-1/+15
When doing the plane state copy from the UV plane to the Y plane let's just copy the hw state directly instead of using the original uapi state. The UV plane has already had its uapi state copied into its hw state, so this extra detour via the uapi state for the Y plane is pointless. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-2-manasi.d.navare@intel.com
2020-11-18drm/amdgpu: add DID for dimgrey_cavefishTao Zhou1-0/+6
Add device id for dimgrey_cavefish. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Jiansong Chen <Jiansong.Chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-18drm/amdgpu: add device ID for navy_flounder (v2)Tao Zhou1-0/+6
add device ID for navy_flounder v2: squash in updates Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-18drm/amd/display: Add comments to hdcp property change codeBhawanpreet Lakha1-2/+24
[Why] These comments are helpful in understanding which case each if statement handles. [How] Add comments for state transitions (9 possible cases) Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Zhan Liu <zhan.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-18drm/amd/display: Add display only once.Bhawanpreet Lakha2-4/+14
[Why] We call add display multiple times because DESIRED->ENABLED cannot happen instantaneously. We can't compare the new_state/old_state to avoid this because on unplug we set the state to DESIRED and on hotplug the state will still be DESIRED. [How] Add a flag to dm_connector_state to keep track of when to enable or disable HDCP Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Zhan Liu <zhan.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-18drm/amd/pm: support runtime PPTable update for dimgrey_cavefishTao Zhou1-1/+1
There is no need to reset DPM for PPTable uploading on dimgrey_cavefish and PMFW can handle it, same as navy_flounder. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Jiansong Chen <Jiansong.Chen@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-18drm/amd/pm: fix smu_v11_0_init_power power_context allocationRyan Taylor1-2/+2
Allocate smu_power->power_context to size of smu_11_0_power_context instead of smu_11_0_dpm_context. Signed-off-by: Ryan Taylor <Ryan.Taylor@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-18drm/amd/display: Always get CRTC updated constant values inside commit tailRodrigo Siqueira1-1/+2
We recently improved our display atomic commit and tail sequence to avoid some issues related to concurrency. One of the major changes consisted of moving the interrupt disable and the stream release from our atomic commit to our atomic tail (commit 6d90a208cfff ("drm/amd/display: Move disable interrupt into commit tail")) . However, the new code introduced inside our commit tail function was inserted right after the function drm_atomic_helper_update_legacy_modeset_state(), which has routines for updating internal data structs related to timestamps. As a result, in certain conditions, the display module can reach a situation where we update our constants and, after that, clean it. This situation generates the following warning: amdgpu 0000:03:00.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) WARNING: CPU: 6 PID: 1269 at drivers/gpu/drm/drm_vblank.c:722 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x32b/0x340 [drm] ... RIP: 0010:drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x32b/0x340 [drm] ... Call Trace: ? dc_stream_get_vblank_counter+0x57/0x60 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x20 [drm] drm_get_last_vbltimestamp+0xad/0xc0 [drm] drm_reset_vblank_timestamp+0x63/0xd0 [drm] drm_crtc_vblank_on+0x85/0x150 [drm] amdgpu_dm_atomic_commit_tail+0xaf1/0x2330 [amdgpu] commit_tail+0x99/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] amdgpu_dm_atomic_commit+0x11/0x20 [amdgpu] drm_atomic_commit+0x4a/0x50 [drm] drm_atomic_helper_set_config+0x7c/0xc0 [drm_kms_helper] drm_mode_setcrtc+0x20b/0x7e0 [drm] ? tomoyo_path_number_perm+0x6f/0x200 ? drm_mode_getcrtc+0x190/0x190 [drm] drm_ioctl_kernel+0xae/0xf0 [drm] drm_ioctl+0x245/0x400 [drm] ? drm_mode_getcrtc+0x190/0x190 [drm] amdgpu_drm_ioctl+0x4e/0x80 [amdgpu] __x64_sys_ioctl+0x91/0xc0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... For fixing this issue we rely upon a refactor introduced on drm_atomic_helper_update_legacy_modeset_state ("Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()") which decouples constant values update from drm_atomic_helper_update_legacy_modeset_state to a new helper. Basically, this commit uses this new helper and place it right after our release module to avoid a situation where our CRTC struct gets wrong values. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1373 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-18drm/amdgpu: Fix missing prototype warningLuben Tuikov2-2/+2
Fix a missing prototype warning for function amdgpu_info_ioctl(), drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:482:5: warning: no previous prototype for 'amdgpu_info_ioctl' [-Wmissing-prototypes] Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201110051548.685725-1-luben.tuikov@amd.com
2020-11-18drm/amdgpu: fix check order in amdgpu_bo_moveChristian König1-30/+23
Reorder the code to fix checking if blitting is available. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/401019/
2020-11-18drm/i915: Fix the DDI encoder namesVille Syrjälä1-3/+6
I totally fumbled the ?: usage when generating the DDI encoder names. Reverse the things that need reversing, and to make it a bit less messy add a few macros to hide the arithmetic on the port enums. Cc: Jani Nikula <jani.nikula@linux.intel.com> Fixes: 2d709a5a624c ("drm/i915: Give DDI encoders even better names") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117154028.8516-1-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2020-11-18drm/vc4/vc4_debugfs: Demote non-conformant kernel-doc headersLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vc4/vc4_debugfs.c:25: warning: Function parameter or member 'minor' not described in 'vc4_debugfs_init' drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member 'dev' not described in 'vc4_debugfs_add_file' drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member 'name' not described in 'vc4_debugfs_add_file' drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member 'show' not described in 'vc4_debugfs_add_file' drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member 'data' not described in 'vc4_debugfs_add_file' Cc: Eric Anholt <eric@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201116174112.1833368-41-lee.jones@linaro.org
2020-11-18drm/vc4/vc4_v3d: Demote non-conformant kernel-doc headersLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vc4/vc4_v3d.c:131: warning: Function parameter or member 'vc4' not described in 'vc4_v3d_pm_get' drivers/gpu/drm/vc4/vc4_v3d.c:231: warning: Function parameter or member 'vc4' not described in 'bin_bo_alloc' Cc: Eric Anholt <eric@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rob Clark <robdclark@gmail.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201116174112.1833368-40-lee.jones@linaro.org
2020-11-18drm/vc4/vc4_hdmi: Remove set but unused variable 'ret'Lee Jones1-2/+1
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_set_audio_infoframe’: drivers/gpu/drm/vc4/vc4_hdmi.c:334:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Eric Anholt <eric@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Rob Clark <robdclark@gmail.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201116174112.1833368-39-lee.jones@linaro.org
2020-11-18drm/vc4/vc4_hdmi_regs: Mark some data sets as __maybe_unusedLee Jones1-3/+3
The alternative is to move them into the source file that uses then, but they are large and intrusive, so that strategy is being avoided. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vc4/vc4_hdmi_regs.h:282:39: warning: ‘vc5_hdmi_hdmi1_fields’ defined but not used [-Wunused-const-variable=] drivers/gpu/drm/vc4/vc4_hdmi_regs.h:206:39: warning: ‘vc5_hdmi_hdmi0_fields’ defined but not used [-Wunused-const-variable=] drivers/gpu/drm/vc4/vc4_hdmi_regs.h:145:39: warning: ‘vc4_hdmi_fields’ defined but not used [-Wunused-const-variable=] Cc: Eric Anholt <eric@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201116174112.1833368-38-lee.jones@linaro.org
2020-11-18drm/v3d/v3d_sched: Demote non-conformant kernel-doc headerLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/v3d/v3d_sched.c:75: warning: Function parameter or member 'sched_job' not described in 'v3d_job_dependency' drivers/gpu/drm/v3d/v3d_sched.c:75: warning: Function parameter or member 's_entity' not described in 'v3d_job_dependency' Cc: Eric Anholt <eric@anholt.net> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201116174112.1833368-37-lee.jones@linaro.org
2020-11-18drm/sun4i: backend: Fix probe failure with multiple backendsMaxime Ripard1-1/+7
Commit e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") introduced a regression in our code since the second backed to probe will now get -EINVAL back from dma_direct_set_offset and will prevent the entire DRM device from probing. Ignore -EINVAL as a temporary measure to get it back working, before removing that call entirely. Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-11-18drm/sun4i: backend: Remove the MBUS quirksMaxime Ripard1-19/+0
Now that the MBUS quirks are applied by our global notifier, we can remove them from our DRM driver. Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-11-17drm/v3d/v3d_gem: Provide descriptions for 'v3d_lookup_bos's paramsLee Jones1-0/+2
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/v3d/v3d_gem.c:292: warning: Function parameter or member 'bo_handles' not described in 'v3d_lookup_bos' drivers/gpu/drm/v3d/v3d_gem.c:292: warning: Function parameter or member 'bo_count' not described in 'v3d_lookup_bos' Cc: Eric Anholt <eric@anholt.net> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201116174112.1833368-36-lee.jones@linaro.org
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.