[Intel-gfx] [PATCH 1/2] [v2] drm/i915/bdw: Force all Data Cache Data Port access to be Non-Coherent

I stumbled on to some unimplemented errata. To be honest, I am not really sure of the impact, just that the docs say to do. No w/a name for this one. v2: v1 was a stale thing which should have never seen the light of day. (Haihao) Cc: Kenneth Graunke Signed-off-by: Ben Widawsky --- drivers/gp

Re: [Intel-gfx] [PATCH 1/2] drm/i915/bdw: Force all Data Cache Data Port access to be Non-Coherent

On Fri, Dec 13, 2013 at 09:16:47AM +0800, Xiang, Haihao wrote: > On Thu, 2013-12-12 at 15:28 -0800, Ben Widawsky wrote: > > I stumbled on to some unimplemented errata. To be honest, I am not > > really sure of the impact, just that the docs say to do. > > > > No w/a name for this one. > > > > Cc

Re: [Intel-gfx] [PATCH 1/2] drm/i915/bdw: Force all Data Cache Data Port access to be Non-Coherent

On Thu, 2013-12-12 at 15:28 -0800, Ben Widawsky wrote: > I stumbled on to some unimplemented errata. To be honest, I am not > really sure of the impact, just that the docs say to do. > > No w/a name for this one. > > Cc: Kenneth Graunke > Signed-off-by: Ben Widawsky > --- > drivers/gpu/drm/i9

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

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/intel_ddi.c between commit 76bb80ed3027 ("drm/i915/ddi: set sink to power down mode on dp disable") from Linus' tree and commit dff392dbd258 ("drm/i915: don't touch the VDD when disabling the panel") from

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7

On Thu, 12 Dec 2013 23:54:37 +0100 Daniel Vetter wrote: > On Thu, Dec 12, 2013 at 12:41:54PM -0800, Jesse Barnes wrote: > > Retrieve current framebuffer config info from the regs and create an fb > > object for the buffer the BIOS or boot loader left us. This should > > allow for smooth transiti

[Intel-gfx] [PATCH 1/2] drm/i915/bdw: Force all Data Cache Data Port access to be Non-Coherent

I stumbled on to some unimplemented errata. To be honest, I am not really sure of the impact, just that the docs say to do. No w/a name for this one. Cc: Kenneth Graunke Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_reg.h | 4 drivers/gpu/drm/i915/intel_pm.c | 7 +++ 2 fil

[Intel-gfx] [PATCH 2/2] drm/i915/bdw: Implement ff workarounds

WaVSRefCountFullforceMissDisable and WaDSRefCountFullforceMissDisable VS is a carry-over from HSW, and DS is likely not used by anyone yet. Cc: Kenneth Graunke Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 11 --- 2 files chan

Re: [Intel-gfx] [PATCH 1/6] drm/i915: unconditionally copy mode into crtc at boot time

On Thu, Dec 12, 2013 at 02:44:33PM -0800, Jesse Barnes wrote: > On Thu, 12 Dec 2013 23:39:39 +0100 > Daniel Vetter wrote: > > > On Thu, Dec 12, 2013 at 01:29:39PM -0800, Jesse Barnes wrote: > > > On Thu, 12 Dec 2013 22:21:29 +0100 > > > Daniel Vetter wrote: > > > > > > > On Thu, Dec 12, 2013 at

Re: [Intel-gfx] [PATCH 1/6] drm/i915: unconditionally copy mode into crtc at boot time

On Thu, 12 Dec 2013 23:39:39 +0100 Daniel Vetter wrote: > On Thu, Dec 12, 2013 at 01:29:39PM -0800, Jesse Barnes wrote: > > On Thu, 12 Dec 2013 22:21:29 +0100 > > Daniel Vetter wrote: > > > > > On Thu, Dec 12, 2013 at 12:41:52PM -0800, Jesse Barnes wrote: > > > > The BIOS code will need this to

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7

