| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/mga_irq.c
shared-core/radeon_irq.c
shared-core/via_irq.c
Mostly trivial conflicts.
mach64 support from Mathieu Bérard.
|
|
This reverts commit 2370ded79b4176d76cda1ec5f495fd33c2d566ed.
Err.. didn't mean for that to slip in :)
|
|
|
|
|
|
|
|
|
|
Kernel "cleanfile" script run.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
Ensure NV_PFIFO_DMA_TIMESLICE_TIMEOUT_ENABLE gets set, otherwise channels
will appear to "freeze" in some circumstances.
|
|
|
|
|
|
Fixes #11868
|
|
If your card doesn't have working context switching, it is now broken.
|
|
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 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 is not called from anywhere, yet.
|
|
Actually a NV04-NV50 ttm backend for both PCI and PCIEGART, but PCIGART
support for G8X using the current mm has been hacked on top of it.
|
|
|
|
|
|
|
|
Turns out lastclose() gets called even if firstopen() has never been...
|
|
Should be OK on G84 for a single channel, multiple channels *almost* work.
Untested on G80.
|
|
Allows multiple references to a single object, needed to support PCI(E)GART
scatter-gather DMA objects which would quickly fill PRAMIN if each channel
had its own.
Handle per-channel private instmem areas. This is needed to support NV50,
but might be something we want to do on earlier chipsets at some point?
Everything that touches PRAMIN is a GPU object.
|
|
|
|
|
|
|
|
For various reasons, this ioctl was a bad idea.
At channel creation we now automatically create DMA objects covering
available VRAM and GART memory, where the client used to do this themselves.
However, there is still a need to be able to create DMA objects pointing at
specific areas of memory (ie. notifiers). Each channel is now allocated a
small amount of memory from which a client can suballocate things (such as
notifiers), and have a DMA object created which covers the suballocated area.
The NOTIFIER_ALLOC ioctl exposes this functionality.
|
|
NV04/NV10 load_context()/save_context() are stubs. I don't know enough about
how they work to implement them sanely. The "old" context_switch() code
remains hooked up, so it shouldn't break anything.
NV20 will probably break if load_context() works. No inital context values
are filled in, so when the first channel is created PGRAPH will probably end
up having its state zeroed. Some setup from nv20_graph_init() will probably
need to be moved to the per-channel context setup.
|
|
|
|
Earlier NV1X chips use the NV04 code, see previous commits about NV10 RAMFC
entry size.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The PGRAPH init for the various cards will need cleaning up at some point,
a lot of the values written there are per-context state left over from the
all the hardcoding done in the ddx.
It's possible some cards get broken by this commit, let me know.
Tested on: NV5, NV18, NV28, NV35, NV40, NV4E
|
|
|
|
|
|
|
