dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH] drm/ast: Support 1600x900 with 108MHz PCLK
by KuoHsiang Chou 23 Dec '21

23 Dec '21

[New] Create the setting for 1600x900 @60Hz refresh rate by 108MHz pixel-clock. Signed-off-by: KuoHsiang Chou <kuohsiang_chou(a)aspeedtech.com> --- drivers/gpu/drm/ast/ast_tables.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ast/ast_tables.h b/drivers/gpu/drm/ast/ast_tables.h index d665dd5af5dd..8414e543f260 100644 --- a/drivers/gpu/drm/ast/ast_tables.h +++ b/drivers/gpu/drm/ast/ast_tables.h @@ -282,6 +282,8 @@ static const struct ast_vbios_enhtable res_1360x768[] = { }; static const struct ast_vbios_enhtable res_1600x900[] = { + {1800, 1600, 24, 80,1000, 900, 1, 3, VCLK108, /* 60Hz */ + (SyncPP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo), 60, 3, 0x3A }, {1760, 1600, 48, 32, 926, 900, 3, 5, VCLK97_75, /* 60Hz CVT RB */ (SyncNP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo | AST2500PreCatchCRT), 60, 1, 0x3A }, -- 2.18.4

5 6

[PATCH v1 0/5] Improvements for TC358768 DSI bridge driver
by Dmitry Osipenko 21 Dec '21

21 Dec '21

This series adds couple improvements to the TC358768 DSI bridge driver, enabling Panasonic VVX10F004B00 DSI panel support. This panel is used by ASUS Transformer TF700T tablet, which is ready for upstream kernel and display panel support is the biggest missing part. Dmitry Osipenko (5): drm/bridge: tc358768: Enable reference clock drm/bridge: tc358768: Support pulse mode drm/bridge: tc358768: Calculate video start delay drm/bridge: tc358768: Disable non-continuous clock mode drm/bridge: tc358768: Correct BTACNTRL1 programming drivers/gpu/drm/bridge/tc358768.c | 94 +++++++++++++++++++++++-------- 1 file changed, 71 insertions(+), 23 deletions(-) -- 2.32.0

2 15

[PATCH v3 0/2] Use "ref" clocks from firmware for DSI PLL VCO parent
by Marijn Suijten 21 Dec '21

21 Dec '21

All DSI PHY/PLL drivers were referencing their VCO parent clock by a global name, most of which don't exist or have been renamed. These clock drivers seem to function fine without that except the 14nm driver for sdm6xx [1]. At the same time all DTs provide a "ref" clock as per the requirements of dsi-phy-common.yaml, but the clock is never used. This patchset puts that clock to use without relying on a global clock name, so that all dependencies are explicitly defined in DT (the firmware) in the end. [1]: https://lore.kernel.org/linux-arm-msm/386db1a6-a1cd-3c7d-a88e-dc83f8a1be96@… Changes since v2: - Added Stephen's a-b and Angelo's r-bs; - Added .name fallback in msm8974's dsi_phy_28nm for a more graceful transition period; - Documented possible breakage in 1/2 if firmware isn't updated in parallel with the kernel. Changes since v1: - Dropped "arm: dts: qcom: apq8064: Use 27MHz PXO clock as DSI PLL reference" which has made its way into 5.15-fixes in advance of this patchset landing in 5.16; - Added Fixes: tags for commits that added missing "ref" clocks to DT while this firmware clock was never used (until this patchset); - Documented missing/wrong and later-added clocks (by aforementioned patches) in patch 1/2 more clearly. Marijn Suijten (2): drm/msm/dsi: Use "ref" fw clock instead of global name for VCO parent clk: qcom: gcc-sdm660: Remove transient global "xo" clock drivers/clk/qcom/gcc-sdm660.c | 14 -------------- drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 4 +++- 6 files changed, 15 insertions(+), 19 deletions(-) -- 2.33.0

3 9

[PATCH v2 0/8] Host1x context isolation support
by Mikko Perttunen 17 Dec '21

17 Dec '21

Hi all, *** New in v2: Added support for Tegra194 Use standard iommu-map property instead of custom mechanism *** this series adds support for Host1x 'context isolation'. Since when programming engines through Host1x, userspace can program in any addresses it wants, we need some way to isolate the engines' memory spaces. Traditionally this has either been done imperfectly with a single shared IOMMU domain, or by copying and verifying the programming command stream at submit time (Host1x firewall). Since Tegra186 there is a privileged (only usable by kernel) Host1x opcode that allows setting the stream ID sent by the engine to the SMMU. So, by allocating a number of context banks and stream IDs for this purpose, and using this opcode at the beginning of each job, we can implement isolation. Due to the limited number of context banks only each process gets its own context, and not each channel. This feature also allows sharing engines among multiple VMs when used with Host1x's hardware virtualization support - up to 8 VMs can be configured with a subset of allowed stream IDs, enforced at hardware level. To implement this, this series adds a new host1x context bus, which will contain the 'struct device's corresponding to each context bank / stream ID, changes to device tree and SMMU code to allow registering the devices and using the bus, as well as the Host1x stream ID programming code and support in TegraDRM. Device tree bindings are not updated yet pending consensus that the proposed changes make sense. Thanks, Mikko Mikko Perttunen (8): gpu: host1x: Add context bus gpu: host1x: Add context device management code gpu: host1x: Program context stream ID on submission iommu/arm-smmu: Attach to host1x context device bus arm64: tegra: Add Host1x context stream IDs on Tegra186+ drm/tegra: falcon: Set DMACTX field on DMA transactions drm/tegra: vic: Implement get_streamid_offset drm/tegra: Support context isolation arch/arm64/boot/dts/nvidia/tegra186.dtsi | 12 ++ arch/arm64/boot/dts/nvidia/tegra194.dtsi | 12 ++ drivers/gpu/Makefile | 3 +- drivers/gpu/drm/tegra/drm.h | 2 + drivers/gpu/drm/tegra/falcon.c | 8 + drivers/gpu/drm/tegra/falcon.h | 1 + drivers/gpu/drm/tegra/submit.c | 13 ++ drivers/gpu/drm/tegra/uapi.c | 34 ++++- drivers/gpu/drm/tegra/vic.c | 38 +++++ drivers/gpu/host1x/Kconfig | 5 + drivers/gpu/host1x/Makefile | 2 + drivers/gpu/host1x/context.c | 174 ++++++++++++++++++++++ drivers/gpu/host1x/context.h | 27 ++++ drivers/gpu/host1x/context_bus.c | 31 ++++ drivers/gpu/host1x/dev.c | 12 +- drivers/gpu/host1x/dev.h | 2 + drivers/gpu/host1x/hw/channel_hw.c | 52 ++++++- drivers/gpu/host1x/hw/host1x06_hardware.h | 10 ++ drivers/gpu/host1x/hw/host1x07_hardware.h | 10 ++ drivers/iommu/arm/arm-smmu/arm-smmu.c | 13 ++ include/linux/host1x.h | 21 +++ include/linux/host1x_context_bus.h | 15 ++ 22 files changed, 488 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/host1x/context.c create mode 100644 drivers/gpu/host1x/context.h create mode 100644 drivers/gpu/host1x/context_bus.c create mode 100644 include/linux/host1x_context_bus.h -- 2.32.0

5 16

[RFC PATCH 00/17] drm: bridge: Samsung MIPI DSIM bridge
by Jagan Teki 15 Dec '21

15 Dec '21

This series supports common bridge support for Samsung MIPI DSIM which is used in Exynos and i.MX8MM SoC's. The final bridge supports both the Exynos and i.MX8MM DSI devices. Right now bridge offers two sets of implementations. A. With component_ops and exynos specific code exclusively for exynos dsi drivers and it's legacy bindings. B. Without componenet_ops for newly implemented bridges and its users like i.MX8MM. The future plan is to fix the implementation A) by dropping component_ops and fixing exynos specific code in order to make the bridge more mature to use and the same is mentioned in drivers TODO. Patch 0001 - 0006: Bridge conversion Patch 0007 - 0017: Samsung MIPI DSIM bridge fixes, additions Tested in Engicam i.Core MX8M Mini SoM. Anyone interest, please have a look on this repo https://github.com/openedev/linux/tree/070421-imx8mm-dsim Would appreciate anyone from the exynos team to test it on the exynos platform? Any inputs? Jagan. Jagan Teki (17): drm/exynos: dsi: Convert to bridge driver drm/exynos: dsi: Handle drm_device for bridge drm/exynos: dsi: Use the drm_panel_bridge API drm/exynos: dsi: Create bridge connector for encoder drm/exynos: dsi: Get the mode from bridge drm/exynos: dsi: Handle exynos specifics via driver_data drm: bridge: Move exynos_drm_dsi into bridges dt-bindings: display: bridge: Add Samsung MIPI DSIM bridge drm: bridge: samsung-dsim: Add module init, exit drm: bridge: samsung-dsim: Update the of_node for port(s) drm: bridge: samsung-dsim: Find the possible DSI devices dt-bindings: display: bridge: samsung,mipi-dsim: Add i.MX8MM support drm: bridge: samsung-dsim: Add i.MX8MM support drm: bridge: samsung-dsim: Add input_bus_flags drm: bridge: samsung-dsim: Move DSI init in bridge enable drm: bridge: samsung-dsim: Fix PLL_P offset drm: bridge: samsung-dsim: Add bridge mode_fixup .../display/bridge/samsung,mipi-dsim.yaml | 360 +++++++++ .../bindings/display/exynos/exynos_dsim.txt | 90 --- MAINTAINERS | 12 + drivers/gpu/drm/bridge/Kconfig | 15 + drivers/gpu/drm/bridge/Makefile | 1 + .../samsung-dsim.c} | 758 ++++++++++-------- drivers/gpu/drm/exynos/Kconfig | 9 - drivers/gpu/drm/exynos/Makefile | 1 - 8 files changed, 795 insertions(+), 451 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt rename drivers/gpu/drm/{exynos/exynos_drm_dsi.c => bridge/samsung-dsim.c} (69%) -- 2.25.1

