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>
Here's the updated topic/core-stuff pull request with the two patches
already merged into drm-fixes dropped.
* tag 'topic/core-stuff-2014-09-15' of git://anongit.freedesktop.org/drm-intel:
drm: Drop modeset locking from crtc init function
drm/i915/hdmi: Enable pipe pixel replication for SD interlaced modes
drm/edid: Reduce horizontal timings for pixel replicated modes
drm: Include task->name and master status in debugfs clients info
drm/gem: Fix kerneldoc typo
drm: use c99 initializers in structures
drm: fix drm_modeset_lock.h kernel-doc notation
At driver init no one can access modeset objects and we're
single-threaded. So locking is just cargo-culting here. Worse, with
the new ww mutexes and ww mutex slowpath debugging the mutex_lock
might actually fail, and we don't have the full-blown ww recovery
dance.
Which then leads to fireworks when we try to unlock the not-locked
crtc lock.
An audit of all the functions called from here shows that none of them
contain locking checks, so there's also no reason to keep the locking
around just for consistency of caller contexts. Besides that I have
the rule (at least in i915) that such places where we take locks just
to simplify locking checks and not for correctness always require a
comment.
This regression was introduced in
commit 51fd371bba
Author: Rob Clark <robdclark@gmail.com>
Date: Tue Nov 19 12:10:12 2013 -0500
drm: convert crtc and connection_mutex to ww_mutex (v5)
v2: Don't drop the lock_init call, spotted by the 0day builder.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=83341
Cc: Rob Clark <robdclark@gmail.com>
Cc: thellstrom@vmware.com
Cc: maarten.lankhorst@canonical.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Enable 2x pixel replication for modes the mode flag DBLCLK to double
horizontal timings and pixel clock across TMDS.
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pixel replicated modes should be non-2x horizontal timings and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change will
allow HDMI certification with 480i/576i modes once pixel replication
is turned on.
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Showing who is the current master is useful for trying to decypher
errors when trying to acquire master (e.g. a race with X taking over
from plymouth). By including the process name as well as the pid
simplifies the task of grabbing enough information remotely at the point
of error.
v2: Add the command column header and flesh out a couple of comments.
(David Herrmann)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The drm_gem_private_object_init function is called drm_gem_object_init
in its kerneldoc. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the MMIO mangling to a separate routine and actually
disable the DVO output when using pure analog.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It looks like the AST2400 comes up with the DVO enable bit set,
which causes us to incorrectly assume we have a SIL164 regardless
of the value of the scratch registers setup by the BMC firmware.
So let's limit that test to the case where the chip has already
been setup by a BIOS.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the P2A has been used to target other SOC registers before that
call, we're going to hit the wrong place so make sure we set the
base address up properly before using it.
(P2A stands for PCIe to AHB bridge and is the bride that allows
accessing the AST's internal AHB bus using a relocatable 64k
window in the second half of the PCIe MMIO BAR)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to do it on machines without a BIOS such as POWER8. Also
for detection to work without triggering PCIe errors, we need
to enable VGA early on, inside ast_detect_chip().
While touching those files, replace a few hard coded register
numbers with the corresponding symbolic constant.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the PIO resources haven't been assigned, then we have no choice
but try to use the MMIO version. This is the case for example on
POWER8 which doesn't support PIO at all.
Chips rev 0x20 or later have MMIO decoding enabled by default.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull vfs fixes from Al Viro:
"double iput() on failure exit in lustre, racy removal of spliced
dentries from ->s_anon in __d_materialise_dentry() plus a bunch of
assorted RCU pathwalk fixes"
The RCU pathwalk fixes end up fixing a couple of cases where we
incorrectly dropped out of RCU walking, due to incorrect initialization
and testing of the sequence locks in some corner cases. Since dropping
out of RCU walk mode forces the slow locked accesses, those corner cases
slowed down quite dramatically.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
be careful with nd->inode in path_init() and follow_dotdot_rcu()
don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
fix bogus read_seqretry() checks introduced in b37199e
move the call of __d_drop(anon) into __d_materialise_unique(dentry, anon)
[fix] lustre: d_make_root() does iput() on dentry allocation failure
The performance regression that Josef Bacik reported in the pathname
lookup (see commit 99d263d4c5 "vfs: fix bad hashing of dentries") made
me look at performance stability of the dcache code, just to verify that
the problem was actually fixed. That turned up a few other problems in
this area.
There are a few cases where we exit RCU lookup mode and go to the slow
serializing case when we shouldn't, Al has fixed those and they'll come
in with the next VFS pull.
But my performance verification also shows that link_path_walk() turns
out to have a very unfortunate 32-bit store of the length and hash of
the name we look up, followed by a 64-bit read of the combined hash_len
field. That screws up the processor store to load forwarding, causing
an unnecessary hickup in this critical routine.
It's caused by the ugly calling convention for the "hash_name()"
function, and easily fixed by just making hash_name() fill in the whole
'struct qstr' rather than passing it a pointer to just the hash value.
With that, the profile for this function looks much smoother.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull parisc updates from Helge Deller:
"The most important patch is a new Light Weigth Syscall (LWS) for 8,
16, 32 and 64 bit atomic CAS operations which is required in order to
be able to implement the atomic gcc builtins on our platform.
Other than that, we wire up the seccomp, getrandom and memfd_create
syscalls, fixes a minor off-by-one bug and a wrong printk string"
* 'parisc-3.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Implement new LWS CAS supporting 64 bit operations.
parisc: Wire up seccomp, getrandom and memfd_create syscalls
parisc: dino: fix %d confusingly prefixed with 0x in format string
parisc: sys_hpux: NUL terminator is one past the end
in the former we simply check if dentry is still valid after picking
its ->d_inode; in the latter we fetch ->d_inode in the same places
where we fetch dentry and its ->d_seq, under the same checks.
Cc: stable@vger.kernel.org # 2.6.38+
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
return the value instead, and have path_init() do the assignment. Broken by
"vfs: Fix absolute RCU path walk failures due to uninitialized seq number",
which was Cc-stable with 2.6.38+ as destination. This one should go where
it went.
To avoid dummy value returned in case when root is already set (it would do
no harm, actually, since the only caller that doesn't ignore the return value
is guaranteed to have nd->root *not* set, but it's more obvious that way),
lift the check into callers. And do the same to set_root(), to keep them
in sync.
Cc: stable@vger.kernel.org # 2.6.38+
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
MAINTAINERS to reflect new e-mail address.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUFR7/AAoJEG5mS6x6i9Ij/84P/RniNXGFS4Kh+YuS5E6KdZ+C
6rzpxlUkeEWkL+1Oy8xpLSJdWsCYajOmteP2V3ubQNlqzd0H/zN5W52/i4tIhVc1
W7SXexh1tr18BeeiQZ0sX5IlBGzixJ9QDzsuf0cg5keX9RphVBNbm16d8DvW/Le3
fj2LXyN+K82vy0GPZE0awi9TWfgj1oZobsKswjBp6Kz/z4gq11/rKQBeBvJbxSF/
WttgvDWONHiuUyHuKYJq53KQ+B7Q6ANwtKfIvd2CpFb8dWlsYYMnr1eRmz4ZC5OM
NDj2T4Dn5VrxqivmFJ+6d4EZK1agZXYXly+mkW21N2sMqL2/fq7b6CgbKzy76PLz
sDc1e5WUTJu0AjfrtTQBKG/ZbxXxvpMsarO3rI3C2Oos9DUPnDG8eHsHeOSoZQXi
tyUyIu4IyH4x7BWO//srU7l82YXWrrGN8+YU+GcLsMGDfsOaR4DDURUu9iYNX3cA
RoGfhmb+H41X+zOnzgnioyGMcK6mwVvsPxIzZ4CwsSa64aWlud6vbxoJr+q6K2ap
KEGxT78gy32Jw9wsfYUJKQpa5By7FdpGUDFk/rTt4ZYVU8TR1e+ShCz2l7Ny5Ioh
u13/vZ/VGVG3+MFjZ5In02egYx3fPnbilbavGCNRQM31/GJxHSc5p8xnoPxLmg70
tVREVtRX23KREqt38CBf
=uhqP
-----END PGP SIGNATURE-----
Merge tag 'ntb-3.17' of git://github.com/jonmason/ntb
Pull ntb driver bugfixes from Jon Mason:
"NTB driver fixes for queue spread and buffer alignment. Also, update
to MAINTAINERS to reflect new e-mail address"
* tag 'ntb-3.17' of git://github.com/jonmason/ntb:
ntb: Add alignment check to meet hardware requirement
MAINTAINERS: update NTB info
NTB: correct the spread of queues over mw's
