[Intel-gfx] [PATCH] drm/i915: Restore DMC required version for Skylake (1.26)

With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic links") we started loading the firmware version directly instead of symbolic links. With this VERSION_REQUIRED variables changed the meaning from minimal required to exact version required. Along with this change we started using the

Re: [Intel-gfx] Correct DMC version for Skylake (1.23 vs 1.26)

On Tue, Aug 9, 2016 at 1:48 AM, Jani Nikula wrote: > On Tue, 09 Aug 2016, Daniel Klaffenbach wrote: >> Hi, >> >> which one is the correct DMC version to load for Linux 4.8-rc1? The >> binary blob in linux-firmware.git is v1.26, which is

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

== Series Details == Series: series starting with [CI,1/2] drm/i915: Add smp_rmb() to busy ioctl's RCU dance URL : https://patchwork.freedesktop.org/series/10828/ State : failure == Summary == Applying: drm/i915: Add smp_rmb() to busy ioctl's RCU dance Using index info to reconstruct a base

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/3] drm/i915: Remove unused i915_gem_active_peek_rcu()

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove unused i915_gem_active_peek_rcu() URL : https://patchwork.freedesktop.org/series/10826/ State : failure == Summary == Applying: drm/i915: Remove unused i915_gem_active_peek_rcu() Using index info to reconstruct a

Re: [Intel-gfx] [PATCH] drm/i915: Fix braces in conditonal branches

On Tue, 2016-08-09 at 23:08 +0100, Chris Wilson wrote: > On Tue, Aug 09, 2016 at 03:06:10PM -0700, Dhinakaran Pandiyan wrote: > > No functional change, just adding braces to all branches of conditional > > statement because one of them already had. > > --- > > drivers/gpu/drm/i915/intel_audio.c |

Re: [Intel-gfx] [PATCH] drm/i915: Fix braces in conditonal branches

On Tue, Aug 09, 2016 at 03:06:10PM -0700, Dhinakaran Pandiyan wrote: > No functional change, just adding braces to all branches of conditional > statement because one of them already had. > --- > drivers/gpu/drm/i915/intel_audio.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > >

[Intel-gfx] [PATCH] drm/i915: Fix braces in conditonal branches

No functional change, just adding braces to all branches of conditional statement because one of them already had. --- drivers/gpu/drm/i915/intel_audio.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c

[Intel-gfx] [PATCH v2] drm/i915/dp: DP audio API changes for MST

DP MST provides the capability to send multiple video and audio streams through a single port. This requires the API's between i915 and audio drivers to distinguish between multiple audio capable displays that can be connected to a port. Currently only the port identity is shared in the APIs. This

Re: [Intel-gfx] [PATCH] drm: avoid "possible bad bitmask?" warning

On Tue, Aug 9, 2016 at 9:53 PM, Chris Wilson wrote: > On Tue, Aug 09, 2016 at 06:35:10PM +0100, Dave Gordon wrote: >> Recent versions of gcc say this: >> >> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ >> requires 37 bits to represent, but ‘int’ only

Re: [Intel-gfx] [PATCH] drm: avoid "possible bad bitmask?" warning

On Tue, Aug 09, 2016 at 06:35:10PM +0100, Dave Gordon wrote: > Recent versions of gcc say this: > > include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ > requires 37 bits to represent, but ‘int’ only has 32 bits > [-Wshift-overflow=] > > Reported-by: David Binderman

[Intel-gfx] [PATCH 7/9] drm/i915/dp: Enable upfront link training on SKL

From: Jim Bride Split the PLL selection code out of the BXT upfront link training implementation and into a stand-alone function in order to allow for the implementation of a platform neutral upfront link training function, and then enable upfront link training for

[Intel-gfx] [PATCH 9/9] drm/i915: Enable upfront link training support for HSW/BDW

Get the PLLs for HSW/BDW using the platform specific function and add hooks for enabling upfront link training on HSW and BDW. Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/intel_dp.c | 4 +++- 2 files changed, 5

