Commit Graph

7465 Commits

Author SHA1 Message Date
Alex Deucher
c7eff978e0 drm/radeon: add rptr save support for r1xx-r5xx
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18 13:53:32 +02:00
Alex Deucher
89d35807fb drm/radeon: update rptr saving logic for memory buffers
Add support for using memory buffers rather than
scratch registers.  Some rings may not be able to
write to scratch registers.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18 13:53:17 +02:00
Alex Deucher
8b25ed3482 drm/radeon: remove radeon_ring_index()
Just store the index in the ring structure.
Idea taken from one of Jerome's wip rptr patches.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18 13:33:54 +02:00
Alex Deucher
a85a7da4c5 drm/radeon: update ib_execute for SI (v2)
When submitting a CONST_IB, emit a SWITCH_BUFFER
packet before the CONST_IB.  This isn't strictly necessary
(the driver will work fine without it), but is good practice
and allows for more flexible DE/CE sychronization options
in the future.  Current userspace drivers do not take
advantage of the CE yet.

v2: - clean up code flow a bit
    - no need to flush caches for CONST IB

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
2012-07-18 13:33:39 +02:00
Christian König
4ef72566f1 drm/radeon: fix const IB handling v2
Const IBs are executed on the CE not the CP, so we can't
fence them in the normal way.

So submit them directly before the IB instead, just as
the documentation says.

v2: keep the extra documentation

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-18 13:17:49 +02:00
Christian König
bfb38d35c1 drm/radeon: let sa manager block for fences to wait for v2
Otherwise we can encounter out of memory situations under extreme load.

v2: add documentation for the new function

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-18 13:17:44 +02:00
Christian König
246fa345a1 drm/radeon: return an error if there is nothing to wait for
Otherwise the sa managers out of memory
handling doesn't work.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-18 13:17:32 +02:00
Laurent Pinchart
29935554b3 drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers
DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
for KMS drivers.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2012-07-18 06:05:48 +10:00
Dave Airlie
faadaf97e5 Merge branch 'next' of git://people.freedesktop.org/~deathsimple/linux into drm-next
This merges Christian work that has been hanging around on the list.
2012-07-17 19:46:49 +10:00
Christian König
55d7c22192 drm/radeon: implement ring saving on reset v4
Try to save whatever is on the rings when
we encounter an lockup.

v2: Fix spelling error. Free saved ring data if reset fails.
    Add documentation for the new functions.
v3: Some more spelling fixes
v4: It doesn't make sense to save anything if all fences
    are signaled

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:33:15 +02:00
Christian König
45df68035c drm/radeon: record what is next valid wptr for each ring v4
Before emitting any indirect buffer, emit the offset of the next
valid ring content if any. This allow code that want to resume
ring to resume ring right after ib that caused GPU lockup.

v2: use scratch registers instead of storing it into memory
v3: skip over the surface sync for ni and si as well
v4: use SET_CONFIG_REG instead of PACKET0

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:33:09 +02:00
Christian König
04eb2206d8 drm/radeon: move radeon_ib_ring_tests out of chipset code
Making it easier to control when it is executed.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:33:01 +02:00
Christian König
c6105f249a drm/radeon: remove vm_manager start/suspend
Just restore the page table instead. Addressing three
problem with this change:

1. Calling vm_manager_suspend in the suspend path is
   problematic cause it wants to wait for the VM use
   to end, which in case of a lockup never happens.

2. In case of a locked up memory controller
   unbinding the VM seems to make it even more
   unstable, creating an unrecoverable lockup
   in the end.

3. If we want to backup/restore the leftover ring
   content we must not unbind VMs in between.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:55 +02:00
Christian König
6f72a63199 drm/radeon: remove r600_blit_suspend
Just reinitialize the shader content on resume instead.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:48 +02:00
Christian König
2898c348e5 drm/radeon: remove ip_pool start/suspend
The IB pool is in gart memory, so it is completely
superfluous to unpin / repin it on suspend / resume.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:41 +02:00
Christian König
b90ca986a4 drm/radeon: make cp init on cayman more robust
It's not critical, but the current code isn't
100% correct.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:35 +02:00
Christian König
d40fd3a337 drm/radeon: remove FIXME comment from chipset suspend
For a normal suspend/resume we allready wait for
the rings to be empty, and for a suspend/reasume
in case of a lockup we REALLY don't want to wait
for anything.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:28 +02:00
Christian König
31be6183d5 drm/radeon: fix fence init after resume
Start with last signaled fence number instead
of last emitted one.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:21 +02:00
Christian König
bf66625e02 drm/radeon: fix fence value access
It is possible that radeon_fence_process is called
after writeback is disabled for suspend, leading
to an invalid read of register 0x0.

This fixes a problem for me where the fence value
is temporary incremented by 0x100000000 on
suspend/resume.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:15 +02:00
Christian König
07a713305a drm/radeon: fix ring commit padding
We don't need to pad anything if the number of dwords
written to the ring already matches the requirements.

Fixes some "writting more dword to ring than expected"
warnings.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:08 +02:00
Jerome Glisse
dee53e7fb3 drm/radeon: add an exclusive lock for GPU reset v2
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.

The GPU reset path take the semaphore as a writer ensuring that
no concurrent reset take place.

v2: init rw semaphore

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:32:02 +02:00
Christian König
93bf888c5c drm/radeon: fix fence related segfault in CS
Don't return success if scheduling the IB fails, otherwise
we end up with an oops in ttm_eu_fence_buffer_objects.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2012-07-17 10:31:54 +02:00
Christian König
35e56bd0a4 drm/radeon: add error handling to radeon_vm_unbind_locked
Waiting for a fence can fail for different reasons,
the most common is a deadlock.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:31:47 +02:00
Christian König
7ecc45e3ef drm/radeon: add error handling to fence_wait_empty_locked
Instead of returning the error handle it directly
and while at it fix the comments about the ring lock.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-07-17 10:31:39 +02:00
Alan Cox
6469195940 gma500,cdv: Fix the brightness base
Some desktop environments carefully save and restore the brightness
settings from the previous boot.  Unfortunately they don't all check to
see if the range has changed.  The end result is that they restore a
brightness of 100/lots not 100/100.

As the old driver and the non-free GMA36xx driver both use 0-100 we thus
need to go back doing the same thing to avoid users getting a mysterious
black screen after boot.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-07-16 09:20:33 -07:00
Alan Cox
166973e506 gma500: move the ASLE enable
Otherwise we end up getting the masks wrong, can get events before we
are doing power control and other ungood things.  Again this is a
regression fix where the ordering of handling was disturbed by other
work, and the user experience on some boxes is a blank screen.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-07-16 09:20:33 -07:00
Alan Cox
f507598b06 gma500: Fix lid related crash
We now set up the lid timer before we set up the backlight.  On some
devices that causes a crash as we do a backlight change before or during
the setup.

As this fixes a crash on boot regression on some setups it ought to go
in ASAP, especially as all the user gets is a blank screen.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Tested-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-07-16 09:20:33 -07:00
Chris Wilson
6b9d89b436 drm: Add colouring to the range allocator
In order to support snoopable memory on non-LLC architectures (so that
we can bind vgem objects into the i915 GATT for example), we have to
avoid the prefetcher on the GPU from crossing memory domains and so
prevent allocation of a snoopable PTE immediately following an uncached
PTE. To do that, we need to extend the range allocator with support for
tracking and segregating different node colours.

This will be used by i915 to segregate memory domains within the GTT.

v2: Now with more drm_mm helpers and less driver interference.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>
2012-07-16 05:59:37 +10:00
Dave Airlie
49099c4991 drm: fail gracefully when proc isn't setup.
If drm can't find proc it should fail more gracefully, than just
oopsing, this tests drm_class is NULL, and sets it to NULL in the
fail paths.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-16 05:57:03 +10:00
Dave Airlie
12f0e670ff Merge tag 'drm-intel-next-2012-07-06' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes:
New pull for -next. Highlights:
- rc6/turbo support for hsw (Eugeni)
- improve corner-case of the reset handling code - gpu reset handling
  should be rock-solid now
- support for fb offset > 4096 pixels on gen4+ (yeah, you need some fairly
  big screens to hit that)
- the "Flush Me Harder" patch to fix the gen6+ fallout from disabling the
  flushing_list
- no more /dev/agpgart on gen6+!
- HAS_PCH_xxx improvements from Paulo
- a few minor bits&pieces all over, most of it in thew hsw code

* tag 'drm-intel-next-2012-07-06' of git://people.freedesktop.org/~danvet/drm-intel: (40 commits)
  drm/i915: program FDI_RX TP and FDI delays
  drm/i915: introduce for_each_encoder_on_crtc
  drm/i915: adjust framebuffer base address on gen4+
  drm/i915: introduce crtc->dspaddr_offset
  drm/i915: Reject page flips with changed format/offset/pitch
  drm/i915: Zero initialize mode_cmd
  drm/i915: don't return a spurious -EIO from intel_ring_begin
  drm/i915: properly SIGBUS on I/O errors
  drm/i915: don't hang userspace when the gpu reset is stuck
  drm/i915: non-interruptible sleeps can't handle -EAGAIN
  drm/i915: don't trylock in the gpu reset code
  drm/i915: fix PIPE_DDI_PORT_MASK
  drm/i915: prevent bogus intel_update_fbc notifications
  drm/i915: re-initialize DDI buffer translations after resume
  drm/i915: don't ironlake_init_pch_refclk() on LPT
  drm/i915: get rid of dev_priv->info->has_pch_split
  drm/i915: add PCH_NONE to enum intel_pch
  drm/i915: prefer wide & slow to fast & narrow in DP configs
  drm/i915: fix up ilk rc6 disabling confusion
  drm/i915: move force wake support into intel_pm
  ...
2012-07-14 18:15:21 +10:00
Eugeni Dodonov
4acf518626 drm/i915: program FDI_RX TP and FDI delays
This is required for a stable FDI connection.

v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni.

CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 15:09:03 +02:00
Daniel Vetter
6c2b7c1208 drm/i915: introduce for_each_encoder_on_crtc
We already have this pattern at quite a few places, and moving part of
the modeset helper stuff into the driver will add more.

v2: Don't clobber the crtc struct name with the macro parameter ...

v3: Convert two more places noticed by Paulo Zanoni.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 15:06:33 +02:00
Daniel Vetter
c2c7513124 drm/i915: adjust framebuffer base address on gen4+
The tileoffset register only supports a limited offset in x/y of 4096,
so for giant screen configuration with a shared fb we wrap around.

Fix this by computing a linear offset in tiles (pages) and only use
the tileoffset register to offset within the tile.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 13:36:01 +02:00
Daniel Vetter
e506a0c638 drm/i915: introduce crtc->dspaddr_offset
To avoid recomputing the display framebuffer offset on gen2/3
pageflips. This is also prep work to do similar trickery on gen4+

Also:
- kill "Start", such upper-case remnants from the ddx must surely die.
- rename "Offset" to linear_offset, to make it clearer that on gen4+
  this is only used by the hw for linear buffers, for tiled buffers it
  uses the TILEOFF register.
- call DSAPADDR DSPLINOFF on gen4+ for the same reason (and because
  the documentation really renamed the register).

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 13:34:14 +02:00
Ville Syrjälä
e6a595d2db drm/i915: Reject page flips with changed format/offset/pitch
MI display flips can't handle some changes in the framebuffer
format or layout. Return an error in such cases.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 13:29:45 +02:00
Ville Syrjälä
3a7f2f6a9e drm/i915: Zero initialize mode_cmd
Zero initialize the mode_cmd structure when creating the kernel
framebuffer. Avoids having uninitialized data in offsets[0] for
instance.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 13:27:58 +02:00
Daniel Vetter
de2b998552 drm/i915: don't return a spurious -EIO from intel_ring_begin
The issue with this check is that it results in userspace receiving an
-EIO while the gpu reset hasn't completed, resulting in fallback to sw
rendering or worse.

Now there's also a stern comment in intel_ring_wait_seqno saying that
intel_ring_begin should not return -EAGAIN, ever, because some callers
can't handle that. But after an audit of the callsites I don't see any
issues. I guess the last problematic spot disappeared with the removal
of the pipelined fencing code.

So do the right thing and call check_wedge, which should properly
decide whether an -EAGAIN or -EIO is appropriate if wedged is set.

Note that the early check for a wedged gpu before touching the ring is
rather important (and it took me quite some time of acting like the
densest doofus to figure that out): If we don't do that and the gpu
died for good, not having been resurrect by the reset code, userspace
can merrily fill up the entire ring until it notices that something is
amiss.

Allowing userspace to emit more render, despite that we know that it
will fail can't lead to anything good (and by experience can lead to
all sorts of havoc, including angering the OOM gods and hard-hanging
the hw for good).

v2: Fix EAGAIN mispell, noticed by Chris Wilson.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 10:03:45 +02:00
Daniel Vetter
a9340ccab5 drm/i915: properly SIGBUS on I/O errors
... instead of looping endless with no hope of ever serving that
page-fault. We only need to break out of this loop when the gpu died,
to run the reset work (and hopefully resurrect it).

To clarify questions Chris raised on irc: This is about handling I/O
errors not from our own code, but e.g. when the disk died when trying
to swap in a gem bo. So this patch remidies the issue that the current
handling only handles gpu-death-induced cases of -EIO. Admittedly,
dying disks are much rarer than hanging gpus ...To clarify questions
Chris raised on irc: This is about handling I/O errors not from our
own code, but e.g. when the disk died when trying to swap in a gem bo.
So this patch remidies the issue that the current handling only
handles gpu-death-induced cases of -EIO. Admittedly, dying disks are
much rarer than hanging gpus ...

This seems to have been lost in:

commit d9bc7e9f32
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Feb 7 13:09:31 2011 +0000

    drm/i915: Fix infinite loop regression from 21dd3734

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 10:03:01 +02:00
Daniel Vetter
0a6759c6ba drm/i915: don't hang userspace when the gpu reset is stuck
With the gpu reset no longer using a trylock we've increased the
chances of userspace getting stuck quite a bit. To make that
(hopefully) rare case more paletable time out when waiting for the gpu
reset code to complete and signal this little issue to the caller by
returning -EIO.

