Re: [Intel-gfx] [PATCH 2/2] drm/i915: Correct the bit number for the MI_FLUSH_ENABLE.

2012-01-25 Thread Daniel Vetter 
On Tue, Jan 24, 2012 at 08:22:57PM -0800, Ben Widawsky wrote:
 On 01/24/12 18:55, Eric Anholt wrote:
 On Sat, 21 Jan 2012 17:36:13 +0100, Daniel Vetterdan...@ffwll.ch  wrote:
 On Thu, Jan 19, 2012 at 10:50:06AM -0800, Eric Anholt wrote:
 Older specs claimed this was bit 11, but newer specs and the actual
 simulator code say it was bit 12.  Regardless, we don't use MI_FLUSH,
 or try to enable it any more.
 
 Signed-off-by: Eric Anholte...@anholt.net
 
 I'd like to amend this with the following (on this patch instead of the
 other, so that ppl actually can find it with git blame):
 
 Furthermore actually setting bit12 results in gpu hangs both on snb and
 ivb. Ben Widawsky discovered a ppt that claims that both bit12 and bit11
 must be set, but that doesn't help either. And last but not least,
 MI_FLUSH seems to work regardless of the setting of these bits.
 
 I haven't seen bit12 hanging snb/ivb -- I only knew of it hanging ilk
 (since it doesn't exist there).  On my snb, running xvideo so that
 MI_FLUSHes are generated by the userland (I think -- I haven't caught
 them in cat i915_batchbuffers | intel_dump_decode -), with
 intel_reg_read 0x209c saying 0x1240, things are going fine.  Also with
 0x209c saying 0x240 (the result of this patch).
 
 Daniel has a failing test on IVB. I haven't tried hard enough to
 make it fail on SNB, so I cannot speak to that.

Could be some other crash and I've just had an unlucky day and it died
much earlier than usual. Anyway, with things tested I'm happy with these 2
patches and queued them for -next.

 That 2008 PPT mentioned also said the bit and bit 12, and only in
 one cut-and-paste of a command line did I see it say two bits should be
 set.  I would trust the actual code more than a ppt.
 
 But basically, whatever we do to make this broken code go away, I'm fine
 with.
 
 I'm in the same boat. I think trying to figure out which source to
 trust is a losing game for all, and our best bet is to find out what
 the Windows driver does, and presumably that cut-and-paste is not
 from the Windows driver.

I've added a small comment to patch 2 to urge people to get a clue before
trying to use this bit ;-)

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working

2012-01-25 Thread Daniel Vetter 
On Wed, Jan 25, 2012 at 09:25:11AM +0100, Alfonso Fiore wrote:
 On Wed, Jan 25, 2012 at 9:12 AM, Alfonso Fiore alfonso.fi...@gmail.com 
 wrote:
  On Wed, Jan 25, 2012 at 8:55 AM, Daniel Vetter dan...@ffwll.ch wrote:
 
  Have you booted with nomodeset and are using the vesa X driver? Iirc
  you've said that the bios can setup up things correctly, the idea is to
  grab a register dump to learn how the bios sets things up.
 
 Here you go.
 
 I run a test at 1024x768 over HDMI with nomodeset.
 
 Please note xrandr complains:
 xrandr: Failed to get size of gamma for output default
 
 and there is no more file for edid:
 cp: cannot stat
 `/sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/edid': No
 such file or directory
 cp: cannot stat
 `/sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid':
 No such file or directory

That's correct, these files are provided by the kernel modesetting code
from the drm driver.

 logs attached.

Thanks, I'll have a look.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working

2012-01-25 Thread Alfonso Fiore 
On Wed, Jan 25, 2012 at 9:12 AM, Alfonso Fiore alfonso.fi...@gmail.com wrote:
 On Wed, Jan 25, 2012 at 8:55 AM, Daniel Vetter dan...@ffwll.ch wrote:

 Have you booted with nomodeset and are using the vesa X driver? Iirc
 you've said that the bios can setup up things correctly, the idea is to
 grab a register dump to learn how the bios sets things up.

Here you go.

I run a test at 1024x768 over HDMI with nomodeset.

Please note xrandr complains:
xrandr: Failed to get size of gamma for output default

and there is no more file for edid:
cp: cannot stat
`/sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/edid': No
such file or directory
cp: cannot stat
`/sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid':
No such file or directory

logs attached.

Hope this helps,
alfonso


HDMI_with_nomodeset.tgz
Description: GNU Zip compressed data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working

2012-01-25 Thread Alfonso Fiore 
On Wed, Jan 25, 2012 at 8:55 AM, Daniel Vetter dan...@ffwll.ch wrote:

 Have you booted with nomodeset and are using the vesa X driver? Iirc
 you've said that the bios can setup up things correctly, the idea is to
 grab a register dump to learn how the bios sets things up.

Hi Daniel,

silly me. Now I got your point.

You'll get this asap.

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Correct the bit number for the MI_FLUSH_ENABLE.

2012-01-25 Thread Chris Wilson 
On Tue, 24 Jan 2012 18:55:53 -0800, Eric Anholt e...@anholt.net wrote:
 On Sat, 21 Jan 2012 17:36:13 +0100, Daniel Vetter dan...@ffwll.ch wrote:
  On Thu, Jan 19, 2012 at 10:50:06AM -0800, Eric Anholt wrote:
   Older specs claimed this was bit 11, but newer specs and the actual
   simulator code say it was bit 12.  Regardless, we don't use MI_FLUSH,
   or try to enable it any more.
   
   Signed-off-by: Eric Anholt e...@anholt.net
  
  I'd like to amend this with the following (on this patch instead of the
  other, so that ppl actually can find it with git blame):
  
  Furthermore actually setting bit12 results in gpu hangs both on snb and
  ivb. Ben Widawsky discovered a ppt that claims that both bit12 and bit11
  must be set, but that doesn't help either. And last but not least,
  MI_FLUSH seems to work regardless of the setting of these bits.
 
 I haven't seen bit12 hanging snb/ivb -- I only knew of it hanging ilk
 (since it doesn't exist there).  On my snb, running xvideo so that
 MI_FLUSHes are generated by the userland (I think -- I haven't caught
 them in cat i915_batchbuffers | intel_dump_decode -), with
 intel_reg_read 0x209c saying 0x1240, things are going fine.  Also with
 0x209c saying 0x240 (the result of this patch).

The SNB Xv path, that is the code called by Gen6DisplayVideoTexture, 
never used MI_FLUSH.
-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 2/2] drm/i915: Correct the bit number for the MI_FLUSH_ENABLE.

