On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
wrote:
>Kees,
> I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
>in the process I got gcc-13 which is not WERROR-clean because we only
>limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
>has all the same
Hi all,
Joshua Ashton and I (with the great collaboration of Harry Wentland -
thanks) have been working on KMS color pipeline enhancement for Steam
Deck/SteamOS by exposing the large set of color caps available in AMD
display HW.
This patchset results from this full-stack work, including
From: Harry Wentland
The shaper LUT requires a 10-bit value of the delta between
segments. We were using dc_fixpt_clamp_u0d10() to do that
but it doesn't do what we want it to do. It will preserve
10-bit precision after the decimal point, but that's not
quite what we want. We want 14-bit
From: Joshua Ashton
dc_acquire_release_mpc_3dlut_for_ctx initializes the bits required to
program 3DLUT in DC MPC hw block, applied in set_output_transfer_func().
Since acquire/release can fail, we should check resources availability
during atomic check considering the new context created. We
HW allows us to program shaper LUT without 3D LUT settings and it is
also good for testing shaper LUT behavior, therefore, DC driver should
allow acquiring both 3D and shaper LUT, but programing shaper LUT
without 3D LUT (not initialized).
Signed-off-by: Melissa Wen
---
Decouple steps of post-blending shaper LUT setup and LUT size validation
according to HW caps as a preparation for DRM CRTC shaper LUT support.
Signed-off-by: Melissa Wen
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 67 ---
1 file changed, 58 insertions(+), 9 deletions(-)
Map DRM CRTC 3D LUT in the atomic color mgmt pipeline to DC
(post-blending). 3D LUT works better in a non-linear color space,
therefore using a degamma to linearize the input space may produce
unexpected results. The next patch introduces shaper LUT support that
can be used to delinearize the
Inspired by regamma TF, follow similar steps to add TF + 1D LUT for
shaper func. Reuse gamma_tf property, since the driver doesn't support
shaper and out gamma at the same time. We could rename gamma_tf, if
necessary to avoid misunderstandings, or add a specific property for
shaper lut.
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.
Signed-off-by: Joshua Ashton
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Now, we can use DRM CRTC shaper LUT to delinearize and/or normalize the
color space for a more efficient 3D LUT support (so far, only for DRM
atomic color mgmt). If a degamma 1D LUT is passed to linearize the color
space, a custom shaper 1D LUT can be used before applying 3D LUT.
NOTE: although
From: Joshua Ashton
Add predefined transfer function programming. There is no out gamma ROM,
but we can use AMD color modules to program LUT parameters from a
predefined TF and an empty regamma LUT (or power LUT parameters with
predefined TF setup).
Signed-off-by: Joshua Ashton
---
We took a similar path for CRTC color mgmt changes, since we remap CRTC
degamma to plane/DPP block. Here we can use the status of
`plane->color_mgmt_changed` to detect when a plane color property
changed and recreate the plane accordingly.
Co-developed-by: Joshua Ashton
Signed-off-by: Joshua
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
DC only has pre-blending degamma caps (pre-blending/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.
Signed-off-by:
From: Joshua Ashton
We only set CRTC degamma if we don't have plane degamma LUT or TF to
configure. We return -EINVAL if we don't have plane degamma settings, so
we can continue and check CRTC degamma.
Signed-off-by: Joshua Ashton
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +-
From: Joshua Ashton
Detach value translation from CTM to reuse it for programming HDR
multiplier property.
Signed-off-by: Joshua Ashton
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 8 +---
drivers/gpu/drm/amd/display/include/fixed31_32.h | 12
2 files
It follows the same path of out_transfer_func for stream updates, since
shaper LUT and 3D LUT is programmed in funcs.set_output_transfer_func()
and this function is called in the atomic commit_tail when
update_flags.bits.out_tf is set.
Signed-off-by: Melissa Wen
---
We are introducing DRM 3D LUT property to DM 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
In the original dc_acquire_release_mpc_3dlut(), only current ctx is
considered, which doesn't fit the steps for atomic checking new ctx.
Therefore, create a function to handle 3D LUT resource for a given
context, so that we can check resources availability in atomic_check
time and handle failures
From: Joshua Ashton
When commiting planes, we copy color mgmt resources to the stream state.
Do the same for shaper and 3D LUTs.
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
Signed-off-by: Joshua Ashton
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file
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.
Signed-off-by: Joshua
> On 20/04/2023 00:00, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> Currently the KMD is using enum i915_cache_level to set caching policy
>> for buffer objects. This is flaky because the PAT index which really
>> controls the caching behavior in PTE has far more levels than what's
>>
> On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote:
>>> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode
From: Harry Wentland
The region and segment calculation was incapable of dealing
with regions of more than 16 segments. We first fix this.
Now that we can support regions up to 256 elements we can
define a better segment distribution for near-linear LUTs
for our maximum of 256 HW-supported
In the next patches we are adding 17 new properties for color
correction:
- CRTC: 3D LUT+size, shaper LUT+size, regamma TF (5)
- Plane: Degamma LUT+size+TF, HDR multiplier, shaper LUT+size+TF, 3D LUT+size,
blend
LUT+size+TF (12)
We still need to detach driver-private counter from
Add CRTC 3D LUT for gamma correction using a 3D lookup table. A shaper
lut must be set to shape the content for a non-linear space. That
details should be handled by the driver according to HW color
capabilities.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 14
>From amdgpu_dm_plane we can get it for both CRTC and plane color
properties. We are adding new plane properties for AMD driver-private
color mgmt.
Signed-off-by: Melissa Wen
---
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 37 +--
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c
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 (using hardcoded curve caps).
Signed-off-by: Joshua Ashton
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
We will add color mgmt properties to DRM planes in the text 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.
Signed-off-by:
From: Joshua Ashton
Add predefined transfer function property to DRM CRTC gamma to convert
to wire encoding with or without gamma LUT.
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
Signed-off-by: Joshua Ashton
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 22
Shaper 1D LUT delinearizes content before applying 3D LUT so that, it
comes before 3D LUT. It's an optional property and drivers should attach
it according to HW caps.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 14 ++
Add property to set predefined transfer function to enable delinearizing
content with or without shaper LUT. Drivers should advertize this
property acoording to HW caps.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 +
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
Add 3D LUT property for plane gamma correction using a 3D lookup table.
3D LUT is more effective when applying in non-linear space, therefore,
userpace may need one 1D LUT (shaper) before it to delinearize content
and another 1D LUT after 3D LUT (blend) to linearize content again for
blending. The
From: Joshua Ashton
Create driver-private properties (not DRM KMS generic) for plane degamma
LUT (user-blob and its size).
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
Signed-off-by: Joshua Ashton
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 14
From: Joshua Ashton
Blend 1D LUT or a predefined transfer function can be set to linearize
content before blending, so that it's positioned just before blending
planes, and after 3D LUT (non-linear space). Shaper and Blend LUTs are
1D LUTs that sandwich 3D LUT. Drivers should advertize blend
Describe some expected behavior of the AMD DM color mgmt programming.
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/amdgpu_dm/amdgpu_dm_color.c
We are enabling a large set of color calibration features to enhance KMS
color mgmt but these properties are specific of AMD display HW, and
cannot be provided by other vendors. Therefore, set a config option to
enable AMD driver-private properties used on Steam Deck color mgmt
pipeline.
CRTC shaper LUT shapes the content after blending, i.e., de-linearizes
or normalizes space before applying a 3D LUT color correction. In the
next patch, we add CRTC 3D LUT property to DRM color management after
this shaper LUT and before the current CRTC gamma LUT.
Signed-off-by: Melissa Wen
---
As per previous code, copy shaper, 3d and blend settings from dc_plane
to surface_updates before commit.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
We already have the steps to program post-blending shaper/3D LUT on AMD
display driver, so that we can reuse them and map plane properties to DC
plane for pre-blending (plane) shaper/3D LUT setup.
Signed-off-by: Melissa Wen
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 34
From: Joshua Ashton
Map DRM 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
Need to funnel the color caps through to these functions so it can check
that the hardware is capable.
Signed-off-by: Joshua Ashton
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 34 ---
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git
From: Joshua Ashton
With `dc_fixpt_from_s3132()` translation, we can just use it to set
hdr_mult.
Signed-off-by: Joshua Ashton
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 3 +++
2 files changed, 4 insertions(+)
smatch has several simailar warnings to
drivers/gpu/drm/meson/meson_venc.c:189:28: warning: symbol
'meson_hdmi_enci_mode_480i' was not declared. Should it be static?
These variables are only used in their defining file so should be static
Signed-off-by: Tom Rix
---
On Tue Apr 18, 2023 at 6:49 PM EEST, Lorenzo Stoakes wrote:
> No invocation of get_user_pages() uses the vmas parameter, so remove
> it.
>
> The GUP API is confusing and caveated. Recent changes have done much to
> improve that, however there is more we can do. Exporting vmas is a prime
> target
If in doubt, say "N"
+
+config DRM_I915_DEBUG_WAKEREF
+ bool "Enable extra tracking for wakerefs"
+ depends on DRM_I915
+ default n
'default n' is not need
Hi,
thank you for the review.
On 20/04/2023 09:35, Linus Walleij wrote:
>> +static int s6d7aa0_on(struct s6d7aa0 *ctx)
>> +{
>> + struct mipi_dsi_device *dsi = ctx->dsi;
>> + struct device *dev = >dev;
>> + int ret;
>> +
>> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
>
>
+
+static inline void
+intel_wakeref_tracker_show(struct ref_tracker_dir *dir,
+ struct drm_printer *p)
+{
+ const size_t buf_size = PAGE_SIZE;
+ char *buf, *sb, *se;
+ size_t count;
+
+ buf = kmalloc(buf_size, GFP_NOWAIT);
+ if (!buf)
+
Hi Maira,
thanks for the patch.
On Fri, Aug 12, 2022 at 05:57:45PM -0300, Maíra Canal wrote:
> This driver includes the deprecated OF GPIO header
> yet fail to use symbols from it, so drop this include.
>
> Cc: Alain Volmat
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/sti/sti_dvo.c
Hi Jani,
On Thu, Sep 01, 2022 at 03:47:09PM +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi in display info over calling
> drm_detect_hdmi_monitor(). Remove the now redundant hdmi_monitor member
> from struct sti_hdmi.
>
> Cc: Alain Volmat
> Signed-off-by: Jani Nikula
> ---
>
This series fixes the blanking pack size and the PMS calculation. It then
adds support to allows the DSIM to dynamically DPHY clocks, and support
non-burst mode while allowing the removal of the hard-coded clock values
for the PLL for imx8m mini/nano/plus, and it allows the removal of the
From: Lucas Stach
Scale the blanking packet sizes to match the ratio between HS clock
and DPI interface clock. The controller seems to do internal scaling
to the number of active lanes, so we don't take those into account.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
---
+ Bridge Maintainers
On Wed, Apr 19, 2023 at 8:35 AM 余治国 wrote:
>
> The log looks like this:
> [ 31.723823] Internal error: Oops: 9604 [#1] SMP\013 \010
> [ 31.729030] Modules linked in:\013 \010
> [ 31.733395] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.59+2.0.0 #250\013
> \010
> [
Make the pll-clock-frequency optional. If it's present, use it
to maintain backwards compatibility with existing hardware. If it
is absent, read clock rate of "sclk_mipi" to determine the rate.
Signed-off-by: Adam Ford
---
drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++--
1 file
The DPHY timings are currently hard coded. Since the input
clock can be variable, the phy timings need to be variable
too. Add an additional variable to the driver data to enable
this feature to prevent breaking boards that don't support it.
The phy_mipi_dphy_get_default_config function
According to Table 13-45 of the i.MX8M Mini Reference Manual, the min
and max values for M and the frequency range for the VCO_out
calculator were incorrect. This information was contradicted in other
parts of the mini, nano and plus manuals. After reaching out to my
NXP Rep, when confronting
The blanking calculation currently uses burst_clk_rate for calculating
the settings. Since it's possible to use this in non-burst mode, it's
possible that where won't be burst_clk_rate. Instead, cache the
clock rate configured from of samsung_dsim_set_pll and use it instead.
Signed-off-by: Adam
The high-speed clock is hard-coded to the burst-clock
frequency specified in the device tree. However, when
using devices like certain bridge chips without burst mode
and varying resolutions and refresh rates, it may be
necessary to set the high-speed clock dynamically based
on the desired pixel
Hi Roman,
On 2023-04-18 at 09:40:01 +0200, Roman Beranek wrote:
> According to Allwinner's BSP code, in DSI mode, TCON0 clock needs to be
> running at what's effectively the per-lane datarate of the DSI link.
> Given that the TCON DCLK divider is fixed to 4 (SUN6I_DSI_TCON_DIV),
> DCLK can't be
On Sun, Apr 23, 2023 at 4:53 PM Tom Rix wrote:
>
> smatch has several simailar warnings to
s/simailar/similar/
> drivers/gpu/drm/meson/meson_venc.c:189:28: warning: symbol
> 'meson_hdmi_enci_mode_480i' was not declared. Should it be static?
>
> These variables are only used in their defining
On 2023-04-20 23:07:01 +0300, Dmitry Baryshkov wrote:
> On Thu, 20 Apr 2023 at 23:01, Janne Grunau wrote:
> >
> > On 2023-03-28 10:31:29 +0800, Zongmin Zhou wrote:
> > > When drivers call drm_kms_helper_poll_disable from
> > > their device suspend implementation without enabled output polling
When a DRM job timeout, the GPU is probably hang and amdgpu have some
ways to deal with that, ranging from soft recoveries to full device
reset. Anyway, when userspace ask the kernel the state of the context
(via AMDGPU_CTX_OP_QUERY_STATE), the kernel reports that the device was
reset, regardless
> On 20/04/2023 00:00, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> Currently the KMD is using enum i915_cache_level to set caching policy for
>> buffer objects. This is flaky because the PAT index which really controls
>> the caching behavior in PTE has far more levels than what's defined
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Signed-off-by: Fei Yang
Reviewed-by: Andrzej
From: Fei Yang
The first four patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has dependency on the pat_index refactor.
This series is focusing on uAPI changes,
1. end support for set caching ioctl
Hi André,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.3 next-20230421]
[If
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent,
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by:
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Signed-off-by: Fei Yang
Reviewed-by: Andrzej
From: Fei Yang
These patches are extracted from series
https://patchwork.freedesktop.org/series/115980/
This series start with adding PTE encode functions for MTL as it can no
longer reuse the PTE encode functions for GEN8 due to PAT index changes.
Then there are patches refactoring the cache
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by:
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent,
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
On Fri, 21 Apr 2023 at 05:09, Lucas De Marchi wrote:
>
> On Wed, Apr 19, 2023 at 02:36:52PM +1000, Dave Airlie wrote:
> >From: Dave Airlie
> >
> >This adds a tag that will go into the module info, only one firmware from
> >the group given needs to be available for this driver to work. This
Kees,
I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
in the process I got gcc-13 which is not WERROR-clean because we only
limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
has all the same issues.
And I want to be able to do my arm64 builds with WERROR on
79 matches
Mail list logo
