Fixes the following:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3928: warning: Function
parameter or member 'srf_updates' not described in
'could_mpcc_tree_change_for_active_pipes'
Cc: Harry Wentland
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Cc: Alex Deucher
Signed-off-by:
Am 22.09.23 um 19:41 schrieb Alex Deucher:
On Fri, Sep 22, 2023 at 1:32 PM Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via
On 22.09.2023 19:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
On Fri, Sep 22, 2023 at 5:51 PM Luben Tuikov wrote:
>
> Fix a memory leak in amdgpu_fru_get_product_info().
>
> Cc: Alex Deucher
> Reported-by: Yang Wang
> Fixes: 0dbf2c56262532 ("drm/amdgpu: Interpret IPMI data for product
> information (v2)")
Reviewed-by: Alex Deucher
> ---
>
They need a similar workaround.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1839
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si_dpm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
They need a similar workaround.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1839
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
Tested-by:JamesZhuforthis patch
James zhu
On 2023-09-20 11:45, Philip Yang wrote:
If new range is splited to multiple pranges with max_svm_range_pages
alignment and added to update_list, svm validate and map should keep
going after error to make sure prange->mapped_to_gpu flag is up to date
On Mon, Sep 25, 2023 at 2:30 AM Christian König
wrote:
>
> Am 22.09.23 um 19:41 schrieb Alex Deucher:
> > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook wrote:
> >> Prepare for the coming implementation by GCC and Clang of the __counted_by
> >> attribute. Flexible array members annotated with
On 2023-09-13 12:43, Melissa Wen wrote:
> Color caps changed between HW versions which caused DCN10 color state
> sections on DTN log no longer fit DCN3.0 versions. Create a
> DCN3.0-specific color state logging and hook it to drivers of DCN3.0
> family.
>
> rfc-v2:
> - detail RAM mode for
On 2023-09-13 12:43, Melissa Wen wrote:
> Hi,
>
> This is an update of previous RFC [0] improving the data collection of
> Gamma Correction and Blend Gamma color blocks.
>
> As I mentioned in the last version, I'm updating the color state part of
> DTN log to match DCN3.0 HW better.
On 2023-09-13 12:43, Melissa Wen wrote:
> Logging DCN3 MPC state was following DCN1 implementation that doesn't
> consider new DCN3 MPC color blocks. Create new elements according to
> DCN3 MPC color caps and a new DCN3-specific function for reading MPC
> data.
>
> Signed-off-by: Melissa Wen
On 2023-09-22 16:12, Mario Limonciello wrote:
> During the suspend process dc_set_power_state() will use kzalloc
> to allocate memory, but this potentially fails with memory pressure.
> If it fails, the suspend should be aborted.
>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2362
>
On 2023-09-25 05:32, Jesse Zhang wrote:
Fix the svm_bo refcount warnging by check the refcount before release.
[ 462.649530] [ cut here ]
[ 462.649532] refcount_t: underflow; use-after-free.
[ 462.649536] WARNING: CPU: 7 PID: 1936 at
On Fri, Sep 22, 2023 at 4:51 PM Mario Limonciello
wrote:
>
> During the suspend process dc_set_power_state() will use kzalloc
> to allocate memory, but this potentially fails with memory pressure.
> If it fails, the suspend should be aborted.
>
> Link:
[Public]
> -Original Message-
> From: Douglas Anderson
> Sent: Thursday, September 21, 2023 3:27 PM
> To: dri-de...@lists.freedesktop.org; Maxime Ripard
> Cc: Douglas Anderson ; Zhang, Bokun
> ; Zhang, Hawking ;
> Zhu, James ; Zhao, Victor ;
> Pan, Xinhui ; airl...@gmail.com; Deucher,
On Mon, Sep 25, 2023 at 08:30:30AM +0200, Christian König wrote:
> Am 22.09.23 um 19:41 schrieb Alex Deucher:
> > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook wrote:
> > > Prepare for the coming implementation by GCC and Clang of the __counted_by
> > > attribute. Flexible array members annotated
On Mon, Sep 25, 2023 at 1:52 PM Kees Cook wrote:
>
> On Mon, Sep 25, 2023 at 08:30:30AM +0200, Christian König wrote:
> > Am 22.09.23 um 19:41 schrieb Alex Deucher:
> > > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook wrote:
> > > > Prepare for the coming implementation by GCC and Clang of the
> > >
DC code is reused by other OSes and so Linux return codes don't
make sense. Change dc_set_power_state() to boolean and add a wrapper
dm_set_power_state() to return a Linux error code for the memory
allocation failure.
Suggested-by: Harry Wentland
Signed-off-by: Mario Limonciello
---
On 9/25/2023 12:50, Harry Wentland wrote:
On 2023-09-22 16:12, Mario Limonciello wrote:
During the suspend process dc_set_power_state() will use kzalloc
to allocate memory, but this potentially fails with memory pressure.
If it fails, the suspend should be aborted.
Link:
On Mon, Sep 25, 2023 at 12:08:36PM +0200, Andrzej Hajda wrote:
>
>
> On 22.09.2023 19:32, Kees Cook wrote:
> > Prepare for the coming implementation by GCC and Clang of the __counted_by
> > attribute. Flexible array members annotated with __counted_by can have
> > their accesses bounds-checked
[AMD Official Use Only - General]
Hi Hawking,
No, no gfx HW programming before gfx power on, gmc_v11_0_flush_gpu_tlb returns
before real tbl flush happens. The dependence is a pure SW one as below:
static void gmc_v11_0_flush_gpu_tlb(struct amdgpu_device *adev, uint32_t vmid,
On Mon, Sep 25, 2023 at 10:07 AM Alex Deucher wrote:
>
> On Mon, Sep 25, 2023 at 2:30 AM Christian König
> wrote:
> >
> > Am 22.09.23 um 19:41 schrieb Alex Deucher:
> > > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook wrote:
> > >> Prepare for the coming implementation by GCC and Clang of the
> >
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of
> Shyam Sundar S K
> Sent: Friday, September 22, 2023 1:51 PM
> To: hdego...@redhat.com; markgr...@kernel.org; Natikar, Basavaraj
> ; ji...@kernel.org;
> benjamin.tissoi...@redhat.com; Deucher, Alexander
> ; Koenig, Christian
> ;
If the system is under high memory pressure, the resources may need
to be evicted into swap instead. If the storage backing for swap
is offlined during the suspend() step then such a call may fail.
So instead move this step into prepare(), while leaving all other
steps that put the GPU into a
[Public]
> -Original Message-
> From: Douglas Anderson
> Sent: Thursday, September 21, 2023 3:27 PM
> To: dri-de...@lists.freedesktop.org; Maxime Ripard
> Cc: Douglas Anderson ; Pan, Xinhui
> ; airl...@gmail.com; Deucher, Alexander
> ; amd-gfx@lists.freedesktop.org; Koenig,
> Christian
On 2023-07-21 09:24, Melissa Wen wrote:
> dc->caps.color.mpc.gamut_remap says there is a post-blending color block
> for gamut remap matrix for DCN3 HW family and newer versions. However,
> those drivers still follow DCN10 programming that remap stream
> gamut_remap_matrix to DPP
Hi,
On Mon, Sep 25, 2023 at 8:49 AM Deucher, Alexander
wrote:
>
> [Public]
>
> > -Original Message-
> > From: Douglas Anderson
> > Sent: Thursday, September 21, 2023 3:27 PM
> > To: dri-de...@lists.freedesktop.org; Maxime Ripard
> > Cc: Douglas Anderson ; Pan, Xinhui
> > ;
On 9/25/2023 11:27, Deucher, Alexander wrote:
[Public]
-Original Message-
From: amd-gfx On Behalf Of
Shyam Sundar S K
Sent: Friday, September 22, 2023 1:51 PM
To: hdego...@redhat.com; markgr...@kernel.org; Natikar, Basavaraj
; ji...@kernel.org;
benjamin.tissoi...@redhat.com; Deucher,
On Mon, Sep 25, 2023 at 2:41 AM Srinivasan Shanmugam
wrote:
>
> Fixes the following:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3928: warning: Function
> parameter or member 'srf_updates' not described in
> 'could_mpcc_tree_change_for_active_pipes'
>
> Cc: Harry Wentland
> Cc:
On 9/25/2023 8:19 AM, Philip Yang wrote:
Caution: This message originated from an External Source. Use proper
caution when opening attachments, clicking links, or responding.
On 2023-09-25 05:32, Jesse Zhang wrote:
Fix the svm_bo refcount warnging by check the refcount before
Hi,
On Mon, Sep 25, 2023 at 8:57 AM Deucher, Alexander
wrote:
>
> [Public]
>
> > -Original Message-
> > From: Douglas Anderson
> > Sent: Thursday, September 21, 2023 3:27 PM
> > To: dri-de...@lists.freedesktop.org; Maxime Ripard
> > Cc: Douglas Anderson ; Zhang, Bokun
> > ; Zhang,
On Mon, Sep 25, 2023 at 10:16 AM Zhang, Yifan wrote:
>
> [AMD Official Use Only - General]
>
> Hi Hawking,
>
> No, no gfx HW programming before gfx power on, gmc_v11_0_flush_gpu_tlb
> returns before real tbl flush happens. The dependence is a pure SW one as
> below:
>
> static void
On 2023-09-25 14:24, Mario Limonciello wrote:
> DC code is reused by other OSes and so Linux return codes don't
> make sense. Change dc_set_power_state() to boolean and add a wrapper
> dm_set_power_state() to return a Linux error code for the memory
> allocation failure.
>
> Suggested-by: Harry
The error path for DMUB firmware loading is unnecessarily noisy.
When a firmware is missing 3 errors show up:
```
amdgpu :07:00.0: Direct firmware load for amdgpu/green_sardine_dmcub.bin
failed with error -2
[drm:dm_early_init [amdgpu]] *ERROR* DMUB firmware loading failed: -19
The error path for SDMA firmware loading is unnecessarily noisy.
When a firmware is missing 3 errors show up:
```
amdgpu :07:00.0: Direct firmware load for amdgpu/green_sardine_sdma.bin
failed with error -2
[drm:sdma_v4_0_early_init [amdgpu]] *ERROR* Failed to load sdma firmware!
As part of IP discovery early_init is run for all HW IP blocks.
During this phase all firmware is supposed to be identified that may
be missing so that the driver can avoid releasing resources used by
the EFI framebuffer or simpledrm until the last possible moment.
Move microcode loading from
I recently found a noisier experience than I expected with missing
microcode. As a result I found that some microcode wasn't being loaded
in early_init and some messages were unnecessary.
Mario Limonciello (8):
drm/amd: Drop error message about failing to load DMUB firmware
drm/amd: Drop
As part of IP discovery early_init is run for all HW IP blocks.
During this phase all firmware is supposed to be identified that may
be missing so that the driver can avoid releasing resources used by
the EFI framebuffer or simpledrm until the last possible moment.
Move microcode loading from
As part of IP discovery early_init is run for all HW IP blocks.
During this phase all firmware is supposed to be identified that may
be missing so that the driver can avoid releasing resources used by
the EFI framebuffer or simpledrm until the last possible moment.
Move microcode loading from
As part of IP discovery early_init is run for all HW IP blocks.
During this phase all firmware is supposed to be identified that may
be missing so that the driver can avoid releasing resources used by
the EFI framebuffer or simpledrm until the last possible moment.
Move microcode loading from
As part of IP discovery early_init is run for all HW IP blocks.
During this phase all firmware is supposed to be identified that may
be missing so that the driver can avoid releasing resources used by
the EFI framebuffer or simpledrm until the last possible moment.
Move microcode loading from
As part of IP discovery early_init is run for all HW IP blocks.
During this phase all firmware is supposed to be identified that may
be missing so that the driver can avoid releasing resources used by
the EFI framebuffer or simpledrm until the last possible moment.
Move microcode loading from
Brief documentation about pre-defined transfer function usage on AMD
display driver and standardized EOTFs and inverse EOTFs.
v3:
- Document BT709 OETF (Pekka)
- Fix description of sRGB and pure power funcs (Pekka)
Co-developed-by: Harry Wentland
Signed-off-by: Harry Wentland
Signed-off-by:
Instead of relying on color block names to get the transfer function
intention regarding encoding pixel's luminance, define supported
Electro-Optical Transfer Functions (EOTFs) and inverse EOTFs, that
includes pure gamma or standardized transfer functions.
v3:
- squash linear and unity TFs to
From: Joshua Ashton
Allow userspace to tell the kernel driver the input space and,
therefore, uses correct predefined transfer function (TF) to delinearize
content with or without LUT.
v2:
- rename TF enum prefix from DRM_ to AMDGPU_ (Harry)
- remove HLG TF
Reviewed-by: Harry Wentland
From: Joshua Ashton
Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
nits for SDR content. So if you want, 203 nits for SDR
On AMD HW, 3D LUT always assumes a preceding shaper 1D LUT used for
delinearizing and/or normalizing the color space before applying a 3D
LUT. Add pre-defined transfer function to enable delinearizing content
with or without shaper LUT, where AMD color module calculates the
resulted shaper curve.
From: Joshua Ashton
Blend 1D LUT or a pre-defined transfer function (TF) can be set to
linearize content before blending, so that it's positioned just before
blending planes in the AMD color mgmt pipeline, and after 3D LUT
(non-linear space). Shaper and Blend LUTs are 1D LUTs that sandwich 3D
Add 3D LUT property for plane color transformations using a 3D lookup
table. 3D LUT allows for highly accurate and complex color
transformations and is suitable to adjust the balance between color
channels. It's also more complex to manage and require more
computational resources. Since a 3D LUT
Add AMD pre-defined transfer function property to default DRM CRTC
gamma to convert to wire encoding with or without a user gamma LUT.
There is no post-blending regamma ROM for pre-defined TF. When setting
blend TF (!= Identity) and LUT at the same time, the color module will
combine the
Describe some expected behavior of the AMD DM color mgmt programming.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git
From: Joshua Ashton
Add predefined transfer function programming. There is no pre-blending
out gamma ROM, but we can use AMD color modules to program LUT
parameters from a pre-defined TF and an empty regamma LUT (or bump up
LUT parameters with pre-defined TF setup).
v2:
- update crtc color mgmt
From: Joshua Ashton
Otherwise this is just initialized to 0. This needs to actually have a
value so that compute_curve can work for PQ EOTF.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
DRM_OBJECT_MAX_PROPERTY limits the number of properties to be attached
and we are increasing that value all time we add a new property (generic
or driver-specific).
In this series, we are adding 13 new KMS driver-specific properties for
AMD color manage:
- CRTC Gamma enumerated Transfer Function
Hi,
This series extends the current KMS color management API with AMD
driver-specific properties to enhance the color management support on
AMD Steam Deck. The key additions to the color pipeline include:
- plane degamma LUT and pre-defined TF;
- plane HDR multiplier;
- plane CTM 3x4;
- plane
Place it in drm_property where drm_property_replace_blob and
drm_property_lookup_blob live. Then we can use the DRM helper for
driver-specific KMS properties too.
Reviewed-by: Harry Wentland
Reviewed-by: Liviu Dudau
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
We will add color mgmt properties to DRM planes in the next patches and
we want to track when one of this properties change to define atomic
commit behaviors. Using a similar approach from CRTC color props, we set
a color_mgmt_changed boolean whenever a plane color prop changes.
Reviewed-by:
Hook up driver-specific atomic operations for managing AMD color
properties. Create AMD driver-specific color management properties
and attach them according to HW capabilities defined by `struct
dc_color_caps`.
First add plane degamma LUT properties that means user-blob and its
size. We will add
On Mon, Sep 25, 2023 at 4:41 PM Mario Limonciello
wrote:
>
> I recently found a noisier experience than I expected with missing
> microcode. As a result I found that some microcode wasn't being loaded
> in early_init and some messages were unnecessary.
Series is:
Reviewed-by: Alex Deucher
>
>
Hi Shyam,
kernel test robot noticed the following build warnings:
[auto build test WARNING on hid/for-next]
[also build test WARNING on linus/master v6.6-rc3 next-20230925]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
From: Joshua Ashton
Unlike degamma, blend gamma doesn't support hardcoded curve
(predefined/ROM), but we can use AMD color module to fill blend gamma
parameters when we have non-linear plane gamma TF without plane gamma
LUT. The regular degamma path doesn't hit this.
Reviewed-by: Harry Wentland
Plane CTM for pre-blending color space conversion. Only enable
driver-specific plane CTM property on drivers that support both pre- and
post-blending gamut remap matrix, i.e., DCN3+ family. Otherwise it
conflits with DRM CRTC CTM property.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
The next patch adds pre-blending degamma to AMD color mgmt pipeline, but
pre-blending degamma caps (DPP) is currently in use to provide DRM CRTC
atomic degamma or implict degamma on legacy gamma. Detach degamma usage
regarging CRTC color properties to manage plane and CRTC color
correction
We will wire up MPC 3D LUT to DM CRTC color pipeline in the next patch,
but so far, only for atomic interface. By checking
set_output_transfer_func in DC drivers with MPC 3D LUT support, we can
verify that regamma is only programmed when 3D LUT programming fails. As
a groundwork to introduce 3D
From: Joshua Ashton
Set DC plane with user degamma LUT or predefined TF from driver-specific
plane color properties. If plane and CRTC degamma are set in the same
time, plane degamma has priority. That means, we only set CRTC degamma
if we don't have plane degamma LUT or TF to configure. We
DC only has pre-blending degamma caps (plane/DPP) that is currently in
use for CRTC/post-blending degamma, so that we don't have HW caps to
perform plane and CRTC degamma at the same time. Reject atomic updates
when serspace sets both plane and CRTC degamma properties.
Reviewed-by: Harry Wentland
From: Joshua Ashton
We should reset a plane state if at least one of the color management
properties differs from old and new state.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Detach value translation from CTM to reuse it for programming HDR
multiplier property.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 8 +---
From: Joshua Ashton
Need to funnel the color caps through to these functions so it can check
that the hardware is capable.
v2:
- remove redundant color caps assignment on plane degamma map (Harry)
- pass color caps to degamma params
v3:
- remove unused color_caps parameter from
Enable usage of predefined transfer func in addition to shaper 1D LUT.
That means we can save some complexity by just setting a predefined
curve, instead of programming a custom curve when preparing color space
for applying 3D LUT.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Create drm_color_ctm_3x4 to support 3x4-dimension plane CTM matrix and
convert DRM CTM to DC CSC float matrix.
v3:
- rename ctm2 to ctm_3x4 (Harry)
Signed-off-by: Joshua Ashton
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 28 +--
Map the plane CTM driver-specific property to DC plane, instead of DC
stream. The remaining steps to program DPP block are already implemented
on DC shared-code.
v3:
- fix comment about plane and CRTC CTMs priorities (Harry)
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Map plane blend properties to DPP blend gamma. Plane blend is a
post-3D LUT curve that linearizes color space for blending. It may be
defined by a user-blob LUT and/or predefined transfer function. As
hardcoded curve (ROM) is not supported on blend gamma, we use AMD color
From: Joshua Ashton
With `dc_fixpt_from_s3132()` translation, we can just use it to set
hdr_mult.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
Map DC shaper LUT to DM plane color management. Shaper LUT can be used
to delinearize and/or normalize the color space for computational
efficiency and achiving specific visual styles. If a plane degamma is
apply to linearize the color space, a custom shaper 1D LUT can be used
just before applying
Wire up DC 3D LUT to DM plane color management (pre-blending). On AMD
display HW, 3D LUT comes after a shaper curve and we always have to
program a shaper curve to delinearize or normalize the color space
before applying a 3D LUT (since we have a reduced number of LUT
entries).
In this version,
From: Joshua Ashton
When commiting planes, we copy color mgmt resources to the stream state.
Do the same for shaper and 3D LUTs.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
On 9/25/2023 9:57 AM, Le Ma wrote:
To add message to select PLPD mode.
Signed-off-by: Le Ma
Reviewed-by: Asad Kamal
Series is -
Reviewed-by: Lijo Lazar
Thanks,
Lijo
---
drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_6_ppsmc.h | 5 +
1 file changed, 5 insertions(+)
[AMD Official Use Only - General]
Hi Mario,
Navi32 which DCE3.2.0 not support this. This patch will cause modprobe fail on
NV32.
[ +0.000126] [drm] DSC precompute is not needed.
[ +19.026503] amdgpu :03:00.0: amdgpu: SMU: I'm not done with your previous
command: SMN_C2PMSG_66:0x002D
Hi Feifei,
On 9/25/2023 22:20, Xu, Feifei wrote:
[AMD Official Use Only - General]
Hi Mario,
Navi32 which DCE3.2.0 not support this. This patch will cause modprobe fail on
NV32.
[ +0.000126] [drm] DSC precompute is not needed.
[ +19.026503] amdgpu :03:00.0: amdgpu: SMU: I'm not done
disable pp_power_profile_mode for sriov on gc11.0.3 as not supported
by smu
Signed-off-by: Victor Zhao
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index
Am 22.09.23 um 21:27 schrieb Christophe JAILLET:
In order to be sure that fw_name is not truncated, this buffer should be
at least 41 bytes long.
Let the compiler compute the correct length by itself.
When building with W=1, this fixes the following warnings:
Am 23.09.23 um 13:16 schrieb Yifan Zhang:
gmc11 hw_init depends on adev->gfxhub.funcs->init now, move
it to gmc11 sw_init. This patch fixes below driver load error on
GC 11.0.4:
[ 43.928149] [drm] amdgpu: 512M of VRAM memory ready
[ 43.928151] [drm] amdgpu: 7641M of GTT memory ready.
[
On 9/22/23 11:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
On 9/22/23 11:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
On 9/22/23 11:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
On 9/22/23 11:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
AMD_IP_BLOCK_TYPE_VPE is a new IP BLOCK type for Video Processing Engine,
but currently lacks description.
Fix the documentation warning:
warning: Enum value 'AMD_IP_BLOCK_TYPE_VPE' not described in
enum 'amd_ip_block_type'
Signed-off-by: Juntong Deng
---
On 9/22/23 11:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
In order to be sure that fw_name is not truncated, this buffer should be
at least 41 bytes long.
Let the compiler compute the correct length by itself.
When building with W=1, this fixes the following warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c: In function ‘amdgpu_vcn_early_init’:
On 9/22/23 11:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
On 9/22/23 11:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
On 9/22/23 11:32, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
On 09/24/ , Juntong Deng wrote:
> AMD_IP_BLOCK_TYPE_VPE is a new IP BLOCK type for Video Processing Engine,
> but currently lacks description.
>
> Fix the documentation warning:
> warning: Enum value 'AMD_IP_BLOCK_TYPE_VPE' not described in
> enum 'amd_ip_block_type'
>
> Signed-off-by: Juntong
[AMD Official Use Only - General]
I'm not sure, mmhub and gfxhub init are separated since the first version of
gfx11 code.
Hi Hawking/Tianci, do you know the reason ? Thanks !
Best Regards,
Yifan
-Original Message-
From: Christian König
Sent: Monday, September 25, 2023 2:45 PM
To:
[AMD Official Use Only - General]
RE - gmc11 hw_init depends on adev->gfxhub.funcs->init now, move it to gmc11
sw_init
isn't any driver loading failure observed? Since from gfx11, GFX won't be
powered on until smu hw_init phase. Any programming that touch gfx core is
invalid before it is
[AMD Official Use Only - General]
For sw_init, it's fine to move to gmc sw_init phase, but any hardware
programming should be done after smu hw_init.
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Zhang,
Hawking
Sent: Monday, September 25, 2023 19:30
To: Zhang, Yifan
Fix the svm_bo refcount warnging by check the refcount before release.
[ 462.649530] [ cut here ]
[ 462.649532] refcount_t: underflow; use-after-free.
[ 462.649536] WARNING: CPU: 7 PID: 1936 at lib/refcount.c:28
refcount_warn_saturate+0xf8/0x150
[ 462.649542] Modules
Am 24.09.23 um 22:00 schrieb Juntong Deng:
AMD_IP_BLOCK_TYPE_VPE is a new IP BLOCK type for Video Processing Engine,
but currently lacks description.
Fix the documentation warning:
warning: Enum value 'AMD_IP_BLOCK_TYPE_VPE' not described in
enum 'amd_ip_block_type'
Signed-off-by: Juntong Deng
Hi Kees,
On Fri, Sep 22, 2023 at 10:32:08AM -0700, Kees Cook wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
>
100 matches
Mail list logo
