This regression has been introduced in
commit ca9bfa7eed
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jan 28 14:49:20 2012 +0100
drm/i915: fixup interlaced vertical timings confusion, part 1
Unfortunately that commit failed to take into account that the lvds
code does some special adjustements to the crtc timings for upscaling
an centering.
Fix this by explicitly computing crtc timings in the lvds mode fixup
function and setting a special flag in mode->private_flags if the crtc
timings have been adjusted.
v2: Add a comment to explain the new mode driver private flag,
suggested by Eugeni Dodonov.
v3: Kill the confusing and now redundant set_crtcinfo call in
intel_fixed_panel_mode, noticed by Chris Wilson.
Reported-and-Tested-by: Hans de Bruin <jmdebruin@xmsnet.nl>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43071
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung:
drm/exynos: fixed exynos broken ioctl
drm/exynos: fix to pointer manager member of struct exynos_drm_subdrv
drm/exynos: fix struct for operation callback functions to driver name
drm/exynos: use define instead of default_win member in struct mixer_context
drm/exynos: rename s/HDMI_OVERLAY_NUMBER/MIXER_WIN_NR
drm/exynos: remove unused codes in hdmi and mixer
drm/exynos: remove unnecessary type conversion of hdmi and mixer
drm/exynos: add format list of plane
drm/exynos: fixed duplicated page allocation bug.
drm/exynos: fixed page align and code clean.
Daniel Vetter writes:
3 regression fixes:
- disable gmbus again, too broken for 3.4, we'll try again for 3.5
- dp bandwidth computation fix, we've lost the 6bpc dithering flag
sometimes, this is a 3.3 regression (maybe even earlier for some
configurations).
- fix resume regression caused by the gen2/3 fencing fix merged into -rc2.
And a few other fixes:
- gpu hang fix for i845 (Chris)
- sprite fix (Armin Reese)
- crtc disable vs. scanlinewait race fix (Chris)
- rc6 module option read-only, it confused testers (Jesse)
- fbc related blitter death hw workaround, note that we disable fbc on snb
by default anyway.
With these fixes we have one 3.4 regression outstanding: One of the
cleanup patches for the interlaced support managed to confuse the lvds
panel fitter when upscaling. The root-cause is still unclear, but test
patches are awaiting feedback from the reporter.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: clear fencing tracking state when retiring requests
drm/i915: make rc6 module parameter read-only
drm/i915: implement ColorBlt w/a
drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g
Revert "drm/i915: reenable gmbus on gen3+ again"
drm/i915: properly compute dp dithering for user-created modes
drm/i915: Finish any pending operations on the framebuffer before disabling
drm/i915: Removed IVB forced enable of sprite dest key.
This fixes a resume regression introduced in
commit 7dd4906586
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Mar 21 10:48:18 2012 +0000
drm/i915: Mark untiled BLT commands as fenced on gen2/3
which fixed fencing tracking for untiled blt commands.
A side effect of that patch was that now also untiled objects have a
non-zero obj->last_fenced_seqno to track when a fence can be set up
after a pipelined tiling change. Unfortunately this was only cleared
by the fence setup and teardown code, resulting in tons of untiled but
inactive objects with non-zero last_fenced_seqno.
Now after resume we completely reset the seqno tracking, both on the
driver side (by setting dev_priv->next_seqno = 1) and on the hw side
(by allocating a new hws page, which contains the seqnos). Hilarity
and indefinite waits ensued from the stale seqnos in
obj->last_fenced_seqno from before the suspend.
The fix is to properly clear the fencing tracking state like we
already do for the normal gpu rendering while moving objects off the
active list.
Reported-and-tested-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The struct exynos_drm_manager has to exist for exynos drm sub driver
using encoder and connector. If it isn't NULL to member of struct
exynos_drm_subdrv, will create encoder and connector else will not. And
the is_local member also doesn't need.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The mixer driver and hdmi driver have each operation callback functions
and they is registered to hdmi common driver. Their struct names in hdmi
common driver include display, manager and overlay. It confuses to
appear whose operation and two driver cannot register same operation
callback functions at the same time. Use their struct names to driver
name.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The default_win member in struct mixer_context isn't change its value
after initialized to 0, so it's better using to define.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
HDMI_OVERLAY_NUMBER is specific of mixer driver and be used "windows
layer" term in exynos user manaual, so rename it.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Some members in struct mixer_context aren't used and the define
HDMI_OVERLAY_NUMBER is unused in hdmi driver, remove them.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
When the void pointer type variable is assigned to the specific pointer
type variable, don't need to do type conversion.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
People have been getting confused and thinking this is a runtime control.
Cc: stable@vger.kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to an internal workaround master list, we need to set bit 5
of register 9400 to avoid issues with color blits.
Testing shows that this seems to fix the blitter hangs when fbc is
enabled on snb, thanks to Chris Wilson for figuring this out.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Michael "brot" Groh <michael.groh@minad.de>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The 845g shares the errata with i830 whereby executing a command
within 2 cachelines of the end of the ringbuffer may cause a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
Chris Wilson pointed out that we still get things wrong for bpp > 24,
but that should be fixed in another patch (and it'll be easier because
this patch consolidates the logic).
The likely culprit for this regression is
commit 3d794f87238f74d80e78a7611c7fbde8a54c85c2
Author: Keith Packard <keithp@keithp.com>
Date: Wed Jan 25 08:16:25 2012 -0800
drm/i915: Force explicit bpp selection for intel_dp_link_required
v2: Fix indentation and tune down the too bold claim that this should
fix the world. Both noticed by Chris Wilson.
v3: Try to really git add things.
Reported-and-tested-by: Brice Goglin <Brice.Goglin@ens-lyon.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170
Cc: stable@kernel.org
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some r4xx chips have the wrong frev in the
DVOEncoderControl table. It should always be 1
on r4xx. Fixes modesetting on DVO on r4xx chips
with the bad frev.
Reported by twied on #radeon.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since cmdbuf->size and cmdbuf->nbox are from userspace, a large value
would overflow the allocation size, leading to out-of-bounds access.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some architectures require that delays longer than a few
miliseconds are called through mdelay. This was triggered
on ARM randconfig builds.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Similar to the case where we are changing from one framebuffer to
another, we need to be sure that there are no pending WAIT_FOR_EVENTs on
the pipe for the current framebuffer before switching. If we disable the
pipe, and then try to execute a WAIT_FOR_EVENT it will block
indefinitely and cause a GPU hang.
We attempted to fix this in commit 85345517fe
(drm/i915: Retire any pending operations on the old scanout when switching)
for the case of mode switching, but this leaves the condition where we
are switching off the pipe vulnerable.
There still remains the race condition were a display may be unplugged,
switched off by the core, a uevent sent to notify the DDX and the DDX
may issue a WAIT_FOR_EVENT before it processes the uevent. This window
does not exist if the pipe is only switched off in response to the
uevent. Time to make sure that is so...
Reported-by: Francis Leblanc <Francis.Leblanc-Lebeau@verint.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36515
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45413
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fixup spelling in comment, noticed by Eugeni.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The destination color key is always enabled for IVB. Removed
the line that does this.
Signed-off-by: Armin Reese <armin.c.reese@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Merge batch of fixes from Andrew Morton:
"The simple_open() cleanup was held back while I wanted for laggards to
merge things.
I still need to send a few checkpoint/restore patches. I've been
wobbly about merging them because I'm wobbly about the overall
prospects for success of the project. But after speaking with Pavel
at the LSF conference, it sounds like they're further toward
completion than I feared - apparently davem is at the "has stopped
complaining" stage regarding the net changes. So I need to go back
and re-review those patchs and their (lengthy) discussion."
* emailed from Andrew Morton <akpm@linux-foundation.org>: (16 patches)
memcg swap: use mem_cgroup_uncharge_swap fix
backlight: add driver for DA9052/53 PMIC v1
C6X: use set_current_blocked() and block_sigmask()
MAINTAINERS: add entry for sparse checker
MAINTAINERS: fix REMOTEPROC F: typo
alpha: use set_current_blocked() and block_sigmask()
simple_open: automatically convert to simple_open()
scripts/coccinelle/api/simple_open.cocci: semantic patch for simple_open()
libfs: add simple_open()
hugetlbfs: remove unregister_filesystem() when initializing module
drivers/rtc/rtc-88pm860x.c: fix rtc irq enable callback
fs/xattr.c:setxattr(): improve handling of allocation failures
fs/xattr.c:listxattr(): fall back to vmalloc() if kmalloc() failed
fs/xattr.c: suppress page allocation failure warnings from sys_listxattr()
sysrq: use SEND_SIG_FORCED instead of force_sig()
proc: fix mount -t proc -o AAA
Many users of debugfs copy the implementation of default_open() when
they want to support a custom read/write function op. This leads to a
proliferation of the default_open() implementation across the entire
tree.
Now that the common implementation has been consolidated into libfs we
can replace all the users of this function with simple_open().
This replacement was done with the following semantic patch:
<smpl>
@ open @
identifier open_f != simple_open;
identifier i, f;
@@
-int open_f(struct inode *i, struct file *f)
-{
(
-if (i->i_private)
-f->private_data = i->i_private;
|
-f->private_data = i->i_private;
)
-return 0;
-}
@ has_open depends on open @
identifier fops;
identifier open.open_f;
@@
struct file_operations fops = {
...
-.open = open_f,
+.open = simple_open,
...
};
</smpl>
[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
NV12, NV12M and NV12MT are added to format list of plane to use these
formats for hdmi vp layer.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This reverts commit d06221c061.
It turns out to trigger the "BUG_ON(!PageCompound(page))" in kfree(),
apparently because the code ends up trying to free somethng that was
never kmalloced in the first place.
BenH points out that the patch was untested and wasn't meant to go into
the upstream kernel that quickly in the first place.
Backtrace:
bios_shadow
bios_shadow_prom
nv_mask
init_io
bios_shadow
nouveau_bios_init
NVReadVgaCrtc
NVSetOwner
nouveau_card_init
nouveau_load
Reported-by: Meelis Roos <mroos@linux.ee>
Requested-by: Dave Airlie <airlied@gmail.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull drm update from Dave Airlie:
"This pull just contains a forward of the Intel fixes from Daniel.
The only annoyance is the RC6 enable, which really should have made
-next, but since Ubuntu are shipping it I reckon its getting a good
testing now by the time 3.4 comes out.
The pull from Daniel contains his pull message to me:
"A few patches for 3.4, major part is 3 regression fixes:
- ppgtt broke hibernate on snb/ivb. Somehow our QA claims that it
still works, which is why this has not been caught earlier.
- ppgtt flails in combination with dmar. I kinda expected this one :(
- fence handling bugfix for gen2/3. Iirc this one is about a year
old, fix curtesy Chris Wilson. I've created an shockingly simple
i-g-t test to catch this in the future."
Wrt regressions I've just got a report that gmbus (newly enabled
again in 3.4) is a bit noisy. I'm looking into this atm.
Also included are the rc6 enable patches for snb from Eugeni. I
wanted to include these in the main 3.4 pull but screwed it up.
Please hit me. Imo these kind of patches really should go in
before -rc1, but in thise case rc6 has brought us tons of press and
guinea pigs^W^W testers and ubuntu is already running with it. So
I estimate a pretty small chance for this to blow up.
And some smaller things:
- two minor locking snafus
- server gt2 ivb pciid
- 2 patches to sanitize the register state left behind by the bios
some more
- 2 new quirk entries
- cs readback trick against missed IRQs from ivb also enabled on snb
- sprite fix from Jesse"
Let's see if the "enable RC6 on sandybridge" finally works and sticks.
I've been enabling it by hand (i915.i915_enable_rc6=1) for several
months on my Macbook Air, and it definitely makes a difference (and has
worked for me). But every time we enabled it before it showed some odd
hw buglet for *somebody*.
This time it's all good, I'm sure.
* 'drm-fixes-intel' of git://people.freedesktop.org/~airlied/linux:
drm/i915: treat src w & h as fixed point in sprite handling code
drm/i915: no-lvds quirk on MSI DC500
drm/i915: Add lock on drm_helper_resume_force_mode
drm/i915: don't leak struct_mutex lock on ppgtt init failures
drm/i915: disable ppgtt on snb when dmar is enabled
drm/i915: add Ivy Bridge GT2 Server entries
drm/i915: properly clear SSC1 bit in the pch refclock init code
drm/i915: apply CS reg readback trick against missed IRQ on snb
drm/i915: quirk away broken OpRegion VBT
drm/i915: enable plain RC6 on Sandy Bridge by default
drm/i915: allow to select rc6 modes via kernel parameter
drm/i915: Mark untiled BLT commands as fenced on gen2/3
drm/i915: properly restore the ppgtt page directory on resume
drm/i915: Sanitize BIOS debugging bits from PIPECONF
Pull drm fixes from Dave Airlie:
"Mainly nouveau fixes, one for a regressions in -rc1, fixes for booting
on a ppc G5, and a Kconfig fix. Two radeon fixes, one oops, one s/r
fix. One udl mmap fix. And one core drm fix to stop bad fbdev apps
overwriting bits of ram."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm: Validate requested virtual size against allocated fb size
drm/radeon: Don't dereference possibly-NULL pointer.
mm, drm/udl: fixup vma flags on mmap
drm/radeon/kms: fix fans after resume
nouveau/bios: Fix tracking of BIOS image data
nouveau: Fix crash when pci_ram_rom() returns a size of 0
drm/nouveau: select POWER_SUPPLY
drm/nouveau: inform userspace of relaxed kernel subchannel requirements
Revert "drm/nouveau: inform userspace of new kernel subchannel requirements"
drm/nouveau: oops, create m2mf for nvd9 too
this patch fixes that buf->pages is allocated two times when it allocates
physically continuous memory region and removes unnecessary codes.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
1M section, 64k page count also should be rounded up so this patch
rounds up them and caculates page count of them properly and also
checks memory flags from user.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.
References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was missed when we converted the source values to 16.16 fixed point.
Cc: stable@vger.kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.
Cc: stable@kernel.org
Signed-off-by: Anisse Astier <anisse@astier.eu>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915_drm_thaw was not locking the mode_config lock when calling
drm_helper_resume_force_mode. When there were multiple wake sources,
this caused FDI training failure on SNB which in turn corrupted the
display.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: Konstantin Belousov <kostikbel@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Totally unexpected that this regressed. Luckily it sounds like we just
need to have dmar disable on the igfx, not the entire system. At least
that's what a few days of testing between Tony Vroon and me indicates.
Reported-by: Tony Vroon <tony@linx.net>
Cc: Tony Vroon <tony@linx.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This adds PCI ID for IVB GT2 server variant which we were missing.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fix up conflict because the patch has been diffed against next. tsk.]
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There should be VM_MIXEDMAP, not VM_PFNMAP, because udl_gem_fault() inserts
pages via vm_insert_page(). Other drm/gem drivers already do this.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
On pre-R600 asics, the SpeedFanControl table is not
executed as part of ASIC_Init as it is on newer asics.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The code tries various methods for retreiving the BIOS data. However
it doesn't clear the bios->data pointer between the iterations.
In some cases, the shadow() method will fail and not update bios->data
at all, which will cause us to "score" the old data and incorrectly
attribute that score to the new method. This can cause double frees
later when disposing of the unused data.
Additionally, we were not freeing the data for methods that fail the
score test (we only freed when a "best" is superseeded, not when the
new method has a lower score than the exising "best"). Fix that as well.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From b15b244d6e6e20964bd4b85306722cb60c3c0809 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon, 2 Apr 2012 13:28:18 +1000
Subject:
Under some circumstances, pci_map_rom() can return a valid mapping
but a size of 0 (if it cannot find an image in the header).
This causes nouveau to try to kmalloc() a 0 sized pointer and
dereference it, which crashes.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben H. reported that building nouveau into the kernel and power supply
as a module was broken.
Just have nouveau select it, like radeon does.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Noticed by staring at intel_reg_dumper diffs. Unfortunately it does
not seem to completely fix the bug.
Still, it's good to get this right, and maybe it helps someplace else.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47117
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky reported missed IRQ issues and this patch here helps.
We have one other missed IRQ report still left on snb, reported by QA:
https://bugs.freedesktop.org/show_bug.cgi?id=46145
This is _not_ a regression due to the forcewake voodoo though, it
started showing up before that was applied and has been on-and-off for
the past few weeks. According to QA this patch does not help. But the
missed IRQ is always from the blt ring (despite running piglit, so
also render activity expected), so I'm hopefully that this is an issue
with the blt ring itself.
Tested-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Somehow the BIOS manages to screw things up when copying the VBT
around, because the one we scrap from the VBIOS rom actually works.
Cc: stable@kernel.org
Tested-by: Markus Heinz <markus.heinz@uni-dortmund.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is yet another chapter in the ongoing saga of bringing RC6 to Sandy
Bridge machines by default.
Now that we have discovered that RC6 issues are triggered by RC6+ state,
let's try to disable it by default. Plain RC6 is the one responsible for
most energy savings, and so far it haven't given any problems - at least,
none we are aware of.
So with this, when i915_enable_rc6=-1 (e.g., the default value), we'll
attempt to enable plain RC6 only on SNB. For Ivy Bridge, the behavior
stays the same as always - we enable both RC6 and deep RC6.
Note that while this exact patch does not has explicit tested-by's, the
equivalent settings were fixed in 3.3 kernel by a smaller patch. And it
has also received considerable testing through Canonical RC6 task-force
testing at https://wiki.ubuntu.com/Kernel/PowerManagementRC6. Up to date,
it looks like all the known issues are gone.
v2: improve description and reference a couple of open bugs related to
RC6 which seem to be fixed with this change.
References: https://bugs.freedesktop.org/show_bug.cgi?id=41682
References: https://bugs.freedesktop.org/show_bug.cgi?id=38567
References: https://bugs.freedesktop.org/show_bug.cgi?id=44867
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows to select which rc6 modes are to be used via kernel parameter,
via a bitmask parameter. E.g.:
- to enable rc6, i915_enable_rc6=1
- to enable rc6 and deep rc6, i915_enable_rc6=3
- to enable rc6 and deepest rc6, use i915_enable_rc6=5
- to enable rc6, deep and deepest rc6, use i915_enable_rc6=7
Please keep in mind that the deepest RC6 state really should NOT be used
by default, as it could potentially worsen the issues with deep RC6. So do
enable it only when you know what you are doing. However, having it around
could help solving possible future rc6-related issues and their debugging
on user machines.
Note that this changes behavior - previously, value of 1 would enable both
RC6 and deep RC6. Now it should only enable RC6 and deep/deepest RC6
stages must be enabled manually.
v2: address Chris Wilson comments and clean up the code.
References: https://bugs.freedesktop.org/show_bug.cgi?id=42579
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BLT commands on gen2/3 utilize the fence registers and so we cannot
modify any fences for the object whilst those commands are in flight.
Currently we marked tiled commands as occupying a fence, but forgot to
restrict the untiled commands from preventing a fence being assigned
before they were completed.
One side-effect is that we ten have to double check that a fence was
allocated for a fenced buffer during move-to-active.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43427
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47990
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Testcase: i-g-t/tests/gem_tiled_after_untiled_blt
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ppgtt page directory lives in a snatched part of the gtt pte
range. Which naturally gets cleared on hibernate when we pull the
power. Suspend to ram (which is what I've tested) works because
despite the fact that this is a mmio region, it is actually back by
system ram.
Fix this by moving the page directory setup code to the ppgtt init
code (which gets called on resume).
This fixes hibernate on my ivb and snb.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Quoting the BSpec from time immemorial:
PIPEACONF, bits 28:27: Frame Start Delay (Debug)
Used to delay the frame start signal that is sent to the display planes.
Care must be taken to insure that there are enough lines during VBLANK
to support this setting.
An instance of the BIOS leaving these bits set was found in the wild,
where it caused our modesetting to go all squiffy and skewiff.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271
Reported-and-tested-by: Eva Wang <evawang@linpus.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
Reported-and-tested-by: Carl Richell <carl@system76.com>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
