dri-devel May 2022

dri-devel@lists.freedesktop.org

344 participants
736 discussions

[Bug 213145] New: AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!"
by bugzilla-daemon＠bugzilla.kernel.org 13 Jun '22

13 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=213145 Bug ID: 213145 Summary: AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!" Product: Drivers Version: 2.5 Kernel Version: 5.10.37 and 5.10.38 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: tgayoso(a)gmail.com Regression: No Created attachment 296867 --> https://bugzilla.kernel.org/attachment.cgi?id=296867&action=edit lspci output AMDGPU driver crashes randomly corrupting screen and freezing X with: [ 60.449781] [drm:0xffffffffc25a7a57] *ERROR* Waiting for fences timed out! [ 60.971941] [drm:0xffffffffc25281ae] *ERROR* ring gfx timeout, signaled seq=3658, emitted seq=3660 [ 60.971946] [drm:0xffffffffc25281cb] *ERROR* Process information: process Xorg pid 1192 thread Xorg:cs0 pid 1193 [ 60.971952] amdgpu 0000:05:00.0: amdgpu: GPU reset begin! ... (some output suppressed for clarity, look at attached dmesg, please). [ 61.800343] amdgpu 0000:05:00.0: amdgpu: recover vram bo from shadow start [ 61.800346] amdgpu 0000:05:00.0: amdgpu: recover vram bo from shadow done [ 61.800348] [drm] Skip scheduling IBs! [ 61.800350] [drm] Skip scheduling IBs! [ 61.800382] [drm] Skip scheduling IBs! [ 61.800398] amdgpu 0000:05:00.0: amdgpu: GPU reset(2) succeeded! [ 61.800566] [drm] Skip scheduling IBs! [ 61.800580] [drm] Skip scheduling IBs! [ 61.800627] [drm] Skip scheduling IBs! [ 61.801012] [drm] Skip scheduling IBs! [ 61.801024] [drm] Skip scheduling IBs! [ 61.801052] [drm] Skip scheduling IBs! [ 61.801062] [drm] Skip scheduling IBs! [ 61.801096] [drm] Skip scheduling IBs! [ 61.801105] [drm] Skip scheduling IBs! [ 61.801137] [drm] Skip scheduling IBs! [ 61.801806] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.808746] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.809392] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.809764] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.810389] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.810866] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.812529] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.813359] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.814770] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.816488] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 62.541982] ucsi_acpi USBC000:00: PPM init failed (-110) [ 67.004898] amdgpu_cs_ioctl: 1467 callbacks suppressed Hardware: ASUS TUF506IU laptop (dual GPU Renoir and Nvidia GeForce GTX 1660 Ti Mobile) Detailed hardware in lspci.txt. Detailed modules in lsmod.txt. Kernle config attached in Kernel_config. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 20

[PATCH v10 00/21] drm/mediatek: Add mt8195 DisplayPort driver
by Guillaume Ranquet 13 Jun '22

13 Jun '22

this series is built around the DisplayPort driver. The dpi/dpintf driver and the added helper functions are required for the DisplayPort driver to work. This v10 still has some un-answered comments and TODOs for v11. This has been tested sucessfully on a 5.18-next based "vendor branch". There's a missing dependency in the mediatek clock framework to allow a mux clock to change it's parent automatically on rate change. Without this change, the dpi driver won't properly set the clocks on mode change and thus nothing will be displayed on screen. Changes from v9: - The DP-Phy is back to being a child device of the DP driver (as in v8) - hot plug detection has been added back to Embedded Display Port... as after discussing with mediatek experts, this is needed eventhough the Embedded Display port is not un-pluggable - rebased on linux-next - simplified/split train_handler function, as suggested by Rex - added comments on the sleep/delays present in the code - removed previous patch introducing retries when receiving AUX_DEFER as this is already handled in the dp_aux framework - added max-lane and max-linkrate device tree u8 properties instead of hardcoded #defines Things that are in my todolist for v11: - retrieve CK/DE support from panel driver instead of hardcoding it into the dpi driver - refcount the dp driver "enabled" status for "future proofing" - review the drm_dp_helpers for features/functions that have been re-implemented in the mediatek dp drivers Older revisions: RFC - https://lore.kernel.org/linux-mediatek/20210816192523.1739365-1-msp@baylibr… v1 - https://lore.kernel.org/linux-mediatek/20210906193529.718845-1-msp@baylibre… v2 - https://lore.kernel.org/linux-mediatek/20210920084424.231825-1-msp@baylibre… v3 - https://lore.kernel.org/linux-mediatek/20211001094443.2770169-1-msp@baylibr… v4 - https://lore.kernel.org/linux-mediatek/20211011094624.3416029-1-msp@baylibr… v5 - https://lore.kernel.org/all/20211021092707.3562523-1-msp@baylibre.com/ v6 - https://lore.kernel.org/linux-mediatek/20211110130623.20553-1-granquet@bayl… v7 - https://lore.kernel.org/linux-mediatek/20211217150854.2081-1-granquet@bayli… v8 - https://lore.kernel.org/linux-mediatek/20220218145437.18563-1-granquet@bayl… v9 - https://lore.kernel.org/all/20220327223927.20848-1-granquet@baylibre.com/ Functional dependencies are: - Add Mediatek Soc DRM (vdosys0) support for mt8195 https://lore.kernel.org/linux-mediatek/20220419094143.9561-2-jason-jh.lin@m… - Add MediaTek SoC DRM (vdosys1) support for mt8195 https://lore.kernel.org/linux-mediatek/20220512053128.31415-1-nancy.lin@med… Guillaume Ranquet (15): drm/edid: Convert cea_sad helper struct to kernelDoc drm/edid: Add cea_sad helpers for freq/length drm/mediatek: dpi: move dpi limits to SoC config drm/mediatek: dpi: implement a CK/DE pol toggle in SoC config drm/mediatek: dpi: implement a swap_input toggle in SoC config drm/mediatek: dpi: move dimension mask to SoC config drm/mediatek: dpi: move hvsize_mask to SoC config drm/mediatek: dpi: move swap_shift to SoC config drm/mediatek: dpi: move the yuv422_en_bit to SoC config drm/mediatek: dpi: move the csc_enable bit to SoC config drm/mediatek: dpi: Add dpintf support drm/mediatek: dpi: Only enable dpi after the bridge is enabled drm/meditek: dpi: Add matrix_sel helper drm/mediatek: Add mt8195 External DisplayPort support drm/mediatek: DP audio support for mt8195 Jitao Shi (1): drm/mediatek: add hpd debounce Markus Schneider-Pargmann (5): dt-bindings: mediatek,dpi: Add DPINTF compatible dt-bindings: mediatek,dp: Add Display Port binding video/hdmi: Add audio_infoframe packing for DP phy: phy-mtk-dp: Add driver for DP phy drm/mediatek: Add mt8195 Embedded DisplayPort driver .../display/mediatek/mediatek,dp.yaml | 99 + .../display/mediatek/mediatek,dpi.yaml | 13 +- MAINTAINERS | 1 + drivers/gpu/drm/drm_edid.c | 74 + drivers/gpu/drm/mediatek/Kconfig | 8 + drivers/gpu/drm/mediatek/Makefile | 2 + drivers/gpu/drm/mediatek/mtk_dp.c | 3419 +++++++++++++++++ drivers/gpu/drm/mediatek/mtk_dp_reg.h | 570 +++ drivers/gpu/drm/mediatek/mtk_dpi.c | 272 +- drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 38 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 + drivers/phy/mediatek/Kconfig | 8 + drivers/phy/mediatek/Makefile | 1 + drivers/phy/mediatek/phy-mtk-dp.c | 200 + drivers/video/hdmi.c | 82 +- include/drm/dp/drm_dp_helper.h | 2 + include/drm/drm_edid.h | 26 +- include/linux/hdmi.h | 7 +- include/linux/soc/mediatek/mtk-mmsys.h | 4 +- 22 files changed, 4765 insertions(+), 81 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h create mode 100644 drivers/phy/mediatek/phy-mtk-dp.c -- 2.35.1

