[PATCH] drm/amdgpu: Allow the initramfs generator to include psp_13_0_6_ta

Allow the initramfs generator to automatically include psp_13_0_6_ta firmware to initramfs. Signed-off-by: Candice Li Reviewed-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/psp_v13_0.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c

RE: [PATCH 1/2] Revert "drm/amdgpu: update kernel vcn ring test"

[AMD Official Use Only - General] Hi Alex , Revert changes are merged, will rework on changes and submit. -Original Message- From: Alex Deucher Sent: Thursday, July 13, 2023 10:22 PM To: Jamadar, Saleemkhan Cc: amd-gfx@lists.freedesktop.org; Olsak, Marek ; Koenig, Christian ; Liu,

RE: [PATCH Review V3 2/2] drm/amdgpu: Disable RAS by default on APU flatform

[AMD Official Use Only - General] The series is: Reviewed-by: Tao Zhou > -Original Message- > From: Stanley.Yang > Sent: Friday, July 14, 2023 11:42 AM > To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ; > Zhou1, Tao ; Chai, Thomas ; Li, > Candice > Cc: Yang, Stanley > Subject:

[PATCH Review V3 2/2] drm/amdgpu: Disable RAS by default on APU flatform

Disable RAS feature by default for aqua vanjaram on APU platform. Changed from V1: Splite Disable RAS by default on APU platform into a separated patch. Changed from V2: Avoid to modify global variable amdgpu_ras_enable. Signed-off-by: Stanley.Yang Reviewed-by: Hawking

[PATCH Review V3 1/2] drm/amdgpu: Enable aqua vanjaram RAS

Enable RAS for aqua vanjaram. Changed from V1: Split the change in amdgpu_ras_asic_supported into a separated patch. Changed from V2: Avoid to modify global variable amdgpu_ras_enable. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang ---

[PATCH v2 4/6] drm/amdgpu: Limit info in coredump for kernel threads

If a kernel thread caused the reset, the information available to be logged will be limited, so return early in the dump function. Signed-off-by: André Almeida --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH v2 6/6] drm/amdgpu: Create version number for coredumps

Even if there's nothing currently parsing amdgpu's coredump files, if we eventually have such tools they will be glad to find a version field to properly read the file. Create a version number to be displayed on top of coredump file, to be incremented when the file format or content get changed.

[PATCH v2 5/6] drm/amdgpu: Log IBs and ring name at coredump

Log the IB addresses used by the hung job along with the stuck ring name. Note that due to nested IBs, the one that caused the reset itself may be in not listed address. Signed-off-by: André Almeida --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++

[PATCH v2 3/6] drm/amdgpu: Rework coredump to use memory dynamically

Instead of storing coredump information inside amdgpu_device struct, move if to a proper separated struct and allocate it dynamically. This will make it easier to further expand the logged information. Signed-off-by: André Almeida --- v2: Replace GFP_KERNEL with GPF_NOWAIT

[PATCH v2 2/6] drm/amdgpu: Allocate coredump memory in a nonblocking way

During a GPU reset, a normal memory reclaim could block to reclaim memory. Giving that coredump is a best effort mechanism, it shouldn't disturb the reset path. Change its memory allocation flag to a nonblocking one. Signed-off-by: André Almeida --- v2: New patch

[PATCH v2 1/6] drm/amdgpu: Create a module param to disable soft recovery

Create a module parameter to disable soft recoveries on amdgpu, making every recovery go through the device reset path. This option makes easier to force device resets for testing and debugging purposes. Signed-off-by: André Almeida --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +

[PATCH v2 0/6] drm/amdgpu: Add new reset option and rework coredump

Hi, The goal of this patchset is to improve debugging device resets on amdgpu. The first patch creates a new module parameter to disable soft recoveries, ensuring every recovery go through the full device reset, making easier to generate resets from userspace tools like [0] and [1]. This is

Re: [PATCH v2] drm/amd/display: Use root connector's colorspace property for MST

[Public] Reviewed-by: Aurabindo Pillai -- Regards, Jay From: amd-gfx on behalf of Harry Wentland Sent: Thursday, July 13, 2023 3:58 PM To: amd-gfx@lists.freedesktop.org Cc: Wentland, Harry Subject: [PATCH v2] drm/amd/display: Use root connector's

