Re: [Intel-gfx] Fw: Very low performance when streaming textures

[Zhang, Xiong Y]

Using the latest mesa master tree, I test it on my Core i7-2600 : 

1)  In default configuration, the monitor's refresh rate is 60FPS, so the test 
result is 59.3 FPS
2)  export vblank_mode = 0, then the test result is 170 FPS.
I don't see the big difference between using direct transfer or using PBO, the 
test result almost is the same on these two cases.

thanks

-Original Message-
From: intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org 
[mailto:intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org] On 
Behalf Of Ben Widawsky
Sent: Tuesday, January 22, 2013 1:34 PM
To: mesa-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] Fw: Very low performance when streaming textures

mesa-dev is a better place for this question.

Begin forwarded message:

Date: Mon, 21 Jan 2013 22:13:34 +0100
From: Marcel Witte 
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] Very low performance when streaming textures


Hi,

I'm refering to the example of this article about streaming textures and using 
Pixel Buffer Objects: http://www.songho.ca/opengl/gl_pbo.html

The PBO Unpack example
(http://www.songho.ca/opengl/files/pboUnpack.zip) is creating an "animated 
texture" and can switch between three modes: Direct transfering of the texture 
using glTexSubImage2D, and using one or two PBOs for better performance.

I'm running this example on an notebook with an Intel Core i7-2630QM and an 
Nvidia Geforce GT 550M with Optimus. If I'm using the Nvidia card using optirun 
I get the expected high performance, using direct tranfer about 150 fps and 
using PBOs about 400 fps. But if I'm using the intel card I get really slow 
rates, about 40 fps in direct mode and even worse about 10 fps using PBOs.

Running the same example with windows I get about 100 fps using the intel card 
in every mode.

Is this expected behaviour or is this a bug in the intel linux driver?
How can I improve the performance? I hope you can help me here as I'm writing a 
real application using a video as texture.

Regards,
Marcel Witte
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Question about driver capatibilities - triple monitor?

[Daniel Vetter]

On Tue, Jan 22, 2013 at 7:36 AM, Ian Pilcher  wrote:
> On 01/21/2013 06:05 PM, Csillag wrote:
>> But now, thanks to GIGABYTE's PR about Thunderbolt and 4K (
>> http://www.gigabyte.com/MicroSite/323/4k.html ), I realized that it
>> might be possible to use a "DisplayPort to Dual-DisplayPort Adapter" to
>> split a DisplayPort 1.1 output into two channels, and drive two monitors
>> from there. (Of course the resolution is limited, but 1920 x 1200 is
>> just what I need.)
>
> Be careful.  When I looked into those "splitters", I found out that
> they are closer to "federators".  In other words, they take 2 displays
> and make them looks like 1 giant display to the operating system.
>
> So 2 1920x1200 displays would appear to be a single 3840x1200 display.
>
> This will give you the number of pixels that you expect, but your
> desktop environment is unlikely to play all that well with such a
> configuration.
>
> (If anyone knows of a device that doesn't operate this way, please let
> me know.  I'll almost certainly buy a couple.)

Multistream display port should make this possible, though currently
no Intel hw supports it (nor any other open-source driver fwiws) :(

For your 3 monitor required a decen ivb based board should be good
enough, as long as you keep the restriction in mind that 2 of them
need to have the same dotclock (which in practice boils down to either
2x DP monitors or 2x identical monitors with the same type of
connector).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/3] drm/i915: acer inverted brightness quirks

[Jani Nikula]

Some long standing brightness fixes for a few Acer machines under
eMachines and Packard Bell brands. These should remove the need to use
i915.invert_brightness=1 on affected machines.

BR,
Jani.

Jani Nikula (3):
  drm/i915: add quirk to invert brightness on eMachines G725
  drm/i915: add quirk to invert brightness on eMachines e725
  drm/i915: add quirk to invert brightness on Packard Bell NCL20

 drivers/gpu/drm/i915/intel_display.c |9 +
 1 file changed, 9 insertions(+)

-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915: add quirk to invert brightness on eMachines G725

[Jani Nikula]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628
Reported-by: Roland Gruber 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7725446..44f9d8f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8599,6 +8599,9 @@ static struct intel_quirk intel_quirks[] = {
 
/* Acer Aspire 5734Z must invert backlight brightness */
{ 0x2a42, 0x1025, 0x0459, quirk_invert_brightness },
+
+   /* Acer/eMachines G725 */
+   { 0x2a42, 0x1025, 0x0210, quirk_invert_brightness },
 };
 
 static void intel_init_quirks(struct drm_device *dev)
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: add quirk to invert brightness on eMachines e725

[Jani Nikula]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35
[Note: There are more than one broken setups in the bug. This fixes one.]
Reported-by: Martins 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 44f9d8f..8575a62 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8602,6 +8602,9 @@ static struct intel_quirk intel_quirks[] = {
 
/* Acer/eMachines G725 */
{ 0x2a42, 0x1025, 0x0210, quirk_invert_brightness },
+
+   /* Acer/eMachines e725 */
+   { 0x2a42, 0x1025, 0x0212, quirk_invert_brightness },
 };
 
 static void intel_init_quirks(struct drm_device *dev)
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915: add quirk to invert brightness on Packard Bell NCL20

[Jani Nikula]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156
Reported-by: Alan Zimmerman 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8575a62..7262786 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8605,6 +8605,9 @@ static struct intel_quirk intel_quirks[] = {
 
/* Acer/eMachines e725 */
{ 0x2a42, 0x1025, 0x0212, quirk_invert_brightness },
+
+   /* Acer/Packard Bell NCL20 */
+   { 0x2a42, 0x1025, 0x034b, quirk_invert_brightness },
 };
 
 static void intel_init_quirks(struct drm_device *dev)
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] drm/i915: acer inverted brightness quirks

[Daniel Vetter]

On Tue, Jan 22, 2013 at 12:50:33PM +0200, Jani Nikula wrote:
> Some long standing brightness fixes for a few Acer machines under
> eMachines and Packard Bell brands. These should remove the need to use
> i915.invert_brightness=1 on affected machines.

Queued up all three patches for -next, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Run hangcheck if we timeout whilst waiting for a seqno

[Chris Wilson]

As a precaution against the driver fouling up and missing a hang leaving
the caller in an indefinite wait, manually inspect for a GPU hang if we
timeout whilst waiting for a seqno.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0d878c1..54bb921 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1129,6 +1129,9 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
u32 seqno,
else
end = wait_event_timeout(ring->irq_queue, EXIT_COND,
 timeout_jiffies);
+   /* Be paranoid and check that we haven't missed a GPU hang */
+   if (end == 0)
+   i915_hangcheck_elapsed((unsigned long)dev_priv->dev);
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
-- 
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/1] drm/i915: use gem_set_seqno() on hardware init

[Mika Kuoppala]

When machine was rebooted or module was reloaded,
gem_hw_init() set last_seqno to be identical to next_seqno.
This lead to situation that waits for first ever request
always passed immediately regardless if it was actually
executed.

Use gem_set_seqno() to be consistent how hw is
initialized on init, wrap and on resume.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c |6 --
 drivers/gpu/drm/i915/intel_ringbuffer.c |2 --
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d90d2f9..1a61d99 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3979,8 +3979,6 @@ i915_gem_init_hw(struct drm_device *dev)
 
i915_gem_init_swizzling(dev);
 
-   dev_priv->next_seqno = dev_priv->last_seqno = (u32)~0 - 0x1000;
-
ret = intel_init_render_ring_buffer(dev);
if (ret)
return ret;
@@ -3997,6 +3995,10 @@ i915_gem_init_hw(struct drm_device *dev)
goto cleanup_bsd_ring;
}
 
