== Series Details ==
Series: drm/i915: Disable frontbuffer tracking
URL : https://patchwork.freedesktop.org/series/81440/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8976 -> Patchwork_18451
Summary
---
**FAILURE**
Hi Christoph,
On 9/8/20 1:55 PM, Christoph Hellwig wrote:
On Tue, Sep 08, 2020 at 06:36:19AM +0100, Christoph Hellwig wrote:
On Mon, Sep 07, 2020 at 09:18:50PM +0100, Tom Murphy wrote:
Yeah we talked about passing an attr to map_sg to disable merging at
the following microconfernce:
https://li
== Series Details ==
Series: drm/i915: Disable frontbuffer tracking
URL : https://patchwork.freedesktop.org/series/81440/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0856e7221aba drm/i915: Disable frontbuffer tracking
-:7: WARNING:COMMIT_MESSAGE: Missing commit description -
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_frontbuffer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index d898b370d7a4..0f1d7a
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/gpu/drm/panel/panel-samsung-s6e63m0.o
Introduced by commit
b7b23e447687 ("drm/panel: s6e63m0: Break out SPI transport")
--
Ch
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_panel.c
between commit:
f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an external
PWM controller")
from Linus' tree and commit:
6b51e7d23aa8 ("drm/i915: panel
== Series Details ==
Series: drm/i915/gvt: Introduce per object locking in GVT scheduler.
URL : https://patchwork.freedesktop.org/series/81434/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8973 -> Patchwork_18450
Summary
-
== Series Details ==
Series: drm/i915/gvt: Introduce per object locking in GVT scheduler.
URL : https://patchwork.freedesktop.org/series/81434/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b9e9ccc05038 drm/i915/gvt: Introduce per object locking in GVT scheduler.
-:6: WARNING:C
To support ww locking and per-object implemented in i915, GVT scheduler needs
to be refined. Most of the changes are located in shadow batch buffer, shadow
wa context in GVT-g, where use quite a lot of i915 gem object APIs.
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Zhenyu Wang
Signed-off-by
On Mon, Sep 07, 2020 at 03:00:26PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We update the timestamping constants per-crtc explicitly in
> intel_crtc_update_active_timings(). Furtermore the helper will
> use uapi.adjusted_mode whereas we want hw.adjusted_mode. Thus
> let's drop the he
On Mon, Sep 07, 2020 at 03:00:25PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The timestamping constants have nothing to do with any legacy state
> so should not be updated from
> drm_atomic_helper_update_legacy_modeset_state().
>
> Let's make everyone call drm_atomic_helper_calc_time
On Mon, Sep 07, 2020 at 03:00:24PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Put the vblank timestamping constants update loop into its own
> function. It has no business living inside
> drm_atomic_helper_update_legacy_modeset_state() so we'll be wanting
> to move it out entirely. As
== Series Details ==
Series: drm/i915: Nuke dpio_phy_iosf_port[]
URL : https://patchwork.freedesktop.org/series/81431/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8973 -> Patchwork_18449
Summary
---
**SUCCESS**
From: Ville Syrjälä
There's no real reason to stash away the DPIO PHY IOSF sideband port
numbers for VLV/CHV. Just compute them at runtime in the sideband code.
Gets rid of the oddball intel_init_dpio() function from the high level
init flow.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i
Hi Dave & Daniel,
Exactly same content as previous PR:
https://lists.freedesktop.org/archives/intel-gfx/2020-September/247626.html
Just rebased adding the missing S-o-b:s and updated "Fixes:" tags accordingly
as requested.
Regards, Joonas
***
drm-intel-gt-next-2020-09-07:
(Same content as dr
On Thu, Sep 03, 2020 at 09:40:44PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 03, 2020 at 11:04:33AM -0700, Navare, Manasi wrote:
> > On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> > > > From: Maarten Lankhorst
>
== Series Details ==
Series: series starting with [1/3] drm/atomic-helper: Extract
drm_atomic_helper_calc_timestamping_constants()
URL : https://patchwork.freedesktop.org/series/81419/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8971 -> Patchwork_18448
=
== Series Details ==
Series: series starting with [1/3] drm/atomic-helper: Extract
drm_atomic_helper_calc_timestamping_constants()
URL : https://patchwork.freedesktop.org/series/81419/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each
From: Ville Syrjälä
We update the timestamping constants per-crtc explicitly in
intel_crtc_update_active_timings(). Furtermore the helper will
use uapi.adjusted_mode whereas we want hw.adjusted_mode. Thus
let's drop the helper call an rely on what we already have in
intel_crtc_update_active_timin
From: Ville Syrjälä
The timestamping constants have nothing to do with any legacy state
so should not be updated from
drm_atomic_helper_update_legacy_modeset_state().
Let's make everyone call drm_atomic_helper_calc_timestamping_constants()
directly instead of relying on
drm_atomic_helper_update_
From: Ville Syrjälä
Put the vblank timestamping constants update loop into its own
function. It has no business living inside
drm_atomic_helper_update_legacy_modeset_state() so we'll be wanting
to move it out entirely. As a first step we'll still call it
from drm_atomic_helper_update_legacy_modes
On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> Small changes to intel_dp_mode_valid(), allow listing modes that
> can only be supported in the bigjoiner configuration, which is
> not supported yet.
>
> eDP does not support bigjoiner, so do not expose
On 07/09/2020 10:31, Petri Latvala wrote:
On Fri, Sep 04, 2020 at 02:06:07PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Adds support for per-client engine busyness stats i915 exports in sysfs
and produces output like the below:
=
On Fri, Sep 04, 2020 at 02:06:07PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Adds support for per-client engine busyness stats i915 exports in sysfs
> and produces output like the below:
>
> ==
> intel-gpu-top
== Series Details ==
Series: drm_managed, leftovers (rev2)
URL : https://patchwork.freedesktop.org/series/81371/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8971 -> Patchwork_18447
Summary
---
**SUCCESS**
No reg
== Series Details ==
Series: drm_managed, leftovers (rev2)
URL : https://patchwork.freedesktop.org/series/81371/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/drm_drv.c:424:6:
== Series Details ==
Series: drm_managed, leftovers (rev2)
URL : https://patchwork.freedesktop.org/series/81371/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
037e65c0f1f3 drm/armada: Use devm_drm_dev_alloc
-:68: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nomina
Gets rid of drmm_add_final_kfree, which I want to unexport so that it
stops confusion people about this transitional state of rolling drm
managed memory out.
This also fixes the missing drm_dev_put in the error path of the probe
code.
v2: Drop the misplaced drm_dev_put from zynqmp_dpsub_drm_init
== Series Details ==
Series: enhanced i915 vgpu with PV feature support
URL : https://patchwork.freedesktop.org/series/81400/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8968_full -> Patchwork_18446_full
Summary
---
On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka wrote:
>
> On 11.02.20 18:04, Daniel Vetter wrote:
> > On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> WARN if the encoder possible_crtcs is effectively empty or contains
> >> bits for non-existing crtcs.
30 matches
Mail list logo
