Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Make prepare_fb/cleanup_fb only take state, v3.

Op 02-09-15 om 17:24 schreef Daniel Vetter: > On Wed, Sep 02, 2015 at 03:36:33PM +0100, Daniel Stone wrote: >> On 2 September 2015 at 09:42, Maarten Lankhorst >> wrote: >>> This removes the need to separately track fb changes i915. >>> That will be done as a

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()

On Thu, Sep 10, 2015 at 06:59:08PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc() > where it belongs instead of doing it in intel_modeset_readout_hw_state(). > > The

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Update legacy primary state outside the commit hook.

On Mon, Sep 14, 2015 at 11:52:26AM +0200, Maarten Lankhorst wrote: > Op 10-09-15 om 17:41 schreef Daniel Vetter: > > On Thu, Sep 10, 2015 at 04:08:01PM +0200, Maarten Lankhorst wrote: > >> This should allow not running plane commit when the crtc is off. > >> While the atomic helpers update those,

[Intel-gfx] [RFC PATCH 1/3] drm/i915: Make wait_for_flips interruptible.

Move it from intel_crtc_atomic_commit to prepare_plane_fb. Waiting is done before committing, otherwise it's too late to undo the changes. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_atomic.c | 2 - drivers/gpu/drm/i915/intel_display.c |

[Intel-gfx] [RFC PATCH 2/3] drm/i915: Change locking for struct_mutex.

Only acquire the struct_mutex once, and interruptibly. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

