tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 734339e5c1c46e3af041b4c288c213e045e34354 Add linux-next specific
files for 20220712
Error/Warning reports:
https://lore.kernel.org/linux-mm/202206292052.lsfui3zo-...@intel.com
Error/Warning
[AMD Official Use Only - General]
The series is:
Reviewed-by: Tao Zhou
> -Original Message-
> From: Chai, Thomas
> Sent: Wednesday, July 13, 2022 11:25 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ;
> Clements, John ; Li, Candice
> ; Chai,
1. Support query umc ras error counter.
2. Support ras umc ue error address remapping.
v2:
Use adev->gmc.num_umc to replace hardcoded definitions.
Signed-off-by: YiPeng Chai
Reviewed-by: Alexander Deucher
Reviewed-by: Hawking Zhang
Reviewed-by: Tao Zhou
---
Add umc v8_10_0 register offset and shift masks
header files
Signed-off-by: YiPeng Chai
Reviewed-by: Alexander Deucher
Reviewed-by: Hawking Zhang
Reviewed-by: Tao Zhou
---
.../include/asic_reg/umc/umc_8_10_0_offset.h | 33 +++
.../include/asic_reg/umc/umc_8_10_0_sh_mask.h | 94
SMU will perform dpm disablement when entering BACO,
and enable them later on, so talking to SMU to get
enabled features mask in runpm cycle as BACO support
check is not reliable. Hence, use a cached baco flag
to fix it.
v2: cache this flag in load sequence to simplify code (from Evan)
v3:
SMU is always alive, so it's fine to skip SMU FW reloading
when runpm resumed from BACO, this can avoid some race issues
when resuming SMU FW.
v2: Exclude boco case if an ASIC supports both boco and baco
Suggested-by: Evan Quan
Signed-off-by: Guchun Chen
---
[AMD Official Use Only - General]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, July 12, 2022 23:14
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 4/4] drm/amd/display:
On Tue, Jul 12, 2022 at 6:57 PM Felix Kuehling wrote:
>
> Eric sent out the corresponding user mode patches to the mailing list as
> well. It looks a bit weird, because it looks like they're part of the
> same patch series. But patch 2 and 3 are actually user mode patches. The
> interesting one
The new display engine uses floating point math, which is not supported
by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov
is enabled") tried to work around the problem by disabling
CONFIG_DRM_AMD_DC_DCN if KCOV_INSTRUMENT_ALL and KCOV_ENABLE_COMPARISONS
are enabled. The
Eric sent out the corresponding user mode patches to the mailing list as
well. It looks a bit weird, because it looks like they're part of the
same patch series. But patch 2 and 3 are actually user mode patches. The
interesting one is patch 3.
Do we still need a link to a user mode patch in
I'll ask around to see if there's some DMI property we can match in
order to detect whether a system is expected to use the EC backlight
driver: if so, maybe we can avoid the WMI interactions in patch 16/29 of
this series. Although I suppose even if there were a DMI property, we'd
still need
Thanks, Hans:
On 7/12/22 14:38, Hans de Goede wrote:
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
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
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
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
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
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"))
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
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
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.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git
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.
Signed-off-by: Hans de Goede
---
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
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
---
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
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
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 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 x86/ACPI boards the acpi_video driver will usually initializing 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
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
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
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
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/
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 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
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.
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
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.
Signed-off-by: Hans
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
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.
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,
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
On 2022-07-12 11:23, Alex Deucher wrote:
> On Mon, Jul 11, 2022 at 10:51 AM Michel Dänzer wrote:
>>
>> From: Michel Dänzer
>>
>> Requires enabling the vblank machinery for them.
>>
>> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2030>>> Signed-off-by:
>> Michel Dänzer
>
> This looks
On 2022-07-12 13:00, Alex Deucher wrote:
On Tue, Jul 12, 2022 at 12:28 PM wrote:
From: Leo Li
When pinning a buffer, we should check to see if there are any
additional restrictions imposed by bo->preferred_domains. This will
prevent the BO from being moved to an invalid domain when
On Tue, Jul 12, 2022 at 12:28 PM wrote:
>
> From: Leo Li
>
> When pinning a buffer, we should check to see if there are any
> additional restrictions imposed by bo->preferred_domains. This will
> prevent the BO from being moved to an invalid domain when pinning.
>
> For example, this can happen
From: Leo Li
When pinning a buffer, we should check to see if there are any
additional restrictions imposed by bo->preferred_domains. This will
prevent the BO from being moved to an invalid domain when pinning.
For example, this can happen if the user requests to create a BO in GTT
domain for
On 12/07/2022 12:02, Limonciello, Mario wrote:
On 7/12/2022 10:59, Rodrigo Siqueira wrote:
We had an MST fix for some DELL devices that got merged, but we missed
other products. This commit adds the other missing Precision devices.
Cc: Mario Limonciello
Cc: Jerry Zuo
Cc: Qian Fu
Cc: Alex
On 06/28, Harry Wentland wrote:
>
>
> On 2022-06-19 18:30, Melissa Wen wrote:
> > Hi,
> >
> > I've been working on a proposal to add 3D LUT interface to DRM CRTC
> > color mgmt, that means new **after-blending** properties for color
> > correction. As I'm targeting AMD display drivers, I need
On 7/12/2022 10:59, Rodrigo Siqueira wrote:
We had an MST fix for some DELL devices that got merged, but we missed
other products. This commit adds the other missing Precision devices.
Cc: Mario Limonciello
Cc: Jerry Zuo
Cc: Qian Fu
Cc: Alex Deucher
Fixes: 9fcd8af669d7 ("drm/amd/display:
We had an MST fix for some DELL devices that got merged, but we missed
other products. This commit adds the other missing Precision devices.
Cc: Mario Limonciello
Cc: Jerry Zuo
Cc: Qian Fu
Cc: Alex Deucher
Fixes: 9fcd8af669d7 ("drm/amd/display: Ignore First MST Sideband Message Return
On 7/12/2022 10:42, Solomon Chiu wrote:
From: Fangzhi Zuo
[why]
First MST sideband message returns AUX_RET_ERROR_HPD_DISCON
on certain intel platform. Aux transaction considered failure
if HPD unexpected pulled low. The actual aux transaction success
in such case, hence do not return error.
On 2022-07-12 11:13, Alex Deucher wrote:
> The indentation is screwed up. I'm not sure quite how the logic
> should flow. Someone more familiar with this code should
> verify this.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
>
From: Fangzhi Zuo
[why]
First MST sideband message returns AUX_RET_ERROR_HPD_DISCON
on certain intel platform. Aux transaction considered failure
if HPD unexpected pulled low. The actual aux transaction success
in such case, hence do not return error.
[how]
Not returning error when
From: Aric Cyr
This version brings along following fixes:
- Fixes for MST, MPO, PSRSU, DP 2.0, Freesync and others
- Add register offsets of NBI and DCN.
- Improvement of ALPM
- Removing assert statement for Linux DM
- Re-implementing ARGB16161616 pixel format
Acked-by: Solomon Chiu
From: Rodrigo Siqueira
We recently introduced a commit that caused a compilation warning
because we tried to print a struct as an unsigned int. This commit
address this issue by adding the missing field.
Fixes: "drm/amd/display: add system info table log"
Reviewed-by: Nicholas Kazlauskas
From: Samson Tam
[Why]
With single display odm 2:1 policy, when moving windowed MPO across
the display, we experience a momentary lag when we move between the
centre of the display and the right half of the display. This is
caused by the MPO pipe being reallocated when it crosses this
From: Aurabindo Pillai
[Why]
Add a field to store the NBIO IP offset for use with runtime offset
calculation
Reviewed-by: Rodrigo Siqueira
Acked-by: Solomon Chiu
Signed-off-by: Aurabindo Pillai
Tested-by: Daniel Wheeler
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
From: Harry Wentland
[Why]
Add a field to store the DCN IP offset for use with runtime offset
calculation
This offset is indexed using reg*_BASE_IDX for the corresponding
group of registers. For example, address of DIG_BE_CNTL instance 0 is
calculated like:
From: Charlene Liu
[why]
insert log for debug use.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Solomon Chiu
Signed-off-by: Charlene Liu
Tested-by: Daniel Wheeler
---
.../drm/amd/display/dc/bios/bios_parser2.c| 30 +++
1 file changed, 30 insertions(+)
diff --git
From: Wayne Lin
[Why & How]
There is chance we change dc state while calling dc_link_detect().
As the result of that, grab the dm.dc_lock before detecting link.
Reviewed-by: Hersen Wu
Acked-by: Solomon Chiu
Signed-off-by: Wayne Lin
Tested-by: Daniel Wheeler
---
From: Wellenreiter Ethan
[Why]
ABGR16161616 colour format was added to dcn10/20/30, and set
any ARGB16161616 to the same value as it (26). As such, the
HDR10 Green Point y value was too far off of the EDID stated
value for DisplayPort.
[How]
Added back the pixel format as 22 for ARGB16161616
Am 12.07.22 um 16:31 schrieb Alex Deucher:
This is not a compliant kerneldoc comment, so make it just
a regular comment.
Reported-by: kernel test robot
Signed-off-by: Alex Deucher
Reviewed-by: Christian König for this series.
---
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c | 2
Applied. Thanks!
Alex
On Tue, Jul 12, 2022 at 9:56 AM Harry Wentland wrote:
>
> On 2022-07-12 07:32, Melissa Wen wrote:
> > Check the value of per_pixel_alpha to decide whether the Coverage pixel
> > blend mode is applicable or not.
> >
> > Fixes: 76818cdd11a2 ("drm/amd/display: add Coverage
On 2022-07-12 10:31, Alex Deucher wrote:
> It's not used outside of irq_service_dcn314.c.
>
> Reported-by: kernel test robot
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/irq/dcn314/irq_service_dcn314.c | 2 +-
> 1 file changed, 1
Applied. Thanks!
On Mon, Jul 11, 2022 at 9:06 PM Mr. B34r wrote:
>
> From: Yefim Barashkin
>
> divide error: [#1] SMP PTI
> CPU: 3 PID: 78925 Comm: tee Not tainted 5.15.50-1-lts #1
> Hardware name: MSI MS-7A59/Z270 SLI PLUS (MS-7A59), BIOS 1.90 01/30/2018
> RIP:
On 2022-07-12 10:50, Alex Deucher wrote:
> Ping?
>
> On Fri, Jul 8, 2022 at 11:50 AM Alex Deucher
> wrote:
>>
>> Not used outside of dc_dmub_srv.c.
>>
>> Reported-by: kernel test robot
>> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
>> ---
>>
On Mon, Jul 11, 2022 at 10:51 AM Michel Dänzer wrote:
>
> From: Michel Dänzer
>
> Requires enabling the vblank machinery for them.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2030
> Signed-off-by: Michel Dänzer
This looks correct to me, but it would be good if one of the display
Applied. Thanks!
Alex
On Mon, Jul 11, 2022 at 1:39 PM Mario Kleiner
wrote:
>
> Various DCE versions had trouble with 36 bpp lb depth, requiring fixes,
> last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display
> on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but
Am 12.07.22 um 17:13 schrieb Alex Deucher:
Not used so drop it.
Signed-off-by: Alex Deucher
Patches #1-#3 are Reviewed-by: Christian König
No idea what to do about patch #4, somebody more familiar with this
needs to take a look.
Regards,
Christian.
---
Hi Sebin,
Às 10:29 de 10/07/22, Sebin Sebastian escreveu:
> Fix two coverity warning's double free and and an uninitialized pointer
> read. Both tmp and new are pointing at same address and both are freed
> which leads to double free. Freeing tmp in the condition after new is
> assigned with new
Unused so drop it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index bc9802ac5534..0d8193b30fc5 100644
---
Unused so drop it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c
index 00ae5d65e1e4..0200cb3a31a4 100644
---
The indentation is screwed up. I'm not sure quite how the logic
should flow. Someone more familiar with this code should
verify this.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 45 +---
1 file changed, 24 insertions(+), 21 deletions(-)
diff
Not used so drop it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 4effee12a4ac..d1657de5f875 100644
Am 12.07.22 um 15:24 schrieb Alex Deucher:
Drop execute.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2085
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h | 0
On 06/28, Harry Wentland wrote:
>
>
> On 6/19/22 18:31, Melissa Wen wrote:
> > Add 3D LUT for gammar correction using a 3D lookup table. The position
> > in the color correction pipeline where 3D LUT is applied depends on hw
> > design, being after CTM or gamma. If just after CTM, a shaper lut
Às 12:50 de 08/07/22, Alex Deucher escreveu:
> Not used outside of dc_dmub_srv.c.
>
> Reported-by: kernel test robot
> Signed-off-by: Alex Deucher
Reviewed-by: André Almeida
On 06/27, Ville Syrjälä wrote:
> On Sun, Jun 19, 2022 at 09:31:03PM -0100, Melissa Wen wrote:
> > Add 3D LUT for gammar correction using a 3D lookup table. The position
> > in the color correction pipeline where 3D LUT is applied depends on hw
> > design, being after CTM or gamma. If just after
Save the original stable pstate on ctx init and restore
it on ctx fini so that we restore a manually selected
stable pstate on ctx exit.
v2: fix init order (Alex)
v3: don't add new variable to ctx struct (Evan)
Fixes: c65b364c52ba ("drm/amdgpu/ctx: only reset stable pstate if the user
changed
Ping?
On Fri, Jul 8, 2022 at 11:50 AM Alex Deucher wrote:
>
> Not used outside of dc_dmub_srv.c.
>
> Reported-by: kernel test robot
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Hi Alex,
Às 11:31 de 12/07/22, Alex Deucher escreveu:
> This is not a compliant kerneldoc comment, so make it just
> a regular comment.
>
> Reported-by: kernel test robot
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c | 2 +-
> 1 file changed, 1
This is not a compliant kerneldoc comment, so make it just
a regular comment.
Reported-by: kernel test robot
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
It's not used outside of irq_service_dcn314.c.
Reported-by: kernel test robot
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/irq/dcn314/irq_service_dcn314.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The patch has been pushed. I will do that for future patches.
Thanks,
Eric
On 2022-07-12 09:57, Deucher, Alexander wrote:
[AMD Official Use Only - General]
Can you please include a link to the proposed userspace in the commit
message when you commit this?
Alex
Às 23:01 de 11/07/22, Yefim Barashkin escreveu:
> divide error: [#1] SMP PTI
> CPU: 3 PID: 78925 Comm: tee Not tainted 5.15.50-1-lts #1
> Hardware name: MSI MS-7A59/Z270 SLI PLUS (MS-7A59), BIOS 1.90 01/30/2018
> RIP: 0010:smu_v11_0_set_fan_speed_rpm+0x11/0x110 [amdgpu]
>
> Speed is
Às 10:55 de 12/07/22, Alex Deucher escreveu:
> Several headers were included twice. Fix that.
>
> Reported-by: kernel test robot
> Signed-off-by: Alex Deucher
> ---
Reviewed-by: André Almeida
In the future, for new files, it's a good practice to keep includes sorted.
On 2022-07-12 09:55, Alex Deucher wrote:
> Several headers were included twice. Fix that.
>
> Reported-by: kernel test robot
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c| 1 -
>
[AMD Official Use Only - General]
Can you please include a link to the proposed userspace in the commit message
when you commit this?
Alex
From: amd-gfx on behalf of Eric Huang
Sent: Monday, July 11, 2022 2:41 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang,
On 2022-07-12 07:32, Melissa Wen wrote:
> Check the value of per_pixel_alpha to decide whether the Coverage pixel
> blend mode is applicable or not.
>
> Fixes: 76818cdd11a2 ("drm/amd/display: add Coverage blend mode for overlay
> plane")
> Reported-by: kernel test robot
> Reported-by: Dan
Several headers were included twice. Fix that.
Reported-by: kernel test robot
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c| 1 -
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c | 1 -
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c |
On Tue, Jul 12, 2022 at 3:28 AM Christian König
wrote:
>
> Am 12.07.22 um 00:44 schrieb sunpeng...@amd.com:
> > From: Leo Li
> >
> > When pinning a buffer, we should check to see if there are any
> > additional restrictions imposed by bo->preferred_domains. This will
> > prevent the BO from
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, July 12, 2022 9:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: fix file permissions on some files
Drop execute.
Bug:
Drop execute.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2085
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h | 0
drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h | 0
Am 12.07.22 um 14:12 schrieb Kent Russell:
The initialism of RunList Controller is RLC, not RCL
Signed-off-by: Kent Russell
Reviewed-by: Christian König
---
Documentation/gpu/amdgpu/amdgpu-glossary.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The initialism of RunList Controller is RLC, not RCL
Signed-off-by: Kent Russell
---
Documentation/gpu/amdgpu/amdgpu-glossary.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst
b/Documentation/gpu/amdgpu/amdgpu-glossary.rst
Check the value of per_pixel_alpha to decide whether the Coverage pixel
blend mode is applicable or not.
Fixes: 76818cdd11a2 ("drm/amd/display: add Coverage blend mode for overlay
plane")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Melissa Wen
---
Thanks for your suggestion, Lijo. I will follow your suggestion in a new patch
set.
Regards,
Guchun
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, July 12, 2022 2:57 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Deucher,
Alexander ; Zhang, Hawking ;
Quan, Evan ; Feng,
Am 12.07.22 um 07:39 schrieb Luben Tuikov:
Protect the struct amdgpu_bo_list with a mutex. This is used during command
submission in order to avoid buffer object corruption as recorded in
the link below.
Suggested-by: Christian König
Cc: Alex Deucher
Cc: Andrey Grodzovsky
Cc: Vitaly Prosyak
Am 12.07.22 um 00:44 schrieb sunpeng...@amd.com:
From: Leo Li
When pinning a buffer, we should check to see if there are any
additional restrictions imposed by bo->preferred_domains. This will
prevent the BO from being moved to an invalid domain when pinning.
For example, this can happen if
Instead of doing this way, suggest to cache the run_pm_mode in
struct amdgpu_pm {
}
You could cache the run_pm modes in kms logic -
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c#L183
Afterwards, you may use the cached value for any check
For ex:
1 - 100 of 102 matches
Mail list logo
