Probably missing something here, doesn't make a lot of sense to write
or+link data into a register whose offset is calculated by the same
or+link info..
This is the all I've witnessed the binary driver and vbios doing so
far, so it'll do.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The binary driver has been doing this since GF119, and we've somehow
gotten away with it. But, TMDS that hasn't been initialised already
by the x86 vbios code is distorted without it on GM204.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Logging at trace level, rather than as en error, as it seems conceivable
that failure could be normal under certain circumstances (new bios,
older sink that doesn't support a particular DPCD address)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Starting from GM204, certain registers are no longer accessible by the host
(or unsigned PMU firmware).
This commit implements devinit on PMU, using a signed microcode image, and
devinit data, from the VBIOS.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The field at +0x2 is technically processor specific, though I don't know
that it's ever mattered in practice (yet).
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We're about to need to be able to fetch additional chunks of data beyond
the primary bios image, which makes fetching a lot more complicated.
This splits out the verious shadowing routines to be nothing more than
very dumb "fetch this much data from this offset" routines, and leaves
the logic of what and how much to fetch in common code.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Just a couple of fixes for the fallout from the fence rework.
* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/gf116: remove copy1 engine
drm/nouveau: prevent stale fence->channel pointers, and protect with rcu
drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it
Indications are that no GF116's actually have a copy engine there, but
actually have the decompression engine. This engine can be made to do
copies, but that should be done separately.
Unclear why this didn't turn up on all GF116's, but perhaps the
non-mobile ones came with enough VRAM to not trigger ttm migrations in
test scenarios.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85465
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59168
Cc: stable@vger.kernel.org
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Closes a very unlikely race that can occur if another NonStallInterrupt
method passes between checking fences and acking the previous interrupt.
With this change, the interrupt will re-fire under such conditions.
Tested-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.
This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.
v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So with all the code movement and extraction in intel_pm.c in -next
git is hopelessly confused with
commit 2208d655a9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Nov 14 09:25:29 2014 +0100
drm/i915: drop WaSetupGtModeTdRowDispatch:snb
from -fixes. Worse even small changes in -next move around the
conflict context so rerere is equally useless. Let's just backmerge
and be done with it.
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/intel_pm.c
Except for git getting lost no tricky conflicts really.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The Baseline_ELD_Len field does not include ELD Header Block size.
From High Definition Audio Specification, Revision 1.0a:
The header block is a fixed size of 4 bytes. The baseline block
is variable size in multiple of 4 bytes, and its size is defined
in the header block Baseline_ELD_Len field (in number of
DWords).
Do not include the header size in Baseline_ELD_Len field. Fix all known
users of eld[2].
While at it, switch to DIV_ROUND_UP instead of open coding it.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
[danvet: Fix compile fail in nouveau.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
One modesetting, one gk20a fix.
* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/nv50/disp: Fix modeset on G94
drm/gk20a/fb: fix setting of large page size bit
Commit 1dce626404 introduced a regression
spotted on several G94 (FDObz #85160). This device seems to expect the
vblank period to be set after setting scale instead of before.
V2: shove this in a separate function
This is a candidate bug-fix for 3.18
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Zlatko Calusic <zcalusic@bitsync.net>
Tested-by: Michael Riesch <michael@riesch.at>
Tested-by: "poma" <pomidorabelisima@gmail.com>
Tested-by: Adam Williamson <adamw@happyassassin.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit "ltc/gf100-: fix cbc issues on certain boards" moved the setting
of the large page size bit from bar/nvc0 to fb/nvc0. GK20A uses its own
FB device and the change was thus not applied to it - fix this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Just a bit of OCD cleanup on headers - this function isn't the core
interface any more but just a helper for drivers who haven't yet
transitioned to universal planes. Put the declaration at the right
spot and sprinkle necessary #includes over all drivers.
Maybe this helps to encourage driver maintainers to do the switch.
v2: Fix #include ordering for tegra, reported by 0-day builder.
v3: Include required headers, reported by Thierry.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
two nouveau fixes.
* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: fix regression on agp boards
drm/gt215/gr: fix initialisation on gddr5 boards
Extends the fix in f2f9a2cbaf to also
workaround permission issues noticed by people using AGP systems.
Cc: stable@vger.kernel.org # 3.16: f2f9a2c: drm/nouveau: fix regression
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The binary driver modifies the default context to have this value, rather
than 0x3d0040, *after* it's filled the buffer with the usual golden data.
We don't really have anything in place to locate the correct offset to do
these type of modifications outside of the generation function, so this
will have to do.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Pull drm updates from Dave Airlie:
"This is the main git pull for the drm,
I pretty much froze major pulls at -rc5/6 time, and haven't had much
fallout, so will probably continue doing that.
Lots of changes all over, big internal header cleanup to make it clear
drm features are legacy things and what are things that modern KMS
drivers should be using. Also big move to use the new generic fences
in all the TTM drivers.
core:
atomic prep work,
vblank rework changes, allows immediate vblank disables
major header reworking and cleanups to better delinate legacy
interfaces from what KMS drivers should be using.
cursor planes locking fixes
ttm:
move to generic fences (affects all TTM drivers)
ppc64 caching fixes
radeon:
userptr support,
uvd for old asics,
reset rework for fence changes
better buffer placement changes,
dpm feature enablement
hdmi audio support fixes
intel:
Cherryview work,
180 degree rotation,
skylake prep work,
execlist command submission
full ppgtt prep work
cursor improvements
edid caching,
vdd handling improvements
nouveau:
fence reworking
kepler memory clock work
gt21x clock work
fan control improvements
hdmi infoframe fixes
DP audio
ast:
ppc64 fixes
caching fix
rcar:
rcar-du DT support
ipuv3:
prep work for capture support
msm:
LVDS support for mdp4, new panel, gpu refactoring
exynos:
exynos3250 SoC support, drop bad mmap interface,
mipi dsi changes, and component match support"
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (640 commits)
drm/mst: rework payload table allocation to conform better.
drm/ast: Fix HW cursor image
drm/radeon/kv: add uvd/vce info to dpm debugfs output
drm/radeon/ci: add uvd/vce info to dpm debugfs output
drm/radeon: export reservation_object from dmabuf to ttm
drm/radeon: cope with foreign fences inside the reservation object
drm/radeon: cope with foreign fences inside display
drm/core: use helper to check driver features
drm/radeon/cik: write gfx ucode version to ucode addr reg
drm/radeon/si: print full CS when we hit a packet 0
drm/radeon: remove unecessary includes
drm/radeon/combios: declare legacy_connector_convert as static
drm/radeon/atombios: declare connector convert tables as static
drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table
drm/radeon/dpm: drop clk/voltage dependency filters for BTC
drm/radeon/dpm: drop clk/voltage dependency filters for CI
drm/radeon/dpm: drop clk/voltage dependency filters for SI
drm/radeon/dpm: drop clk/voltage dependency filters for NI
drm/radeon: disable audio when we disable hdmi (v2)
drm/radeon: split audio enable between eg and r600 (v2)
...
Pull vfs updates from Al Viro:
"The big thing in this pile is Eric's unmount-on-rmdir series; we
finally have everything we need for that. The final piece of prereqs
is delayed mntput() - now filesystem shutdown always happens on
shallow stack.
Other than that, we have several new primitives for iov_iter (Matt
Wilcox, culled from his XIP-related series) pushing the conversion to
->read_iter()/ ->write_iter() a bit more, a bunch of fs/dcache.c
cleanups and fixes (including the external name refcounting, which
gives consistent behaviour of d_move() wrt procfs symlinks for long
and short names alike) and assorted cleanups and fixes all over the
place.
This is just the first pile; there's a lot of stuff from various
people that ought to go in this window. Starting with
unionmount/overlayfs mess... ;-/"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (60 commits)
fs/file_table.c: Update alloc_file() comment
vfs: Deduplicate code shared by xattr system calls operating on paths
reiserfs: remove pointless forward declaration of struct nameidata
don't need that forward declaration of struct nameidata in dcache.h anymore
take dname_external() into fs/dcache.c
let path_init() failures treated the same way as subsequent link_path_walk()
fix misuses of f_count() in ppp and netlink
ncpfs: use list_for_each_entry() for d_subdirs walk
vfs: move getname() from callers to do_mount()
gfs2_atomic_open(): skip lookups on hashed dentry
[infiniband] remove pointless assignments
gadgetfs: saner API for gadgetfs_create_file()
f_fs: saner API for ffs_sb_create_file()
jfs: don't hash direct inode
[s390] remove pointless assignment of ->f_op in vmlogrdr ->open()
ecryptfs: ->f_op is never NULL
android: ->f_op is never NULL
nouveau: __iomem misannotations
missing annotation in fs/file.c
fs: namespace: suppress 'may be used uninitialized' warnings
...
Linus commit 05c63c2ff2 modified the
runtime suspend/resume paths to skip over display-related tasks to
avoid locking issues on resume.
Unfortunately, this resulted in the display hardware being left in
a partially initialised state, preventing subsequent modesets from
completing.
This commit unifies the (many) suspend/resume paths, bringing back
display (and fbcon) handling in the runtime paths.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Preparation for some runtime pm fixes. Currently we skip over fbcon
suspend/resume in the runtime path, which causes issues on resume if
fbcon tries to write to the framebuffer before the BAR subdev has
been resumed to restore the BAR1 VM setup.
As we might be woken up via a sysfs connector, we are unable to call
fb_set_suspend() in the resume path as it could make its way down to
a modeset and cause all sorts of locking hilarity.
To solve this, we'll just delay the fbcon resume to a workqueue.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Xorg (and any non-DRM client really) doesn't have permission to directly
touch VRAM on nv50 and up, which the fence code prior to g84 depends on.
It's less invasive to temporarily grant it premission to do so, as it
previously did, than it is to rework fencenv50 to use the VM. That
will come later on.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
fixups for nouveau and fencing
* 'for-airlied-next' of git://people.freedesktop.org/~mlankhorst/linux:
drm/nouveau: export reservation_object from dmabuf to ttm
drm/ttm: add reservation_object as argument to ttm_bo_init
drm: Pass dma-buf as argument to gem_prime_import_sg_table
drm/nouveau: assign fence_chan->name correctly
drm/nouveau: specify if interruptible wait is desired in nouveau_fence_sync
drm/nouveau: bump driver patchlevel to 1.2.1
Ok, here's the update core-stuff pull request with the locking fixup patch
fixed up with another patch.
* tag 'topic/core-stuff-2014-09-29' of git://anongit.freedesktop.org/drm-intel:
drm: Drop grab fpriv->fbs_lock in drm_fb_release
drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper
drm/ast: use container_of to resolve ast_fbdev from drm_fb_helper
drm/gma500: use container_of to resolve psb_fbdev from drm_fb_helper
drm/qxl: use container_of to resolve qxl_fbdev from drm_fb_helper
drm/nouveau: use container_of to resolve nouveau_plane from drm_plane
drm/nouveau: use container_of to resolve nouveau_fbdev from drm_fb_helper
drm/radeon: use container_of to resolve radeon_fbdev from drm_fb_helper
drm/mgag200: use container_of to resolve mga_fbdev from drm_fb_helper
drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helper
drm: Improve debug output for drm_wait_one_vblank
drm: Fixup locking for universal cursor planes
drm: Don't update vblank timestamp when the counter didn't change
Make nouveau_fence_chan refcounted, to make trace_fence_destroy
always return the correct name without a race condition.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
This fixes a regression introduced by "drm/nouveau: rework to new fence interface"
(commit 29ba89b237).
The fence sequence should not be reset after creation, the old value is used instead.
On destruction the final value is written, to prevent another source of accidental
wraparound in case of a channel being destroyed after a hang, and unblocking any other
channel that may wait on the about-to-be-deleted channel to signal.
I'm nothing if not optimistic about any hope of recovery from that. ;-)
Reported-by: Ted Percival <ted@tedp.id.au>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Ted Percival <ted@tedp.id.au>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use container_of instead of casting first structure member.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use container_of instead of casting first structure member.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Don't forget git add, noticed by David.
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Really, the legacy buffer api should be dead, especially for all these
newfangled drivers. I suspect this is copypasta from the transitioning
days, which probably originated in radeon.
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rashika <rashika.kheria@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Fabian Frederick <fabf@skynet.be>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull drm fixes from Dave Airlie:
"A bunch of radeon fixes for oops on module unload, and problems with
resetting the dma engine, one nouveau fix for black boxes in rendering
on my mbp retina, one sti fix, and a couple of intel fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/nouveau: ltc/gf100-: fix cbc issues on certain boards
drm/bochs: add missing drm_connector_register call
drm/cirrus: add missing drm_connector_register call
drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page
drm/nouveau/runpm: fix module unload
drm/radeon/px: fix module unload
vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops
drm/radeon: don't reset dma on r6xx-evergreen init
drm/radeon: don't reset sdma on CIK init
drm/radeon: don't reset dma on NI/SI init
drm/radeon/dpm: fix resume on mullins
drm/radeon: Disable HDP flush before every CS again for < r600
drm/radeon: delete unused PTE_* defines
drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv
drm: sti: do not iterate over the info frame array
drm/i915: Fix SRC_COPY width on 830/845g
A mismatch between FB and LTC's idea of how big a large page is causes
issues such as black "holes" in rendering to occur on some boards
(those where LTC is configured for 64KiB large pages) when compression
is used.
Confirmed to fix at least the GK107 MBP.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Enumeration
- Don't default exclusively to first video device (Bruno Prémont)
PCI device hotplug
- Remove "no hotplug settings from platform" warning (Bjorn Helgaas)
- Add pci_ignore_hotplug() for VGA switcheroo (Bjorn Helgaas)
Freescale i.MX6
- Put LTSSM in "Detect" state before disabling (Lucas Stach)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUG7o9AAoJEFmIoMA60/r8hbYP/3gR3xHd2QKpkmBcM1lf1yiR
osQQnAfRqEO4fzrpmOYrYbLIAOPwanK6Y36rmIYB+wHU2SUaffV7ZI9uW32shTud
09+1N+OrSS6fwzVUWOuKsf1kv/jxpS+ic2fb+Qe1OXwJh5G+z1D9Kvd2EPLJdlgK
ySyX4zSTrLni8CoclzREO7u82VVO5rTdvbujBxuvpOQTOdD5TFqV/uhb/y3gQz+u
sG6IxUbdXsy4r24C6OnPrmmZ1Rk/lgCMyA+QSozc5Eu5PdGzcY9a6gcKlTnsbwBs
qYLAb+/KCa3KgQh07NYmFfYdpoMZUXgSsEtD8gyvfJQHwUYwW8rsEMKxlSCQrzYr
0OrpBSVTO6ta1r8SKOWtSYETQgPE3GUiJR1DuCyV+55RLZYp6Q8zH6dbgfWQbA/g
R/kWHihR/tcD9YIlT99QrBppZtvG5nZ3y7aLSqdYYxEJqHE0tlbuxAu8hgwDf3Qp
lKZJMyadLB1MS9lnrMj8DYqIOKbe62LOwcEYzhMJzaq8vCy+JWtjxOOgwBkT7P5v
bhhYh3eqi5/MBONtw52V6RDUQId9vOLGHoiM5/akG4FFmWdhO9S0SbMBhAJyazKT
n3IP5yj657XAi/fK939PUCQ3YuT5GqlCNcXDCqUzBZhGnt/Ln7LPmQI323519Lp4
3vI3irFT0Fu2IFEBhc6l
=xIYe
-----END PGP SIGNATURE-----
Merge tag 'pci-v3.17-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
"These fix:
- Boot video device detection on dual-GPU Apple systems
- Hotplug fiascos on VGA switcheroo with radeon & nouveau drivers
- Boot hang on Freescale i.MX6 systems
- Excessive "no hotplug settings from platform" warnings
In particular:
Enumeration
- Don't default exclusively to first video device (Bruno Prémont)
PCI device hotplug
- Remove "no hotplug settings from platform" warning (Bjorn Helgaas)
- Add pci_ignore_hotplug() for VGA switcheroo (Bjorn Helgaas)
Freescale i.MX6
- Put LTSSM in "Detect" state before disabling (Lucas Stach)"
* tag 'pci-v3.17-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
vgaarb: Drop obsolete #ifndef
vgaarb: Don't default exclusively to first video device with mem+io
ACPIPHP / radeon / nouveau: Remove acpi_bus_no_hotplug()
PCI: Remove "no hotplug settings from platform" warning
PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device
PCI: imx6: Put LTSSM in "Detect" state before disabling it
MAINTAINERS: Add Lucas Stach as co-maintainer for i.MX6 PCI driver
Use the new vga_switcheroo_fini_domain_pm_ops function
to unregister the pm ops.
Based on a patch from:
Pali Rohár <pali.rohar@gmail.com>
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=84431
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: Ben Skeggs <bskeggs@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUFjfVAAoJEHm+PkMAQRiGANkIAIU3PNrAz9dIItq8a/rEAhnx
l2shHoOyEmyNR2apholM3BPUNX50cbsc/HGdi7lZKLkA/ifAj6B9nFD2NzVsIChD
1QWVcvdkKlVuxXCDd26qbijlfmbTOAWrLw9ntvM+J6ZtECM6zCAZF4MAV/FwogPq
ETGKD76AxJtVIhBMS99troAiC1YxmQ7DKgEr8CraTOR1qwXEonnPCmN/IZA6x2/G
EXiihOuQB5me1X7k4PI0V8CDscQOn+3B2CQHIrjRB+KiTF+iKIuI8n6ORC6bpFh+
U8UZP9wLlIG1BrUHG83pIndglIHotqPcjmtfl1WGrRr2hn7abzVSfV+g5Syo3Vg=
=Ep+s
-----END PGP SIGNATURE-----
drm: backmerge tag 'v3.17-rc5' into drm-next
This is requested to get the fixes for intel and radeon into the
same tree for future development work.
i915_display.c: fix missing dev_priv conflict.
Revert parts of f244d8b623 ("ACPIPHP / radeon / nouveau: Fix VGA
switcheroo problem related to hotplug").
A previous commit 5493b31f0b55 ("PCI: Add pci_ignore_hotplug() to ignore
hotplug events for a device") added equivalent functionality implemented in
a different way for both acpiphp and pciehp.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Rajat Jain <rajatxjain@gmail.com>
NVIDIA appear to have tweaked the algorithm from GF110, this implements
the previous algorithm for them still.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Solves blinking on reclocking memory. The value set is an underestimate, but
with non-reduced vblanking this should give us plenty of time
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
More accurate as to the function of the opcodes. Not only is FB disabled,
but the host is prevented from touching the GPU. An upcoming patch for
Kepler will also halt PFIFO (as NVIDIA does).
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nv92 hardware has only 16 interrupt lines, while nv94 and later
has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect
PDISP setup. This is a regression introduced with
commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon May 12 15:22:42 2014 +1000
gpio: split g92 class from nv50
Reported-by: estece on #nouveau
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
*when* this is done is only a rough approximation of what the binary driver
does.. need to investigate more to see if it matters
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Awful, awful. But, on the GK106 I have, some upcoming patches show
that this is actually necessary after all.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
All the other chipsets should be moved over to this too. It's not needed
yet for the upcoming commits, so left this step as it'll conflict badly
with Roy's GT21x reclocking work.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NVIDIA binary driver appears to, not sure if it's for a good reason, but
grasping at straws for some GDDR5 reclocking issues here.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Time measured from disabling FB to re-enabling, PPWR_IN reveals status of
heads at the end of script. Helps debug various issues (like flicker).
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Needs to be done after wait-for-VBLANK, and NVA3 requires register writes
in between.
Rather than hard-coding register writes, just split out fb_disable and
fb_enable.
v2. Squashed "fb/ramnve0: disable fb before reclocking"
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
One of my nv92 has a calibrated internal sensor but it displays 0°C
as the default values use sw calibration values to force the temperature
to 0.
Since we cannot read the temperature from the adt7473 present on this board,
let's re-enable the internal reading!
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We will use this subdev to disable temperature reading on cards that did not
get a sensor calibration in the factory.
v2:
- rename "nouveau_fuse_rd32" to "gxXXX_fuse_rd32" as adviced by Christian Costa
- fold the code a little as adviced by Emil Velikov
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It can help to remove any ambiguity about which options were passed to Nouveau,
especially in case the user had some options set in /etc/modprobe.d/*.conf that
he forgot about, as they won't appear in a dmesg.
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The problem with the current implementation is that adding a timer improperly
checked which process would time up first by not taking into account how much
time elapsed since their timer got scheduled. Rework the re-scheduling
decision t fix this.
The catch with this fix is that we are limited to scheduling timers of up to
2^31 ticks to avoid any potential overflow. Since we are unlikely to need to
wait for more than a second, this won't be a problem :)
Another possible fix would be to decrement the timeouts of all processes but
it would duplicate a lot of code and dealing with edge cases wasn't pretty
last time I checked.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
For some reason, it is now required to wait a 20 µs after the 0x200 reset of
the engine.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2: change the copyright ownership from "Nouveau Community" to myself, as per
Illia's recommendation.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Re-use the therm-exported fan structure with only two minor modifications:
- pwm_freq: u16 -> u32;
- add fan_type (toggle or PWM)
v2:
- Do not memset the table to 0 as it erases the pre-set default values
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The allocation algorithm doesn't expect there to be holes in the mm, which
causes its alignment/cutoff calculations to choke (and go negative) when
encountering the last chunk of a block before a hole.
The least expensive solution is to simply fill in any holes with nodes
that are pre-marked as being allocated.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is really the wrong thing to do, but at the time it was our only
option to prevent worse issues.
We no longer cause quite so much anger from LTC, so it's not needed.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Dave asked me to do the backmerge before sending him the revised pull
request, so here we go. Nothing fancy in the conflicts, just a few
things changed right next to each another.
Conflicts:
drivers/gpu/drm/drm_irq.c
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
I've read INVBL as "invalid backlight" and got mightly confused.
The #defines are already fairly long and we can afford to extend
them a bit more without resulting in ugly code all over.
I'm not sure how useful the complicated bitmask return value of these
functions really are since no one checks them. But for now let's keep
things as is.
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold),
normally generates a hot-remove event that unbinds the driver.
Some drivers expect to remain bound to a device even while they power it
off and back on again. This can be dangerous, because if the device is
removed or replaced while it is powered off, the driver doesn't know that
anything changed. But some drivers accept that risk.
Add pci_ignore_hotplug() for use by drivers that know their device cannot
be removed. Using pci_ignore_hotplug() tells the PCI core that hot-plug
events for the device should be ignored.
The radeon and nouveau drivers use this to switch between a low-power,
integrated GPU and a higher-power, higher-performance discrete GPU. They
power off the unused GPU, but they want to remain bound to it.
This is a reimplementation of f244d8b623 ("ACPIPHP / radeon / nouveau:
Fix VGA switcheroo problem related to hotplug") but extends it to work with
both acpiphp and pciehp.
This fixes a problem where systems with dual GPUs using the radeon drivers
become unusable, freezing every few seconds (see bugzillas below). The
resume of the radeon device may also fail, e.g.,
This fixes problems on dual GPU systems where the radeon driver becomes
unusable because of problems while suspending the device, as in bug 79701:
[drm] radeon: finishing device.
radeon 0000:01:00.0: Userspace still has active objects !
radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free
...
WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]()
trying to unbind memory from uninitialized GART !
or while resuming it, as in bug 77261:
radeon 0000:01:00.0: ring 0 stalled for more than 10158msec
radeon 0000:01:00.0: GPU lockup ...
radeon 0000:01:00.0: GPU pci config reset
pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1)
radeon 0000:01:00.0: GPU reset succeeded, trying to resume
*ERROR* radeon: dpm resume failed
radeon 0000:01:00.0: Wait for MC idle timedout !
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701
Reported-by: Shawn Starr <shawn.starr@rogers.com>
Reported-by: Jose P. <lbdkmjdf@sharklasers.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Rajat Jain <rajatxjain@gmail.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
CC: stable@vger.kernel.org # v3.15+
One step closer to dropping all the drm_bus_* code:
Add a driver->set_busid() callback and make all drivers use the generic
helpers. Nouveau is the only driver that uses two different bus-types with
the same drm_driver. This is totally broken if both buses are available on
the same machine (unlikely, but lets be safe). Therefore, we create two
different drivers for each platform during module_init() and set the
set_busid() callback respectively.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes not being able to init fence subsystem when multiple boards are
present.
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nouveau keeps track in userspace whether a buffer is being
written to or being read, but it doesn't use that information.
Change this to allow multiple readers on the same bo.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Maintain the original order to handle VRAM/GART/mixed correctly for <nv50,
it's likely not as important on newer cards.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
With the conversion to the reservation api this should be safe.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
This will ensure we always hold the required lock when calling those functions.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.
After the switch to rcu the reservation lock will be
removed again.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
This allows us to more fine grained specify where to place the buffer object.
v2: rebased on drm-next, add bochs changes as well
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
A couple of thinkos from the -next merge, some random fixes from a
coverity scan, fix for (at least) GK106 accidentally using
non-existent vram on some board configurations, and better behaviour
of the instmem allocations if vmalloc space runs out.
* 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/platform: fix compilation error
drm/nouveau/gk20a: add LTC device
drm/nouveau: warn if we fail to re-pin fb on resume
drm/nouveau/nvif: fix dac load detect method definition
drm/gf100-/gr: fix -ENOSPC detection when allocating zbc table entries
drm/nouveau/nvif: return null pointers on failure, in addition to ret != 0
drm/nouveau/ltc: fix tag base address getting truncated if above 4GiB
drm/nvc0-/fb/ram: fix use of non-existant ram if partitions aren't uniform
drm/nouveau/bar: behave better if ioremap failed
drm/nouveau/kms: nouveau_fbcon_accel_fini can be static
drm/nouveau: kill unused variable warning if !__OS_HAS_AGP
drm/nouveau/nvif: fix a number of notify thinkos
nouveau_platform.c was still using the old nouveau_dev() macro,
triggering a compilation error. Fix this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
LTC device is now required for PGRAPH to work, add it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reported by Coverity. The intention is that the return value is
checked, but let's be more paranoid and make it extremely obvious
if something forgets to.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Pull nouveau drm updates from Ben Skeggs:
"Apologies for not getting this done in time for Dave's drm-next merge
window. As he mentioned, a pre-existing bug reared its head a lot
more obviously after this lot of changes. It took quite a bit of time
to track it down. In any case, Dave suggested I try my luck by
sending directly to you this time.
Overview:
- more code for Tegra GK20A from NVIDIA - probing, reclockig
- better fix for Kepler GPUs that have the graphics engine powered
off on startup, method courtesy of info provided by NVIDIA
- unhardcoding of a bunch of graphics engine setup on
Fermi/Kepler/Maxwell, will hopefully solve some issues people have
noticed on higher-end models
- support for "Zero Bandwidth Clear" on Fermi/Kepler/Maxwell, needs
userspace support in general, but some lucky apps will benefit
automagically
- reviewed/exposed the full object APIs to userspace (finally), gives
it access to perfctrs, ZBC controls, various events. More to come
in the future.
- various other fixes"
Acked-by: Dave Airlie <airlied@redhat.com>
* 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (87 commits)
drm/nouveau: expose the full object/event interfaces to userspace
drm/nouveau: fix headless mode
drm/nouveau: hide sysfs pstate file behind an option again
drm/nv50/disp: shhh compiler
drm/gf100-/gr: implement the proper SetShaderExceptions method
drm/gf100-/gr: remove some broken ltc bashing, for now
drm/gf100-/gr: unhardcode attribute cb config
drm/gf100-/gr: fetch tpcs-per-ppc info on startup
drm/gf100-/gr: unhardcode pagepool config
drm/gf100-/gr: unhardcode bundle cb config
drm/gf100-/gr: improve initial context patch list helpers
drm/gf100-/gr: add support for zero bandwidth clear
drm/nouveau/ltc: add zbc drivers
drm/nouveau/ltc: s/ltcg/ltc/ + cleanup
drm/nouveau: use ram info from nvif_device
drm/nouveau/disp: implement nvif event sources for vblank/connector notifiers
drm/nouveau/disp: allow user direct access to channel control registers
drm/nouveau/disp: audit and version display classes
drm/nouveau/disp: audit and version SCANOUTPOS method
drm/nv50-/disp: audit and version PIOR_PWR method
...
No-one has yet had time to move this to debugfs as discussed during
the last merge window. Until this happens, hide the option to make
it clear it's not going to be here forever.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We have another version of it implemented in SW, however, that version
isn't serialised with normal PGRAPH operation and can possibly clobber
the enables for another context.
This is the same method that's implemented by the NVIDIA binary driver.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
... and hope that the defaults are good enough. This was always
supposed to be a read/modify/write thing anyway, so we're writing
very wrong stuff for some boards already.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Should be the same values as before, except:
GF117 has smaller buffer allocated, as per register setup.
GK20A now uses values from Tegra driver, not GK104's.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Removes need for fixed buffer indices, and allows the functions
utilising them to also be run outside of context generation.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Default ZBC table is compatible with binary driver defaults.
Userspace will need to be updated to take full advantage of this
feature, however, some applications will see a performance boost
without updated drivers.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
One of the next commits will remove some of the class IDs, leaving only
the ones used by NVIDIA which, presumably, mark where functionality
changes actually happened.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The indirect method has been left in-place here as a fallback path, as
it may not be possible to map the non-PAGE_SIZE aligned control areas
across some chipset+interface combinations.
This isn't a problem for the primary use-case where the core and drm
are linked together in kernel-land, but across a VM or (in the case
where it applies now) between the core in the kernel and a userspace
test tool.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