11 46

[PATCH v2 0/3] io-pgtable-arm + drm/msm: Extend iova fault debugging
by Rob Clark 14 Dec '21

14 Dec '21

From: Rob Clark <robdclark(a)chromium.org> This series extends io-pgtable-arm with a method to retrieve the page table entries traversed in the process of address translation, and then beefs up drm/msm gpu devcore dump to include this (and additional info) in the devcore dump. The motivation is tracking down an obscure iova fault triggered crash on the address of the IB1 cmdstream. This is one of the few places where the GPU address written into the cmdstream is soley under control of the kernel mode driver, so I don't think it can be a userspace bug. The logged cmdstream from the devcore's I've looked at look correct, and the TTBR0 read back from arm-smmu agrees with the kernel emitted cmdstream. Unfortunately it happens infrequently enough (something like once per 1000hrs of usage, from what I can tell from our telemetry) that actually reproducing it with an instrumented debug kernel is not an option. So further spiffying out the devcore dumps and hoping we can spot a clue is the plan I'm shooting for. See https://gitlab.freedesktop.org/drm/msm/-/issues/8 for more info on the issue I'm trying to debug. v2: Fix an armv7/32b build error in the last patch Rob Clark (3): iommu/io-pgtable-arm: Add way to debug pgtable walk drm/msm: Show all smmu info for iova fault devcore dumps drm/msm: Extend gpu devcore dumps with pgtbl info drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 35 +++++++++++++++++----- drivers/gpu/drm/msm/msm_gpu.c | 10 +++++++ drivers/gpu/drm/msm/msm_gpu.h | 10 ++++++- drivers/gpu/drm/msm/msm_iommu.c | 17 +++++++++++ drivers/gpu/drm/msm/msm_mmu.h | 2 ++ drivers/iommu/io-pgtable-arm.c | 40 ++++++++++++++++++++----- include/linux/io-pgtable.h | 9 ++++++ 8 files changed, 107 insertions(+), 18 deletions(-) -- 2.31.1

