== Series Details ==
Series: Extended Wake Timeout (rev4)
URL : https://patchwork.freedesktop.org/series/142517/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15998 -> Patchwork_142517v4
Summary
---
**SUCCESS**
No
== Series Details ==
Series: Extended Wake Timeout (rev4)
URL : https://patchwork.freedesktop.org/series/142517/
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/cx0: Set ssc_enabled for c20 too
URL : https://patchwork.freedesktop.org/series/143824/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15998 -> Patchwork_143824v1
Summary
---
**FA
terse descriptions.
- Link to v8:
https://lore.kernel.org/r/20250121-hblank-v8-1-b05752f4a...@intel.com
---
.../gpu/drm/i915/display/intel_crtc_state_dump.c | 1 +
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp_mst.c| 53
On Tue, 2025-01-21 at 17:11 +0200, Ville Syrjälä wrote:
> On Tue, Jan 21, 2025 at 10:29:25AM +, Hogander, Jouni wrote:
> > On Mon, 2025-01-20 at 16:39 +0200, Ville Syrjälä wrote:
> > > On Mon, Jan 20, 2025 at 07:28:52AM +, Hogander, Jouni wrote:
> > > > On Sat, 2025-01-18 at 01:07 +0200, Vi
> Usually retimers take around 30 to 40ms to exit all devices from sleep state.
> Extended wake timeout mechanism helps to give that additional time.
>
> --v2
> -Grant the requested time only if greater than 1ms [Arun/Jani] -Reframe
> commit message [Arun]
>
> --v3
> -Move the function to drm_cor
> On Tue, 21 Jan 2025, Arun R Murthy wrote:
> > Mandate a minimum Hblank symbol cycle count between BlankingStart and
> > BlankingEnd in 8b/10b MST and 128b/132b mode.
> >
> > v2: Affine calculation/updation of min HBlank to dp_mst (Jani)
> > v3: moved min_hblank from struct intel_dp to intel_crtc
== Series Details ==
Series: drm/i915/display: Add WA_14018221282 (rev5)
URL : https://patchwork.freedesktop.org/series/141087/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15992 -> Patchwork_141087v5
Summary
---
**
Extended wake timeout request helps to give additional
time by reading the DPCD register through which sink requests the
minimal amount of time required to wake the sink up.
Source device shall keep retying the AUX tansaction till the
extended timeout that is being granted for LTTPRs from the
sink
Usually retimers take around 30 to 40ms to exit all devices from
sleep state. Extended wake timeout mechanism helps to give
that additional time.
--v2
-Grant the requested time only if greater than 1ms [Arun/Jani]
-Reframe commit message [Arun]
--v3
-Move the function to drm_core [Dmitry/Jani]
S
Add DPCD registers required to configure Extended Wake Timeout
for LTTPR.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
include/drm/display/drm_dp.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
inde
Retimers in H/w usually takes 30 to 40ms to wake up all the devices. To
get this we use the Extended Wake Time feature in which the sink device
tells us the minimum amount of time it requires to wake up and we need
to do a write to grant this request else we need to wake up within 1ms
of low power
ssc_enabled does not get set for c20 phy.
This patch makes sure we set ssc_enabled for both c10 and c20.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/
On Tue, Jan 21, 2025 at 02:14:56AM +0100, Xaver Hugl wrote:
> > +It is the responsibility of the consumer to make sure that the device or
> > +its resources are not in use by any process before attempting recovery.
> I'm not convinced this is actually doable in practice, outside of
> killing all ap
On Tue, Jan 21, 2025 at 01:59:47AM +0100, Xaver Hugl wrote:
> Hi,
>
> I experimented with using this in KWin, and
> https://invent.kde.org/plasma/kwin/-/merge_requests/7027/diffs?commit_id=6da40f1b9e2bc94615a436de4778880cee16f940
> makes it fall back to a software renderer when a rebind is require
== Series Details ==
Series: Check Scaler and DSC Prefill Latency Against Vblank (rev8)
URL : https://patchwork.freedesktop.org/series/143160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15993 -> Patchwork_143160v8
Summar
On Tue, Jan 21, 2025 at 06:10:34PM -0500, Rodrigo Vivi wrote:
On Tue, Jan 21, 2025 at 02:25:57PM -0800, Umesh Nerlige Ramappa wrote:
drm/i915/pmu as tag please...
will do
When running igt@gem_exec_balancer@individual for multiple iterations,
it is seen that the delta busyness returned by P
On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
>
> I'm pushing this soon to drm-intel-next, unless Linus want to take
> this one directly to his tree
Let's just go through the proper channels and go through the drm tree.
Unless I've issed something, I think this is only an active issue on
par
On Tue, Jan 21, 2025 at 02:25:57PM -0800, Umesh Nerlige Ramappa wrote:
drm/i915/pmu as tag please...
> When running igt@gem_exec_balancer@individual for multiple iterations,
> it is seen that the delta busyness returned by PMU is 0. The issue stems
> from a combination of 2 implementation specifi
On Tue, Jan 21, 2025 at 06:52:03AM -0800, Guenter Roeck wrote:
> The scale() functions detects invalid parameters, but continues
> its calculations anyway. This causes bad results if negative values
> are used for unsigned operations. Worst case, a division by 0 error
> will be seen if source_min =
Thank You for the series.
Tested a modeline that is not pre-computed and able to see pixel clock
calculation done correctly and the analyzer turns on:
adjusted mode: "3440x1440": 50 265250 3440 3488 3520 3600 1440 1443
1453 1474 0x48 0x9
crtc timings: clock=265250, hd=3440 hb=3440-3600 hs=3488-35
When running igt@gem_exec_balancer@individual for multiple iterations,
it is seen that the delta busyness returned by PMU is 0. The issue stems
from a combination of 2 implementation specific details:
1) gt_park is throttling __update_guc_busyness_stats() so that it does
not hog PCI bandwidth for
Quoting Patchwork (2025-01-21 18:29:38-03:00)
>== Series Details ==
>
>Series: drm/i915/cmtg: Disable the CMTG (rev7)
>URL : https://patchwork.freedesktop.org/series/142947/
>State : failure
>
>== Summary ==
>
>CI Bug Log - changes from CI_DRM_15994 -> Patchwork_142947v7
>
== Series Details ==
Series: drm/i915/cmtg: Disable the CMTG (rev7)
URL : https://patchwork.freedesktop.org/series/142947/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15994 -> Patchwork_142947v7
Summary
---
**FAILU
== Series Details ==
Series: drm/i915/cmtg: Disable the CMTG (rev7)
URL : https://patchwork.freedesktop.org/series/142947/
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/cmtg: Disable the CMTG (rev7)
URL : https://patchwork.freedesktop.org/series/142947/
State : warning
== Summary ==
Error: dim checkpatch failed
a438820e12ec drm/i915/cmtg: Disable the CMTG
-:74: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), d
The CMTG is a timing generator that runs in parallel with transcoders
timing generators and can be used as a reference for synchronization.
On PTL (display Xe3_LPD), we have observed that we are inheriting from
GOP a display configuration with the CMTG enabled. Because our driver
doesn't currently
== Series Details ==
Series: Check Scaler and DSC Prefill Latency Against Vblank (rev8)
URL : https://patchwork.freedesktop.org/series/143160/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/incl
== Series Details ==
Series: Check Scaler and DSC Prefill Latency Against Vblank (rev8)
URL : https://patchwork.freedesktop.org/series/143160/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15993 -> Patchwork_143160v8
Summar
== Series Details ==
Series: Check Scaler and DSC Prefill Latency Against Vblank (rev8)
URL : https://patchwork.freedesktop.org/series/143160/
State : warning
== Summary ==
Error: dim checkpatch failed
53b3e6d5e22c drm/i915/scaler: Add and compute scaling factors
078da48f861c drm/i915/scaler:
== Series Details ==
Series: drm/i915/backlight: Return immediately when scale() finds invalid
parameters (rev2)
URL : https://patchwork.freedesktop.org/series/143775/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15993 -> Patchwork_143775v2
==
On Mon, Jan 20, 2025 at 02:42:14PM +0100, Maarten Lankhorst wrote:
> Hey,
>
> Den 2025-01-17 kl. 23:09, skrev Rodrigo Vivi:
> > Start the xe-i915-display reconciliation by using the same
> > shutdown sequences.
> >
> > v2: include the stubs for !CONFIG_DRM_XE_DISPLAY (Kunit)
> >
> > Reviewed-by:
== Series Details ==
Series: drm/i915/backlight: Return immediately when scale() finds invalid
parameters (rev2)
URL : https://patchwork.freedesktop.org/series/143775/
State : warning
== Summary ==
Error: dim checkpatch failed
1cbbd90d5f1b drm/i915/backlight: Return immediately when scale() f
== Series Details ==
Series: drm/i915/gt: Handle INTEL_WAKEREF_DEF return value in
gen8_ggtt_bind_get_ce
URL : https://patchwork.freedesktop.org/series/143797/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15993 -> Patchwork_143797v1
==
== Series Details ==
Series: drm/i915/fbdev: Discard large BIOS framebuffers
URL : https://patchwork.freedesktop.org/series/143796/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15993 -> Patchwork_143796v1
Summary
---
Compute scaling factors and scaler user for pipe scaler if
particular scaler user is pipe scaler.
--v2:
- Fix typos. [Ankit]
- Remove FIXME tag. [Ankit]
- Should be common hscale, vscale instead of local one to
avoid garbage overwritten.
--v3:
- Separate out max_scaling information. [Ankit]
- Use
== Series Details ==
Series: drm/i915: Handle null 'fb' in 'intel_plane_atomic_check_with_state'
URL : https://patchwork.freedesktop.org/series/143795/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15992 -> Patchwork_143795v1
===
== Series Details ==
Series: drm/i915/display: Add WA_14018221282 (rev5)
URL : https://patchwork.freedesktop.org/series/141087/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15992 -> Patchwork_141087v5
Summary
---
**
On 2025-01-21 11:59 a.m., Lucas De Marchi wrote:
> On Tue, Jan 21, 2025 at 10:53:31AM -0500, Liang, Kan wrote:
>>
>>
>> On 2025-01-21 9:29 a.m., Lucas De Marchi wrote:
>>> On Mon, Jan 20, 2025 at 08:42:41PM -0500, Liang, Kan wrote:
>>> -static int i915_pmu_cpu_offline(unsigned int cpu, struc
On Tue, Jan 21, 2025 at 10:53:31AM -0500, Liang, Kan wrote:
On 2025-01-21 9:29 a.m., Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 08:42:41PM -0500, Liang, Kan wrote:
-static int i915_pmu_cpu_offline(unsigned int cpu, struct hlist_node
*node)
-{
- struct i915_pmu *pmu = hlist_entry_safe(n
On Mon, Jan 20, 2025 at 01:45:12PM +0530, Nitin Gote wrote:
> Fix all typos in files under drm/i915/gem reported by codespell tool.
>
> v2: Codespell won't catch it, but it should be
> "user defined" and not "use defined".
>
> Signed-off-by: Nitin Gote
> ---
> drivers/gpu/drm/i915/gem/i915
On 2025-01-21 9:29 a.m., Lucas De Marchi wrote:
> On Mon, Jan 20, 2025 at 08:42:41PM -0500, Liang, Kan wrote:
> -static int i915_pmu_cpu_offline(unsigned int cpu, struct hlist_node
> *node)
> -{
> - struct i915_pmu *pmu = hlist_entry_safe(node, typeof(*pmu),
> cpuhp.node);
On Fri, Jan 17, 2025 at 10:45:56AM -0600, Lucas De Marchi wrote:
> [...]
> > > > > > diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
> > > > > > index b51a2bde73e29..50cf80df51900 100644
> > > > > > --- a/drivers/gpu/drm/xe/Kconfig
> > > > > > +++ b/drivers/gpu/drm/xe/Kconfig
>
On Tue, Jan 21, 2025 at 10:29:25AM +, Hogander, Jouni wrote:
> On Mon, 2025-01-20 at 16:39 +0200, Ville Syrjälä wrote:
> > On Mon, Jan 20, 2025 at 07:28:52AM +, Hogander, Jouni wrote:
> > > On Sat, 2025-01-18 at 01:07 +0200, Ville Syrjälä wrote:
> > > > On Fri, Jan 17, 2025 at 10:20:17PM +0
The scale() functions detects invalid parameters, but continues
its calculations anyway. This causes bad results if negative values
are used for unsigned operations. Worst case, a division by 0 error
will be seen if source_min == source_max.
On top of that, after v6.13, the sequence of WARN_ON() f
On Tue, Jan 21, 2025 at 06:37:54AM +0200, Kandpal, Suraj wrote:
>
>
> > -Original Message-
> > From: Deak, Imre
> > Sent: Friday, January 17, 2025 9:09 PM
> > To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> > Cc: Kandpal, Suraj ; De Marchi, Lucas
> >
> > Subject: [
On Sat, Jan 18, 2025 at 06:47:27PM +0100, Michal Wajdeczko wrote:
>
>
> On 17.01.2025 22:57, Vinay Belgaumkar wrote:
> > Default SLPC power profile is Base(0). Power Saving mode(1)
> > has conservative up/down thresholds and is suitable for use with
> > apps that typically need to be power effici
On Mon, Jan 20, 2025 at 06:48:31PM +0200, Jani Nikula wrote:
> On Thu, 16 Jan 2025, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > intel_set_transcoder_timings() will set TRANS_VBLANK.vblank_start to 0
> > for clarity on ADL+ (non-DSI) because the hardware no longer uses that
> > value. So
On Mon, Jan 20, 2025 at 08:42:41PM -0500, Liang, Kan wrote:
-static int i915_pmu_cpu_offline(unsigned int cpu, struct hlist_node
*node)
-{
- struct i915_pmu *pmu = hlist_entry_safe(node, typeof(*pmu),
cpuhp.node);
- unsigned int target = i915_pmu_target_cpu;
-
- /*
- * Unregistering
On Tue, Jan 21, 2025 at 10:29:25AM +, Hogander, Jouni wrote:
> On Mon, 2025-01-20 at 16:39 +0200, Ville Syrjälä wrote:
> > On Mon, Jan 20, 2025 at 07:28:52AM +, Hogander, Jouni wrote:
> > > On Sat, 2025-01-18 at 01:07 +0200, Ville Syrjälä wrote:
> > > > On Fri, Jan 17, 2025 at 10:20:17PM +0
Quoting Ville Syrjälä (2025-01-16 16:31:42-03:00)
>On Wed, Jan 15, 2025 at 04:41:05PM -0300, Gustavo Sousa wrote:
>> Quoting Gustavo Sousa (2025-01-15 13:18:48-03:00)
>> >Quoting Ville Syrjälä (2025-01-15 12:07:39-03:00)
>> >>On Wed, Jan 15, 2025 at 09:44:14AM -0300, Gustavo Sousa wrote:
>> >>> Quo
On Tue, Jan 21, 2025 at 03:34:20AM +, Murthy, Arun R wrote:
> > On Wed, Jan 08, 2025 at 11:09:02AM +0530, Arun R Murthy wrote:
> > > Populate the list of formats/modifiers supported by async flip.
> > > Register a async property and expose the same to user through blob.
> > >
> > > Signed-off-b
On Sat, 18 Jan 2025 13:21:39 -0800
Linus Torvalds wrote:
> On Sat, 18 Jan 2025 at 09:49, Guenter Roeck wrote:
> >
> > No idea why the compiler would know that the values are invalid.
>
> It's not that the compiler knows tat they are invalid, but I bet what
> happens is in scale() (and possibl
On Sat, 18 Jan 2025 14:58:48 -0800
Guenter Roeck wrote:
> On 1/18/25 14:11, David Laight wrote:
> > On Sat, 18 Jan 2025 13:21:39 -0800
> > Linus Torvalds wrote:
> >
> >> On Sat, 18 Jan 2025 at 09:49, Guenter Roeck wrote:
> >>>
> >>> No idea why the compiler would know that the values are i
On Mon, 20 Jan 2025 06:15:30 -0800
Guenter Roeck wrote:
> On 1/20/25 03:21, Jani Nikula wrote:
> > On Mon, 20 Jan 2025, David Laight wrote:
> >> On Mon, 20 Jan 2025 12:48:11 +0200
> >> Jani Nikula wrote:
> >>
> >>> On Sun, 19 Jan 2025, David Laight wrote:
> On Sat, 18 Jan 2025 14:58
The function 'gen8_ggtt_bind_get_ce' previously did not handle the case
where 'intel_gt_pm_get_if_awake()' returns 'INTEL_WAKEREF_DEF'.
This value is returned when the 'intel_ref_tracker_alloc()' call within
'intel_gt_pm_get_if_awake()' fails to allocate due
to memory pressure or other constraints.
On Sat, Jan 18, 2025 at 10:11 PM David Laight
wrote:
>
> On Sat, 18 Jan 2025 13:21:39 -0800
> Linus Torvalds wrote:
>
> > On Sat, 18 Jan 2025 at 09:49, Guenter Roeck wrote:
> > >
> > > No idea why the compiler would know that the values are invalid.
> >
> > It's not that the compiler knows tat t
- Ursprüngliche Mail -
>> > This streamlines device tree and allows to anchor
>> > runtime power management on master device in all cases.
>>
>> Please explain in more detail why this is needed.
>> If this change makes the overall situation better and breaks
>> no userspace, I'm happy. :-)
On Sat, 18 Jan 2025 08:13:06 -0800
Guenter Roeck wrote:
> Hi,
>
> On Mon, Nov 18, 2024 at 07:13:31PM +, David Laight wrote:
> > Use BUILD_BUG_ON_MSG(statically_true(ulo > uhi), ...) for the sanity
> > check of the bounds in clamp().
> > Gives better error coverage and one less expansion of t
Add null pointer check before use fb.
Reported by smatch.
Signed-off-by: Lu Yao
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_
On Sat, 18 Jan 2025 09:49:21 -0800
Guenter Roeck wrote:
> On Sat, Jan 18, 2025 at 05:09:59PM +, David Laight wrote:
> > On Sat, 18 Jan 2025 08:13:06 -0800
> > Guenter Roeck wrote:
> >
> > > Hi,
> > >
> > > On Mon, Nov 18, 2024 at 07:13:31PM +, David Laight wrote:
> > > > Use BUILD_
> +It is the responsibility of the consumer to make sure that the device or
> +its resources are not in use by any process before attempting recovery.
I'm not convinced this is actually doable in practice, outside of
killing all apps that aren't the one trying to recover the GPU.
Is this just about
On Mon, 20 Jan 2025 12:48:11 +0200
Jani Nikula wrote:
> On Sun, 19 Jan 2025, David Laight wrote:
> > On Sat, 18 Jan 2025 14:58:48 -0800
> > Guenter Roeck wrote:
> >
> >> On 1/18/25 14:11, David Laight wrote:
> >> > On Sat, 18 Jan 2025 13:21:39 -0800
> >> > Linus Torvalds wrote:
> >> >
On certain 4K panels, the BIOS framebuffer
exceeds the panel's required dimensions,
leading to display corruption.
This patch introduces a validation check to address the issue.
Signed-off-by: Atharva Tiwari
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 6 +++---
1 file changed, 3 insertions(
Hi,
I experimented with using this in KWin, and
https://invent.kde.org/plasma/kwin/-/merge_requests/7027/diffs?commit_id=6da40f1b9e2bc94615a436de4778880cee16f940
makes it fall back to a software renderer when a rebind is required to
recover the GPU.
Making it also survive the rebind properly is mo
On Sat, 18 Jan 2025 10:36:11 -0800
Guenter Roeck wrote:
> On 1/18/25 10:09, David Laight wrote:
> > On Sat, 18 Jan 2025 09:49:21 -0800
> > Guenter Roeck wrote:
> >
> >> On Sat, Jan 18, 2025 at 05:09:59PM +, David Laight wrote:
> >>> On Sat, 18 Jan 2025 08:13:06 -0800
> >>> Guenter Roeck
== Series Details ==
Series: drm/i915/dp: Correct max compressed bpp bounds by using link bpp (rev2)
URL : https://patchwork.freedesktop.org/series/143597/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15972 -> Patchwork_143597v2
===
/drivers/gpu/drm/i915/i915_reg.h
> @@ -3197,6 +3197,10 @@
> #define _TRANS_DP2_VFREQLOW_D0x630a8
> #define TRANS_DP2_VFREQLOW(trans)_MMIO_TRANS(trans,
> _TRANS_DP2_VFREQLOW_A, _TRANS_DP2_VFREQLOW_B)
>
> +#define _DP_MIN_HBLANK_CTL_A 0x600ac
> +#define _DP_MIN_HBLANK_CTL_B 0x610ac
> +#define DP_MIN_HBLANK_CTL(trans) _MMIO_TRANS(trans,
> _DP_MIN_HBLANK_CTL_A, _DP_MIN_HBLANK_CTL_B)
> +
> /* SNB eDP training params */
> /* SNB A-stepping */
> #define EDP_LINK_TRAIN_400MV_0DB_SNB_A (0x38 << 22)
>
> ---
> base-commit: a15d2a84505eed8dbb58911147e44752734f3a88
> change-id: 20250121-hblank-ad8ce892eb3a
>
> Best regards,
--
Jani Nikula, Intel
On Tue, 21 Jan 2025, Atharva Tiwari wrote:
> On certain 4K panels, the BIOS framebuffer
> exceeds the panel's required dimensions,
> leading to display corruption.
> This patch introduces a validation check to address the issue.
>
> Signed-off-by: Atharva Tiwari
See [1], [2], and [3].
Please ad
== Series Details ==
Series: drm/i915/xe3: FBC Dirty rect feature support (rev4)
URL : https://patchwork.freedesktop.org/series/141527/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/141527/revisions/4/mbox/ not
applied
Applying: drm/i915/display:
It's fixing messing screen of PSR issue on lnl after screen is inverted.
xe issue: #3992.
Tested-by: Aaron Ma
Hey,
On 2025-01-21 12:33, Aaron Ma wrote:
It's fixing messing screen of PSR issue on lnl after screen is inverted.
xe issue: #3992.
Tested-by: Aaron Ma
You just missed the push by an hour. :-)
Cheers,
~Maarten
On Tue, Jan 21, 2025 at 12:10:25PM +0100, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> CC sfr
>
> On Tue, Jan 21, 2025 at 11:44 AM Dmitry Baryshkov
> wrote:
> > On Tue, 21 Jan 2025 at 11:13, Geert Uytterhoeven
> > wrote:
> > > On Tue, Jan 7, 2025 at 12:31 PM Dmitry Baryshkov
> > > wrote:
> > >
Hi Dmitry,
CC sfr
On Tue, Jan 21, 2025 at 11:44 AM Dmitry Baryshkov
wrote:
> On Tue, 21 Jan 2025 at 11:13, Geert Uytterhoeven wrote:
> > On Tue, Jan 7, 2025 at 12:31 PM Dmitry Baryshkov
> > wrote:
> > > On Sat, 14 Dec 2024 15:37:04 +0200, Dmitry Baryshkov wrote:
> > > > While working on the ge
On Tue, 21 Jan 2025 at 11:13, Geert Uytterhoeven wrote:
>
> Hi Dmitry,
>
> On Tue, Jan 7, 2025 at 12:31 PM Dmitry Baryshkov
> wrote:
> > On Sat, 14 Dec 2024 15:37:04 +0200, Dmitry Baryshkov wrote:
> > > While working on the generic mode_valid() implementation for the HDMI
> > > Connector framewor
On Mon, 2025-01-20 at 16:39 +0200, Ville Syrjälä wrote:
> On Mon, Jan 20, 2025 at 07:28:52AM +, Hogander, Jouni wrote:
> > On Sat, 2025-01-18 at 01:07 +0200, Ville Syrjälä wrote:
> > > On Fri, Jan 17, 2025 at 10:20:17PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Jan 09, 2025 at 09:31:37AM +020
On Tue, Jan 21, 2025 at 11:35:21AM +0530, Suraj Kandpal wrote:
> Extended wake timeout request helps to give additional
> time by reading the DPCD register through which sink requests the
> minimal amount of time required to wake the sink up.
> Source device shall keep retying the AUX tansaction t
On Mon, 2025-01-13 at 11:22 +, Kahola, Mika wrote:
> > -Original Message-
> > From: Intel-xe On Behalf
> > Of Jouni
> > Högander
> > Sent: Thursday, 9 January 2025 12.36
> > To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> > Cc: Hogander, Jouni
> > Subject: [PATCH
== Series Details ==
Series: drm/i915/dp: Guarantee a minimum HBlank time (rev9)
URL : https://patchwork.freedesktop.org/series/139267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15986 -> Patchwork_139267v9
Summary
-
Hi Dmitry,
On Tue, Jan 7, 2025 at 12:31 PM Dmitry Baryshkov
wrote:
> On Sat, 14 Dec 2024 15:37:04 +0200, Dmitry Baryshkov wrote:
> > While working on the generic mode_valid() implementation for the HDMI
> > Connector framework I noticed that unlike other DRM objects
> > drm_connector accepts non-
On Fri, 2025-01-17 at 14:49 +0200, Ville Syrjälä wrote:
> On Tue, Jan 14, 2025 at 02:07:16PM +0200, Vinod Govindapillai wrote:
> > If FBC is already active, we don't need to call FBC activate
> > routine again during the post plane update. As this will
> > explicitly call the nuke and also rewrite
== Series Details ==
Series: drm/i915/backlight: Return immediately when scale() finds invalid
parameters
URL : https://patchwork.freedesktop.org/series/143775/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15986 -> Patchwork_143775v1
=
== Series Details ==
Series: drm/i915/backlight: Return immediately when scale() finds invalid
parameters
URL : https://patchwork.freedesktop.org/series/143775/
State : warning
== Summary ==
Error: dim checkpatch failed
db85a8427347 drm/i915/backlight: Return immediately when scale() finds in
On Mon, 20 Jan 2025, Guenter Roeck wrote:
> The scale() functions detects invalid parameters, but continues
> its calculations anyway. This causes bad results if negative values
> are used for unsigned operations. Worst case, a division by 0 error
> will be seen if source_min == source_max.
>
> On
84 matches
Mail list logo