- 04 Apr, 2014 1 commit
-
-
Imre Deak authored
During resume the intel hda audio driver depends on the i915 driver reinitializing the audio power domain. Since the order of calling the i915 resume handler wrt. that of the audio driver is not guaranteed, move the power domain reinitialization step to the resume_early handler. This is guaranteed to run before the resume handler of any other driver. The power domain initialization in turn requires us to enable the i915 pci device first, so move that part earlier too. Accordingly disabling of the i915 pci device should happen after the audio suspend handler ran. So move the disabling later from the i915 resume handler to the resume_late handler. v2: - move intel_uncore_sanitize/early_sanitize earlier too, so they don't get reordered wrt. intel_power_domains_init_hw() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Cc: stable@vger.kernel.org [danvet: Add cc: stable and loud comments that this is just a hack.] [danvet: Fix "Should it be static?" sparse warning reported by Wu Fengguang's kbuilder.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 Apr, 2014 1 commit
-
-
Chris Wilson authored
The computation of required framebuffer size in commit d978ef14 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Mar 7 08:57:51 2014 -0800 drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12 is too optimistic, and would rely on the invariant fb being reconstructed to exactly fit each pipe (and probably ignore hardware limits). Instead, we want to compute the upper bound on what the display engine will access and ensure that is within the inherited framebuffer. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 01 Apr, 2014 8 commits
-
-
Paulo Zanoni authored
Because gen6_gt_force_wake_{get,put} should already be responsible for getting/putting runtime PM. If we keep these calls, debugfs will not be testing the get/put calls of the forcewake functions. Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
If runtime PM is enabled and we unset all modes, we will runtime suspend after __intel_set_mode() , then function intel_modeset_check_state() will try to read the HW state while it is suspended and trigger lots of WARNs because it shouldn't be reading registers. So on this patch we make intel_ddi_connector_get_hw_state() return false in case the power domain is disabled, and we also make intel_display_power_enabled() return false in case the device is suspended. Notice that we can't just use intel_display_power_enabled_sw() because while the driver is being initialized the power domain refcounts are not reflecting the real state of the hardware. Just for reference, I have previously published an alternate patch for this problem, called "drm/i915: get runtime PM at intel_set_mode". Testcase: igt/pm_pc8 Signed-off-by:
-
Paulo Zanoni authored
At i915_display_info, don't call cursor_position() for a disabled CRTC, since the CRTC may be on a powered down pipe, and this will cause "Unclaimed register before interrupt" error messages. Testcase: igt/pm_pc8/debugfs-read Signed-off-by:
-
Paulo Zanoni authored
Otherwise we may get some WARNs complaining that we're reading a register while we're suspended. Testcase: igt/pm_pc8/debugfs-read Signed-off-by:
-
Paulo Zanoni authored
... at edp_have_panel_vdd. Just return false, saying we don't have the panel VDD since the device is suspended. We started getting WARNs about this problem since the patch that started checking if we're suspended while reading registers. Example backtrace provided by Paulo: [ 63.572201] [drm:hsw_enable_pc8] Enabling package C8+ [ 63.581831] [drm:i915_runtime_suspend] Device suspended [ 63.664798] ------------[ cut here ]------------ [ 63.664824] WARNING: CPU: 3 PID: 828 at drivers/gpu/drm/i915/intel_uncore.c:47 assert_device_not_suspended.isra.7+0x32/0x40 [i915]() [ 63.664826] Device suspended [ 63.664828] Modules linked in: ccm fuse ip6table_filter ip6_tables ebtable_nat ebtables arc4 ath9k_htc ath9k_common ath9k_hw mac80211 ath cfg80211 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp microcode i2c_i801 e1000e pcspkr serio_raw lpc_ich ptp pps_core mei_me mei mfd_core dm_crypt i915 crc32_pclmul crc32c_intel ghash_clmulni_intel i2c_algo_bit drm_kms_helper drm video [ 63.664867] CPU: 3 PID: 828 Comm: kworker/3:3 Not tainted 3.14.0+ #153 [ 63.664869] Hardware name: Intel Corporation Shark Bay Client platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0133.R00.1309172123 09/17/2013 [ 63.664887] Workqueue: events edp_panel_vdd_work [i915] [ 63.664889] 0000000000000009 ffff88009d745c28 ffffffff8167ec6f ffff88009d745c70 [ 63.664895] ffff88009d745c60 ffffffff8106c8ed ffff880036278000 00000000000c7204 [ 63.664900] ffff88014f2d3040 ffff880036278070 0000000000000001 ffff88009d745cc0 [ 63.664905] Call Trace: [ 63.664911] [<ffffffff8167ec6f>] dump_stack+0x4d/0x66 [ 63.664916] [<ffffffff8106c8ed>] warn_slowpath_common+0x7d/0xa0 [ 63.664920] [<ffffffff8106c95c>] warn_slowpath_fmt+0x4c/0x50 [ 63.664926] [<ffffffff810bd6be>] ? mark_held_locks+0xae/0x130 [ 63.664941] [<ffffffffa00d80d2>] assert_device_not_suspended.isra.7+0x32/0x40 [i915] [ 63.664956] [<ffffffffa00d99d2>] gen6_read32+0x32/0x120 [i915] [ 63.664969] [<ffffffffa00d99a0>] ? gen6_read8+0x120/0x120 [i915] [ 63.664985] [<ffffffffa0106f8f>] edp_have_panel_vdd+0x3f/0x50 [i915] [ 63.665000] [<ffffffffa01074e8>] edp_panel_vdd_off_sync+0x58/0x1c0 [i915] [ 63.665004] [<ffffffff8108a06c>] ? process_one_work+0x18c/0x560 [ 63.665018] [<ffffffffa0107684>] edp_panel_vdd_work+0x34/0x50 [i915] [ 63.665022] [<ffffffff8108a0d7>] process_one_work+0x1f7/0x560 [ 63.665026] [<ffffffff8108a06c>] ? process_one_work+0x18c/0x560 [ 63.665031] [<ffffffff8108ae2b>] worker_thread+0x11b/0x3a0 [ 63.665035] [<ffffffff8108ad10>] ? manage_workers.isra.21+0x2a0/0x2a0 [ 63.665039] [<ffffffff810916fc>] kthread+0xfc/0x120 [ 63.665043] [<ffffffff81091600>] ? kthread_create_on_node+0x230/0x230 [ 63.665048] [<ffffffff8169082c>] ret_from_fork+0x7c/0xb0 [ 63.665052] [<ffffffff81091600>] ? kthread_create_on_node+0x230/0x230 [ 63.665054] ---[ end trace 1250bcc890af9999 ]--- [ 63.665060] [drm:edp_panel_vdd_off_sync] Turning eDP VDD off [ 63.665061] ------------[ cut here ]------------ Testcase: igt/pm_pc8 Signed-off-by:
-
Paulo Zanoni authored
To avoid WARNs when we call it. Testcase: igt/pm_pc8/reg-read-ioctl Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75693Signed-off-by:
-
Paulo Zanoni authored
So far force_wake_timer was only used by gen6_gt_force_wake_put. Since we always had balanced gen6_gt_force_wake_get/put calls, we could guarantee balanced calls to intel_runtime_pm_get/put. Commit 8232644c, "drm/i915: Convert the forcewake worker into a timer func" started scheduling the force_wake_timer at gen6_read, which resulted in an unbalanced runtime_pm refcount. So this commit just reverts to the old behavior until we can find a proper way to used delayed force_wake from the register read/write macros without leaving the runtime_pm refcounts unbalanced and without runtime suspending the driver while forcewake is active. Testcase: igt/pm_pc8/rte Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76544Signed-off-by:
-
Imre Deak authored
Atm we reserve/allocate and free the power context during GT power enable/disable time. There is no need to do this, we can reserve/allocate the buffer once during driver loading and free it during driver cleanup. The re-reservation can also fail in case the driver previously manages to allocate something on the given fixed address. The buffer isn't exepected to move even if allocated by the BIOS, for safety add an assert to check this assumption. This also fixed a bug for Ville, where re-reserving the context failed during a GPU reset (I assume because something else got allocated on its fixed address). Tested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 31 Mar, 2014 23 commits
-
-
Jani Nikula authored
Remove the rest of the references to drm_i915_private_t. No functional changes. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> [danvet: Drop hunk in i915_cmd_parser.c] Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Jani Nikula authored
Also drop any unnecessary casts. No functional changes. Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Jani Nikula authored
Also drop any unnecessary casts. No functional changes. Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Chris Wilson authored
The speculation is that we can conserve more power by masking off the interrupts at source (PMINTRMSK) rather than filtering them by the up/down thresholds (RPINTLIM). We can select which events we know will be active based on the current frequency versus our imposed range, i.e. if at minimum, we know we will not want to generate any more down-interrupts and vice versa. v2: We only need the TIMEOUT when above min frequency. v3: Tweak VLV at the same time Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
What used to be a short-circuit now needs to adjust interrupt masking in response to user requests for changing the min/max allowed frequencies. This is currently done by a special case and early return, but the next patch adds another common action to take, so refactor the code to reduce duplication. Signed-off-by:
-
Chris Wilson authored
This reverts commit 27544369. Conflicts: drivers/gpu/drm/i915/i915_irq.c The partial application of interrupt masking without regard to other pathways for adjusting the RPS frequency results in completely disabling the PM interrupts. This leads to excessive power consumption as the GPU is kept at max clocks (until the failsafe mechanism fires of explicitly downclocking the GPU when all requests are idle). Or equally as bad for the UX, the GPU is kept at minimum clocks and prevented from upclocking in response to a requirement for more power. Testcase: pm_rps/blocking Cc: Deepak S <deepak.s@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
If vsyncshift comes out as negative, add one htotal to it to get the corresponding positive value. This is rather theoretical as it would require a mode where the hsync+back porch is very long and the active+front porch very short. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
PIPECONF_INTERLACE_W_FIELD_INDICATION is only meant to be used for sdvo since it implies a slightly weird vsync shift of htotal/2. For everything else we should use PIPECONF_INTERLACE_W_SYNC_SHIFT and let the value in the VSYNCSHIFT register take effect. The only exception is gen3 simply because VSYNCSHIFT didn't exist yet. Gen2 doesn't support interlaced modes at all, so we can drop the explicit gen2 checks. Signed-off-by:
-
Ville Syrjälä authored
When interlaced sdvo output is used, vsyncshift should supposedly be (htotal-1)/2. In reality PIPECONF/TRANSCONF will override it by using the legacy vsyncshift interlace mode which causes the hardware to ignore the VSYNCSHIFT register. The only odd thing here is that on PCH platforms we program the VSYNCSHIFT on both CPU and PCH, and it's not entirely clear if both sides have to agree on the value or not. On the CPU side there's no way to override the value via PIPECONF anymore, so if we want to make the CPU side agree with the PCH side, we should probably program the approriate value into VSYNCSHIFT manually. So let's do that, but for now leave the PCH side to still use the legacy interlace mode in TRANSCONF. We can also drop the gen2 check since gen2 doesn't support interlaced modes at all. Signed-off-by:
-
Jesse Barnes authored
This makes HDMI testers happier on VLV platforms. It may be that we need it for any non-SVO platform, but I don't have any tests to back that up, so I'm leaving other pre-ILK platforms alone for now. Tested-by: "Clint Taylor <clinton.a.taylor@intel.com>" Signed-off-by:
-
Daniel Vetter authored
We want future generations to at least attempt to use all features, so restrict the stolen memory disabling when vt-d is enabled to the latest generation we have reports for. Which is a HSW per the original report. Also once we get a bit a hold of some of the mysterious framebuffer in stolen memory issues that still haunt bugzilla, we should probably drop this hack again and see what happens. This was introduced in commit 0f4706d2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Mar 18 14:50:50 2014 +0200 drm/i915: Disable stolen memory when DMAR is active Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=68535Acked-by:
-
Daniel Vetter authored
Linux 3.14 The vt-d w/a merged late in 3.14-rc needs a bit of fine-tuning, hence backmerge. Conflicts: drivers/gpu/drm/i915/i915_gem_gtt.c drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_dp.c All trivial adjacent lines changed type conflicts, so trivial git doesn't even show them in the merg commit. Signed-off-by: -
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs fixes from Al Viro: "Switch mnt_hash to hlist, turning the races between __lookup_mnt() and hash modifications into false negatives from __lookup_mnt() (instead of hangs)" On the false negatives from __lookup_mnt(): "The *only* thing we care about is not getting stuck in __lookup_mnt(). If it misses an entry because something in front of it just got moved around, etc, we are fine. We'll notice that mount_lock mismatch and that'll be it" * 'for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: switch mnt_hash to hlist don't bother with propagate_mnt() unless the target is shared keep shadowed vfsmounts together resizable namespace.c hashes
-
Randy Dunlap authored
I am the new kernel tree Documentation maintainer (except for parts that are handled by other people, of course). Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by:
Rob Landley <rob@landley.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
Pull input updates from Dmitry Torokhov: "Some more updates for the input subsystem. You will get a fix for race in mousedev that has been causing quite a few oopses lately and a small fixup for force feedback support in evdev" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: mousedev - fix race when creating mixed device Input: don't modify the id of ioctl-provided ff effect on upload failure
-
Eric Paris authored
It its possible to configure your PAM stack to refuse login if audit messages (about the login) were unable to be sent. This is common in many distros and thus normal configuration of many containers. The PAM modules determine if audit is enabled/disabled in the kernel based on the return value from sending an audit message on the netlink socket. If userspace gets back ECONNREFUSED it believes audit is disabled in the kernel. If it gets any other error else it refuses to let the login proceed. Just about ever since the introduction of namespaces the kernel audit subsystem has returned EPERM if the task sending a message was not in the init user or pid namespace. So many forms of containers have never worked if audit was enabled in the kernel. BUT if the container was not in net_init then the kernel network code would send ECONNREFUSED (instead of the audit code sending EPERM). Thus by pure accident/dumb luck/bug if an admin configured the PAM stack to reject all logins that didn't talk to audit, but then ran the login untility in the non-init_net namespace, it would work!! Clearly this was a bug, but it is a bug some people expected. With the introduction of network namespace support in 3.14-rc1 the two bugs stopped cancelling each other out. Now, containers in the non-init_net namespace refused to let users log in (just like PAM was configfured!) Obviously some people were not happy that what used to let users log in, now didn't! This fix is kinda hacky. We return ECONNREFUSED for all non-init relevant namespaces. That means that not only will the old broken non-init_net setups continue to work, now the broken non-init_pid or non-init_user setups will 'work'. They don't really work, since audit isn't logging things. But it's what most users want. In 3.15 we should have patches to support not only the non-init_net (3.14) namespace but also the non-init_pid and non-init_user namespace. So all will be right in the world. This just opens the doors wide open on 3.14 and hopefully makes users happy, if not the audit system... Reported-by:
Andre Tomt <andre@tomt.net> Reported-by:
Adam Richter <adam_richter2004@yahoo.com> Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
Theodore Ts'o authored
Use cmpxchg() to atomically set i_flags instead of clearing out the S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race where an immutable file has the immutable flag cleared for a brief window of time. Reported-by:
John Sullivan <jsrhbz@kanargh.force9.co.uk> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
-
- 30 Mar, 2014 4 commits
-
-
Al Viro authored
fixes RCU bug - walking through hlist is safe in face of element moves, since it's self-terminating. Cyclic lists are not - if we end up jumping to another hash chain, we'll loop infinitely without ever hitting the original list head. [fix for dumb braino folded] Spotted by: Max Kellermann <mk@cm4all.com> Cc: stable@vger.kernel.org Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
If the dest_mnt is not shared, propagate_mnt() does nothing - there's no mounts to propagate to and thus no copies to create. Might as well don't bother calling it in that case. Cc: stable@vger.kernel.org Signed-off-by: -
Al Viro authored
preparation to switching mnt_hash to hlist Cc: stable@vger.kernel.org Signed-off-by: -
Al Viro authored
* switch allocation to alloc_large_system_hash() * make sizes overridable by boot parameters (mhash_entries=, mphash_entries=) * switch mountpoint_hashtable from list_head to hlist_head Cc: stable@vger.kernel.org Signed-off-by:
-
- 29 Mar, 2014 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Ingo Molnar: "A late breaking fix from John. (The bug fixed has a hard lockup potential, but that was not observed, warnings were)" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: time: Revert to calling clock_was_set_delayed() while in irq context
-
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-clientLinus Torvalds authored
Pull Ceph fix from Sage Weil: "This drops a bad assert that a few users have been hitting but we've only recently been able to track down" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: rbd: drop an unsafe assertion
-
Dmitry Torokhov authored
We should not be using static variable mousedev_mix in methods that can be called before that singleton gets assigned. While at it let's add open and close methods to mousedev structure so that we do not need to test if we are dealing with multiplexor or normal device and simply call appropriate method directly. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551Reported-by:
GiulioDP <depasquale.giulio@gmail.com> Tested-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
