summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2013-02-20drm/i915: Kill obj->pending_flipVille Syrjälä
The pending flip mask no longer set anywhere, so trying to wait for while it's non-zero is a no-op. Remove it completely. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20drm/i915: Fix a typo in a intel_modeset_stage_output_state() commentDamien Lespiau
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20drm/i915: remove bogus mutex_unlock from error-pathDaniel Vetter
This has been lost in the locking rework for intel_alloc_context_page: commit 2c34b850ee1e9f86b41706149d0954eee58757a3 Author: Ben Widawsky <ben@bwidawsk.net> Date: Sat Mar 19 18:14:26 2011 -0700 drm/i915: fix ilk rc6 teardown locking Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20drm/i915: Print the pipe control page GTT addressVille Syrjälä
We already print the HWS addresses during init, so do the same for the pipe control page. Reduces guesswork when looking at hex addresses later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20drm/i915: clean up panel fitter handling in lvdsMika Kuoppala
With the previous patch "drm/i915: disable shared panel fitter for pipe" we now disable the panel fitter at the right spot in the modeset sequence in the crtc functions on all platforms. Hence the disabling in intel_disable_lvds is no longer required and potentially harmful (since the plane is still enabled at this point). Similarly on the enabling side we enable the panel fitter in the lvds callback only once the plane is enabled. Which is too late. Hence move this into a new intel_pre_enable_lvds callback. Finally we can ditch lvds_encoder->pfit_dirty - this was required to work around the crtc helper semantics, but with the new i915 modeset infrastructure we should enable/disable the pfit only when enabling or disabling the entire output pipeline. So separate state tracking for the pfit is no longer required. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Bikeshed the commit message a bit to stress that now we enable/disable the pfit on i9xx platforms at the right point of time compared to the old code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20drm/i915: disable shared panel fitter for pipeMika Kuoppala
If encoder is switched off by BIOS, but the panel fitter is left on, we never try to turn off the panel fitter and leave it still attached to the pipe - which can cause blurry output elsewhere. Based on work by Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867 Cc: stable@vger.kernel.org Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com> [danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-20drm/i915: detect wrong MCH watermark valuesDaniel Vetter
Some early bios versions seem to ship with the wrong tuning values for the MCH, possible resulting in pipe underruns under load. Especially on DP outputs this can lead to black screen, since DP really doesn't like an occasional whack from an underrun. Unfortunately the registers seem to be locked after boot, so the only thing we can do is politely point out issues and suggest a BIOS upgrade. Arthur Runyan pointed us at this issue while discussion DP bugs - thus far no confirmation from a bug report yet that it helps. But at least some of my machines here have wrong values, so this might be useful in understanding bug reports. v2: After a bit more discussion with Art and Ben we've decided to only the check the watermark values, since the OREF ones could be be a notch more aggressive on certain machines. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Runyan, Arthur J <arthur.j.runyan@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-19drm/tilcdc: add support for LCD panels (v5)Rob Clark
Add an output panel driver for LCD panels. Tested with LCD3 cape on beaglebone. v1: original v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis Antoniou v3: add backlight support v4: rebase to latest of video timing helpers v5: remove some unneeded fields from panel-info struct, add DT bindings docs Signed-off-by: Rob Clark <robdclark@gmail.com> Tested-by: Koen Kooi <koen@dominion.thruhere.net>
2013-02-19drm/tilcdc: add encoder slave (v2)Rob Clark
Add output panel driver for i2c encoder slaves. v1: original v2: add DT bindings docs, and minor updates for review comments Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Koen Kooi <koen@dominion.thruhere.net>
2013-02-19drm/i2c: nxp-tda998x (v3)Rob Clark
Driver for the NXP TDA998X i2c hdmi encoder slave. v1: original v2: fix npix/nline programming v3: add Kconfig, fix dup'd MODULE_DESCRIPTION Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Koen Kooi <koen@dominion.thruhere.net>
2013-02-19drm/tilcdc: add TI LCD Controller DRM driver (v4)Rob Clark
A simple DRM/KMS driver for the TI LCD Controller found in various smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the CMA helpers. Currently only the TFP410 DVI encoder is supported (tested with beaglebone + DVI cape). There are also various LCD displays, for which support can be added (as I get hw to test on), and an external i2c HDMI encoder found on some boards. The display controller supports a single CRTC. And the encoder+ connector are split out into sub-devices. Depending on which LCD or external encoder is actually present, the appropriate output module(s) will be loaded. v1: original v2: fix fb refcnting and few other cleanups v3: get +/- vsync/hsync from timings rather than panel-info, add option DT max-bandwidth field so driver doesn't attempt to pick a display mode with too high memory bandwidth, and other small cleanups v4: remove some unneeded stuff from panel-info struct, properly set high bits for hfp/hsw/hbp for rev 2, add DT bindings docs Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Koen Kooi <koen@dominion.thruhere.net>
2013-02-20drm: Don't set the plane->fb to NULL on successfull set_planeDaniel Vetter
We need to clear the local variable to get the refcounting right (since the reference drm_mode_setplane holds is transferred to the plane->fb pointer). But should be done _after_ we update the pointer. Breakage introduced in commit 6c2a75325c800de286166c693e0cd33c3a1c5ec8 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Dec 11 00:59:24 2012 +0100 drm: refcounting for sprite framebuffers Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Rob Clark <rob@ti.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-02-20drm: don't add inferred modes for monitors that don't support themPaulo Zanoni
If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, "the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks". For more information, please see the EDID spec, check the notes of the table that explains the "Feature Support" byte (18h) and also the notes on the tables of the section that explains "Display Range Limits & Additional Timing Description Definition (tag #FDh)". Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-02-20drm/cma-helper: fixup compilationDaniel Vetter
/me grabs a few brown paper bags So it looks like I've broken compilation in commit 6aed8ec3f76a22217c9ae183d32b1aa990bed069 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jan 20 17:32:21 2013 +0100 drm: review locking for drm_fb_helper_restore_fbdev_mode Fix it up again. v2: Only deref fbdev_cma once we're sure it's non-NULL, noticed by Thierry Reding. Reported-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-02-19Merge tag 'tegra-for-3.9-soc-ccf-fixes' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra into next/dt ARM: tegra: common clock framework fixes A number of small fixes are included to the new Tegra common clock driver. These are: Missing locking, definition of device tree clock IDs not matching the binding, a static cleanup, missing initialization of some UART clocks. This branch is based on Tegra's previous pull request tegra-for-3.9-dt. This dependency is caused by the one patch that edits the device tree. If this causes a problem, I can drop the final two patches in this pull request for now, and rebase it onto previous tegra-for-3.9-soc-ccf instead. * tag 'tegra-for-3.9-soc-ccf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra: clk: tegra: initialise parent of uart clocks ARM: tegra: remove clock-frequency properties from serial nodes clk: tegra: fix driver to match DT binding clk: tegra: local arrays should be static clk: tegra: Add missing spinlock for hclk and pclk clk: tegra: Implement locking for super clock clk: tegra: fix wrong clock index between se to sata_cold (applied to next/dt branch rather than next/soc because of the dependency) Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-02-19libfcoe: Check for unusable FCFs before looking for conflicting FCFsBhanu Prakash Gollapudi
When there are multiple FCFs in the fabric, and one of them becomes unavailable, the fabric name for the unavailable FCF becomes 0 along with FIP_FL_AVAIL getting reset. In this case, FCF selection logic does not select any FCF as it first checks for conflicting FCFs (since fabric name is 0, it fails the condition), instead of first checking if it is usable or not. Fix it by first checking if FCF is usable and skip that FCF, and go to the next one in the list to check if it can be selected. Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
2013-02-19xen-blkback: use balloon pages for persistent grantsRoger Pau Monne
With current persistent grants implementation we are not freeing the persistent grants after we disconnect the device. Since grant map operations change the mfn of the allocated page, and we can no longer pass it to __free_page without setting the mfn to a sane value, use balloon grant pages instead, as the gntdev device does. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: stable@vger.kernel.org Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-02-19xen-blkfront: drop the use of llist_for_each_entry_safeKonrad Rzeszutek Wilk
Replace llist_for_each_entry_safe with a while loop. llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best to remove it and use a while loop and do the deletion manually. Specifically this bug can be triggered by hot-unplugging a disk, either by doing xm block-detach or by save/restore cycle. BUG: unable to handle kernel paging request at fffffffffffffff0 IP: [<ffffffffa0047223>] blkif_free+0x63/0x130 [xen_blkfront] The crash call trace is: ... bad_area_nosemaphore+0x13/0x20 do_page_fault+0x25e/0x4b0 page_fault+0x25/0x30 ? blkif_free+0x63/0x130 [xen_blkfront] blkfront_resume+0x46/0xa0 [xen_blkfront] xenbus_dev_resume+0x6c/0x140 pm_op+0x192/0x1b0 device_resume+0x82/0x1e0 dpm_resume+0xc9/0x1a0 dpm_resume_end+0x15/0x30 do_suspend+0x117/0x1e0 When drilling down to the assembler code, on newer GCC it does .L29: cmpq $-16, %r12 #, persistent_gnt check je .L30 #, out of the loop .L25: ... code in the loop testq %r13, %r13 # n je .L29 #, back to the top of the loop cmpq $-16, %r12 #, persistent_gnt check movq 16(%r12), %r13 # <variable>.node.next, n jne .L25 #, back to the top of the loop .L30: While on GCC 4.1, it is: L78: ... code in the loop testq %r13, %r13 # n je .L78 #, back to the top of the loop movq 16(%rbx), %r13 # <variable>.node.next, n jmp .L78 #, back to the top of the loop Which basically means that the exit loop condition instead of being: &(pos)->member != NULL; is: ; which makes the loop unbound. Since xen-blkfront is the only user of the llist_for_each_entry_safe macro remove it from llist.h. Orabug: 16263164 CC: stable@vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-02-19xen/blkback: Don't trust the handle from the frontend.Konrad Rzeszutek Wilk
The 'handle' is the device that the request is from. For the life-time of the ring we copy it from a request to a response so that the frontend is not surprised by it. But we do not need it - when we start processing I/Os we have our own 'struct phys_req' which has only most essential information about the request. In fact the 'vbd_translate' ends up over-writing the preq.dev with a value from the backend. This assignment of preq.dev with the 'handle' value is superfluous so lets not do it. Cc: stable@vger.kernel.org Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-02-19xen-blkback: do not leak mode propertyJan Beulich
"be->mode" is obtained from xenbus_read(), which does a kmalloc() for the message body. The short string is never released, so do it along with freeing "be" itself, and make sure the string isn't kept when backend_changed() doesn't complete successfully (which made it desirable to slightly re-structure that function, so that the error cleanup can be done in one place). Reported-by: Olaf Hering <olaf@aepfle.de> CC: stable@vger.kernel.org Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2013-02-19Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
2013-02-19Merge tag 'omap-for-v3.9/usb-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/soc These changes contain the OMAP USB related platform data changes that were dropped from linux next because of the merge conflicts as requested by me and Olof. The reason was that at this point we really should be able to do the arch/arm related changes separately from driver changes to avoid dependencies between branches. These patches were initially part of the USB related MFD patches. Based on our comments, Roger Quadros quickly reworked these patches into a shared branch between ARM SoC tree and the MFD tree, then separate patches for the OMAP platform data and MFD driver. Note that this branch will conflict with c1d1cd597fc7 ("ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code"). Please see http://lkml.org/lkml/2013/2/11/16 for the merge resolution. [arnd - resolved the merge conflict] Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-02-19ppp: set qdisc_tx_busylock to avoid LOCKDEP splatEric Dumazet
If a qdisc is installed on a ppp device, its possible to get a lockdep splat under stress, because nested dev_queue_xmit() can lock busylock a second time (on a different device, so its a false positive) Avoid this problem using a distinct lock_class_key for ppp devices. Reported-by: Yanko Kaneti <yaneti@declera.com> Tested-by: Yanko Kaneti <yaneti@declera.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-02-19Merge branch 'pci/yinghai-root-bus-hotplug' into nextBjorn Helgaas
* pci/yinghai-root-bus-hotplug: PCI/ACPI: Don't cache _PRT, and don't associate them with bus numbers
2013-02-19atl1c: restore buffer stateHuang, Xiong
in the previous commit : f1f220ea1dda078, the BUSY state of buffer is wrongly deleted. this patch just restore it. Signed-off-by: xiong <xiong@qca.qualcomm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-02-19Revert "xen: netback: remove redundant xenvif_put"David S. Miller
This reverts commit d37204566a61d5116d385ae909db8e14a734b30f. This change is incorrect, as per Jan Beulich: ==================== But this is wrong from all we can tell, we discussed this before (Wei pointed to the discussion in an earlier reply). The core of it is that the put here parallels the one in netbk_tx_err(), and the one in xenvif_carrier_off() matches the get from xenvif_connect() (which normally would be done on the path coming through xenvif_disconnect()). ==================== And a previous discussion of this issue is at: http://marc.info/?l=xen-devel&m=136084174026977&w=2 Signed-off-by: David S. Miller <davem@davemloft.net>
2013-02-19IPoIB: Don't attempt to release resources on error flowItai Garbi
If the ipoib client info isn't found on the _remove_one callback, we must not attempt to scan the returned null list. Found by Coverity. Signed-off-by: Itai Garbi <igarbi@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-02-19IPoIB: Add version and firmware info to ethtool reportingYan Burman
Implement version info as well as report firmware version and bus info of the underlying IB HW device. Signed-off-by: Yan Burman <yanb@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-02-19IPoIB: Fix ipoib_neigh hashing to use the correct daddr octetsShlomo Pongratz
The hash function introduced in commit b63b70d877 ("IPoIB: Use a private hash table for path lookup in xmit path") was designd to use the 3 octets of the IPoIB HW address that holds the remote QPN. However, this currently isn't the case on little-endian machines, because the the code there uses the flags part (octet[0]) and not the last octet of the QPN (octet[3]). Fix this. The fix caused a checkpatch warning on line over 80 characters, to solve that changed the name of the temp variable that holds the daddr. Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-02-19Merge branches 'core', 'arm/omap', 'iommu/fixes', 'arm/tegra', ↵Joerg Roedel
'arm/shmobile', 'arm/exynos', 'x86/vt-d' and 'x86/amd' into next
2013-02-19iommu/tegra: assume CONFIG_OF in SMMU driverStephen Warren
Tegra only supports, and always enables, device tree. Remove all ifdefs for DT support from the driver. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
2013-02-19iommu/tegra: assume CONFIG_OF in gart driverStephen Warren
Tegra only supports, and always enables, device tree. Remove all ifdefs for DT support from the driver. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
2013-02-19HID: hidraw: print message when succesfully initializedJiri Kosina
Print a message when hidraw has been succesfully initialized. Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-02-19HID: logitech: split accel, brake for Driving Force wheelPaul Sbarra
Signed-off-by: Paul Sbarra <sbarra.paul@gmail.com> Signed-off-by: Simon Wood <simon@mungewell.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-02-19HID: logitech: add report descriptor for Driving Force wheelPaul Sbarra
This is the original report descriptor as reported by lsusb -vd 046d:c294. Signed-off-by: Paul Sbarra <sbarra.paul@gmail.com> Signed-off-by: Simon Wood <simon@mungewell.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-02-19Merge remote-tracking branch 'regulator/topic/tps65090' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/tps6507x' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/tps51632' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/s5m8767' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/palmas' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/of' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/mc13892' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/max8998' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/max8997' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/max77686' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/lp8788' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/lp8755' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/lp872x' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/lp3972' into regulator-nextMark Brown
2013-02-19Merge remote-tracking branch 'regulator/topic/lp3971' into regulator-nextMark Brown