Re: [Intel-gfx] [PATCH] drm/i915: Keep track of active forcewake domains in a bitmask

On 9/27/2016 6:51 PM, Tvrtko Ursulin wrote: On 27/09/2016 13:26, Chris Wilson wrote: On Tue, Sep 27, 2016 at 01:11:50PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin There are current places in the code, and there will be more in the future, which iterate the

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree

Hi all, Today's linux-next merge of the drm-misc tree got conflicts in: drivers/gpu/drm/sti/sti_dvo.c drivers/gpu/drm/sti/sti_hqvdp.c drivers/gpu/drm/sti/sti_mixer.c between commits: bdfd36ef8e64 ("drm/sti: Fix sparse warnings") b4bba92dfbe2 ("drm/sti: remove stih415-416 platform

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Code cleanup to use dev_priv and INTEL_GEN

== Series Details == Series: drm/i915: Code cleanup to use dev_priv and INTEL_GEN URL : https://patchwork.freedesktop.org/series/12995/ State : warning == Summary == Series 12995v1 drm/i915: Code cleanup to use dev_priv and INTEL_GEN

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Code cleanup to use dev_priv and INTEL_GEN

On Mon, Sep 26, 2016 at 04:45:05PM +0300, Jani Nikula wrote: > On Fri, 16 Sep 2016, Manasi Navare wrote: > > Replace dev with dev_priv and INTEL_INFO with INTEL_GEN > > Patches like this could easily sent separately, or at the very least as > the first patches in the

[Intel-gfx] [PATCH v1] drm/i915: Code cleanup to use dev_priv and INTEL_GEN

From: "Navare, Manasi D" Replace dev with dev_priv and INTEL_INFO with INTEL_GEN v1: * Rebased on drm-nightly (Jani Nikula) * Separated from the link training patch series Signed-off-by: Manasi Navare Reviewed-by: Mika Kahola

Re: [Intel-gfx] [PATCH v3 2/6] drm/i915: Remove the link rate and lane count loop in compute config

On Tue, Sep 27, 2016 at 04:39:38PM +0300, Jani Nikula wrote: > On Mon, 26 Sep 2016, Jani Nikula wrote: > > On Fri, 16 Sep 2016, Manasi Navare wrote: > >> While configuring the pipe during modeset, it should use > >> max clock and max lane

Re: [Intel-gfx] [PATCH v3 2/6] drm/i915: Remove the link rate and lane count loop in compute config

On Mon, Sep 26, 2016 at 04:41:27PM +0300, Jani Nikula wrote: > On Fri, 16 Sep 2016, Manasi Navare wrote: > > While configuring the pipe during modeset, it should use > > max clock and max lane count and reduce the bpp until > > the requested mode rate is less than or

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Update only cur_freq without setting RPNSWREQ when device is suspended

== Series Details == Series: series starting with [1/2] drm/i915: Update only cur_freq without setting RPNSWREQ when device is suspended URL : https://patchwork.freedesktop.org/series/12986/ State : success == Summary == Series 12986v1 Series without cover letter

[Intel-gfx] [PATCH 1/2] drm/i915: Update only cur_freq without setting RPNSWREQ when device is suspended

If min/max frequency is updated from debugfs/sysfs and device is suspended, just update the driver tracking state cur_freq and it will come into effect when HW becomes busy next. Signed-off-by: Chris Wilson Signed-off-by: Sagar Arun Kamble ---

[Intel-gfx] [PATCH 2/2] drm/i915: Handle GEN6_PMINTRMSK for proper masking of RPS interrupts with GuC submission

Driver needs to ensure that it doesn't mask the PM interrupts, which are unmasked/needed by GuC firmware. For that, Driver maintains a bitmask of interrupts to be kept enabled, pm_intr_keep. By default, RP Up/Down Threshold Interrupt bits (and others) in GEN6_PMINTRMSK register were unmasked (by

