On Thu, 23 Jan 2025, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 8 Jan 2025 12:16:50 +1100 Stephen Rothwell
> wrote:
>>
>> On Mon, 6 Jan 2025 13:03:48 +1100 Stephen Rothwell
>> wrote:
>> >
>> > Today's linux-next merge of the drm-intel tree got a conflict in:
>> >
>> > drivers/gpu/drm/i91
On 20/01/2025 22:57, Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 10:08:39AM -0500, Liang, Kan wrote:
On 2025-01-16 5:24 p.m., Lucas De Marchi wrote:
Since commit 4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with
a scope"), there's generic support for system-wide counters and
in
On Wed, 22 Jan 2025, "Govindapillai, Vinod"
wrote:
> On Wed, 2025-01-22 at 12:47 +0200, Jani Nikula wrote:
>> On Wed, 22 Jan 2025, Vinod Govindapillai
>> wrote:
>> > Programming of the dirty rectangle coordinates should happen
>> > within the scope of DSB prepare and finish calls. So call the
>
On Thu, Jan 23, 2025 at 12:41:26PM +0200, Joonas Lahtinen wrote:
> Quoting Rodrigo Vivi (2025-01-21 18:14:51)
> > 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
Hi,
https://patchwork.freedesktop.org/series/142947/ - Re-reported.
i915.CI.BAT - Re-reported.
Thanks,
Ravali.
-Original Message-
From: I915-ci-infra On Behalf Of
Gustavo Sousa
Sent: 23 January 2025 03:13
To: i915-ci-in...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
Cc: int
This reverts commit 835443da6f50d9516b58bba5a4fdf9e563d961c7.
Kernel taint information is present in dmesg already, and in
the case of an unrecoverable error, the CI restarts the device
accordingly. Raising an error causes intentional error injection
to report an undesired error notification.
Sig
On Wed, 22 Jan 2025 at 13:25, Joel Granados wrote:
>
> On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> >
> > Hi Joel,
> >
> > > Add the const qualifier to all the ctl_tables in the tree except for
> > > watchdo
Hello,
On Mon, 4 Nov 2024 at 23:28, Rodrigo Vivi wrote:
>
> On Mon, Nov 04, 2024 at 02:09:46PM +0200, Giedrius Statkevičius wrote:
> > Hello,
> >
> > Kind ping.
>
> There was a pipe underun in CI... I honestly don't believe this patch is
> causing it, but anyway I decided to trigger a retest ther
On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
Hi Joel,
> Add the const qualifier to all the ctl_tables in the tree except for
> watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> drivers/inifi
Quoting Rodrigo Vivi (2025-01-21 18:14:51)
> 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-o
On Wed, 22 Jan 2025, Suraj Kandpal wrote:
> 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 [Aru
The Forcewake timeout issue has been observed on Gen 12.0 and above. To address
this,
disable Render Power-Gating (RPG) during live self-tests for these generations.
The temporary workaround 'drm/i915/mtl: do not enable render power-gating on
MTL'
disables RPG globally, which is unnecessary since
On Thu, 23 Jan 2025, Jani Nikula wrote:
> From: Gustavo Sousa
>
> The header drm_print.h uses members of struct drm_device pointers, as
> such, it should include drm_device.h to let the compiler know the full
> type definition.
>
> Without such include, users of drm_print.h that don't explicitly
On 17.01.2025 19:06, Gustavo Sousa wrote:
> The DMC wakelock code needs to keep track of register offsets that need
> the wakelock for proper access. If one of the necessary offsets are
> missed, then the failure in asserting the wakelock is very likely to
> cause problems down the road.
>
> A mis
Quoting Jani Nikula (2025-01-23 12:14:31-03:00)
>On Thu, 23 Jan 2025, Jani Nikula wrote:
>> From: Gustavo Sousa
>>
>> The header drm_print.h uses members of struct drm_device pointers, as
>> such, it should include drm_device.h to let the compiler know the full
>> type definition.
>>
>> Without s
== Series Details ==
Series: drm/i915: Disable RPG during live selftest
URL : https://patchwork.freedesktop.org/series/143886/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16008 -> Patchwork_143886v1
Summary
---
**F
This reverts commit 835443da6f50d9516b58bba5a4fdf9e563d961c7.
- turns out that logging with gt_err() causes CI to pick up an error
even in intentional error injects,
- the unintentional (real) errors are already reported correctly by CI,
- a gt wedge is already being logged without this patch, s
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Add a static inline helper to convert struct drm_device to struct
device, with the main benefit bein
From: Gustavo Sousa
The header drm_print.h uses members of struct drm_device pointers, as
such, it should include drm_device.h to let the compiler know the full
type definition.
Without such include, users of drm_print.h that don't explicitly need
drm_device.h would bump into build errors and be
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(sched, ...) to dev_err(sched->dev, ...) and
similar. This matches current usage, as
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(host, ...) to dev_err(host->dev, ...). This matches
current usage, as struct drm_dev
Quoting Luca Coelho (2025-01-22 07:19:35-03:00)
>On Fri, 2025-01-17 at 19:06 -0300, Gustavo Sousa wrote:
>> We already have a way of finding the set of untracked offsets for which
>> there has been one or more MMIO operations via the
>> "intel_dmc_wl/untracked" debugfs interface.
>>
>> However, in
On Thu, Jan 23, 2025 at 03:41:08PM +, Borah, Chaitanya Kumar wrote:
> Hello Al,
>
> Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
>
> This mail is regarding a regression we are seeing in our CI runs[1] on
> linux-next repository.
>
> Since the version next-2
Fix all cases that pass something other than struct drm_device to the
drm_device based logging helpers, and add strict type checking.
Gustavo Sousa (1):
drm/print: Include drm_device.h
Jani Nikula (4):
drm/mipi-dsi: stop passing non struct drm_device to drm_err() and
friends
drm/rockchi
The expectation is that the struct drm_device based logging helpers get
passed an actual struct drm_device pointer rather than some random
struct pointer where you can dereference the ->dev member.
Convert drm_err(hdmi, ...) to dev_err(hdmi->dev, ...). This matches
current usage, but drops "[drm]
On Thu, Jan 23, 2025 at 06:06:29PM +, Tvrtko Ursulin wrote:
On 23/01/2025 16:27, Lucas De Marchi wrote:
On Thu, Jan 23, 2025 at 09:43:35AM +, Tvrtko Ursulin wrote:
On 20/01/2025 22:57, Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 10:08:39AM -0500, Liang, Kan wrote:
On 2025-01-16
== Series Details ==
Series: Revert "drm/i915/gt: Log reason for setting TAINT_WARN at reset" (rev2)
URL : https://patchwork.freedesktop.org/series/143885/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16009 -> Patchwork_143885v2
===
Quoting Luca Coelho (2025-01-22 06:06:00-03:00)
>On Fri, 2025-01-17 at 19:06 -0300, Gustavo Sousa wrote:
>> The DMC wakelock code needs to keep track of register offsets that need
>> the wakelock for proper access. If one of the necessary offsets are
>> missed, then the failure in asserting the wak
On Wed, Jan 22, 2025 at 04:41:32PM +0200, Jani Nikula wrote:
> Add CONFIG_DRM_HEADER_TEST to ensure drm headers are self-contained and
> pass kernel-doc. And for starters, fix one header that this catches.
>
> Jani Nikula (2):
> drm/client: include types.h to make drm_client_event.h self-contain
Hello Al,
Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.
This mail is regarding a regression we are seeing in our CI runs[1] on
linux-next repository.
Since the version next-20250120 [2], we are seeing the following regression
```
On 10.01.2025 16:46, Krzysztof Karas wrote:
GuC code uses in_atomic() function to determine if the current
context is atomic. As noted by the function's description it
should not be used in driver code, as it is not guaranteed to
determine atomicity correctly in every instance. This is also
poin
On Thu Jan 23, 2025 at 1:54 PM UTC, Krzysztof Niemiec wrote:
> Hi Sebastian,
>
> On 2025-01-23 at 11:33:00 GMT, Sebastian Brzezinka wrote:
>> This reverts commit 835443da6f50d9516b58bba5a4fdf9e563d961c7.
>>
>> Kernel taint information is present in dmesg already, and in
>> the case of an unrecover
== Series Details ==
Series: drm/i915/guc: Always disable interrupt ahead of synchronize_irq
URL : https://patchwork.freedesktop.org/series/143894/
State : warning
== Summary ==
Error: dim checkpatch failed
e77f8a990b84 drm/i915/guc: Always disable interrupt ahead of synchronize_irq
-:7: WARNI
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
On Thu, Jan 23, 2025 at 05:09:10PM +0200, Jani Nikula wrote:
> The expectation is that the struct drm_device based logging helpers get
> passed an actual struct drm_device pointer rather than some random
> struct pointer where you can dereference the ->dev member.
>
> Convert drm_err(sched, ...) t
== Series Details ==
Series: drm/i915/guc: Always disable interrupt ahead of synchronize_irq
URL : https://patchwork.freedesktop.org/series/143894/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16009 -> Patchwork_143894v1
S
== Series Details ==
Series: drm: strict type checking for drm_device based logging helpers
URL : https://patchwork.freedesktop.org/series/143893/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16009 -> Patchwork_143893v1
Su
The purpose of synchronize_irq is to wait for any pending IRQ handlers for the
interrupt to complete, if synchronize_irq called before interrupt disabled, an
tiny timing window created, where no more pending IRQ, but interrupt not
disabled yet. Meanwhile, if the interrupt event happened in this tim
On Thu, Jan 23, 2025 at 09:43:35AM +, Tvrtko Ursulin wrote:
On 20/01/2025 22:57, Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 10:08:39AM -0500, Liang, Kan wrote:
On 2025-01-16 5:24 p.m., Lucas De Marchi wrote:
Since commit 4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with
a
On 23/01/2025 16:27, Lucas De Marchi wrote:
On Thu, Jan 23, 2025 at 09:43:35AM +, Tvrtko Ursulin wrote:
On 20/01/2025 22:57, Lucas De Marchi wrote:
On Mon, Jan 20, 2025 at 10:08:39AM -0500, Liang, Kan wrote:
On 2025-01-16 5:24 p.m., Lucas De Marchi wrote:
Since commit 4ba4f1afb6a9 ("p
Quoting Vivekanandan, Balasubramani (2025-01-23 13:11:03-03:00)
>On 17.01.2025 19:06, Gustavo Sousa wrote:
>> The DMC wakelock code needs to keep track of register offsets that need
>> the wakelock for proper access. If one of the necessary offsets are
>> missed, then the failure in asserting the w
== Series Details ==
Series: drm: strict type checking for drm_device based logging helpers
URL : https://patchwork.freedesktop.org/series/143893/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Quoting Luca Coelho (2025-01-22 07:24:43-03:00)
>On Fri, 2025-01-17 at 19:06 -0300, Gustavo Sousa wrote:
>> We use a spinlock to protect DMC wakelock debugfs data, since it is also
>> accessed by the core DMC wakelock logic. Taking the spinlock when the
>> debugfs is not in use introduces a small b
Hi Sebastian,
On 2025-01-23 at 11:33:00 GMT, Sebastian Brzezinka wrote:
> This reverts commit 835443da6f50d9516b58bba5a4fdf9e563d961c7.
>
> Kernel taint information is present in dmesg already, and in
> the case of an unrecoverable error, the CI restarts the device
> accordingly. Raising an error
== Series Details ==
Series: Revert "drm/i915/gt: Log reason for setting TAINT_WARN at reset"
URL : https://patchwork.freedesktop.org/series/143885/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16008 -> Patchwork_143885v1
== Series Details ==
Series: drm/i915: Disable RPG during live selftest
URL : https://patchwork.freedesktop.org/series/143886/
State : warning
== Summary ==
Error: dim checkpatch failed
5f796f393df5 drm/i915: Disable RPG during live selftest
-:6: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum
On 1/20/2025 10:52 PM, Mitul Golani wrote:
Compute and check if dsc and scaler prefill latency is sufficient with
respect to vblank.
Previous Revision Reference:
https://patchwork.freedesktop.org/series/141203/
https://patchwork.freedesktop.org/series/142745/
Mitul Golani (7):
drm/i915/scale
On Wed, Jan 22, 2025 at 01:15:31PM +0200, Giedrius Statkevičius wrote:
> Hello,
>
> On Mon, 4 Nov 2024 at 23:28, Rodrigo Vivi wrote:
> >
> > On Mon, Nov 04, 2024 at 02:09:46PM +0200, Giedrius Statkevičius wrote:
> > > Hello,
> > >
> > > Kind ping.
> >
> > There was a pipe underun in CI... I hones
The Forcewake timeout issue has been observed on Gen 12.0 and above. To address
this,
disable Render Power-Gating (RPG) during live self-tests for these generations.
The temporary workaround 'drm/i915/mtl: do not enable render power-gating on
MTL'
disables RPG globally, which is unnecessary since
On 1/22/2025 11:00 AM, Suraj Kandpal wrote:
ssc_enabled does not get set for c20 phy.
This patch makes sure we set ssc_enabled for both c10 and c20.
Remove 'patch'.
Add Bspec: 74491
Signed-off-by: Suraj Kandpal
LGTM. With suggested changes, this is:
Reviewed-by: Ankit Nautiyal
---
dr
== Series Details ==
Series: drm/i915/pmu: Fix zero delta busyness issue
URL : https://patchwork.freedesktop.org/series/143900/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16011 -> Patchwork_143900v1
Summary
---
**
>From eDP 1.5 we are supposed to use the VESA pathways to control
brightness. But still did not have the Nits brightness control coded
in. This series enables NITS based backlight control over AUX using
VESA pathways.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3669
Signed-off-by
Add the eDP revision bit value for 1.5.
Spec: eDPv1.5 Table 16-5
Signed-off-by: Suraj Kandpal
---
include/drm/display/drm_dp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index a6f8b098c56f..76162ad3b152 100644
--- a/include/drm
eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 8 +++-
1 file changed, 7 insertions(+),
Check if we are capable of controlling brightness via Nits which
is dependant on PANEL_LUMINANCE_OVERRIDE and SMOOTH_BRIGHTNESS
capablility being set.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp_aux_backlight
Create a function that fills in the value for
PANEL_TARGET_LUMINANCE_VALUE which helps in changing the brightness in
NITS using VESA interface.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/
Modify backlight setup function for VESA interface to take into
account the NITS based brightness.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 97 +++
1 file changed, 57 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display
Enable Nits based brightness by writing the PANEL_LUMINANCE_CONTROL
bit and set the correct register to change brightness.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/
Modify vesa_get_brightness function to take into account nits_support
and based on that read the appropriate register and return the value.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 20 +++
1 file changed, 20 insertions(+)
diff --git a/driv
Add documentation for device wedged event in a new 'Device wedging'
chapter. The describes basic definitions, prerequisites and consumer
expectations along with an example.
v8: Improve documentation (Christian, Rodrigo)
v9: Add prerequisites section (Christian)
v10: Clarify mmap cleanup and cons
Introduce device wedged event, which notifies 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 and has become unrecoverable from driver context. Purpose of
this implementation is
This was previously attempted as xe specific reset uevent but dropped
in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
as part of refactoring.
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
W
From: André Almeida
Use DRM's device wedged event to notify userspace that a reset had
happened. For now, only use `none` method meant for telemetry
capture.
In the future we might want to report a recovery method if the reset didn't
succeed.
Acked-by: Shashank Sharma
Signed-off-by: André Alme
This series introduces device wedged event in DRM subsystem and uses it
in xe, i915 and amdgpu drivers. Detailed description in commit message.
This was earlier attempted as xe specific uevent in v1 and v2 on [1].
Similar work by André Almeida on [2].
Wedged event support for amdgpu by André Almei
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
With this in place, userspace will be notified of wedged device on
gt reset failure.
Signed-off-by: Raag Jadav
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/d
65 matches
Mail list logo