10 89

[LINUX PATCH 0/2] Add Xilinx DSI-Tx DRM driver
by Venkateshwar Rao Gannavarapu 13 Jun '22

13 Jun '22

MIPI DSI TX subsystem allows you to quickly create systems based on the MIPI protocol. It interfaces between the video processing subsystems and MIPI-based displays. An internal high-speed physical layer design, D-PHY, is provided to allow direct connection to display peripherals. The subsystem consists of the following sub-blocks: - MIPI D-PHY - MIPI DSI TX Controller - AXI Crossbar Please refer pg238 [1]. The DSI TX Controller receives stream of image data through an input stream interface. At design time, this subsystem can be configured to number of lanes and pixel format. This patch series adds the dt-binding and DRM driver for Xilinx DSI-Tx soft IP. References: [1]: https://www.xilinx.com/support/documentation/ip_documentation/mipi_dsi_tx_s… Venkateshwar Rao Gannavarapu (2): dt-bindings: display: xlnx: Add DSI 2.0 Tx subsystem documentation drm: xlnx: dsi: driver for Xilinx DSI Tx subsystem .../bindings/display/xlnx/xlnx,dsi-tx.yaml | 105 +++++ drivers/gpu/drm/xlnx/Kconfig | 14 + drivers/gpu/drm/xlnx/Makefile | 1 + drivers/gpu/drm/xlnx/xlnx_dsi.c | 456 +++++++++++++++++++++ 4 files changed, 576 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/xlnx/xlnx,dsi-tx.yaml create mode 100644 drivers/gpu/drm/xlnx/xlnx_dsi.c -- 1.8.3.1

3 8

[PATCH v2 01/11] drm: of: Add drm_of_get_data_lanes_count and drm_of_get_data_lanes_ep
by Marek Vasut 12 Jun '22

12 Jun '22

