On Fri, Nov 29, 2013 at 02:57:13PM +0800, Xiang, Haihao wrote:
From: Xiang, Haihao haihao.xi...@intel.com
It is to check whether media pipeline on render ring works. Codes
are copied and modified from the rendercopy case which uses 3D pipeline.
However media pipeline is simpler than 3D
From: Deepak S deepa...@intel.com
On VLV, FIFO will be shared by both SW and HW. So, we read the
free entries through register and update dev_priv variable
and wait for only 20 entries to be free
v2: Apply mask when we read the number of free FIFO entries (Ville).
Signed-off-by: Deepak S
From: Deepak S deepa...@intel.com
On VLV, FIFO will be shared by both SW and HW. So, we read the
free entries through register and update dev_priv variable
and wait for only 20 entries to be free
v2: Apply mask when we read the number of free FIFO entries (Ville).
v3: Mask applied after reading
On Fri, Nov 29, 2013 at 03:44:31PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
On VLV, FIFO will be shared by both SW and HW. So, we read the
free entries through register and update dev_priv variable
and wait for only 20 entries to be free
But the whole point of
I think it should be a return instead a WARN.
Myabe I'm just sleeping yet, but I think the delayed work will execute this
even for non HAS_PC8 and warn will always ring on non HSW.
But even if I'm sleeping, since it really touch hsw registers wouldn't be safer
a return instead of a warn anyway?
From: Ville Syrjälä ville.syrj...@linux.intel.com
The ring scratch pages don't have a PPGTT mapping, so the DERRM SRM
should target the global GTT instead.
v2: Add MI_SRM_LRM_GLOBAL_GTT define for -fixes
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 05:57:20PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
When I submitted the first patch adding these force wake functions,
Chris Wilson observed that I was using the wrong functions, so I sent
From: Ville Syrjälä ville.syrj...@linux.intel.com
We're currently misprinting the port name when vlv_wait_port_ready()
times out. Fix it by using port_name().
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1
Hi Chris,
In VLV, both hardware and software can use the write fifo in parallel, we are
adding this change as a water mark to make sure we atleast have 20 free entries
.This will help us to avoid software mmio write being dropped.
Thanks
Deepak
-Original Message-
From: Chris Wilson
On Fri, Nov 29, 2013 at 11:22:32AM +, S, Deepak wrote:
Hi Chris,
In VLV, both hardware and software can use the write fifo in parallel, we are
adding this change as a water mark to make sure we atleast have 20 free
entries .This will help us to avoid software mmio write being dropped.
During the vmap() routine for the dma-buf, we first grab the pages and
then try to allocate a temporary array to pass to the vmap(). However,
the shrinker can and will reap any object that is unbound if the
allocation for the array first fails. This includes the object which we
are attempting to
Sure Chris, I will recheck the spec and change the commit accordingly.
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, November 29, 2013 5:07 PM
To: S, Deepak
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/vlv:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 05:59:22PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
In the current code, at haswell_modeset_global_resources, first we
decide if we want to enable/disable the power well, then we decide if
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 06:01:19PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Currently, PC8 is enabled at modeset_global_resources, which is called
after intel_modeset_update_state. Due to this, there's a small
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 06:10:30PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This patch adds the initial infrastructure to allow a Runtime PM
implementation that sets the device to its D3 state. The patch just
2013/11/29 Rodrigo Vivi rodrigo.v...@gmail.com:
I think it should be a return instead a WARN.
Myabe I'm just sleeping yet, but I think the delayed work will execute this
even for non HAS_PC8 and warn will always ring on non HSW.
But even if I'm sleeping, since it really touch hsw registers
From: Ville Syrjälä ville.syrj...@linux.intel.com
The MI_PREDICATE_RESULT_2 register exits only on HSW. On other
platforms the same offset is either reserved, or contains some
other register. So write the register only on HSW.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 06:13:44PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Now that we are actually setting the device to the D3 state, we should
issue the notification.
The opregion spec says we should send
On Wed, Nov 27, 2013 at 06:20:34PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If I add code to enable runtime PM on my Haswell machine, start a
desktop environment, then enable runtime PM, these functions will
complain that they're trying to read/write registers
I think this one and last one could be only one patch, but anyway:
Reviewed-by Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 06:21:54PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
These are needed when we cat the debugfs and sysfs files.
V2: -
On Fri, Nov 29, 2013 at 09:14:41AM -0200, Rodrigo Vivi wrote:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 05:57:20PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
When I submitted the first patch adding these force wake functions,
On Fri, Nov 29, 2013 at 10:55 AM, Paulo Zanoni przan...@gmail.com wrote:
2013/11/29 Rodrigo Vivi rodrigo.v...@gmail.com:
I think it should be a return instead a WARN.
Myabe I'm just sleeping yet, but I think the delayed work will execute this
even for non HAS_PC8 and warn will always ring on
I think this one and last one could be only one patch, but anyway:
Reviewed-by Rodrigo Vivi rodrigo.v...@gmail.com
(resent with correct smtp)
On Fri, Nov 29, 2013 at 11:05 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
I think this one and last one could be only one patch, but anyway:
I got the idea here, just not sure if it fits on this patch or it is
just the commit message.
Anyway,
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
(resent with correct smtp)
On Fri, Nov 29, 2013 at 11:03 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
On Wed, Nov 27, 2013 at 06:20:34PM
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
(resent with correct smtp)
On Fri, Nov 29, 2013 at 10:56 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 06:13:44PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
(resent with correct smtp)
On Fri, Nov 29, 2013 at 10:54 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 06:10:30PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
(resent with correct smtp)
On Fri, Nov 29, 2013 at 10:38 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 06:01:19PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
(resent with correct smtp)
On Fri, Nov 29, 2013 at 10:35 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 27, 2013 at 05:59:22PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com
Fixes regression introduced by:
commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
Author: Paulo Zanoni paulo.r.zanoni at intel.com
Date: Wed Jul 3 17:12:13 2013 -0300
drm/i915: switch disable_power_well default value to 1
The bug
On Wed, Nov 06, 2013 at 01:46:41PM +1000, Dave Airlie wrote:
On Wed, Oct 30, 2013 at 4:06 AM, ville.syrj...@linux.intel.com wrote:
So I took another look at the vblank timestamping code, and got a bit
excited. The result is this patchset.
I'd like to merge this, I was hoping Mario could
On Wed, Nov 27, 2013 at 06:24:08PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Sometimes we want to disable all the screens on a system, because that
will allow the graphics card to be put into low-power states. The
problem is that, for example, while all screens
On Fri, Nov 29, 2013 at 11:05:49AM -0200, Rodrigo Vivi wrote:
I think this one and last one could be only one patch, but anyway:
Yeah, agreed that the split doesn't make too much sense. What I'd really
like to see in these commits (and also all the following ones that
sprinkle runtime pm get/put
On Fri, Nov 29, 2013 at 02:56:12PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The MI_PREDICATE_RESULT_2 register exits only on HSW. On other
platforms the same offset is either reserved, or contains some
other register. So write the register
On Thu, Nov 21, 2013 at 01:47:23PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And put it when it's off. Otherwise, when you run pm_pc8 from
intel-gpu-tools, and the delayed function that disables VDD runs,
we'll get some messages saying we're touching registers
On Thu, Nov 28, 2013 at 05:30:00PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
On Thu, Nov 28, 2013 at 05:30:01PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Only plane A is FBC capable on gen2 (like gen3), but the panel fitter
is hooked up to pipe B, so we want to prefer pipe B + plane A.
Ah, so that's the explanation!
On Thu, Nov 28, 2013 at 05:30:02PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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.
Just comment here
2013/11/29 Daniel Vetter dan...@ffwll.ch:
On Fri, Nov 29, 2013 at 11:05:49AM -0200, Rodrigo Vivi wrote:
I think this one and last one could be only one patch, but anyway:
Yeah, agreed that the split doesn't make too much sense. What I'd really
like to see in these commits (and also all the
On Thu, Nov 28, 2013 at 05:29:58PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On gen2 and gen3 chipsets FBC is supported only on plane A. Fix (and
simplify) the plane checks in intel_update_fbc() accordingly.
Signed-off-by: Ville Syrjälä
On Thu, Nov 28, 2013 at 05:29:59PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Initialize the FBC vfuncs on gen2 and gen3 chipsets,
which are the same as currently used for Crestline (early mobile gen4
platform).
Also make
a clean split for
2013/11/29 Rodrigo Vivi rodrigo.v...@gmail.com:
On Thu, Nov 21, 2013 at 01:47:23PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And put it when it's off. Otherwise, when you run pm_pc8 from
intel-gpu-tools, and the delayed function that disables VDD runs,
we'll get
On Thu, Nov 28, 2013 at 05:29:55PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Chris Wilons ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open Source Technology
On Fri, Nov 29, 2013 at 11:44:59AM +, Chris Wilson wrote:
During the vmap() routine for the dma-buf, we first grab the pages and
then try to allocate a temporary array to pass to the vmap(). However,
the shrinker can and will reap any object that is unbound if the
allocation for the array
On Thu, Nov 28, 2013 at 05:29:57PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Gen2 and gen3 don't have the FBC_CONTROL2 register, so don't
touch it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Hmm, another instance in
On Fri, Nov 29, 2013 at 11:53:44AM +, S, Deepak wrote:
Sure Chris, I will recheck the spec and change the commit accordingly.
I guess the big question is why vlv is special. We've had these 20 fifo
entries ever since gen6, so I'd also really like to know what suddenly
changed. Even the 20
On Fri, Nov 29, 2013 at 01:21:49PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We're currently misprinting the port name when vlv_wait_port_ready()
times out. Fix it by using port_name().
Signed-off-by: Ville Syrjälä
At Wed, 27 Nov 2013 18:10:30 -0200,
Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This patch adds the initial infrastructure to allow a Runtime PM
implementation that sets the device to its D3 state. The patch just
adds the necessary callbacks and the initial
On Fri, Nov 29, 2013 at 01:56:19PM +, Chris Wilson wrote:
On Thu, Nov 28, 2013 at 05:30:02PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
All mobile gen2 and gen3 chipsets should have FBC1, and the code
should now handle them all. So
On Fri, Nov 29, 2013 at 03:10:17PM +0100, Daniel Vetter wrote:
On Fri, Nov 29, 2013 at 01:56:19PM +, Chris Wilson wrote:
On Thu, Nov 28, 2013 at 05:30:02PM +0200, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
All mobile gen2 and gen3
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Thu, Nov 21, 2013 at 01:47:24PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The current code was checking if all bits of val were enabled and
DE_PCH_EVENT_IVB was disabled. The new code doesn't care about the
On Fri, Nov 29, 2013 at 11:59 AM, Paulo Zanoni przan...@gmail.com wrote:
2013/11/29 Rodrigo Vivi rodrigo.v...@gmail.com:
On Thu, Nov 21, 2013 at 01:47:23PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And put it when it's off. Otherwise, when you run pm_pc8 from
On Fri, Nov 29, 2013 at 02:15:52PM +, Chris Wilson wrote:
On Fri, Nov 29, 2013 at 03:10:17PM +0100, Daniel Vetter wrote:
On Fri, Nov 29, 2013 at 01:56:19PM +, Chris Wilson wrote:
On Thu, Nov 28, 2013 at 05:30:02PM +0200, ville.syrj...@linux.intel.com
wrote:
From: Ville
I'm just not sure if it won't regress in any other platform... Just
wondering why it was added in this way But..
makes sense so feel free to use:
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Thu, Nov 21, 2013 at 1:47 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni
with or without my bikeshed on patch 10 and with same regress concern
than patch 15,
feel free to use Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Thu, Nov 21, 2013 at 1:47 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
I don't see a reason to
On Fri, Nov 29, 2013 at 01:48:44PM +, Chris Wilson wrote:
On Fri, Nov 29, 2013 at 02:56:12PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The MI_PREDICATE_RESULT_2 register exits only on HSW. On other
platforms the same offset is
Hi all,
New -testing cycle with cool stuff:
- some more ppgtt prep patches from Ben
- a few fbc fixes from Ville
- power well rework from Imre
- vlv forcewake improvements from Deepak S, Ville and Jesse
- a few smaller things all over
Happy testing!
Cheers, Daniel
--
Daniel Vetter
Software
Here's an updated series of patches taking into account Ville's review.
Regards,
Thomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 52e060e..0a1e4a5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++
Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.
v2: Use an offset value depending on 3D_Multi_present and add
detail_present. (Ville Syrjälä)
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
drivers/gpu/drm/drm_edid.c | 64
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
drivers/gpu/drm/drm_edid.c | 67 +++---
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0a1e4a5..f1d6e1e 100644
---
Chasing wild speculation that we may be writing the wrong addresses
into the GTT for stolen objects, I would like to inspect those values.
Also to aide debugging ENOSPC issues with fragmentation, order the
object list by ascending GTT order so that holes are more easily seen.
Signed-off-by: Chris
Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.
v2: Use an offset value depending on 3D_Multi_present and add
detail_present. (Ville Syrjälä)
v3: Make sure the list is parsed even if 3D_Structure_ALL/MASK is not
present. (Ville
Here's a tentative patch that I unfortunately can't test on HSW because my dev
machine seems quite unhappy. The patch had limited testing on simulation
though.
The general problem is that intel_digital_port encoders personalities (ie
intel_encoder-type) are only set by -detect() at the moment.
The -detect() vfunc of connectors is usually responsible for setting the
encoder type on intel_digital_ports when a hotplug event happens.
However we sometimes want to force a modeset on a specific connector:
- the user can ask the SETCRTC ioctl to use a connector that wasne
marked as
On Fri, Nov 29, 2013 at 06:18:58PM +, Thomas Wood wrote:
Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.
v2: Use an offset value depending on 3D_Multi_present and add
detail_present. (Ville Syrjälä)
v3: Make sure the list is
From: Paulo Zanoni paulo.r.zan...@intel.com
In some cases we have more than 1 connector associated to an encoder
(e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of
these connectors. If we only allowed modesets for connected connectors
we would never need this patch, but since we
That we can use for debugging purposes.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 13 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
The -detect() vfunc of connectors is usually responsible for setting the
encoder type on intel_digital_ports when a hotplug event happens.
However we sometimes want to force a modeset on a specific connector:
- the user can ask the SETCRTC ioctl to use a connector that wasne
marked as
Completely untested, so buggy, I'm sure. In any case, might be of some use.
You're in a much better position to do this, I don't have a DDI machine that
works.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
69 matches
Mail list logo
