drm/exynos: use __free_page() to deallocate memory
this patch uses __free_page() to deallocate the pages allocated
by alloc_page() and the pages doesn't need set_parge_dirty()
and mark_page_accessed() because they aren't from page cache so
removes them.
this patch has a pair with previous patch below,
http://www.spinics.net/lists/dri-devel/msg24382.html
Changelog v2:
remove unnecessary arguments.
Changelog v3:
fix npages type.
- npages can have negative value.
Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Inki Dae [Thu, 7 Jun 2012 07:15:07 +0000 (16:15 +0900)]
drm/exynos: set buffer type from exporter.
when fd is imported to gem, whether the memory type from exporter
is contigous or not should be set to gem flag so that drm-based
driver can aware of the memory type.
Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Inki Dae [Thu, 7 Jun 2012 06:59:48 +0000 (15:59 +0900)]
drm/exynos: use alloc_page() to allocate pages.
shmem_read_mapping_page_gfp() first tries to allocate pages from page cache
so if pages are allocated from page cache then these pages could have
valid cache line. after that cpu may read garbage data from cache
once gpu operation is completed with allocated pages. so with this patch,
Non-contiguous memory allocation request allocates pages from highmem
through alloc_page() with GFP_HIGHUSER_MOVABLE.
Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Subash Patel [Mon, 25 Jun 2012 18:22:57 +0000 (11:22 -0700)]
drm/exynos: check for null in return value of dma_buf_map_attachment()
dma_buf_map_attachment() can return NULL and valid sg as return
value. Hence the check for the returned scatter-gather must be using
the inline function IS_ERR_OR_NULL() in place of IS_ERR()
Subash Patel [Mon, 25 Jun 2012 18:22:56 +0000 (11:22 -0700)]
drm/exynos: return NULL if exynos_pages_to_sg fails
exynos_pages_to_sg() internally calls sg_kmalloc() which can return
no pages when the system is under high memory crunch. One such instance
is chromeos-install in the chromeos. This patch adds check for the return
value of the function in subject to return NULL on failure.
Sachin Kamat [Wed, 13 Jun 2012 08:47:09 +0000 (14:17 +0530)]
drm/exynos: Add missing static storage class specifier
Fixes the following sparse warning:
drivers/gpu/drm/exynos/exynos_drm_connector.c:199:20:
warning: symbol 'exynos_drm_best_encoder' was not declared. Should it be static?
Joonyoung Shim [Wed, 27 Jun 2012 05:27:11 +0000 (14:27 +0900)]
drm/exynos: add property for crtc mode
This patch adds exynos specific property for crtc mode. The crtc mode
property has tow modes - normal and blank. The normal mode is default
mode and can use crtc normally. The blank mode turns off the private
plane of crtc, so we don't see crtc screen but can see other plane
screens.
Joonyoung Shim [Wed, 27 Jun 2012 05:27:06 +0000 (14:27 +0900)]
drm/exynos: add property for plane zpos
The exynos drm driver used a specific ioctl - DRM_EXYNOS_PLANE_SET_ZPOS
to set zpos of plane. It can be substitute to property of plane. This
patch adds a property for plane zpos and removes
DRM_EXYNOS_PLANE_SET_ZPOS ioctl.
Joonyoung Shim [Wed, 27 Jun 2012 05:27:05 +0000 (14:27 +0900)]
drm/exynos: update overlay via plane from crtc
There is no any reason to update overlay at crtc directly because the
crtc uses plane. Move its code to plane and call proper functions of
plane from crtc.
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>
projects / linux-beck.git / log