[Intel-gfx] [PATCH v2 4/9] drm/i915: Split bxt_ddi_pll_select()

From: Durgadoss R Split out of bxt_ddi_pll_select() the logic that calculates the pll dividers and dpll_hw_state into a new function that doesn't depend on crtc state. This will be used for enabling the port pll when doing upfront link training. v2: * Refactored code so

[Intel-gfx] [PATCH v8 5/9] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

From: Durgadoss R To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel

[Intel-gfx] [PATCH v2 3/9] drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions

From: Ander Conselvan de Oliveira Split intel_ddi_pre_enable() into encoder type specific versions that don't depend on crtc_state. The necessary parameters are passed as function arguments. This split will be necessary for implementing DP upfront link

[Intel-gfx] [PATCH v2 2/9] drm/i915: Remove ddi_pll_sel from intel_crtc_state

From: Ander Conselvan de Oliveira The value of ddi_pll_sel is derived from the selection of shared dpll, so just calculate the final value when necessary. v2: Actually remove it from crtc state and delete remaining usages. (CI) Reviewed-by: Durgadoss R

[Intel-gfx] [PATCH 8/9] drm/i915: Split hsw_get_dpll()

Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code that calculates the pll so that it doesn't depend on crtc state. This will be used for acquiring port pll when doing upfront link training. Signed-off-by: Manasi Navare

[Intel-gfx] [PATCH 1/9] drm/i915: Don't pass crtc_state to intel_dp_set_link_params()

From: Ander Conselvan de Oliveira Decouple intel_dp_set_link_params() from struct intel_crtc_state. This will be useful for implementing DP upfront link training. Reviewed-by: Durgadoss R Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH 0/9] Enable upfront link training on DDI platforms

This patch series enables upfront link training on DDI platforms (SKL/BDW/HSW/BXT). They are based on some of the patches submitted earlier by Ander and Durgadoss. The upfront link training had to be factored out of long pulse hanlder because of deadlock issues seen on DP MST cases. Now the

Re: [Intel-gfx] [PATCH v3 05/21] drm/i915: Get rid of HAS_CORE_RING_FREQ

On Tue, Aug 09, 2016 at 11:45:11AM -0700, Carlos Santa wrote: > No need for HAS_CORE_RING_FREQ as that flag is actually the same as > .has_llc. Feedback from V. Syrjala. > > Signed-off-by: Carlos Santa > --- > drivers/gpu/drm/i915/i915_debugfs.c | 3 ++- >

[Intel-gfx] [PATCH v3 3/6] drm/i915/lvds: Restore initial HW state during encoder enabling

Atm the LVDS encoder depends on the PPS HW context being saved/restored from generic suspend/resume code. Since the PPS is specific to the LVDS and eDP encoders a cleaner way is to reinitialize it during encoder enabling, so do this here for LVDS. Follow-up patches will init the PPS for the eDP

[Intel-gfx] [PATCH v3 5/6] drm/i915: Apply the PPS register unlock workaround more consistently

Atm, we apply this workaround somewhat inconsistently at the following points: driver loading, LVDS init, eDP PPS init, system resume. As this workaround also affects registers other than PPS (timing, PLL) a more consistent way is to apply it early after the PPS HW context is known to be lost:

[Intel-gfx] [PATCH v3 09/21] drm/i915: Move HAS_RC6p definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 17/21] drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 16/21] drm/i915: Move HAS_HW_CONTEXTS definition to platform

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 04/21] drm/i915: Move HAS_RUNTIME_PM definition to platform

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Feedback from V. Syrjala: remove runtime PM support for snb as it breaks

[Intel-gfx] [PATCH v3 00/21] drm/i915: Organize most GPU features by platform

- organize most GPU features so that they are easy to group by platforms. It seems some of the ground work was already done for Gen7 features. - make most of these GPU features now a device_info flag also based on previous work done by others. The idea is here is to have a central place

[Intel-gfx] [PATCH v3 13/21] drm/i915: Introduce GEN4_FEATURES for device info