Add helper function to count and sanitize DT "data-lanes" property and return either error or the data-lanes count. This is useful for both DSI and (e)DP "data-lanes" property. The later version of the function is an extra wrapper which handles the endpoint look up by regs, that's what majority of the drivers duplicate too, but not all of them. Reviewed-by: Andrzej Hajda <andrzej.hajda(a)intel.com> Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Andrzej Hajda <andrzej.hajda(a)intel.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Maxime Ripard <maxime(a)cerno.tech> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> To: dri-devel(a)lists.freedesktop.org --- V2: - Rename drm_of_get_data_lanes{,_ep} to drm_of_get_data_lanes_count{,_ep} - Add RB from Andrzej --- drivers/gpu/drm/drm_of.c | 61 ++++++++++++++++++++++++++++++++++++++++ include/drm/drm_of.h | 20 +++++++++++++ 2 files changed, 81 insertions(+) diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c index 9a2cfab3a177f..2c1ee601f1d83 100644 --- a/drivers/gpu/drm/drm_of.c +++ b/drivers/gpu/drm/drm_of.c @@ -430,3 +430,64 @@ int drm_of_lvds_get_data_mapping(const struct device_node *port) return -EINVAL; } EXPORT_SYMBOL_GPL(drm_of_lvds_get_data_mapping); + +/** + * drm_of_get_data_lanes_count - Get DSI/(e)DP data lane count + * @endpoint: DT endpoint node of the DSI/(e)DP source or sink + * @min: minimum supported number of data lanes + * @max: maximum supported number of data lanes + * + * Count DT "data-lanes" property elements and check for validity. + * + * Return: + * * min..max - positive integer count of "data-lanes" elements + * * -ve - the "data-lanes" property is missing or invalid + * * -EINVAL - the "data-lanes" property is unsupported + */ +int drm_of_get_data_lanes_count(const struct device_node *endpoint, + const unsigned int min, const unsigned int max) +{ + int ret; + + ret = of_property_count_u32_elems(endpoint, "data-lanes"); + if (ret < 0) + return ret; + + if (ret < min || ret > max) + return -EINVAL; + + return ret; +} +EXPORT_SYMBOL_GPL(drm_of_get_data_lanes_count); + +/** + * drm_of_get_data_lanes_count_ep - Get DSI/(e)DP data lane count by endpoint + * @port: DT port node of the DSI/(e)DP source or sink + * @port_reg: identifier (value of reg property) of the parent port node + * @reg: identifier (value of reg property) of the endpoint node + * @min: minimum supported number of data lanes + * @max: maximum supported number of data lanes + * + * Count DT "data-lanes" property elements and check for validity. + * This variant uses endpoint specifier. + * + * Return: + * * min..max - positive integer count of "data-lanes" elements + * * -EINVAL - the "data-mapping" property is unsupported + * * -ENODEV - the "data-mapping" property is missing + */ +int drm_of_get_data_lanes_count_ep(const struct device_node *port, + int port_reg, int reg, + const unsigned int min, + const unsigned int max) +{ + struct device_node *endpoint; + int ret; + + endpoint = of_graph_get_endpoint_by_regs(port, port_reg, reg); + ret = drm_of_get_data_lanes_count(endpoint, min, max); + of_node_put(endpoint); + + return ret; +} +EXPORT_SYMBOL_GPL(drm_of_get_data_lanes_count_ep); diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h index 99f79ac8b4cd7..92387eabcb6f0 100644 --- a/include/drm/drm_of.h +++ b/include/drm/drm_of.h @@ -50,6 +50,12 @@ int drm_of_find_panel_or_bridge(const struct device_node *np, int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1, const struct device_node *port2); int drm_of_lvds_get_data_mapping(const struct device_node *port); +int drm_of_get_data_lanes_count(const struct device_node *endpoint, + const unsigned int min, const unsigned int max); +int drm_of_get_data_lanes_count_ep(const struct device_node *port, + int port_reg, int reg, + const unsigned int min, + const unsigned int max); #else static inline uint32_t drm_of_crtc_port_mask(struct drm_device *dev, struct device_node *port) @@ -105,6 +111,20 @@ drm_of_lvds_get_data_mapping(const struct device_node *port) { return -EINVAL; } + +int drm_of_get_data_lanes_count(const struct device_node *endpoint, + const unsigned int min, const unsigned int max) +{ + return -EINVAL; +} + +int drm_of_get_data_lanes_count_ep(const struct device_node *port, + int port_reg, int reg + const unsigned int min, + const unsigned int max) +{ + return -EINVAL; +} #endif /* -- 2.35.1

2 12

[PATCH v2] drm/msm/adreno: Allow larger address space size
by Rob Clark 12 Jun '22

12 Jun '22