+   ret = i915_gem_set_seqno(dev, ((u32)~0 - 0x1000));
+   if (ret)
+   return ret;
+
/*
 * XXX: There was some w/a described somewhere suggesting loading
 * contexts before PPGTT.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2bd074a..1bb2ec5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1184,8 +1184,6 @@ static int intel_init_ring_buffer(struct drm_device *dev,
if (IS_I830(ring->dev) || IS_845G(ring->dev))
ring->effective_size -= 128;
 
-   intel_ring_init_seqno(ring, dev_priv->last_seqno);
-
return 0;
 
 err_unmap:
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Run hangcheck if we timeout whilst waiting for a seqno

[Chris Wilson]

As a precaution against the driver fouling up and missing a hang leaving
the caller in an indefinite wait, manually inspect for a GPU hang if we
timeout whilst waiting for a seqno.

v2: To avoid issues with multiple clients running hangchecks
concurrently or in very rapid succession, make sure we only reactivate
the hangcheck timer if we find it idle whilst waiting.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0d878c1..dc382eb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1096,7 +1096,6 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
u32 seqno,
struct timespec before, now, wait_time={1,0};
unsigned long timeout_jiffies;
long end;
-   bool wait_forever = true;
int ret;
 
if (i915_seqno_passed(ring->get_seqno(ring, true), seqno))
@@ -1104,10 +1103,8 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
u32 seqno,
 
trace_i915_gem_request_wait_begin(ring, seqno);
 
-   if (timeout != NULL) {
+   if (timeout != NULL)
wait_time = *timeout;
-   wait_forever = false;
-   }
 
timeout_jiffies = timespec_to_jiffies(&wait_time);
 
@@ -1129,6 +1126,12 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
u32 seqno,
else
end = wait_event_timeout(ring->irq_queue, EXIT_COND,
 timeout_jiffies);
+   /* Be paranoid and check that we haven't missed a GPU hang */
+   if (end == 0 &&
+   i915_enable_hangcheck &&
+   !timer_pending(&dev_priv->gpu_error.hangcheck_timer))
+   mod_timer(&dev_priv->gpu_error.hangcheck_timer,
+ round_jiffies_up(jiffies + 
DRM_I915_HANGCHECK_JIFFIES));
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
@@ -1140,7 +1143,7 @@ static int __wait_seqno(struct intel_ring_buffer *ring, 
u32 seqno,
ret = i915_gem_check_wedge(&dev_priv->gpu_error, interruptible);
if (ret)
end = ret;
-   } while (end == 0 && wait_forever);
+   } while (end == 0 && timeout == NULL);
 
getrawmonotonic(&now);
 
-- 
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: use gem_set_seqno() on hardware init

[Chris Wilson]

On Tue, Jan 22, 2013 at 02:12:17PM +0200, Mika Kuoppala wrote:
> When machine was rebooted or module was reloaded,
> gem_hw_init() set last_seqno to be identical to next_seqno.
> This lead to situation that waits for first ever request
> always passed immediately regardless if it was actually
> executed.
> 
> Use gem_set_seqno() to be consistent how hw is
> initialized on init, wrap and on resume.

Nice catch, and you caught the only other side-effect I could spot of
moving the seqno init, so

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: use gem_set_seqno() on hardware init

[Daniel Vetter]

On Tue, Jan 22, 2013 at 12:28:16PM +, Chris Wilson wrote:
> On Tue, Jan 22, 2013 at 02:12:17PM +0200, Mika Kuoppala wrote:
> > When machine was rebooted or module was reloaded,
> > gem_hw_init() set last_seqno to be identical to next_seqno.
> > This lead to situation that waits for first ever request
> > always passed immediately regardless if it was actually
> > executed.
> > 
> > Use gem_set_seqno() to be consistent how hw is
> > initialized on init, wrap and on resume.
> 
> Nice catch, and you caught the only other side-effect I could spot of
> moving the seqno init, so
> 
> Reviewed-by: Chris Wilson 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/10] drm/i915: fix intel_init_power_wells

[Daniel Vetter]

