[git pull] i915 fixes

[git pull] i915 fixes

[Chris Wilson]

Dave, hopefully this completes the regression fixes for .38. There is
still some doubt over eDP, with 011b9910bdaf failing for Jim Gettys but
seeming required for other (currently working in .37) machines. And
despite Linus's intervention, backlight controls are still broken for some
users.

I've taken the conservative approach and disabled GPU semaphores by
default since that prevents one cause of hangs, even though I think it is
fixed by the earlier patch to prevent the FIFO overflow. The other patch
addresses a bug introduced by the combination of relaxed fencing and fence
pipelining infrastructure where to forgot to teardown a bound buffer if it
invalidated its new alignment constraints. Hopefully this will fix the
reported corruption for gen2/3 devices, though there is the possibility of
further underlying bugs.
-Chris

The following changes since commit fb62c00a6d8942775abc23d1621db1252e2d93d1:

  Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client (2011-03-05 10:43:22 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-fixes

Chris Wilson (4):
      Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
      drm/i915: Do not overflow the MMADDR write FIFO
      drm/i915: Disable GPU semaphores by default
      drm/i915: Rebind the buffer if its alignment constraints changes with tiling

 drivers/gpu/drm/i915/i915_debugfs.c        |    4 +-
 drivers/gpu/drm/i915/i915_drv.c            |   17 +++++++++++-
 drivers/gpu/drm/i915/i915_drv.h            |   24 ++++++++++++++----
 drivers/gpu/drm/i915/i915_gem.c            |    2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |    4 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c     |   37 +++++++++++++--------------
 drivers/gpu/drm/i915/i915_reg.h            |    2 +
 drivers/gpu/drm/i915/intel_display.c       |    8 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h    |   13 +++++----
 9 files changed, 70 insertions(+), 41 deletions(-)

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [git pull] i915 fixes

[Jim Gettys]

On 03/07/2011 07:00 AM, Chris Wilson wrote:
> Dave, hopefully this completes the regression fixes for .38. There is
> still some doubt over eDP, with 011b9910bdaf failing for Jim Gettys but
> seeming required for other (currently working in .37) machines. And
> despite Linus's intervention, backlight controls are still broken for some
> users.

FWIW:

The failure is not so common for me as to claim the change should not go 
in; and my work around is to suspend/resume the system again.

It's mostly niggling discomfort that there is still something about eDP 
we still don't understand...

The remaining question, of course, is whether the other fixes in the 
final release will continue the fine year long tradition of completely 
breaking my laptop in Linus' releases yet again ;-).
			- Jim


>
> I've taken the conservative approach and disabled GPU semaphores by
> default since that prevents one cause of hangs, even though I think it is
> fixed by the earlier patch to prevent the FIFO overflow. The other patch
> addresses a bug introduced by the combination of relaxed fencing and fence
> pipelining infrastructure where to forgot to teardown a bound buffer if it
> invalidated its new alignment constraints. Hopefully this will fix the
> reported corruption for gen2/3 devices, though there is the possibility of
> further underlying bugs.
> -Chris
>
> The following changes since commit fb62c00a6d8942775abc23d1621db1252e2d93d1:
>
>    Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client (2011-03-05 10:43:22 -0800)
>
> are available in the git repository at:
>
>    git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-fixes
>
> Chris Wilson (4):
>        Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
>        drm/i915: Do not overflow the MMADDR write FIFO
>        drm/i915: Disable GPU semaphores by default
>        drm/i915: Rebind the buffer if its alignment constraints changes with tiling
>
>   drivers/gpu/drm/i915/i915_debugfs.c        |    4 +-
>   drivers/gpu/drm/i915/i915_drv.c            |   17 +++++++++++-
>   drivers/gpu/drm/i915/i915_drv.h            |   24 ++++++++++++++----
>   drivers/gpu/drm/i915/i915_gem.c            |    2 +-
>   drivers/gpu/drm/i915/i915_gem_execbuffer.c |    4 +-
>   drivers/gpu/drm/i915/i915_gem_tiling.c     |   37 +++++++++++++--------------
>   drivers/gpu/drm/i915/i915_reg.h            |    2 +
>   drivers/gpu/drm/i915/intel_display.c       |    8 +++---
>   drivers/gpu/drm/i915/intel_ringbuffer.h    |   13 +++++----
>   9 files changed, 70 insertions(+), 41 deletions(-)
>

Re: [git pull] i915 fixes

[Dave Airlie]

On Tue, Mar 8, 2011 at 7:28 AM, Jim Gettys <jg@freedesktop.org> wrote:
> On 03/07/2011 07:00 AM, Chris Wilson wrote:
>>
>> Dave, hopefully this completes the regression fixes for .38. There is
>> still some doubt over eDP, with 011b9910bdaf failing for Jim Gettys but
>> seeming required for other (currently working in .37) machines. And
>> despite Linus's intervention, backlight controls are still broken for some
>> users.
>
> FWIW:
>
> The failure is not so common for me as to claim the change should not go in;
> and my work around is to suspend/resume the system again.

The thing with this patch is the only think I can think it could do
different on your system is timing related.

I'm a bit worried that I haven't seen much attempt at debugging this
from the Intel folks,
since its an 80 line patch it really wouldn't harm if they could
suggest something.

It might be interetsing to print out the is_pch_port to make sure it
never changes,
and also to see if bypassing the whole new code section added in to
turn off the CPU FDI and PCH FDI
helps at all.

Dave.

Re: [git pull] i915 fixes

[Jesse Barnes]

On Tue, 8 Mar 2011 14:00:45 +1000
Dave Airlie <airlied@gmail.com> wrote:

> On Tue, Mar 8, 2011 at 7:28 AM, Jim Gettys <jg@freedesktop.org> wrote:
> > On 03/07/2011 07:00 AM, Chris Wilson wrote:
> >>
> >> Dave, hopefully this completes the regression fixes for .38. There is
> >> still some doubt over eDP, with 011b9910bdaf failing for Jim Gettys but
> >> seeming required for other (currently working in .37) machines. And
> >> despite Linus's intervention, backlight controls are still broken for some
> >> users.
> >
> > FWIW:
> >
> > The failure is not so common for me as to claim the change should not go in;
> > and my work around is to suspend/resume the system again.
> 
> The thing with this patch is the only think I can think it could do
> different on your system is timing related.
> 
> I'm a bit worried that I haven't seen much attempt at debugging this
> from the Intel folks,
> since its an 80 line patch it really wouldn't harm if they could
> suggest something.
> 
> It might be interetsing to print out the is_pch_port to make sure it
> never changes,
> and also to see if bypassing the whole new code section added in to
> turn off the CPU FDI and PCH FDI
> helps at all.

I did check out the reg dumps, and the only theory I have is that we're
re-training DP at resume and coming up with a different vswing and/or
pre-emphasis, which could cause trouble.  The patch should only affect
things in a timing sense though like you say.  I'll try to find time
this week to come up with a patch to allow suspend/resume to use fast
link training, and see if that makes things better.

I don't think this is a regression relative to 2.6.37 though?  If not,
we probably shouldn't revert, since the patch referenced fixes so many
other machines...

Jesse

Re: [git pull] i915 fixes

[Jim Gettys]

On 03/07/2011 04:28 PM, Jim Gettys wrote:
> On 03/07/2011 07:00 AM, Chris Wilson wrote:
>> Dave, hopefully this completes the regression fixes for .38. There is
>> still some doubt over eDP, with 011b9910bdaf failing for Jim Gettys but
>> seeming required for other (currently working in .37) machines. And
>> despite Linus's intervention, backlight controls are still broken for
>> some
>> users.
>
> FWIW:
>
> The failure is not so common for me as to claim the change should not go
> in; and my work around is to suspend/resume the system again.
>
> It's mostly niggling discomfort that there is still something about eDP
> we still don't understand...
>
> The remaining question, of course, is whether the other fixes in the
> final release will continue the fine year long tradition of completely
> breaking my laptop in Linus' releases yet again ;-).

Well, Chris' tree with the last set of patches works about the same as 
Linus' rc7; still exhibits the flashing bug, but suspending again can 
get it to go away.  So maybe we can avoid the completely broken Linus 
release this time (knock on wooden head); certainly we're well beyond 
the previous state where installation required serious gymnastics.
			- Jim


>
>>
>> I've taken the conservative approach and disabled GPU semaphores by
>> default since that prevents one cause of hangs, even though I think it is
>> fixed by the earlier patch to prevent the FIFO overflow. The other patch
>> addresses a bug introduced by the combination of relaxed fencing and
>> fence
>> pipelining infrastructure where to forgot to teardown a bound buffer
>> if it
>> invalidated its new alignment constraints. Hopefully this will fix the
>> reported corruption for gen2/3 devices, though there is the
>> possibility of
>> further underlying bugs.
>> -Chris
>>
>> The following changes since commit
>> fb62c00a6d8942775abc23d1621db1252e2d93d1:
>>
>> Merge branch 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
>> (2011-03-05 10:43:22 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git
>> drm-intel-fixes
>>
>> Chris Wilson (4):
>> Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
>> drm/i915: Do not overflow the MMADDR write FIFO
>> drm/i915: Disable GPU semaphores by default
>> drm/i915: Rebind the buffer if its alignment constraints changes with
>> tiling
>>
>> drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
>> drivers/gpu/drm/i915/i915_drv.c | 17 +++++++++++-
>> drivers/gpu/drm/i915/i915_drv.h | 24 ++++++++++++++----
>> drivers/gpu/drm/i915/i915_gem.c | 2 +-
>> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
>> drivers/gpu/drm/i915/i915_gem_tiling.c | 37 +++++++++++++--------------
>> drivers/gpu/drm/i915/i915_reg.h | 2 +
>> drivers/gpu/drm/i915/intel_display.c | 8 +++---
>> drivers/gpu/drm/i915/intel_ringbuffer.h | 13 +++++----
>> 9 files changed, 70 insertions(+), 41 deletions(-)
>>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

Re: [git pull] i915 fixes

[Dave Airlie]

On Tue, Mar 8, 2011 at 2:08 PM, Jim Gettys <jg@freedesktop.org> wrote:
> On 03/07/2011 04:28 PM, Jim Gettys wrote:
>>
>> On 03/07/2011 07:00 AM, Chris Wilson wrote:
>>>
>>> Dave, hopefully this completes the regression fixes for .38. There is
>>> still some doubt over eDP, with 011b9910bdaf failing for Jim Gettys but
>>> seeming required for other (currently working in .37) machines. And
>>> despite Linus's intervention, backlight controls are still broken for
>>> some
>>> users.
>>
>> FWIW:
>>
>> The failure is not so common for me as to claim the change should not go
>> in; and my work around is to suspend/resume the system again.
>>
>> It's mostly niggling discomfort that there is still something about eDP
>> we still don't understand...
>>
>> The remaining question, of course, is whether the other fixes in the
>> final release will continue the fine year long tradition of completely
>> breaking my laptop in Linus' releases yet again ;-).
>
> Well, Chris' tree with the last set of patches works about the same as
> Linus' rc7; still exhibits the flashing bug, but suspending again can get it
> to go away.  So maybe we can avoid the completely broken Linus release this
> time (knock on wooden head); certainly we're well beyond the previous state
> where installation required serious gymnastics.

drm-intel-next on my HP laptop fails on boot with some GMBUS error and I have
to s/r to see gdm on it ;-)

We have a week more with rc8 so maybe we can get some movement or ideas.

Dave.

Re: [git pull] i915 fixes

[Chris Wilson]

On Tue, 8 Mar 2011 17:27:46 +1000, Dave Airlie <airlied@gmail.com> wrote:
> drm-intel-next on my HP laptop fails on boot with some GMBUS error and I have
> to s/r to see gdm on it ;-)
> 
> We have a week more with rc8 so maybe we can get some movement or ideas.

