summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-07-01drm/xe/pf: Restart VFs provisioning after GT resetMichal Wajdeczko
Any prior configurations pushed to the GuC are lost when the GT is reset. Push again all non-empty VF configurations to the GuC as part of the GuC reset procedure. This will also help restore early manual provisioning, when the PF was in the meantime suspended and then resumed. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240701102738.934-3-michal.wajdeczko@intel.com
2024-07-01drm/xe/pf: Skip fair VFs provisioning if already provisionedMichal Wajdeczko
Our debugfs allows to view and change VFs' provisioning configs. If we attempt to experiment with VFs provisioning before enabling them, this early config will affect fair provisioning calculations, and will also be overwritten, which is undesirable behavior. To improve this, check if the VFs configs are empty (unprovisioned) before starting the fair provisioning procedure. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240701102738.934-2-michal.wajdeczko@intel.com
2024-07-01drm/xe/pf: Remove inlined #ifdef CONFIG_PCI_IOVMichal Wajdeczko
We can remove #ifdef CONFIG_PCI_IOV in .c files if we provide dummy replacement of the xe_pci_sriov_configure() function. Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627104305.1477-1-michal.wajdeczko@intel.com
2024-07-01drm/xe/guc: Configure TLB timeout based on CT buffer sizeNirmoy Das
GuC TLB invalidation depends on GuC to process the request from the CT queue and then the real time to invalidate TLB. Add a function to return overestimated possible time a TLB inval H2G might take which can be used as timeout value for TLB invalidation wait time. v4: Make sure CTB is in 4K blocks(Michal) and other doc fixes v3: Pass CT to xe_guc_ct_queue_proc_time_jiffies() (Michal) Add tlb_timeout_jiffies() that replaces TLB_TIMEOUT(Michal) v2: Address reviews from Michal. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1622 Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628085845.2369-1-nirmoy.das@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2024-07-01drm: panel-orientation-quirks: Add labels for both Valve Steam Deck revisionsMatthew Schwartz
This accounts for the existence of two Steam Deck revisions instead of a single revision Signed-off-by: Matthew Schwartz <mattschwartz@gwu.edu> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628205822.348402-3-mattschwartz@gwu.edu
2024-07-01drm: panel-orientation-quirks: Add quirk for Valve GalileoJohn Schoenick
Valve's Steam Deck Galileo revision has a 800x1280 OLED panel Cc: stable@vger.kernel.org # 6.1+ Signed-off-by: John Schoenick <johns@valvesoftware.com> Signed-off-by: Matthew Schwartz <mattschwartz@gwu.edu> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628205822.348402-2-mattschwartz@gwu.edu
2024-07-01drm/tests: Add tests for the new Monochrome value of tv_modeDave Stevenson
Adds test for the cmdline parser, connector property, and drm_analog_tv_mode to ensure the behaviour of the new value is correct. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240620110947.3615207-1-dave.stevenson@raspberrypi.com
2024-07-01drm/i915/display: For MTL+ platforms skip mg dp programmingImre Deak
For MTL+ platforms we use PICA chips for Type-C support and hence mg programming is not needed. Fixes issue with drm warn of TC port not being in legacy mode. Cc: stable@vger.kernel.org Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240625111840.597574-1-mika.kahola@intel.com (cherry picked from commit aaf9dc86bd806458f848c39057d59e5aa652a399) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-06-30drm/lima: Mark simple_ondemand governor as softdepDragan Simic
Lima DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Lima, to have its kernel module included in the initial ramdisk. This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or may have forced some users to introduce unnecessary workarounds. Having simple_ondemand marked as a softdep for Lima may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [3] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [4] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet. [1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinephone/-/blob/6.7-megi/config?ref_type=heads#L5749 [2] https://gitlab.com/postmarketOS/pmaports/-/blob/7f64e287e7732c9eaa029653e73ca3d4ba1c8598/main/linux-postmarketos-allwinner/config-postmarketos-allwinner.aarch64#L4654 [3] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d [4] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad Cc: Philip Muller <philm@manjaro.org> Cc: Oliver Smith <ollieparanoid@postmarketos.org> Cc: Daniel Smith <danct12@disroot.org> Cc: stable@vger.kernel.org Fixes: 1996970773a3 ("drm/lima: Add optional devfreq and cooling device support") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/fdaf2e41bb6a0c5118ff9cc21f4f62583208d885.1718655070.git.dsimic@manjaro.org
2024-06-29drm/msm/adreno: Introduce gmu_chipid for a740 & a750Akhil P Oommen
To simplify, introduce the new gmu_chipid for a740 & a750 GPUs. Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/601396/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-06-29drm/msm/adreno: Add support for X185 GPUAkhil P Oommen
Add support in drm/msm driver for the Adreno X185 gpu found in Snapdragon X1 Elite chipset. Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/601399/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-06-29drm/msm/adreno: fix a743 and a740 cx mem initNeil Armstrong
Disable the call to qcom_scm_gpu_init_regs() for a730 and a740 after init failures on the HDK8550 and HDK8450 platforms: msm_dpu ae01000.display-controller: failed to load adreno gpu msm_dpu ae01000.display-controller: failed to bind 3d00000.gpu (ops a3xx_ops [msm]): -5 msm_dpu ae01000.display-controller: adev bind failed: -5 While debugging, it happens the call to: qcom_scm_gpu_init_regs(QCOM_SCM_GPU_ALWAYS_EN_REQ) returns -5 and makes the gpu fail to initialize. Remove the scm call since it's not done downstream either and works fine without. Fixes: 14b27d5df3ea ("drm/msm/a7xx: Initialize a750 "software fuse"") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/600972/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-06-29drm/msm/adreno: fix a7xx gpu initNeil Armstrong
The gpulist has twice the a6xx gpulist, replace the second one with the a7xx gpulist. Solves: msm_dpu ae01000.display-controller: Unknown GPU revision: 7.3.0.1 msm_dpu ae01000.display-controller: Unknown GPU revision: 67.5.10.1 msm_dpu ae01000.display-controller: Unknown GPU revision: 67.5.20.1 on SM8450, SM8550 & SM8560. Fixes: 8ed322f632a9 ("drm/msm/adreno: Split up giant device table") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/600939/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-06-29Revert "drm/msm/a6xx: Poll for GBIF unhalt status in hw_init"Konrad Dybcio
Commit f6ebff4fe810 ("drm/msm/adreno: De-spaghettify the use of memory barriers") made some fixups relating to write arrival, ensuring that the GPU's memory interface has *really really really* been told to come out of reset. That in turn rendered the hacky commit being reverted no longer necessary. Get rid of it. This reverts commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/600870/ Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-06-29drm/msm/adreno: De-spaghettify the use of memory barriersKonrad Dybcio
Memory barriers help ensure instruction ordering, NOT time and order of actual write arrival at other observers (e.g. memory-mapped IP). On architectures employing weak memory ordering, the latter can be a giant pain point, and it has been as part of this driver. Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of readl/writel, which include r/w (respectively) barriers. Replace the barriers with a readback (or drop altogether where possible) that ensures the previous writes have exited the write buffer (as the CPU must flush the write to the register it's trying to read back). Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/600869/ Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-06-28kernel-wide: fix spelling mistakes like "assocative" -> "associative"Jesse Brandeburg
There were several instances of the string "assocat" in the kernel, which should have been spelled "associat", with the various endings of -ive, -ed, -ion, and sometimes beginnging with dis-. Add to the spelling dictionary the corrections so that future instances will be caught by checkpatch, and fix the instances found. Originally noticed by accident with a 'git grep socat'. Link: https://lkml.kernel.org/r/20240612001247.356867-1-jesse.brandeburg@intel.com Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-28drm/xe/mcr: Avoid clobbering DSS steeringMatt Roper
A couple copy/paste mistakes in the code that selects steering targets for OADDRM and INSTANCE0 unintentionally clobbered the steering target for DSS ranges in some cases. The OADDRM/INSTANCE0 values were also not assigned as intended, although that mistake wound up being harmless since the desired values for those specific ranges were '0' which the kzalloc of the GT structure should have already taken care of implicitly. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626210536.1620176-2-matthew.d.roper@intel.com
2024-06-28drm/xe/mocs: Clarify difference between hw and sw sizesMatt Roper
It's not very obvious what the difference is between the 'size' and 'n_entries' fields of the MOCS structure. Rename both fields slightly and add some comments explaining that one is the documentation-defined table size, while the other is the number of entries that can be programmed into the hardware (and the documented table size can potentially be smaller than the number of hardware entries). Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627203741.2042752-4-matthew.d.roper@intel.com
2024-06-28drm/xe/mocs: Update MOCS assertions and remove redundant checksMatt Roper
Rely more heavily on assertions to describe the MOCS programming invariants. CI checks these assertions and will ensure no violations sneak in due to programmer error, so we can remove some of the redundant WARN and silent return checks from non-debug builds. Also tweak/augment some of the existing assertions: there's no reason we'd ever want a platform not to have a MOCS 'ops' structure hooked up so ensure info->ops is non-NULL. Likewise, we should never have a case where the bspec-defined MOCS setting table is larger than the number of MOCS registers exposed by the hardware, so add an extra assert on those sizes as well. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627203741.2042752-3-matthew.d.roper@intel.com
2024-06-28drm/xe: Get hwe domain specific FW to read RING_TIMESTAMPUmesh Nerlige Ramappa
Per client engine utilization uses RING_TIMESTAMP to return drm-total-cycles to the user. Current code uses XE_FW_GT to read this register on the first available engine in a GT. When testing on DG2, it is observed that this value is 0 when running test on some engines. To resolve that, get the hwe domain specific FW for reading the engine timestamp. v2: - update commit message - use domain specific FW (Matt) v3: - Drop check for hwe in the helper (Matt, Michal) v4: - checkpatch fixes v5: Rebase Fixes: 188ced1e0ff8 ("drm/xe/client: Print runtime to fdinfo") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627235105.2631135-1-umesh.nerlige.ramappa@intel.com
2024-06-28drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesMa Ke
In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable@vger.kernel.org Fixes: 6ee738610f41 ("drm/nouveau: Add DRM driver for NVIDIA GPUs") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627074204.3023776-1-make24@iscas.ac.cn
2024-06-28drm/mediatek/dp: Fix spurious kfree()Michael Walle
drm_edid_to_sad() might return an error or just zero. If that is the case, we must not free the SADs because there was no allocation in the first place. Fixes: dab12fa8d2bd ("drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection") Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20240604083337.1879188-1-mwalle@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2024-06-28drm/mediatek: dpi/dsi: Fix possible_crtcs calculationMichael Walle
mtk_find_possible_crtcs() assumes that the main path will always have the CRTC with id 0, the ext id 1 and the third id 2. This is only true if the paths are all available. But paths are optional (see also comment in mtk_drm_kms_init()), e.g. the main path might not be enabled or available at all. Then the CRTC IDs will shift one up, e.g. ext will be 0 and the third path will be 1. To fix that, dynamically calculate the IDs by the presence of the paths. While at it, make the return code a signed one and return -ENODEV if no path is found and handle the error in the callers. Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc way") Suggested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240606092122.2026313-1-mwalle@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2024-06-28drm/i915/mtl: Skip PLL state verification in TBT modeImre Deak
In TBT-alt mode the driver doesn't program the PHY's PLL, which is handled instead by Thunderbolt driver/FW components, hence the PLL's HW vs. SW state verification should be skipped. During HW readout set a flag in the PLL state if the port was at the moment in TBT-alt mode and skip the verification of PLL parameters in this case. Fixes: 45fe957ae769 ("drm/i915/display: Add compare config for MTL+ platforms") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11258 Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626170813.806470-1-imre.deak@intel.com
2024-06-28drm/stm: dsi: expose DSI PHY internal clockRaphael Gallais-Pou
DSISRC __________ __\_ | \ pll4_p_ck ->| 1 |____dsi_k ck_dsi_phy ->| 0 | |____/ A DSI clock is missing in the clock framework. Looking at the clk_summary, it appears that 'ck_dsi_phy' is not implemented. Since the DSI kernel clock is based on the internal DSI pll. The common clock driver can not directly expose this 'ck_dsi_phy' clock because it does not contain any common registers with the DSI. Thus it needs to be done directly within the DSI phy driver. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by: Yannick Fertre <yannick.fertre@foss.st.com> Tested-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240129104106.43141-4-raphael.gallais-pou@foss.st.com
2024-06-28drm/stm: dsi: add pm runtime opsYannick Fertre
Update control of clocks and supply thanks to the PM runtime mechanism to avoid kernel crash during a system suspend. Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by: Yannick Fertre <yannick.fertre@foss.st.com> Tested-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240129104106.43141-3-raphael.gallais-pou@foss.st.com
2024-06-28drm/stm: dsi: use new SYSTEM_SLEEP_PM_OPS() macroRaphael Gallais-Pou
Use RUNTIME_PM_OPS() instead of the old SET_SYSTEM_SLEEP_PM_OPS(). This means we don't need __maybe_unused on the functions. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by: Yannick Fertre <yannick.fertre@foss.st.com> Tested-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240129104106.43141-2-raphael.gallais-pou@foss.st.com
2024-06-28drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driverRaphael Gallais-Pou
The Low-Voltage Differential Signaling (LVDS) Display Interface Transmitter handles the LVDS protocol: it maps the pixels received from the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS PHY. It is composed of three sub blocks: * LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input pixels onto the data lanes of the PHY * LVDS PHY: parallelize the data and drives the LVDS data lanes * LVDS wrapper: handles top-level settings The LVDS controller driver supports the following high-level features: * FDP-Link-I and OpenLDI (v0.95) protocols * Single-Link or Dual-Link operation * Single-Display or Double-Display (with the same content duplicated on both) * Flexible Bit-Mapping, including JEIDA and VESA * RGB888 or RGB666 output * Synchronous design, with one input pixel per clock cycle Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226-lvds-v6-2-15e3463fbe70@foss.st.com
2024-06-28drm/panel: jd9365da: Add the function of adjusting orientationZhaoxiong Lv
This driver does not have the function to adjust the orientation, so this function is added. Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240624141926.5250-6-lvzhaoxiong@huaqin.corp-partner.google.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-6-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28drm/panel: jd9365da: Support for kd101ne3-40ti MIPI-DSI panelZhaoxiong Lv
The K&d kd101ne3-40ti is a 10.1" WXGA TFT-LCD panel, use jd9365da controller,which fits in nicely with the existing panel-jadard-jd9365da-h3 driver.Hence,we add a new compatible with panel specific config. Although they have the same control IC, the two panels are different, and the timing will be slightly different, so we added some variables in struct jadard_panel_desc to control the timing. Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com> Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240624141926.5250-5-lvzhaoxiong@huaqin.corp-partner.google.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-5-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28drm/panel: panel-jadard-jd9365da-h3: use wrapped MIPI DCS functionsZhaoxiong Lv
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to simplify driver's init/enable/exit code. Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240624141926.5250-4-lvzhaoxiong@huaqin.corp-partner.google.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-4-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28drm/panel: jd9365da: Modify the method of sending commandsZhaoxiong Lv
Currently, the init_code of the jd9365da driver is placed in the enable() function and sent, but this seems to take a long time. It takes 17ms to send each instruction (an init code consists of about 200 instructions), so it takes about 3.5s to send the init_code. So we moved the sending of the inti_code to the prepare() function, and each instruction seemed to take only 25μs. We checked the DSI host and found that the difference in command sending time is caused by the different modes of the DSI host in prepare() and enable() functions. Our DSI Host only supports sending cmd in LP mode, The prepare() function can directly send init_code (LP->cmd) in LP mode, but the enable() function is in HS mode and needs to switch to LP mode before sending init code (HS->LP->cmd->HS). Therefore, it takes longer to send the command. Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240624141926.5250-2-lvzhaoxiong@huaqin.corp-partner.google.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240624141926.5250-2-lvzhaoxiong@huaqin.corp-partner.google.com
2024-06-28drm/panel: simple: Add AUO G104STN01 panel entryPaul Gerber
Add support for the AUO G104STN01 10.4" (800x600) LCD-TFT panel. Signed-off-by: Paul Gerber <paul.gerber@ew.tq-group.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240627084446.3197196-3-paul.gerber@ew.tq-group.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240627084446.3197196-3-paul.gerber@ew.tq-group.com
2024-06-28drm/drm_file: Fix pid refcounting raceJann Horn
<maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de> filp->pid is supposed to be a refcounted pointer; however, before this patch, drm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelist_mutex, making the following race possible: process A process B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid B>, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid A>, 1) mutex_unlock(&dev->filelist_mutex) get_pid(<pid A>) synchronize_rcu() put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here *** get_pid(<pid B>) *** UAF *** synchronize_rcu() put_pid(<pid A>) As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y because it requires RCU to detect a quiescent state in code that is not explicitly calling into the scheduler. This race leads to use-after-free of a "struct pid". It is probably somewhat hard to hit because process A has to pass through a synchronize_rcu() operation while process B is between mutex_unlock() and get_pid(). Fix it by ensuring that by the time a pointer to the current task's pid is stored in the file, an extra reference to the pid has been taken. This fix also removes the condition for synchronize_rcu(); I think that optimization is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above. Fixes: 1c7a387ffef8 ("drm: Update file owner during use") Cc: <stable@vger.kernel.org> Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2024-06-28Merge tag 'drm-misc-next-2024-06-27' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.11: UAPI Changes: Cross-subsystem Changes: Core Changes: - panic: Monochrome logo support, Various fixes - ttm: Improve the number of page faults on some platforms, Fix test build breakage with PREEMPT_RT, more test coverage and various test improvements Driver Changes: - Add missing MODULE_DESCRIPTION where needed - ipu-v3: Various fixes - vc4: Monochrome TV support - bridge: - analogix_dp: Various improvements and reworks, handle AUX transfers timeout - tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR, Fix clock calculations - panels: - More transitions to mipi_dsi wrapped functions - New panels: Lincoln Technologies LCD197, Ortustech COM35H3P70ULC, Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627-congenial-pistachio-nyala-848cf4@houat
2024-06-28drm/i915/gem: Suppress oom warning in favour of ENOMEM to userspaceNirmoy Das
We report object allocation failures to userspace with ENOMEM so add __GFP_NOWARN to remove superfluous oom warnings. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/4936 Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626143318.11600-1-nirmoy.das@intel.com
2024-06-27drm/amd: Don't initialize ISP hardware without FWMario Limonciello
Although designs may contain an ISP IP block, the camera might be a USB camera. Because of this the ISP firmware is considered optional from amdgpu. However if the firmware doesn't get loaded the hardware should not be initialized. Adjust the return code for early init to ensure the IP block doesn't go through the other init and fini sequences. Also decrease the message about firmware load failure to debug so it's not as alarming to users. Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amdgpu: refine isp firmware loadingYang Wang
refine isp firmware loading Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amd/amdgpu: Enable MMHUB prefetch for ISP v4.1.0 and 4.1.1Pratap Nirujogi
Remove temporary WA to disable ISP prefetch as MMHUB SAW is initialized to support ISP HW access GART memory using the TLSi path with prefetch enabled. Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amd/amdgpu: Fix 'snprintf' output truncation warningPratap Nirujogi
snprintf can truncate the output fw filename if the isp ucode_prefix exceeds 29 characters. Knowing ISP ucode_prefix is in the format isp_x_x_x, limiting the size of ucode_prefix[] to 10 characters to fix the warning. Fixes the below warning: drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c: In function 'isp_early_init': drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c:192:58: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] 192 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", ucode_prefix); | ^ In function 'isp_load_fw_by_psp', inlined from 'isp_early_init' at drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c:218:8: drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c:192:9: note: 'snprintf' output between 12 and 41 bytes into a destination of size 40 192 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", ucode_prefix); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amd/amdgpu: Disable MMHUB prefetch for ISP v4.1.1Pratap Nirujogi
Disable MMHUB prefetch for ISP v4.1.1 as a temporary WA until the GART supports MMHUB TLSi and SAW for ISP HW to access GART memory using the TLSi path. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amd/amdgpu: Add ISP4.1.0 and ISP4.1.1 modulesPratap Nirujogi
Add independent IP centric modules for ISP4.1.0 and ISP4.1.1 hw blocks. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amd/amdgpu: Map ISP interrupts as generic IRQsPratap Nirujogi
Map ISP IH interrupts to Linux generic IRQ for ISP driver to handle the interrupts using MFD IORESOURCE_IRQ resource. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amdgpu: fix Kconfig for ISP v2Alex Deucher
Add new config option and set proper dependencies for ISP. v2: add missed guards, drop separate Kconfig Reviewed-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Pratap Nirujogi <pratap.nirujogi@amd.com>
2024-06-27drm/amd/amdgpu: Enable ISP in amdgpu_discoveryPratap Nirujogi
Enable ISP for ISP V4.1.0 and V4.1.1 in amdgpu_discovery. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amd/amdgpu: Add ISP driver supportPratap Nirujogi
Add the isp driver in amdgpu to support ISP device on the APUs that supports ISP IP block. ISP hw block is used for camera front-end, pre and post processing operations. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amd/amdgpu: Add ISP support to amdgpu_discoveryPratap Nirujogi
ISP hw block is supported in some of the AMD GPU versions, add support to discover ISP IP in amdgpu_discovery. v2: squash in documentation update (Alex) Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amdgpu/jpeg5: Add support for DPG modeSonny Jiang
Add DPG support for JPEG 5.0 Signed-off-by: Sonny Jiang <sonjiang@amd.com> Acked-by: Saleemkhan Jamadar <saleemkhan.jamadar@amd.com> Reviewed-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amdgpu: tolerate allocating GTT bo with dcc flagFrank Min
Do not return failure for allocating GTT bo with dcc flag on gfx12. This will improve compatibility for UMD. Signed-off-by: Frank Min <Frank.Min@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-06-27drm/amd/display: Fix null pointer deref in dcn20_resource.cAurabindo Pillai
Fixes a hang thats triggered when MPV is run on a DCN401 dGPU: mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all and then enabling fullscreen playback (double click on the video) The following calltrace will be seen: [ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 181.843997] #PF: supervisor instruction fetch in kernel mode [ 181.844003] #PF: error_code(0x0010) - not-present page [ 181.844009] PGD 0 P4D 0 [ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI [ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018 [ 181.844044] RIP: 0010:0x0 [ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246 [ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004 [ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400 [ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c [ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8 [ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005 [ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000 [ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0 [ 181.844141] Call Trace: [ 181.844146] <TASK> [ 181.844153] ? show_regs+0x6d/0x80 [ 181.844167] ? __die+0x24/0x80 [ 181.844179] ? page_fault_oops+0x99/0x1b0 [ 181.844192] ? do_user_addr_fault+0x31d/0x6b0 [ 181.844204] ? exc_page_fault+0x83/0x1b0 [ 181.844216] ? asm_exc_page_fault+0x27/0x30 [ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu] [ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu] [ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu] [ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu] [ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu] [ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu] Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-28 17:27:56 +0000