tiler:tiler-omap5.git
6 years agoInput: omap-keypad: dynamically handle register offsets
G, Manjunath Kondaiah [Mon, 10 Oct 2011 15:22:05 +0000 (20:52 +0530)]
Input: omap-keypad: dynamically handle register offsets

Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.

Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
6 years agoARM: OMAP5: PM: Set MPUSS-L4PER clock-domain static dependency.
Santosh Shilimkar [Wed, 1 Feb 2012 10:49:30 +0000 (16:19 +0530)]
ARM: OMAP5: PM: Set MPUSS-L4PER clock-domain static dependency.

With L4PER clock-domain put under hardware supervised control, GPIO module
wakeup is not working. Seems to be an issue with swakeup even with GIPO
module is kept under smart-idle wakeup. (SYSC = 0x1D)

Till issue gets root-caused, the recommendation is to set MPUSS static
dependency towards L4PER clock-domain to avoid issues.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
6 years agousb: host: xhci: fix compile warning
Felipe Balbi [Wed, 1 Feb 2012 09:54:04 +0000 (11:54 +0200)]
usb: host: xhci: fix compile warning

Fix the following compile warning:

drivers/usb/host/xhci-ring.c: In function 'handle_port_status':
drivers/usb/host/xhci-ring.c:1253:18: warning: 'hcd' may be used \
uninitialized in this function

Signed-off-by: Felipe Balbi <balbi@ti.com>
6 years agousb: gadget: zero: fix compile error
Felipe Balbi [Tue, 31 Jan 2012 08:47:07 +0000 (10:47 +0200)]
usb: gadget: zero: fix compile error

Commit 6535700 (usb/g_zero: don't access private
data in complete callback on error) broke compilation
of g_zero. Fix it.

Signed-off-by: Felipe Balbi <balbi@ti.com>
6 years agousb: dwc3: core: always set needs_fifo_resize flag
Felipe Balbi [Wed, 1 Feb 2012 07:41:50 +0000 (09:41 +0200)]
usb: dwc3: core: always set needs_fifo_resize flag

We don't have a working DT setup on internal trees
so we need to make sure it will work in the meantime.

Hardcoding the flag to 'true' is the easiest temporary
solution.

Signed-off-by: Felipe Balbi <balbi@ti.com>
6 years agousb/g_zero: don't access private data in complete callback on error
Sebastian Andrzej Siewior [Wed, 25 Jan 2012 10:55:51 +0000 (11:55 +0100)]
usb/g_zero: don't access private data in complete callback on error

This is the temp fix for g_zero.

The following scenario:
- use a third party tool
- issue SetConfiguration, start a transfer
- g_zero enqueues 4k reqs. Be rude and stop after a multiple of maxpacketsize
  but before the 4k
- Assume the UDC can handle 4k transfer in one go and will interrupt after the
  4k arrived or a short transfer. That the transfer is still "busy".
- now soft the disconnect the device.
- the UDC gets a SetConfiguration 0 and will disable all endpoints
- disabling an endpoint means cancles all pending transfers.

On DWC3 we issue a cancel transfer command and wait for the command/transfer to
complete. That means we return immediately from ->disable(). The _gadget_ has to
wait for the ->complete() callback. g_zero does not and the result is:

| dwc3 dwc3.0: ep0out: Transfer Complete
| dwc3 dwc3.0: Transfer Complete while ep0out in state 'Setup Phase'
| dwc3 dwc3.0: Inspecting Setup Bytes
| dwc3 dwc3.0: USB_REQ_SET_CONFIGURATION
| zero gadget: reset config
| dwc3 dwc3.0: ep1in: cmd 'End Transfer' params 00000000 00000000 00000000
| dwc3 dwc3.0: Command Complete --> 0

Issue the end transfer command to the udc.

| dwc3 dwc3.0: request dd7e5060 from ep1out completed 0/4096 ===> -108

This completes the one request which in our internal list and not yet
prepared on HW for transfers so we complete it right away.

| zero gadget: high speed config #0: unconfigured
| dwc3 dwc3.0: queueing request dd7e5360 to ep0out length 0, state 'Setup Phase'
| dwc3 dwc3.0: ep0in: Transfer Not Ready
| dwc3 dwc3.0: Transfer Not Ready while ep0in in state 'Setup Phase'
| dwc3 dwc3.0: Control Status
| dwc3 dwc3.0: ep0in: cmd 'Start Transfer' params 00000000 83887000 00000000
| dwc3 dwc3.0: Command Complete --> 0
| dwc3 dwc3.0: ep1in: Endpoint Command Complete
| dwc3 dwc3.0: incomplete IN transfer ep1in
| dwc3 dwc3.0: request dd7e5420 from ep1in completed 0/4096 ===> -104
This is the response to our "End Transfer" command.

| Unable to handle kernel NULL pointer dereference at virtual address 00000014
dereference of ep->driver_data which is NULL due to cleanup in disable by
source sink.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
6 years agommc: core: clarify how to use post_req in case of errors
Per Forlin [Mon, 29 Aug 2011 13:35:58 +0000 (15:35 +0200)]
mmc: core: clarify how to use post_req in case of errors

The err condition in post_req() is set to undo a call made to pre_req()
that hasn't been started yet.  The err condition is not set if an MMC
request returns an error.

Signed-off-by: Per Forlin <per.forlin@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
6 years agoomap5: sata: Enable sata for omap5 evm build
Keshava Munegowda [Mon, 23 Jan 2012 10:09:19 +0000 (15:39 +0530)]
omap5: sata: Enable sata for omap5 evm build

The AHCI platform driver and SCSI disk support
is enabled for omap5 evm build def config file.
Thus , sata device detection and usage support
exists during system boot.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
6 years agoomap5: sata: Invoke sata device initialization
Keshava Munegowda [Mon, 23 Jan 2012 10:07:09 +0000 (15:37 +0530)]
omap5: sata: Invoke sata device initialization

The sata device initialization is invoked from
the omap2_init_devices function.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
6 years agoomap5: sata: Adding sata device init file for compilation
Keshava Munegowda [Thu, 5 Jan 2012 12:28:17 +0000 (17:58 +0530)]
omap5: sata: Adding sata device init file for compilation

The sata.c is add for the compilation for omap5 build.
The sata.c file is conditionally compiled if the
ahci platform driver is selected.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
6 years agoomap5: sata: AHCI sata support for OMAP5 socs
Keshava Munegowda [Fri, 17 Jun 2011 11:12:25 +0000 (16:42 +0530)]
omap5: sata: AHCI sata support for OMAP5 socs

This patch builds the sata platform data by acessing
the sata hwmod data and ocp2scp3 from the hwmod data base
and initializes SATA controller as part of
AHCI platform driver initialization.
The OCP2SCP3 hwmod is retrieved and timing values are configured
as a part of omap_sata_init which is invoked by ahci_probe function
of the AHCI platform driver initialization. OCP2SCP3 soft reset
is performed after this as described by OMAP5 TRM.
The PLL configuration is performed to generate 1.5Ghz clock
to make SATA PHY functional.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
6 years agoARM: OMAP5: SATA: OCP2SCP3 hwmod update
Keshava Munegowda [Thu, 5 Jan 2012 09:19:06 +0000 (14:49 +0530)]
ARM: OMAP5: SATA: OCP2SCP3 hwmod update

The new hwmod strcucure named ocp2scp3 is created;
This hwmod is retrived and platform device is created
as part of ahci platform device.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
6 years agoarm: omap5: sata: hwmod update
Keshava Munegowda [Tue, 8 Nov 2011 11:42:49 +0000 (17:12 +0530)]
arm: omap5: sata: hwmod update

The sys config base address of sata conntroller is added to
hwmod of the sata.
The PLL base adress and sysconfig address of sata phy is added to
hwmod of the sata. this will be the temproray inclusion
once the seperate sata phy driver is aviable the pll and
sysconfig address should be removed.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
6 years agoarm: omap4: hsmmc: configure SDMMC1_DR0 properly
Balaji T K [Thu, 29 Sep 2011 14:32:28 +0000 (20:02 +0530)]
arm: omap4: hsmmc: configure SDMMC1_DR0 properly

