From: John Harrison
Rather than just saying 'GuC failed to load: -110', actually print out
the GuC status register and break it down into the individual fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 27 ++-
1 file changed, 22 insertion
== Series Details ==
Series: series starting with [1/4] drm/i915/gem: Hold request reference for
canceling an active context
URL : https://patchwork.freedesktop.org/series/81728/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9019_full -> Patchwork_18510_full
=
Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.
We also take care not to reprogram the source OUI i
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simp
No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c
Reviewed-by: Rodrigo Vivi
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting sup
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that w
Since we're about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.
Si
A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-sp
Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight fu
On Wed, 16 Sep 2020 at 10:46, Chris Wilson wrote:
>
> After marking the requests on an engine as cancelled upon wedging, send
> any signals for their completions.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Inte
On Wed, 16 Sep 2020 at 10:46, Chris Wilson wrote:
>
> Flush all the pending requests from the mock engine when they are
> cancelled.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
On Wed, 16 Sep 2020 at 10:46, Chris Wilson wrote:
>
> If we manage to hit the intel_gt_set_wedged_on_fini() while active, i.e.
> module unload during a stress test, we may cancel the requests but not
> clean up. This leads to a slow module unload as we wait for something or
> other to trigger the
On Wed, 16 Sep 2020 at 10:01, Chris Wilson wrote:
>
> Shrink the hold time for the error capture mutex to just around the
> acquire/release of the PTE used for reading back the object via the
> Global GTT. For platforms that do not need the GGTT read back, we can
> skip the mutex entirely and allo
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
> Several GEM and PRIME callbacks have been deprecated in favor of
> per-instance GEM object functions. Remove the callbacks as they are
> now unused. The only exception is .gem_prime_mmap, which is still
> in use by several drivers.
>
> What is al
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests
URL : https://patchwork.freedesktop.org/series/81729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019_full -> Patchwork_18511_full
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/display: Ignore
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL : https://patchwork.freedesktop.org/series/81758/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18515
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/81761/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b85247eec0d5 drm/i915/guc: New GuC IDs based on engine class and instance
923da8dfc700 drm/i915/guc: Support logical
WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Gen9 to
resolve VP8 hardware encoding system hang up on GT1 sku
Reference: HSD#1508045018
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: William Tseng
Cc: Lee Shawn C
Signed-off-by: Cooper
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/81761/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18516
Summary
---
**FAILURE**
Seri
On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote:
>
> All fair, but some of us need to write code that must handle being
> invoked from a wide variety of contexts.
Note that I think that core functionality is different from random drivers.
Of course core code can (and will) look at things
On Tue, Sep 15, 2020 at 12:57 PM Thomas Gleixner wrote:
>
> You wish. I just found a 7 year old bug in a 10G network driver which
> surely would have been found if people would enable debug configs and
> not just run the crap on their PREEMPT_NONE, all debug off kernel. And
> that driver is not su
== Series Details ==
Series: drm/i915: Add support for Intel's eDP backlight controls (rev2)
URL : https://patchwork.freedesktop.org/series/81702/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8aaf96a8cf98 drm/i915/dp: Program source OUI on eDP panels
ba0a5a5d9619 drm/i915: Ren
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initialise outparam for error
return from wait_for_register
URL : https://patchwork.freedesktop.org/series/81731/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019_full -> Patchwork_18512_full
=
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, September 16, 2020 6:51 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pll:
> Centralize PLL_ENABLE register lookup (rev4)
>
> On Fri, 11 Sep
On Mon, Sep 14, 2020 at 11:55:24PM +0200, Thomas Gleixner wrote:
> But just look at any check which uses preemptible(), especially those
> which check !preemptible():
hmm.
+++ b/include/linux/preempt.h
@@ -180,7 +180,9 @@ do { \
#define preempt_enable_no_resched() sched_preempt_enable_no_resch
== Series Details ==
Series: drm/i915: Add support for Intel's eDP backlight controls (rev2)
URL : https://patchwork.freedesktop.org/series/81702/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18517
Summar
== Series Details ==
Series: drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
URL : https://patchwork.freedesktop.org/series/81764/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18518
On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote:
>
> On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> > wrote:
> > >
> > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner
> > > wrote:
> > > >
> > > > OTOH, having a workin
On Wed, Sep 16, 2020 at 08:23:52PM +0100, Matthew Wilcox wrote:
> On Mon, Sep 14, 2020 at 11:55:24PM +0200, Thomas Gleixner wrote:
> > But just look at any check which uses preemptible(), especially those
> > which check !preemptible():
>
> hmm.
>
> +++ b/include/linux/preempt.h
> @@ -180,7 +180,
On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> wrote:
> >
> > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote:
> > >
> > > OTOH, having a working 'preemptible()' or maybe better named
> > > 'can_schedule()' check makes tons
On Wed, Sep 16, 2020 at 11:32:00AM -0700, Linus Torvalds wrote:
> On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote:
> >
> > All fair, but some of us need to write code that must handle being
> > invoked from a wide variety of contexts.
>
> Note that I think that core functionality is differ
On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote:
> On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote:
> >
> > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds
> > > wrote:
> > > >
> > > > On Tue, Sep 15, 2020 at
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev9)
URL : https://patchwork.freedesktop.org/series/74386/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9019_full -> Patchwork_18513_full
Summary
---
On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote:
>
> On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote:
> > >
> > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote:
> > > > On Tue, Sep 15, 2020 at 7:35 P
== Series Details ==
Series: drm/i915: Add support for Intel's eDP backlight controls (rev2)
URL : https://patchwork.freedesktop.org/series/81702/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019_full -> Patchwork_18517_full
==
On 9/16/2020 10:16 AM, john.c.harri...@intel.com wrote:
From: John Harrison
Update to the latest GuC firmware and enable by default.
Missing a big note to make it clear that all these patches have to be
squashed into one before pushing.
Daniele
Signed-off-by: John Harrison
Daniele
On 9/16/2020 10:16 AM, john.c.harri...@intel.com wrote:
From: Matthew Brost
The new GuC FW introduces a physical to logical engine mapping table in
the GuC additional data structures which needs to be configured in order
for the firmware to load. This patch initializes the table with a 1 to
On 9/16/2020 10:16 AM, john.c.harri...@intel.com wrote:
From: Matthew Brost
The new GuC requires the additional data structure and associated
'private_data' pointer to be setup. This is basically a scratch area
of memory that the GuC owns. The size is read from the CSS header.
Cc: John Harr
On 9/16/2020 10:16 AM, john.c.harri...@intel.com wrote:
From: Matthew Brost
The new GuC interface has removed GUC_CTL_CTXINFO from initialization
params.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel
On 9/16/2020 10:16 AM, john.c.harri...@intel.com wrote:
From: Michal Wajdeczko
Starting GuC firmware version 40.0 reg_state_buffer is maintained
internally by the GuC as part of "private data".
Signed-off-by: Michal Wajdeczko
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/
On 9/16/2020 16:27, Daniele Ceraolo Spurio wrote:
On 9/16/2020 10:16 AM, john.c.harri...@intel.com wrote:
From: Matthew Brost
The new GuC FW introduces a physical to logical engine mapping table in
the GuC additional data structures which needs to be configured in order
for the firmware to loa
Hello,
The failures below all appear to be because the new GuC firmware was not
found on the test system.
My understanding is that all we need to do to get the CI system to
update with new firmwares is to push the firmware to a branch on the FDO
drm-firmware repo and then send a pull request
+ Tomi
> -Original Message-
> From: John Harrison
> Sent: torstai 17. syyskuuta 2020 4.23
> To: intel-gfx@lists.freedesktop.org; Latvala, Petri ;
> Saarinen, Jani ; Szwichtenberg, Radoslaw
>
> Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915/guc: Update to GuC v49
>
> Hello,
>
> The fail
On Wed, Sep 16, 2020 at 06:22:45PM -0700, John Harrison wrote:
> Hello,
>
> The failures below all appear to be because the new GuC firmware was not
> found on the test system.
>
> My understanding is that all we need to do to get the CI system to update
> with new firmwares is to push the firmwa
101 - 146 of 146 matches
Mail list logo
