summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2020-11-03drm/amdgpu/swsmu: remove duplicate call to smu_set_default_dpm_tableAlex Deucher
For kernel 5.10, this function was called twice right next to each other in the same function due to what looks like a mis-merge. Remove one of them. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30drm/amdgpu/powerplay: Only apply optimized mclk dpm policy on polarisAlex Deucher
Leads to improper dpm on older parts. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1353 Fixes: 8d89b96fe797 ("drm/amd/powerplay: optimize the mclk dpm policy settings") Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30drm/amd/pm: do not use ixFEATURE_STATUS for checking smc runningEvan Quan
This reverts commit f87812284172a9809820d10143b573d833cd3f75 ("drm/amdgpu: Fix bug where DPM is not enabled after hibernate and resume"). It was intended to fix Hawaii S4(hibernation) issue but break S3. As ixFEATURE_STATUS is filled with garbage data on resume which can be only cleared by reloading smc firmware(but that will involve many changes). So, we will revert this S4 fix and seek a new way. Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30drm/amd/pm: perform SMC reset on suspend/hibernationEvan Quan
So that the succeeding resume can be performed based on a clean state. Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30drm/amd/pm: enable baco reset for HawaiiEvan Quan
Which can be used for S4(hibernation) support. Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30drm/amd/pm: correct the baco reset sequence for CI ASICsEvan Quan
Correct some registers bitmasks and add mmBIOS_SCRATCH_7 reset. Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30drm/amdgpu: perform srbm soft reset always on SDMA resumeEvan Quan
This can address the random SDMA hang after pci config reset seen on Hawaii. Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30drm/amdgpu: rename nv_is_headless_sku()Flora Cui
for headless NAVI ASICs Signed-off-by: Flora Cui <flora.cui@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30drm/amdgpu: disable DCN and VCN for Navi14 0x7340/C9 SKUFlora Cui
Navi14 0x7340/C9 SKU has no display and video support, remove them. Signed-off-by: Flora Cui <flora.cui@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-30Merge tag 'drm-intel-fixes-2020-10-29' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix max memory region size calculation (Matt) - Restore ILK-M RPS support, restoring performance (Ville) - Reject 90/270 degreerotated initial fbs (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201030004442.GA146813@intel.com
2020-10-30Merge branch 'linux-5.10' of git://github.com/skeggsb/linux into drm-fixesDave Airlie
Fixes an endian regression on older GPUs, a refcount overflow, a migration fix and 3 display fixes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv6MOjtgzKchpis1XrZYmu7-6CaxnHVzJKOXPH62_em7tw@mail.gmail.com
2020-10-30Merge tag 'drm-misc-fixes-2020-10-29' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes First round of drm-misc-fixes with a couple of leftovers from drm-misc-fixes next. Some reset fixes for the mantix panel, some fixes for a scaler issue on sun4i, many kernel-doc fixes and various fixes for vc4 (mostly HDMI audio related) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201029173414.fxrl5jacsdwqheto@gilmour.lan
2020-10-30drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()Lyude Paul
While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max data rate supported by the DP encoder. So, limiting it to the output of ds_clock (which refers to the maximum dotclock of the downstream DP device) doesn't make any sense. Additionally, since we're using the connector's bpc as the canonical BPC we should use this in mode_valid until we support dynamically setting the bpp based on bandwidth constraints. https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html For more info. So, let's rewrite this using Ville's advice. v2: * Ville pointed out I mixed up the dotclock and the link rate. So fix that... * ...and also rename all the variables in this function to be more appropriately labeled so I stop mixing them up. * Reuse the bpp from the connector for now until we have dynamic bpp selection. * Use use DIV_ROUND_UP for calculating the mode rate like i915 does, which we should also have been doing from the start Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid()Lyude Paul
Ville also pointed out that I got a lot of the logic here wrong as well, whoops. While I don't think anyone's likely using 3D output with nouveau, the next patch will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get rid of it and open-code it like before, while taking care to move the 3D frame packing calculations on the dot clock into the right place. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: d6a9efece724 ("drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/device: fix changing endianess code to work on older GPUsKarol Herbst
With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") Signed-off-by: Karol Herbst <kherbst@redhat.com> Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"Karol Herbst
we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/kms/nv50-: Program notifier offset before requesting disp capsLyude Paul
Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier offset programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix this by doing that, and also perform an update afterwards to prevent racing with the GPU when reading capabilities. v2: * Don't just program the DMA notifier offset, make sure to actually perform an update v3: * Don't call UPDATE() * Actually read the correct notifier fields, as apparently the CAPABILITIES_DONE field lives in a different location than the main NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different CAPABILITIES_DONE field then pre-907d cards. v4: * Don't forget to check the return value of core507d_read_caps() v5: * Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY * Disable notifier after calling GetCapabilities() Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support") Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/nouveau: fix the start/end range for migrationRalph Campbell
The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-29drm/i915: Reject 90/270 degree rotated initial fbsVille Syrjälä
We don't currently handle the initial fb readout correctly for 90/270 degree rotated scanout. Reject it. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020194330.28568-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit a40a8305a732f4ecc2186ac7ca132ba062ed770d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-10-29drm/i915: Restore ILK-M RPS supportVille Syrjälä
Restore RPS for ILK-M. We lost it when an extra HAS_RPS() check appeared in intel_rps_enable(). Unfortunaltey this just makes the performance worse on my ILK because intel_ips insists on limiting the GPU freq to the minimum. If we don't do the RPS init then intel_ips will not limit the frequency for whatever reason. Either it can't get at some required information and thus makes wrong decisions, or we mess up some weights/etc. and cause it to make the wrong decisions when RPS init has been done, or the entire thing is just wrong. Would require a bunch of reverse engineering to figure out what's going on. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 9c878557b1eb ("drm/i915/gt: Use the RPM config register to determine clk frequencies") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 2bf06370bcfb0dea5655e9a5ad460c7f7dca7739) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-10-29drm/i915/region: fix max size calculationMatthew Auld
We are incorrectly limiting the max allocation size as per the mm max_order, which is effectively the largest power-of-two that we can fit in the region size. However, it's normal to setup the region or allocator with a non-power-of-two size(for example 3G), which we should already handle correctly, except it seems for the early too-big-check. v2: make sure we also exercise the I915_BO_ALLOC_CONTIGUOUS path, which is quite different, since for that we are actually limited by the largest power-of-two that we can fit within the region size. (Chris) Fixes: b908be543e44 ("drm/i915: support creating LMEM objects") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: CQ Tang <cq.tang@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/20201021103606.241395-1-matthew.auld@intel.com (cherry picked from commit 83ebef47f8ebe320d5c5673db82f9903a4f40a69) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-10-29drm/vc4: Rework the structure conversion functionsMaxime Ripard
Most of the helpers to retrieve vc4 structures from the DRM base structures rely on the fact that the first member of the vc4 structure is the DRM one and just cast the pointers between them. However, this is pretty fragile especially since there's no check to make sure that the DRM structure is indeed at the offset 0 in the structure, so let's use container_of to make it more robust. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028123752.1733242-1-maxime@cerno.tech
2020-10-29drm/vc4: hdmi: Add a name to the codec DAI componentMaxime Ripard
Since the components for a given device in ASoC are identified by their name, it makes sense to add one even though it's not strictly necessary. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708144555.718404-1-maxime@cerno.tech
2020-10-28drm/shme-helpers: Fix dma_buf_mmap forwarding bugDaniel Vetter
When we forward an mmap to the dma_buf exporter, they get to own everything. Unfortunately drm_gem_mmap_obj() overwrote vma->vm_private_data after the driver callback, wreaking the exporter complete. This was noticed because vb2_common_vm_close blew up on mali gpu with panfrost after commit 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf"). Unfortunately drm_gem_mmap_obj also acquires a surplus reference that we need to drop in shmem helpers, which is a bit of a mislayer situation. Maybe the entire dma_buf_mmap forwarding should be pulled into core gem code. Note that the only two other drivers which forward mmap in their own code (etnaviv and exynos) get this somewhat right by overwriting the gem mmap code. But they seem to still have the leak. This might be a good excuse to move these drivers over to shmem helpers completely. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Christian König <christian.koenig@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf") Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: <stable@vger.kernel.org> # v5.9+ Reported-and-tested-by: piotr.oniszczuk@gmail.com Cc: piotr.oniszczuk@gmail.com Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201027214922.3566743-1-daniel.vetter@ffwll.ch
2020-10-27drm/vc4: hdmi: Avoid sleeping in atomic contextMaxime Ripard
When running the trigger hook, ALSA by default will take a spinlock, and thus will run the trigger hook in atomic context. However, our HDMI driver will send the infoframes as part of the trigger hook, and part of that process is to wait for a bit to be cleared for up to 100ms. To be nicer to the system, that wait has some usleep_range that interact poorly with the atomic context. There's several ways we can fix this, but the more obvious one is to make ALSA take a mutex instead by setting the nonatomic flag on the DAI link. That doesn't work though, since now the cyclic callback installed by the dmaengine helpers in ALSA will take a mutex, while that callback is run by dmaengine's virt-chan code in a tasklet where sleeping is not allowed either. Given the delay we need to poll the bit for, changing the usleep_range for a udelay and keep running it from a context where interrupts are disabled is not really a good option either. However, we can move the infoframe setup code in the hw_params hook, like is usually done in other HDMI controllers, that isn't protected by a spinlock and thus where we can sleep. Infoframes will be sent on a regular basis anyway, and since hw_params is where the audio parameters that end up in the infoframes are setup, this also makes a bit more sense. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201027101558.427256-1-maxime@cerno.tech
2020-10-27drm/amdgpu/pm: fix the fan speed in fan1_input in manual mode for navi1xAlex Deucher
It has been confirmed that the SMU metrics table should always reflect the current fan speed even in manual mode. Fixes: 3033e9f1c2de ("drm/amdgpu/swsmu: handle manual fan readback on SMU11") Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-27drm/amd/pm: fix the wrong fan speed in fan1_inputKenneth Feng
fix the wrong fan speed in fan1_input when the fan control mode is manual. the fan speed value is not correct when we set manual mode to fan1_enalbe - 1. since the fan speed in the metrics table always reflects the real fan speed,we can fetch the fan speed for both auto and manual mode. Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Likun Gao <Likun.Gao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-27drm/amdgpu/swsmu: drop smu i2c bus on navi1xAlex Deucher
Stop registering the SMU i2c bus on navi1x. This leads to instability issues when userspace processes mess with the bus and also seems to cause display stability issues in some cases. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1314 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1341 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-10-27drm/vc4: drv: Add error handding for bindHoegeun Kwon
There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com
2020-10-27drm: kernel-doc: add description for a new function parameterMauro Carvalho Chehab
As reported by "make htmldocs": ./drivers/gpu/drm/drm_prime.c:808: warning: Function parameter or member 'dev' not described in 'drm_prime_pages_to_sg' Add a description for the new parameter. Fixes: 707d561f77b5 ("drm: allow limiting the scatter list size.") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/9366f48e6e9c3ec2f31a3e68452a2b23a1089fce.1603791716.git.mchehab+huawei@kernel.org
2020-10-27drm/dp: fix a kernel-doc issue at drm_edid.cMauro Carvalho Chehab
The name of the argument is different, causing those warnings: ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member 'video_code' not described in 'drm_display_mode_from_cea_vic' ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 'vic' description in 'drm_display_mode_from_cea_vic' Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()") Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/7f4d6c3ff6df63ebd006eb90a5108006c23e2168.1603791716.git.mchehab+huawei@kernel.org
2020-10-27drm/dp: fix kernel-doc warnings at drm_dp_helper.cMauro Carvalho Chehab
As warned by kernel-doc: ./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or member 'type' not described in 'drm_dp_downstream_is_type' ./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or member 'dev' not described in 'drm_dp_downstream_mode' Some function parameters weren't documented. Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port types") Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/03c9c8ba3f492aca76e2b4836803219cd9c971cf.1603791716.git.mchehab+huawei@kernel.org
2020-10-27drm: kernel-doc: document drm_dp_set_subconnector_property() paramsMauro Carvalho Chehab
Changeset e5b92773287c ("drm: report dp downstream port type as a subconnector property") added a new function to the kAPI, but didn't add any documentation for the parameters for drm_dp_set_subconnector_property(). Fixes: e5b92773287c ("drm: report dp downstream port type as a subconnector property") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/0870be85a77bea4ba5cf1715010834289a4e10b1.1603791716.git.mchehab+huawei@kernel.org
2020-10-26drm/amd/display: Clean up debug macrosTakashi Iwai
This patch simplifies the ASSERT*() and BREAK_TO_DEBUGGER() macros: - Move the dependency check of CONFIG_KGDB into Kconfig - Unify the kgdb_breakpoint() call - Drop the non-existing CONFIG_HAVE_KGDB Also align the behavior of ASSERT() macro in both cases with and without CONFIG_DEBUG_KERNEL_DC. Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm/amd/display: Don't invoke kgdb_breakpoint() unconditionallyTakashi Iwai
ASSERT_CRITICAL() invokes kgdb_breakpoint() whenever either CONFIG_KGDB or CONFIG_HAVE_KGDB is set. This, however, may lead to a kernel panic when no kdb stuff is attached, since the kgdb_breakpoint() call issues INT3. It's nothing but a surprise for normal end-users. For avoiding the pitfall, make the kgdb_breakpoint() call only when CONFIG_DEBUG_KERNEL_DC is set. https://bugzilla.opensuse.org/show_bug.cgi?id=1177973 Cc: <stable@vger.kernel.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm/amd/display: Fix kernel panic by dal_gpio_open() errorTakashi Iwai
Currently both error code paths handled in dal_gpio_open_ex() issues ASSERT_CRITICAL(), and this leads to a kernel panic unnecessarily if CONFIG_KGDB is enabled. Since basically both are non-critical errors and can be recovered, drop those assert calls and use a safer one, BREAK_TO_DEBUGGER(), for allowing the debugging, instead. BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1177973 Cc: <stable@vger.kernel.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm/amdgpu/display: use kvzalloc again in dc_create_stateAlex Deucher
It looks this was accidently lost in a follow up patch. dc context is large and we don't need contiguous pages. Fixes: e4863f118a7d ("drm/amd/display: Multi display cause system lag on mode change") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Aric Cyr <aric.cyr@amd.com> Cc: Alex Xu <alex_y_xu@yahoo.ca> Reported-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Cc: stable@vger.kernel.org
2020-10-26drm/amd/display: adding ddc_gpio_vga_reg_list to ddc reg def'nsMartin Leung
why: oem-related ddc read/write fails without these regs how: copy from hw_factory_dcn20.c Signed-off-by: Martin Leung <martin.leung@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm/amd/display: prevent null pointer accessDmytro Laktyushkin
Prevent null pointer access when checking odm tree. Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: <stable@vger.kernel.org>
2020-10-26drm/amdgpu: increase the reserved VM size to 2MBChristian König
Ideally this should be a multiple of the VM block size. 2MB should at least fit for Vega/Navi. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Madhav Chauhan <madhav.chauhan@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-10-26drm/amd/display: Fixed panic during seamless boot.David Galiffi
[why] get_pixel_clk_frequency_100hz is undefined in clock_source_funcs. [how] set function pointer: ".get_pixel_clk_frequency_100hz = get_pixel_clk_frequency_100hz" Signed-off-by: David Galiffi <David.Galiffi@amd.com> Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm/amdgpu: don't map BO in reserved regionMadhav Chauhan
2MB area is reserved at top inside VM. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Madhav Chauhan <madhav.chauhan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-10-26drm/amdgpu: add DID for navi10 blockchain SKUTianci.Yin
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm/amdgpu: disable DCN and VCN for navi10 blockchain SKU(v3)Tianci.Yin
The blockchain SKU has no display and video support, remove them. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm/v3d: Fix double free in v3d_submit_cl_ioctl()Dan Carpenter
Originally this error path used to leak "bin" but then we accidentally applied two separate commits to fix it and ended up with a double free. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201026094905.GA1634423@mwanda
2020-10-26drm/sun4i: frontend: Fix the scaler phase on A33Maxime Ripard
The A33 has a different phase parameter in the Allwinner BSP on the channel1 than the one currently applied. Fix this. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-maxime@cerno.tech
2020-10-26drm/sun4i: frontend: Reuse the ch0 phase for RGB formatsMaxime Ripard
When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko <tpgalchenko@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-maxime@cerno.tech
2020-10-26drm/sun4i: frontend: Rework a bit the phase dataMaxime Ripard
The scaler filter phase setup in the allwinner kernel has two different cases for setting up the scaler filter, the first one using different phase parameters for the two channels, and the second one reusing the first channel parameters on the second channel. The allwinner kernel has a third option where the horizontal phase of the second channel will be set to a different value than the vertical one (and seems like it's the same value than one used on the first channel). However, that code path seems to never be taken, so we can ignore it for now, and it's essentially what we're doing so far as well. Since we will have always the same values across each components of the filter setup for a given channel, we can simplify a bit our frontend structure by only storing the phase value we want to apply to a given channel. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-maxime@cerno.tech
2020-10-26Merge remote-tracking branch 'drm-misc/drm-misc-next-fixes' into drm-misc-fixesMaxime Ripard
We have a few leftovers from the merge window period in drm-misc-next-fixes, let's bring them into drm-misc-fixes Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2020-10-24Merge tag 'armsoc-drivers' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC-related driver updates from Olof Johansson: "Various driver updates for platforms. A bulk of this is smaller fixes or cleanups, but some of the new material this time around is: - Support for Nvidia Tegra234 SoC - Ring accelerator support for TI AM65x - PRUSS driver for TI platforms - Renesas support for R-Car V3U SoC - Reset support for Cortex-M4 processor on i.MX8MQ There are also new socinfo entries for a handful of different SoCs and platforms" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (131 commits) drm/mediatek: reduce clear event soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add write_s_mask value function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s_mask function soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add address shift in jump soc: mediatek: mtk-infracfg: Fix kerneldoc soc: amlogic: pm-domains: use always-on flag reset: sti: reset-syscfg: fix struct description warnings reset: imx7: add the cm4 reset for i.MX8MQ dt-bindings: reset: imx8mq: add m4 reset reset: Fix and extend kerneldoc reset: reset-zynqmp: Added support for Versal platform dt-bindings: reset: Updated binding for Versal reset driver reset: imx7: Support module build soc: fsl: qe: Remove unnessesary check in ucc_set_tdm_rxtx_clk soc: fsl: qman: convert to use be32_add_cpu() ...
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-12 08:00:32 +0000