[PATCH v2] drm/amd/display: Use root connector's colorspace property for MST

After driver init we shouldn't create new properties. Doing so will lead to a warning storm from __drm_mode_object_add. We don't really need to create the property for MST connectors. Re-using the mst_root connector's property is fine. v2: Add curly braces to avoid possibly 'else' confusion

Re: [PATCH v4 21/21] dyndbg-doc: add classmap info to howto

On 7/13/23 09:36, Jim Cromie wrote: > Add some basic info on classmap usage and api > > Signed-off-by: Jim Cromie > --- > .../admin-guide/dynamic-debug-howto.rst | 64 ++- > 1 file changed, 63 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH v4 20/21] config TEST_DYNAMIC_DEBUG default m

Hi Jim, On 7/13/23 09:36, Jim Cromie wrote: > Signed-off-by: Jim Cromie > --- > lib/Kconfig.debug | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index d4fbbcc395d2..82d11ac63758 100644 > --- a/lib/Kconfig.debug > +++

Re: [PATCH v3 09/12] drm/amdgpu: use doorbell manager for kfd process doorbells

On 2023-06-20 13:16, Shashank Sharma wrote: This patch: - adds a doorbell object in kfd pdd structure. - allocates doorbells for a process while creating its queue. - frees the doorbells with pdd destroy. - moves doorbell bitmap init function to kfd_doorbell.c PS: This patch ensures that we

Re: [PATCH v3 08/12] drm/amdgpu: use doorbell manager for kfd kernel doorbells

On 2023-06-20 13:16, Shashank Sharma wrote: This patch: - adds a doorbell bo in kfd device structure. - creates doorbell page for kfd kernel usages. - updates the get_kernel_doorbell and free_kernel_doorbell functions accordingly V2: Do not use wrapper API, use direct

[PATCH] drm/amd: Fix an error handling mistake in psp_sw_init()

If the second call to amdgpu_bo_create_kernel() fails, the memory allocated from the first call should be cleared. If the third call fails, the memory from the second call should be cleared. Fixes: b95b5391684b ("drm/amdgpu/psp: move PSP memory alloc from hw_init to sw_init") Signed-off-by:

Re: [PATCH 1/3] drm/amd/display: Expose more formats for overlay planes on DCN

On 7/8/23 22:06, Joshua Ashton wrote: DCN planes are universal and therefore overlay planes can use the same formats as primary planes, unlike DCE. Gamescope/Steam Deck would like to take advantage of this functionality for partial composition which in some cases in our pipeline, can contain

Re: [PATCH 3/3] drm/amd/display: Implement zpos property

On 2023-07-08 22:06, Joshua Ashton wrote: > Despite certain GPUs supporting multiple overlay planes already in > AMDGPU, the driver did not expose the zpos property which is required > for userspace to take advantage of multiple overlay planes in any > meaningful way. > > The driver was