From: Rob Clark <robdclark(a)chromium.org> The restriction to 4G was strictly to work around 64b math bug in some versions of SQE firmware. This appears to be fixed in a650+ SQE fw, so allow a larger address space size on these devices. Also, add a modparam override for debugging and igt. v2: Send the right version of the patch (ie. the one that actually compiles) Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 ++- drivers/gpu/drm/msm/adreno/adreno_device.c | 3 +++ drivers/gpu/drm/msm/adreno/adreno_gpu.c | 17 +++++++++++++++++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 ++ 4 files changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 42ed9a3c4905..24932b2945ae 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -1737,7 +1737,8 @@ a6xx_create_private_address_space(struct msm_gpu *gpu) return ERR_CAST(mmu); return msm_gem_address_space_create(mmu, - "gpu", 0x100000000ULL, SZ_4G); + "gpu", 0x100000000ULL, + adreno_private_address_space_size(gpu)); } static uint32_t a6xx_get_rptr(struct msm_gpu *gpu, struct msm_ringbuffer *ring) diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index 89cfd84760d7..f3685130ce9b 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_device.c +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c @@ -303,6 +303,7 @@ static const struct adreno_info gpulist[] = { .init = a6xx_gpu_init, .zapfw = "a650_zap.mdt", .hwcg = a650_hwcg, + .address_space_size = SZ_16G, }, { .rev = ADRENO_REV(6, 6, 0, ANY_ID), .revn = 660, @@ -316,6 +317,7 @@ static const struct adreno_info gpulist[] = { .init = a6xx_gpu_init, .zapfw = "a660_zap.mdt", .hwcg = a660_hwcg, + .address_space_size = SZ_16G, }, { .rev = ADRENO_REV(6, 3, 5, ANY_ID), .fw = { @@ -326,6 +328,7 @@ static const struct adreno_info gpulist[] = { .inactive_period = DRM_MSM_INACTIVE_PERIOD, .init = a6xx_gpu_init, .hwcg = a660_hwcg, + .address_space_size = SZ_16G, }, { .rev = ADRENO_REV(6, 8, 0, ANY_ID), .revn = 680, diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c index 4e665c806a14..7b5f30881eee 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c @@ -21,6 +21,10 @@ #include "msm_gem.h" #include "msm_mmu.h" +static u64 address_space_size = 0; +MODULE_PARM_DESC(address_space_size, "Override for size of processes private GPU address space"); +module_param(address_space_size, ullong, 0600); + static bool zap_available = true; static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname, @@ -228,6 +232,19 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu, return aspace; } +u64 adreno_private_address_space_size(struct msm_gpu *gpu) +{ + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu); + + if (address_space_size) + return address_space_size; + + if (adreno_gpu->info->address_space_size) + return adreno_gpu->info->address_space_size; + + return SZ_4G; +} + int adreno_get_param(struct msm_gpu *gpu, struct msm_file_private *ctx, uint32_t param, uint64_t *value, uint32_t *len) { diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h b/drivers/gpu/drm/msm/adreno/adreno_gpu.h index ab3b5ef80332..0a4d45695dc7 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h @@ -70,6 +70,7 @@ struct adreno_info { const char *zapfw; u32 inactive_period; const struct adreno_reglist *hwcg; + u64 address_space_size; }; const struct adreno_info *adreno_info(struct adreno_rev rev); @@ -280,6 +281,7 @@ static inline int adreno_is_a650_family(struct adreno_gpu *gpu) adreno_is_a660_family(gpu); } +u64 adreno_private_address_space_size(struct msm_gpu *gpu); int adreno_get_param(struct msm_gpu *gpu, struct msm_file_private *ctx, uint32_t param, uint64_t *value, uint32_t *len); int adreno_set_param(struct msm_gpu *gpu, struct msm_file_private *ctx, -- 2.35.3

2 1

[Bug 210301] New: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u
by bugzilla-daemon＠bugzilla.kernel.org 11 Jun '22

11 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=210301 Bug ID: 210301 Summary: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u Product: Drivers Version: 2.5 Kernel Version: 5.9.8 Hardware: Intel 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: ar_registration(a)mailbox.org Regression: No Boting in a new Thinkpad T14 AMD (4750u), I get *sometimes* the following errors: 2020-11-21T16:45:15.53245 kern.err: [ 5.934142] amdgpu 0000:07:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx (-110). 2020-11-21T16:45:15.53247 kern.err: [ 5.935598] [drm:process_one_work] *ERROR* ib ring test failed (-110). When this happens (typically 9/10 times) the machine eventually hangs. Sometimes with a page fault, sometimes with a general protection fault, but *always* in what appears to be the zfs calls. When the machine boots without the "*ERROR* IB test failed on gfx ", the machines *never* produces segmentation faults/general protection faults, even under very heavy i/o load. I have reproduced this problem: - In kernels 5.8.18, 5.9.6, 5.9.7, 5.9.8 - With two different SSD - With the firmware versions 20201118, 20201022, 20200918 - I have updated te BIOS two times (versions 1.09, 1.25, 1.27) I boot with the kernel command line options amd_iommu=on iommu=soft in order to avoid *another* error (AMD-Vi: Unable to read/write to IOMMU perf counter.) For example: 2020-10-24T22:00:29.88940 kern.warn: [ 1021.160344] general protection fault, probably for non-canonical address 0x3ff800040000000: 0000 [#1] SMP NOPTI 2020-10-24T22:00:29.89005 kern.warn: [ 1021.160348] CPU: 10 PID: 12746 Comm: bonnie++ Tainted: P O 5.8.16_1 #1 2020-10-24T22:00:29.89014 kern.warn: [ 1021.160349] Hardware name: LENOVO 20UDCTO1WW/20UDCTO1WW, BIOS R1BET40W(1.09 ) 08/07/2020 2020-10-24T22:00:29.89005 kern.warn: [ 1021.160348] CPU: 10 PID: 12746 Comm: bonnie++ Tainted: P O 5.8.16_1 #1 2020-10-24T22:00:29.89014 kern.warn: [ 1021.160349] Hardware name: LENOVO 20UDCTO1WW/20UDCTO1WW, BIOS R1BET40W(1.09 ) 08/07/2020 2020-10-24T22:00:29.89021 kern.warn: [ 1021.160385] RIP: 0010:dbuf_find+0x86/0x190 [zfs] 2020-10-24T22:00:29.89030 kern.warn: [ 1021.160387] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89033 kern.warn: [ 1021.160387] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89030 kern.warn: [ 1021.160387] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89033 kern.warn: [ 1021.160387] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89041 kern.warn: [ 1021.160389] RAX: 03ff800040000000 RBX: 00000000000587ce RCX: 0000000000001fd4 2020-10-24T22:00:29.89044 kern.warn: [ 1021.160389] RDX: ffff98bc4b6dbe00 RSI: 00000000000587ce RDI: ffffffffc11be4d0 2020-10-24T22:00:29.89046 kern.warn: [ 1021.160390] RBP: ffff98bc9cfa3000 R08: 99de27c9bb992351 R09: 9ae16a3b2f90404f 2020-10-24T22:00:29.89049 kern.warn: [ 1021.160391] R10: 0000000000000000 R11: ffff98bcca928000 R12: 0000000000030fc0 2020-10-24T22:00:29.89061 kern.warn: [ 1021.160391] R13: 0000000000000000 R14: ffff98bc4b6dbe00 R15: ffffffffc11be4d0 2020-10-24T22:00:29.89065 kern.warn: [ 1021.160392] FS: 00007f739cf48740(0000) GS:ffff98bccf080000(0000) knlGS:0000000000000000 2020-10-24T22:00:29.89070 kern.warn: [ 1021.160393] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2020-10-24T22:00:29.89077 kern.warn: [ 1021.160393] CR2: 00007f790e77d280 CR3: 0000000757346000 CR4: 0000000000340ee0 2020-10-24T22:00:29.89081 kern.warn: [ 1021.160394] Call Trace: 2020-10-24T22:00:29.89084 kern.warn: [ 1021.160400] ? _cond_resched+0x15/0x30 2020-10-24T22:00:29.89088 kern.warn: [ 1021.160410] dbuf_hold_impl_arg+0x41/0x610 [zfs] 2020-10-24T22:00:29.89091 kern.warn: [ 1021.160413] ? spl_kmem_alloc+0xbf/0x100 [spl] 2020-10-24T22:00:29.89095 kern.warn: [ 1021.160424] dbuf_hold_impl+0x94/0xc0 [zfs] 2020-10-24T22:00:29.89098 kern.warn: [ 1021.160434] dbuf_hold_level+0x2b/0x60 [zfs] 2020-10-24T22:00:29.89102 kern.warn: [ 1021.160446] dmu_tx_check_ioerr+0x35/0xd0 [zfs] 2020-10-24T22:00:29.89105 kern.warn: [ 1021.160457] dmu_tx_count_write+0xe5/0x1a0 [zfs] 2020-10-24T22:00:29.89109 kern.warn: [ 1021.160468] dmu_tx_hold_write_by_dnode+0x35/0x50 [zfs] 2020-10-24T22:00:29.89112 kern.warn: [ 1021.160481] zfs_write+0x410/0xe00 [zfs] 2020-10-24T22:00:29.89116 kern.warn: [ 1021.160485] ? enqueue_entity+0xf1/0x580 2020-10-24T22:00:29.89121 kern.warn: [ 1021.160497] zpl_write_common_iovec+0xaf/0x100 [zfs] 2020-10-24T22:00:29.89126 kern.warn: [ 1021.160509] zpl_iter_write+0xed/0x120 [zfs] 2020-10-24T22:00:29.89129 kern.warn: [ 1021.160511] new_sync_write+0x11b/0x1b0 2020-10-24T22:00:29.89133 kern.warn: [ 1021.160513] vfs_write+0x1c3/0x1f0 2020-10-24T22:00:29.89136 kern.warn: [ 1021.160515] ksys_write+0x5f/0xe0 2020-10-24T22:00:29.89140 kern.warn: [ 1021.160516] do_syscall_64+0x44/0x70 2020-10-24T22:00:29.89145 kern.warn: [ 1021.160518] entry_SYSCALL_64_after_hwframe+0x44/0xa9 2020-10-24T22:00:29.89150 kern.warn: [ 1021.160519] RIP: 0033:0x7f739d4f7de3 2020-10-24T22:00:29.89155 kern.warn: [ 1021.160521] Code: 75 05 48 83 c4 58 c3 e8 9b 43 ff ff 66 2e 0f 1f 84 00 00 00 00 00 90 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 2020-10-24T22:00:29.89160 kern.warn: [ 1021.160521] RSP: 002b:00007ffee6a2caa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 2020-10-24T22:00:29.89165 kern.warn: [ 1021.160522] RAX: ffffffffffffffda RBX: 00007ffee6a2caf0 RCX: 00007f739d4f7de3 2020-10-24T22:00:29.89177 kern.warn: [ 1021.160523] RDX: 0000000000002000 RSI: 00005623e29fd000 RDI: 0000000000000003 2020-10-24T22:00:29.89188 kern.warn: [ 1021.160523] RBP: 0000000000001d41 R08: 0000000000000000 R09: 0036343732312e00 2020-10-24T22:00:29.89202 kern.warn: [ 1021.160524] R10: 0000000000000180 R11: 0000000000000246 R12: 000000000001fd40 2020-10-24T22:00:29.89207 kern.warn: [ 1021.160524] R13: 00007ffee6a2caf0 R14: 00007ffee6a2cad0 R15: 00005623e29fd000 2020-10-24T22:00:29.89212 2020-10-24T22:00:29.89212 2020-10-24T22:00:29.89212 kern.warn: [ 1021.160525] Modules linked in: ctr ccm acpi_call(O) 8021q garp mrp stp llc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev btusb mc btrtl btbcm btintel joydev snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn snd_soc_core snd_compress snd_pcm_dmaengine ac97_bus tps6598x typec roles edac_mce_amd kvm_amd iwlmvm kvm mac80211 irqbypass crct10dif_pclmul ghash_clmulni_intel snd_hda_codec_realtek aesni_intel libarc4 snd_hda_codec_generic snd_hda_codec_hdmi crypto_simd cryptd snd_hda_intel glue_helper snd_intel_dspcfg rapl iwlwifi snd_hda_codec psmouse input_leds pcspkr wmi_bmof snd_hda_core snd_hwdep ipmi_devintf cfg80211 r8169 snd_rn_pci_acp3x sp5100_tco tpm_crb snd_pcm snd_pci_acp3x ccp ipmi_msghandler realtek k10temp i2c_piix4 thinkpad_acpi i2c_multi_instantiate ledtrig_audio ac tpm_tis tpm_tis_core evdev mac_hid tpm i2c_scmi rng_core acpi_cpufreq i2c_designware_platform tiny_power_button i2c_designware_core snd_seq snd_seq_device snd_timer snd soundcore kern.warn: [ 1021.160525] Modules linked in: ctr ccm acpi_call(O) 8021q garp mrp stp llc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev btusb mc btrtl btbcm btintel joydev snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn snd_soc_core snd_compress snd_pcm_dmaengine ac97_bus tps6598x typec roles edac_mce_amd kvm_amd iwlmvm kvm mac80211 irqbypass crct10dif_pclmul ghash_clmulni_intel snd_hda_codec_realtek aesni_intel libarc4 snd_hda_codec_generic snd_hda_codec_hdmi crypto_simd cryptd snd_hda_intel glue_helper snd_intel_dspcfg rapl iwlwifi snd_hda_codec psmouse input_leds pcspkr wmi_bmof snd_hda_core snd_hwdep ipmi_devintf cfg80211 r8169 snd_rn_pci_acp3x sp5100_tco tpm_crb snd_pcm snd_pci_acp3x ccp ipmi_msghandler realtek k10temp i2c_piix4 thinkpad_acpi i2c_multi_instantiate ledtrig_audio ac tpm_tis tpm_tis_core evdev mac_hid tpm i2c_scmi rng_core acpi_cpufreq i2c_designware_platform tiny_power_button i2c_designware_core snd_seq snd_seq_device snd_timer snd soundcore 2020-10-24T22:00:29.89238 kern.warn: [ 1021.160552] vhost_vsock vmw_vsock_virtio_transport_common vsock vhost_net vhost tap vhost_iotlb uhid hid hci_vhci bluetooth ecdh_generic rfkill ecc crc16 vfio_iommu_type1 vfio dm_mod uinput userio ppp_generic slhc tun loop nvram btrfs blake2b_generic xor raid6_pq libcrc32c crc32c_generic cuse fuse zfs(PO) zunicode(PO) zlua(PO) zavl(PO) icp(PO) amdgpu iommu_v2 gpu_sched i2c_algo_bit ttm rtsx_pci_sdmmc mmc_core drm_kms_helper syscopyarea sysfillrect zcommon(PO) sysimgblt fb_sys_fops cec znvpair(PO) rc_core xhci_pci xhci_pci_renesas spl(O) xhci_hcd ehci_pci crc32_pclmul drm crc32c_intel ehci_hcd serio_raw usbcore agpgart rtsx_pci wmi button battery video 2020-10-24T22:00:29.89243 kern.warn: [ 1021.160577] ---[ end trace 17b0063aeadb5c32 ]--- 2020-10-24T22:00:29.89248 kern.warn: [ 1021.160589] RIP: 0010:dbuf_find+0x86/0x190 [zfs] 2020-10-24T22:00:29.89253 kern.warn: [ 1021.160589] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89267 kern.warn: [ 1021.160590] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89271 kern.warn: [ 1021.160591] RAX: 03ff800040000000 RBX: 00000000000587ce RCX: 0000000000001fd4 2020-10-24T22:00:29.89276 kern.warn: [ 1021.160591] RDX: ffff98bc4b6dbe00 RSI: 00000000000587ce RDI: ffffffffc11be4d0 2020-10-24T22:00:29.89281 kern.warn: [ 1021.160592] RBP: ffff98bc9cfa3000 R08: 99de27c9bb992351 R09: 9ae16a3b2f90404f 2020-10-24T22:00:29.89287 kern.warn: [ 1021.160592] R10: 0000000000000000 R11: ffff98bcca928000 R12: 0000000000030fc0 2020-10-24T22:00:29.89292 kern.warn: [ 1021.160593] R13: 0000000000000000 R14: ffff98bc4b6dbe00 R15: ffffffffc11be4d0 2020-10-24T22:00:29.89297 kern.warn: [ 1021.160593] FS: 00007f739cf48740(0000) GS:ffff98bccf080000(0000) knlGS:0000000000000000 2020-10-24T22:00:29.89302 kern.warn: [ 1021.160594] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2020-10-24T22:00:29.89307 kern.warn: [ 1021.160594] CR2: 00007f790e77d280 CR3: 0000000757346000 CR4: 0000000000340ee0 -- You are receiving this mail because: You are watching the assignee of the bug.

2 4

[PATCH] drm/msm: less magic numbers in msm_mdss_enable
by Dmitry Baryshkov 10 Jun '22

10 Jun '22

Replace magic register writes in msm_mdss_enable() with version that contains less magic and more variable names that can be traced back to the dpu_hw_catalog or the downstream dtsi files. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/gpu/drm/msm/msm_mdss.c | 79 ++++++++++++++++++++++++++++++---- 1 file changed, 71 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c index 0454a571adf7..2a48263cd1b5 100644 --- a/drivers/gpu/drm/msm/msm_mdss.c +++ b/drivers/gpu/drm/msm/msm_mdss.c @@ -21,6 +21,7 @@ #define HW_REV 0x0 #define HW_INTR_STATUS 0x0010 +#define UBWC_DEC_HW_VERSION 0x58 #define UBWC_STATIC 0x144 #define UBWC_CTRL_2 0x150 #define UBWC_PREDICTION_MODE 0x154 @@ -132,9 +133,63 @@ static int _msm_mdss_irq_domain_add(struct msm_mdss *msm_mdss) return 0; } +#define UBWC_1_0 0x10000000 +#define UBWC_2_0 0x20000000 +#define UBWC_3_0 0x30000000 +#define UBWC_4_0 0x40000000 + +static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss, + u32 ubwc_static) +{ + writel_relaxed(ubwc_static, msm_mdss->mmio + UBWC_STATIC); +} + +static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss, + unsigned int ubwc_version, + u32 ubwc_swizzle, + u32 highest_bank_bit, + u32 macrotile_mode) +{ + u32 value = (ubwc_swizzle & 0x1) | + (highest_bank_bit & 0x3) << 4 | + (macrotile_mode & 0x1) << 12; + + if (ubwc_version == UBWC_3_0) + value |= BIT(10); + + if (ubwc_version == UBWC_1_0) + value |= BIT(8); + + writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC); +} + +static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss, + unsigned int ubwc_version, + u32 ubwc_swizzle, + u32 ubwc_static, + u32 highest_bank_bit, + u32 macrotile_mode) +{ + u32 value = (ubwc_swizzle & 0x7) | + (ubwc_static & 0x1) << 3 | + (highest_bank_bit & 0x7) << 4 | + (macrotile_mode & 0x1) << 12; + + writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC); + + if (ubwc_version == UBWC_3_0) { + writel_relaxed(1, msm_mdss->mmio + UBWC_CTRL_2); + writel_relaxed(0, msm_mdss->mmio + UBWC_PREDICTION_MODE); + } else { + writel_relaxed(2, msm_mdss->mmio + UBWC_CTRL_2); + writel_relaxed(1, msm_mdss->mmio + UBWC_PREDICTION_MODE); + } +} + static int msm_mdss_enable(struct msm_mdss *msm_mdss) { int ret; + u32 hw_rev; ret = clk_bulk_prepare_enable(msm_mdss->num_clocks, msm_mdss->clocks); if (ret) { @@ -149,26 +204,34 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss) if (msm_mdss->is_mdp5) return 0; + hw_rev = readl_relaxed(msm_mdss->mmio + HW_REV); + dev_info(msm_mdss->dev, "HW_REV: 0x%x\n", hw_rev); + dev_info(msm_mdss->dev, "UBWC_DEC_HW_VERSION: 0x%x\n", + readl_relaxed(msm_mdss->mmio + UBWC_DEC_HW_VERSION)); + /* * ubwc config is part of the "mdss" region which is not accessible * from the rest of the driver. hardcode known configurations here + * + * Decoder version can be read from the UBWC_DEC_HW_VERSION reg, + * UBWC_n comes from hw_catalog. + * Unforunately this driver can not access hw catalog. */ - switch (readl_relaxed(msm_mdss->mmio + HW_REV)) { + switch (hw_rev) { case DPU_HW_VER_500: case DPU_HW_VER_501: - writel_relaxed(0x420, msm_mdss->mmio + UBWC_STATIC); + msm_mdss_setup_ubwc_dec_30(msm_mdss, UBWC_3_0, 0, 2, 0); break; case DPU_HW_VER_600: - /* TODO: 0x102e for LP_DDR4 */ - writel_relaxed(0x103e, msm_mdss->mmio + UBWC_STATIC); - writel_relaxed(2, msm_mdss->mmio + UBWC_CTRL_2); - writel_relaxed(1, msm_mdss->mmio + UBWC_PREDICTION_MODE); + /* TODO: highest_bank_bit = 2 for LP_DDR4 */ + msm_mdss_setup_ubwc_dec_40(msm_mdss, UBWC_4_0, 6, 1, 3, 1); break; case DPU_HW_VER_620: - writel_relaxed(0x1e, msm_mdss->mmio + UBWC_STATIC); + /* UBWC_2_0 */ + msm_mdss_setup_ubwc_dec_20(msm_mdss, 0x1e); break; case DPU_HW_VER_720: - writel_relaxed(0x101e, msm_mdss->mmio + UBWC_STATIC); + msm_mdss_setup_ubwc_dec_40(msm_mdss, UBWC_3_0, 6, 1, 1, 1); break; } -- 2.35.1

2 15

[PATCH] drm: adv7511: override i2c address of cec before accessing it
by Antonio Borneo 10 Jun '22

10 Jun '22

Commit 680532c50bca ("drm: adv7511: Add support for i2c_new_secondary_device") allows a device tree node to override the default addresses of the secondary i2c devices. This is useful for solving address conflicts on the i2c bus. In adv7511_init_cec_regmap() the new i2c address of cec device is read from device tree and immediately accessed, well before it is written in the proper register to override the default address. This can cause an i2c error during probe and a consequent probe failure. Once the new i2c address is read from the device tree, override the default address before any attempt to access the cec. Tested with adv7533 and stm32mp157f. Signed-off-by: Antonio Borneo <antonio.borneo(a)foss.st.com> Fixes: 680532c50bca ("drm: adv7511: Add support for i2c_new_secondary_device") --- To: Andrzej Hajda <a.hajda(a)samsung.com> To: Neil Armstrong <narmstrong(a)baylibre.com> To: Robert Foss <robert.foss(a)linaro.org> To: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> To: Jonas Karlman <jonas(a)kwiboo.se> To: Jernej Skrabec <jernej.skrabec(a)gmail.com> To: David Airlie <airlied(a)linux.ie> To: Daniel Vetter <daniel(a)ffwll.ch> To: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> To: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-stm32(a)st-md-mailman.stormreply.com --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 76555ae64e9c..629e05286fd9 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -1048,6 +1048,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv) ADV7511_CEC_I2C_ADDR_DEFAULT); if (IS_ERR(adv->i2c_cec)) return PTR_ERR(adv->i2c_cec); + + regmap_write(adv->regmap, ADV7511_REG_CEC_I2C_ADDR, + adv->i2c_cec->addr << 1); + i2c_set_clientdata(adv->i2c_cec, adv); adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec, @@ -1252,9 +1256,6 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id) if (ret) goto err_i2c_unregister_packet; - regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, - adv7511->i2c_cec->addr << 1); - INIT_WORK(&adv7511->hpd_work, adv7511_hpd_work); if (i2c->irq) { base-commit: fc74881c28d314b10efac016ef49df4ff40b8b97 -- 2.34.1

3 5

[PATCH V2 0/3] DSI host and peripheral initialisation ordering
by Dave Stevenson 10 Jun '22

10 Jun '22

Hi All Changes from v1: - New patch to refactor drm_bridge_chain_post_disable and drm_bridge_chain_pre_enable to reuse drm_atomic_bridge_chain_post_disable / drm_atomic_bridge_chain_pre_enable but with a NULL state. - New patch that adds a pre_enable_upstream_first to drm_panel. - changed from an OPS flag to a bool "pre_enable_upstream_first" in drm_bridge. - Followed Andrzej's suggestion of using continue in the main loop to avoid needing 2 additional loops (one forward to find the last bridge wanting upstream first, and the second backwards again). - Actioned Laurent's review comments on docs patch. Original cover letter: Hopefully I've cc'ed all those that have bashed this problem around previously, or are otherwise linked to DRM bridges. There have been numerous discussions around how DSI support is currently broken as it doesn't support initialising the PHY to LP-11 and potentially the clock lane to HS prior to configuring the DSI peripheral. There is no op where the interface is initialised but HS video isn't also being sent. Currently you have: - peripheral pre_enable (host not initialised yet) - host pre_enable - encoder enable - host enable - peripheral enable (video already running) vc4 and exynos currently implement the DSI host as an encoder, and split the bridge_chain. This fails if you want to switch to being a bridge and/or use atomic calls as the state of all the elements split off are not added by drm_atomic_add_encoder_bridges. dw-mipi-dsi[1] and now msm[2] use the mode_set hook to initialise the PHY, so the bridge/panel pre_enable can send commands. In their post_disable they then call the downstream bridge/panel post_disable op manually so that shutdown commands can be sent before shutting down the PHY. Nothing handles that fact, so the framework then continues down the bridge chain and calls the post_disable again, so we get unbalanced panel prepare/unprepare calls being reported [3]. There have been patches[4] proposing reversing the entire direction of pre_enable and post_disable, but that risks driving voltage into devices that have yet to be powered up. There have been discussions about adding either a pre_pre_enable, or adding a DSI host_op to initialise the host[5]. Both require significant reworking to all existing drivers in moving initialisation phases. We have patches that look like they may well be addressing race conditions in starting up a DSI peripheral[6]. This patch takes a hybrid of the two: an optional reversing of the order for specific links within the bridge chain within pre_enable and post_disable done within the drm_bridge framework. I'm more than happy to move where the flag exists in structures (currently as DRM_BRIDGE_OP_UPSTREAM_FIRST in drm_bridge_ops, but it isn't an op), but does this solve the problem posed? If not, then can you describe the actual scenario it doesn't cover? A DSI peripheral can set the flag to get the DSI host initialised first, and therefore it has a stable LP-11 state before pre_enable. Likewise the peripheral can still send shutdown commands prior to the DSI host being shut down in post_disable. It also handles the case where there are multiple devices in the chain that all want their upstream bridge enabled first, so should there be a DSI mux between host and peripheral, then it can still get the host to the correct state. An example tree is at [7] which is drm-misc-next with these patches and then a conversion of vc4_dsi to use the atomic bridge functions (will be upstreamed once we're over this hurdle). It is working happily with the Toshiba TC358762 on a Raspberry Pi 7" panel. The same approach but on our vendor 5.15 tree[8] has also been tested successfully on a TI SN65DSI83 and LVDS panel. Whilst here, I've also documented the expected behaviour of DSI hosts and peripherals to aid those who come along after. Thanks Dave [1] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synops… [2] https://lists.freedesktop.org/archives/dri-devel/2022-January/337769.html [3] https://lists.freedesktop.org/archives/dri-devel/2021-December/333908.html [4] https://lists.freedesktop.org/archives/dri-devel/2021-October/328476.html [5] https://lists.freedesktop.org/archives/dri-devel/2021-October/325853.html [6] https://lists.freedesktop.org/archives/dri-devel/2022-February/341852.html [7] https://github.com/6by9/linux/tree/drm-misc-next-vc4_dsi [8] https://github.com/6by9/linux/tree/rpi-5.15.y-sn65dsi83 Dave Stevenson (4): drm/bridge: Remove duplication from drm_bridge and drm_atomic_bridge chains drm/bridge: Introduce pre_enable_upstream_first to alter bridge init order drm/panel: Add prepare_upstream_first flag to drm_panel drm/bridge: Document the expected behaviour of DSI host controllers Documentation/gpu/drm-kms-helpers.rst | 7 ++ drivers/gpu/drm/bridge/panel.c | 3 + drivers/gpu/drm/drm_bridge.c | 181 ++++++++++++++++++++++++---------- include/drm/drm_bridge.h | 8 ++ include/drm/drm_panel.h | 10 ++ 5 files changed, 159 insertions(+), 50 deletions(-) -- 2.7.4

