Reviewed-by: Xiaogang Chen
Regards
Xiaogang
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Instead of attaching the eviction fence when a KFD BO is first mapped,
attach it when it is allocated or imported. This in preparation to allow
KFD BOs to be mapped using the render node API.
Acked-by: Xiaogang Chen
Regards
Xiaogang
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Let amdgpu_vm_handle_moved update all BO VA mappings of BOs reserved by
the caller. This will be useful for handling extra BO VA mappings in
KFD VMs that are managed through the render node API.
Reviewed-by: Xiaogang Chen
Regards
Xiaogang
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Exports a DMA buf fd of a given KFD buffer handle. This is intended for
being able to import KFD BOs into GEM contexts to leverage the
amdgpu_bo_va API for more flexible virtual address mappings. It
The amdgpu driver tries to use fields not supported by UML's cpuinfo
struct. Disable the driver when targeting UML to avoid tripping up
allyesconfig.
e.g.
../drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c: In function
‘intel_core_rkl_chk’:
From: Vitaly Prosyak
Revert the following change: move drm_dev_unplug call after
amdgpu_driver_unload_kms in amdgpu_pci_remove.
The reason is following: amdgpu_pci_remove calls drm_dev_unregister
and it should be called first to ensure userspace can't access the
device instance anymore. If we
On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
>
> Cc: intel-gfx, drm maintainers
>
> Please have the courtesy of Cc'ing us for changes impacting us, and
> maybe try to involve us earlier instead of surprising us like
> this. Looks like this has been debugged for at least three
sriov does not need to init pptable from amdgpu driver
we finish it from PF
Signed-off-by: Jane Jian
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
Am 12.01.23 um 17:59 schrieb Pierre-Eric Pelloux-Prayer:
This allows to correlate the infos printed by
/sys/kernel/debug/dri/n/amdgpu_gem_info to the ones found
in /proc/.../fdinfo and /sys/kernel/debug/dma_buf/bufinfo.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Christian König
Cc: intel-gfx, drm maintainers
Please have the courtesy of Cc'ing us for changes impacting us, and
maybe try to involve us earlier instead of surprising us like
this. Looks like this has been debugged for at least three months, and
the huge revert at this point is going to set us back with
Am 13.01.23 um 06:34 schrieb Ma Jun:
Check the ttm_debugfs_root before creating files under it.
If the ttm_debugfs_root is NULL, all the files created for
ttm/ will be placed in the /sys/kerne/debug/ but not
/sys/kernel/debug/ttm/
Well NAK for upstreaming. Why should ttm_debugfs_root be NULL
Am 13.01.23 um 06:34 schrieb Ma Jun:
Use debugfs_remove_recursive to remove the /sys/kernel/debug/ttm
directory for better compatibility. Becuase debugfs_remove fails
on older kernel.
Again NAK for upstreaming.
The upstream kernel is made for the newest kernel version and should not
contain
Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on vmwgfx's inside
helpers.
Therefore, remove the redundant framebuffer format check from the
vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_bo()
functions, letting
This series is a follow-up of the [1] in which I introduced a check for valid
formats on drm_gem_fb_create(). During the discussion, I realized that would be
a better idea to put the check inside framebuffer_check() so that it wouldn't be
needed to hit any driver-specific code path when the check
Currently, framebuffer_check() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on framebuffer_check(), so that the ADDFB2 IOCTL rejects
calls with invalid
Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on amdgpu's inside
helpers.
Therefore, remove the redundant framebuffer format check from the
amdgpu_display_gem_fb_verify_and_init() function, letting
framebuffer_check() perform the
Am 13.01.23 um 11:36 schrieb Maxime Ripard:
On Mon, Jan 09, 2023 at 11:12:38AM +0100, Thomas Zimmermann wrote:
Remove unnecessary include statements for . I recently
changed this header and had to rebuild a good part of DRM. So avoid
this by removing the dependency.
Some source files require
On Fri, Jan 13, 2023 at 08:27:42AM -0300, Maíra Canal wrote:
> Currently, framebuffer_check() doesn't check if the pixel format is
> supported, which can lead to the acceptance of invalid pixel formats
> e.g. the acceptance of invalid modifiers. Therefore, add a check for
> valid formats on
Looks like Sasha picked it up again for some reason. I'll revert that on 6.1.x.
Alex
On Fri, Jan 13, 2023 at 1:02 AM Yury Zhuravlev wrote:
>
> Yes, this is right in 6.2-rc3
>
>
Reviewed-by: Alex Deucher
On Thu, Jan 12, 2023 at 9:11 PM Liu, Aaron wrote:
>
> Reviewed-by: Aaron Liu aaron@amd.com
>
>
>
> From: amd-gfx On Behalf Of Zhang,
> Jesse(Jie)
> Sent: Friday, January 13, 2023 10:07 AM
> To: Deucher, Alexander
> Cc: amd-gfx@lists.freedesktop.org
> Subject:
On Fri, Jan 13, 2023 at 9:47 AM Braiam wrote:
>
> Hi,
>
> I have two monitors with the current following configuration:
>
> Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
> DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
> right x axis y axis) 597mm x
Am 13.01.23 um 11:35 schrieb Braiam:
Hi,
I have two monitors with the current following configuration:
Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
right x axis y axis) 597mm x 336mm
2560x1440
Hi Ville,
On Wed, Jan 11, 2023 at 06:08:42PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 11, 2023 at 02:01:58PM +0100, Thomas Zimmermann wrote:
> > Include in source files that need it. Some of DRM's
> > source code gets OF header via drm_crtc_helper.h and ,
> > which can leed to unnecessary
Hi
Am 13.01.23 um 16:09 schrieb Sam Ravnborg:
Hi Thomas,
On Wed, Jan 11, 2023 at 02:01:57PM +0100, Thomas Zimmermann wrote:
Include in source files that need it. Some of
DRM's source code gets the backlight header via drm_crtc_helper.h
and , which can leed to unnecessary recompilation. If
The EDID of an HDR display defines EOTFs that are supported
by the display and can be set in the HDR metadata infoframe.
Userspace is expected to read the EDID and set an appropriate
HDR_OUTPUT_METADATA.
In drm_parse_hdr_metadata_block the kernel reads the supported
EOTFs from the EDID and stores
This is useful to understand the bpc defaults and
support of a driver.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-de...@lists.freedesktop.org
Cc:
This patchset enables the DP and HDMI infoframe properties
in amdgpu.
The first two patches are not completely related to the rest. The
first patch allows for HDR_OUTPUT_METADATA with EOTFs that are
unknown in the kernel.
The second one prints a connector's max_bpc as part of the atomic
state
We need to signal mode_changed to make sure we update the output
colorspace.
v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
own infoframe packing.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc:
Look at connector->colorimetry to determine output colorspace.
We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc:
We use this by default but if userspace passes this explicitly
we should respect it.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua
On Fri, Jan 13, 2023 at 5:56 AM Jane Jian wrote:
>
> sriov does not need to init pptable from amdgpu driver
> we finish it from PF
>
> Signed-off-by: Jane Jian
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
This tab was deleted accidentally and triggers a Smatch warning:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:1006 gfx_v8_0_init_microcode()
warn: inconsistent indenting
Add it back.
Fixes: 0aaafb7359d2 ("drm/amd: Use `amdgpu_ucode_*` helpers for GFX8")
Signed-off-by: Dan Carpenter
---
On Mon, Jan 09, 2023 at 11:12:38AM +0100, Thomas Zimmermann wrote:
> Remove unnecessary include statements for . I recently
> changed this header and had to rebuild a good part of DRM. So avoid
> this by removing the dependency.
>
> Some source files require the OF or backlight headers. Include
Hi,
I have two monitors with the current following configuration:
Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
right x axis y axis) 597mm x 336mm
2560x1440164.83 + 59.95 + 120.05* 96.01
On Fri, Jan 13, 2023 at 4:44 AM wrote:
>
> From: Vitaly Prosyak
>
> Revert the following change: move drm_dev_unplug call after
> amdgpu_driver_unload_kms in amdgpu_pci_remove.
> The reason is following: amdgpu_pci_remove calls drm_dev_unregister
> and it should be called first to ensure
On Fri, Jan 13, 2023 at 04:11:48PM +0100, Sam Ravnborg wrote:
> Hi Ville,
> On Wed, Jan 11, 2023 at 06:08:42PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 11, 2023 at 02:01:58PM +0100, Thomas Zimmermann wrote:
> > > Include in source files that need it. Some of DRM's
> > > source code gets OF
From: Joshua Ashton
Code in get_output_color_space depends on knowing the pixel encoding to
determine whether to pick between eg. COLOR_SPACE_SRGB or
COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka
Format the input and output CSC matrix so they
look like 3x4 matrixes. This will make parsing them
much easier and allows us to quickly spot potential
mistakes.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc:
This will let us pass the kms_hdr.bpc_switch IGT
test.
The reason the bpc restriction was required is
historical. At one point in time we were not falling
back to a lower bpc when we didn't have enough
bandwidth for the maximum bpc reported by a display.
This meant that we couldn't enable some
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++-
1 file
On Fri, Jan 13, 2023 at 10:05 AM Braiam wrote:
>
> AMD RX 590. Forgot to include it. How do I know the blanking period?
OK polaris falls into the first bucket. Look at the full modelines.
E.g., xrandr --verbose.
> Would variable refresh rate mess up with that?
Probably.
Alex
>
> On Fri, Jan
AMD RX 590. Forgot to include it. How do I know the blanking period?
Would variable refresh rate mess up with that?
On Fri, Jan 13, 2023 at 10:57 AM Alex Deucher wrote:
>
> On Fri, Jan 13, 2023 at 9:47 AM Braiam wrote:
> >
> > Hi,
> >
> > I have two monitors with the current following
Hi Thomas.
On Wed, Jan 11, 2023 at 02:01:56PM +0100, Thomas Zimmermann wrote:
> Remove unnecessary include statements for . I recently
> changed this header and had to rebuild a good part of DRM. So avoid
> this by removing the dependency.
>
> Several files include via drm_fb_helper.h. So in v2
Am 13.01.23 um 16:09 schrieb Alex Deucher:
On Fri, Jan 13, 2023 at 10:05 AM Braiam wrote:
AMD RX 590. Forgot to include it. How do I know the blanking period?
OK polaris falls into the first bucket. Look at the full modelines.
E.g., xrandr --verbose.
Would variable refresh rate mess up
Hi Thomas,
On Wed, Jan 11, 2023 at 02:01:57PM +0100, Thomas Zimmermann wrote:
> Include in source files that need it. Some of
> DRM's source code gets the backlight header via drm_crtc_helper.h
> and , which can leed to unnecessary recompilation. If
> possible, do not include drm_crtc_helper.h
On Wed, Jan 11, 2023 at 02:02:01PM +0100, Thomas Zimmermann wrote:
> Remove unnecessary include statements for . No functional
> changes. Include where the driver got the header file via
> .
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
>
On 1/13/23 05:25, Daniel Vetter wrote:
> On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
>>
>> Cc: intel-gfx, drm maintainers
>>
>> Please have the courtesy of Cc'ing us for changes impacting us, and
>> maybe try to involve us earlier instead of surprising us like
>> this. Looks
The value is the same as DEFAULT. The HDMI_COLORIMETRY_NO_DATA
makes sense for the infopacket but it's meaningless for the
connector colorspace. or, in otherwise, just means to go with
driver default.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc:
From: Joshua Ashton
Given that we always pass dm_state into here now, this won't ever
trigger anymore.
This is needed for we will always fail mode validation with invalid
clocks or link bandwidth errors.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc:
In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.
This might also come in handy when debugging display
issues.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc:
From: Joshua Ashton
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Harry Wentland
---
From: Joshua Ashton
Replace the messy two if-else chains here that were
on the same value with a switch on the enum.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc:
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc:
This allows us to use strongly typed arguments.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton
---
v3: Fix kerneldocs (kernel test robot)
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By:
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Drivers might not support all colorspaces defined in
dp_colorspaces and hdmi_colorspaces. This results in
undefined behavior when userspace is setting an
unsupported colorspace.
Allow drivers to pass the list of supported colorspaces
when creating the colorspace property.
v2:
- Use 0 to
From: Joshua Ashton
Userspace might not aware whether we're sending RGB or YCbCr
data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is
requested but the output encoding is YCbCr we should
send COLOR_SPACE_2020_YCBCR.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka
We need to reset this or otherwise run into list corruption later on./
Fixes: 16be3e9f6f03 ("drm/amdgpu: rework reserved VMID handling")
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Friday, January 13th, 2023 at 17:59, Maíra Canal wrote:
> + /* Verify that the modifier is supported. */
> + if (r->modifier[0] && drm_drv_uses_atomic_modeset(dev) &&
> + !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
> + drm_dbg_kms(dev,
On Fri, Jan 13, 2023 at 11:35 AM Christian König
wrote:
>
> We need to reset this or otherwise run into list corruption later on./
Drop the / above.
Reviewed-by: Alex Deucher
>
> Fixes: 16be3e9f6f03 ("drm/amdgpu: rework reserved VMID handling")
> Signed-off-by: Christian König
> ---
>
Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on amdgpu's inside
helpers.
Therefore, remove the redundant framebuffer format check from the
amdgpu_display_gem_fb_verify_and_init() function, letting
framebuffer_check() perform the
Currently, framebuffer_check() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on framebuffer_check(), so that the ADDFB2 IOCTL rejects
calls with invalid
This series is a follow-up of the [1] in which I introduced a check for valid
formats on drm_gem_fb_create(). During the discussion, I realized that would be
a better idea to put the check inside framebuffer_check() so that it wouldn't be
needed to hit any driver-specific code path when the check
Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on vmwgfx's inside
helpers.
Therefore, remove the redundant framebuffer format check from the
vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_bo()
functions, letting
Hm, unfortunately I think we need to keep the check in amdgpu for the
same reason as i915: amdgpu will pick a modifier if user-space didn't
supply one on GFX9+.
I wonder if that also applies to vmwgfx? Maybe that would be a reason
to have the check in framebuffer_init()? (Not sure!)
On 1/13/23 14:06, Simon Ser wrote:
Hm, unfortunately I think we need to keep the check in amdgpu for the
same reason as i915: amdgpu will pick a modifier if user-space didn't
supply one on GFX9+.
I wonder if that also applies to vmwgfx? Maybe that would be a reason
to have the check in
On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter wrote:
>
> On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > Hi everyone,
> >
> > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> >
> > Regression is due to a chicken-egg problem loading modules; on
> > `modprobe i915`, drm is loaded
On Fri, Jan 13, 2023 at 11:29:57AM -0700, jim.cro...@gmail.com wrote:
> On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter wrote:
> >
> > On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > > Hi everyone,
> > >
> > > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> > >
> > > Regression
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
DECLARE_DYNDBG_CLASSMAP's job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf. Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap). Modules wanting a drm.debug
style knob need
Drop macro args after _var. Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward. Keep only the _var arg, which is the extern'd struct
classmap with all the class info.
Signed-off-by: Jim Cromie
---
Split param_set_dyndbg_classes() to interface-preserving wrapper &
inner function with an additional param: mod_name, which is passed
into ddebug_apply_class_bitmap() to allow adjusting a single module's
prdbgs. Wrapper passes NULL, preserving current behavior for now.
no functional change.
currently, for verbose=3, this is logged:
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="" format="" lineno=0-0
Change function's 1st arg-type, by derefing in the caller.
The fn doesnt need any other fields in the old type.
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
ddebug_apply_class_bitmap() does not alter its 2 bitmap args, make
this guarantee in the interface.
NOTE: the bitmap is also available in the dcp arg, but the 2 vars
serve a 2nd purpose; the CLASS_TYPE callers use them to translate
levels into their underlying disjoint representation.
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE, lets differentiate
them according to their separate jobs.
Dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
.
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the
Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined. Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:
[ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[ 15.293189] dyndbg: 32 debug prints in
ARRAY_SIZE works here, since array decl is complete.
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 bf47bcfad8e6..81b643ab7f6e 100644
---
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
ddebug_apply_class_bitmap() currently applies the class settings to
all modules, by calling ddebug_exec_queries(query, NULL), where NULL
is wildcard ("*" does the same). Make it more selective, by adding
query_module param, and passing it into ddebug_exec_queries, instead
of the NULL.
This
On 2023-01-12 16:18, Philip Yang wrote:
Update queue qpd is done for the first queue creation of the process,
if the device support XNACK mode per process, update qpd setup
sh_mem_config based on the process XNACK mode, to support the process
destory all queues, change XNACK mode, and then
Hi everyone,
DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in drivers
It is due to a chicken-egg problem loading modules; on `modprobe
i915`, drm is loaded 1st, and drm/parameters/debug is set. When
drm_debug_enabled() tested it at runtime, things just worked.
But with
On Fri, Jan 13, 2023 at 4:02 PM Marek Olšák wrote:
>
> i've added the comments and indeed pahole shows the hole as expected.
What about on 32-bit?
Alex
>
> Marek
>
> On Thu, Jan 12, 2023 at 11:44 AM Alex Deucher wrote:
>>
>> On Thu, Jan 12, 2023 at 6:50 AM Christian König
>> wrote:
>> >
>> >
The existing codebase never had a case for detecting MP0 version on
Renoir and instead relied upon hardcoded chip name. This was missed as
part of the changes to migrate all IP blocks to build filenames from
`amdgpu_ucode.c`.
Consequently, Renoir tries to fetch a binary with 11_0_3 in the
On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote:
> On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
> >
> > Cc: intel-gfx, drm maintainers
> >
> > Please have the courtesy of Cc'ing us for changes impacting us, and
> > maybe try to involve us earlier instead of surprising us
On 1/13/2023 13:28, Lyude Paul wrote:
On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote:
On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
Cc: intel-gfx, drm maintainers
Please have the courtesy of Cc'ing us for changes impacting us, and
maybe try to involve us earlier
On 2023-01-13 18:00, Chen, Xiaogang wrote:
On 1/13/2023 4:26 PM, Felix Kuehling wrote:
On 2023-01-12 17:41, Chen, Xiaogang wrote:
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable
Applied. Thanks!
Alex
On Fri, Jan 13, 2023 at 9:46 AM Dan Carpenter wrote:
>
> This tab was deleted accidentally and triggers a Smatch warning:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:1006 gfx_v8_0_init_microcode()
> warn: inconsistent indenting
>
> Add it back.
>
> Fixes:
i've added the comments and indeed pahole shows the hole as expected.
Marek
On Thu, Jan 12, 2023 at 11:44 AM Alex Deucher wrote:
> On Thu, Jan 12, 2023 at 6:50 AM Christian König
> wrote:
> >
> > Am 11.01.23 um 21:48 schrieb Alex Deucher:
> > > On Wed, Jan 4, 2023 at 3:17 PM Marek Olšák
On 2023-01-12 17:41, Chen, Xiaogang wrote:
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying
Reviewed-by: Xiaogang Chen
Regards
Xiaogang
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
This is needed to correctly handle BOs imported into the GEM API, which
would otherwise get added twice to the same VM.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
Valve would like this in kernel 6.2, but if put it there, we also need to
backport INFO ioctl changes for DRM driver version 3.50.0.
Marek
On Fri, Jan 13, 2023 at 6:33 PM Marek Olšák wrote:
> There is no hole on 32-bit unfortunately. It looks like the hole on 64-bit
> is now ABI.
>
> I moved
Can someone review this patch (2/2)? 1/2 is superseded by Jesse's
patch, but this one still makes sense.
Thanks
On Thu, Jan 12, 2023 at 11:25 AM Alex Deucher wrote:
>
> Power reporting is socket power. On APUs this includes
> the CPU. Update the documentation to clarify this.
>
>
Reviewed-by: Xiaogang Chen
Regards
Xiaogang
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
When restoring after an eviction, use amdgpu_vm_handle_moved to update
BO VA mappings in KFD VMs that are not managed through the KFD API. This
should allow using the render node API to create more
On 1/13/2023 4:26 PM, Felix Kuehling wrote:
On 2023-01-12 17:41, Chen, Xiaogang wrote:
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs
There is no hole on 32-bit unfortunately. It looks like the hole on 64-bit
is now ABI.
I moved the field to replace _pad1. The patch is attached (with your Rb).
Marek
On Fri, Jan 13, 2023 at 4:20 PM Alex Deucher wrote:
> On Fri, Jan 13, 2023 at 4:02 PM Marek Olšák wrote:
> >
> > i've added
__jump_label_patch currently will "crash the box" if it finds a
jump_entry not as expected. ISTM this overly harsh; it doesn't
distinguish between "alternate/opposite" state, and truly
"insane/corrupted".
The "opposite" (but well-formed) state is a milder mis-initialization
problem, and some
lib/test_dynamic_debug.c is used to build 2 modules:
test_dynamic_debug.ko and test_dynamic_debug_submod.ko
Define DEBUG only in the main module, not in the submod. Its purpose
is to insure that prdbgs are enabled by default, so that a modprobe
without params actually logs something, showing
1 - 100 of 107 matches
Mail list logo
