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
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
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
---
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
---
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
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: 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
== 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 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
== 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: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
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
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
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 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
== 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
== 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
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()
> -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
== 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
== 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:
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
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
== 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**
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:
== 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
== 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: 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
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
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
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: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
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
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.
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
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
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
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
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.
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
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
== 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
From: John Harrison
GuC v46 partially increased the number of engine classes supported in
the ADS. GuC v48 then finished the change off by cleaning up the
per class engine mask fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 16 +---
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 1
mapping.
Signed-off-by: Matthew Brost
CC: John Harrison
From: Daniele Ceraolo Spurio
This will enable HuC loading for Gen11+ by default if the binaries
are available on the system. GuC submission still requires explicit
enabling by the user.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
From: John Harrison
Note that the GuC major version jumped from 35 to 40. This is because
the v40 firmware included a significant re-write of the API. The 'new
GuC API' patch series is required to make use of command submission
with this new GuC firmware. Versions 36 through 39 are reserved for
From: Michal Wajdeczko
While i915 does not use GuC doorbells, the firmware requires that some
initialisation is done.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 9 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
From: John Harrison
Update to the latest GuC firmware and enable by default.
Signed-off-by: John Harrison
Daniele Ceraolo Spurio (1):
drm/i915/uc: turn on GuC/HuC auto mode by default
John Harrison (5):
drm/i915/guc: ADS changes for GuC v42
drm/i915/guc: Increased engine classes in
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
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
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 --
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
2 files
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 Harrison
Signed-off-by: Matthew Brost
---
From: Michal Wajdeczko
Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer dereferences in some existing GuC
functions that use the guc_id to dereference arrays but these functions
From: John Harrison
Was hitting null pointers and similar issues when running various
module load/unload and inject failure type tests. So clear those
pointers down when the objects have been de-allocated.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 1 +
From: John Harrison
The ADS layout changes significantly with GuC firmware v42. This patch
updates the shared structure (but does not fill in the new tables,
that comes later as part of the GuC submission support). It also adds
better documentation of the layout.
Signed-off-by: John Harrison
From: Matthew Brost
The new GuC interface has removed GUC_CTL_CTXINFO from initialization
params.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 --
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 15 +--
2 files
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev12)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18514
Summary
---
Another step towards PSR2 selective fetch, here programming plane
selective fetch registers and MAN_TRK_CTL enabling selective fetch but
for now it is fetching the whole area of the planes.
The damaged area calculation will come as next and final step.
v2:
- removed warn on when no plane is
Due to the debugfs flag, has_psr2 in CRTC state could have a different
value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
and selective fetch) to be set to not a expected state.
So here only taking in consideration the parameter and debugfs flag
when computing PSR state, this
For platforms without selective fetch this register is reserved so
do not write 0 to it.
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Show engine properties in the
pretty printer
URL : https://patchwork.freedesktop.org/series/81727/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019_full -> Patchwork_18509_full
We need details about enabling TE on which port
before we enable TE through vblank enable path.
This is based on the configuration that we receive
from the VBT wrt ports, dual_link.
Signed-off-by: Vandita Kulkarni
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 30
Configure TE interrupt as part of the vblank
enable call flow.
v2: Hide the private flags check inside configure_te (Jani)
v3: Fix the position of masking de_port_masked for DSI_TE.
v4: Simplify the caller of configure_te (Jani)
v5: Clear IIR, remove the usage of private_flags
v6: including
This series contain interrupt handling part of cmd mode.
Configuration patches were merged already.
v10: Address the review comments on patch 3 and 4
v11: fix compilation issue introduced in v10
v12: fix check patch errors on patch 3
Vandita Kulkarni (4):
drm/i915/dsi: Add details about TE in
In TE Gate mode or TE NO_GATE mode on every flip
we need to set the frame update request bit.
After this bit is set transcoder hardware will
automatically send the frame data to the panel
in case of TE NO_GATE mode, where it sends after
it receives the TE event in case of TE_GATE mode.
Once the
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
If we are operating in TE_GATE mode, after we do
a frame update, the transcoder will send the frame data
to the panel, after it receives a TE. Whereas if we
are operating in NO_GATE mode then the transcoder will
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev9)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18513
Summary
---
On 9/16/2020 6:30 PM, Karthik B S wrote:
On 9/15/2020 8:11 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev9)
URL : https://patchwork.freedesktop.org/series/74386/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev9)
URL : https://patchwork.freedesktop.org/series/74386/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ed031e0bb186 drm/i915: Add enable/disable flip done and flip done handler
bd5ec737f6d0 drm/i915:
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
v3: -Move the patch to the end of the series (Paulo)
v4: -Rebased.
v5: -Rebased.
v6: -Rebased.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
Signed-off-by: Karthik B S
Add the details of the implementation of asynchronous flips for i915.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
Documentation/gpu/i915.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/gpu/i915.rst
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
v6: -Move the plane hook to separate patch. (Paulo)
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was causing issues for PSR.
v3: -No need to wait for vblank to pass, as this wait was causing a
16ms delay
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated before continuing
with the normal commit for sync flip.
v9: -Rename skl_toggle_async_sync() to
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
v2: -Few patches have been squashed and patches have been
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
On Wed, 2020-09-16 at 10:43 +0300, Jani Nikula wrote:
> On Tue, 15 Sep 2020, Rodrigo Vivi wrote:
> > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > Since we're about to start adding support for Intel's magic HDR
> > > backlight interface over DPCD, we need to ensure we're
== 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 -> Patchwork_18512
== 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 : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each
== 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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
870f8ace9fa6 drm/i915: Initialise outparam for
== 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 -> Patchwork_18511
Hi Tomas,
Thanks for the patch.
On Tue, Sep 15, 2020 at 08:53:46AM -0700, Laurent Pinchart wrote:
> Hi Thomas,
>
> Thank you for the patch.
>
> On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote:
> > The xlnx driver uses CMA helpers with default callback functions.
> >
On 14/09/20 21:42, Thomas Gleixner wrote:
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
>
> Signed-off-by: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Juri Lelli
> Cc: Vincent Guittot
> Cc: Dietmar
On 14/09/20 21:42, Thomas Gleixner wrote:
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
>
> Signed-off-by: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Juri Lelli
> Cc: Vincent Guittot
> Cc: Dietmar
On Fri, 11 Sep 2020, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev4)
> URL : https://patchwork.freedesktop.org/series/81150/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> dac234339c17 drm/i915/pll:
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests
URL : https://patchwork.freedesktop.org/series/81729/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== 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 : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18510
Hi
Am 16.09.20 um 14:59 schrieb Christian König:
> Am 16.09.20 um 14:24 schrieb Daniel Vetter:
>> On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 16.09.20 um 11:37 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
== 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 : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each
== 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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8e90943e9601 drm/i915/gem: Hold request reference
On 9/15/2020 8:11 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl
Am 16.09.20 um 14:24 schrieb Daniel Vetter:
On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
Hi
Am 16.09.20 um 11:37 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
Dma-buf provides vmap() and vunmap() for retrieving and releasing
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Show engine properties in the
pretty printer
URL : https://patchwork.freedesktop.org/series/81727/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18509
On 9/15/2020 7:49 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:31AM +0530, Karthik B S wrote:
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated
On 9/15/2020 7:40 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl
On 9/15/2020 7:37 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:29AM +0530, Karthik B S wrote:
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was
On 9/15/2020 7:33 PM, Ville Syrjälä wrote:
On Mon, Sep 14, 2020 at 11:26:28AM +0530, Karthik B S wrote:
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified,
1 - 100 of 147 matches
Mail list logo