Unfortunately, the US team, Jesse included, will be preoccupied by the
same event as Linus. Maybe they'll find time to fix a bug or two, but I
doubt Jesse managed to take his full array of laptops. ;-)

Hmm, that leaves me...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] i915 fixes

[Chris Wilson]

As I don't anticipate any more fixes in the near future for 2.6.38, I
thought I may as well send this single patch to prevent 965G[M] from
using a status page above 4GiB, in a timely fashion.
-Chris

The following changes since commit dd9c1549edef02290edced639f67b54a25abbe0e:

  Linux 2.6.38-rc7 (2011-03-01 13:55:12 -0800)

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

Jan Niehusmann (1):
      drm/i915: fix memory corruption with GM965 and >4GB RAM

 drivers/gpu/drm/i915/i915_dma.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] i915 fixes

[Chris Wilson]

Dave, time has flown by, so, against all evidence to the contrary, I must
have been enjoying myself.

An assortment of regression fixes are still trickling in; the sampler for
tiled surfaces on gen2 being more nasty than expected, interrupts during
fdi training were less than useful and Jesse assures me that this is an
eDP fix of the utmost importance.

Given the nature of those fixes, including the cache-coherency fix for
gen2 looks a bit odd, but it's the first major breakthrough we've had in
fixing their stability problems. (Of course, now the bugs have just
shifted elsewhere... And 830GM/845G are still in need of another miracle.)
-Chris


