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>
Just a few cosmetic fixes to usb_gadget_probe_driver()
and usb_gadget_unregister_driver().
Decreased a few indentation levels with goto statements.
While at that, also add the missing call to musb_stop().
If we don't have OTG, there's no point of leaving
MUSB prepared for operation if a gadget driver fails
to probe. The same is valid for usb_gadget_unregister_driver(),
since we are removing the gadget driver and we don't have
OTG, we can completely unconfigure MUSB.
Signed-off-by: Felipe Balbi <balbi@ti.com>
During development, even though board is wired
to e.g. OTG, we might want to compile host-only
or peripheral-only configurations.
Let's allow that to happen.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This is needed to resolve some merge conflicts that were found
in the USB host controller patches, and reported by Stephen Rothwell.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The convention is to prefix symbols exported from the USB HCD core with
"usb_hcd". This change makes unmap_urb_setup_for_dma() and
unmap_urb_for_dma() consistent with that.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gadget MUSB driver handles dma mappings in musb_gadget_queue(). Where as it is
possible for dma code to reject the usb request later at ->channel_program()
called from txstate()/rxstate()
For example ->channel_program in tusb6010_omap.c:
static int tusb_omap_dma_program(struct dma_channel *channel, u16 packet_sz,
u8 rndis_mode, dma_addr_t dma_addr, u32 len)
{
...
if (unlikely(dma_addr & 0x1) || (len < 32) || (len > packet_sz))
return false;
...
if (dma_addr & 0x2)
return false;
...
}
In this case, usb request will be handled in PIO mode which renders dma mapping
operations unnecessary.
This patch adds an api to allow dma code to indicate incompatibility with usb
request. Gadget musb driver call this api, if available, before dma mappings to
avoid any unnecessary mapping operations.
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If dma buffers are mapped by a higher layer, with a boolean musb_request.mapped
it is still possible to call dma_sync_single_for_device() from
musb_g_giveback(), even if txstate()/rxstate() has called unmap_dma_buffer()
before falling back to pio mode.
Moreover, check for musb_ep->dma is moved within map_dma_buffer() so where
applicable checks for it are removed. And where possible, checks for
is_dma_capable() are merged with buffer map state check.
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We know that blackfin doesn't support double
buffering feature as of today. So we add a
flag set by musb_platform_init() to forcefully
disable that feature.
Such flag is created and marked as deprecated
to force us to find a solution for the missing
double buffering support on blackfin.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Blackfin platform doesn't support 32bits musbdma registers, so change back to
use musb_read/writew instead of musb_read/writel and simply some format casts.
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
musb_probe() only regards 0 as a wrong IRQ number, despite platform_get_irq()
that it calls returns -ENXIO in that case. It leads to musb_init_controller()
calling request_irq() with a negative IRQ number, and when it naturally
fails, the following is printed to the console:
request_irq -6 failed!
musb_init_controller failed with status -19
Fix musb_probe() to filter out the error values as well as 0.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch fixes kernel panic during s2ram, which is caused
by the below:
- musb is not put into drv data of musb platform device if
CONFIG_USB_MUSB_HDRC_HCD is defined
- glue layer driver always get musb instance via platform_get_drvdata.
The patch fixes the issue by always puting musb into drv data
of musb platform device, which is doable even the platform device
is a host controller device.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Remove kobject.h from files which don't need it, notably,
sched.h and fs.h.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Conflicts:
MAINTAINERS
arch/arm/mach-omap2/pm24xx.c
drivers/scsi/bfa/bfa_fcpim.c
Needed to update to apply fixes for which the old branch was too
outdated.
* usb-next: (132 commits)
USB: uas: Use GFP_NOIO instead of GFP_KERNEL in I/O submission path
USB: uas: Ensure we only bind to a UAS interface
USB: uas: Rename sense pipe and sense urb to status pipe and status urb
USB: uas: Use kzalloc instead of kmalloc
USB: uas: Fix up the Sense IU
usb: musb: core: kill unneeded #include's
DA8xx: assign name to MUSB IRQ resource
usb: gadget: g_ncm added
usb: gadget: f_ncm.c added
usb: gadget: u_ether: prepare for NCM
usb: pch_udc: Fix setup transfers with data out
usb: pch_udc: Fix compile error, warnings and checkpatch warnings
usb: add ab8500 usb transceiver driver
USB: gadget: Implement runtime PM for MSM bus glue driver
USB: gadget: Implement runtime PM for ci13xxx gadget
USB: gadget: Add USB controller driver for MSM SoC
USB: gadget: Introduce ci13xxx_udc_driver struct
USB: gadget: Initialize ci13xxx gadget device's coherent DMA mask
USB: gadget: Fix "scheduling while atomic" bugs in ci13xxx_udc
USB: gadget: Separate out PCI bus code from ci13xxx_udc
...
This reverts commit 32d5dc9520.
Needed to properly merge the musb changes that are in the
usb-next branch into Linus's tree.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This reverts commit 1e393c6eec.
Needed to properly merge the musb changes that are in the
usb-next branch into Linus's tree.
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
musb_core.c #include's a bunch of ARM and DaVinci specific headers, goodness
knows why -- it happily compiles without them...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
OMAP4430 supports UTMI and ULPI types of transceiver interface.
In UTMI mode: The PHY is embedded within OMAP4430. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
musb driver is register for blocking notifications from the transceiver
driver to get the event notifications for connect/disconnect and ID-GND.
Based on these events call the transceiver init/shutdown function to
configure the transceiver to toggle the VBUS valid, session end and ID_GND
signals to musb and power on/off the internal PHY.
For ID_GND event notifications, toggle the ID_GND signal and then wait for
musb to be configured as "A" device, and then call the transceiver function
to set the VBUS.
In OTG mode and musb as a host, When the Micro A connector used, VBUS is turned on
and session bit set. When the device is connected, enumeration goes through.
When the device disconnected from the other end of the connector(ID is still grounded),
link will detect the disconnect and end the session. When the device is connected back,
there are no events generated in the TWL6030-usb, and link is already down.
So the device is not detected. Removed the session bit disable code which
will recognize the connect of the device.
Limitation: In OTG host mode, if device is connected during boot, it does not get
detected. If disconnect and connect it back or connect after boot only it works.
Fix for this, I will submit seperate patch later.
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Selecting the twl6030-usb for OMAP4430SDP and OMAP4PANDA boards and
adding OMAP4 internal phy code for compilation
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Initial support for u8500 and u5500 platform.
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 4814ced511 (OMAP:
control: move plat-omap/control.h to mach-omap2/control.h)
moved <plat/control.h> to another location, preventing
drivers from accessing it, so we need to pass function
pointers from arch code to be able to talk to internal
PHY on AM35x.
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
all glue layers are now fully moved to the
new setup. We are now using dev_pm_ops to
implement suspend/resume functionality and
thus, musb_platform_suspend/resume has become
deprecated and useless.
This patch drops those function pointers and
its uses.
Signed-off-by: Felipe Balbi <balbi@ti.com>
instead of using musb_platform_suspend_resume,
we can use dev_pm_ops and let platform_device
core handle when to call musb_core's suspend and
glue layer's suspend.
Signed-off-by: Felipe Balbi <balbi@ti.com>
instead of using musb_platform_suspend_resume,
we can use dev_pm_ops and let platform_device
core handle when to call musb_core's suspend and
glue layer's suspend.
Signed-off-by: Felipe Balbi <balbi@ti.com>
instead of using musb_platform_suspend/resume,
we can use dev_pm_ops and let the platform_device
core handle when to call musb_core's suspend and
glue layer's suspend.
Signed-off-by: Felipe Balbi <balbi@ti.com>
musb core doesn't need to know about platform
specific details. So start moving clock
handling to platform glue layer and make
musb core agnostic about that.
Signed-off-by: Felipe Balbi <balbi@ti.com>
that structure currently only holds a device
pointer to our own platform_device and musb's
platform_device, but soon it will hold pointers
to our clock structures and glue-specific bits
and pieces.
Signed-off-by: Felipe Balbi <balbi@ti.com>
that structure currently only holds a device
pointer to our own platform_device and musb's
platform_device, but soon it will hold pointers
to our clock structures and glue-specific bits
and pieces.
Signed-off-by: Felipe Balbi <balbi@ti.com>
that structure currently only holds a device
pointer to our own platform_device and musb's
platform_device, but soon it will hold pointers
to our clock structures and glue-specific bits
and pieces.
Signed-off-by: Felipe Balbi <balbi@ti.com>
that structure currently only holds a device
pointer to our own platform_device and musb's
platform_device, but soon it will hold pointers
to our clock structures and glue-specific bits
and pieces.
Signed-off-by: Felipe Balbi <balbi@ti.com>
that structure currently only holds a device
pointer to our own platform_device and musb's
platform_device, but soon it will hold pointers
to our clock structures and glue-specific bits
and pieces.
Signed-off-by: Felipe Balbi <balbi@ti.com>
that structure currently only holds a device
pointer to our own platform_device and musb's
platform_device, but soon it will hold pointers
to our clock structures and glue-specific bits
and pieces.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just adding its own platform_driver, not really
using it yet.
Later patches will come to split power management
code from musb_core and move it completely to HW
glue layer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just adding its own platform_driver, not really
using it yet.
When all HW glue layers are converted, more patches
will come to split power management code from musb_core
and move it completely to HW glue layer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just adding its own platform_driver, not really
using it yet.
When all HW glue layers are converted, more patches
will come to split power management code from musb_core
and move it completely to HW glue layer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just adding its own platform_driver, not really
using it yet.
When all HW glue layers are converted, more patches
will come to split power management code from musb_core
and move it completely to HW glue layer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just adding its own platform_driver, not really
using it yet.
When all HW glue layers are converted, more patches
will come to split power management code from musb_core
and move it completely to HW glue layer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just adding its own platform_driver, not really
using it yet.
When all HW glue layers are converted, more patches
will come to split power management code from musb_core
and move it completely to HW glue layer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
change all ocurrences of musb_hdrc to musb-hdrc.
We will call glue layer drivers musb-<glue layer>,
so in order to keep things somewhat standard, let's
change the underscore into a dash.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This will make things simpler when choosing which
glue layer to compile. It avoids a lot of magic
around the "default" Kconfig option and lets the
user choose what exactly s/he wants to compile.
Signed-off-by: Felipe Balbi <balbi@ti.com>
preparing to a big refactor on musb code. We need
to be able to compile in all glue layers (or at
least all ARM-based ones) together and have a
working binary.
While preparing for that, we move every glue
layer to export only one symbol, which is
a struct musb_platform_ops, and make all
other functions static.
Later patches will come to allow for compiling
all glue layers together and have a working
binary.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This will be passed to musb_core by platform glue
layer in order to make it easier to compile support
for several HW glue layers.
Later patches will come using this structure and
also moving HW glue layers to its own platform
driver; the idea is to be able to handle platform
peculiarities in a manner which doesn't affect one
another.
Signed-off-by: Felipe Balbi <balbi@ti.com>