2 4

[PATCH v3 00/17] drm/i915/dg2: Enabling 64k page size and flat ccs
by Ramalingam C 14 Dec '21

14 Dec '21

This series introduces the enabling patches for new memory compression feature Flat CCS and 64k page support for i915 local memory, along with documentation on the uAPI impact. Included the details of the feature and the implications on the uAPI below. Which is also added into Documentation/gpu/rfc/i915_dg2.rst DG2 64K page size support: ========================= On discrete platforms, starting from DG2, we have to contend with GTT page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE objects. Specifically the hardware only supports 64K or larger GTT page sizes for such memory. The kernel will already ensure that all I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page sizes underneath. Note that the returned size here will always reflect any required rounding up done by the kernel, i.e 4K will now become 64K on devices such as DG2. Special DG2 GTT address alignment requirement: ============================================= The GTT alignment will also need be at least 64K for such objects. Note that due to how the hardware implements 64K GTT page support, we have some further complications: 1) The entire PDE(which covers a 2M virtual address range), must contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same PDE is forbidden by the hardware. 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM objects. To handle the above the kernel implements a memory coloring scheme to prevent userspace from mixing I915_MEMORY_CLASS_DEVICE and I915_MEMORY_CLASS_SYSTEM objects in the same PDE. If the kernel is ever unable to evict the required pages for the given PDE(different color) when inserting the object into the GTT then it will simply fail the request. Since userspace needs to manage the GTT address space themselves, special care is needed to ensure this doesn’t happen. The simplest scheme is to simply align and round up all I915_MEMORY_CLASS_DEVICE objects to 2M, which avoids any issues here. At the very least this is likely needed for objects that can be placed in both I915_MEMORY_CLASS_DEVICE and I915_MEMORY_CLASS_SYSTEM, to avoid potential issues when the kernel needs to migrate the object behind the scenes, since that might also involve evicting other objects. To summarise the GTT rules, on platforms like DG2: 1) All objects that can be placed in I915_MEMORY_CLASS_DEVICE must have 64K alignment. The kernel will reject this otherwise. 2) All I915_MEMORY_CLASS_DEVICE objects must never be placed in the same PDE with other I915_MEMORY_CLASS_SYSTEM objects. The kernel will reject this otherwise. 3) Objects that can be placed in both I915_MEMORY_CLASS_DEVICE and I915_MEMORY_CLASS_SYSTEM should probably be aligned and padded out to 2M. Flat CCS support for lmem ========================= On Xe-HP and later devices, we use dedicated compression control state (CCS) stored in local memory for each surface, to support the 3D and media compression formats. The memory required for the CCS of the entire local memory is 1/256 of the local memory size. So before the kernel boot, the required memory is reserved for the CCS data and a secure register will be programmed with the CCS base address. Flat CCS data needs to be cleared when a lmem object is allocated. And CCS data can be copied in and out of CCS region through XY_CTRL_SURF_COPY_BLT. CPU can’t access the CCS data directly. When we exaust the lmem, if the object’s placements support smem, then we can directly decompress the compressed lmem object into smem and start using it from smem itself. But when we need to swapout the compressed lmem object into a smem region though objects’ placement doesn’t support smem, then we copy the lmem content as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT). When the object is referred, lmem content will be swaped in along with restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding location. Flat-CCS Modifiers for different compression formats ==================================================== I915_FORMAT_MOD_F_TILED_DG2_RC_CCS - used to indicate the buffers of Flat CCS render compression formats. Though the general layout is same as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression algorithm is used. Render compression uses 128 byte compression blocks I915_FORMAT_MOD_F_TILED_DG2_MC_CCS -used to indicate the buffers of Flat CCS media compression formats. Though the general layout is same as I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm is used. Media compression uses 256 byte compression blocks. I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC - used to indicate the buffers of Flat CCS clear color render compression formats. Unified compression format for clear color render compression. The genral layout is a tiled layout using 4Kb tiles i.e Tile4 layout. v2: Fixed some formatting issues and platform naming issues Added some more documentation on Flat-CCS v3: Plane programming is handled for flat-ccs and clear color Tile4 and flat ccs modifier patches are rebased on table based modifier reference method Three patches are squashed Y tile is pruned for DG2. flat_ccs_cc plane format info is added Added mesa, compute and media ppl for required uAPI ack. Abdiel Janulgue (1): drm/i915/lmem: Enable lmem for platforms with Flat CCS Anshuman Gupta (1): drm/i915/dg2: Plane handling for Flat CCS and clear color Ayaz A Siddiqui (1): drm/i915/gt: Clear compress metadata for Xe_HP platforms CQ Tang (1): drm/i915/xehpsdv: Add has_flat_ccs to device info Matt Roper (1): uapi/drm/dg2: Format modifier for DG2 unified compression and clear color Matthew Auld (7): drm/i915/xehpsdv: set min page-size to 64K drm/i915/xehpsdv: enforce min GTT alignment drm/i915: enforce min page size for scratch drm/i915/gtt/xehpsdv: move scratch page to system memory drm/i915/xehpsdv: support 64K GTT pages drm/i915/xehpsdv: implement memory coloring drm/i915/uapi: document behaviour for DG2 64K support Ramalingam C (3): drm/i915/dg2: Prune the Y Tiling modifiers drm/i915/Flat-CCS: Document on Flat-CCS memory compression Doc/gpu/rfc/i915: i915 DG2 uAPI Stanislav Lisovskiy (1): drm/i915/dg2: Tile 4 plane format support Stuart Summers (1): drm/i915: Add has_64k_pages flag Documentation/gpu/rfc/i915_dg2.rst | 32 ++++ Documentation/gpu/rfc/index.rst | 3 + .../gpu/drm/i915/display/intel_atomic_plane.c | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 5 +- drivers/gpu/drm/i915/display/intel_fb.c | 87 +++++++-- drivers/gpu/drm/i915/display/intel_fb.h | 3 +- drivers/gpu/drm/i915/display/intel_fbc.c | 1 + .../drm/i915/display/intel_plane_initial.c | 1 + drivers/gpu/drm/i915/display/skl_scaler.c | 6 +- .../drm/i915/display/skl_universal_plane.c | 68 +++++-- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 61 +++++++ .../i915/gem/selftests/i915_gem_client_blt.c | 23 ++- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 + drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 145 ++++++++++++++- drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 14 ++ drivers/gpu/drm/i915/gt/intel_gt.c | 19 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 1 + drivers/gpu/drm/i915/gt/intel_gtt.c | 23 ++- drivers/gpu/drm/i915/gt/intel_gtt.h | 20 +++ drivers/gpu/drm/i915/gt/intel_migrate.c | 167 +++++++++++++++++- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 + drivers/gpu/drm/i915/gt/intel_region_lmem.c | 27 ++- drivers/gpu/drm/i915/i915_drv.h | 7 + drivers/gpu/drm/i915/i915_gem_evict.c | 17 ++ drivers/gpu/drm/i915/i915_pci.c | 4 + drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/i915_vma.c | 55 ++++-- drivers/gpu/drm/i915/intel_device_info.h | 3 + drivers/gpu/drm/i915/intel_pm.c | 10 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ++++++---- drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 + include/uapi/drm/drm_fourcc.h | 38 ++++ include/uapi/drm/i915_drm.h | 67 ++++++- 35 files changed, 909 insertions(+), 113 deletions(-) create mode 100644 Documentation/gpu/rfc/i915_dg2.rst -- 2.20.1