On Thu, Dec 12, 2013 at 12:41:54PM -0800, Jesse Barnes wrote: > Retrieve current framebuffer config info from the regs and create an fb > object for the buffer the BIOS or boot loader left us. This should > allow for smooth transitions to userspace apps once we finish the > initial configuration c

Re: [Intel-gfx] [PATCH 1/6] drm/i915: unconditionally copy mode into crtc at boot time

On Thu, Dec 12, 2013 at 01:29:39PM -0800, Jesse Barnes wrote: > On Thu, 12 Dec 2013 22:21:29 +0100 > Daniel Vetter wrote: > > > On Thu, Dec 12, 2013 at 12:41:52PM -0800, Jesse Barnes wrote: > > > The BIOS code will need this to properly inherit the mode. > > > > > > Signed-off-by: Jesse Barnes

Re: [Intel-gfx] [PATCH 6/6] drm/i915: inform drm_fb_helper if we abandoned a connected output

On Thu, 12 Dec 2013 22:30:41 + Chris Wilson wrote: > On Thu, Dec 12, 2013 at 12:41:57PM -0800, Jesse Barnes wrote: > > Otherwise subsequent fb activity will try to do blank/unblank on outputs > > that were never fully enabled. > > Hmm, actually this highlights a bug in drm_setup_crtcs() that

Re: [Intel-gfx] [PATCH 6/6] drm/i915: inform drm_fb_helper if we abandoned a connected output

On Thu, Dec 12, 2013 at 12:41:57PM -0800, Jesse Barnes wrote: > Otherwise subsequent fb activity will try to do blank/unblank on outputs > that were never fully enabled. Hmm, actually this highlights a bug in drm_setup_crtcs() that we do not reconstruct enabled[] after a return false here. Only t

[Intel-gfx] [PATCH] tests: Document the Makefile variables a bit better

Also, this is a test for the patchwork hook. Signed-off-by: Daniel Vetter --- tests/Makefile.sources | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tests/Makefile.sources b/tests/Makefile.sources index 571341242b54..e286a7cf5ea0 100644 --- a/tests/Makefile.sources +++ b/tests/Makefil

Re: [Intel-gfx] [PATCH 1/6] drm/i915: unconditionally copy mode into crtc at boot time

On Thu, 12 Dec 2013 22:21:29 +0100 Daniel Vetter wrote: > On Thu, Dec 12, 2013 at 12:41:52PM -0800, Jesse Barnes wrote: > > The BIOS code will need this to properly inherit the mode. > > > > Signed-off-by: Jesse Barnes > > --- > > drivers/gpu/drm/i915/intel_display.c | 2 +- > > 1 file changed

Re: [Intel-gfx] [PATCH 1/6] drm/i915: unconditionally copy mode into crtc at boot time

On Thu, Dec 12, 2013 at 12:41:52PM -0800, Jesse Barnes wrote: > The BIOS code will need this to properly inherit the mode. > > Signed-off-by: Jesse Barnes > --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make sprite updates atomic

On Thu, 17 Oct 2013 22:53:17 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Add a mechanism by which we can evade the leading edge of vblank. This > guarantees that no two sprite register writes will straddle on either > side of the vblank start, and that means all the writ

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Add pipe update trace points

On Thu, 17 Oct 2013 22:53:19 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Add trace points for observing the atomic pipe update mechanism. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_trace.h | 77 > + > driv

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Perform primary enable/disable atomically with sprite updates

On Thu, 17 Oct 2013 22:53:18 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move the primary plane enable/disable to occur atomically with the > sprite update that caused the primary plane visibility to change. > > FBC and IPS enable/disable is left to happen well before o

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make sprite updates atomic

On Thu, 17 Oct 2013 22:53:17 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Add a mechanism by which we can evade the leading edge of vblank. This > guarantees that no two sprite register writes will straddle on either > side of the vblank start, and that means all the writ

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Don't disable primary when color keying is used

