On 17-10-2024 01:12, Taylor, Clinton A wrote:
On Fri, 2024-10-11 at 12:34 +0530, Pottumuttu, Sai Teja wrote:
On 11-10-2024 03:00, Taylor, Clinton A wrote:
On Wed, 2024-10-09 at 22:32 +0530, Pottumuttu, Sai Teja wrote:
On 05-10-2024 02:38, Clint Taylor wrote:
Some devices NAK DPCD writes to
On Thu, Oct 17, 2024, at 00:26, Sean Christopherson wrote:
> On Tue, Oct 15, 2024, Arnd Bergmann wrote:
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index 46301c06d18a..985cb78d8256 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
> -Original Message-
> From: Roper, Matthew D
> Sent: Wednesday, October 16, 2024 10:13 PM
> To: Atwood, Matthew S
> Cc: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Kandpal,
> Suraj
> Subject: Re: [PATCH v3 5/7] drm/i915/xe3lpd: Add new bit range of MAX
> swing se
> -Original Message-
> From: Roper, Matthew D
> Sent: Wednesday, October 16, 2024 8:58 PM
> To: Atwood, Matthew S
> Cc: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Kandpal,
> Suraj
> Subject: Re: [PATCH v3 3/7] drm/i915/xe3lpd: Include hblank restriction for
> xe3
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, October 16, 2024 7:31 PM
> To: Murthy, Arun R
> Cc: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/display: plane property for async supported
On Mon, Sep 30, 2024 at 01:08:41PM +0530, Raag Jadav wrote:
> Introduce device wedged event, which will notify userspace of wedged
> (hanged/unusable) state of the DRM device through a uevent. This is
> useful especially in cases where the device is no longer operating as
> expected even after a ha
On Tue, Oct 15, 2024, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Depending on x86 and KVM is not enough, as the kvm helper functions
> that get called here are controlled by CONFIG_KVM_X86, which is
> disabled if both KVM_INTEL and KVM_AMD are turned off.
>
> ERROR: modpost: "kvm_write_track
== Series Details ==
Series: drm/i915/dp: Fix memory leak in parse_lfp_panel_dtd() (rev2)
URL : https://patchwork.freedesktop.org/series/139856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15541 -> Patchwork_139856v2
Summ
== Series Details ==
Series: drm/i915/pfit: Panel fitter stuff
URL : https://patchwork.freedesktop.org/series/140066/
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: w
== Series Details ==
Series: drm/i915/pfit: Panel fitter stuff
URL : https://patchwork.freedesktop.org/series/140066/
State : warning
== Summary ==
Error: dim checkpatch failed
df5c45ccdc0b drm/i915/pfit: Check pipe source size against pfit limits on
ILK-BDW
32e09391e38a drm/i915/pfit: Check
== Series Details ==
Series: drm/i915/pfit: Panel fitter stuff
URL : https://patchwork.freedesktop.org/series/140066/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15541 -> Patchwork_140066v1
Summary
---
**SUCCESS**
On Fri, 2024-10-11 at 12:34 +0530, Pottumuttu, Sai Teja wrote:
> On 11-10-2024 03:00, Taylor, Clinton A wrote:
> > On Wed, 2024-10-09 at 22:32 +0530, Pottumuttu, Sai Teja wrote:
> > > On 05-10-2024 02:38, Clint Taylor wrote:
> > > > Some devices NAK DPCD writes to the SOURCE OUI (0x300) DPCD regist
== Series Details ==
Series: Miscelaneous fixes for display tracepoints (rev4)
URL : https://patchwork.freedesktop.org/series/137978/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15541 -> Patchwork_137978v4
Summary
---
== Series Details ==
Series: Miscelaneous fixes for display tracepoints (rev4)
URL : https://patchwork.freedesktop.org/series/137978/
State : warning
== Summary ==
Error: dim checkpatch failed
8807b4f2c0c4 drm/i915/display: Fix out-of-bounds access in pipe-related
tracepoints
-:22: WARNING:CO
== Series Details ==
Series: Miscelaneous fixes for display tracepoints (rev4)
URL : https://patchwork.freedesktop.org/series/137978/
State : warning
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/137978/revisions/4/mbox/ not
found
== Series Details ==
Series: drm/i915: Write source OUI for non-eDP sinks
URL : https://patchwork.freedesktop.org/series/140061/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15541 -> Patchwork_140061v1
Summary
---
*
== Series Details ==
Series: drm/i915: Write source OUI for non-eDP sinks
URL : https://patchwork.freedesktop.org/series/140061/
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
On Tue, Oct 15, 2024 at 04:11:22PM -0700, Matt Atwood wrote:
> From: Suraj Kandpal
>
> Add new bit range for Max PHY Swing Setup in PORT_ALPM_CTL
> register for DISPLAY_VER >= 30.
So the only change here is that the register field got larger, right?
I.e., it's 25:20 now instead of 23:20? In tha
The function parse_lfp_panel_dtd() is called when the driver
attempts to initialize the eDP connector, and it allocates memory,
which is recorded in panel->vbt.lfp_vbt_mode. However, since no
eDP panel is connected, the driver fails at intel_edp_init_dpcd()
and follows the failure path. Unfortunate
On Tue, Oct 15, 2024 at 04:11:20PM -0700, Matt Atwood wrote:
> From: Suraj Kandpal
>
> hblank restriction now includes all of xe3.
>
> v2: add additional definition instead of function, commit message typo
> fix and update.
> v3: restore lost conditional from v2.
>
> Signed-off-by: Suraj Kandpa
Quoting Matt Atwood (2024-10-15 20:11:19-03:00)
>From: Radhakrishna Sripada
>
>Xe3_LPD has new max cdclk of 691200 which requires reusing the lnl table
>and modify/add higher frequencies. Updating the max cdclk supported by
>the platform and voltage_level determination is also updated.
>
>There ar
On Tue, Oct 15, 2024 at 04:11:19PM -0700, Matt Atwood wrote:
> From: Radhakrishna Sripada
>
> Xe3_LPD has new max cdclk of 691200 which requires reusing the lnl table
> and modify/add higher frequencies. Updating the max cdclk supported by
> the platform and voltage_level determination is also up
Unrelated error – the entire patch only adds/removes comments
On Thu, Oct 10, 2024 at 09:35:00AM +0530, Mitul Golani wrote:
> Refactor VRR compute config to account for Panel replay workaround
> for VSC SDP.
>
> Previous Patch series links:
> https://patchwork.freedesktop.org/series/135629/
> https://patchwork.freedesktop.org/series/135851/
> https://patchwo
From: Ville Syrjälä
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the panel code to
use it (as much as possible at this stage).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +-
drivers/gpu/drm/i915/d
From: Ville Syrjälä
skl_plane_check() already takes care to reject scaling when an
unsupported pixel format or color keying is used. No need to
replicate that in the scaler code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 77 +++
1 file cha
From: Ville Syrjälä
The ILK-BDW panel fitter has several restrictions on the
destination window size. Check for those and reject the
configuration if things aren't entirely proper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c | 55 ++
1 file c
From: Ville Syrjälä
The panel fitter code doesn't really have much to do with the
rest of intel_panel.c, so extract it all into its own file.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/icl_dsi.c | 1 +
drivers/gpu/drm
From: Ville Syrjälä
The panel fitter lives inside the pipe and so would affect all cloned
outputs. However the relevant properties (scaling mode, TV margins)
are per-connector so we could end up with a situation where each cloned
output wants a different pfit configuration. Let's just reject pfit
From: Ville Syrjälä
Transcoder hdisplay/vdisplay have documented minimum limits
when using the panel fitter. Enforce those limits for all
pre-SKL platforms. SKL+ handles everything in the unified
scaler code instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c |
From: Ville Syrjälä
Gen2/3 pfit doesn't support downscaling at all, so reject it.
On i965+ downscaling is supported by the hardware (max scale
factor < 2.0), but as downscaling increases the effective
pixel rate we can't safely allow it unless
intel_crtc_compute_pixel_rate() gets fixed. Probably
From: Ville Syrjälä
Make sure we're not exceeding the max scaling factors for the panel
fitter on ILK-BDW. SKL+ is skipped here since this is all supposed to
be handled by the unified scaler code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c | 39
From: Ville Syrjälä
The ILK-BDW panel fitter imposes extra limits on the maximum
pipe source size we can use. Check for that.
Only HSW/BDW are really affected by this since on older platforms
the max hdisplay/vdisplay matches the max PIPESRC. But we'll
put in the limits for all the platforms jus
From: Ville Syrjälä
Add a bunch of missing validity checks for panel fitter
usage, and extract the pane fitter code into its own file.
Ville Syrjälä (9):
drm/i915/pfit: Check pipe source size against pfit limits on ILK-BDW
drm/i915/pfit: Check pfit scaling factors on ILK-BDW
drm/i915/pfit:
On Wed, Oct 16, 2024 at 04:54:09PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> > > Create a i915 private plane property for sharing the async supported
> > > modifiers to the user.
On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> > Create a i915 private plane property for sharing the async supported
> > modifiers to the user.
> > UMD related discussion requesting the same
> > https://gitlab.freed
Tracepoints that display frame and scanline counters for all pipes were
added with commit 1489bba82433 ("drm/i915: Add cxsr toggle tracepoint")
and commit 0b2599a43ca9 ("drm/i915: Add pipe enable/disable
tracepoints"). At that time, we only had pipes A, B and C. Now that we
can also have pipe D, th
In an upcoming change, we will also add support for logging
frame/scanline counts for pipe D in relevant tracepoints.
In [1], Matt mentioned the possibility of having garbage in those counts
for pipe D on a platform containing only 3 pipes. Indeed, it has been
verified that the counts for the extr
Because much of kernel tracepoints is implemented at the C preprocessor
level, C identifiers used in TP_printk() are saved verbatim in the event
format, even when they represent compile-time constant values.
As an example, we can look at the format for the intel_pipe_enable
event:
# cat /sys/
The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():
"Do not create new tracepoint-specific helpers, because that will
confuse user-space tools that know about the TRACE_EVENT() helper
macros but will not know how to handle ones created for individual
Some display trace events use array members to store frame and scanline
counts for each pipe. However, those arrays are declared with 3 as the
hardcoded size, which cause out-of-bounds access when the trace event is
enabled on a platform that contains pipe D.
For example, when looking at the last
I recently bumped into some issues while using trace-cmd to inspect i915
display trace events. This series of patches provides fixes for them.
v2:
- Add another patch to zero-initialize frame/scanline counts.
- Add static_assert(PIPE_A == _TRACE_PIPE_A) in "Do not use ids from enum pipe
in
On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> Create a i915 private plane property for sharing the async supported
> modifiers to the user.
> UMD related discussion requesting the same
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29618#note_2487123
>
> Signed-off-
While updating the source OUI on the sink the driver should avoid
writing the OUI if it's already up-to-date to prevent the sink from
resetting itself in response to the update. On eDP - the only output
type where the OUI was updated so far - the driver ensured this by
comparing the current source
Reuse intel_dp_detect_dsc_caps() which already checks for the source's
DSC cap and retrieves the DPCD version from the DPRX caps.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 38 -
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/d
This is v3 of [1] handling a few cases where the source OUI value
written to an eDP sink could be not yet valid or could have gotten
reset after the panel power was disabled (in patches 1, 2, 4, 6, 7).
[1] https://lore.kernel.org/all/20241001123259.616486-1-imre.d...@intel.com
Imre Deak (8):
dr
If the source OUI DPCD register value matches the expected Intel OUI
value, the write timestamp doesn't get updated leaving it at the 0
initial value if the OUI wasn't written before. This can lead to an
incorrect wait duration in intel_dp_wait_source_oui(), since jiffies is
not inited to 0 in gene
The DP sink's capabilities, like DSC, may depend on the source OUI
written to the sink. On eDP this OUI value could have been reset before
the detection started if the panel power on it got disabled. Make sure
the OUI is re-written at the beginning of detection in this case, before
the sink capabil
The eDP sink's capabilities, like DSC, may depend on the source OUI
written to the sink, so ensure the OUI is written before reading out the
capabilities.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff
At least the i-tec USB-C Nano 2x Display Docking Station (containing a
Synaptics MST branch device) requires the driver to update the source
OUI DPCD registers to expose its DSC capability. Accordingly update the
OUI for all sink types (besides eDP where this has been done already).
Closes: https:
The sink's capabilities, like the DSC caps, depend on the source OUI
written to the sink's DPCD registers and so this OUI value should be
valid for the whole duration of the detection. An eDP sink will reset
this OUI value when the panel power is disabled, so prevent the
disabling - happening by de
Make sure that a DP connector detection doesn't happen in parallel
with an ongoing modeset on the connector. The reasons for this are:
- Besides reading the capabilities, EDID etc. the detection may change
the state of the sink (via the AUX bus), for instance by setting the
LTTPR mode or the s
Quoting Matt Atwood (2024-10-15 20:11:18-03:00)
>From: Matt Roper
>
>There are some minor changes to pmdemand handling on Xe3:
> - Active scalers are no longer tracked. We can simply skip the readout
> and programming of this field.
> - Active dbuf slices are no longer tracked. We should skip
Hi Ankit,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20241016]
[cannot apply to drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master
v6.12-rc3]
[If your patch is applied to the wrong git tree
On Tue, Oct 15, 2024 at 03:56:10PM +0530, Riana Tauro wrote:
> Hi Raag
>
> On 10/11/2024 4:02 PM, Raag Jadav wrote:
> > Having similar naming convention in intel-family.h and intel_device_info.h
> > results in redefinition of a few platforms. Define CPU IDs in its own file
> > to avoid this.
> >
== Series Details ==
Series: drm/i915/display: Workaround for odd panning for planar yuv (rev6)
URL : https://patchwork.freedesktop.org/series/136416/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15539 -> Patchwork_136416v6
== Series Details ==
Series: drm/i915/display: plane property for async supported modifiers
URL : https://patchwork.freedesktop.org/series/140039/
State : warning
== Summary ==
Error: dim checkpatch failed
e95cd76d20c0 drm/i915/display: plane property for async supported modifiers
-:10: WARNIN
== Series Details ==
Series: drm/i915/display: plane property for async supported modifiers
URL : https://patchwork.freedesktop.org/series/140039/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15539 -> Patchwork_140039v1
Su
Disable the support for odd x pan for even xsize for NV12
format as underrun issue is seen.
WA: 16024459452
v2: Replace HSD with WA in commit message [Suraj]
Modified the condition for handling odd panning
v3: Simplified the condition for checking hsub
Using older framework for wa as rev
59 matches
Mail list logo