3 21

[PATCH] drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf
by AngeloGioacchino Del Regno 13 Dec '21

13 Dec '21

In commit 41ca9caaae0b ("drm/mediatek: hdmi: Add check for CEA modes only") a check for CEA modes was added to function mtk_hdmi_bridge_mode_valid() in order to address possible issues on MT8167; moreover, with commit c91026a938c2 ("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode clock") another similar check was introduced. Unfortunately though, at the time of writing, MT8173 does not provide any mtk_hdmi_conf structure and this is crashing the kernel with NULL pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as soon as a HDMI cable gets plugged in. To fix this regression, add a NULL pointer check for hdmi->conf in the said function, restoring HDMI functionality and avoiding NULL pointer kernel panics. Fixes: 41ca9caaae0b ("drm/mediatek: hdmi: Add check for CEA modes only") Fixes: c91026a938c2 ("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode clock") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c index 5838c44cbf6f..3196189429bc 100644 --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c @@ -1224,12 +1224,14 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge, return MODE_BAD; } - if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode)) - return MODE_BAD; + if (hdmi->conf) { + if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode)) + return MODE_BAD; - if (hdmi->conf->max_mode_clock && - mode->clock > hdmi->conf->max_mode_clock) - return MODE_CLOCK_HIGH; + if (hdmi->conf->max_mode_clock && + mode->clock > hdmi->conf->max_mode_clock) + return MODE_CLOCK_HIGH; + } if (mode->clock < 27000) return MODE_CLOCK_LOW; -- 2.33.0