On Thu, Dec 12, 2013 at 9:56 PM, Jesse Barnes wrote: > On Thu, 17 Oct 2013 22:53:13 +0300 > ville.syrj...@linux.intel.com wrote: > >> From: Ville Syrjälä >> >> When color keying is used, the primary may not be invisible even though >> the sprite fully covers it. So check for color keying before d

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Shuffle sprite register writes into a tighter group

On Thu, 17 Oct 2013 22:53:16 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Group the sprite register writes a bit tighter. We want to write > the registers atomically, and so doing the base address/offset > artihmetic within the critical section is pointless when it can >

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Add i915_get_crtc_scanline()

On Thu, 17 Oct 2013 22:53:15 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Refactor the i915_get_crtc_scanoutpos() code a bit to make the > "negative values during vblank" adjustment optional. For most uses > the raw scanline number without such adjustments is easier to us

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Don't disable primary when color keying is used

On Thu, 17 Oct 2013 22:53:13 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > When color keying is used, the primary may not be invisible even though > the sprite fully covers it. So check for color keying before deciding to > disable the primary plane. > > Signed-off-by: Vi

Re: [Intel-gfx] [PATCH 07/19] drm/i915: add runtime put/get calls at the basic places

On Thu, Dec 12, 2013 at 9:07 PM, Paulo Zanoni wrote: >> This hunk here is the wrong thing to do: If we're suspended and the >> hangcheck fires, we'll just delay it. But if we keep on being suspended >> the hangcheck will fire at the normal recheck rate (but never do anything) >> which wreaks utter

[Intel-gfx] [PATCH 6/6] drm/i915: inform drm_fb_helper if we abandoned a connected output

Otherwise subsequent fb activity will try to do blank/unblank on outputs that were never fully enabled. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_fbdev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev

[Intel-gfx] [PATCH 3/6] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7

Retrieve current framebuffer config info from the regs and create an fb object for the buffer the BIOS or boot loader left us. This should allow for smooth transitions to userspace apps once we finish the initial configuration construction. v2: check for non-native modes and adjust (Jesse) fi

[Intel-gfx] [PATCH 2/6] drm/i915: retrieve current fb config into new plane_config structure at init

Read out the current plane configuration at init time into a new plane_config structure. This allows us to track any existing framebuffers attached to the plane and potentially re-use them in our fbdev code for a smooth handoff. v2: update for new pitch_for_width function (Jesse) comment how

[Intel-gfx] [PATCH 5/6] drm/i915/vlv: move DPIO init earlier v2

It's needed for early mode state readout, which is in turn needed to inherit the BIOS config. So split out the reset, which we need on resume too, from the DPIO reg init, and do the latter earlier. v2: split reset and reg init Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_display.

[Intel-gfx] [PATCH 1/6] drm/i915: unconditionally copy mode into crtc at boot time

The BIOS code will need this to properly inherit the mode. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index af3717a..1ae3d44

[Intel-gfx] [PATCH 4/6] drm/i915: don't memset the fb buffer if preallocated

We want to preserve the BIOS/bootloader contents for later. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_fbdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index db75f22..53675d2 10

Re: [Intel-gfx] [PATCH 07/19] drm/i915: add runtime put/get calls at the basic places

2013/12/10 Daniel Vetter : > On Fri, Nov 29, 2013 at 11:03:38AM -0200, Rodrigo Vivi wrote: >> On Wed, Nov 27, 2013 at 06:20:34PM -0200, Paulo Zanoni wrote: >> > diff --git a/drivers/gpu/drm/i915/i915_irq.c >> > b/drivers/gpu/drm/i915/i915_irq.c >> > index 2715600..70c4cef 100644 >> > --- a/drivers

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Always use INTEL_INFO() to access the device_info structure

On Thu, Dec 12, 2013 at 05:23:08PM +, Chris Wilson wrote: > On Thu, Dec 12, 2013 at 05:05:18PM +, Damien Lespiau wrote: > > On Thu, Dec 12, 2013 at 04:58:21PM +, Chris Wilson wrote: > > > On Thu, Dec 12, 2013 at 02:36:37PM +, Damien Lespiau wrote: > > > > If we make sure that all th

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Always use INTEL_INFO() to access the device_info structure

