| Age | Commit message (Collapse) | Author |
|---|
|
dude kernel moduless use kernel errors :)
this fixes an oops on init when this codepath hits.
|
|
|
|
- Note that this may not work for all nv86.
|
|
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. :-)
|
|
The wait functions depend on PTIMER, so write the old (incorrect, but working) values for uninitialised hw
|
|
Kernel bug 10289.
|
|
|
|
|
|
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.
|
|
Limit frag address to 8 bits
|
|
|
|
|
|
This needs to be tested thoroughly before pushing to the
kernel.
|
|
This updated microcode is not in use yet.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
The docs state bits 4-11 represent bits 32-39 of a 40-bit address
|
|
|
|
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.
|
|
|
|
Also, power cycle PGRAPH when resetting AGP -- it seems to fix problems encountered by p0g on nv25
|
|
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.
|
|
Not only was this entirely pointless, it actually causes my NV30GL to
die randomly when channels are destroyed.
|
|
this adds something to say the kernel initialised the memory region not
the userspace. and blocks userspace from deallocating kernel areas
|
|
taken from modesetting branch but could be useful outside it.
|
|
Rip out the whole head thing and replace it with an idr and drm_minor
structure.
|
|
writting relocations, otherwise the GPU probably sees some
inconsistent data. Fix fd.o bug#14656
|
|
|
|
|
|
to leap it's vblank count a huge value.
This will stall some applications that switch video mode if vblank_mode is set to a non zero value in drirc.
|
|
|
|
|
|
|
|
|
|
|
|
In particular -EAGAINs, which should be common during Xserver operation.
Also handle the fence creation failure case.
|
|
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.
|
|
|
|
|
