== Series Details ==
Series: drm/i915: Fix Memory BW formulae for ADL-P
URL : https://patchwork.freedesktop.org/series/96635/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10852_full -> Patchwork_21530_full
Summary
---
Hi Jani,
On Fri, 05 Nov 2021 13:03:43 +0200 Jani Nikula wrote:
>
> I probably should have pushed c4f08d7246a5 ("drm/locking: fix
> __stack_depot_* name conflict") to drm-misc-next-fixes.
Please do so as builds will start failing otherwise :-(
--
Cheers,
Stephen Rothwell
pgpa2iVfhrIzA.pgp
== Series Details ==
Series: drm/i915: Fix Memory BW formulae for ADL-P
URL : https://patchwork.freedesktop.org/series/96635/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10852 -> Patchwork_21530
Summary
---
The earlier update to BW formulae broke ADL-P. Include
GEN13 to use TGL path for BW parameters.
Fixes: c64a9a7c05be drm/i915: Update memory bandwidth formulae
Cc: Matt Roper
Reported-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_bw.c | 2
== Series Details ==
Series: drm/i915: Call intel_update_active_dpll() for both bigjoiner pipes
URL : https://patchwork.freedesktop.org/series/96633/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10851_full -> Patchwork_21529_full
== Series Details ==
Series: drm/i915: Call intel_update_active_dpll() for both bigjoiner pipes
URL : https://patchwork.freedesktop.org/series/96633/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10851 -> Patchwork_21529
On Thu, 2021-11-04 at 06:40 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/display/adlp: Disable underrun recovery
> URL: https://patchwork.freedesktop.org/series/96548/
> State:success
> Details:
>
== Series Details ==
Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
(rev11)
URL : https://patchwork.freedesktop.org/series/95127/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10850_full -> Patchwork_21527_full
From: Ville Syrjälä
Currently we're only calling intel_update_active_dpll() for the
bigjoiner master pipe but not for the slave. With TC ports this
leads to the two pipes end up trying to use different PLLs
(TC vs. TBT). What's worse we're enabling the PLL that didn't get
== Series Details ==
Series: use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace (rev2)
URL : https://patchwork.freedesktop.org/series/96327/
State : failure
== Summary ==
Applying: dyndbg: add DEFINE_DYNAMIC_DEBUG_BITGRPS macro and callbacks
Applying: drm: fix doc grammar
Applying: amdgpu:
Hi,
On Fri, Nov 5, 2021 at 11:34 AM Lyude Paul wrote:
>
> As it turns out, apparently some machines will actually leave additional
> backlight functionality like dynamic backlight control on before the OS
> loads. Currently we don't take care to disable unsupported features when
> writing back
== Series Details ==
Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
(rev11)
URL : https://patchwork.freedesktop.org/series/95127/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10850 -> Patchwork_21527
With the recent addition of pr_debug to tracefs via +T flag, we now
want to add drm.trace; like its model: drm.debug, it maps bits to
pr_debug categories, but this one enables/disables writing to tracefs
(iff CONFIG_TRACING).
Do this by:
1. add flags to dyndbg_bitmap_param, holds "p" or "T" to
Sean Paul proposed, in:
https://patchwork.freedesktop.org/series/78133/
drm/trace: Mirror DRM debug logs to tracefs
His patchset's objective is to be able to independently steer some of
the drm.debug stream to an alternate tracing destination, by splitting
drm_debug_enabled() into syslog & trace
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
DRM_DEBUG*(8 names). There are thousands of these callsites, each
categorized in this systematized way.
These callsites can be enabled at runtime by their
The gvt component of this driver has ~120 pr_debugs with formats using
one of 9 fixed string prefixes, which are quite similar to those
enumerated in DRM debug categories. Following the interface model of
drm.debug, add a parameter to map bits to these format prefixes.
static struct
add sysfs knobs to enable modules' pr_debug()s ---> tracefs
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 8
drivers/gpu/drm/drm_print.c| 13 ++---
drivers/gpu/drm/i915/intel_gvt.c | 15 ---
3 files
Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg"
branch.
Then convert the "dyndbg" branch's code to a macro, so that the
pr_debug() get its callsite info from the invoking function, instead
of from
logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these already use DRM debug API, so are controllable using
drm.debug, but others use a bare pr_debug("$prefix: .."), with 1 of 13
different class-prefixes matching [:uppercase:]
Use DEFINE_DYNAMIC_DEBUG_BITGRPS to create a
Taking embedded spaces out of existing prefixes makes them more easily
searchable; simplifying the extra quoting needed otherwise:
$> echo format "^gvt: core:" +p >control
Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched
allocates and initializes ...
Signed-off-by: Jim Cromie
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 0cd95953cdf5..4b29261c4537 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@
DEFINE_DYNAMIC_DEBUG_BITGRPS(fsname, var, bitmap_desc, bitmap)
allows users to create a drm.debug style (bitmap) sysfs interface,
mapping each bit to a group of pr_debugs, matching on their formats.
This works well when the formats systematically include a prefix
string such as ERR|WARN|INFO,
Hi Jason, Greg, DRM-everyone,
This patchset has 3 separate but related parts:
1. DEFINE_DYNAMIC_DEBUG_BITGRPS [patch 1/10]
Declares DRM.debug style bitmap, bits control pr_debugs by matching formats
Adds callback to translate bits to $cmd > dynamic_debug/control
This could obsolete
== Series Details ==
Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
(rev11)
URL : https://patchwork.freedesktop.org/series/95127/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
== Series Details ==
Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
(rev11)
URL : https://patchwork.freedesktop.org/series/95127/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
87f25e6e4d96 drm/i915: Add support for panels with VESA backlights
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks
URL : https://patchwork.freedesktop.org/series/96593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10841_full -> Patchwork_21521_full
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have
Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Reviewed-by: Karol Herbst
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c
This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us
On Fri, Nov 05, 2021 at 05:44:21PM +, Souza, Jose wrote:
> On Fri, 2021-11-05 at 15:46 +0200, Ville Syrjälä wrote:
> > On Thu, Nov 04, 2021 at 05:56:52PM +, Souza, Jose wrote:
> > > On Thu, 2021-11-04 at 16:10 +0200, Ville Syrjälä wrote:
> > > > On Tue, Nov 02, 2021 at 12:32:14PM -0700,
On Fri, 2021-11-05 at 15:46 +0200, Ville Syrjälä wrote:
> On Thu, Nov 04, 2021 at 05:56:52PM +, Souza, Jose wrote:
> > On Thu, 2021-11-04 at 16:10 +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 02, 2021 at 12:32:14PM -0700, José Roberto de Souza wrote:
> > > > Changing the buffer in the middle
On Wed, Nov 03, 2021 at 06:08:58PM -0700, José Roberto de Souza wrote:
> It was also defeatured for ADL-P and other platforms.
>
> BSpec: 55424
> Signed-off-by: José Roberto de Souza
Reviewed-by: Ville Syrjälä
Can you also nuke the now pointless bubble counter programming
as well?
> ---
>
Filed below issue and re-reported.
https://gitlab.freedesktop.org/drm/intel/-/issues/4445
igt@i915_selftest@live@migrate - dmesg-warn - WARNING: held lock freed!
Lakshmi.
From: Thomas Hellström
Sent: Thursday, November 4, 2021 11:40 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks
URL : https://patchwork.freedesktop.org/series/96593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10841 -> Patchwork_21521
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks
URL : https://patchwork.freedesktop.org/series/96615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10846_full -> Patchwork_21526_full
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks
URL : https://patchwork.freedesktop.org/series/96615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10846 -> Patchwork_21526
Hi, gentle ping on this. Is it something that could go through the tip
tree?
thanks
Lucas De Marchi
On Thu, Oct 21, 2021 at 11:15:11AM -0700, Lucas De Marchi wrote:
PAGE_KERNEL_IO is only defined for x86 and nowadays is the same as
PAGE_KERNEL. It was different for some time, OR'ing a
== Series Details ==
Series: drm/i915/gem: Fix gem_madvise for ttm+shmem objects
URL : https://patchwork.freedesktop.org/series/96611/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10846_full -> Patchwork_21525_full
On 05/11/2021 13:03, Thomas Hellström wrote:
Gem-TTM objects that are backed by shmem might have populated
page-vectors without having the Gem pages set. Those objects
aren't moved to the correct shrinker / purge list by the
gem_madvise. Furthermore they are purged directly on
MADV_DONTNEED
Some selftests assume that nothing will attempt to grab these bitlocks
while they are held by the selftests. With GuC, for example, that is
not true because the hanging workloads may cause the GuC code to attempt
to grab them for a global reset, and that may cause it to end up
sleeping on the bit
The taint aborts the CI test runner. Skip the affected GEM_TRACE_DUMP()
that taints the kernel to allow CI to proceed.
There has been a suggestion to also remove the intel_gt_set_wedged() and
return -EINTR to allow also skipped subtests to proceed but that might and
would probably clash with the
== Series Details ==
Series: drm/i915/gem: Fix gem_madvise for ttm+shmem objects
URL : https://patchwork.freedesktop.org/series/96611/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10846 -> Patchwork_21525
Summary
---
On Thu, Nov 04, 2021 at 05:56:52PM +, Souza, Jose wrote:
> On Thu, 2021-11-04 at 16:10 +0200, Ville Syrjälä wrote:
> > On Tue, Nov 02, 2021 at 12:32:14PM -0700, José Roberto de Souza wrote:
> > > Changing the buffer in the middle of the scanout then entering an
> > > period of flip idleness
On Thu, 04 Nov 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Bunch of refactoring and cleanups, mainly as prep work
> for introducing multiple FBC instances in the future.
Eyeballed through the series, and I like all of it. Really nice.
Acked-by: Jani Nikula
>
> Ville Syrjälä (17):
>
Gem-TTM objects that are backed by shmem might have populated
page-vectors without having the Gem pages set. Those objects
aren't moved to the correct shrinker / purge list by the
gem_madvise. Furthermore they are purged directly on
MADV_DONTNEED rather than waiting for the shrinker to do that.
Hi
Am 05.11.21 um 13:00 schrieb Javier Martinez Canillas:
On 11/5/21 11:04, Jani Nikula wrote:
On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
[snip]
Do you envision other condition that could be added later to disable a
DRM driver ? Or do you think that just from a code readability
On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective
> > structure for the HDR planes.
> >
> >
On 11/5/21 11:04, Jani Nikula wrote:
> On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
[snip]
>>
>> Do you envision other condition that could be added later to disable a
>> DRM driver ? Or do you think that just from a code readability point of
>> view makes worth it ?
>
> Taking a step
Hi,
On Fri, Nov 05, 2021 at 01:03:43PM +0200, Jani Nikula wrote:
> On Fri, 05 Nov 2021, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Mon, 1 Nov 2021 19:42:23 +1100 Stephen Rothwell
> > wrote:
> >>
> >> On Fri, 15 Oct 2021 20:26:48 +1100 Stephen Rothwell
> >> wrote:
> >> >
> >> > After
On Thu, Nov 04, 2021 at 12:27:56PM -0400, Harry Wentland wrote:
>
>
> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > On Wed, 3 Nov 2021 11:08:13 -0400
> > Harry Wentland wrote:
> >
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Existing LUT precision structure is having only 16 bit
> >>>
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks (rev2)
URL : https://patchwork.freedesktop.org/series/96602/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10845_full ->
On Fri, 05 Nov 2021, Ville Syrjälä wrote:
> On Thu, Nov 04, 2021 at 06:18:57PM +0200, Jani Nikula wrote:
>> Unify audio init/cleanup paths wrt LPE audio, and base the logic on the
>> return values from LPE audio calls. Move the platform device check on
>> cleanup to intel_lpe_audio.c, thereby
On Fri, 05 Nov 2021, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 1 Nov 2021 19:42:23 +1100 Stephen Rothwell
> wrote:
>>
>> On Fri, 15 Oct 2021 20:26:48 +1100 Stephen Rothwell
>> wrote:
>> >
>> > After merging the drm-misc tree, today's linux-next build (arm
>> > multi_v7_defconfig) failed
On Thu, Nov 04, 2021 at 06:18:58PM +0200, Jani Nikula wrote:
> Follow the filename based prefix naming.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_audio.h | 2 +-
>
On Thu, Nov 04, 2021 at 06:18:57PM +0200, Jani Nikula wrote:
> Unify audio init/cleanup paths wrt LPE audio, and base the logic on the
> return values from LPE audio calls. Move the platform device check on
> cleanup to intel_lpe_audio.c, thereby limiting all audio.lpe substruct
> access to that
Hi
Am 05.11.21 um 10:48 schrieb Javier Martinez Canillas:
Hello Thomas,
On 11/5/21 09:43, Thomas Zimmermann wrote:
Hi
Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
Hello Jani,
On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ *
On Thu, Nov 04, 2021 at 05:15:43PM -0400, Ilia Mirkin wrote:
> On Thu, Nov 4, 2021 at 4:03 PM Mark Yacoub wrote:
> >
> > From: Mark Yacoub
> >
> > [Why]
> > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> > or Degamma props in the new CRTC state, allowing any invalid
On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
> Hello Thomas,
>
> On 11/5/21 09:43, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
>>> Hello Jani,
>>>
>>> On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks (rev2)
URL : https://patchwork.freedesktop.org/series/96602/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10845 -> Patchwork_21524
On 11/5/21 10:39, Thomas Zimmermann wrote:
[snip]
+obj-$(CONFIG_VGA_CONSOLE) += drm_nomodeset.o
+
>>>
>>> This now depends on the VGA textmode console. Even if you have no VGA
>>> console, you'd want drm_nomodeset.o. Simpledrm might be built-in and can
>>> provide graphics.
On 11/5/21 10:00, Thomas Zimmermann wrote:
[snip]
>> +
>> +static int __init disable_modeset(char *str)
>> +{
>> +drm_nomodeset = true;
>> +
>> +pr_warn("You have booted with nomodeset. This means your GPU drivers
>> are DISABLED\n");
>> +pr_warn("Any video related functionality
Hello Thomas,
On 11/5/21 09:43, Thomas Zimmermann wrote:
> Hi
>
> Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
>> Hello Jani,
>>
>> On 11/4/21 20:57, Jani Nikula wrote:
>>> On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ * drm_drv_enabled - Checks if a DRM driver
Hi
Am 05.11.21 um 10:22 schrieb Jani Nikula:
On Fri, 05 Nov 2021, Thomas Zimmermann wrote:
Hi
Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM
On Fri, 05 Nov 2021, Thomas Zimmermann wrote:
> Hi
>
> Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
>> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
>> but the exported vgacon_text_force() symbol is only used by DRM drivers.
>>
>> It makes much more sense for
Hi
Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers
Hi
Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
Hello Jani,
On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ * drm_drv_enabled - Checks if a DRM driver can be enabled
+ * @driver: DRM driver to check
+ *
+ * Checks whether a DRM
Hi Dave, Daniel,
Here's this week drm-misc-next-fixes PR
Thanks!
Maxime
drm-misc-next-fixes-2021-11-05:
A refcounting fix for outstanding fence callbacks.
The following changes since commit b3ec8cdf457e5e63d396fe1346cc788cf7c1b578:
fbdev: Garbage collect fbdev scrolling acceleration, part 1
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks
URL : https://patchwork.freedesktop.org/series/96602/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10844 -> Patchwork_21523
The taint aborts the CI test runner.
v2: Comment out GEM_TRACE_DUMP() also active_request_put().
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Some selftests assume that nothing will attempt to grab these bitlocks
while they are held by the selftests. With GuC, for example, that is
not true because the hanging workloads may cause the GuC code to attempt
to grab them for a global reset, and that may cause it to end up
sleeping on the bit
On 11/5/21 00:01, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* series starting with [1/2] drm/i915/selftests: Use
clear_and_wake_up_bit() for the per-engine reset bitlocks
*URL:* https://patchwork.freedesktop.org/series/96593/
*State:*failure
*Details:*
Hi all,
On Mon, 1 Nov 2021 19:42:23 +1100 Stephen Rothwell
wrote:
>
> On Fri, 15 Oct 2021 20:26:48 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> >
75 matches
Mail list logo
