Commit Graph

2962 Commits

Author SHA1 Message Date
Jani Nikula
bcd7235cea drm/i915: fix EDID memory leak in SDVO
The EDID returned by drm_get_edid() was never freed.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-08-24 09:37:03 +10:00
Daniel Vetter
a22ddff8be Linux 3.6-rc2
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (GNU/Linux)
 
 iQEcBAABAgAGBQJQLWtvAAoJEHm+PkMAQRiG/DYH+wd0FqfEuYkYk4KPyAPuhKpX
 zX7HYfLvyJE/ZYIdrhjq1E6Xm2KNr7gtX7/Rdzi2W38M9sjbYzwG1UGIw51qnxWy
 yZJH9BGkfyQgQPeuDGohfB6DkDy2JWr2eqMDvakjOwgBsIzji0PQD/f3UvndhtUa
 c+tTj/kjavHE1Yr2Wy6OnRZz3Uc0hIMn/Q0JqtbCs3LUgEV1KA4OEAe56XNz4Ku4
 WE+FFaGFPvtriQsQON+ohPS5IC8jzQGK/0vbrJ4lWjFnZy4gvZXnborTOwD0WSQG
 fbsNuxp1AaM2/pqfMwXm1w0ADvwOITHNiwwXf9id6DoK81QwTFpUdvKpn6yB6gQ=
 =rurr
 -----END PGP SIGNATURE-----

Merge tag 'v3.6-rc2' into drm-intel-next

Backmerge Linux 3.6-rc2 to resolve a few funny conflicts before we put
even more madness on top:

- drivers/gpu/drm/i915/i915_irq.c: Just a spurious WARN removed in
  -fixes, that has been changed in a variable-rename in -next, too.

- drivers/gpu/drm/i915/intel_ringbuffer.c: -next remove scratch_addr
  (since all their users have been extracted in another fucntion),
  -fixes added another user for a hw workaroudn.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-17 09:01:08 +02:00
Chris Wilson
7d54a90428 drm/i915: Apply post-sync write for pipe control invalidates
When invalidating the TLBs it is documentated as requiring a post-sync
write. Failure to do so seems to result in a GPU hang.

Exposure to this hang on IVB seems to be a result of removing the extra
stalls required for SNB pipecontrol workarounds:

commit 6c6cf5aa9c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 18:02:28 2012 +0100

    drm/i915: Only apply the SNB pipe control w/a to gen6