The following changes since commit ef3242859fae47e728b50b7ce3d17b201a71779a:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 (2011-02-23 16:02:00 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-fixes

Chris Wilson (2):
      drm/i915: Ignore a hung GPU when flushing the framebuffer prior to a switch
      agp/intel: Experiment with a 855GM GWB bit

Daniel Vetter (1):
      drm/i915: fix corruptions on i8xx due to relaxed fencing

Jesse Barnes (2):
      drm/i915: don't enable FDI & transcoder interrupts after all
      drm/i915: skip FDI & PCH enabling for DP_A

 drivers/char/agp/intel-agp.h           |    1 +
 drivers/char/agp/intel-gtt.c           |   56 +++++++------------
 drivers/gpu/drm/i915/i915_gem_tiling.c |   16 +++++-
 drivers/gpu/drm/i915/i915_irq.c        |    6 +-
 drivers/gpu/drm/i915/intel_display.c   |   93 +++++++++++++++++++++++++++++---
 5 files changed, 126 insertions(+), 46 deletions(-)

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [git pull] i915 fixes

[Jesse Barnes]

On Thu, 24 Feb 2011 01:09:47 +0000
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> Dave, time has flown by, so, against all evidence to the contrary, I must
> have been enjoying myself.
> 
> An assortment of regression fixes are still trickling in; the sampler for
> tiled surfaces on gen2 being more nasty than expected, interrupts during
> fdi training were less than useful and Jesse assures me that this is an
> eDP fix of the utmost importance.

Definitely fixes things for many people, distros have been grabbing
it.  But I'm still deeply afraid of this code; it's proven very fragile
in the past.  At least the stuff in -next cleans up this area some so
problems should be easier to find in the future.

-- 
Jesse Barnes, Intel Open Source Technology Center

[git pull] i915 fixes

[Chris Wilson]

Dave, a few more days have passed and we have a fresh batch of
regression fixes.

The patch that is most notable is one for its absence:

commit 25ed6eb15ebc4472fb0e473666c0ef3bba87097f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Dec 22 11:37:09 2010 +0000

    agp/intel: Experiment with a 855GM GWB bit

is still sitting on drm-intel-staging just begging for someone with an
865g to give it the once over.

What we do have in batch are the usual mode setting fixes and a regression
fix for a regression fix. :(
-Chris

The following changes since commit d2478521afc20227658a10a8c5c2bf1a2aa615b3:

  char/ipmi: fix OOPS caused by pnp_unregister_driver on unregistered driver (2011-02-10 18:00:21 -0800)

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

Chris Wilson (7):
      drm/i915: Invalidate TLB caches on SNB BLT/BSD rings
      drm/i915/lvds: Restore dithering on native modes for gen2/3
      drm/i915: Disable RC6 on Ironlake
      drm/i915/sdvo: If we have an EDID confirm it matches the mode of the connection
      drm/i915: Trigger modesetting if force-audio changes
      drm/i915/tv: Use polling rather than interrupt-based hotplug
      drm/i915: Fix resume regression from 5d1d0cc

 drivers/gpu/drm/i915/i915_drv.c         |    5 +-
 drivers/gpu/drm/i915/i915_drv.h         |    1 +
 drivers/gpu/drm/i915/i915_reg.h         |    4 +-
 drivers/gpu/drm/i915/intel_display.c    |   95 ++++++++++++++++--------------
 drivers/gpu/drm/i915/intel_dp.c         |   36 ++++++++++--
 drivers/gpu/drm/i915/intel_drv.h        |    1 -
 drivers/gpu/drm/i915/intel_hdmi.c       |   39 +++++++++++--
 drivers/gpu/drm/i915/intel_lvds.c       |   12 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c |   26 +++++---
 drivers/gpu/drm/i915/intel_sdvo.c       |   66 ++++++++++++++++++----
 drivers/gpu/drm/i915/intel_tv.c         |   43 ++++++++++----
 11 files changed, 229 insertions(+), 99 deletions(-)

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [git pull] i915 fixes

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 1075 bytes --]

On Fri, 11 Feb 2011 09:58:03 +0000, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Dave, a few more days have passed and we have a fresh batch of
> regression fixes.
> 
> The patch that is most notable is one for its absence:
> 
> commit 25ed6eb15ebc4472fb0e473666c0ef3bba87097f
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Dec 22 11:37:09 2010 +0000
> 
>     agp/intel: Experiment with a 855GM GWB bit
> 
> is still sitting on drm-intel-staging just begging for someone with an
> 865g to give it the once over.

Tested-by: Eric Anholt <eric@anholt.net>

Tested on my 865G using openarena 5 times before and after, and x11perf
-aa24text 2 times before and after, with no stability or performance
change (and yes, it was stable).  I was concerned I wasn't getting good
enough coverage of the chipset flush path, so I also hacked the 2D
driver to upload the batch using bo_map; memcpy; bo_unmap instead of
bo_subdata, with no change.

before was ac66808814036b4c33dd98091b2176ae6157f1a8.
after was the cherry-pick on top of that.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [git pull] i915 fixes

[Chris Wilson]

On Fri, 11 Feb 2011 18:04:49 -0800, Eric Anholt <eric@anholt.net> wrote:
> On Fri, 11 Feb 2011 09:58:03 +0000, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > Dave, a few more days have passed and we have a fresh batch of
> > regression fixes.
> > 
> > The patch that is most notable is one for its absence:
> > 
> > commit 25ed6eb15ebc4472fb0e473666c0ef3bba87097f
> > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > Date:   Wed Dec 22 11:37:09 2010 +0000
> > 
> >     agp/intel: Experiment with a 855GM GWB bit
> > 
> > is still sitting on drm-intel-staging just begging for someone with an
> > 865g to give it the once over.
> 
> Tested-by: Eric Anholt <eric@anholt.net>

Thanks a lot Eric! Knowing that it does not cause 865g to spontaneously
burst into flames makes me feel a lot more comfortable with it.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] i915 fixes