Fix the typo, instead it should be SDMMC1
USBC1 is not related to MMC1 I/Os

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agoarm: omap4: hsmmc: Fix Pbias configuration on regulator OFF
Balaji T K [Thu, 29 Sep 2011 14:25:52 +0000 (19:55 +0530)]
arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF

MMC1 data line IO's are powered down in before set regulator function.
IO's should not be powered ON when regulator is OFF.
Keep the IO's in power pown mode after regulator OFF otherwise VMODE_ERROR
interrupt is generated due to mismatch in input (regulator)
voltage and MMC IO drive voltage.
Delete incorrect comments which are not applicable for OMAP4.

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com>
Reported-by: Viswanath Puttagunta <vishp@ti.com>
6 years agoarm: omap: hsmmc: enable context loss counter
Balaji T K [Mon, 30 Jan 2012 14:24:15 +0000 (19:54 +0530)]
arm: omap: hsmmc: enable context loss counter

enable context loss count API for omap5

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agommc: omap: balance regulator calls
Balaji T K [Fri, 20 Jan 2012 17:31:33 +0000 (18:31 +0100)]
mmc: omap: balance regulator calls

do not check the ret value to balance host->vcc_aux regulator calls
for eMMC incase regulator host->vcc errors

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agoarm: omap5evm: add ddr50 uhs capability to omap_hsmmc
Balaji T K [Tue, 23 Aug 2011 16:27:28 +0000 (21:57 +0530)]
arm: omap5evm: add ddr50 uhs capability to omap_hsmmc

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agommc: omap: UHS-I voltage switch
Balaji T K [Tue, 23 Aug 2011 16:27:29 +0000 (21:57 +0530)]
mmc: omap: UHS-I voltage switch

add support for voltage switch needed for UHS-I card
sdcard data io voltage is reduced from VDD to 1.8V for UHS-I card

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agoregulator: palmas: ldo9: remove bypass mode
Balaji T K [Fri, 20 Jan 2012 17:31:14 +0000 (18:31 +0100)]
regulator: palmas: ldo9: remove bypass mode

ldo9 powers sdcard_vdds of OMAP5
remove bypass mode in ldo9 to configure it to 1.8 or 3V
for SD UHS-I cards.
while at it correct palmas i2c read/write api for LDO

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agommc: omap5: set debounce time for sd card detect gpio
Balaji T K [Fri, 20 Jan 2012 17:31:08 +0000 (18:31 +0100)]
mmc: omap5: set debounce time for sd card detect gpio

set card detect debounce time to 50mS

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agommc: omap: add cmd23 support
Balaji T K [Tue, 23 Aug 2011 16:27:28 +0000 (21:57 +0530)]
mmc: omap: add cmd23 support

Add support for set block count, close ended transfer

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agoarm: omap: hsmmc: sparse warning fix
Sourav Poddar [Tue, 26 Jul 2011 08:50:00 +0000 (14:20 +0530)]
arm: omap: hsmmc: sparse warning fix

Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
6 years agommc: omap: hsmmc: Enable Auto CMD12
Balaji T K [Tue, 23 Aug 2011 16:27:27 +0000 (21:57 +0530)]
mmc: omap: hsmmc: Enable Auto CMD12

Enable Auto-CMD12 for multi block read/write on HSMMC

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agoarm: omap5evm: hsmmc: add DDR support
Balaji T K [Mon, 16 Jan 2012 16:00:00 +0000 (17:00 +0100)]
arm: omap5evm: hsmmc: add DDR support

Enable DDR support for eMMC/MMC2

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agommc: Fix bug to enable DDR on MMC
Viswanath Puttagunta [Mon, 5 Dec 2011 13:22:23 +0000 (18:52 +0530)]
mmc: Fix bug to enable DDR on MMC

MMC_CAP_UHS_DDR50 is an SD card feature and not
MMC feature. We don't have to check for this flag
to enable DDR on MMC. Checking for MMC_CAP_1.8V_DDR
is sufficient.

Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
6 years agommc: omap: add DDR support to omap_hsmmc
Balaji T K [Mon, 5 Dec 2011 13:22:21 +0000 (18:52 +0530)]
mmc: omap: add DDR support to omap_hsmmc

Add DDR support for omap_hsmmc

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agoarm: omap5evm: mmc: enable hsmmc in evm defconfig
Balaji T K [Wed, 4 Jan 2012 08:55:46 +0000 (09:55 +0100)]
arm: omap5evm: mmc: enable hsmmc in evm defconfig

add fixed regulator support for SD/eMMC in omap5evm.

CONFIG_MMC is enabled by below commit
commit b56ea259a14ac996912ae5ecf8a3df05dea69879
Author: Govindraj.R <govindraj.raja@ti.com>
Date:   Tue Jan 31 19:32:33 2012 +0530

    Add usb ehci, nfs filesystem smsc95xx and mass storage support.

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agommc: sd: Handle SD3.0 cards not supporting UHS-I bus speed mode
Subhash Jadavani [Tue, 3 Jan 2012 16:19:25 +0000 (17:19 +0100)]
mmc: sd: Handle SD3.0 cards not supporting UHS-I bus speed mode

Here is Essential conditions to indicate Version 3.00 Card
(SD_SPEC=2 and SD_SPEC3=1) :
(1) The card shall support CMD6
(2) The card shall support CMD8
(3) The card shall support CMD42
(4) User area capacity shall be up to 2GB (SDSC) or 32GB (SDHC)
    User area capacity shall be more than or equal to 32GB and
    up to 2TB (SDXC)
(5) Speed Class shall be supported (SDHC or SDXC)

So even if SD card doesn't support any of the newly defined
UHS-I bus speed mode, it can advertise itself as SD3.0 cards
as long as it supports all the essential conditions of
SD3.0 cards. Given this, these type of cards should atleast
run in High Speed mode @50MHZ if it supports HS.

But current initialization sequence for SD3.0 cards is
such that these non-UHS-I SD3.0 cards runs in Default
Speed mode @25MHz.

This patch makes sure that these non-UHS-I SD3.0 cards run
in High Speed Mode @50MHz.

Tested this patch with SanDisk Extreme SDHC 8GB Class 10 card.

Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
6 years agommc: omap: remove clock rate hard coding
Balaji T K [Thu, 29 Dec 2011 15:12:06 +0000 (20:42 +0530)]
mmc: omap: remove clock rate hard coding

MMC master clock rate can vary for each instance of the MMC controller
on the device. Use clk_get_rate instead to get the value

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agommc: omap: Add HSMMC support in omap5 evm boardfile
Sourav Poddar [Wed, 25 May 2011 09:29:24 +0000 (14:59 +0530)]
mmc: omap: Add HSMMC support in omap5 evm boardfile

add support for eMMC and SD to omap5 evm board
enable hsmmc for OMAP5

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
6 years agommc: omap_hsmmc: DMA unmap only once in case of MMC error
Per Forlin [Mon, 7 Nov 2011 16:25:11 +0000 (21:55 +0530)]
mmc: omap_hsmmc: DMA unmap only once in case of MMC error

Reported by Russell King:
mmcblk0: error -84 transferring data, sector 149201, nr 64,
cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read

WARNING: at lib/dma-debug.c:811 check_unmap
omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x0000000080933000] [size=20480 bytes]

In case of an error dma_unmap() is issued in omap_hsmmc_dma_cleanup()
and then again in omap_hsmmc_post_req(). Resolve this by clearing the
host_cookie to indicate there is no DMA mapped memory to unmap.

Signed-off-by: Per Forlin <per.forlin@linaro.org>
Tested-by: Balaji T K <balajitk@ti.com>
6 years agommc: omap_hsmmc: ensure pbias configuration is always done
Adrian Hunter [Fri, 6 May 2011 09:14:10 +0000 (12:14 +0300)]
mmc: omap_hsmmc: ensure pbias configuration is always done

