- 02 Oct, 2012 40 commits
-
-
Alex Deucher authored
commit c205b232 upstream. Power gating is per crtc pair, but the powergating registers should be called individually. The hw handles power up/down properly. The pair is powered up if either crtc in the pair is powered up and the pair is not powered down until both crtcs in the pair are powered down. This simplifies programming and should save additional power as the previous code never actually power gated the crtc pair. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alex Deucher authored
commit 8d1af57a upstream. The ordering is important and the current drm code wasn't cutting it for modern DIG encoders. We need to have information about crtc before setting up the encoders so I've shifted the ordering a bit. Probably we'll need a full rework akin to danvet's recent intel patchs. This patch fixes numerous issues with DP bridge chips and makes link training much more reliable. Signed-off-by:
-
Jakob Bornecrantz authored
commit 7c4eaca4 upstream. Signed-off-by:
Jakob Bornecrantz <jakob@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
AceLan Kao authored
commit 3766054f upstream. There are some new video switch keys that used by newer machines. 0xA0 - SDSP HDMI only 0xA1 - SDSP LCD + HDMI 0xA2 - SDSP CRT + HDMI 0xA3 - SDSP TV + HDMI But in Linux, there is no suitable userspace application to handle this, so, mapping them all to KEY_SWITCHVIDEOMODE. Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Cc: Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Corentin Chary authored
commit 8871e99f upstream. Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=24222Signed-off-by:
Corentin Chary <corentin.chary@gmail.com> Signed-off-by:
-
Jani Nikula authored
commit 4eab8136 upstream. Refactor the connector update part of intel_ddc_get_modes() into a separate intel_connector_update_modes() function for reuse. No functional changes. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45881Tested-by:
Alex Ferrando <alferpal@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Tvrtko Ursulin authored
commit 52e9b39d upstream. There is a more recent APU stepping with a new PCI ID shipping in the same board by Fujitsu which needs the same quirk to correctly mark the back plane connectors. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> Signed-off-by:
-
David Lamparter authored
commit 268ba0a9 upstream. This is required for pure UEFI systems. The vbios is stored in ACPI rather than at the legacy vga location. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=26891 V2: fix #ifdefs as per Greg's comments V3: fix it harder Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit c61e2775 upstream. There are systems that use ATRM, but not ATPX. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41265 V2: fix #ifdefs as per Greg's comments V3: fix it harder Signed-off-by:
-
Alex Deucher authored
commit 53176706 upstream. When checking if a pll is in use. Signed-off-by:
-
Jerome Glisse authored
commit 5efcc76c upstream. If spread spectrum is enabled and in use for a given pll we should not turn it off as it will lead to turning off display for crtc that use the pll (this behavior was observed on chelsea edp). Signed-off-by:
-
Dave Airlie authored
commit d8636a27 upstream. So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load) Thread B (timer thread) unbind_con_driver -> | bind_con_driver -> | vc->vc_sw->con_deinit -> | fbcon_deinit -> | console_lock() | | | | fbcon_flashcursor timer fires | console_lock() <- blocked for A | | fbcon_del_cursor_timer -> del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb->kms driver handoff. v1.1: add comment suggestion from Alan. Signed-off-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Tested-by:
Josh Boyer <jwboyer@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Robin Holt authored
commit 7838f994 upstream. On many of our larger systems, CPU 0 has had all of its IRQ resources consumed before XPC loads. Worst cases on machines with multiple 10 GigE cards and multiple IB cards have depleted the entire first socket of IRQs. This patch makes selecting the node upon which IRQs are allocated (as well as all the other GRU Message Queue structures) specifiable as a module load param and has a default behavior of searching all nodes/cpus for an available resources. [akpm@linux-foundation.org: fix build: include cpu.h and module.h] Signed-off-by:
Robin Holt <holt@sgi.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Rafael J. Wysocki authored
commit 58a34de7 upstream. The power.deferred_resume can only be set if the runtime PM status of device is RPM_SUSPENDING and it should be cleared after its status has been changed, regardless of whether or not the runtime suspend has been successful. However, it only is cleared on suspend failure, while it may remain set on successful suspend and is happily leaked to rpm_resume() executed in that case. That shouldn't happen, so if power.deferred_resume is set in rpm_suspend() after the status has been changed to RPM_SUSPENDED, clear it before calling rpm_resume(). Then, it doesn't need to be cleared before changing the status to RPM_SUSPENDING any more, because it's always cleared after the status has been changed to either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure). Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Rafael J. Wysocki authored
commit 7f321c26 upstream. For devices whose power.no_callbacks flag is set, rpm_resume() should return 1 if the device's parent is already active, so that the callers of pm_runtime_get() don't think that they have to wait for the device to resume (asynchronously) in that case (the core won't queue up an asynchronous resume in that case, so there's nothing to wait for anyway). Modify the code accordingly (and make sure that an idle notification will be queued up on success, even if 1 is to be returned). Signed-off-by:
-
Atsushi Nemoto authored
commit 7dbfb315 upstream. Correct the offset by subtracting 20 from tm_hour before taking the modulo 12. [ "Why 20?" I hear you ask. Or at least I did. Here's the reason why: RS5C348_BIT_PM is 32, and is - stupidly - included in the RS5C348_HOURS_MASK define. So it's really subtracting out that bit to get "hour+12". But then because it does things modulo 12, it needs to add the 12 in again afterwards anyway. This code is confused. It would be much clearer if RS5C348_HOURS_MASK just didn't include the RS5C348_BIT_PM bit at all, then it wouldn't need to do the silly subtract either. Whatever. It's all just math, the end result is the same. - Linus ] Reported-by:
James Nute <newten82@gmail.com> Tested-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
-
Will Deacon authored
commit 0bce9c46 upstream. ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation after the previous implementation was found to be missing some crucial memory barriers. However, this has revealed some problems running hackbench on SMP platforms due to the way in which the MUTEX_SPIN_ON_OWNER code operates. The symptoms are that a bunch of hackbench tasks are left waiting on an unlocked mutex and therefore never get woken up to claim it. This boils down to the following sequence of events: Task A Task B Task C Lock value 0 1 1 lock() 0 2 lock() 0 3 spin(A) 0 4 unlock() 1 5 lock() 0 6 cmpxchg(1,0) 0 7 contended() -1 8 lock() 0 9 spin(C) 0 10 unlock() 1 11 cmpxchg(1,0) 0 12 unlock() 1 At this point, the lock is unlocked, but Task B is in an uninterruptible sleep with nobody to wake it up. This patch fixes the problem by ensuring we put the lock into the contended state if we fail to acquire it on the fastpath, ensuring that any blocked waiters are woken up when the mutex is released. Signed-off-by:
Will Deacon <will.deacon@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Chris Mason <chris.mason@fusionio.com> Cc: Ingo Molnar <mingo@elte.hu> Reviewed-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Xinyu Chen authored
commit 9ec1882d upstream. The console feature's write routing is unsafe on SMP with the startup/shutdown call. There could be several consumers of the console * the kernel printk * the init process using /dev/kmsg to call printk to show log * shell, which open /dev/console and write with sys_write() The shell goes into the normal uart open/write routing, but the other two go into the console operations. The open routing calls imx serial startup, which will write USR1/2 register without any lock and critical with imx_console_write call. Add a spin_lock for startup/shutdown/console_write routing. This patch is a port from Freescale's Android kernel. Signed-off-by:
Xinyu Chen <xinyu.chen@freescale.com> Tested-by:
Dirk Behme <dirk.behme@de.bosch.com> CC: Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Moiz Sonasath authored
commit 29636578 upstream. For non PCI-based stacks, this function call usb_disable_xhci_ports(to_pci_dev(hcd->self.controller)); made from xhci_shutdown is not applicable. Ideally, we wouldn't have any PCI-specific code on a generic driver such as the xHCI stack, but it looks like we should just stub usb_disable_xhci_ports() out for non-PCI devices. [ balbi@ti.com: slight improvement to commit log ] This patch should be backported to kernels as old as 3.0, since the commit it fixes (e95829f4 "xhci: Switch PPT ports to EHCI on shutdown.") was marked for stable. Signed-off-by: Moiz Sonasath<m-sonasath@ti.com> Signed-off-by:
Ruchika Kharwar <ruchika@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Manoj Iyer authored
commit 29d21457 upstream. On Intel Panther Point chipset USB 3.0 devices show up as high-speed devices on powerup, but after an s3 cycle they are correctly recognized as SuperSpeed. At powerup switch the port to xHCI so that USB 3.0 devices are correctly recognized. BugLink: http://bugs.launchpad.net/bugs/1000424 This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by:
Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by:
-
Matthew Garrett authored
commit e955a1cd upstream. My test platform (Intel DX79SI) boots reliably under BIOS, but frequently crashes when booting via UEFI. I finally tracked this down to the xhci handoff code. It seems that reads from the device occasionally just return 0xff, resulting in xhci_find_next_cap_offset generating a value that's larger than the resource region. We then oops when attempting to read the value. Sanity checking that value lets us avoid the crash. I've no idea what's causing the underlying problem, and xhci still doesn't actually *work* even with this, but the machine at least boots which will probably make further debugging easier. This should be backported to kernels as old as 2.6.31, that contain the commit 66d4eadd "USB: xhci: BIOS handoff and HW initialization." Signed-off-by:
-
Dan Carpenter authored
commit 052c7f9f upstream. The intent was to test whether the flag was set. This patch should be backported to stable kernels as old as 3.0, since it fixes a bug in commit e95829f4 "xhci: Switch PPT ports to EHCI on shutdown.", which was marked for stable. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Ruchika Kharwar authored
commit 319acdfc upstream. Use the ioremap_nocache variant of the ioremap API in order to make sure our memory will be marked uncachable. This patch should be backported to kernels as old as 3.4, that contain the commit 3429e91a "usb: host: xhci: add platform driver support". Signed-off-by:
-
Keng-Yu Lin authored
commit a96874a2 upstream. With a previous patch to enable the EHCI/XHCI port switching, it switches all the available ports. The assumption is not correct because the BIOS may expect some ports not switchable by the OS. There are two more registers that contains the information of the switchable and non-switchable ports. This patch adds the checking code for the two register so that only the switchable ports are altered. This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by:
Keng-Yu Lin <kengyu@canonical.com> Signed-off-by:
-
Alexis R. Cortes authored
commit 71c731a2 upstream. This patch is intended to work around a known issue on the SN65LVPE502CP USB3.0 re-driver that can delay the negotiation between a device and the host past the usual handshake timeout. If that happens on the first insertion, the host controller port will enter in Compliance Mode and NO port status event will be generated (as per xHCI Spec) making impossible to detect this event by software. The port will remain in compliance mode until a warm reset is applied to it. As a result of this, the port will seem "dead" to the user and no device connections or disconnections will be detected. For solving this, the patch creates a timer which polls every 2 seconds the link state of each host controller's port (this by reading the PORTSC register) and recovers the port by issuing a Warm reset every time Compliance mode is detected. If a xHC USB3.0 port has previously entered to U0, the compliance mode issue will NOT occur only until system resumes from sleep/hibernate, therefore, the compliance mode timer is stopped when all xHC USB 3.0 ports have entered U0. The timer is initialized again after each system resume. Since the issue is being caused by a piece of hardware, the timer will be enabled ONLY on those systems that have the SN65LVPE502CP installed (this patch uses DMI strings for detecting those systems) therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK has been added to the xhci stack). This patch applies for these systems: Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820. This patch should be backported to kernels as old as 3.2, as that was the first kernel to support warm reset. The kernels will need to contain both commit 10d674a8 "USB: When hot reset for USB3 fails, try warm reset" and commit 8bea2bd3 "usb: Add support for root hub port status CAS". The first patch add warm reset support, and the second patch modifies the USB core to issue a warm reset when the port is in compliance mode. Signed-off-by:
Alexis R. Cortes <alexis.cortes@ti.com> Signed-off-by:
-
Sergei Poselenov authored
commit efd5d6b0 upstream. On our system (ARM Cortex-M3 SOC running linux-2.6.33) frequent crashes were observed in the rt2800usb module because of the invalid length of the received packet (3392, 46920...). This patch adds the sanity check on the packet legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone() so that the bad packet condition would be noticed. The fix was tested on the latest compat-wireless-3.5.1-1-snpc. Signed-off-by:
Sergei Poselenov <sposelenov@emcraft.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Alan Stern authored
commit 92fc7a8b upstream. This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss infrared touchboard device. The device doesn't like to be asked for its interface strings. Signed-off-by:
adam ? <adam3337@wp.pl> Signed-off-by:
-
Nicolas Ferre authored
commit 6fffb77c upstream. If the number of ports present on the SoC/board is not the maximum and that the platform data is not filled with all data, there is an easy way to mess the PIO setup for this interface. This quick fix addresses mis-configuration in USB host platform data that is common in at91 boards since commit 0ee6d1ee (USB: ohci-at91: change maximum number of ports) that did not modified the associatd board files. Reported-by:
Klaus Falkner <klaus.falkner@solectrix.de> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
-
Bjørn Mork authored
commit 6a448868 upstream. A logic error made the wdm_find_device* functions return a bogus pointer into static data instead of the intended NULL no matching device was found. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Pratyush Anand authored
commit 0416e494 upstream. In case of ep0 out, if length is not aligned to maxpacket size then we use dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we have alreday done memcpy from dwc->ep0_bounce to request->buf, so we do not need to issue cache sync function. In fact, cache sync function will bring wrong data in request->buf from request->dma in this scenario. So, cache sync function must not be executed in case of ep0 bounced. Signed-off-by:
Pratyush Anand <pratyush.anand@st.com> Signed-off-by:
-
Éric Piel authored
commit dafc4f7b upstream. Commit b69cc672 added support for the E-861. After acquiring a C-867, I realised that every Physik Instrumente's device has a different PID. They are listed in the Windows device driver's .inf file. So here are all PIDs for the current (and probably future) USB devices from Physik Instrumente. Compiled, but only actually tested on the E-861 and C-867. Signed-off-by:
Éric Piel <piel@delmic.com> Signed-off-by:
-
Bjørn Mork authored
commit f08dea73 upstream. The Microchip vid:pid 04d8:000a is used for their CDC ACM demo firmware application. This is a device with a single function conforming to the CDC ACM specification and with the intention of demonstrating CDC ACM class firmware and driver interaction. The demo is used on a number of development boards, and may also be used unmodified by vendors using Microchip hardware. Some vendors have re-used this vid:pid for other types of firmware, emulating FTDI chips. Attempting to continue to support such devices without breaking class based applications that by matching on interface class/subclass/proto being ff/ff/00. I have no information about the actual device or interface descriptors, but this will at least make the proper CDC ACM devices work again. Anyone having details of the offending device's descriptors should update this entry with the details. Reported-by:
Florian Wöhrl <fw@woehrl.biz> Reported-by:
Xiaofan Chen <xiaofanc@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by:
-
Horst Schirmeier authored
commit 26a538b9 upstream. This adds the USB PID for the NZR SEM 16+ USB energy monitor device <http://www.nzr.de>. It works perfectly with the GPL software on <http://schou.dk/linux/sparometer/>. Signed-off-by:
Horst Schirmeier <horst@schirmeier.com> Signed-off-by:
-
Pavankumar Kondeti authored
commit 3d037774 upstream. There is a possibility of QH overlay region having reference to a stale qTD pointer during unlink. Consider an endpoint having two pending qTD before unlink process begins. The endpoint's QH queue looks like this. qTD1 --> qTD2 --> Dummy To unlink qTD2, QH is removed from asynchronous list and Asynchronous Advance Doorbell is programmed. The qTD1's next qTD pointer is set to qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell interrupt. If QH's current qTD pointer points to qTD1, transfer overlay region still have reference to qTD2. But qtD2 is just unlinked and freed. This may cause EHCI system error. Fix this by updating qTD next pointer in QH overlay region with the qTD next pointer of the current qTD. Signed-off-by:
Pavankumar Kondeti <pkondeti@codeaurora.org> Acked-by:
-
Weston Andros Adamson authored
commit 01913b49 upstream. If decode_getfh failed, nfs4_xdr_dec_open would return 0 since the last decode_* call must have succeeded. Signed-off-by:
Weston Andros Adamson <dros@netapp.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit 872ece86 upstream. Apparently, am-utils is still using the legacy binary mountdata interface, and is having trouble parsing /proc/mounts due to the 'port=' field being incorrectly set. The following patch should fix up the regression. Reported-by:
Marius Tolzmann <tolzmann@molgen.mpg.de> Signed-off-by:
-
Trond Myklebust authored
commit c3f52af3 upstream. When the NFS_COOKIEVERF helper macro was converted into a static inline function in commit 99fadcd7 (nfs: convert NFS_*(inode) helpers to static inline), we broke the initialisation of the readdir cookies, since that depended on doing a memset with an argument of 'sizeof(NFS_COOKIEVERF(inode))' which therefore changed from sizeof(be32 cookieverf[2]) to sizeof(be32 *). At this point, NFS_COOKIEVERF seems to be more of an obfuscation than a helper, so the best thing would be to just get rid of it. Also see: https://bugzilla.kernel.org/show_bug.cgi?id=46881Reported-by:
Andi Kleen <andi@firstfloor.org> Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
-
Gertjan van Wingerde authored
commit a396e100 upstream. We need to program the rfkill switch GPIO pin direction to input at device initialization time, not only when the interface is brought up. Doing this only when the interface is brought up could lead to rfkill detecting the switch is turned on erroneously and inability to create the interface and bringing it up. Reported-and-tested-by:
Andreas Messer <andi@bastelmap.de> Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
-
Gertjan van Wingerde authored
commit 6ced58a5 upstream. The register is 16 bits wide, not 32. Signed-off-by:
-
Gertjan van Wingerde authored
commit 177ef836 upstream. This is an RT3572 based device. Signed-off-by:
Maximilian Engelhardt <maxi@daemonizer.de> Signed-off-by:
-
