summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2021-07-15drm/i915/bxt: Use revid->stepping tablesMatt Roper2-9/+10
Switch BXT to use a revid->stepping table as we're trying to do on all platforms going forward. Note that the REVID macros we had before weren't being used anywhere in the code and weren't even correct; the table values come from the bspec (and omits all the placeholder and preproduction revisions). Although nothing in the code is using the data from this table at the moment, we expect some upcoming DMC patches to start utilizing it. Bspec: 13620 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-6-matthew.d.roper@intel.com
2021-07-15drm/i915/kbl: Drop pre-production revision from stepping tableMatt Roper1-1/+0
We're long past the point where we need to care about pre-production hardware, and we already warn the user and taint the kernel if we detect the driver is being loaded on pre-production hardware. Bspec: 18329 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-5-matthew.d.roper@intel.com
2021-07-15drm/i915/skl: Use revid->stepping tablesMatt Roper4-16/+31
Switch SKL to use a revid->stepping table as we're trying to do on all platforms going forward. Also drop the preproduction revisions and add the newer steppings we hadn't already handled. Note that SKL has a case where a newer revision ID corresponds to an older GT/disp stepping (0x9 -> STEP_J0, 0xA -> STEP_I1). Also, the lack of a revision ID 0x8 in the table is intentional and not an oversight. We'll re-write the KBL-specific comment to make it clear that these kind of quirks are expected. v2: - Since GT and display steppings are always identical on SKL use a macro to set both values at once in a more readable manner. (Anusha) - Drop preproduction steppings. Bspec: 13626 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-4-matthew.d.roper@intel.com
2021-07-15drm/i915: Make pre-production detection use direct revid comparisonMatt Roper1-4/+4
Although we're converting our workarounds to use a revid->stepping lookup table, the function that detects pre-production hardware should continue to compare against PCI revision ID values directly. These are listed in the bspec as integers, so it's easier to confirm their correctness if we just use an integer literal rather than a symbolic name anyway. Bspec: 13620, 19131, 13626, 18329 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-3-matthew.d.roper@intel.com
2021-07-15drm/i915/step: s/<platform>_revid_tbl/<platform>_revidsAnusha Srivatsa1-12/+12
Simplify the stepping info array name. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.roper@intel.com
2021-07-14drm/panel: Add Innolux EJ030NA 3.0" 320x480 panelChristophe Branchereau3-0/+299
Add support for the Innolux/Chimei EJ030NA 3.0" 320x480 TFT panel. This panel can be found in the LDKs, RS97 V2.1 and RG300 (non IPS) handheld gaming consoles. While being 320x480, it is actually a horizontal 4:3 panel with non-square pixels in delta arrangement. Signed-off-by: Christophe Branchereau <cbranchereau@gmail.com> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210625121045.81711-2-paul@crapouillou.net
2021-07-14drm/amdgpu: add another Renoir DIDJinzhou Su1-0/+1
Add new PCI device id. Signed-off-by: Jinzhou Su <Jinzhou.Su@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.11.x
2021-07-14drm/amdgpu: add another Renoir DIDJinzhou Su1-0/+1
Add new PCI device id. Signed-off-by: Jinzhou Su <Jinzhou.Su@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-14drm/ttm: add a check against null pointer dereferenceZheyu Ma1-0/+3
When calling ttm_range_man_fini(), 'man' may be uninitialized, which may cause a null pointer dereference bug. Fix this by checking if it is a null pointer. This log reveals it: [ 7.902580 ] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 7.905721 ] RIP: 0010:ttm_range_man_fini+0x40/0x160 [ 7.911826 ] Call Trace: [ 7.911826 ] radeon_ttm_fini+0x167/0x210 [ 7.911826 ] radeon_bo_fini+0x15/0x40 [ 7.913767 ] rs400_fini+0x55/0x80 [ 7.914358 ] radeon_device_fini+0x3c/0x140 [ 7.914358 ] radeon_driver_unload_kms+0x5c/0xe0 [ 7.914358 ] radeon_driver_load_kms+0x13a/0x200 [ 7.914358 ] ? radeon_driver_unload_kms+0xe0/0xe0 [ 7.914358 ] drm_dev_register+0x1db/0x290 [ 7.914358 ] radeon_pci_probe+0x16a/0x230 [ 7.914358 ] local_pci_probe+0x4a/0xb0 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1626274459-8148-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-07-14drm/i915/debugfs: DISPLAY_VER 13 lpsp capabilityAnshuman Gupta1-0/+5
Extend i915_lpsp_capability debugfs to DG2,ADLP and future platforms. v2: commit log modification. Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713075738.23759-1-anshuman.gupta@intel.com
2021-07-14drm/i915/gtt: drop the page table optimisationMatthew Auld1-4/+1
We skip filling out the pt with scratch entries if the va range covers the entire pt, since we later have to fill it with the PTEs for the object pages anyway. However this might leave open a small window where the PTEs don't point to anything valid for the HW to consume. When for example using 2M GTT pages this fill_px() showed up as being quite significant in perf measurements, and ends up being completely wasted since we ignore the pt and just use the pde directly. Anyway, currently we have our PTE construction split between alloc and insert, which is probably slightly iffy nowadays, since the alloc doesn't actually allocate anything anymore, instead it just sets up the page directories and points the PTEs at the scratch page. Later when we do the insert step we re-program the PTEs again. Better might be to squash the alloc and insert into a single step, then bringing back this optimisation(along with some others) should be possible. Fixes: 14826673247e ("drm/i915: Only initialize partially filled pagetables") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: <stable@vger.kernel.org> # v4.15+ Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210713130431.2392740-1-matthew.auld@intel.com (cherry picked from commit 8f88ca76b3942d82e2c1cea8735ec368d89ecc15) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-07-14drm/i915/gtt: drop the page table optimisationMatthew Auld1-4/+1
We skip filling out the pt with scratch entries if the va range covers the entire pt, since we later have to fill it with the PTEs for the object pages anyway. However this might leave open a small window where the PTEs don't point to anything valid for the HW to consume. When for example using 2M GTT pages this fill_px() showed up as being quite significant in perf measurements, and ends up being completely wasted since we ignore the pt and just use the pde directly. Anyway, currently we have our PTE construction split between alloc and insert, which is probably slightly iffy nowadays, since the alloc doesn't actually allocate anything anymore, instead it just sets up the page directories and points the PTEs at the scratch page. Later when we do the insert step we re-program the PTEs again. Better might be to squash the alloc and insert into a single step, then bringing back this optimisation(along with some others) should be possible. Fixes: 14826673247e ("drm/i915: Only initialize partially filled pagetables") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: <stable@vger.kernel.org> # v4.15+ Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210713130431.2392740-1-matthew.auld@intel.com
2021-07-14swiotlb: Update is_swiotlb_active to add a struct device argumentClaire Chang2-2/+2
Update is_swiotlb_active to add a struct device argument. This will be useful later to allow for different pools. Signed-off-by: Claire Chang <tientzu@chromium.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Will Deacon <will@kernel.org> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2021-07-13drm/i915/guc: Module load failure test for CT buffer creationJohn Harrison1-0/+8
Add several module failure load inject points in the CT buffer creation code path. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708162055.129996-8-matthew.brost@intel.com
2021-07-13drm/i915/guc: Optimize CTB writes and readsMatthew Brost2-32/+67
CTB writes are now in the path of command submission and should be optimized for performance. Rather than reading CTB descriptor values (e.g. head, tail) which could result in accesses across the PCIe bus, store shadow local copies and only read/write the descriptor values when absolutely necessary. Also store the current space in the each channel locally. v2: (Michal) - Add additional sanity checks for head / tail pointers - Use GUC_CTB_HDR_LEN rather than magic 1 v3: (Michal / John H) - Drop redundant check of head value v4: (John H) - Drop redundant checks of tail / head values v5: (Michal) - Address more nits v6: (Michal) - Add GEM_BUG_ON sanity check on ctb->space Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708162055.129996-7-matthew.brost@intel.com
2021-07-13drm/i915/guc: Add stall timer to non blocking CTB send functionMatthew Brost2-7/+59
Implement a stall timer which fails H2G CTBs once a period of time with no forward progress is reached to prevent deadlock. v2: (Michal) - Improve error message in ct_deadlock() - Set broken when ct_deadlock() returns true - Return -EPIPE on ct_deadlock() v3: (Michal) - Add ms to stall timer comment (Matthew) - Move broken check to intel_guc_ct_send() Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708162055.129996-6-matthew.brost@intel.com
2021-07-13drm/i915/guc: Add non blocking CTB send functionMatthew Brost4-15/+91
Add non blocking CTB send function, intel_guc_send_nb. GuC submission will send CTBs in the critical path and does not need to wait for these CTBs to complete before moving on, hence the need for this new function. The non-blocking CTB now must have a flow control mechanism to ensure the buffer isn't overrun. A lazy spin wait is used as we believe the flow control condition should be rare with a properly sized buffer. The function, intel_guc_send_nb, is exported in this patch but unused. Several patches later in the series make use of this function. v2: (Michal) - Use define for H2G room calculations - Move INTEL_GUC_SEND_NB define (Daniel Vetter) - Use msleep_interruptible rather than cond_resched v3: (Michal) - Move includes to following patch - s/INTEL_GUC_SEND_NB/INTEL_GUC_CT_SEND_NB/g v4: (John H) - Update comment, add type local variable Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708162055.129996-5-matthew.brost@intel.com
2021-07-13drm/i915/guc: Increase size of CTB buffersMatthew Brost1-3/+8
With the introduction of non-blocking CTBs more than one CTB can be in flight at a time. Increasing the size of the CTBs should reduce how often software hits the case where no space is available in the CTB buffer. Cc: John Harrison <john.c.harrison@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708162055.129996-4-matthew.brost@intel.com
2021-07-13drm/i915/guc: Improve error message for unsolicited CT responseMatthew Brost1-3/+7
Improve the error message when a unsolicited CT response is received by printing fence that couldn't be found, the last fence, and all requests with a response outstanding. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708162055.129996-3-matthew.brost@intel.com
2021-07-13drm/i915/guc: Relax CTB response timeoutMatthew Brost1-3/+7
In upcoming patch we will allow more CTB requests to be sent in parallel to the GuC for processing, so we shouldn't assume any more that GuC will always reply without 10ms. Use bigger value hardcoded value of 1s instead. v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option v3: (Daniel Vetter) - Use hardcoded value of 1s rather than config option v4: (Michal) - Use defines for timeout values Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708162055.129996-2-matthew.brost@intel.com
2021-07-13drm/i915/gt: Fix -EDEADLK handling regressionVille Syrjälä1-1/+1
The conversion to ww mutexes failed to address the fence code which already returns -EDEADLK when we run out of fences. Ww mutexes on the other hand treat -EDEADLK as an internal errno value indicating a need to restart the operation due to a deadlock. So now when the fence code returns -EDEADLK the higher level code erroneously restarts everything instead of returning the error to userspace as is expected. To remedy this let's switch the fence code to use a different errno value for this. -ENOBUFS seems like a semi-reasonable unique choice. Apart from igt the only user of this I could find is sna, and even there all we do is dump the current fence registers from debugfs into the X server log. So no user visible functionality is affected. If we really cared about preserving this we could of course convert back to -EDEADLK higher up, but doesn't seem like that's worth the hassle here. Not quite sure which commit specifically broke this, but I'll just attribute it to the general gem ww mutex work. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@intel.com> Testcase: igt/gem_pread/exhaustion Testcase: igt/gem_pwrite/basic-exhaustion Testcase: igt/gem_fenced_exec_thrash/too-many-fences Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210630164413.25481-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit 78d2ad7eb4e1f0e9cd5d79788446b6092c21d3e0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-07-13Merge drm/drm-next into drm-intel-gt-nextRodrigo Vivi375-7987/+10787
Catching up with 5.14-rc1 and also preparing for a needed common topic branch for the "Minor revid/stepping and workaround cleanup" Reference: https://patchwork.freedesktop.org/series/92299/ Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-07-13Merge drm/drm-next into drm-intel-nextRodrigo Vivi70-565/+1287
Catching up with 5.14-rc1 Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-07-13drm/i915/display/xelpd: Extend Wa_14011508470José Roberto de Souza1-2/+2
This workaround is also applicable to xelpd display so extending it. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-6-jose.souza@intel.com
2021-07-13drm/i915: Limit Wa_22010178259 to affected platformsJosé Roberto de Souza1-4/+5
This workaround is not needed for platforms with display 13. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-5-jose.souza@intel.com
2021-07-13drm/i915/display: Settle on "adl-x" in WA commentsJosé Roberto de Souza5-9/+9
Most of the places are using this format so lets consolidate it. v2: - split patch in two: display and non-display because of conflicts between drm-intel-gt-next x drm-intel-next Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-1-jose.souza@intel.com
2021-07-13drm/i915/adl_s: Extend Wa_1406941453José Roberto de Souza1-2/+3
BSpec: 54370 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-4-jose.souza@intel.com
2021-07-13drm/i915: Implement Wa_1508744258José Roberto de Souza1-0/+7
Same bit was required for Wa_14012131227 in DG1 now it is also required as Wa_1508744258 to TGL, RKL, DG1, ADL-S and ADL-P. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-3-jose.souza@intel.com
2021-07-13drm/i915: Settle on "adl-x" in WA commentsJosé Roberto de Souza2-3/+3
Most of the places are using this format so lets consolidate it. v2: - split patch in two: display and non-display because of conflicts between drm-intel-gt-next x drm-intel-next Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-2-jose.souza@intel.com
2021-07-13drm/amd/pm: Add waiting for response of mode-reset message for yellow carpAaron Liu1-7/+3
Remove mdelay process and use smu_cmn_send_smc_msg_with_param to send mode-reset message to SMC. Signed-off-by: Aaron Liu <aaron.liu@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13Revert "drm/amdkfd: Add heavy-weight TLB flush after unmapping"Eric Huang1-1/+0
This reverts commit 1098d658bef05e5fee634aab0b6a1fa590cfca24. Reason for revert: it causes regressions on several Asics. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13Revert "drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update"Eric Huang4-10/+10
This reverts commit 075e8080c1a7571563171a07fa9ce47c4bc80044. Reason for revert: the related commit is reverted. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13Revert "drm/amdkfd: Make TLB flush conditional on mapping"Eric Huang4-27/+20
This reverts commit 31f33243788dcbae8bd2819ed83923a73f7dfd30. Reason for revert: it causes regressions on several Asics. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13Revert "drm/amdgpu: Fix warning of Function parameter or member not described"Eric Huang1-1/+0
This reverts commit 7a68d188d1c4a9d947369acaa19040a58baaaeda. Reason for revert: the related commit is reverted. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13Revert "drm/amdkfd: Add memory sync before TLB flush on unmap"Eric Huang1-20/+3
This reverts commit 3be4dca197010d1328df8b11febc8c40491be498. Reason for revert: it causes regressions on several Asics. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amd/pm: Fix BACO state setting for Beige_GobyChengming Gui1-0/+1
Correct BACO state setting for Beige_Goby Signed-off-by: Chengming Gui <Jack.Gui@amd.com> Reviewed-by: Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amdgpu: Restore msix after FLREmily.Deng1-0/+18
After FLR, the msix will be cleared, so need to re-enable it. Signed-off-by: Peng Ju Zhou <PengJu.Zhou@amd.com> Signed-off-by: Emily.Deng <Emily.Deng@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amdkfd: Allow CPU access for all VRAM BOsFelix Kuehling1-2/+1
The thunk needs to mmap all BOs for CPU access to allow the debugger to access them. Invisible ones are mapped with PROT_NONE. Fixes: 71df0368e9b6 ("drm/amdgpu: Implement mmap as GEM object function") Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amdgpu/display - only update eDP's backlight level when necessaryZhan Liu1-1/+1
[Why] The original logic is to update eDP's backlight level on every amdgpu dm atomic commit, which causes excessive DMUB write. As a result, when playing game or moving window around, DMUB timeout and system lagging are observed. [How] We only need to update eDP's backlight level when current level doesn't match requested level. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amdkfd: handle fault counters on invalid addressPhilip Yang1-12/+18
prange is NULL if vm fault retry on invalid address, for this case, can not use prange to get pdd, use adev to get gpuidx and then get pdd instead, then increase pdd vm fault counter. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amdgpu: Correct the irq numbers for virtual crtcEmily Deng1-1/+1
The irq number should be decided by num_crtc, and the num_crtc could change by parameter. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed by: Monk Liu <monk.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amd/display: update header file nameXiaomeng Hou1-2/+2
Update the register header file name. Signed-off-by: Xiaomeng Hou <Xiaomeng.Hou@amd.com> Reviewed-by: Aaron Liu <aaron.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amd/pm: drop smu_v13_0_1.c|h files for yellow carpXiaomeng Hou8-1263/+57
Since there's nothing special in smu implementation for yellow carp, it's better to reuse the common smu_v13_0 interfaces and drop the specific smu_v13_0_1.c|h files. v2: remove the duplicate register offset and shift mask header files as well. Signed-off-by: Xiaomeng Hou <Xiaomeng.Hou@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Kevin Wang <kevin1.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amd/display: remove faulty assertDmytro Laktyushkin1-1/+0
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13Revert "drm/amd/display: Always write repeater mode regardless of LTTPR"Wesley Chalmers1-3/+4
This reverts commit 2b7605d73b97e2fa28e0817242e66ca968d2a7cb Some displays are not lighting up when put in LTTPR Transparent Mode Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-07-13drm/amd/display: Fix updating infoframe for DCN3.1 eDPNicholas Kazlauskas1-1/+1
[Why] We're only treating TMDS as a valid target for infoframe updates which results in PSR being unable to transition from state 4 to state 5. [How] Also allow infoframe updates for DCN3.1 - following how we handle this path for earlier ASIC as well. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Eric Yang <eric.yang2@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amdgpu: Return error if no RASLuben Tuikov2-17/+38
In amdgpu_ras_query_error_count() return an error if the device doesn't support RAS. This prevents that function from having to always set the values of the integer pointers (if set), and thus prevents function side effects--always to have to set values of integers if integer pointers set, regardless of whether RAS is supported or not--with this change this side effect is mitigated. Also, if no pointers are set, don't count, since we've no way of reporting the counts. Also, give this function a kernel-doc. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: John Clements <john.clements@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Reported-by: Tom Rix <trix@redhat.com> Fixes: a46751fbcde505 ("drm/amdgpu: Fix RAS function interface") Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Reviewed-by: Alexander Deucher <Alexander.Deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amdgpu: SRIOV flr_work should take write_lockJingwen Chen2-4/+4
[Why] If flr_work takes read_lock, then other threads who takes read_lock can access hardware when host is doing vf flr. [How] flr_work should take write_lock to avoid this case. Signed-off-by: Jingwen Chen <Jingwen.Chen2@amd.com> Reviewed-by: Monk Liu <monk.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amdgpu: Resolve bug in UMC 6.7 error offset calculationJohn Clements1-2/+2
Use correct channel and instance values Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-07-13drm/amd/pm: Add waiting for response of mode-reset message for yellow carpAaron Liu1-7/+3
Remove mdelay process and use smu_cmn_send_smc_msg_with_param to send mode-reset message to SMC. Signed-off-by: Aaron Liu <aaron.liu@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-17 03:31:26 +0300