Go through the driver's set_power() functions rather than
calling regulator_enable/disable() directly because otherwise
pbias configuration for MMC1 is not done.

Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
6 years agoi2c-omap: Keep I2C module enabled on NACK
Balaji T K [Thu, 29 Dec 2011 15:11:58 +0000 (20:41 +0530)]
i2c-omap: Keep I2C module enabled on NACK

Retain other bit fields while configuring STOP condition in
configuration register.
Current code writes STOP condition to configuration register
and clears other bit fields that results in disabling the
controller

Tested on OMAP4, OMAP3 and OMAP2 by i2c read/write access to non existing
device, Next i2c read/write to nonexisting / existing device should not
fail with "i2c_omap i2c_omap.1: controller timed out"

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agoarm: omap5evm: vmmc: max voltage change and binding
Balaji T K [Thu, 29 Dec 2011 15:11:55 +0000 (20:41 +0530)]
arm: omap5evm: vmmc: max voltage change and binding

ldo9 supplies VDDS_SDCARD1 - pbias cell of MMC1
create binding between ldo9 - vmmc regulator and hsmmc driver
SD card i/o lines can operate 3V, update max_uV accordingly.

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agoarm: omap5evm: add fixed regulator support for SDCARD/MMC1
Balaji T K [Thu, 29 Dec 2011 15:11:50 +0000 (20:41 +0530)]
arm: omap5evm: add fixed regulator support for SDCARD/MMC1

In omap5evm board, sdcard and eMMC are supplied by same 3V fixed regulator
Add support for vmmc fixed regulator.

Signed-off-by: Balaji T K <balajitk@ti.com>
6 years agotty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds
Paul Walmsley [Thu, 26 Jan 2012 02:50:56 +0000 (19:50 -0700)]
tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds

The receive FIFO wakeup latency estimate in the omap-serial driver is
three orders of magnitude too small.  This effectively prevents the
MPU from going to a low-power state when CONFIG_CPU_IDLE=y.  This is a
major power management regression and masks some other FIFO-related
bugs in the driver.

Fix by correcting the most egregious problem in the RX wakeup latency
estimate.  There are several other flaws in the estimator; these will
be fixed by a separate patch series intended for 3.4.

The difference in low-power states with this patch can be observed via
debugfs in pm_debug/count.

This estimate does not have any effect when CONFIG_CPU_IDLE=n.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
6 years agotty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode
Paul Walmsley [Thu, 26 Jan 2012 02:50:36 +0000 (19:50 -0700)]
tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode

In the (default) PIO mode, use a one-byte RX FIFO threshold.  The OMAP
UART IP blocks do not appear to be capable of waking the system under
an RX timeout condition.  Since the previous RX FIFO threshold was 16
bytes, this meant that omap-serial.c did not become aware of any
received data until all those bytes arrived or until another UART
interrupt occurred.  This made the serial console and presumably other
serial applications (GPS, serial Bluetooth) unusable or extremely
slow.  A 1-byte RX FIFO threshold also allows the MPU to enter a
low-power consumption state while waiting for the FIFO to fill.

This can be verified using the serial console by comparing the
behavior when "0123456789abcde" is pasted in from another window, with
the behavior when "0123456789abcdef" is pasted in.  Since the former
string is less than sixteen bytes long, the string is not echoed for
some time, while the latter string is echoed immediately.

DMA operation is unaffected by this patch.

Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for some
additional information on the standard behavior of the RX timeout
event, which was used to improve this commit description.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
6 years agoOMAP5: UART: Add the extra ports in OMAP5
Shubhrajyoti D [Wed, 9 Nov 2011 08:08:11 +0000 (13:38 +0530)]
OMAP5: UART: Add the extra ports in OMAP5

Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
6 years agoOAMP2+: UART: Make module wakeup configurable from board file
Govindraj.R [Fri, 16 Dec 2011 09:07:57 +0000 (14:37 +0530)]
OAMP2+: UART: Make module wakeup configurable from board file

Different boards use different uart lines to connect client devices.
Based on lines used module level wakeup configuration can be set
or enabled from board file, same is context restored if context lost
while waking up from low power state. By default all wakeups are enabled
as done prior to this patch. However one can configure wakeups based on
the board requirements.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agotty: serial: omap-serial: fix software flow control
Vikram Pandita [Mon, 5 Dec 2011 06:36:42 +0000 (12:06 +0530)]
tty: serial: omap-serial: fix software flow control

Software flow control register bits were not defined correctly.

Also clarify the IXON and IXOFF logic to reflect what userspace wants.

Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agotty: serial: omap-serial: clear auto rts cts bits
Vikram Pandita [Mon, 5 Dec 2011 06:27:42 +0000 (11:57 +0530)]
tty: serial: omap-serial: clear auto rts cts bits

Clear the auto-rts/cts bits if HW flow control is not chosen.
There are cases wherein a UART is dynamically switched between
hw and sw flow control.

Make sure each setup of uart is clean - not retaining previous
flow control settings.

Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Fix compilation/sparse warnings
Govindraj.R [Wed, 14 Dec 2011 15:54:11 +0000 (21:24 +0530)]
OMAP2+: UART: Fix compilation/sparse warnings

Fixes below compilation warning.

drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq':
drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized]

Fix below sparse warning.

drivers/tty/serial/omap-serial.c:392:52: warning: incorrect type in argument 2 (different signedness)
drivers/tty/serial/omap-serial.c:392:52:    expected int *status
drivers/tty/serial/omap-serial.c:392:52:    got unsigned int *<noident>

Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
Govindraj.R [Wed, 9 Nov 2011 12:11:21 +0000 (17:41 +0530)]
OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos

Omap_uart_can_sleep function blocks system wide low power state until
uart is active remove this func and add qos requests to prevent
MPU from transitioning.

Keep qos request to default value which will allow MPU to transition
and while uart baud rate is available calculate the latency value
from the baudrate and use the same to hold constraint while uart clocks
are enabled, and if uart is auto-idled the constraint is updated with
default constraint value allowing MPU to transition.

Qos requests are blocking notifier calls so put these requests to
work queue, also the driver uses irq_safe version of runtime API's
and callbacks can be called in interrupt disabled context.
So to avoid warn on slow path warning while using qos update
API's from runtime callbacks use the qos_work_queue.

During bootup the runtime_resume call backs might not be called and runtime
callback gets called only after uart is idled by setting the autosuspend
timeout. So qos_request from runtime resume callback might not activated during
boot if uart baudrate is calculated during bootup for console uart, so schedule
the qos_work queue once we calc_latency while configuring the uart port.

Flush and complete any pending qos jobs in work queue while suspending.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Do not gate uart clocks if used for debug_prints
Govindraj.R [Wed, 21 Sep 2011 11:24:12 +0000 (16:54 +0530)]
OMAP2+: UART: Do not gate uart clocks if used for debug_prints

If OMAP UART is used as console uart and debug is enabled,
avoid gating of uart clocks to print all debug prints.

If uart clocks are gated then the debug prints from omap_device
framework or hwmod framework can cause uart to enter recursive
pm_runtime calls, which can cause a deadlock over power lock usage.

For example: Say, uart clocks are cut and we get a print from
omap_device_disable stating disabling uart clocks. This print
calls omap_uart driver console_write which will call runtime API
get_sync which means we enter from runtime API put context to
runtime API get context.

--> runtime put (take power lock)
    --> print disabling uart clocks
        --> call uart console write
            --> call get_sync (try to take power lock)

Also any clock enable API call from uart driver should not call any uart
operation until clocks are enabled back. Like get_sync having debug print
calling uart console write even before clocks are enabled.

So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used
in debug mode. If so, do not set device_may_wakeup. This will prevent
pm_runtime_enable in uart driver and will avoid uart clock gating.
Debug is enabled either by adding debug word in bootarg or by setting
loglevel=10

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecase
Govindraj.R [Tue, 18 Oct 2011 11:39:10 +0000 (17:09 +0530)]
OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecase

If no_console_suspend is used we have prevent uart idling during suspend
to provide debug prints.

Power domain hooks can idle uarts if left enabled during system wide suspend
so re-use the omap_device_disable_idle_on_suspend API's to ensure console_uart
is not idled during suspend.

omap_device_disable_idle_on_suspend API was used on all uarts since the uart
driver was not runtime adapted, now with runtime adaptation we can re-use this
API only for no_console_suspend use cases.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Avoid console uart idling during bootup
Govindraj.R [Mon, 7 Nov 2011 13:35:44 +0000 (19:05 +0530)]
OMAP2+: UART: Avoid console uart idling during bootup

Omap-uart can be used as console uart to print early boot messages using
earlyprintk so for console uart prevent hwmod reset or idling during bootup.

Identify omap-uart used as console and avoid idling rather than preventing
all omap-uarts from idling during bootup. Update the comments for the same.

Remove the uart idling and enabling back using hwmod_idle/omap_device_enable
for all uarts that where left enabled from boot to set the hwmod framework
state machine right. This need not be taken care any more serial.c rather
can be handled within the hwmod framework.
Reference: http://www.spinics.net/lists/linux-omap/msg60300.html

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: remove temporary variable used to count uart instance
Govindraj.R [Tue, 18 Oct 2011 11:02:14 +0000 (16:32 +0530)]
OMAP2+: UART: remove temporary variable used to count uart instance

Reuse the num_uarts variable itself to count number of uarts.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART
Jon Hunter [Wed, 9 Nov 2011 12:04:49 +0000 (17:34 +0530)]
OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART

When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
The secound timeout, RX_TIMEOUT, is a timeout after which the
DMA will be stopped if no more data is received. To make this
clearer, rename rx_timeout as rx_poll_rate and rename the
function serial_omap_rx_timeout() to serial_omap_rxdma_poll().

The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is
used to indicate when the DMA for UART can be stopped if no more
data is received. The value is a global definition that is applied
to all instances of the UART.

Each UART may be used for a different purpose and so the timeout
required may differ. Make this value configurable for each UART so
that this value can be optimised for power savings.

Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Allow UART parameters to be configured from board file.
Deepak K [Wed, 9 Nov 2011 12:03:38 +0000 (17:33 +0530)]
OMAP2+: UART: Allow UART parameters to be configured from board file.

The following UART parameters are defined within the UART driver:

1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The auto suspend delay that will be passed for pm_runtime_autosuspend
    where uart will be disabled after timeout

Different UARTs may be used for different purpose such as the console,
for interfacing bluetooth chip, for interfacing to a modem chip, etc.
Therefore, it is necessary to be able to customize the above settings
for a given board on a per UART basis.

This change allows these parameters to be configured from the board file
and allows the parameters to be configured for each UART independently.

If a board does not define its own custom parameters for the UARTs, then
use the default parameters in the structure "omap_serial_default_info".
The default parameters are defined to be the same as the current settings
in the UART driver to avoid breaking the UART for any cuurnelty supported
boards. By default, make all boards use the default UART parameters.

Signed-off-by: Deepak K <deepak.k@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Remove old and unused clocks handling funcs
Govindraj.R [Mon, 7 Nov 2011 13:31:24 +0000 (19:01 +0530)]
OMAP2+: UART: Remove old and unused clocks handling funcs

With runtime adaptation done remove clock_enable/disbale API's

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Add wakeup mechanism for omap-uarts
Govindraj.R [Thu, 13 Oct 2011 08:41:09 +0000 (14:11 +0530)]
OMAP2+: UART: Add wakeup mechanism for omap-uarts

From the runtime callbacks enable hwmod wakeups for uart which will
internally enable io-pad wakeups for uarts if they have rx-pad pins
set as wakeup capabale.

Use the io-ring wakeup mechanism after uart clock gating and leave
the PM_WKST set for uart to default reset values cleanup the
code in serial.c which was handling PM_WKST reg.
Irq_chaing(PRM_DRIVER) is used to wakeup uart after uart clocks are gated
using pad wakeup mechanism.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Move errata handling from serial.c to omap-serial
Govindraj.R [Mon, 7 Nov 2011 13:30:33 +0000 (19:00 +0530)]
OMAP2+: UART: Move errata handling from serial.c to omap-serial

Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.

Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as from on errata will be handled in driver file itself.
Corrected errata id from chapter reference 2.15 to errata id i291.

Removed errata and dma_enabled fields from omap_uart_state struct
as they are no more needed with errata handling done within omap-serial.

Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Get context loss count to context restore
Govindraj.R [Tue, 11 Oct 2011 13:41:27 +0000 (19:11 +0530)]
OMAP2+: UART: Get context loss count to context restore

Avoid unconditional context restore every time we gate uart
clocks. Check whether context loss happened based on which
we can context restore uart regs from uart_port structure.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Remove uart reset function.
Govindraj.R [Mon, 7 Nov 2011 13:28:55 +0000 (18:58 +0530)]
OMAP2+: UART: Remove uart reset function.

Remove the uart reset function which is configuring the
TX empty irq which can now be handled within omap-serial driver.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Ensure all reg values configured are available from port structure
Govindraj.R [Mon, 7 Nov 2011 13:27:03 +0000 (18:57 +0530)]
OMAP2+: UART: Ensure all reg values configured are available from port structure

Add missing uart regs to uart_port structure which can be used in
context restore. Store dll, dlh, mdr1, scr, efr, lcr, mcr reg values
into uart_port structure while configuring individual port in termios
function.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Remove context_save and move context restore to driver
Govindraj.R [Mon, 7 Nov 2011 13:26:12 +0000 (18:56 +0530)]
OMAP2+: UART: Remove context_save and move context restore to driver

Remove context save function from serial.c and move context restore
function to omap-serial. Remove all regs stored in omap_uart_state
for contex_save/restore, reg read write funcs used in context_save/restore,
io_addresses populated for read/write funcs.

Clock gating mechanism was done in serial.c and had no info on uart state
thus we needed context save and restore in serial.c
With runtime conversion and clock gating done within uart driver
context restore can be done from regs value available from uart_omap_port
structure.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Add runtime pm support for omap-serial driver
Govindraj.R [Mon, 28 Feb 2011 12:42:23 +0000 (18:12 +0530)]
OMAP2+: UART: Add runtime pm support for omap-serial driver

Adapts omap-serial driver to use pm_runtime API's.
Use runtime runtime API's to handle uart clocks and obtain
device_usage statics. Set runtime API's usage to irq_safe so that
we can use get_sync from irq context. Auto-suspend for port specific
activities and put for reg access. Moving suspend/resume hooks
to dev_pm_ops structure and bind with config_suspend to avoid any
compilation warning if config_suspend is disabled.

By default uart autosuspend delay is set to -1 to avoid character loss
if uart's are autoidled and woken up on rx pin.

After boot up UART's can be autoidled by setting autosuspend delay from sysfs.

echo 3000 > /sys/devices/platform/omap/omap_uart.X/power/autosuspend_delay_ms
X=0,1,2,3 for UART1/2/3/4. Number of uarts available may vary across omap_soc.

Also if uart is not wakeup capable we can prevent runtime autosuspend by
forbiding runtime.

Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Remove mapbase/membase fields from pdata.
Govindraj.R [Tue, 11 Oct 2011 09:25:41 +0000 (14:55 +0530)]
OMAP2+: UART: Remove mapbase/membase fields from pdata.

The mapbase (start_address), membase(io_remap cookie) part of
pdata struct omap_uart_port_info are removed as this should be
derived within driver.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Add default mux for all uarts.
Govindraj.R [Mon, 7 Nov 2011 13:25:05 +0000 (18:55 +0530)]
OMAP2+: UART: Add default mux for all uarts.

Padconf wakeup is used to wakeup uart after uart fclks/iclks are gated.
Rx-Pad wakeup was done by writing to rx-pad offset value populated in
serial.c idle_init. Remove the direct reading and writing into rx pad.
Remove the padconf field part of omap_uart_state struct and pad offsets
populated.

