summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-08-05drm/i915: thread address space through execbufBen Widawsky
This represents the first half of hooking up VMs to execbuf. Here we basically pass an address space all around to the different internal functions. It should be much more readable, and have less risk than the second half, which begins switching over to using VMAs instead of an obj,vm. The overall series echoes this style of, "add a VM, then make it smart later" Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Switch a BUG_ON to WARN_ON.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Update describe_objBen Widawsky
Make it aware of which domain it is bound into GGTT, or PPGTT. While modifying the function, add a global gtt flag to the object description. Global is more interesting than aliasing since aliasing is the default. v2: Access VMA directly for start/size instead of helpers (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Use ggtt_vm to save some typingBen Widawsky
Just some small cleanups, and a rename of vm->ggtt_vm requested by Daniel. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Add VM to pinBen Widawsky
To verbalize it, one can say, "pin an object into the given address space." The semantics of pinning remain the same otherwise. Certain objects will always have to be bound into the global GTT. Therefore, global GTT is a special case, and keep a special interface around for it (i915_gem_obj_ggtt_pin). v2: s/i915_gem_ggtt_pin/i915_gem_obj_ggtt_pin Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Use bound list for inactive shrinkBen Widawsky
Do to the move active/inactive lists, it no longer makes sense to use them for shrinking, since shrinking isn't VM specific (such a need may also exist, but doesn't yet). What we can do instead is use the global bound list to find all objects which aren't active. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Make proper functions for VMsBen Widawsky
Earlier in the conversion sequence we attempted to quickly wedge in the transitional interface as static inlines. Now that we're sure these interfaces are sane, for easier debug and to decrease code size (since many of these functions may be called quite a bit), make them real functions While at it, kill off the set_color interface. We'll always have the VMA, or easily get to it. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Rework drop caches for checkpatchBen Widawsky
With an upcoming change to bind, to make checkpatch happy and keep the code clean, we need to rework this code a bit. This should have no functional impact. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add the newline Chris requested.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Create an init vmBen Widawsky
Move all the similar address space (VM) initialization code to one function. Until we have multiple VMs, there should only ever be 1 VM. The aliasing ppgtt is a special case without it's own VM (since it doesn't need it's own address space management). Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915/hsw: Change default LLC age to 3Ben Widawsky
The default LLC age was changed: commit 0d8ff15e9a15f2b393e53337a107b7a1e5919b6d Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Thu Jul 4 11:02:03 2013 -0700 drm/i915/hsw: Set correct Haswell PTE encodings. On the surface it would seem setting a default age wouldn't matter because all GEM BOs are aged similarly, so the order in which objects are evicted would not be subject to aging. The current working theory as to why this caused a regression though is that LLC is a bit special in that it is shared with the CPU. Presumably (not verified) the CPU fetches cachelines with age 3, and therefore recently cached GPU objects would be evicted before similar CPU object first when the LLC is full. It stands to reason therefore that this would negatively impact CPU bound benchmarks - but those seem to be low on the priority list. eLLC OTOH does not have this same property as LLC. It should be used entirely for the GPU, and so the age really shouldn't matter. Furthermore, we have no evidence to suggest one is better than another on eLLC. Since we've never properly supported eLLC before no, there should be no regression. If the GPU client really wants "younger" objects, they should use MOCS. v2: Drop the extra #define (Chad) v3: Actually git add v4: Pimped commit message Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67062 Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05i915: fix ACPI _DSM warningPeter Wu
Since commit 29a241c (ACPICA: Add argument typechecking for all predefined ACPI names), _DSM parameters are validated which trigger the following warning: ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) As the Intel _DSM method seems to ignore this parameter, let's comply to the ACPI spec and use a Package instead. Signed-off-by: Peter Wu <lekensteyn@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32602 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: make user mode sync polarity setting explicitImre Deak
Userspace can pass a mode with an unspecified vsync/hsync polarity setting. All encoders in the Intel driver take this to mean a negative polarity setting. The HW readout/state checker code on the other hand needs these flags to be explicitly set, otherwise the state checker will WARN about the mismatch. Get rid of the WARN by making the polarity setting explicit in the adjusted mode flags based on the requested mode flags. This will keep the existing behavior otherwise. Note that we could guess from the other timing parameters whether the user wanted a VESA or other standard mode and set the polarity accordingly. This is what the NV driver does (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very exact and would change the existing behavior of the Intel driver. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442 Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: cancan,feng <cancan.feng@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: move encoder->enable callback later in VLV crtc enableJani Nikula
VLV wants encoder enabling before the pipe is up. With the previously rearranged VLV DP and HDMI ->pre_enable and ->enable callbacks in place, this no longer depends on the early ->enable hook call. Move the ->enable call at the end of the sequence, similar to the crtc enable on other platforms. This will be needed e.g. for moving the eDP backlight enabling to the right place in the sequence, currently done too early on VLV. There should be no functional changes. v2: Rebase. v3: Explain why this is needed in the commit message (Chris). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: rearrange vlv hdmi enable and pre_enable callbacksJani Nikula
VLV wants encoder enabling before the pipe is up. This is currently achieved through calling the ->enable callback early, right after the ->pre_enable callback, in valleyview_crtc_enable(). This loses both the distinction between ->pre_enable and ->enable on VLV and the possibility to use a hook at the end of the modeset sequence. Rearrange the HDMI callbacks to make it possible to move ->enable call later. Basically do everything in ->pre_enable on VLV, and make ->enable a NOP. There should be no functional changes. v2: Rebase. v3: Explain why this is needed in the commit message (Chris). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: rearrange vlv dp enable and pre_enable callbacksJani Nikula
VLV wants encoder enabling before the pipe is up. This is currently achieved through calling the ->enable callback early, right after the ->pre_enable callback, in valleyview_crtc_enable(). This loses both the distinction between ->pre_enable and ->enable on VLV and the possibility to use a hook at the end of the modeset sequence. Rearrange the DP callbacks to make it possible to move ->enable call later. Basically do everything in ->pre_enable on VLV, and make ->enable a NOP. There should be no functional changes. v2: Rebase. v3: Explain why this is needed in the commit message (Chris). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMIChris Wilson
Otherwise we get flooded by the kernel warning us that we are doing long sequences of IO without serialisation. For example, WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef() Modules linked in: CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G W 3.11.0-rc2+ #4 Call Trace: [<c2028564>] ? warn_slowpath_common+0x63/0x78 [<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef [<c20285dd>] ? warn_slowpath_null+0xf/0x13 [<c227ad43>] ? vlv_sideband_rw+0x48/0x1ef [<c227b060>] ? vlv_dpio_write+0x1c/0x21 [<c2262b3b>] ? intel_dp_set_signal_levels+0x24a/0x385 [<c2264909>] ? intel_dp_complete_link_train+0x25/0x1d1 [<c2264c55>] ? intel_dp_check_link_status+0xf7/0x106 [<c2238ced>] ? i915_hotplug_work_func+0x17b/0x221 [<c203a204>] ? process_one_work+0x12e/0x210 [<c203a5e4>] ? worker_thread+0x116/0x1ad [<c203a4ce>] ? rescuer_thread+0x1cb/0x1cb [<c203d8f5>] ? kthread+0x67/0x6c [<c2457ebb>] ? ret_from_kernel_thread+0x1b/0x30 [<c203d88e>] ? init_completion+0x18/0x18 v2: Retire the locking in vlv_crtc_enable() and do it close to the meat. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Squash in a s/mutex_lock/mutex_unlock/ fixup spotted by the 0 day kernel build/coccinelle and reported by Dan Carpenter.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: enable IPS for bpp <= 24Jesse Barnes
Art confirms that this should work fine. Since most panels are 18bpp with dithering from 24bpp, the existing code wouldn't be enabled in most cases. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Add SNB/IVB support to intel_read_wm_latencyVille Syrjälä
SNB and IVB have slightly a different way to read out the watermark latency values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Don't multiply the watermark latency values too earlyVille Syrjälä
The LP1+ watermark latency values need to be multiplied by 5 to make them suitable for watermark calculations. However on pre-HSW platforms we're going to need the raw value later when we have to write it to the WM_LPn registers' latency field. So delay the multiplication until it's needed. Note: Paulo complains that the units of wm (now in 100ns) aren't really clear and I agree. But that can be fixed later on ... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Add a comment about the unit obfuscation.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Split out reading of HSW watermark latency valuesVille Syrjälä
Move parsing of MCH_SSKPD to a separate function, we'll add other platforms there later. Note: Chris spotted an empty struct initializer and wondered whether that is hiding a compilier warning. Ville explained that it should have been part of the patch that extends this function to snb/ivb, which don't have all levels hsw has. I've figured it's ok to keep it here with a small note. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Add note about the ominous struct initializer.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Change the watermark latency type to uint16_tVille Syrjälä
The latency values fit in uint16_t, so let's save a few bytes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Don't pass "mem_value" to ilk_compute_fbc_wmVille Syrjälä
The FBC watermark doesn't depend on the latency value, so no point in passing it in. Note: It actually depends upon the latency, but only through priv_val ... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Add review comment from Paulo to the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Rename most wm compute functions to ilk_ prefixVille Syrjälä
These functions are appropriate for everything since ILK. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Rename hsw_wm_get_pixel_rate to ilk_pipe_pixel_rateVille Syrjälä
hsw_wm_get_pixel_rate() isn't specific to HSW. In fact it should be made to handle all gens, but for now it depends on the PCH panel fitter state, so give it an ilk_ prefix. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Calculate the sprite WM based on the source width instead of the ↵Ville Syrjälä
destination width Using the destination width in the sprite WM calculations isn't correct. We should be using the source width. Note: This doesn't affect hsw since it does not support sprite scaling. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Add review note from Paulo to the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Pass the actual sprite width to watermarks functionsVille Syrjälä
Don't subtract one from the sprite width before watermark calculations. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Add scaled paramater to update_sprite_watermarks()Ville Syrjälä
For calculating watermarks we want to know whether sprites are scaled. Pass that information to update_sprite_watermarks() so that eventually we may do some watermark pre-computing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05drm/i915: Tidy the macro casting by using an inline functionChris Wilson
Some of our macros we trying to convert from an drm_device to a drm_i915_private and then use the pointer inline. This is not only cumbersome but prone to error. Replacing it with a typesafe function should help catch those errors in future. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Squash in fixup to correctly order static vs. inline qualifiers, static comes first. Also fix up another offender.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-05netfilter: nfnetlink_{log,queue}: fix information leaks in netlink messageDan Carpenter
These structs have a "_pad" member. Also the "phw" structs have an 8 byte "hw_addr[]" array but sometimes only the first 6 bytes are initialized. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-08-05regmap: cache: Make sure to sync the last register in a blockLars-Peter Clausen
regcache_sync_block_raw_flush() expects the address of the register after last register that needs to be synced as its parameter. But the last call to regcache_sync_block_raw_flush() in regcache_sync_block_raw() passes the address of the last register in the block. This effectively always skips over the last register in a block, even if it needs to be synced. In order to fix it increase the address by one register. The issue was introduced in commit 75a5f89 ("regmap: cache: Write consecutive registers in a single block write"). Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-08-05vfs: add missing check for __O_TMPFILE in fcntl_init()Zheng Liu
As comment in include/uapi/asm-generic/fcntl.h described, when introducing new O_* bits, we need to check its uniqueness in fcntl_init(). But __O_TMPFILE bit is missing. So fix it. Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-05fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flinkAndy Lutomirski
Every now and then someone proposes a new flink syscall, and this spawns a long discussion of whether it would be a security problem. I think that this is missing the point: flink is *already* allowed without privilege as long as /proc is mounted -- it's called AT_SYMLINK_FOLLOW. Now that O_TMPFILE is here, the ability to create a file with O_TMPFILE, write it, and link it in is very convenient. The only problem is that it requires that /proc be mounted so that you can do: linkat(AT_FDCWD, "/proc/self/fd/<tmpfd>", dfd, path, AT_SYMLINK_NOFOLLOW) This sucks -- it's much nicer to do: linkat(tmpfd, "", dfd, path, AT_EMPTY_PATH) Let's allow it. If this turns out to be excessively scary, it we could instead require that the inode in question be I_LINKABLE, but this seems pointless given the /proc situation Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-05fs: Fix file mode for O_TMPFILEAndy Lutomirski
O_TMPFILE, like O_CREAT, should respect the requested mode and should create regular files. This fixes two bugs: O_TMPFILE required privilege (because the mode ended up as 000) and it produced bogus inodes with no type. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-05reiserfs: fix deadlock in umountAl Viro
Since remove_proc_entry() started to wait for IO in progress (i.e. since 2007 or so), the locking in fs/reiserfs/proc.c became wrong; if procfs read happens between the moment when umount() locks the victim superblock and removal of /proc/fs/reiserfs/<device>/*, we'll get a deadlock - read will wait for s_umount (in sget(), called by r_start()), while umount will wait in remove_proc_entry() for that read to finish, holding s_umount all along. Fortunately, the same change allows a much simpler race avoidance - all we need to do is remove the procfs entries in the very beginning of reiserfs ->kill_sb(); that'll guarantee that pointer to superblock will remain valid for the duration for procfs IO, so we don't need sget() to keep the sucker alive. As the matter of fact, we can get rid of the home-grown iterator completely, and use single_open() instead. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-08-05MIPS: BMIPS: fix hardware interrupt routing for boot CPU != 0Florian Fainelli
The hardware interrupt routing for boot CPU != 0 is wrong because it will route all the hardware interrupts to TP0 which is not the one we booted from. Fix this by properly checking which boot CPU we are booting from and updating the right interrupt mask for the boot CPU. This fixes booting on BCM3368 with bmips_smp_emabled = 0. Signed-off-by: Florian Fainelli <florian@openwrt.org> Cc: linux-mips@linux-mips.org Cc: blogic@openwrt.org Cc: jogo@openwrt.org Cc: cernekee@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/5650/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-08-05MIPS: oprofile: Fix BUG due to smp_processor_id() in preemptible code.Ralf Baechle
current_cpu_type() is not preemption-safe. If CONFIG_PREEMPT is enabled then mipsxx_reg_setup() can be called from preemptible state. Added get_cpu()/put_cpu() pair to make it preemption-safe. This was found while testing oprofile with CONFIG_DEBUG_PREEMPT enable. /usr/zntestsuite # opcontrol --init /usr/zntestsuite # opcontrol --setup --event=L2_CACHE_ACCESSES:500 --event=L2_CACHE_MISSES:500 --no-vmlinux /usr/zntestsuite # opcontrol --start Using 2.6+ OProfile kernel interface. BUG: using smp_processor_id() in preemptible [00000000] code: oprofiled/1362 caller is mipsxx_reg_setup+0x11c/0x164 CPU: 0 PID: 1362 Comm: oprofiled Not tainted 3.10.4 #18 Stack : 00000006 70757465 00000000 00000000 00000000 00000000 80b173f6 00000037 80b10000 00000000 80b21614 88f5a220 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 89c49c00 89c49c2c 80721254 807b7927 8012c1d0 80b10000 80721254 00000000 00000552 88f5a220 80b1335c 807b78e6 89c49ba8 ... Call Trace: [<801099a4>] show_stack+0x64/0x7c [<80665520>] dump_stack+0x20/0x2c [<803a2250>] debug_smp_processor_id+0xe0/0xf0 [<8052df24>] mipsxx_reg_setup+0x11c/0x164 [<8052cd70>] op_mips_setup+0x24/0x4c [<80529cfc>] oprofile_setup+0x5c/0x12c [<8052b9f8>] event_buffer_open+0x78/0xf8 [<801c3150>] do_dentry_open.isra.15+0x2b8/0x3b0 [<801c3270>] finish_open+0x28/0x4c [<801d49b8>] do_last.isra.41+0x2cc/0xd00 [<801d54a0>] path_openat+0xb4/0x4c4 [<801d5c44>] do_filp_open+0x3c/0xac [<801c4744>] do_sys_open+0x110/0x1f4 [<8010f47c>] stack_done+0x20/0x44 Bug reported and original patch by Jerin Jacob <jerinjacobk@gmail.com>. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Jerin Jacob <jerinjacobk@gmail.com>
2013-08-05MIPS: PNX833x: PNX8335_PCI_ETHERNET_INT depends on CONFIG_SOC_PNX8335Markos Chandras
The PNX8335_PCI_ETHERNET_INT macro is defined in arch/mips/include/asm/mach-pnx833x/irq-mapping.h only if CONFIG_SOC_PNX8335 is selected. Fixes the following randconfig problem: arch/mips/pnx833x/common/platform.c:210:12: error: 'PNX8335_PIC_ETHERNET_INT' undeclared here (not in a function) Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Acked-by: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5585/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-08-05xen/arm: missing put_cpu in xen_percpu_initJulien Grall
When CONFIG_PREEMPT is enabled, Linux will not be able to boot and warn: [ 4.127825] ------------[ cut here ]------------ [ 4.133376] WARNING: at init/main.c:699 do_one_initcall+0x150/0x158() [ 4.140738] initcall xen_init_events+0x0/0x10c returned with preemption imbalance This is because xen_percpu_init uses get_cpu but doesn't have the corresponding put_cpu. Signed-off-by: Julien Grall <julien.grall@linaro.org> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2013-08-05Merging v3.10-rc2 as I need to apply a fix forStefano Stabellini
3cc8e40e8ff8e232a9dd672da81beabd09f87366 "xen/arm: rename xen_secondary_init and run it on every online cpu" The commit is in v3.10-rc2, the current branch is based on v3.10-rc1.
2013-08-05perf/x86: Fix intel QPI uncore event definitionsVince Weaver
John McCalpin reports that the "drs_data" and "ncb_data" QPI uncore events are missing the "extra bit" and always return zero values unless the bit is properly set. More details from him: According to the Xeon E5-2600 Product Family Uncore Performance Monitoring Guide, Table 2-94, about 1/2 of the QPI Link Layer events (including the ones that "perf" calls "drs_data" and "ncb_data") require that the "extra bit" be set. This was confusing for a while -- a note at the bottom of page 94 says that the "extra bit" is bit 16 of the control register. Unfortunately, Table 2-86 clearly says that bit 16 is reserved and must be zero. Looking around a bit, I found that bit 21 appears to be the correct "extra bit", and further investigation shows that "perf" actually agrees with me: [root@c560-003.stampede]# cat /sys/bus/event_source/devices/uncore_qpi_0/format/event config:0-7,21 So the command # perf -e "uncore_qpi_0/event=drs_data/" Is the same as # perf -e "uncore_qpi_0/event=0x02,umask=0x08/" While it should be # perf -e "uncore_qpi_0/event=0x102,umask=0x08/" I confirmed that this last version gives results that agree with the amount of data that I expected the STREAM benchmark to move across the QPI link in the second (cross-chip) test of the original script. Reported-by: John McCalpin <mccalpin@tacc.utexas.edu> Signed-off-by: Vince Weaver <vincent.weaver@maine.edu> Cc: zheng.z.yan@intel.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Cc: Paul Mackerras <paulus@samba.org> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1308021037280.26119@vincent-weaver-1.um.maine.edu Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-08-05i2c: Fix Kontron PLD prescaler calculationMichael Brunner
Add some necessary braces that have been removed during driver cleanup. This fixes the I2C prescaler calculation. Signed-off-by: Michael Brunner <michael.brunner@kontron.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-05i2c: i2c-mxs: Use DMA mode even for small transfersFabio Estevam
Recently we have been seing some reports about PIO mode not working properly. - http://www.spinics.net/lists/linux-i2c/msg11985.html - http://marc.info/?l=linux-i2c&m=137235593101385&w=2 - https://lkml.org/lkml/2013/6/24/430 Let's use DMA mode even for small transfers. Without this patch, i2c reads the incorrect sgtl5000 version on a mx28evk when touchscreen is enabled: [ 5.856270] sgtl5000 0-000a: Device with ID register 0 is not a sgtl5000 [ 9.877307] sgtl5000 0-000a: ASoC: failed to probe CODEC -19 [ 9.883528] mxs-sgtl5000 sound.12: ASoC: failed to instantiate card -19 [ 9.892955] mxs-sgtl5000 sound.12: snd_soc_register_card failed (-19) Cc: <stable@vger.kernel.org> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Marek Vasut <marex@denx.de> [wsa: we have a proper solution for -next, so this non intrusive solution is OK for now] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-04skge: fix build on 32 bitStephen Hemminger
The following is needed as well to fix warning/error about shifting a 32 bit value 32 bits which occurs if building on 32 bit platform caused by conversion to using dma_addr_t Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-08-05Merge tag 'iio-fixes-for-3.11b' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: Second round of IIO fixes for the 3.11 cycle. 1) Fix a long term race in the IIO trigger handling. This only effects cases where a single trigger is in use by multiple devices. 2) ti_am335x fix an issue with incorrect data due to reading before the sequencer is finished.
2013-08-05MAINTAINERS: Add separate section for USB NETWORKING DRIVERSJoe Perches
There are several drivers in drivers/net/usb/ that do not have specific MAINTAINERS that should have emails forwarded to the linux-usb mailing list. Add a section for those drivers. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-05Merge tag 'for-usb-linus-2013-07-31' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus Sarah writes: xhci: Misc bug fixes for 3.11. Hi Greg, Here's two small fixes for 3.11. The first patch fixes a 5 second hang in khubd after a USB device disconnect on some xHCI hosts. The second fixes a build warning. Sarah Sharp
2013-08-04busy_poll: cleanup do-nothing placeholdersEliezer Tamir
When renaming ll_poll to busy poll, I introduced a typo in the name of the do-nothing placeholder for sk_busy_loop and called it sk_busy_poll. This broke compile when busy poll was not configured. Cong Wang submitted a patch to fixed that. This patch removes the now redundant, misspelled placeholder. Signed-off-by: Eliezer Tamir <eliezer.tamir@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-08-04skge: add dma_mapping checkstephen hemminger
This old driver never checked for DMA mapping errors. Causing splats with the new DMA mapping checks: WARNING: at lib/dma-debug.c:937 check_unmap+0x47b/0x930() skge 0000:01:09.0: DMA-API: device driver failed to check map Add checks and unwind code. Reported-by: poma <pomidorabelisima@gmail.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-08-04ACPI / video: improve quirk check in acpi_video_bqc_quirk()Felipe Contreras
If the _BCL package ordering is descending, the first level (br->levels[2]) is likely to be 0, and if the number of levels matches the number of steps, we might confuse a returned level to mean the index. For example: current_level = max_level = 100 test_level = 0 returned level = 100 In this case 100 means the level, not the index, and _BCM failed. Still, if the _BCL package ordering is descending, the index of level 0 is also 100, so we assume _BQC is indexed, when it's not. This causes all _BQC calls to return bogus values causing weird behavior from the user's perspective. For example: xbacklight -set 10; xbacklight -set 20; would flash to 90% and then slowly down to the desired level (20). The solution is simple; test anything other than the first level (e.g. 1). [rjw: Changelog] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-04ARM: tegra: enable ULPI phy on Colibri T20Lucas Stach
This was missed when splitting out the phy from the controller node in commit 9dffe3be3f32 (ARM: tegra: modify ULPI reset GPIO properties). Signed-off-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2013-08-04Linux 3.11-rc4v3.11-rc4Linus Torvalds
generated by cgit (git 2.34.1) at 2025-09-23 16:58:01 +0000