| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
Thanks to Todd Merrill for pointing it out.
|
|
This matches the changes in mesa to use the system drm includes
for the definitions of the drm ioctl structs.
|
|
|
|
Failing to preserve the MI_ARB_STATE register was causing FIFO underruns on
the VGA output on my HP 2510p after resume.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
On resume, if the interrupt state isn't restored correctly, we may end
up with a flood of unexpected or ill-timed interrupts, which could cause
the kernel to disable the interrupt or vblank events to happen at the
wrong time. So save/restore them properly.
|
|
since a breadcrumb may actually turn up before a corresponding fence object
has been placed on the fence ring.
|
|
And make nv30_graph_init a bit more like mmio-traces
|
|
- Moved the fix from the ddx to drm, because it seemed more appropriate.
- Don't be shy, report if it works for you or not.
|
|
|
|
waiting types.
Add a "command_stream_barrier" method to the bo driver.
|
|
With some luck the drm-side will be OK now for this chipset.
|