Now with mux framework support we can use mux_utilities
along with hmwod framework to handle io-pad configuration and enable rx-pad
wake-up mechanism.

To avoid breaking any board support add default mux data for all uart's
if mux info is not passed from board file.
With the default pads populated in serial.c wakeup capability for
rx pads is set, this can be used to enable uart_rx io-pad wakeup from
hwmod framework. The pad values in 3430sdp/4430sdp/omap4panda board file
are same as the default pad values populated in serial.c. Remove pad values
from 3430sdp/4430sdp/omap4panda board file and use the default pads
from serial.c file.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: Cleanup part of clock gating mechanism for uart
Govindraj.R [Tue, 13 Sep 2011 08:31:01 +0000 (14:01 +0530)]
OMAP2+: UART: Cleanup part of clock gating mechanism for uart

Currently we use a shared irq handler to identify uart activity and then
trigger a timer. By default the timeout value is zero and can be set or
modified from sysfs. If there was no uart activity for the period set
through sysfs, the timer will expire and call timer handler this will
set a flag can_sleep using which decision to gate uart clocks can be taken.

Since the clock gating mechanism is outside the uart driver, we currently
use this mechanism. In preparation to runtime implementation for omap-serial
driver we can cleanup this mechanism and use runtime API's to gate uart clocks.

Removes the following:
* timer related info from local uart_state struct
* the code used to set timeout value from sysfs.
* irqflags used to set shared irq handler.
* un-used function omap_uart_check_wakeup.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: cleanup 8250 console driver support
Govindraj.R [Tue, 13 Sep 2011 08:02:32 +0000 (13:32 +0530)]
OMAP2+: UART: cleanup 8250 console driver support

We had been using traditional 8250 driver as uart console driver
prior to omap-serial driver. Since we have omap-serial driver
in mainline kernel for some time now it has been used as default
uart console driver on omap2+ platforms. Remove 8250 support for
omap-uarts.

Serial_in and serial_out override for 8250 serial driver is also
removed. Empty fifo read fix is already taken care with omap-serial
driver with data ready bit check from LSR reg before reading RX fifo.
Also waiting for THRE(transmit hold reg empty) is done with wait_for_xmitr
in omap-serial driver.

Serial_in/out overrides are not neceesary for omap-serial driver
and things that are taken with omap-serial driver are removed here.

Remove headers that were necessary to support 8250 support
and remove all config bindings done to keep 8250 backward compatibility
while adding omap-serial driver. Remove omap_uart_reset needed for
8250 autoconf.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP2+: UART: cleanup + remove uart pm specific API
Govindraj.R [Wed, 9 Nov 2011 11:52:30 +0000 (17:22 +0530)]
OMAP2+: UART: cleanup + remove uart pm specific API

In preparation to UART runtime conversion remove uart specific calls
from pm24xx/34xx files and their definition from serial.c
These func calls will no more be used with upcoming uart runtime design.

1.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks.
2.) omap_uart_enable_irqs :- Used to enable/disable uart irq's in suspend
    path from PM code, this is removed as same is handled by
    uart_suspend_port/uart_resume_port in omap-serial driver which will
    do an port_shutdown on suspend freeing irq and port_startup on resume
    enabling back irq.
3.) Remove prepare_idle/resume_idle calls used to gate uart clocks.
    UART clocks can be gated within driver using runtime funcs
    and be woken up using irq_chaining from omap_prm driver.
4.) Remove console_locking from idle path as clock gating is done withing
    driver itself with runtime API. Remove is_suspending check used to acquire
    console_lock.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoAdd usb ehci, nfs filesystem smsc95xx and mass storage support.
Govindraj.R [Tue, 31 Jan 2012 14:02:33 +0000 (19:32 +0530)]
Add usb ehci, nfs filesystem smsc95xx and mass storage support.

Smsc95xx driver is needed by Ethernet controller connected to
usb port3 and smsc hub is connected to usb port2 hub has two downstream
ports so enable mass storage support( note: mass storage require
scsi and blk_dev upport which enabled).

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP5: USB: Add port 3 hsic mode check.
Govindraj.R [Sat, 14 Jan 2012 09:57:45 +0000 (15:27 +0530)]
OMAP5: USB: Add port 3 hsic mode check.

Port3 on omap5 can be configured in hsic mode
and there are 3 tll ports for omap5 tll needs
to be configured for hsic mode.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP5: Clock: fix utmi fclk
Govindraj.R [Thu, 12 Jan 2012 07:23:36 +0000 (12:53 +0530)]
OMAP5: Clock: fix utmi fclk

for omap5 there no utmi fclk3 remove it,
there is only opt p3 clk.

make tll rev >= omap2_rev so looks like rev
has changed for omap5

6 years agoOMAP5: USB: Enable EHCI support for usb
Govindraj.R [Tue, 31 Jan 2012 12:26:05 +0000 (17:56 +0530)]
OMAP5: USB: Enable EHCI support for usb

OMAP5 soc supports usb ehci. Enable the same for
omap5 in kconfig.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP5: EHCI: Add ehci port support for omap5 evm
Govindraj.R [Tue, 31 Jan 2012 12:23:11 +0000 (17:53 +0530)]
OMAP5: EHCI: Add ehci port support for omap5 evm

On omap5 board port2 is connected to smsc4640 hub having two
downstream ports and port3 is connected to SMSC LAN9730 controller
so add the port2/3 support and both controllers need gpio reset,
update uhh_pdata with appropriate gpio numbers. Currently ehci
module limits gpio reset only to two ports hence add port3 gpio reset
which will be used in omap5 board by ethernet chip.
Both port3 and port2 are configured in hsic mode as per external
smsc controllers requirements.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoomap: usb: add HSIC support for EHCI
Govindraj.R [Mon, 2 Jan 2012 09:05:53 +0000 (14:35 +0530)]
omap: usb: add HSIC support for EHCI

Configure the usb host controller in OMAP to support HSIC mode.
HSIC DFE needs TLL module so enable port clocks for HSIC MODE
and Also configure TLL module for HSIC mode functionality and
enable TLL Clocks for HSIC mode functionality.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP5: usbhs: clock configuration for HSIC
Kishon Vijay Abraham I [Tue, 25 Oct 2011 09:23:52 +0000 (14:53 +0530)]
OMAP5: usbhs: clock configuration for HSIC

Adds clock configuration for all the ports supported by usbhs in
HSIC mode. This includes clock configuration for port3 added in
omap5 which supports only hsic mode.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoOMAP5: usbhs: Add mux initialization for ehci to support HSIC
Kishon Vijay Abraham I [Wed, 9 Nov 2011 08:58:31 +0000 (14:28 +0530)]
OMAP5: usbhs: Add mux initialization for ehci to support HSIC

Adds mux initialization to support hsic mode in EHCI. This includes
mux initialization for port3 that has been added in omap5.

Rename setup_ehci/ohci_io_mux funcs to setup_34xx_ehci/ohci_io_mux
As these are used only for OMAP3 socs.

Rename setup_4430ehci/ohci_io_mux to setup_ehci_io_mux as this will
be used for both omap4 and omap5 socs.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agousb: ehci: remove the 1st wmb in qh_append_tds
Ming Lei [Mon, 5 Sep 2011 13:05:58 +0000 (21:05 +0800)]
usb: ehci: remove the 1st wmb in qh_append_tds

According to ehci spec 4.10.2, Advance Queue

If the fetched qTD has its Active bit set to a zero, the
host controller aborts the queue advance and follows the
queue head's horizontal pointer to the next schedule data
structure.

the 'qtd' will be linked into qh hardware queue after the line
below

*dummy = *qtd;

is executed and observed by EHCI HC, but EHCI HC won't have chance to
fetch the qtd descriptor pointed by 'qtd' in qh_append_tds until the
line below

dummy->hw_token = token; #set Active bit here

is executed by CPU and observed by EHCI HC.