On Mon, Jan 21, 2013 at 03:37:42PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 18, 2013 at 06:29:05PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni 
> > 
> > The current code was wrong in many different ways, so this is a full
> > rewrite. We don't have "different power wells for different parts of
> > the GPU", we have a single power well, but we have multiple registers
> > that can be used to request enabling/disabling the power well. So
> > let's be a good citizen and only use the register we're supposed to
> > use, except when we're loading the driver, where we clear the request
> > made by the BIOS.
> > 
> > If any of the registers is requesting the power well to be enabled, it
> > will be enabled. If none of the registers is requesting the power well
> > to be enabled, it will be disabled.
> > 
> > For now we're just forcing the power well to be enabled, but in the
> > next commits we'll change this.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |8 ++--
> >  drivers/gpu/drm/i915/intel_display.c |5 +--
> >  drivers/gpu/drm/i915/intel_drv.h |2 +-
> >  drivers/gpu/drm/i915/intel_pm.c  |   70 
> > +-
> >  4 files changed, 59 insertions(+), 26 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 2521617..f054554 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4414,10 +4414,10 @@
> >  #define   AUDIO_CP_READY_C (1<<9)
> >  
> >  /* HSW Power Wells */
> > -#define HSW_PWR_WELL_CTL1  0x45400 /* BIOS */
> > -#define HSW_PWR_WELL_CTL2  0x45404 /* Driver */
> > -#define HSW_PWR_WELL_CTL3  0x45408 /* KVMR */
> > -#define HSW_PWR_WELL_CTL4  0x4540C /* Debug */
> > +#define HSW_PWR_WELL_BIOS  0x45400 /* CTL1 */
> > +#define HSW_PWR_WELL_DRIVER0x45404 /* CTL2 */
> > +#define HSW_PWR_WELL_KVMR  0x45408 /* CTL3 */
> > +#define HSW_PWR_WELL_DEBUG 0x4540C /* CTL4 */
> >  #define   HSW_PWR_WELL_ENABLE  (1<<31)
> >  #define   HSW_PWR_WELL_STATE   (1<<30)
> >  #define HSW_PWR_WELL_CTL5  0x45410
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index b35902e..4a9f048 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8647,10 +8647,7 @@ static void i915_disable_vga(struct drm_device *dev)
> >  
> >  void intel_modeset_init_hw(struct drm_device *dev)
> >  {
> > -   /* We attempt to init the necessary power wells early in the 
> > initialization
> > -* time, so the subsystems that expect power to be enabled can work.
> > -*/
> > -   intel_init_power_wells(dev);
> > +   intel_init_power_well(dev);
> >  
> > intel_prepare_ddi(dev);
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index aeff0d1..8cfad75 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -666,7 +666,7 @@ extern void intel_update_fbc(struct drm_device *dev);
> >  extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
> >  extern void intel_gpu_ips_teardown(void);
> >  
> > -extern void intel_init_power_wells(struct drm_device *dev);
> > +extern void intel_init_power_well(struct drm_device *dev);
> >  extern void intel_enable_gt_powersave(struct drm_device *dev);
> >  extern void intel_disable_gt_powersave(struct drm_device *dev);
> >  extern void gen6_gt_check_fifodbg(struct drm_i915_private *dev_priv);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 5a8a72c..2273b9c 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4043,33 +4043,69 @@ void intel_init_clock_gating(struct drm_device *dev)
> > dev_priv->display.init_clock_gating(dev);
> >  }
> >  
> > -/* Starting with Haswell, we have different power wells for
> > - * different parts of the GPU. This attempts to enable them all.
> > +static void intel_set_power_well(struct drm_device *dev, bool enable)
> > +{
> > +   struct drm_i915_private *dev_priv = dev->dev_private;
> > +   bool is_enabled, enable_requested;
> > +   uint32_t tmp;
> > +
> > +   tmp = I915_READ(HSW_PWR_WELL_DRIVER);
> > +   is_enabled = !!(tmp & HSW_PWR_WELL_STATE);
> > +   enable_requested = !!(tmp & HSW_PWR_WELL_ENABLE);
> > +
> > +   if (enable) {
> > +   if (!enable_requested)
> > +   I915_WRITE(HSW_PWR_WELL_DRIVER, HSW_PWR_WELL_ENABLE);
> > +
> > +   if (!is_enabled) {
> > +   DRM_DEBUG_KMS("Enabling power well\n");
> > +   if (wait_for((I915_READ(HSW_PWR_WELL_DRIVER) &
> > + HSW_PWR_WELL_STATE), 20))
> > +

Re: [Intel-gfx] [PATCH 06/10] drm/i915: check the power down well on assert_pipe()

[Daniel Vetter]

On Mon, Jan 21, 2013 at 03:45:48PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni 
> > 
> > If the power well is disabled, we should not try to read its
> > registers, otherwise we'll get "unclaimed register" messages.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c |   12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a7fb7e1..921b020 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1214,9 +1214,15 @@ void assert_pipe(struct drm_i915_private *dev_priv,
> > if (pipe == PIPE_A && dev_priv->quirks & QUIRK_PIPEA_FORCE)
> > state = true;
> >  
> > -   reg = PIPECONF(cpu_transcoder);
> > -   val = I915_READ(reg);
> > -   cur_state = !!(val & PIPECONF_ENABLE);
> > +   if (cpu_transcoder == TRANSCODER_EDP ||
> > +   (I915_READ(HSW_PWR_WELL_DRIVER) & HSW_PWR_WELL_STATE)) {
> 
> Should that also check HSW_PWR_WELL_ENABLE? KVMR might have the well
> enabled, while the driver has it disabled. But KVMR might have already
> disabled the well, and it might get disabled just after this check,
> and then you would hit the unclaimed register issue again.

The important matter is to not read registers in the power well if it's
off, for which checking just one of the three bits is enough. If the kvm
keeps the power well on, we just avoid checking the pipe state if we don't
need the power well, but otherwise no side effect. Otoh just one set bit
makes sure that the power well is on and we can read the regs).

So looks good to me.
-Daniel
> 
> > +   reg = PIPECONF(cpu_transcoder);
> > +   val = I915_READ(reg);
> > +   cur_state = !!(val & PIPECONF_ENABLE);
> > +   } else {
> > +   cur_state = false;
> > +   }
> > +
> > WARN(cur_state != state,
> >  "pipe %c assertion failure (expected %s, current %s)\n",
> >  pipe_name(pipe), state_string(state), state_string(cur_state));
> > -- 
> > 1.7.10.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/8] Detect and deal with Interrupt 'Storms' from noisy Hotplug Lines.

[Egbert Eich]

Hi Daniel,

I've played around a bit now, and implemented your suggestions:

On Thu, Jan 17, 2013 at 03:45:26PM +0100, Daniel Vetter wrote:
> On Thu, Jan 17, 2013 at 03:01:06PM +0100, Egbert Eich wrote:
> > Hi Daniel,
> > 
> > On Fri, Jan 11, 2013 at 09:34:08PM +0100, Daniel Vetter wrote:
> > > 
> > > Nice work, and we know that we need this since quite a while. But
> > > unfortunately we've not yet come around to implement something. Some
> > > high-level comments on how I think this should best be handled:
> > > 
> > > - imo dv_priv->hotplug_supported_mask should die - it leaks platform
> > >   specific irq magic from i915_irq.c into every connector/encoder. And we
> > >   have had the bugs and confusions to prove that it's not a good idea. I
> > >   think it'd be better if we add a new HOTPLUG_PIN_FOO enum that encoders
> > >   register interest in, and the platform code in i915_irq.c then maps
> > >   from/to that. On a quick check we have hotplug pins for CRT, TV,
> > >   SDVO_B&C and PORT_A-D (for DP&HDMI).
> > 
> > I thought along the same lines, I just didn't want to go quite as far.
> > Therefore I added functions in i915_irq.c to set these depending on the
> > connector.
> > 
> > > 
> > >   Also note that on PCH_SPLIT platforms port A is not in the same
> > >   register, further platforms will make an even cuter mess of this ...
> > 
> > Ok, I will look into that.
> > 

So far I have not seen anywhere where there's hotplug support for PORT_A.
PORT_A is marked as an internal connector without any HPD.

> > > 
> > > - I think the the hpd pin should be track in the encoder, not in the
> > >   connector. The only encoders where there's not a 1:1 relationship (sdvo
> > >   and ddi on hsw) want it there. Also, we already have the ->hot_plug
> > >   callback in the encoder, which will be useful for later extensions.

For SDVO it is definitely much simpler to track this in the encoder.
However in the IRQ handling code we always need to take the detour thru
the connector as the drm code expects any hotplog related information in
the connector.
To get the connector we always have to walk thru the connector list and
obtain the associated encoder. Walking thru the encoder list isn't 
sufficient as there is no easy way from encoder to connector.
I don't have a strong preference either way - in the code I'm currently 
playing around with I keep this information in struct intel_encoder.

> > > 
> > > - Since some encoders share the same hpd pin (HDMI&DP on pre-hsw) I think
> > >   we should keep the noise statistic data in the device's dev_priv
> > >   somewhere in an array, with one set for each hpd pin from the enum 
> > > above.
> > 
> > This would also be an option. I did notice that these pins are shared, it
> > didn't cause any issues as always both connectors got flagged 
> > simultaniously.
> > On the other hand calling the same disable/enable twice when traversing the
> > connector list is sorta ugly.
> 
> Yeah, I mostly want to have a clear 1:1 relationship between interrupt
> lines and the statistics about the noise on them ...

Yup. That's easy to do. In fact in my original prove of concept implementation
I had it that way. However I was not sure if it's appreciated to add such 
bookkeeping in such a global fashion.

> 
> > > - In 3.8 the drm hpd/polling helpers are much improved and don't randomly
> > >   poll everything any more. So if a hpd connector isn't marked as
> > >   OUTPUT_POLL, it wont ever get polled. Which means if you disable the hpd
> > >   irq for it, we need to have our own poll work to do that for us. The
> > >   long-term goal I have is to pimp the encoder->hot_plug callback also for
> > >   this case, to avoid re-running the connector detect code on unrelated
> > >   outputs (which can sometimes cause havoc).
> > 
> > I do change the state of the 'polled' member when I disable/reenable hotplug
> > interrupts already. This part therefore should work fine already.
> 
> Hm, I've missed that, despite looking for it in the patches. One thing to
> note is that the poll work will disable itself if there's no connector
> with one of the POLL flags set in 3.8, so I think you need to kick it
> again when polling. Another thing to keep in mind is that we have encoders

Exactly. This is something I had missed. It's however easily fixed by
calling drm_kms_helper_poll_enable() when changing the settings.

> with POLL and HDP connectors (sometimes on the same one) - SDVO is the
> prime example since polling seems to work, but not too reliably. Hence we
> need the polling as a backup. To correctly restore those flags I guess we
> need a saved_polled variable in intel_connector which we need to restore
> when enabling the the hpd line again.

I don't see this in the code (drm-intel-testing pulled last Friday).
On any connector it is either the DRM_CONNECTOR_POLL_HPD or the 
DRM_CONNECTOR_POLL_CONNECT (mostly with the DRM_CONNECTOR_POLL_DISCONNECT flag)
set but not both.
Of course it could be don

Re: [Intel-gfx] [PATCH 03/10] drm/i915: fix intel_init_power_wells

[Ville Syrjälä]

On Tue, Jan 22, 2013 at 02:02:26PM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2013 at 03:37:42PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 18, 2013 at 06:29:05PM -0200, Paulo Zanoni wrote:
> > > From: Paulo Zanoni 
> > > 
> > > The current code was wrong in many different ways, so this is a full
> > > rewrite. We don't have "different power wells for different parts of
> > > the GPU", we have a single power well, but we have multiple registers
> > > that can be used to request enabling/disabling the power well. So
> > > let's be a good citizen and only use the register we're supposed to
> > > use, except when we're loading the driver, where we clear the request
> > > made by the BIOS.
> > > 
> > > If any of the registers is requesting the power well to be enabled, it
> > > will be enabled. If none of the registers is requesting the power well
> > > to be enabled, it will be disabled.
> > > 
> > > For now we're just forcing the power well to be enabled, but in the
> > > next commits we'll change this.
> > > 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h  |8 ++--
> > >  drivers/gpu/drm/i915/intel_display.c |5 +--
> > >  drivers/gpu/drm/i915/intel_drv.h |2 +-
> > >  drivers/gpu/drm/i915/intel_pm.c  |   70 
> > > +-
> > >  4 files changed, 59 insertions(+), 26 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 2521617..f054554 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -4414,10 +4414,10 @@
> > >  #define   AUDIO_CP_READY_C   (1<<9)
> > >  
> > >  /* HSW Power Wells */
> > > -#define HSW_PWR_WELL_CTL10x45400 /* BIOS */
> > > -#define HSW_PWR_WELL_CTL20x45404 /* Driver */
> > > -#define HSW_PWR_WELL_CTL30x45408 /* KVMR */
> > > -#define HSW_PWR_WELL_CTL40x4540C /* Debug */
> > > +#define HSW_PWR_WELL_BIOS0x45400 /* CTL1 */
> > > +#define HSW_PWR_WELL_DRIVER  0x45404 /* CTL2 */
> > > +#define HSW_PWR_WELL_KVMR0x45408 /* CTL3 */
> > > +#define HSW_PWR_WELL_DEBUG   0x4540C /* CTL4 */
> > >  #define   HSW_PWR_WELL_ENABLE(1<<31)
> > >  #define   HSW_PWR_WELL_STATE (1<<30)
> > >  #define HSW_PWR_WELL_CTL50x45410
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index b35902e..4a9f048 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -8647,10 +8647,7 @@ static void i915_disable_vga(struct drm_device 
> > > *dev)
> > >  
> > >  void intel_modeset_init_hw(struct drm_device *dev)
> > >  {
> > > - /* We attempt to init the necessary power wells early in the 
> > > initialization
> > > -  * time, so the subsystems that expect power to be enabled can work.
> > > -  */
> > > - intel_init_power_wells(dev);
> > > + intel_init_power_well(dev);
> > >  
> > >   intel_prepare_ddi(dev);
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index aeff0d1..8cfad75 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -666,7 +666,7 @@ extern void intel_update_fbc(struct drm_device *dev);
> > >  extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
> > >  extern void intel_gpu_ips_teardown(void);
> > >  
> > > -extern void intel_init_power_wells(struct drm_device *dev);
> > > +extern void intel_init_power_well(struct drm_device *dev);
> > >  extern void intel_enable_gt_powersave(struct drm_device *dev);
> > >  extern void intel_disable_gt_powersave(struct drm_device *dev);
> > >  extern void gen6_gt_check_fifodbg(struct drm_i915_private *dev_priv);
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 5a8a72c..2273b9c 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -4043,33 +4043,69 @@ void intel_init_clock_gating(struct drm_device 
> > > *dev)
> > >   dev_priv->display.init_clock_gating(dev);
> > >  }
> > >  
> > > -/* Starting with Haswell, we have different power wells for
> > > - * different parts of the GPU. This attempts to enable them all.
> > > +static void intel_set_power_well(struct drm_device *dev, bool enable)
> > > +{
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > + bool is_enabled, enable_requested;
> > > + uint32_t tmp;
> > > +
> > > + tmp = I915_READ(HSW_PWR_WELL_DRIVER);
> > > + is_enabled = !!(tmp & HSW_PWR_WELL_STATE);
> > > + enable_requested = !!(tmp & HSW_PWR_WELL_ENABLE);
> > > +
> > > + if (enable) {
> > > + if (!enable_requested)
> > > + I915_W

Re: [Intel-gfx] [PATCH 0/8] Detect and deal with Interrupt 'Storms' from noisy Hotplug Lines.

[Daniel Vetter]

On Tue, Jan 22, 2013 at 2:22 PM, Egbert Eich  wrote:
> On Thu, Jan 17, 2013 at 03:45:26PM +0100, Daniel Vetter wrote:
>> On Thu, Jan 17, 2013 at 03:01:06PM +0100, Egbert Eich wrote:
>> > Hi Daniel,
>> >
>> > On Fri, Jan 11, 2013 at 09:34:08PM +0100, Daniel Vetter wrote:
>> > >
>> > > Nice work, and we know that we need this since quite a while. But
>> > > unfortunately we've not yet come around to implement something. Some
>> > > high-level comments on how I think this should best be handled:
>> > >
>> > > - imo dv_priv->hotplug_supported_mask should die - it leaks platform
>> > >   specific irq magic from i915_irq.c into every connector/encoder. And we
>> > >   have had the bugs and confusions to prove that it's not a good idea. I
>> > >   think it'd be better if we add a new HOTPLUG_PIN_FOO enum that encoders
>> > >   register interest in, and the platform code in i915_irq.c then maps
>> > >   from/to that. On a quick check we have hotplug pins for CRT, TV,
>> > >   SDVO_B&C and PORT_A-D (for DP&HDMI).
>> >
>> > I thought along the same lines, I just didn't want to go quite as far.
>> > Therefore I added functions in i915_irq.c to set these depending on the
>> > connector.
>> >
>> > >
>> > >   Also note that on PCH_SPLIT platforms port A is not in the same
>> > >   register, further platforms will make an even cuter mess of this ...
>> >
>> > Ok, I will look into that.
>> >
>
> So far I have not seen anywhere where there's hotplug support for PORT_A.
> PORT_A is marked as an internal connector without any HPD.

Hm, I've thought the hw supports short dp pulses on eDP port A in case
the panel needs our attention, but maybe I've mixed that up with the
dp aux irq for port A. In any case, that's easy to add if we need it.

>
>> > >
>> > > - I think the the hpd pin should be track in the encoder, not in the
>> > >   connector. The only encoders where there's not a 1:1 relationship (sdvo
>> > >   and ddi on hsw) want it there. Also, we already have the ->hot_plug
>> > >   callback in the encoder, which will be useful for later extensions.
>
> For SDVO it is definitely much simpler to track this in the encoder.
> However in the IRQ handling code we always need to take the detour thru
> the connector as the drm code expects any hotplog related information in
> the connector.

Yeah, once we start filtering irq handling to only the ports affect,
the current code will get messy. Which is why I think we should move
the actual hpd handling into encoder->hotplug (and no longer call
every ->detect callback). But I'm not too sure about it, and it can be
done later on anyway.

> To get the connector we always have to walk thru the connector list and
> obtain the associated encoder. Walking thru the encoder list isn't
> sufficient as there is no easy way from encoder to connector.
> I don't have a strong preference either way - in the code I'm currently
> playing around with I keep this information in struct intel_encoder.

Can't we just loop over all connectors and before we update the
hotplug state check whether the attached intel encoder is interested
in the hpd irq we're processing? Or do I miss something here?

>> with POLL and HDP connectors (sometimes on the same one) - SDVO is the
>> prime example since polling seems to work, but not too reliably. Hence we
>> need the polling as a backup. To correctly restore those flags I guess we
>> need a saved_polled variable in intel_connector which we need to restore
>> when enabling the the hpd line again.
>
> I don't see this in the code (drm-intel-testing pulled last Friday).
> On any connector it is either the DRM_CONNECTOR_POLL_HPD or the
> DRM_CONNECTOR_POLL_CONNECT (mostly with the DRM_CONNECTOR_POLL_DISCONNECT 
> flag)
> set but not both.
> Of course it could be done like you suggest, ie. continue polling despite
> waiting for interrupts, but this begs the question if we should not resort
> to polling entirely: the only benefit of doing HDP would be that we would
> get informed about an output change more quickly.

I mean that different connectors which use the same hpd line could use
both polling and non-polling modes since there's only one hpd line per
sdvo encoder. So we need to be a bit careful with which part of our
detect code handles which pieces of hw and that we don't lose anything
when switching modes.

> I had sent a patch for EDID caching on the DRM level to Dave last December.
> I received some comments and suggestions from Ville from Intel which I had
> worked in - however I have not seen any reaction from Dave, yet.

Hm, missed that, I'll take a look again.

> Maybe you want to take a look at this. It cannot cache in all situations
> where caching would be useful and possible. It still should do a fairly good
> job of caching EDID extension blocks. This is because it currently
> lacks any driver interface and thus only can do as much as you can do
> without a deeper knowledge of what's going on on the hardware level.

Atm I'm less sure about what we rea

Re: [Intel-gfx] [PATCH 06/10] drm/i915: check the power down well on assert_pipe()

[Ville Syrjälä]

On Tue, Jan 22, 2013 at 02:04:09PM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2013 at 03:45:48PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
> > > From: Paulo Zanoni 
> > > 
> > > If the power well is disabled, we should not try to read its
> > > registers, otherwise we'll get "unclaimed register" messages.
> > > 
> > > Signed-off-by: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c |   12 +---
> > >  1 file changed, 9 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index a7fb7e1..921b020 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -1214,9 +1214,15 @@ void assert_pipe(struct drm_i915_private *dev_priv,
> > >   if (pipe == PIPE_A && dev_priv->quirks & QUIRK_PIPEA_FORCE)
> > >   state = true;
> > >  
> > > - reg = PIPECONF(cpu_transcoder);
> > > - val = I915_READ(reg);
> > > - cur_state = !!(val & PIPECONF_ENABLE);
> > > + if (cpu_transcoder == TRANSCODER_EDP ||
> > > + (I915_READ(HSW_PWR_WELL_DRIVER) & HSW_PWR_WELL_STATE)) {
> > 
> > Should that also check HSW_PWR_WELL_ENABLE? KVMR might have the well
> > enabled, while the driver has it disabled. But KVMR might have already
> > disabled the well, and it might get disabled just after this check,
> > and then you would hit the unclaimed register issue again.
> 
> The important matter is to not read registers in the power well if it's
> off, for which checking just one of the three bits is enough. If the kvm
> keeps the power well on, we just avoid checking the pipe state if we don't
> need the power well, but otherwise no side effect. Otoh just one set bit
> makes sure that the power well is on and we can read the regs).

The power well may be on when you're reading the status bit, but
assuming it was KVMR who caused the power well to be powered on,
we can't be sure the power well will remain powered long enough
to read the registers.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/10] drm/i915: fix intel_init_power_wells

[Ville Syrjälä]

On Fri, Jan 18, 2013 at 06:29:05PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni 
> 
> The current code was wrong in many different ways, so this is a full
> rewrite. We don't have "different power wells for different parts of
> the GPU", we have a single power well, but we have multiple registers
> that can be used to request enabling/disabling the power well. So
> let's be a good citizen and only use the register we're supposed to
> use, except when we're loading the driver, where we clear the request
> made by the BIOS.
> 
> If any of the registers is requesting the power well to be enabled, it
> will be enabled. If none of the registers is requesting the power well
> to be enabled, it will be disabled.
> 
> For now we're just forcing the power well to be enabled, but in the
> next commits we'll change this.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |8 ++--
>  drivers/gpu/drm/i915/intel_display.c |5 +--
>  drivers/gpu/drm/i915/intel_drv.h |2 +-
>  drivers/gpu/drm/i915/intel_pm.c  |   70 
> +-
>  4 files changed, 59 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2521617..f054554 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4414,10 +4414,10 @@
>  #define   AUDIO_CP_READY_C   (1<<9)
>  
>  /* HSW Power Wells */
> -#define HSW_PWR_WELL_CTL10x45400 /* BIOS */
> -#define HSW_PWR_WELL_CTL20x45404 /* Driver */
> -#define HSW_PWR_WELL_CTL30x45408 /* KVMR */
> -#define HSW_PWR_WELL_CTL40x4540C /* Debug */
> +#define HSW_PWR_WELL_BIOS0x45400 /* CTL1 */
> +#define HSW_PWR_WELL_DRIVER  0x45404 /* CTL2 */
> +#define HSW_PWR_WELL_KVMR0x45408 /* CTL3 */
> +#define HSW_PWR_WELL_DEBUG   0x4540C /* CTL4 */
>  #define   HSW_PWR_WELL_ENABLE(1<<31)
>  #define   HSW_PWR_WELL_STATE (1<<30)
>  #define HSW_PWR_WELL_CTL50x45410
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b35902e..4a9f048 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8647,10 +8647,7 @@ static void i915_disable_vga(struct drm_device *dev)
>  
>  void intel_modeset_init_hw(struct drm_device *dev)
>  {
> - /* We attempt to init the necessary power wells early in the 
> initialization
> -  * time, so the subsystems that expect power to be enabled can work.
> -  */
> - intel_init_power_wells(dev);
> + intel_init_power_well(dev);
>  
>   intel_prepare_ddi(dev);
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index aeff0d1..8cfad75 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -666,7 +666,7 @@ extern void intel_update_fbc(struct drm_device *dev);
>  extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
>  extern void intel_gpu_ips_teardown(void);
>  
> -extern void intel_init_power_wells(struct drm_device *dev);
> +extern void intel_init_power_well(struct drm_device *dev);
>  extern void intel_enable_gt_powersave(struct drm_device *dev);
>  extern void intel_disable_gt_powersave(struct drm_device *dev);
>  extern void gen6_gt_check_fifodbg(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5a8a72c..2273b9c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4043,33 +4043,69 @@ void intel_init_clock_gating(struct drm_device *dev)
>   dev_priv->display.init_clock_gating(dev);
>  }
>  
> -/* Starting with Haswell, we have different power wells for
> - * different parts of the GPU. This attempts to enable them all.
> +static void intel_set_power_well(struct drm_device *dev, bool enable)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + bool is_enabled, enable_requested;
> + uint32_t tmp;
> +
> + tmp = I915_READ(HSW_PWR_WELL_DRIVER);
> + is_enabled = !!(tmp & HSW_PWR_WELL_STATE);
> + enable_requested = !!(tmp & HSW_PWR_WELL_ENABLE);
> +
> + if (enable) {
> + if (!enable_requested)
> + I915_WRITE(HSW_PWR_WELL_DRIVER, HSW_PWR_WELL_ENABLE);
> +
> + if (!is_enabled) {
> + DRM_DEBUG_KMS("Enabling power well\n");
> + if (wait_for((I915_READ(HSW_PWR_WELL_DRIVER) &
> +   HSW_PWR_WELL_STATE), 20))
> + DRM_ERROR("Timeout enabling power well\n");
> + }
> + } else {
> + if (enable_requested)
> + I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
> +
> + if (is_enabled) {
> +

Re: [Intel-gfx] [PATCH 0/8] Detect and deal with Interrupt 'Storms' from noisy Hotplug Lines.

[Egbert Eich]

On Tue, Jan 22, 2013 at 02:48:29PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2013 at 2:22 PM, Egbert Eich  wrote:
> 
> Hm, I've thought the hw supports short dp pulses on eDP port A in case
> the panel needs our attention, but maybe I've mixed that up with the
> dp aux irq for port A. In any case, that's easy to add if we need it.

Yes, of course.
> 
> >
> >
> > For SDVO it is definitely much simpler to track this in the encoder.
> > However in the IRQ handling code we always need to take the detour thru
> > the connector as the drm code expects any hotplog related information in
> > the connector.
> 
> Yeah, once we start filtering irq handling to only the ports affect,
> the current code will get messy. Which is why I think we should move
> the actual hpd handling into encoder->hotplug (and no longer call
> every ->detect callback). But I'm not too sure about it, and it can be
> done later on anyway.

Yeah, this looks easily doable.

> 
> > To get the connector we always have to walk thru the connector list and
> > obtain the associated encoder. Walking thru the encoder list isn't
> > sufficient as there is no easy way from encoder to connector.
> > I don't have a strong preference either way - in the code I'm currently
> > playing around with I keep this information in struct intel_encoder.
> 
> Can't we just loop over all connectors and before we update the
> hotplug state check whether the attached intel encoder is interested
> in the hpd irq we're processing? Or do I miss something here?

No, this is exactly how I've implemented it now.

> 
> >> with POLL and HDP connectors (sometimes on the same one) - SDVO is the
> >> prime example since polling seems to work, but not too reliably. Hence we
> >> need the polling as a backup. To correctly restore those flags I guess we
> >> need a saved_polled variable in intel_connector which we need to restore
> >> when enabling the the hpd line again.
> >
> > I don't see this in the code (drm-intel-testing pulled last Friday).
> > On any connector it is either the DRM_CONNECTOR_POLL_HPD or the
> > DRM_CONNECTOR_POLL_CONNECT (mostly with the DRM_CONNECTOR_POLL_DISCONNECT 
> > flag)
> > set but not both.
> > Of course it could be done like you suggest, ie. continue polling despite
> > waiting for interrupts, but this begs the question if we should not resort
> > to polling entirely: the only benefit of doing HDP would be that we would
> > get informed about an output change more quickly.
> 
> I mean that different connectors which use the same hpd line could use
> both polling and non-polling modes since there's only one hpd line per
> sdvo encoder. So we need to be a bit careful with which part of our
> detect code handles which pieces of hw and that we don't lose anything
> when switching modes.

Ah, ok. Got it, will think about it. Thanks!

> 
> > I had sent a patch for EDID caching on the DRM level to Dave last December.
> > I received some comments and suggestions from Ville from Intel which I had
> > worked in - however I have not seen any reaction from Dave, yet.
> 
> Hm, missed that, I'll take a look again.

I had sent it on dri-devel. If you want I can send this to you again.

> 
> > Maybe you want to take a look at this. It cannot cache in all situations
> > where caching would be useful and possible. It still should do a fairly good
> > job of caching EDID extension blocks. This is because it currently
> > lacks any driver interface and thus only can do as much as you can do
> > without a deeper knowledge of what's going on on the hardware level.
> 
> Atm I'm less sure about what we really should do wrt edid caching. One
> ugly problem is boot-up, where a bunch of userspace pieces all want to
> figure out the optimal configuration, but where it's pretty pointless
> to re-query to hw all the time. So I wonder whether we shouldn't have
> temporal caching of even unreliable outputs (e.g. a few seconds), with
> an option for drivers to invalidate the cache on e.g. a hpd interrupt.

Definitely. I don't think it is unreasonable to believe that once we have
a valid EDID that this will remain valid either until we receive an event
from the hardware telling us that something has changed (hotplug event)
or we reprobe and find out that something has definitely changed or
our reprobe timeout has expired.
If there's no valid EDID it is of course reasonable to reprobe at the
earliest convenience: the situation where there's no EDID at all can
be detected very quickly.
EDID readout is a slow undertaking and EDID extension make it even
take longer.
Thus in my code I compare the EDID base block and if this hasn't changed
I use data from the cache. This of course will only work if monitors
are not able to dynamically reconfigure their EDID blocks.

> 
> Another ugly issue is when people disconnect outputs slowly so that we
> get the hpd interrupt _before_ the cable is fully unplugged. We've
> tried to fix those by checking the relevant hpd line state, but on
> noisy l

[Intel-gfx] [PATCH] drm/i915: HDMI/DP - ELD info refresh support for Haswell

[Wang Xingchao]

ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().

Reviewed-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Wang Xingchao 
---
 drivers/gpu/drm/i915/intel_ddi.c |   21 +
 drivers/gpu/drm/i915/intel_display.c |4 
 drivers/gpu/drm/i915/intel_drv.h |1 +
 3 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f02b3fe..821316c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -650,6 +650,7 @@ static void intel_ddi_mode_set(struct drm_encoder *encoder,
DRM_DEBUG_KMS("Preparing DDI mode for Haswell on port %c, pipe %c\n",
  port_name(port), pipe_name(pipe));
 
+   intel_crtc->eld_vld = false;
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
@@ -1274,10 +1275,14 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder)
 static void intel_enable_ddi(struct intel_encoder *intel_encoder)
 {
struct drm_encoder *encoder = &intel_encoder->base;
+   struct drm_crtc *crtc = encoder->crtc;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   int pipe = intel_crtc->pipe;
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
+   uint32_t tmp;
 
if (type == INTEL_OUTPUT_HDMI) {
/* In HDMI/DVI mode, the port width, and swing/emphasis values
@@ -1290,18 +1295,34 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder)
 
ironlake_edp_backlight_on(intel_dp);
}
+
+   if (intel_crtc->eld_vld) {
+   tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+   tmp |= ((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) << (pipe * 
4));
+   I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
+   }
 }
 
 static void intel_disable_ddi(struct intel_encoder *intel_encoder)
 {
struct drm_encoder *encoder = &intel_encoder->base;
+   struct drm_crtc *crtc = encoder->crtc;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   int pipe = intel_crtc->pipe;
int type = intel_encoder->type;
+   struct drm_device *dev = encoder->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   uint32_t tmp;
 
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
ironlake_edp_backlight_off(intel_dp);
}
+
+   tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+   tmp &= ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) << (pipe * 4));
+   I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
 }
 
 int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1464e47..11fbe04 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3745,10 +3745,12 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_connector *connector;
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 
/* crtc should still be enabled when we disable it. */
WARN_ON(!crtc->enabled);
 
+   intel_crtc->eld_vld = false;
dev_priv->display.crtc_disable(crtc);
intel_crtc_update_sarea(crtc, false);
dev_priv->display.off(crtc);
@@ -5622,6 +5624,7 @@ static void haswell_write_eld(struct drm_connector 
*connector,
struct drm_i915_private *dev_priv = connector->dev->dev_private;
uint8_t *eld = connector->eld;
struct drm_device *dev = crtc->dev;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
uint32_t eldv;
uint32_t i;
int len;
@@ -5663,6 +5666,7 @@ static void haswell_write_eld(struct drm_connector 
*connector,
DRM_DEBUG_DRIVER("ELD on pipe %c\n", pipe_name(pipe));
 
eldv = AUDIO_ELD_VALID_A << (pipe * 4);
+   intel_crtc->eld_vld = true;
 
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
DRM_DEBUG_DRIVER("ELD: DisplayPort detected\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 116580b..be588da 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -206,6 +206,7 @@ struct intel_crtc {
 * some outputs connected to this crtc.
 */
bool active;
+   bool eld_vld;
bool primary_disabled; /* is the crtc obscured by a plane? */
bool lowfreq_avail;

Re: [Intel-gfx] i915-related and general system freezes with specific kernel config // IOMMU

[Mihai Moldovan]

* On 21.01.2013 07:11 PM, Mihai Moldovan wrote:
> I'm also currently testing a kernel without the Intel IOMMU feature
> [CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least
> not seeing USB and PCI(e) issues. I'll leave the box running for some
> more [time] [...]

No freezes for >22h, seems to be fine.


> [...] and will afterwards disable IOMMU as a whole to see if I hit
> USB and PCI(e) issues again with that combination.

The systems seems to run stable with CONFIG_IOMMU_SUPPORT=n set, too. This is
expected.
However: unlike during earlier tests when I disabled IOMMU and Intel IOMMU via
kernel/boot parameters, I am not seeing any DMA mapping errors.

There seems to be a difference between disabling IOMMU/Intel IOMMU statically in
the kernel compared to disabling it via kernel parameter. Is this another bug?

I've attached both kernel ring buffer logs (minus the timings for easier 
diffing.)

  [*] kern-new-iommu_off.log.bz2 disables IOMMU and Intel IOMMU via boot 
parameter
  [*] kern-iommu_static_off.log.bz2 has CONFIG_IOMMU_SUPPORT=n set and any IOMMU
support statically disabled (also consequently DMAR)



Mihai



kern-new-iommu_off.log.bz2
Description: BZip2 compressed data


kern-iommu_static_off.log.bz2
Description: BZip2 compressed data


smime.p7s
Description: S/MIME Cryptographic Signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915-related and general system freezes with specific kernel config // IOMMU

[Daniel Vetter]

On Tue, Jan 22, 2013 at 7:15 PM, Mihai Moldovan  wrote:
> * On 21.01.2013 07:11 PM, Mihai Moldovan wrote:
>> I'm also currently testing a kernel without the Intel IOMMU feature
>> [CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least
>> not seeing USB and PCI(e) issues. I'll leave the box running for some
>> more [time] [...]
>
> No freezes for >22h, seems to be fine.
>
>
>> [...] and will afterwards disable IOMMU as a whole to see if I hit
>> USB and PCI(e) issues again with that combination.
>
> The systems seems to run stable with CONFIG_IOMMU_SUPPORT=n set, too. This is
> expected.
> However: unlike during earlier tests when I disabled IOMMU and Intel IOMMU via
> kernel/boot parameters, I am not seeing any DMA mapping errors.
>
> There seems to be a difference between disabling IOMMU/Intel IOMMU statically 
> in
> the kernel compared to disabling it via kernel parameter. Is this another bug?

Behaviour should be the same for the actual dma access at the hw
layer, but if you disable things at compile-time at least drm/i915
selects different paths. We've recently killed those though since it's
not worth the complexity at all. But dunno why you still get dma
errors, that shouldn't be possible. Maybe David has an idea.

> I've attached both kernel ring buffer logs (minus the timings for easier 
> diffing.)
>
>   [*] kern-new-iommu_off.log.bz2 disables IOMMU and Intel IOMMU via boot 
> parameter
>   [*] kern-iommu_static_off.log.bz2 has CONFIG_IOMMU_SUPPORT=n set and any 
> IOMMU
> support statically disabled (also consequently DMAR)

In any case I'll ping David about my 2nd quirk patch and whether
that's something which makes sense and could be merged. Thanks a lot
for all the testing you've done.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets

[David Woodhouse]

On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
> We already have the quirk entry for the mobile platform, but also
> reports on some desktop versions. So be paranoid and set it
> everywhere.
> 
> References: 
> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html
> Cc: sta...@vger.kernel.org
> Cc: David Woodhouse 
> Reported-and-tested-by: Mihai Moldovan 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/iommu/intel-iommu.c |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 9743769..19854bf 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -4215,13 +4215,19 @@ static void __devinit quirk_iommu_rwbf(struct pci_dev 
> *dev)
>  {
>   /*
>* Mobile 4 Series Chipset neglects to set RWBF capability,
> -  * but needs it:
> +  * but needs it. Same seems to hold for the desktop versions.
>*/
>   printk(KERN_INFO "DMAR: Forcing write-buffer flush capability\n");
>   rwbf_quirk = 1;
>  }
>  
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_rwbf);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_rwbf);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_rwbf);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_rwbf);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_rwbf);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_rwbf);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_rwbf);
>  
>  #define GGC 0x52
>  #define GGC_MEMORY_SIZE_MASK (0xf << 8)