7 21

[PATCH 1/4] media: mediatek: vcodec: Fix decoder v4l2 bus_info not correctly
by Yunfei Dong 10 Jun '22

10 Jun '22

Fix v4l2 capability bus_info value with correct chip name according to compatible. Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> --- .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 23 ++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c index 52e5d36aa912..ccfa426a34ab 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c @@ -185,11 +185,32 @@ static int vidioc_vdec_dqbuf(struct file *file, void *priv, return v4l2_m2m_dqbuf(file, ctx->m2m_ctx, buf); } +static int mtk_vcodec_dec_get_chip_name(void *priv) +{ + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv); + struct device *dev = &ctx->dev->plat_dev->dev; + + if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-dec")) + return 8173; + else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-dec")) + return 8183; + else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-dec")) + return 8192; + else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-dec")) + return 8195; + else if (of_device_is_compatible(dev->of_node, "mediatek,mt8186-vcodec-dec")) + return 8186; + else + return 8173; +} + static int vidioc_vdec_querycap(struct file *file, void *priv, struct v4l2_capability *cap) { + int platform_name = mtk_vcodec_dec_get_chip_name(priv); + strscpy(cap->driver, MTK_VCODEC_DEC_NAME, sizeof(cap->driver)); - strscpy(cap->bus_info, MTK_PLATFORM_STR, sizeof(cap->bus_info)); + snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:mt%d", platform_name); strscpy(cap->card, MTK_PLATFORM_STR, sizeof(cap->card)); return 0; -- 2.18.0

3 5

← Newer
1
...
4
5
6
7
8
9
10
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2022