There is already one 'wmb' to order writing to 'dummy'/'qtd' descriptors
and writing 'token' to 'dummy' descriptor(set Active bit), so the 1st
wmb is not needed and can be removed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agousb: ehci: only prepare zero packet for out transfer if required
Ming Lei [Mon, 5 Sep 2011 13:05:56 +0000 (21:05 +0800)]
usb: ehci: only prepare zero packet for out transfer if required

Obviously, ZLP is only required for transfer of OUT direction,
so just take same policy with UHCI for ZLP packet.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agousb: ehci: remove wmb in qh_update
Ming Lei [Mon, 5 Sep 2011 13:05:55 +0000 (21:05 +0800)]
usb: ehci: remove wmb in qh_update

qh_refresh is always called when the qh is idle and has not been
linked into hardware queue, so EHCI will not access overlay of
the qh at this time. Just before linking qh into hardware queue, there
has already one wmb to order writing qh descriptor and writing dma
address of the qh into hardware queue, so HC can always see
up-to-date qh descriptor once the qh is fetched with its dma address
by EHCI.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agoARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Keshava Munegowda [Thu, 24 Nov 2011 08:37:46 +0000 (14:07 +0530)]
ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

It is observed that the echi ports of 3430 sdp board
are not working due to the random timing of programming
the associated GPIOs of the ULPI PHYs of the EHCI for reset.
If the PHYs are reset at during usbhs core driver, host ports will
not work because EHCI driver is loaded after the resetting PHYs.
The PHYs should be in reset state while initializing the EHCI
controller.
The code which does the GPIO pins associated with the PHYs
are programmed to reset is moved from the USB host core driver
to EHCI driver.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoARM: OMAP: change the USB TLL function and interface clocks device name
Keshava Munegowda [Tue, 22 Nov 2011 06:28:55 +0000 (11:58 +0530)]
ARM: OMAP: change the USB TLL function and interface clocks device name

The platfrom device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
6 years agoARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
Keshava Munegowda [Mon, 21 Nov 2011 16:05:24 +0000 (21:35 +0530)]
ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver

The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
6 years agoARM: OMAP: USB: Remove TLL specific code
Keshava Munegowda [Mon, 21 Nov 2011 14:29:40 +0000 (19:59 +0530)]
ARM: OMAP: USB: Remove TLL specific code

The TLL specific code such as channels clocks enable/disable,
initialization functions are removed fromt the USBHS core
driver.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoARM: OMAP: USB: Build the USB HOST TLL omap device
Keshava Munegowda [Mon, 21 Nov 2011 14:06:06 +0000 (19:36 +0530)]
ARM: OMAP: USB: Build the USB HOST TLL omap device

The hwmod of the usb tll is retrived and omap device build is
performed to created the platform device for the usb tll component.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
6 years agoARM: OMAP: USB: HOST TLL platform driver
Keshava Munegowda [Mon, 21 Nov 2011 13:28:04 +0000 (18:58 +0530)]
ARM: OMAP: USB: HOST TLL platform driver

The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the exported APIS of the USB TLL
platform driver.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
6 years agoMFD: OMAP: USB: Runtime PM support
Keshava Munegowda [Tue, 11 Oct 2011 07:53:29 +0000 (13:23 +0530)]
MFD: OMAP: USB: Runtime PM support

The usbhs core driver does not enable/disable the interface and
functional clocks directly, These clocks are handled by runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the optional clocks and port clocks are handled by
the usbhs core.

Dependency:
This patch is dependent on this series:
[PATCH 0/5 v13 or latest version] omap: usb: host: Runtime PM preparation
for EHCI and OHCI drivers.

Validation performed:
The global suspend/resume of EHCI and OHCI is validated on
OMAP3430 sdp board with this patch combined with the series:
[PATCH 0/5 v13 or latest version] omap: usb: host: Runtime PM preparation
for EHCI and OHCI drivers.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
6 years agoARM: OMAP: USBHOST: Replace usbhs core driver APIs by Runtime pm APIs
Keshava Munegowda [Tue, 11 Oct 2011 07:52:11 +0000 (13:22 +0530)]
ARM: OMAP: USBHOST: Replace usbhs core driver APIs by Runtime pm APIs

The ehci and ohci drivers does not use the APIs of the usbhs
core driver; the runtime pm APIs are used for clock
enable/disable. Since usbhs is parent platform device of the
ehci and ohci devices, the runtime apis indirectly uses the
usb hs core device as input parameter to for clock functions.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
6 years agoARM: OMAP: USB: register hwmods of usbhs
Keshava Munegowda [Tue, 11 Oct 2011 07:51:37 +0000 (13:21 +0530)]
ARM: OMAP: USB: register hwmods of usbhs

The hwmod structure of usb_host_hs  and usb_tll are
retrieved and registered with omap device

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
[paul@pwsan.com: this patch is merged with the understanding that the
 authors will send patches for the next merge window to remove the
 multiple hwmods-per-omap_device]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
6 years agoARM: mm: Increase the temporary stack size during the initial boot.
R Sricharan [Tue, 31 Jan 2012 13:09:13 +0000 (18:39 +0530)]
ARM: mm: Increase the temporary stack size during the initial boot.

A temporary stack of size 44 bytes (4 * 11) registers
is setup during the initial boot process, with r12 as the stack pointer.
But this is not sufficient for scenarios where we have to save
more than 11 registers. So increasing this to 15 * 4 registers,
that would help to save all the ARM registers.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
6 years agoARM: OMAP5: Fix the build error for kernel build without ARM timers.
Santosh Shilimkar [Tue, 31 Jan 2012 12:21:54 +0000 (17:51 +0530)]
ARM: OMAP5: Fix the build error for kernel build without ARM timers.

With ARCH_TIMERS disabled, OMAP5 sEVM build breaks because of
wrongly added semicolon in omap4-common in omap4-common.h

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
6 years agoARM: OMAP5: Keep CONFIG_NO_HZ disabled since it causes regression with ARM timer...
Santosh Shilimkar [Tue, 31 Jan 2012 11:38:40 +0000 (17:08 +0530)]
ARM: OMAP5: Keep CONFIG_NO_HZ disabled since it causes regression with ARM timer code.

The current A15 ARM timer code doesn't work with tick suppression enabled.
So disabled it.

The issue seen with suspend wakeup from UART and GP timer

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
6 years agousb/host: introduce USB_ARCH_HAS_XHCI
Felipe Balbi [Fri, 23 Sep 2011 21:19:56 +0000 (14:19 -0700)]
usb/host: introduce USB_ARCH_HAS_XHCI

to make it look like OHCI and EHCI, we introduce
that symbol and USB_XHCI_HCD depend on that
instead of PCI.

[bigeasy@linutronix.de: wire up USB_ARCH_HAS_HCD]

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agousb/xhci: add platform driver support
Sebastian Andrzej Siewior [Wed, 2 Nov 2011 12:35:51 +0000 (13:35 +0100)]
usb/xhci: add platform driver support

This adds a fairly simple xhci-platform driver support. Currently it is
used by the dwc3 driver.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
6 years agoxHCI: fix bug in xhci_clear_command_ring()
Andiry Xu [Wed, 30 Nov 2011 08:37:41 +0000 (16:37 +0800)]
xHCI: fix bug in xhci_clear_command_ring()

When system enters suspend, xHCI driver clears command ring by writing zero
to all the TRBs. However, this also writes zero to the Link TRB, and the ring
is mangled. This may cause driver accesses wrong memory address and the
result is unpredicted.

When clear the command ring, keep the last Link TRB intact, only clear its
cycle bit. This should fix the "command ring full" issue reported by Oliver
Neukum.

This should be backported to stable kernels as old as 2.6.37, since the
commit 89821320 "xhci: Fix command ring replay after resume" is merged.

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Oliver Neukum <oneukum@suse.de>
6 years agoUSB: XHCI: resume root hubs when the controller resumes
Alan Stern [Thu, 3 Nov 2011 15:37:10 +0000 (11:37 -0400)]
USB: XHCI: resume root hubs when the controller resumes