Again, I'm really unhappy about doing this kind of thing based on
hearsay. This should have a specific reference (with URL) to a published
erratum. Rajesh?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Fw: Very low performance when streaming textures

[Marcel Witte]

Thanks for your testing. Can you give me any hints why the performance is so 
bad on my System?

I'm using openSUSE 12.2, Mesa 9.0.1, the latest xf86-video-intel and Kernel 
3.7.3

Am Dienstag, 22. Januar 2013 schrieb Zhang, Xiong Y :
> Using the latest mesa master tree, I test it on my Core i7-2600 : 
> 
> 1)  In default configuration, the monitor's refresh rate is 60FPS, so the 
> test result is 59.3 FPS
> 2)  export vblank_mode = 0, then the test result is 170 FPS.
> I don't see the big difference between using direct transfer or using PBO, 
> the test result almost is the same on these two cases.
> 
> thanks
> 
> -Original Message-
> From: intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org 
> [mailto:intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org] On 
> Behalf Of Ben Widawsky
> Sent: Tuesday, January 22, 2013 1:34 PM
> To: mesa-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] Fw: Very low performance when streaming textures
> 
> mesa-dev is a better place for this question.
> 
> Begin forwarded message:
> 
> Date: Mon, 21 Jan 2013 22:13:34 +0100
> From: Marcel Witte 
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] Very low performance when streaming textures
> 
> 
> Hi,
> 
> I'm refering to the example of this article about streaming textures and 
> using Pixel Buffer Objects: http://www.songho.ca/opengl/gl_pbo.html
> 
> The PBO Unpack example
> (http://www.songho.ca/opengl/files/pboUnpack.zip) is creating an "animated 
> texture" and can switch between three modes: Direct transfering of the 
> texture using glTexSubImage2D, and using one or two PBOs for better 
> performance.
> 
> I'm running this example on an notebook with an Intel Core i7-2630QM and an 
> Nvidia Geforce GT 550M with Optimus. If I'm using the Nvidia card using 
> optirun I get the expected high performance, using direct tranfer about 150 
> fps and using PBOs about 400 fps. But if I'm using the intel card I get 
> really slow rates, about 40 fps in direct mode and even worse about 10 fps 
> using PBOs.
> 
> Running the same example with windows I get about 100 fps using the intel 
> card in every mode.
> 
> Is this expected behaviour or is this a bug in the intel linux driver?
> How can I improve the performance? I hope you can help me here as I'm writing 
> a real application using a video as texture.
> 
> Regards,
> Marcel Witte
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: HDMI/DP - ELD info refresh support for Haswell

[Daniel Vetter]

On Tue, Jan 22, 2013 at 11:25:25PM +0800, Wang Xingchao wrote:
> ELD info should be updated dynamically according to hot plug event.
> For haswell chip, clear/set the eld valid bit and output enable bit
> from callback intel_disable/eanble_ddi().
> 
> Reviewed-by: Ville Syrjälä 
> Reviewed-by: Rodrigo Vivi 
> Signed-off-by: Wang Xingchao 

Queued for -next, thanks for the patch. For further patches please include
an in-patch changelog for the different patch iterations, that way it's
really clear what (and why) something changed compared to a previous patch
submission. Otherwise if a patch later on causes issues or is unclear why
we need a given piece of code it's much more work to dig out the old
discussions and conclusions.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Intel HD 4000 and Sunix DPD2000 scrolling screen

[Karsten Nielsen]

Hi,

I am just curios is there anyone that has any suggestions as to what might be 
wrong ?

Thanks,
Karsten

-Original message-
From:   Karsten Nielsen 
Sent:   Fri 21-12-2012 10:52
Subject:Re: [Intel-gfx] Intel HD 4000 and Sunix DPD2000 scrolling screen
To: Daniel Vetter ; 
CC: intel-gfx@lists.freedesktop.org; 
> Hi,
> 
> As promised
> 
> dmesg is here http://home.foo-bar.dk/dmesg.txt
> and the video http://home.foo-bar.dk/i915-scrolling.mp4
> 
> 
> - Karsten
> 
> 
> -Original message-
> From: Daniel Vetter 
> Sent: Thursday 20th December 2012 10:49
> To: Karsten Nielsen 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] Intel HD 4000 and Sunix DPD2000 scrolling screen
> 
> 
> On Wed, Dec 19, 2012 at 8:44 PM, Karsten Nielsen   > wrote:
> > I have bought a Lenovo X1 carbon which have a integrated Intel HD 4000 
> graphics chip and wanted to attach 2 external monitors however there is only 
> one mini-DislpayPort in this machine.
> >
> > I found a Sunix DPD2000 displayport splitter and it works and percents a 
> > nice 
> 3840x1200 display to me but the screen scrolls I cannot get it to stop.
> >
> > System:
> > Debian sid with kernel 3.7
> > xserver-xorg  1:7.7+1
> > xserver-xorg-video-intel  2:2.20.14-1
> >
> > Anyone have suggestions ?
> 
> Make a short video of the scrolling behaviour and upload it somewhere
> please. Also, please boot with drm.debug=0xe added to your kernel
> cmdline and attach the complete dmesg after the monitor is enable
> 
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch  
> 
> 
> 
> ___
> 
> Intel-gfx mailing list
> 
> Intel-gfx@lists.freedesktop.org
> 
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Intel HD 4000 and Sunix DPD2000 scrolling screen

