Re: [RFC 0/6] Define and use reset domain for GPU recovery in amdgpu

Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky: This patchset is based on earlier work by Boris[1] that allowed to have an ordered workqueue at the driver level that will be used by the different schedulers to queue their timeout work. On top of that I also serialized any GPU reset we trigger

Re: [RFC 4/6] drm/amdgpu: Serialize non TDR gpu recovery with TDRs

Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky: Use reset domain wq also for non TDR gpu recovery trigers such as sysfs and RAS. We must serialize all possible GPU recoveries to gurantee no concurrency there. For TDR call the original recovery function directly since it's already executed from

Re: [RFC 3/6] drm/amdgpu: Fix crash on modprobe

Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky: Restrict jobs resubmission to suspend case only since schedulers not initialised yet on probe. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [RFC 2/6] drm/amdgpu: Move scheduler init to after XGMI is ready

Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky: Before we initialize schedulers we must know which reset domain are we in - for single device there iis a single domain per device and so single wq per device. For XGMI the reset domain spans the entire XGMI hive and so the reset wq is per hive.

[PATCH] video: fbdev: Check for null res pointer

The return value of platform_get_resource() needs to be checked. To avoid use of error pointer in case of the failure of alloc. Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev") Signed-off-by: Jiasheng Jiang --- drivers/video/fbdev/imxfb.c | 2 ++ 1 file changed, 2 insertions(+)

Re: [PATCH 3/3] drm: fix the warnning of string style for scheduler trace.

A soft reminder. May I know any comments of this patch, just a minor warning fix? Thanks, Ray On Mon, Dec 13, 2021 at 02:34:22PM +0800, Huang, Ray wrote: > Use __string(), __assign_str() and __get_str() helpers in the TRACE_EVENT() > instead of string definitions in gpu scheduler trace. > > [

Re: [PATCH] dt-bindings: display: bridge: lvds-codec: Document TI DS90CF364A decoder

Hi Marek, Thank you for the patch. On Sat, Dec 18, 2021 at 04:23:09PM +0100, Marek Vasut wrote: > Add compatible string for TI DS90CF364A, which is another LVDS to DPI > decoder similar to DS90CF384A, except it is using smaller package and > only provides 18bit DPI bus. We could add a rule to

[GIT PULL] mediatek drm fixes for 5.16

Hi, Dave & Daniel: This includes: 1. Perform NULL pointer check for mtk_hdmi_conf. Regards, Chun-Kuang. The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) are available in the git repository at:

[PATCH v9 6/6] drm/i915: Remove unused i915->ggtt

The reference to the GGTT from the private date is not used anymore. Remove it. The ggtt in the root gt will now be dynamically allocated and the deallocation handled by the drmm_* managed allocation. Suggested-by: Matt Roper Signed-off-by: Andi Shyti Cc: Michał Winiarski Reviewed-by:

[PATCH v9 5/6] drm/i915/selftests: Use to_gt() helper for GGTT accesses

From: Michał Winiarski GGTT is currently available both through i915->ggtt and gt->ggtt, and we eventually want to get rid of the i915->ggtt one. Use to_gt() for all i915->ggtt accesses to help with the future refactoring. Signed-off-by: Michał Winiarski Cc: Michal Wajdeczko Signed-off-by:

[PATCH v9 2/6] drm/i915: Use to_gt() helper for GGTT accesses

From: Michał Winiarski GGTT is currently available both through i915->ggtt and gt->ggtt, and we eventually want to get rid of the i915->ggtt one. Use to_gt() for all i915->ggtt accesses to help with the future refactoring. Signed-off-by: Michał Winiarski Cc: Michal Wajdeczko Signed-off-by:

[PATCH v9 4/6] drm/i915/display: Use to_gt() helper for GGTT accesses

From: Michał Winiarski GGTT is currently available both through i915->ggtt and gt->ggtt, and we eventually want to get rid of the i915->ggtt one. Use to_gt() for all i915->ggtt accesses to help with the future refactoring. Signed-off-by: Michał Winiarski Cc: Michal Wajdeczko Signed-off-by:

[PATCH v9 3/6] drm/i915/gem: Use to_gt() helper for GGTT accesses

From: Michał Winiarski GGTT is currently available both through i915->ggtt and gt->ggtt, and we eventually want to get rid of the i915->ggtt one. Use to_gt() for all i915->ggtt accesses to help with the future refactoring. Signed-off-by: Michał Winiarski Cc: Michal Wajdeczko Signed-off-by:

[PATCH v9 1/6] drm/i915/gt: Use to_gt() helper for GGTT accesses

From: Michał Winiarski GGTT is currently available both through i915->ggtt and gt->ggtt, and we eventually want to get rid of the i915->ggtt one. Use to_gt() for all i915->ggtt accesses to help with the future refactoring. Signed-off-by: Michał Winiarski Cc: Michal Wajdeczko Signed-off-by:

[PATCH v9 0/6] More preparation for multi gt patches