[Chris Wilson]

Hi Dave, a fairly busy week or two of bouncing .38 regression fixes off
testers. A great big thanks to the QA at Suse who have been very
responsive and helped a great deal with these patches.

In the wings, as always, we have more patches under test, mainly focusing
on stability fixes for SNB and we must not forget that we almost have
*the* gen2 stability fix. (Ok, admittedly 830/845 is still fubar...)
And there is the continuing saga of the backlight.

This set of patches touch heavily on the core drm, in order to a fix a
couple of bugs in there and to provide the facility for i915 to hook into
for resetting its state.
-Chris


The following changes since commit ebf53826e105f488f4f628703a108e98940d1dc5:

  Linux 2.6.38-rc3 (2011-02-01 13:05:49 +1000)

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

Chris Wilson (9):
      drm/i915/sdvo: If at first we don't succeed in reading the response, wait
      drm: Add an interface to reset the device
      drm/i915: Reset state after a GPU reset or resume
      drm/i915/crt: Force the initial probe after reset
      drm/i915: Reset crtc after resume
      drm: Don't switch fb when disabling an output
      drm: Simplify and defend later checks when disabling a crtc
      drm: Avoid leak of adjusted mode along quick set_mode paths
      drm/i915: Suppress spurious vblank interrupts

 drivers/gpu/drm/drm_crtc.c           |   20 ++++++++++++++
 drivers/gpu/drm/drm_crtc_helper.c    |   21 ++++++++-------
 drivers/gpu/drm/drm_irq.c            |    7 +++--
 drivers/gpu/drm/i915/i915_drv.c      |    2 +
 drivers/gpu/drm/i915/i915_irq.c      |    8 +++---
 drivers/gpu/drm/i915/intel_crt.c     |   10 +++++++
 drivers/gpu/drm/i915/intel_display.c |   17 ++++++++++--
 drivers/gpu/drm/i915/intel_sdvo.c    |   46 +++++++++++++++++-----------------
 include/drm/drmP.h                   |    2 +-
 include/drm/drm_crtc.h               |    7 +++++
 10 files changed, 96 insertions(+), 44 deletions(-)

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] i915 fixes