[Daniel Vetter]

On Tue, Jan 22, 2013 at 8:44 PM, Karsten Nielsen  wrote:
> Hi,
>
> I am just curios is there anyone that has any suggestions as to what might be 
> wrong ?

I've looked at your video and logs, but didn't have an immediate idea.
Can you please file a bug for this at bugs.freedesktop.org against DRI
-> DRM/Intel?

Also, does this scrolling behaviour happen on all the resolutions?
I've also noticed that your dp converter exposes some single-screen
modes - do those work?

Yours, Daniel

>
> Thanks,
> Karsten
>
> -Original message-
> From:   Karsten Nielsen 
> Sent:   Fri 21-12-2012 10:52
> Subject:Re: [Intel-gfx] Intel HD 4000 and Sunix DPD2000 scrolling 
> screen
> To: Daniel Vetter ;
> CC: intel-gfx@lists.freedesktop.org;
>> Hi,
>>
>> As promised
>>
>> dmesg is here http://home.foo-bar.dk/dmesg.txt
>> and the video http://home.foo-bar.dk/i915-scrolling.mp4
>>
>>
>> - Karsten
>>
>>
>> -Original message-
>> From: Daniel Vetter 
>> Sent: Thursday 20th December 2012 10:49
>> To: Karsten Nielsen 
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] Intel HD 4000 and Sunix DPD2000 scrolling screen
>>
>>
>> On Wed, Dec 19, 2012 at 8:44 PM, Karsten Nielsen >  > wrote:
>> > I have bought a Lenovo X1 carbon which have a integrated Intel HD 4000
>> graphics chip and wanted to attach 2 external monitors however there is only
>> one mini-DislpayPort in this machine.
>> >
>> > I found a Sunix DPD2000 displayport splitter and it works and percents a 
>> > nice
>> 3840x1200 display to me but the screen scrolls I cannot get it to stop.
>> >
>> > System:
>> > Debian sid with kernel 3.7
>> > xserver-xorg  1:7.7+1
>> > xserver-xorg-video-intel  2:2.20.14-1
>> >
>> > Anyone have suggestions ?
>>
>> Make a short video of the scrolling behaviour and upload it somewhere
>> please. Also, please boot with drm.debug=0xe added to your kernel
>> cmdline and attach the complete dmesg after the monitor is enable
>>
>> Thanks, Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch 
>>
>>
>>
>> ___
>>
>> Intel-gfx mailing list
>>
>> Intel-gfx@lists.freedesktop.org
>>
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>
>>
>>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: fixup sbi_read/write locking

