30 Apr, 2014
4 commits
-
Use %pad for dma_addr_t, because a dma_addr_t type can vary
based on build options. So, it prevents possible build warnings
in printks.Signed-off-by: Jingoo Han
Reviewed-by: Daniel Kurtz
Signed-off-by: Inki Dae
Signed-off-by: Dave Airlie -
devm_ioremap_resource() returns an error pointer, not NULL. Thus,
the result should be checked with IS_ERR().Signed-off-by: Jingoo Han
Signed-off-by: Inki Dae
Signed-off-by: Dave Airlie -
exynos_drm_crtc_mode_set assigns primary framebuffer to plane without
taking reference. Then during framebuffer removal it is dereferenced twice,
causing oops. The patch fixes it.Signed-off-by: Andrzej Hajda
Signed-off-by: Inki Dae
Signed-off-by: Dave Airlie -
single security fix, cc'd stable.
* 'vmwgfx-fixes-3.15' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2
28 Apr, 2014
3 commits
-
drm/tegra: Fixes for v3.15-rc3
A single fix for some framebuffer reference counting fallout caused by
the primary plane helpers introduced in 3.15-rc1.* tag 'drm/tegra/for-3.15-rc3' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: restrict plane loops to legacy planes -
Fixes for msm for 3.15.. a memory leak fix for devices using vram
carveout instead of iommu. Plus I think finally managed to sort out /
workaround some cursor vs underflow issues. And small fbcon tweak
needed to avoid extra full-modesets at boot.* 'msm-fixes-3.15-rc3' of git://people.freedesktop.org/~robclark/linux:
drm/msm/mdp4: cure for the cursor blues (v2)
drm/msm: default to XR24 rather than AR24
drm/msm: fix memory leak -
Fix regression with DVI and fix warns, and GM45 boot regression.
* tag 'drm-intel-fixes-2014-04-25' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Move all ring resets before setting the HWS page
drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms
drm/i915: Allow full PPGTT with param override
drm/i915: Discard BIOS framebuffers too small to accommodate chosen mode
drm/i915: get power domain in case the BIOS enabled eDP VDD
drm/i915: Don't check gmch state on inherited configs
drm/i915: Allow user modes to exceed DVI 165MHz limit
25 Apr, 2014
5 commits
-
In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
Author: Naresh Kumar Kachhi
Date: Wed Mar 12 16:39:40 2014 +0530drm/i915: disable rings before HW status page setup
we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.Reference: http://lkml.kernel.org/r/20140423202248.GA3621@amd.pavel.ucw.cz
Tested-by: Pavel Machek
Cc: Naresh Kumar Kachhi
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Signed-off-by: Daniel Vetter
Signed-off-by: Jani Nikula -
The status bits are unconditionally set, the control bits only enable
the actual interrupt generation. Which means if we get some random
other interrupts we'll bogusly complain about them.So restrict the WARN to platforms with a sane hotplug interrupt
handling scheme. And even more important also don't attempt to process
the hpd bit since we've detected a storm already. Instead just clear
the bit silently.This WARN has been introduced in
commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b
Author: Egbert Eich
Date: Fri Jul 26 14:14:24 2013 +0200drm/i915: Add messages useful for HPD storm detection debugging (v2)
before that we silently handled the hpd event and so partially
defeated the storm detection.v2: Pimp commit message (Jani)
Cc: Jani Nikula
Cc: Egbert Eich
Cc: bitlord
Reported-by: bitlord
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter
Signed-off-by: Jani Nikula -
The hw cursor is relatively adept at triggering underflows, which
manifest as a "blue flash" (since blue is configured as the underflow
color). Juggle a few things around to tighten up the timing for setting
cursor registers in DONE irq.And most importantly, don't ever disable the hw cursor. Instead flip it
to a blank/empty cursor. This seems far more reliable, as even simply
clearing the cursor-enable bit (with no other updates in previous/
following frames) can in some cases cause underflow.v1: original
v2: add missing locking spotted by MicahCc: Micah Richert
Signed-off-by: Rob Clark -
Since X11 is going to create an XR24 fb, if the pixel formats do not
match then crtc helpers will think it is a full modeset even if mode is
the same, which prevents smooth/flickerless handover from fbcon/plymouth
to X11.Signed-off-by: Rob Clark
-
Signed-off-by: Micah Richert
Signed-off-by: Rob Clark
24 Apr, 2014
4 commits
-
In Matt Ropers primary plane series a set of prep patches like
commit af2b653bfb4ef40931b4d101ca842ce0c5da57ef
Author: Matt Roper
Date: Tue Apr 1 15:22:32 2014 -0700drm/i915: Restrict plane loops to only operate on overlay planes (v2)
ensured that all exisiting users of the mode_config->plane_list
wouldn't change behaviour. Unfortunately tegra seems to have fallen
through the cracks. Fix it.This regression was introduced in
commit e13161af80c185ecd8dc4641d0f5df58f9e3e0af
Author: Matt Roper
Date: Tue Apr 1 15:22:38 2014 -0700drm: Add drm_crtc_init_with_planes() (v2)
The result was that we've unref'ed the fb for the primary plane twice,
leading to a use-after free bug. This is because the drm core will
already set crtc->primary->fb to NULL and do the unref for us, and the
crtc disable hook is called by the drm crtc helpers for exactly this
case.Aside: Now that the fbdev helpers clean up planes there's no longer a
need to do this in drivers. So this could probably be nuked entirely
in linux-next.Signed-off-by: Daniel Vetter
Reviewed-by: Matt Roper
Tested-by: Stephen Warren
Signed-off-by: Thierry Reding -
When PPGTT was disabled by default, the patch also prevented the user
from overriding this behavior via module parameter. Being able to test
this on arbitrary kernels is extremely beneficial to track down the
remaining bugs. The patch that prevented this was:commit 93a25a9e2d67765c3092bfaac9b855d95e39df97
Author: Daniel Vetter
Date: Thu Mar 6 09:40:43 2014 +0100drm/i915: Disable full ppgtt by default
By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
means full, all other values are reserved.Signed-off-by: Ben Widawsky
Signed-off-by: Daniel Vetter
Signed-off-by: Jani Nikula -
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.Regression from commit d978ef14456a38034f6c0e94a794129501f89200
Author: Jesse Barnes
Date: Fri Mar 7 08:57:51 2014 -0800drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12
v2: Add a debug message to track the discard of the BIOS fb.
v3: Ville pointed out the difference between ref/unrefReported-by: Knut Petersen
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77767
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
Reviewed-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula -
We already check that the buffer object we're accessing is registered with
the file. Now also make sure that we can't DMA across buffer object boundaries.v2: Code commenting update.
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
23 Apr, 2014
2 commits
-
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(), which trigger a WARN saying that the
refcount of the power domain is less than zero.The problem happens because the driver gets a refcount whenever it
enables the VDD bit, and puts the refcount whenever it disables the
VDD bit. But on this case, the BIOS enabled VDD, so all we do is to
call put() without calling get() first, so the code added is there to
make sure we always have the get() in case the BIOS enabled the bit.This regression was introduced in
commit e9cb81a22841908b1c075156b409a538d09c8466
Author: Paulo Zanoni
Date: Thu Nov 21 13:47:23 2013 -0200drm/i915: get a runtime PM reference when the panel VDD is on
v2: - Rebase
Tested-by: Chris Wilson (v1)
Reviewed-by: Daniel Vetter
Cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: Paulo Zanoni
Signed-off-by: Jani Nikula -
... our current modeset code isn't good enough yet to handle this. The
scenario is:1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.2. We read out that state for pipe B and assign the gmch_pfit state to
it.3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max
Cc: Alan Stern
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter
Signed-off-by: Jani Nikula
22 Apr, 2014
7 commits
-
vgaswitcheroo and the ATPX ACPI methods are required to
power down the dGPU.bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73901Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
Some newer PX laptops have the pci device class
set to DISPLAY_OTHER rather than DISPLAY_VGA. This
properly detects ATPX on those laptops.Based on a patch from: Pali Rohár
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Cc: airlied@gmail.com -
Avoids a crash in certain cases when thermal irqs are generated
before the display structures have been initialized.v2: fix the vblank and vrefresh helpers as well
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
Need to properly unregister the hwmon device on driver
unload.v2: minor clean up
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
Should be 5 rather than 4.
Noticed-by: Mathias Fröhlich
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Christian König -
In commit
commit 6375b768a9850b6154478993e5fb566fa4614a9c
Author: Ville Syrjälä
Date: Mon Mar 3 11:33:36 2014 +0200drm/i915: Reject >165MHz modes w/ DVI monitors
the driver started to filter out display modes which exceed the
single-link DVI 165Mz dotclock limits when the monitor doesn't report
itself as being HDMI compliant. The intent was to filter out all
EDID derived modes that require dual-link DVI to operate since we
don't support dual-link.However the patch went a bit too far and also causes the driver to reject
such modes even when specified by the user. Normally we don't check the
sink limitations when setting a mode from the user. This allows the user
to specify any mode whether the sink reports to support it or not. This
can be useful since often the sinks support more modes than they report
in the EDID.So relax the checks a bit, and apply the single-link DVI dotclock limit
only when filtering the mode list, and ignore the limit when setting
a user specified mode.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72961
Tested-by: Nicholas Vinson
Cc: stable@vger.kernel.org [3.14]
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
Signed-off-by: Jani Nikula -
The hpd (hot plug detect) pin assignment got lost
in the conversion to to the common i2c over aux
code. Without this information, aux transactions
do not work properly. Fixes DP failures.Signed-off-by: Alex Deucher
Signed-off-by: Christian König
20 Apr, 2014
2 commits
-
This improves the PLL parameters when we work at
the limits of the allowed ranges.Signed-off-by: Christian König
-
Signed-off-by: Christian König
19 Apr, 2014
2 commits
-
There seem to be stability issues on a number of cards.
bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=76286
https://bugzilla.redhat.com/show_bug.cgi?id=1085785
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619Signed-off-by: Alex Deucher
Cc: matthias.graf@st.ovqu.de
Cc: bp@alien8.de
Cc: stable@vger.kernel.org -
Some i2c fixes over DisplayPort.
* 'drm-next-3.15-wip' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: Improve vramlimit module param documentation
drm/radeon: fix audio pin counts for DCE6+ (v2)
drm/radeon/dp: switch to the common i2c over aux code
drm/dp/i2c: Update comments about common i2c over dp assumptions (v3)
drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
drm/i915: support address only i2c-over-aux transactions
drm/tegra: dp: Support address-only I2C-over-AUX transactions
18 Apr, 2014
10 commits
-
Signed-off-by: Gerd Hoffmann
Signed-off-by: Dave Airlie -
bochs kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.Fix this by adding suspend and resume functions.
Signed-off-by: Gerd Hoffmann
Signed-off-by: Dave Airlie -
cirrus kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.Fix this by adding suspend and resume functions.
Also make the mode_set function unblank the screen.Signed-off-by: Gerd Hoffmann
Signed-off-by: Dave Airlie -
This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.Signed-off-by: Daniel Vetter
Signed-off-by: Dave Airlie -
After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:- The locking is all wrong: set_config(NULL) will also unlink encoders
and connectors, but those links are protected with the mode_config
mutex. In the ->disable_plane callback we only hold all modeset
locks, but eventually we want to switch to just grabbing the
per-crtc (and maybe per-plane) locks as needed, maybe based on
ww_mutexes. Having a callback which absolutely needs all modeset
locks is bad for this conversion.Note that the same isn't true for the provided ->update_plane since
we've audited the crtc helpers to make sure that not encoder or
connector links are changed.- There's no way to re-enable the plane with an ->update_plane: The
connectors/encoder links are lost and so we can't re-enable the
CRTC. Even without that issue the driver might have reassigned some
shared resources (as opposed to e.g. DPMS off, where drivers are not
allowed to do that to make sure the CRTC can be enabled again).- The semantics don't make much sense: Userspace asked to scan out
black (or some other color if the driver supports a background
color), not that the screen be disabled.- Implementing proper primary plane support (i.e. actually disabling
the primary plane without disabling the CRTC) is really simple, at
least if all the hw needs is flipping a bit. The big task is
auditing all the interactions with other ioctls when the CRTC is on
but there's no primary plane (e.g. pageflips). And some of that work
still needs to be done.Cc: Matt Roper
Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
Reviewed-by: Matt Roper
Signed-off-by: Dave Airlie -
this is a typo vs the ums driver, fix to check correct value.
Found initially by Coverity.
Reported-by: Daniel Vetter
Signed-off-by: Dave Airlie -
Commit 457e77b26428ab4a24998eecfb99f27fa4195397 added two checks applied to a
value received from nv_rd32(bios, 0x619f04). But after this new piece of code
is executed, the addr local variable does not hold the same value it used to
hold before the commit. Here is what is was assigned in the original code:
(u64)(nv_rd32(bios, 0x619f04) & 0xffffff00) << 8
in the committed code it ends up with this value:
(u64)(nv_rd32(bios, 0x619f04) >> 8) << 8
These expressions are obviously not equivalent.My Nvidia video card does not show anything on the display when I boot a
kernel containing this commit.The patch fixes the code so that the new checks are still done, but the
side effect of an incorrect addr value is gone.Cc: Ben Skeggs
Cc: Dave Airlie
Cc: Andrew Morton
Signed-off-by: Sergei Antonov
Signed-off-by: Dave Airlie -
…tomba/linux into drm-next
Fixes for omapdrm, some of which were already present in 3.14, and some which
appeared in 3.15-rc1:- fixes for primary-plane handling which caused crashes
- fix all kinds of uninit issues which prevented from unloading the omapdrm
module.
- fixes for HDMI enable/disable issues* tag 'omapdrm-fixes-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
drm/omap: fix the handling of fb ref counts
drm/omap: protect omap_crtc's event with event_lock spinlock
drm/omap: Use old_fb to synchronize between successive page flips
drm/omap: Fix crash when using LCD3 overlay manager
drm/omap: gem sync: wait on correct events
drm/omap: Fix memory leak in omap_gem_op_async
drm/omap: remove warn from debugfs
drm/omap: remove extra plane->destroy from crtc destroy
drm/omap: print warning when rotating non-TILER fb
drm/omap: fix missing unref to fb's buf object
drm/omap: fix plane rotation
drm/omap: fix enabling/disabling of video pipeline
drm/omap: fix missing disable for unused encoder
drm/omap: fix race issue when unloading omapdrm
drm/omap: fix DMM driver (un)registration
drm/omap: fix uninit order in pdev_remove()
drm/omap: fix output enable/disable sequence -
1. Fixing PLL regressions
2. A couple of memory reclocking and DPM fixes
3. Small cleanups* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon/ci: make sure mc ucode is loaded before checking the size
drm/radeon/si: make sure mc ucode is loaded before checking the size
drm/radeon: improve PLL params if we don't match exactly v2
drm/radeon: memory leak on bo reservation failure. v2
drm/radeon: fix VCE fence command
drm/radeon: re-enable mclk dpm on R7 260X asics
drm/radeon: add support for newer mc ucode on CI (v2)
drm/radeon: add support for newer mc ucode on SI (v2)
drm/radeon: apply more strict limits for PLL params v2
drm/radeon: update CI DPM powertune settings
drm/radeon: fix runpm handling on APUs (v4)
drm/radeon: disable mclk dpm on R7 260X -
drm/tegra: Fixes for v3.15-rc2
This contains a fix for the host1x driver writing to non-existent syncpt
registers.A second commit removes an excess pad field in the parameter structure
for the DRM_TEGRA_SUBMIT IOCTL. Archeaology on earlier versions of this
file indicates that this was once there to pad an uneven number of u32
u32 fields, of which one was subsequently removed. Unfortunately nobody
remembered to get rid of the padding when that happened.Both of these commits are Cc: stable because they fix issues that were
introduced back in v3.10.* tag 'drm/tegra/for-3.15-rc2' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Remove gratuitous pad field
gpu: host1x: handle the correct # of syncpt regs
17 Apr, 2014
1 commit
-
Avoid a possible segfault.
Noticed-by: Dan Carpenter
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org