Sanity check on resource happening with devm_ioremap_resource().
Signed-off-by: NVarka Bhadram <varkab@cdac.in>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Sanity check on resource happening with devm_ioremap_resource().
Signed-off-by: NVarka Bhadram <varkab@cdac.in>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The OMAP2+ MUSB glue layer still uses a bare number for the DEVCTL.B-Device bit
in one place, while there's #define MUSB_DEVCTL_BDEVICE for that.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that call is completely unnecessary because
usb_del_gadget_udc() already makes sure the
gadget driver is properly unregistered from
the UDC.
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that call is completely unnecessary because
usb_del_gadget_udc() already makes sure the
gadget driver is properly unregistered from
the UDC.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that call is completely unnecessary because
usb_del_gadget_udc() already makes sure the
gadget driver is properly unregistered from
the UDC.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that call is completely unnecessary because
usb_del_gadget_udc() already makes sure the
gadget driver is properly unregistered from
the UDC.
Acked-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As the udc clock controls both the output signals and the internal IP,
it must be enabled before any UDC register is touched.

The bug is revealed when the clock framework disables the clock for a
couple of milliseconds during the boot sequence, and the endpoint
configuration is lost. The bug is hidden when clock framework is not
used, because no "unused clocks disable" occurs.

This patch fixes the wrong behaviour by ensuring that :
 - whenever a UDC register is read or written, the clock is enabled
 - reworks the endpoints programming to have it done under running clock
 - reworks suspend/resume to ensure the same thing
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use devm_* helpers in the probe function to simplify the error path and
the remove path.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add documentation for device-tree binding of arm PXA 27x udc (usb
device) driver.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: devicetree@vger.kernel.org
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

No functional changes, just adding a prefix
which should have been there from the start.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that no UDC driver relies on the extra
'driver' argument to ->udc_stop(), we can
safely remove it.

This commit is based on previous work by
Robert Baldyga <r.baldyga@samsung.com> which
can be found at [1]; however that patch turned
out to have a high probability of regressing
many UDC drivers because of a blind search & replace
s/driver/$udc->driver/ which caused the 'driver'
argument to stop_activity() to be a valid non-NULL
pointer when it should be NULL, thus causing UDCs
to mistakenly call gadget driver's ->disconnect()
callback.

[1] http://markmail.org/message/x5zneg4xea4zntabAcked-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Currently, we're printing gadget driver name when
registering and UDC name when unregistering. Standardize
on always printing gadget driver name.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we provide generic register/unregister
debugging messages from udc-core, we can remove
the same messages from this driver.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We know that our udc points to our gadget and our
gadget_driver, simplify the interface by passing
a single argument.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

future patches will remove the extra 'driver'
argument to ->udc_stop(), in order to do that,
we must make sure that our UDC does not rely
on it first.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The drivers should use dmaengine_terminate_all() or dmaengine_slave_config()
API instead of accessing the device_control which will be deprecated soon
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The memory subsystem has already had similar message for it.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>