The kernel message "[ PTHERM][0000:01:00.0] Thermal management: disabled"
is misleading as it actually means "fan management: disabled".
This patch fixes both the source and the message to improve readability.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In nouveau_therm_sensor_event, temperature is stored as an uint8_t
even though the original interface returns an int.
This change should make it more obvious when the sensor is either
very-ill-calibrated or when we selected the wrong sensor style
on the nv40 family.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Based on my experience, 10ms wasn't always enough. Let's bump that
to a little more.
If this turns out to be insufficient-enough again, then an approach
based on letting the sensor settle for several seconds before starting
polling on the temperature would be better suited. This way, boot time
wouldn't be impacted by those waits too much.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The condition to select between the old and new style was a thinko
as rnndb orders chipsets based on their release date (or general
chronologie hw-wise) and not based on their chipset number.
As the nv40 family is a mess when it comes to numbers, this patch
introduces a switch-based selection between the old and new style.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This reverts commit 0d71068835.
Not only that the commit introduces a bogus check (voltage_tries == 5
will never meet at the inserted code path), it brings the i915 driver
into an endless dp-train loop on HP Z1 desktop machine with IVY+eDP.
At least reverting this commit recovers the framebuffer (but X is
still broken by other reasons...)
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Once we thought we got semaphores working, we disabled kicking the ring
if hangcheck fired whilst waiting upon a ring as it was doing more harm
than good:
commit 4e0e90dcb8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Dec 14 13:56:58 2011 +0100
drm/i915: kicking rings stuck on semaphores considered harmful
However, life is never that easy and semaphores are still causing
problems whereby the value written by one ring (bcs) is not being
propagated to the waiter (rcs). Thus the waiter never wakes up and we
declare the GPU hung, which often has unfortunate consequences, even if
we successfully reset the GPU.
But the GPU is idle as it has completed the work, just didn't notify its
clients. So we can detect the incomplete wait during hang check and
probe the target ring to see if has indeed emitted the breadcrumb seqno
following the work and then and only then kick the waiter.
Based on a suggestion by Ben Widawsky.
v2: cross-check wait with iphdr. fix signaller calculation.
References: https://bugs.freedesktop.org/show_bug.cgi?id=54226
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To avoid this:
[ 256.798060] [drm] capturing error event; look for more information
in/sys/kernel/debug/dri/0/i915_error_state
Ben Widawsky identified that this regression has been introduced in
commit 2f86f19165
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Mon Jan 28 15:32:15 2013 -0800
drm/i915: Error state should print /sys/kernel/debug
...
[danvet: split up long line.] <----- he did it
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Pimp commit message with the regression note. Also, order
more brown paper bags, I've run out.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because the register does not exist on LPT. The interesting fact is
that reading/writing PCH_LVDS on LPT does *not* give us "unclaimed
register" messages, but the register value is always 0.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now it returns false for all platforms unless they're explicitly
listed on the function. There should be no real difference, except for
the fact that it now returns false on Haswell.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're starting to add many IS_HASWELL checks for the power well code,
so add a HAS_POWER_WELL macro to properly document that we're checking
for hardware that has the power down well.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Resolve conflicts since some converted code was added by
not-yet merged patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't read it when we hang the GPU. This solves "unclaimed
register" messages.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Future-proof by adding a gen >= 7 check in addition to the
!IS_HSW check from Paulo's original patch, suggested by Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't read it when capturing the error state. This solves some
"unclaimed register" messages on Haswell when we hang the GPU.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This solves some "unclaimed register" messages when there's a GPU hang
on Haswell.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add missing IS_VLV check as spotted by Ville Syrjälä.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our mode set sequence documentation says audio must be disabled first.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict since the first patch in this series isn't
applied yet. Also bikeshed commit message as suggested by Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
psb_intel_crtc_gamma_set() and psb_intel_crtc_destroy() aren't used outside of
psb_intel_display.c right now so no need to expose them.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
This makes it easier to read. We do the same for cdv so it becomes more
consistent as well.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
i9xx_clock() and i8xx_clock() did the same calc and psb_intel_clock() just
called i9xx_clock() so just move it all into psb_intel_clock().
The same calculation is duplicated in cdv_intel_display.c as well so maybe we
can share it later on.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Remove old comment and allow benchmarking moves within the
same memory domain for both dma and blit methods.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Replaced calls kzalloc followed by memcpy with call to kmemdup.
Patch found using coccinelle.
Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
commit f9f23a77f07506a32d9dc1d925bf85c0e7507b66(gma500: remove no_fb bits)
remove all the drm_psb_no_fb relations code in gma500 except this line code,
so remove it also.
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.
CVE-2013-0913
v3: collapse test, improve comment
v2: move check into validate_exec_list
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Pinkie Pie
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Masks kernel address info-leak in object dumps with the %pK suffix,
so they cannot be used to target kernel memory corruption attacks if
the kptr_restrict sysctl is set.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This clarifies the comment above the access_ok check so a missing
VERIFY_READ doesn't alarm anyone.
v2:
- rewrote comment, thanks to Chris Wilson
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: add patch history log to commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This replaces the manual read/write routines in debugfs with the common
simple attribute helpers. Doing this gets rid of repeated copy/pasting
of copy_from_user and value formatting code.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Squash in follow-up fix from Kees Cook to fix u64 divides on
32bit platforms.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both videomode and display_timing contain flags describing the modes.
These are stored in dmt_flags and data_flags. There's no need to
separate these flags, and having separate fields just makes the flags
more difficult to use.
This patch combines the fields and renames VESA_DMT_* flags to
DISPLAY_FLAGS_*.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:
* Videomode helper functions are not something that should be shown in
the kernel configuration options. The related code should just be
included if it's needed, i.e. selected by drivers using videomode.
* There's no need to have separate Kconfig options for videomode and
display_timing. First of all, the amount of code for both is quite
small. Second, videomode depends on display_timing, and display_timing
in itself is not really useful, so both would be included in any case.
* CONFIG_VIDEOMODE is a bit vague name, and CONFIG_VIDEOMODE_HELPERS
describes better what's included.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Regression fixes and oops fixes for nouveau.
* 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nv50: use correct tiling methods for m2mf buffer moves
drm/nouveau: idle channel before releasing notify object
drm/nouveau: fix regression in vblanking
drm/nv50: encoder creation failure doesn't mean full init failure
Unmapping it while it's still in use (e.g. by M2MF) can lead to page faults
and a lot of TRAP_M2MF spam in dmesg.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nv50_vblank_enable/disable got switched from NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is wrong.
4 << head is the correct value.
Fixes regression with vblanking since 1d7c71a3e2 "drm/nouveau/disp: port vblank handling to event interface"
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit ac24c2204a ("drm/tegra: Use generic
HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA
Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select
statement for that symbol is a nop. Drop it.
What was needed to use HDMI functionality was to select HDMI (which this
entry already did through depending on DRM) and to include linux/hdmi.h
(which this commit also did).
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Renesas boards were consistently defaulting to the 1024x768 resolution,
regardless of the native resolution of the monitor plugged in. It was
determined that the EDID of the monitor was not being read. Since the
DAC is a shared line, in order to read from or write to it we must take
control of the DAC clock. This can be done by setting the proper
register to one.
This bug fix sets the register MGA1064_GEN_IO_CTL2 to one. The DAC
control line can be used to determine whether or not a new monitor has
been plugged in. But since the hotplug feature is not one we will
support, it has been decided to simply leave the register set to one.
Signed-off-by: Julia Lemire <jlemire@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
A monitor or a user could request a resolution greater than the
available VRAM for the backing framebuffer. This change checks the
required framebuffer size against the max VRAM size and rejects modes
if they are too big. This change can also remove a mode request passed
in via the video= parameter.
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
