ioremap must be balanced by an iounmap and failing to do so can result
in a memory leak.
Tested (compilation only) to make sure the files are compiling without
any warning/error due to new changes
Signed-off-by: Amol Lad <amol@verismonetworks.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
I need the following patch to fix compilation of
latest drm/linux-core on my ppc64 machine.
/home/mb/develop/git/drm/linux-core/savage_bci.c: In function ‘savage_driver_firstopen’:
/home/mb/develop/git/drm/linux-core/savage_bci.c:587: error: ‘DRM_MTRR_WC’ undeclared (first use in this function)
/home/mb/develop/git/drm/linux-core/savage_bci.c:587: error: (Each undeclared identifier is reported only once
/home/mb/develop/git/drm/linux-core/savage_bci.c:587: error: for each function it appears in.)
/home/mb/develop/git/drm/linux-core/savage_bci.c: In function ‘savage_driver_lastclose’:
/home/mb/develop/git/drm/linux-core/savage_bci.c:664: error: ‘DRM_MTRR_WC’ undeclared (first use in this function)
I looked at in-kernel drmP.h and it actually
has the same fix in it.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Replace r300_check_offset() with generic radeon_check_offset(), which doesn't
reject valid offsets when the framebuffer area is at the very end of the card's
32 bit address space. Make radeon_check_and_fixup_offset() use
radeon_check_offset() as well.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=7697 .
The current version didn't build on BSD, where the new functionality isn't used
yet anyway. Whoever changes that will hopefully be able to make the OSes share
this file as well.
Previously, if there were several buffer swaps scheduled for the same vertical
blank, all but the first blit emitted stood a chance of exhibiting tearing. In
order to avoid this, split the blits along slices of each output top to bottom.
This will come in very handy for tiled buffers on intel hardware.
Also add some padding to interface structures to allow future binary backwards
compatible changes.
This makes an allocated block actually align itself and returns any
wasted space to the manager.
Also add some functions to grow and shrink the managed area.
This will be used in the future to manage the buffer object swap cache.
otherwise data will be missing, which becomes apparent when the kernel evicts
batch buffers which are likely to be written into in the evicted state,
and then rebound to the AGP aperture.
This means we cannot rely on the AGP module to flush the
cache for us.
driver we're on.
Avoid global cache flushes before inserting pages.
In general, they are never mapped, and not accessed through the kernel map, so
a cache flush should not be necessary. The exception is pages that are bound
cached. We might need a cache flush for those.
The mm_lock function is used when leaving vt. It evicts _all_ buffers.
Buffers with the DRM_BO_NO_MOVE attribute set will be guaranteed to
get the same offset when / if they are rebound.
Fix buffer bound caching policy changing, Allow
on-the-fly changing of caching policy on bound buffers if the hardware
supports it.
Allow drivers to use driver-specific AGP memory types for TTM AGP pages.
Will make AGP drivers much easier to migrate.
Adapt for new functions in the 2.6.19 kernel.
Remove the ability to have multiple regions in one TTM.
This simplifies a lot of code.
Remove the ability to access TTMs from user space.
We don't need it anymore without ttm regions.
Don't change caching policy for evicted buffers. Instead change it only
when the buffer is accessed by the CPU (on the first page fault).
This tremendously speeds up eviction rates.
Current code is safe for kernels <= 2.6.14.
Should also be OK with 2.6.19 and above.
mach64_state.c: convert the DRM_MACH64_BLIT ioctl to submit a pointer to
user-space memory rather than a DMA buffer index, similar to DRM_MACH64_VERTEX.
This change allows the DDX to map the DMA buffers read-only and eliminate a
security problem where a client can alter the contents of the DMA buffer after
submission to the DRM.
This change also affects the DRI/DRM interface. Performace-wise, it basically
affects PCI mode where I get a ~12% speedup for some Mesa demos I tested.
This is mainly due to eliminating an ioctl for allocating the DMA buffer.
mach64_dma.c: move the responsibility for allocating memory for the DMA ring
in PCI mode to the DDX.
This change affects the DDX/DRM interface and unifies a couple of PCI/AGP code
paths for ring memory in the DRM.
Bump the mach64 DRM version major and date.