[Chris Wilson]

Hi Linus,

Dave asked to me send this pull request directly to you as he is on
holiday over the New Year. In this batch, there are a few regression
fixes. The most notable being the revert of the SSC frequency switch,
along with a use-before-initialisation introduced much earlier in the
sdvo/hdmi audio enabling and a fix for the loss of correct modesetting on
one particular DVO chipset. Eric also found another instance where we were
not adhering to the specs when setting up Ironlake. The impact is not
conclusively known but we did find a few scenarios where it delayed a
hang.
-Chris

The following changes since commit 387c31c7e5c9805b0aef8833d1731a5fe7bdea14:

  Linux 2.6.37-rc8 (2010-12-28 17:05:48 -0800)

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

Chris Wilson (4):
      drm/i915/sdvo: Add hdmi connector properties after initing the connector
      drm/i915: Verify Ironlake eDP presence on DP_A using the capability fuse
      Revert "drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks"
      drm/i915/dvo: Report LVDS attached to ch701x as connected

Eric Anholt (2):
      drm/i915: Set the required VFMUNIT clock gating disable on Ironlake.
      drm/i915, intel_ips: When i915 loads after IPS, make IPS relink to i915.

 drivers/gpu/drm/i915/dvo_ch7017.c    |    2 +-
 drivers/gpu/drm/i915/i915_dma.c      |   23 +++++++++++++++++++++
 drivers/gpu/drm/i915/i915_reg.h      |   10 +++++++++
 drivers/gpu/drm/i915/intel_bios.c    |    2 +-
 drivers/gpu/drm/i915/intel_display.c |   21 ++++++++++++++++++-
 drivers/gpu/drm/i915/intel_sdvo.c    |    3 +-
 drivers/platform/x86/intel_ips.c     |   36 +++++++++++++++++++++++++++++++--
 drivers/platform/x86/intel_ips.h     |   21 +++++++++++++++++++
 8 files changed, 111 insertions(+), 7 deletions(-)
 create mode 100644 drivers/platform/x86/intel_ips.h

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [git pull] i915 fixes