This should help userspace to somewhat gracefully fall back and
hopefully allow the user to grab some logs and reboot the machine
(instead of staring at a frozen X screen in agony).

Suggested by Chris Wilson because I've been stubborn about allowing
the gpu reset code no to fail, ever (by removing the trylock).

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 10:02:24 +02:00
Daniel Vetter
d6b2c790a4 drm/i915: non-interruptible sleeps can't handle -EAGAIN
So don't return -EAGAIN, even in the case of a gpu hang. Remap it to
-EIO instead. Note that this isn't really an issue with
interruptability, but more that we have quite a few codepaths (mostly
around kms stuff) that simply can't handle any errors and hence not
even -EAGAIN. Instead of adding proper failure paths so that we could
restart these ioctls we've opted for the cheap way out of sleeping
non-interruptibly.  Which works everywhere but when the gpu dies,
which this patch fixes.

So essentially interruptible == false means 'wait for the gpu or die
trying'.'

This patch is a bit ugly because intel_ring_begin is all non-interruptible
and hence only returns -EIO. But as the comment in there says,
auditing all the callsites would be a pain.

To avoid duplicating code, reuse i915_gem_check_wedge in __wait_seqno
and intel_wait_ring_buffer. Also use the opportunity to clarify the
different cases in i915_gem_check_wedge a bit with comments.

v2: Don't access dev_priv->mm.interruptible from check_wedge - we
might not hold dev->struct_mutex, making this racy. Instead pass
interruptible in as a parameter. I've noticed this because I've hit a
BUG_ON(!mutex_is_locked) at the top of check_wedge. This has been
added in

commit b4aca0106c
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Wed Apr 25 20:50:12 2012 -0700

    drm/i915: extract some common olr+wedge code

although that commit is missing any justification for this. I guess
it's just copy&paste, because the same commit add the same BUG_ON
check to check_olr, where it indeed makes sense.

But in check_wedge everything we access is protected by other means,
so this is superflous. And because it now gets in the way (we add a
new caller in __wait_seqno, which can be called without
dev->struct_mutext) let's just remove it.

v3: Group all the i915_gem_check_wedge refactoring into this patch, so
that this patch here is all about not returning -EAGAIN to callsites
that can't handle syscall restarting.

v4: Add clarification what interuptible == fales means in our code,
requested by Ben Widawsky.

v5: Fix EAGAIN mispell noticed by Chris Wilson.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 10:01:14 +02:00
Daniel Vetter
d54a02c041 drm/i915: don't trylock in the gpu reset code
Simply failing to reset the gpu because someone else might still hold
the mutex isn't a great idea - I see reliable silent reset failures.
And gpu reset simply needs to be reliable and Just Work.

"But ... the deadlocks!"

We already kick all processes waiting for the gpu before launching the
reset work item. New waiters need to check the wedging state anyway
and then bail out. If we have places that can deadlock, we simply need
to fix them.

"But ... testing!"

We have the gpu hangman, and if the current gpu load gem_exec_nop
isn't good enough to hit a specific case, we can add a new one.

"But ...  don't we return -EAGAIN for non-interruptible calls to
wait_seqno now?"

Yep, but this problem already exists in the current code. A follow up
patch will remedy this by returning -EIO for non-interruptible sleeps
if the gpu died and the low-level wait bails out with -EAGAIN.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 10:00:46 +02:00
Paulo Zanoni
4c3c115a1e drm/i915: fix PIPE_DDI_PORT_MASK
Only bits 30:28, bit 31 is PIPE_DDI_FUNC_ENABLE.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:58:10 +02:00
Eugeni Dodonov
4c243e2573 drm/i915: prevent bogus intel_update_fbc notifications
This pollutes dmesg output even if we do not have FBC for the device, so
move the DRM_DEBUG_KMS statement lower.

v2: just kill the message as suggested by Daniel.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:07 +02:00
Eugeni Dodonov
a8f78b5822 drm/i915: re-initialize DDI buffer translations after resume
This is necessary for the modesetting to work correctly after a
suspend-resume cycle. Without this, the pipes and clocks got the correct
configuration, but the underlying DDI buffers configuration was lost.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:06 +02:00
Paulo Zanoni
40579abed0 drm/i915: don't ironlake_init_pch_refclk() on LPT
This function is used to set the PCH_DREF_CONTROL register, which does
not exist on LPT anymore.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:06 +02:00
Paulo Zanoni
45e6e3a1cd drm/i915: get rid of dev_priv->info->has_pch_split
Previously we had has_pch_split to tell us whether we had a PCH or not
and we also had dev_priv->pch_type to tell us which kind of PCH it
was, but it could only be used if we were 100% sure we did have a PCH.
Now that PCH_NONE was added to dev_priv->pch_type we don't need
has_pch_split anymore: we can just check for pch_type != PCH_NONE.

The HAS_PCH_{IBX,CPT,LPT} macros use dev_priv->pch_type, so they can
only be called after intel_detect_pch. The HAS_PCH_SPLIT macro looks
at dev_priv->info->has_pch_split, which is available earlier.

Since the goal is to implement HAS_PCH_SPLIT using dev_priv->pch_type
instead of dev_priv->info->has_pch_split, we need to make sure that
intel_detect_pch is called before any calls to HAS_PCH_SPLIT are made.
So we moved the intel_detect_pch call to an earlier stage.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:05 +02:00
Paulo Zanoni
f035083055 drm/i915: add PCH_NONE to enum intel_pch
And rely on the fact that it's 0 to assume that machines without a PCH
will have PCH_NONE as dev_priv->pch_type.

Just today I finally realized that HAS_PCH_IBX is true for machines
without a PCH. IMHO this is totally counter-intuitive and I don't
think it's a good idea to assume that we're going to check for
HAS_PCH_IBX only after we check for HAS_PCH_SPLIT.

I believe that in the future we'll have more PCH types and checks
like:

    if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))

will become more and more common. There's a good chance that we may
break non-PCH machines by adding these checks in code that runs on all
machines. I also believe that the HAS_PCH_SPLIT check will become less
common as we add more and more different PCH types. We'll probably
start replacing checks like:

    if (HAS_PCH_SPLIT(dev))
        foo();
    else
        bar();

with:

    if (HAS_PCH_NEW(dev))
        baz();
    else if (HAS_PCH_OLD(dev) || HAS_PCH_IBX(dev))
        foo();
    else
        bar();

and this may break gen 2/3/4.

As far as we have investigated, this patch will affect the behavior of
intel_hdmi_dpms and intel_dp_link_down on gen 4. In both functions the
code inside the HAS_PCH_IBX check is for IBX-specific workarounds, so
we should be safe. If we start bisecting gen 2/3/4 bugs to this commit
we should consider replacing the HAS_PCH_IBX checks with something
else.

V2: Improve commit message, list possible side effects and solution.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:05 +02:00
Jesse Barnes
2514bc510d drm/i915: prefer wide & slow to fast & narrow in DP configs
High frequency link configurations have the potential to cause trouble
with long and/or cheap cables, so prefer slow and wide configurations
instead.  This patch has the potential to cause trouble for eDP
configurations that lie about available lanes, so if we run into that we
can make it conditional on eDP.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
Tested-by: peter@colberg.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:05 +02:00
Daniel Vetter
930ebb4624 drm/i915: fix up ilk rc6 disabling confusion
While creating the new enable/disable_gt_powersave functions in

commit 8090c6b9da
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jun 24 16:42:32 2012 +0200

    drm/i915: wrap up gt powersave enabling functions

I've botched up the handling of ironlake_disable_rc6. Fix this up by
calling it at the right place. Note though that ironlake_disable_rc6
does a bit more than just disabling rc6 - it also tears down all the
allocated context objects.

Hence we need to move intel_teardown_rc6 out and directly call it from
intel_modeset_cleanup.

Also properly mark ironlake_enable_rc6 as static and kill the un-used
declaration in i915_drv.h.

Note: In review a question popped out why disable_rc6 also tears down
the backing object and why we should move that out - it's simply for
consistency with gen6+ rps code, which does it that way.

Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:04 +02:00
Eugeni Dodonov
6590190d12 drm/i915: move force wake support into intel_pm
This commit moves force wake support routines into intel_pm modules, and
exports the gen6_gt_check_fifodbg routine (used in I915_READ).

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:04 +02:00
Eugeni Dodonov
1544d9d573 drm/i915: enable RC6 workaround on Haswell
For Haswell, on some of the early hardware revisions, it is possible to
run into issues when RC6 state is enabled and when pipes change state.

v2: add comment saying that this is for early revisions only.

v3: beautify as suggested by Daniel Vetter.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:03 +02:00
Eugeni Dodonov
cad2a2d776 drm/i915: introduce haswell_init_clock_gating
This is based on Ivy Bridge clock gating for now, but is subject to
changes in the future.

Note: Compared to the ivb clock gating this drops the the IDICOS
medium uncore sharing tuned in

commit 208482232d
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri May 4 18:58:59 2012 -0700

    drm/i915: set IDICOS to medium uncore resources

Eugeni wants to benchmark the effect of this first.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: added note]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:03 +02:00
Eugeni Dodonov
8850948450 drm/i915: disable RC6 when disabling rps
We weren't disabling RC6 bits when bringing down RPS.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:02 +02:00
Eugeni Dodonov
4a637c2c83 drm/i915: enable RC6 by default on Haswell
It should be working so let's turn it on by default and catch any possible
issues faster.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:02 +02:00
Eugeni Dodonov
7cf50fc8d7 drm/i915: slightly improve gt enable/disable routines
Just a cosmetic change to simplify the if statement.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:56:02 +02:00
Eugeni Dodonov
5a7dc92a0b drm/i915: add RPS configuration for Haswell
Most of the RPS and RC6 enabling functionality is similar to what we had
on Gen6/Gen7, so we preserve most of the registers.

Note that Haswell only has RC6, so account for that as well. As suggested
by Daniel Vetter, to reduce the amount of changes in the patch, we still
write the RC6p/RC6pp thresholds, but those are ignored on Haswell.

Note: Some discussion about the nature of the new tuning constants
popped up in review - the answer is that we don't know why they've
changed, but the guide from VPG with the magic numbers simply has
different values now.

v2: Squash fix for ?: vs | operation precende bug into this patch.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Added note to commit message. Squashed fix.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-05 09:55:16 +02:00
Eugeni Dodonov
e7911c48a0 drm/i915: support Haswell force waking
There is a different ACK register for force wake on Haswell, so account
for that.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-03 22:15:21 +02:00
Chris Wilson
c4de7b0ffd drm/i915: Implement w/a for sporadic read failures on waking from rc6
As a w/a to prevent reads sporadically returning 0, we need to wait for
the GT thread to return to TC0 before proceeding to read the registers.

v2: adapt for Haswell changes (Eugeni).

v3: use wait_for_atomic_us for thread status polling.

v3: *really* use wait_for_atomic for polling.

References: https://bugs.freedesktop.org/show_bug.cgi?id=50243
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-03 22:09:21 +02:00
Chris Wilson
990bbdadab drm/i915: Group the GT routines together in both code and vtable
Tidy up the routines for interacting with the GT (in particular the
forcewake dance) which are scattered throughout the code in a single
structure.

v2: use wait_for_atomic for polling.

v3: *really* use wait_for_atomic for polling.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-03 22:08:46 +02:00
Daniel Vetter
9f846a16d2 drm/i915: kick any firmware framebuffers before claiming the gtt
Especially vesafb likes to map everything as uc- (yikes), and if that
mapping hangs around still while we try to map the gtt as wc the
kernel will downgrade our request to uc-, resulting in abyssal
performance.

Unfortunately we can't do this as early as readon does (i.e. as the
first thing we do when initializing the hw) because our fb/mmio space
region moves around on a per-gen basis. So I've had to move it below
the gtt initialization, but that seems to work, too. The important
thing is that we do this before we set up the gtt wc mapping.

Now an altogether different question is why people compile their
kernels with vesafb enabled, but I guess making things just work isn't
bad per se ...

v2:
- s/radeondrmfb/inteldrmfb/
- fix up error handling

v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky.

v4: Jani Nikula complained about the pointless bool primary
initialization.

v5: Don't oops if we can't allocate, noticed by Chris Wilson.

v6: Resolve conflicts with agp rework and fixup whitespace.

This is commit e188719a28 in drm-next.

Backport to 3.5 -fixes queue requested by Dave Airlie - due to grub
using vesa on fedora their initrd seems to load vesafb before loading
the real kms driver. So tons more people actually experience a
dead-slow gpu. Hence also the Cc: stable.

Cc: stable@vger.kernel.org
Reported-and-tested-by: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-03 11:18:48 +01:00
Takashi Iwai
7b668ebe2f drm: edid: Don't add inferred modes with higher resolution
When a monitor EDID doesn't give the preferred bit, driver assumes
that the mode with the higest resolution and rate is the preferred
mode.  Meanwhile the recent changes for allowing more modes in the
GFT/CVT ranges give actually more modes, and some modes may be over
the native size.  Thus such a mode would be picked up as the preferred
mode although it's no native resolution.

For avoiding such a problem, this patch limits the addition of
inferred modes by checking not to be greater than other modes.
Also, it checks the duplicated mode entry at the same time.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-03 11:18:10 +01:00
Jerome Glisse
1ef5325b23 drm/radeon: fix rare segfault
In gem idle/busy ioctl the radeon object was derefenced after
drm_gem_object_unreference_unlocked which in case the object
have been destroyed lead to use of a possibly free pointer with
possibly wrong data.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-07-03 11:17:09 +01:00
Ben Widawsky
146937e582 drm/i915: linuxify create_hw_context()
Daniel complained about this on initial review, but he graciously moved
the patches forward. As promised, I am delivering the desired cleanup
now.

Hopefully I didn't screw the trivial patch up ;-)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-29 19:43:59 +02:00
Alex Deucher
74da01dcfb drm/radeon: move r100_enable_bm to a more logic place
It was stuck right in the middle of the gart functions.
Move next to the bm_disable function and where it is used.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-29 15:14:47 +01:00
Alex Deucher
0242f74d29 drm/radeon: clean up CS functions in r100.c
Consolidate the CS functions to one section of the file.
Previously they were spread all around.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-29 15:14:38 +01:00
Alex Deucher
c21b328ea8 drm/radeon: fix VM page table setup on SI
Cayman and trinity allow for variable sized VM page
tables, but SI requires that all page tables be the
same size.  The current code assumes variablely sized
VM page tables so SI may end up with part of each page
table overlapping with other memory which could end
up being interpreted by the VM hw as garbage.