Based on the GEN7_FEATURES changes from Ben W. Use it for i965g, i965gm, g45 and gm45. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git

[Intel-gfx] [PATCH v3 10/21] drm/i915: Move HAS_DP_MST definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 11/21] drm/i915: Introduce GEN5_FEATURES for device info

Based on the GEN7_FEATURES changes from Ben w. Use it for ilk. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_pci.c

[Intel-gfx] [PATCH v3 14/21] drm/i915: Introduce GEN3_FEATURES for device info

Based on the GEN7_FEATURES from Ben W. Use it for i915g, i915gm, i945g, i945gm, g33 and pnv. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 30 ++ 1 file changed, 14 insertions(+), 16 deletions(-) diff --git

[Intel-gfx] [PATCH v3 21/21] drm/i915: Move HAS_GUC definition to platform definition

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platform - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 02/21] drm/i915: Remove .is_mobile field from platform struct

As recommended by Ville Syrjala removing .is_mobile field from the platform struct definition for vlv and hsw+ GPUs as there's no need to make the distinction in later hardware anymore. Keep it for older GPUs as it is still needed for ilk-ivb. Signed-off-by: Carlos Santa

[Intel-gfx] [PATCH v3 19/21] drm/i915: Move HAS_GMCH_DISPLAY definition to platform

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 18/21] drm/i915: Move HAS_L3_DPF definition to platform definition

Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 01/21] drm/i915: Move HAS_PSR definition to platform struct definition

[patch series] Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definition Signed-off-by: Carlos Santa Reviewed-by:

[Intel-gfx] [PATCH v3 20/21] drm/i915: Make HWS_NEEDS_PHYSICAL the exception

Make the .hws_needs_physical the exception by switching the flag on earlier platforms since they are fewer to support. Remove the flag on later GPUs hardware since they all use GTT hws by default. Switch the logic as well in the driver to reflect this change. Signed-off-by: Carlos Santa

[Intel-gfx] [PATCH v3 08/21] drm/i915: Move HAS_RC6 definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 07/21] drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 15/21] drm/i915: Introduce GEN2_FEATURES for device info

Based on the GEN7_FEATURES changes from Ben W. Use it for 830, 845g, i85x, i865g. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_pci.c | 37 - 1 file changed, 16 insertions(+), 21 deletions(-) diff --git

[Intel-gfx] [PATCH v3 05/21] drm/i915: Get rid of HAS_CORE_RING_FREQ

No need for HAS_CORE_RING_FREQ as that flag is actually the same as .has_llc. Feedback from V. Syrjala. Signed-off-by: Carlos Santa --- drivers/gpu/drm/i915/i915_debugfs.c | 3 ++- drivers/gpu/drm/i915/i915_drv.h | 4 2 files changed, 2 insertions(+), 5

[Intel-gfx] [PATCH v3 12/21] drm/i915: Move HAS_GMBUS_IRQ definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 06/21] drm/i915 Move HAS_CSR definition to platform definition

Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa ---

[Intel-gfx] [PATCH v3 03/21] drm/i915: Introduce GEN6_FEATURES for device info

Based on the GEN7_FEATURES changes from Ben W. Use it for snb. Signed-off-by: Carlos Santa Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pci.c | 26 -- 1 file changed, 12 insertions(+), 14 deletions(-) diff

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Remove LVDS and PPS suspend time save/restore

On Tue, Aug 09, 2016 at 02:34:12PM +0300, Imre Deak wrote: > In the preceeding patches we made sure that: > - the LVDS encoder takes care of reiniting both the LVDS register > and its PPS > - the eDP encoder takes care of reiniting its PPS > - the PPS register unlocking workaround is applied

Re: [Intel-gfx] [PATCH 0/9] Enable upfront link training on DDI platforms

This patch series had some git format-patch issues due to which it did not apply cleanly in CI system. So please disregard this patch set. I will be sending a new patch series for enabling upfront link training. Regards Manasi On Mon, Aug 08, 2016 at 07:33:09PM -0700, Manasi Navare wrote: > This

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Merge TARGET_POWER_ON and PANEL_POWER_ON flag definitions