Re: [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback

Hi Jim On Thu, Jul 13, 2023 at 10:36:23AM -0600, Jim Cromie wrote: > We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using > __COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should > fail on this (and harder to avoid situations): > > DECLARE_FOO(); DECLARE_FOO(); >

Re: [PATCH 1/2] Revert "drm/amdgpu: update kernel vcn ring test"

On Thu, Jul 13, 2023 at 1:20 AM Saleemkhan Jamadar wrote: > > VCN FW depncencies revert it to unblock others Alternatively, you could fix it by adding the appropriate firmware version checks if that is the underlying issue. Alex > > This reverts commit

[PATCH v4 21/21] dyndbg-doc: add classmap info to howto

Add some basic info on classmap usage and api Signed-off-by: Jim Cromie --- .../admin-guide/dynamic-debug-howto.rst | 64 ++- 1 file changed, 63 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst

[PATCH v4 20/21] config TEST_DYNAMIC_DEBUG default m

Signed-off-by: Jim Cromie --- lib/Kconfig.debug | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index d4fbbcc395d2..82d11ac63758 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2696,13 +2696,14 @@ config TEST_STATIC_KEYS

[PATCH v4 19/21] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers

Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c files. For drivers, add the decl just above the module's PARAMs, since it identifies the "inherited" drm.debug param. Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring DRM_CLASSMAP_USE will have its

[PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback

We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using __COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should fail on this (and harder to avoid situations): DECLARE_FOO(); DECLARE_FOO(); Its 2023, can we haz a no-fallback __UNIQUE_ID ? NOTE: This also changes

[PATCH v4 14/21] dyndbg: refactor ddebug_classparam_clamp_input

Extract input validation code, from param_set_dyndbg_module_classes() (the sys-node >handler) to new: ddebug_classparam_clamp_input(kp), call it from former. It takes kernel-param arg, so it can complain about "foo: bad input". Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(), to

[PATCH v4 17/21] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

Lots of burn-in testing needed before signing, upstreaming. I set default Y to maximize testing by default. NOTE: without __UNIQUE_ID fix in HEAD~1, this population of DRM_CLASSMAP_USE()rs experienced name collisions in several different @lkp-robot allyes and randconfigs, probably because the

[PATCH v4 15/21] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API

move macro from test-dynamic-debug.c into header, and refine it. Distinguish the 2 use cases of DYNDBG_CLASSMAP_PARAM* 1.DYNDBG_CLASSMAP_PARAM_REF for DRM, to pass in extern __drm_debug by name. dyndbg keeps bits in it, so drm can still use it as before/remaining.

[PATCH v4 16/21] dyndbg-test: make it build with just CONFIG_DYNAMIC_DEBUG_CORE

To make the 2 test modules buildable with CONFIG_DYNAMIC_DEBUG_CORE, add CFLAGS_$ofile defns to supply -DDYNAMIC_DEBUG_MODULE to cc. And change the Kconfig entry to allow building with just _CORE. Signed-off-by: Jim Cromie --- lib/Kconfig.debug | 10 +- lib/Makefile | 2 ++ 2

[PATCH v4 13/21] dyndbg-API: fix DECLARE_DYNDBG_CLASSMAP & CONFIG_DRM_USE_DYNAMIC_DEBUG

DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K rule: "define once, refer many times". When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across DRM core & drivers; they all repeat the same classmap-defn args, which must match for the modules to respond together when

[PATCH v4 11/21] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap

old_bits arg is currently a pointer to the input bits, but this could allow inadvertent changes to the input by the fn. Disallow this. And constify new_bits while here. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 21 +++-- 1 file changed, 11 insertions(+), 10

[PATCH v4 12/21] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code

Remove the NAMED class types; these 2 classmap types accept class names at the PARAM interface, for example: echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names The code works, but its only used by test-dynamic-debug, and wasn't asked for by anyone else, so simplify things

[PATCH v4 08/21] dyndbg: reduce verbose/debug clutter

currently, for verbose=3, these are logged (blank lines for clarity): dyndbg: query 0: "class DRM_UT_CORE +p" mod:* dyndbg: split into words: "class" "DRM_UT_CORE" "+p" dyndbg: op='+' dyndbg: flags=0x1 dyndbg: *flagsp=0x1 *maskp=0x dyndbg: parsed: func="" file="" module=""

[PATCH v4 10/21] dyndbg: tighten ddebug_class_name() 1st arg type

Change function's 1st arg-type, and deref in the caller. The fn doesn't need any other fields in the struct. no functional change. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/dynamic_debug.c

[PATCH v4 09/21] dyndbg: silence debugs with no-change updates

check for actual changes before announcing them, declutter logs. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 2a5cbb68d88d..a8973d1a6896 100644 ---

[PATCH v4 05/21] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it

Add query_module param to ddebug_apply_class_bitmap(). This allows its caller to update just one module, or all (as currently). We'll use this later to propagate drm.debug to each USEr as they're modprobed. No functional change. Signed-off-by: Jim Cromie --- after `modprobe i915`, heres the

[PATCH v4 07/21] dyndbg: drop NUM_TYPE_ARRAY

ARRAY_SIZE works here, since array decl is complete. no functional change Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index

[PATCH v4 06/21] dyndbg: split param_set_dyndbg_classes to module/wrapper fns

rename param_set_dyndbg_classes: add _module_ name & arg, old name is wrapper to new. New arg allows caller to specify that only one module is affected by a prdbgs update. Outer fn preserves kernel_param interface, passing NULL to inner fn. This selectivity will be used later to narrow the scope

[PATCH v4 03/21] dyndbg: make ddebug_class_param union members same size

struct ddebug_class_param keeps a ref to the state-storage of the param, make both flavors use the same unsigned long under-type. ISTM this is simpler and safer. Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 2 +- lib/dynamic_debug.c | 2 +- 2 files changed, 2

[PATCH v4 04/21] dyndbg: replace classmap list with a vector

Classmaps are stored/linked in a section/array, but are each added to the module's ddebug_table.maps list-head. This is unnecessary; even when ddebug_attach_classmap() is handling the builtin section (with classmaps for multiple builtin modules), its contents are ordered, so a module's possibly

[PATCH v4 02/21] test-dyndbg: fixup CLASSMAP usage error

more careful reading of test output reveals: lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing categories\n" lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" class:MID lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI

[PATCH v4 01/21] drm: use correct ccflags-y syntax

Incorrect CFLAGS- usage failed to add -DDYNAMIC_DEBUG_MODULE, which broke builds with: CONFIG_DRM_USE_DYNAMIC_DEBUG=y CONFIG_DYNAMIC_DEBUG_CORE=y but without DYNAMIC_DEBUG Nobody noticed because a larger regression emerged. Also add subdir-ccflags so that all drivers pick up the addition.

[PATCH v4 00/21] fix DRM_USE_DYNAMIC_DEBUG regression

hi Jason, Daniel, Greg, etal Heres another run at the regression, adequately explained in V3 here: https://lore.kernel.org/lkml/20230125203743.564009-1-jim.cro...@gmail.com/ https://patchwork.freedesktop.org/series/113363/ V3 exposed an init-ordering issue with jump-label, fixed by Jason with

Re: [PATCH v2 18/18] fbdev: Document that framebuffer_alloc() returns zero'ed data

On 7/13/23 06:21, Miguel Ojeda wrote: > On Thu, Jul 13, 2023 at 3:03 PM Thomas Zimmermann wrote: >> >> Most fbdev drivers depend on framebuffer_alloc() to initialize the >> allocated memory to 0. Document this guarantee. >> >> Suggested-by: Miguel Ojeda >> Signed-off-by: Thomas Zimmermann >>

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

Hi Am 13.07.23 um 16:41 schrieb Sean Paul: On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König wrote: hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: I'd really prefer this patch (series or single) is not accepted. This will cause problems for everyone cherry-picking

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

On Thu, Jul 13, 2023 at 04:14:55PM +0100, Tvrtko Ursulin wrote: > > On 13/07/2023 16:09, Thomas Zimmermann wrote: > > Hi > > > > Am 13.07.23 um 16:41 schrieb Sean Paul: > > > On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König > > > wrote: > > > > > > > > hello Sean, > > > > > > > > On Wed, Jul

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

On Thu, Jul 13, 2023 at 10:41:45AM -0400, Sean Paul wrote: > On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König > > But even with the one-patch-per-rename approach I'd consider the > > renaming a net win, because ease of understanding code has a big value. > > It's value is not so easy measurable as

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

On 13/07/2023 16:09, Thomas Zimmermann wrote: Hi Am 13.07.23 um 16:41 schrieb Sean Paul: On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König wrote: hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: I'd really prefer this patch (series or single) is not accepted. This

Re: [PATCH Review V2 2/2] drm/amdgpu: Disable RAS by default on APU flatform

On 2023-07-13 10:50, Stanley.Yang wrote: Disable RAS feature by default for aqua vanjaram on APU platform. Changed from V1: Splite Disable RAS by default on APU platform into a separated patch. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang ---

[PATCH Review V2 2/2] drm/amdgpu: Disable RAS by default on APU flatform

Disable RAS feature by default for aqua vanjaram on APU platform. Changed from V1: Splite Disable RAS by default on APU platform into a separated patch. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 + 1 file

[PATCH Review V2 1/2] drm/amdgpu: Enable aqua vanjaram RAS

Enable RAS for aqua vanjaram. Changed from V1: Split the change in amdgpu_ras_asic_supported into a separated patch. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König wrote: > > hello Sean, > > On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > > I'd really prefer this patch (series or single) is not accepted. This > > will cause problems for everyone cherry-picking patches to a > > downstream kernel

RE: [PATCH 2/2] drm/amdgpu/pm: make mclk consistent for smu 13.0.7

[AMD Official Use Only - General] Reviewed-by: Kenneth Feng -Original Message- From: amd-gfx On Behalf Of Alex Deucher Sent: Thursday, July 13, 2023 10:33 PM To: Deucher, Alexander Cc: amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 2/2] drm/amdgpu/pm: make mclk consistent for smu

Re: [PATCH 2/2] drm/amdgpu/pm: make mclk consistent for smu 13.0.7

Ping on this series? Alex On Tue, Jun 13, 2023 at 12:42 PM Alex Deucher wrote: > > Use current uclk to be consistent with other dGPUs. > > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [PATCH v2 08/18] sh: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flag

Hi Thomas! On Thu, 2023-07-13 at 15:53 +0200, John Paul Adrian Glaubitz wrote: > On Thu, 2023-07-13 at 14:58 +0200, Thomas Zimmermann wrote: > > Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of > > FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change. > > > >

Re: [PATCH v2 08/18] sh: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flag

On Thu, 2023-07-13 at 14:58 +0200, Thomas Zimmermann wrote: > Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of > FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change. > > FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info. > Flags for videomodes are

Re: [PATCH] Revert "drm/amdgpu: enable mcbp by default on gfx9"

On Wed, Jul 12, 2023 at 2:47 PM Alex Deucher wrote: > > This reverts commit 50a7c8765ca69543ffdbf855de0fd69aea769ccf. > > This breaks some SQA tests on gfx9 dGPUs. Chistian > also reported problems. Apparently this is a bug in mesa which this change uncovered:

Re: [PATCH v2 18/18] fbdev: Document that framebuffer_alloc() returns zero'ed data

On Thu, Jul 13, 2023 at 3:03 PM Thomas Zimmermann wrote: > > Most fbdev drivers depend on framebuffer_alloc() to initialize the > allocated memory to 0. Document this guarantee. > > Suggested-by: Miguel Ojeda > Signed-off-by: Thomas Zimmermann > Cc: Helge Deller Thanks for sending this! Maybe

Re: [PATCH] drm/amdgpu: Avoid possiblity of kernel crash in 'gmc_v8_0, gmc_v7_0_init_microcode()'

On Thu, Jul 13, 2023 at 9:20 AM Srinivasan Shanmugam wrote: > > If the function 'gmc_v8_0_ or gmc_v7_0_init_microcode()' fails, the > driver will just fail to load, hence return -EINVAL rather having BUG(), > fixes WARNING: Do not crash the kernel unless it is absolutely > unavoidable--use

[PATCH] drm/amdgpu: Avoid possiblity of kernel crash in 'gmc_v8_0, gmc_v7_0_init_microcode()'

If the function 'gmc_v8_0_ or gmc_v7_0_init_microcode()' fails, the driver will just fail to load, hence return -EINVAL rather having BUG(), fixes WARNING: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

On Thu, Jul 13, 2023 at 08:52:12AM +0200, Geert Uytterhoeven wrote: > Hi Uwe, > > Let's add some fuel to keep the thread alive ;-) > > On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König > wrote: > > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote: > > > I think this is an unnecessary

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

On Thu, Jul 13, 2023 at 12:03:05PM +0300, Jani Nikula wrote: > On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > > Hello Jani, > > > > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote: > >> On Wed, 12 Jul 2023, Uwe Kleine-König > >> wrote: > >> > Hello, > >> > > >> > while I debugged an

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > Hello Jani, > > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote: >> On Wed, 12 Jul 2023, Uwe Kleine-König wrote: >> > Hello, >> > >> > while I debugged an issue in the imx-lcdc driver I was constantly >> > irritated about struct

[PATCH v4 05/11] drm/amdgpu: Use RMW accessors for changing LNKCTL

Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. And in the case of upstream bridge, the driver does not even own the device it's changing the registers for. Use RMW capability accessors which do proper

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

Hi Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. Rather than renaming dev in all

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

Hi Jani, On Thu, Jul 13, 2023 at 11:03 AM Jani Nikula wrote: > On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote: > >> On Wed, 12 Jul 2023, Uwe Kleine-König > >> wrote: > >> > while I debugged an issue in the imx-lcdc driver I was

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

Hi Am 12.07.23 um 20:31 schrieb Sean Paul: On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula wrote: On Wed, 12 Jul 2023, Uwe Kleine-König wrote: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev"

[PATCH v4 06/11] drm/radeon: Use RMW accessors for changing LNKCTL

Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. And in the case of upstream bridge, the driver does not even own the device it's changing the registers for. Use RMW capability accessors which do proper

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

Hi Am 12.07.23 um 18:10 schrieb Uwe Kleine-König: Hello Jani, On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote: On Wed, 12 Jul 2023, Uwe Kleine-König wrote: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer

[PATCH v2 13/18] fbdev: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit

[PATCH v2 18/18] fbdev: Document that framebuffer_alloc() returns zero'ed data

Most fbdev drivers depend on framebuffer_alloc() to initialize the allocated memory to 0. Document this guarantee. Suggested-by: Miguel Ojeda Signed-off-by: Thomas Zimmermann Cc: Helge Deller --- drivers/video/fbdev/core/fb_info.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH v2 17/18] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT

Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No functional changes. Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Helge Deller --- include/linux/fb.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/linux/fb.h b/include/linux/fb.h index

