Exposes the following sysfs entries:
- fan0_input: read the rotational speed of the fan (poll a bit during 250ms)
- pwm0: set the pwm duty cycle
- pwm0_min/max: set the minimum/maximum pwm value
v2 (Ben Skeggs):
- nv50 pwm controller code removed in favour of other more complete code
- FAN_RPM -> FAN_SENSE
- merged FAN_SENSE readout into common code, not at all nv50-specific
- protected fanspeed changes with perflvl_wr
- formatting tidying
- added some comments where things are shaky
v3 (Martin Peres)
- ensure duty min/max from thermal table are sane
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Merge in the upstream tree to bring in the mainline fixes.
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_fbdev.c
drivers/gpu/drm/nouveau/nouveau_sgdma.c
ttm_backend will only exist with a ttm_tt, and ttm_tt
will only be of interest when bound to a backend. Merge them
to avoid code and data duplication.
V2 Rebase on top of memory accounting overhaul
V3 Rebase on top of more memory accounting changes
V4 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
V5 make sure ttm is unbound before destroying, change commit
message on suggestion from Tormod Volden
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Will need to be able to distinguish 2.0/2.1 from 3.0 soon. Also, move
the vbios parsing to nouveau_dp where it belongs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not used currently, but it will be used in preference to pre-determined
lane/bandwidth numbers at a later point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
I'm sure that out there somewhere, someone will need this. We currently
haven't seen an example of LVDS being on a non-0 SOR so far though.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NV30: Create framework for memtm
NV50: Improve reg creation,
NV50: Use P.version instead of card codename/stepping,
NVC0: Initial memtiming code for Fermi,
Renamed regs for consistency,
Overall redesign to improve readability,
Avoid kfree on null-pointer
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
This is probably better than having to tell the common code about all the
clocks that exist on every chipset.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It may not be necessary to fail in certain cases (such as failing to idle)
on module unload, whereas on suspend it's important to ensure a consistent
state can be restored on resume.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Many (all?) of the coefficients related to calculating the
correct temperature are signed integers
This patch correcly parses and stores those values
It also ensures that the default offset is 0 (previously 1)
Affected cards - the original nv50 and the nv40 family
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit "drm/nouveau: add some debug output if nouveau_mm busy at destroy time"
revealed an issue where vram mm takedown would actually fail due to there
still being nodes present, causing nouveau to leak a small amount of memory
on module unload.
This splits TTM/nouveau_mm a bit more cleanly and ensures nouveau_mm fini
isn't done until all gpuobjs are also destroyed.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Greatly simplifies a number of things, particularly once per-client GPU
address spaces are involved.
May add this back later once I know what things'll look like.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Was previously assuming a page size of 4KiB unless a VMA was present to
override it. Eventually, a buffer won't necessarily have a VMA at all at
some stages of its life, so we need to store this info elsewhere.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Abuses existing gpuobj_new() chan argument for this, which in turn forces
all NVOBJ_FLAG_VM allocations to be done from the global heap, not
suballocated from the channel's private heap. Not a problem though in
practise.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Userspace hasn't passed us a channel_hint for a long long time now, and
there isn't actually a need to do so anymore anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The ability to use NVIDIA's fuc has been retained *temporarily* in order
to better debug any issues that may be lingering in our initial attempt
at writing this ucode. Once I'm fairly confident we're okay, it'll be
removed.
There's a number of things not implemented by this fuc currently, but
most of it is sets of state that our context setup would not have used
anyway. No doubt we'll find out what they're for at some point, and
implement it if required.
This has been tested on 0xc0/0xc4 thus far, and from what I could tell
it worked as well as NVIDIA's. It's also been tested on 0xc1, but even
with NVIDIA's fuc that chipset doesn't work correctly with nouveau yet.
0xc3/0xc8/0xce should in theory be supported too, but I don't have the
hardware to check that.
There's no doubt numerous bugs to squash yet, please report any!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need the physical VRAM address in vinst, even for objects mapped into
a vm, as the gpuobj suspend/resume code uses PMEM to access the object.
Previously, vinst was overloaded to mean "VRAM address" for !VM objects,
and "VM address" for VM objects, causing the wrong data to be accessed
during suspend/resume.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Until we know these should work properly, would much rather default to
noaccel than risk giving people corruption/hangs out of the box..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The core/mem/shader clocks don't support the fractional feedback divider,
causing our calculated clocks to be off by quite a lot in some cases. To
solve this we will switch to a search-based algorithm when fN is NULL.
For my NVA8 at PL3, this actually generates identical cooefficients to
the binary driver. Hopefully that's a good sign, and that does not
break VPLL calculation for someone..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2 (Ben Skeggs): fix ramcfg strap, and remove bogus handling of perf 0x40
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In the very least VPE (PMPEG and friends) also has this style of tile
region regs, lets make them just work if/when they get added.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This needs a massive cleanup, but to catch bugs from the interface changes
vs the engine code cleanup, this will be done later.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's lots of more-or-less independant engines present on NVIDIA GPUs
these days, and we generally want to perform the same operations on them.
Implementing new ones requires hooking into lots of different places,
the aim of this work is to make this simpler and cleaner.
NV84:NV98 PCRYPT moved over as a test.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Improves the parsing of the memory timing table on NV50-NV98revA1 chipsets.
Added stepping to drm_nouveau_private to make sure newer NV98 (105M) is
zero rather than incorrect.
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch fixes messages such as
ERROR: space required after that ','
ERROR: spaces required around that '='
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Fix 'ERROR: code indent should use tabs where possible'
Fix 'ERROR: space required before the open parenthesis ('
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Fixes a possible lock ordering reversal between context_switch_lock
and ramin_lock.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
* 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next:
drm/nvc0: improve vm flush function
drm/nv50-nvc0: remove some code that doesn't belong here
drm/nv50: use "nv86" tlb flush method on everything except 0x50/0xac
drm/nouveau: quirk for XFX GT-240X-YA
drm/nv50-nvc0: work around an evo channel hang that some people see
drm/nouveau: implement init table opcode 0x5c
drm/nouveau: fix oops on unload with disabled LVDS panel
nv30: Fix parsing of perf table
drm/nouveau: correct memtiming table parsing for nv4x
It has been reported that this greatly improves (and possibly fixes
completely) the stability of NVA3+ chipsets. In traces of my NVA8,
NVIDIA now appear to be doing this too.
The most recent traces of 0x50 and 0xac I could find don't show NVIDIA
checking PGRAPH status on these flushes, so for now, we won't either.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We may eventually end up with per-connector backlights, especially with
ddcci devices. Make sure that the parent node for the backlight device is
the connector rather than the PCI device.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Sedat Dilek <sedat.dilek@googlemail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit changed an internal radeon structure, that meant a new driver
in -next had to be fixed up, merge in the commit and fix up the driver.
Also fixes a trivial nouveau merge.
Conflicts:
drivers/gpu/drm/nouveau/nouveau_mem.c
The nv30/nv40 3d driver is about to start using DMA_FENCE from the 3D
object which, it turns out, doesn't like its DMA object to not be
aligned to a 4KiB boundary.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The immediate benefit of doing this is that on NV50 and up, the GPU
virtual address of any buffer is now constant, regardless of what
memtype they're placed in.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Upcoming patches are going to enable full support for buffers that keep
a constant GPU virtual address whenever they're validated for use by
the GPU.
In order for this to work properly while keeping support for large pages,
we need to know if it's ever going to be possible for a buffer to end
up in GART, and if so, disable large pages for the buffer's VMA.
This is a new restriction that's not present in earlier kernel's, but
should not break userspace as the current code never attempts to validate
buffers into a memtype other than it was created with.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
'mappable' isn't really used at all, nor is it necessary anymore as the
bo code is capable of moving buffers to mappable vram as required.
'no_vm' isn't necessary anymore either, any places that don't want to be
mapped into a GPU address space should allocate the VRAM directly instead.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to be able to have the bh run while possibly spinning waiting for
the EVO notifier to signal. This apparently happens in some circumstances
with preempt disabled, so our workqueue was never being run.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
With cmwq, there's no reason for nouveau to use a dedicated workqueue.
Drop dev_priv->wq and use system_wq instead. Each work item is sync
flushed when the containing structure is unregistered/destroyed.
Note that this change also makes sure that nv50_gpio_handler is not
freed while the contained work item is still running.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In preparation for the addition of a new nv40 backend, we'll need to be
able to distinguish between a paged dma object and the on-chip GART.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6:
drm/nvc0/grctx: correct an off-by-one
drm/nv50: Fix race with PFIFO during PGRAPH context destruction.
drm/nouveau: Workaround incorrect DCB entry on a GeForce3 Ti 200.
drm/nvc0: implement irq handler for whatever's at 0x14xxxx
drm/nvc0: fix incorrect TPC register setup
drm/nouveau: probe for adt7473 before f75375
drm/nouveau: remove dead function definition
* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next:
drm/nouveau: fix gpu page faults triggered by plymouthd
drm/nouveau: greatly simplify mm, killing some bugs in the process
drm/nvc0: enable protection of system-use-only structures in vm
drm/nv40: initialise 0x17xx on all chipsets that have it
drm/nv40: make detection of 0x4097-ful chipsets available everywhere
* 'nouveau/drm-nouveau-next' of ../drm-nouveau-next:
drm/nouveau: fix hwmon device binding
drm/nouveau: create grctx on the fly on all chipsets
drm/nvc0: fix init without firmware present
drm/nvc0/pgraph: fix 0x406028/0x405870 init
drm/nvc0/pgraph: more unit names
drm/nvc0/pfifo: support for chipsets with only one PSUBFIFO (0xc1)
drm/nvc0: reserve only subc 0 for kernel use
drm/nv50: sync up gr data error names with rnn, use for nvc0 also
drm/nvc0: parse a couple more PGRAPH_INTR
drm/nvc0: nuke left-over debug messages
drm/nvc0: kill off a couple more magics
drm/nouveau: Validate channel indices passed from userspace.
drm/nouveau: Only select ACPI_VIDEO if its dependencies are met
We need to track the state of the switch in drivers, so that after s/r
we don't resume the card we've explicitly switched off before. Also
don't allow a userspace open to occur if we've switched the gpu off.
Signed-off-by: Dave Airlie <airlied@redhat.com>
NVC0 will be able to share some of nv50's paths this way. This also makes
it the card-specific vram code responsible for deciding if a given set
of tile_flags is valid, rather than duplicating the allowed types in
nv50_vram.c and nouveau_gem.c
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
As of this commit, it's guaranteed that if an object is in VRAM that its
GPU virtual address will be constant.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is required on nv50 as we need to be able to have more precise control
over physical VRAM allocations to avoid buffer corruption when using
buffers of mixed memory types.
This removes some nasty overallocation/alignment that we were previously
using to "control" this problem.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There have been reports of PFIFO cache errors during context take down
(fdo bug 31637). They are caused by some GPU objects being taken out
while the channel is still potentially processing commands. Make sure
that all the previous rendering has landed before releasing a GPU
object.
Reported-by: Grzesiek Sójka <pld@pfu.pl>
Reported-by: Patrice Mandin <patmandin@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Allows callers to install their own handlers for when a GPIO line
changes state (such as for hotplug detect).
This also fixes a bug where we weren't acknowledging the GPIO IRQ
until after the bottom half had run, causing a severe IRQ storm
in some cases.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The point is to share more code between the PFB/PGRAPH tile region
hooks, and give the hardware specific functions a chance to allocate
per-region resources.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_bo_move_m2mf() needs to lock the kernel channel, and it may be
called from the pushbuf IOCTL with an user channel already locked. Use
a separate subclass for the kernel channel mutex because this is
legitimate mutex nesting.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In a multihead setup vblank interrupts may end up enabled in both
heads. In that case we want to ignore the vblank interrupts coming
from the wrong CRTC to avoid tearing and unbalanced calls to
drm_vblank_get/put (fdo bug 31074).
Reported-by: Felix Leimbach <felix.leimbach@gmx.net>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nv0x-nv4x should be mostly fine, nv50 doesn't work yet.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_fence_* functions are not type safe, which could lead to bugs.
Additionally every use of nouveau_fence_unref had to cast struct
nouveau_fence to void **.
Fix it by renaming old functions and creating static inline functions with
new prototypes. We still need old functions, because we pass function
pointers to ttm.
As we are wrapping functions, drop unused "void *arg" parameter where possible.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Only supported on NV50+ so far, and disabled by default currently. The
module parameter "msi=1" will enable it.
There's a kernel bug which will cause this to fail if the module (or the
NVIDIA binary driver) has ever been loaded before loading nouveau with
MSI enabled. As such, this is only safe to enable if you have nouveau
load on boot, and don't wish to ever reload it.
The workaround is to "echo 0 > /sys/bus/pci/devices/<device>/enable"
until the enable count reads 0. Then you should be able to load nouveau
with MSI enabled.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We previously added all the available classes for the entire generation,
even though the objects wouldn't work on the hardware.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The structs themselves, as well as the non-sw object creation function are
probably very misnamed now. That's a problem for later :)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau_channel_ref() takes a "weak" channel reference that doesn't
prevent the hardware channel resources from being released, it just
keeps the channel data structure alive.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The destroy_context() engine hooks call gpuobj management functions to
release the channel resources, these functions use HARDIRQ-unsafe locks
whereas destroy_context() is called with the HARDIRQ-safe
context_switch_lock held, that's a lock ordering violation.
Push the engine-specific channel destruction logic into destroy_context()
and let the hardware-specific code lock and unlock when it's actually
needed. Change the engine destruction order to avoid a race in the small
gap between pgraph and pfifo context uninitialization.
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
No other driver uses this, and userspace should be responsible for handling
locking between them if they share BOs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ben Skeggs