- 01 Apr, 2014 7 commits
-
-
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 <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Imre Deak <imre.deak@intel.com> Reviewed-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:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Deepak S <deepak.s@linux.intel.com> Reviewed-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 5 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>
-
Elias Vanderstuyft authored
If a new (id == -1) ff effect was uploaded from userspace, ff-core.c::input_ff_upload() will have assigned a positive number to the new effect id. Currently, evdev.c::evdev_do_ioctl() will save this new id to userspace, regardless of whether the upload succeeded or not. On upload failure, this can be confusing because the dev->ff->effects[] array will not contain an element at the index of that new effect id. This patch fixes this by leaving the id unchanged after upload fails. Note: Unfortunately applications should still expect changed effect id for quite some time. This has been discussed on: http://www.mail-archive.com/linux-input@vger.kernel.org/msg08513.html ("ff-core effect id handling in case of a failed effect upload") Suggested-by:
Elias Vanderstuyft <elias.vds@gmail.com> Signed-off-by:
-
Alex Elder authored
Olivier Bonvalet reported having repeated crashes due to a failed assertion he was hitting in rbd_img_obj_callback(): Assertion failure in rbd_img_obj_callback() at line 2165: rbd_assert(which >= img_request->next_completion); With a lot of help from Olivier with reproducing the problem we were able to determine the object and image requests had already been completed (and often freed) at the point the assertion failed. There was a great deal of discussion on the ceph-devel mailing list about this. The problem only arose when there were two (or more) object requests in an image request, and the problem was always seen when the second request was being completed. The problem is due to a race in the window between setting the "done" flag on an object request and checking the image request's next completion value. When the first object request completes, it checks to see if its successor request is marked "done", and if so, that request is also completed. In the process, the image request's next_completion value is updated to reflect that both the first and second requests are completed. By the time the second request is able to check the next_completion value, it has been set to a value *greater* than its own "which" value, which caused an assertion to fail. Fix this problem by skipping over any completion processing unless the completing object request is the next one expected. Test only for inequality (not >=), and eliminate the bad assertion. Tested-by:Olivier Bonvalet <ob@daevel.fr> Signed-off-by:
Alex Elder <elder@linaro.org> Reviewed-by:
Sage Weil <sage@inktank.com> Reviewed-by:
Ilya Dryomov <ilya.dryomov@inktank.com>
-
- 28 Mar, 2014 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) We've discovered a common error in several networking drivers, they put VLAN offload features into ->vlan_features, which would suggest that they support offloading 2 or more levels of VLAN encapsulation. Not only do these devices not do that, but we don't have the infrastructure yet to handle that at all. Fixes from Vlad Yasevich. 2) Fix tcpdump crash with bridging and vlans, also from Vlad. 3) Some MAINTAINERS updates for random32 and bonding. 4) Fix late reseeds of prandom generator, from Sasha Levin. 5) Bridge doesn't handle stacked vlans properly, fix from Toshiaki Makita. 6) Fix deadlock in openvswitch, from Flavio Leitner. 7) get_timewait4_sock() doesn't report delay times correctly, fix from Eric Dumazet. 8) Duplicate address detection and addrconf verification need to run in contexts where RTNL can be obtained. Move them to run from a workqueue. From Hannes Frederic Sowa. 9) Fix route refcount leaking in ip tunnels, from Pravin B Shelar. 10) Don't return -EINTR from non-blocking recvmsg() on AF_UNIX sockets, from Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (28 commits) vlan: Warn the user if lowerdev has bad vlan features. veth: Turn off vlan rx acceleration in vlan_features ifb: Remove vlan acceleration from vlan_features qlge: Do not propaged vlan tag offloads to vlans bridge: Fix crash with vlan filtering and tcpdump net: Account for all vlan headers in skb_mac_gso_segment MAINTAINERS: bonding: change email address MAINTAINERS: bonding: change email address ipv6: move DAD and addrconf_verify processing to workqueue tcp: fix get_timewait4_sock() delay computation on 64bit openvswitch: fix a possible deadlock and lockdep warning bridge: Fix handling stacked vlan tags bridge: Fix inabillity to retrieve vlan tags when tx offload is disabled vhost: validate vhost_get_vq_desc return value vhost: fix total length when packets are too short random32: avoid attempt to late reseed if in the middle of seeding random32: assign to network folks in MAINTAINERS net/mlx4_core: pass pci_device_id.driver_data to __mlx4_init_one during reset core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors vlan: Set hard_header_len according to available acceleration ...
-