On Thu, Dec 12, 2013 at 05:05:18PM +, Damien Lespiau wrote: > On Thu, Dec 12, 2013 at 04:58:21PM +, Chris Wilson wrote: > > On Thu, Dec 12, 2013 at 02:36:37PM +, Damien Lespiau wrote: > > > If we make sure that all the dev_priv->info usages are wrapped by > > > INTEL_INFO(), we can easi

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Always use INTEL_INFO() to access the device_info structure

On Thu, Dec 12, 2013 at 04:58:21PM +, Chris Wilson wrote: > On Thu, Dec 12, 2013 at 02:36:37PM +, Damien Lespiau wrote: > > If we make sure that all the dev_priv->info usages are wrapped by > > INTEL_INFO(), we can easily modify the ->info field to be structure and > > not a pointer while k

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Make the intel_device_info structure kept in dev_priv writable

On Thu, Dec 12, 2013 at 02:36:38PM +, Damien Lespiau wrote: > Turns out it'd be nice to change some device information at run-time or > simply have some code to fill in the info struct instead of having to > declare the values in 30+ structures. > > What prompted this change is handling fused

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Always use INTEL_INFO() to access the device_info structure

On Thu, Dec 12, 2013 at 02:36:37PM +, Damien Lespiau wrote: > If we make sure that all the dev_priv->info usages are wrapped by > INTEL_INFO(), we can easily modify the ->info field to be structure and > not a pointer while keeping the const protection in the INTEL_INFO() > macro. Yuck. -Chris

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to set the DP sink power state on disconnected monitors

On Thu, Dec 12, 2013 at 03:34:24PM +, Damien Lespiau wrote: > While looking at some debug traces, I noticed that we were always trying > to set the sink power, even when we previously identified that the > connector was in the disconnected state. > > In that case, we don't a big chance for the

Re: [Intel-gfx] [PATCH] drm/i915: dont call irq_put when irq test is on

On Thu, Dec 12, 2013 at 06:06:16PM +0200, Ville Syrjälä wrote: > On Thu, Dec 12, 2013 at 05:54:42PM +0200, Mika Kuoppala wrote: > > If test is running, irq_get was not called so we should gain > > balance by not doing irq_put > > > > "So the rule is: if you access unlocked values, you use ACCESS_O

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Rework the FBC interval/stall stuff a bit

On Thu, Dec 12, 2013 at 05:27:40PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Don't touch DPFC_RECOMP_CTL on FBC2, use RMW to update > the FBC_CONTROL on FBC1 to make it easier for people to > experiment with different numbers. Also fix the interval > mask for FBC1. >

Re: [Intel-gfx] [PATCH] drm/i915: dont call irq_put when irq test is on

On Thu, Dec 12, 2013 at 05:54:42PM +0200, Mika Kuoppala wrote: > If test is running, irq_get was not called so we should gain > balance by not doing irq_put > > "So the rule is: if you access unlocked values, you use ACCESS_ONCE(). > You don't say "but it can't matter". Because you simply don't kn

[Intel-gfx] [PATCH] drm/i915: dont call irq_put when irq test is on

If test is running, irq_get was not called so we should gain balance by not doing irq_put "So the rule is: if you access unlocked values, you use ACCESS_ONCE(). You don't say "but it can't matter". Because you simply don't know." -- Linus v2: use local variable so it can't change during test (Chr

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Make the intel_device_info structure kept in dev_priv writable

On Thu, Dec 12, 2013 at 05:30:14PM +0200, Jani Nikula wrote: > > -#define INTEL_INFO(dev)(to_i915(dev)->info) > > +#define INTEL_INFO(dev)((const struct intel_device_info > > *)&to_i915(dev)->info) > > If that were an inline function you wouldn't have to cast to add const: > > static inl