[PATCH v2 16/18] fbdev/pxafb: Remove flag FBINFO_FLAG_DEFAULT

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix

[PATCH v2 14/18] fbdev: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: *

[PATCH v2 11/18] media: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit

[PATCH v2 06/18] fbdev/fsl-diu-fb: Remove flag FBINFO_DEFAULT

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2:

[PATCH v2 15/18] fbdev/atafb: Remove flag FBINFO_FLAG_DEFAULT

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by a static declaration. So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: *

[PATCH v2 02/18] fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by a static declaration. So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix

[PATCH v2 09/18] auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: *

[PATCH v2 07/18] vfio-mdev: Remove flag FBINFO_DEFAULT from fbdev sample driver

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix

[PATCH v2 12/18] staging: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: *

[PATCH v2 10/18] hid/picolcd: Remove flag FBINFO_FLAG_DEFAULT from fbdev driver

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: *

[PATCH v2 05/18] fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix

[PATCH v2 08/18] sh: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flag

Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change. FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info. Flags for videomodes are prefixed with FB_MODE_. v2: * assign FB_MODE_IS_UNKNOWN

[PATCH v2 04/18] fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit

[PATCH v2 03/18] fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit

[PATCH v2 01/18] drm: Remove flag FBINFO_DEFAULT from fbdev emulation

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix

[PATCH v2 00/18] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags

Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from fbdev and drivers, as briefly discussed at [1]. Both flags were maybe useful when fbdev had special handling for driver modules. With commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0 and have no further effect.

[PATCH] drm/amdgpu: load sdma ucode in the guest machine

Load the sdma ucode in the guest machine CHIP_NAVI12 and CHIP_SIENNA_CICHLID, so that the guest can check the version of current sdma ucode. It is used to support KFDTopologyTest.BasicTest, which need use the sdma ucode version to see whether the sdma engine support a new type of package (Barrier

Re: [PATCH v5 6/6] drm/doc: Define KMS atomic state set

On Tue, 11 Jul 2023 10:57:57 +0200 Daniel Vetter wrote: > On Fri, Jul 07, 2023 at 07:40:59PM -0300, André Almeida wrote: > > From: Pekka Paalanen > > > > Specify how the atomic state is maintained between userspace and > > kernel, plus the special case for async flips. > > > > Signed-off-by:

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

Hi Uwe, Let's add some fuel to keep the thread alive ;-) On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König wrote: > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote: > > On Wed, 12 Jul 2023, Uwe Kleine-König > > wrote: > > > Hello, > > > > > > while I debugged an issue in the