2012-01-25 Thread Daniel Vetter 
On Wed, Jan 25, 2012 at 09:57:58AM +, Chris Wilson wrote:
 On Tue, 24 Jan 2012 18:55:53 -0800, Eric Anholt e...@anholt.net wrote:
  On Sat, 21 Jan 2012 17:36:13 +0100, Daniel Vetter dan...@ffwll.ch wrote:
   On Thu, Jan 19, 2012 at 10:50:06AM -0800, Eric Anholt wrote:
Older specs claimed this was bit 11, but newer specs and the actual
simulator code say it was bit 12.  Regardless, we don't use MI_FLUSH,
or try to enable it any more.

Signed-off-by: Eric Anholt e...@anholt.net
   
   I'd like to amend this with the following (on this patch instead of the
   other, so that ppl actually can find it with git blame):
   
   Furthermore actually setting bit12 results in gpu hangs both on snb and
   ivb. Ben Widawsky discovered a ppt that claims that both bit12 and bit11
   must be set, but that doesn't help either. And last but not least,
   MI_FLUSH seems to work regardless of the setting of these bits.
  
  I haven't seen bit12 hanging snb/ivb -- I only knew of it hanging ilk
  (since it doesn't exist there).  On my snb, running xvideo so that
  MI_FLUSHes are generated by the userland (I think -- I haven't caught
  them in cat i915_batchbuffers | intel_dump_decode -), with
  intel_reg_read 0x209c saying 0x1240, things are going fine.  Also with
  0x209c saying 0x240 (the result of this patch).
 
 The SNB Xv path, that is the code called by Gen6DisplayVideoTexture, 
 never used MI_FLUSH.

Ok, I've quickly tested this with intel_reg_write and installing older
userspace. Doesn't seem to blow up.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Fedora 16, kernel 3.2.0+, i5 2500K, Z68 system freeze

2012-01-25 Thread Chris Wilson 
On Wed, 25 Jan 2012 12:29:05 +1100, Graeme Russ graeme.r...@gmail.com wrote:
 Hi All,
 
 I've been hunting around for information on how to help debug the issue
 I'm having - Hopefully someone here can help
 
 My setup is:
  - ASRock Z68 Pro3 Gen3 motherboard
  - i5 2500K CPU
  - Fedora 16
  - Vanilla 3.2.0+ kernel (commt ccb19d263fd1c9e34948e2158c53eacbff369344)

We've had a second report for ASRock Z68 Pro3,
https://bugs.freedesktop.org/show_bug.cgi?id=44992. There he mentions that
setting the iGPU voltage to fixed (1.25V) rather than auto in the BIOS
fixes the system hangs.
-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] Fedora 16, kernel 3.2.0+, i5 2500K, Z68 system freeze

2012-01-25 Thread Graeme Russ 
On 01/25/2012 10:31 PM, Chris Wilson wrote:
 On Wed, 25 Jan 2012 12:29:05 +1100, Graeme Russ graeme.r...@gmail.com wrote:
 Hi All,

 I've been hunting around for information on how to help debug the issue
 I'm having - Hopefully someone here can help

 My setup is:
  - ASRock Z68 Pro3 Gen3 motherboard
  - i5 2500K CPU
  - Fedora 16
  - Vanilla 3.2.0+ kernel (commt ccb19d263fd1c9e34948e2158c53eacbff369344)
 
 We've had a second report for ASRock Z68 Pro3,
 https://bugs.freedesktop.org/show_bug.cgi?id=44992. There he mentions that
 setting the iGPU voltage to fixed (1.25V) rather than auto in the BIOS
 fixes the system hangs.

The MB is a ASRock Z68 Pro3-M, mine is a ASRock Z68 Pro3 Gen3

Also see https://bugzilla.kernel.org/show_bug.cgi?id=42597

quote
I've recently had a problem with an AsRock mainboard. As it turned out,
their voltage control of the integrated GPU was buggy. Setting the voltage
to fixed 1.5V instead of auto resolved the issue.
/quote

I think this is the same person

I don't know about the ASRock Z68 Pro3-M, but the Gen3 has a EUFI BIOS and
I cannot find an explicit GPU voltage setting. My options are:

CPU Core Voltage Offset -100mV - +500mV
IGPU Voltage Offset -100mV - +500mV
DRAM Voltage 1.201V - 1.8V
PCH Voltage 0.780V - 1.646V
CPU PLL Voltage 1.548V - 2.310V
VTT Voltage 0.768V - 1.634V
VCCSA Voltage 0.925V - 1.200V

I have already update to the latest BIOS (1.20)

Regards,

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

Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working

2012-01-25 Thread Peter Ross 
On Wed, Jan 25, 2012 at 02:03:30AM +0100, Alfonso Fiore wrote:
 Hi Angela,
 
 did you try with the latest patches from Peter?
 
 Peter: any idea for a next step since Angela still experienced the bug?