Change the code to better accomodate SI.  Allocate enough
space for at least 2 full page tables and always set
last_pfn to max_pfn on SI so each VM is backed by a full
page table.  This limits us to only 2 VMs active at any
given time on SI.  This will be rectified and the code can
be reunified once we move to two level page tables.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-29 15:13:07 +01:00
Paulo Zanoni
e486fad913 drm/i915: fix PIPE_WM_LINETIME definition
Looks like a copy/paste error.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-28 21:39:28 +02:00
Daniel Vetter
97f209bcfc drm/i915: "Flush Me Harder" required on gen6+
The prep to remove the flushing list in

commit cc889e0f6c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jun 13 20:45:19 2012 +0200

    drm/i915: disable flushing_list/gpu_write_list

causes quite some decent regressions. We can fix this by setting the
CS_STALL bit to ensure that the following seqno write happens only
after the cache flush has completed. But only do that when the caller
actually wants the flush (and not also when we invalidate caches
before starting the next batch).

I've looked through all our ancient scrolls about gen6+ pipe control
workarounds, and this seems to be indeed a legal combination: We're
allowed to set the CS_STALL bit when we flush the render cache (which
we do).

While yelling at this code, also pass back the return value from
intel_emit_post_sync_nonzero_flush properly.

v2: Instead of emitting more pipe controls, set the CS_STALL bit on
the write flush as suggested by Chris Wilson. It seems to work, too.

Cc: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51436
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51429
Tested-by: Lu Hua <huax.lu@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-28 21:06:25 +02:00
Dave Airlie
4391b2cf4b Merge tag 'drm-intel-next-2012-06-21-merged' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
Daniel writes:
 New -next pull request. Highlights:
 - Remaining vlv patches from Jesse et al.
 - Some hw workarounds from Jesse
 - hw context support from Ben
 - full uncore sharing on ivb
 - prep work to move the gtt code from intel-gtt.c to drm/i915 for gen6+
 - some backlight code improvements
 - leftovers for the timeout ioctl (we've forgotten the getparam)
 - ibx transcoder workarounds
 - some smaller fixlets and improvements
 - the new version of the "dont rely on HPD exclusively for VGA" patch

 Wrt regressions QA reported quite a few this time around.
 - The piglit/kernel-test fallout all has patches that are just awaiting
   review and merging into the next -next cycle.
 - Which just leaves a bunch of bugs about new modelines that don't work.
   It looks like these are all due to the new 16:9/16:10 modes in 3.5
   (yeah, only in this manual testing cycle did the git branch used by QA
   contain a backmerge of mainline with these patches).  Although I haven't
   yet confirmed this by letting our QA test the revert of that series.
 - Wrt bugs in general I'm trying to fight down some of our long-standing
   backlight issues (not regressions), but this seems to be a game of
   "you move, you lose" ... :("

Dropped merge bits since this had an -rc4 merge in it to fix some ugly
conflicts.
2012-06-28 13:38:39 +01:00
Dave Airlie
2266b058d3 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Daniel writes:
"Two tiny patches and one revert:
- Kill a bogus error message introduced in 3.4, further Bspec reading
  indicates that this is how the hw is supposed to work.
- Reorder one backlight register restore, fixing broken backlight on some
  machines after resume.
- Revert a hack from Jesse for ivb backlight control - it breaks the
  backlight controls on my shiny new ivb laptop."

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  Revert "drm/i915: allow PCH PWM override on IVB"
  drm/i915: Fix eDP blank screen after S3 resume on HP desktops
  drm/i915: rip out the PM_IIR WARN
2012-06-27 19:56:20 +01:00
Daniel Vetter
7aa1e7f06d Revert "drm/i915: allow PCH PWM override on IVB"
This reverts commit f82cfb6bcd.

This breaks the backlight controls on my IVB asus zenbook with an eDP
panel.

I guess the right fix would be to read this bit and use either the pch
or the cpu register to frob the backlight values. But that is stuff
for -next.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-27 20:26:30 +02:00
Jesper Juhl
a8b0bbabf7 drm/i915/sprite: Fix mem leak in intel_plane_init()
If we ever hit the default case in the switch statement we'll return
from the function without freeing the memory we just allocated to
'intel_plane' (but that has not been used).

This patch gets rid of the leak by freeing the memory just before we
return.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-27 17:03:24 +02:00
Jesse Barnes
f4d7105648 drm/i915: correct IVB default sprite format
We shouldn't hit this path anyway, but make it use the IVB sprite format
definition to avoid confusion.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-27 17:03:23 +02:00
Jesse Barnes
e86fe0d317 drm/i915: mask tiled bit when updating IVB sprites
Or going from tiled to untiled may break.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-27 17:03:23 +02:00
Dan Carpenter
0317c6cecd drm/i915/bios: cleanup return type of intel_parse_bios()
These are unintuitive.  These are type bool and return -1 casted to true
on failure.  Let's just make it return an int.  The callers don't care,
but let's change this as a cleanup.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-27 10:17:51 +01:00
Dave Airlie
e9bf5f36b0 drm/nouveau: add license header to prime.
Just forgot this when I posted it, and yes I'm the only person
to have changed the file since.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-27 09:27:35 +01:00
Ben Skeggs
9bd0c15fcf drm/nouveau/fbcon: using nv_two_heads is not a good idea
nv_two_heads() was never meant to be used outside of pre-nv50 code.  The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).

The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..

This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-26 12:16:43 +01:00
Daniel Vetter
01a06850fb drm/i915: disable drm agp support for !gen3 with kms enabled
This is the quick&dirty way Dave Airlie suggested to workaround the
midlayer drm agp brain-damange. Note that i915_probe is only called
when the driver has ksm enabled, so no need to check for that.

We also need to move the intel_agp_enabled check at the right place.
Note that the only thing this does is enforce the correct module load
order (by using a symbol from intel-agp.ko) to ensure that the fake
agp driver is ready before the drm core tries to set up the agp stuff.

v2: Add a comment to explain why gen3 needs all this legacy fake agp
stuff - we've shipped an XvMC library with a kms-enabled ddx that
requires it (but only on gen3).

v3: Make it clear that this is only a gen3 issue in the comment.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-25 21:10:14 +02:00
Daniel Vetter
87207ca20e drm/i915: don't use dev->agp
This single leftover use is due to a patch that went into 3.5 through
-fixes. With the fake agp stuff on demise, at least for gen6+ we can't
use this any more.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-25 21:08:44 +02:00
Daniel Vetter
79f5b2c759 drm/i915: make enable/disable_gt_powersave locking consistent
The enable functions grabbed dev->struct_mutex themselves, whereas
the disable functions expected dev->struct_mutex to be held by the
caller. Move the locking out to the (currently only) callsite of
intel_enable_gt_powersave to make this more consistent.

Originally this was prep work for future patches, but I've chased down
a totally wrong alley. Still, I think this is a sensible
clarification.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-25 21:07:29 +02:00
Daniel Vetter
8090c6b9da drm/i915: wrap up gt powersave enabling functions
... instead of calling each one for each generation indiviudally.

Notice that we've already managed to be inconsistent, the resume path
is missing an IS_VLV check. As a nice benefit we can mark all the
platform specific enable/disable functions as static and hide them in
intel_pm.c

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-25 21:07:03 +02:00
Daniel Vetter
7b0cfee1a2 Linux 3.5-rc4
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (GNU/Linux)
 
 iQEcBAABAgAGBQJP53AxAAoJEHm+PkMAQRiGs2QH/RaqkXz96fwjhDcyiKpDqA3c
 kGuS5mz5cOhnqKSmR88HFm6pwuhLux/qSJzeAmoQy1MC8a0ACx7AnANW0lfN3/qe
 /HGYz8h60yCL/fhn8/bUYtdt9xsoDqoDcq/ooFl9mcsJGWbC6WeMSZU5dAUYqviE
 qFrp5zjY07FG53CRGT0hFpezQNwNL+VLH30CF9LD+fJLPVEYum2zBNGXWM42rcw5
 fxzGL/6SO8YqA/Upic1ht6HAd6s5LOrlST7qvnyXUMvRXN5z/Y92ueYJZefkS1Om
 ohuLIKM2bv9/dJS67H8N2baSKGCzBdfSe5/5WaHdLYW9MiVju0wRl6HPJtAMrkk=
 =H8t8
 -----END PGP SIGNATURE-----

Merge tag 'v3.5-rc4' into drm-intel-next-queued

I want to merge the "no more fake agp on gen6+" patches into
drm-intel-next (well, the last pieces). But a patch in 3.5-rc4 also
adds a new use of dev->agp. Hence the backmarge to sort this out, for
otherwise drm-intel-next merged into Linus' tree would conflict in the
relevant code, things would compile but nicely OOPS at driver load :(

Conflicts in this merge are just simple cases of "both branches
changed/added lines at the same place". The only tricky part is to
keep the order correct wrt the unwind code in case of errors in
intel_ringbuffer.c (and the MI_DISPLAY_FLIP #defines in i915_reg.h
together, obviously).

Conflicts:
	drivers/gpu/drm/i915/i915_reg.h
	drivers/gpu/drm/i915/intel_ringbuffer.c

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-25 19:10:36 +02:00
Dave Airlie
d42f0349f3 drm/udl: Make sure to get correct endian keys from vendor descriptor
This is a port of
commit b49f184b64
Author: Ben Collins <bcollins@ubuntu.com>
from udlfb to udl kms driver.

The driver was not using le16_to_cpu when reading keys from the vendor
descriptor, causing incorrect parsing. Mainly, sku_pixel_limit was not
being parsed on big-endian systems. This would result in a blank screen
on big-endian CPUs where the DL chips's max mode was smaller than the
monitor's native mode.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-25 07:43:12 +01:00
Takashi Iwai
6db65cbb94 drm/i915: Fix eDP blank screen after S3 resume on HP desktops
This patch fixes the problem on some HP desktop machines with eDP
which give blank screens after S3 resume.

It turned out that BLC_PWM_CPU_CTL must be written after
BLC_PWM_CPU_CTL2.  Otherwise it doesn't take effect on these
SNB machines.

Tested with 3.5-rc3 kernel.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-23 00:01:42 +02:00
Daniel Vetter
58bf8062d0 drm/i915: rip out the PM_IIR WARN
After banging my head against this for the past few months, I still
don't see how this could possible race under the premise that once an
irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
until we unmask it in PM_IMR.

Still, we have reports of this being seen in the wild. Now Bspec has
this little bit of lovely language in the PMIIR register:

Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":

"For each bit, the IIR can store a second pending interrupt if two or
more of the same interrupt conditions occur before the first condition
is cleared. Upon clearing the interrupt, the IIR bit will momentarily
go low, then return high to indicate there is another interrupt
pending."

Now if we presume that PMIMR only prevent new interrupts from being
queued, we could easily end up masking an interrupt and clearing it,
but the 2nd pending interrupt setting the bit in PMIIR right away
again. Which leads, the next time the irq handler runs, to hitting the
WARN.

Also, no bad side effects of this have ever been reported. And we've
tracked down our issues with the gpu turbo getting stuck to bogus
interrupt generation limits in th RPLIMIT register.

So let's just rip out this WARN as bogus and call it a day. The only
shallow thing here is that this 2-deep irq queue in the hw makes you
wonder how racy the windows irq handler is ...

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-23 00:01:41 +02:00
Sjoerd Simons
9756fe38d1 drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13
This box claims to have an LVDS interface but doesn't
actually have one.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-22 10:41:17 +02:00
Dave Airlie
7c0143341a Merge branch 'next' of git://people.freedesktop.org/~deathsimple/linux into drm-core-next
* 'next' of git://people.freedesktop.org/~deathsimple/linux:
  drm/radeon: replace cs_mutex with vm_mutex v3
  drm/radeon: replace pflip and sw_int counters with atomics
  drm/radeon: apply Murphy's law to the kms irq code v3
  drm/radeon: fix & improve ih ring handling v3
  drm/radeon: remove some unneeded structure members
  drm/radeon: replace vmram_mutex with mclk_lock v2
  drm/radeon: rework ring syncing code
  drm/radeon: add infrastructure for advanced ring synchronization v2
  drm/radeon: remove radeon_fence_create
2012-06-21 11:58:23 +01:00
Yuanhan Liu
4ef7fe7c66 drm: use format %d to print error code
It is more readable by printing "ret = -1" than "ret = 0xffffffff"

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-21 09:34:42 +01:00
Daniel Vetter
b196a4980f drm/edid: don't return stack garbage from supports_rb
We need to initialize this to false, because the is_rb callback only
ever sets it to true.

Noticed while reading through the code.

Cc: stable@vger.kernel.org
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-21 09:34:13 +01:00
Sachin Kamat
b375de0b09 drm: Add missing static storage class specifier
Fixes the following sparse warning:
drivers/gpu/drm/drm_info.c:238:5:
warning: symbol 'drm_gem_one_name_info' was not declared. Should it be static?

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-21 09:33:10 +01:00
Christian König
36ff39c404 drm/radeon: replace cs_mutex with vm_mutex v3
Try to remove or replace the cs_mutex with a
vm_mutex where it is still needed.

v2: fix locking order
v3: rebased on drm-next

Signed-off-by: Christian König <deathsimple@vodafone.de>
2012-06-21 09:40:34 +02:00
Christian Koenig
736fc37fd7 drm/radeon: replace pflip and sw_int counters with atomics
So we can skip the locking. Also renames sw_int to
ring_int, cause that better matches its purpose.

Signed-off-by: Christian Koenig <christian.koenig@amd.com>
2012-06-21 09:38:53 +02:00
Christian Koenig
fb98257a9d drm/radeon: apply Murphy's law to the kms irq code v3
1. It is really dangerous to have more than one
   spinlock protecting the same information.

2. radeon_irq_set sometimes wasn't called with lock
   protection, so it can happen that more than one
   CPU would tamper with the irq regs at the same
   time.

3. The pm.gui_idle variable was assuming that the 3D
   engine wasn't becoming idle between testing the
   register and setting the variable. So just remove
   it and test the register directly.

v2: Also handle the hpd irq code the same way.
v3: Rename hpd parameter for clarification.

Signed-off-by: Christian Koenig <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2012-06-21 09:38:50 +02:00
Christian Koenig
c20dc3698d drm/radeon: fix & improve ih ring handling v3
The spinlock was actually there to protect the
rptr, but rptr was read outside of the locked area.

Also we don't really need a spinlock here, an
atomic should to quite fine since we only need to
prevent it from being reentrant.

v2: Keep the spinlock....
v3: Back to an atomic again after finding & fixing the real bug.

Signed-off-by: Christian Koenig <christian.koenig@amd.com>
2012-06-21 09:38:48 +02:00
Christian Koenig
6823d74003 drm/radeon: remove some unneeded structure members
Signed-off-by: Christian Koenig <christian.koenig@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
2012-06-21 09:38:45 +02:00
Christian König
db7fce3983 drm/radeon: replace vmram_mutex with mclk_lock v2
It is a rw_semaphore now and only write locked
while changing the clock. Also the lock is renamed
to better reflect what it is protecting.

v2: Keep the ttm_vm_ops on IGPs

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
2012-06-21 09:38:43 +02:00
Christian König
220907d983 drm/radeon: rework ring syncing code
Move inter ring syncing with semaphores into the
existing ring allocations, with that we need to
lock the ring mutex only once.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
2012-06-21 09:38:40 +02:00
Christian König
68e250b7c2 drm/radeon: add infrastructure for advanced ring synchronization v2
v2: BUG_ON not matching rings.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
2012-06-21 09:38:38 +02:00
Christian König
876dc9f329 drm/radeon: remove radeon_fence_create
It is completely unnecessary to create fences
before they are emitted, so remove it and a bunch
of checks if fences are emitted or not.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
2012-06-21 09:38:35 +02:00
Jesse Barnes
ff049b6ce2 drm/i915: bind driver to ValleyView chipsets
With the code in place, we can bind the driver, should make bisect possible.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 22:52:49 +02:00
Jesse Barnes
7983117f0b drm/i915: enable display messages to GT on ValleyView
Enable the on-chip messaging between the display engine and the GT.

v2: use bit definitions for DPFLIPSTAT reg

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 22:52:42 +02:00
Jesse Barnes
31acc7f59a drm/i915: support page flipping on ValleyView
And restructure the IRQ handling a little.  We can use pipestat for most
things, and make sure we don't affect pipe events when enabling and
disabling vblank interupts.

We can leave vblank interrupts masked but enabled so we're not dependent
on the first client to toggle the disable timer.  We can also mask all
render based interrupts, since the ring code will handle unmasking them
for us.

v2: roll in vblank masking, remove unneeded variable (Daniel)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 22:51:26 +02:00
Jesse Barnes
9355360963 drm/i915: don't enable PPGTT on VLV yet
Needs some more work and testing.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 22:49:46 +02:00
Jesse Barnes
bd9e8413c9 drm/i915: VLV VGA port only handles on & off, like PCH VGA
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 22:49:45 +02:00
Jesse Barnes
f7dff0c9cb drm/i915: access VLV regs through read/write switch
Since the offsets have all moved around.

v2: switch IS_DISPLAYREG and IS_VALLEYVIEW checks around since the latter is
    cheaper (Daniel)
    bail out early in IS_DISPLAYREG if the reg is in the new range (Daniel)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Fixup if cascading fail that broke HAS_FORCEWAKE machines.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 22:47:15 +02:00
Alex Deucher
b7019b2f31 drm/radeon: SI tiling fixes for display
- Use the correct union for getting the tiling info
- Properly init the PIPE_CONFIG field for SI

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-20 19:55:56 +01:00
Dave Airlie
9c19415c23 Merge tag 'drm-intel-next-2012-06-04' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
Daniel Vetter writes:
rc2 is out the door so I've figured I'll annoy you with the first -next
pull request for 3.6 already. Highlights:
- new wait_rendring_timeout interface (Ben)
- l3 cache remapping and error uevent support (Ben)
- even more infoframes work from Paulo
- gen4 hotplug rework from Chris
- prep work to make Laurent Pincharts original mode constification for
 connector->mode_fixup possible

QA reported a few new bugs this time around, but no regressions afact. For
3.5 the only thing I'm aware of is the edp vdd dmesg spam Linus originally
reported - it looks like that might have been introduced in 3.5. But
somehow my brain is routinely offline when I work on that issue, so things
seem to take forever (and atm I'm at patch v4 for that little problem).

* tag 'drm-intel-next-2012-06-04' of git://people.freedesktop.org/~danvet/drm-intel: (39 commits)
  drm/i915: add min freq control to debugfs
  drm/i915: don't chnage the original mode in dp_mode_fixup
  drm/i915: adjusted_mode->clock in the dp mode_fixup
  drm/i915: compute the target_clock for edp directly
  drm/i915: extract object active state flushing code
  drm/i915: clarify IBX dp workaround
  drm/i915: simplify sysfs setup code
  drm/i915: initialize the parity work only once
  drm/i915: ivybridge_handle_parity_error should be static
  drm/i915: l3 parity sysfs interface
  drm/i915: remap l3 on hw init
  drm/i915: enable parity error interrupts
  drm/i915: Dynamic Parity Detection handling
  drm/i915: s/mdelay/msleep/ in the sdvo detect function
  drm/i915: reuse the sdvo tv clock adjustment in ilk mode_set
  drm/i915: there's no cxsr on ilk
  drm/i915: add some barriers when changing DIPs
  drm/i915: remove comment about HSW HDMI DIPs
  drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI
  drm/i915: don't write 0 to DIP control at HDMI init
  ...
2012-06-20 19:17:08 +01:00
Jesse Barnes
4a87d65d54 drm/i915: add HDMI and DP port enumeration on ValleyView
ValleyView is similar to IbexPeak here, but with different register
offsets.

v2: use SDVOB instead ov VLV_HDMIB (Daniel)
    drop unnecessary eDP check in DP_C init (Daniel)

eDP support will be coming later from Shobit.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 14:52:42 +02:00
Jesse Barnes
7d2c24e8cd drm/i915: add ValleyView specific CRT detect function
Might be able to merge this back in at some point, but we're seeing bugs
with ADPA based detection, so keep it separate for now with explicit
hotplug trigger usage.

v2: drop superfluous debug message
v3: comment forced detection, need to debug (Eugeni)

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 14:52:16 +02:00
Shobhit Kumar
98364379e1 drm/i915: Enable DP panel power sequencing for ValleyView
VLV supports two dp panels, there are two set of panel power sequence
registers which needed to be programmed based on the configured
pipe. This patch add supports for the same

Acked-by: Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Beeresh G <beeresh.g@intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop the lone hunk and only keep the register definitions - I
loathe incomplete bandaids. Also add a comment that this is for vlv.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 14:51:38 +02:00
Jesse Barnes
a0c4da24ea drm/i915: ValleyView mode setting limits and PLL functions
Add some VLV limit structures and update the PLL code.

v2: resolve conflicts, Vijay to re-post with PLL valid checks and fixed limits
v3: re-add dpio write function
v4: squash in Vijay's fixes for the PLL limits and clean up the m/n finder

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 14:21:23 +02:00
Daniel Vetter
cc889e0f6c drm/i915: disable flushing_list/gpu_write_list
This is just the minimal patch to disable all this code so that we can
do decent amounts of QA before we rip it all out.

The complicating thing is that we need to flush the gpu caches after
the batchbuffer is emitted. Which is past the point of no return where
execbuffer can't fail any more (otherwise we risk submitting the same
batch multiple times).

Hence we need to add a flag to track whether any caches associated
with that ring are dirty. And emit the flush in add_request if that's
the case.

Note that this has a quite a few behaviour changes:
- Caches get flushed/invalidated unconditionally.
- Invalidation now happens after potential inter-ring sync.

I've bantered around a bit with Chris on irc whether this fixes
anything, and it might or might not. The only thing clear is that with
these changes it's much easier to reason about correctness.

Also rip out a lone get_next_request_seqno in the execbuffer
retire_commands function. I've dug around and I couldn't figure out
why that is still there, with the outstanding lazy request stuff it
shouldn't be necessary.

v2: Chris Wilson complained that I also invalidate the read caches
when flushing after a batchbuffer. Now optimized.

v3: Added some comments to explain the new flushing behaviour.

Cc: Eric Anholt <eric@anholt.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 13:54:28 +02:00
Daniel Vetter
8e88a2bd59 drm/i915: don't call modeset_init_hw in i915_reset
It seems to blow up my ilk in all kinds of strange ways. And now that
we're no longer resetting the entire modeset state, it shouldn't be
necessary any longer.

This essentially reverts

commit f817586ceb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 10 15:50:11 2012 +0200

    drm/i915: re-init modeset hw state after gpu reset

safe for the introduction of modeset_init_hw, that one is nice to
prevent code duplication between driver load and resume.

v2: Add a comment to the code to warn future travellers of the dragon
dungeon ahead, suggested by Chris Wilson.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:31:44 +02:00
Daniel Vetter
5fa8be65e9 drm/i915: return -ENODEV if hw context are not supported
Otherwise userspace has no way to figure this out.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:19:20 +02:00
Daniel Vetter
73c273eb75 drm/i915: simplify context_idr_cleanup
The idr code already passes us the pointer associated with that id, so
no need to look it up again. Also, we'll kill the idr right away, so
there's no issue with leaving these dangling pointers behind - the
current code does the same.

v2: Also drop the file argument, spotted by Ben Widawsky.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:16:48 +02:00
Daniel Vetter
6f4c45c12c drm/i915/context: shut up compiler
It found some unused variables.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:16:28 +02:00
Daniel Vetter
0d32601376 drm/i915: return -ENOENT if the context doesn't exist
This is our customary "no such object" errno, not -EINVAL.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:16:08 +02:00
Daniel Vetter
df12c6d5ec drm/i915: initialize the context idr unconditionally
It doesn't hurt and it at least prevents us from OOPSing left and
right at quite a few places. This also allows us to simplify the code
a bit by folding the only line of context_open into the callsite.

We obviuosly also need to run the cleanup code unconditionally, too.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:15:37 +02:00
Daniel Vetter
55a6662837 drm/i915: fix module unload after context merge
commit 8e96d9c4d9
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Mon Jun 4 14:42:56 2012 -0700

    drm/i915: reset the GPU on context fini

broke module unload because it reset the gpu before we've stopped
touching it. Later on in the unload sequence the ringbuffer code
complained that the gpu would idle properly (because intel_gpu_reset
only resets the hw and not our sw state).

v2: Reorder things so that we reset the gpu _before_ we release the
backing storage of the default context.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51183
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 10:06:29 +02:00
Jesse Barnes
e3f33d46fd drm/i915: add L3 bank clock gating disable on VLV
Prevents a possible hang: WaDisableL3Bank2xClockGate.

v2: only apply to VLV, IVB doesn't need this anymore

References: https://bugs.freedesktop.org/show_bug.cgi?id=50245
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 18:41:47 +02:00
Jesse Barnes
6edaa7fcf2 drm/i915: add TDL unit clock gating disable for VLV
Another required workaround for a potential hang:
WaDisableTDLUnitClockGating.

v2: only apply this to VLV, IVB doesn't need it anymore (Eugeni)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50245
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 18:41:14 +02:00
Jesse Barnes
b4ae3f22d2 drm/i915: load boot context at driver init time
According to the bspec for MBCTL:

Driver must set bit in the following scenarios:
  - to realod teh h/w boot context every time it gets loaded through OS
  - after an FLR clears the register (BIOS won't run afterwards)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50237
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 18:40:48 +02:00
Jesse Barnes
0f846f81a1 drm/i915: disable RCBP and VDS unit clock gating on SNB and VLV
The RCBP workaround still applies on these chips, and we need VDS as well.

v2: remove MB boot fetch that snuck in (Daniel)
    add workaround tags to comments for easier internal tracking (Daniel)
v3: only apply RCPB and VDS on SNB and VLV, IVB doesn't need them (Eugeni)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50251
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 18:37:13 +02:00
Daniel Vetter
e080b915ec drm/i915: fixup hangman rebase goof-up
I've added a bit of logic such that running the hangman test on chips
without any hw reset support at all doesn't wedge the gpu because the
reset failed. This relied on checking for non-null stop_rings.
Unfortunately I've botched a rebase somewhere and stop_rings is still
cleared at the old place before the reset code.

Fix this up so that running the i-g-t tests on gen2/3 doesn't result
in a wedged gpu.

v2: Actually remove the lines instead of adding them twice ... my git
license should be revoked immediately.

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 10:43:54 +02:00
Ben Widawsky
208482232d drm/i915: set IDICOS to medium uncore resources
I'm seeing about a 5% FPS improvement across various benchmarks on my
IVB i3. Rumor has it that the higher end parts show even more benefit.

This derives from a patch originally given to me by Bernard. The docs
are  confusing about the definition names (ie. medium really seems like
max), but it would seem it gives more cache to the GT at the expense of
uncore. This configuration makes the split most in favor of the GT. I've
not tried the other IDICOS values.

Cc: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 10:43:53 +02:00
Ben Widawsky
e158c5aa17 drm/i915: disable contexts on old HW
This got dropped as a result of the last round of comments. I didn't
test it on unsupported HW (which this is likely the case).

Note that this prevents hw context from blowing up on any pre-gen6 hw.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51142
[danvet: Added note and buglink.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 10:01:08 +02:00
Eugeni Dodonov
39fb50f617 drm/i915: properly wait for SBI status
Somehow this went unnoticed in the past reviews, but the condition would
never timeout properly.

This was initially introduced in the v2 of original SBI enabling patch.
Highly embarrassing.

Note that we now actually time out for the read, which resulted in gcc
complaining that we can now return unitialized garbage if that
happens. There's not much we can do here because there's not much
point in thread -EIO all the way down through these functions. Hence
simply shut up the compiler.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: Added note and squashed uninitialized value shut-up into this
patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 09:57:07 +02:00
Dave Airlie
c4af5c4597 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: cache the EDID for eDP panels
  Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"
  drm/i915: eDP aux needs vdd
  drm/i915: don't enumerate HDMID if an eDP panel is already active on the port
2012-06-16 14:45:17 +01:00
Jesse Barnes
d6f24d0fa6 drm/i915: cache the EDID for eDP panels
They aren't going anywhere, and probing on DDC can cause the panel to
blank briefly, so read them up front and cache them for later queries.

v2: fix potential NULL derefs in intel_dp_get_edid_modes and
    intel_dp_get_edid (Jani)
    copy full EDID length, including extension blocks (Takashi)
    free EDID on teardown (Takashi)
v3: malloc a new EDID buffer that's big enough for the memcpy (Chris)
v4: change handling of NULL EDIDs, just preserve the NULL behavior
    across detects and mode list fetches rather than trying to re-fetch
    the EDID (Chris)
v5: be glad that Chris is around to remind me to hit C-x C-s before
    committing.

References: https://bugs.freedesktop.org/show_bug.cgi?id=46856
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 15:39:02 +02:00
Daniel Vetter
6b4e0a93ff Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"
This reverts commit 092945e11c.

This commit prevents a DP screen from properly training the link.
Oddly enough it works, once the machine has been warm-booted with an
older kernel.

According to DP docs this _should_ have been the right precharge time.
Also, the commit that originally introduces this was just general snb
DP enabling and didn't mention any specific reason for this special
value. Whatever, trust the reporter that this makes things worse and
let's just revert it.

v2: Less spelling fail.

Cc: Adam Jackson <ajax@redhat.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: "Wouter M. Koolen" <W.M.Koolen-Wijkstra@cwi.nl>
Buglink: https://lkml.org/lkml/2012/6/14/301
Cc: stable@vger.kernel.org (only for 3.4)
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 15:39:02 +02:00
Daniel Vetter
351cfc34db drm/i915: eDP aux needs vdd
The new oui probe has been missing these.

This issue has been introduce in

commit 0d19832853
Author: Adam Jackson <ajax@redhat.com>
Date:   Mon May 14 16:05:47 2012 -0400

    drm/i915/dp: Probe branch/sink OUIs

v2: Do the eDP vdd dance of simply not probing the OUI on eDP panels
as suggested by Chris Wilson.

v3: Fix up the error path fail - I suck.

Cc: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
Tested-by: Yang Guang <guang.a.yang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 15:39:02 +02:00
Jesse Barnes
b708a1d5ea drm/i915: don't enumerate HDMID if an eDP panel is already active on the port
This prevents the HDMI detect functions from poking at an eDP
connected panel, which can lead to trouble.

[danvet: Note that we have some other reports of DP vs. HDMI fighting,
but the general case is a much bigger fish to fry.]

References: https://bugs.freedesktop.org/show_bug.cgi?id=42278
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 15:39:01 +02:00
Alex Deucher
7c77bf2a1a drm/radeon: add support for STRMOUT_BASE_UPDATE on 7xx
Required for streamout.  Bump drm minor.

Marek v2: fix pkt->count check

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-16 14:30:56 +01:00
Alex Deucher
b866d1334b drm/radeon: add some additional 6xx/7xx/EG register init
- SMX_SAR_CTL0 needs to be programmed correctly to prevent
problems with memory exports in certain cases.
- VC_ENHANCE needs to be initialized on 6xx/7xx.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-16 14:30:47 +01:00
Daniel Vetter
aaa377302b drm/i915/crt: Do not rely upon the HPD presence pin
VGA hotplug detection "works" by measuring the resistance across
certain pins. A lot of kvm switches fumble this and wire up cheap
resistors with the wrong resistance or don't bother at all.

To accomodate these, also try to detect a connected monitor by trying
to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother
with an actual load-detection cycle when the output is life - that
would be actual work to implement because things moved around. This is
the big difference to Chris Wilson's original approach:

commit 9e612a008f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu May 31 13:08:53 2012 +0100

    drm/i915/crt: Do not rely upon the HPD presence pin

This blew up on Linus' machine because it errornously detected a vga
screen (without and edid and hence only the default modes), leading to
it's prompt removal:

commit 8f53369b75
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Jun 8 14:53:06 2012 -0700

    Revert "drm/i915/crt: Do not rely upon the HPD presence pin"

Some digging around in Bspec shows the reason why load detect doesn't work on
newer chips - the legacy VGA load detect bit isn't wired up any longer:

Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4:

"RGB Comparator / Sense. This bit is here for compatibility and will
always return one. Monitor detection must be done be done through the
programming of registers in the MMIO space.
0 = Below threshold
1 = Above threshold"

v2: Add a comment in the code that load detect on hotplug capable
machines is broken and pimp the commit message with a quote of Bspec
to show why.

Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 15:30:32 +02:00
Rafał Miłecki
6b53a0507b drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)
After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Christian König <christian.koenig@amd.com>
Tested-by: Andre Heider <a.heider@gmail.com>
Tested-by: Zoltán Böszörményi <zboszor@pr.hu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-16 11:21:19 +01:00
Márton Németh
648ccc7d35 drm sis: initialize object_idr
The filed object_idr of struct drm_sis_private was introduced with
commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=6de8a748881f1cd9d795454da2b6db616d5ca3d7 .

The idr_init(&dev->object_name_idr) is called instead of
idr_init(&dev_priv->object_idr) by mistake, leaving object_idr
uninitialized. Correct this.

This patch was not tested because of lack of hardware.

Signed-off-by: Márton Németh <nm127@freemail.hu>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-16 11:18:53 +01:00
Márton Németh
ce020ea532 drm via: initialize object_idr
The field obejct_idr of struct drm_via_private was introduced with the
commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc .
In that patch idr_init(&dev->object_name_idr) was called instead of
idr_init(&dev_priv->object_idr) by mistake, leaving the dev_priv->object_idr
uninitialized. To be more exact, the object_idr buffer is filled with zeros
because of kzalloc(), but the dev_priv->object_idr.lock spinlock can cause
system freeze at lib/idr.c:move_to_free_list() when spin_lock_irqsave()
is called on this spinlock.

The patch was tested on Clevo D4J, model D410J laptop, on the following
hardware, without AGP kernel module loaded:

  # lspci -s 01:00.0 -n
  01:00.0 0300: 1106:3108 (rev 01)
  # lspci -s 01:00.0 -v
  01:00.0 VGA compatible controller: VIA Technologies, Inc. K8M800/K8N800/K8N800A [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA controller])
          Subsystem: CLEVO/KAPOK Computer Device 4702
          Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
          Memory at f0000000 (32-bit, prefetchable) [size=64M]
          Memory at d1000000 (32-bit, non-prefetchable) [size=16M]
          Expansion ROM at <unassigned> [disabled]
          Capabilities: [60] Power Management version 2
          Capabilities: [70] AGP version 3.0

Signed-off-by: Márton Németh <nm127@freemail.hu>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-16 11:18:38 +01:00
Dave Airlie
489797d510 drm/radeon/prime: reserve/unreserve around pin
I finally got to test this code a bit more and hit the ttm
no reserved assert, so add the reservations around the pinning.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-16 11:14:05 +01:00
Alex Deucher
0ec0612a80 drm/radeon: fix regression in dynpm due to multi-ring rework
Not all asics have all rings, so make sure the ring is ready
before attempting to check it in the dynpm work handler.

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

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-16 11:12:13 +01:00
Dave Airlie
e5a867a51d drm/udl: only bind to the video devices on the hub.
This is ported from udlfb.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=832188
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-16 11:09:58 +01:00
Ben Widawsky
8e96d9c4d9 drm/i915: reset the GPU on context fini
It's the only way we know how to make the GPU actually forget about the
default context.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:21 +02:00
Ben Widawsky
6e0a69dbc8 drm/i915/context: switch contexts with execbuf2
Use the rsvd1 field in execbuf2 to specify the context ID associated
with the workload. This will allow the driver to do the proper context
switch when/if needed.

v2: Add checks for context switches on rings not supporting contexts.
Before the code would silently ignore such requests.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:21 +02:00
Ben Widawsky
846248136d drm/i915/context: create & destroy ioctls
Add the interfaces to allow user space to create and destroy contexts.
Contexts are destroyed automatically if the file descriptor for the dri
device is closed.

Following convention as usual here causes checkpatch warnings.

v2: with is_initialized, no longer need to init at create
drop the context switch on create (daniel)

v3: Use interruptible lock (Chris)
return -ENODEV in !GEM case (Chris)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:20 +02:00
Ben Widawsky
f2ef6eb145 drm/i915: switch to default context on idle
To keep things as sane as possible, switch to the default context before
idling. This should help free context objects, as well as put things in
a more well defined state before suspending.

v2: remove seqno from context switch call (daniel)
return error on failed context switch instead of WARN+continue (daniel)

v3: move idling to i915_gpu idle (from i915_gem_idle) (Chris)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:20 +02:00
Ben Widawsky
b9a3906b60 drm/i915: add ccid to error state
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:19 +02:00
Ben Widawsky
dfabbcb4f6 drm/i915: use the default context
With the code to do HW context switches in place have the driver load the
default context for the render ring when the driver loads.

The default context will be an ever present context that is available to
switch to at any time for the given ring.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:19 +02:00
Ben Widawsky
12b0286f49 drm/i915: possibly invalidate TLB before context switch
From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf

[DevSNB] If Flush TLB invalidation Mode is enabled it's the driver's
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT
entries).  This can be done by a pipelined PIPE_CONTROL with TLB inv bit
set immediately before MI_SET_CONTEXT.

On GEN7 the invalidation mode is explicitly set, but this appears to be
lacking for GEN6. Since I don't know the history on this, I've decided
to dynamically read the value at ring init time, and use that value
throughout.

v2: better comment (daniel)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:19 +02:00
Ben Widawsky
cc0f639822 drm/i915: PIPE_CONTROL_TLB_INVALIDATE
This has showed up in several other patches. It's required for the next
context workaround.

I tested this one on its own and saw no differences in basic tests
(performance or otherwise). This patch is relatively likely to cause
regressions, hence why it's split out.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:18 +02:00
Ben Widawsky
e37ec39b18 drm/i915: Ivybridge MI_ARB_ON_OFF context w/a
The workaround itself applies to gen7 only (according to the docs) and
as Eric Anholt points out shouldn't be required since we don't use HW
scheduling features, and therefore arbitration. Though since it is a
small, and simple addition, and we don't really understand the issue,
just do it.

FWIW, I eventually want to play with some of the arbitration stuff, and
I'd hate to forget about this.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:18 +02:00
Daniel Vetter
3af7b8572f drm/i915: ensure context objects are bound to the global gtt
This way round we don't introduce and ugly layering violations and use
the interface as I planned to use it.

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-14 17:36:17 +02:00
Ben Widawsky
e055684168 drm/i915: context switch implementation
Implement the context switch code as well as the interfaces to do the
context switch. This patch also doesn't match 1:1 with the RFC patches.
The main difference is that from Daniel's responses the last context
object is now stored instead of the last context. This aids in allows us
to free the context data structure, and context object independently.

There is room for optimization: this code will pin the context object
until the next context is active. The optimal way to do it is to
actually pin the object, move it to the active list, do the context
switch, and then unpin it. This allows the eviction code to actually
evict the context object if needed.

The context switch code is missing workarounds, they will be implemented
in future patches.

v2: actually do obj->dirty=1 in switch (daniel)
Modified comment around above
Remove flags to context switch (daniel)
Move mi_set_context code to i915_gem_context.c (daniel)
Remove seqno , use lazy request instead (daniel)

v3: use i915_gem_request_next_seqno instead of
      outstanding_lazy_request (Daniel)
remove id's from trace events (Daniel)
Put the context BO in the instruction domain (Daniel)
Don't unref the BO is context switch fails (Chris)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:17 +02:00
Ben Widawsky
40521054fd drm/i915: context basic create & destroy
Invent an abstraction for a hw context which is passed around through
the core functions. The main bit a hw context holds is the buffer object
which backs the context. The rest of the members are just helper
functions. Specifically the ring member, which could likely go away if
we decide to never implement whatever other hw context support exists.

Of note here is the introduction of the 64k alignment constraint for the
BO. If contexts become heavily used, we should consider tweaking this
down to 4k. Until the contexts are merged and tested a bit though, I
think 64k is a nice start (based on docs).

Since we don't yet switch contexts, there is really not much complexity
here. Creation/destruction works pretty much as one would expect. An idr
is used to generate the context id numbers which are unique per file
descriptor.

v2: add DRM_DEBUG_DRIVERS to distinguish ENOMEM failures (ben)
convert a BUG_ON to WARN_ON, default destruction is still fatal (ben)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:16 +02:00
Ben Widawsky
254f965c39 drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.

Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores.  With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5).  Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.

In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state.  The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.

All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.

There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.

As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.

v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:16 +02:00
Ben Widawsky
fe1cc68fcb drm/i915: CXT_SIZE register offsets added
The GPUs can have different default context layouts, and the sizes could
vary based on platform or BIOS. In order to back the context object with
a properly sized BO, we must read this register in order to find out a
sufficient size.

Thankfully (sarcarm!), the register moves and changes meanings
throughout generations.

CTX and CXT differences are intentional as that is how it is in the
documentation (prior to GEN6 it was CXT).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:16 +02:00
Seth Forshee
14d94a3d82 drm/i915: ignore pipe select bit when checking for LVDS register initialization
The Lenovo Thinkpad T410 has the LVDS_PIPEB_SELECT bit set in the LVDS
register when booted with the lid closed, even though the LVDS hasn't
really been initialized. Ignore this bit so that the VBT value will be
used instead.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-13 21:05:06 +02:00
Chris Wilson
93314b5b6f drm/i915: Switch off FBC when disabling the primary plane when obscured
As we switch on/off the primary plane if it is completely obscured by an
overlapping video sprite, we also nee to make sure that we update the
FBC configuration at the same time.

v2: Not all crtcs are intel_crtcs, as spotted by Daniel.
v3: Boot testing rules.

References: https://bugs.freedesktop.org/show_bug.cgi?id=50238
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-13 20:10:00 +02:00
Daniel Vetter
e188719a28 drm/i915: kick any firmware framebuffers before claiming the gtt
Especially vesafb likes to map everything as uc- (yikes), and if that
mapping hangs around still while we try to map the gtt as wc the
kernel will downgrade our request to uc-, resulting in abyssal
performance.

Unfortunately we can't do this as early as readon does (i.e. as the
first thing we do when initializing the hw) because our fb/mmio space
region moves around on a per-gen basis. So I've had to move it below
the gtt initialization, but that seems to work, too. The important
thing is that we do this before we set up the gtt wc mapping.

Now an altogether different question is why people compile their
kernels with vesafb enabled, but I guess making things just work isn't
bad per se ...

v2:
- s/radeondrmfb/inteldrmfb/
- fix up error handling

v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky.

v4: Jani Nikula complained about the pointless bool primary
initialization.

v5: Don't oops if we can't allocate, noticed by Chris Wilson.

v6: Resolve conflicts with agp rework and fixup whitespace.

Reported-and-tested-by: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-13 13:33:42 +02:00
Daniel Vetter
8ecd1a6615 drm/i915: call intel_enable_gtt
When drm/i915 is in control of the gtt, we need to call
the enable function at all the relevant places ourselves.

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:21:07 +02:00
Daniel Vetter
14be93ddff drm/i915 + agp/intel-gtt: prep work for direct setup
To be able to directly set up the intel-gtt code from drm/i915 and
avoid setting up the fake-agp driver we need to prepare a few things:
- pass both the bridge and gpu pci_dev to the probe function and add
  code to handle the gpu pdev both being present (for drm/i915) and
  not present (fake agp).
- add refcounting to the remove function so that unloading drm/i915
  doesn't kill the fake agp driver

v2: Fix up the cleanup and refcount, noticed by Jani Nikula.

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:19:49 +02:00
Daniel Vetter
dd2757f8b5 drm/i915: stop using dev->agp->base
For that to work we need to export the base address of the gtt
mmio window from intel-gtt. Also replace all other uses of
dev->agp by values we already have at hand.

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:18:06 +02:00
Daniel Vetter
0b9f43a0ee drm/i915: allow pipe A for lvds on gen4
Given the havoc the missing backlight pipe select code might have
caused, let's try to re-enabled pipe A support for lvds on gen4 hw.
Just to see what all blows up ...

Note though that

commit 4add75c43f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Dec 4 17:49:46 2010 +0000

    drm/i915: Allow LVDS to be on pipe A for Ironlake+

claims that this caused tons of spurious wakeups somehow.

More details can be found in the old revert:

commit 12e8ba25ef
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 7 23:39:28 2010 +0100

    Revert "drm/i915: Allow LVDS on pipe A on gen4+"

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

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:28:40 +02:00
Daniel Vetter
24ded20442 drm/i915: properly enable the blc controller on the right pipe
On gen4+ we have a bitfield to specify from which pipe the backlight
controller should take it's clock. For PCH split platforms we've
already set these up, but only at initialization time. And without
taking into account the 3rd pipe added with ivb.

For gen4, we've completely ignored these. Although we do restrict lvds
to the 2nd pipe, so this is only a problem on machines where we boot
up with the lvds on the first pipe.

So restructure the code to enable the backlight on the right pipe at
modeset time.

v2: For odd reasons panel_enable_backlight gets called twice in a
modeset, so we can't WARN_ON in there if the backlight controller is
switched on already.

v3: backlight enable can also be called through dpms on, so the check
in there is legit. Update the comment to reflect that.

Tested-By: Kamal Mostafa <kamal@canonical.com>
Bugzilla: https://bugs.launchpad.net/bugs/954661
Cc: Carsten Emde <C.Emde@osadl.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:27:58 +02:00
Daniel Vetter
7cf4160148 drm/i915: clear up backlight #define confusion on gen4+
- Regroup definitions for BLC_PWM_CTL so that they're all together and
  and ordered according to the bitfields.

- Add all missing definitions for BLC_PWM_CTL2.

- Use the BLM_ (for backlight modulation) prefix consistently.

- Note that combination mode (i.e. also taking the legacy backlight
  control value from pci config space into account) is gen4 only.

- Move the new registers for PCH-split machines up, they're an almost
  match for the gen4 defitions.  Prefix the special PCH-only bits with
  BLM_PCH_. Also add the pipe C select bit for ivb.

- Rip out the second pair of PCH polarity definitions - they're only
  valid on early (pre-production) ilk silicon.

- Adapt the existing code to use the new definitions. This has the
  nice benefit of killing a magic (1 << 30) left behind be Jesse
  Barnes.

No functional changes in this patch.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:25:46 +02:00
Daniel Vetter
534b5a5341 drm/i915: pnv has a backlight polarity control bit, too
We already correctly ignore bit0 on gen < 4, now we also know why ;-)
I've decided that losing that single bit of precision isn't worth the
trouble to sprinkle IS_PINEVIEW checks all over the backlight control
code - that code is way too fragile imo.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:25:03 +02:00
Daniel Vetter
afba018898 drm/i915: ensure HDMI port is disabled inside set_infoframes
This function is supposed to be used at mode set time, so prevent
against future mistakes by adding a WARN().

Based on a patch by Paulo Zanoni, with the check extracted into a
little assert_hdmi_port_disabled helper added to make things self
documenting and move the assert stuff out of line.

[fixed up spelling goof-up while applying.]
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:19:52 +02:00
Thomas Hellstrom
a393c730ab drm/ttm: Fix buffer object metadata accounting regression v2
A regression was introduced in the 3.3 rc series, commit
"drm/ttm: simplify memory accounting for ttm user v2",
causing the metadata of buffer objects created using the ttm_bo_create()
function to be accounted twice.
That causes massive leaks with the vmwgfx driver running for example
SpecViewperf Catia-03 test 2, eventually killing the app.

Furthermore, the same commit introduces a regression where
metadata accounting is leaked if a buffer object is
initialized with an illegal size. This is also fixed with this commit.

v2: Fixed an error path and removed an unused variable.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-12 15:57:47 +01:00
Jerome Glisse
d26098759c drm/radeon: fix tiling and command stream checking on evergreen v3
Fix regresson since the introduction of command stream checking on
evergreen (thread referenced below). Issue is cause by ddx allocating
bo with formula width*height*bpp while programming the GPU command
stream with ALIGN(height, 8). In some case (where page alignment does
not hide the extra size bo should be according to height alignment)
the kernel will reject the command stream.

This patch reprogram the command stream to slice - 1 (slice is
a derivative value from height) which avoid rejecting the command
stream while keeping the value of command stream checking from a
security point of view.

This patch also fix wrong computation of layer size for 2D tiled
surface. Which should fix issue when 2D color tiling is enabled.
This dump the radeon KMS_DRIVER_MINOR so userspace can know if
they are on a fixed kernel or not.

https://lkml.org/lkml/2012/6/3/80
https://bugs.freedesktop.org/show_bug.cgi?id=50892
https://bugs.freedesktop.org/show_bug.cgi?id=50857

!!! STABLE need a custom version of this patch for 3.4 !!!

v2: actually bump the minor version and add comment about stable
v3: do compute the height the ddx was trying to use

[airlied: drop left over debug]

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-10 17:41:46 +01:00
Linus Torvalds
8f53369b75 Revert "drm/i915/crt: Do not rely upon the HPD presence pin"
This reverts commit 9e612a008f.

It incorrectly finds VGA connectors where none are attached, apparently
not noticing that nothing replied to the EDID queries, and happily using
the default EDID modes that have nothing to do with actual hardware.

That in turn then causes X to fall down to the lowest common
denominator, which is usually the default 1024x768 mode that is in the
default EDID and pretty much anything supports).

I'd suggest that if not relying on the HDP pin, the code should at least
check whether it gets valid EDID data back, rather than just assume
there's something on the VGA connector.

Cc: Dave Airlie <airlied@linux.ie>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-06-08 14:53:06 -07:00
Dave Airlie
2d5c7cd35f Merge branch 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes
* 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung:
  drm/exynos: fixed blending for hdmi graphic layer
  drm/exynos: Remove dummy encoder get_crtc operation implementation
  drm/exynos: Keep a reference to frame buffer GEM objects
  drm/exynos: Don't cast GEM object to Exynos GEM object when not needed
  drm/exynos: DRIVER_BUS_PLATFORM is not a driver feature
  drm/exynos: fixed size type.
  drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}
2012-06-08 09:42:51 +01:00
Dave Airlie
6cf98d6ebb Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler
  char/agp: add another Ironlake host bridge
  drm/i915: fix up ivb plane 3 pageflips
  drm/i915: hold forcewake around ring hw init
  drm/i915: Mark the ringbuffers as being in the GTT domain
  drm/i915/crt: Do not rely upon the HPD presence pin
  drm/i915: Reset last_retired_head when resetting ring
2012-06-08 09:42:35 +01:00
Adam Jackson
23e81d691a drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler
Cougar/Panther Point redefine the bits in SDEIIR pretty completely.
This function is just debugging, but if we're debugging we probably want
to be told accurate things instead of lies.

I'm told Lynx Point changes this yet more, but I have no idea how...

Note from Eugeni's review:

"For the record and for future enabling efforts, for LPT, bits 28-31
and 1-14 are gone since CPT/PPT (e.g., those must be zero). And there
is the bit 15 as a new addition, but we are not using it yet and
probably won't be using in foreseeable future."

Signed-off-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35103
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-06 23:01:08 +02:00
Ben Widawsky
172cf15d18 drm/i915: Add wait render timeout get param
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-06 12:28:40 +02:00
Ben Widawsky
eac1f14fd1 drm/i915: Inifite timeout for wait ioctl
Change the ns_timeout parameter of the wait ioctl to a signed value.
Doing this allows the kernel to provide an infinite wait when a timeout
of less than 0 is provided. This mimics select/poll.

Initially the parameter was meant to match up with the GL spec 1:1, but
after being made aware of how much 2^64 - 1 nanoseconds actually is, I
do not think anyone will ever notice the loss of 1 bit.

The infinite timeout on waiting is similar to the existing i915
userspace interface with the exception that struct_mutex is dropped
while doing the wait in this ioctl.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-06 12:25:46 +02:00
Daniel Vetter
de9a35abb3 drm/i915: assert that the IBX port transcoder select w/a is implemented
Let's be a bit more paranoid here.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-06 09:30:37 +02:00
Daniel Vetter
7a87c28977 drm/i915: implement IBX hdmi transcoder select workaround
Bspec Vol 3, Part 3, Section 3.8.1.1, bit 30:

"[DevIBX] Writing to this bit only takes effect when port is enabled.
Due to hardware issue it is required that this bit be cleared when port
is disabled. To clear this bit software must temporarily enable this
port on transcoder A."

Unfortunately the public Bspec misses totally out on the same language
for HDMIB. Internal Bspec also mentions that one of the bad
side-effects is that DPx can fail to light up on transcoder A if HDMIx
is disabled but using transcoder B.

I've found this while reviewing Bsepc. We already implement the same
workaround for the DP ports.

Also replace a magic 1 with PIPE_B I've found while looking through the
code.

v2: Implement suggestions from Chris Wilson:
- add pipe variable to cut down on code noise
- write the reg value twice to w/a hw issues (Bspec is unclear on
  which bit actually require the write twice stuff, but better be
  paranoid about it)
- untangle the if logic

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-06 09:25:13 +02:00
Daniel Vetter
cb05d8dede drm/i915: fix up ivb plane 3 pageflips
Or at least plug another gapping hole. Apparrently hw desingers only
moved the bit field, but did not bother ot re-enumerate the planes
when adding support for a 3rd pipe.

Discovered by i-g-t/flip_test.

This may or may not fix the reference bugzilla, because that one
smells like we have still larger fish to fry.

v2: Fixup the impossible case to catch programming errors, noticed by
Chris Wilson.

References: https://bugs.freedesktop.org/show_bug.cgi?id=50069
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Eugeni Dodonov <eugeni.dodonov@intel.com>
Cc: stable@vger.kernel.org
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-05 21:05:21 +02:00
Alex Deucher
d430f7dbf7 drm/radeon/kms: add new Trinity PCI ids
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-05 15:11:09 +01:00
Christian König
bb40915582 drm/radeon: fix vm deadlocks on cayman
Locking mutex in different orders just screams for
deadlocks, and some testing showed that it is actually
quite easy to trigger them.

Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-05 09:27:23 +01:00
Alex Deucher
1a8ca7502c drm/radeon: fix gpu_init on si
- Properly set up the RBs
- Properly set up the SPI
- Properly set up gb_addr_config

This should fix rendering issues on certain cards.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-05 09:25:54 +01:00
Rafał Miłecki
7838e05a0d drm/radeon/hdmi: don't set SEND_MAX_PACKETS bit
Many TVs and A/V receivers don't work with this bit set. Problem was
confirmed using: Onkyo TX-SR605, Sony BRAVIA KDL-52X3500, Sony BRAVIA
KDL-40S40xx. In theory this bit shouldn't affect audio engine when
feeding it with data, however it seems it does. Driver fglrx doesn't set
that bit in any of the above cases.
This fixes a regression introduced by 3.5-rc1.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-05 09:25:33 +01:00
Rafał Miłecki
0aecb5a4ba drm/radeon/audio: don't hardcode CRTC id
This is based on info released by AMD, should allow using audio in much
more cases.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-05 09:25:01 +01:00
Alex Deucher
d4e30ef05c drm/radeon: make audio_init consistent across asics
Call it in the asic startup callback on all asics.
Previously r600 and rv770 called it in the startup
and resume callbacks while all the other asics called
it in the startup callback.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-05 09:24:33 +01:00
Seung-Woo Kim
5736603bef drm/exynos: fixed blending for hdmi graphic layer
Blending for graphic layer 0 of hdmi mixer was not set so video
layer cannot be showed if graphic layer 0 is enabled.
This patch fixes blending values to support blending between
graphic layer 0 and video layer.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
2012-06-05 13:25:18 +09:00
Laurent Pinchart
f56fdcef4d drm/exynos: Remove dummy encoder get_crtc operation implementation
The encoder get_crtc operation is called to retrieve a pointer to the
CRTC the encoder is currenctly connected to, right after setting the
encoder::crtc field to the new CRTC. The implementation of this
operation returns the pointer to the new CRTC, which is then pointlessly
compared to itself.

As the operation is not mandatory, don't implement it.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-06-05 13:25:15 +09:00
Laurent Pinchart
07b6835f2c drm/exynos: Keep a reference to frame buffer GEM objects
GEM objects used by frame buffers must be referenced for the whole life
of the frame buffer. Release the references in the frame buffer
destructor instead of its constructor.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-06-05 11:53:58 +09:00
Laurent Pinchart
6037bafa2e drm/exynos: Don't cast GEM object to Exynos GEM object when not needed
The exynos_drm_gem_dumb_map_offset() doesn't need to access any
Exynos-specific GEM object fields, don't cast the GEM object.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-06-05 11:53:58 +09:00
Laurent Pinchart
293a1c128e drm/exynos: DRIVER_BUS_PLATFORM is not a driver feature
DRIVER_BUS_PLATFORM is a bus type used internally in the DRM core, not a
flag for the drm_driver::driver_features field.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-06-05 11:53:58 +09:00
Ville Syrjälä
363b06aaa5 drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}
The NV12M/YUV420M formats are identical to the already existing standard
NV12/YUV420 formats. The M variants will be removed, so convert the
driver to use the standard names.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
2012-06-05 11:51:43 +09:00
Jesse Barnes
1523c310b3 drm/i915: add min freq control to debugfs
This makes for easier benchmarking and testing.  One can set a fixed
frequency by setting min and max to the same value.

v2: fix whitespace & comment (Eugeni)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni@dodonov.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-04 21:34:47 +02:00
Daniel Vetter
cb1793ce92 drm/i915: don't chnage the original mode in dp_mode_fixup
We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.

After the previous two prep patches the only thing left is to clean up
things a bit. I've opted to pass in an adjust_mode param to
dp_adjust_dithering because that way we can be sure to avoid
duplicating this logic between mode_valid and mode_fixup - which was
the cause behind a dp link bw calculation bug in the past.

Also mark the mode argument of pch_panel_fitting const.

v2: Split up the mode->clock => adjusted_mode->clock change,
as suggested by Chris Wilson.

Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-04 21:29:47 +02:00
Daniel Vetter
71244653a8 drm/i915: adjusted_mode->clock in the dp mode_fixup
... instead of changing mode->clock, which we should leave as-is.

After the previous patch we only touch that if it's a panel, and then
adjusted mode->clock equals adjusted_mode->clock. Outside of
intel_dp.c we only use ajusted_mode->clock in the mode_set functions.

Within intel_dp.c we only use it to calculate the dp dithering
and link bw parameters, so that's the only thing we need to fix
up.

As a temporary ugliness (until the cleanup in the next patch) we
pass the adjusted_mode into dp_dither for both parameters (because
that one still looks at mode->clock).

Note that we do overwrite adjusted_mode->clock with the selected dp
link clock, but that only happens after we've calculated everything we
need based on the dotclock of the adjusted output configuration.

Outside of intel_dp.c only intel_display.c uses adjusted_mode->clock,
and that stays the same after this patch (still equals the selected dp
link clock). intel_display.c also needs the actual dotclock (as
target_clock), but that has been fixed up in the previous patch.

v2: Adjust the debug message to also use adjusted_mode->clock.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-04 21:28:44 +02:00
Daniel Vetter
94bf2cedbc drm/i915: compute the target_clock for edp directly
... instead of abusing mode->clock by storing it in there - we
shouldn't touch that one at all. This patch is the first prep step to
constify the mode argument of the intel_dp_mode_fixup function.

The next patch will stop us from modifying mode->clock.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-04 21:27:47 +02:00
Daniel Vetter
b7884eb45e drm/i915: hold forcewake around ring hw init
Empirical evidence suggests that we need to: On at least one ivb
machine when running the hangman i-g-t test, the rings don't properly
initialize properly - the RING_START registers seems to be stuck at
all zeros.

Holding forcewake around this register init sequences makes chip reset
reliable again. Note that this is not the first such issue:

commit f01db988ef
Author: Sean Paul <seanpaul@chromium.org>
Date:   Fri Mar 16 12:43:22 2012 -0400

    drm/i915: Add wait_for in init_ring_common

added delay loops to make RING_START and RING_CTL initialization
reliable on the blt ring at boot-up. So I guess it won't hurt if we do
this unconditionally for all force_wake needing gpus.

To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new
intel_info bit for that.

v2: Fixup missing commas in static struct and properly handling the
error case in init_ring_common, both noticed by Jani Nikula.

Cc: stable@vger.kernel.org
Reported-and-tested-by: Yang Guang <guang.a.yang@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-04 20:25:29 +02:00
Chris Wilson
3eef8918ff drm/i915: Mark the ringbuffers as being in the GTT domain
By correctly describing the rinbuffers as being in the GTT domain, it
appears that we are more careful with the management of the CPU cache
upon resume and so prevent some coherency issue when submitting commands
to the GPU later. A secondary effect is that the debug logs are then
consistent with the actual usage (i.e. they no longer describe the
ringbuffers as being in the CPU write domain when we are accessing them
through an wc iomapping.)

Reported-and-tested-by: Daniel Gnoutcheff <daniel@gnoutcheff.name>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41092
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-04 20:16:40 +02:00
Daniel Vetter
30dfebf34b drm/i915: extract object active state flushing code
Both busy_ioctl and the new wait_ioct need to do the same dance (or at
least should). Some slight changes:
- busy_ioctl now unconditionally checks for olr. Before emitting a
  require flush would have prevent the olr check and hence required a
  second call to the busy ioctl to really emit the request.
- the timeout wait now also retires request. Not really required for
  abi-reasons, but makes a notch more sense imo.

I've tested this by pimping the i-g-t test some more and also checking
the polling behviour of the wait_rendering_timeout ioctl versus what
busy_ioctl returns.

v2: Too many people complained about unplug, new color is
flush_active.

v3: Kill the comment about the unplug moniker.

v4: s/un-active/inactive/

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-02 20:51:03 +02:00
Linus Torvalds
3ded7acfdd Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
 "A bunch of fixes:
   - vmware memory corruption
   - ttm spinlock balance
   - cirrus/mgag200 work in the presence of efifb
  and finally Alex and Jerome managed to track down a magic set of bits
  that on certain rv740 and evergreen cards allow the correct use of the
  complete set of render backends, this makes the cards operate
  correctly in a number of scenarios we had issues in before, it also
  manages to boost speed on benchmarks my large amounts on these
  specific gpus."

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/edid: Make the header fixup threshold tunable
  drm/radeon: fix regression in UMS CS ioctl
  drm/vmwgfx: Fix nasty write past alloced memory area
  drm/ttm: Fix spinlock imbalance
  drm/radeon: fixup tiling group size and backendmap on r6xx-r9xx (v4)
  drm/radeon: fix HD6790, HD6570 backend programming
  drm/radeon: properly program gart on rv740, juniper, cypress, barts, hemlock
  drm/radeon: fix bank information in tiling config
  drm/mgag200: kick off conflicting framebuffers earlier.
  drm/cirrus: kick out conflicting framebuffers earlier
  cirrus: avoid crash if driver fails to load
2012-06-01 15:40:29 -07:00
Daniel Vetter
493a708179 drm/i915: clarify IBX dp workaround
Instead of checking for !CPT, check for IBX to make it clearer that
this is a IBX-specific workaround. No functional change because we
smash the PPT PCH into the HAS_PCH_CPT check and atm DP isn't enabled
on the haswell LPT PCH yet.

See Bspec Vol 3, Part 3, Section 4.[3-5].1 about DP[BCD], bit 30 for
details of this workaround.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-01 21:38:59 +02:00
Linus Torvalds
1193755ac6 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull vfs changes from Al Viro.
 "A lot of misc stuff.  The obvious groups:
   * Miklos' atomic_open series; kills the damn abuse of
     ->d_revalidate() by NFS, which was the major stumbling block for
     all work in that area.
   * ripping security_file_mmap() and dealing with deadlocks in the
     area; sanitizing the neighborhood of vm_mmap()/vm_munmap() in
     general.
   * ->encode_fh() switched to saner API; insane fake dentry in
     mm/cleancache.c gone.
   * assorted annotations in fs (endianness, __user)
   * parts of Artem's ->s_dirty work (jff2 and reiserfs parts)
   * ->update_time() work from Josef.
   * other bits and pieces all over the place.

  Normally it would've been in two or three pull requests, but
  signal.git stuff had eaten a lot of time during this cycle ;-/"

Fix up trivial conflicts in Documentation/filesystems/vfs.txt (the
'truncate_range' inode method was removed by the VM changes, the VFS
update adds an 'update_time()' method), and in fs/btrfs/ulist.[ch] (due
to sparse fix added twice, with other changes nearby).

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (95 commits)
  nfs: don't open in ->d_revalidate
  vfs: retry last component if opening stale dentry
  vfs: nameidata_to_filp(): don't throw away file on error
  vfs: nameidata_to_filp(): inline __dentry_open()
  vfs: do_dentry_open(): don't put filp
  vfs: split __dentry_open()
  vfs: do_last() common post lookup
  vfs: do_last(): add audit_inode before open
  vfs: do_last(): only return EISDIR for O_CREAT
  vfs: do_last(): check LOOKUP_DIRECTORY
  vfs: do_last(): make ENOENT exit RCU safe
  vfs: make follow_link check RCU safe
  vfs: do_last(): use inode variable
  vfs: do_last(): inline walk_component()
  vfs: do_last(): make exit RCU safe
  vfs: split do_lookup()
  Btrfs: move over to use ->update_time
  fs: introduce inode operation ->update_time
  reiserfs: get rid of resierfs_sync_super
  reiserfs: mark the superblock as dirty a bit later
  ...
2012-06-01 10:34:35 -07:00
Adam Jackson
47819ba234 drm/edid: Make the header fixup threshold tunable
6 bytes seems to be a reasonable default so far, but for the desperate
it's worth exposing this.

[airlied: change include to module.h for this]

Bugzilla: https://bugzilla.redhat.com/582559
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 17:00:23 +01:00
Alex Deucher
9b00147d9f drm/radeon: fix regression in UMS CS ioctl
radeon_cs_parser_init is called by both the legacy UMS
CS ioctl and the KMS CS ioctl.  Protect KMS specific
pieces of the code by checking that rdev is not NULL.

Reported-by: Michael Burian <michael.burian@sbg.at>

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 17:00:21 +01:00
Thomas Hellstrom
0824db38e5 drm/vmwgfx: Fix nasty write past alloced memory area
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 17:00:20 +01:00
Thomas Hellstrom
a8ff3ee211 drm/ttm: Fix spinlock imbalance
This imbalance may cause hangs when TTM is trying to swap out a buffer
that is already on the delayed delete list.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 17:00:19 +01:00
Alex Deucher
416a2bd274 drm/radeon: fixup tiling group size and backendmap on r6xx-r9xx (v4)
Tiling group size is always 256bits on r6xx/r7xx/r8xx/9xx. Also fix and
simplify render backend map. This now properly sets up the backend map
on r6xx-9xx which should improve 3D performance.

Vadim benchmarked also:
Some benchmarks on juniper (5750), fullscreen 1920x1080,
first result - kernel 3.4.0+ (fb21affa), second - with these patches:

Lightsmark:   91 fps => 123 fps    +35%
Doom3:        74 fps => 101 fps    +36%

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 17:00:14 +01:00
Jerome Glisse
95c4b23ec4 drm/radeon: fix HD6790, HD6570 backend programming
Without this bit sets we get broken rendering and
lockups.

fglrx sets this bit.

Bugs that should be fixed by this patch :
https://bugs.freedesktop.org/show_bug.cgi?id=49792
https://bugzilla.kernel.org/show_bug.cgi?id=43207
https://bugs.freedesktop.org/show_bug.cgi?id=39282

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 15:40:05 +01:00
Alex Deucher
0b8c30bc49 drm/radeon: properly program gart on rv740, juniper, cypress, barts, hemlock
Need to program an additional VM register.  This doesn't not currently
cause any problems, but allows us to program the proper backend
map in a subsequent patch which should improve performance on these
asics.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 15:36:54 +01:00
Alex Deucher
29d654067a drm/radeon: fix bank information in tiling config
While there are cards with more than 8 mem banks, the max
number of banks from a tiling perspective is 8, so cap
the tiling config at 8 banks.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=43448

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 15:36:31 +01:00
Dave Airlie
08ef8e41a6 drm/mgag200: kick off conflicting framebuffers earlier.
It appears grub2 can pass framebuffer info via efifb, so
we need to kick it off earlier to reserve the vram allocation.

(just a fixup same as for cirrus)

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 11:12:39 +01:00
Dave Airlie
dedc14e2a6 drm/cirrus: kick out conflicting framebuffers earlier
It appears that grub2 will pass framebuffer info via EFI,
this causes the vram reserve to fail, so kick out efifb
earlier before cirrus loads.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=826983
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-01 11:11:09 +01:00
Daniel Vetter
e269f90f3d Merge remote-tracking branch 'airlied/drm-prime-vmap' into drm-intel-next-queued
We need the latest dma-buf code from Dave Airlie so that we can pimp
the backing storage handling code in drm/i915 with Chris Wilson's
unbound tracking and stolen mem backed gem object code.

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-01 10:52:54 +02:00
Daniel Vetter
112abd291d drm/i915: simplify sysfs setup code
Positively checking for the required feature/gen is simpler than build
a cascade of negative "we need to bail" checks. And the later won't
scale if we add more stuff that doesn't fit in nicely.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-01 10:00:57 +02:00
Daniel Vetter
98fd81cd64 drm/i915: initialize the parity work only once
This fixes an (albeit really hard to hit) race resulting in an oops:
- The parity work get scheduled.
- We re-init the irq state and call INIT_WORK again.
- The workqueue code tries to run the work item and stumbles over a
  work item that should be on it's runlist.

Also initiliaze the work item unconditionally like all the others,
it's simpler.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-01 10:00:47 +02:00
Daniel Vetter
d2ba8470cc drm/i915: ivybridge_handle_parity_error should be static
Notice by Fengguang Wu's automatic sparse checker.

Reported-by: Fengguang Wu <wfg@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-01 10:00:27 +02:00
Dave Airlie
63bc620b45 radeon: add radeon prime vmap support.
This is the same as the nouveau code pretty much.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-31 14:14:01 +01:00
Dave Airlie
35916acedd nouveau: add vmap support to nouveau prime support
Tested sharing to udl.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-31 14:14:00 +01:00
Dave Airlie
e8aa1d1ebc udl: support vmapping imported dma-bufs
This allows udl to get a vmapping of an imported buffer for scanout.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-31 14:13:59 +01:00
Dave Airlie
9a70cc2a78 i915: add dma-buf vmap support for exporting vmapped buffer
This is used to export a vmapping to the udl driver so that
i915 and udl can share the udl scanout.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-31 14:13:57 +01:00
Dave Airlie
93b4cc56aa cirrus: avoid crash if driver fails to load
If we haven't inited the mm code, don't try and tear it down.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-31 13:53:56 +01:00
Chris Wilson
9e612a008f drm/i915/crt: Do not rely upon the HPD presence pin
Whilst most monitors do wire up the HPD presence pin, it seems quite a
few KVM do not. Therefore if we simply rely on the HPD pin being
asserted to indicate a connected monitor we fail miserable, so fall back
to performing a DCC query for the EDID.

Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-31 14:50:31 +02:00
Dave Airlie
946c7491b3 radeon: add stub dma-buf mmap functionality
This just adds a stub until we have pieces in place to test
a correct one.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-31 13:13:38 +01:00
Dave Airlie
e1bbc4bff9 nouveau: add stub dma-buf mmap functionality.
This just adds a stub until we have some users in place to test
this with.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-31 13:13:37 +01:00
Dave Airlie
2dad9d4d05 i915: add stub dma-buf mmap callback.
This just adds a stub for now, until we have some users in
place to test this functionality properly.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-31 13:13:31 +01:00
Ben Widawsky
84bc758124 drm/i915: l3 parity sysfs interface
Dumb binary interfaces which allow root-only updates of the cache
remapping registers. As mentioned in a previous patch, software using
this interface needs to know about HW limits, and other programming
considerations as the kernel interface does no checking for these things
on the root-only interface.

v1: Drop extra posting reads (Chris)
Return negative values in the sysfs interfaces on errors (Chris)

v2: Return -EINVAL for offset % 4 (Jesse)
Move schizo userspace check out (Jesse)
Cleaner sysfs item initializers (Daniel)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-31 12:29:21 +02:00
Ben Widawsky
b9524a1e1c drm/i915: remap l3 on hw init
If any l3 rows have been previously remapped, we must remap them after
GPU reset/resume too.

v2: Just return (no warn) on remapping init if not IVB (Jesse)
Move the check of schizo userspace to i915_gem_l3_remap (Jesse)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-31 12:11:29 +02:00
Ben Widawsky
15b9f80e00 drm/i915: enable parity error interrupts
The previous patch put all the code, and handlers in place. It should
now be safe to enable the parity error interrupt. The parity error must
be unmasked in both the GTIMR, and the CS IMR. Unfortunately, the docs
aren't clear about this; nevertheless it's the truth.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-31 12:07:13 +02:00
Ben Widawsky
e368919008 drm/i915: Dynamic Parity Detection handling
On IVB hardware we are given an interrupt whenever a L3 parity error
occurs in the L3 cache. The L3 cache is used by internal GPU clients
only.  This is a very rare occurrence (in fact to test this I need to
use specially instrumented silicon).

When a row in the L3 cache detects a parity error the HW generates an
interrupt. The interrupt is masked in GTIMR until we get a chance to
read some registers and alert userspace via a uevent. With this
information userspace can use a sysfs interface (follow-up patch) to
remap those rows.

Way above my level of understanding, but if a given row fails, it is
statistically more likely to fail again than a row which has not failed.
Therefore it is desirable for an operating system to maintain a lifelong
list of failing rows and always remap any bad rows on driver load.
Hardware limits the number of rows that are remappable per bank/subbank,
and should more than that many rows detect parity errors, software
should maintain a list of the most frequent errors, and remap those
rows.

V2: Drop WARN_ON(IS_GEN6) (Jesse)
DRM_DEBUG row/bank/subbank on errror (Jesse)
Comment updates (Jesse)

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-31 11:53:51 +02:00
Daniel Vetter
6c982376de drm/i915: s/mdelay/msleep/ in the sdvo detect function
A 30 ms delay is simply way too big to waste cpu cycles on.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-31 10:28:23 +02:00
Daniel Vetter
61e9653f0d drm/i915: reuse the sdvo tv clock adjustment in ilk mode_set
Jesse extracted this nice helper in his i9xx_crtc_mode_set refactor,
but we have the identical code in ironlake_ccrtc_mode_set. And that
function is huge, so extracting some code full of magic numbers is
always nice.

Noticed while trying to get a handle on our dp clock code.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-31 09:31:34 +02:00
Daniel Vetter
e5153dc09c drm/i915: there's no cxsr on ilk
Already discovered in

commit 5a117db77e
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date:   Thu Jan 5 09:34:29 2012 -0200

    drm/i915: there is no pipe CxSR on ironlake

but we've failed to rip out the code from the ironlake specific code.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-31 09:29:42 +02:00
Al Viro
244ca2b4d0 i810: switch to vm_mmap()
Weirdness around do_mmap() in there does not rely on ->mmap_sem for
exclusion, so no need to keep it under that.  As the result, we can
turn that do_mmap() into vm_mmap().

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-05-30 21:04:54 -04:00
Paulo Zanoni
9d9740f099 drm/i915: add some barriers when changing DIPs
On IVB and older, we basically have two registers: the control and the
data register. We write a few consecutitve times to the control
register, and we need these writes to arrive exactly in the specified
order.

Also, when we're changing the data register, we need to guarantee that
anything written to the control register already arrived (since
changing the control register can change where the data register
points to). Also, we need to make sure all the writes to the data
register happen exactly in the specified order, and we also *can't*
read the data register during this process, since reading and/or
writing it will change the place it points to.

So invoke the "better safe than sorry" rule and just be careful and
put barriers everywhere :)

On HSW we still have a control register that we write many times, but
we have many data registers.

Demanded-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 23:05:08 +02:00
Paulo Zanoni
c30b611090 drm/i915: remove comment about HSW HDMI DIPs
HSW support is now just like all the other generations: we send AVI
and SPD InfoFrames. There are other DIPs for HSW, but there are other
DIPs for the previous generations too. For each gen, we can see which
DIPs are missing by looking at the 'set_infoframes' function: we
explicitly disable the DIPs we're not using.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 23:04:27 +02:00
Paulo Zanoni
b659c3dbe1 drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI
The register that controls the HDMI port can be used to control the
sDVO port. Some bits are defined only for sDVO, and SDVO_BORDER_ENABLE
is one of those: HDMI ports that can't be used in sDVO mode don't even
have this bit defined in their specifications.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 23:04:10 +02:00
Paulo Zanoni
9d32d1653d drm/i915: don't write 0 to DIP control at HDMI init
At this time, the HDMI port is enabled, and the DIP control register
specification says we need to disable the port *before* disabling the
DIPs. Also, while doing this we risk telling the HW to send the AVI
DIPs once (not every VSync), which really seems to confuse the HW and
trigger bugs where the DIPs are not sent.

This code was here just to set the DIP register to a 'known state'
before using it, but since now the set_infoframes functions already
set the control registers to a known state, this code can go away.

Also, the previous code disables *all* the DIP registers for *each*
HDMI port, so we end disabling each DIP register more than once.

This patch solves a problem I can reproduce on my IVB machine. When I
boot it with just a single HDMI monitor, the AVI InfoFrames are not
sent. With this patch, the InfoFrames are sent. Previously, I wrote a
patch to 'touch the DIP registers after we enable the HDMI port' to
solve this same problem, but that patch doesn't seem to be needed
anymore after this patch.

All this patch does is revert a chunk of the following commit:

    commit 64a8fc0145
    Author: Jesse Barnes <jbarnes@virtuousgeek.org>
    Date:   Thu Sep 22 11:16:00 2011 +0530

        drm/i915: fix ILK+ infoframe support

So bugs that can be bisected to that commit may be fixed now.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43256
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 23:03:39 +02:00
Paulo Zanoni
72b78c9d19 drm/i915: disable DIP while changing the port
The register specification says we need to do this.

V2: Only write the register if the port is enabled.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 23:01:09 +02:00
Paulo Zanoni
0dd87d2084 drm/i915: explicitly disable the DIPs we're not using
From this point on, the 'set_infoframe' functions always set the DIP
registers to a known state, so anything done will always be undone at
the modeset.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 22:51:20 +02:00
Paulo Zanoni
5cde2a62e8 drm/i915: don't wait for vblank while writing InfoFrames
This function is called when the pipe is disabled, so it always gets
the 50ms timeout.

This function is called once for each InfoFrame, so we actually get a
100ms timeout. Will be more if we add more InfoFrames.

Also, the spec says we need to "wait for a VSync to ensure completion
of any pending DIP transmissions", not for a VBlank. OTOH, the
register documentation suggests that the DIPs are sent *during* the
VSync, so shouldn't we be waiting until *after* the VSync to ensure
all DIPs are sent?

So this wait_for_vblank seems, besides useless, totally wrong.

If we ever want to change some specific InfoFrame on-the-fly (outside
of the modeset code), the code that changes the InfoFrame will have to
do the waiting itself, and properly.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 21:52:46 +02:00
Paulo Zanoni
822974aea8 drm/i915: enable DIP before enabling each InfoFrame
So the write_infoframe function can assume the DIP is on.

V2: Be more defensive and add WARN().

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 21:51:03 +02:00
Paulo Zanoni
f278d97215 drm/i915: only set the HDMI port on the DIP once
Not once for each InfoFrame. Now we have a function that allows us to
do this.

[danvet: Paulo clarified on irc that a later bugfix patch needs this
cleanup.]

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 21:50:33 +02:00
Paulo Zanoni
0c14c7f957 drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.

When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.

When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.

Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.

This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
  - drm/i915: don't write 0 to DIP control at HDMI init

[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]

V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 21:38:21 +02:00
Paulo Zanoni
687f4d06db drm/i915: add set_infoframes to struct intel_hdmi
We need a function that is able to fully 'set' the state of the DIP
registers to a known state.

Currently, we have the write_infoframe function that is called twice:
once for AVI and once for SPD. The problem is that write_infoframe
tries to keep the state of the DIP register as it is, changing only
the minimum necessary bits. The second problem is that
write_infoframe does twice (once for each time it is called) some
work that should be done only once (like waiting for vblank and
setting the port). If we add even more DIPs, it will do even more
repeated work.

This patch only adds the infrastructure keeping the code behavior the
same as before.

v2: add static keywords

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-30 21:36:58 +02:00
Chris Wilson
c3b2003792 drm/i915: Reset last_retired_head when resetting ring
When we reset the ring control registers, including the HEAD and TAIL of
the ring, we also need to reset associated state. In this instance, we
were failing to reset the cached value of ring->last_retired_head and so
upon the first request for more space following a resume would
potentially (depending on a narrow race window) believe that the HEAD had
advanced much further than reality.

This is a regression from:

commit a71d8d9452
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Feb 15 11:25:36 2012 +0000

    drm/i915: Record the tail at each request and use it to estimate the head

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org # 3.4
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 20:06:58 +02:00
Adam Jackson
bc42aabc6a drm/edid/quirks: ViewSonic VA2026w
Entirely new class of fail for this one.  The detailed timings are for
normal CVT but the monitor really wanted CVT-R.

Bugzilla: http://bugzilla.redhat/com/516471
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-29 16:16:38 +01:00
Dave Airlie
1c780f2cfe drm/udl: remove unused variables.
These two variables were not required after new API was introduced.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-29 13:47:59 +01:00
Dave Airlie
a21f976094 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: tune down the noise of the RP irq limit fail
  drm/i915: Remove the error message for unbinding pinned buffers
  drm/i915: Limit page allocations to lowmem (dma32) for i965
  drm/i915: always use RPNSWREQ for turbo change requests
  drm/i915: reject doubleclocked cea modes on dp
  drm/i915: Adding TV Out Missing modes.
  drm/i915: wait for a vblank to pass after tv detect
  drm/i915: no lvds quirk for HP t5740e Thin Client
  drm/i915: enable vdd when switching off the eDP panel
  drm/i915: Fix PCH PLL assertions to not assume CRTC:PLL relationship
  drm/i915: Always update RPS interrupts thresholds along with frequency
  drm/i915: properly handle interlaced bit for sdvo dtd conversion
  drm/i915: fix module unload since error_state rework
  drm/i915: be more careful when returning -ENXIO in gmbus transfer
2012-05-29 11:09:06 +01:00
Alex Deucher
1ebf169ad4 drm/radeon: fix XFX quirk
Only override the ddc bus if the connector doesn't have
a valid one.  The existing code overrode the ddc bus for
all connectors even if it had ddc bus.

Fixes ddc on another XFX card with the same pci ids that
was broken by the quirk overwriting the correct ddc bus.

Reported-by: Mehdi Aqadjani Memar <m.aqadjanimemar@student.ru.nl>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-29 11:08:19 +01:00
Ville Syrjälä
592c20ee45 drm: Use stdint types for consistency
The rest of the code uses stdint types, so use them in
drm_property_change_is_valid() as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-29 11:07:09 +01:00
Ville Syrjälä
cff91b625f drm: Constify params to format_check() and framebuffer_checks()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-29 11:06:58 +01:00
Alex Deucher
1f73cca799 drm/radeon: fix typo in trinity tiling setup
Using the wrong union.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-29 11:05:01 +01:00
Dan Carpenter
ace281e8ab drm/udl: unlock before returning in udl_gem_mmap()
If we hit an error here, then we should unlock and unreference obj
before returning.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-29 11:02:50 +01:00