Hi, thanks Matt for merging the first 10 patches from v8. This series contains only the last 6 patches from the previous that make use of the newly inserted to_gt() to reach the ggtt that at the end moves from the i915 structure to the gt. I have reshuffled a bit the order of the patche (refer

Re: [PATCH] drm: drm/drm_file.h: fix a kernel-doc typo

Reviewed-by: Simon Ser

[PATCH] drm: drm/drm_modeset_lock.h: add a kernel-doc entry

Add @stack_depot to the kernel-doc comments to prevent a kernel-doc build warning. ../include/drm/drm_modeset_lock.h:74: warning: Function parameter or member 'stack_depot' not described in 'drm_modeset_acquire_ctx' Signed-off-by: Randy Dunlap Cc: David Airlie Cc: Daniel Vetter ---

[PATCH] drm: drm/drm_file.h: fix a kernel-doc typo

Fix a build warning from 'make htmldocs' by correcting the lock name in the kernel-doc comment. ../include/drm/drm_file.h:369: warning: Function parameter or member 'master_lookup_lock' not described in 'drm_file' Signed-off-by: Randy Dunlap Cc: David Airlie Cc: Daniel Vetter ---

Re: [PATCH 1/2] drm/bridge: chipone-icn6211: Switch to atomic operations

On Fri, Nov 19, 2021 at 8:23 PM Jagan Teki wrote: > > Replace atomic version of the pre_enable/enable/post_disable > operations to continue the transition to the atomic API. > > Also added default drm atomic operations for duplicate, destroy > and reset state API's in order to have smooth

Re: [PATCH] drm/panel: panel-simple: Fix proper bpc for AM-1280800N3TZQW-T00H

Hi Sam, On Thu, Nov 11, 2021 at 3:11 PM Jagan Teki wrote: > > AM-1280800N3TZQW-T00H panel support 8 bpc not 6 bpc as per > recent testing in i.MX8MM platform. > > Fix it. > > Fixes: bca684e69c4c ("drm/panel: simple: Add AM-1280800N3TZQW-T00H") > Signed-off-by: Jagan Teki > --- >

Re: [PATCH v1 0/5] Improvements for TC358768 DSI bridge driver

19.10.2021 23:37, Dmitry Osipenko пишет: > 19.10.2021 12:47, Robert Foss пишет: >> Applied to drm-misc-next >> >> On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote: >>> >>> This series adds couple improvements to the TC358768 DSI bridge driver, >>> enabling Panasonic VVX10F004B00 DSI panel

[Bug 215223] AMDGPU Driver with Radeon RX 6700 sometimes can not find display

https://bugzilla.kernel.org/show_bug.cgi?id=215223 reznov90...@gmail.com changed: What|Removed |Added Kernel Version|5.15.6 |5.15.10 -- You may reply to

[Bug 215223] AMDGPU Driver with Radeon RX 6700 sometimes can not find display

https://bugzilla.kernel.org/show_bug.cgi?id=215223 --- Comment #5 from reznov90...@gmail.com --- Created attachment 300077 --> https://bugzilla.kernel.org/attachment.cgi?id=300077=edit journalctl -b - 1..4 -- You may reply to this email to add a comment. You are receiving this mail because:

[Bug 215223] AMDGPU Driver with Radeon RX 6700 sometimes can not find display

https://bugzilla.kernel.org/show_bug.cgi?id=215223 --- Comment #4 from reznov90...@gmail.com --- I also have update to latest kernel and have same problem. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

[Bug 215223] AMDGPU Driver with Radeon RX 6700 sometimes can not find display

https://bugzilla.kernel.org/show_bug.cgi?id=215223 --- Comment #3 from reznov90...@gmail.com --- Created attachment 300075 --> https://bugzilla.kernel.org/attachment.cgi?id=300075=edit dmesg -- You may reply to this email to add a comment. You are receiving this mail because: You are

[Bug 215223] AMDGPU Driver with Radeon RX 6700 sometimes can not find display

https://bugzilla.kernel.org/show_bug.cgi?id=215223 --- Comment #2 from reznov90...@gmail.com --- (In reply to Alex Deucher from comment #1) > Please attach your dmesg output. What type of display is problematic (HDMI, > Displayport, some sort of dongle)? Sorry for long delay. I have not got

[PATCH] video: fbdev: use swap() to make code cleaner

From: Yang Guang Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid opencoding it. Reported-by: Zeal Robot Signed-off-by: David Yang Signed-off-by: Yang Guang --- drivers/video/fbdev/sis/sis_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [syzbot] KASAN: use-after-free Read in drm_gem_object_release_handle

syzbot has found a reproducer for the following issue on: HEAD commit:fbf252e09678 Add linux-next specific files for 20211216 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=168bf493b0 kernel config:

[PATCH] drm: adv7511: override i2c address of cec before accessing it

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

[intel-gfx] How to determine supported HDMI versions of an Intel GPU

[ Please CC me I am not subscribed to any CCed mailing-lists ] Hi Daniel, I hope you are well. While searching for a new monitor I wanted to buy a miniHDMI->HDMI adapter or cable to connect it. My Samsung laptop has a Intel HD graphics 3000 GPU and a miniHDMI connector. Unfortunately, I have

Re: [PATCH] drm/i915: Fix possible uninitialized variable in parallel extension

On Sat, Dec 18, 2021 at 04:19:09PM -0800, Matthew Brost wrote: 'prev_engine' was declared inside the output loop and checked in the inner after at least 1 pass of either loop. The variable should be declared outside both loops as it needs to be persistent across the entire loop structure.