- 04 Nov, 2020 15 commits
-
-
Alex Deucher authored
No need for a separate config option at this point. Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Roman Li authored
Display Manager support for green_sardine Signed-off-by:
Roman Li <Roman.Li@amd.com> Reviewed-by:
-
Roman Li authored
Display Core support for green_sardine Signed-off-by:
Hersen Wu <hersenxs.wu@amd.com> Reviewed-by:
-
Thong Thai authored
Enable Green_Sardine VCN support and VCN firmware loading v2: use apu flags Signed-off-by:
Thong Thai <thong.thai@amd.com> Signed-off-by:
-
Aaron Liu authored
This patch enable green_sardine_asd.bin loading. v2: use apu flags Signed-off-by:
Aaron Liu <aaron.liu@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Prike Liang <Prike.Liang@amd.com> Signed-off-by:
-
Prike Liang authored
Initialize the SDMA IP for green_sardine. v2: use apu flags Signed-off-by:
-
Prike Liang authored
Enable the gfx base HW function of green_sardine. v2: use apu flags Signed-off-by:
-
Prike Liang authored
This patch adds common ip support for green_sardine. v2: use apu flags, squash in CG/PG enablement v3: rebase Signed-off-by:
-
Prike Liang authored
This patch adds green_sardine support for gpu_info firmware and ip block setting. v2: use apu flag Signed-off-by:
-
Alex Deucher authored
Will be used for Green_Sardine which is a new APU. Signed-off-by: -
John Clements authored
updated fw header v2 parser to set asd fw memory Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
Kent Russell authored
If we can't kvmalloc the pcrat_image, then we shouldn't memcpy Signed-off-by:
Kent Russell <kent.russell@amd.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Likun Gao authored
Update golden setting for sienna_cichlid. Signed-off-by:
Likun Gao <Likun.Gao@amd.com> Reviewed-by:
-
Veerabadhran Gopalakrishnan authored
Concurrent operation of VCN and JPEG decoder in DPG mode is causing ring timeout due to power state. Signed-off-by:
Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan@amd.com> Reviewed-by:
Leo Liu <leo.liu@amd.com> Signed-off-by:
-
Alex Deucher authored
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:
-
- 30 Oct, 2020 11 commits
-
-
Alex Deucher authored
Leads to improper dpm on older parts. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1353 Fixes: 8d89b96f ("drm/amd/powerplay: optimize the mclk dpm policy settings") Reviewed-by:
-
Joe Perches authored
commit e098bc96 ("drm/amd/pm: optimize the power related source code layout") moved the directory, update the F: file pattern to match. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Evan Quan authored
This reverts commit f8781228 ("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:
Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by:
-
Evan Quan authored
So that the succeeding resume can be performed based on a clean state. Signed-off-by:
-
Evan Quan authored
Which can be used for S4(hibernation) support. Signed-off-by:
-
Evan Quan authored
Correct some registers bitmasks and add mmBIOS_SCRATCH_7 reset. Signed-off-by:
-
Evan Quan authored
This can address the random SDMA hang after pci config reset seen on Hawaii. Signed-off-by:
-
Flora Cui authored
for headless NAVI ASICs Signed-off-by:
Flora Cui <flora.cui@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
-
Flora Cui authored
Navi14 0x7340/C9 SKU has no display and video support, remove them. Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-fixes-2020-10-29' of 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
-
git://github.com/skeggsb/linuxDave Airlie authored
Fixes an endian regression on older GPUs, a refcount overflow, a migration fix and 3 display fixes. Signed-off-by:
-
- 29 Oct, 2020 13 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
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:
-
Lyude Paul authored
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: 409d3813 ("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>
-
Lyude Paul authored
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:
-
Karol Herbst authored
With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340 ("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:
-
Karol Herbst authored
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:
-
Lyude Paul authored
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:
-
Ralph Campbell authored
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:
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-5.10-2020-10-29' of git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.10-2020-10-29: amdgpu: - Add new navi1x PCI ID - GPUVM reserved area fixes - Misc display fixes - Fix bad interactions between display code and CONFIG_KGDB - Fixes for SMU manual fan control and i2c Signed-off-by:
-
Ville Syrjälä authored
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.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit a40a8305) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
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: 9c878557 ("drm/i915/gt: Use the RPM config register to determine clk frequencies") Signed-off-by:
-
Matthew Auld authored
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: b908be54 ("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:
-
Maxime Ripard authored
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
-
Maxime Ripard authored
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:
-
- 28 Oct, 2020 1 commit
-
-
Daniel Vetter authored
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 26d3ac3c ("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: 26d3ac3c ("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
-
