- 12 Mar, 2012 40 commits
-
-
Jan Beulich authored
commit 6b7f000e upstream. This function is called from enable_iommus(), which in turn is used from amd_iommu_resume(). Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sebastian Siewior authored
commit 4231d47e upstream. |kernel BUG at kernel/rtmutex.c:724! |[<c029599c>] (rt_spin_lock_slowlock+0x108/0x2bc) from [<c01c2330>] (defer_bh+0x1c/0xb4) |[<c01c2330>] (defer_bh+0x1c/0xb4) from [<c01c3afc>] (rx_complete+0x14c/0x194) |[<c01c3afc>] (rx_complete+0x14c/0x194) from [<c01cac88>] (usb_hcd_giveback_urb+0xa0/0xf0) |[<c01cac88>] (usb_hcd_giveback_urb+0xa0/0xf0) from [<c01e1ff4>] (musb_giveback+0x34/0x40) |[<c01e1ff4>] (musb_giveback+0x34/0x40) from [<c01e2b1c>] (musb_advance_schedule+0xb4/0x1c0) |[<c01e2b1c>] (musb_advance_schedule+0xb4/0x1c0) from [<c01e2ca8>] (musb_cleanup_urb.isra.9+0x80/0x8c) |[<c01e2ca8>] (musb_cleanup_urb.isra.9+0x80/0x8c) from [<c01e2ed0>] (musb_urb_dequeue+0xec/0x108) |[<c01e2ed0>] (musb_urb_dequeue+0xec/0x108) from [<c01cbb90>] (unlink1+0xbc/0xcc) |[<c01cbb90>] (unlink1+0xbc/0xcc) from [<c01cc2ec>] (usb_hcd_unlink_urb+0x54/0xa8) |[<c01cc2ec>] (usb_hcd_unlink_urb+0x54/0xa8) from [<c01c2a84>] (unlink_urbs.isra.17+0x2c/0x58) |[<c01c2a84>] (unlink_urbs.isra.17+0x2c/0x58) from [<c01c2b44>] (usbnet_terminate_urbs+0x94/0x10c) |[<c01c2b44>] (usbnet_terminate_urbs+0x94/0x10c) from [<c01c2d68>] (usbnet_stop+0x100/0x15c) |[<c01c2d68>] (usbnet_stop+0x100/0x15c) from [<c020f718>] (__dev_close_many+0x94/0xc8) defer_bh() takes the lock which is hold during unlink_urbs(). The safe walk suggest that the skb will be removed from the list and this is done by defer_bh() so it seems to be okay to drop the lock here. Reported-by:
AnÃbal Almeida Pinto <anibal.pinto@efacec.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marek Olšák authored
commit cf00790d upstream. Mesa may set it to 1, causing all primitives to be killed. v2: also update the r7xx code Signed-off-by:
Marek Olšák <maraeo@gmail.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Christian Lamparter authored
commit 9926a675 upstream. Nicolas Cavallari discovered that carl9170 has some serious problems delivering data to sleeping stations. It turns out that the driver was not honoring two important flags (IEEE80211_TX_CTL_POLL_RESPONSE and IEEE80211_TX_CTL_CLEAR_PS_FILT) which are set on frames that should be sent although the receiving station is still in powersave mode. Reported-by:
Nicolas Cavallari <Nicolas.Cavallari@lri.fr> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nicolas Cavallari authored
commit 992d5252 upstream. On Access Point mode, when transmitting a packet, if the destination station is in powersave mode, we abort transmitting the packet to the device queue, but we do not reclaim the allocated memory. Given enough packets, we can go in a state where there is no packet on the device queue, but we think the device has no memory left, so no packet gets transmitted, connections breaks and the AP stops working. This undo the allocation done in the TX path when the station is in power-save mode. Signed-off-by:
Nicolas Cavallari <cavallar@lri.fr> Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guenter Roeck authored
commit 7ad6307a upstream. A global delay parameter has the side effect of being overwritten with 0 if a single ZL2004 or ZL6105 is instantiated. If other chips supported by the same driver are in the system, this will result in access errors for those chips. To solve the problem, keep a per-instance copy of the delay parameter, and do not change the original parameter. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guenter Roeck authored
commit 1bd612a2 upstream. Also update IDT datasheet locations. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jean Delvare authored
commit 4de86126 upstream. These are fully compatible with Jedec JC 42.4 as far as I can see. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guenter Roeck authored
commit 7cb3c44f upstream. There are up to three POUT alarm attributes, not two, since cap_alarm was added. Reported-by:
Michele Petracca <mi.petracca@gmail.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akio Idehara authored
commit 99c90ab3 upstream. ALPS touchpad detection fails if some buttons of ALPS are pressed. The reason is that the "E6" query response byte is different from what is expected. This was tested on a Toshiba Portege R500. Signed-off-by:
Akio Idehara <zbe64533@gmail.com> Tested-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Hutchings authored
commit affc9a0d upstream. lirc_serial_probe() must fail if request_irq() returns an error, even if it isn't EBUSY or EINVAL, Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Hutchings authored
commit 1ff1d88e upstream. A resume function cannot remove the device it is resuming! Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Hutchings authored
commit c8e57e1b upstream. Failure to allocate the I/O region leaves the IRQ allocated. A later failure leaves them both allocated. Reported-by:
Torsten Crass <torsten.crass@eBiology.de> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Hutchings authored
commit 9105b8b2 upstream. Currently the module init function registers a platform_device and only then allocates its IRQ and I/O region. This allows allocation to race with the device's suspend() function. Instead, allocate resources in the platform driver's probe() function and free them in the remove() function. The module exit function removes the platform device before the character device that provides access to it. Change it to reverse the order of initialisation. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit 3f31ae12 upstream. xscale2 PMUs indicate overflow not via the PMU control register, but by a separate overflow FLAG register instead. This patch fixes the xscale2 PMU code to use this register to detect to overflow and ensures that we clear any pending overflow when disabling a counter. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit f6f5a30c upstream. The PMU IRQ handlers in perf assume that if a counter has overflowed then perf must be responsible. In the paranoid world of crazy hardware, this could be false, so check that we do have a valid event before attempting to dereference NULL in the interrupt path. Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit 99c1745b upstream. When disabling a counter on an ARMv7 PMU, we should also clear the overflow flag in case an overflow occurred whilst stopping the counter. This prevents a spurious overflow being picked up later and leading to either false accounting or a NULL dereference. Reported-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit 57273471 upstream. On ARM, the PMU does not stop counting after an overflow and therefore IRQ latency affects the new counter value read by the kernel. This is significant for non-sampling runs where it is possible for the new value to overtake the previous one, causing the delta to be out by up to max_period events. Commit a737823d ("ARM: 6835/1: perf: ensure overflows aren't missed due to IRQ latency") attempted to fix this problem by allowing interrupt handlers to pass an overflow flag to the event update function, causing the overflow calculation to assume that the counter passed through zero when going from prev to new. Unfortunately, this doesn't work when overflow occurs on the perf_task_tick path because we have the flag cleared and end up computing a large negative delta. This patch removes the overflow flag from armpmu_event_update and instead limits the sample_period to half of the max_period for non-sampling profiling runs. Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit efbc74ac upstream. Erratum #743622 affects all r2 variants of the Cortex-A9 processor, so ensure that the workaround is applied regardless of the revision. Reported-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rob Clark authored
commit ca888a79 upstream. The "OMAPDSS: HDMI: PHY burnout fix" commit switched the HDMI driver over to using a GPIO for plug detect. Unfortunately the ->detect() method was not also updated, causing HDMI to no longer work for the omapdrm driver (because it would actually check if a connection was detected before attempting to enable display). Signed-off-by:
Rob Clark <rob@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomi Valkeinen authored
commit c49d005b upstream. A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board if the HDMI PHY is kept powered on when the cable is not connected. This patch solves the problem by adding hot-plug-detection into the HDMI IP driver. This is not a real HPD support in the sense that nobody else than the IP driver gets to know about the HPD events, but is only meant to fix the HW bug. The strategy is simple: If the display device is turned off by the user, the PHY power is set to OFF. When the display device is turned on by the user, the PHY power is set either to LDOON or TXON, depending on whether the HDMI cable is connected. The reason to avoid PHY OFF when the display device is on, but the cable is disconnected, is that when the PHY is turned OFF, the HDMI IP is not "ticking" and thus the DISPC does not receive pixel clock from the HDMI IP. This would, for example, prevent any VSYNCs from happening, and would thus affect the users of omapdss. By using LDOON when the cable is disconnected we'll avoid the HW bug, but keep the HDMI working as usual from the user's point of view. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomi Valkeinen authored
commit aa74274b upstream. Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure this GPIO in the board files. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomi Valkeinen authored
commit 78a1ad8f upstream. The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured. This patch configures them as output pins. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomi Valkeinen authored
commit 7bb122d1 upstream. "hdmi_hpd" pin is muxed to INPUT and PULLUP, but the pin is not currently used, and in the future when it is used, the pin is used as a GPIO and is board specific, not an OMAP4 wide thing. So remove the muxing for now. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomi Valkeinen authored
commit 3932a32f upstream. The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in the board files, but CT_CP_HPD, which is used to enable/disable HPD functionality. This patch renames the GPIO. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomi Valkeinen authored
commit 575753e3 upstream. Instead of freeing the GPIOs individually, use gpio_free_array(). Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andrew Lunn authored
commit b0654037 upstream. Patchset "ARM: orion: Refactor the MPP code common in the orion platform" broke at least Orion5x based platforms. These platforms have pins configured as GPIO when the selector is not 0x0. However the common code assumes the selector is always 0x0 for a GPIO lines. It then ignores the GPIO bits in the MPP definitions, resulting in that Orion5x machines cannot correctly configure there GPIO lines. The Fix removes the assumption that the selector is always 0x0. In order that none GPIO configurations are correctly blocked, Kirkwood and mv78xx0 MPP definitions are corrected to only set the GPIO bits for GPIO configurations. This third version, which does not contain any whitespace changes, and is rebased on v3.3-rc2. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net>
-
Andrew Lunn authored
commit 72053353 upstream. The patch "ARM: orion: Consolidate USB platform setup code.", commit 4fcd3f37 broke USB on TS-7800 and other orion5x boards, because the wrong type of PHY was being passed to the EHCI driver in the platform data. Orion5x needs EHCI_PHY_ORION and all the others want EHCI_PHY_NA. Allow the mach- code to tell the generic plat-orion code which USB PHY enum to place into the platform data. Version 2: Rebase to v3.3-rc2. Reported-by:
Ambroz Bizjak <ambrop7@gmail.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
Ambroz Bizjak <ambrop7@gmail.com> Acked-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wu Fengguang authored
commit b3f33cbf upstream. SandyBridge should be using the same register addresses as IvyBridge. Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kenneth Graunke authored
commit d71de14d upstream. The BSpec Workarounds page states that bits 10 and 26 must be set to avoid 3D ring hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610Tested-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eugeni Dodonov authored
commit db099c8f upstream. This adds the workaround for WaCatErrorRejectionIssue which could result in a system hang. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610Tested-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eugeni Dodonov authored
commit e4e0c058 upstream. This adds two cache-related workarounds for Ivy Bridge which can lead to 3D ring hangs and corruptions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610Tested-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eugeni Dodonov authored
commit eae66b50 upstream. This is yet another workaround related to clock gating which we need on Ivy Bridge. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610Tested-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Larry Finger authored
commit 6cddafab upstream. The latest vendor (non-mac80211) driver of 9/22/2011 shows some new device IDs for rtl8192cu. In addition, some typos in the table are fixed and one duplicate is removed. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Keng-Yu Lin authored
commit 5a50a7c3 upstream. The models do not resume correctly without acpi_sleep=nonvs. Signed-off-by:
Keng-Yu Lin <kengyu@canonical.com> Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Cc: Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Fabio Baltieri authored
commit 31e0017e upstream. Enable use of the generic atomic64 implementation on AVR32 platforms. Without this the kernel fails to build as the architecture does not provide its version. Signed-off-by:
Fabio Baltieri <fabio.baltieri@gmail.com> Acked-by:
Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stanislaw Gruszka authored
commit 37b40adf upstream. We create "bsg" link if q->kobj.sd is not NULL, so remove it only when the same condition is true. Fixes: WARNING: at fs/sysfs/inode.c:323 sysfs_hash_and_remove+0x2b/0x77() sysfs: can not remove 'bsg', no directory Call Trace: [<c0429683>] warn_slowpath_common+0x6a/0x7f [<c0537a68>] ? sysfs_hash_and_remove+0x2b/0x77 [<c042970b>] warn_slowpath_fmt+0x2b/0x2f [<c0537a68>] sysfs_hash_and_remove+0x2b/0x77 [<c053969a>] sysfs_remove_link+0x20/0x23 [<c05d88f1>] bsg_unregister_queue+0x40/0x6d [<c0692263>] __scsi_remove_device+0x31/0x9d [<c069149f>] scsi_forget_host+0x41/0x52 [<c0689fa9>] scsi_remove_host+0x71/0xe0 [<f7de5945>] quiesce_and_remove_host+0x51/0x83 [usb_storage] [<f7de5a1e>] usb_stor_disconnect+0x18/0x22 [usb_storage] [<c06c29de>] usb_unbind_interface+0x4e/0x109 [<c067a80f>] __device_release_driver+0x6b/0xa6 [<c067a861>] device_release_driver+0x17/0x22 [<c067a46a>] bus_remove_device+0xd6/0xe6 [<c06785e2>] device_del+0xf2/0x137 [<c06c101f>] usb_disable_device+0x94/0x1a0 Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Javier Martin authored
commit 5ed80a75 upstream. According to i.MX27 Reference Manual (p 1593) TXBIT0 bit selects whether the most significant or the less significant part of the data word written to the FIFO is transmitted. As DSP_A is the same as DSP_B with a data offset of 1 bit, it doesn't make any sense to remove TXBIT0 bit here. Signed-off-by:
Javier Martin <javier.martin@vista-silicon.com> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mark Brown authored
commit 7679e42e upstream. Recent enhancements in the bias management means that we might not be in standby when the CODEC is idle and can have active widgets without being in full power mode but the shutdown functionality assumes these things. Add checks for the bias level at each stage so that we don't do transitions other than the ON->PREPARE->STANDBY->OFF ones that the drivers are expecting. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Florian Tobias Schandinat authored
commit e2920638 upstream. Even if the documentation calls this bit "Reserved" it has to be set to 0 for correct modesetting on IGA1. Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-