This is necessary for AGP to work after running bios init scripts on nv3x, and
is seen in mmio traces of all cards (nv04-nv4x)
I'm not making the equivalent change to nv40_mc.c, as early cards (6200, 6800gt)
use the 0x000018XX PBUS and later cards use the 0x000880XX PBUS and I don't know
the effects of using the wrong one
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.
I should not have renamed this field.
I should not have renamed this field.
I should not have renamed this field.
On the plus side, it was at least binary compatible.
Modify the TTM backend bind arguments.
Export a number of functions needed for driver-specific super-ioctls.
Add a function to map buffer objects from the kernel, regardless of where they're
currently placed.
A number of error fixes.
This branch replaces the NO_MOVE/NO_EVICT flags to buffer validation with a
separate privileged ioctl to pin buffers like NO_EVICT meant before. The
functionality that was supposed to be covered by NO_MOVE may be reintroduced
later, possibly in a different way, after the superioctl branch is merged.
We can figure out which pipe a given plane is mapped to by looking at the
display control registers instead of tracking it in a new SAREA private field.
If this becomes a performance problem, we could move to an ioctl based solution
by adding a new parameter for the DDX to set (defaulting to the old behavior if
the param was never set of course).
This mod makes the SAREA track plane to pipe mappings and corrects the name of
the plane info variables (they were mislabeled as pipe info since until now all
code assumed a direct mapping between planes and pipes).
It also updates the flip ioctl argument to take a set of planes rather than
pipes, since planes are flipped while pipes generate vblank events.
- add forgotten init value
- use the same PGRAPH_DEBUG than the blob
- remove init of ddx reg : it should be done with object
- better handle of channel destruction
hope I didn't break anything ;)
The DRM_XGI_PCIE_ALLOC and DRM_XGI_FB_ALLOC ioctls (and the matching
free ioctls) are unified to DRM_XGI_ALLOC. The desired memory region
is selected by xgi_mem_alloc::location. The region is magically
encoded in xgi_mem_alloc::index, which is used to release the memory.
Bump to version 0.11.0. This update requires a new DDX.
Need to find another way of doing this, ideally someone'd hunt down which
object/method controls it! The Xv blit adaptor is likely now broken on
cards that have pNv->WaitVSyncPossible enabled.
1. DRM_NOUVEAU_GPUOBJ_FREE
Used to free GPU objects. The obvious usage case is for Gr objects,
but notifiers can also be destroyed in the same way.
GPU objects gain a destructor method and private data fields with
this change, so other specialised cases (like notifiers) can be
implemented on top of gpuobjs.
2. DRM_NOUVEAU_CHANNEL_FREE
3. DRM_NOUVEAU_CARD_INIT
Ideally we'd do init during module load, but this isn't currently
possible. Doing init during firstopen() is bad as X has a love of
opening/closing the DRM many times during startup. Once the
modesetting-101 branch is merged this can go away.
IRQs are enabled in nouveau_card_init() now, rather than having the
X server call drmCtlInstHandler(). We'll need this for when we give
the kernel module its own channel.
4. DRM_NOUVEAU_GETPARAM
Add CHIPSET_ID value, which will return the chipset id derived
from NV_PMC_BOOT_0.
4. Use list_* in a few places, rather than home-brewed stuff.
The core DRM lastclose routine automatically destroys all mappings and
releases SG memory. XP10 DRM and DDX assumed this data stayed around
until module unload. xgi_bootstrap was reworked to recreate all these
mappings. In addition, the drm_addmap for the GART backing store was
moved into the kernel. This causes a change to the ioctl protocol and
a version bump.
There were numerous unnecessary fields in xgi_cmd_info. The remaining
fields had pretty crummy names. Cut out the cruft, and rename the
rest. As a result, the unused parameter "triggerCounter" to
triggerHWCommandList can be removed.
The data is now in kernel space, copied in/out as appropriate according to the
This results in DRM_COPY_{TO,FROM}_USER going away, and error paths to deal
with those failures. This also means that XFree86 4.2.0 support for i810 DRM
is lost.
As a fallout, replace filp storage with file_priv storage for "unique
identifier of a client" all over the DRM. There is a 1:1 mapping, so this
should be a noop. This could be a minor performance improvement, as everything
on Linux dereferenced filp to get file_priv anyway, while only the mmap ioctls
went the other direction.
This was used to make all ioctl handlers return -errno on linux and errno on
*BSD. Instead, just return -errno in shared code, and flip sign on return from
shared code to *BSD code.