Re: [Intel-gfx] [PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements

On 09/13/2015 05:58 PM, Daniel Vetter wrote: > On Sun, Sep 13, 2015 at 9:13 PM, Jonathan Corbet wrote: >> On Sun, 13 Sep 2015 12:36:07 +0200 >> Daniel Vetter wrote: >> >>> Personally I don't care which kind of text markup we pick and wich >>> converter, as long

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add .get_hw_state() method for planes

Op 10-09-15 om 17:59 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > Add a .get_hw_state() method for planes, returning true or false > depending on whether the plane is enabled. Use it to populate the > plane state 'visible' during state readout. >

Re: [Intel-gfx] [fixup PATCH] drm/i915: Only commit active planes when updating planes during reset.

On Mon, Sep 14, 2015 at 11:41:51AM +0200, Maarten Lankhorst wrote: > In a future commit commit_plane will no longer check if the crtc is active. > To prevent issues with legacy page flips the check should be performed inside > update_primary_planes. > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [RFC CABC v3 PATCH 2/2] drm/i915: CABC support for backlight control

On Mon, Sep 14, 2015 at 01:10:01PM +0300, Jani Nikula wrote: > On Mon, 14 Sep 2015, Daniel Vetter wrote: > > On Fri, Sep 11, 2015 at 02:28:02PM +0300, Jani Nikula wrote: > >> On Fri, 11 Sep 2015, Deepak M wrote: > >> > In CABC (Content Adaptive Brightness

Re: [Intel-gfx] [PATCH] drm/i915: fixing eu_mask value for BXT due to wrong bit mapping (v2)

On pe, 2015-09-11 at 16:31 -0700, Dongwon Kim wrote: > From: dw kim > > Correct bit mapping of EUs in 'eu_disable' fuse register > for each subslice is (each word represents one subslice), > > bit # 7 6 5 4 3 2 1 0 > EU # 11 10 9 8 3 2 1 0 > >

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Assign hwmode after encoder state readout

On Thu, Sep 10, 2015 at 06:59:07PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The dotclock is often calculated in encoder .get_config(), so we > shouldn't copy the adjusted_mode to hwmode until we have read out the > dotclock. > > Gets

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Move scanline_offset and timestamping constant setup to intel_modeset_readout_hw_state()

Op 10-09-15 om 17:59 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > intel_modeset_readout_hw_state() seems like the more appropriate place > for populating the scanline_offset and timestamping constants than > intel_sanitize_crtc() since they are

Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well

On Mon, Sep 14, 2015 at 11:50:29AM +0200, Daniel Vetter wrote: > On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote: > > We need to be able to control if DC6 is allowed or not. Much like > > requesting power to a specific piece of the hardware we need to be able > > to request that

[Intel-gfx] [PATCH 1/1] drm/i915: make backlight hooks connector specific

Previously we've relied on having basically one backlight and one backlight type per platform. This is already a bit quirky with PMIC PWM support on VLV/CHV platforms with MIPI DSI. In the foreseeable future we'll have at least DPCD based backlight control on eDP and DCS command based backlight

Re: [Intel-gfx] [PATCH 0/1] drm/i915: connector specific backlight hooks for eDP/DSI

On Mon, 14 Sep 2015, Jani Nikula wrote: > Hi all - > > This patch moves the backlight hooks from dev_priv->display to > intel_panel. This should enable connector specific backlight control > mechanisms, such as DPCD for eDP and DCS commands for DSI, to be neatly > connected

Re: [Intel-gfx] [RFC CABC v3 PATCH 2/2] drm/i915: CABC support for backlight control

On Mon, 14 Sep 2015, Jani Nikula wrote: > On Mon, 14 Sep 2015, Daniel Vetter wrote: >> On Fri, Sep 11, 2015 at 02:28:02PM +0300, Jani Nikula wrote: >>> On Fri, 11 Sep 2015, Deepak M wrote: >>> > In CABC (Content Adaptive

Re: [Intel-gfx] [PATCH] drm/i915: workaround bad DSL readout v2

On Mon, Sep 14, 2015 at 11:10:04AM +0200, Daniel Vetter wrote: > On Fri, Sep 11, 2015 at 01:33:08AM +0300, Ville Syrjälä wrote: > > On Thu, Sep 10, 2015 at 02:57:32PM -0700, Jesse Barnes wrote: > > > On 09/10/2015 02:53 PM, Ville Syrjälä wrote: > > > > On Thu, Sep 10, 2015 at 02:38:53PM -0700,

Re: [Intel-gfx] [PATCH] drm/i915: Backlight Control over AUX feature

On Mon, Sep 14, 2015 at 01:00:26PM +0300, Jani Nikula wrote: > On Thu, 10 Sep 2015, Yetunde Adebisi wrote: > > This patch adds support for Backlight Control over the AUX channel for > > DP and eDP connectors. It allows the backlight of DP and eDP connected > > displays

[Intel-gfx] [PATCH] drm/i915: Add link training test

--- On Fri, 2015-09-11 at 17:11 +0300, Ander Conselvan de Oliveira wrote: > On Wed, 2015-09-09 at 11:33 +0100, Thomas Wood wrote: > > On 8 September 2015 at 13:28, Ander Conselvan de Oliveira > > wrote: > > > > > > > diff --git

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Move scanline_offset and timestamping constant setup to intel_modeset_readout_hw_state()

On Thu, Sep 10, 2015 at 06:59:10PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > intel_modeset_readout_hw_state() seems like the more appropriate place > for populating the scanline_offset and timestamping constants than >

Re: [Intel-gfx] [PATCH] drm/i915: Add link training test

On Mon, Sep 14, 2015 at 02:51:51PM +0300, Ander Conselvan de Oliveira wrote: > --- > > On Fri, 2015-09-11 at 17:11 +0300, Ander Conselvan de Oliveira wrote: > > On Wed, 2015-09-09 at 11:33 +0100, Thomas Wood wrote: > > > On 8 September 2015 at 13:28, Ander Conselvan de Oliveira > > >

[Intel-gfx] [PATCH 0.5/2] drm/i915: Make prepare_plane_fb fully interruptible.

Now that we agreed on not preserving framebuffers pinning is finally allowed to fail because of signals. Use this to make pinning and acquire the mutex in an interruptible way too. Unpinning is still uninterruptible, because it happens as a cleanup of old state, or undoing pins after one of the

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add HDMI probe function

On Mon, Sep 14, 2015 at 09:55:33AM +, Sharma, Shashank wrote: > > You need to inject a fake hpd or similar everytime the world might have > > changed from under us, which isn't just init but also system resume. > This is a fake hpd only, just without wrapper, if you want, we can > create a

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Update legacy primary state outside the commit hook.

Op 14-09-15 om 15:13 schreef Daniel Vetter: > On Mon, Sep 14, 2015 at 11:52:26AM +0200, Maarten Lankhorst wrote: >> Op 10-09-15 om 17:41 schreef Daniel Vetter: >>> On Thu, Sep 10, 2015 at 04:08:01PM +0200, Maarten Lankhorst wrote: This should allow not running plane commit when the crtc is

[Intel-gfx] [PATCH 0/1] drm/i915: connector specific backlight hooks for eDP/DSI

Hi all - This patch moves the backlight hooks from dev_priv->display to intel_panel. This should enable connector specific backlight control mechanisms, such as DPCD for eDP and DCS commands for DSI, to be neatly connected to the existing backlight infrastructure. Basically it should be

Re: [Intel-gfx] [PATCH] drm/i915: CABC support for backlight control

On Mon, 14 Sep 2015, Deepak M wrote: > In CABC (Content Adaptive Brightness Control) content grey level > scale can be increased while simultaneously decreasing > brightness of the backlight to achieve same perceived brightness. > > The CABC is not standardized and panel

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add .get_hw_state() method for planes

On Mon, Sep 14, 2015 at 02:10:20PM +0200, Maarten Lankhorst wrote: > Op 10-09-15 om 17:59 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä > > > > Add a .get_hw_state() method for planes, returning true or false > > depending on whether the plane is

Re: [Intel-gfx] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote: > Gen8+ supports 48-bit virtual addresses, but some objects must always be > allocated inside the 32-bit address range. > > In specific, any resource used with flat/heapless (0x-0xf000) > General State Heap (GSH) or

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gen9: WA ST Unit Power Optimization Disable

Reviewed-by: Sagar Arun Kamble On 9/14/2015 2:55 PM, Arun Siluvery wrote: On 12/09/2015 17:52, Kamble, Sagar A wrote: On 9/8/2015 3:01 PM, Arun Siluvery wrote: From: Robert Beckett WaDisableSTUnitPowerOptimization:skl,bxt

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gen9: WA ST Unit Power Optimization Disable

On Mon, Sep 14, 2015 at 08:21:20PM +0530, Kamble, Sagar A wrote: > Reviewed-by: Sagar Arun Kamble Queued for -next, thanks for the patch. -Daniel > > On 9/14/2015 2:55 PM, Arun Siluvery wrote: > >On 12/09/2015 17:52, Kamble, Sagar A wrote: > >> > >> > >>On 9/8/2015

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Use atomic plane state in the primary plane update.

On Thu, Sep 10, 2015 at 04:07:56PM +0200, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/intel_display.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add HDMI probe function

Regards Shashank On 9/14/2015 6:37 PM, Daniel Vetter wrote: On Mon, Sep 14, 2015 at 09:55:33AM +, Sharma, Shashank wrote: You need to inject a fake hpd or similar everytime the world might have changed from under us, which isn't just init but also system resume. This is a fake hpd only,

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Update legacy primary state outside the commit hook.

On Mon, Sep 14, 2015 at 03:16:20PM +0200, Maarten Lankhorst wrote: > Op 14-09-15 om 15:13 schreef Daniel Vetter: > > On Mon, Sep 14, 2015 at 11:52:26AM +0200, Maarten Lankhorst wrote: > >> Op 10-09-15 om 17:41 schreef Daniel Vetter: > >>> On Thu, Sep 10, 2015 at 04:08:01PM +0200, Maarten Lankhorst

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Move scanline_offset and timestamping constant setup to intel_modeset_readout_hw_state()

On Mon, Sep 14, 2015 at 01:57:45PM +0200, Maarten Lankhorst wrote: > Op 10-09-15 om 17:59 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä > > > > intel_modeset_readout_hw_state() seems like the more appropriate place > > for populating the

Re: [Intel-gfx] [PATCH] drm/i915: Backlight Control over AUX feature

> -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Monday, September 14, 2015 11:00 AM > To: Adebisi, YetundeX; Intel-gfx@lists.freedesktop.org > Cc: Adebisi, YetundeX > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Backlight Control over AUX feature > >

Re: [Intel-gfx] [RFC CABC v3 PATCH 2/2] drm/i915: CABC support for backlight control

On Mon, 14 Sep 2015, Daniel Vetter wrote: > On Mon, Sep 14, 2015 at 01:10:01PM +0300, Jani Nikula wrote: >> On Mon, 14 Sep 2015, Daniel Vetter wrote: >> > On Fri, Sep 11, 2015 at 02:28:02PM +0300, Jani Nikula wrote: >> >> On Fri, 11 Sep 2015, Deepak M

Re: [Intel-gfx] [PATCH] drm/i915: workaround bad DSL readout v2

On Mon, Sep 14, 2015 at 04:02:44PM +0300, Ville Syrjälä wrote: > On Mon, Sep 14, 2015 at 11:10:04AM +0200, Daniel Vetter wrote: > > On Fri, Sep 11, 2015 at 01:33:08AM +0300, Ville Syrjälä wrote: > > > On Thu, Sep 10, 2015 at 02:57:32PM -0700, Jesse Barnes wrote: > > > > On 09/10/2015 02:53 PM,

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Use atomic plane state in the primary plane update.

On Mon, Sep 14, 2015 at 04:23:35PM +0200, Daniel Vetter wrote: > On Mon, Sep 14, 2015 at 04:27:23PM +0300, Ville Syrjälä wrote: > > On Thu, Sep 10, 2015 at 04:07:56PM +0200, Maarten Lankhorst wrote: > > > Signed-off-by: Maarten Lankhorst > > > --- > > >

Re: [Intel-gfx] [PATCH] drm/i915: Add link training test

On Mon, 2015-09-14 at 15:11 +0200, Daniel Vetter wrote: > On Mon, Sep 14, 2015 at 02:51:51PM +0300, Ander Conselvan de Oliveira wrote: > > --- > > > > On Fri, 2015-09-11 at 17:11 +0300, Ander Conselvan de Oliveira wrote: > > > On Wed, 2015-09-09 at 11:33 +0100, Thomas Wood wrote: > > > > On 8

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only check pipe state for fast modeset when it's possible.

On Mon, Sep 14, 2015 at 11:30:11AM +0200, Maarten Lankhorst wrote: > A fast modeset can only be performed when connectors and active are > not changed. This prevents a lot of KMS spam when going from a NULL > mode with 0 connectors to an actual mode. > > When a crtc is inactive there's no need to

Re: [Intel-gfx] [PATCH 1/1] drm/i915: make backlight hooks connector specific

On Mon, Sep 14, 2015 at 02:03:48PM +0300, Jani Nikula wrote: > Previously we've relied on having basically one backlight and one > backlight type per platform. This is already a bit quirky with PMIC PWM > support on VLV/CHV platforms with MIPI DSI. In the foreseeable future > we'll have at least

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Use atomic plane state in the primary plane update.

On Mon, Sep 14, 2015 at 04:27:23PM +0300, Ville Syrjälä wrote: > On Thu, Sep 10, 2015 at 04:07:56PM +0200, Maarten Lankhorst wrote: > > Signed-off-by: Maarten Lankhorst > > --- > > drivers/gpu/drm/i915/intel_display.c | 4 +++- > > 1 file changed, 3

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Use atomic plane state in the primary plane update.

Op 14-09-15 om 15:27 schreef Ville Syrjälä: > On Thu, Sep 10, 2015 at 04:07:56PM +0200, Maarten Lankhorst wrote: >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/i915/intel_display.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >>

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Use atomic plane state in the primary plane update.

On Mon, Sep 14, 2015 at 03:40:47PM +0200, Maarten Lankhorst wrote: > Op 14-09-15 om 15:27 schreef Ville Syrjälä: > > On Thu, Sep 10, 2015 at 04:07:56PM +0200, Maarten Lankhorst wrote: > >> Signed-off-by: Maarten Lankhorst > >> --- > >>

Re: [Intel-gfx] [PATCH 00/39] drop null test before destroy functions

> Recent commits to kernel/git/torvalds/linux.git have made the following > functions able to tolerate NULL arguments: > > kmem_cache_destroy (commit 3942d29918522) > mempool_destroy (commit 4e3ca3e033d1) > dma_pool_destroy (commit 44d7175da6ea) How do you think about to extend an other SmPL

Re: [Intel-gfx] [PATCH] drm/i915: CABC support for backlight control

>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Monday, September 14, 2015 5:51 PM >To: Deepak, M; intel-gfx@lists.freedesktop.org >Cc: Deepak, M >Subject: Re: [Intel-gfx] [PATCH] drm/i915: CABC support for backlight control > >On Mon, 14 Sep 2015,

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave, -rc1 is out the door and here's my first pull request for drm-next. It's all over: - better atomic helpers for runtime pm drivers - atomic fbdev - dp aux i2c STATUS_UPDATE handling (for short i2c replies from the sink) - bunch of constify patches - various polish all over There's a few

[Intel-gfx] [PATCH v2 1/1] drm/i915: Fix fb object's frontbuffer-bits

Shared frontbuffer bits are causing warnings when same FB is displayed in another plane without clearing the bits from previous plane. v2: Removing coversion of fb bits to 64 bit as it is not needed for now. (Daniel) Change-Id: Ic2df80747f314b82afd22f8326297c57d1e652c6 Signed-off-by: Sagar Arun

Re: [Intel-gfx] [PATCH] drm/i915: Backlight Control over AUX feature

> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Thursday, September 10, 2015 4:21 PM > To: Adebisi, YetundeX > Cc: Intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Backlight Control over AUX

Re: [Intel-gfx] [PATCH] drm/i915: fix crash in error state readout on non-execlist platforms

On 14/09/15 10:21, Daniel Vetter wrote: On Thu, Sep 10, 2015 at 03:07:00PM -0700, Yu Dai wrote: Agree. The LRC prefix is confusing. Thanks for the patch. -Alex Care to do an official r-b? Thanks, Daniel On 09/10/2015 02:58 PM, Jesse Barnes wrote: That looks like it would, but I think

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Fix fb object's frontbuffer-bits

On Mon, Sep 14, 2015 at 09:35:42PM +0530, Sagar Arun Kamble wrote: > Shared frontbuffer bits are causing warnings when same FB is displayed > in another plane without clearing the bits from previous plane. > > v2: Removing coversion of fb bits to 64 bit as it is not needed for now. > (Daniel) >

Re: [Intel-gfx] [PATCH] drm/i915: Backlight Control over AUX feature

On Mon, Sep 14, 2015 at 04:29:05PM +, Adebisi, YetundeX wrote: > > > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Thursday, September 10, 2015 4:21 PM > > To: Adebisi, YetundeX > > Cc:

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only check pipe state for fast modeset when it's possible.

Hi, On 14 September 2015 at 10:30, Maarten Lankhorst wrote: > @@ -13013,14 +13013,15 @@ static int intel_atomic_check(struct drm_device > *dev, > if (ret) > return ret; > > - if

Re: [Intel-gfx] [PATCH] drm/i915: Make sure fb objects with rotated views are also fenceable

On Sat, 12 Sep 2015 08:49:08 +0100 Chris Wilson wrote: > On Fri, Sep 11, 2015 at 06:44:26PM -0700, Vivek Kasireddy wrote: > > From: Vivek Kasireddy > > > > Currently, fb objects with rotated views are ignored while pinning. > > Therefore,

Re: [Intel-gfx] [PATCH] drm/i915: Make sure fb objects with rotated views are also fenceable

On Mon, 14 Sep 2015 10:08:19 +0100 Tvrtko Ursulin wrote: > > Hi, > > On 09/12/2015 02:44 AM, Vivek Kasireddy wrote: > > From: Vivek Kasireddy > > > > Currently, fb objects with rotated views are ignored while pinning. > > Therefore,

Re: [Intel-gfx] Linux 4.3-rc1

Hi, I have reported the same issue in [0]... You write in [1]... [ cut here ] WARNING: CPU: 3 PID: 24 at drivers/gpu/drm/i915/intel_display.c:1377 assert_planes_disabled+0xe4/0x150 [i915]() plane A assertion failure, should be disabled but not ... I can confirm this was

[Intel-gfx] [PATCH 01/14] drm/i915: Drop redundant watermark programming

In commit commit e4ca061275ec6a48b66c6edebe08644e666994c0 Author: Patrik Jakobsson Date: Wed Jul 8 15:31:52 2015 +0200 drm/i915: Don't forget to mark crtc as inactive after disable we added extra watermark updates to all

[Intel-gfx] [PATCH 10/14] drm/i915: Calculate pipe watermarks into CRTC state (v3)

A future patch will calculate these during the atomic 'check' phase rather than at WM programming time, so let's store the watermark values we're planning to use in the CRTC state; the values actually active on the hardware remains in intel_crtc. While we're at it, do some minor restructuring to

[Intel-gfx] [PATCH 05/14] drm/i915/skl: Simplify wm structures slightly (v2)

A bunch of SKL watermark-related structures have the cursor plane as a separate entry from the rest of the planes. Since a previous patch updated I915_MAX_PLANES such that those plane arrays now have a slot for the cursor, update the code to use the new slot in the existing plane arrays and kill

[Intel-gfx] [PATCH 14/14] drm/i915: Add two-stage ILK-style watermark programming (v4)

In addition to calculating final watermarks, let's also pre-calculate a set of intermediate watermark values at atomic check time. These intermediate watermarks are a combination of the watermarks for the old state and the new state; they should satisfy the requirements of both states which means

[Intel-gfx] [PATCH 04/14] drm/i915: Determine I915_MAX_PLANES from plane enum

Let the compiler figure out what I915_MAX_PLANES is from 'enum plane' so that we don't need a separate #define. While we're at it, add the cursor plane to the enum. This will cause I915_MAX_PLANES to now include the cursor plane in its count (it didn't previously). This change is safe since we

[Intel-gfx] [PATCH 02/14] drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)

Just pull the info out of the plane state structure rather than staging it in an additional structure. v2: Add 'visible' condition to sprites_scaled so that we don't limit the WM level when the sprite isn't enabled. (Ville) Signed-off-by: Matt Roper

[Intel-gfx] [PATCH 09/14] drm/i915: Refactor ilk_update_wm (v3)

From: Ville Syrjälä Split ilk_update_wm() into two parts; one doing the programming and the other the calculations. v2: Fix typo in commit message v3 (by Matt): Heavily rebased for current codebase. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 08/14] drm/i915: Drop intel_update_sprite_watermarks

The only platform that still has an update_sprite_wm entrypoint is SKL; on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and then performs a regular watermark update. However intel_plane->wm is only used to update a couple fields in intel_wm_config, and those fields are never

[Intel-gfx] [PATCH 03/14] drm/i915: Eliminate usage of pipe_wm_parameters from ILK-style WM (v2)

Just pull the info out of the CRTC state structure rather than staging it in an additional structure. Note that we use cstate->active rather than intel_crtc->active which may appear to be a change in behavior. However since we're no longer trying to recalculate watermarks during the "pipe off"

[Intel-gfx] [PATCH 13/14] drm/i915: Calculate watermark configuration during atomic check (v2)

v2: Don't forget to actually check the cstate->active value when tallying up the number of active CRTC's. (Ander) Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_drv.h | 10 ++ drivers/gpu/drm/i915/intel_display.c | 52

[Intel-gfx] [PATCH 12/14] drm/i915: Don't set plane visible during HW readout if CRTC is off

We already ensure that pstate->visible = false when crtc->active = false during runtime programming; make sure we follow the same logic when reading out initial hardware state. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed,

[Intel-gfx] [PATCH 06/14] drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v2)

Just pull the info out of the state structures rather than staging it in an additional set of structures. To make this more straightforward, we change the signature of several internal WM functions to take the crtc state as a parameter. v2: - Don't forget to skip cursor planes on a loop in the

[Intel-gfx] [PATCH 00/14] Atomic watermark updates (v4)

Previous revision is here: http://lists.freedesktop.org/archives/intel-gfx/2015-August/074161.html Key changes: - Lots of bugfixes from review comments by Ander and Ville (and a couple I found on my own) - We now keep the active watermarks in intel_crtc, but pre-calculate to future

[Intel-gfx] [PATCH 11/14] drm/i915: Calculate ILK-style watermarks during atomic check (v3)

Calculate pipe watermarks during atomic calculation phase, based on the contents of the atomic transaction's state structure. We still program the watermarks at the same time we did before, but the computation now happens much earlier. While this patch isn't too exciting by itself, it paves the

[Intel-gfx] [PATCH 07/14] drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check

Determine whether we need to apply this workaround at atomic check time and just set a flag that will be used by the main watermark update routine. Moving this workaround into the atomic framework reduces ilk_update_sprite_wm() to just a standard watermark update, so drop it completely and just

[Intel-gfx] [PATCH] drm/i915: Don't leak VBT mode data

We allocate memory for LVDS modes while parsing the VBT at startup, but never free this memory when the driver is unloaded, causing a small leak. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_dma.c | 4 1 file changed, 4 insertions(+) diff --git

[Intel-gfx] [PATCH] drm/i915: Check live status before reading edid

The Bspec is very clear that Live status must be checked about before trying to read EDID over DDC channel. This patch makes sure that HDMI EDID is read only when live status is up. The live status doesn't seem to perform very consistent across various platforms when tested with different

[Intel-gfx] [REGRESSION] drm/i915/gen9: Removed byte swapping for csr firmware

On Fri, Sep 11, 2015 at 06:29:19PM +0300, Mika Kuoppala wrote: > Daniel Vetter writes: > > > On Tue, Aug 04, 2015 at 11:25:40AM +0530, Animesh Manna wrote: > >> > >> > >> On 8/4/2015 9:16 AM, Nagaraju, Vathsala wrote: > >> >"This patch contains the changes to remove the byte

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Make updating pipe without modeset atomic.

On Thu, Sep 10, 2015 at 12:31:03PM -0700, Jesse Barnes wrote: > On 08/27/2015 06:44 AM, Maarten Lankhorst wrote: > > + /* on skylake this is done by detaching scalers */ > > + if (INTEL_INFO(dev)->gen == 9) { > > + skl_detach_scalers(crtc); > > + > > + if

Re: [Intel-gfx] [DMC_BUGFIX_SKL_V2 1/5] drm/i915/skl: Added a check for the hardware status of csr fw before loading.

On Fri, Sep 11, 2015 at 12:36:24AM +0530, Animesh Manna wrote: > > > On 9/10/2015 8:15 PM, Daniel Vetter wrote: > >On Thu, Sep 10, 2015 at 01:58:54AM +0530, Animesh Manna wrote: > >> > >>On 9/2/2015 2:24 PM, Daniel Vetter wrote: > >>>On Wed, Aug 26, 2015 at 07:40:54PM +0530, Animesh Manna wrote:

[Intel-gfx] [PATCH 7/9] drm/i915: don't apply WaFbcAsynchFlipDisableFbcQueue on SKL

This WA is only for HSW/BDW. Reviewed-by: Ville Syrjälä Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_fbc.c

[Intel-gfx] [PATCH 6/9] drm/i915: apply WaFbcAsynchFlipDisableFbcQueue earlier

The spec says the register should have that value for the entire time that FBC is enabled, so apply the WA before we enable FBC. Notice that we also have this WA for ILK/SNB, but it is implemented at init_clock_gating(). I could move the IVB/HSW/BDW WA code to init_clock_gating() too, but since

[Intel-gfx] [PATCH 2/9] drm/i915: check for the supported strides on HSW+ FBC

Don't allow FBC for cases where the spec says we can't FBC. v2: - Just WARN_ON() the strides that should have been caught earlier (Daniel) - Make it a new function since I expect this to grow more. v3: - Document which IGT test is exercised by this. v4: - Implement the restrictions

[Intel-gfx] [PATCH 5/9] drm/i915: don't enable FBC when pixel rate exceeds 95% on HSW/BDW

BSpec says we shouldn't enable FBC on HSW/BDW when the pipe pixel rate exceeds 95% of the core display clock. v2: - HSW also needs the WA (Ville). - Add the WA name (Ville). - Use the current cdclk (Ville). Signed-off-by: Paulo Zanoni ---

[Intel-gfx] [PATCH 1/9] drm/i915: fix the FBC work allocation failure path

Always update the currrent crtc, fb and vertical offset after calling enable_fbc. We were forgetting to do so along the failure paths when enabling fbc synchronously. Fix this with a new helper to enable_fbc() and update the state simultaneously. v2: Improve commit message (Chris). v3: Constify

[Intel-gfx] [PATCH 9/9] drm/i915: fix FBC for cases where crtc->base.y is non-zero

I only tested this on BDW and SKL, but since the register description is the same ever since gen4, let's assume that all gens take the same register format. If that's not true, then hopefully someone will bisect a bug to this patch and we'll fix it. Notice that the wrong fence offset register

[Intel-gfx] [PATCH 8/9] drm/i915: reject invalid formats for FBC

This commit is essentially a rewrite of "drm/i915: Check pixel format for fbc" from Ville Syrjälä. The idea is the same, but the code is different due to all the changes that happened since his original patch. So any bugs are due to my bad rewrite. v2: - Drop the alpha formats (Ville).

[Intel-gfx] [PATCH 3/9] drm/i915: avoid the last 8mb of stolen on BDW/SKL

The FBC hardware for these platforms doesn't have access to the bios_reserved range, so it always assumes the maximum (8mb) is used. So avoid this range while allocating. This solves a bunch of FIFO underruns that happen if you end up putting the CFB in that memory range. On my machine, with 32mb

[Intel-gfx] [PATCH 4/9] drm/i915: print the correct amount of bytes allocated for the CFB

And also print the threshold. I was surprised to see a log message claiming the CFB size was 32mb when there was less than 24mb available for it. Reviewed-by: Ville Syrjälä Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c

[Intel-gfx] [PATCH 01/11] drm: s/int crtc/unsigned int pipe/ straggles

From: Ville Syrjälä Finish the recent replacement of 'int pipe' with 'unsigned int pipe' Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_irq.c | 16 1 file changed, 8

[Intel-gfx] [PATCH 10/11] drm: Use vblank timestamps to guesstimate how many vblanks were missed

From: Ville Syrjälä When lacking am accurate hardware frame counter, we can fall back to using the vblank timestamps to guesstimagte how many vblanks have elapsed since the last time the vblank counter was updated. Take the oppostunity to unify the

[Intel-gfx] [PATCH 02/11] drm: Move timestamping constants into drm_vblank_crtc

From: Ville Syrjälä Collect the timestamping constants alongside the rest of the relevant stuff under drm_vblank_crtc. We can now get rid of the 'refcrtc' parameter to drm_calc_vbltimestamp_from_scanoutpos(). Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 00/11] drm: vblank fixes and timestamp based missed vblank guesttimation

From: Ville Syrjälä This series has a few goals: - make timestamps more accurate by not using rounded pixel/line durations - avoid infinite loops in vblank code - use the timestamps to guesttimate the number of missed vblanks, in case there's no hardware frame

[Intel-gfx] [PATCH 04/11] drm: Kill pixeldur_ns

From: Ville Syrjälä pixeldur_ns is now unsued, so kill it from drm_vblank_crtc. framedur_ns is also currently unused but we will have use for it in the near future so leave it be. linedur_ns is still used by nouveau for some internal delays. Signed-off-by: Ville

[Intel-gfx] [PATCH 07/11] drm: Limit the number of .get_vblank_counter() retries

From: Ville Syrjälä Pontential infinite loops in the vblank code are a bad idea. Add some limits. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_irq.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 08/11] drm: Clean up drm_calc_vbltimestamp_from_scanoutpos() vbl_status

From: Ville Syrjälä Avoid confusion and don't use 'vbl_status' as both the .get_scanout_position() return value and the return value from drm_calc_vbltimestamp_from_scanoutpos(). While at it make 'vbl_status' unsigned and print it as hex in the debug prints since

[Intel-gfx] [PATCH 06/11] drm: Pass flags to drm_update_vblank_count()

From: Ville Syrjälä We'll soon have use for the 'flags' in drm_update_vblank_count() so pass it in. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_irq.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff

[Intel-gfx] [PATCH 05/11] drm/i915: Fix vblank count variable types

From: Ville Syrjälä The vblank counts are u32 so make flip_queued_vblank and flip_ready_vblank u32 as well. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[Intel-gfx] [PATCH 03/11] drm: Stop using linedur_ns and pixeldur_ns for vblank timestamps

From: Ville Syrjälä linedur_ns, and especially pixeldur_ns are becoming rather inaccurate to be used for the vblank timestamp correction. With 4k@60 the pixel duration is already below 2ns, so the amount of error due to the truncation to nanoseconds is introducing

[Intel-gfx] [PATCH 11/11] drm: Fix vblank timestamp races

From: Ville Syrjälä The vblank timestamp ringbuffer only has two entries, so if the vblank->count is incremented by an even number readers may end up seeing the new vblank timestamp alongside the old vblank counter value. Fix the problem by storing the vblank

[Intel-gfx] [PATCH 09/11] drm: store_vblank() is never called with NULL timestamp

From: Ville Syrjälä Remove the NULL 't_vblank' checks from store_vblank() since that will never happen. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_irq.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-)

[Intel-gfx] [PATCH] drm/i915: Implement stolen reserved detection for ctg/elk

From: Ville Syrjälä Finally managed to dig up enough hints as to where the stolen reserved stuff lives on ctg/elk. So add the code to decode it. This was a combination of old chipset specs, diggin up an old elk grits release with an ctg/elk AubLoad etc. This was

Re: [Intel-gfx] [PATCH] drm/i915: workaround bad DSL readout v2

On Thu, Sep 10, 2015 at 02:38:53PM -0700, Jesse Barnes wrote: > On HSW at least (still testing other platforms, but should be harmless > elsewhere), the DSL reg reads back as 0 when read around vblank start > time. This ends up confusing the atomic start/end checking code, since > it causes the

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add HDMI probe function

On Fri, Sep 11, 2015 at 04:15:39PM +0530, Jindal, Sonika wrote: > > > On 9/10/2015 12:25 AM, Rodrigo Vivi wrote: > >I liked the approach and agree with Daniel, so with his suggestions feel > >free to use: > >Reviewed-by: Rodrigo Vivi >> >

  1   2   >