On Tue, Aug 09, 2016 at 02:34:08PM +0300, Imre Deak wrote: > These two flags mean the same thing, so remove the duplication. > > Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_reg.h | 1 - >

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Merge the PPS register definitions

On Tue, Aug 09, 2016 at 08:21:31PM +0300, Imre Deak wrote: > The PPS registers are pretty much the same everywhere, the differences > being: > - Register fields appearing, disappearing from one platform to the > next: panel-reset-on-powerdown, backlight-on, panel-port, > register-unlock > -

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/dp: Restore PPS HW state from the encoder resume hook

On Tue, Aug 09, 2016 at 08:21:33PM +0300, Imre Deak wrote: > Similarly to the previous patch, initialize the PPS from the DP > encoder's resume hook. Note that as opposed to LVDS we can't do this > during encoder enabling, since we need the PPS for DP detection as well. > The PPS init code is now

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/lvds: Restore initial HW state during encoder enabling

On Tue, Aug 09, 2016 at 08:21:32PM +0300, Imre Deak wrote: > Atm the LVDS encoder depends on the PPS HW context being saved/restored > from generic suspend/resume code. Since the PPS is specific to the LVDS > and eDP encoders a cleaner way is to reinitialize it during encoder > enabling, so do

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Apply the PPS register unlock workaround more consistently

On Tue, Aug 09, 2016 at 08:21:34PM +0300, Imre Deak wrote: > Atm, we apply this workaround somewhat inconsistently at the following > points: driver loading, LVDS init, eDP PPS init, system resume. As this > workaround also affects registers other than PPS (timing, PLL) a more > consistent way is

[Intel-gfx] [PATCH] drm: avoid "possible bad bitmask?" warning

Recent versions of gcc say this: include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ requires 37 bits to represent, but ‘int’ only has 32 bits [-Wshift-overflow=] Reported-by: David Binderman Signed-off-by: Dave Gordon Cc: Dave

[Intel-gfx] [PATCH v2 3/6] drm/i915/lvds: Restore initial HW state during encoder enabling

Atm the LVDS encoder depends on the PPS HW context being saved/restored from generic suspend/resume code. Since the PPS is specific to the LVDS and eDP encoders a cleaner way is to reinitialize it during encoder enabling, so do this here for LVDS. Follow-up patches will init the PPS for the eDP

[Intel-gfx] [PATCH v2 1/6] drm/i915: Merge the PPS register definitions

The PPS registers are pretty much the same everywhere, the differences being: - Register fields appearing, disappearing from one platform to the next: panel-reset-on-powerdown, backlight-on, panel-port, register-unlock - Different register base addresses - Different number of PPS instances: 2

[Intel-gfx] [PATCH v2 5/6] drm/i915: Apply the PPS register unlock workaround more consistently

Atm, we apply this workaround somewhat inconsistently at the following points: driver loading, LVDS init, eDP PPS init, system resume. As this workaround also affects registers other than PPS (timing, PLL) a more consistent way is to apply it early after the PPS HW context is known to be lost:

[Intel-gfx] [PATCH v2 4/6] drm/i915/dp: Restore PPS HW state from the encoder resume hook

Similarly to the previous patch, initialize the PPS from the DP encoder's resume hook. Note that as opposed to LVDS we can't do this during encoder enabling, since we need the PPS for DP detection as well. The PPS init code is now the same for init and resume, so factor out a new

[Intel-gfx] [PATCH v2] drm/i915: Always mark the writer as also a read for busy ioctl

One of the few guarantees we want the busy ioctl to provide is that the reported busy writer is included in the set of busy read engines. This should be provided by the ordering of setting and retiring the active trackers, but we can do better by explicitly setting the busy read engine flag for

[Intel-gfx] [CI 2/3] drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs

In commit 2529d57050af ("drm/i915: Drop racy markup of missed-irqs from idle-worker") the racy detection of missed interrupts was removed when we went idle. This however opened up the issue that the stuck waiters were not being reported, causing a test case failure. If we move the stuck waiter