Re: [Intel-gfx] [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

On Tue, Sep 27, 2016 at 12:54 PM, Emil Velikov wrote: > On 27 September 2016 at 17:43, Joe Perches wrote: >> On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote: >>> On 27 September 2016 at 17:04, Joe Perches wrote: >>> > On Tue,

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

On Tue, 27 Sep 2016, Manasi Navare wrote: > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote: >> On Fri, 16 Sep 2016, Manasi Navare wrote: >> > According to the DisplayPort Spec, in case of Clock Recovery failure >> > the link

Re: [Intel-gfx] [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote: > On 27 September 2016 at 17:04, Joe Perches wrote: > > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote: > > > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote: > > > > Use a bit more consistent

Re: [Intel-gfx] [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

On 27 September 2016 at 17:43, Joe Perches wrote: > On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote: >> On 27 September 2016 at 17:04, Joe Perches wrote: >> > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote: >> > > On Sun, Sep 25, 2016 at 10:18 PM,

Re: [Intel-gfx] [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote: > On 27 September 2016 at 17:04, Joe Perches wrote: > > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote: > > > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote: > > > > Use a bit more consistent

Re: [Intel-gfx] [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

On 27 September 2016 at 17:04, Joe Perches wrote: > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote: >> > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote: >> > Use a bit more consistent style with kernel loglevels >> > I'm not convinced this is worth

Re: [Intel-gfx] [PATCH] drm: Convert prime dma-buf <-> handle to rbtree

On Tue, Sep 27, 2016 at 2:36 AM, David Herrmann wrote: > Hi Chris > > On Mon, Sep 26, 2016 at 10:44 PM, Chris Wilson > wrote: >> Currently we use a linear walk to lookup a handle and return a dma-buf, >> and vice versa. A long overdue TODO task

Re: [Intel-gfx] [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote: > > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote: > > Use a bit more consistent style with kernel loglevels > > I'm not convinced this is worth doing if we're going to keep the > WARN/WARNING discrepancy, and I don't

Re: [Intel-gfx] [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote: > Use a bit more consistent style with kernel loglevels I'm not convinced this is worth doing if we're going to keep the WARN/WARNING discrepancy, and I don't think we should switch DRM_WARN to DRM_WARNING since it's so

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix HDMI DPLL configuration

On ti, 2016-09-27 at 16:04 +0300, Ander Conselvan De Oliveira wrote: > On Tue, 2016-09-27 at 14:26 +0300, Imre Deak wrote: > > On ti, 2016-09-27 at 11:03 +0300, Ander Conselvan De Oliveira > > wrote: > > > > > > On Mon, 2016-09-26 at 17:54 +0300, Imre Deak wrote: > > > > > > > > a277ca7dc01d

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote: > On Fri, 16 Sep 2016, Manasi Navare wrote: > > According to the DisplayPort Spec, in case of Clock Recovery failure > > the link training sequence should fall back to the lower link rate > > followed by lower

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix HDMI DPLL configuration

On Tue, Sep 27, 2016 at 05:08:34PM +0300, Imre Deak wrote: > On ti, 2016-09-27 at 15:46 +0300, Ville Syrjälä wrote: > > On Tue, Sep 27, 2016 at 02:07:11PM +0300, Imre Deak wrote: > > > On ma, 2016-09-26 at 15:25 +, Patchwork wrote: > > > > == Series Details == > > > > > > > > Series:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix HDMI DPLL configuration

On ti, 2016-09-27 at 15:46 +0300, Ville Syrjälä wrote: > On Tue, Sep 27, 2016 at 02:07:11PM +0300, Imre Deak wrote: > > On ma, 2016-09-26 at 15:25 +, Patchwork wrote: > > > == Series Details == > > > > > > Series: drm/i915/bxt: Fix HDMI DPLL configuration > > > URL   :

Re: [Intel-gfx] [PATCH v18 5/6] drm/i915/dp: Enable Upfront link training on DDI platforms

On Wed, 21 Sep 2016, Manasi Navare wrote: > 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

Re: [Intel-gfx] [PATCH v3 2/6] drm/i915: Remove the link rate and lane count loop in compute config

On Mon, 26 Sep 2016, Jani Nikula wrote: > On Fri, 16 Sep 2016, Manasi Navare wrote: >> While configuring the pipe during modeset, it should use >> max clock and max lane count and reduce the bpp until >> the requested mode rate is less than

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Keep track of active forcewake domains in a bitmask

== Series Details == Series: drm/i915: Keep track of active forcewake domains in a bitmask URL : https://patchwork.freedesktop.org/series/12960/ State : warning == Summary == Series 12960v1 drm/i915: Keep track of active forcewake domains in a bitmask

Re: [Intel-gfx] [PATCH] drm/i915: Keep track of active forcewake domains in a bitmask

On 27/09/2016 13:26, Chris Wilson wrote: On Tue, Sep 27, 2016 at 01:11:50PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin There are current places in the code, and there will be more in the future, which iterate the forcewake domains to find out which ones are

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix HDMI DPLL configuration

On Tue, 2016-09-27 at 14:26 +0300, Imre Deak wrote: > On ti, 2016-09-27 at 11:03 +0300, Ander Conselvan De Oliveira wrote: > > > > On Mon, 2016-09-26 at 17:54 +0300, Imre Deak wrote: > > > > > > a277ca7dc01d should've been a no-functional-change commit, but it > > > removed the initialization of

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

== Series Details == Series: drm/i915: Cleanup i915_gem_request_add_to_client URL : https://patchwork.freedesktop.org/series/12959/ State : success == Summary == Series 12959v1 drm/i915: Cleanup i915_gem_request_add_to_client

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix HDMI DPLL configuration

On Tue, Sep 27, 2016 at 02:07:11PM +0300, Imre Deak wrote: > On ma, 2016-09-26 at 15:25 +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/bxt: Fix HDMI DPLL configuration > > URL   : https://patchwork.freedesktop.org/series/12930/ > > State : failure > > > > == Summary ==

Re: [Intel-gfx] [PATCH] drm/i915: Cleanup i915_gem_request_add_to_client

On 27/09/2016 13:19, Chris Wilson wrote: On Tue, Sep 27, 2016 at 01:07:13PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Several things we can clean up in this function: * Request and file passed in cannot be NULL. There is a single caller which makes it

Re: [Intel-gfx] [PATCH] drm/i915: Keep track of active forcewake domains in a bitmask

On Tue, Sep 27, 2016 at 01:11:50PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > There are current places in the code, and there will be more in the > future, which iterate the forcewake domains to find out which ones > are currently active. > > To save them

Re: [Intel-gfx] [PATCH] drm/i915: Cleanup i915_gem_request_add_to_client

On Tue, Sep 27, 2016 at 01:07:13PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Several things we can clean up in this function: > > * Request and file passed in cannot be NULL. There is >a single caller which makes it impossible so change >that

[Intel-gfx] [PATCH] drm/i915: Keep track of active forcewake domains in a bitmask

From: Tvrtko Ursulin There are current places in the code, and there will be more in the future, which iterate the forcewake domains to find out which ones are currently active. To save them from doing this iteration, we can cheaply keep a mask of active domains in

[Intel-gfx] [PATCH] drm/i915: Cleanup i915_gem_request_add_to_client

From: Tvrtko Ursulin Several things we can clean up in this function: * Request and file passed in cannot be NULL. There is a single caller which makes it impossible so change that condition to a GEM_BUG_ON instead of a WARN with a return code. * Same is

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix HDMI DPLL configuration

On ti, 2016-09-27 at 11:03 +0300, Ander Conselvan De Oliveira wrote: > On Mon, 2016-09-26 at 17:54 +0300, Imre Deak wrote: > > a277ca7dc01d should've been a no-functional-change commit, but it > > removed the initialization of the dpll_hw_state for HDMI outputs, > > resulting in state mismatches

Re: [Intel-gfx] [PATCH v2] Idleness DRRS test

Hi Chris, Thanks for the comments. I will try out the changes you have mentioned for counting vblanks. For other comments please find the responses inline. On 9/23/2016 6:48 PM, Chris Wilson wrote: On Fri, Sep 23, 2016 at 06:10:29PM +0530, Nautiyal Ankit wrote: From: Ramalingam C

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix HDMI DPLL configuration

On ma, 2016-09-26 at 15:25 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/bxt: Fix HDMI DPLL configuration > URL   : https://patchwork.freedesktop.org/series/12930/ > State : failure > > == Summary == > > Series 12930v1 drm/i915/bxt: Fix HDMI DPLL configuration >

Re: [Intel-gfx] [PATCH v3 03/15] drm: Add support for optional per-plane rotation property

On Tue, Sep 27, 2016 at 12:54:46PM +0300, Joonas Lahtinen wrote: > On ma, 2016-09-26 at 19:30 +0300, ville.syrj...@linux.intel.com wrote: > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > > > index 85172a977bf3..e52aece30900 100644 > > ---

Re: [Intel-gfx] [PATCH v2 15/15] drm/i915: Add horizontal mirroring support for CHV pipe B planes

On ma, 2016-09-26 at 19:31 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The primary and sprite planes on CHV pipe B support horizontal > mirroring. Expose it to the world. > > Sadly the hardware ignores the mirror bit when the rotate bit

Re: [Intel-gfx] [PATCH v2 12/15] drm: RIP mode_config->rotation_property

On ma, 2016-09-26 at 19:30 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that all drivers have been converted over to the per-plane rotation > property, we can just nuke the global rotation property. > > v2: Rebase due to

Re: [Intel-gfx] [PATCH v3 11/15] drm/i915: Use the per-plane rotation property

On ma, 2016-09-26 at 19:30 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > On certain platforms not all planes support the same set of > rotations/reflections, so let's use the per-plane property > for this. > > This is already a problem on

Re: [Intel-gfx] [PATCH v3 03/15] drm: Add support for optional per-plane rotation property

On ma, 2016-09-26 at 19:30 +0300, ville.syrj...@linux.intel.com wrote: > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > index 85172a977bf3..e52aece30900 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c Now that I'm thinking, *_zpos_* fits

Re: [Intel-gfx] [PATCH i-g-t] lib: Do two writes to /proc/sys/vm/drop_caches again

On Tue, Sep 27, 2016 at 12:22:12PM +0300, Petri Latvala wrote: > The drop_caches sysctl has a max value of 4, so writing 7 to it just > fails. Avoid the earlier two-writes problem by opening the fd twice. > > v2: Don't lseek(), open() twice. (Chris) > > Signed-off-by: Petri Latvala

Re: [Intel-gfx] [PATCH v2 01/15] drm: Add drm_rotation_90_or_270()

On ma, 2016-09-26 at 19:30 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > We have intel_rotation_90_or_270() in i915 to check if the rotation is > 90 or 270 degrees. Similar checks are elsewhere in drm, so let's move > the helper into a

[Intel-gfx] [PATCH i-g-t] lib: Do two writes to /proc/sys/vm/drop_caches again

The drop_caches sysctl has a max value of 4, so writing 7 to it just fails. Avoid the earlier two-writes problem by opening the fd twice. v2: Don't lseek(), open() twice. (Chris) Signed-off-by: Petri Latvala --- lib/intel_os.c | 13 +++-- 1 file changed, 11

Re: [Intel-gfx] [PATCH 11/38] drm/i915: Introduce an internal allocator for disposable private objects

On Wed, Sep 21, 2016 at 02:50:34PM +0300, Joonas Lahtinen wrote: > On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote: > > Quite a few of our objects used for internal hardware programming do not > > benefit from being swappable or from being zero initialised. As such > > they do not benefit

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix HDMI DPLL configuration

On Mon, 2016-09-26 at 17:54 +0300, Imre Deak wrote: > a277ca7dc01d should've been a no-functional-change commit, but it > removed the initialization of the dpll_hw_state for HDMI outputs, > resulting in state mismatches and a failed modeset with blank > screen. Fix this by reinstating the

Re: [Intel-gfx] [PATCH i-g-t] lib: Do two writes to /proc/sys/vm/drop_caches again

On Tue, Sep 27, 2016 at 10:45:17AM +0300, Petri Latvala wrote: > The drop_caches sysctl has a max value of 4, so writing 7 to it just > fails. Avoid the earlier two-writes problem by seeking to the > beginning between writes. > > Signed-off-by: Petri Latvala > --- >

[Intel-gfx] [PATCH i-g-t] lib: Do two writes to /proc/sys/vm/drop_caches again

The drop_caches sysctl has a max value of 4, so writing 7 to it just fails. Avoid the earlier two-writes problem by seeking to the beginning between writes. Signed-off-by: Petri Latvala --- lib/intel_os.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-)

Re: [Intel-gfx] [PATCH 6/9] drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations

On 22/09/2016 22:00, Paulo Zanoni wrote: The confusing thing is that plane_blocks_per_line is listed as part of the method 2 calculation but is also used for other things. We calculated it in two different places and different ways: one inside skl_wm_method2() and the other inside

Re: [Intel-gfx] [PATCH 2/2] kms_atomic: plane_primary: Allow modeset if atomic check returns -EINVAL

On 12 September 2016 at 09:11, Liu Ying wrote: > Allowing modeset may prevent the test case from failing in case the atomic > check phase finds the userspace doesn't allow modeset for the commit and > returns -EINVAL. A real case is to run the test case on imx-drm which >

Re: [Intel-gfx] [PATCH 5/9] drm/i915/gen9: minimum scanlines for Y tile is not always 4

Hi, On 22/09/2016 22:00, Paulo Zanoni wrote: During watermarks calculations, this value is used in 3 different places. Only one of them was not using a hardcoded 4. Move the code up so everybody can benefit from the actual value. This should only help on situations with Y tiling + 90/270

Re: [Intel-gfx] [PATCH 1/2] drm/i915: add a few missing platform tags to workaround tags

On Mon, 26 Sep 2016, Paulo Zanoni wrote: > Em Seg, 2016-09-26 às 15:07 +0300, Jani Nikula escreveu: >> Cc: Paulo Zanoni >> Signed-off-by: Jani Nikula > > Reviewed-by: Paulo Zanoni Thanks,

Re: [Intel-gfx] [PATCH] drm: Convert prime dma-buf <-> handle to rbtree

Hi Chris On Mon, Sep 26, 2016 at 10:44 PM, Chris Wilson wrote: > Currently we use a linear walk to lookup a handle and return a dma-buf, > and vice versa. A long overdue TODO task is to convert that to a > hashtable. Since the initial implementation of dma-buf/prime, we