2 2

[Bug 207763] New: Noisy Screen in Linux with kernel 5
by bugzilla-daemon＠bugzilla.kernel.org 12 Dec '21

12 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=207763 Bug ID: 207763 Summary: Noisy Screen in Linux with kernel 5 Product: Drivers Version: 2.5 Kernel Version: 5.0.0-23-generic Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: xunilarium(a)gmail.com Regression: No Created attachment 289165 --> https://bugzilla.kernel.org/attachment.cgi?id=289165&action=edit My Noisy Screen As linux kernel was updated to version 5 my laptop screen become noisy, I have same problem with all linux distros with kernel 5 and above. The problem is available both in graphic and text mode. windows works fine so my graphic card is OK. Ubunut 18.04.02: -------------------------------------------------------------------------------- Kernel Ver: 4.18.0-15-generic VGA Driver: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470] Subsystem: Sony Corporation RV620/M82 [Mobility Radeon HD 3450/3470] Kernel driver in use: radeon Kernel modules: radeon Screen Status: OK ________________________________________________________________________________ Ubuntu 18.04.03: -------------------------------------------------------------------------------- Kernel Ver: 5.0.0-23-generic VGA Driver: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470] Subsystem: Sony Corporation RV620/M82 [Mobility Radeon HD 3450/3470] Kernel driver in use: radeon Kernel modules: radeon Screen Status: Noisy -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