Note: Manually switch the pipe_control cmd to 4 dwords to avoid a
(silent) functional conflict with -next. This way will get a loud (but
conflict with next (since the scratch_addr has been deleted there).

Reported-and-tested-by: yex.tian@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: added note about merge conflict with -next.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-14 09:47:45 +02:00
Daniel Vetter
35a38556d9 drm/i915: reorder edp disabling to fix ivb MacBook Air
eDP is tons of fun. It turns out that at least the new MacBook Air 5,1
model absolutely doesn't like the new force vdd dance we've introduced
in

commit 6cb49835da
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 20 17:14:50 2012 +0200

    drm/i915: enable vdd when switching off the eDP panel

But that patch also tried to fix some neat edp sequence issue with the
force_vdd timings. Closer inspection reveals that we've raised
force_vdd only to do the aux channel communication dp_sink_dpms. If we
move the edp_panel_off below that, we don't need any force_vdd for the
disable sequence, which makes the Air happy.

Unfortunately the reporter of the original bug that the above commit
fixed is travelling, so we can't test whether this regresses things.
But my theory is that since we don't check for any power-off ->
force_vdd-on delays in edp_panel_vdd_on, this was the actual
root-cause of this failure. With that force_vdd dance completely
eliminated, I'm hopeful the original bug stays fixed, too.

For reference the old bug, which hopefully doesn't get broken by this:

https://bugzilla.kernel.org/show_bug.cgi?id=43163

In any case, regression fixers win over plain bugfixes, so this needs
to go in asap.

v2: The crucial pieces seems to be to clear the force_vdd flag
uncoditionally, too, in edp_panel_off. Looks like this is left behind
by the firmware somehow.

v3: The Apple firmware seems to switch off the panel on it's own, hence
we still need to keep force_vdd on, but properly clear it when switching
the panel off.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671
Tested-by: Roberto Romer <sildurin@gmail.com>
Tested-by: Daniel Wagner <wagi@monom.org>
Tested-by: Keith Packard <keithp@keithp.com>
Cc: stable@vger.kernel.org
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-14 09:38:25 +02:00
Jani Nikula
cee25168e9 drm/i915: ensure i2c adapter is all set before adding it
i2c_add_adapter() may do i2c transfers on the bus to detect supported
devices. Therefore the adapter needs to be all set before adding it. This
was not the case for the bit-banging fallback, resulting in an oops if the
device detection GMBUS transfers timed out. Fix the issue by calling
i2c_add_adapter() only after intel_gpio_setup().

LKML-Reference: <5021F00B.7000503@ionic.de>
Tested-by: Mihai Moldovan <ionic@ionic.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-13 19:04:24 +02:00
Daniel Vetter
20d5a540e5 drm/i915: don't grab dev->struct_mutex for userspace forcewak
Since forcewake is now protected by a spinlock, we don't need to grab
dev->struct_mutex any more. This way we can also get rid of a stale
comment, noticed by Ben Widawsky while reviewing some locking changes.

v2: Kill the unused variable ret, noticed by Fengguang Wu.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-12 11:28:49 +02:00
Daniel Vetter
4344b813f1 drm/i915: ignore eDP bpc settings from vbt
This has originally been introduced to not oversubscribe the dp links
in

commit 885a5fb5b1
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Tue Jan 12 05:38:31 2010 +0800

    drm/i915: fix pixel color depth setting on eDP

Since then we've fixed up the dp link bandwidth calculation code and
should now automatically fall back to 6bpc dithering. So this is
unnecessary.

Furthermore it seems to break the new MacbookPro with retina display,
hence let's just rip this out.

Reported-by: Benoit Gschwind <gschwind@gnu-log.net>
Cc: Benoit Gschwind <gschwind@gnu-log.net>
Cc: Francois Rigaut <frigaut@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Tested-by: Bernhard Froemel <froemel at vmars tuwien.ac.at>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

--

Testing feedback highgly welcome, and thanks for Benoit for finding
out that the bpc computations are busted.
-Daniel
2012-08-11 21:42:52 +02:00
Takashi Iwai
770c12312a drm/i915: Fix blank panel at reopening lid
When you reopen the lid on a laptop with PCH, the panel suddenly goes
blank sometimes.  It seems because BLC_PWM_CPU_CTL register is cleared
to zero when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 registers are
enabled.

This patch fixes the problem by moving the call of the function setting
BLC_PWM_CPU_CTL after enabling other two registers.

Reported-and-tested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-11 21:15:16 +02:00
Paulo Zanoni
126e9be816 drm/i915: try harder to find WR PLL clock settings
If we don't find the exact refresh rate, go with the next one. This
makes some modes work for me. They won't have the best settings, but
will at least have something. Just returning from this function when
we don't find the perfect settings does not help us at all.

Version 2:
  - Remove duplicate lines on the clock table.
  - Add back debug message with refresh, p, n2 and r2.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-10 18:35:28 +02:00
Paulo Zanoni
228d3e367c drm/i915: use the correct encoder type when comparing
- intel_encoder->type is INTEL_OUTPUT_SOMETHING
  - drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING

Here we're using intel_encoder, so compare the oranges against
oranges. While at it, rename the variable to "intel_encoder" so we
keep our naming standards used everywhere.

Luckily this was not a bug because both DRM_MODE_ENCODER_DAC and
INTEL_OUTPUT_ANALOG are defined as 1. This is the only case where the
drm definition matches the intel definition.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-10 18:34:05 +02:00
Chris Wilson
b2eadbc85b drm/i915: Lazily apply the SNB+ seqno w/a
Avoid the forcewake overhead when simply retiring requests, as often the
last seen seqno is good enough to satisfy the retirment process and will
be promptly re-run in any case. Only ensure that we force the coherent
seqno read when we are explicitly waiting upon a completion event to be
sure that none go missing, and also for when we are reporting seqno
values in case of error or debugging.

This greatly reduces the load for userspace using the busy-ioctl to
track active buffers, for instance halving the CPU used by X in pushing
the pixels from a software render (flash). The effect will be even more
magnified with userptr and so providing a zero-copy upload path in that
instance, or in similar instances where X is simply compositing DRI
buffers.

v2: Reverse the polarity of the tachyon stream. Daniel suggested that
'force' was too generic for the parameter name and that 'lazy_coherency'
better encapsulated the semantics of it being an optimization and its
purpose. Also notice that gen6_get_seqno() is only used by gen6/7
chipsets and so the test for IS_GEN6 || IS_GEN7 is redundant in that
function.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-10 11:11:32 +02:00
Daniel Vetter
456470eb58 drm/i915: enable rc6 on ilk again
I have the faint hope that the total absence of any locking for the
rps code wasn't too good an idea and could very well have caused some
rc6 related regressions.

Unfortunately we've never managed to reproduce these issues on any of
our own machines, so the only way to go about this is to enable it and
see what happens.

While at it, kill some stale comments and improve the logging.

Acked-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 22:35:48 +02:00
Daniel Vetter
9270388e18 drm/i915: fix up ilk drps/ips locking
We change the drps/ips sw/hw state from different callers: Our own irq
handler, the external intel-ips module and from process context. Most
of these callers don't take any lock at all.

Protect everything by making the mchdev_lock irqsave and grabbing it in
all relevant callsites. Note that we have to convert a few sleeps in the
drps enable/disable code to delays, but alas, I'm not volunteering to
restructure the code around a few work items.

For paranoia add a spin_locked assert to ironlake_set_drps, too.

v2: Move one access inside the lock protection. Caught by the
dev_priv->ips mass-rename ...

v3: Resolve rebase conflict.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 21:53:52 +02:00
Daniel Vetter
73edd18f61 drm/i915: DE_PCU_EVENT irq is ilk-only
Like all the other drps/ips stuff. Hence add the corresponding check,
give the function a preciser prefix and move the single reg clearing into
the rps handling function, too.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 21:53:17 +02:00
Daniel Vetter
35eb73234b drm/i915: kill dev_priv->mchdev_lock
It's only ever a pointer to the global mchdev_lock, and we don't use
it at all.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 21:53:01 +02:00
Daniel Vetter
c6a828d326 drm/i915: move all rps state into dev_priv->rps
This way it's easier so see what belongs together, and what is used
by the ilk ips code. Also add some comments that explain the locking.

Note that (cur|min|max)_delay need to be duplicated, because
they're also used by the ips code.

v2: Missed one place that the dev_priv->ips change caught ...

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 21:52:22 +02:00
Daniel Vetter
22bcfc6a4b drm/i915: use mutex_lock_interruptible for debugfs files
It's no fun if your shell hangs when the driver has gone on vacation
and you want to know why ...

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 21:50:17 +02:00
Daniel Vetter
004777cb22 drm/i915: fixup up debugfs rps state handling
- Take the dev->struct_mutex around access the corresponding state
  (and adjusting the rps hw state).
- Add an assert to gen6_set_rps to ensure we don't forget about this
  in the future.
- Don't set up the min/max_freq files if it doesn't apply to the hw.
  And do the same for the gen6+ cache sharing file while at it.

v2: Move the gen6+ checks into the read/write callbacks. Thanks to the
awesome drm midlayer we can't check that when registering the debugfs
files, because the driver is not yet fully set up, specifically the
->load callback hasn't run yet.

Oh how I despise this disaster ...

v3: Also add a WARN_ON(mutex_is_locked) in set_rps to check the
locking.

v4: Use mutex_lock_interruptible, suggested by Chris Wilson.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (for v2)
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 21:49:54 +02:00
Daniel Vetter
02d719562e drm/i915: properly guard ilk ips state
The update_gfx_val function called from mark_busy wasn't taking the
mchdev_lock, as it should have. Also sprinkle a few spinlock asserts
over the code to document things better.

Things are still rather confusing, especially since a few variables
in dev_priv are used by both the gen6+ rps code and the ilk ips code.
But protected by totally different locks. Follow-on patches will clean
that up.

v2: Don't add a deadlock ... hence split up update_gfx_val into a
wrapper that grabs the lock and an internal __ variant for callsites
within intel_pm.c that already have taken the lock.

v3: Mark the internal helper as static, noticed by Ben Widawsky.

v4: Damien Lespiau had questions about the safety of the ips setup
sequence, explain in a comment why it works.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 21:45:17 +02:00
Paulo Zanoni
745ca3be81 drm/i915: add parentheses around PIXCLK_GATE definitions
By looking at the current way we're using these definitions I don't
think this commit will fix any bug, but programmers from the future
are evil and will certainly find ways to combine macro expansion with
operator precedence to introduce bugs that are hard to find.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 18:42:09 +02:00
Paulo Zanoni
5e49cea643 drm/i915: reindent Haswell register definitions
It's the only part of the i915_reg.h file that looks totally wrongly
indented, so I assume my editor config is the correct one.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 18:41:47 +02:00
Paulo Zanoni
602c43d34d drm/i915: completely reset the value of DDI_FUNC_CTL
Don't rely on previous values already set on the register. Everything
we're not explicitly setting should be zero for now.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 18:41:25 +02:00
Paulo Zanoni
dfcef252e0 drm/i915: correctly set the DDI_FUNC_CTL bpc field
Correctly erase the values previously set and also check for 6bpc and
10bpc.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 18:41:14 +02:00
Paulo Zanoni
f63eb7c452 drm/i915: set the DDI sync polarity bits
During my tests, everything worked even if the wrong polarity was set.
Still, we should try to set the correct values.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 18:38:18 +02:00
Paulo Zanoni
3f7c447faa drm/i915: fix pipe DDI mode select
Mask the value before changing it and also select DVI when needed.

DVI was working in cases where the BIOS was setting the correct value
because we were not masking the value before changing it.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 18:36:04 +02:00
Daniel Vetter
c96ea64ebb drm/i915: dump the device info
Handy for lazy people like me, or when people forget to add the output
of lspci -nn.

v2: Chris Wilson noticed that we have this duplicated already in the
i915_capabilites debugfs file. But there \n as separator looks better,
which would be a bit verbose in dmesg. Abuse the preprocessor to
extract this all.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-09 18:29:21 +02:00
Dave Airlie
41494cbaea Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:

"- Regression fixer for an OOPS at boot when i915.ko is built-in and
  CONFIG_PM=n, introduce in 3.5 (patch from Hunt Xu)
- Regression fixer for occlusion query failures, the required w/a wasn't
  applied in all cases (thanks to Eric for tracking this on down).
- dmar vs. dma_buf imprt fix (Dave Airlie)
- 2 patches to fight down forcewake issues on snb. This is the stuff I've
  talked about 2 weeks ago already, it's a minefield. Investigation still
  going on, but afaict this is the best we have for now.
- a few minor things to keep coverty&compiler happy (Alan, Davendra,
  Stéphane)
- tons of hsw pci ids - this one is a bit late because internal approval
  sometimes takes a while, but ppl in charge finally agreed that world+dog
  already knows about ult and crw haswell variants ;-)