The next step would be to install Microsoft Windows and the Intel display
driver, switch to 1080i mode, and perform a register dump. Microsoft was
offering a trial version for download, that'd probably be suffice for testing.
The tool to perform register dumps on windows is called 'RW Everything'
(http://jacky5488.myweb.hinet.net/). I can describe the process if you're
up for this.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

[Intel-gfx] [PATCH] drm/i915: fixup forcewake spinlock fallout in drpc debugfs function

2012-01-25 Thread Daniel Vetter 
My forcewake spinlock patches have a functional conflict with Ben
Widawsky's gen6 drpc support for debugfs. Result was a benign warning
about trying to read an non-atomic variabla with atomic_read.

Note that the entire check is racy anyway and purely informational.
Also update it to reflect the forcewake voodoo changes, the kernel can
now also hold onto a forcewake reference for longer times.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b014542..0c89e77 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1076,6 +1076,7 @@ static int gen6_drpc_info(struct seq_file *m)
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
u32 rpmodectl1, gt_core_status, rcctl1;
+   unsigned forcewake_count;
int count=0, ret;
 
 
@@ -1083,9 +1084,13 @@ static int gen6_drpc_info(struct seq_file *m)
if (ret)
return ret;
 
-   if (atomic_read(dev_priv-forcewake_count)) {
-   seq_printf(m, RC information inaccurate because userspace 
- holds a reference \n);
+   spin_lock_irq(dev_priv-gt_lock);
+   forcewake_count = dev_priv-forcewake_count;
+   spin_unlock_irq(dev_priv-gt_lock);
+
+   if (forcewake_count) {
+   seq_printf(m, RC information inaccurate because somebody 
+ holds a forcewake reference \n);
} else {
/* NB: we cannot use forcewake, else we read the wrong values */
while (count++  50  (I915_READ_NOTRACE(FORCEWAKE_ACK)  1))
-- 
1.7.7.5

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

[Intel-gfx] [PATCH 2/4] drm/i915: fixup seqno allocation logic for lazy_request

2012-01-25 Thread Daniel Vetter 
Currently we reserve seqnos only when we emit the request to the ring
(by bumping dev_priv-next_seqno), but start using it much earlier for
ring-oustanding_lazy_request. When 2 threads compete for the gpu and
run on two different rings (e.g. ddx on blitter vs. compositor)
hilarity ensued, especially when we get constantly interrupted while
reserving buffers.

Breakage seems to have been introduced in

commit 6f392d548658a17600da7faaf8a5df25ee5f01f6
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Sat Aug 7 11:01:22 2010 +0100

drm/i915: Use a common seqno for all rings.

This patch fixes up the seqno reservation logic by moving it into
i915_gem_next_request_seqno. The ring-add_request functions now
superflously still return the new seqno through a pointer, that will
be refactored in the next patch.

v2: Keep i915_gem_get_seqno (but move it to i915_gem.c) to make it
clear that we only have one seqno counter for all rings. Suggested by
Chris Wilson.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181
Tested-by: Nicolas Kalkhof nkalkhof()at()web.de
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h |7 +--
 drivers/gpu/drm/i915/i915_gem.c |   23 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c |   24 
 3 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 32737a3..2f102ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1159,12 +1159,7 @@ i915_seqno_passed(uint32_t seq1, uint32_t seq2)
return (int32_t)(seq1 - seq2) = 0;
 }
 
-static inline u32
-i915_gem_next_request_seqno(struct intel_ring_buffer *ring)
-{
-   drm_i915_private_t *dev_priv = ring-dev-dev_private;
-   return ring-outstanding_lazy_request = dev_priv-next_seqno;
-}
+u32 i915_gem_next_request_seqno(struct intel_ring_buffer *ring);
 
 int __must_check i915_gem_object_get_fence(struct drm_i915_gem_object *obj,
   struct intel_ring_buffer *pipelined);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8f01c3d..dc8e45f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1647,6 +1647,28 @@ i915_gem_process_flushing_list(struct intel_ring_buffer 
*ring,
}
 }
 
+static u32
+i915_gem_get_seqno(struct drm_device *dev)
+{
+   drm_i915_private_t *dev_priv = dev-dev_private;
+   u32 seqno = dev_priv-next_seqno;
+
+   /* reserve 0 for non-seqno */
+   if (++dev_priv-next_seqno == 0)
+   dev_priv-next_seqno = 1;
+
+   return seqno;
+}
+
+u32
+i915_gem_next_request_seqno(struct intel_ring_buffer *ring)
+{
+   if (ring-outstanding_lazy_request == 0)
+   ring-outstanding_lazy_request = i915_gem_get_seqno(ring-dev);
+
+   return ring-outstanding_lazy_request;
+}
+
 int
 i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
@@ -1658,6 +1680,7 @@ i915_add_request(struct intel_ring_buffer *ring,
int ret;
 
BUG_ON(request == NULL);
+   seqno = i915_gem_next_request_seqno(ring);
 
ret = ring-add_request(ring, seqno);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1ab842c..bc0d791 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -52,20 +52,6 @@ static inline int ring_space(struct intel_ring_buffer *ring)
return space;
 }
 
-static u32 i915_gem_get_seqno(struct drm_device *dev)
-{
-   drm_i915_private_t *dev_priv = dev-dev_private;
-   u32 seqno;
-
-   seqno = dev_priv-next_seqno;
-
-   /* reserve 0 for non-seqno */
-   if (++dev_priv-next_seqno == 0)
-   dev_priv-next_seqno = 1;
-
-   return seqno;
-}
-
 static int
 render_ring_flush(struct intel_ring_buffer *ring,
  u32   invalidate_domains,
@@ -467,7 +453,7 @@ gen6_add_request(struct intel_ring_buffer *ring,
mbox1_reg = ring-signal_mbox[0];
mbox2_reg = ring-signal_mbox[1];
 
-   *seqno = i915_gem_get_seqno(ring-dev);
+   *seqno = ring-outstanding_lazy_request;
 
update_mboxes(ring, *seqno, mbox1_reg);
update_mboxes(ring, *seqno, mbox2_reg);
@@ -565,8 +551,7 @@ static int
 pc_render_add_request(struct intel_ring_buffer *ring,
  u32 *result)
 {
-   struct drm_device *dev = ring-dev;
-   u32 seqno = i915_gem_get_seqno(dev);
+   u32 seqno = ring-outstanding_lazy_request;
struct pipe_control *pc = ring-private;
u32 scratch_addr = pc-gtt_offset + 128;
int ret;
@@ -617,8 +602,7 @@ static int
 render_ring_add_request(struct intel_ring_buffer *ring,
u32 *result)
 {
-   struct drm_device *dev = ring-dev;
-   u32 seqno =

[Intel-gfx] [PATCH] drm/i915: adjust ring-add_request to no longer pass back the seqno

2012-01-25 Thread Daniel Vetter 
The seqno is now allocated ahead of calling ring-add_request, so this
is just unncessery and can be removed.

v2: Rebased on top of the changed fix patch.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_gem.c |2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   24 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h |2 +-
 3 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dc8e45f..a72100c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1682,7 +1682,7 @@ i915_add_request(struct intel_ring_buffer *ring,
BUG_ON(request == NULL);
seqno = i915_gem_next_request_seqno(ring);
 
-   ret = ring-add_request(ring, seqno);
+   ret = ring-add_request(ring, seqno);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 7a107c9..117004f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -440,7 +440,7 @@ update_mboxes(struct intel_ring_buffer *ring,
  */
 static int
 gen6_add_request(struct intel_ring_buffer *ring,
-u32 *seqno)
+u32 seqno)
 {
u32 mbox1_reg;
u32 mbox2_reg;
@@ -453,13 +453,11 @@ gen6_add_request(struct intel_ring_buffer *ring,
mbox1_reg = ring-signal_mbox[0];
mbox2_reg = ring-signal_mbox[1];
 
-   *seqno = i915_gem_next_request_seqno(ring);
-
-   update_mboxes(ring, *seqno, mbox1_reg);
-   update_mboxes(ring, *seqno, mbox2_reg);
+   update_mboxes(ring, seqno, mbox1_reg);
+   update_mboxes(ring, seqno, mbox2_reg);
intel_ring_emit(ring, MI_STORE_DWORD_INDEX);
intel_ring_emit(ring, I915_GEM_HWS_INDEX  MI_STORE_DWORD_INDEX_SHIFT);
-   intel_ring_emit(ring, *seqno);
+   intel_ring_emit(ring, seqno);
intel_ring_emit(ring, MI_USER_INTERRUPT);
intel_ring_advance(ring);
 
@@ -549,9 +547,8 @@ do {
\
 
 static int
 pc_render_add_request(struct intel_ring_buffer *ring,
- u32 *result)
+ u32 seqno)
 {
-   u32 seqno = i915_gem_next_request_seqno(ring);
struct pipe_control *pc = ring-private;
u32 scratch_addr = pc-gtt_offset + 128;
int ret;
@@ -594,15 +591,13 @@ pc_render_add_request(struct intel_ring_buffer *ring,
intel_ring_emit(ring, 0);
intel_ring_advance(ring);
 
-   *result = seqno;
return 0;
 }
 
 static int
 render_ring_add_request(struct intel_ring_buffer *ring,
-   u32 *result)
+   u32 seqno)
 {
-   u32 seqno = i915_gem_next_request_seqno(ring);
int ret;
 
ret = intel_ring_begin(ring, 4);
@@ -615,7 +610,6 @@ render_ring_add_request(struct intel_ring_buffer *ring,
intel_ring_emit(ring, MI_USER_INTERRUPT);
intel_ring_advance(ring);
 
-   *result = seqno;
return 0;
 }
 
@@ -767,24 +761,20 @@ bsd_ring_flush(struct intel_ring_buffer *ring,
 
 static int
 ring_add_request(struct intel_ring_buffer *ring,
-u32 *result)
+u32 seqno)
 {
-   u32 seqno;
int ret;
 
ret = intel_ring_begin(ring, 4);
if (ret)
return ret;
 
-   seqno = i915_gem_next_request_seqno(ring);
-
intel_ring_emit(ring, MI_STORE_DWORD_INDEX);
intel_ring_emit(ring, I915_GEM_HWS_INDEX  MI_STORE_DWORD_INDEX_SHIFT);
intel_ring_emit(ring, seqno);
intel_ring_emit(ring, MI_USER_INTERRUPT);
intel_ring_advance(ring);
 
-   *result = seqno;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 68281c9..1638f32 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -70,7 +70,7 @@ struct  intel_ring_buffer {
  u32   invalidate_domains,
  u32   flush_domains);
int (*add_request)(struct intel_ring_buffer *ring,
-  u32 *seqno);
+  u32 seqno);
u32 (*get_seqno)(struct intel_ring_buffer *ring);
int (*dispatch_execbuffer)(struct intel_ring_buffer *ring,
   u32 offset, u32 length);
-- 
1.7.7.5

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Correct the bit number for the MI_FLUSH_ENABLE.

2012-01-25 Thread Eric Anholt 
On Wed, 25 Jan 2012 09:57:58 +, Chris Wilson ch...@chris-wilson.co.uk 
wrote:
 On Tue, 24 Jan 2012 18:55:53 -0800, Eric Anholt e...@anholt.net wrote:
  On Sat, 21 Jan 2012 17:36:13 +0100, Daniel Vetter dan...@ffwll.ch wrote:
   On Thu, Jan 19, 2012 at 10:50:06AM -0800, Eric Anholt wrote:
Older specs claimed this was bit 11, but newer specs and the actual
simulator code say it was bit 12.  Regardless, we don't use MI_FLUSH,
or try to enable it any more.

Signed-off-by: Eric Anholt e...@anholt.net
   
   I'd like to amend this with the following (on this patch instead of the
   other, so that ppl actually can find it with git blame):
   
   Furthermore actually setting bit12 results in gpu hangs both on snb and
   ivb. Ben Widawsky discovered a ppt that claims that both bit12 and bit11
   must be set, but that doesn't help either. And last but not least,
   MI_FLUSH seems to work regardless of the setting of these bits.
  
  I haven't seen bit12 hanging snb/ivb -- I only knew of it hanging ilk
  (since it doesn't exist there).  On my snb, running xvideo so that
  MI_FLUSHes are generated by the userland (I think -- I haven't caught
  them in cat i915_batchbuffers | intel_dump_decode -), with
  intel_reg_read 0x209c saying 0x1240, things are going fine.  Also with
  0x209c saying 0x240 (the result of this patch).
 
 The SNB Xv path, that is the code called by Gen6DisplayVideoTexture, 
 never used MI_FLUSH.

Oops.  Not sure why I remembered confirming that that code still
MI_FLUSHed on newer chipsets.


pgpFBxk39uuN2.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Working on 3.0.0-12] RGB Problem with Intel i915 driver, i3 2010T, RGB color output over HDMI

2012-01-25 Thread paulo louro 

Hello all again,
This problem is new to kernel 3.2.0-rc6, here is the diff between the bad and 
good register dump. I tried to correct the register but without any luck...
Marked with  is not working kernel 3.2.0Marked with  works. kernel 3.0.0-12 / 
also works fine in LiveCD of Ubuntu 11.10

GEN6_INSTDONE_1: 0xGEN6_INSTDONE_2: 
0x---GEN6_INSTDONE_1: 0xfffe
GEN6_INSTDONE_2: 0x31c31   DSPACNTR: 0xd8004000 
(enabled)---   DSPACNTR: 0xd8004400 (enabled)34c34
   DSPASURF: 0x00064000---   DSPASURF: 
0x0665d00070c70   PCH_DREF_CONTROL: 0x0400 (cpu source 
disable, ssc_source disable, nonspread_source enable, superspread_source 
disable, ssc4_mode downspread, ssc1 disable, ssc4 disable)---   
PCH_DREF_CONTROL: 0x1400 (cpu source disable, ssc_source enable, 
nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 
disable, ssc4 disable)79,80c79,80   PCH_FPA0: 0x00021007 
(n = 2, m1 = 16, m2 = 7)   PCH_FPA1: 0x00021007 (n = 2, m1 
= 16, m2 = 7)---   PCH_FPA0: 0x00c21007 (n = 2, m1 = 16, 
m2 = 7)   PCH_FPA1: 0x00c21007 (n = 2, m1 = 16, m2 = 7)
From: paulo_lo...@msn.com
To: intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] RGB Problem with Intel i915 driver, i3 2010T, RGB 
color output over HDMI
Date: Tue, 24 Jan 2012 15:24:04 +







Hello all,
This e-mail is a continuation of my previews one regarding HDMI modeline output 
problems. So far with the help of Rodrigo Vivi i have manage to output the 
1920x1080p@60hz mode over HDMI to my AV receiver. (To fix my previews problem i 
inserted the EDID frame directly inside drm_edid.c file. So i dont read EDID 
from the AV i2c bus anymore. So the mode is always set correctly.)
The issue now is that the AV reports that the signal is not in RGB mode and the 
image shows some strange colors, specially on the white color (showing like 
greens).
Does any one has any idea if this is a problem on the EDID or inside drm/i915? 
All comments and help are very appreciated.-- Paulo Louro


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

[Intel-gfx] [PULL] drm-intel-fixes

2012-01-25 Thread Keith Packard 

A bunch of patches which fix IVB-specific troubles:

 * A selection of code which was labeled for SNB, but needs to be run on
   IVB as well.

 * A replacement for the quick-hack IVB lost-IRQ issue. This appears to
   help on SNB as well, but for now it's only enabled on IVB in case we
   discover problems with it.
   
 * Fix some 3-pipe issues

And, a couple of minor mode setting fixes.

The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:

  Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-fixes

Daniel Vetter (7):
  drm/i915: convert force_wake_get to func pointer in the gpu reset code
  drm/i915: protect force_wake_(get|put) with the gt_lock
  drm/i915: paper over missed irq issues with force wake voodoo
  drm/i915: rip out the HWSTAM missed irq workaround
  drm/i915: allow userspace forcewake references also on gen7
  drm/i915: debugfs: show semaphore registers also on gen7
  drm/i915: fixup forcewake spinlock fallout in drpc debugfs function

Duncan Laurie (1):
  CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB

Eric Anholt (3):
  drm/i915: Print debugfs object list sizes in KiB instead of bytes.
  drm/i915: Correct debugfs printout for RC1e.
  drm/i915: Re-enable gen7 RC6 and GPU turbo after resume.

Eugeni Dodonov (2):
  drm/i915: simplify pipe checking
  drm/i915: handle 3rd pipe

Jesse Barnes (2):
  drm/i915: mask transcoder select bits before setting them on LVDS
  drm/i915: sprite init failure on pre-SNB is not a failure

Joel Sass (1):
  drm/i915: Add Clientron E830 to the ignore LVDS list

Keith Packard (5):
  Merge branch 'drm-intel-next-fixes' into drm-intel-fixes
  drm/i915: Move reset forcewake processing to gen6_do_reset
  drm/i915: Hold gt_lock during reset
  drm/i915: Hold gt_lock across forcewake register reads
  Revert drm/i915: Work around gen7 BLT ring synchronization issues.

Paulo Zanoni (1):
  drm/i915/sdvo: always set positive sync polarity

Rodrigo Vivi (2):
  drm/i915: Fix TV Out refresh rate.
  drm/i915: Removing TV Out modes.

Rohit Jain (1):
  drm/i915: VBT Parser cleanup for eDP block

 drivers/gpu/drm/i915/i915_debugfs.c |   31 +---
 drivers/gpu/drm/i915/i915_dma.c |1 +
 drivers/gpu/drm/i915/i915_drv.c |   56 ++---
 drivers/gpu/drm/i915/i915_drv.h |   10 ++-
 drivers/gpu/drm/i915/i915_irq.c |3 +-
 drivers/gpu/drm/i915/i915_suspend.c |   11 ++-
 drivers/gpu/drm/i915/intel_bios.h   |6 +-
 drivers/gpu/drm/i915/intel_crt.c|   23 +
 drivers/gpu/drm/i915/intel_display.c|   22 +++---
 drivers/gpu/drm/i915/intel_lvds.c   |8 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c |   41 ++
 drivers/gpu/drm/i915/intel_sdvo.c   |8 +-
 drivers/gpu/drm/i915/intel_sprite.c |8 +--
 drivers/gpu/drm/i915/intel_tv.c |  138 ++-
 14 files changed, 167 insertions(+), 199 deletions(-)


-- 
keith.pack...@intel.com


pgpLcJ7U0RBD6.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

2012-01-25 Thread Jesse Barnes 
On Wed, 25 Jan 2012 08:16:25 -0800
Keith Packard kei...@keithp.com wrote:

 It is never correct to use intel_crtc-bpp in intel_dp_link_required,
 so instead pass an explicit bpp in to this function. This patch
 only supports 18bpp and 24bpp modes, which means that 10bpc modes will
 be computed incorrectly. Fixing that will require more extensive
 changes, and so must be addressed separately from this bugfix.
 
 intel_dp_link_required is called from intel_dp_mode_valid and
 intel_dp_mode_fixup.
 
 * intel_dp_mode_valid is called to list supported modes; in this case,
   the current crtc values cannot be relevant as the modes in question
   may never be selected. Thus, using intel_crtc-bpp is never right.
 
 * intel_dp_mode_fixup is called during mode setting, but it is run
   well before ironlake_crtc_mode_set is called to set intel_crtc-bpp,
   so using intel_crtc-bpp in this path can only ever get a stale
   value.

Yeah, looks like I got this wrong when I added the pipe bpp field.
Wonder if there's a good way to catch this sort of bug with an assert
so we don't get the order mixed up again...

The big downside here is that we'll be very pessimistic about the link
bw requirements for say 16 or 8bpp modes.

I see you have another patch to address some of this, but I wonder if
we have enough info to calculate the bpp at prepare time so it's set
early on for use by both the crtc and encoder code?

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

2012-01-25 Thread Keith Packard 
On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes jbar...@virtuousgeek.org 
wrote:

 Yeah, looks like I got this wrong when I added the pipe bpp field.
 Wonder if there's a good way to catch this sort of bug with an assert
 so we don't get the order mixed up again...

Ideally, we'd figure out a way to compute this only once. I think the
only relevant piece of data here is what bpc the pipe should run at, and
that can be computed at any time during the mode set. We'd then be able
to compare the pipe bpc with the frame buffer bpp to decide when to
dither in the crtc mode set code.

 The big downside here is that we'll be very pessimistic about the link
 bw requirements for say 16 or 8bpp modes.

Right, with this patch, we'll choose link parameters capable of
supporting 8bpc, even for 16bpp video modes. Note that 8bpp video modes
need 8bpc links as they have colormaps with 8bpc data in them.

 I see you have another patch to address some of this, but I wonder if
 we have enough info to calculate the bpp at prepare time so it's set
 early on for use by both the crtc and encoder code?

fixup gets exactly the same info as mode set, so it should end up with
exactly the same resulting bpc, which will set the link bandwidth to
support 6bpc mode if that's all that is needed.

One problem with the patch is that the pre-PCH mode set path doesn't use
intel_choose_pipe_bpp_dither, so the condition for 6bpc mode is
duplicated in i9xx_crtc_mode_set and intel_dp_mode_fixup.

If crtc-fixup was called before encoder-fixup, we could have computed
bpp in the crtc-fixup function and then used it in encoder-fixup.

Alternatively, crtc-fixup could call into the DP code to set the
link_bw, lane_count and adjusted_mode-clock values after it sets the
bpp, but that seems to break the abstraction even more.

-- 
keith.pack...@intel.com


pgpk4RZfQQ9fB.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

2012-01-25 Thread Daniel Vetter 
On Wed, Jan 25, 2012 at 01:17:51PM -0800, Keith Packard wrote:
 On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes jbar...@virtuousgeek.org 
 wrote:
 
  Yeah, looks like I got this wrong when I added the pipe bpp field.
  Wonder if there's a good way to catch this sort of bug with an assert
  so we don't get the order mixed up again...
 
 Ideally, we'd figure out a way to compute this only once. I think the
 only relevant piece of data here is what bpc the pipe should run at, and
 that can be computed at any time during the mode set. We'd then be able
 to compare the pipe bpc with the frame buffer bpp to decide when to
 dither in the crtc mode set code.

I think we could compute this in crtc-mode_fixup (crtc-prepare doesn't
have the mode and adjusted_mode arguments). We could then store the
computed bpc and dithering in one of the private fields. We'd still have
to loop over all encoders, but alas ...

  The big downside here is that we'll be very pessimistic about the link
  bw requirements for say 16 or 8bpp modes.
 
 Right, with this patch, we'll choose link parameters capable of
 supporting 8bpc, even for 16bpp video modes. Note that 8bpp video modes
 need 8bpc links as they have colormaps with 8bpc data in them.

Afaics we'll still correctly fall back to 6bpc (undithered for 16bpp
obviously) and hence things should keep on working.

  I see you have another patch to address some of this, but I wonder if
  we have enough info to calculate the bpp at prepare time so it's set
  early on for use by both the crtc and encoder code?
 
 fixup gets exactly the same info as mode set, so it should end up with
 exactly the same resulting bpc, which will set the link bandwidth to
 support 6bpc mode if that's all that is needed.
 
 One problem with the patch is that the pre-PCH mode set path doesn't use
 intel_choose_pipe_bpp_dither, so the condition for 6bpc mode is
 duplicated in i9xx_crtc_mode_set and intel_dp_mode_fixup.
 
 If crtc-fixup was called before encoder-fixup, we could have computed
 bpp in the crtc-fixup function and then used it in encoder-fixup.
 
 Alternatively, crtc-fixup could call into the DP code to set the
 link_bw, lane_count and adjusted_mode-clock values after it sets the
 bpp, but that seems to break the abstraction even more.

Yeah, there are a few rough corners with the bpc computation in patch 2.
I'll try to throw around a few ideas that crossed my mind while reading
through it in a reply there.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Select DP BPC at mode set, rather than mode validate

2012-01-25 Thread Daniel Vetter 
On Wed, Jan 25, 2012 at 08:16:26AM -0800, Keith Packard wrote:
 The DP configuration must match the pipe configuration, and until mode
 set we don't know what BPC will be used. Delay all decisions about BPC
 until mode set, computing the target BPC in both intel_dp_mode_fixup
 and either i9xx_crtc_mode_set or ironlake_crtc_mode_set. It might be
 slightly better to compute this only once, but storing the value
 between those two calls would be a pain.
 
 Cc: Lubos Kolouch lubos.kolo...@gmail.com
 Cc: Adam Jackson a...@redhat.com
 Signed-off-by: Keith Packard kei...@keithp.com
 ---
  drivers/gpu/drm/i915/intel_display.c |   27 +---
  drivers/gpu/drm/i915/intel_dp.c  |   77 
 +++---
  drivers/gpu/drm/i915/intel_drv.h |6 ++-
  3 files changed, 78 insertions(+), 32 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index b3b51c4..d613676 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -4850,9 +4850,9 @@ static inline bool intel_panel_use_ssc(struct 
 drm_i915_private *dev_priv)
   * Dithering requirement (i.e. false if display bpc and pipe bpc match,
   * true if they don't match).
   */
 -static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
 -  unsigned int *pipe_bpp,
 -  struct drm_display_mode *mode)
 +bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
 +   unsigned int *pipe_bpp,
 +   struct drm_display_mode *mode)
  {
   struct drm_device *dev = crtc-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
 @@ -4883,13 +4883,13 @@ static bool intel_choose_pipe_bpp_dither(struct 
 drm_crtc *crtc,
   continue;
   }
  
 - if (intel_encoder-type == INTEL_OUTPUT_EDP) {
 - /* Use VBT settings if we have an eDP panel */
 - unsigned int edp_bpc = dev_priv-edp.bpp / 3;
 + if (intel_encoder-type == INTEL_OUTPUT_EDP ||
 + intel_encoder-type == INTEL_OUTPUT_DISPLAYPORT) {
 + unsigned int dp_bpc = 
 intel_dp_max_bpp(intel_encoder-base, mode);
  
 - if (edp_bpc  display_bpc) {
 - DRM_DEBUG_KMS(clamping display bpc (was %d) to 
 eDP (%d)\n, display_bpc, edp_bpc);
 - display_bpc = edp_bpc;
 + if (dp_bpc  display_bpc) {
 + DRM_DEBUG_KMS(clamping display bpc (was %d) to 
 DP (%d)\n, display_bpc, dp_bpc);
 + display_bpc = dp_bpc;
   }
   continue;
   }

I'm a bit unhappy how generic code in intel_display.c calls function out
of intel_dp.c. And choose_pipe_bpp_dither already has special cases for
quite a few other encoders ... Could we add an -adjust_bpc function to
intel_encoder to separate this in a cleaner fashion?

I know that this isn't really the only layering violation in
intel_display.c, but functions in that file have an uncanny ability to
grow without bounds ;-)

 @@ -4923,11 +4923,6 @@ static bool intel_choose_pipe_bpp_dither(struct 
 drm_crtc *crtc,
   }
   }
  
 - if (mode-private_flags  INTEL_MODE_DP_FORCE_6BPC) {
 - DRM_DEBUG_KMS(Dithering DP to 6bpc\n);
 - display_bpc = 6;
 - }
 -
   /*
* We could just drive the pipe at the highest bpc all the time and
* enable dithering as needed, but that costs bandwidth.  So choose
 @@ -4990,6 +4985,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
   int ret;
   u32 temp;
   u32 lvds_sync = 0;
 + int dp_max_bpp = 0;
  
   list_for_each_entry(encoder, mode_config-encoder_list, base.head) {
   if (encoder-base.crtc != crtc)
 @@ -5016,6 +5012,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
   break;
   case INTEL_OUTPUT_DISPLAYPORT:
   is_dp = true;
 + dp_max_bpp = intel_dp_max_bpp(encoder-base, mode);
   break;
   }
  
 @@ -5192,7 +5189,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
   /* default to 8bpc */
   pipeconf = ~(PIPECONF_BPP_MASK | PIPECONF_DITHER_EN);
   if (is_dp) {
 - if (mode-private_flags  INTEL_MODE_DP_FORCE_6BPC) {
 + if (dp_max_bpp = 18) {
   pipeconf |= PIPECONF_BPP_6 |
   PIPECONF_DITHER_EN |
   PIPECONF_DITHER_TYPE_SP;
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 94f860c..2482796 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -219,14 +219,51 @@ intel_dp_max_data_rate(int max_link_clock,

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

2012-01-25 Thread Keith Packard 
On Wed, 25 Jan 2012 22:50:55 +0100, Daniel Vetter dan...@ffwll.ch wrote:

 I think we could compute this in crtc-mode_fixup (crtc-prepare doesn't
 have the mode and adjusted_mode arguments). We could then store the
 computed bpc and dithering in one of the private fields. We'd still have
 to loop over all encoders, but alas ...

Alas, intel_crtc_mode_fixup is called *after* the intel_dp_mode_fixup. So,
we'd either need to change drm_crtc_helper, or have
intel_crtc_mode_fixup call down into intel_dp.c to set the link
parameters. In either case, ick.

 Afaics we'll still correctly fall back to 6bpc (undithered for 16bpp
 obviously) and hence things should keep on working.

Right, the problem is that the DP link parameters will be set to support
24bpp color, so we'll use a higher clock/lane-count than strictly
necessary as intel_dp_mode_fixup doesn't take the frame buffer format
into consideration when computing the link values.

 Yeah, there are a few rough corners with the bpc computation in patch 2.
 I'll try to throw around a few ideas that crossed my mind while reading
 through it in a reply there.

Thanks. I'm not happy with it either.

In short, I think we can (and should) apply the simple first patch to
drm-intel-fixes so that at least displays work consistently, and then
come up with a nicer patch that computes correct link parameters, and
also supports 10bpc formats.

-- 
keith.pack...@intel.com


pgpXJSBxJAAzP.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Select DP BPC at mode set, rather than mode validate

2012-01-25 Thread Keith Packard 
On Wed, 25 Jan 2012 23:11:00 +0100, Daniel Vetter dan...@ffwll.ch wrote:

 I'm a bit unhappy how generic code in intel_display.c calls function out
 of intel_dp.c. And choose_pipe_bpp_dither already has special cases for
 quite a few other encoders ... Could we add an -adjust_bpc function to
 intel_encoder to separate this in a cleaner fashion?

Yeah, seems quite reasonable.

I can't find any reason why the lane count and link bw values are set in
fixup_mode and not just in intel_dp_set_mode. If we moved that, we could
use the bpp value computed in intel_display.c.

There's a weird mixture of code in ironlake_crtc_mode_set where it calls
intel_edp_link_config and uses those values when setting the CPU M/N
values for non-PCH eDP panels. That would also need fixing.

 I know that this isn't really the only layering violation in
 intel_display.c, but functions in that file have an uncanny ability to
 grow without bounds ;-)

The more we clean things up, the easier fixing bugs is in the future.

 As you've already said in another mail, this PCH_SPLIT here looks a bit
 strange. Could we unify these two paths here a bit?

The simple way to unify them would be to use
intel_choose_pipe_bpp_dither from the i9xx_crtc_mode_set path. Perhaps
that function could codify the currently simplistic rule used on i9xx?

-- 
keith.pack...@intel.com


pgpPDoJY4lydW.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/2] infinite revusion patches v9999

2012-01-25 Thread Daniel Vetter 
On Wed, Jan 25, 2012 at 01:58:47PM -0800, Ben Widawsky wrote:
 On 01/24/2012 11:17 PM, Ben Widawsky wrote:
  Revusion.  Fail. null
  
  
 To clarify for posterity. I meant, I typo'd the subject of the
 cover-letter. The patches themselves should be good to merge.

I think we'll still see a v10k, current one fails the module symbol linker
check:

ERROR: i915_wait_request [drivers/gpu/drm/i915/i915.ko] undefined!

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

Re: [Intel-gfx] [PATCH 0/2] infinite revusion patches v9999

2012-01-25 Thread Ben Widawsky 
On 01/25/2012 03:31 PM, Daniel Vetter wrote:
 On Wed, Jan 25, 2012 at 01:58:47PM -0800, Ben Widawsky wrote:
 On 01/24/2012 11:17 PM, Ben Widawsky wrote:
 Revusion.  Fail. null


 To clarify for posterity. I meant, I typo'd the subject of the
 cover-letter. The patches themselves should be good to merge.
 
 I think we'll still see a v10k, current one fails the module symbol linker
 check:
 
 ERROR: i915_wait_request [drivers/gpu/drm/i915/i915.ko] undefined!
 
 Cheers, Daniel

Yeah it's a one line fix; coming up. I'm not sure how this rebase got
screwed up.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PROBLEM FOUND] Problem No HDMI when AV/TV in standby mode

2012-01-25 Thread paulo louro 

An update on this issue.
The registers VSYNCSHIFT PIPEACONF and TRANSACONF are been set to interlace 
mode at GRUB startup.
Test:
Boot computer with AV/TV in standby.Force GRUB to show menu selection.Turn on 
AV/TV and select PC HDMI while in GRUB menu.GRUB shows up with 1080i 50hz.
So is it GRUB setting the mode or the BIOS? This may happen to me since my AV 
is telling via EDID that the preferred mode is interlaced?

-- Paulo Louro

 Date: Tue, 24 Jan 2012 23:28:36 +0100
 From: dan...@ffwll.ch
 To: paulo_lo...@msn.com
 CC: intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PROBLEM FOUND] Problem No HDMI when AV/TV in 
 standby mode
 
 On Tue, Jan 24, 2012 at 10:03:57PM +, paulo louro wrote:
  
  Very ugly hack, 
  In file ---  intel_display.c function ---   
  ironlake_crtc_mode_set
  temp = I915_READ(_TRANSACONF);  I915_WRITE(_TRANSACONF,  temp  
  ~(721)); 
  I915_WRITE( 0x60028, 0x);   //VSYNCSHIFT_A— Vertical Sync Shift 
  Register   This register needs to be 0x for progressive mode 
  I915_WRITE(PIPECONF(pipe), pipeconf);   POSTING_READ(PIPECONF(pipe));
  In file ---  i915_reg.h #define   
  PIPECONF_INTERLACE_W_FIELD_INDICATION(7  21)  // ( 6  21)  
  Not sure why the PIPECONF MASK is 110 and not 111, from intel pdf 000b  
  Progressive Fetch / Progressive display / 001b PF-ID Progressive Fetch / 
  Interlaced display (HDMI) Requires panel fitting to be enabled 
 
 Wohoo, this is awesome. Can you maybe go right ahead and create a patch
 for this? Should be nothing more than checking for an interlaced mode and
 banging the right values into these registers ...
 
 Yours, Daniel
 -- 
 Daniel Vetter
 Mail: dan...@ffwll.ch
 Mobile: +41 (0)79 365 57 48
  ___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx