Dave Airlie [Thu, 26 Jul 2012 00:40:31 +0000 (10:40 +1000)]
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Daniel writes: (this pull is the one with the bad patch dropped)
First pile of fixes for 3.6 already, and I'm afraid it's a bit larger than
what I'd wish for. But I've moved all the feature-y stuff to -next, so
this really is all -fixes. Most of it is handling fallout from the hw
context stuff, discovered now that mesa git has started using them for
real. Otherwise all just small fixes:
- unbreak modeset=0 on gen6+ (regressed in next)
- const mismatch fix for ->mode_fixup
- simplify overly clever lvds modeset code (current code can totally
confuse backlights, resulting in broken panels until a full power draw
restores them).
- fix some fallout from the flushing_list disabling (regression only
introduced in -next)
- DP link train improvements (this also kills the last 3.2 dp regression
afaik)
- bugfix for the new ddc VGA detection on newer platforms
- minor backlight fixes (one of them a -next regression)
- only enable the required PM interrupts (to avoid waking up the cpu
unnecessarily)
- some really minor bits (workaround clarification, make coverty happy,
hsw init fix)
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (23 commits)
drm/i915: unbreak lastclose for failed driver init
drm/i915: Set the context before setting up regs for the context.
drm/i915: constify mode in crtc_mode_fixup
drm/i915/lvds: ditch ->prepare special case
drm/i915: dereferencing an error pointer
drm/i915: fix invalid reference handling of the default ctx obj
drm/i915: Add -EIO to the list of known errors for __wait_seqno
drm/i915: Flush the context object from the CPU caches upon switching
drm/i915: Make the lock for pageflips interruptible
drm/i915: don't forget the PCH backlight registers
drm/i915: Insert a flush between batches if the breadcrumb was dropped
drm/i915: missing error case in init status page
drm/i915: mask tiled bit when updating ILK sprites
drm/i915: try to train DP even harder
drm/i915: kill intel_ddc_probe
drm/i915: check whether we actually received an edid in detect_ddc
drm/i915: fix up PCH backlight #define mixup
drm/i915: Add comments to explain the BSD tail write workaround
drm/i915: Disable the BLT on pre-production SNB hardware
drm/i915: initialize power wells in modeset_init_hw
...
Dave Airlie [Thu, 26 Jul 2012 00:35:44 +0000 (10:35 +1000)]
Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: init vblank requests list
drm/nv50: extend vblank semaphore to generic dmaobj + offset pair
drm/nouveau: mark most of our ioctls as deprecated, move to compat layer
drm/nouveau: move current gpuobj code out of nouveau_object.c
drm/nouveau/gem: fix object reference leak in a failure path
drm/nv50: rename INVALID_QUERY_OR_TEXTURE error to INVALID_OPERATION
drm/nv84: decode PCRYPT errors
drm/nouveau: dcb table quirk for fdo#50830
nouveau: Fix alignment requirements on src and dst addresses
nouveau: Fix alignment requirements on src and dst addresses
Linear copy works by adding the offset to the buffer address,
which may end up not being 16-byte aligned.
Some tests I've written for prime_pcopy show that the engine
allows this correctly, so the restriction on lowest 4 bits of
address can be lifted safely.
The comments added were by envyas, I think because I used
a newer version.
Which results in the drm core calling our lastclose function to clean
up the mess, but that one is neatly broken for such failure cases
since kms has been introduced in
Eric Anholt [Mon, 23 Jul 2012 19:33:55 +0000 (12:33 -0700)]
drm/i915: Set the context before setting up regs for the context.
Fixes failures in transform feedback on gen7 because our SOL_RESET
flag was setting the transform feedback offsets in the old context
(occasionally happened to be ours) instead of the new context.
Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 11 Jul 2012 14:27:52 +0000 (16:27 +0200)]
drm/i915/lvds: ditch ->prepare special case
LVDS is the first output where dpms on/off and prepare/commit don't
perfectly match. Now the idea behind this special case seems to be
that for simple resolution changes on the LVDS we don't need to stop
the pipe, because (at least on newer chips) we can adjust the panel
fitter on the fly.
There are a few problems with the current code though:
- We still stop and restart the pipe unconditionally, because the crtc
helper code isn't flexible enough.
- We show some ugly flickering, especially when changing crtcs (this
the crtc helper would actually take into account, but we don't
implement the encoder->get_crtc callback required to make this work
properly).
So it doesn't even work as advertised. I agree that it would be nice
to do resolution changes on LVDS (and also eDP) whithout blacking the
screen where the panel fitter allows to do that. But imo we should
implement this as a special case a few layers up in the mode set code,
akin to how we already detect simple framebuffer changes (and only
update the required registers with ->mode_set_base).
Until this is all in place, make our lives easier and just rip it out.
Also note that this seems to fix actual bugs with enabling the lvds
output, see:
Cc: Takashi Iwai <tiwai@suse.de> Cc: Giacomo Comes <comes@naic.edu> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sun, 15 Jul 2012 11:34:23 +0000 (12:34 +0100)]
drm/i915: fix invalid reference handling of the default ctx obj
Otherwise we end up trying to unpin a freed object and BUG.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sun, 15 Jul 2012 11:34:22 +0000 (12:34 +0100)]
drm/i915: Flush the context object from the CPU caches upon switching
The issue is that we stale data in the CPU caches, when we come to
swap-out the object, the CPU may short-circuit the reads from those
cacheline and so corrupt the context object.
Secondary, leaving the context object as being marked in the CPU write
domain whilst on the GPU active list is a bad idea and will throw
warnings later.
Note: Thanks to calling set_to_gtt_domain with write = false and not
setting any gpu write domain when putting a context object onto the
active list (when we switch away from it) the set_to_gtt_domain call
won't block.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Added a note to the commit message and a comment in the code
to explain the clever non-blocking trick.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/radeon: on hotplug force link training to happen (v2)
To have DP behave like VGA/DVI we need to retrain the link
on hotplug. For this to happen we need to force link
training to happen by setting connector dpms to off
before asking it turning it on again.
v2: agd5f
- drop the dp_get_link_status() change in atombios_dp.c
for now. We still need the dpms OFF change.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)
No need to retrain the link for passive adapters.
v2: agd5f
- no passive DP to VGA adapters, update comments
- assign radeon_connector_atom_dig after we are sure
we have a digital connector as analog connectors
have different private data.
- get new sink type before checking for retrain. No
need to check if it's no longer a DP connection.
Cc: <stable@vger.kernel.org> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
We want to print link status query failed only if it's
an unexepected fail. If we query to see if we need
link training it might be because there is nothing
connected and thus link status query have the right
to fail in that case.
To avoid printing failure when it's expected, move the
failure message to proper place.
Cc: stable@vger.kernel.org Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dan Carpenter [Fri, 20 Jul 2012 11:17:00 +0000 (14:17 +0300)]
drm/radeon: check for allocation failure in radeon_ring_backup()
Static checkers complain if this we don't check for allocation failure.
Also we can use the new kmalloc_array() function here as a cleanup.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Retry label was at wrong place in function leading to memory
leak.
Cc: <stable@vger.kernel.org> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Ilija Hadzic [Tue, 15 May 2012 20:40:10 +0000 (16:40 -0400)]
drm: track dev_mapping in more robust and flexible way
Setting dev_mapping (pointer to the address_space structure
used for memory mappings) to the address_space of the first
opener's inode and then failing if other openers come in
through a different inode has a few restrictions that are
eliminated by this patch.
If we already have valid dev_mapping and we spot an opener
with different i_node, we force its i_mapping pointer to the
already established address_space structure (first opener's
inode). This will make all mappings from drm device hang off
the same address_space object.
Some benefits (things that now work and didn't work
before) of this patch are:
* user space can mknod and use any number of device
nodes and they will all work fine as long as the major
device number is that of the drm module.
* user space can even remove the first opener's device
nodes and mknod the new one and the applications and
windowing system will still work.
* GPU drivers can safely assume that dev->dev_mapping is
correct address_space and just blindly copy it
into their (private) bdev.dev_mapping
For reference, some discussion that lead to this patch can
be found here:
Patch 649bf3ca77343e3be1e0af8e21356fa569b1abd9 has completely
removed ttm_backend structure. Remove lingering declaration
and related (now stale) field in ttm_tt structure,
CC: Jerome Glisse <jglisse at redhat.com> Signed-off-by: Ilija Hadzic <ihadzic at research.bell-labs.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Chris Wilson [Wed, 23 May 2012 10:13:58 +0000 (11:13 +0100)]
drm/i915: Make the lock for pageflips interruptible
As we take the struct_mutex lock to access the command-stream, there is
a possibility that we may need to wait for a GPU hang and so should make
the lock both interruptible and error-checking.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50069 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Sat, 14 Jul 2012 14:57:12 +0000 (11:57 -0300)]
drm/i915: don't forget the PCH backlight registers
When we enable/disable the CPU backlight registers we can't forget to
enable/disable the PCH backlight registers. Since we're using the CPU
registers we should also unset the override bit.
Fixes a regression on the following commit:
drm/i915: properly enable the blc controller on the right pipe
The commit just deleted the code that sets the PCH registers, so it
was relying on the values set by the BIOS. I told my BIOS to boot on
the DVI monitor instead of the LVDS panel, so I noticed the bug.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 13 Jul 2012 13:14:08 +0000 (14:14 +0100)]
drm/i915: Insert a flush between batches if the breadcrumb was dropped
If we drop the breadcrumb request after a batch due to a signal for
example we aim to fix it up at the next opportunity. In this case we
emit a second batchbuffer with no waits upon the first and so no
opportunity to insert the missing request, so we need to emit the
missing flush for coherency. (Note that that invalidating the render
cache is the same as flushing it, so there should have been no
observable corruption.)
Note that beside simply adding the missing flush, avoiding potential
render corruption, this will also fix at least parts of the problem
introduced by some funny interaction of these two commits:
The issue happens when we submit a batch & emit it, but get
interrupted (thanks to the first patch) while trying to emit the
flush. On the next batch we still assume that the full gpu domain
handling is in effect and hence compute the invalidate&flushing
domains. But thanks to the 2nd patch we totally ignore these and only
invalidate all gpu domains, presuming that any required flushes have
been issued already. Which is wrong and eventually results in us
updating the new write_domain values with the computed
pending_write_domain values, which leaves an object with write_domain
== 0 on the gpu_write_list.
As soon as we try to unbind that object, things blow up.
Fix this by emitting the missing flush according to the new
ring->gpu_caches_dirty flag.
Note that this does _not_ fix all the current cases where we end up
with an object on the flushing_list that can't be flushed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52040 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add bug explanation to commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: mask tiled bit when updating ILK sprites
Or going from tiled to untiled may break.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 29 Jun 2012 19:03:34 +0000 (16:03 -0300)]
drm/i915: try to train DP even harder
While debugging Haswell link train failures I observed that we never
try the maximum voltage configuration more than once consecutively. We
start the training, the monitor keeps telling us to increase the
voltage, then when we reach the maximum we just go back to the start
(because of the "memset" above "voltage_tries = 0"). When we reach
this point, we keep alternating between the maximum and the minimum
voltages until we give up.
The DP spec suggests that we should try the same voltage 5 times
before giving up. This patch makes us try the maximum voltage at
least 5 times before going back to the minimum voltages.
This patch does not fix any particular bug I'm aware of.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 11 Jul 2012 10:31:52 +0000 (12:31 +0200)]
drm/i915: check whether we actually received an edid in detect_ddc
Somehow detect_ddc manages to fall through all checks when we think
that something responds on the ddc i2c address, but the edid read
failed. Fix this up by explicitly checking for this case.
This fixes a regression on newer chips because since
drm/i915/crt: Do not rely upon the HPD presence pin
we use ddc detection also on hotplug capable platforms. And one of
these reads all 0s for any i2c transaction if nothing is connected to
the vga port.
v2: Implement Chris Wilson's review:
- simplify logic, default to "nothing detected"
- kill stale comment
- BUG_ON(!crt->type != ANALOG)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51900 Tested-by: Yang Guang <guang.a.yang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 5 Jul 2012 16:14:01 +0000 (17:14 +0100)]
drm/i915: Add comments to explain the BSD tail write workaround
Having had to dive into the bspec to understand what each stage of the
workaround meant, and how that the ring broadcasting IDLE corresponded
with the GT powering down the ring (i.e. rc6) add comments to aide
the next reader.
And since the register "is used to control all aspects of PSMI and power
saving functions" that makes it quite interesting to inspect with
regards to RC6 hangs, so add it to the error-state.
v2: Rediscover the piece of magic, set the RNCID to 0 before waiting for
the ring to wake up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 5 Jul 2012 22:49:40 +0000 (23:49 +0100)]
drm/i915: Disable the BLT on pre-production SNB hardware
It never quite worked despite the numerous workarounds, yet I still see
people trying to use this hardware and filing bug reports. As we no
longer even try to implement the workarounds, since 6a233c78878
(drm/i915/ringbuffer: kill snb blt workaround), simply disable the ring.
v2: Add a message to inform the user about the limited capabilities of
their pre-production hardware.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: initialize power wells in modeset_init_hw
This initializes power wells within the modeset_init_hw routine.
Testing has shown that this works for both driver load time and for
suspend-resume code paths.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 5 Jul 2012 14:02:17 +0000 (15:02 +0100)]
drm/i915: Only request PM interrupts for the events we handled
There is little point waking up every 10ms to service an interrupt which
we then promptly ignore. So only program the the PMIER to enable
interrupts for those events which we do handle, not all of them!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eugeni Dodonov <eugeni.dodonov@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Wed, 18 Jul 2012 17:10:09 +0000 (10:10 -0700)]
drm/i915/context/: s/CTX/CXT
*sigh* the docs had it spelled wrong, corrected it, and then proceeded
to re-do the original error. The original code preserved this history,
and this patch attempts to keep in sync with the current docs.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Sun, 24 Jun 2012 17:57:24 +0000 (19:57 +0200)]
drm/sis: fixup sis_mm ioctl structs
Userspace uses long in quite a few places more than the kernel. Which
gives me neat proof that I'm the only guy on this side of the galaxy
who ever tried to run glxgears on a 64bit machine with sis graphics on
linux.
Note that the longs in drm_sis_mem_t aren't aligned properly, so this
won't even work with 32bit userspace on 64bit kernel as-is. Hence the
patch can't break that, either.
Nope, I'm not nuts enough to write the 32bit ioctl compat layer for
this and test it with some wine app. Even though hunting the ebay
dungeons for a sis card actually supported by the mesa drivers casts
some doubts on this ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Tue, 25 Oct 2011 22:53:57 +0000 (00:53 +0200)]
drm: ditch strange DRIVER_DMA_QUEUE only error bail-out
Only one driver (i810) even sets that flag. Now the actual locking
code uncoditionally promotes lock->context to an unsigned int.
Closer inspection of the userspace reveals that the drm lock context
is defined as an unsigned int (at least on linux). I suspect we just
have a strange case of signedness confusion going on.
Tested on my i815, doesn't seem to break anything.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Tue, 25 Oct 2011 22:14:15 +0000 (00:14 +0200)]
drm/savage: clean up reclaim_buffers
The reclaim_buffers function of the savage driver actually wants to run
with the hw_lock held - at least there are printks in the call-chain
to that effect. But the drm core only calls reclaim_buffers as used
by savage _after_ forcefully dropping the hwlock (in case it's still
hold by the closing fd).
So do the same idlelock dance as for the other dma drivers and hope
that papers over any issues.
v2: Don't let the idlelock linger around.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Tormod Volden <debian.tormod@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
My dear old i815 always hits the deadlocked on reclaim_buffers
warning. Switch over to the idlelock duct-tape on hope that
works better. I've fired up my i815 and now closing glxgears doesn't
take 5 seconds anymore. \o/
The original problem with that was that I've moved it ahead in the
series so that it could be included despite some patches not being
ready quite yet. The little problem is that this patch required some
of the previous rework to work correctly.
Now that everything is in the right order again, this actually works
on my i810 and does speed up closing gl apps as the original commit
claimed. Without hanging the machine, as the revert says.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Tue, 25 Oct 2011 21:37:09 +0000 (23:37 +0200)]
drm/via: clean up reclaim_buffers
A few things
- kill reclaim_buffers, it's never ever called because via does not set
DRIVER_HAVE_DMA
- inline the idlelock dance into the buffer reclaim logic and make it
a simple preclose cleanup function
- directly call the the dma_quiescent function and kill the needless
if check.
v2: Actually drop the idlelock when we take it. Reported by James
Simmons.
v3: Rebased onto latest drm-next.
v4: Fixup the refactor.
v5: More fixup the refactor - I've accidentally changed the check for
any master to checking whether the closing fd is the master.
v6: Don't forget to drop the idlelock in the early return path, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Michel Dänzer [Tue, 17 Jul 2012 17:02:09 +0000 (19:02 +0200)]
drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.
This could previously fail if either of the enabled displays was using a
horizontal resolution that is a multiple of 128, and only the leftmost column
of the cursor was (supposed to be) visible at the right edge of that display.
The solution is to move the cursor one pixel to the left in that case.
Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Daniel Vetter [Fri, 15 Jun 2012 09:01:22 +0000 (11:01 +0200)]
drm/fb-helper: delay hotplug handling when partially bound
Ok, this requires quite a dance to actually hit:
1) We plug in a 2nd screen, enable it in both X and (by vt-switching)
in the fbcon.
2) We disable that screen again in with xrandr.
3) We vt-switch again, so that fbcon displays on the 2nd screen, but X
on the first screen. This obviously needs a driver that doesn't switch
off unused functions when regaining the VT.
3) When X controls the vt, we unplug that screen.
Now drm_fb_helper_hotplug_event we noticed that that some crtcs are
bound, but because we still have the fbcon on the 2nd screeen we also
have bound set. Which means the fbcon wrongly assumes it's in control
of everything an happily disables the output on the 2nd screen, but
enables its fb on the first screen.
Work around this issue by counting how many crtcs are bound and how
many are bound to fbcon and assuming that when fbcon isn't bound to
all of them, it better not touch the output configuration.
Conceptually this is the same as only restoring the fbcon output
configuration on the driver's ->lastclose, when we're sure that no one
else is using kms. So this should be consistent with existing kms
drivers.
Chris has created a separate patch for the intel ddx, but I think we
should fix this issue here regardless - the fbcon messing with the
output config while it's not fully in control simply isn't a too
polite behaviour.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772 Tested-by: Maxim A. Nikulin <M.A.Nikulin@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 20 Jul 2012 01:20:54 +0000 (21:20 -0400)]
Merge branch 'next' of git://people.freedesktop.org/~deathsimple/linux into drm-next
This contains all the radeon documentation rebased on top of the ib fixes.
* 'next' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: fix SS setup for DCPLL
drm/radeon: fix up pll selection on DCE5/6
drm/radeon: start to document evergreen.c
drm/radeon: start to document the functions r100.c
drm/radeon: document VM functions in radeon_gart.c (v3)
drm/radeon: document non-VM functions in radeon_gart.c (v2)
drm/radeon: document radeon_ring.c (v4)
drm/radeon: document radeon_fence.c (v2)
drm/radeon: document radeon_asic.c
drm/radeon: document radeon_irq_kms.c
drm/radeon: document radeon_kms.c
drm/radeon: document radeon_device.c (v2)
drm/radeon: add rptr save support for r1xx-r5xx
drm/radeon: update rptr saving logic for memory buffers
drm/radeon: remove radeon_ring_index()
drm/radeon: update ib_execute for SI (v2)
drm/radeon: fix const IB handling v2
drm/radeon: let sa manager block for fences to wait for v2
drm/radeon: return an error if there is nothing to wait for
Alex Deucher [Tue, 17 Jul 2012 18:02:43 +0000 (14:02 -0400)]
drm/radeon: fix up pll selection on DCE5/6
Selecting ATOM_PPLL_INVALID should be equivalent as the
DCPLL or PPLL0 are already programmed for the DISPCLK, but
the preferred method is to always specify the PLL selected.
SetPixelClock will check the parameters and skip the
programming if the PLL is already set up.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
Alex Deucher [Tue, 17 Jul 2012 18:02:37 +0000 (14:02 -0400)]
drm/radeon: document radeon_fence.c (v2)
Adds documentation to most of the functions in
radeon_fence.c
v2: address Christian's comments:
- split common concept description into it's own comment
- fix description of intr parameter
- Improve description of -EDEADLK error
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
Alex Deucher [Tue, 17 Jul 2012 18:02:29 +0000 (14:02 -0400)]
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>
Christian König [Mon, 9 Jul 2012 09:52:44 +0000 (11:52 +0200)]
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>
Christian König [Fri, 6 Jul 2012 14:22:55 +0000 (16:22 +0200)]
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>
Christian König [Sat, 7 Jul 2012 10:47:58 +0000 (12:47 +0200)]
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>
Christian König [Thu, 5 Jul 2012 12:32:00 +0000 (14:32 +0200)]
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>
Christian König [Wed, 4 Jul 2012 19:36:53 +0000 (21:36 +0200)]
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>
Christian König [Thu, 5 Jul 2012 11:33:41 +0000 (13:33 +0200)]
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>
Christian König [Sat, 7 Jul 2012 11:10:39 +0000 (13:10 +0200)]
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>
Christian König [Mon, 9 Jul 2012 08:52:39 +0000 (10:52 +0200)]
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>
Christian König [Sat, 7 Jul 2012 10:11:32 +0000 (12:11 +0200)]
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>
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>
projects / ~andy / linux / log