[Jesse Barnes]

On Thu, 30 Dec 2010 19:01:34 +0000
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> Hi Linus,
> 
> Dave asked to me send this pull request directly to you as he is on
> holiday over the New Year. In this batch, there are a few regression
> fixes. The most notable being the revert of the SSC frequency switch,
> along with a use-before-initialisation introduced much earlier in the
> sdvo/hdmi audio enabling and a fix for the loss of correct modesetting on
> one particular DVO chipset. Eric also found another instance where we were
> not adhering to the specs when setting up Ironlake. The impact is not
> conclusively known but we did find a few scenarios where it delayed a
> hang.
> -Chris
> 
> The following changes since commit 387c31c7e5c9805b0aef8833d1731a5fe7bdea14:
> 
>   Linux 2.6.37-rc8 (2010-12-28 17:05:48 -0800)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-fixes
> 
> Chris Wilson (4):
>       drm/i915/sdvo: Add hdmi connector properties after initing the connector
>       drm/i915: Verify Ironlake eDP presence on DP_A using the capability fuse
>       Revert "drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks"
>       drm/i915/dvo: Report LVDS attached to ch701x as connected

Did you want to disable SSC entirely on gen5+ just so we can get all
the known machines working?  It's possible it could add some wifi or
sound interference, but that's better than not having a display (most
of the time).

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] i915 fixes

[Chris Wilson]

On Thu, 30 Dec 2010 14:01:03 -0800, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Did you want to disable SSC entirely on gen5+ just so we can get all
> the known machines working?  It's possible it could add some wifi or
> sound interference, but that's better than not having a display (most
> of the time).

My first step was to simply restore the behaviour to 2.3.36 and then look
for an alternate patch. I'd like to give any such patch at least the
chance for smoketesting by QA (and the machines here) before asking
Linus to pull ;-)

There is one interesting difference between the BIOS and KMS clock setting
for the Lenovo U160; the BIOS is able to set n=1, whereas we can't find a
suitable clock with just a single wire. Maybe we can fix the U160 and save
0.1W as well!

As far as I am aware, only the LVDS panel on the U160 is broken. Does
anyone else have a panel that sprang to life (ignoring the recent bug)
by disabling SSC?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [git pull] i915 fixes

[Linus Torvalds]

On Thu, Dec 30, 2010 at 2:01 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
> Did you want to disable SSC entirely on gen5+ just so we can get all
> the known machines working?  It's possible it could add some wifi or
> sound interference, but that's better than not having a display (most
> of the time).

