This is a HUGE commit, but it's not nearly as bad as it looks - any problems
can be isolated to a particular chipset and engine combination. It was
simply too difficult to port each one at a time, the compat layers are
*already* ridiculous.
Most of the changes here are simply to the glue, the process for each of the
engine modules was to start with a standard skeleton and copy+paste the old
code into the appropriate places, fixing up variable names etc as needed.
v2: Marcin Slusarz <marcin.slusarz@gmail.com>
- fix find/replace bug in license header
v3: Ben Skeggs <bskeggs@redhat.com>
- bump indirect pushbuf size to 8KiB, 4KiB barely enough for userspace and
left no space for kernel's requirements during GEM pushbuf submission.
- fix duplicate assignments noticed by clang
v4: Marcin Slusarz <marcin.slusarz@gmail.com>
- add sparse annotations to nv04_fifo_pause/nv04_fifo_start
- use ioread32_native/iowrite32_native for fifo control registers
v5: Ben Skeggs <bskeggs@redhat.com>
- rebase on v3.6-rc4, modified to keep copy engine fix intact
- nv10/fence: unmap fence bo before destroying
- fixed fermi regression when using nvidia gr fuc
- fixed typo in supported dma_mask checking
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2: Ben Skeggs <bskeggs@redhat.com>
- de-inline nv_icmd, triggers some gcc issue causing ctxnv[ce]0.c to
take a *very* *very* long time to build on some configs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is all very much a policy thing, and hence will not belong in SW
after the rework.
engsw now only handles receiving the event to say "can flip now" and makes
a callback to perform the actual work.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's a *lot* of code in here, and it's all going to use the PGRAPH priv
pointer rather than drm_device after the engine rework. This is handling
all the rename-only parts of the change.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Still the same code, but not an "engine" anymore. The fence code is more of
a policy decision rather than exposing mechanisms, so it's not appropriate
to port it to the new engine subsystem.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Having GPUOBJ and VM intertwined like this makes it *really* hard to
continue porting to the new driver architecture, split it out in
favour of requiring explit maps be the caller.
It's more flexible and obvious this way anyway...
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Still missing the main bits we use to change performance levels, I'll get
to it after all the hard yakka has been finished.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2/v3: Ben Skeggs <bskeggs@redhat.com>
- fix typo in default bus selection
- fix accidental loss of destructor
v4: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
- fix typo causing incorrect default i2c port settings when no BMP data
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2: Ben Skeggs <bskeggs@redhat.com>
- rebase on top of v3.6-rc6 with gpio reset patch integrated already
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Adds an extra layer of indirection to each register access, but it's not
too bad, and will also go away as pieces are ported.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
These currently just call the existing ones in nouveau_drv.c, but will be
extended in upcoming commits. This needed to be separated from the current
code as there will be some header clashes until things are ported.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This commit provides most of the infrastructure to support a major overhaul
of Nouveau's internals coming in the following commits. This work aims to
take all the things we've learned over the last several years, and turn that
into a cleaner architecture that's more maintainable going forward.
RAMHT and MM bits of the new core have been left out for the moment, and
will be pulled in as I go through the process of porting the code to
become either subdev or engine modules.
There are several main goals I wanted to achieve through this work:
-- Reduce complexity
The goal here was to make each component of the driver as independent as
possible, which will ease maintainability and readability, and provide a
good base for resetting locked up GPU units in the future.
-- Better tracking of GPU units that are required at any given time
This is for future PM work, we'll be able to tell exactly what parts of the
GPU we need powered at any given point (etc).
-- Expose all available NVIDIA GPUs to the client
In order to support things such as multi-GPU channels, we want to be able
to expose all the NVIDIA GPUs to the client over a single file descriptor
so it can send a single push buffer to multiple GPUs.
-- Untangle the core hardware support code from the DRM implementation
This happened initially as an unexpected side-effect of developing the
initial core infrastructure in userspace, but it turned into a goal of
the whole project. Initial benefits will be the availablility of a
number of userspace tools and tests using the same code as the driver
itself, but will also be important as I look into some virtualisation
ideas.
v2: Ben Skeggs <bskeggs@redhat.com>
- fix duplicate assignments noticed by clang
- implement some forgotten yelling in error path
- ensure 64-bit engine mask is used everywhere
v3: Marcin Slusarz <marcin.slusarz@gmail.com>
- sparse fixes
- inline nv_printk into nv_assert to prevent recursive inlining issues
v4: Ben Skeggs <bskeggs@redhat.com>
- fixed minor memory leak on gpuobj destruction
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Future work will be headed in the way of separating the policy supplied by
the nouveau drm module from the mechanisms provided by the driver core.
There will be a couple of major classes (subdev, engine) of driver modules
that have clearly defined tasks, and the further directory structure change
is to reflect this.
No code changes here whatsoever, aside from fixing up a couple of include
file pathnames.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Won't necessarily be a drm_mm_node in the future, and I can't think of any
good reason to not use the offset from the bo struct. There may have been
some reason once apon a time, but, separate commit just in case.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes some unfortunate races on resume. The G84 version of the code doesn't
need this as "gpuobj"s are automagically suspended/resumed by the core code
whereas pinned buffer objects are not.
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Another spurious dmesg quitening.
* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN
PFIFO_INTR = 0x40000000 appears to be a normal case on nvc0/nve0 PFIFO,
the binary driver appears to completely ignore it in its PFIFO interrupt
handler and even masks off the bit (as we do) in PFIFO_INTR_EN at init
time.
The bits still light up in the hardware sometimes though, so lets just
ignore any bits we haven't explicitely requested.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Otherwise when X starts we commonly get a black screen scanning
out nothing, its wierd dpms on/off from userspace brings it back,
With this on F18, multi-seat works again with my 1920x1200 monitor
which is above the sku limit for the device I have.
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher <alexander.deucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't allocate enough data for this struct. As soon as we start
modifying event->event on the next lines, then we're going beyond the
end of the memory we allocated.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@gmail.com>
NVIDIA do that at startup too on Fermi, so perhaps the heap of 0x10
intrs we receive are normal and we can ignore them.
On Kepler NVIDIA *don't* do this, but the hardware appears to come up
with the bit masked off by default - so that's probably why :)
This should silence some interrupt spam seen on Fermi+ boards.
Backported patch from reworked nouveau kernel tree.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Daniel writes:
Essentially just flush my -fixes queue before I head off to xdc.
- gen2 regression fixer, we've enabled the lvds stuff too late. Not
causing any known issues, but this restores the sequence before a
refactor that landed in 3.5, and lvds is a fickle beast. And seriously,
who runs gen2 still ...
- downgrade a BUG to a WARN - we haven't root-caused/fixed the underlying
issue yet, but this should help bug reporters quite a bit.
- properly disable hdmi audio - we've lost track of this, which resulted
in the alsa driver again losing track of the unplug event.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
drm/i915: Reduce a pin-leak BUG into a WARN
drm/i915: enable lvds pin pairs before dpll on gen2
This fixes the gpio reset problem so the Retina MBP works, but avoids
breaking the Dell systems. Ben will work on a better solution for 3.7.
Tested by me on retina MBP.
Signed-off-by: Dave Airlie <airlied@redhat.com>
fixes a resume regression on pre-r6xx asics.
* 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: Prevent leak of scratch register on resume from suspend
Cards typically have 5-7 scratch registers; one of these is reserved for
rdev->rptr_save_reg. Unfortunately the reservation is done in function
r100_cp_init, which is called by all drivers except r600 - and this
function is also invoked on resume from suspend. After several resumes,
no scratch registers are free and graphics acceleration is disabled.
Dmesg then reports either:
*ERROR* radeon: cp failed to get scratch reg (-22).
*ERROR* radeon: cp isn't working(-22).
radeon 0000:01:00.0: failed initializing CP (-22).
or:
*ERROR* radeon: failed to get scratch reg (-22).
*ERROR* radeon: failed testing IB on GFX ring (-22).
*ERROR* ib ring test failed (-22).
The chain of calls on boot for all except r600 is:
radeon_init -> ... -> (rXXX_init) -> rXXX_startup -> r100_cp_init
The chain of calls on resume for all except r600 is:
rXXX_resume -> rXXX_startup -> r100_cp_init.
R600 correctly allocates rptr_save_reg in r600_init (ie once only, not
in resume). However moving the code into the init functions for all
drivers means touching 4 drivers. So instead, this patch just adds a
test in r100_cp_init to avoid reallocating on resume. As the rdev
structure is allocated via kzalloc in radeon_driver_load_kms, and zero
is not a valid registerid, zero safely implies not-yet-allocated.
This issue appears to have been introduced in c7eff978 (3.6.0-rcN)
Signed-off-by: Simon Kitching <skitching@vonos.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
