== Series Details ==
Series: drm/display: split DSC helpers from DP helpers (rev2)
URL : https://patchwork.freedesktop.org/series/135231/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15034_full -> Patchwork_135231v2_full
S
On Fri, Jul 05, 2024 at 03:58:32PM +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Ville
> > Syrjala
> > Sent: Tuesday, June 25, 2024 12:40 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [PATCH 11/14] drm/i915/dsb: Allow intel_dsb_chain()
On Fri, Jul 05, 2024 at 04:09:43PM +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Manna, Animesh
> > Sent: Friday, July 5, 2024 9:29 PM
> > To: Ville Syrjala ; intel-
> > g...@lists.freedesktop.org
> > Subject: RE: [PATCH 11/14] drm/i915/dsb: Allow intel_dsb_chain() to
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Tuesday, June 25, 2024 12:41 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 13/14] drm/i915/dsb: s/dsb/dsb_color_vblank/
>
> From: Ville Syrjälä
>
> We'll soon utilize several DSBs during the commi
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Tuesday, June 25, 2024 12:41 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 12/14] drm/i915/dsb: Clear DSB_ENABLE_DEWAKE once the
> DSB is done
>
> From: Ville Syrjälä
>
> In order to avoid the DSB
On Fri, Jul 05, 2024 at 06:18:58PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 03, 2024 at 06:59:37PM +0300, Imre Deak wrote:
> > Dump the descriptor of the detected LTTPRs in non-transparent mode to
> > help the debugging related to LTTPRs easier.
> >
> > Signed-off-by: Imre Deak
> > ---
> > .../
On Fri, Jul 05, 2024 at 06:16:45PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 03, 2024 at 06:59:33PM +0300, Imre Deak wrote:
> > Switching to transparent mode leads to a loss of link synchronization,
> > so prevent doing this on an active link. This happened at least on an
> > Intel N100 system / DE
> -Original Message-
> From: Manna, Animesh
> Sent: Friday, July 5, 2024 9:29 PM
> To: Ville Syrjala ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH 11/14] drm/i915/dsb: Allow intel_dsb_chain() to use
> DSB_WAIT_FOR_VBLANK
>
>
>
> > -Original Message-
> > From: Inte
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Tuesday, June 25, 2024 12:40 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 11/14] drm/i915/dsb: Allow intel_dsb_chain() to use
> DSB_WAIT_FOR_VBLANK
>
> From: Ville Syrjälä
>
> Allow intel_dsb_cha
== Series Details ==
Series: drm/{i915, xe}: FBC cleanups + tweak fbdev stolen usage
URL : https://patchwork.freedesktop.org/series/135800/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15036 -> Patchwork_135800v1
Summary
-
== Series Details ==
Series: drm/{i915, xe}: FBC cleanups + tweak fbdev stolen usage
URL : https://patchwork.freedesktop.org/series/135800/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/{i915, xe}: FBC cleanups + tweak fbdev stolen usage
URL : https://patchwork.freedesktop.org/series/135800/
State : warning
== Summary ==
Error: dim checkpatch failed
1548cd572c1d drm/i915/fbc: Extract intel_fbc_has_fences()
7aedff05b81d drm/i915/fbc: Convert to
On Wed, Jul 03, 2024 at 06:59:37PM +0300, Imre Deak wrote:
> Dump the descriptor of the detected LTTPRs in non-transparent mode to
> help the debugging related to LTTPRs easier.
>
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_dp_link_training.c | 22 ++-
> 1 file
On Wed, Jul 03, 2024 at 06:59:33PM +0300, Imre Deak wrote:
> Switching to transparent mode leads to a loss of link synchronization,
> so prevent doing this on an active link. This happened at least on an
> Intel N100 system / DELL UD22 dock, the LTTPR residing either on the
> host or the dock. To f
From: Ville Syrjälä
Replace the "1/2 of stolen size" fbdev fb size heuristic with
something a bit more clever, that is ask the FBC code how much
stolen mem it would like to have avaialable for its CFB use.
TODO:
- This doesn't account for the fact that FBC's idea
usable stolen size might diffe
From: Ville Syrjälä
Replace the "1/2 of stolen size" fbdev fb size heuristic with
something a bit more clever, that is ask the FBC code how much
stolen mem it would like to have avaialable for its CFB use.
TODO:
- This doesn't account for the fact that FBC's idea
usable stolen size might diffe
From: Ville Syrjälä
Currently xe only checks that the BIOS FB doesn't take up too much
stolen memory, but does no such check when allocating a fresh FB
from stolen. Use the same rule for both, just like i915 does.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 5
From: Ville Syrjälä
Consolidate the "should we allocate fbdev fb in stolen?"
check into a helper function. Makes it easier to change the
heuristics without having to change so many places.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 24 ---
From: Ville Syrjälä
Pull the "should we keep the bios fb in stolen?" logic into
into a helper function, same as was done for i915. Gives us
a single place where to tweak the heuristics.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 18 ++
driv
From: Ville Syrjälä
Looks like stolen->size is in bytes, not pages. Remove the
bogus PAGE_SHIFT stuff.
Also for some rnadom reason xe rejects the FB if it takes up
exactly half of stolen, whereas i915 allows it to be used
in that case. Adjust xe to follow the i915 rule for consistency.
Signed-o
From: Ville Syrjälä
Allow the code to declare roughly how much stolen memory
should remain available for the CFB. Since we don't know
the actual resolutions that will eventually be used simply
assume that the maximum plane size (with no extra stride
padding) is enough, with 1:1 compression ratio
From: Ville Syrjälä
Extract a helper to determine the CFB bytes per pixel value.
Currently this is always 4, but that could change in the
future.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
From: Ville Syrjälä
Pull the lower level stuff out from intel_fbc_cfb_size() into
a separate function that doesn't depend on the plane_state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/d
From: Ville Syrjälä
Pull the code to determine the maximum CFB height
into a separate function. For pre-HSW the maximum CFB
height is the same as the maximum plane height (ie. the
older hardware supposedely doens't have the trick of leaving
the extra lines uncompressed).
Signed-off-by: Ville Syr
From: Ville Syrjälä
Rearrange the max CFB max height platform into the
more common "new first, old last" order.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel
From: Ville Syrjälä
Use the more customary name 'height' instead of 'lines'.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/di
From: Ville Syrjälä
Pull the lower level stuff out from intel_fbc_cfb_stride() into
a separate function that doesn't depend on the plane_state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-
From: Ville Syrjälä
Do the "is this ilk+ or g4x" checks in the customary order instead
of the reverse order. Easier for the poor brain to parse this
when it's always done the same way.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
1 file changed, 2 inserti
From: Ville Syrjälä
Rename intel_fbc_hw_tracking_covers_screen() to intel_fbc_surface_size_ok()
so that the naming scheme is the same for the surface size vs. plane
size checks. "surface size" is what bspec talks about.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c
From: Ville Syrjälä
Extract intel_fbc_max_surface_size() from
intel_fbc_hw_tracking_covers_screen(), mainly to mirror the
"max plane size" counterparts.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 41 ++--
1 file changed, 24 insertions(+), 17
From: Ville Syrjälä
_intel_fbc_cfb_stride() calculates the CFB stride the hardware would
automagically generate from the plane's stride. Rename the function
to intel_fbc_plane_cfb_stride() to better reflect its purpose.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c
From: Ville Syrjälä
Extract intel_fbc_max_plane_size() from intel_fbc_plane_size_valid().
We'll have another use for this soon in determining how much stolen
memory we'd like to keep reserved for FBC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 29 ++
From: Ville Syrjälä
Switch the FBC code over to intel_display from i915, as
much as possible. This is the future direction so that
the display code can be shared between i915 and xe more
cleanly.
Some of the platform checks and the stolen mem facing stiff
still need i915 around though.
Signed-o
From: Ville Syrjälä
Pull the "do we have fences?" check into a single helper in the FBC
code. Avoids having to call to outside the display code in multiple
places for this.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 9 +++--
1 file changed, 7 insertions(+),
From: Ville Syrjälä
Here's an idea for a slightly better heuristic to answer
the "should fbdev use stolen or not?" question.
Ended up with a pile of refactoring and cleanups in
the FBC code as a result.
Ville Syrjälä (20):
drm/i915/fbc: Extract intel_fbc_has_fences()
drm/i915/fbc: Convert t
On Wed, Jun 05, 2024 at 11:34:57AM +0530, Melanie Lobo wrote:
> Add support for a RGB64(FP16) format where each color component is a
> 16-bit floating point value. FP16 format which is a binary
> floating-point computer number format that occupies 16 bits in computer
> memory. Platform shall render
== Series Details ==
Series: Display Global Histogram
URL : https://patchwork.freedesktop.org/series/135793/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15036 -> Patchwork_135793v1
Summary
---
**SUCCESS**
No reg
== Series Details ==
Series: Display Global Histogram
URL : https://patchwork.freedesktop.org/series/135793/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./arch/x86/include/asm/bitops.h:116:1: warning:
== Series Details ==
Series: Display Global Histogram
URL : https://patchwork.freedesktop.org/series/135793/
State : warning
== Summary ==
Error: dim checkpatch failed
9b4d0f8ed82e drm/i915/display: Add support for histogram
-:42: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), doe
== Series Details ==
Series: drm/i915/display: Call panel_fitting function from pipe_config
URL : https://patchwork.freedesktop.org/series/135791/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15036 -> Patchwork_135791v1
Su
== Series Details ==
Series: drm/i915/display: Call panel_fitting function from pipe_config
URL : https://patchwork.freedesktop.org/series/135791/
State : warning
== Summary ==
Error: dim checkpatch failed
2971c1bf873c drm/i915/display: Call panel_fitting function from pipe_config
-:134: CHECK
== Series Details ==
Series: Introduce drm sharpening property (rev3)
URL : https://patchwork.freedesktop.org/series/129888/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15036 -> Patchwork_129888v3
Summary
---
**SUC
== Series Details ==
Series: Introduce drm sharpening property (rev3)
URL : https://patchwork.freedesktop.org/series/129888/
State : warning
== Summary ==
Error: dim checkpatch failed
b96b65457ae5 drm: Introduce sharpness mode property
d540875503e0 drm/i915/display: Compute the scaler filter c
== Series Details ==
Series: Introduce drm sharpening property (rev3)
URL : https://patchwork.freedesktop.org/series/129888/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Thu, 4 Jul 2024 22:17:08 +0300, Dmitry Baryshkov wrote:
> Currently the DRM DSC functions are selected by the
> DRM_DISPLAY_DP_HELPER Kconfig symbol. This is not optimal, since the DSI
> code (both panel and host drivers) end up selecting the seemingly
> irrelevant DP helpers. Split the DSC code
On Thu, Jul 04, 2024 at 03:17:09PM +0200, Maxime Ripard wrote:
> Hi,
>
> Here's this week drm-misc-next PR, and the last PR for the 6.11 release cycle.
>
> Thanks!
> Maxime
>
> drm-misc-next-2024-07-04:
> drm-misc-next for $kernel-version:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
>
> Co
On Thu, Jul 04, 2024 at 07:31:54AM +, Tvrtko Ursulin wrote:
>
> Hi Dave, Sima,
>
> The final pull for 6.11 is quite small and only contains a handful of
> fixes in areas such as stolen memory probing on ATS-M, GuC priority
> handling, out of memory reporting noise downgrade and fence register
Upon enabling histogram an interrupt is trigerred after the generation
of the statistics. This patch registers the histogram interrupt and
handles the interrupt.
Signed-off-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_display_irq.c | 6 +-
.../gpu/drm/i915/display/intel_histogram.c
In LNL+, histogram/IE data and index registers are added which was
included in the control registers in the legacy platforms. The new
registers are used for reading histogram and writing the IET LUT data.
Signed-off-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_histogram.c| 174 ++
The delay counter for histogram does not reset and as a result the
histogram bin never gets updated. Woraround would be to use save and
restore histogram register.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_histogram.c | 17 +
drivers/gpu/drm/i915/display
CRTC properties have been added for enable/disable histogram, reading
the histogram data and writing the IET data.
"HISTOGRAM_EN" is the crtc property to enable/disable the global
histogram and takes a value 0/1 accordingly.
"Histogram" is a crtc property to read the binary histogram data.
"Global
Statistics is generated from the image frame that is coming to display
and an event is sent to user after reading this histogram data.
This statistics/histogram is then shared with the user upon getting a
request from user. User can then use this histogram and generate an
enhancement factor. This e
Display histogram is a hardware functionality where a statistics for 'x'
number of frames is generated to form a histogram data. This is notified
to the user via histogram event. Compositor will then upon sensing the
histogram event will read the histogram data from KMD via crtc property.
A library
In panel fitter/pipe scaler scenario the pch_pfit configuration
currently takes place before we account for bigjoiner.
So once the calculation for bigjoiner is done, proper values
of width and height can be used for panel fitting.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel
Load the lut values during pipe enable.
v2: Add the display version check
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_crtc.c| 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
drivers/gpu/drm/i915/display/skl_scaler.c| 13 -
3 files chan
Add new registers and related bits. Compute the strength
value and tap value based on display mode.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +-
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_sharpen_filter.c | 105 ++
As only second scaler can be used for sharpness check if it
is available and if panel fitting is also not enabled, the
set the sharpness. Panel fitting will have the preference
over sharpness property.
v2: Added the panel fitting check before enabling sharpness
Signed-off-by: Nemesa Garg
---
dr
The sharpness property requires the use of one of the scaler
so need to set the sharpness scaler coefficient values.
These values are based on experiments and vary for different
tap value/win size. These values are normalized by taking the
sum of all values and then dividing each value with a sum.
Introduces the new crtc property "SHARPNESS_STRENGTH" that allows
the user to set the intensity so as to get the sharpness effect.
The value of this property can be set from 0-255.
It is useful in scenario when the output is blurry and user
want to sharpen the pixels. User can increase/decrease the
Many a times images are blurred or upscaled content is also not as
crisp as original rendered image. Traditional sharpening techniques often
apply a uniform level of enhancement across entire image, which sometimes
result in over-sharpening of some areas and potential loss of natural details.
In
On Tue, Jul 02, 2024 at 03:02:22PM -0400, Rodrigo Vivi wrote:
> Hi Dave and Sima,
>
> Here goes our actual last PR towards 6.11.
> One extra to make the drm-xe-next-fixes smoother.
>
> Mostly with fixes that would be anyway part of the
> drm-xe-next-fixes, plus some more SRIOV preparation
> and a
61 matches
Mail list logo