This patch (as1494) fixes a problem in xhci-hcd's resume routine.
When the controller is runtime-resumed, this can only mean that one of
the two root hubs has made a wakeup request and therefore needs to be
resumed as well.  Rather than try to determine which root hub requires
attention (which might be difficult in the case where a new
non-SuperSpeed device has been plugged in), the patch simply resumes
both root hubs.

Without this change, there is a race: The controller might be put back
to sleep before it can activate its IRQ line, and the wakeup condition
might never get handled.

The patch also simplifies the logic in xhci_resume a little, combining
some repeated flag settings into a single pair of statements.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agoxhci: Set slot and ep0 flags for address command.
Sarah Sharp [Thu, 3 Nov 2011 20:06:08 +0000 (13:06 -0700)]
xhci: Set slot and ep0 flags for address command.

Matt's AsMedia xHCI host controller was responding with a Context Error
to an address device command after a configured device reset.  Some
sequence of events leads both the slot and endpoint zero add flags
cleared to zero, which the AsMedia host doesn't like:

[  223.701839] xhci_hcd 0000:03:00.0: Slot ID 1 Input Context:
[  223.701841] xhci_hcd 0000:03:00.0: @ffff880137b25000 (virt) @ffffc000 (dma) 0x000000 - drop flags
[  223.701843] xhci_hcd 0000:03:00.0: @ffff880137b25004 (virt) @ffffc004 (dma) 0x000000 - add flags
[  223.701846] xhci_hcd 0000:03:00.0: @ffff880137b25008 (virt) @ffffc008 (dma) 0x000000 - rsvd2[0]
[  223.701848] xhci_hcd 0000:03:00.0: @ffff880137b2500c (virt) @ffffc00c (dma) 0x000000 - rsvd2[1]
[  223.701850] xhci_hcd 0000:03:00.0: @ffff880137b25010 (virt) @ffffc010 (dma) 0x000000 - rsvd2[2]
[  223.701852] xhci_hcd 0000:03:00.0: @ffff880137b25014 (virt) @ffffc014 (dma) 0x000000 - rsvd2[3]
[  223.701854] xhci_hcd 0000:03:00.0: @ffff880137b25018 (virt) @ffffc018 (dma) 0x000000 - rsvd2[4]
[  223.701857] xhci_hcd 0000:03:00.0: @ffff880137b2501c (virt) @ffffc01c (dma) 0x000000 - rsvd2[5]
[  223.701858] xhci_hcd 0000:03:00.0: Slot Context:
[  223.701860] xhci_hcd 0000:03:00.0: @ffff880137b25020 (virt) @ffffc020 (dma) 0x8400000 - dev_info
[  223.701862] xhci_hcd 0000:03:00.0: @ffff880137b25024 (virt) @ffffc024 (dma) 0x010000 - dev_info2
[  223.701864] xhci_hcd 0000:03:00.0: @ffff880137b25028 (virt) @ffffc028 (dma) 0x000000 - tt_info
[  223.701866] xhci_hcd 0000:03:00.0: @ffff880137b2502c (virt) @ffffc02c (dma) 0x000000 - dev_state
[  223.701869] xhci_hcd 0000:03:00.0: @ffff880137b25030 (virt) @ffffc030 (dma) 0x000000 - rsvd[0]
[  223.701871] xhci_hcd 0000:03:00.0: @ffff880137b25034 (virt) @ffffc034 (dma) 0x000000 - rsvd[1]
[  223.701873] xhci_hcd 0000:03:00.0: @ffff880137b25038 (virt) @ffffc038 (dma) 0x000000 - rsvd[2]
[  223.701875] xhci_hcd 0000:03:00.0: @ffff880137b2503c (virt) @ffffc03c (dma) 0x000000 - rsvd[3]
[  223.701877] xhci_hcd 0000:03:00.0: Endpoint 00 Context:
[  223.701879] xhci_hcd 0000:03:00.0: @ffff880137b25040 (virt) @ffffc040 (dma) 0x000000 - ep_info
[  223.701881] xhci_hcd 0000:03:00.0: @ffff880137b25044 (virt) @ffffc044 (dma) 0x2000026 - ep_info2
[  223.701883] xhci_hcd 0000:03:00.0: @ffff880137b25048 (virt) @ffffc048 (dma) 0xffffe8e0 - deq
[  223.701885] xhci_hcd 0000:03:00.0: @ffff880137b25050 (virt) @ffffc050 (dma) 0x000000 - tx_info
[  223.701887] xhci_hcd 0000:03:00.0: @ffff880137b25054 (virt) @ffffc054 (dma) 0x000000 - rsvd[0]
[  223.701889] xhci_hcd 0000:03:00.0: @ffff880137b25058 (virt) @ffffc058 (dma) 0x000000 - rsvd[1]
[  223.701892] xhci_hcd 0000:03:00.0: @ffff880137b2505c (virt) @ffffc05c (dma) 0x000000 - rsvd[2]
...
[  223.701927] xhci_hcd 0000:03:00.0: // Ding dong!
[  223.701992] xhci_hcd 0000:03:00.0: Setup ERROR: address device command for slot 1.

The xHCI spec says that both flags must be set to one for the Address
Device command.  When the device is first enumerated,
xhci_setup_addressable_virt_dev() does set those flags.  However, when
the device is addressed after it has been reset in the configured state,
xhci_setup_addressable_virt_dev() is not called, and
xhci_copy_ep0_dequeue_into_input_ctx() is called instead.  That function
relies on the flags being set up by previous commands, which apparently
isn't a good assumption.

Move the setting of the flags into the common parent function.

This should be queued for stable kernels as old as 2.6.35, since that
was the first introduction of xhci_copy_ep0_dequeue_into_input_ctx.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Matt <mdm@iinet.net.au>
Cc: stable@vger.kernel.org
6 years agousb, xhci: fix lockdep warning on endpoint timeout
Don Zickus [Fri, 21 Oct 2011 03:52:14 +0000 (23:52 -0400)]
usb, xhci: fix lockdep warning on endpoint timeout

While debugging a usb3 problem, I stumbled upon this lockdep warning.