[PATCH] drm/msm/a5xx: Add support for Adreno 506 GPU
by Vladimir Lypak 12 Dec '21

12 Dec '21

This GPU is found on SoCs such as MSM8953(650MHz), SDM450(600MHz), SDM632(725MHz). Signed-off-by: Vladimir Lypak <vladimir.lypak(a)gmail.com> --- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34 ++++++++++++++-------- drivers/gpu/drm/msm/adreno/adreno_device.c | 18 ++++++++++++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 ++++ 3 files changed, 45 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c index 5e2750eb3810..249a0d8bc673 100644 --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c @@ -441,7 +441,7 @@ void a5xx_set_hwcg(struct msm_gpu *gpu, bool state) const struct adreno_five_hwcg_regs *regs; unsigned int i, sz; - if (adreno_is_a508(adreno_gpu)) { + if (adreno_is_a506(adreno_gpu) || adreno_is_a508(adreno_gpu)) { regs = a50x_hwcg; sz = ARRAY_SIZE(a50x_hwcg); } else if (adreno_is_a509(adreno_gpu) || adreno_is_a512(adreno_gpu)) { @@ -485,7 +485,7 @@ static int a5xx_me_init(struct msm_gpu *gpu) OUT_RING(ring, 0x00000000); /* Specify workarounds for various microcode issues */ - if (adreno_is_a530(adreno_gpu)) { + if (adreno_is_a506(adreno_gpu) || adreno_is_a530(adreno_gpu)) { /* Workaround for token end syncs * Force a WFI after every direct-render 3D mode draw and every * 2D mode 3 draw @@ -620,8 +620,17 @@ static int a5xx_ucode_init(struct msm_gpu *gpu) static int a5xx_zap_shader_resume(struct msm_gpu *gpu) { + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu); int ret; + /* + * Adreno 506,508,512 have CPZ Retention feature and + * don't need to resume zap shader + */ + if (adreno_is_a506(adreno_gpu) || adreno_is_a508(adreno_gpu) || + adreno_is_a512(adreno_gpu)) + return 0; + ret = qcom_scm_set_remote_state(SCM_GPU_ZAP_SHADER_RESUME, GPU_PAS_ID); if (ret) DRM_ERROR("%s: zap-shader resume failed: %d\n", @@ -733,9 +742,10 @@ static int a5xx_hw_init(struct msm_gpu *gpu) 0x00100000 + adreno_gpu->gmem - 1); gpu_write(gpu, REG_A5XX_UCHE_GMEM_RANGE_MAX_HI, 0x00000000); - if (adreno_is_a508(adreno_gpu) || adreno_is_a510(adreno_gpu)) { + if (adreno_is_a506(adreno_gpu) || adreno_is_a508(adreno_gpu) || + adreno_is_a510(adreno_gpu)) { gpu_write(gpu, REG_A5XX_CP_MEQ_THRESHOLDS, 0x20); - if (adreno_is_a508(adreno_gpu)) + if (adreno_is_a506(adreno_gpu) || adreno_is_a508(adreno_gpu)) gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x400); else gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x20); @@ -751,7 +761,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu) gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_1, 0x40201B16); } - if (adreno_is_a508(adreno_gpu)) + if (adreno_is_a506(adreno_gpu) || adreno_is_a508(adreno_gpu)) gpu_write(gpu, REG_A5XX_PC_DBG_ECO_CNTL, (0x100 << 11 | 0x100 << 22)); else if (adreno_is_a509(adreno_gpu) || adreno_is_a510(adreno_gpu) || @@ -769,8 +779,8 @@ static int a5xx_hw_init(struct msm_gpu *gpu) * Disable the RB sampler datapath DP2 clock gating optimization * for 1-SP GPUs, as it is enabled by default. */ - if (adreno_is_a508(adreno_gpu) || adreno_is_a509(adreno_gpu) || - adreno_is_a512(adreno_gpu)) + if (adreno_is_a506(adreno_gpu) || adreno_is_a508(adreno_gpu) || + adreno_is_a509(adreno_gpu) || adreno_is_a512(adreno_gpu)) gpu_rmw(gpu, REG_A5XX_RB_DBG_ECO_CNTL, 0, (1 << 9)); /* Disable UCHE global filter as SP can invalidate/flush independently */ @@ -895,8 +905,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu) if (ret) return ret; - if (!(adreno_is_a508(adreno_gpu) || adreno_is_a509(adreno_gpu) || - adreno_is_a510(adreno_gpu) || adreno_is_a512(adreno_gpu))) + if (adreno_is_a530(adreno_gpu) || adreno_is_a540(adreno_gpu)) a5xx_gpmu_ucode_init(gpu); ret = a5xx_ucode_init(gpu); @@ -1338,7 +1347,7 @@ static int a5xx_pm_resume(struct msm_gpu *gpu) if (ret) return ret; - /* Adreno 508, 509, 510, 512 needs manual RBBM sus/res control */ + /* Adreno 506, 508, 509, 510, 512 needs manual RBBM sus/res control */ if (!(adreno_is_a530(adreno_gpu) || adreno_is_a540(adreno_gpu))) { /* Halt the sp_input_clk at HM level */ gpu_write(gpu, REG_A5XX_RBBM_CLOCK_CNTL, 0x00000055); @@ -1381,8 +1390,9 @@ static int a5xx_pm_suspend(struct msm_gpu *gpu) u32 mask = 0xf; int i, ret; - /* A508, A510 have 3 XIN ports in VBIF */ - if (adreno_is_a508(adreno_gpu) || adreno_is_a510(adreno_gpu)) + /* A506, A508, A510 have 3 XIN ports in VBIF */ + if (adreno_is_a506(adreno_gpu) || adreno_is_a508(adreno_gpu) || + adreno_is_a510(adreno_gpu)) mask = 0x7; /* Clear the VBIF pipe before shutting down */ diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index 2a6ce76656aa..eb4b8527153b 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_device.c +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c @@ -131,6 +131,24 @@ static const struct adreno_info gpulist[] = { .gmem = (SZ_1M + SZ_512K), .inactive_period = DRM_MSM_INACTIVE_PERIOD, .init = a4xx_gpu_init, + }, { + .rev = ADRENO_REV(5, 0, 6, ANY_ID), + .revn = 506, + .name = "A506", + .fw = { + [ADRENO_FW_PM4] = "a530_pm4.fw", + [ADRENO_FW_PFP] = "a530_pfp.fw", + }, + .gmem = (SZ_128K + SZ_8K), + /* + * Increase inactive period to 250 to avoid bouncing + * the GDSC which appears to make it grumpy + */ + .inactive_period = 250, + .quirks = ADRENO_QUIRK_TWO_PASS_USE_WFI | + ADRENO_QUIRK_LMLOADKILL_DISABLE, + .init = a5xx_gpu_init, + .zapfw = "a506_zap.mdt", }, { .rev = ADRENO_REV(5, 0, 8, ANY_ID), .revn = 508, diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h b/drivers/gpu/drm/msm/adreno/adreno_gpu.h index 225c277a6223..427a96d81280 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h @@ -201,6 +201,11 @@ static inline int adreno_is_a430(struct adreno_gpu *gpu) return gpu->revn == 430; } +static inline int adreno_is_a506(struct adreno_gpu *gpu) +{ + return gpu->revn == 506; +} + static inline int adreno_is_a508(struct adreno_gpu *gpu) { return gpu->revn == 508; -- 2.33.0

3 4

← Newer
1
...
5
6
7
8
9
10
11
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021