[Intel-gfx] [CI 3/3] drm/i915: Use RCU to annotate and enforce protection for breadcrumb's bh

The bottom-half we use for processing the breadcrumb interrupt is a task, which is an RCU protected struct. When accessing this struct, we need to be holding the RCU read lock to prevent it disappearing beneath us. We can use the RCU annotation to mark our irq_seqno_bh pointer as being under RCU

[Intel-gfx] [CI 1/3] drm/i915: Always mark the writer as also a read for busy ioctl

One of the few guarantees we want the busy ioctl to provide is that the reported busy writer is included in the set of busy read engines. This should be provided by the ordering of setting and retiring the active trackers, but we can do better by explicitly setting the busy read engine flag for

Re: [Intel-gfx] [PATCH 02/20] drm/doc: Light drm-kms-helper.rst cleanup

On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote: > - Move the common vtable stuff to the top > - Move "Tile Group" to a more appropriate heading level > - Throw away the old intro for the crtc helpers (it's entirely stale, > e.g. helpers have become modular years

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable upfront link training on DDI platforms

== Series Details == Series: Enable upfront link training on DDI platforms URL : https://patchwork.freedesktop.org/series/10821/ State : failure == Summary == Applying: drm/i915: Don't pass crtc_state to intel_dp_set_link_params() Applying: drm/i915: Remove ddi_pll_sel from intel_crtc_state

Re: [Intel-gfx] [PATCH 08/33] drm/i915: Move setting of request->batch into its single callsite

On Tue, Aug 09, 2016 at 06:53:16PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > request->batch_obj is only set by execbuffer for the convenience of > > debugging hangs. By moving that operation to the callsite, we can > > simplify all other callers and

[Intel-gfx] [CI] drm/i915: Correct typo for __i915_gem_active_get_rcu in a comment

I mistyped and added an extra _request_ to __i915_gem_active_get_rcu() Also, the same happened to another comment for i915_gem_active_get_rcu() Reported-by: Mika Kuoppala Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

On 09/08/16 03:59, Dave Airlie wrote: On 8 August 2016 at 19:40, Daniel Vetter wrote: On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote: Hello there, Recent versions of gcc say this: include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ requires 37

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Use connector atomic state in encoders.

== Series Details == Series: drm/i915: Use connector atomic state in encoders. URL : https://patchwork.freedesktop.org/series/10853/ State : failure == Summary == Applying: drm/i915: handle DP_MST correctly in bxt_get_dpll Applying: drm/i915: Pass atomic state to crtc enable/disable functions

Re: [Intel-gfx] [PATCH 08/33] drm/i915: Move setting of request->batch into its single callsite

Chris Wilson writes: > request->batch_obj is only set by execbuffer for the convenience of > debugging hangs. By moving that operation to the callsite, we can > simplify all other callers and future patches. We also move the > complications of reference handling of the

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Accommodate multiple GuC submission clients

On 09/08/16 15:55, Patchwork wrote: == Series Details == Series: Accommodate multiple GuC submission clients URL : https://patchwork.freedesktop.org/series/10847/ State : failure == Summary == Series 10847v1 Accommodate multiple GuC submission clients

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/guc: use symbolic names for module parameter values (rev2)

On 09/08/16 12:25, Patchwork wrote: == Series Details == Series: drm/i915/guc: use symbolic names for module parameter values (rev2) URL : https://patchwork.freedesktop.org/series/10188/ State : warning == Summary == Series 10188v2 drm/i915/guc: use symbolic names for module parameter

[Intel-gfx] [CI] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a kmem_cache_node is destroyed the call_rcu() may trigger a slab allocation to fill the debug object pool (__debug_object_init:fill_pool). Everywhere but during kmem_cache_destroy(), discard_slab() is performed outside of the

Re: [Intel-gfx] [PATCH v3] drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs

Chris Wilson writes: > In commit 2529d57050af ("drm/i915: Drop racy markup of missed-irqs from > idle-worker") the racy detection of missed interrupts was removed when > we went idle. This however opened up the issue that the stuck waiters > were not being reported,

[Intel-gfx] ✓ Ro.CI.BAT: success for Picture aspect ratio support in DRM layer

== Series Details == Series: Picture aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/10849/ State : success == Summary == Series 10849v1 Picture aspect ratio support in DRM layer http://patchwork.freedesktop.org/api/1.0/series/10849/revisions/1/mbox

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Apply the PPS register unlock workaround more consistently

On ti, 2016-08-09 at 16:01 +0300, Ville Syrjälä wrote: > On Tue, Aug 09, 2016 at 02:34:11PM +0300, Imre Deak wrote: > > Atm, we apply this workaround somewhat inconsistently at the following > > points: driver loading, LVDS init, eDP PPS init, system resume. As this > > workaround also affects

Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp: Restore PPS HW state from the encoder resume hook

On ti, 2016-08-09 at 15:52 +0300, Ville Syrjälä wrote: > On Tue, Aug 09, 2016 at 02:34:10PM +0300, Imre Deak wrote: > > Similarly to the previous patch, initialize the PPS from the DP > > encoder's resume hook. Note that as opposed to LVDS we can't do this > > during encoder enabling, since we

[Intel-gfx] [PATCH 03/15] drm/i915: Remove unused mode_set hook from encoder

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_drv.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 1ad2e2c5f580..0e53cc1fd5cc 100644 ---

Re: [Intel-gfx] [PATCH 0/4] drm/i915: Maarten's pre-g4x GPU reset regression fix + other reset stuff

On Fri, Aug 05, 2016 at 11:28:26PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I got annoyed at the pre-g4x gpu reset regression again, so I > picked up the latest (I think it was the latest anyway) version of > Maarten's locking fix from

Re: [Intel-gfx] [PATCH] drm/i915: Don't mark PCH underrun reporting as diasabled for transcoder B/C on LPT-H

On Fri, Aug 05, 2016 at 10:22:48PM +0200, Daniel Vetter wrote: > On Fri, Aug 05, 2016 at 08:00:17PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Marking PCH transcoder FIFO underrun reporting as disabled for > > transcoder B/C on

Re: [Intel-gfx] [PATCH] drm/i915: Add some curly braces

On Fri, Aug 05, 2016 at 06:49:26PM +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 08:41:34PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > intel_enable_pipe() looks rather confusing when one side doesn't have > > the curly

[Intel-gfx] [PATCH 04/15] drm/i915: Walk over encoders in crtc enable/disable using atomic state.

This cleans up another possible use of the connector list, encoder->crtc is legacy state and should not be used. With the atomic state as argument it's easy to find the encoder from the connector it belongs to. intel_opregion_notify_encoder is a noop for !HAS_DDI, so it's harmless to

[Intel-gfx] [PATCH 06/15] drm/i915: Make encoder->compute_config take the connector state

Some places iterate over connector_state to find the right connector, pass it along as argument. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_crt.c | 3 ++- drivers/gpu/drm/i915/intel_ddi.c | 7 ---

[Intel-gfx] [PATCH 05/15] drm/i915: Pass crtc_state and connector_state to encoder functions

This is mostly code churn, with exception of a few places: - intel_display.c has changes in intel_sanitize_encoder - intel_ddi.c has intel_ddi_fdi_disable calling intel_ddi_post_disable, and required a function change. Also affects intel_display.c - intel_dp_mst.c passes a NULL crtc_state and

[Intel-gfx] [PATCH 12/15] drm/i915: Convert intel_lvds to use atomic state

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_lvds.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index

[Intel-gfx] [PATCH 02/15] drm/i915: Pass atomic state to crtc enable/disable functions

This is required for supporting nonblocking modesets. Iterating over the connector list will no longer be allowed when we don't hold connection_mutex, so we have to use the atomic state. Fix disable_noatomic by populating the minimal state required to disable a connector. Signed-off-by: Maarten

[Intel-gfx] [PATCH 15/15] drm/i915: Use more atomic state in intel_color.c

crtc_state is already passed around, use it instead of crtc->config. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_color.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git

[Intel-gfx] [PATCH 11/15] drm/i915: Convert intel_sdvo to use atomic state

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_sdvo.c | 27 +++ 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index

[Intel-gfx] [PATCH 08/15] drm/i915: Convert intel_crt to use atomic state

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_crt.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 8fe36d049d2f..1daf2d9c937e 100644

[Intel-gfx] [PATCH 13/15] drm/i915: Convert intel_dp_mst to use atomic state

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp_mst.c | 48 ++--- 1 file changed, 18 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index

[Intel-gfx] [PATCH 01/15] drm/i915: handle DP_MST correctly in bxt_get_dpll

No idea if it supports it, but this is the minimum required from get_dpll. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 14/15] drm/i915: Convert intel_dp to use atomic state

