Hello,
This patch is reviewed by Andrey and Christian and pushed into bringup
temp branch. It need to be cherry-picked to drm-next, too. Does anyone
has any comments on this patch?
Thanks,
Yubiao Wang
[Why]
In amdgpu_cs_ioctl, amdgpu_job_free could be performed ealier if there
is -ERESTARTSYS
Hi AMD folks,
Top posting because it might not have been obvious but I was looking for
your feedback on this message (which can be viewed on lore.kernel.org if
you do not have the original [1]) so that we can try to get this fixed
in some way for 6.0/6.1. If my approach is not welcome, please
Dne četrtek, 18. avgust 2022 ob 23:00:07 CEST je Wolfram Sang napisal(a):
> Follow the advice of the below link and prefer 'strscpy' in this
> subsystem. Conversion is 1:1 because the return value is not used.
> Generated by a coccinelle script.
>
> Link:
>
On Wed, Aug 24, 2022 at 11:09 AM Simon Ser wrote:
>
> amdgpu_dm_commit_planes already sets the flip_immediate flag for
> async page-flips. This flag is used to set the UNP_FLIP_CONTROL
> register. Thus, no additional change is required to handle async
> page-flips with the atomic uAPI.
>
> Note,
Hi Dave, Daniel,
Fixes for 6.0. Mainly fixes for new IPs added in 6.0.
The following changes since commit b1fb6b87ed55ced458b322ea10cf0d0ab151e01b:
Merge tag 'amd-drm-fixes-6.0-2022-08-17' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2022-08-19 09:45:22
+1000)
are
[+cc Greg, no action needed yet, just FYI that stable will want these]
On Thu, Aug 25, 2022 at 02:28:19PM +0530, Lijo Lazar wrote:
> HDP flush is used early in the init sequence as part of memory controller
> block initialization. Hence remapping of HDP registers needed for flush
> needs to
On Thu, Aug 25, 2022 at 10:18:28AM +0200, Christian König wrote:
> Am 25.08.22 um 09:54 schrieb Lazar, Lijo:
> > On 8/25/2022 1:04 PM, Christian König wrote:
> > > Am 25.08.22 um 08:40 schrieb Stefan Roese:
> > > > On 24.08.22 16:45, Tom Seewald wrote:
> > > > > On Wed, Aug 24, 2022 at 12:11 AM
On Tue, Aug 23, 2022 at 3:29 AM Bernard Zhao wrote:
>
> This patch fix potential memory leak (clk_src) when function run
> into last return NULL.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff
Applied. Thanks!
On Tue, Aug 23, 2022 at 3:30 AM Bernard Zhao wrote:
>
> This patch fix cocci warning:
> drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c:1816:6-8:
> WARNING: possible condition with no effect (if == else).
>
> Signed-off-by: Bernard Zhao
> ---
>
Applied. Thanks!
Alex
On Tue, Aug 23, 2022 at 3:01 AM Bernard Zhao wrote:
>
> This patch fix cocci warning:
> drivers/gpu/drm/amd/display/dc/core/dc.c:3335:2-4: WARNING:
> possible condition with no effect (if == else).
>
> Signed-off-by: Bernard Zhao
> ---
>
Applied. Thanks!
Alex
On Tue, Aug 23, 2022 at 2:36 AM Bernard Zhao wrote:
>
> This patch fix potential memory leak (clk_src) when function run
> into last return NULL.
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 1 +
> 1 file changed, 1
Applied. Thanks!
On Tue, Aug 23, 2022 at 3:29 AM Bernard Zhao wrote:
>
> This patch fix potential memory leak (clk_src) when function run
> into last return NULL.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 1 +
> 1 file changed, 1
Applied. Thanks!
Alex
On Tue, Aug 23, 2022 at 3:15 AM wrote:
>
> From: Qu Huang
>
> The mmVM_L2_CNTL3 register is not assigned an initial value
>
> Signed-off-by: Qu Huang
> ---
> drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
[AMD Official Use Only - General]
> -Original Message-
> From: Alex Deucher
> Sent: Thursday, August 25, 2022 11:26 AM
> To: Joshi, Mukul
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: Fix page table setup on Arcturus
>
> [CAUTION: External Email]
>
> On Thu,
Applied. Thanks!
Alex
On Thu, Aug 25, 2022 at 3:58 AM Limonciello, Mario
wrote:
>
> On 8/24/2022 12:32, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > According to the ACPI specification [1], the ACPI_FADT_LOW_POWER_S0
> > flag merely means that it is better to use low-power S0
Applied. Thanks!
Alex
On Wed, Aug 24, 2022 at 10:40 PM Yu Zhe wrote:
>
> time_after() deals with timer wrapping correctly.
>
> Signed-off-by: Yu Zhe
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Thu, Aug 25, 2022 at 10:49 AM Joshi, Mukul wrote:
>
> [AMD Official Use Only - General]
>
>
>
> > -Original Message-
> > From: Alex Deucher
> > Sent: Thursday, August 25, 2022 9:33 AM
> > To: Joshi, Mukul
> > Cc: amd-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH] drm/amdgpu: Fix
Am 2022-08-25 um 04:58 schrieb Lijo Lazar:
HDP flush is used early in the init sequence as part of memory controller
block initialization. Hence remapping of HDP registers needed for flush
needs to happen earlier.
This also fixes the AER error reported as Unsupported Request during
driver load.
Am 2022-08-25 um 09:31 schrieb Christian König:
Use DMA_RESV_USAGE_BOOKKEEP for VM page table updates and KFD preemption fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 3 ++-
2 files
Am 2022-08-24 um 01:10 schrieb Lazar, Lijo:
On 8/23/2022 10:34 PM, Tom Seewald wrote:
On Sat, Aug 20, 2022 at 2:53 AM Lazar, Lijo wrote:
Missed the remap part, the offset is here -
https://elixir.bootlin.com/linux/v6.0-rc1/source/drivers/gpu/drm/amd/amdgpu/nv.c#L680
The trace is
Am 25.08.22 um 16:26 schrieb Alex Deucher:
On Thu, Aug 25, 2022 at 10:22 AM Lazar, Lijo wrote:
On 8/25/2022 7:37 PM, Alex Deucher wrote:
On Thu, Aug 25, 2022 at 4:58 AM Lijo Lazar wrote:
HDP flush is used early in the init sequence as part of memory controller
block initialization.
[AMD Official Use Only - General]
> -Original Message-
> From: Alex Deucher
> Sent: Thursday, August 25, 2022 9:33 AM
> To: Joshi, Mukul
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: Fix page table setup on Arcturus
>
> [CAUTION: External Email]
>
> On Mon,
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.
acpi_video_set_dmi_backlight_type() is
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates
Add an entry summarizing the discussion about dealing with brightness
control on devices with more then 1 internal panel.
The original discussion can be found here:
https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight,
Remove this check from the asus-wmi backlight handling:
/* Some Asus desktop boards export an acpi-video backlight interface,
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Changes in v2:
- Add missing Nvidia copyright header
- Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
On x86/ACPI boards the acpi_video driver will usually initialize before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the
Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.
Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.
Acked-by: Rafael J.
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Move all the
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight,
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the
Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
Now that acpi_video_get_backlight_type() has apple-gmux detection (using
apple_gmux_present()), it is no longer necessary for the apple-gmux code
to manually remove possibly conflicting drivers.
So remove the handling for this from the apple-gmux driver.
Signed-off-by: Hans de Goede
---
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is
Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec
check. This will make nvidia-wmi-ec-backlight properly honor the user
selecting a different backlight driver through the acpi_backlight=...
kernel commandline option.
Since the auto-detect code check for
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step towards this is to deal with some existing technical debt
in backlight handling on
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type
backlight devices call acpi_video_backlight_use_native() now. This sets
__acpi_video_get_backlight_type()'s internal static native_available flag.
This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check
unnecessary.
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2
On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.
Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.
This will allow removig the (ab)use
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.
Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
On Thu, Aug 25, 2022 at 10:22 AM Lazar, Lijo wrote:
>
>
>
> On 8/25/2022 7:37 PM, Alex Deucher wrote:
> > On Thu, Aug 25, 2022 at 4:58 AM Lijo Lazar wrote:
> >>
> >> HDP flush is used early in the init sequence as part of memory controller
> >> block initialization. Hence remapping of HDP
On 8/25/2022 7:37 PM, Alex Deucher wrote:
On Thu, Aug 25, 2022 at 4:58 AM Lijo Lazar wrote:
HDP flush is used early in the init sequence as part of memory controller
block initialization. Hence remapping of HDP registers needed for flush
needs to happen earlier.
This also fixes the AER
On Thu, Aug 25, 2022 at 9:22 AM Alex Deucher wrote:
>
> Series is:
> Reviewed-by: Alex Deucher
>
Actually, hold off on that, I have a comment on patch 1.
Alex
> On Thu, Aug 25, 2022 at 4:58 AM Lijo Lazar wrote:
> >
> > Make sure the register offsets used for HDP flush in VF is
> >
On Thu, Aug 25, 2022 at 4:58 AM Lijo Lazar wrote:
>
> HDP flush is used early in the init sequence as part of memory controller
> block initialization. Hence remapping of HDP registers needed for flush
> needs to happen earlier.
>
> This also fixes the AER error reported as Unsupported Request
On 2022-08-24 22:29, Luben Tuikov wrote:
Inlined:
On 2022-08-24 12:21, Andrey Grodzovsky wrote:
On 2022-08-23 17:37, Luben Tuikov wrote:
On 2022-08-23 14:57, Andrey Grodzovsky wrote:
On 2022-08-23 14:30, Luben Tuikov wrote:
On 2022-08-23 14:13, Andrey Grodzovsky wrote:
On 2022-08-23
On 2022-08-24 22:29, Luben Tuikov wrote:
Inlined:
On 2022-08-24 12:21, Andrey Grodzovsky wrote:
On 2022-08-23 17:37, Luben Tuikov wrote:
On 2022-08-23 14:57, Andrey Grodzovsky wrote:
On 2022-08-23 14:30, Luben Tuikov wrote:
On 2022-08-23 14:13, Andrey Grodzovsky wrote:
On 2022-08-23
On Mon, Aug 22, 2022 at 11:53 AM Mukul Joshi wrote:
>
> When translate_further is enabled, page table depth needs to
> be updated. This was missing on Arcturus MMHUB init. This was
> causing address translations to fail for SDMA user-mode queues.
>
Do other mmhub implementations need a similar
This reverts commit 250195ff744f260c169f5427422b6f39c58cb883.
The job should now be initialized when we reach the parser functions.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git
We already discussed that the call to drm_sched_entity_select_rq() needs
to move to drm_sched_job_arm() to be able to set a new scheduler list
between _init() and _arm(). This was just not applied for some reason.
Signed-off-by: Christian König
Reviewed-by: Andrey Grodzovsky
---
Sort the functions in the order they are called and cleanup the coding
style and function names to represent the data they process.
Check the size of the IB chunk, initialize resulting entity and scheduler
job much earlier as well.
Signed-off-by: Christian König
---
Check if the entity is already limited, not if it's assigned to the
first instance.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 5 ++---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 5 ++---
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git
Similar to what we did for VCN3 use the job instead of the parser
entity. Cleanup the coding style quite a bit as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 46 +++
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git
Allows submitting jobs as gang which needs to run on multiple engines at the
same time.
All members of the gang get the same implicit, explicit and VM dependencies. So
no gang member will start running until everything else is ready.
The last job is considered the gang leader (usually a
Allows submitting jobs as gang which needs to run on multiple
engines at the same time.
Basic idea is that we have a global gang submit fence representing when the
gang leader is finally pushed to run on the hardware last.
Jobs submitted as gang are never re-submitted in case of a GPU reset
We should not have any different CS constrains based
on the execution environment.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
Move setting the job resources into amdgpu_job.c
Signed-off-by: Christian König
Reviewed-by: Andrey Grodzovsky
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 21 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 17 +
This reverts commit 94f4c4965e5513ba624488f4b601d6b385635aec.
We found that the bo_list is missing a protection for its list entries.
Since that is fixed now this workaround can be removed again.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 21
Use DMA_RESV_USAGE_BOOKKEEP for VM page table updates and KFD preemption fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
Hi guys,
so Trigger found another issues with this series which is now fixed.
Patch #11 is just a shoot into the dark so far, could be that the VCN3/4
problems are now solved. But could as well be that this needs more
investigation.
Bas still has a backtrace with this which I can't figure out
Series is:
Reviewed-by: Alex Deucher
On Thu, Aug 25, 2022 at 4:58 AM Lijo Lazar wrote:
>
> Make sure the register offsets used for HDP flush in VF is
> initialized early so that it works fine during any early HDP flush
> sequence. For that, move the offset initialization to *_remap_hdp.
>
>
On 08/24, Simon Ser wrote:
> This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
> commits, aka. "immediate flip" (which might result in tearing).
> The feature was only available via the legacy uAPI, however for
> gaming use-cases it may be desirable to enable it via the atomic
>
From: Rafael J. Wysocki
According to the ACPI specification [1], the ACPI_FADT_LOW_POWER_S0
flag merely means that it is better to use low-power S0 idle on the
given platform than S3 (provided that the latter is supported) and it
doesn't preclude using either of them (which of them will be used
On 8/24/22 20:45, Christian König wrote:
> Am 24.08.22 um 17:49 schrieb Dmitry Osipenko:
>> On 8/24/22 18:24, Christian König wrote:
>>> Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
Move dma-buf attachment API functions to the dynamic locking
specification.
The strict locking
Hi Lyude,
Thank you for the review.
On 8/24/22 19:41, Lyude Paul wrote:
> Just one tiny nitpick below:
>
> On Wed, 2022-08-24 at 14:14 +0200, Hans de Goede wrote:
>> Before this commit when we want userspace to use the acpi_video backlight
>> device we register both the GPU's native backlight
Hi All,
On 8/24/22 14:50, Jani Nikula wrote:
> On Wed, 24 Aug 2022, Hans de Goede wrote:
>> Before this commit when we want userspace to use the acpi_video backlight
>> device we register both the GPU's native backlight device and acpi_video's
>> firmware acpi_video# backlight device. This
[AMD Official Use Only - General]
It does indeed short-circuit on || (If the left side of an || statement is not
0, it doesn't evaluate the right side and returns true). So we can ignore this
patch, since checking for each individual field on the 2nd term is probably
overkill. We were still
[AMD Official Use Only - General]
Good point, as if (1 || 0) should short-circuit at the if (1) part. Thus we
should go down to NOTIFY_DONE if m is NULL. Yazen can confirm here, as he was
the one who with me when we found the original issue. It's possible that one of
the 3 message fields was
On 8/25/2022 5:16 PM, Russell, Kent wrote:
[AMD Official Use Only - General]
Friendly ping
Wonder how it goes any further when m is NULL. It should do shortcut
evaluation and return NOTIFY_DONE, right? Or is this for better readability?
Thanks,
Lijo
Kent
-Original Message-
[AMD Official Use Only - General]
Friendly ping
Kent
-Original Message-
From: Russell, Kent
Sent: Monday, August 15, 2022 11:31 AM
To: amd-gfx@lists.freedesktop.org
Cc: Ghannam, Yazen ; Russell, Kent
Subject: [PATCH] drm/amdgpu: Handle potential NULL pointer dereference
If m is
[AMD Official Use Only - General]
Reviewed-by: Kent Russell
-Original Message-
From: Chen, Guchun
Sent: Wednesday, August 24, 2022 11:04 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking ; Russell,
Kent
Cc: Chen, Guchun
Subject: [PATCH] drm/amdgpu:
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> Add an entry summarizing the discussion about dealing with brightness
> control on devices with more then 1 internal panel.
>
> The original discussion can be found here:
>
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> Typically the acpi_video driver will initialize before nouveau, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> nouveau would register its own nv_backlight device later. After
Just one tiny nitpick below:
On Wed, 2022-08-24 at 14:14 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on
Make sure the register offsets used for HDP flush in VF is
initialized early so that it works fine during any early HDP flush
sequence. For that, move the offset initialization to *_remap_hdp.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
HDP flush is used early in the init sequence as part of memory controller
block initialization. Hence remapping of HDP registers needed for flush
needs to happen earlier.
This also fixes the AER error reported as Unsupported Request during
driver load.
Link:
Am 25.08.22 um 09:54 schrieb Lazar, Lijo:
On 8/25/2022 1:04 PM, Christian König wrote:
Am 25.08.22 um 08:40 schrieb Stefan Roese:
On 24.08.22 16:45, Tom Seewald wrote:
On Wed, Aug 24, 2022 at 12:11 AM Lazar, Lijo
wrote:
Unfortunately, I don't have any NV platforms to test. Attached is an
Am 25.08.22 um 09:48 schrieb Guchun Chen:
adev_to_drm is used everywhere in amdgpu code, so modify
it to keep consistency.
Signed-off-by: Guchun Chen
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On 8/24/2022 12:32, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
According to the ACPI specification [1], the ACPI_FADT_LOW_POWER_S0
flag merely means that it is better to use low-power S0 idle on the
given platform than S3 (provided that the latter is supported) and it
doesn't preclude
On 8/25/2022 1:04 PM, Christian König wrote:
Am 25.08.22 um 08:40 schrieb Stefan Roese:
On 24.08.22 16:45, Tom Seewald wrote:
On Wed, Aug 24, 2022 at 12:11 AM Lazar, Lijo wrote:
Unfortunately, I don't have any NV platforms to test. Attached is an
'untested-patch' based on your trace logs.
[Public]
Reviewed-by: Aaron Liu
> -Original Message-
> From: Liang, Prike
> Sent: Wednesday, August 24, 2022 8:40 PM
> To: Liang, Prike ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Huang, Ray
> ; Zhang, Yifan ; Liu, Aaron
> ; Limonciello, Mario
> Subject: RE: [PATCH]
I think so, we indeed need a new message indicating suspend, e.g. runtime
suspend has completed. I will provide a new patch for this.
Regards,
Guchun
-Original Message-
From: Quan, Evan
Sent: Thursday, August 25, 2022 3:17 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Deucher,
adev_to_drm is used everywhere in amdgpu code, so modify
it to keep consistency.
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
Patch 1 adds kfd_lock_pdd_by_id and patch 2 adds kfd_unlock_pdd helpers,
broken out this way to reduce noise in the first patch, which is a bit
tricky because of modifying a lot of error paths. Patch 2 is trivial.
Daniel Phillips (2):
drm/amdgpu: Use kfd_lock_pdd_by_id helper in more places
Convert most of the "mutex_lock; kfd_process_device_data_by_id" occurrences
in kfd_chardev to use the kfd_lock_pdd_by_id. These will now consistently
log debug output if the lookup fails. Sites where kfd_process_device_data_by_id
is used without locking are not converted for now.
Signed-off-by:
Am 25.08.22 um 08:40 schrieb Stefan Roese:
On 24.08.22 16:45, Tom Seewald wrote:
On Wed, Aug 24, 2022 at 12:11 AM Lazar, Lijo wrote:
Unfortunately, I don't have any NV platforms to test. Attached is an
'untested-patch' based on your trace logs.
Thanks,
Lijo
Thank you for the patch. It
I thought I reviewed this one together with another one from you that fixed
hive refcount leak. You sent them in series.
Anyway, go ahead to submit with my RB.
Thanks.
Regards,
Hawking
From: amd-gfx on behalf of Chai, Thomas
Date: Thursday, August 25, 2022 at 00:37
To:
1 - 100 of 159 matches
Mail list logo
