Names are just another unique integer set (from another idr object).
Names are removed when the user refernces (handles) are all destroyed --
this required that handles for objects be counted separately from
internal kernel references (so that we can tell when the handles are all
gone).
mixed 32/64 bit systems need 'special' help for ioctl where the user-space
and kernel-space datatypes differ. Fixing the datatypes to be the same size,
and align the same way for both 32 and 64-bit ppc and x86 environments will
elimiante the need to have magic 32/64-bit ioctl translation code.
This is possibly temporary. I can trigger an unending IRQ storm on G8x
in some circumstances, and have no idea how to handle that particular PFIFO
exception correctly yet.
I swore I'd actually do this properly and not go the horrible route
we did with nv4x, but I won't get around to it just yet with so many
*actually* interesting things to do first.. One day.
Since someone already added nv86, why not!
Enum can be of pretty much any size since C leaves the choice of size up to the implementation. So avoid using it in new interfaces like the vblank pre- & post-modeset ioctl. Thanks to hch for spotting this.
The batchbuffer submission paths were fixed to use the 965-specific command,
but the vblank tasklet was not. When the older version is sent, the 965 will
lock up.
This interface was defined completely wrong, however userspace has only
ever used 4 values from it (0x1, 0x2, 0x3 and 0x6), so fix the interface to do what userspace actually expected but define new defines for new users to use
it properly.
Previously, the R300_CMD_WAIT command would write the passed directly to the
hardware. However this is incorrect because the R300_WAIT_* values used are
internal interface values that do not map directly to the hardware.
The new function I have added translates the R300_WAIT_* values into appropriate
values for the hardware before writing the register.
Thanks to John Bridgman for pointing this out. :-)
More or less a workaround for issues on some chipsets where a context
switch results in critical data in PRAMIN being overwritten by the GPU.
The correct fix is known, but may take some time before it's a feasible
option.
This is the correct fix for the RS690 and hopefully the dma coherent work.
For now we limit everybody to a 32-bit DMA mask but it is possible for
RS690 to use a 40-bit DMA mask for the GART table itself,
and the PCIE cards can use 40-bits for the table entries.
Signed-off-by: Dave Airlie <airlied@redhat.com>
DMA command submission. It's worth remembering that all new bright ideas on how
to make this command reader work properly and according to docs
will probably fail :( Bring in some old code.
If we ever want to be able to use the 3D engine we have no choice. It
appears that the tiling setup (required for 3D on G8x) is in the page tables.
The immediate benefit of this change however is that it's now not possible
for a client to use the GPU to render over the top of important engine setup
tables, which also live in VRAM.
G8x VRAM size is limited to 512MiB at the moment, as we use a 1-1 mapping
of real vram pages to their offset within the start of a channel's VRAM
DMA object and only populate a single PDE for VRAM use.
Conflicts:
linux-core/drm_compat.c
linux-core/drm_compat.h
linux-core/drm_ttm.c
shared-core/i915_dma.c
Bump driver minor to 13 due to introduction of new
relocation type.
My 965GM gets interrupts stuck when using the old PIPE_VBLANK interrupt.
Switch to the PIPE_EVENT interrupt mechanism, and set the PIPE*STAT
registers to use START_VBLANK on 965 and VBLANK on previous chips.
Will hopefully work a bit better than previous code, which depended on
knowing the channel's most recent PUT value. Some chips always return
0 on reading these regs, and currently userspace is the only other entity
which knows the value.
Texture uploads could hit the blitter coordinate limit, adjust the texture
offset when uploading the pieces. Make sure to check the end address of the
upload too.
Make sure we have enough room for all the GR registers or we'll end up
clobbering the AR index register (which should actually be harmless
unless the BIOS is making an assumption about it).
Keith Packard
Dave Airlie
Eric Anholt
Ben Skeggs
Jesse Barnes
Maarten Maathuis
Jesse Barnes
Jesse Barnes
Xiang, Haihao
Dave Airlie
Oliver McFadden
Stuart Bennett
Alex Deucher
Alex Deucher
Thomas Hellstrom
Alex Deucher
Zou Nan hai
Roland Scheidegger
Kristian Høgsberg
Alan Hourihane
Stephane Marchesin
Jesse Barnes