Slightly less straightforward. Some of the drrs calls are done from workers or from intel_ddi.c, pass along crtc_state when we can, or crtc->config when we can't. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_ddi.c | 4 +-

[Intel-gfx] [PATCH 10/15] drm/i915: Convert intel_dsi to use atomic state

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dsi.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index

[Intel-gfx] [PATCH 07/15] drm/i915: Remove unused loop from intel_dp_mst_compute_config

conn_state is passed as argument now, if anything required conn_state they can get it without having to look it up. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp_mst.c | 19 +-- 1 file changed, 1 insertion(+), 18

[Intel-gfx] [PATCH 00/15] drm/i915: Use connector atomic state in encoders.

This is required for supporting nonblocking modeset and atomic connector properties. Connector properties will need the connector state to be passed or it will not work as intended. Nonblocking modesets need to iterate over the atomic state, instead of relying on the legacy state fixed up by

[Intel-gfx] [PATCH 09/15] drm/i915: Convert intel_dvo to use atomic state

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dvo.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c index 141483fdcf7b..642c5550a1e5 100644

Re: [Intel-gfx] [PATCH 3/6] drm/i915/lvds: Restore initial HW state during encoder enabling

On Tue, Aug 09, 2016 at 05:40:32PM +0300, Imre Deak wrote: > On ti, 2016-08-09 at 15:48 +0300, Ville Syrjälä wrote: > > On Tue, Aug 09, 2016 at 02:34:09PM +0300, Imre Deak wrote: > > > Atm the LVDS encoder depends on the PPS HW context being saved/restored > > > from generic suspend/resume code.

