As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending "\n" was added.
airlied:- I cleaned up a few that this patch missed also
Flags pending validation were stored in a misleadingly named field, 'mask'.
As 'mask' is already used to indicate pieces of a flags field which are
changing, it seems better to use a name reflecting the actual purpose of
this field. I chose 'proposed_flags' as they may not actually end up in
'flags', and in an case will be modified when they are moved over.
This affects the API, but not ABI of the user-mode interface.
drivers/char/drm/mga_dma.c::mga_do_cleanup_dma() and I think there's a small
problem.
The variable is only used inside #if __OS_HAS_AGP which is fine, but all
that
ever happens is an assignment to the variable - it is never actually used
for
anything. The variable is nicely initialized to zero which is also what the
return statement at the end of function returns (always at the moment).
It looks to me like that function should be returning 'err' instead of
always
just returning 0. Here's a patch to do that.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Document parameters and usage for drm_bo_handle_validate. Change parameter
order to match drm_bo_do_validate (fence_class has been moved to after
flags, hint and mask values). Existing users of this function have been
changed, but out-of-tree users must be modified separately.
Add comments about the parameters to drm_bo_do_validate, along
with comments for the DRM_BO_HINT options. Remove the 'do_wait'
parameter as it is duplicated by DRM_BO_HINT_DONT_BLOCK.
One of the costs of superioctl has been the need to perform relocations
inside the kernel. The cost of mapping the buffers to the CPU and writing
data is fairly high, especially if those buffers have been mapped and read
by the GPU.
If we assume that buffers don't move around very often, we can have the
client compute the relocations itself using the previous GPU address. When
that object doesn't move, the kernel can skip computing and writing the
updated data.
Here's a patch which adds a new field to struct drm_bo_info_req called
'presumed_offset', and a new DRM_BO_HINT_PRESUMED_OFFSET that is set when
this field has been filled in by the client.
There are two separate optimizations performed when the presumed_offset is
correct:
1. i915_exec_reloc checks to see if all previous buffer offsets were guessed
correctly. If so, there's no need for it to look at *any* of the
relocations for a buffer. When this happens, it skips the whole
relocation process, simply returning success.
2. i915_apply_reloc checks to see if the target buffer offset was guessed
correctly. If so, it skips mapping the relocatee, computing the
relocation and writing the value. If no relocations are needed, the
relocatee should never be mapped to the CPU, and so the kernel shouldn't
need to wait for any fences to pass.
If drmMinor >= 6, the intel DDX driver will enable vblank events on both
pipes. If drmMinor >= 10 on pre-965 chipsets, the intel DDX driver will
swap the pipe<->plane mapping to allow for framebuffer compression on
laptop screens. This means the secondary vblank counter (corresponding
to pipe B) will be incremented when vblank interrupts occur.
Now Mesa waits for vblank events on whichever plane has a greater
portion of the displayed window. So it will happly ask to wait for the
primary counter even though that one won't increment.
So we can fix this in either the DDX driver, Mesa or the kernel (though
I thought we already had several times).
Since current (and previous) userspace assumes it's talking about a pipe
== plane situation and now uses planes when talking to the kernel, we
should probably just hide the mapping details there (indeed they already
are hidden there for vblank swaps), which this patch does.
So as far as userland is concerned, whether we call things planes or
pipes is irrelevant, as long as kernel developers understand that
userland hands them planes and they have to figure out which pipe that
corresponds to (which will typically be the same on 965+ hardware and
reversed on pre-965 mobile chips).
This header file is shared across linux and bsd, but is not installed
for user space to access. It's the place to put prototypes and data
types that aren't platform or chipset specific, but still internal to
the drm.
This patch is originally from malc0_, but since it used some NV40_*
regs, I edited them into hex values with a comment.
This seems to correspond quite well with my own mmio-trace,
for the parts I cared to check.
This code relied on the CPU and GPU address for the aperture being the same,
On some r5xx hardware I was playing with I noticed that this isn't always true.
I wonder if this will fix some of those r4xx DRI issues we've seen in the past.
This mapping allows cached objects to be mapped in/out of the TT space
with the appropriate flushing calls.
It should put back the old CACHED functionality for snooped mappings
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_irq.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/mga_drv.h
shared-core/mga_irq.c
shared-core/radeon_drv.h
shared-core/radeon_irq.c
Merge in the latest master bits and update the remaining drivers (except
mach64 which math_b is working on). Also remove the 9xx hack from the i915
driver; it seems to be correct.
Add suspend/resume support to the i915 driver. Moves some of the
initialization into the driver load routine, and fixes up places where we
assumed no dev_private existed in some of the cleanup paths. This allows
us to suspend/resume properly even if X isn't running.
Implement a version check IOCTL for drivers that don't use
drmMMInit from user-space.
Remove the minor check from the kernel code. That's really up
to the driver.
Bump major.
Remove need for lock for now.
May create races when we clean memory areas or on takedown.
Needs to be fixed.
Really do a validate on buffer creation in order to avoid problems with
fixed memory buffers.
We now always create a drm_ref_object for user objects and this is then the only
things that holds a reference to the user object. This way unreference on will
destroy the user object when the last drm_ref_object goes way.
The buffer object type is still tracked internally, but it is no longer
part of the user space visible ioctl interface. If the bo create ioctl
specifies a non-NULL buffer address we assume drm_bo_type_user,
otherwise drm_bo_type_dc. Kernel side allocations call
drm_buffer_object_create() directly and can still specify drm_bo_type_kernel.
Not 100% this makes sense either, but with this patch, the buffer type
is no longer exported and we can clean up the internals later on.
This adds the initial i915 superioctl interface. The interface should be
sufficent even if the implementation may needs fixes/optimisations internally
in the drm wrt caching etc.
All nv30 functions in nv30_graph.c that can be used on nv20 are renamed
as accordingly. nv20 specific parts from nv20_graph.c are moved into
nv30_graph.c.
Dave Airlie
Márton Németh
Keith Packard
Li Zefan
Jesper Juhl
Patrice Mandin
José Fonseca
Jesse Barnes
Kristian Høgsberg
Robert Noland
Robert Noland
Maarten Maathuis
Jiri Slaby
Dave Airlie
Dave Airlie
Eric Anholt
Robert Noland
Stephane Marchesin
Kristian Høgsberg
Ben Skeggs
Zhenyu Wang
Pekka Paalanen
Jeremy Kolb
Jesse Barnes
Jesse Barnes
Ian Romanick
Thomas Hellstrom
Dave Airlie
Stuart Bennett
Arthur Huillet
Matthieu Castet
chaohong guo