we are compiling the driver always with full OTG
capabilities, so that board_mode trick becomes
useless.

Signed-off-by: Felipe Balbi <balbi@ti.com>

Do not rely on any hints from gadget drivers and use DMA mode 1
whenever we expect data of at least the endpoint's packet size and
have not yet received a short packet.

The last packet if short is always transferred using DMA mode 0.

This patch fixes USB throughput issues in mass storage mode for
host to device transfers.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

This is to reduce the overhead of dma programming for zero byte
transmit as same can be done using pio mode.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

In rxstate(), improper types are given to 'fifo_count' and 'len' variables, and
these variables are not used in accordance to their names (up to the certain
point), i.e. 'len' to hold the size of a packet in the RX FIFO, and 'fifo_count'
to hold a difference between 'request->length' and 'request->actual'...
Interchange the variables up to the point where their use starts to make sense
again.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb_ep_ops.disable must clear external copy of the endpoint descriptor,
otherwise musb crashes after loading/unloading several gadget modules
in a row:

Unable to handle kernel paging request at virtual address bf013730
pgd = c0004000
[bf013730] *pgd=8f26d811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1]
Modules linked in: g_cdc [last unloaded: g_file_storage]
CPU: 0    Not tainted  (3.2.17 #647)
PC is at musb_gadget_enable+0x4c/0x24c
LR is at _raw_spin_lock_irqsave+0x4c/0x58
[<c027c030>] (musb_gadget_enable+0x4c/0x24c) from [<bf01b760>] (gether_connect+0x3c/0x19c [g_cdc])
[<bf01b760>] (gether_connect+0x3c/0x19c [g_cdc]) from [<bf01ba1c>] (ecm_set_alt+0x15c/0x180 [g_cdc])
[<bf01ba1c>] (ecm_set_alt+0x15c/0x180 [g_cdc]) from [<bf01ecd4>] (composite_setup+0x85c/0xac4 [g_cdc])
[<bf01ecd4>] (composite_setup+0x85c/0xac4 [g_cdc]) from [<c027b744>] (musb_g_ep0_irq+0x844/0x924)
[<c027b744>] (musb_g_ep0_irq+0x844/0x924) from [<c027a97c>] (musb_interrupt+0x79c/0x864)
[<c027a97c>] (musb_interrupt+0x79c/0x864) from [<c027aaa8>] (generic_interrupt+0x64/0x7c)
[<c027aaa8>] (generic_interrupt+0x64/0x7c) from [<c00797cc>] (handle_irq_event_percpu+0x28/0x178)
...

Cc: stable@vger.kernel.org # v3.1+
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

User can trigger disabling of gadget at run time while the
transfers are going on.
Eg: 1: rmmod of musb driver while transfers are going on

Eg: 2: On android doing:
 echo 0       > /sys/class/android_usb/android0/enable
While a big file transfer is going on via PTP/MTP.

In such a case, musb_gadget_disable() calls nuke()
but the dma interrupt may still happen for an endpoint since hw
would raise the interrupt in anycase.

This can result in a NULL pointer access crash:

[  314.030426] PC is at txstate+0x74/0x20c
[  314.034759] LR is at musb_g_tx+0x140/0x204
[  314.039489] pc : [<c03506f4>]    lr : [<c0350bcc>]    psr: 20000193
[  314.039520] sp : c783bc68  ip : 00000002  fp : c783bc9c
[  314.052429] r10: 00000018  r9 : 00000000  r8 : 00000200
[  314.058258] r7 : 00000000  r6 : fc0ab130  r5 : c781a410  r4 : c6caf640
[  314.065643] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : c781a000
[  315.083251] Backtrace:
[  315.086242] [<c0350680>] (txstate+0x0/0x20c) from [<c0350bcc>] (musb_g_tx+0x140/0x204)
[  315.095123] [<c0350a8c>] (musb_g_tx+0x0/0x204) from [<c034eb00>] (musb_dma_completion+0x40/0x54)
[  315.104980] [<c034eac0>] (musb_dma_completion+0x0/0x54) from [<c0351e6c>] (dma_controller_irq+0x118/0x184)
[  315.115661] [<c0351d54>] (dma_controller_irq+0x0/0x184) from [<c00d86b8>] (handle_irq_event_percpu+0x54/0x188)

So put protection in code to handle possiblity of getting an interrupt for an
endpoint that might have been already nuked.

Reported-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

There's really no point in having hcd->irq as a
signed integer when we consider the fact that
IRQ 0 means NO_IRQ. In order to avoid confusion,
make hcd->irq unsigned and fix users who were
passing -1 as the IRQ number to usb_add_hcd.

Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This changes the otg functions so that they receive struct
otg instead of struct usb_phy as parameter and
converts all users of these functions to pass the otg member
of their usb_phy.

Includes fixes to IMX code from Sascha Hauer.

[ balbi@ti.com : fixed a compile warning on ehci-mv.c ]

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Acked-by: Li Yang <leoli@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Use the new usb_phy_* functions with transceiver
operations instead of the old otg functions.

Includes fixes from Sascha Hauer.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Acked-by: Li Yang <leoli@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

musb INDEX register is getting modified/corrupted during temporary
un-locking in a SMP system. Set this register with proper value
after re-acquiring the lock

Scenario:
---------
CPU1 is handling a data transfer completion interrupt received for
the CLASS1 EP
CPU2 is handling a CLASS2 thread which is queuing data to musb for
transfer

Below is the error sequence:

         CPU1                   |             CPU2
--------------------------------------------------------------------
Data transfer completion inter- |
rupt recieved.                  |
                                |
musb INDEX reg set to CLASS1 EP |
                                |
musb LOCK is acquired.          |
                                |
                                | CLASS2 thread queues data.
                                |
                                | CLASS2 thread tries to acquire musb
                                | LOCK but lock is already taken by
                                | CLASS1, so CLASS2 thread is
                                | spinning.
                                |
From Interrupt Context musb     |
giveback function is called     |
                                |
The giveback function releases  | CLASS2 thread now acquires LOCK
LOCK                            |
                                |
ClASS1 Request's completion cal-| ClASS2 schedules the data transfer and
lback is called                 | sets the MUSB INDEX to Class2 EP number
                                |
Interrupt handler for CLASS1 EP |
tries to acquire LOCK and is    |
spinning                        |
                                |
Interrupt for Class1 EP acquires| Class2 completes the scheduling etc and
the MUSB LOCK                   | releases the musb LOCK
                                |
Interrupt for Class1 EP schedul-|
es the next data transfer       |
but musb INDEX register is still|
set to CLASS2 EP                |

Since the MUSB INDEX register is set to a different endpoint, we
read and modify the wrong registers. Hence data transfer will not
happen properly. This results in unpredictable behavior

So, the MUSB INDEX register is set to proper value again when
interrupt re-acquires the lock

Cc: stable@vger.kernel.org
Signed-off-by: Supriya Karanth <supriya.karanth@stericsson.com>
Signed-off-by: Praveena Nadahally <praveen.nadahally@stericsson.com>
Reviewed-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Use struct usb_otg members with OTG specific functions instead
of usb_phy members.

[ balbi@ti.com: added a missing change on musb_gadget.c to avoid
	a compile error on a later patch ]

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

There's really no point in doing all that
initcall trickery when we can safely let
udev handle module probing for us.

Remove all of that trickery, by moving everybody
to module_init() and making proper use of
platform_device_register() rather than
platform_device_probe().

Tested-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>
Tested-by: Tasslehoff Kjappfot <tasskjapp@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Remove a few unnecessary headers from a
few files.

Signed-off-by: Felipe Balbi <balbi@ti.com>

This commit renames the “speed” field of the usb_gadget_driver
structure to “max_speed”.  This is so that to make it more
apparent that the field represents the maximum speed gadget
driver can support.

This also make the field look more like fields with the same
name in usb_gadget and usb_composite_driver structures.  All
of those represent the *maximal* speed given entity supports.

After this commit, there are the following fields in various
structures:
* usb_gadget::speed - the current connection speed,
* usb_gadget::max_speed - maximal speed UDC supports,
* usb_gadget_driver::max_speed - maximal speed gadget driver
  supports, and
* usb_composite_driver::max_speed - maximal speed composite
  gadget supports.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

This commit replaces usb_gadget's is_dualspeed field with
a max_speed field.

[ balbi@ti.com : Fixed DWC3 driver ]

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Several UDC drivers had a gadget driver's speed sanity check of the
form of:

	driver->speed != USB_SPEED_HIGH

or:

	driver->speed != USB_SPEED_HIGH && driver->speed != USB_SPEED_FULL

As more and more gadget drivers support USB SuperSpeed, driver->speed
may be set to USB_SPEED_SUPER and UDC driver should handle such gadget
correctly.  The above checks however fail to recognise USB_SPEED_SUPER
as a valid speed.

This commit changes the two checks to:

	driver->speed < USB_SPEED_HIGH

or:

	driver->speed < USB_SPEED_FULL

respectively.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

that has already being done by udc-core.c. It's
unnecessary and might cause issues with some gadget
drivers.

Tested: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

This patch enables DMA mode1 for the RX path when we know
there won't be any short packets. We check that by looking
into the short_no_ok flag, if it's true we enable mode1, otherwise
we use mode0 to transfer the data.

This will result in a throughput performance gain of around
40% for USB mass-storage/mtp use cases.

[ balbi@ti.com : updated commit log and code comments slightly ]

Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Tested-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Now ${LINUX}/drivers/usb/* can use usb_endpoint_maxp(desc) to get maximum packet size
instead of le16_to_cpu(desc->wMaxPacketSize).
This patch fix it up

Cc: Armin Fuerst <fuerst@in.tum.de>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Johannes Erdfelt <johannes@erdfelt.com>
Cc: Vojtech Pavlik <vojtech@suse.cz>
Cc: Oliver Neukum <oliver@neukum.name>
Cc: David Kubicek <dave@awk.cz>
Cc: Johan Hovold <jhovold@gmail.com>
Cc: Brad Hards <bhards@bigpond.net.au>
Acked-by: Felipe Balbi <balbi@ti.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Dahlmann <dahlmann.thomas@arcor.de>
Cc: David Brownell <david-b@pacbell.net>
Cc: David Lopo <dlopo@chipidea.mips.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Michal Nazarewicz <m.nazarewicz@samsung.com>
Cc: Xie Xiaobo <X.Xie@freescale.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Jiang Bo <tanya.jiang@freescale.com>
Cc: Yuan-hsin Chen <yhchen@faraday-tech.com>
Cc: Darius Augulis <augulis.darius@gmail.com>
Cc: Xiaochen Shen <xiaochen.shen@intel.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: OKI SEMICONDUCTOR, <toshiharu-linux@dsn.okisemi.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Ben Dooks <ben@simtec.co.uk>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Herbert Pötzl <herbert@13thfloor.at>
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Roman Weissgaerber <weissg@vienna.at>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: Florian Floe Echtler <echtler@fs.tum.de>
Cc: Christian Lucht <lucht@codemercs.com>
Cc: Juergen Stuber <starblue@sourceforge.net>
Cc: Georges Toth <g.toth@e-biz.lu>
Cc: Bill Ryder <bryder@sgi.com>
Cc: Kuba Ober <kuba@mareimbrium.org>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

In case one "forgot" to load the receiver i.e. doing
|modprobe omap2430
|modprobe musb_hdrc

he ends up with:

|musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
|HS USB OTG: no transceiver configured
|musb-hdrc musb-hdrc: musb_init_controller failed with status -19
|(NULL device *): gadget not registered.
|Unable to handle kernel NULL pointer dereference at virtual address 0000001c
|Internal error: Oops: 17 [#1] SMP
|[<c011383c>] (sysfs_find_dirent+0x4/0x60) from [<c01138c0>] (sysfs_get_dirent+0x28/0x78)
|[<c01138c0>] (sysfs_get_dirent+0x28/0x78) from [<c0115b78>] (sysfs_unmerge_group+0x1c/0x90)
|[<c0115b78>] (sysfs_unmerge_group+0x1c/0x90) from [<c0179ba4>] (dpm_sysfs_remove+0x14/0x3c)
|[<c0179ba4>] (dpm_sysfs_remove+0x14/0x3c) from [<c01742f8>] (device_del+0x40/0x1b4)
|[<c01742f8>] (device_del+0x40/0x1b4) from [<c0174478>] (device_unregister+0xc/0x18)
|[<c0174478>] (device_unregister+0xc/0x18) from [<bf0489b4>] (musb_free+0x24/0x88 [musb_hdrc])
|[<bf0489b4>] (musb_free+0x24/0x88 [musb_hdrc]) from [<bf057d18>] (musb_probe+0xb50/0xe3c [musb_hdrc])
|[<bf057d18>] (musb_probe+0xb50/0xe3c [musb_hdrc]) from [<c01779c4>] (platform_drv_probe+0x1c/0x24)

The problem is that musb_free() tries to figure out what was
initializued and what wasn't and clean up only the initialized part.
This works well for usb_del_gadget_udc() but device_unregister() can't
deal with it. Therefore we rely on the fact the we always have a parent
device and only then remove the device.
I broke this in 0f91349b ("usb: gadget: convert all users to the new udc
infrastructure")

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

an 'unhandled fault' is causes when a gadget driver calls
usb_gadget_connect() while the USB cable isn't plugged into
the OTG port.

the fault is caused by an access to MUSB's memory space
while its clock is turned off due to pm_runtime kicking
in.

in order to fix the fault, we enclose musb_gadget_pullup()
with pm_runtime_get_sync() ... pm_runtime_put() calls to
be sure we will always reach that path with clock turned on.

[ balbi@ti.com : simplified commit log; removed few things
	which didn't belong there ]

Cc: stable@kernel.org
Reported-by: Zach Pfeffer <zach.pfeffer@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>

an 'unhandled fault' is causes when a gadget driver calls
usb_gadget_connect() while the USB cable isn't plugged into
the OTG port.

the fault is caused by an access to MUSB's memory space
while its clock is turned off due to pm_runtime kicking
in.

in order to fix the fault, we enclose musb_gadget_pullup()
with pm_runtime_get_sync() ... pm_runtime_put() calls to
be sure we will always reach that path with clock turned on.

[ balbi@ti.com : simplified commit log; removed few things
	which didn't belong there ]

Cc: stable@kernel.org
Reported-by: Zach Pfeffer <zach.pfeffer@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>

udc-core checks for valid callbacks so there is no need for the driver
to do so. Also "can-be-bound-once" is verified by udc-core. The pull-up
callback is called by udc-core afterwords.

[ balbi@ti.com : keep holding gadget_driver pointer for now
		 remove the stupid check for gadget_driver otherwise
		  we don't handle IRQs ]

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

the MUSB IP is always OTG, so there's no point
in adding so many ifdefs on the code. Drop those
and always compile the driver for OTG support.

This also allows us to drop the useless "driver
mode" choice. For doing that, we need to make
musb depend on both Host and Peripheral side.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

peripheral drivers are using usb_add_gadget()/usb_del_gadget() to
register/unregister to the udc-core.

The udc-core will take the first available gadget driver and attach
function driver which is calling usb_gadget_register_driver(). This is
the same behaviour we have right now.

Only dummy_hcd was tested, the others were compiled tested.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Anton Tikhomirov <av.tikhomirov@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Darius Augulis <augulis.darius@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
Cc: Roy Huang <roy.huang@analog.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Cc: Xiaochen Shen <xiaochen.shen@intel.com>
Cc: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Cc: Yuan-Hsin Chen <yhchen@faraday-tech.com>
Cc: cxie4 <cxie4@marvell.com>
Cc: linux-geode@lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Fixes mis-use of MUSB's hardware feature where it won't
flush FIFOs when TXPKTRDY flag was set before and we are
flushing setting both FLUSHFIFO and TXPKTRDY.

In other words, we need to ensure that when we try to
flush FIFOs, we don't accidentaly set TXPKTRDY bit too
due to a read-back of the register.

The MUSB Programming Guide says "May be set simultaneously
with TxPktRdy to abort the packet that is currently being
loaded into the FIFO". This is a situation where TXPKTRDY
hasn't been set yet, but some data already loaded into the
fifo. It looks, that if TXPKTRDY has been set before, and
there is no loading in progress, but we set FLUSHFIFO with
the TXPKTRDY, controller tries to use the same logic to
abort loading and as the result just does nothing (because
there is no packet been loaded currently)

Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@nokia.com>

[ balbi@ti.com : fixed one whitespace git complained about
		 improved the commit log slightly ]

Signed-off-by: Felipe Balbi <balbi@ti.com>

Although U8500 and U5500 platforms use paltform dma, Inventra dma specific code
can work for them for the most part. Only difference is for the Rx path where
this patch is making use of request->short_not_ok to select dma mode.

Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

Call VBUS pulsing API when there is SRP initiation from user space.

Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

We have a generic way of enabling/disabling
different debug messages on a driver called
DYNAMIC_PRINTK. Anyone interested in enabling
just part of the debug messages, please read
the documentation under:

Documentation/dynamic-debug-howto.txt

for information on how to use that great
infrastructure.

Signed-off-by: Felipe Balbi <balbi@ti.com>

Commit 3dacdf11 "usb: factor out state_string() on otg drivers"
broke building musb drivers since there is already another
otg_state_string() function in musb drivers, but with different
prototype. Fix musb drivers to use common otg_state_string(), too.

Also provide a nop for otg_state_string() if CONFIG_USB_OTG_UTILS
is not defined.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

If cable is not connected to peripheral only board when initializing the
gadget driver, then runtime pm calls are out-of-sync and the musb cannot
idle with omap2430.c. This was noted on Nokia N900 where musb prevented the
CPU to be able to enter deeper retention idle state.

This was working in 2.6.38 before runtime pm conversions but there musb
smart standby/idle modes were configured statically where they are now
updated runtime depending on use and cable status.

Reason for out-of-sync is that runtime pm is activated in function
musb_gadget.c: usb_gadget_probe_driver but suspended only in OTG mode if
cable is not connected when initializing. In peripheral only mode this leads
to out-of-sync runtime pm since runtime pm remain active and is activated
another time in omap2430.c: musb_otg_notifications for VBUS Connect event
and thus cannot suspend for VBUS Disconnect event since the use count remains
active.

Fix this by moving cable status check and pm_runtime_put call in
usb_gadget_probe_driver out of is_otg_enabled block.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

We are now using our own list_head, so we should
be checking against that, not the gadget driver's
list_head.

Signed-off-by: Felipe Balbi <balbi@ti.com>

On the completion of tx dma, dma is disabled by clearing MUSB_TXCSR_DMAENAB in
TXCSR. If MUSB_TXCSR_AUTOSET was set in txstate() it will remain set although
it is not needed in PIO mode. Clear it as soon as it is not needed.

Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

There was conflict while merging 2 patches. Enabling vbus code
is wrongly moved to error check if loop.

This is a fix to resolve the merge issue.

Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch supports the retention and offmode support in the idle path for
musb driver using runtime pm APIs.

This is restricted to support offmode and retention only when device not
connected.When device/cable connected with gadget driver loaded,configured
to no idle/standby which will not allow the core transition to retention
or off.

There is no context save/restore done by hardware for musb in OMAP3
and OMAP4,driver has to take care of saving and restoring the context
during offmode.

Musb has a requirement of configuring sysconfig register to force
idle/standby mode and set the ENFORCE bit in module STANDBY register
for retention and offmode support.

Runtime pm and hwmod frameworks will take care of configuring to force
idle/standby when pm_runtime_put_sync is called and back to no
idle/standby when pm_runeime_get_sync is called.

Compile, boot tested and also tested the retention in the idle path on
OMAP3630Zoom3. And tested the global suspend/resume with offmode enabled.
Usb basic functionality tested on OMAP4430SDP.

There is some problem with idle path offmode in mainline, I could not test
with offmode. But I have tested this patch with resetting the controller
in the idle path when wakeup from retention just to make sure that the
context is lost, and restore path is working fine.

Removed .suspend/.resume fnction pointers and functions because there
is no need of having these functions as all required work is done
at runtime in the driver.

There is no need to call the runtime pm api with glue driver device
as glue layer device is the parent of musb core device, when runtime apis
are called for the child, parent device runtime functionality
will be invoked.

Design overview:

pm_runtime_get_sync: When called with musb core device takes care of
enabling the clock, calling runtime callback function of omap2430 glue
layer, runtime call back of musb driver and configure the musb sysconfig
to no idle/standby

pm_runtime_put: Takes care of calling runtime callback function of omap2430
glue layer, runtime call back of musb driver, Configure the musb sysconfig
to force idle/standby and disable the clock.

During musb driver load: Call pm_runtime_get_sync.

End of musb driver load: Call pm_runtime_put

During gadget driver load: Call pm_runtime_get_sync,
End of gadget driver load: Call pm_runtime_put if there is no device
or cable is connected.

During unload of the gadget driver:Call pm_runtime_get_sync if cable/device
is not connected.
End of the gadget driver unload : pm_runtime_put

During unload of musb driver : Call pm_runtime_get_sync
End of unload: Call pm_runtime_put

On connect of usb cable/device -> transceiver notification(VBUS and ID-GND):
pm_runtime_get_sync only if the gadget driver loaded.

On disconnect of the cable/device -> Disconnect Notification:
pm_runtime_put if the gadget driver is loaded.

Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

commit ad1adb89
(usb: musb: gadget: do not poke with gadget's list_head)
fixed a bug in musb where it was corrupting the list_head
which is supposed to be used by gadget drivers. While
doing that, I forgot to fix the usage in musb_gadget_dequeue()
method. Fix that.

Reported-by: Pavol Kurina <pavol.kurina@emsys.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>

In the gadget code, there are several DBG() macro invocations that explicitly
print the calling function's name while DBG() macro itself does this anyway;
most of these were added by commit f11d893d
(usb: musb: support ISO high bandwidth for gadget mode). Remove the duplicated
printing, somewhat clarifying the messages at the same time...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

OMAP4430 is embedded with UTMI PHY. This PHY does not support the
OTG features like ID pin detection and VBUS detection. This function
is exported to an external companion chip TWL6030. Software must retrieve
the OTG HNP and SRP status from the TWL6030 and configure the bits inside
the control module that drive the related USBOTGHS UTMI interface signals.
It must also read back the UTMI signals needed to configure the TWL6030
OTG module.

Can find more details in the TRM[1].
[1]:http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.0_Public_TRM_vJ.pdf



In OMAP4430 musb driver VBUS and ID notifications are received from the
transceiver driver. If the cable/device is connected during boot,
notifications from transceiver driver will be missed till musb driver
is loaded.
Patch to configure the transceiver in the platform_enable/disable
functions and enable the vbus in the gadget driver based on the
last_event of the otg_transceiver.

Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

struct usb_request's list_head is supposed to be
used only by gadget drivers, but musb is abusing
that. Give struct musb_request its own list_head
and prevent musb from poking into other driver's
business.

Signed-off-by: Felipe Balbi <balbi@ti.com>