Hi,
Le 14/05/2025 à 14:44, Philipp Stanner a écrit :
On Thu, 2025-04-24 at 10:38 +0200, Pierre-Eric Pelloux-Prayer wrote:
This will be used in a later commit to trace the drm client_id in
some of the gpu_scheduler trace events.
This requires changing all the users of drm_sched_job_init to
add
On 5/14/2025 4:35 PM, Pratap Nirujogi wrote:
ISP is a child device to GFX, and its device specific information
is not available in ACPI. Adding the 2 GPIO resources required for
ISP_v4_1_1 in amdgpu_isp driver.
- GPIO 0 to allow sensor driver to enable and disable sensor module.
- GPIO 85 to all
ISP is a child device to GFX, and its device specific information
is not available in ACPI. Adding the 2 GPIO resources required for
ISP_v4_1_1 in amdgpu_isp driver.
- GPIO 0 to allow sensor driver to enable and disable sensor module.
- GPIO 85 to allow ISP driver to enable and disable ISP RGB str
On Wed, May 14, 2025 at 4:48 PM Leonardo Gomes
wrote:
>
> Adjust get_value function in hw_hpd.c file to have
> prefix to help in ftrace, the name change from
> 'get_value' to 'dal_hw_gpio_get_value'
This won't compile. dal_hw_gpio_get_value is already defined in
drivers/gpu/drm/amd/display/dc/gp
On 14/05/2025 17:19, Melissa Wen wrote:
Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains
edid info. It's a groundwork to get rid of raw edid stored as dc_edid.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
.../amd/display/
On Thu, 2025-04-24 at 10:38 +0200, Pierre-Eric Pelloux-Prayer wrote:
> This will be used in a later commit to trace the drm client_id in
> some of the gpu_scheduler trace events.
>
> This requires changing all the users of drm_sched_job_init to
> add an extra parameter.
>
> The newly added drm_cl
On Thu, 2025-04-24 at 10:38 +0200, Pierre-Eric Pelloux-Prayer wrote:
> Its only purpose was for trace events, but jobs can already be
> uniquely identified using their fence.
>
> The downside of using the fence is that it's only available
> after 'drm_sched_job_arm' was called which is true for al
Adjust get_value function in hw_hpd.c file to have
prefix to help in ftrace, the name change from
'get_value' to 'dal_hw_gpio_get_value'
Signed-off-by: Leonardo da Silva Gomes
Co-developed-by: Derick Frias
Signed-off-by: Derick Frias
---
drivers/gpu/drm/amd/display/dc/gpio/hw_hpd.c | 4 ++--
1
Adjust set_value function in hw_hpd.c file to have
prefix to help in ftrace, the name change from
'set_value' to 'dal_hw_gpio_set_value'
Signed-off-by: Leonardo da Silva Gomes
Co-developed-by: Derick Frias
Signed-off-by: Derick Frias
---
drivers/gpu/drm/amd/display/dc/gpio/hw_hpd.c | 4 ++--
1
On 25/05/13 11:20AM, Wayne Lin wrote:
> It's expected that we'll encounter temporary exceptions
> during aux transactions. Adjust logging from drm_info to
> drm_dbg_dp to prevent flooding with unnecessary log messages.
>
> Fixes: 6285f12bc54c ("drm/amd/display: Fix wrong handling for AUX_DEFER cas
On 5/13/25 21:51, Mario Limonciello wrote:
> On 5/13/2025 2:45 PM, Bjorn Helgaas wrote:
>> From Denis's report at https://bugzilla.kernel.org/show_bug.cgi?id=220110:
>>
>>> I am having problems with my laptop that has a thunderbolt
>>> controller to which I connected an AMD 6750XT.
>>>
>>> The t
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.c | 6 ++
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.h | 1 +
Reduce direct handling of edid data by resorting to drm helpers that
deal with this info inside drm_edid infrastructure.
v3:
- remove uneccessary include (jani)
- use dc_edid_sink_edid_free in link_detection
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +
AMD driver has a function used to compare if two edid are the same; this
is useful to some of the link detection algorithms implemented by
amdgpu. Since the amdgpu function can be helpful for other drivers, this
commit abstracts the AMD function to make it available at the DRM level
by wrapping exi
From: Rodrigo Siqueira
As part of the effort of stopping using raw edid, this commit move the
copy of the edid in DC to a dedicated function that will allow the usage
of drm_edid in the next steps.
v3:
- remove superfulous cast (jani)
Signed-off-by: Rodrigo Siqueira
Co-developer--by: Melissa W
There is an opaque obj in Linux/DRM to encapsulate edid data as
`drm_edid`. This obj isn't present in other platforms but we need to
pass it through DC when adding sink. To pass this data without
compromise the independence of DC code, make some DC functions accept
edid data as private options.
Si
From: Rodrigo Siqueira
Since DC is a shared code, this commit introduces a new file to work as
a mid-layer in DC for the edid manipulation.
v3:
- rebase on top of asdn
Signed-off-by: Rodrigo Siqueira
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_
Hi,
Siqueira and I have been working on a solution to reduce the usage of
drm_edid_raw in the AMD display driver, since the current guideline in
the DRM subsystem is to stop handling raw edid data in driver-specific
implementation and use opaque `drm_edid` object with common-code
helpers.
In shor
Original drm_edid_get_monitor_name encapsulates raw edid in drm_edid and
then call get_monitor_name. AMD still stores the display name for
debugging, but it is migrating to drm_edid, on the other hand,
drm_dp_mst_topology and sil-sii8620 still use the raw edid version.
Split drm_edid_get_monitor_n
Instead of using driver-specific code, use DRM helpers.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/d
drm_edid_connector_update() updates display info, filling ELD with audio
info from Short-Audio Descriptors in the last step of
update_dislay_info(). Our goal is stopping using raw edid, so we can
extract SAD from drm_eld instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
drm_edid_connector_update() updates display info, filling ELD with
speaker allocation data in the last step of update_dislay_info(). Our
goal is stopping using raw edid, so we can extract SADB from drm_eld
instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
.../drm/amd/d
Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains
edid info. It's a groundwork to get rid of raw edid stored as dc_edid.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 18 +++
Groundwork that allocates a temporary drm_edid from raw edid to take
advantage of DRM common-code helpers instead of driver-specific code.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c| 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
Since [1], we can use drm_edid_product_id to get debug info from
drm_edid instead of directly parsing EDID.
Link:
https://lore.kernel.org/dri-devel/cover.1712655867.git.jani.nik...@intel.com/
[1]
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15
Make sure the drm_edid container stored in aconnector is freed when
destroying the aconnector.
Fixes: 48edb2a4 ("drm/amd/display: switch amdgpu_dm_connector to use struct
drm_edid")
Reviewed-by: Mario Limonciello
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
From: Mario Limonciello
Normally resources are evicted on dGPUs at suspend or hibernate and
on APUs at hibernate. These steps are unnecessary when using the S4
callbacks to put the system into S5.
Cc: AceLan Kao
Cc: Kai-Heng Feng
Cc: Mark Pearson
Cc: Denis Benato
Cc: Merthan Karakaş
Signed
From: Mario Limonciello
For the suspend flow PCIe ports that have downstream devices are put into
the appropriate D3 state when children are not in D0. For the hibernate
flow, PCIe ports with downstream devices stay in D0 however. This can
lead to PCIe ports that are remained powered on needlessl
From: Mario Limonciello
A variety of issues both in function and in power consumption have been
raised as a result of devices not being put into a low power state when
the system is powered off.
There have been some localized changes[1] to PCI core to help these issues,
but they have had various
From: Mario Limonciello
When the system is powered off the kernel will call device_shutdown()
which will issue callbacks into PCI core to wake up a device and call
it's shutdown() callback. This will leave devices in ACPI D0 which can
cause some devices to misbehave with spurious wakeups and als
If the MEC firmware supports chaining runlists of XNACK+/XNACK-
processes, set SQ_CONFIG1 chicken bit and SET_RESOURCES bit 28.
When the MEC/HWS supports it, KFD checks the XNACK+/XNACK- processes mix
happens or not. If it does, enter over-subscription.
Signed-off-by: Amber Lin
Reviewed-by: Phil
Hi Dave, Simona,
Fixes for 6.15.
The following changes since commit 82f2b0b97b36ee3fcddf0f0780a9a0825d52fec3:
Linux 6.15-rc6 (2025-05-11 14:54:11 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.15-2025-05-14
for you to fe
On Wed, May 14, 2025 at 1:33 PM David (Ming Qiang) Wu wrote:
>
> Similar to the changes made for VCN v4.0.5, the addition of register
> read-back support in other VCN versions is intended to prevent potential
> race conditions, even though such issues have not been observed yet.
> This change ensu
On Wed, May 14, 2025 at 1:33 PM David (Ming Qiang) Wu wrote:
>
> Similar to the changes made for VCN v4.0.5, the addition of register
> read-back support in other VCN versions is intended to prevent potential
> race conditions, even though such issues have not been observed yet.
> This change ensu
[AMD Official Use Only - AMD Internal Distribution Only]
Only in start() ? what about stop(), pause() and etc?
Thanks,
Ruijing
-Original Message-
From: Wu, David
Sent: Wednesday, May 14, 2025 1:23 PM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
Cc: Koenig, Christian ; Liu, Le
hmm... I knew that - but I would rather add that in case
jpeg_v1_0_start() might change.
A little conservative ...
Thanks,
David
On 5/14/2025 1:33 PM, Dong, Ruijing wrote:
[AMD Official Use Only - AMD Internal Distribution Only]
This patch is not needed as it has the read-back in jpeg_v1_0_sta
[AMD Official Use Only - AMD Internal Distribution Only]
This patch is not needed as it has the read-back in jpeg_v1_0_start();
Thanks,
Ruijing
-Original Message-
From: Wu, David
Sent: Wednesday, May 14, 2025 1:23 PM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
Cc: Koenig, Ch
Reviewed-by: Arvind Yadav
On 5/14/2025 9:02 PM, Alex Deucher wrote:
On Sun, May 11, 2025 at 10:21 PM Prike Liang wrote:
Lock and refer to the eviction fence before the eviction fence
schedules work queue tries to signal it.
Suggested-by: Christian König
Signed-off-by: Prike Liang
Acked-by
The addition of register read-back in VCN v5.0.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c
b/drivers/g
The addition of register read-back in VCN v4.0.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/d
The addition of register read-back in VCN v2.5 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
b/drivers/gpu/drm
The addition of register read-back in VCN v5.0.1 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v5_0_1.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_1.c
b/drivers/gpu/drm/
The addition of register read-back in VCN v4.0.3 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c
b/drivers/gpu/drm/a
The addition of register read-back in VCN v2.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
b/drivers/gpu/dr
The addition of register read-back in VCN v3.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
b/drivers/gpu/drm
Similar to the changes made for VCN v4.0.5, the addition of register
read-back support in other VCN versions is intended to prevent potential
race conditions, even though such issues have not been observed yet.
This change ensures consistency across different VCN variants and helps
avoid similar is
The addition of register read-back in VCN v1.0 is intended to prevent
potential race conditions.
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm
Release pdd->drm_file may free the vm if this is the last reference,
move it to the last step after memory is unmapped.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkf
To unmap and free seq64 memory when drm node close to free vm, if there
is signal accepted, then taking vm lock failed and leaking seq64 va
mapping, and then dmesg has error log "still active bo inside vm".
Change to use uninterruptible lock fix the mapping leaking and no dmesg
error log.
Signed-
This series fix the dmesg error message "still active bo inside vm" and
2 potential races when process exit and vm cleanup.
Philip Yang (3):
drm/amdgpu: seq64 memory unmap uses uninterruptible lock
drm/amdgpu: amdgpu_vm_fini hold vm lock to access vm->va
drm/amdkfd: destroy_pdds release pdd-
Move vm root bo unreserve after vm->va mapping free because we should
hold vm lock to access vm->va.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers
On Wed, May 14, 2025 at 7:58 AM Tvrtko Ursulin
wrote:
>
>
> On 14/05/2025 14:57, Rob Clark wrote:
> > On Wed, May 14, 2025 at 3:01 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 13/05/2025 15:16, Rob Clark wrote:
> >>> On Fri, May 9, 2025 at 8:34 AM Tvrtko Ursulin
> >>> wrote:
>
> Dma
On Sun, May 11, 2025 at 10:21 PM Prike Liang wrote:
>
> Lock and refer to the eviction fence before the eviction fence
> schedules work queue tries to signal it.
>
> Suggested-by: Christian König
> Signed-off-by: Prike Liang
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ev
On 14/05/2025 14:57, Rob Clark wrote:
On Wed, May 14, 2025 at 3:01 AM Tvrtko Ursulin
wrote:
On 13/05/2025 15:16, Rob Clark wrote:
On Fri, May 9, 2025 at 8:34 AM Tvrtko Ursulin wrote:
Dma-fence objects currently suffer from a potential use after free problem
where fences exported to user
On 14/05/2025 14:50, Christian König wrote:
I'm going to push patches #1-#6 to drm-misc-next.
They make sense as a stand alone cleanups anyway.
Holding off for now because the 64 bit seqno flag needs a build fix. I
have it locally but was waiting for more feedback on the series.
> But tha
On Tue, May 13, 2025 at 9:53 PM wrote:
>
> From: "Dr. David Alan Gilbert"
>
> Free doorbells in the error paths of cik_init and in cik_fini.
>
> Build tested only.
>
> Suggested-by: Christophe JAILLET
> Signed-off-by: Dr. David Alan Gilbert
Applied. Thanks!
Alex
> ---
> RFC->v1
> Renamed
On Wed, May 14, 2025 at 3:24 AM George Anthony Vernon
wrote:
>
> The kerneldoc comment for HGCP locality check debug mask was missing a
> semicolon resulting in a documentation build warning. Correct it.
>
> Signed-off-by: George Anthony Vernon
Thanks for the patch, but this was already fixed.
On Wed, May 14, 2025 at 3:31 AM Abdelrahman Fekry
wrote:
>
> The DC_HDCP_LC_ENABLE_SW_FALLBACK enum comment was missing the required
> colon after the parameter name in its kernel-doc tag:
>
> * @DC_HDCP_LC_ENABLE_SW_FALLBACK If set, ...
>
> Kernel-doc insists on the form @name: description. Add
On Wed, May 14, 2025 at 3:01 AM Tvrtko Ursulin
wrote:
>
>
> On 13/05/2025 15:16, Rob Clark wrote:
> > On Fri, May 9, 2025 at 8:34 AM Tvrtko Ursulin
> > wrote:
> >>
> >> Dma-fence objects currently suffer from a potential use after free problem
> >> where fences exported to userspace and other dr
On 5/13/25 09:45, Tvrtko Ursulin wrote:
> Access the dma-fence internals via the previously added helpers.
>
> Drop the macro while at it, since the length is now more manageable.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
I'm going to push patches #1-#6 to drm-misc-next.
They make sense as a stand alone cleanups anyway.
But that here needs a bit more documentation I think.
On 5/13/25 09:45, Tvrtko Ursulin wrote:
> Dma-fence objects currently suffer from a potential use after free problem
> where fences exported t
Hi Philipp,
Did you get a chance to take a look at the latest revision of this series?
Thanks,
Pierre-Eric
Le 24/04/2025 à 10:38, Pierre-Eric Pelloux-Prayer a écrit :
Hi,
The initial goal of this series was to improve the drm and amdgpu
trace events to be able to expose more of the inner work
[AMD Official Use Only - AMD Internal Distribution Only]
Hi, @Koenig, Christian @Lazar, Lijo kindly pls provide your expertise for the
Sam's update below. Thanks for your support.
Rgds/Owen
-Original Message-
From: Samuel Zhang
Sent: Monday, May 12, 2025 2:42 PM
To: amd-gfx@lists.free
On 13/05/2025 15:16, Rob Clark wrote:
On Fri, May 9, 2025 at 8:34 AM Tvrtko Ursulin wrote:
Dma-fence objects currently suffer from a potential use after free problem
where fences exported to userspace and other drivers can outlive the
exporting driver, or the associated data structures.
The
On 5/14/25 10:19, Liang, Prike wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
>> From: Koenig, Christian
>> Sent: Wednesday, May 14, 2025 3:02 PM
>> To: Liang, Prike ; amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander
>> Subject: Re: [PATCH] drm/amdgpu: fix userq resou
On 12/05/2025 14:03, Philipp Stanner wrote:
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
There is no need to keep entities with no jobs in the tree so lets
remove
it once the last job is consumed. This keeps the tree smaller which
is
nicer and more efficient as entities are removed
On 12/05/2025 13:56, Philipp Stanner wrote:
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
To implement fair scheduling we will need as accurate as possible
view
into per entity GPU time utilisation. Because sched fence execution
time
are only adjusted for accuracy in the free worker
On 12/05/2025 13:53, Philipp Stanner wrote:
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
Reduce to one spin_unlock for hopefully a little bit clearer flow in
the
function. It may appear that there is a behavioural change with the
drm_sched_start_timeout_unlocked() now not being cal
On 12/05/2025 13:57, Matthew Brost wrote:
On Mon, May 12, 2025 at 02:49:55PM +0200, Philipp Stanner wrote:
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
Currently the job free work item will lock sched->job_list_lock first
time
to see if there are any jobs, free a single job, and t
On 12/05/2025 13:49, Philipp Stanner wrote:
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
Currently the job free work item will lock sched->job_list_lock first
time
to see if there are any jobs, free a single job, and then lock again
to
decide whether to re-queue itself if there are
[AMD Official Use Only - AMD Internal Distribution Only]
> From: Koenig, Christian
> Sent: Wednesday, May 14, 2025 3:02 PM
> To: Liang, Prike ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH] drm/amdgpu: fix userq resource double freed
>
> On 5/12/25 09:30, Prike Li
On 5/14/2025 12:53 PM, Lazar, Lijo wrote:
>
>
> On 5/14/2025 11:51 AM, Shiwu Zhang wrote:
>> Expose the debugfs file node for user space to dump the IFWI image
>> on spirom.
>>
>> For one transaction between PSP and host, it will read out the
>> images on both active and inactive partitions so
On 5/14/2025 12:55 PM, Lazar, Lijo wrote:
>
>
> On 5/14/2025 12:53 PM, Lazar, Lijo wrote:
>>
>>
>> On 5/14/2025 11:51 AM, Shiwu Zhang wrote:
>>> Expose the debugfs file node for user space to dump the IFWI image
>>> on spirom.
>>>
>>> For one transaction between PSP and host, it will read out
* Dr. David Alan Gilbert (li...@treblig.org) wrote:
> * Alex Deucher (alexdeuc...@gmail.com) wrote:
> > On Sun, May 11, 2025 at 8:13 AM Dr. David Alan Gilbert
> > wrote:
> > >
> > > * Christophe JAILLET (christophe.jail...@wanadoo.fr) wrote:
> > > > Le 18/04/2025 à 02:21, li...@treblig.org a écrit
The DC_HDCP_LC_ENABLE_SW_FALLBACK enum comment was missing the required
colon after the parameter name in its kernel-doc tag:
* @DC_HDCP_LC_ENABLE_SW_FALLBACK If set, ...
Kernel-doc insists on the form @name: description. Adding the colon
eliminates the warning and ensures consistent extraction
From: "Dr. David Alan Gilbert"
Free doorbells in the error paths of cik_init and in cik_fini.
Build tested only.
Suggested-by: Christophe JAILLET
Signed-off-by: Dr. David Alan Gilbert
---
RFC->v1
Renamed ringCP[12]->ring_cp[12]
Cleaned up doorbells in cik_startup failure case
drivers/gp
The kerneldoc comment for HGCP locality check debug mask was missing a
semicolon resulting in a documentation build warning. Correct it.
Signed-off-by: George Anthony Vernon
---
drivers/gpu/drm/amd/include/amd_shared.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/g
On 5/14/2025 11:51 AM, Shiwu Zhang wrote:
> Expose the debugfs file node for user space to dump the IFWI image
> on spirom.
>
> For one transaction between PSP and host, it will read out the
> images on both active and inactive partitions so a buffer with two
> times the size of maximum IFWI im
On 5/12/25 09:30, Prike Liang wrote:
> As the userq resource was already freed at the drm_release
> early phase, it should avoid freeing userq resource again
> at the later kms postclose callback.
Clear NAK. You are just hiding a bug.
The userq resources should always be only cleaned up here and
79 matches
Mail list logo
