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 CONFIG_FORTIF
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 CONFIG_FORTIF
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 CONFIG_FORTIF
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 CONFIG_FORTIF
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 CONFIG_FORTIF
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 CONFIG_FORTIF
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 CONFIG_FORTIF
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
---
drivers/gpu/drm/amd/include/amd_shared.
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 CONFIG_FORTIF
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’:
dri
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 De
[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: Zha
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 l
[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 power
[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 ;
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
> (
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 CONFIG_FOR
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 lib
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
for
[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 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 __counte
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
> > >>
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: Rodri
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 low
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
> ---
> drivers/gpu/
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: https://gitlab.freedesktop.org/drm/amd/-/issu
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
inde
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
b/drivers/gpu/d
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 (pre-blending).
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 rel
[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 ;
[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, Al
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-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 gamc
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. Currently,
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
> > ; airl...@gmail
[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
> ;
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, A
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, Hawki
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 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: https://gitlab.freede
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 at
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
> > >
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 with
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 gmc_v11_0_fl
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
---
drivers/gp
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 W
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 sha
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 +-
driv
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: Harry
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
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: Mel
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 iden
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
Signed-o
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 content,
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. W
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
LUT
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 ha
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 pre-define
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 a/drivers/gpu/drm/amd/display/amdg
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
---
drivers/gpu/drm/amd/display/amdgp
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 combinat
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 LUT
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 retu
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
---
drivers/gpu/drm/amd/display/amdgpu_dm/amd
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 +---
drivers/gpu/drm/amd/display/i
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, th
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
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_
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
---
.../gpu/drm/amd/display/amdgpu_dm/amdgp
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
modu
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 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgp
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 set_color_proper
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 +--
.../amd/display/amdg
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 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
[drm:amdgpu_dev
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!
[drm:amdgpu_d
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 sw_i
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 erro
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 sw_i
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 sw_i
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 sw_i
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 sw_i
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 sw_i
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
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 2d192
[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 S
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 wit
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(+)
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 8fff9184d1b5810dca5dd1a02726d4f844af88fc Add linux-next specific
files for 20230925
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202308282000.2xnh0k6d-...@intel.com
https
97 matches
Mail list logo