[Intel-gfx] [PATCH] drm/i915: Don't try to set the DP sink power state on disconnected monitors

While looking at some debug traces, I noticed that we were always trying to set the sink power, even when we previously identified that the connector was in the disconnected state. In that case, we don't a big chance for the write to succeed, so don't try. [drm:drm_helper_probe_single_connector_m

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Make the intel_device_info structure kept in dev_priv writable

On Thu, 12 Dec 2013, Damien Lespiau wrote: > Turns out it'd be nice to change some device information at run-time or > simply have some code to fill in the info struct instead of having to > declare the values in 30+ structures. > > What prompted this change is handling fused out display/pipe and

[Intel-gfx] [PATCH v2 6/8] drm/i915: Rework the FBC interval/stall stuff a bit

From: Ville Syrjälä Don't touch DPFC_RECOMP_CTL on FBC2, use RMW to update the FBC_CONTROL on FBC1 to make it easier for people to experiment with different numbers. Also fix the interval mask for FBC1. v2: Rebased Reviewed-by: Imre Deak Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Enable FBC for all mobile gen2 and gen3 platforms

On Thu, Dec 12, 2013 at 03:38:38PM +0100, Daniel Vetter wrote: > On Thu, Dec 12, 2013 at 3:32 PM, Ville Syrjälä > wrote: > > On Thu, Dec 12, 2013 at 04:19:34PM +0200, Imre Deak wrote: > >> On Thu, 2013-11-28 at 17:30 +0200, ville.syrj...@linux.intel.com wrote: > >> > From: Ville Syrjälä > >> > >

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Rework the FBC interval/stall stuff a bit

On Thu, Dec 12, 2013 at 04:04:49PM +0200, Imre Deak wrote: > On Thu, 2013-11-28 at 17:30 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Don't touch DPFC_RECOMP_CTL on FBC2, use RMW to update > > the FBC_CONTROL on FBC1 to make it easier for people to > > experiment wi

Re: [Intel-gfx] [PATCH 3/8] drm/i915: FBC_CONTROL2 is gen4 only

On Thu, Dec 12, 2013 at 03:00:42PM +0200, Imre Deak wrote: > On Fri, 2013-11-29 at 14:01 +, Chris Wilson wrote: > > On Thu, Nov 28, 2013 at 05:29:57PM +0200, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > Gen2 and gen3 don't have the FBC_CONTROL2 register, so

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Enable FBC for all mobile gen2 and gen3 platforms

On Thu, Dec 12, 2013 at 3:32 PM, Ville Syrjälä wrote: > On Thu, Dec 12, 2013 at 04:19:34PM +0200, Imre Deak wrote: >> On Thu, 2013-11-28 at 17:30 +0200, ville.syrj...@linux.intel.com wrote: >> > From: Ville Syrjälä >> > >> > All mobile gen2 and gen3 chipsets should have FBC1, and the code >> > sh

[Intel-gfx] [PATCH 8/8] drm/i915: Use I915_MAX_PIPES in the pipe/plane_to_crtc_mapping definitions

Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index c3e170f..ea6b578 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i91

[Intel-gfx] [PATCH 5/8] drm/i915: Consolidate FUSE_STRAP in one set of defines

We had 2 set of defines for the same register, so make it one. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_reg.h | 18 -- drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 3 +-- 3 files changed, 10 insertions(+), 13 deleti

[Intel-gfx] [PATCH 6/8] drm/i915: Disable display when fused off

FUSE_STRAP has a bit to inform us that the display has been fused off. Use it to setup the definitive number of pipes at run-time. v2: actually tweak num_pipes, not num_planes v3: also tests SFUSE_STRAP bit 7 Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_dma.c | 18 +++

[Intel-gfx] [PATCH 2/8] drm/i915: Always use INTEL_INFO() to access the device_info structure

If we make sure that all the dev_priv->info usages are wrapped by INTEL_INFO(), we can easily modify the ->info field to be structure and not a pointer while keeping the const protection in the INTEL_INFO() macro. Suggested-by: Ville Syrjälä Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i91

[Intel-gfx] [PATCH 7/8] drm/i915: Remove the Quanta special case

We now read out the FUSE_STRAP and SFUSE_STRAP registers, looking for configurations with display fused off. Let's remove the Quanta special case and rely on the programmed fuses to set num_pipes to 0. This patch is untested and needs a good soul with such a device to give it a go. Cc: Ben Widaws

[Intel-gfx] [PATCH 4/8] drm/i915: Move num_plane to the intel_device_info structure

And rename it to num_sprites as this value doesn't count the primary plane. This limit lives with num_pipes really, and now that dev_priv->info is writable we can put it there instead. While at it, introduce a intel_device_info_runtime_init() where we'll be able to gather the device info fields a

[Intel-gfx] [PATCH 1/8] drm/i915: Use IS_VALLEYVIEW() to test the is_valleyview flag

Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_pm.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index c01d08d..351065d 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm

[Intel-gfx] Supporting fused display configurations v3

v3, following up a couple of review comments from Ville: http://lists.freedesktop.org/archives/intel-gfx/2013-December/037313.html Changes: - Always use INTEL_INFO() after initialization to access dev_priv->info (well, except in the reg macros, where it's just too impractical), - Cast th

[Intel-gfx] [PATCH 3/8] drm/i915: Make the intel_device_info structure kept in dev_priv writable

Turns out it'd be nice to change some device information at run-time or simply have some code to fill in the info struct instead of having to declare the values in 30+ structures. What prompted this change is handling fused out display/pipe and tweaking num_pipes at run-time, but I'm quite sure we

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Enable FBC for all mobile gen2 and gen3 platforms

On Thu, Dec 12, 2013 at 04:19:34PM +0200, Imre Deak wrote: > On Thu, 2013-11-28 at 17:30 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > All mobile gen2 and gen3 chipsets should have FBC1, and the code > > should now handle them all. So just set has_fbc=true for all su

Re: [Intel-gfx] [PATCH] drm/i915: split intel_ddi_pll_mode_set in 2 pieces

On Thu, Dec 12, 2013 at 11:17:39AM -0200, Paulo Zanoni wrote: > 2013/12/12 Damien Lespiau : > > On Mon, Nov 25, 2013 at 03:27:08PM -0200, Paulo Zanoni wrote: > >> From: Paulo Zanoni > >> > >> The first piece, intel_ddi_pll_select, finds a PLL and assigns it to > >> the CRTC, but doesn't write any

Re: [Intel-gfx] [PATCH] drm/i915: Fix timeout with missed interrupts in __wait_seqno

On Thu, Dec 12, 2013 at 02:48:47PM +0200, Ville Syrjälä wrote: > On Tue, Dec 10, 2013 at 05:02:43PM +0200, Mika Kuoppala wrote: > > Commit 094f9a54e355 ("drm/i915: Fix __wait_seqno to use true infinite > > timeouts") added support for __wait_seqno to detect missing interrupts and > > go around them

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Enable FBC for all mobile gen2 and gen3 platforms

On Thu, 2013-11-28 at 17:30 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > All mobile gen2 and gen3 chipsets should have FBC1, and the code > should now handle them all. So just set has_fbc=true for all such > chipsets. > > Signed-off-by: Ville Syrjälä Based on the above

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Rework the FBC interval/stall stuff a bit

On Thu, 2013-11-28 at 17:30 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Don't touch DPFC_RECOMP_CTL on FBC2, use RMW to update > the FBC_CONTROL on FBC1 to make it easier for people to > experiment with different numbers. Also fix the interval > mask for FBC1. As I unde

Re: [Intel-gfx] [PATCH] drm/i915: split intel_ddi_pll_mode_set in 2 pieces

2013/12/12 Damien Lespiau : > On Mon, Nov 25, 2013 at 03:27:08PM -0200, Paulo Zanoni wrote: >> From: Paulo Zanoni >> >> The first piece, intel_ddi_pll_select, finds a PLL and assigns it to >> the CRTC, but doesn't write any register. It can also fail in case it >> doesn't find a PLL. >> >> The sec

Re: [Intel-gfx] [PATCH 3/8] drm/i915: FBC_CONTROL2 is gen4 only

On Fri, 2013-11-29 at 14:01 +, Chris Wilson wrote: > On Thu, Nov 28, 2013 at 05:29:57PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Gen2 and gen3 don't have the FBC_CONTROL2 register, so don't > > touch it. > > > > Signed-off-by: Ville Syrjälä > > Hmm, anoth

Re: [Intel-gfx] [PATCH] drm/i915: dont call irq_put when irq test is on

On Mon, Dec 09, 2013 at 08:47:22PM +0200, Mika Kuoppala wrote: > If test is running, irq_get was not called so we should > gain balance by not doing irq_put > > v2: use local variable so it can't change during test (Chris) > > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Gen2 FBC1 CFB pitch wants 32B units

On Thu, 2013-11-28 at 17:29 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On gen2 the compressed frame buffer pitch is specified in 32B units > rather than the 64B units used on gen3+. > > Signed-off-by: Ville Syrjälä Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i9

Re: [Intel-gfx] [PATCH] drm/i915: Fix timeout with missed interrupts in __wait_seqno

On Tue, Dec 10, 2013 at 05:02:43PM +0200, Mika Kuoppala wrote: > Commit 094f9a54e355 ("drm/i915: Fix __wait_seqno to use true infinite > timeouts") added support for __wait_seqno to detect missing interrupts and > go around them by polling. As there is also timeout detection in > __wait_seqno, the

Re: [Intel-gfx] [PATCH 3/3] drm/i915: touch VGA MSR after we enable the power well

On Thu, Dec 12, 2013 at 11:36:09AM +, Damien Lespiau wrote: > On Wed, Dec 11, 2013 at 06:50:10PM -0200, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > Fixes regression introduced by: > > commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41 > > Author: Paulo Zanoni > > Date: Wed

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Make the intel_device_info structure kept in dev_priv writable

On Thu, Dec 12, 2013 at 11:20:58AM +, Damien Lespiau wrote: > Turns out it'd be nice to change some device information at run-time or > simply have some code to fill in the info struct instead of having to > declare the values in 30+ structures. > > What prompted this change is handling fused

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Move num_plane to the intel_device_info structure

On Thu, Dec 12, 2013 at 11:20:59AM +, Damien Lespiau wrote: > And rename it to num_planes to match num_pipes. It should really be num_sprites, or even more accurately num_sprites_per_pipe but that's a bit of a mouthful. > > This limit lives with num_pipes really, and now that dev_priv->info

Re: [Intel-gfx] [PATCH 3/3] drm/i915: touch VGA MSR after we enable the power well

On Wed, Dec 11, 2013 at 06:50:10PM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > Fixes regression introduced by: > commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41 > Author: Paulo Zanoni > Date: Wed Jul 3 17:12:13 2013 -0300 > drm/i915: switch disable_power_well defaul

Re: [Intel-gfx] [PATCH 2/3] drm/i915: extract hsw_power_well_post_{enable, disable}

On Wed, Dec 11, 2013 at 06:50:09PM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > I want to add more code to the post_enable function. > > Signed-off-by: Paulo Zanoni Reviewed-by: Damien Lespiau -- Damien ___ Intel-gfx mailing list Intel-gfx@

Re: [Intel-gfx] [PATCH 1/3] drm/i915: remove i915_disable_vga_mem declaration

On Wed, Dec 11, 2013 at 06:50:08PM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > It was supposed to have been killed on the same commit that killed the > function, e1264ebe9ff48e1b3e1dd11805eec9f5b143ab7c, but I guess the > intel_drv.h reorganization accidentally brought it back. > > Signe

[Intel-gfx] [PATCH 6/6] drm/i915: Use I915_MAX_PIPES in the pipe/plane_to_crtc_mapping definitions

Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 704dc7d..ac1d691 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i91

[Intel-gfx] [PATCH 4/6] drm/i915: Disable display when fused off

FUSE_STRAP has a bit to inform us that the display has been fused off. Use it to setup the definitive number of pipes at run-time. v2: actually tweak num_pipes, not num_planes v3: also tests SFUSE_STRAP bit 7 Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_dma.c | 18 +++

[Intel-gfx] [PATCH 1/6] drm/i915: Make the intel_device_info structure kept in dev_priv writable

Turns out it'd be nice to change some device information at run-time or simply have some code to fill in the info struct instead of having to declare the values in 30+ structures. What prompted this change is handling fused out display/pipe and tweaking num_pipes at run-time, but I'm quite sure we

[Intel-gfx] Supporting fused display configurations v2

The previous series (and cover letter) can be found at: http://lists.freedesktop.org/archives/intel-gfx/2013-December/036949.html Changes: - Use SFUSE_STRAP bit 7 in addition to FUSE_STRAP bit 30 to detect fused off display, - Remove pipe C test for now as we don't know of any device that

[Intel-gfx] [PATCH 5/6] drm/i915: Remove the Quanta special case

We now read out the FUSE_STRAP and SFUSE_STRAP registers, looking for configurations with display fused off. Let's remove the Quanta special case and rely on the programmed fuses to set num_pipes to 0. This patch is untested and needs a good soul with such a device to give it a go. Cc: Ben Widaws

[Intel-gfx] [PATCH 3/6] drm/i915: Consolidate FUSE_STRAP in one set of defines

We had 2 set of defines for the same register, so make it one. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_reg.h | 18 -- drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 3 +-- 3 files changed, 10 insertions(+), 13 deleti

[Intel-gfx] [PATCH 2/6] drm/i915: Move num_plane to the intel_device_info structure

And rename it to num_planes to match num_pipes. This limit lives with num_pipes really, and now that dev_priv->info is writable we can put it there instead. While at it, introduce a intel_device_info_runtime_init() where we'll be able to gather the device info fields at run-time. Signed-off-by:

Re: [Intel-gfx] [PATCH 37/48] drm/i915: Defer request freeing

On Fri, Dec 06, 2013 at 02:11:22PM -0800, Ben Widawsky wrote: > From: Ben Widawsky > > With context destruction, we always want to be able to tear down the > underlying address space. This is invoked on the last unreference to the > context which could happen before we've moved all objects to the

Re: [Intel-gfx] [PATCH 39/48] drm/i915: Do not allow buffers at offset 0

On Fri, Dec 06, 2013 at 02:11:24PM -0800, Ben Widawsky wrote: > This is primarily a band aid for an unexplainable error in > gem_reloc_vs_gpu/forked-faulting-reloc-thrashing. Essentially as soon as > a relocated buffer (which had a non-zero presumed offset) moved to > offset 0, something goes bad.

Re: [Intel-gfx] [PATCH] drm/i915: split intel_ddi_pll_mode_set in 2 pieces

On Mon, Nov 25, 2013 at 03:27:08PM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > The first piece, intel_ddi_pll_select, finds a PLL and assigns it to > the CRTC, but doesn't write any register. It can also fail in case it > doesn't find a PLL. > > The second piece, intel_ddi_pll_enable, us

Re: [Intel-gfx] [PATCH] drm/i915: Fix erroneous dereference of batch_obj inside reset_status

On Thu, Dec 05, 2013 at 04:22:02PM +, Chris Wilson wrote: > On Thu, Dec 05, 2013 at 06:07:27PM +0200, Mika Kuoppala wrote: > > Chris Wilson writes: > > > > > As the rings may be processed and their requests deallocated in a > > > different order to the natural retirement during a reset, > > >