James Simmons [Mon, 20 Dec 2010 19:10:39 +0000 (19:10 +0000)]
drm/fb: Don't expose mmio for fbdev emulation layer
For the fbdev api if the struct fb_var_screeninfo accel_flags field is set
to FB_ACCELF_TEXT then userland applications can not mmap the mmio region.
Since it is a bad idea for DRM drivers to expose the mmio region via the
fbdev layer we always set the accel_flags to prevent this. Please apply.
Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Thu, 16 Dec 2010 04:49:02 +0000 (14:49 +1000)]
Merge remote branch 'nouveau/drm-nouveau-next' of ../drm-nouveau-next into drm-core-next
* 'nouveau/drm-nouveau-next' of ../drm-nouveau-next: (93 commits)
drm/nv50: fix a couple of vm init issues
drm/nv04-nv40: Fix up PCI(E) GART DMA object bus address calculation.
drm/nouveau: kick vram functions out into an "engine"
drm/nouveau: allow gpuobj vinst to be a virtual address when necessary
drm/nv50: tidy up PCIEGART implementation
drm/nv50: enable non-contig vram allocations where requested
drm/nv50: enable 4KiB pages for small vram allocations
drm/nv50: implement global channel address space on new VM code
drm/nv50: implement BAR1/BAR3 management on top of new VM code
drm/nv50: import new vm code
drm/nv50: implement custom vram mm
drm/nouveau: Avoid potential race between nouveau_fence_update() and context takedown.
drm/nouveau: fix use of drm_mm_node in semaphore object
drm/nouveau: wrap calls to ttm_bo_validate()
drm/nouveau: no need to zero dma objects, we fill them completely anyway
drm/nouveau: introduce a util function to wait on reg != val
drm/nouveau: implicitly insert non-DMA objects into RAMHT
drm/nouveau: make fifo.create_context() responsible for mapping control regs
drm/nouveau: Spin for a bit in nouveau_fence_wait() before yielding the CPU.
drm/nouveau: Use WC memory on the AGP GART.
...
Ben Skeggs [Thu, 16 Dec 2010 04:47:46 +0000 (14:47 +1000)]
drm/ttm: delay freeing of old node during move_memcpy until after iounmap
Drivers using their own implementation of io_mem_reserve/io_mem_free are
likely to store the tracking information for the map in mem.mm_node, so
it can't be freed while still mapped.
Signed-off-by: Ben Skeggs<bskeggs@redhat.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Francisco Jerez [Thu, 16 Dec 2010 00:30:35 +0000 (10:30 +1000)]
drm/nv50: fix a couple of vm init issues
Fixes overwriting the first page table entry when testing that the PRAMIN
BAR can be correctly read/written, and adds an additional bar flush after
poking the BAR3 control regs.
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Mon, 6 Dec 2010 05:28:54 +0000 (15:28 +1000)]
drm/nouveau: kick vram functions out into an "engine"
NVC0 will be able to share some of nv50's paths this way. This also makes
it the card-specific vram code responsible for deciding if a given set
of tile_flags is valid, rather than duplicating the allowed types in
nv50_vram.c and nouveau_gem.c
Ben Skeggs [Wed, 25 Aug 2010 05:26:04 +0000 (15:26 +1000)]
drm/nv50: implement custom vram mm
This is required on nv50 as we need to be able to have more precise control
over physical VRAM allocations to avoid buffer corruption when using
buffers of mixed memory types.
This removes some nasty overallocation/alignment that we were previously
using to "control" this problem.
Ben Skeggs [Mon, 22 Nov 2010 06:05:54 +0000 (16:05 +1000)]
drm/nouveau: make fifo.create_context() responsible for mapping control regs
The regs belong to PFIFO, they're different for pretty much the same
generations we need different PFIFO control for, and NVC0 is going
to be even more different than the rest.
Francisco Jerez [Thu, 18 Nov 2010 22:57:46 +0000 (23:57 +0100)]
drm/nouveau: Synchronize with the user channel before GPU object destruction.
There have been reports of PFIFO cache errors during context take down
(fdo bug 31637). They are caused by some GPU objects being taken out
while the channel is still potentially processing commands. Make sure
that all the previous rendering has landed before releasing a GPU
object.
Reported-by: Grzesiek Sójka <pld@pfu.pl> Reported-by: Patrice Mandin <patmandin@gmail.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez [Sat, 20 Nov 2010 13:43:51 +0000 (14:43 +0100)]
drm/nv04-nv10: Don't re-enable FIFO access multiple times after IRQ dispatch.
nvxx_graph_isr is already taking care of it. In some cases this
could've made you miss PGRAPH interrupts (e.g. when you were supposed
to get several IRQs of the same kind in a row).
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez [Sun, 24 Oct 2010 14:14:41 +0000 (16:14 +0200)]
drm/nouveau: Rework tile region handling.
The point is to share more code between the PFB/PGRAPH tile region
hooks, and give the hardware specific functions a chance to allocate
per-region resources.
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez [Mon, 25 Oct 2010 21:38:59 +0000 (23:38 +0200)]
drm/nouveau: Add a separate class for the kernel channel mutex.
nouveau_bo_move_m2mf() needs to lock the kernel channel, and it may be
called from the pushbuf IOCTL with an user channel already locked. Use
a separate subclass for the kernel channel mutex because this is
legitimate mutex nesting.
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez [Sun, 24 Oct 2010 12:15:58 +0000 (14:15 +0200)]
drm/nv50: Keep track of the head a channel is vsync'ing to.
In a multihead setup vblank interrupts may end up enabled in both
heads. In that case we want to ignore the vblank interrupts coming
from the wrong CRTC to avoid tearing and unbalanced calls to
drm_vblank_get/put (fdo bug 31074).
Reported-by: Felix Leimbach <felix.leimbach@gmx.net> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Marcin Slusarz [Wed, 20 Oct 2010 19:50:24 +0000 (21:50 +0200)]
drm/nouveau: fix annoying nouveau_fence type issue
nouveau_fence_* functions are not type safe, which could lead to bugs.
Additionally every use of nouveau_fence_unref had to cast struct
nouveau_fence to void **.
Fix it by renaming old functions and creating static inline functions with
new prototypes. We still need old functions, because we pass function
pointers to ttm.
As we are wrapping functions, drop unused "void *arg" parameter where possible.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Thu, 21 Oct 2010 04:07:03 +0000 (14:07 +1000)]
drm/nouveau: add support for MSI
Only supported on NV50+ so far, and disabled by default currently. The
module parameter "msi=1" will enable it.
There's a kernel bug which will cause this to fail if the module (or the
NVIDIA binary driver) has ever been loaded before loading nouveau with
MSI enabled. As such, this is only safe to enable if you have nouveau
load on boot, and don't wish to ever reload it.
The workaround is to "echo 0 > /sys/bus/pci/devices/<device>/enable"
until the enable count reads 0. Then you should be able to load nouveau
with MSI enabled.
Ben Skeggs [Wed, 20 Oct 2010 01:47:09 +0000 (11:47 +1000)]
drm/nv50: create graph and crypt contexts on demand
This really needs cleaning up somehow, and probably investigate what's
needed to do this on earlier generations. NVIDIA do something similar
there too.
Francisco Jerez [Mon, 18 Oct 2010 01:56:40 +0000 (03:56 +0200)]
drm/nouveau: Avoid race in the interchannel sync code.
It needs a "strong" channel reference because it actually writes to
the channel pushbuf, otherwise the corresponding FIFO context could
get kicked off in the middle of nouveau_fence_sync().
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez [Mon, 18 Oct 2010 01:56:14 +0000 (03:56 +0200)]
drm/nouveau: Make fences take a weak channel reference.
Fences didn't increment the channel reference count, and the fenced
channel could go away at any time. Fixes a potential race in
nouveau_fence_update().
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez [Mon, 18 Oct 2010 01:55:48 +0000 (03:55 +0200)]
drm/nouveau: Implement weak channel references.
nouveau_channel_ref() takes a "weak" channel reference that doesn't
prevent the hardware channel resources from being released, it just
keeps the channel data structure alive.
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez [Mon, 18 Oct 2010 01:54:33 +0000 (03:54 +0200)]
drm/nouveau: Fix race condition in channel refcount handling.
nouveau_channel_put() can be executed after the 'refcount == 0' check
in nouveau_channel_get() and before the channel reference count is
incremented. In that case CPU0 will take the context down while CPU1
thinks it owns the channel and 'refcount == 1'.
Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez [Mon, 18 Oct 2010 01:53:39 +0000 (03:53 +0200)]
drm/nouveau: Refactor context destruction to avoid a lock ordering issue.
The destroy_context() engine hooks call gpuobj management functions to
release the channel resources, these functions use HARDIRQ-unsafe locks
whereas destroy_context() is called with the HARDIRQ-safe
context_switch_lock held, that's a lock ordering violation.
Push the engine-specific channel destruction logic into destroy_context()
and let the hardware-specific code lock and unlock when it's actually
needed. Change the engine destruction order to avoid a race in the small
gap between pgraph and pfifo context uninitialization.
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs [Tue, 5 Oct 2010 06:53:48 +0000 (16:53 +1000)]
drm/nouveau: add per-channel mutex, use to lock access to drm's channel
This fixes a race condition between fbcon acceleration and TTM buffer
moves. To reproduce:
- start X
- switch to vt and "while (true); do dmesg; done"
- switch to another vt and "sleep 2 && cat /path/to/debugfs/dri/0/evict_vram"
- switch back to vt running dmesg
We don't make use of this on any other channel yet, they're currently
protected by drm_global_mutex. This will change in the near future.
Ben Skeggs [Tue, 5 Oct 2010 06:41:29 +0000 (16:41 +1000)]
drm/nouveau: disallow fbcon accel if running in interrupt context
A future commit will add locking to the DRM's channel, and there's numerous
problems that come up if we allow printk from an interrupt context to be
accelerated. It seems saner to just disallow it completely.
As a nice side-effect, all the "to accel or not to accel" logic gets moved
out of the chipset-specific code.
Dave Airlie [Fri, 3 Dec 2010 04:01:08 +0000 (14:01 +1000)]
Merge branch 'drm-radeon-fusion' of ../drm-radeon-next into drm-core-next
* 'drm-radeon-fusion' of ../drm-radeon-next:
drm/radeon/kms: add Ontario APU ucode loading support
drm/radeon/kms: add Ontario Fusion APU pci ids
drm/radeon/kms: enable MSIs on fusion APUs
drm/radeon/kms: add power table parsing support for Ontario fusion APUs
drm/radeon/kms: refactor atombios power state fetching
drm/radeon/kms: add bo blit support for Ontario fusion APUs
drm/radeon/kms: add thermal sensor support for fusion APUs
drm/radeon/kms: fill in GPU init for AMD Ontario Fusion APUs
drm/radeon/kms: add radeon_asic struct for AMD Ontario fusion APUs
drm/radeon/kms: evergreen.c updates for fusion
drm/radeon/kms: MC setup changes for fusion APUs
drm/radeon/kms: move r7xx/evergreen to its own vram_gtt setup function
drm/radeon/kms: add support for ss overrides on Fusion APUs
drm/radeon/kms: Add support for external encoders on fusion APUs
drm/radeon/kms: atom changes for DCE4.1 devices
drm/radeon/kms: add new family id for AMD Ontario APUs
drm/radeon/kms: upstream power table updates
drm/radeon/kms: upstream atombios.h updates
drm/radeon/kms: upstream ObjectID.h updates
drm/radeon/kms: setup mc chremap properly on r7xx/evergreen
projects / linux-beck.git / log