[daniel . vetter]

From: Daniel Vetter 

commit 09153000b8ca32a539a1207edebabd0d40b6c61b
Author: Daniel Vetter 
Date:   Wed Dec 12 14:06:44 2012 +0100

drm/i915: rework locking for intel_dpio|sbi_read|write

reworked the locking around sbi_read/write functions for 3.8-fixes.
But

commit dde86e2db54545ef981b64805097a7b4c3156d6e
Author: Paulo Zanoni 
Date:   Sat Dec 1 12:04:25 2012 -0200

drm/i915: add lpt_init_pch_refcl

Added new use-cases in the -next tree which has not been updated in
the merge. Fix it up.

Reported-by: Ben Widawsky 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 26df9e3..27fe702 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4871,6 +4871,8 @@ static void lpt_init_pch_refclk(struct drm_device *dev)
if (!has_vga)
return;
 
+   mutex_lock(&dev_priv->dpio_lock);
+
/* XXX: Rip out SDV support once Haswell ships for real. */
if (IS_HASWELL(dev) && (dev->pci_device & 0xFF00) == 0x0C00)
is_sdv = true;
@@ -5013,6 +5015,8 @@ static void lpt_init_pch_refclk(struct drm_device *dev)
tmp = intel_sbi_read(dev_priv, SBI_DBUFF0, SBI_ICLK);
tmp |= SBI_DBUFF0_ENABLE;
intel_sbi_write(dev_priv, SBI_DBUFF0, tmp, SBI_ICLK);
+
+   mutex_unlock(&dev_priv->dpio_lock);
 }
 
 /*
-- 
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] iommu/intel: disable DMAR for g4x integrated gfx

[Daniel Vetter]

On Mon, Jan 21, 2013 at 01:03:48PM -0600, David Woodhouse wrote:
> On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> > DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> > So don't bother, but instead disable it by default to allow distros to
> > unconditionally enable DMAR support.
> 
> Acked-By: David Woodhouse 

Ok, I've picked that up into my drm-intel-fixes tree and will send it off
to Dave in the next few days.

> It *really* winds me up that we never bother to test this hardware
> before we ship it.
> 
> But I'm even *more* disappointed that we can't even diagnose it and
> publish coherent errata *after* the fact. I'd really like to see each
> quirk which disables features referencing a specific published erratum.
> We really ought to be able to manage at least *that* much.
> 
> Rajesh?

Yeah, some real quirk notice would be nice. I've hunted down the gen4
errata sheets, but there's nothing in there about the gfx not working for
dmar. Hence I'm opting for a working gpu in case of doubts.

Also note that according to intel docs only the gm45 and g45 have vt-d
support. So with this bug report we have them all covered. I've still left
all the other gen4 ids in the quirk tables, just in case intel marketing
materials win another round against me. Instead amended the commit message
a bit.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fixup sbi_read/write locking

[Ben Widawsky]

On Tue, 22 Jan 2013 15:33:27 +0100
daniel.vet...@ffwll.ch wrote:

> From: Daniel Vetter 
> 
> commit 09153000b8ca32a539a1207edebabd0d40b6c61b
> Author: Daniel Vetter 
> Date:   Wed Dec 12 14:06:44 2012 +0100
> 
> drm/i915: rework locking for intel_dpio|sbi_read|write
> 
> reworked the locking around sbi_read/write functions for 3.8-fixes.
> But
> 
> commit dde86e2db54545ef981b64805097a7b4c3156d6e
> Author: Paulo Zanoni 
> Date:   Sat Dec 1 12:04:25 2012 -0200
> 
> drm/i915: add lpt_init_pch_refcl
> 
> Added new use-cases in the -next tree which has not been updated in
> the merge. Fix it up.
> 
> Reported-by: Ben Widawsky 
> Signed-off-by: Daniel Vetter 
Reviewed-by: Ben Widawsky 
Tested-by: Ben Widawsky 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fixup sbi_read/write locking

[Daniel Vetter]

On Tue, Jan 22, 2013 at 03:42:14PM -0800, Ben Widawsky wrote:
> On Tue, 22 Jan 2013 15:33:27 +0100
> daniel.vet...@ffwll.ch wrote:
> 
> > From: Daniel Vetter 
> > 
> > commit 09153000b8ca32a539a1207edebabd0d40b6c61b
> > Author: Daniel Vetter 
> > Date:   Wed Dec 12 14:06:44 2012 +0100
> > 
> > drm/i915: rework locking for intel_dpio|sbi_read|write
> > 
> > reworked the locking around sbi_read/write functions for 3.8-fixes.
> > But
> > 
> > commit dde86e2db54545ef981b64805097a7b4c3156d6e
> > Author: Paulo Zanoni 
> > Date:   Sat Dec 1 12:04:25 2012 -0200
> > 
> > drm/i915: add lpt_init_pch_refcl
> > 
> > Added new use-cases in the -next tree which has not been updated in
> > the merge. Fix it up.
> > 
> > Reported-by: Ben Widawsky 
> > Signed-off-by: Daniel Vetter 
> Reviewed-by: Ben Widawsky 
> Tested-by: Ben Widawsky 

Queued for -next, thanks for the review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx