dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH] drm: bridge: it66121: Added it66121 chip external screen status judgment
by Yunlongli 10 Mar '22

10 Mar '22

In the actual tests, the IT66121 chip sometimes misjudged whether it had an external screen, so, reference the it66121_user_guid.pdf about Audio/Video data is stable or not A typical initialization of HDMI link should be based on interrupt signal and appropriate register probing. Recommended flow is detailed in IT66121 Programming Guide. Simply put, the microcontroller should monitor the HPD status first. Upon valid HPD event, move on to check RxSENDetect register to see if the receiver chip is ready for further handshaking. When RxSENDetect is asserted, start reading EDID data through DDC channels and carry on the rest of the handshaking subsequently.If the micro-controller makes no use of the interrupt signal as well as the above-mentioned status registers, the link establishment might fail. Please do follow the suggested initialization flow recommended in IT66121 Programming Guide. So, I add the IT66121_SYS_STATUS_SENDECTECT register status detection. Signed-off-by: Yunlongli <liyunlonga(a)uniontech.com> --- drivers/gpu/drm/bridge/ite-it66121.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c index 2f2a09adb4bc..9ed4fa298d11 100644 --- a/drivers/gpu/drm/bridge/ite-it66121.c +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -523,7 +523,7 @@ static bool it66121_is_hpd_detect(struct it66121_ctx *ctx) if (regmap_read(ctx->regmap, IT66121_SYS_STATUS_REG, &val)) return false; - return val & IT66121_SYS_STATUS_HPDETECT; + return ((val & IT66121_SYS_STATUS_HPDETECT) && (val & IT66121_SYS_STATUS_SENDECTECT)); } static int it66121_bridge_attach(struct drm_bridge *bridge, -- 2.20.1

3 2

[PATCH v3 0/5] drm: use dyndbg in drm_print
by Jim Cromie 05 Mar '22

05 Mar '22

hi dri-devel, Im pretty new in this particular playground. Im using this to send, is it too spammy ? too --to ? git send-email --dry-run \ --to-cmd='scripts/get_maintainer.pl --no-rolestats v3-000*.patch' \ --to=jbaron(a)akamai.com v3-000*.patch drm_debug_enabled() is called a lot (by drm_dev_dbg) to do unlikely bit-tests to selectively enable debug printing; this is a good job for dynamic-debug, IFF it is built with JUMP_LABEL. This patchset enables the use of dynamic-debug to avoid those drm_debug_enabled() overheads, if CONFIG_DRM_USE_DYNAMIC_DEBUG=y. v3: fixes missed SOB, && on BOL, commit-log tweaks reordered patches, 1 is comment, 2 is whitespace. dropped RFC, to see what happens. v2: https://lore.kernel.org/lkml/20210711055003.528167-1-jim.cromie@gmail.com/ v1: https://lore.kernel.org/lkml/20201204035318.332419-1-jim.cromie@gmail.com/ Doing so creates many new pr_debug callsites, otherwise i915 has ~120 prdbgs, and drm has just 1; bash-5.1# modprobe i915 dyndbg: 8 debug prints in module video dyndbg: 305 debug prints in module drm dyndbg: 207 debug prints in module drm_kms_helper dyndbg: 2 debug prints in module ttm dyndbg: 1720 debug prints in module i915 On amdgpu, enabling it adds ~3200 prdbgs, currently at 56 bytes each. So CONFIG_DRM_USE_DYNAMIC_DEBUG=y affects resource requirements. Im running this patchset bare-metal on an i915 laptop & an amdgpu desktop (both as loadable modules). I booted the amdgpu box with: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-5.13.0-dd7-13692-g8def25788f56 \ root=UUID=mumble ro \ rootflags=subvol=root00 rhgb \ dynamic_debug.verbose=3 main.dyndbg=+p \ amdgpu.debug=1 amdgpu.test=1 \ "amdgpu.dyndbg=format ^[ +p" That last line enables ~1700 prdbg callsites with a format like '[DML' etc at boot, and amdgpu.test=1 triggers 3 minutes of tests, causing ~76k prdbgs in 409 seconds, before I turned them off with: echo module amdgpu -p > /proc/dynamic_debug/control This is on top of master @ v5.14-rc1 Should I rebase onto something else ? Jim Cromie (5): drm/print: fixup spelling in a comment drm_print.h: rewrap __DRM_DEFINE_DBG_RATELIMITED macro drm/print: RFC add choice to use dynamic debug in drm-debug drm/print: move conditional deref into macro defn i915: map gvt pr_debug categories to bits in parameters/debug_gvt Note: 3/5, 5/5 have bits that are here for POC, but belong in dynamic_debug.c. drivers/gpu/drm/Kconfig | 13 ++++ drivers/gpu/drm/drm_print.c | 75 +++++++++++++++++- drivers/gpu/drm/i915/gvt/Makefile | 4 + drivers/gpu/drm/i915/i915_params.c | 76 +++++++++++++++++++ include/drm/drm_print.h | 117 ++++++++++++++++++++--------- 5 files changed, 247 insertions(+), 38 deletions(-) -- 2.31.1

4 12

[RFC PATCH 00/11] drm/bridge: ti-sn65dsi86: Support DisplayPort mode
by Laurent Pinchart 04 Mar '22

04 Mar '22

Hello, Despite the SN65DSI86 being a DSI to eDP bridge, it can also operate in DisplayPort mode. This patch series adds support for this feature to the ti-sn65dsi86 driver. The series starts with miscellaneous fixes and improvements in patch 01/11 to 04/11. Patch 05/11 then moves to the panel-bridge helper, and is followed by patches 06/11 and 07/11 that refactor the code to prepare for the next steps. As my goal is to use the sn65dsi86 with the R-Car DU driver, which requires DRM_BRIDGE_ATTACH_NO_CONNECTOR support, the series continues with support for this feature. In patch 08/11 the bridge connector operations are added, and in 09/11 the connector creation is made optional. Patch 10/11 then implements supports for DisplayPort mode, enabled automatically when the next component in the pipeline isn't a panel. Finally, patch 11/11 adds hotplug detection support, which isn't very useful for eDP, but is needed for DisplayPort. This series is an RFC as I haven't been able to test it fully yet. The platform I'm working on is missing support for three other components in the display pipeline (I'm on it), which are required in order to run tests. I would however like to receive feedback on the approach already, in case problems would need to be solved. Laurent Pinchart (11): dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional drm/bridge: ti-sn65dsi86: Make enable GPIO optional drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove() drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge drm/bridge: ti-sn65dsi86: Group code in sections drm/bridge: ti-sn65dsi86: Split connector creation to a function drm/bridge: ti-sn65dsi86: Implement bridge connector operations drm/bridge: ti-sn65dsi86: Make connector creation optional drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode drm/bridge: ti-sn65dsi86: Support hotplug detection .../bindings/display/bridge/ti,sn65dsi86.yaml | 1 - drivers/gpu/drm/bridge/ti-sn65dsi86.c | 266 ++++++++++++------ 2 files changed, 183 insertions(+), 84 deletions(-) -- Regards, Laurent Pinchart

8 55

[PATCH v3 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433
by Andrzej Hajda 03 Mar '22

03 Mar '22

Hi Inki, GSCALERs in Exynos SoCs support conversion between wide range of image formats, plus scaling and rotation. Driver already supports mem2mem mode - via ExynosDRM IPP framework. This patchset adds support for mem to display mode - framebuffers can be converted, scaled and send directly to Display Controller. From DRM framework's point of view every GSCALER exposes drm_plane which can be connected to display controller (display panel or TV). The feature is not well documented so the development was quite difficult - a process of trial and error, vendor code analysis, guessing from datasheets. Hopefully most of the issues were solved. I have developed and tested it on TM2 device with panel and TV paths. The patchset contains three parts: 1. Preparatory patches - mostly cleanup and refactoring of drm_crtc and drm_plane related structures, to allow usage of planes which are not physically bound to crtcs (01-13). 2. Adding local path support to GSCALER and DECON (14-20). 3. Few fixes of bugs existing already in the code but discovered due to added local path support (21-23). The patchset is based on exynos_drm_next plus my patchset adding zpos to DECON and FIMD - 'drm/exynos: add support for dynamic zpos in DECON and FIMD' - it is required to allow set z-pos position of GSCALER planes. To simplify tests I have also created branch containing all required patches: Repo: https://git.tizen.org/cgit/platform/kernel/linux-exynos Branch: sandbox/ahajda/dev/exynos-drm-local-path This is v2 version of the patchset. In this version I have moved code setting cursor plane in crtc to separate patch together with code disabling fast cursor updates - hardware does not support it. To keep bisectability DTS patches should be applied before subsequent ones. It is rebased on today's exynos-drm-next. Please be aware that DTS patches has been already applied to samsung-soc tree, I left them here to simplify testing on exynos-drm-next, which is not in sync with samsung-soc, for this reason I have moved them on the beginning of the patchset. Regards Andrzej Andrzej Hajda (24): arm64: dts: exynos: configure GSCALER related clocks arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs drm/exynos: remove exynos_drm_plane.h header drm/exynos: remove spare macro drm/exynos: drop exynos_drm_plane_config structure drm/exynos: add exynos_drm_crtc_init function drm/exynos/decon5433: embed exynos_drm_crtc directly into context drm/exynos/decon7: embed exynos_drm_crtc directly into context drm/exynos/fimd: embed exynos_drm_crtc directly into context drm/exynos/mixer: embed exynos_drm_crtc directly into context drm/exynos/vidi: embed exynos_drm_crtc directly into context drm/exynos: remove standalone exynos_drm_crtc leftovers drm/exynos/vidi: remove encoder_to_vidi helper drm/exynos: unify plane type assignment drm/exynos: set primary plane in exynos_drm_crtc_init drm/exynos: set cursor plane in exynos_drm_crtc_init drm/exynos: add plane update/disable callbacks for planes drm/exynos: add GSCALER plane capability drm/exynos/gscaler: fix id assignement drm/exynos/gscaler: add local path support drm/exynos/decon5433: add local path support drm/exynos/decon5433: wait for finish previous update drm/exynos/gscaler: change supported color format BGRX8888 to XBGR8888 drm/exynos/gscaler: fix handling YVU420 pixel format .../dts/exynos/exynos5433-tm2-common.dtsi | 6 + arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 6 +- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 25 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 162 ++++++++----- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 66 +++-- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 46 ++-- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 - drivers/gpu/drm/exynos/exynos_drm_drv.h | 50 ++-- drivers/gpu/drm/exynos/exynos_drm_fb.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 85 +++---- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 229 ++++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_plane.c | 84 ++++--- drivers/gpu/drm/exynos/exynos_drm_plane.h | 14 -- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 48 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 95 +++----- drivers/gpu/drm/exynos/regs-decon5433.h | 6 + drivers/gpu/drm/exynos/regs-gsc.h | 6 + 18 files changed, 538 insertions(+), 408 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h -- 2.17.1

5 35

[PATCH] drm/bridge: cdns-dsi: Make sure to to create proper aliases for dt
by Nishanth Menon 28 Feb '22

28 Feb '22

Add MODULE_DEVICE_TABLE to the device tree table to create required aliases needed for module to be loaded with device tree based platform. Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver") Signed-off-by: Nishanth Menon <nm(a)ti.com> --- drivers/gpu/drm/bridge/cdns-dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c b/drivers/gpu/drm/bridge/cdns-dsi.c index d8a15c459b42..829e1a144656 100644 --- a/drivers/gpu/drm/bridge/cdns-dsi.c +++ b/drivers/gpu/drm/bridge/cdns-dsi.c @@ -1284,6 +1284,7 @@ static const struct of_device_id cdns_dsi_of_match[] = { { .compatible = "cdns,dsi" }, { }, }; +MODULE_DEVICE_TABLE(of, cdns_dsi_of_match); static struct platform_driver cdns_dsi_platform_driver = { .probe = cdns_dsi_drm_probe, -- 2.32.0

3 4

[PATCH] drm: Only select I2C_ALGOBIT for drivers that actually need it
by Uwe Kleine-König 21 Feb '22

21 Feb '22

While working on a drm driver that doesn't need the i2c algobit stuff I noticed that DRM selects this code even tough only 8 drivers actually use it. While also only some drivers use i2c, keep the select for I2C for the next cleanup patch. Still prepare this already by also selecting I2C for the individual drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> --- drivers/gpu/drm/Kconfig | 5 ++++- drivers/gpu/drm/ast/Kconfig | 2 ++ drivers/gpu/drm/gma500/Kconfig | 2 ++ drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 ++ drivers/gpu/drm/i915/Kconfig | 2 ++ drivers/gpu/drm/mgag200/Kconfig | 2 ++ drivers/gpu/drm/nouveau/Kconfig | 2 ++ 7 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3c16bd1afd87..351ea617c498 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -12,7 +12,6 @@ menuconfig DRM select HDMI select FB_CMDLINE select I2C - select I2C_ALGOBIT select DMA_SHARED_BUFFER select SYNC_FILE # gallium uses SYS_kcmp for os_same_file_description() to de-duplicate @@ -233,6 +232,8 @@ config DRM_RADEON select DRM_KMS_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE @@ -254,6 +255,8 @@ config DRM_AMDGPU select DRM_SCHED select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig index fbcf2f45cef5..bcc25decd485 100644 --- a/drivers/gpu/drm/ast/Kconfig +++ b/drivers/gpu/drm/ast/Kconfig @@ -6,6 +6,8 @@ config DRM_AST select DRM_VRAM_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT help Say yes for experimental AST GPU driver. Do not enable this driver without having a working -modesetting, diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 0cff20265f97..e26c3a24955d 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -3,6 +3,8 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 select ACPI_VIDEO if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig b/drivers/gpu/drm/hisilicon/hibmc/Kconfig index 43943e980203..ac8c42dc79f6 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig @@ -6,6 +6,8 @@ config DRM_HISI_HIBMC select DRM_VRAM_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT help Choose this option if you have a Hisilicon Hibmc soc chipset. If M is selected the module will be called hibmc-drm. diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 69f57ca9c68d..b3bb6f7cfbbc 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -13,6 +13,8 @@ config DRM_I915 select DRM_PANEL select DRM_MIPI_DSI select RELAY + select I2C + select I2C_ALGOBIT select IRQ_WORK # i915 depends on ACPI_VIDEO when ACPI is enabled # but for select to work, need to select ACPI_VIDEO's dependencies, ick diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig index eec59658a938..b28c5e4828f4 100644 --- a/drivers/gpu/drm/mgag200/Kconfig +++ b/drivers/gpu/drm/mgag200/Kconfig @@ -4,6 +4,8 @@ config DRM_MGAG200 depends on DRM && PCI && MMU select DRM_GEM_SHMEM_HELPER select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT help This is a KMS driver for Matrox G200 chips. It supports the original MGA G200 desktop chips and the server variants. It requires 0.3.0 diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 9436310d0854..8823f0b24c73 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -7,6 +7,8 @@ config DRM_NOUVEAU select DRM_KMS_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT select X86_PLATFORM_DEVICES if ACPI && X86 base-commit: 315d99318179b9cd5077ccc9f7f26a164c9fa998 -- 2.30.2

1 1

[PATCH v2 1/2] drm/msm/dpu: Add a function to retrieve the current CTL status
by AngeloGioacchino Del Regno 18 Feb '22

18 Feb '22

Add a function that returns whether the requested CTL is active or not: this will be used in a later commit to fix command mode panel issues. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)somainline.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 6 ++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7 +++++++ 2 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c index 64740ddb983e..3b6fd73eb3a8 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c @@ -91,6 +91,11 @@ static inline void dpu_hw_ctl_trigger_start(struct dpu_hw_ctl *ctx) DPU_REG_WRITE(&ctx->hw, CTL_START, 0x1); } +static inline bool dpu_hw_ctl_is_started(struct dpu_hw_ctl *ctx) +{ + return !!(DPU_REG_READ(&ctx->hw, CTL_START) & BIT(0)); +} + static inline void dpu_hw_ctl_trigger_pending(struct dpu_hw_ctl *ctx) { trace_dpu_hw_ctl_trigger_prepare(ctx->pending_flush_mask, @@ -579,6 +584,7 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops, ops->get_pending_flush = dpu_hw_ctl_get_pending_flush; ops->get_flush_register = dpu_hw_ctl_get_flush_register; ops->trigger_start = dpu_hw_ctl_trigger_start; + ops->is_started = dpu_hw_ctl_is_started; ops->trigger_pending = dpu_hw_ctl_trigger_pending; ops->reset = dpu_hw_ctl_reset_control; ops->wait_reset_status = dpu_hw_ctl_wait_reset_status; diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h index 806c171e5df2..ac1544474022 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h @@ -61,6 +61,13 @@ struct dpu_hw_ctl_ops { */ void (*trigger_start)(struct dpu_hw_ctl *ctx); + /** + * check if the ctl is started + * @ctx : ctl path ctx pointer + * @Return: true if started, false if stopped + */ + bool (*is_started)(struct dpu_hw_ctl *ctx); + /** * kickoff prepare is in progress hw operation for sw * controlled interfaces: DSI cmd mode and WB interface -- 2.32.0

3 11

[Bug 121831] New: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo
by bugzilla-daemon＠bugzilla.kernel.org 17 Feb '22

17 Feb '22

https://bugzilla.kernel.org/show_bug.cgi?id=121831 Bug ID: 121831 Summary: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo Product: Drivers Version: 2.5 Kernel Version: 4.7-rc6 Hardware: All 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: casteyde.christian(a)free.fr Regression: No Created attachment 222631 --> https://bugzilla.kernel.org/attachment.cgi?id=222631&action=edit dmesg output Slackware 64 14.1 With kmemcheck activated, I get the following warnings: [ 1185.586288] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8801c2cd5d08) [ 1185.586292] 000000000000000060f11c81ffffffff68509ab40188ffff0100010001000000 [ 1185.586314] i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u [ 1185.586335] ^ [ 1185.586337] RIP: 0010:[<ffffffff8158521d>] [<ffffffff8158521d>] fence_signal+0x1d/0xe0 [ 1185.586343] RSP: 0018:ffff8801b560fa20 EFLAGS: 00010282 [ 1185.586345] RAX: 0000000000000003 RBX: ffff8801c2cd5cc0 RCX: 0000000000000002 [ 1185.586346] RDX: 0000000080000002 RSI: ffff8801b5591fa0 RDI: ffff8801c2cd5cc0 [ 1185.586348] RBP: ffff8801b560fa50 R08: 0000000000000000 R09: 0000000000000001 [ 1185.586349] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003 [ 1185.586350] R13: ffff8801c2cd5cc0 R14: 00000000021ae410 R15: ffff8800a9490000 [ 1185.586352] FS: 00007fe3e0e408c0(0000) GS:ffff8801c7400000(0000) knlGS:0000000000000000 [ 1185.586353] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1185.586355] CR2: ffff8801c7060c90 CR3: 00000001b558d000 CR4: 00000000000406f0 [ 1185.586356] [<ffffffff8148cb7a>] radeon_fence_signaled+0x4a/0x80 [ 1185.586360] [<ffffffff814f5cf7>] radeon_sa_bo_free+0x37/0xb0 [ 1185.586364] [<ffffffff81547f39>] radeon_ib_free+0x29/0x40 [ 1185.586369] [<ffffffff814a5105>] radeon_cs_parser_fini+0xc5/0x120 [ 1185.586372] [<ffffffff814a597b>] radeon_cs_ioctl+0x2fb/0x7d0 [ 1185.586374] [<ffffffff81449dce>] drm_ioctl+0x13e/0x530 [ 1185.586378] [<ffffffff81471b17>] radeon_drm_ioctl+0x47/0x80 [ 1185.586381] [<ffffffff811aebce>] do_vfs_ioctl+0x8e/0x670 [ 1185.586384] [<ffffffff811af1ec>] SyS_ioctl+0x3c/0x70 [ 1185.586386] [<ffffffff819434a5>] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 1185.586391] [<ffffffffffffffff>] 0xffffffffffffffff [ 1197.075973] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800a2cf4ac8) [ 1197.075977] 0200000000000000ffffffff3f000000ffffffff3f0000000000000000000000 [ 1197.075999] i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u [ 1197.076019] ^ [ 1197.076021] RIP: 0010:[<ffffffff81584fc6>] [<ffffffff81584fc6>] fence_signal_locked+0x16/0xc0 [ 1197.076028] RSP: 0018:ffff8801c7403d18 EFLAGS: 00010082 [ 1197.076029] RAX: 000000000000001a RBX: ffff8800a2cf4b10 RCX: 0000000000000000 [ 1197.076031] RDX: ffff8800a9490000 RSI: 0000000000000003 RDI: ffff8800a2cf4a80 [ 1197.076032] RBP: ffff8801c7403d48 R08: 0000000000000000 R09: 0000000000000001 [ 1197.076033] R10: 0000000000000000 R11: ffffffff8200b540 R12: ffff8800a2cf4a80 [ 1197.076034] R13: ffff8800a9491ea8 R14: 0000000000000000 R15: 0000000000000003 [ 1197.076036] FS: 0000000000000000(0000) GS:ffff8801c7400000(0000) knlGS:0000000000000000 [ 1197.076038] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1197.076039] CR2: ffff8801c29c016c CR3: 0000000002006000 CR4: 00000000000406f0 [ 1197.076040] [<ffffffff8148c571>] radeon_fence_check_signaled+0x41/0x80 [ 1197.076044] [<ffffffff810da49d>] __wake_up_common+0x4d/0x80 [ 1197.076334] [<ffffffff810da504>] __wake_up+0x34/0x50 [ 1197.076336] [<ffffffff8148c6c6>] radeon_fence_process+0x26/0x30 [ 1197.076338] [<ffffffff814e0caa>] evergreen_irq_process+0x92a/0x17e0 [ 1197.076342] [<ffffffff814a4309>] radeon_driver_irq_handler_kms+0x19/0x40 [ 1197.076345] [<ffffffff810f15e4>] handle_irq_event_percpu+0x64/0x100 [ 1197.076349] [<ffffffff810f16b4>] handle_irq_event+0x34/0x60 [ 1197.076352] [<ffffffff810f466e>] handle_edge_irq+0xbe/0x150 [ 1197.076356] [<ffffffff810617f8>] handle_irq+0x68/0x180 [ 1197.076360] [<ffffffff81060ff8>] do_IRQ+0x68/0x130 [ 1197.076362] [<ffffffff81943e09>] ret_from_intr+0x0/0x19 [ 1197.076367] [<ffffffff816fec82>] cpuidle_enter+0x12/0x20 [ 1197.076371] [<ffffffff810db0f5>] call_cpuidle+0x25/0x40 [ 1197.076373] [<ffffffff810db3c3>] cpu_startup_entry+0x1b3/0x290 [ 1197.076375] [<ffffffff8193ad5c>] rest_init+0x12c/0x140 [ 1197.076379] [<ffffffff82299de5>] start_kernel+0x354/0x361 [ 1197.076384] [<ffffffff822992ae>] x86_64_start_reservations+0x2f/0x31 [ 1197.076387] [<ffffffff8229939b>] x86_64_start_kernel+0xeb/0xf0 [ 1197.076390] [<ffffffffffffffff>] 0xffffffffffffffff [ 1207.836251] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800a2cf4348) etc. In gdb: (gdb) l *0xffffffff8158521d 0xffffffff8158521d is in fence_signal (drivers/dma-buf/fence.c:114). 109 unsigned long flags; 110 111 if (!fence) 112 return -EINVAL; 113 114 if (!ktime_to_ns(fence->timestamp)) { 115 fence->timestamp = ktime_get(); 116 smp_mb__before_atomic(); 117 } -- You are receiving this mail because: You are watching the assignee of the bug.

2 3

[PATCH v1] fbtft: fb_st7789v: added reset on init_display()
by Oliver Graute 10 Feb '22

10 Feb '22

staging: fbtft: fb_st7789v: reset display before initialization In rare cases the display is flipped or mirrored. This was observed more often in a low temperature environment. A clean reset on init_display() should help to get registers in a sane state. Signed-off-by: Oliver Graute <oliver.graute(a)kococonnector.com> --- drivers/staging/fbtft/fb_st7789v.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/fbtft/fb_st7789v.c b/drivers/staging/fbtft/fb_st7789v.c index 3a280cc1892c..0a2dbed9ffc7 100644 --- a/drivers/staging/fbtft/fb_st7789v.c +++ b/drivers/staging/fbtft/fb_st7789v.c @@ -82,6 +82,8 @@ enum st7789v_command { { int rc; + par->fbtftops.reset(par); + rc = init_tearing_effect_line(par); if (rc) return rc; -- 2.17.1

2 4

[Bug 201539] New: AMDGPU R9 390 automatic fan speed control in Linux 4.19
by bugzilla-daemon＠bugzilla.kernel.org 05 Feb '22

05 Feb '22

https://bugzilla.kernel.org/show_bug.cgi?id=201539 Bug ID: 201539 Summary: AMDGPU R9 390 automatic fan speed control in Linux 4.19 Product: Drivers Version: 2.5 Kernel Version: 4.19 Hardware: All 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: 0xe2.0x9a.0x9b(a)gmail.com Regression: No GPU: R9 390 Kernel module: amdgpu Application (example): Rise of the Tomb Raider benchmark In Linux 4.18 the fan speed of the GPU gradually adapts to GPU load. Maximum pwm is 155 during the benchmark. In Linux 4.19 the overall fan speed is lower (which is more silent than 4.18, with maximum at 112) but the fan spikes to full speed (pwm=255) for 1-2 seconds which is extremely loud. The 4.18 and 4.19 kernels are using the same firmware. -- You are receiving this mail because: You are watching the assignee of the bug.

2 78

← Newer
1
2
3
4
5
6
7
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021