Wrt regressions I'm aware of:
- the power regression due to semaphores=1. Ben is running around with a
  killawatt, unfortunately we have a hard time reproducing this one. And
  this /shouldn't/ increase power usage. Ben has turned up a few odds bits
  though already.
- the lvds fix in 3.6-rc1 broke a backlight after lid close/open (but can
  be resurrected with a modeset cycle). I guess we anger the bios - I'm
  still looking into this one.
- gmbus broke edid reading on an odd-ball monitor, we need to fall-back.
  Due to vacation (both mine&the reporter's) this is stalling for a final
  patch and a tested-by on it. But issue is fully diagnosed."

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: correctly order the ring init sequence
  drm/i915: add more Haswell PCI IDs
  drm/i915: make rc6 in sysfs functions conditional
  drm/i915: Workaround hang with BSD and forcewake on SandyBridge
  drm/i915: Make intel_panel_get_backlight static.
  i915: don't map imported dma-bufs for dmar.
  drm/i915: remove unused variable
  drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround.
  drm/i915: fix forcewake related hangs on snb
  i915: Remove silly test
  i915: fix error path leak in intel_sdvo_write_cmd
  vlv: it might be wise if we initialised the flag value...
2012-08-09 09:54:49 +10:00
Daniel Vetter
65bccb5c70 drm/i915: fixup desired rps frequency computation
In commit

commit 20b46e59dd
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 26 11:16:14 2012 +0200

    drm/i915: Only set the down rps limit when at the loweset frequency

The computation for the new desired frequency was extracted, but since
the desired frequency was passed-by value, the adjustments didn't
propgate back. Fix this.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-08 22:54:06 +02:00
Chris Wilson
2fedbff948 drm/i915: Add I915_GEM_PARAM_HAS_SEMAPHORES
Userspace tries to estimate the cost of ring switching based on whether
the GPU and GEM supports semaphores. (If we have multiple rings and no
semaphores, userspace assumes that the cost of switching rings between
batches is exorbitant and will endeavour to keep the next batch on the
active ring - as a coarse approximation to tracking both destination and
source surfaces.) Currently userspace has to guess whether semaphores
exist based on the chipset generation and the module parameter,
i915.semaphores. This is a crude and inaccurate guess as the defaults
internally depend upon other chipset features being enabled or disabled,
nor does it extend well into the future. By exporting a HAS_SEMAPHORES
parameter, we can easily query the driver and obtain an accurate answer.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-08 14:29:12 +02:00
Daniel Vetter
0d8957c8a9 drm/i915: correctly order the ring init sequence
We may only start to set up the new register values after having
confirmed that the ring is truely off. Otherwise the hw might lose the
newly written register values. This is caught later on in the init
sequence, when we check whether the register writes have stuck.

Cc: stable@vger.kernel.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Tested-by: Yang Guang <guang.a.yang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-08 10:23:35 +02:00
Chris Wilson
6c6cf5aa9c drm/i915: Only apply the SNB pipe control w/a to gen6
The requirements for the sync flush to be emitted prior to the render
cache flush is only true for SandyBridge. On IvyBridge and friends we
can just emit the flushes with an inline CS stall.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-08 09:34:32 +02:00
Paulo Zanoni
da612d880f drm/i915: add more Haswell PCI IDs
Also properly indent the HB IDs.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-07 13:17:33 +02:00
Hunt Xu
5ab3633d69 drm/i915: make rc6 in sysfs functions conditional
Commit 0136db586c merges rc6 information
into the power group. However, when compiled with CONFIG_PM not set,
modprobing i915 would taint since power_group_name is defined as NULL.

This patch makes these rc6 in sysfs functions conditional upon the
definition of the CONFIG_PM macro to avoid the above-mentioned problem.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45181
Cc: stable@vger.kernel.org
Tested-by: Kris Karas <bugs-a12@moonlit-rail.com>
Signed-off-by: Hunt Xu <mhuntxu@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-06 19:31:33 +02:00
Chris Wilson
bcf9dcc1e6 drm/i915: Workaround hang with BSD and forcewake on SandyBridge
For reasons that are not apparent to anybody, 990bbdadab (drm/i915:
Group the GT routines together in both code and vtable) breaks the use
of the BitStream Decoder ring on SandyBridge. The active ingredient of
that patch is the conversion from a udelay(10) to a udelay(1) in the
busy-wait loop of waiting for the forcewake acknowledge. If we restore
that udelay(10) or insert another udelay(1) afterwards (or any wait
longer than 250ns) everything works again. An alternative is also to
remove any delay from the busy-wait loop.

Given that in the atomic sections we want to complete the wait as quick
as possible to avoid blocking the CPU for too long, it makes sense to
remove the delay altogether and simply spin on the exit condition until
it completes. So we replace the udelay(1) with cpu_relax().

Papers over regression from

commit 990bbdadab
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 2 11:51:02 2012 -0300

    drm/i915: Group the GT routines together in both code and vtable

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-06 10:43:29 +02:00
Stéphane Marchesin
faea35dd8a drm/i915: Make intel_panel_get_backlight static.
This function isn't used outside of intel_panel.c, so make it static.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-06 08:57:48 +02:00
Dave Airlie
f00f979145 i915: don't map imported dma-bufs for dmar.
The exporter should have given us pages in the correct place, avoid
the prepare object mapping phase on dmar systems.

This fixes an oops on a GM45/R600 machine, when running the intel/radeon
tests.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-05 22:53:59 +02:00
Devendra Naga
e47e9ad918 drm/i915: remove unused variable
the following warning was produced,

drivers/gpu/drm/i915/i915_gem_context.c: In function ‘i915_switch_context’:
drivers/gpu/drm/i915/i915_gem_context.c:454:6: warning: unused variable ‘ret’ [-Wunused-variable]

fix up by removing it

Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-05 22:39:53 +02:00
Eric Anholt
e844b990b1 drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround.
If a buffer that was the target of a PIPE_CONTROL from userland was a
reused one that hadn't been evicted which had not previously had this
workaround applied, then the early return for a correct
presumed_offset in this function meant we would not bind it into the
GTT and the write would land somewhere else.

Fixes reproducible failures with GL_EXT_timer_query usage in apitrace,
and I also expect it to fix the intermittent OQ issues on snb that
danvet's been working on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48019
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52932
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Carl Worth <cworth@cworth.org>
Tested-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-05 21:45:01 +02:00
Daniel Vetter
6af2d180f8 drm/i915: fix forcewake related hangs on snb
... by adding seemingly redudant posting reads.

This little dragon lair exploded the first time around when we've
refactored the code a bit to use the common wait_for_atomic_us in
"drm/i915: Group the GT routines together in both code and vtable",
which caused QA to file fdo bug #51738.

Chris Wilson entertained a few approaches to fixing #51738: Replacing
the udelay(1) with the previously-used udelay(10) (or any other
"sufficiently larger" delay), adding a posting read, or ditching the
delay completely and using cpu_relax. We went with the cpu_relax and
"915: Workaround hang with BSD and forcewake on SandyBridge". Which
blew up in fdo bug #52424, but adding the posting read while still
using cpu_relax seems to also fix that, it looks like the
posting read is the important ingriedient to fix these rc6 related
hangs on snb.

Popular theories as to why this is like it is include:
- A herd of pink elephants got royally angered somehow.

- The gpu has internally different functional units and judging by the
  register offsets, the forcewake request register and the forcewake
  ack registers are _not_ in the same functional unit (or at least
  aren't reached through the same routes). Hence the posting read
  syncs up with the wrong block and gets the entire gpu confused.

- ...

As a minimal ducttape fix for 3.6, let's just put these posting reads
into place again. We can try fancier approaches (like adding back the
cpu_relax instead of the udelay) in -next.

This (re-)fixes a regression introduced in

commit 990bbdadab
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 2 11:51:02 2012 -0300

    drm/i915: Group the GT routines together in both code and vtable

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Du Yan <yanx.du@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52424
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738u
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-27 08:23:28 +02:00
Eugeni Dodonov
ab3951eb74 drm/i915: prevent possible pin leak on error path
We should not hit this under any sane conditions, but still, this does not
looks right.

CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: stable@vger.kernel.org
Reported-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Reviewed-by: Chris Wlison <chris@chris-wilson.co.uk>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26 22:32:29 +02:00
Daniel Vetter
acbe947550 drm/i915: rip out sanitize_pm again
We believe to have squashed all issues around the gen6+ rps interrupt
generation and why the gpu sometimes got stuck. With that cleared up,
there's no user left for the sanitize_pm infrastructure, so let's just
rip it out.

Note that 'intel_reg_write 0xa014 0x13070000' is the w/a if we find
ourselves stuck again.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26 13:37:13 +02:00
Daniel Vetter
20b46e59dd drm/i915: Only set the down rps limit when at the loweset frequency
The power docs say that when the gt leaves rc6, it is in the lowest
frequency and only about 25 usec later will switch to the frequency
selected in GEN6_RPNSWREQ. If the downclock limit expires in that
window and the down limit is set to the lowest possible frequency, the
hw will not send the down interrupt. Which leads to a too high gpu
clock and wasted power.

Chris Wilson already worked on this with

commit 7b9e0ae6da
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Apr 28 08:56:39 2012 +0100

    drm/i915: Always update RPS interrupts thresholds along with
    frequency

but got the logic inverted: The current code set the down limit as
long as we haven't reached it. Instead of only once with reached the
lowest frequency.

Note that we can't always set the downclock limit to 0, because
otherwise the hw will keep on bugging us with downclock request irqs
once the lowest level is reached.

For similar reasons also always set the upclock limit, otherwise the
hw might poke us again with interrupts.

v2: Chris Wilson noticed that the limit reg is also computed in
sanitize_pm. To avoid duplication, extract the code into a common
function.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26 13:29:30 +02:00
Chris Wilson
e6994aeedc drm/i915: Export ability of changing cache levels to userspace
By selecting the cache level (essentially whether or not the CPU snoops
any updates to the bo, and on more recent machines whether it resides
inside the CPU's last-level-cache) a userspace driver is able to then
manage all of its memory within buffer objects, if it so desires. This
enables the userspace driver to accelerate uploads and more importantly
downloads from the GPU and to able to mix CPU and GPU rendering/activity
efficiently.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added code comment about where we plan to stuff platform
specific cacheing control bits in the ioctl struct.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26 12:56:25 +02:00
Chris Wilson
42d6ab4839 drm/i915: Segregate memory domains in the GTT using coloring
Several functions of the GPU have the restriction that differing memory
domains cannot be placed next to each other (as the GPU may prefetch
beyond the end of one domain and hang as it crosses into the other
domain). We use the facility of the drm_mm to mark ranges with a
particular color that corresponds to the cache attributes of those pages
in order to prevent allocating adjacent blocks of differing memory
types.

v2: Rebase ontop of drm_mm coloring v2.
v3: Fix rebinding existing gtt_space and add a verification routine.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26 12:56:25 +02:00
Alan Cox
9978cf5042 i915: Remove silly test
drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful
than a chocolate teapot.

Possibly we should be testing bus != NULL each iteration of the loop
instead ?

gcc could help by warning too!

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26 09:50:35 +02:00
Alan Cox
0274df3e43 i915: fix error path leak in intel_sdvo_write_cmd
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26 09:50:04 +02:00
Alan Cox
af447bd358 vlv: it might be wise if we initialised the flag value...
Otherwise our initial behaviour is "randomly save a bogus PLL
choice" as far as I can see.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-26 09:47:31 +02:00
Dave Airlie
98c7b42375 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes: (this pull is the one with the bad patch dropped)
First pile of fixes for 3.6 already, and I'm afraid it's a bit larger than
what I'd wish for. But I've moved all the feature-y stuff to -next, so
this really is all -fixes. Most of it is handling fallout from the hw
context stuff, discovered now that mesa git has started using them for
real. Otherwise all just small fixes:
- unbreak modeset=0 on gen6+ (regressed in next)
- const mismatch fix for ->mode_fixup
- simplify overly clever lvds modeset code (current code can totally
  confuse backlights, resulting in broken panels until a full power draw
  restores them).
- fix some fallout from the flushing_list disabling (regression only
  introduced in -next)
- DP link train improvements (this also kills the last 3.2 dp regression
  afaik)
- bugfix for the new ddc VGA detection on newer platforms
- minor backlight fixes (one of them a -next regression)
- only enable the required PM interrupts (to avoid waking up the cpu
  unnecessarily)
- some really minor bits (workaround clarification, make coverty happy,
  hsw init fix)
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (23 commits)
  drm/i915: unbreak lastclose for failed driver init
  drm/i915: Set the context before setting up regs for the context.
  drm/i915: constify mode in crtc_mode_fixup
  drm/i915/lvds: ditch ->prepare special case
  drm/i915: dereferencing an error pointer
  drm/i915: fix invalid reference handling of the default ctx obj
  drm/i915: Add -EIO to the list of known errors for __wait_seqno
  drm/i915: Flush the context object from the CPU caches upon switching
  drm/i915: Make the lock for pageflips interruptible
  drm/i915: don't forget the PCH backlight registers
  drm/i915: Insert a flush between batches if the breadcrumb was dropped
  drm/i915: missing error case in init status page
  drm/i915: mask tiled bit when updating ILK sprites
  drm/i915: try to train DP even harder
  drm/i915: kill intel_ddc_probe
  drm/i915: check whether we actually received an edid in detect_ddc
  drm/i915: fix up PCH backlight #define mixup
  drm/i915: Add comments to explain the BSD tail write workaround
  drm/i915: Disable the BLT on pre-production SNB hardware
  drm/i915: initialize power wells in modeset_init_hw
  ...
2012-07-26 10:40:31 +10:00
Ben Widawsky
f27b92651d drm/i915: Expand DPF support to Haswell
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25 18:23:57 +02:00
Ben Widawsky
e1ef7cc299 drm/i915: Macro to determine DPF support
Originally I had a macro specifically for DPF support, and Daniel, with
good reason asked me to change it to this. It's not the way I would have
gone (and indeed I didn't), but for now there is no distinction as all
platforms with L3 also have DPF.

Note: The good reasons are that dpf is a l3$ feature (at least on
currrent hw), hence I don't expect one to go without the other.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: added note]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-25 18:23:56 +02:00