It would be sad to possibly add more electrical noise to machines that
already work with it, but at the same time I do think that "working
screen" tends to be a lot more important than "try to avoid RF noise".

Also, are you sure it's really the fact that we enable spread-spectrum
that causes this? The code is really confused, and seems to mix up
"lvds_use_ssc" not just with the enabling of SSC, but it also with how
impacts the reference clock itself.

And it impacts the reference clock in really odd ways, that look buggy
and confusing, where the tests are repeated in multiple places: first
to set the reference frequency, and then later to set the bits that
choose the reference input frequency.

In particular, look at how 'refclk' is calculated in
intel_crtc_mode_set(), vs how we actually set the input frequency
later in the function. The two don't actually *match*. That sounds
bogus to me - since it means that the pll values have been calculated
for a reference clock that isn't actually used. No?

Look at the code for the "!is_lvds" case, for example. It uses
"IS_GEN2()" to determine what refclk to use, but then when setting the
PLL_REF_INPUT_xyz bits, we actually take "is_tv" into account - which
the code didn't when it calculated refclk. That strikes me as odd. No?

Now, that shouldn't matter for the LVDS case, but I'm wondering
whether something similar is going on where the conditionals just
don't match up, and we end up calculating the plls for a different
frequency than the one we actually end up _using_.

There's also this very odd special refclock magic for ironlake
limiting that only happens for ssc_freq == 100 when ssc is enabled.
Maybe the problem is in the limiting tables, and the ssc frequency
change just ends up then picking the "wrong" limiter table? So even if
the frequency is correct, and the pll calculations are using that
correct frequency, the 120-vs-100Mhz frequency change ended up
switching the tables around?

                               Linus

Re: [git pull] i915 fixes

[Chris Wilson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3087 bytes --]

On Thu, 30 Dec 2010 14:29:34 -0800, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, Dec 30, 2010 at 2:01 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >
> > Did you want to disable SSC entirely on gen5+ just so we can get all
> > the known machines working?  It's possible it could add some wifi or
> > sound interference, but that's better than not having a display (most
> > of the time).
> 
> It would be sad to possibly add more electrical noise to machines that
> already work with it, but at the same time I do think that "working
> screen" tends to be a lot more important than "try to avoid RF noise".
> 
> Also, are you sure it's really the fact that we enable spread-spectrum
> that causes this? The code is really confused, and seems to mix up
> "lvds_use_ssc" not just with the enabling of SSC, but it also with how
> impacts the reference clock itself.
> 
> And it impacts the reference clock in really odd ways, that look buggy
> and confusing, where the tests are repeated in multiple places: first
> to set the reference frequency, and then later to set the bits that
> choose the reference input frequency.
> 
> In particular, look at how 'refclk' is calculated in
> intel_crtc_mode_set(), vs how we actually set the input frequency
> later in the function. The two don't actually *match*. That sounds
> bogus to me - since it means that the pll values have been calculated
> for a reference clock that isn't actually used. No?
> 
> Look at the code for the "!is_lvds" case, for example. It uses
> "IS_GEN2()" to determine what refclk to use, but then when setting the
> PLL_REF_INPUT_xyz bits, we actually take "is_tv" into account - which
> the code didn't when it calculated refclk. That strikes me as odd. No?
> 
> Now, that shouldn't matter for the LVDS case, but I'm wondering
> whether something similar is going on where the conditionals just
> don't match up, and we end up calculating the plls for a different
> frequency than the one we actually end up _using_.
> 
> There's also this very odd special refclock magic for ironlake
> limiting that only happens for ssc_freq == 100 when ssc is enabled.
> Maybe the problem is in the limiting tables, and the ssc frequency
> change just ends up then picking the "wrong" limiter table? So even if
> the frequency is correct, and the pll calculations are using that
> correct frequency, the 120-vs-100Mhz frequency change ended up
> switching the tables around?

Switching those tables around was the reason why the one-line change had
any impact at all, and I hoped that it was the leniency in our pll finder
that enabled us to bring up any SSC-enabled panel. I also made one pass at
removing the confusion surrounding refclk, which wasn't -fixes material.
Now I have several more concerns about the code.

However, switching the SSC refclk back to 100MHz we do end up choosing the
same PLL clocks as the BIOS does on the U160, but modesetting still fails.
So the discrepancy is not likely to be in the limit tables themselves.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre