| Age | Commit message (Collapse) | Author |
|---|
|
Add a comment explaining the parameters for this function
|
|
Just add documentation for this function, no code changes.
|
|
drmBOSetStatus does not bother to set the fence_class parameter.
Fortunately, drm_bo_setstatus_ioctl doesn't end up using it as it
calls drm_bo_handle_validate with use_old_fence_class = 1.
|
|
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.
|
|
Creating a ttm was done with drm_ttm_init while destruction was done with
drm_destroy_ttm. Renaming these to drm_ttm_create and drm_ttm_destroy makes
their use clearer. Passing page_flags to the create function will allow that
to know whether user or kernel pages are needed, with the goal of allowing
kernel ttms to be saved for later reuse.
|
|
This reverts commit 46235ea4595152d8dd5f016c18c6845a77db30b0.
|
|
modesetting-101
|
|
|
|
|
|
When writing a relocation entry, make sure the target buffer is idle,
otherwise the GPU may see inconsistent data.
|
|
|
|
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.
|
|
modesetting-101
Conflicts:
linux-core/drm_drv.c
shared-core/drm.h
shared-core/i915_dma.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 field isn't touched or read by any other code in the stack so it's
time to retire these last few references.
|
|
I'm going to pass back a list of blob ids and lengths in the getproperty.
will need another ioctl to return the blob data as it is variable length.
|
|
This also starts to add blob property support.
someone needs to check this work for other things like ppc/x86 alignment diffs
|
|
This fix is actually a bit of a cleanup too--it moves lock freeing to
drm_rmmap_locked and out of drm_lastclose. This makes it symmetrical with
addmap and also prevents the lock from being incorrectly freed from driver
mappings.
|
|
This should work on all radeon but there is still many things todo:
- add crtc2
- tmds
- lvds
- add bios data table so we don't need to hardcode dac/crtc infos
- separate clock control to make power saving easier & cleaner
- tiling (warning tiling shouldn't be enable in double scan or interlace)
- surface reg manager (this goes along with tiling)
- suspend/resume hook
- avivo & r500 family support
- atom bios support (for posting card mostly)
- finish superioctl skeleton
- what else ? :)
|
|
|
|
|
|
|
|
|
|
|
|
so really want to get a list of modes per output not the global hammer list.
also we remove the mode ids and let the user pass back the full mode description
need to fix up add/remove mode for user modes now
|
|
|
|
We needed to specifically check for driver support and test the correct
vbl_received value. Also pulled over support for _DRM_VBLANK_NEXTONMISS
from the linux code.
|
|
|
|
|
|
Calling semantics are the same and both were introduced in 5.0
|
|
|
|
|
