- 27 Jun, 2023 1 commit
-
-
Imre Deak authored
Add the seq_file struct forward declaration to intel_display_power.h fixing the build error below. While at it add the rest of missing forward declarations/includes to the display power header files. In file included from <command-line>: ./../drivers/gpu/drm/i915/display/intel_display_power.h:255:70: error: 'struct seq_file' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 255 | void intel_display_power_debug(struct drm_i915_private *i915, struct seq_file *m); | ^~~~~~~~ Closes: https://lore.kernel.org/intel-gfx/89adc1ac-25a0-6eb6-4cc9-ab6cc8d49730@infradead.org/Reported-by:Randy Dunlap <rdunlap@infradead.org> Acked-by:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-1-imre.deak@intel.com (cherry picked from commit f4fab137) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
- 26 Jun, 2023 5 commits
-
-
Suraj Kandpal authored
Currently hdcp->content_type is being assigned the content_type field in drm_connector_state which is wrong and instead it needs to be assigned hdcp_content_type field from drm_connector_state Fixes: 4c4279a8 ("drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Vinay Belgaumkar authored
The scenario being fixed here is depicted in the following sequence- modprobe i915 echo 1 > /sys/class/drm/card0/gt/gt0/slpc_ignore_eff_freq echo 300 > /sys/class/drm/card0/gt_min_freq_mhz (RPn) cat /sys/class/drm/card0/gt_cur_freq_mhz --> cur == RPn as expected echo 1 > /sys/kernel/debug/dri/0/gt0/reset --> reset cat /sys/class/drm/card0/gt_min_freq_mhz --> cached freq is RPn cat /sys/class/drm/card0/gt_cur_freq_mhz --> it's not RPn, but RPe!! When SLPC reinitializes, it sets SLPC min freq to efficient frequency. Even if we disable efficient freq post that, we should restore the cached min freq (via H2G) for it to take effect. v2: Clarify commit message (Ashutosh) Fixes: 95ccf312 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency") Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230621014257.1769564-1-vinay.belgaumkar@intel.com (cherry picked from commit da86b2b1) Signed-off-by:
-
Jouni Högander authored
Encoder compute config is changing hw.adjusted mode. Uapi.adjusted mode doesn't get updated before psr compute config gets called. This causes io and fast wake line calculation using adjusted mode containing values before encoder adjustments. Fix this by using hw.adjusted mode instead of uapi.adjusted mode. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230620111745.2870706-1-jouni.hogander@intel.com (cherry picked from commit ef0af9db) Signed-off-by:
-
Radhakrishna Sripada authored
Driver does not clear the default SSC for MPLLA. This causes link training failure when trying to use 10G and 20G rates. Fix the behaviour and enable ssc only when we really want. Fixes: 237e7be0 ("drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Tested-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by:
-
Imre Deak authored
A recent bspec update added a restriction on when DC states can be enabled: [Before enabling DC states:] """ PG2 can be kept enabled only because PGB requires PG2. Do not use PG2 functions, such as type-C DDIs. DMC will dynamically control PG1, PGA, PG2, PGB. """ Accordingly prevent DC states if PW2 (aka PG2) is enabled for any other functionality. Bpsec: 49193 Fixes: 88c48793 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2") Reported-by:
Kai Vehmanen <kai.vehmanen@intel.com> Tested-by:
Ambica Pramod <ambica.pramod@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
- 20 Jun, 2023 4 commits
-
-
Dan Carpenter authored
The mmap_offset_attach() function returns error pointers, it doesn't return NULL. Fixes: eaee1c08 ("drm/i915: Add a function to mmap framebuffer obj") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
The function is only defined if CONFIG_PROC_FS is enabled: ld.lld: error: undefined symbol: i915_drm_client_fdinfo >>> referenced by i915_driver.c >>> drivers/gpu/drm/i915/i915_driver.o:(i915_drm_driver) in archive vmlinux.a Use the PTR_IF() helper to make the reference NULL otherwise. Fixes: e894b724 ("drm/i915: Use the fdinfo helper") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Harshit Mogalapalli authored
Smatch warns: drivers/gpu/drm/i915/gt/uc/intel_huc.c:388 intel_huc_init() warn: missing error code 'err' When the allocation of VMAs fail: The value of err is zero at this point and it is passed to PTR_ERR and also finally returning zero which is success instead of failure. Fix this by adding the missing error code when VMA allocation fails. Fixes: 08872cb1 ("drm/i915/mtl/huc: auth HuC via GSC") Signed-off-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by:
-
Alan Previn authored
Ensure intel_gsc_uc_fw_init_done and intel_gsc_uc_fw_proxy_init takes a wakeref before reading GSC Shim registers. NOTE: another patch in review also adds a call from selftest to this same function. (https://patchwork.freedesktop.org/series/117713/) which is why i am adding the wakeref inside the callee, not the caller. v2: - add a helper, 'gsc_uc_get_fw_status' for both callers (Daniele Ceraolo) Fixes: 99afb7cc ("drm/i915/pxp: Add ARB session creation and cleanup") Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
-
- 19 Jun, 2023 4 commits
-
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
Updates for v6.5.. this includes a backmerg of drm-next tree to be able to use new DRM DSC helpers. Core: + Add Marijn Suijten as drm/msm reviewer + Adreno A660 bindings + SM8350 MDSS bindings fix + Fix adreno_is_a690() warnings + More generic (DRM) and MSM-specific DSC helpers DP: + Removed obsolete USB-PD remains + Documented DP compatible string for sm8550 platform DPU: + Enable missing features (DSPP, DSC, split display) on sc8180x, sc8280xp, sm8450 + Enabled writeback on sc7280 + Implemented tearcheck support to support vsync on SM150 and newer platforms + Native HDMI output support + Dropped unused features: regdma, GC, IGC + Fixed the DSC flush operations + Simplified QoS handling, removing obsolete and unused features and merging SSPP and WB code paths + Reworked dpu_encoder initialisation path + Enabled DSPP support on sdm845 + Disabled color-management if DSPP blocks are not available + Added support for DSC 1.2 blocks found on sm8350 and later + Added .fb_dirty to fix CMD panels DSI: + Drop powerup quirks in favour of using pre_enable_prev_first for downstream bridges + Fixed 14nm DSI PHY programming + Added support for DSI and 28nm DSI PHY on MSM8226 platform + Make use of DRM and MSM DSC helpers MDP5: + Added support for display controller on MSM8226 platform GPU: + A690 support + Don't set IO_PGTABLE_QUIRK_ARM_OUTER_WBWA on devices with coherent SMMU (like A690) + Move cmdstream dumping out of fence signaling path + Cleanups + Support for a6xx devices without GMU (aka "GMU wrapper" + a610 support + a619_holi support (a619 variant without GMU) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsUB=tRB4nR6ZCJMuLhro5zN3BQWUSywVYbaipqqDZ_cQ@mail.gmail.com
-
Dave Airlie authored
Backmerge tag 'v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Linux 6.4-rc7 Need this to pull in the msm work. Signed-off-by:
-
https://gitlab.freedesktop.org/agd5f/linuxDave Airlie authored
amd-drm-next-6.5-2023-06-16: amdgpu: - Misc display fixes - W=1 fixes - Improve scheduler naming - DCN 3.1.4 fixes - kdoc fixes - Enable W=1 - VCN 4.0 fix - xgmi fixes - TOPDOWN fix for large BAR systems - eDP fix - PSR fixes - SubVP fixes - Freesync fix - DPIA fix - SMU 13.0.5 fixes - vblflash fix - RAS fixes - SDMA 4 fix - BO locking fix - BO backing store fix - NBIO 7.9 fixes - GC 9.4.3 fixes - GPU reset recovery fixes - HMM fix amdkfd: - Fix NULL check - Trap fixes - Queue count fix - Add event age tracking radeon: - fbdev client fix scheduler: - Avoid an infinite loop UAPI: - Add KFD event age tracking: Proposed ROCT-Thunk-Interface: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/efdbf6cfbc026bd68ac3c35d00dacf84370eb81e https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/1820ae0a2db85b6f584611dc0cde1a00e7c22915 Proposed ROCR-Runtime: https://github.com/RadeonOpenCompute/ROCR-Runtime/compare/master...zhums:ROCR-Runtime:new_event_wait_review https://github.com/RadeonOpenCompute/ROCR-Runtime/commit/e1f5bdb88eb882ac798aeca2c00ea3fbb2dba459 https://github.com/RadeonOpenCompute/ROCR-Runtime/commit/7d26afd14107b5c2a754c1a3f415d89f3aabb503 drm: - DP MST fix Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2023-06-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Short summary of fixes pull: * Fix fbdev initializer macros Signed-off-by:
-
- 18 Jun, 2023 26 commits
-
-
Linus Torvalds authored
-
Konrad Dybcio authored
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125 (trinket) and SM6225 (khaje). Trinket does not support speed binning (only a single SKU exists) and we don't yet support khaje upstream. Hence, add a fuse mapping table for bengal to allow for per-chip frequency limiting. Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/542780/Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375 (blair). This is what seems to be a first occurrence of this happening, but it's easy to overcome by guarding the SoC-specific fuse values with of_machine_is_compatible(). Do just that to enable frequency limiting on these SoCs. Reviewed-by:
-
Konrad Dybcio authored
Before transitioning to using per-SoC and not per-Adreno speedbin fuse values (need another patchset to land elsewhere), a good improvement/stopgap solution is to use adreno_is_aXYZ macros in place of explicit revision matching. Do so to allow differentiating between A619 and A619_holi. Reviewed-by:
-
Konrad Dybcio authored
The GPU can only be one at a time. Turn a series of ifs into if + elseifs to save some CPU cycles. Reviewed-by:
-
Konrad Dybcio authored
Adreno 619 expects some tunables to be set differently. Make up for it. Fixes: b7616b5c ("drm/msm/adreno: Add A619 support") Reviewed-by:
-
Konrad Dybcio authored
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It features no GMU, as it's implemented solely on SoCs with SMD_RPM. What's more interesting is that it does not feature a VDDGX line either, being powered solely by VDDCX and has an unfortunate hardware quirk that makes its reset line broken - after a couple of assert/ deassert cycles, it will hang for good and will not wake up again. This GPU requires mesa changes for proper rendering, and lots of them at that. The command streams are quite far away from any other A6XX GPU and hence it needs special care. This patch was validated both by running an (incomplete) downstream mesa with some hacks (frames rendered correctly, though some instructions made the GPU hangcheck which is expected - garbage in, garbage out) and by replaying RD traces captured with the downstream KGSL driver - no crashes there, ever. Add support for this GPU on the kernel side, which comes down to pretty simply adding A612 HWCG tables, altering a few values and adding a special case for handling the reset line. Reviewed-by:
-
Konrad Dybcio authored
A619_holi is a GMU-less variant of the already-supported A619 GPU. It's present on at least SM4350 (holi) and SM6375 (blair). No mesa changes are required. Add the required kernel-side support for it. Signed-off-by:
-
Konrad Dybcio authored
A610 and A619_holi don't support the feature. Disable it to make the GPU stop crashing after almost each and every submission - the received data on the GPU end was simply incomplete in garbled, resulting in almost nothing being executed properly. Extend the disablement to adreno_has_gmu_wrapper, as none of the GMU wrapper Adrenos that don't support yet seem to feature it. Reviewed-by:
-
Konrad Dybcio authored
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs but don't implement the associated GMUs. This is due to the fact that the GMU directly pokes at RPMh. Sadly, this means we have to take care of enabling & scaling power rails, clocks and bandwidth ourselves. Reuse existing Adreno-common code and modify the deeply-GMU-infused A6XX code to facilitate these GPUs. This involves if-ing out lots of GMU callbacks and introducing a new type of GMU - GMU wrapper (it's the actual name that Qualcomm uses in their downstream kernels). This is essentially a register region which is convenient to model as a device. We'll use it for managing the GDSCs. The register layout matches the actual GMU_CX/GX regions on the "real GMU" devices and lets us reuse quite a bit of gmu_read/write/rmw calls. Signed-off-by:
-
Konrad Dybcio authored
Since the introduction of A6xx support, we've been enabling the CX GMU power counter 0 in a bit of a weird spot. Move it to hw_init so that GMU wrapper GPUs can reuse the same code paths. As a bonus, this order makes it easier to compare mainline and downstream register access traces. Signed-off-by:
-
Konrad Dybcio authored
Rename lower_bit to hbb_lo and explain what it signifies. Add explanations (wherever possible to other tunables). Port setting min_access_length, ubwc_mode and hbb_hi from downstream. Reviewed-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Konrad Dybcio authored
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also need REG_A6XX_GBIF_HALT to be set to 0. This is typically done automatically on successful GX collapse, but in case that fails, we should take care of it. Also, add a memory barrier to ensure it's gone through before jumping to further initialization. Reviewed-by:
-
Konrad Dybcio authored
Introduce a6xx_gpu_sw_reset() in preparation for adding GMU wrapper GPUs and reuse it in a6xx_gmu_force_off(). This helper, contrary to the original usage in GMU code paths, adds a readback+delay sequence to ensure that the reset is never deasserted too quickly due to e.g. OoO execution going crazy. Signed-off-by:
-
Konrad Dybcio authored
Unify the indentation and explain the cryptic 0xF value. Reviewed-by:
-
Konrad Dybcio authored
This function is responsible for telling the GPU to halt transactions on all of its relevant buses, drain them and leave them in a predictable state, so that the GPU can be e.g. reset cleanly. Move the function to a6xx_gpu.c, remove the static keyword and add a prototype in a6xx_gpu.h to accomodate for the move. Reviewed-by:
-
Konrad Dybcio authored
As pointed out by Akhil during the review process of GMU wrapper introduction [1], it makes sense to move this write into the function that's responsible for forcibly shutting the GMU off. It is also very convenient to move this to GMU-specific code, so that it does not have to be guarded by an if-condition to avoid calling it on GMU wrapper targets. Move the write to the aforementioned a6xx_gmu_force_off() to achieve that. No effective functional change. [1] https://lore.kernel.org/linux-arm-msm/20230501194022.GA18382@akhilpo-linux.qualcomm.com/Reviewed-by:
-
Konrad Dybcio authored
These two will be reused by at least A619_holi in the non-gmu paths. Turn them non-static them to make it possible. Reviewed-by:
-
Konrad Dybcio authored
The adreno_is_revn rework came at the same time as A690 introduction and that resulted in it not covering all cases. Fix it. Signed-off-by:
-
Konrad Dybcio authored
The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks we'd normally assign to the GMU as if they were a part of the GMU, even though they are not". It's a (good) software representation of the GMU_CX and GMU_GX register spaces within the GPUSS that helps us programatically treat these de-facto GMU-less parts in a way that's very similar to their GMU-equipped cousins, massively saving up on code duplication. The "wrapper" register space was specifically designed to mimic the layout of a real GMU, though it rather obviously does not have the M3 core et al. To sum it all up, the GMU wrapper is essentially a register space within the GPU, which Linux sees as a dumbed-down regular GMU: there's no clocks, interrupts, multiple reg spaces, iommus and OPP. Document it. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Konrad Dybcio authored
The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks we'd normally assign to the GMU as if they were a part of the GMU, even though they are not". It's a (good) software representation of the GMU_CX and GMU_GX register spaces within the GPUSS that helps us programatically treat these de-facto GMU-less parts in a way that's very similar to their GMU-equipped cousins, massively saving up on code duplication. The "wrapper" register space was specifically designed to mimic the layout of a real GMU, though it rather obviously does not have the M3 core et al. GMU wrapper-equipped A6xx GPUs require clocks and clock-names to be specified under the GPU node, just like their older cousins. Account for that. Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Four fixes, all in drivers: three fairly obvious small ones and a large one in aacraid to add block queue completion mapping and fix a CPU offline hang" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: lpfc: Fix incorrect big endian type assignment in bsg loopback path scsi: target: core: Fix error path in target_setup_session() scsi: storvsc: Always set no_report_opcodes scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity
-
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libataLinus Torvalds authored
Pull ata fix from Damien Le Moal: - Avoid deadlocks on resume from sleep by delaying scsi rescan until the scsi device is also fully resumed. * tag 'ata-6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: ata: libata-scsi: Avoid deadlock on rescan after device resume
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull parisc fix from Helge Deller: - Drop redundant register definitions to fix build with latest binutils * tag 'parisc-for-6.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Delete redundant register definitions in <asm/assembly.h>
-
Liam R. Howlett authored
The error unrolling was leaving the VMAs detached in many cases and leaving the locked_vm statistic altered, and skipping the unrolling entirely in the case of the vma tree write failing. Fix the error path by re-attaching the detached VMAs and adding the necessary goto for the failed vma tree write, and fix the locked_vm statistic by only updating after the vma tree write succeeds. Fixes: 763ecb03 ("mm: remove the vma linked list") Reported-by:
Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by:
Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Damien Le Moal authored
When an ATA port is resumed from sleep, the port is reset and a power management request issued to libata EH to reset the port and rescanning the device(s) attached to the port. Device rescanning is done by scheduling an ata_scsi_dev_rescan() work, which will execute scsi_rescan_device(). However, scsi_rescan_device() takes the generic device lock, which is also taken by dpm_resume() when the SCSI device is resumed as well. If a device rescan execution starts before the completion of the SCSI device resume, the rcu locking used to refresh the cached VPD pages of the device, combined with the generic device locking from scsi_rescan_device() and from dpm_resume() can cause a deadlock. Avoid this situation by changing struct ata_port scsi_rescan_task to be a delayed work instead of a simple work_struct. ata_scsi_dev_rescan() is modified to check if the SCSI device associated with the ATA device that must be rescanned is not suspended. If the SCSI device is still suspended, ata_scsi_dev_rescan() returns early and reschedule itself for execution after an arbitrary delay of 5ms. Reported-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Reported-by:
Joe Breuer <linux-kernel@jmbreuer.net> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217530 Fixes: a19a93e4 ("scsi: core: pm: Rely on the device driver core for async power management") Signed-off-by:
Damien Le Moal <dlemoal@kernel.org> Reviewed-by:
Hannes Reinecke <hare@suse.de> Tested-by:
-
