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
http://lists.freedesktop
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 conne
That we can use for debugging purposes.
Signed-off-by: Damien Lespiau
---
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
b/drivers/gpu/drm/i915/intel_displ
From: Paulo Zanoni
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 do allow modeset for
disc
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
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 conne
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. I
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 Syrjä
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
On Fri, Nov 29, 2013 at 03:33:28PM +, 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ä)
>
> Signed-off-by: Thom
Signed-off-by: Thomas Wood
---
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
--- 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
---
drivers/gpu/drm/drm_edid.c | 64 +
Signed-off-by: Thomas Wood
---
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
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2674,7 +2674,7
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
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 Eng
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ä
> >
> > The MI_PREDICATE_RESULT_2 register exits only on HSW. On other
> > platforms the same offset is either reserved, or contai
with or without my bikeshed on patch 10 and with same regress concern
than patch 15,
feel free to use Reviewed-by: Rodrigo Vivi
On Thu, Nov 21, 2013 at 1:47 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> I don't see a reason to touch VDD when we're disabling the panel:
> since the panel is
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
On Thu, Nov 21, 2013 at 1:47 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We just don't need this. This saves 250
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:
On Fri, Nov 29, 2013 at 11:59 AM, Paulo Zanoni wrote:
> 2013/11/29 Rodrigo Vivi :
>> On Thu, Nov 21, 2013 at 01:47:23PM -0200, Paulo Zanoni wrote:
>>> From: Paulo Zanoni
>>>
>>> And put it when it's off. Otherwise, when you run pm_pc8 from
>>> intel-gpu-tools, and the delayed function that disabl
Reviewed-by: Rodrigo Vivi
On Thu, Nov 21, 2013 at 01:47:24PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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
> state of DE_PCH_EVENT_IVB: it just checks i
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ä
> > >
> > > All mobile gen2 and gen3 chipsets should hav
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ä
> >
> > All mobile gen2 and gen3 chipsets should have FBC1, and the code
> > should now handle them all. So just set has_fbc=true
At Wed, 27 Nov 2013 18:10:30 -0200,
Paulo Zanoni wrote:
>
> From: Paulo Zanoni
>
> 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 infrastructure.
>
> We still d
On Fri, Nov 29, 2013 at 01:21:49PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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ä
Queued for -next, thanks for the patch.
-Dani
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 e
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, another instance in i915_suspend.c
-Chris
--
Chris Wilson, Intel Open Source
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 arr
On Thu, Nov 28, 2013 at 05:29:55PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilons
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
In
On Thu, Nov 28, 2013 at 05:29:59PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 gen7+ vs. gen5+ vfunc ini
2013/11/29 Rodrigo Vivi :
> On Thu, Nov 21, 2013 at 01:47:23PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> 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
On Thu, Nov 28, 2013 at 05:29:58PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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ä
Reviewed-by: Chris Wilso
2013/11/29 Daniel Vetter :
> 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 on
On Thu, Nov 28, 2013 at 05:30:02PM +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.
Just comment here that the default value for i
On Thu, Nov 28, 2013 at 05:30:01PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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!
Pretty please can I have
On Thu, Nov 28, 2013 at 05:30:00PM +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.
I
On Thu, Nov 21, 2013 at 01:47:23PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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 while the HW
> is susp
On Fri, Nov 29, 2013 at 02:56:12PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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
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 Wed, Nov 27, 2013 at 06:24:08PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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 are disabled, if we
>
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 default value to 1
The bug I'm seeing can be reproduced with:
- Boot your Haswell
On Wed, Nov 06, 2013 at 01:46:41PM +1000, Dave Airlie wrote:
> On Wed, Oct 30, 2013 at 4:06 AM, 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 ack it at least as it
>
Reviewed-by: Rodrigo Vivi
(resent with correct smtp)
On Fri, Nov 29, 2013 at 10:35 AM, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Wed, Nov 27, 2013 at 05:59:22PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> In the current code, at haswell_modeset_global_resources, first
Reviewed-by: Rodrigo Vivi
(resent with correct smtp)
On Fri, Nov 29, 2013 at 10:54 AM, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Wed, Nov 27, 2013 at 06:10:30PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> This patch adds the initial infrastructure to allow a Runtime PM
Reviewed-by: Rodrigo Vivi
(resent with correct smtp)
On Fri, Nov 29, 2013 at 10:38 AM, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Wed, Nov 27, 2013 at 06:01:19PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Currently, PC8 is enabled at modeset_global_resources, which is
Reviewed-by: Rodrigo Vivi
(resent with correct smtp)
On Fri, Nov 29, 2013 at 10:56 AM, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Wed, Nov 27, 2013 at 06:13:44PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Now that we are actually setting the device to the D3 state, we
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
(resent with correct smtp)
On Fri, Nov 29, 2013 at 11:03 AM, Rodrigo Vivi wrote:
> On Wed, Nov 27, 2013 at 06:20:34PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanon
On Fri, Nov 29, 2013 at 10:55 AM, Paulo Zanoni wrote:
> 2013/11/29 Rodrigo Vivi :
>> 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 sleepi
I think this one and last one could be only one patch, but anyway:
Reviewed-by Rodrigo Vivi
(resent with correct smtp)
On Fri, Nov 29, 2013 at 11:05 AM, Rodrigo Vivi wrote:
> I think this one and last one could be only one patch, but anyway:
>
> Reviewed-by Rodrigo Vivi
>
> On Wed, Nov 27, 20
On Fri, Nov 29, 2013 at 09:14:41AM -0200, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Wed, Nov 27, 2013 at 05:57:20PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > When I submitted the first patch adding these force wake functions,
> > Chris Wilson observed that I was usi
I think this one and last one could be only one patch, but anyway:
Reviewed-by Rodrigo Vivi
On Wed, Nov 27, 2013 at 06:21:54PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> These are needed when we cat the debugfs and sysfs files.
>
> V2: - Rebase
> V3: - Rebase
> V4: - Rebase
>
> Sign
On Wed, Nov 27, 2013 at 06:20:34PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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 while the
> graphics
Reviewed-by: Rodrigo Vivi
On Wed, Nov 27, 2013 at 06:13:44PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Now that we are actually setting the device to the D3 state, we should
> issue the notification.
>
> The opregion spec says we should send the message before the adapter
> is about
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/i915_gem.c | 7 +++
1 file changed, 3 i
2013/11/29 Rodrigo Vivi :
> 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
Reviewed-by: Rodrigo Vivi
On Wed, Nov 27, 2013 at 06:10:30PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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
Reviewed-by: Rodrigo Vivi
On Wed, Nov 27, 2013 at 06:01:19PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Currently, PC8 is enabled at modeset_global_resources, which is called
> after intel_modeset_update_state. Due to this, there's a small race
> condition on the case where we start en
Reviewed-by: Rodrigo Vivi
On Wed, Nov 27, 2013 at 05:59:22PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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
> we want to enable/disable PC8. On the cas
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: Updat
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 vm
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 dropp
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 [m
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_
Reviewed-by: Rodrigo Vivi
On Wed, Nov 27, 2013 at 05:57:20PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> When I submitted the first patch adding these force wake functions,
> Chris Wilson observed that I was using the wrong functions, so I sent
> a second version of the patch to correct
From: Ville Syrjälä
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
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm
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?
On Fri, Nov 29, 2013 at 03:44:31PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> 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 leaving 20 entries
From: Deepak S
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 the register (Deep
From: Deepak S
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
---
drivers/gpu/drm/i91
On Fri, Nov 29, 2013 at 02:57:13PM +0800, Xiang, Haihao wrote:
> From: "Xiang, Haihao"
>
> 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 pipeline and there is
70 matches
Mail list logo