[Intel-gfx] ✗ Ro.CI.BAT: failure for Accommodate multiple GuC submission clients

== Series Details == Series: Accommodate multiple GuC submission clients URL : https://patchwork.freedesktop.org/series/10847/ State : failure == Summary == Series 10847v1 Accommodate multiple GuC submission clients http://patchwork.freedesktop.org/api/1.0/series/10847/revisions/1/mbox Test

[Intel-gfx] [PATCH v2 3/4] video: Add new aspect ratios for HDMI 2.0

HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds enumeration for the new aspect ratios in the existing aspect ratio list. V2: rebase Signed-off-by: Shashank Sharma Reviewed-by: Sean Paul Cc: Daniel Vetter

[Intel-gfx] [PATCH v2 4/4] drm: Add and handle new aspect ratios in DRM layer

HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise versa. V2: Rebase Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH v2 2/4] drm: Add aspect ratio parsing in DRM layer

Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information

[Intel-gfx] [PATCH v2 1/4] drm: add picture aspect ratio flags

This patch adds drm flag bits for aspect ratio information Currently drm flag bits don't have field for mode's picture aspect ratio. This field will help the driver to pick mode with right aspect ratio, and help in setting right VIC field in avi infoframes. Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH v2 0/4] Picture aspect ratio support in DRM layer

This patch series adds 4 patches. - The first two patches add aspect ratio support in DRM layes - Next two patches add new aspect ratios defined in CEA-861-F supported for HDMI 2.0 4k modes. Adding aspect ratio support in DRM layer: - The CEA videmodes contain aspect ratio information, which we

  1   2   3   >