[Intel-gfx] [PATCH] drm/i915: Disable frontbuffer tracking

2020-09-07 Thread Animesh Manna
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

[Intel-gfx] linux-next: build warning after merge of the drm-misc tree

2020-09-07 Thread Stephen Rothwell
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") --

[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

2020-09-07 Thread Stephen Rothwell
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:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Introduce per object locking in GVT scheduler.

2020-09-07 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: Introduce per object locking in GVT scheduler.

2020-09-07 Thread Patchwork
== 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:

[Intel-gfx] [PATCH] drm/i915/gvt: Introduce per object locking in GVT scheduler.

2020-09-07 Thread Zhi Wang
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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Drop the drm_atomic_helper_calc_timestamping_constants() call

2020-09-07 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH 2/3] drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()

2020-09-07 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()

2020-09-07 Thread Daniel Vetter
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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Nuke dpio_phy_iosf_port[]

2020-09-07 Thread Patchwork
== 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**

[Intel-gfx] [PATCH] drm/i915: Nuke dpio_phy_iosf_port[]

2020-09-07 Thread Ville Syrjala
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ä ---

[Intel-gfx] [PULL] drm-intel-gt-next

2020-09-07 Thread Joonas Lahtinen
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

Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode

2020-09-07 Thread Ville Syrjälä
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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()

2020-09-07 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()

2020-09-07 Thread Patchwork
== 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,

[Intel-gfx] [PATCH 3/3] drm/i915: Drop the drm_atomic_helper_calc_timestamping_constants() call

2020-09-07 Thread Ville Syrjala
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-gfx] [PATCH 2/3] drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()

2020-09-07 Thread Ville Syrjala
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

[Intel-gfx] [PATCH 1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()

2020-09-07 Thread Ville Syrjala
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

Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.

2020-09-07 Thread Ville Syrjälä
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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/1] intel-gpu-top: Support for client stats

2020-09-07 Thread Tvrtko Ursulin
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:

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/1] intel-gpu-top: Support for client stats

2020-09-07 Thread Petri Latvala
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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm_managed, leftovers (rev2)

2020-09-07 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm_managed, leftovers (rev2)

2020-09-07 Thread Patchwork
== 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:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm_managed, leftovers (rev2)

2020-09-07 Thread Patchwork
== 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

[Intel-gfx] [PATCH] drm/xlnx: Use devm_drm_dev_alloc

2020-09-07 Thread Daniel Vetter
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

[Intel-gfx] ✗ Fi.CI.IGT: failure for enhanced i915 vgpu with PV feature support

2020-09-07 Thread Patchwork
== 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 ---

Re: [Intel-gfx] [PATCH v3 6/7] drm: Validate encoder->possible_crtcs

2020-09-07 Thread Daniel Vetter
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.