Oct 18 21:41:17 dhcp47-74 kernel: =================================
Oct 18 21:41:17 dhcp47-74 kernel: [ INFO: inconsistent lock state ]
Oct 18 21:41:17 dhcp47-74 kernel: 3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: ---------------------------------
Oct 18 21:41:17 dhcp47-74 kernel: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Oct 18 21:41:17 dhcp47-74 kernel: swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
Oct 18 21:41:17 dhcp47-74 kernel: (&(&xhci->lock)->rlock){?.-...}, at: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: {IN-HARDIRQ-W} state was registered at:
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109a941>] __lock_acquire+0x781/0x1660
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109bed7>] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa02299fa>] xhci_irq+0x3a/0x1960 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022b351>] xhci_msi_irq+0x31/0x40 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d2305>] handle_irq_event_percpu+0x85/0x320
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d25e8>] handle_irq_event+0x48/0x70
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d537d>] handle_edge_irq+0x6d/0x130
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810048c9>] handle_irq+0x49/0xa0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150d56d>] do_IRQ+0x5d/0xe0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff815029b0>] ret_from_intr+0x0/0x13
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81388aca>] usb_set_device_state+0x8a/0x180
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8138f038>] usb_add_hcd+0x2b8/0x730
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022ed7e>] xhci_pci_probe+0x9e/0xd4 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127915f>] local_pci_probe+0x5f/0xd0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a569>] pci_device_probe+0x119/0x120
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334473>] driver_probe_device+0xa3/0x2c0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133473b>] __driver_attach+0xab/0xb0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133373c>] bus_for_each_dev+0x6c/0xa0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff813341fe>] driver_attach+0x1e/0x20
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81333b88>] bus_add_driver+0x1f8/0x2b0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334df6>] driver_register+0x76/0x140
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a7c6>] __pci_register_driver+0x66/0xe0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c04a>] snd_timer_find+0x4a/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c00e>] snd_timer_find+0xe/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810001d3>] do_one_initcall+0x43/0x180
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810a9ed2>] sys_init_module+0x92/0x1f0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150ab6b>] system_call_fastpath+0x16/0x1b
Oct 18 21:41:17 dhcp47-74 kernel: irq event stamp: 631984
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last  enabled at (631984): [<ffffffff81502720>] _raw_spin_unlock_irq+0x30/0x50
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last disabled at (631983): [<ffffffff81501c49>] _raw_spin_lock_irq+0x19/0x90
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last  enabled at (631980): [<ffffffff8105ff63>] _local_bh_enable+0x13/0x20
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last disabled at (631981): [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: other info that might help us debug this:
Oct 18 21:41:17 dhcp47-74 kernel: Possible unsafe locking scenario:
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel:       CPU0
Oct 18 21:41:17 dhcp47-74 kernel:       ----
Oct 18 21:41:17 dhcp47-74 kernel:  lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:  <Interrupt>
Oct 18 21:41:17 dhcp47-74 kernel:    lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: *** DEADLOCK ***
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: 1 lock held by swapper/0:
Oct 18 21:41:17 dhcp47-74 kernel: #0:  (&ep->stop_cmd_timer){+.-...}, at: [<ffffffff8106abf2>] run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: stack backtrace:
Oct 18 21:41:17 dhcp47-74 kernel: Pid: 0, comm: swapper Tainted: G        W   3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: Call Trace:
Oct 18 21:41:17 dhcp47-74 kernel: <IRQ>  [<ffffffff81098ed7>] print_usage_bug+0x227/0x270
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810999c6>] mark_lock+0x346/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109a7de>] __lock_acquire+0x61e/0x1660
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81099893>] ? mark_lock+0x213/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109bed7>] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106ac9d>] run_timer_softirq+0x20d/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228960>] ? xhci_queue_isoc_tx_prepare+0x8e0/0x8e0 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810604d2>] __do_softirq+0xf2/0x3f0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81020edd>] ? lapic_next_event+0x1d/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81090d4e>] ? clockevents_program_event+0x5e/0x90
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8100484d>] do_softirq+0x8d/0xc0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8105ff35>] irq_exit+0xe5/0x100
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150d65e>] smp_apic_timer_interrupt+0x6e/0x99
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150b6f0>] apic_timer_interrupt+0x70/0x80
Oct 18 21:41:17 dhcp47-74 kernel: <EOI>  [<ffffffff81095d8d>] ? trace_hardirqs_off+0xd/0x10
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb76>] ? acpi_idle_enter_bm+0x227/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb71>] ? acpi_idle_enter_bm+0x222/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff813eda63>] cpuidle_idle_call+0x103/0x290
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81002155>] cpu_idle+0xe5/0x160
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7f50>] rest_init+0xe0/0xf0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7e70>] ? csum_partial_copy_generic+0x170/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8e23>] start_kernel+0x3fc/0x407
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8321>] x86_64_start_reservations+0x131/0x135
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8412>] x86_64_start_kernel+0xed/0xf4
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -110
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -22
Oct 18 21:41:17 dhcp47-74 kernel: hub 3-0:1.0: cannot disable port 4 (err = -19)

Basically what is happening is in xhci_stop_endpoint_command_watchdog()
the xhci->lock is grabbed with just spin_lock.  What lockdep deduces is
that if an interrupt occurred while in this function it would deadlock
with xhci_irq because that function also grabs the xhci->lock.

Fixing it is trivial by using spin_lock_irqsave instead.

This should be queued to stable kernels as far back as 2.6.33.

Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
6 years agousb: fix implicit usage of gfp.h in host/xhci-hub.c
Paul Gortmaker [Mon, 18 Jul 2011 18:42:00 +0000 (14:42 -0400)]
usb: fix implicit usage of gfp.h in host/xhci-hub.c

To fix this build error on ARM:

drivers/usb/host/xhci-hub.c: In function 'xhci_stop_device':
drivers/usb/host/xhci-hub.c:261: error: 'GFP_NOIO' undeclared (first use in this function)
make[4]: *** [drivers/usb/host/xhci-hub.o] Error 1

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
6 years agousb: Add module.h to drivers/usb consumers who really use it.
Paul Gortmaker [Sun, 3 Jul 2011 20:09:31 +0000 (16:09 -0400)]
usb: Add module.h to drivers/usb consumers who really use it.

The situation up to this point meant that module.h was pretty
much everywhere, regardless of whether you asked for it or not.
We are fixing that, so give the USB folks who want it an actual
include of it.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
6 years agoxHCI/USB: Make xHCI driver have a BOS descriptor.
Sarah Sharp [Thu, 6 Oct 2011 18:54:23 +0000 (11:54 -0700)]
xHCI/USB: Make xHCI driver have a BOS descriptor.

To add USB 3.0 link power management (LPM), we need to know what the U1
and U2 exit latencies are for the xHCI host controller.  External USB 3.0
hubs report these values through the SuperSpeed Capabilities descriptor in
the BOS descriptor.  Make the USB 3.0 roothub for the xHCI host behave
like an external hub and return the BOS descriptors.

The U1 and U2 exit latencies will vary across each host controller, so we
need to dynamically fill those values in by reading the exit latencies out
of the xHC registers.  Make the roothub code in the USB core handle
hub_control() returning the length of the data copied.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agousb/xhci: remove CONFIG_PCI in xhci.c's probe function
Sebastian Andrzej Siewior [Fri, 23 Sep 2011 21:20:02 +0000 (14:20 -0700)]
usb/xhci: remove CONFIG_PCI in xhci.c's probe function

This removes the need of ifdefs within the init function and with it the
headache about the correct clean without bus X but with bus/platform Y &
Z.
xhci-pci is only compiled if CONFIG_PCI is selected which can be
de-selected now without trouble. For now the result is kinda useless
because we have no other glue code. However, since nobody is using
USB_ARCH_HAS_XHCI then it should not be an issue :)

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agousb/xhci: move xhci_gen_setup() away from -pci.
Sebastian Andrzej Siewior [Fri, 23 Sep 2011 21:20:01 +0000 (14:20 -0700)]
usb/xhci: move xhci_gen_setup() away from -pci.

xhci_gen_setup() is generic so it can be used to perform the bare xhci
setup even on non-pci based platform. The typedef for the function
pointer is moved into the headerfile

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agousb/xhci: refactor xhci_pci_setup()
Sebastian Andrzej Siewior [Fri, 23 Sep 2011 21:20:00 +0000 (14:20 -0700)]
usb/xhci: refactor xhci_pci_setup()

xhci_pci_setup() is split into three pieces:

- xhci_gen_setup()
  The major remaining of xhci_pci_setup() is now containing the generic
  part of the xhci setup. It allocates the xhci struct, setup
  hcs_params? and friends, performs xhci_halt(), xhci_init and so one.
  It also obtains the quirks via a callback
- xhci_pci_quirks()
  It checks the origin of the xhci core and sets core specific quirks.
- xhci_pci_setup()
  PCI specific setup functions. Besides calling xhci_gen_setup() with
  xhci_pci_quirks() as an argument it performs PCI specific setup like
  obtaining the address of sbrn via a PCI config space.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agousb/xhci: replace pci_*_consistent() with dma_*_coherent()
Sebastian Andrzej Siewior [Fri, 23 Sep 2011 21:19:59 +0000 (14:19 -0700)]
usb/xhci: replace pci_*_consistent() with dma_*_coherent()

pci_*_consistent() calls dma_*_coherent() with GFP_ATOMIC and requires
pci_dev struct. This is a preparion for later where we no longer have
the pci struct around.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6 years agousb/xhci: hide MSI code behind PCI bars
Sebastian Andrzej Siewior [Fri, 23 Sep 2011 21:19:58 +0000 (14:19 -0700)]
usb/xhci: hide MSI code behind PCI bars

The MSI related fuctionality requires a few structs which are not
available if CONFIG_PCI is not enabled. This is a prepartion to allow
xhci be built without CONFIG_PCI set.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>