RE: Root hub autosusend delay
Add rpm trace log for log 1, the coming behavior is expected, the usb subsystem will enters low power mode again. root@freescale ~$ cat /sys/kernel/debug/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 156/156 #P:4 # # _-= irqs-off # / _= need-resched #| / _---= hardirq/softirq #|| / _--= preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | idle-0 [000] d.h.48.691373: rpm_resume: ci_hdrc.0 flags-5 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 idle-0 [000] dNh.48.691389: rpm_return_int: rpm_resume+0x94/0x750:ci_hdrc.0 ret=0 kworker/0:1-53[000] d...48.691415: rpm_resume: ci_hdrc.0 flags-2 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.691418: rpm_resume: 2184000.usb flags-0 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.703000: rpm_idle: ci_hdrc.0 flags-5 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.703004: rpm_return_int: rpm_idle+0x4c/0x228:ci_hdrc.0 ret=-11 kworker/0:1-53[000] d...48.708896: rpm_idle: 2184000.usb flags-1 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.708899: rpm_return_int: rpm_idle+0x4c/0x228:2184000.usb ret=-11 kworker/0:1-53[000] d...48.708902: rpm_idle: 210.aips-bus flags-5 cnt-0 dep-1 auto-1 p-0 irq-0 child-1 kworker/0:1-53[000] d...48.708903: rpm_return_int: rpm_idle+0x4c/0x228:210.aips-bus ret=-13 kworker/0:1-53[000] d...48.708905: rpm_return_int: rpm_resume+0x94/0x750:2184000.usb ret=0 kworker/0:1-53[000] d...48.708908: rpm_idle: ci_hdrc.0 flags-1 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.708911: rpm_suspend: ci_hdrc.0 flags-1 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.708913: rpm_idle: 2184000.usb flags-1 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.708915: rpm_return_int: rpm_idle+0x4c/0x228:2184000.usb ret=-11 kworker/0:1-53[000] d...48.708917: rpm_return_int: rpm_suspend+0x370/0x6a0:ci_hdrc.0 ret=0 kworker/0:1-53[000] d...48.708918: rpm_return_int: rpm_idle+0x4c/0x228:ci_hdrc.0 ret=0 kworker/0:1-53[000] d...48.708920: rpm_idle: 2184000.usb flags-5 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.708923: rpm_return_int: rpm_idle+0x4c/0x228:2184000.usb ret=0 kworker/0:1-53[000] d...48.708925: rpm_return_int: rpm_resume+0x94/0x750:ci_hdrc.0 ret=0 kworker/0:1-53[000] d...48.708944: rpm_resume: usb1 flags-4 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.708947: rpm_resume: ci_hdrc.0 flags-0 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.708949: rpm_idle: ci_hdrc.0 flags-1 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.708951: rpm_return_int: rpm_idle+0x4c/0x228:ci_hdrc.0 ret=-11 kworker/0:1-53[000] d...48.708952: rpm_return_int: rpm_resume+0x94/0x750:ci_hdrc.0 ret=1 kworker/0:1-53[000] dN..48.710126: rpm_idle: usb1 flags-1 cnt-1 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] dN..48.710130: rpm_return_int: rpm_idle+0x4c/0x228:usb1 ret=-11 kworker/0:1-53[000] dN..48.710132: rpm_idle: ci_hdrc.0 flags-5 cnt-0 dep-0 auto-1 p-0 irq-0 child-1 kworker/0:1-53[000] dN..48.710133: rpm_return_int: rpm_idle+0x4c/0x228:ci_hdrc.0 ret=-16 kworker/0:1-53[000] dN..48.710135: rpm_return_int: rpm_resume+0x94/0x750:usb1 ret=0 kworker/0:1-53[000] d...48.710168: rpm_suspend: usb1 flags-c cnt-0 dep-0 auto-1 p-0 irq-0 child-0 kworker/0:1-53[000] d...48.710172: rpm_return_int: rpm_suspend+0x370/0x6a0:usb1 ret=0 kworker/0:1-53[000] dN..48.710181: rpm_idle: 2184000.usb flags-2 cnt-0 dep-0 auto-1 p-0 irq-0 child-1 kworker/0:1-53[000] dN..48.710183: rpm_return_int: rpm_idle+0x4c/0x228:2184000.usb ret=-16 khubd-27[000] d...48.710192: rpm_resume: 1-0:1.0 flags-4 cnt-2 dep-0 auto-1 p-0 irq-0 child-0 khubd-27[000] d...48.710195: rpm_idle: 1-0:1.0 flags-1 cnt-2 dep-0 auto-1 p-0 irq-0 child-0 khubd-27[000] d...48.710197: rpm_return_int: rpm_idle+0x4c/0x228:1-0:1.0 ret=-11 khubd-27[000] d...48.710199: rpm_return_int: rpm_resume+0x94/0x750:1-0:1.0 ret=1 khubd-27[000] d...48.710204: rpm_idle: 1-0:1.0 flags-4 cnt-0 dep-0 auto-1 p-0 irq-0 child-0 khubd-27[000] d...48.710205: rpm_suspend: 1-0:1.0 flags-4 cnt-0 dep-0 auto-1 p-0 irq-0
[PATCH 0/2] drivers/usb/host/uhci-*: fix memory flow bug and beautify source code
PATCH 1/2: check buffer length to avoid memory overflow PATCH 2/2: beautify source code PATCH 2/2 is made based on PATCH 1/2 please apply PATCH 1/2 firstly, and then apply PATCH 2/2 total stat (2 patches together): --- drivers/usb/host/uhci-debug.c | 178 +++-- drivers/usb/host/uhci-hcd.c | 31 --- drivers/usb/host/uhci-hub.c |6 +- drivers/usb/host/uhci-q.c |2 +- 4 files changed, 140 insertions(+), 77 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drivers/usb/host/uhci-* : check buffer length to avoid memory overflow
for function uhci_sprint_schedule:
the buffer len is MAX_OUTPUT: 64 * 1024, which may not be enough:
may loop UHCI_NUMFRAMES times (UHCI_NUMFRAMES is 1024)
each time of loop may get more than 64 bytes
so need check the buffer length to avoid memory overflow
this patch fix it like this:
at first, make enough room for buffering the exceeding contents
judge the contents which written whether bigger than buffer length
if bigger (the exceeding contents will be in the exceeding buffer)
break current work flow, and return.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
drivers/usb/host/uhci-debug.c | 150 -
drivers/usb/host/uhci-hcd.c |4 +-
drivers/usb/host/uhci-q.c |2 +-
3 files changed, 107 insertions(+), 49 deletions(-)
diff --git a/drivers/usb/host/uhci-debug.c b/drivers/usb/host/uhci-debug.c
index fc0b0da..8a55bb2 100644
--- a/drivers/usb/host/uhci-debug.c
+++ b/drivers/usb/host/uhci-debug.c
@@ -16,6 +16,8 @@
#include uhci-hcd.h
+#define EXTRA_SPACE1024
+
static struct dentry *uhci_debugfs_root;
#ifdef DEBUG
@@ -44,10 +46,6 @@ static int uhci_show_td(struct uhci_hcd *uhci, struct
uhci_td *td, char *buf,
char *spid;
u32 status, token;
- /* Try to make sure there's enough memory */
- if (len 160)
- return 0;
-
status = td_status(uhci, td);
out += sprintf(out, %*s[%p] link (%08x) , space, , td,
hc32_to_cpu(uhci, td-link));
@@ -64,6 +62,8 @@ static int uhci_show_td(struct uhci_hcd *uhci, struct uhci_td
*td, char *buf,
(status TD_CTRL_CRCTIMEO) ? CRC/Timeo : ,
(status TD_CTRL_BITSTUFF) ? BitStuff : ,
status 0x7ff);
+ if (out - buf len)
+ goto done;
token = td_token(uhci, td);
switch (uhci_packetid(token)) {
@@ -90,6 +90,9 @@ static int uhci_show_td(struct uhci_hcd *uhci, struct uhci_td
*td, char *buf,
spid);
out += sprintf(out, (buf=%08x)\n, hc32_to_cpu(uhci, td-buffer));
+done:
+ if (out - buf len)
+ out += sprintf(out, ...\n);
return out - buf;
}
@@ -101,8 +104,6 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
int i, nactive, ninactive;
char *ptype;
- if (len 200)
- return 0;
out += sprintf(out, urb_priv [%p] , urbp);
out += sprintf(out, urb [%p] , urbp-urb);
@@ -110,6 +111,8 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
out += sprintf(out, Dev=%d , usb_pipedevice(urbp-urb-pipe));
out += sprintf(out, EP=%x(%s) , usb_pipeendpoint(urbp-urb-pipe),
(usb_pipein(urbp-urb-pipe) ? IN : OUT));
+ if (out - buf len)
+ goto done;
switch (usb_pipetype(urbp-urb-pipe)) {
case PIPE_ISOCHRONOUS: ptype = ISO; break;
@@ -128,6 +131,9 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
out += sprintf(out, Unlinked=%d, urbp-urb-unlinked);
out += sprintf(out, \n);
+ if (out - buf len)
+ goto done;
+
i = nactive = ninactive = 0;
list_for_each_entry(td, urbp-td_list, list) {
if (urbp-qh-type != USB_ENDPOINT_XFER_ISOC
@@ -135,6 +141,8 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
out += sprintf(out, %*s%d: , space + 2, , i);
out += uhci_show_td(uhci, td, out,
len - (out - buf), 0);
+ if (out - buf len)
+ goto tail;
} else {
if (td_status(uhci, td) TD_CTRL_ACTIVE)
++nactive;
@@ -146,7 +154,10 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
out += sprintf(out, %*s[skipped %d inactive and %d active
TDs]\n,
space, , ninactive, nactive);
-
+done:
+ if (out - buf len)
+ out += sprintf(out, ...\n);
+tail:
return out - buf;
}
@@ -158,10 +169,6 @@ static int uhci_show_qh(struct uhci_hcd *uhci,
__hc32 element = qh_element(qh);
char *qtype;
- /* Try to make sure there's enough memory */
- if (len 80 * 7)
- return 0;
-
switch (qh-type) {
case USB_ENDPOINT_XFER_ISOC: qtype = ISO; break;
case USB_ENDPOINT_XFER_INT: qtype = INT; break;
@@ -182,6 +189,8 @@ static int uhci_show_qh(struct uhci_hcd *uhci,
else if (qh-type == USB_ENDPOINT_XFER_INT)
out += sprintf(out, %*speriod %d phase %d load %d us\n,
space, , qh-period, qh-phase, qh-load);
+ if (out - buf len)
+ goto done;
if
[PATCH 2/2] drivers/usb/host/uhci-*: beautify source code
get rid of the line breaks in string constants.
let comments within 80 with limitation.
delete ' \' at the end of a statement.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
drivers/usb/host/uhci-debug.c | 28
drivers/usb/host/uhci-hcd.c | 27 +--
drivers/usb/host/uhci-hub.c |6 --
3 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/host/uhci-debug.c b/drivers/usb/host/uhci-debug.c
index 8a55bb2..4557375 100644
--- a/drivers/usb/host/uhci-debug.c
+++ b/drivers/usb/host/uhci-debug.c
@@ -151,8 +151,8 @@ static int uhci_show_urbp(struct uhci_hcd *uhci, struct
urb_priv *urbp,
}
}
if (nactive + ninactive 0)
- out += sprintf(out, %*s[skipped %d inactive and %d active
- TDs]\n,
+ out += sprintf(out,
+ %*s[skipped %d inactive and %d active TDs]\n,
space, , ninactive, nactive);
done:
if (out - buf len)
@@ -182,8 +182,8 @@ static int uhci_show_qh(struct uhci_hcd *uhci,
hc32_to_cpu(uhci, qh-link),
hc32_to_cpu(uhci, element));
if (qh-type == USB_ENDPOINT_XFER_ISOC)
- out += sprintf(out, %*speriod %d phase %d load %d us,
- frame %x desc [%p]\n,
+ out += sprintf(out,
+ %*speriod %d phase %d load %d us, frame %x
desc [%p]\n,
space, , qh-period, qh-phase, qh-load,
qh-iso_frame, qh-iso_packet_desc);
else if (qh-type == USB_ENDPOINT_XFER_INT)
@@ -434,8 +434,8 @@ static int uhci_sprint_schedule(struct uhci_hcd *uhci, char
*buf, int len)
tmp = tmp-next;
if (link != LINK_TO_TD(uhci, td)) {
if (nframes 0) {
- out += sprintf(out, link does
- not match list entry!\n);
+ out += sprintf(out,
+ link does not match list
entry!\n);
if (out - buf len)
goto done;
} else
@@ -460,8 +460,8 @@ check_link:
i, hc32_to_cpu(uhci, link));
j = 1;
}
- out += sprintf(out,link does not match
- QH (%08x)!\n,
+ out += sprintf(out,
+ link does not match QH (%08x)!\n,
hc32_to_cpu(uhci, qh_dma));
if (out - buf len)
goto done;
@@ -483,7 +483,7 @@ check_link:
int cnt = 0;
qh = uhci-skelqh[i];
- out += sprintf(out, - skel_%s_qh\n, qh_names[i]); \
+ out += sprintf(out, - skel_%s_qh\n, qh_names[i]);
out += uhci_show_qh(uhci, qh, out, len - (out - buf), 4);
if (out - buf len)
goto tail;
@@ -491,7 +491,8 @@ check_link:
/* Last QH is the Terminating QH, it's different */
if (i == SKEL_TERM) {
if (qh_element(qh) != LINK_TO_TD(uhci, uhci-term_td)) {
- out += sprintf(out, skel_term_qh element
is not set to term_td!\n);
+ out += sprintf(out,
+ skel_term_qh element is not set to
term_td!\n);
if (out - buf len)
goto done;
}
@@ -530,7 +531,8 @@ check_link:
link = LINK_TO_QH(uhci, uhci-skel_term_qh);
check_qh_link:
if (qh-link != link)
- out += sprintf(out, last QH not linked to next
skeleton!\n);
+ out += sprintf(out,
+ last QH not linked to next skeleton!\n);
if (out - buf len)
goto done;
@@ -587,7 +589,9 @@ static loff_t uhci_debug_lseek(struct file *file, loff_t
off, int whence)
up = file-private_data;
- /* XXX: atomic 64bit seek access, but that needs to be fixed in the VFS
*/
+ /*
+* XXX: atomic 64bit seek access, but that needs to be fixed in the VFS
+*/
switch (whence) {
case 0:
new = off;
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 7c12b26..01628e3 100644
---
[PATCH] usb:musb: musbhsdma: change the number of dma channels according to hardware configuration
According to musbhdrd usb 2.0 high-speed dual-role controller
Product Specification
the number of dma channels can be read from register RAMINFO.
it is not always that number of dma channels is MUSB_HSDMA_CHANNELS, some
SOC may have little dma channels(for my chip, it only has 4 channel).
Signed-off-by: Yingchun Lisword.l.dra...@gmail.com
---
drivers/usb/musb/musbhsdma.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 3d1fd52..0130d82 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -57,7 +57,7 @@ static int dma_controller_stop(struct dma_controller *c)
dev_err(musb-controller,
Stopping DMA controller while channel active\n);
- for (bit = 0; bit MUSB_HSDMA_CHANNELS; bit++) {
+ for (bit = 0; bit controller-channel_count; bit++) {
if (controller-used_channels (1 bit)) {
channel = controller-channel[bit].channel;
dma_channel_release(channel);
@@ -80,7 +80,7 @@ static struct dma_channel
*dma_channel_allocate(struct dma_controller *c,
struct dma_channel *channel = NULL;
u8 bit;
- for (bit = 0; bit MUSB_HSDMA_CHANNELS; bit++) {
+ for (bit = 0; bit controller-channel_count; bit++) {
if (!(controller-used_channels (1 bit))) {
controller-used_channels |= (1 bit);
musb_channel = (controller-channel[bit]);
@@ -277,7 +277,7 @@ static irqreturn_t dma_controller_irq(int irq,
void *private_data)
if (!int_hsdma) {
dev_dbg(musb-controller, spurious DMA irq\n);
- for (bchannel = 0; bchannel MUSB_HSDMA_CHANNELS; bchannel++) {
+ for (bchannel = 0; bchannel controller-channel_count;
bchannel++) {
musb_channel = (struct musb_dma_channel *)
(controller-channel[bchannel]);
channel = musb_channel-channel;
@@ -295,7 +295,7 @@ static irqreturn_t dma_controller_irq(int irq,
void *private_data)
goto done;
}
- for (bchannel = 0; bchannel MUSB_HSDMA_CHANNELS; bchannel++) {
+ for (bchannel = 0; bchannel controller-channel_count; bchannel++) {
if (int_hsdma (1 bchannel)) {
musb_channel = (struct musb_dma_channel *)
(controller-channel[bchannel]);
@@ -386,6 +386,7 @@ struct dma_controller
*dma_controller_create(struct musb *musb, void __iomem *ba
struct device *dev = musb-controller;
struct platform_device *pdev = to_platform_device(dev);
int irq = platform_get_irq_byname(pdev, dma);
+ u8 count;
if (irq = 0) {
dev_err(dev, No DMA interrupt line!\n);
@@ -396,7 +397,9 @@ struct dma_controller
*dma_controller_create(struct musb *musb, void __iomem *ba
if (!controller)
return NULL;
- controller-channel_count = MUSB_HSDMA_CHANNELS;
+ count = musb_readb(musb-mregs, MUSB_RAMINFO) 4;
+ controller-channel_count = (count MUSB_HSDMA_CHANNELS) ?
+ MUSB_HSDMA_CHANNELS : count;
controller-private_data = musb;
controller-base = base;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Root hub autosusend delay
Hi Peter,
On Wed, Jan 23, 2013 at 2:15 PM, Peter Chen peter.c...@freescale.com wrote:
Hi Ming, I also find this problem at my platform.
(At chipidea controller, the resume signal will be ended about 21ms
automatically)
Neither delay 30ms at hub_events, nor revert your patch
(596d789a211d134dc5f94d1e5957248c204ef850) can work.
Good point, looks I can reproduce the problem on Pandaboard too,
and same result with you, but root cause of the problem is what Alan
mentioned, the port change can't be retrieved during root hub ports
resuming.
Looks a little change on my previous patch might fix the problem, could
you test the below patch to see if it can fix that on your board?
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 4225d5e..5f5a9ec 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2112,6 +2112,29 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
}
EXPORT_SYMBOL_GPL(usb_hcd_resume_root_hub);
+void usb_hcd_set_rh_ports_resuming(struct usb_device *rhdev, bool val)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave (hcd_root_hub_lock, flags);
+ rhdev-rh_resuming_ports = val;
+ spin_unlock_irqrestore (hcd_root_hub_lock, flags);
+}
+EXPORT_SYMBOL_GPL(usb_hcd_set_rh_ports_resuming);
+
+bool usb_hcd_get_rh_ports_resuming(struct usb_device *rhdev)
+{
+ unsigned long flags;
+ bool val;
+
+ spin_lock_irqsave (hcd_root_hub_lock, flags);
+ val = rhdev-rh_resuming_ports;
+ spin_unlock_irqrestore (hcd_root_hub_lock, flags);
+
+ return val;
+}
+EXPORT_SYMBOL_GPL(usb_hcd_get_rh_ports_resuming);
+
#endif /* CONFIG_USB_SUSPEND */
/*-*/
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a815fd2..0f53d38 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1034,6 +1034,15 @@ static void hub_activate(struct usb_hub *hub,
enum hub_activation_type type)
}
}
init2:
+ if (type == HUB_RESUME) {
+ /* root hub is sending resume signal, so wait for its
completion */
+ if (!hdev-parent usb_hcd_get_rh_ports_resuming(hdev)) {
+ dev_dbg(hdev-dev, wait for ports resuming over\n);
+ msleep(30);
+ usb_hcd_set_rh_ports_resuming(hdev, 0);
+ dev_dbg(hdev-dev, ports resuming over\n);
+ }
+ }
/* Check each port and set hub-change_bits to let khubd know
* which ports need attention.
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c97503b..3a90150 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -802,6 +802,7 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd)
set_bit(i, ehci-resuming_ports);
ehci_dbg (ehci, port %d remote wakeup\n, i + 1);
mod_timer(hcd-rh_timer, ehci-reset_done[i]);
+ usb_hcd_set_rh_ports_resuming(hcd-self.root_hub, 1);
}
}
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 689b14b..ea16fda 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -562,6 +562,7 @@ struct usb_device {
unsigned do_remote_wakeup:1;
unsigned reset_resume:1;
unsigned port_is_suspended:1;
+ unsigned rh_resuming_ports:1;
#endif
struct wusb_dev *wusb_dev;
int slot_id;
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 608050b..451650d 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -590,11 +590,15 @@ extern int hcd_bus_resume(struct usb_device
*rhdev, pm_message_t msg);
#ifdef CONFIG_USB_SUSPEND
extern void usb_hcd_resume_root_hub(struct usb_hcd *hcd);
+extern void usb_hcd_set_rh_ports_resuming(struct usb_device *rhdev, bool val);
+extern bool usb_hcd_get_rh_ports_resuming(struct usb_device *rhdev);
#else
static inline void usb_hcd_resume_root_hub(struct usb_hcd *hcd)
{
return;
}
+static inline void usb_hcd_set_rh_ports_resuming(struct usb_device
*rhdev, bool val) {}
+static inline bool usb_hcd_get_rh_ports_resuming(struct usb_device
*rhdev) {return false;}
#endif /* CONFIG_USB_SUSPEND */
/*-*/
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: phy: moving all PHY API definitions to usb/phy directory
On 01/23/2013 01:56 AM, Venu Byravarasu wrote:
-Original Message-
From: Roger Quadros [mailto:rog...@ti.com]
Sent: Tuesday, January 22, 2013 7:51 PM
To: Venu Byravarasu
Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-usb@vger.kernel.org;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH v2] usb: phy: moving all PHY API definitions to usb/phy
directory
On 01/22/2013 01:01 PM, Venu Byravarasu wrote:
As drivers/usb/otg/otg.c contains most of the PHY related APIs
which are not OTG specific, moving them to more logical place
under driver/usb/phy.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
delta from v1:
Missed adding newly created file usb_phy.c with previous patch.
hence sending v2, after adding that.
drivers/usb/otg/otg.c| 184
--
drivers/usb/phy/Makefile |1 +
drivers/usb/{otg/otg.c = phy/usb_phy.c} | 45 +---
3 files changed, 6 insertions(+), 224 deletions(-)
copy drivers/usb/{otg/otg.c = phy/usb_phy.c} (82%)
what about updating
drivers/usb/otg/Makefile and Kconfig?
i.e. remove CONFIG_USB_OTG_UTILS and otg.o there?
Thanks for your comments.
Those files may still be needed, as we're not removing otg.c,
due to remaining only otg function i.e. otg_state_string().
Oh yes, in that case it is fine.
--
cheers,
-roger.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Root hub autosusend delay
On Wed, Jan 23, 2013 at 04:44:54PM +0800, Ming Lei wrote:
Hi Peter,
On Wed, Jan 23, 2013 at 2:15 PM, Peter Chen peter.c...@freescale.com wrote:
Hi Ming, I also find this problem at my platform.
(At chipidea controller, the resume signal will be ended about 21ms
automatically)
Neither delay 30ms at hub_events, nor revert your patch
(596d789a211d134dc5f94d1e5957248c204ef850) can work.
Good point, looks I can reproduce the problem on Pandaboard too,
and same result with you, but root cause of the problem is what Alan
mentioned, the port change can't be retrieved during root hub ports
resuming.
Looks a little change on my previous patch might fix the problem, could
you test the below patch to see if it can fix that on your board?
Hi Ming,
As I can't apply your patch directly, I just try below code.
It works, no hub 1-0:1.0: hub_suspend is called.
init2:
+ if (type == HUB_RESUME) {
+ /* root hub is sending resume signal, so wait for its
completion */
+ if (!hdev-parent usb_hcd_get_rh_ports_resuming(hdev)) {
+ dev_dbg(hdev-dev, wait for ports resuming over\n);
+ msleep(30);
+ usb_hcd_set_rh_ports_resuming(hdev, 0);
+ dev_dbg(hdev-dev, ports resuming over\n);
+ }
+ }
Do you know the reason why hub_suspend is called if there is a
30ms delay at hub_resume? Below is the log with and without 30ms
at your patch, the process just means kick_khubd is called from
process context.
---log 1-
usb usb1: usb wakeup-resume
usb usb1: usb auto-resume
ci_hdrc ci_hdrc.0: resume root hub
hub 1-0:1.0: hub_resume
usb usb1: wait for ports resuming over
hub 1-0:1.0: port 1: status 0107 change
process
hub 1-0:1.0: state 7 ports 1 chg evt
hub 1-0:1.0: hub_suspend
usb usb1: bus auto-suspend, wakeup 1
ci_hdrc ci_hdrc.0: suspend root hub
ci_hdrc ci_hdrc.0: suspend failed because a port is resuming
usb usb1: bus suspend fail, err -16
hub 1-0:1.0: hub_resume
usb usb1: wait for ports resuming over
ci_hdrc ci_hdrc.0: GetStatus port:1 status 10001805 8 ACK POWER sig=j PE
CONNECT
hub 1-0:1.0: port 1: status 0103 change 0004
process
hub 1-0:1.0: state 7 ports 1 chg 0002 evt
ci_hdrc ci_hdrc.0: GetStatus port:1 status 10001805 8 ACK POWER sig=j PE
CONNECT
usb 1-1: usb wakeup-resume
usb 1-1: finish resume
hub 1-1:1.0: hub_resume
--log
2-
usb usb1: usb wakeup-resume
usb usb1: usb auto-resume
ci_hdrc ci_hdrc.0: resume root hub
hub 1-0:1.0: hub_resume
usb usb1: wait for ports resuming over
ci_hdrc ci_hdrc.0: GetStatus port:1 status 10001805 8 ACK POWER sig=j PE
CONNECT
hub 1-0:1.0: port 1: status 0103 change 0004
process
hub 1-0:1.0: state 7 ports 1 chg 0002 evt
ci_hdrc ci_hdrc.0: GetStatus port:1 status 10001805 8 ACK POWER sig=j PE
CONNECT
usb 1-1: usb wakeup-resume
usb 1-1: finish resume
hub 1-1:1.0: hub_resume
Thanks.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: option: add and update Alcatel modems
Adding three currently unsupported modems based on information
from .inf driver files:
Diag VID_1BBBPID_0052MI_00
AGPS VID_1BBBPID_0052MI_01
VOICE VID_1BBBPID_0052MI_02
ATVID_1BBBPID_0052MI_03
Modem VID_1BBBPID_0052MI_05
wwan VID_1BBBPID_0052MI_06
Diag VID_1BBBPID_00B6MI_00
ATVID_1BBBPID_00B6MI_01
Modem VID_1BBBPID_00B6MI_02
wwan VID_1BBBPID_00B6MI_03
Diag VID_1BBBPID_00B7MI_00
AGPS VID_1BBBPID_00B7MI_01
VOICE VID_1BBBPID_00B7MI_02
ATVID_1BBBPID_00B7MI_03
Modem VID_1BBBPID_00B7MI_04
wwan VID_1BBBPID_00B7MI_05
Updating the blacklist info for the X060S_X200 and X220_X500D,
reserving interfaces for a wwan driver, based on
wwan VID_1BBBPID_MI_04
wwan VID_1BBBPID_0017MI_06
Cc: sta...@vger.kernel.org
Signed-off-by: Bjørn Mork bj...@mork.no
---
drivers/usb/serial/option.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 0d9dac9..b51abfd 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -474,6 +474,7 @@ static const struct option_blacklist_info
four_g_w14_blacklist = {
static const struct option_blacklist_info alcatel_x200_blacklist = {
.sendsetup = BIT(0) | BIT(1),
+ .reserved = BIT(4),
};
static const struct option_blacklist_info zte_0037_blacklist = {
@@ -1203,7 +1204,14 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X060S_X200),
.driver_info = (kernel_ulong_t)alcatel_x200_blacklist
},
- { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X220_X500D) },
+ { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X220_X500D),
+ .driver_info = (kernel_ulong_t)net_intf6_blacklist },
+ { USB_DEVICE(ALCATEL_VENDOR_ID, 0x0052),
+ .driver_info = (kernel_ulong_t)net_intf6_blacklist },
+ { USB_DEVICE(ALCATEL_VENDOR_ID, 0x00b6),
+ .driver_info = (kernel_ulong_t)net_intf3_blacklist },
+ { USB_DEVICE(ALCATEL_VENDOR_ID, 0x00b7),
+ .driver_info = (kernel_ulong_t)net_intf5_blacklist },
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_L100V),
.driver_info = (kernel_ulong_t)net_intf4_blacklist },
{ USB_DEVICE(AIRPLUS_VENDOR_ID, AIRPLUS_PRODUCT_MCD650) },
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: tegra: don't touch EMC clock
Am Mittwoch, den 23.01.2013, 12:25 +0530 schrieb Venu Byravarasu: -Original Message- From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra- ow...@vger.kernel.org] On Behalf Of Stephen Warren Sent: Wednesday, January 23, 2013 5:58 AM To: Alan Stern; Greg Kroah-Hartman; Stephen Warren Cc: Venu Byravarasu; linux-te...@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-usb@vger.kernel.org; Stephen Warren Subject: [PATCH 1/2] usb: host: tegra: don't touch EMC clock From: Stephen Warren swar...@nvidia.com Clock emc is for the External Memory Controller. The USB driver has no business touching this clock directly. Remove the code that does so. Stephen, This was primarily done to make sure that EMC is set to a minimum frequency, below which data errors may occur during USB transfers. If we plan to remove this, how should we make sure that the EMC is programmed for the required frequency during USB transfers? You could use something like the API I added in ARM: tegra: add EMC clock scaling API. This needs some rework and I looked into integrating this with the DEVFREQ framework, but I don't think it fits too well. Bandwidth requirements should always be communicated to the EMC driver and not described by clock rates. Regards, Lucas -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device
Hi,
On Tue, Jan 22, 2013 at 02:04:56PM -0800, Kukjin Kim wrote:
Felipe Balbi wrote:
Hi,
Hi Felipe,
[...]
Right, DWC has version number, but that being the kind of USB controller
(USB 2.0 and USB 3.0)
DWC2: USB High Speed controller (as also indicated in the patch from
Paul: [RFC PATCH 0/6] DWC2 DesignWare HS OTG driver)
DWC3: USB Super Speed controller
Is it fine if we use something like shown below, as suggested by you
earlier ?
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,synopsis-dwc3 }
You're both missing a point here. The synopsys IP driver is called
dwc3.ko and that's compatible with synopsys,dwc3. Your glue layer driver
(dwc3-exynos.ko) is compatible with your platform, so
samsung,exynos-dwc3 sounds correct to me.
Hmm...yeah, you're right and agreed.
However, we need to use more clear name there like samsung,exynos-dwusb3
in compatible, because you know there are lots of other IPs in Synopsis
Design Ware brand. So we have to include usb in compatible for that.
fair enough.
--
balbi
signature.asc
Description: Digital signature
Re: Linux USB file storage gadget with new UDC
Hi, On Wed, Jan 23, 2013 at 03:10:50PM +0800, victor yeo wrote: Ok, rephrase the question, is this the flow for bulk transfer? 1) data is received by Usb mass storage HW, the UDC driver ISR is called to read the data to usb_request buffer 2) bulk_out_complete() in gadget driver, is called to set buffer state to full 3) get_next_command() in gadget driver, is called to read the CBW. 4) do_scsi_command() to process SCSI command encoded in CBW 5) send_status() sends the CSW to host Something like below: OUT Token - ISR - giveback() - bulk_out_complete() - get_next_command() - do_scsi_command() - usb_ep_queue() - OUT/IN Token - ISR - bulk_out_complete() - send_status() For the IN Token, i will just write the data to the HW buffer, and the flow will go to send_status(). I use a different USB cable, now the USB gadget is able to receive bulk transfer data from host PC. I am working on the bulk transfer code. Thank you for the very useful answers. np In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and intr_in. Why is the intr_out endpoint not defined? because it's not needed. Read the USB Mass Storage Class specification from usb.org -- balbi signature.asc Description: Digital signature
Re: Root hub autosusend delay
On Wed, Jan 23, 2013 at 5:38 PM, Peter Chen peter.c...@freescale.com wrote:
Hi Ming,
As I can't apply your patch directly, I just try below code.
It works, no hub 1-0:1.0: hub_suspend is called.
init2:
+ if (type == HUB_RESUME) {
+ /* root hub is sending resume signal, so wait for its
completion */
+ if (!hdev-parent usb_hcd_get_rh_ports_resuming(hdev)) {
+ dev_dbg(hdev-dev, wait for ports resuming over\n);
+ msleep(30);
+ usb_hcd_set_rh_ports_resuming(hdev, 0);
+ dev_dbg(hdev-dev, ports resuming over\n);
+ }
+ }
Do you know the reason why hub_suspend is called if there is a
30ms delay at hub_resume? Below is the log with and without 30ms
hub_suspend is called inside runtime suspend path, because no port changes
can be retrieved during root hub ports resuming after remote wakeup
event, then no new child device is found. The added 30ms will cause hcd
to know that it is safe to return the actual port change, so hub_event() will
know the port change and handle it.
In fact, hub_suspend log can still be seen immeaditely if you connect one
hub device into your host controller, but you will find that the port change
event is retrieved and no 'suspend failed because a port is resuming' shows
in the dmesg log.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, Ok, rephrase the question, is this the flow for bulk transfer? 1) data is received by Usb mass storage HW, the UDC driver ISR is called to read the data to usb_request buffer 2) bulk_out_complete() in gadget driver, is called to set buffer state to full 3) get_next_command() in gadget driver, is called to read the CBW. 4) do_scsi_command() to process SCSI command encoded in CBW 5) send_status() sends the CSW to host Something like below: OUT Token - ISR - giveback() - bulk_out_complete() - get_next_command() - do_scsi_command() - usb_ep_queue() - OUT/IN Token - ISR - bulk_out_complete() - send_status() For the IN Token, i will just write the data to the HW buffer, and the flow will go to send_status(). I use a different USB cable, now the USB gadget is able to receive bulk transfer data from host PC. I am working on the bulk transfer code. Thank you for the very useful answers. np In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and intr_in. Why is the intr_out endpoint not defined? because it's not needed. Read the USB Mass Storage Class specification from usb.org Ok. In the gadget driver, it keeps on receiving the same bulk_out data, maybe because the data is not processed. The get_next_command is not called. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C g_file_storage gadget: bulk_out_complete -- 0, 31/0 Is it because the bh-bulk_out_intended_length is 0? thanks, victor -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, On Wed, Jan 23, 2013 at 06:04:55PM +0800, victor yeo wrote: Hi, Ok, rephrase the question, is this the flow for bulk transfer? 1) data is received by Usb mass storage HW, the UDC driver ISR is called to read the data to usb_request buffer 2) bulk_out_complete() in gadget driver, is called to set buffer state to full 3) get_next_command() in gadget driver, is called to read the CBW. 4) do_scsi_command() to process SCSI command encoded in CBW 5) send_status() sends the CSW to host Something like below: OUT Token - ISR - giveback() - bulk_out_complete() - get_next_command() - do_scsi_command() - usb_ep_queue() - OUT/IN Token - ISR - bulk_out_complete() - send_status() For the IN Token, i will just write the data to the HW buffer, and the flow will go to send_status(). I use a different USB cable, now the USB gadget is able to receive bulk transfer data from host PC. I am working on the bulk transfer code. Thank you for the very useful answers. np In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and intr_in. Why is the intr_out endpoint not defined? because it's not needed. Read the USB Mass Storage Class specification from usb.org Ok. In the gadget driver, it keeps on receiving the same bulk_out data, maybe because the data is not processed. The get_next_command is not called. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C g_file_storage gadget: bulk_out_complete -- 0, 31/0 Is it because the bh-bulk_out_intended_length is 0? that data is a CBW. But aparently gadget driver queued 0-bytes, why did you unload data if req-length was zero ? another bug in your udc driver -- balbi signature.asc Description: Digital signature
[PATCH v9 09/20] mfd: omap-usb-tll: serialize access to TLL device
Get rid of the unnecessary spin_lock_irqsave/restore() as there is
no interrupt handler for this driver. Instead we serialize access
to tll_dev using a global spinlock.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-tll.c | 53 ++-
1 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index eccc65e..55c85c7 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -103,14 +103,13 @@ struct usbtll_omap {
int nch;/* num. of channels */
struct usbhs_omap_platform_data *pdata;
struct clk **ch_clk;
- /* secure the register updates */
- spinlock_t lock;
};
/*-*/
static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
static struct device *tll_dev;
+static DEFINE_SPINLOCK(tll_lock); /* serialize access to tll_dev */
/*-*/
@@ -212,7 +211,6 @@ static int usbtll_omap_probe(struct platform_device *pdev)
struct resource *res;
struct usbtll_omap *tll;
unsignedreg;
- unsigned long flags;
int ret = 0;
int i, ver;
bool needs_tll;
@@ -230,8 +228,6 @@ static int usbtll_omap_probe(struct platform_device *pdev)
return -ENODEV;
}
- spin_lock_init(tll-lock);
-
tll-pdata = pdata;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -246,8 +242,6 @@ static int usbtll_omap_probe(struct platform_device *pdev)
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
- spin_lock_irqsave(tll-lock, flags);
-
ver = usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
@@ -265,8 +259,6 @@ static int usbtll_omap_probe(struct platform_device *pdev)
break;
}
- spin_unlock_irqrestore(tll-lock, flags);
-
tll-ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll-nch]),
GFP_KERNEL);
if (!tll-ch_clk) {
@@ -286,8 +278,6 @@ static int usbtll_omap_probe(struct platform_device *pdev)
dev_dbg(dev, can't get clock : %s\n, clkname);
}
- spin_lock_irqsave(tll-lock, flags);
-
needs_tll = false;
for (i = 0; i tll-nch; i++)
needs_tll |= omap_usb_mode_needs_tll(pdata-port_mode[i]);
@@ -332,10 +322,11 @@ static int usbtll_omap_probe(struct platform_device *pdev)
}
}
- spin_unlock_irqrestore(tll-lock, flags);
pm_runtime_put_sync(dev);
/* only after this can omap_tll_enable/disable work */
+ spin_lock(tll_lock);
tll_dev = dev;
+ spin_unlock(tll_lock);
return 0;
@@ -357,7 +348,9 @@ static int usbtll_omap_remove(struct platform_device *pdev)
struct usbtll_omap *tll = platform_get_drvdata(pdev);
int i;
+ spin_lock(tll_lock);
tll_dev = NULL;
+ spin_unlock(tll_lock);
for (i = 0; i tll-nch; i++)
if (!IS_ERR(tll-ch_clk[i]))
@@ -371,13 +364,10 @@ static int usbtll_runtime_resume(struct device *dev)
{
struct usbtll_omap *tll = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = tll-pdata;
- unsigned long flags;
int i;
dev_dbg(dev, usbtll_runtime_resume\n);
- spin_lock_irqsave(tll-lock, flags);
-
for (i = 0; i tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
int r;
@@ -393,8 +383,6 @@ static int usbtll_runtime_resume(struct device *dev)
}
}
- spin_unlock_irqrestore(tll-lock, flags);
-
return 0;
}
@@ -402,13 +390,10 @@ static int usbtll_runtime_suspend(struct device *dev)
{
struct usbtll_omap *tll = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = tll-pdata;
- unsigned long flags;
int i;
dev_dbg(dev, usbtll_runtime_suspend\n);
- spin_lock_irqsave(tll-lock, flags);
-
for (i = 0; i tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
if (!IS_ERR(tll-ch_clk[i]))
@@ -416,8 +401,6 @@ static int usbtll_runtime_suspend(struct device *dev)
}
}
- spin_unlock_irqrestore(tll-lock, flags);
-
return 0;
}
[PATCH v9 19/20] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7f9c386..b21ca76 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -671,32 +671,32 @@ static int usbhs_omap_probe(struct platform_device *pdev)
}
if (is_ehci_phy_mode(pdata-port_mode[0])) {
- /* for OMAP3 , the clk set paretn fails */
+ /* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap-utmi_p1_gfclk,
omap-xclk60mhsp1_ck);
if (ret != 0)
- dev_err(dev, xclk60mhsp1_ck set parent
- failed error:%d\n, ret);
+ dev_dbg(dev, xclk60mhsp1_ck set parent failed: %d\n,
+ ret);
} else if (is_ehci_tll_mode(pdata-port_mode[0])) {
ret = clk_set_parent(omap-utmi_p1_gfclk,
omap-init_60m_fclk);
if (ret != 0)
- dev_err(dev, init_60m_fclk set parent
- failed error:%d\n, ret);
+ dev_dbg(dev, P0 init_60m_fclk set parent failed: %d\n,
+ ret);
}
if (is_ehci_phy_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_p2_gfclk,
omap-xclk60mhsp2_ck);
if (ret != 0)
- dev_err(dev, xclk60mhsp2_ck set parent
- failed error:%d\n, ret);
+ dev_dbg(dev, xclk60mhsp2_ck set parent failed: %d\n,
+ ret);
} else if (is_ehci_tll_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_p2_gfclk,
omap-init_60m_fclk);
if (ret != 0)
- dev_err(dev, init_60m_fclk set parent
- failed error:%d\n, ret);
+ dev_dbg(dev, P1 init_60m_fclk set parent failed: %d\n,
+ ret);
}
omap_usbhs_init(dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 20/20] mdf: omap-usb-host: get rid of build warning
Fixes the below build warning when driver is built-in.
drivers/mfd/omap-usb-host.c:750:12: warning:
‘usbhs_omap_remove’ defined but not used [-Wunused-function]
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index b21ca76..6b5edf6 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -791,7 +791,7 @@ static struct platform_driver usbhs_omap_driver = {
.owner = THIS_MODULE,
.pm = usbhsomap_dev_pm_ops,
},
- .remove = __exit_p(usbhs_omap_remove),
+ .remove = usbhs_omap_remove,
};
MODULE_AUTHOR(Keshava Munegowda keshava_mgo...@ti.com);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 18/20] mfd: omap-usb-host: clean up omap_usbhs_init()
We split initializing revision 1 and revision 2 into different
functions. Initialization is now done dynamically so that only
the number of ports available on the system are initialized.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c | 129 +++
1 files changed, 81 insertions(+), 48 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0740c68..7f9c386 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -358,6 +358,75 @@ static int usbhs_runtime_suspend(struct device *dev)
return 0;
}
+static unsigned omap_usbhs_rev1_hostconfig(struct usbhs_hcd_omap *omap,
+ unsigned reg)
+{
+ struct usbhs_omap_platform_data *pdata = omap-pdata;
+ int i;
+
+ for (i = 0; i omap-nports; i++) {
+ switch (pdata-port_mode[i]) {
+ case OMAP_USBHS_PORT_MODE_UNUSED:
+ reg = ~(OMAP_UHH_HOSTCONFIG_P1_CONNECT_STATUS i);
+ break;
+ case OMAP_EHCI_PORT_MODE_PHY:
+ if (pdata-single_ulpi_bypass)
+ break;
+
+ if (i == 0)
+ reg = ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
+ else
+ reg = ~(OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS
+(i-1));
+ break;
+ default:
+ if (pdata-single_ulpi_bypass)
+ break;
+
+ if (i == 0)
+ reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
+ else
+ reg |= OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS
+(i-1);
+ break;
+ }
+ }
+
+ if (pdata-single_ulpi_bypass) {
+ /* bypass ULPI only if none of the ports use PHY mode */
+ reg |= OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
+
+ for (i = 0; i omap-nports; i++) {
+ if (is_ehci_phy_mode(pdata-port_mode[i])) {
+ reg = OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
+ break;
+ }
+ }
+ }
+
+ return reg;
+}
+
+static unsigned omap_usbhs_rev2_hostconfig(struct usbhs_hcd_omap *omap,
+ unsigned reg)
+{
+ struct usbhs_omap_platform_data *pdata = omap-pdata;
+ int i;
+
+ for (i = 0; i omap-nports; i++) {
+ /* Clear port mode fields for PHY mode */
+ reg = ~(OMAP4_P1_MODE_CLEAR 2 * i);
+
+ if (is_ehci_tll_mode(pdata-port_mode[i]) ||
+ (is_ohci_port(pdata-port_mode[i])))
+ reg |= OMAP4_P1_MODE_TLL 2 * i;
+ else if (is_ehci_hsic_mode(pdata-port_mode[i]))
+ reg |= OMAP4_P1_MODE_HSIC 2 * i;
+ }
+
+ return reg;
+}
+
static void omap_usbhs_init(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
@@ -389,54 +458,18 @@ static void omap_usbhs_init(struct device *dev)
reg |= OMAP4_UHH_HOSTCONFIG_APP_START_CLK;
reg = ~OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN;
- if (is_omap_usbhs_rev1(omap)) {
- if (pdata-port_mode[0] == OMAP_USBHS_PORT_MODE_UNUSED)
- reg = ~OMAP_UHH_HOSTCONFIG_P1_CONNECT_STATUS;
- if (pdata-port_mode[1] == OMAP_USBHS_PORT_MODE_UNUSED)
- reg = ~OMAP_UHH_HOSTCONFIG_P2_CONNECT_STATUS;
- if (pdata-port_mode[2] == OMAP_USBHS_PORT_MODE_UNUSED)
- reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
-
- /* Bypass the TLL module for PHY mode operation */
- if (pdata-single_ulpi_bypass) {
- dev_dbg(dev, OMAP3 ES version = ES2.1\n);
- if (is_ehci_phy_mode(pdata-port_mode[0]) ||
- is_ehci_phy_mode(pdata-port_mode[1]) ||
- is_ehci_phy_mode(pdata-port_mode[2]))
- reg = ~OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
- else
- reg |= OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
- } else {
- dev_dbg(dev, OMAP3 ES version ES2.1\n);
- if (is_ehci_phy_mode(pdata-port_mode[0]))
- reg = ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
- else
- reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
- if (is_ehci_phy_mode(pdata-port_mode[1]))
-
[PATCH v9 14/20] mfd: omap-usb-host: override number of ports from platform data
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OMAP5
and depend on platform data (or device tree) instead.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c| 34 +++
include/linux/platform_data/usb-omap.h |1 +
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 26319ca..779588b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -493,19 +493,27 @@ static int usbhs_omap_probe(struct platform_device *pdev)
*/
pm_runtime_put_sync(dev);
- switch (omap-usbhs_rev) {
- case OMAP_USBHS_REV1:
- omap-nports = 3;
- break;
- case OMAP_USBHS_REV2:
- omap-nports = 2;
- break;
- default:
- omap-nports = OMAP3_HS_USB_PORTS;
- dev_dbg(dev,
- USB HOST Rev : 0x%d not recognized, assuming %d ports\n,
- omap-usbhs_rev, omap-nports);
- break;
+ /*
+* If platform data contains nports then use that
+* else make out number of ports from USBHS revision
+*/
+ if (pdata-nports) {
+ omap-nports = pdata-nports;
+ } else {
+ switch (omap-usbhs_rev) {
+ case OMAP_USBHS_REV1:
+ omap-nports = 3;
+ break;
+ case OMAP_USBHS_REV2:
+ omap-nports = 2;
+ break;
+ default:
+ omap-nports = OMAP3_HS_USB_PORTS;
+ dev_dbg(dev,
+USB HOST Rev:0x%d not recognized, assuming %d
ports\n,
+omap-usbhs_rev, omap-nports);
+ break;
+ }
}
for (i = 0; i omap-nports; i++)
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 04c7537..925a4a7 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -39,6 +39,7 @@ enum usbhs_omap_port_mode {
};
struct usbhs_omap_platform_data {
+ int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
int reset_gpio_port[OMAP3_HS_USB_PORTS];
struct regulator*regulator[OMAP3_HS_USB_PORTS];
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 16/20] mfd: omap-usb-host: Manage HSIC clocks for HSIC mode
Enable the optional HSIC clocks (60MHz and 480MHz) for the ports
that are configured in HSIC mode.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c | 97 --
1 files changed, 83 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9fa0215..bdfc8b7 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -93,6 +93,8 @@
struct usbhs_hcd_omap {
int nports;
struct clk **utmi_clk;
+ struct clk **hsic60m_clk;
+ struct clk **hsic480m_clk;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
@@ -286,13 +288,40 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap-ehci_logic_fck);
for (i = 0; i omap-nports; i++) {
- if (!is_ehci_tll_mode(pdata-port_mode[i]) ||
- IS_ERR(omap-utmi_clk[i]))
- continue;
-
- r = clk_enable(omap-utmi_clk[i]);
- if (r)
- dev_err(dev, Can't enable port %d clk : %d\n, i, r);
+ switch (pdata-port_mode[i]) {
+ case OMAP_EHCI_PORT_MODE_HSIC:
+ if (!IS_ERR(omap-hsic60m_clk[i])) {
+ r = clk_enable(omap-hsic60m_clk[i]);
+ if (r) {
+ dev_err(dev,
+Can't enable port %d hsic60m
clk:%d\n,
+i, r);
+ }
+ }
+
+ if (!IS_ERR(omap-hsic480m_clk[i])) {
+ r = clk_enable(omap-hsic480m_clk[i]);
+ if (r) {
+ dev_err(dev,
+Can't enable port %d hsic480m
clk:%d\n,
+i, r);
+ }
+ }
+ /* Fall through as HSIC mode needs utmi_clk */
+
+ case OMAP_EHCI_PORT_MODE_TLL:
+ if (!IS_ERR(omap-utmi_clk[i])) {
+ r = clk_enable(omap-utmi_clk[i]);
+ if (r) {
+ dev_err(dev,
+Can't enable port %d clk : %d\n,
+i, r);
+ }
+ }
+ break;
+ default:
+ break;
+ }
}
spin_unlock_irqrestore(omap-lock, flags);
@@ -312,9 +341,22 @@ static int usbhs_runtime_suspend(struct device *dev)
spin_lock_irqsave(omap-lock, flags);
for (i = 0; i omap-nports; i++) {
- if (is_ehci_tll_mode(pdata-port_mode[i])
- !IS_ERR(omap-utmi_clk[i]))
- clk_disable(omap-utmi_clk[i]);
+ switch (pdata-port_mode[i]) {
+ case OMAP_EHCI_PORT_MODE_HSIC:
+ if (!IS_ERR(omap-hsic60m_clk[i]))
+ clk_disable(omap-hsic60m_clk[i]);
+
+ if (!IS_ERR(omap-hsic480m_clk[i]))
+ clk_disable(omap-hsic480m_clk[i]);
+ /* Fall through as utmi_clks were used in HSIC mode */
+
+ case OMAP_EHCI_PORT_MODE_TLL:
+ if (!IS_ERR(omap-utmi_clk[i]))
+ clk_disable(omap-utmi_clk[i]);
+ break;
+ default:
+ break;
+ }
}
if (!IS_ERR(omap-ehci_logic_fck))
@@ -520,7 +562,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
i = sizeof(struct clk *) * omap-nports;
omap-utmi_clk = devm_kzalloc(dev, i, GFP_KERNEL);
- if (!omap-utmi_clk) {
+ omap-hsic480m_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+ omap-hsic60m_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+
+ if (!omap-utmi_clk || !omap-hsic480m_clk || !omap-hsic60m_clk) {
dev_err(dev, Memory allocation failed\n);
ret = -ENOMEM;
goto err_mem;
@@ -578,7 +623,7 @@ static int usbhs_omap_probe(struct platform_device *pdev)
}
for (i = 0; i omap-nports; i++) {
- char clkname[] = usb_host_hs_utmi_px_clk;
+ char clkname[30];
/* clock names are indexed from 1*/
snprintf(clkname, sizeof(clkname),
@@ -592,6 +637,20 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (IS_ERR(omap-utmi_clk[i]))
[PATCH v9 17/20] mfd: omap-usb-host: Get rid of unnecessary spinlock
The driver does not have an interrupt handler and
we don't really need a spinlock, so get rid of it.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index bdfc8b7..0740c68 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -23,7 +23,6 @@
#include linux/delay.h
#include linux/clk.h
#include linux/dma-mapping.h
-#include linux/spinlock.h
#include linux/gpio.h
#include linux/platform_device.h
#include linux/platform_data/usb-omap.h
@@ -108,7 +107,6 @@ struct usbhs_hcd_omap {
struct usbhs_omap_platform_data *pdata;
u32 usbhs_rev;
- spinlock_t lock;
};
/*-*/
@@ -276,13 +274,11 @@ static int usbhs_runtime_resume(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap-pdata;
- unsigned long flags;
int i, r;
dev_dbg(dev, usbhs_runtime_resume\n);
omap_tll_enable();
- spin_lock_irqsave(omap-lock, flags);
if (!IS_ERR(omap-ehci_logic_fck))
clk_enable(omap-ehci_logic_fck);
@@ -324,8 +320,6 @@ static int usbhs_runtime_resume(struct device *dev)
}
}
- spin_unlock_irqrestore(omap-lock, flags);
-
return 0;
}
@@ -333,13 +327,10 @@ static int usbhs_runtime_suspend(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap-pdata;
- unsigned long flags;
int i;
dev_dbg(dev, usbhs_runtime_suspend\n);
- spin_lock_irqsave(omap-lock, flags);
-
for (i = 0; i omap-nports; i++) {
switch (pdata-port_mode[i]) {
case OMAP_EHCI_PORT_MODE_HSIC:
@@ -362,7 +353,6 @@ static int usbhs_runtime_suspend(struct device *dev)
if (!IS_ERR(omap-ehci_logic_fck))
clk_disable(omap-ehci_logic_fck);
- spin_unlock_irqrestore(omap-lock, flags);
omap_tll_disable();
return 0;
@@ -372,7 +362,6 @@ static void omap_usbhs_init(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap-pdata;
- unsigned long flags;
unsignedreg;
dev_dbg(dev, starting TI HSUSB Controller\n);
@@ -391,7 +380,6 @@ static void omap_usbhs_init(struct device *dev)
}
pm_runtime_get_sync(dev);
- spin_lock_irqsave(omap-lock, flags);
reg = usbhs_read(omap-uhh_base, OMAP_UHH_HOSTCONFIG);
/* setup ULPI bypass and burst configurations */
@@ -454,8 +442,6 @@ static void omap_usbhs_init(struct device *dev)
usbhs_write(omap-uhh_base, OMAP_UHH_HOSTCONFIG, reg);
dev_dbg(dev, UHH setup done, uhh_hostconfig=%x\n, reg);
- spin_unlock_irqrestore(omap-lock, flags);
-
pm_runtime_put_sync(dev);
if (pdata-phy_reset) {
/* Hold the PHY in RESET for enough time till
@@ -521,8 +507,6 @@ static int usbhs_omap_probe(struct platform_device *pdev)
return -EADDRNOTAVAIL;
}
- spin_lock_init(omap-lock);
-
omap-pdata = pdata;
pm_runtime_enable(dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 15/20] mfd: omap-usb-host: cleanup clock management code
All ports have similarly named port clocks so we can
bunch them into a port data structure and use for loop
to enable/disable the clocks.
Dynamically allocate and get clocks based on number of ports
available on the platform
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c | 186 --
1 files changed, 106 insertions(+), 80 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 779588b..9fa0215 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -92,13 +92,12 @@
struct usbhs_hcd_omap {
int nports;
+ struct clk **utmi_clk;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
- struct clk *utmi_p1_fck;
- struct clk *usbhost_p1_fck;
- struct clk *utmi_p2_fck;
- struct clk *usbhost_p2_fck;
+ struct clk *utmi_p1_gfclk;
+ struct clk *utmi_p2_gfclk;
struct clk *init_60m_fclk;
struct clk *ehci_logic_fck;
@@ -276,22 +275,25 @@ static int usbhs_runtime_resume(struct device *dev)
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap-pdata;
unsigned long flags;
+ int i, r;
dev_dbg(dev, usbhs_runtime_resume\n);
omap_tll_enable();
spin_lock_irqsave(omap-lock, flags);
- if (omap-ehci_logic_fck !IS_ERR(omap-ehci_logic_fck))
+ if (!IS_ERR(omap-ehci_logic_fck))
clk_enable(omap-ehci_logic_fck);
- if (is_ehci_tll_mode(pdata-port_mode[0]))
- clk_enable(omap-usbhost_p1_fck);
- if (is_ehci_tll_mode(pdata-port_mode[1]))
- clk_enable(omap-usbhost_p2_fck);
+ for (i = 0; i omap-nports; i++) {
+ if (!is_ehci_tll_mode(pdata-port_mode[i]) ||
+ IS_ERR(omap-utmi_clk[i]))
+ continue;
- clk_enable(omap-utmi_p1_fck);
- clk_enable(omap-utmi_p2_fck);
+ r = clk_enable(omap-utmi_clk[i]);
+ if (r)
+ dev_err(dev, Can't enable port %d clk : %d\n, i, r);
+ }
spin_unlock_irqrestore(omap-lock, flags);
@@ -303,20 +305,19 @@ static int usbhs_runtime_suspend(struct device *dev)
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap-pdata;
unsigned long flags;
+ int i;
dev_dbg(dev, usbhs_runtime_suspend\n);
spin_lock_irqsave(omap-lock, flags);
- if (is_ehci_tll_mode(pdata-port_mode[0]))
- clk_disable(omap-usbhost_p1_fck);
- if (is_ehci_tll_mode(pdata-port_mode[1]))
- clk_disable(omap-usbhost_p2_fck);
-
- clk_disable(omap-utmi_p2_fck);
- clk_disable(omap-utmi_p1_fck);
+ for (i = 0; i omap-nports; i++) {
+ if (is_ehci_tll_mode(pdata-port_mode[i])
+ !IS_ERR(omap-utmi_clk[i]))
+ clk_disable(omap-utmi_clk[i]);
+ }
- if (omap-ehci_logic_fck !IS_ERR(omap-ehci_logic_fck))
+ if (!IS_ERR(omap-ehci_logic_fck))
clk_disable(omap-ehci_logic_fck);
spin_unlock_irqrestore(omap-lock, flags);
@@ -458,6 +459,7 @@ static int usbhs_omap_probe(struct platform_device *pdev)
struct resource *res;
int ret = 0;
int i;
+ boolneed_logic_fck;
if (!pdata) {
dev_err(dev, Missing platform data\n);
@@ -516,76 +518,91 @@ static int usbhs_omap_probe(struct platform_device *pdev)
}
}
- for (i = 0; i omap-nports; i++)
+ i = sizeof(struct clk *) * omap-nports;
+ omap-utmi_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+ if (!omap-utmi_clk) {
+ dev_err(dev, Memory allocation failed\n);
+ ret = -ENOMEM;
+ goto err_mem;
+ }
+
+ need_logic_fck = false;
+ for (i = 0; i omap-nports; i++) {
if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
- is_ehci_hsic_mode(i)) {
- omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
- if (IS_ERR(omap-ehci_logic_fck)) {
- ret = PTR_ERR(omap-ehci_logic_fck);
- dev_warn(dev, ehci_logic_fck failed:%d\n,
-ret);
- }
- break;
+
[PATCH v9 12/20] mfd: omap-usb-host: Use devm_kzalloc() and devm_request_and_ioremap()
Use devm_ variants of kzalloc and ioremap. Also clean up error path.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c | 38 +++---
1 files changed, 11 insertions(+), 27 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 061366d..310aaa9 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -461,15 +461,20 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (!pdata) {
dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
+ return -ENODEV;
}
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
+ omap = devm_kzalloc(dev, sizeof(*omap), GFP_KERNEL);
if (!omap) {
dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
+ return -ENOMEM;
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, uhh);
+ omap-uhh_base = devm_request_and_ioremap(dev, res);
+ if (!omap-uhh_base) {
+ dev_err(dev, Resource request/ioremap failed\n);
+ return -EADDRNOTAVAIL;
}
spin_lock_init(omap-lock);
@@ -568,20 +573,6 @@ static int usbhs_omap_probe(struct platform_device *pdev)
failed error:%d\n, ret);
}
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, uhh);
- if (!res) {
- dev_err(dev, UHH EHCI get resource failed\n);
- ret = -ENODEV;
- goto err_init_60m_fclk;
- }
-
- omap-uhh_base = ioremap(res-start, resource_size(res));
- if (!omap-uhh_base) {
- dev_err(dev, UHH ioremap failed\n);
- ret = -ENOMEM;
- goto err_init_60m_fclk;
- }
-
platform_set_drvdata(pdev, omap);
omap_usbhs_init(dev);
@@ -591,13 +582,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_alloc;
}
- goto end_probe;
+ return 0;
err_alloc:
omap_usbhs_deinit(pdev-dev);
- iounmap(omap-uhh_base);
-
-err_init_60m_fclk:
clk_put(omap-init_60m_fclk);
err_usbhost_p2_fck:
@@ -621,9 +609,7 @@ err_utmi_p1_fck:
err_end:
clk_put(omap-ehci_logic_fck);
pm_runtime_disable(dev);
- kfree(omap);
-end_probe:
return ret;
}
@@ -638,7 +624,6 @@ static int usbhs_omap_remove(struct platform_device *pdev)
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
omap_usbhs_deinit(pdev-dev);
- iounmap(omap-uhh_base);
clk_put(omap-init_60m_fclk);
clk_put(omap-usbhost_p2_fck);
clk_put(omap-usbhost_p1_fck);
@@ -648,7 +633,6 @@ static int usbhs_omap_remove(struct platform_device *pdev)
clk_put(omap-utmi_p1_fck);
clk_put(omap-ehci_logic_fck);
pm_runtime_disable(pdev-dev);
- kfree(omap);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 02/20] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data
Let's have a single platform data structure for the OMAP's High-Speed
USB host subsystem instead of having 3 separate ones i.e. one for
board data, one for USB Host (UHH) module and one for USB-TLL module.
This makes the code much simpler and avoids creating multiple copies of
platform data.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
For the ehci-omap.c part:
Acked-by: Alan Stern st...@rowland.harvard.edu
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-3630sdp.c|2 +-
arch/arm/mach-omap2/board-am3517crane.c|2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |4 +-
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/board-zoom.c |2 +-
arch/arm/mach-omap2/usb-host.c | 29 ++---
arch/arm/mach-omap2/usb.h | 20 +
drivers/mfd/omap-usb-host.c| 63 +++
drivers/mfd/omap-usb-tll.c | 11 ++---
drivers/usb/host/ehci-omap.c |6 +-
include/linux/platform_data/usb-omap.h | 23 ++
22 files changed, 61 insertions(+), 125 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..46147c8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -424,7 +424,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 050aaa7..78b1724 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -53,7 +53,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 51b96a1..26f1916 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -40,7 +40,7 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static struct usbhs_omap_board_data usbhs_bdata __initdata = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index f81a303..c76725d 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -274,7 +274,7 @@ static __init void am3517_evm_mcbsp1_init(void)
omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
}
-static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index b3102c2..cdf1d6e 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -418,7 +418,7 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct usbhs_omap_board_data usbhs_bdata __initdata = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index ebbc2ad..cfa9098 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -166,7 +166,7 @@ static inline void
[PATCH v9 07/20] mfd: omap-usb-tll: Check for missing platform data in probe
No need to check for missing platform data in runtime_suspend/resume
as it makes more sense to do it in the probe function.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-tll.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index af67b96..3dbbfea 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -225,6 +225,11 @@ static int usbtll_omap_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ if (!pdata) {
+ dev_err(dev, Platform data missing\n);
+ return -ENODEV;
+ }
+
spin_lock_init(tll-lock);
tll-pdata = pdata;
@@ -368,11 +373,6 @@ static int usbtll_runtime_resume(struct device *dev)
dev_dbg(dev, usbtll_runtime_resume\n);
- if (!pdata) {
- dev_dbg(dev, missing platform_data\n);
- return -ENODEV;
- }
-
spin_lock_irqsave(tll-lock, flags);
for (i = 0; i tll-nch; i++) {
@@ -404,11 +404,6 @@ static int usbtll_runtime_suspend(struct device *dev)
dev_dbg(dev, usbtll_runtime_suspend\n);
- if (!pdata) {
- dev_dbg(dev, missing platform_data\n);
- return -ENODEV;
- }
-
spin_lock_irqsave(tll-lock, flags);
for (i = 0; i tll-nch; i++) {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 08/20] mfd: omap-usb-tll: Fix error message
omap_enable/disable_tll() can fail if TLL device is not
initialized. It could be due to multiple reasons and not only
due to missing platform data.
Also make local variables static and use 'struct device *'
instead of 'struct platform_device *' for global reference.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-tll.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 3dbbfea..eccc65e 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -109,8 +109,8 @@ struct usbtll_omap {
/*-*/
-const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
-struct platform_device *tll_pdev;
+static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
+static struct device *tll_dev;
/*-*/
@@ -334,7 +334,8 @@ static int usbtll_omap_probe(struct platform_device *pdev)
spin_unlock_irqrestore(tll-lock, flags);
pm_runtime_put_sync(dev);
- tll_pdev = pdev;
+ /* only after this can omap_tll_enable/disable work */
+ tll_dev = dev;
return 0;
@@ -356,6 +357,8 @@ static int usbtll_omap_remove(struct platform_device *pdev)
struct usbtll_omap *tll = platform_get_drvdata(pdev);
int i;
+ tll_dev = NULL;
+
for (i = 0; i tll-nch; i++)
if (!IS_ERR(tll-ch_clk[i]))
clk_put(tll-ch_clk[i]);
@@ -436,21 +439,21 @@ static struct platform_driver usbtll_omap_driver = {
int omap_tll_enable(void)
{
- if (!tll_pdev) {
- pr_err(missing omap usbhs tll platform_data\n);
+ if (!tll_dev) {
+ pr_err(%s: OMAP USB TLL not initialized\n, __func__);
return -ENODEV;
}
- return pm_runtime_get_sync(tll_pdev-dev);
+ return pm_runtime_get_sync(tll_dev);
}
EXPORT_SYMBOL_GPL(omap_tll_enable);
int omap_tll_disable(void)
{
- if (!tll_pdev) {
- pr_err(missing omap usbhs tll platform_data\n);
+ if (!tll_dev) {
+ pr_err(%s: OMAP USB TLL not initialized\n, __func__);
return -ENODEV;
}
- return pm_runtime_put_sync(tll_pdev-dev);
+ return pm_runtime_put_sync(tll_dev);
}
EXPORT_SYMBOL_GPL(omap_tll_disable);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 10/20] mfd: omap-usb-tll: Add OMAP5 revision and HSIC support
The TLL module on OMAP5 has 3 channels.
HSIC mode requires the TLL channel to be in Transparent UTMI mode.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-tll.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 55c85c7..0aef1a7 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -54,10 +54,13 @@
#defineOMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004
* num)
#define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT 24
+#define OMAP_TLL_CHANNEL_CONF_DRVVBUS (1 16)
+#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS (1 15)
#defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11)
#defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10)
#defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9)
#defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8)
+#define OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI(2 1)
#define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS(1 1)
#defineOMAP_TLL_CHANNEL_CONF_CHANEN(1 0)
@@ -92,6 +95,7 @@
#define OMAP_USBTLL_REV1 0x0015 /* OMAP3 */
#define OMAP_USBTLL_REV2 0x0018 /* OMAP 3630 */
#define OMAP_USBTLL_REV3 0x0004 /* OMAP4 */
+#define OMAP_USBTLL_REV4 0x0006 /* OMAP5 */
#define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
@@ -245,6 +249,7 @@ static int usbtll_omap_probe(struct platform_device *pdev)
ver = usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
+ case OMAP_USBTLL_REV4:
tll-nch = OMAP_TLL_CHANNEL_COUNT;
break;
case OMAP_USBTLL_REV2:
@@ -310,6 +315,15 @@ static int usbtll_omap_probe(struct platform_device *pdev)
reg = ~(OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE
| OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF
| OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE);
+ } else if (pdata-port_mode[i] ==
+ OMAP_EHCI_PORT_MODE_HSIC) {
+ /*
+* HSIC Mode requires UTMI port configurations
+*/
+ reg |= OMAP_TLL_CHANNEL_CONF_DRVVBUS
+| OMAP_TLL_CHANNEL_CONF_CHRGVBUS
+| OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI
+| OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF;
} else {
continue;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 13/20] mfd: omap-usb-host: know about number of ports from revision register
The revision register should tell us how many ports are present.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c | 33 -
1 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 310aaa9..26319ca 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -91,6 +91,8 @@
struct usbhs_hcd_omap {
+ int nports;
+
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -347,8 +349,6 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_get_sync(dev);
spin_lock_irqsave(omap-lock, flags);
- omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
- dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);
reg = usbhs_read(omap-uhh_base, OMAP_UHH_HOSTCONFIG);
/* setup ULPI bypass and burst configurations */
@@ -483,7 +483,32 @@ static int usbhs_omap_probe(struct platform_device *pdev)
pm_runtime_enable(dev);
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
+ platform_set_drvdata(pdev, omap);
+ pm_runtime_get_sync(dev);
+
+ omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
+
+ /* we need to call runtime suspend before we update omap-nports
+* to prevent unbalanced clk_disable()
+*/
+ pm_runtime_put_sync(dev);
+
+ switch (omap-usbhs_rev) {
+ case OMAP_USBHS_REV1:
+ omap-nports = 3;
+ break;
+ case OMAP_USBHS_REV2:
+ omap-nports = 2;
+ break;
+ default:
+ omap-nports = OMAP3_HS_USB_PORTS;
+ dev_dbg(dev,
+ USB HOST Rev : 0x%d not recognized, assuming %d ports\n,
+ omap-usbhs_rev, omap-nports);
+ break;
+ }
+
+ for (i = 0; i omap-nports; i++)
if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
is_ehci_hsic_mode(i)) {
omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
@@ -573,8 +598,6 @@ static int usbhs_omap_probe(struct platform_device *pdev)
failed error:%d\n, ret);
}
- platform_set_drvdata(pdev, omap);
-
omap_usbhs_init(dev);
ret = omap_usbhs_alloc_children(pdev);
if (ret) {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 11/20] mfd: omap_usb_host: Avoid missing platform data checks in suspend/resume
Get rid of the unnecessary missing platform data checks
in runtime_suspend/resume. We are already checking for missing
platform data in probe.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-host.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index d6e6b8c..061366d 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -277,11 +277,6 @@ static int usbhs_runtime_resume(struct device *dev)
dev_dbg(dev, usbhs_runtime_resume\n);
- if (!pdata) {
- dev_dbg(dev, missing platform_data\n);
- return -ENODEV;
- }
-
omap_tll_enable();
spin_lock_irqsave(omap-lock, flags);
@@ -309,11 +304,6 @@ static int usbhs_runtime_suspend(struct device *dev)
dev_dbg(dev, usbhs_runtime_suspend\n);
- if (!pdata) {
- dev_dbg(dev, missing platform_data\n);
- return -ENODEV;
- }
-
spin_lock_irqsave(omap-lock, flags);
if (is_ehci_tll_mode(pdata-port_mode[0]))
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 06/20] mfd: omap-usb-tll: introduce and use mode_needs_tll()
This is a handy macro to check if the port requires the
USB TLL module or not. Use it to Enable the TLL module and manage
the clocks.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-tll.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index bf7355e..af67b96 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -95,6 +95,10 @@
#define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
+/* only PHY and UNUSED modes don't need TLL */
+#define omap_usb_mode_needs_tll(x) ((x) != OMAP_USBHS_PORT_MODE_UNUSED \
+(x) != OMAP_EHCI_PORT_MODE_PHY)
+
struct usbtll_omap {
int nch;/* num. of channels */
struct usbhs_omap_platform_data *pdata;
@@ -211,6 +215,7 @@ static int usbtll_omap_probe(struct platform_device *pdev)
unsigned long flags;
int ret = 0;
int i, ver;
+ bool needs_tll;
dev_dbg(dev, starting TI HSUSB TLL Controller\n);
@@ -278,12 +283,11 @@ static int usbtll_omap_probe(struct platform_device *pdev)
spin_lock_irqsave(tll-lock, flags);
- if (is_ehci_tll_mode(pdata-port_mode[0]) ||
- is_ehci_tll_mode(pdata-port_mode[1]) ||
- is_ehci_tll_mode(pdata-port_mode[2]) ||
- is_ohci_port(pdata-port_mode[0]) ||
- is_ohci_port(pdata-port_mode[1]) ||
- is_ohci_port(pdata-port_mode[2])) {
+ needs_tll = false;
+ for (i = 0; i tll-nch; i++)
+ needs_tll |= omap_usb_mode_needs_tll(pdata-port_mode[i]);
+
+ if (needs_tll) {
/* Program Common TLL register */
reg = usbtll_read(base, OMAP_TLL_SHARED_CONF);
@@ -372,7 +376,7 @@ static int usbtll_runtime_resume(struct device *dev)
spin_lock_irqsave(tll-lock, flags);
for (i = 0; i tll-nch; i++) {
- if (is_ehci_tll_mode(pdata-port_mode[i])) {
+ if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
int r;
if (IS_ERR(tll-ch_clk[i]))
@@ -408,7 +412,7 @@ static int usbtll_runtime_suspend(struct device *dev)
spin_lock_irqsave(tll-lock, flags);
for (i = 0; i tll-nch; i++) {
- if (is_ehci_tll_mode(pdata-port_mode[i])) {
+ if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
if (!IS_ERR(tll-ch_clk[i]))
clk_disable(tll-ch_clk[i]);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 05/20] mfd: omap-usb-tll: Clean up clock handling
Every channel has a functional clock that is similarly named.
It makes sense to use a for loop to manage these clocks as OMAPs
can come with up to 3 channels.
Dynamically allocate and get channel clocks depending on the
number of clocks avaiable on the platform.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/mfd/omap-usb-tll.c | 87 +++-
1 files changed, 54 insertions(+), 33 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 9a19cc7..bf7355e 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -96,10 +96,9 @@
#define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
struct usbtll_omap {
- struct clk *usbtll_p1_fck;
- struct clk *usbtll_p2_fck;
int nch;/* num. of channels */
struct usbhs_omap_platform_data *pdata;
+ struct clk **ch_clk;
/* secure the register updates */
spinlock_t lock;
};
@@ -225,26 +224,12 @@ static int usbtll_omap_probe(struct platform_device *pdev)
tll-pdata = pdata;
- tll-usbtll_p1_fck = clk_get(dev, usb_tll_hs_usb_ch0_clk);
- if (IS_ERR(tll-usbtll_p1_fck)) {
- ret = PTR_ERR(tll-usbtll_p1_fck);
- dev_err(dev, usbtll_p1_fck failed error:%d\n, ret);
- return ret;
- }
-
- tll-usbtll_p2_fck = clk_get(dev, usb_tll_hs_usb_ch1_clk);
- if (IS_ERR(tll-usbtll_p2_fck)) {
- ret = PTR_ERR(tll-usbtll_p2_fck);
- dev_err(dev, usbtll_p2_fck failed error:%d\n, ret);
- goto err_p2_fck;
- }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_request_and_ioremap(dev, res);
if (!base) {
ret = -EADDRNOTAVAIL;
dev_err(dev, Resource request/ioremap failed:%d\n, ret);
- goto err_res;
+ return ret;
}
platform_set_drvdata(pdev, tll);
@@ -270,6 +255,29 @@ static int usbtll_omap_probe(struct platform_device *pdev)
break;
}
+ spin_unlock_irqrestore(tll-lock, flags);
+
+ tll-ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll-nch]),
+ GFP_KERNEL);
+ if (!tll-ch_clk) {
+ ret = -ENOMEM;
+ dev_err(dev, Couldn't allocate memory for channel clocks\n);
+ goto err_clk_alloc;
+ }
+
+ for (i = 0; i tll-nch; i++) {
+ char clkname[] = usb_tll_hs_usb_chx_clk;
+
+ snprintf(clkname, sizeof(clkname),
+ usb_tll_hs_usb_ch%d_clk, i);
+ tll-ch_clk[i] = clk_get(dev, clkname);
+
+ if (IS_ERR(tll-ch_clk[i]))
+ dev_dbg(dev, can't get clock : %s\n, clkname);
+ }
+
+ spin_lock_irqsave(tll-lock, flags);
+
if (is_ehci_tll_mode(pdata-port_mode[0]) ||
is_ehci_tll_mode(pdata-port_mode[1]) ||
is_ehci_tll_mode(pdata-port_mode[2]) ||
@@ -321,11 +329,9 @@ static int usbtll_omap_probe(struct platform_device *pdev)
return 0;
-err_res:
- clk_put(tll-usbtll_p2_fck);
-
-err_p2_fck:
- clk_put(tll-usbtll_p1_fck);
+err_clk_alloc:
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
return ret;
}
@@ -339,9 +345,12 @@ err_p2_fck:
static int usbtll_omap_remove(struct platform_device *pdev)
{
struct usbtll_omap *tll = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i tll-nch; i++)
+ if (!IS_ERR(tll-ch_clk[i]))
+ clk_put(tll-ch_clk[i]);
- clk_put(tll-usbtll_p2_fck);
- clk_put(tll-usbtll_p1_fck);
pm_runtime_disable(pdev-dev);
return 0;
}
@@ -351,6 +360,7 @@ static int usbtll_runtime_resume(struct device *dev)
struct usbtll_omap *tll = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = tll-pdata;
unsigned long flags;
+ int i;
dev_dbg(dev, usbtll_runtime_resume\n);
@@ -361,11 +371,20 @@ static int usbtll_runtime_resume(struct device *dev)
spin_lock_irqsave(tll-lock, flags);
- if (is_ehci_tll_mode(pdata-port_mode[0]))
- clk_enable(tll-usbtll_p1_fck);
+ for (i = 0; i tll-nch; i++) {
+ if (is_ehci_tll_mode(pdata-port_mode[i])) {
+ int r;
- if (is_ehci_tll_mode(pdata-port_mode[1]))
- clk_enable(tll-usbtll_p2_fck);
+ if (IS_ERR(tll-ch_clk[i]))
+ continue;
+
+ r = clk_enable(tll-ch_clk[i]);
+
[PATCH v9 04/20] mfd: omap-usb-tll: Use devm_kzalloc/ioremap and clean up error path
Use devm_ variants of kzalloc() and ioremap(). Simplify the error path.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-tll.c | 38 --
1 files changed, 12 insertions(+), 26 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 9658e18..9a19cc7 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -215,11 +215,10 @@ static int usbtll_omap_probe(struct platform_device *pdev)
dev_dbg(dev, starting TI HSUSB TLL Controller\n);
- tll = kzalloc(sizeof(struct usbtll_omap), GFP_KERNEL);
+ tll = devm_kzalloc(dev, sizeof(struct usbtll_omap), GFP_KERNEL);
if (!tll) {
dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end;
+ return -ENOMEM;
}
spin_lock_init(tll-lock);
@@ -230,28 +229,22 @@ static int usbtll_omap_probe(struct platform_device *pdev)
if (IS_ERR(tll-usbtll_p1_fck)) {
ret = PTR_ERR(tll-usbtll_p1_fck);
dev_err(dev, usbtll_p1_fck failed error:%d\n, ret);
- goto err_tll;
+ return ret;
}
tll-usbtll_p2_fck = clk_get(dev, usb_tll_hs_usb_ch1_clk);
if (IS_ERR(tll-usbtll_p2_fck)) {
ret = PTR_ERR(tll-usbtll_p2_fck);
dev_err(dev, usbtll_p2_fck failed error:%d\n, ret);
- goto err_usbtll_p1_fck;
+ goto err_p2_fck;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, usb tll get resource failed\n);
- ret = -ENODEV;
- goto err_usbtll_p2_fck;
- }
-
- base = ioremap(res-start, resource_size(res));
+ base = devm_request_and_ioremap(dev, res);
if (!base) {
- dev_err(dev, TLL ioremap failed\n);
- ret = -ENOMEM;
- goto err_usbtll_p2_fck;
+ ret = -EADDRNOTAVAIL;
+ dev_err(dev, Resource request/ioremap failed:%d\n, ret);
+ goto err_res;
}
platform_set_drvdata(pdev, tll);
@@ -323,23 +316,17 @@ static int usbtll_omap_probe(struct platform_device *pdev)
}
spin_unlock_irqrestore(tll-lock, flags);
- iounmap(base);
pm_runtime_put_sync(dev);
tll_pdev = pdev;
- if (!ret)
- goto end;
- pm_runtime_disable(dev);
-err_usbtll_p2_fck:
+ return 0;
+
+err_res:
clk_put(tll-usbtll_p2_fck);
-err_usbtll_p1_fck:
+err_p2_fck:
clk_put(tll-usbtll_p1_fck);
-err_tll:
- kfree(tll);
-
-end:
return ret;
}
@@ -356,7 +343,6 @@ static int usbtll_omap_remove(struct platform_device *pdev)
clk_put(tll-usbtll_p2_fck);
clk_put(tll-usbtll_p1_fck);
pm_runtime_disable(pdev-dev);
- kfree(tll);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 01/20] USB: ehci-omap: Don't free gpios that we didn't request
This driver does not request any gpios so don't free them.
Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd
with ehci-omap in use.
Without this patch, EHCI will break on repeated insmod/rmmod
of ehci_hcd for all OMAP2+ platforms that use EHCI and
set 'phy_reset = true' in usbhs_omap_board_data.
i.e.
board-3430sdp.c:.phy_reset = true,
board-3630sdp.c:.phy_reset = true,
board-am3517crane.c:.phy_reset = true,
board-am3517evm.c: .phy_reset = true,
board-cm-t3517.c: .phy_reset = true,
board-cm-t35.c: .phy_reset = true,
board-devkit8000.c: .phy_reset = true,
board-igep0020.c: .phy_reset = true,
board-igep0020.c: .phy_reset = true,
board-omap3beagle.c:.phy_reset = true,
board-omap3evm.c: .phy_reset = true,
board-omap3pandora.c: .phy_reset = true,
board-omap3stalker.c: .phy_reset = true,
board-omap3touchbook.c: .phy_reset = true,
board-omap4panda.c: .phy_reset = false,
board-overo.c: .phy_reset = true,
board-zoom.c: .phy_reset = true,
CC: Alan Stern st...@rowland.harvard.edu
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: sta...@vger.kernel.org
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index ac17a7c..e9d9b09 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -288,7 +288,6 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
{
struct device *dev = pdev-dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
- struct ehci_hcd_omap_platform_data *pdata = dev-platform_data;
usb_remove_hcd(hcd);
disable_put_regulator(dev-platform_data);
@@ -298,13 +297,6 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
- if (pdata-phy_reset) {
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- gpio_free(pdata-reset_gpio_port[0]);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- gpio_free(pdata-reset_gpio_port[1]);
- }
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 00/20] OMAP USB Host cleanup
Hi Samuel, I think this series is in a pretty good shape to pull now :). I've added Reviewed-by and Acked-by tags. You can please pull from below. NOTE: the first patch is a stable fix so Greg KH might want to pick it up for 3.8-rc. The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://github.com/rogerq/linux.git linux-usbhost14-part This patchset addresses the following - Consolidate USB Host platform data. - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested). v9: - Addressed clock framework related comments from Russell King. - Removed 2 clock data patches from the series as they will be taken care of by Paul Walmsey. v8: - Re-arranged patch USB-ehci-omap-Don-t-free-gpios-that-we-didn-t-reques.patch to be the first since it is a candidate for stable. - Fixed issues raised by Felipe, i.e. indentation and use of switch () v7: - Updated patch 4 to not hold a spinlock when using clk_get(). - Updated patches 3 and 11 to return -EADDRNOTAVAIL on failure of demv_request_and_ioremap(). v6: - Added USB Host platform data consolidation patch as the first patch. based on request from Tony. - Rebased on v3.8-rc3. v5: - Rebased on top of todays arm-soc/for-next. - Removed the clock merging patch from the list. - Updated patches 14, 19 and 20 to accomodate the above change. - Added patch 22 to fix a build warning. v4: - Added appropriate maintainers in to/cc. - minor print message fix in patch 23 to maintain consistency. v3: - Rebased on arm-soc/for-next commit f979306c4d38d213c6977aaf3b1115e8ded71e3a. - Rearranged patch that get rids of cpu_is_omap..() macros. - Coding style fixes. v2: - Clocks are allocated dynamically based on number of ports available on the platform. - Reduced console spam if non critical clocks are not found on the platform. - Get rid of cpu_is_.. macros from USB host driver. cheers, -roger --- Roger Quadros (20): USB: ehci-omap: Don't free gpios that we didn't request mfd: omap-usb-host: Consolidate OMAP USB-HS platform data mfd: omap-usb-tll: Fix channel count detection mfd: omap-usb-tll: Use devm_kzalloc/ioremap and clean up error path mfd: omap-usb-tll: Clean up clock handling mfd: omap-usb-tll: introduce and use mode_needs_tll() mfd: omap-usb-tll: Check for missing platform data in probe mfd: omap-usb-tll: Fix error message mfd: omap-usb-tll: serialize access to TLL device mfd: omap-usb-tll: Add OMAP5 revision and HSIC support mfd: omap_usb_host: Avoid missing platform data checks in suspend/resume mfd: omap-usb-host: Use devm_kzalloc() and devm_request_and_ioremap() mfd: omap-usb-host: know about number of ports from revision register mfd: omap-usb-host: override number of ports from platform data mfd: omap-usb-host: cleanup clock management code mfd: omap-usb-host: Manage HSIC clocks for HSIC mode mfd: omap-usb-host: Get rid of unnecessary spinlock mfd: omap-usb-host: clean up omap_usbhs_init() mfd: omap-usb-host: Don't spam console on clk_set_parent failure mdf: omap-usb-host: get rid of build warning arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-3630sdp.c|2 +- arch/arm/mach-omap2/board-am3517crane.c|2 +- arch/arm/mach-omap2/board-am3517evm.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-igep0020.c |4 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-zoom.c |2 +- arch/arm/mach-omap2/usb-host.c | 29 +-- arch/arm/mach-omap2/usb.h | 20 +- drivers/mfd/omap-usb-host.c| 558 +--- drivers/mfd/omap-usb-tll.c | 243 +++-- drivers/usb/host/ehci-omap.c | 14 +- include/linux/platform_data/usb-omap.h | 24 +- 22 files changed, 497 insertions(+), 425 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 03/20] mfd: omap-usb-tll: Fix channel count detection
Fix channel count detecion for REV2. Also, don't give up
if we don't recognize the IP Revision. We assume the default
number of channels (i.e. 3) for unrecognized IPs.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/omap-usb-tll.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e459489..9658e18 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -98,6 +98,7 @@
struct usbtll_omap {
struct clk *usbtll_p1_fck;
struct clk *usbtll_p2_fck;
+ int nch;/* num. of channels */
struct usbhs_omap_platform_data *pdata;
/* secure the register updates */
spinlock_t lock;
@@ -210,7 +211,7 @@ static int usbtll_omap_probe(struct platform_device *pdev)
unsignedreg;
unsigned long flags;
int ret = 0;
- int i, ver, count;
+ int i, ver;
dev_dbg(dev, starting TI HSUSB TLL Controller\n);
@@ -262,16 +263,18 @@ static int usbtll_omap_probe(struct platform_device *pdev)
ver = usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
- case OMAP_USBTLL_REV2:
- count = OMAP_TLL_CHANNEL_COUNT;
+ tll-nch = OMAP_TLL_CHANNEL_COUNT;
break;
+ case OMAP_USBTLL_REV2:
case OMAP_USBTLL_REV3:
- count = OMAP_REV2_TLL_CHANNEL_COUNT;
+ tll-nch = OMAP_REV2_TLL_CHANNEL_COUNT;
break;
default:
- dev_err(dev, TLL version failed\n);
- ret = -ENODEV;
- goto err_ioremap;
+ tll-nch = OMAP_TLL_CHANNEL_COUNT;
+ dev_dbg(dev,
+USB TLL Rev : 0x%x not recognized, assuming %d channels\n,
+ ver, tll-nch);
+ break;
}
if (is_ehci_tll_mode(pdata-port_mode[0]) ||
@@ -291,7 +294,7 @@ static int usbtll_omap_probe(struct platform_device *pdev)
usbtll_write(base, OMAP_TLL_SHARED_CONF, reg);
/* Enable channels now */
- for (i = 0; i count; i++) {
+ for (i = 0; i tll-nch; i++) {
reg = usbtll_read(base, OMAP_TLL_CHANNEL_CONF(i));
if (is_ohci_port(pdata-port_mode[i])) {
@@ -319,7 +322,6 @@ static int usbtll_omap_probe(struct platform_device *pdev)
}
}
-err_ioremap:
spin_unlock_irqrestore(tll-lock, flags);
iounmap(base);
pm_runtime_put_sync(dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] net: cdc_mbim: send ZLP only for the specific buggy device
Reverting 328d7b8 and instead adding an exception for the
Sierra Wireless MC7710.
commit 328d7b8 (net: cdc_mbim: send ZLP after max sized NTBs)
added a workaround for an issue observed on one specific device.
Concerns were raised that this workaround adds a performance
penalty to all devices based on questionable, if not buggy,
behaviour of a single device:
If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU
load, increasing interrupt load by factor of 2 in high load traffic
scenario and possibly decreasing throughput for all other devices
which behaves correctly.
The idea of NCM was to avoid extra ZLPs. If your transfer is exactly
dwNtbOutMaxSize, it's known, you can submit such request on the receiver
side and you do not need any EOT indicatation, so the frametime can be
used for useful data.
Adding a device specific exception to prevent the workaround from
affecting well behaved devices.
The assumption here is that needing a ZLP is truly an *exception*.
We do not yet have enough data to verify this. The generic
workaround in commit 328d7b8 should be considered acceptable despite
the performance penalty if the exception list becomes a maintainance
hassle.
Cc: Alexey ORISHKO alexey.oris...@stericsson.com
Cc: Yauheni Kaliuta y.kali...@gmail.com
Signed-off-by: Bjørn Mork bj...@mork.no
---
Sorry about all the back and forth here. And as indicated in the commit
message, I am not guaranteeing this is the last round either...
I am not going to maintain an ever-growing exception list. My personal
accptance limit for such lists in a class driver is extremely low. I am
going to reconsider the original patch the next time a device wants this
specific workaround. And I fear that will happen really soon, based on
the facts that the device the issue in question
- is based on Qualcomm firmware,
- is commercially available now,
- is just one of a gazillion expected Qualcomm hardware/firmware based
MBIM devices on their way to a Linux computer near you...
Yes the firmware is of course buggy as hell. We don't expect anything
else. But it doesn't matter. If a significant number of MBIM devices
from a number of different vendors have the same bug, then we will do
what's needed to support them. Including accepting smaller performance
penalties not noticable to any end user. In fact not even measurable to
anyone without device firmware debugging tools.
But please let this go into 3.8 for now, and let us all hope I am wrong
this time too, as I often am :-)
Bjørn
drivers/net/usb/cdc_mbim.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 3a5673a..248d2dc 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -366,6 +366,21 @@ err:
static const struct driver_info cdc_mbim_info = {
.description = CDC MBIM,
+ .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN,
+ .bind = cdc_mbim_bind,
+ .unbind = cdc_mbim_unbind,
+ .manage_power = cdc_mbim_manage_power,
+ .rx_fixup = cdc_mbim_rx_fixup,
+ .tx_fixup = cdc_mbim_tx_fixup,
+};
+
+/* MBIM and NCM devices should not need a ZLP after NTBs with
+ * dwNtbOutMaxSize length. This driver_info is for the exceptional
+ * devices requiring it anyway, allowing them to be supported without
+ * forcing the performance penalty on all the sane devices.
+ */
+static const struct driver_info cdc_mbim_info_zlp = {
+ .description = CDC MBIM,
.flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN | FLAG_SEND_ZLP,
.bind = cdc_mbim_bind,
.unbind = cdc_mbim_unbind,
@@ -385,6 +400,10 @@ static const struct usb_device_id mbim_devs[] = {
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_NCM,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)cdc_mbim_info,
},
+ /* Sierra Wireless MC7710 need ZLPs */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x68a2, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)cdc_mbim_info_zlp,
+ },
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)cdc_mbim_info,
},
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: musb: fix context save over suspend.
Hi, I faced the same issue on OMAP4 and made similar fix a week ago: http://review.omapzoom.org/31700 but in this patch I also check is the MUSB is already suspended (so the context is already saved) in .suspend callback so reading/writing to MUSB register is more safe. It is almost same solution as we had a long time ago. -- Best regards, Ruslan Bilovol From: linux-usb-ow...@vger.kernel.org [linux-usb-ow...@vger.kernel.org] on behalf of Igor Grinberg [grinb...@compulab.co.il] Sent: Tuesday, January 22, 2013 11:12 AM To: NeilBrown Cc: Balbi, Felipe; Greg Kroah-Hartman; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org; Kevin Hilman Subject: Re: [PATCH] usb: musb: fix context save over suspend. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks like Kevin has a new address: Kevin Hilman khil...@deeprootsystems.com On 01/21/13 23:38, NeilBrown wrote: On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/21/13 11:28, NeilBrown wrote: The standard suspend sequence involves runtime_resuming devices before suspending the system. So just saving context in runtime_suspend and restoring it in runtime resume isn't enough. We must also save in suspend and restore in resume. Without this patch, and OMAP3 system with off_mode enabled will find the musb port non-functional after suspend/resume. With the patch it works perfectly. Hmmm... Some time ago, this has been removed in 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path) Am I missing something? Or things changed and now this patch is correct? Hi Igor, thanks for alerting me to that patch does anyone else get the feeling that power management to too complex to be understood by a mere human? That commit (5d193ce8) suggests that the musb-hdrc device is an 'omap_device', or maybe has a PM domain set to something else. However it isn't/doesn't. dev-pm_domain is NULL. So no PM domain layer will ever call the musb_core musb_runtime_suspend/resume. The parent device - musb-omap2430 - is an omap device, does have pm_domain set, and does have its omap2430_runtime_suspend/resume called for system suspend and so the context for that device is saved and restored. However that doesn't help the context for musb-hdrc. Whether musb ever was an omap_device is beyond my archaeological skills to determine. Kevin: Was musb-hdrc ever a device with a pm_domain? or was it only ever the various possible parents that had domains? Are you able to defend your earlier patch in today's kernel? It certainly causes my device not to work properly. Thanks, NeilBrown Signed-off-by: NeilBrown ne...@suse.de diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index fd34867..b6ccc02 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev) } spin_unlock_irqrestore(musb-lock, flags); + musb_save_context(musb); return 0; } @@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev) * unless for some reason the whole soc powered down or the USB * module got reset through the PSC (vs just being disabled). */ + struct musb *musb = dev_to_musb(dev); + musb_restore_context(musb); return 0; } - -- Regards, Igor. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ/lgWAAoJEBDE8YO64EfacIAP/3nyXjs8QQpcD6RcNuRSLp3O veKU2grzsUOL/Eu/8TQMM7WDz5n8YlycQ6/THNGGYojjOlEimDC02wbsI4gc5j41 QC1/XGf62Nlxv6CzORzkGkUoKXtVWzgMYKddWKPEwsXMKPun/LH4ZGDp+7Rkfcmu U0k7LM1Pv487iG9pF3Bq5BPYeMxyxyFJC0PiQEK1ZE65RKWbCvInibc7p1bvZ+XX JQxf8Qx1p/kBhqWc6LLpcHT5Z3B/F+3rxEhvf8lSu5fdRPHFffcmuX7bIbC/GlTe e6mODA114mtn5YbaKCmnYExvJcpz4Nziy+8fGLJ56aAyeKI1wsOJzhWDpSKwQiIF CVtYulk5iIfaeUA4sAzvRqEu7dJuaVgm6mEeGHQjebPastYhK7vHjiEOJJ2+LQrs 698A9wMLckp4AQ75HiwXRgi5N0W528gD8piNoIA9Sh1LwyytIa5Wg7uYw14UjtLJ QIerm0v6Ay+8FbVfmpm9k0v3HkYfv0ZVTSdtIXVAE30+WKIBTn0yszxWYo6JZtvj p0NEFUNVuR3C9k/xyzkcqwJh8Q6DrleWJeHWL59xgWWKzfeDKjU/DMOuWmuVEkTO aRdAlW32VDtUeWlWz3Jz3IOWZRJQKCW2o97n/MDyxwMoRiMWcHxYw6jti6se9S7a IGZeEMCcf39fnH5o7i2q =nwGe -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and intr_in. Why is the intr_out endpoint not defined? because it's not needed. Read the USB Mass Storage Class specification from usb.org Ok. In the gadget driver, it keeps on receiving the same bulk_out data, maybe because the data is not processed. The get_next_command is not called. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C g_file_storage gadget: bulk_out_complete -- 0, 31/0 Is it because the bh-bulk_out_intended_length is 0? that data is a CBW. But aparently gadget driver queued 0-bytes, why did you unload data if req-length was zero ? another bug in your udc driver In my udc driver, i set the req-length to the number of bytes i received from HW, which is 31 bytes. Is it necessary to do that? How to know the gadget driver queued 0-bytes? By bh-bulk_out_intended_length ? thanks, victor -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, On Wed, Jan 23, 2013 at 07:17:44PM +0800, victor yeo wrote: In fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and intr_in. Why is the intr_out endpoint not defined? because it's not needed. Read the USB Mass Storage Class specification from usb.org Ok. In the gadget driver, it keeps on receiving the same bulk_out data, maybe because the data is not processed. The get_next_command is not called. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C g_file_storage gadget: bulk_out_complete -- 0, 31/0 Is it because the bh-bulk_out_intended_length is 0? that data is a CBW. But aparently gadget driver queued 0-bytes, why did you unload data if req-length was zero ? another bug in your udc driver In my udc driver, i set the req-length to the number of bytes i received from HW, which is 31 bytes. Is it necessary to do that? How you shouldn't touch req-lenght, you should only update req-actual. req-length is readonly for the UDC. to know the gadget driver queued 0-bytes? By bh-bulk_out_intended_length ? read req-length -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/4] ARM: OMAP: devices: create device for usb part of control module
Hi, On Mon, Jan 21, 2013 at 07:38:26PM +0530, Kishon Vijay Abraham I wrote: A seperate driver has been added to handle the usb part of control module. A device for the above driver is created here, using the register address information to be used by the driver for powering on the PHY and for writing to the mailbox. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Tony ? Without this we won't have the control module driver. -- balbi signature.asc Description: Digital signature
Re: Linux USB file storage gadget with new UDC
Hi, Ok. In the gadget driver, it keeps on receiving the same bulk_out data, maybe because the data is not processed. The get_next_command is not called. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C g_file_storage gadget: bulk_out_complete -- 0, 31/0 Is it because the bh-bulk_out_intended_length is 0? that data is a CBW. But aparently gadget driver queued 0-bytes, why did you unload data if req-length was zero ? another bug in your udc driver In my udc driver, i set the req-length to the number of bytes i received from HW, which is 31 bytes. Is it necessary to do that? How you shouldn't touch req-lenght, you should only update req-actual. req-length is readonly for the UDC. to know the gadget driver queued 0-bytes? By bh-bulk_out_intended_length ? read req-length i removed setting the req-length in udc driver. Now in the bulk_out_complete(), the value of req-length is 512. who set it to 512? thanks, victor -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, On Wed, Jan 23, 2013 at 07:35:41PM +0800, victor yeo wrote: Hi, Ok. In the gadget driver, it keeps on receiving the same bulk_out data, maybe because the data is not processed. The get_next_command is not called. g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 b5 ea 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00^C g_file_storage gadget: bulk_out_complete -- 0, 31/0 Is it because the bh-bulk_out_intended_length is 0? that data is a CBW. But aparently gadget driver queued 0-bytes, why did you unload data if req-length was zero ? another bug in your udc driver In my udc driver, i set the req-length to the number of bytes i received from HW, which is 31 bytes. Is it necessary to do that? How you shouldn't touch req-lenght, you should only update req-actual. req-length is readonly for the UDC. to know the gadget driver queued 0-bytes? By bh-bulk_out_intended_length ? read req-length i removed setting the req-length in udc driver. Now in the bulk_out_complete(), the value of req-length is 512. who set it to 512? Read the code and you will figure it out. -- balbi signature.asc Description: Digital signature
[PATCH 0/9] Towards configfs in mass storage
The prerequisite for providing the configfs interface for mass storage and all its users is converting them to the new function interface from Sebastian. This patch series serves the purpose stated above. The plan for the conversion is as follows: - identify all users of mass storage (acm_ms, mass_storage, multi) - get rid of #including the storage_common.c file by using separate compilation - make f_mass_storage a separately compiled module with the new interface a) create a header file b) convert to the new function interface c) provide compatibility for the mass storage's users - convert the users of mass storage one by one to the new interface - remove the compatibility for old style mass storage users - merge separately compiled object files storage_common.o and f_mass_storage.o into one module (at this point there is no purpose in having a separate utiltiy module) The series depends on Sebastian's series found here: http://www.spinics.net/lists/linux-usb/msg76378.html @Sebastian: Felipe reports that there are problems with applying some of the patches in your series. Are you willing to fix the problem? Andrzej Pietrasiewicz (9): usb/gadget: create utility for mass_storage usb/gadget: allow not clearing the memory for struct fsg_common usb/gadget: create header file for f_mass_storage usb/gadget: convert f_mass_storage to new function interface with backward compatibility usb/gadget: convert acm_ms to new function interface usb/gadget: convert mass_storage to new function interface usb/gadget: convert multi to new function interface usb/gadget: remove compatibility layer for f_mass_storage usb/gadget: merge mass storage utility object with f_mass_storage object drivers/usb/gadget/Kconfig |6 + drivers/usb/gadget/Makefile |2 + drivers/usb/gadget/acm_ms.c | 77 + drivers/usb/gadget/f_mass_storage.c | 286 +++- drivers/usb/gadget/f_mass_storage.h | 196 + drivers/usb/gadget/mass_storage.c | 122 +- drivers/usb/gadget/multi.c | 68 ++-- drivers/usb/gadget/storage_common.c | 317 ++- drivers/usb/gadget/storage_common.h | 208 +++ 9 files changed, 735 insertions(+), 547 deletions(-) create mode 100644 drivers/usb/gadget/f_mass_storage.h create mode 100644 drivers/usb/gadget/storage_common.h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] usb/gadget: create utility for mass_storage
This aims at making f_mass_storage.c a module. But first
we need to get rid of #include storage_common.c.
This patch makes mass_storage.c a separately compiled
file, which is built as a utility module named u_ms.ko.
After all mass storage users are converted to the new
function interface this module can be eliminated by merging
it with the mass storage function's module.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |6 +
drivers/usb/gadget/Makefile |2 +
drivers/usb/gadget/f_mass_storage.c | 53 ++-
drivers/usb/gadget/mass_storage.c |9 +
drivers/usb/gadget/storage_common.c | 317 ++-
drivers/usb/gadget/storage_common.h | 208 +++
6 files changed, 326 insertions(+), 269 deletions(-)
create mode 100644 drivers/usb/gadget/storage_common.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index e8d2f8e..9cc5260 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -510,6 +510,9 @@ config USB_F_SS_LB
config USB_U_SERIAL
tristate
+config USB_U_MS
+ tristate
+
choice
tristate USB Gadget Drivers
default USB_ETH
@@ -736,6 +739,7 @@ config USB_MASS_STORAGE
tristate Mass Storage Gadget
depends on BLOCK
select USB_LIBCOMPOSITE
+ select USB_U_MS
help
The Mass Storage Gadget acts as a USB Mass Storage disk drive.
As its storage repository it can use a regular file or a block
@@ -848,6 +852,7 @@ config USB_G_ACM_MS
select USB_LIBCOMPOSITE
select USB_U_SERIAL
select USB_F_ACM
+ select USB_U_MS
help
This driver provides two functions in one configuration:
a mass storage, and a CDC ACM (serial port) link.
@@ -862,6 +867,7 @@ config USB_G_MULTI
select USB_LIBCOMPOSITE
select USB_U_SERIAL
select USB_F_ACM
+ select USB_U_MS
help
The Multifunction Composite Gadget provides Ethernet (RNDIS
and/or CDC Ethernet), mass storage and ACM serial link
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 070eb33..01a16a2 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -79,4 +79,6 @@ obj-$(CONFIG_USB_GADGET_TARGET) += tcm_usb_gadget.o
obj-$(CONFIG_USB_F_ACM)+= f_acm.o
f_ss_lb-y := f_loopback.o f_sourcesink.o
obj-$(CONFIG_USB_F_SS_LB) += f_ss_lb.o
+u_ms-y := storage_common.o
+obj-$(CONFIG_USB_U_MS) += u_ms.o
obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index fc5c16c..35c6144 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -228,7 +228,32 @@
static const char fsg_string_interface[] = Mass Storage;
-#include storage_common.c
+#include storage_common.h
+
+/* Static strings, in UTF-8 (for simplicity we use only ASCII characters) */
+static struct usb_string fsg_strings[] = {
+ {FSG_STRING_INTERFACE, fsg_string_interface},
+ {}
+};
+
+static struct usb_gadget_strings fsg_stringtab = {
+ .language = 0x0409, /* en-us */
+ .strings= fsg_strings,
+};
+
+#ifdef CONFIG_USB_GADGET_DEBUG_FILES
+
+static unsigned int fsg_num_buffers = CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS;
+
+#else
+
+/*
+ * Number of buffers we will use.
+ * 2 is usually enough for good buffering pipeline
+ */
+#define fsg_num_buffersCONFIG_USB_GADGET_STORAGE_NUM_BUFFERS
+
+#endif /* CONFIG_USB_DEBUG */
/*-*/
@@ -2605,6 +2630,16 @@ static inline void fsg_common_put(struct fsg_common
*common)
kref_put(common-ref, fsg_common_release);
}
+/* check if fsg_num_buffers is within a valid range */
+static inline int fsg_num_buffers_validate(void)
+{
+ if (fsg_num_buffers = 2 fsg_num_buffers = 4)
+ return 0;
+ pr_err(fsg_num_buffers %u is out of range (%d to %d)\n,
+ fsg_num_buffers, 2 ,4);
+ return -EINVAL;
+}
+
static struct fsg_common *fsg_common_init(struct fsg_common *common,
struct usb_composite_dev *cdev,
struct fsg_config *cfg)
@@ -3007,7 +3042,7 @@ struct fsg_module_parameters {
S_IRUGO);\
MODULE_PARM_DESC(prefix ## name, desc)
-#define FSG_MODULE_PARAMETERS(prefix, params) \
+#define __FSG_MODULE_PARAMETERS(prefix, params)
\
_FSG_MODULE_PARAM_ARRAY(prefix, params, file, charp,\
names of backing
[PATCH 2/9] usb/gadget: allow not clearing the memory for struct fsg_common
This patch is needed to prepare for using the new function interface.
The memory for struct fsg_common can either be provided
by the mass storage user, or it can be allocated by mass storage.
With the new function interface it will be provided by the mass storage user.
The new function interface uses function instances and functions
(@Sebastian: I really don't like this naming scheme because it means a
function instance IS NOT an instance of struct usb_function).
The function instance is allocated by the function code (e.g. f_mass_storage)
which in fact can allocate a greater structure containing a struct
usb_function_instance and return the pointer to the said component.
It is the well known container_of technique: when using the new
function interface, after the stuct usb_function_instance is obtained
with usb_get_function_instance(mass_storage), the struct fsg_common
is reached with container_of. Later, fsg_common_init needs to be called,
and it used to clear the entire struct with memset. Now it is no good,
since it clears the component struct usb_function_instance which already
contains important data. This patch adds an option not to clear
the struct, which in this case has been allocated with kzalloc anyway.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_mass_storage.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 35c6144..7bb3587 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -2640,9 +2640,9 @@ static inline int fsg_num_buffers_validate(void)
return -EINVAL;
}
-static struct fsg_common *fsg_common_init(struct fsg_common *common,
+static struct fsg_common *fsg_common_init_memset(struct fsg_common *common,
struct usb_composite_dev *cdev,
- struct fsg_config *cfg)
+ struct fsg_config *cfg, bool zero)
{
struct usb_gadget *gadget = cdev-gadget;
struct fsg_buffhd *bh;
@@ -2669,7 +2669,8 @@ static struct fsg_common *fsg_common_init(struct
fsg_common *common,
return ERR_PTR(-ENOMEM);
common-free_storage_on_release = 1;
} else {
- memset(common, 0, sizeof *common);
+ if (zero)
+ memset(common, 0, sizeof *common);
common-free_storage_on_release = 0;
}
@@ -2846,6 +2847,13 @@ error_release:
return ERR_PTR(rc);
}
+static struct fsg_common *fsg_common_init(struct fsg_common *common,
+ struct usb_composite_dev *cdev,
+ struct fsg_config *cfg)
+{
+ return fsg_common_init_memset(common, cdev, cfg, true);
+}
+
static void fsg_common_release(struct kref *ref)
{
struct fsg_common *common = container_of(ref, struct fsg_common, ref);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] usb/gadget: convert acm_ms to new function interface
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |1 +
drivers/usb/gadget/acm_ms.c | 78 ---
2 files changed, 45 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index adbc434..3cdd10a 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -856,6 +856,7 @@ config USB_G_ACM_MS
select USB_U_SERIAL
select USB_F_ACM
select USB_U_MS
+ select USB_F_MASS_STORAGE
help
This driver provides two functions in one configuration:
a mass storage, and a CDC ACM (serial port) link.
diff --git a/drivers/usb/gadget/acm_ms.c b/drivers/usb/gadget/acm_ms.c
index 0af60f3..2fc559c 100644
--- a/drivers/usb/gadget/acm_ms.c
+++ b/drivers/usb/gadget/acm_ms.c
@@ -33,15 +33,7 @@
/*-*/
-/*
- * Kbuild is not very cooperative with respect to linking separately
- * compiled library objects into one module. So for now we won't use
- * separate compilation ... ensuring init/exit sections work to shrink
- * the runtime footprint, and giving us at least some parts of what
- * a gcc --combine ... part1.c part2.c part3.c ... build would.
- */
-#define USB_FMS_INCLUDED
-#include f_mass_storage.c
+#include f_mass_storage.h
/*-*/
USB_GADGET_COMPOSITE_OPTIONS();
@@ -107,16 +99,20 @@ static struct usb_gadget_strings *dev_strings[] = {
static struct fsg_module_parameters fsg_mod_data = { .stall = 1 };
FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
-static struct fsg_common fsg_common;
-
/*-*/
static struct usb_function *f_acm;
static struct usb_function_instance *f_acm_inst;
+
+static struct usb_function *f_fsg;
+static struct usb_function_instance *f_fsg_inst;
+
/*
* We _always_ have both ACM and mass storage functions.
*/
static int __init acm_ms_do_config(struct usb_configuration *c)
{
+ struct fsg_config config;
+ struct fsg_common *common;
int status;
if (gadget_is_otg(c-cdev-gadget)) {
@@ -131,23 +127,49 @@ static int __init acm_ms_do_config(struct
usb_configuration *c)
f_acm = usb_get_function(f_acm_inst);
if (IS_ERR(f_acm)) {
status = PTR_ERR(f_acm);
- goto err_func;
+ goto err_acm_func;
}
status = usb_add_function(c, f_acm);
if (status 0)
- goto err_conf;
+ goto err_acm_conf;
+
+ f_fsg_inst = usb_get_function_instance(mass_storage);
+ if (IS_ERR(f_fsg_inst)) {
+ status = PTR_ERR(f_fsg_inst);
+ goto err_acm;
+ }
+
+ common = container_of(f_fsg_inst, struct fsg_common, func_inst);
+ fsg_config_from_params(config, fsg_mod_data);
+ common = fsg_common_init_memset(common, c-cdev, config, false);
+ if (IS_ERR(common)) {
+ status = PTR_ERR(common);
+ goto err_fsg_func;
+ }
+
+ f_fsg = usb_get_function(f_fsg_inst);
+ if (IS_ERR(f_fsg)) {
+ status = PTR_ERR(f_fsg);
+ goto err_fsg_func;
+ }
- status = fsg_bind_config(c-cdev, c, fsg_common);
+ status = usb_add_function(c, f_fsg);
if (status 0)
- goto err_fsg;
+ goto err_fsg_conf;
return 0;
-err_fsg:
+
+err_fsg_conf:
+ usb_put_function(f_fsg);
+err_fsg_func:
+ fsg_common_put(common);
+ usb_put_function_instance(f_fsg_inst);
+err_acm:
usb_remove_function(c, f_acm);
-err_conf:
+err_acm_conf:
usb_put_function(f_acm);
-err_func:
+err_acm_func:
usb_put_function_instance(f_acm_inst);
return status;
}
@@ -165,14 +187,6 @@ static int __init acm_ms_bind(struct usb_composite_dev
*cdev)
{
struct usb_gadget *gadget = cdev-gadget;
int status;
- void*retp;
-
- /* set up mass storage function */
- retp = fsg_common_from_params(fsg_common, cdev, fsg_mod_data);
- if (IS_ERR(retp)) {
- status = PTR_ERR(retp);
- return PTR_ERR(retp);
- }
/*
* Allocate string descriptor numbers ... note that string
@@ -180,30 +194,26 @@ static int __init acm_ms_bind(struct usb_composite_dev
*cdev)
*/
status = usb_string_ids_tab(cdev, strings_dev);
if (status 0)
- goto fail1;
+ return status;
device_desc.iManufacturer = strings_dev[USB_GADGET_MANUFACTURER_IDX].id;
device_desc.iProduct = strings_dev[USB_GADGET_PRODUCT_IDX].id;
/* register our configuration */
status = usb_add_config(cdev,
[PATCH 8/9] usb/gadget: remove compatibility layer for f_mass_storage
There are no old function interface users left, so the old interface
can be removed.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_mass_storage.c | 66 ---
1 files changed, 0 insertions(+), 66 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index f76e090..c7353b6 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -2528,9 +2528,7 @@ void fsg_common_put(struct fsg_common *common)
{
kref_put(common-ref, fsg_common_release);
}
-#ifndef USB_FMS_INCLUDED
EXPORT_SYMBOL(fsg_common_put);
-#endif
/* check if fsg_num_buffers is within a valid range */
static inline int fsg_num_buffers_validate(void)
@@ -2748,9 +2746,7 @@ error_release:
fsg_common_release(common-ref);
return ERR_PTR(rc);
}
-#ifndef USB_FMS_INCLUDED
EXPORT_SYMBOL(fsg_common_init_memset);
-#endif
static void fsg_common_release(struct kref *ref)
{
@@ -2867,64 +2863,6 @@ static struct usb_gadget_strings *fsg_strings_array[] = {
NULL,
};
-#ifdef USB_FMS_INCLUDED
-
-static void old_fsg_unbind(struct usb_configuration *c, struct usb_function *f)
-{
- struct fsg_dev *fsg = fsg_from_func(f);
- struct fsg_common *common = fsg-common;
-
- DBG(fsg, unbind\n);
- if (fsg-common-fsg == fsg) {
- fsg-common-new_fsg = NULL;
- raise_exception(fsg-common, FSG_STATE_CONFIG_CHANGE);
- /* FIXME: make interruptible or killable somehow? */
- wait_event(common-fsg_wait, common-fsg != fsg);
- }
-
- fsg_common_put(common);
- usb_free_all_descriptors(fsg-function);
- kfree(fsg);
-}
-
-static int fsg_bind_config(struct usb_composite_dev *cdev,
- struct usb_configuration *c,
- struct fsg_common *common)
-{
- struct fsg_dev *fsg;
- int rc;
-
- fsg = kzalloc(sizeof *fsg, GFP_KERNEL);
- if (unlikely(!fsg))
- return -ENOMEM;
-
- fsg-function.name= FSG_DRIVER_DESC;
- fsg-function.strings = fsg_strings_array;
- fsg-function.bind= fsg_bind;
- fsg-function.unbind = old_fsg_unbind;
- fsg-function.setup = fsg_setup;
- fsg-function.set_alt = fsg_set_alt;
- fsg-function.disable = fsg_disable;
-
- fsg-common = common;
- /*
-* Our caller holds a reference to common structure so we
-* don't have to be worry about it being freed until we return
-* from this function. So instead of incrementing counter now
-* and decrement in error recovery we increment it only when
-* call to usb_add_function() was successful.
-*/
-
- rc = usb_add_function(c, fsg-function);
- if (unlikely(rc))
- kfree(fsg);
- else
- fsg_common_get(fsg-common);
- return rc;
-}
-
-#else
-
static void fsg_free_inst(struct usb_function_instance *fi)
{
struct fsg_common *common;
@@ -3006,8 +2944,6 @@ DECLARE_USB_FUNCTION_INIT(mass_storage, fsg_alloc_inst,
fsg_alloc);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Michal Nazarewicz);
-#endif
-
/* Module parameters */
@@ -3041,7 +2977,5 @@ void fsg_config_from_params(struct fsg_config *cfg,
/* Finalise */
cfg-can_stall = params-stall;
}
-#ifndef USB_FMS_INCLUDED
EXPORT_SYMBOL(fsg_config_from_params);
-#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] usb/gadget: create header file for f_mass_storage
In order to prepare for the new function interface the f_mass_storage.c
needs to be compiled as a module, and so a header file will be required.
This patch factors out some code to a new f_mass_storage.h.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_mass_storage.c | 187 +
drivers/usb/gadget/f_mass_storage.h | 196 +++
2 files changed, 201 insertions(+), 182 deletions(-)
create mode 100644 drivers/usb/gadget/f_mass_storage.h
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 7bb3587..c1134d2 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -229,6 +229,7 @@
static const char fsg_string_interface[] = Mass Storage;
#include storage_common.h
+#include f_mass_storage.h
/* Static strings, in UTF-8 (for simplicity we use only ASCII characters) */
static struct usb_string fsg_strings[] = {
@@ -261,104 +262,6 @@ static unsigned int fsg_num_buffers =
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS;
struct fsg_dev;
struct fsg_common;
-/* FSF callback functions */
-struct fsg_operations {
- /*
-* Callback function to call when thread exits. If no
-* callback is set or it returns value lower then zero MSF
-* will force eject all LUNs it operates on (including those
-* marked as non-removable or with prevent_medium_removal flag
-* set).
-*/
- int (*thread_exits)(struct fsg_common *common);
-};
-
-/* Data shared by all the FSG instances. */
-struct fsg_common {
- struct usb_gadget *gadget;
- struct usb_composite_dev *cdev;
- struct fsg_dev *fsg, *new_fsg;
- wait_queue_head_t fsg_wait;
-
- /* filesem protects: backing files in use */
- struct rw_semaphore filesem;
-
- /* lock protects: state, all the req_busy's */
- spinlock_t lock;
-
- struct usb_ep *ep0; /* Copy of gadget-ep0 */
- struct usb_request *ep0req;/* Copy of cdev-req */
- unsigned intep0_req_tag;
-
- struct fsg_buffhd *next_buffhd_to_fill;
- struct fsg_buffhd *next_buffhd_to_drain;
- struct fsg_buffhd *buffhds;
-
- int cmnd_size;
- u8 cmnd[MAX_COMMAND_SIZE];
-
- unsigned intnluns;
- unsigned intlun;
- struct fsg_lun *luns;
- struct fsg_lun *curlun;
-
- unsigned intbulk_out_maxpacket;
- enum fsg_state state; /* For exception handling */
- unsigned intexception_req_tag;
-
- enum data_direction data_dir;
- u32 data_size;
- u32 data_size_from_cmnd;
- u32 tag;
- u32 residue;
- u32 usb_amount_left;
-
- unsigned intcan_stall:1;
- unsigned intfree_storage_on_release:1;
- unsigned intphase_error:1;
- unsigned intshort_packet_received:1;
- unsigned intbad_lun_okay:1;
- unsigned intrunning:1;
-
- int thread_wakeup_needed;
- struct completion thread_notifier;
- struct task_struct *thread_task;
-
- /* Callback functions. */
- const struct fsg_operations *ops;
- /* Gadget's private data. */
- void*private_data;
-
- /*
-* Vendor (8 chars), product (16 chars), release (4
-* hexadecimal digits) and NUL byte
-*/
- char inquiry_string[8 + 16 + 4 + 1];
-
- struct kref ref;
-};
-
-struct fsg_config {
- unsigned nluns;
- struct fsg_lun_config {
- const char *filename;
- char ro;
- char removable;
- char cdrom;
- char nofua;
- } luns[FSG_MAX_LUNS];
-
- /* Callback functions. */
- const struct fsg_operations *ops;
- /* Gadget's private data. */
- void*private_data;
-
- const char *vendor_name;/* 8 characters or less */
- const char *product_name; /* 16 characters or less */
-
- charcan_stall;
-};
-
struct fsg_dev {
struct usb_function function;
struct usb_gadget *gadget;/* Copy of cdev-gadget */
@@ -2620,12 +2523,7 @@ static void fsg_lun_release(struct device *dev)
/* Nothing needs to be done */
}
-static inline void fsg_common_get(struct fsg_common *common)
-{
- kref_get(common-ref);
-}
-
-static inline void fsg_common_put(struct fsg_common *common)
+void
[PATCH 9/9] usb/gadget: merge mass storage utility object with f_mass_storage object
The u_ms.ko utility module is now used only by the f_mass_storage.ko module, so there is no point in splitting the code into two modules. This patch merges the two into one while keeping their corresponing source code files compiled separately. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/usb/gadget/Kconfig |6 -- drivers/usb/gadget/Makefile |4 +--- 2 files changed, 1 insertions(+), 9 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index f8cae6e..4613b6d 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -510,9 +510,6 @@ config USB_F_SS_LB config USB_U_SERIAL tristate -config USB_U_MS - tristate - config USB_F_MASS_STORAGE tristate @@ -742,7 +739,6 @@ config USB_MASS_STORAGE tristate Mass Storage Gadget depends on BLOCK select USB_LIBCOMPOSITE - select USB_U_MS select USB_F_MASS_STORAGE help The Mass Storage Gadget acts as a USB Mass Storage disk drive. @@ -856,7 +852,6 @@ config USB_G_ACM_MS select USB_LIBCOMPOSITE select USB_U_SERIAL select USB_F_ACM - select USB_U_MS select USB_F_MASS_STORAGE help This driver provides two functions in one configuration: @@ -872,7 +867,6 @@ config USB_G_MULTI select USB_LIBCOMPOSITE select USB_U_SERIAL select USB_F_ACM - select USB_U_MS select USB_F_MASS_STORAGE help The Multifunction Composite Gadget provides Ethernet (RNDIS diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 8472100..2e62bf9 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -79,8 +79,6 @@ obj-$(CONFIG_USB_GADGET_TARGET) += tcm_usb_gadget.o obj-$(CONFIG_USB_F_ACM)+= f_acm.o f_ss_lb-y := f_loopback.o f_sourcesink.o obj-$(CONFIG_USB_F_SS_LB) += f_ss_lb.o -u_ms-y := storage_common.o -obj-$(CONFIG_USB_U_MS) += u_ms.o -f_ms-y := f_mass_storage.o +f_ms-y := f_mass_storage.o storage_common.o obj-$(CONFIG_USB_F_MASS_STORAGE)+= f_ms.o obj-$(CONFIG_USB_U_SERIAL) += u_serial.o -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] usb/gadget: convert multi to new function interface
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |1 +
drivers/usb/gadget/multi.c | 69 +++-
2 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 34ce7c4..f8cae6e 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -873,6 +873,7 @@ config USB_G_MULTI
select USB_U_SERIAL
select USB_F_ACM
select USB_U_MS
+ select USB_F_MASS_STORAGE
help
The Multifunction Composite Gadget provides Ethernet (RNDIS
and/or CDC Ethernet), mass storage and ACM serial link
diff --git a/drivers/usb/gadget/multi.c b/drivers/usb/gadget/multi.c
index b138a22..c638564 100644
--- a/drivers/usb/gadget/multi.c
+++ b/drivers/usb/gadget/multi.c
@@ -41,8 +41,7 @@ MODULE_LICENSE(GPL);
* the runtime footprint, and giving us at least some parts of what
* a gcc --combine ... part1.c part2.c part3.c ... build would.
*/
-#define USB_FMS_INCLUDED
-#include f_mass_storage.c
+#include f_mass_storage.h
#include f_ecm.c
#include f_subset.c
@@ -132,17 +131,20 @@ static struct usb_gadget_strings *dev_strings[] = {
static struct fsg_module_parameters fsg_mod_data = { .stall = 1 };
FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
-static struct fsg_common fsg_common;
+static struct fsg_common *fsg_common;
static u8 hostaddr[ETH_ALEN];
static struct usb_function_instance *fi_acm;
static struct eth_dev *the_dev;
+static struct usb_function_instance *fi_fsg;
+
/** RNDIS **/
#ifdef USB_ETH_RNDIS
static struct usb_function *f_acm_rndis;
+static struct usb_function *f_fsg_rndis;
static __init int rndis_do_config(struct usb_configuration *c)
{
@@ -165,11 +167,19 @@ static __init int rndis_do_config(struct
usb_configuration *c)
if (ret)
goto err_conf;
- ret = fsg_bind_config(c-cdev, c, fsg_common);
- if (ret 0)
+ f_fsg_rndis = usb_get_function(fi_fsg);
+ if (IS_ERR(f_fsg_rndis)) {
+ ret = PTR_ERR(f_fsg_rndis);
goto err_fsg;
+ }
+
+ ret = usb_add_function(c, f_fsg_rndis);
+ if (ret)
+ goto err_func_fsg;
return 0;
+err_func_fsg:
+ usb_put_function(f_fsg_rndis);
err_fsg:
usb_remove_function(c, f_acm_rndis);
err_conf:
@@ -205,6 +215,7 @@ static int rndis_config_register(struct usb_composite_dev
*cdev)
#ifdef CONFIG_USB_G_MULTI_CDC
static struct usb_function *f_acm_multi;
+static struct usb_function *f_fsg_multi;
static __init int cdc_do_config(struct usb_configuration *c)
{
@@ -228,11 +239,19 @@ static __init int cdc_do_config(struct usb_configuration
*c)
if (ret)
goto err_conf;
- ret = fsg_bind_config(c-cdev, c, fsg_common);
- if (ret 0)
+ f_fsg_multi = usb_get_function(fi_fsg);
+ if (IS_ERR(f_fsg_multi)) {
+ ret = PTR_ERR(f_fsg_multi);
goto err_fsg;
+ }
+
+ ret = usb_add_function(c, f_fsg_multi);
+ if (ret)
+ goto err_func_fsg;
return 0;
+err_func_fsg:
+ usb_put_function(f_fsg_multi);
err_fsg:
usb_remove_function(c, f_acm_multi);
err_conf:
@@ -269,6 +288,7 @@ static int cdc_config_register(struct usb_composite_dev
*cdev)
static int __ref multi_bind(struct usb_composite_dev *cdev)
{
+ struct fsg_config config;
struct usb_gadget *gadget = cdev-gadget;
int status;
@@ -290,41 +310,47 @@ static int __ref multi_bind(struct usb_composite_dev
*cdev)
goto fail0;
}
- /* set up mass storage function */
- {
- void *retp;
- retp = fsg_common_from_params(fsg_common, cdev, fsg_mod_data);
- if (IS_ERR(retp)) {
- status = PTR_ERR(retp);
- goto fail1;
- }
+ fi_fsg = usb_get_function_instance(mass_storage);
+ if (IS_ERR(fi_fsg)) {
+ status = PTR_ERR(fi_fsg);
+ goto fail1;
+ }
+
+ fsg_common = container_of(fi_fsg, struct fsg_common, func_inst);
+ fsg_config_from_params(config, fsg_mod_data);
+ fsg_common = fsg_common_init_memset(fsg_common, cdev, config, false);
+ if (IS_ERR(fsg_common)) {
+ status = PTR_ERR(fsg_common);
+ goto fail2;
}
/* allocate string IDs */
status = usb_string_ids_tab(cdev, strings_dev);
if (unlikely(status 0))
- goto fail2;
+ goto fail3;
device_desc.iProduct = strings_dev[USB_GADGET_PRODUCT_IDX].id;
/* register configurations */
status = rndis_config_register(cdev);
if (unlikely(status 0))
- goto fail2;
+ goto fail3;
status =
[PATCH 4/9] usb/gadget: convert f_mass_storage to new function interface with backward compatibility
Converting mass storage to the new function interface requires converting
the USB mass storage's function code and its users.
This patch converts the f_mass_storage.c to the new function interface.
The file is now compiled into a separate f_ms.ko module.
The old function interface is provided by means of a preprocessor conditional
directives. After all users are converted, the old interface can be removed.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |3 +
drivers/usb/gadget/Makefile |2 +
drivers/usb/gadget/acm_ms.c |1 +
drivers/usb/gadget/f_mass_storage.c | 136 +-
drivers/usb/gadget/mass_storage.c |1 +
drivers/usb/gadget/multi.c |1 +
6 files changed, 124 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 9cc5260..adbc434 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -513,6 +513,9 @@ config USB_U_SERIAL
config USB_U_MS
tristate
+config USB_F_MASS_STORAGE
+ tristate
+
choice
tristate USB Gadget Drivers
default USB_ETH
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 01a16a2..8472100 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -81,4 +81,6 @@ f_ss_lb-y := f_loopback.o f_sourcesink.o
obj-$(CONFIG_USB_F_SS_LB) += f_ss_lb.o
u_ms-y := storage_common.o
obj-$(CONFIG_USB_U_MS) += u_ms.o
+f_ms-y := f_mass_storage.o
+obj-$(CONFIG_USB_F_MASS_STORAGE)+= f_ms.o
obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
diff --git a/drivers/usb/gadget/acm_ms.c b/drivers/usb/gadget/acm_ms.c
index 4b947bb..0af60f3 100644
--- a/drivers/usb/gadget/acm_ms.c
+++ b/drivers/usb/gadget/acm_ms.c
@@ -40,6 +40,7 @@
* the runtime footprint, and giving us at least some parts of what
* a gcc --combine ... part1.c part2.c part3.c ... build would.
*/
+#define USB_FMS_INCLUDED
#include f_mass_storage.c
/*-*/
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index c1134d2..f76e090 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -213,6 +213,7 @@
#include linux/spinlock.h
#include linux/string.h
#include linux/freezer.h
+#include linux/module.h
#include linux/usb/ch9.h
#include linux/usb/gadget.h
@@ -2527,6 +2528,9 @@ void fsg_common_put(struct fsg_common *common)
{
kref_put(common-ref, fsg_common_release);
}
+#ifndef USB_FMS_INCLUDED
+EXPORT_SYMBOL(fsg_common_put);
+#endif
/* check if fsg_num_buffers is within a valid range */
static inline int fsg_num_buffers_validate(void)
@@ -2744,6 +2748,9 @@ error_release:
fsg_common_release(common-ref);
return ERR_PTR(rc);
}
+#ifndef USB_FMS_INCLUDED
+EXPORT_SYMBOL(fsg_common_init_memset);
+#endif
static void fsg_common_release(struct kref *ref)
{
@@ -2793,24 +2800,6 @@ static void fsg_common_release(struct kref *ref)
/*-*/
-static void fsg_unbind(struct usb_configuration *c, struct usb_function *f)
-{
- struct fsg_dev *fsg = fsg_from_func(f);
- struct fsg_common *common = fsg-common;
-
- DBG(fsg, unbind\n);
- if (fsg-common-fsg == fsg) {
- fsg-common-new_fsg = NULL;
- raise_exception(fsg-common, FSG_STATE_CONFIG_CHANGE);
- /* FIXME: make interruptible or killable somehow? */
- wait_event(common-fsg_wait, common-fsg != fsg);
- }
-
- fsg_common_put(common);
- usb_free_all_descriptors(fsg-function);
- kfree(fsg);
-}
-
static int fsg_bind(struct usb_configuration *c, struct usb_function *f)
{
struct fsg_dev *fsg = fsg_from_func(f);
@@ -2871,13 +2860,33 @@ autoconf_fail:
return -ENOTSUPP;
}
-/** ADD FUNCTION **/
+/** ALLOCATE FUNCTION */
static struct usb_gadget_strings *fsg_strings_array[] = {
fsg_stringtab,
NULL,
};
+#ifdef USB_FMS_INCLUDED
+
+static void old_fsg_unbind(struct usb_configuration *c, struct usb_function *f)
+{
+ struct fsg_dev *fsg = fsg_from_func(f);
+ struct fsg_common *common = fsg-common;
+
+ DBG(fsg, unbind\n);
+ if (fsg-common-fsg == fsg) {
+ fsg-common-new_fsg = NULL;
+ raise_exception(fsg-common, FSG_STATE_CONFIG_CHANGE);
+ /* FIXME: make interruptible or killable somehow? */
+ wait_event(common-fsg_wait, common-fsg != fsg);
+ }
+
+ fsg_common_put(common);
+
[PATCH 6/9] usb/gadget: convert mass_storage to new function interface
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig|1 +
drivers/usb/gadget/mass_storage.c | 118 +++-
2 files changed, 76 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 3cdd10a..34ce7c4 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -743,6 +743,7 @@ config USB_MASS_STORAGE
depends on BLOCK
select USB_LIBCOMPOSITE
select USB_U_MS
+ select USB_F_MASS_STORAGE
help
The Mass Storage Gadget acts as a USB Mass Storage disk drive.
As its storage repository it can use a regular file or a block
diff --git a/drivers/usb/gadget/mass_storage.c
b/drivers/usb/gadget/mass_storage.c
index 1b668cc..53896d5 100644
--- a/drivers/usb/gadget/mass_storage.c
+++ b/drivers/usb/gadget/mass_storage.c
@@ -29,8 +29,12 @@
#include linux/kernel.h
-#include linux/usb/ch9.h
#include linux/module.h
+#include linux/err.h
+#include linux/usb/ch9.h
+#include linux/usb/composite.h
+
+#include f_mass_storage.h
/*-*/
@@ -48,17 +52,6 @@
/*-*/
-/*
- * kbuild is not very cooperative with respect to linking separately
- * compiled library objects into one module. So for now we won't use
- * separate compilation ... ensuring init/exit sections work to shrink
- * the runtime footprint, and giving us at least some parts of what
- * a gcc --combine ... part1.c part2.c part3.c ... build would.
- */
-#define USB_FMS_INCLUDED
-#include f_mass_storage.c
-
-/*-*/
USB_GADGET_COMPOSITE_OPTIONS();
static struct usb_device_descriptor msg_device_desc = {
@@ -123,34 +116,6 @@ static int msg_thread_exits(struct fsg_common *common)
return 0;
}
-static int __init msg_do_config(struct usb_configuration *c)
-{
- static const struct fsg_operations ops = {
- .thread_exits = msg_thread_exits,
- };
- static struct fsg_common common;
-
- struct fsg_common *retp;
- struct fsg_config config;
- int ret;
-
- if (gadget_is_otg(c-cdev-gadget)) {
- c-descriptors = otg_desc;
- c-bmAttributes |= USB_CONFIG_ATT_WAKEUP;
- }
-
- fsg_config_from_params(config, mod_data);
- config.ops = ops;
-
- retp = fsg_common_init(common, c-cdev, config);
- if (IS_ERR(retp))
- return PTR_ERR(retp);
-
- ret = fsg_bind_config(c-cdev, c, common);
- fsg_common_put(common);
- return ret;
-}
-
static struct usb_configuration msg_config_driver = {
.label = Linux File-Backed Storage,
.bConfigurationValue= 1,
@@ -158,27 +123,93 @@ static struct usb_configuration msg_config_driver = {
};
+static struct usb_function *func_ms;
+static struct usb_function_instance *fi_ms;
+
/** Gadget Bind **/
static int __init msg_bind(struct usb_composite_dev *cdev)
{
+ struct fsg_common *common;
+ struct fsg_config config;
+
+ static const struct fsg_operations ops = {
+ .thread_exits = msg_thread_exits,
+ };
+
int status;
+ fi_ms = usb_get_function_instance(mass_storage);
+ if (IS_ERR(fi_ms))
+ return PTR_ERR(fi_ms);
+ common = container_of(fi_ms, struct fsg_common, func_inst);
+
+ fsg_config_from_params(config, mod_data);
+ config.ops = ops;
+
+ common = fsg_common_init_memset(common, cdev, config, false);
+ if (IS_ERR(common)) {
+ status = PTR_ERR(common);
+ goto err_get_inst;
+ }
+
status = usb_string_ids_tab(cdev, strings_dev);
if (status 0)
- return status;
+ goto err_get_inst;
+
msg_device_desc.iProduct = strings_dev[USB_GADGET_PRODUCT_IDX].id;
- status = usb_add_config(cdev, msg_config_driver, msg_do_config);
+ if (gadget_is_otg(cdev-gadget)) {
+ msg_config_driver.descriptors = otg_desc;
+ msg_config_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
+ }
+
+ func_ms = usb_get_function(fi_ms);
+ if (IS_ERR(func_ms)) {
+ status = PTR_ERR(func_ms);
+ goto err_get_inst;
+ }
+
+ status = usb_add_config_only(cdev, msg_config_driver);
if (status 0)
- return status;
+ goto err_get_function;
+
+ status = usb_add_function(msg_config_driver, func_ms);
+ if (status)
+ goto err_ms_get;
+ else
+ fsg_common_get(common);
+
usb_composite_overwrite_options(cdev, coverwrite);
Re: [V4 PATCH 18/26] usb: phy: mv_usb2_phy: add externel chip support
Hi, On Tue, Jan 22, 2013 at 10:51:32AM +0800, Chao Xie wrote: On Mon, Jan 21, 2013 at 11:51 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 21, 2013 at 05:07:36AM -0500, Chao Xie wrote: + mv_phy-extern_chip.head = devm_kzalloc(pdev-dev, + sizeof(*mv_phy-extern_chip.head), + GFP_KERNEL); + if (mv_phy-extern_chip.head == NULL) + return -ENOMEM; + ATOMIC_INIT_NOTIFIER_HEAD(mv_phy-extern_chip.head); Why do you need to allocate an atomic notifier list head as an entirely separate data structure? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Th reason is that the original code seperate the extern_chip and phy support. So it depends on the -head to detect whether extern_chip is initialized or not. Now it is combined with phy, the -phy pointer can do the job. does that need to be dynamically allocated ? -- balbi signature.asc Description: Digital signature
Re: [V4 PATCH 00/26] mv-usb fix and enhancement patches
Hi, On Mon, Jan 21, 2013 at 05:07:18AM -0500, Chao Xie wrote: The patches are divied into 4 parts 1. bug fixes usb: gadget: mv_udc: use udc_start and udc_stop functions usb: gadget: mv_udc: use devm_xxx for probe usb: gadget: mv_udc: fix the warning of mv_udc_remove usb: otg: mv_otg: use devm_xxx for probe usb: host: ehci-mv: remove unused variable usb: gadget: mv_udc: fix the value of tranceiver usb: gadget: mv_udc: make mv_udc depends on ARCH_MMP or ARCH_PXA Above patches are bug fixes. 2. PHY driver To remove the callbacks in the platform data, a usb PHY driver for marvell udc/otg/ehci is written. For device tree support, it is not good to pass the callback pointers by platform data. The PHY driver also removes the block. usb: phy: mv_usb2: add PHY driver for marvell usb2 controller usb: gadget: mv_udc: use PHY driver for udc usb: ehci: ehci-mv: use PHY driver for ehci usb: otg: mv_otg: use PHY driver for otg Above patches are marvell usb PHY driver support. arm: mmp2: change the defintion of usb devices arm: pxa910: change the defintion of usb devices arm: brownstone: add usb support for the board arm: ttc_dkb: add usb support arm: mmp: remove the usb phy setting arm: mmp: remove usb devices from pxa168 Above patches are for SOC/board support for marvell usb PHY driver. 3. external chip support The marvell usb controller can detect the vbus/idpin, but it need PHY and usb clocks to be enabled. Based on measurement it will import 15mA current, and increase the power when the usb is not used. Using a external chip to detect vbus/idpin changes will save the power. In fact the marvell PMIC 88pm860x and 88pm80x can do it. The drivers are located at drivers/mfd. So add a middle layer in the marvell usb PHY driver. PMIC call the APIs in middle driver to registers the callback for vbus/idpin detection/query udc/otg/ehci driver will call the APIs to get vbus/idpin changes and query the states of the vbus/idpin. usb: phy: mv_usb2_phy: add externel chip support usb: gadget: mv_udc: add extern chip support usb: ehci: ehci-mv: add extern chip support usb: otg: mv_otg: add extern chip support Above patches are the middle layer suppor for udc/otg/ehci arm: mmp: add extern chip support for brownstone arm: mmp: add extern chip support for ttc_dkb Above patches are corresponding board file changes 4. device tree support After removing the callbacks in platform data, and the not constant variables in platform data. All the information needed by udc/otg/ehci driver are constant. usb: gadget: mv_udc: add device tree support usb: otg: mv_otg: add device tree support usb: ehci: ehci-mv: add device tree support Above patches are device tree support for udc/otg/ehci driver. this series will be delayed for v3.10. Sorry -- balbi signature.asc Description: Digital signature
USB3 host dying on SIGKILL
Hello,
We have a somewhat UVC compliant USB2 camera connected to a USB3 port.
It works mostly great. But when we SIGKILL the program which opened the
device, the corresponding host controller dies and the system must be
rebooted to access the USB port again. If the program closes the device
normally and then ends, everything works correctly.
In the error case we get the following messages. The uvcvideo lines are
additional debug messages which we added during debugging this problem:
[ 130.812349] uvcvideo: uvc_v4l2_release
[ 130.812352] uvcvideo: uvc_v4l2_release has_privileges
[ 130.812355] uvcvideo: uvc_uninit_video start
[ 130.812536] uvcvideo: uvc_uninit_video done
[ 131.113099] uvcvideo: usb_set_interface start
[ 131.113121] xhci_hcd :00:14.0: Signal while waiting for configure
endpoint command
[ 131.113163] usb 3-1: Not enough bandwidth for altsetting 0
[ 131.113165] uvcvideo: usb_set_interface done
[ 131.416625] uvcvideo: uvc_queue_enable start
[ 131.416630] uvcvideo: uvc_queue_enable done
[ 131.720344] uvcvideo: uvc_v4l2_release 2
[ 131.720348] uvcvideo: uvc_v4l2_release 3
[ 131.720356] xhci_hcd :00:14.0: ERROR no room on ep ring
[ 131.720359] xhci_hcd :00:14.0: ERR: No room for command on command
ring
[ 136.728324] xhci_hcd :00:14.0: xHCI host not responding to stop
endpoint command.
[ 136.728330] xhci_hcd :00:14.0: Assuming host is dying, halting host.
[ 136.728344] xhci_hcd :00:14.0: HC died; cleaning up
[ 136.728364] usb 3-1: USB disconnect, device number 2
[ 136.728378] uvcvideo: uvc_v4l2_release 4
[ 136.728388] uvcvideo: uvc_v4l2_release 5
[ 136.768486] xhci_hcd :00:14.0: Slot 1 endpoint 2 not removed from BW
list!
I.e. the uvc driver calls
usb_set_interface(stream-dev-udev, stream-intfnum, 0);
during it's uvc_v4l2_release() execution. This fails with
[ 131.113121] xhci_hcd :00:14.0: Signal while waiting for configure
endpoint command
[ 131.113163] usb 3-1: Not enough bandwidth for altsetting 0
If we remove this usb_set_interface() call everything seems to work
correctly, no error messages are in the log, and the USB3 port
remains accessible.
But that's probably not the right solution. At least I, with my very
limit knowledge about USB and xhci, don't see an error in calling this
here during the release operation. So we looked further. The call
chain which is performed starting from usb_set_interface() is:
usb_set_interface()
ret = usb_hcd_alloc_bandwidth(dev, NULL, iface-cur_altsetting, alt);
ret = hcd-driver-check_bandwidth(hcd, udev);
xhci_check_bandwidth()
ret = xhci_configure_endpoint(xhci, udev, NULL, false, false);
timeleft = wait_for_completion_interruptible_timeout(
cmd_completion, XHCI_CMD_DEFAULT_TIMEOUT);
It seems to me as if wait_for_completion_interruptible_timeout()
stops because of the SIGKILL which the process received before.
Changing the wait_for_completion_interruptible_timeout() in
xhci_configure_endpoint() to wait_for_completion_timeout() fixed
the problem for us as well. No error messages occur in the log
and the USB3 port remains accessible. Don't now if this is anything
near the right solution to this problem.
Attached is a patch for this, probably wrong, solution and the
kernel logs starting shortly before the SIGKILL and ending shortly
after the HC died message. The kernel logs where generated with
CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on.
Additionally uvcvideo was loaded with trace=255.
During debugging this problem we used the kernels 3.2.0-35-generic
from Ubuntu 12.4 and the latest vanilla kernel from the 3.6 series,
version 3.6.11. The patch is against version 3.6.11.
We use an AAEON IMBM-B75A mainboard with an Intel B75 chipset,
bios version 0601. The camera is a DFK 42AUC03 from
The Imaging Source Europe GmbH.
Does anybody know what's the right solution for this problem?
Or is the patch even correct?
Thanks in advance,
--
Dr. Frank Lömker
Leiter Softwareentwicklung
E-Mail: frank.loem...@isa.de.com
Tel : +49(0)3677-46929-63
Internet: www.isa.de.com
ISA Institut für Serviceautomation GmbH Co. KG
Ziolkowskistr. 8, 98693 Ilmenau
phG: ISA GmbH, Ilmenau (AG Jena, HRB 306708)
Geschäftsführer: Dipl.-Ing. (FH) Jürgen Utschig
Ust-IdNr. DE 239745996
ILN 43 99901 84388 2
Amtsgericht Jena
HRA 301735
HRB 306708
Member of SIELAFF GROUP
--- drivers/usb/host/xhci.c.orig 2013-01-23 09:55:56.280871103 +0100
+++ drivers/usb/host/xhci.c 2013-01-23 09:57:18.704872621 +0100
@@ -2592,7 +2592,7 @@ static int xhci_configure_endpoint(struc
spin_unlock_irqrestore(xhci-lock, flags);
/* Wait for the configure endpoint command to complete */
- timeleft = wait_for_completion_interruptible_timeout(
+ timeleft = wait_for_completion_timeout(
cmd_completion,
XHCI_CMD_DEFAULT_TIMEOUT);
if (timeleft = 0) {
log.txt.gz
Description:
Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device
Hi all,
On Wed, Jan 23, 2013 at 3:20 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jan 22, 2013 at 02:04:56PM -0800, Kukjin Kim wrote:
Felipe Balbi wrote:
Hi,
Hi Felipe,
[...]
Right, DWC has version number, but that being the kind of USB controller
(USB 2.0 and USB 3.0)
DWC2: USB High Speed controller (as also indicated in the patch from
Paul: [RFC PATCH 0/6] DWC2 DesignWare HS OTG driver)
DWC3: USB Super Speed controller
Is it fine if we use something like shown below, as suggested by you
earlier ?
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,synopsis-dwc3 }
You're both missing a point here. The synopsys IP driver is called
dwc3.ko and that's compatible with synopsys,dwc3. Your glue layer driver
(dwc3-exynos.ko) is compatible with your platform, so
samsung,exynos-dwc3 sounds correct to me.
Hmm...yeah, you're right and agreed.
However, we need to use more clear name there like samsung,exynos-dwusb3
in compatible, because you know there are lots of other IPs in Synopsis
Design Ware brand. So we have to include usb in compatible for that.
fair enough.
Thanks for your suggestions. This definitely make things clear.
I shall then keep samsung,exynos-dwusb3 as the compatible string or,
should i be including '5250' string as well, something like
samsung,exynos5250-dwusb3
as pointed out by Grant earlier ? :-O
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, In my udc driver, i set the req-length to the number of bytes i received from HW, which is 31 bytes. Is it necessary to do that? How you shouldn't touch req-lenght, you should only update req-actual. req-length is readonly for the UDC. to know the gadget driver queued 0-bytes? By bh-bulk_out_intended_length ? read req-length i removed setting the req-length in udc driver. Now in the bulk_out_complete(), the value of req-length is 512. who set it to 512? Read the code and you will figure it out. Here are the last two setup data and CBW data received. the get_next_command() is not called when CBW data is received. the bulk_out_complete() wakes up the thread, however, get_next_command() still sleeps. i do not see where req-length is checked in gadget driver. g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: ep0-setup, length 8: : a1 fe 00 00 00 00 01 00 g_file_storage gadget: get max LUN g_file_storage gadget: ep0-in, length 1: : 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk_out_complete -- 0, 31/0 victor -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device
Hi,
On 01/23/2013 01:20 PM, Vivek Gautam wrote:
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,synopsis-dwc3 }
You're both missing a point here. The synopsys IP driver is called
dwc3.ko and that's compatible with synopsys,dwc3. Your glue layer driver
(dwc3-exynos.ko) is compatible with your platform, so
samsung,exynos-dwc3 sounds correct to me.
Hmm...yeah, you're right and agreed.
However, we need to use more clear name there like samsung,exynos-dwusb3
in compatible, because you know there are lots of other IPs in Synopsis
Design Ware brand. So we have to include usb in compatible for that.
fair enough.
Thanks for your suggestions. This definitely make things clear.
I shall then keep samsung,exynos-dwusb3 as the compatible string or,
should i be including '5250' string as well, something like
samsung,exynos5250-dwusb3
as pointed out by Grant earlier ? :-O
IMHO this needs to be samsung,exynos5250-dwusb3, rather than
samsung,exynos-dwusb3. :)
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, On Wed, Jan 23, 2013 at 08:24:36PM +0800, victor yeo wrote: In my udc driver, i set the req-length to the number of bytes i received from HW, which is 31 bytes. Is it necessary to do that? How you shouldn't touch req-lenght, you should only update req-actual. req-length is readonly for the UDC. to know the gadget driver queued 0-bytes? By bh-bulk_out_intended_length ? read req-length i removed setting the req-length in udc driver. Now in the bulk_out_complete(), the value of req-length is 512. who set it to 512? Read the code and you will figure it out. Here are the last two setup data and CBW data received. the get_next_command() is not called when CBW data is received. the bulk_out_complete() wakes up the thread, however, get_next_command() still sleeps. i do not see where req-length is checked in gadget driver. g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: ep0-setup, length 8: : a1 fe 00 00 00 00 01 00 g_file_storage gadget: get max LUN g_file_storage gadget: ep0-in, length 1: : 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk_out_complete -- 0, 31/0 file_storage uses bulk_out_intended_length. You're on your own, to be fair, using a really old kernel, you never posted your UDC driver for review, so you need to fix it all up by yourself. Read the code, add prints, look at other UDC drivers. g_file_storage is next to perfect and proven to work with many, many different setups. good luck -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 3/4] ARM: Exynos5250: Add clock information for dwc3-exynos
Hi Tomasz,
On Wed, Jan 16, 2013 at 8:35 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
Hi Tomasz,
On Wed, Jan 16, 2013 at 1:19 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vivek,
Don't you need also some clkdev lookup entry to make the clock available
in the driver?
This clock source we added with a motive of completion, however it's
not being used as of now.
As far as i could see the lookup structure contains clocks for devices
having multiple instances.
Do you feel that i should be adding an entry in clk_lookup structure ?
May be i am missing here something. Can you please elaborate on the
use-case of clk_lookup
entries.
Any suggestions on this please ?
On Tuesday 15 of January 2013 19:08:31 Vivek Gautam wrote:
Adding necessary device clock to exynos5 needed for
the DWC3 controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/mach-exynos/clock-exynos5.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c index 0208c3a..13af020 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -757,6 +757,11 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_fsys_ctrl ,
.ctrlbit= (1 18),
}, {
+ .name = usbdrd30,
+ .parent = exynos5_clk_aclk_200.clk,
+ .enable = exynos5_clk_ip_fsys_ctrl,
+ .ctrlbit= (1 19),
+ }, {
.name = usbotg,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1 7),
@@ -1035,6 +1040,16 @@ static struct clksrc_sources exynos5_clkset_group
= { .nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
};
+struct clk *exynos5_clkset_usbdrd30_list[] = {
+ [0] = exynos5_clk_mout_mpll.clk,
+ [1] = exynos5_clk_mout_cpll.clk,
+};
+
+struct clksrc_sources exynos5_clkset_usbdrd30 = {
+ .sources= exynos5_clkset_usbdrd30_list,
+ .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
+};
+
/* Possible clock sources for aclk_266_gscl_sub Mux */
static struct clk *clk_src_gscl_266_list[] = {
[0] = clk_ext_xtal_mux,
@@ -1329,6 +1344,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.parent = exynos5_clk_mout_cpll.clk,
},
.reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3
},
+ }, {
+ .clk= {
+ .name = sclk_usbdrd30,
+ .enable = exynos5_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 28),
+ },
+ .sources = exynos5_clkset_usbdrd30,
+ .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 28, .size =
1 },
+ .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 24, .size =
4 },
},
};
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device
Hi Sylwester,
On Wed, Jan 23, 2013 at 6:10 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
Hi,
On 01/23/2013 01:20 PM, Vivek Gautam wrote:
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,synopsis-dwc3 }
You're both missing a point here. The synopsys IP driver is called
dwc3.ko and that's compatible with synopsys,dwc3. Your glue layer driver
(dwc3-exynos.ko) is compatible with your platform, so
samsung,exynos-dwc3 sounds correct to me.
Hmm...yeah, you're right and agreed.
However, we need to use more clear name there like samsung,exynos-dwusb3
in compatible, because you know there are lots of other IPs in Synopsis
Design Ware brand. So we have to include usb in compatible for that.
fair enough.
Thanks for your suggestions. This definitely make things clear.
I shall then keep samsung,exynos-dwusb3 as the compatible string or,
should i be including '5250' string as well, something like
samsung,exynos5250-dwusb3
as pointed out by Grant earlier ? :-O
IMHO this needs to be samsung,exynos5250-dwusb3, rather than
samsung,exynos-dwusb3. :)
Alright, thanks.
I shall update this patch. :)
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
Hi Koen, On Tue, Jan 22, 2013 at 22:32:56, Koen Kooi wrote: Actually it uses nop-phy as a phy, which is missing from arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the nop-phy to the DT is easy enough to patch in locally. USB first instance of am335x works in mainline as of now. Regards Afzal
Re: Linux USB file storage gadget with new UDC
Hi,
Here are the last two setup data and CBW data received. the
get_next_command() is not called when CBW data is received. the
bulk_out_complete() wakes up the thread, however, get_next_command()
still sleeps. i do not see where req-length is checked in gadget
driver.
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
g_file_storage gadget: ep0-setup, length 8:
: a1 fe 00 00 00 00 01 00
g_file_storage gadget: get max LUN
g_file_storage gadget: ep0-in, length 1:
: 00
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12
0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00
g_file_storage gadget: bulk_out_complete -- 0, 31/0
file_storage uses bulk_out_intended_length.
You're on your own, to be fair, using a really old kernel, you never
posted your UDC driver for review, so you need to fix it all up by
yourself.
Read the code, add prints, look at other UDC drivers. g_file_storage is
next to perfect and proven to work with many, many different setups.
Here is my UDC driver code. I use a kthread to poll the hardware
register EP0 and EP1 interrupt. I removed the HW register access code.
If it is required, i can send the full code. Something could be wrong
in my UDC driver. Thanks.
#include linux/device.h
#include linux/interrupt.h
#include linux/io.h
#include linux/ioport.h
#include linux/kernel.h
#include linux/list.h
#include linux/module.h
#include linux/moduleparam.h
#include linux/platform_device.h
#include linux/usb/ch9.h
#include linux/usb/gadget.h
#include linux/kthread.h
#include linux/delay.h
#define NUM_ENDPOINTS 3
#define EP_MAX_PACKET_SIZE 0x200
#define EP0_MAX_PACKET_SIZE 64
#define QH_MAXNUM 32
/*-*/
#define IO_OFFSET 0x5500
#define __IO_ADDRESS(x) ((x) + IO_OFFSET)
#define IO_ADDRESS(pa) IOMEM(__IO_ADDRESS(pa))
#ifdef IOMEM // Override asm/io.h
#undef IOMEM
#endif // IOMEM
#ifdef __ASSEMBLER__
#define IOMEM(x)x
#else
#define IOMEM(x)((void __force __iomem *)(x))
#endif
#define ka2000_readb(a) __raw_readb(IO_ADDRESS(a))
#define ka2000_readw(a) __raw_readw(IO_ADDRESS(a))
#define ka2000_readl(a) __raw_readl(IO_ADDRESS(a))
#define ka2000_writeb(v, a) __raw_writeb(v, IO_ADDRESS(a))
#define ka2000_writew(v, a) __raw_writew(v, IO_ADDRESS(a))
#define ka2000_writel(v, a) __raw_writel(v, IO_ADDRESS(a))
/*-*/
static const char *reqname(unsigned r)
{
switch (r) {
case USB_REQ_GET_STATUS: return GET_STATUS;
case USB_REQ_CLEAR_FEATURE: return CLEAR_FEATURE;
case USB_REQ_SET_FEATURE: return SET_FEATURE;
case USB_REQ_SET_ADDRESS: return SET_ADDRESS;
case USB_REQ_GET_DESCRIPTOR: return GET_DESCRIPTOR;
case USB_REQ_SET_DESCRIPTOR: return SET_DESCRIPTOR;
case USB_REQ_GET_CONFIGURATION: return GET_CONFIGURATION;
case USB_REQ_SET_CONFIGURATION: return SET_CONFIGURATION;
case USB_REQ_GET_INTERFACE: return GET_INTERFACE;
case USB_REQ_SET_INTERFACE: return SET_INTERFACE;
default: return *UNKNOWN*;
}
}
static struct usb_endpoint_descriptor ep0_out_desc = {
.bLength = sizeof(struct usb_endpoint_descriptor),
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = 0,
.bmAttributes = USB_ENDPOINT_XFER_CONTROL,
};
static struct usb_endpoint_descriptor ep0_in_desc = {
.bLength = sizeof(struct usb_endpoint_descriptor),
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_CONTROL,
};
struct kagen2;
struct kagen2_request {
struct usb_request req;
struct list_head queue;
unsigned mapped:1,
valid:1;
};
struct ka_ep {
struct usb_ep ep;
struct kagen2 * dev;
unsigned long irqs;
struct usb_request req;
struct list_head queue;
const struct usb_endpoint_descriptor *desc;
unsigned num:8,
fifo_size:12,
stopped:1,
wedged:1,
is_in:1,
is_iso:1,
dma:1,
not_empty:1;
};
struct ka_udc {
struct usb_gadget gadget;
struct usb_gadget_driver*driver;
};
#define CONFIG_MAX_PKT(n) ((n) 16)
#define TERMINATE 1
#define INFO_BYTES(n) ((n) 16)
#define INFO_IOC (1 15)
#define INFO_ACTIVE (1 7)
#define INFO_HALTED (1 6)
#define INFO_BUFFER_ERROR (1 5)
#define INFO_TX_ERROR (1 3)
static struct ka_ep ka_ep_g[NUM_ENDPOINTS];
enum SPEED {
LOWSPEED = 0,
FULLSPEED = 1,
HIGHSPEED = 2,
};
enum STATE {
DEFAULT = 0,
Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
On Tue, 22 Jan 2013, Sascha Hauer wrote: On Tue, Jan 22, 2013 at 03:38:55PM +, Arnd Bergmann wrote: On Tuesday 22 January 2013, Alan Stern wrote: In order to prevent this, you have to make sure that each glue driver depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround the Kconfig entries for those drivers with if USB USB_ARCH_HAS_EHCI ... endif. I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI as well once we have inverted the logic for selecting USB_EHCI_HCD, but there is another problem with that, because then we still need something to select USB_ARCH_HAS_HCD, or kill that symbol as well. +1 for killing it. Such symbols get more and more meaningless anyway with multiarch kernels- I tend to agree. Anyway, the symbols are named badly. _Any_ architecture with HAS_IOMEM can in theory aupport host-side USB. Maybe some of the platforms don't, but that has nothing to do with the CPU's architecture. Furthermore, even platforms that don't support USB host controllers can use things like dummy-hcd and usbip, which provide virtual host controllers. Anybody think these symbols should be retained? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: tegra: don't touch EMC clock
On Tue, 22 Jan 2013, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Clock emc is for the External Memory Controller. The USB driver has no business touching this clock directly. Remove the code that does so. Signed-off-by: Stephen Warren swar...@nvidia.com --- Greg, Alan, I'd like to take this patch through the Tegra tree to avoid any merge conflicts with the Tegra USB changes that have recently happened there. It's okay with me. Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
On Wed, 23 Jan 2013, victor yeo wrote: In my udc driver, i set the req-length to the number of bytes i received from HW, which is 31 bytes. Is it necessary to do that? How to know the gadget driver queued 0-bytes? By bh-bulk_out_intended_length ? Victor, it sounds like you haven't read include/linux/usb/gadget.h. Reading it carefully would provide the answers to a lot of your questions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/20] OMAP USB Host cleanup
On Wed, 23 Jan 2013, Roger Quadros wrote: Hi Samuel, I think this series is in a pretty good shape to pull now :). I've added Reviewed-by and Acked-by tags. You can please pull from below. NOTE: the first patch is a stable fix so Greg KH might want to pick it up for 3.8-rc. The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://github.com/rogerq/linux.git linux-usbhost14-part This patchset addresses the following - Consolidate USB Host platform data. - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested). Roger: I haven't yet submitted the patch splitting ehci-omap apart from ehci-hcd. Will this interfere with your work? Or is it a prerequisite? How would you like to handle this? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] arm: mvebu: Update defconfig to select USB support
Cc: Lior Amsalem al...@marvell.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Gregory CLEMENT gregory.clem...@free-electrons.com Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org Tested-by: Florian Fainelli flor...@openwrt.org Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index c3c6326..f8d0183 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -42,7 +42,10 @@ CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y -# CONFIG_USB_SUPPORT is not set +CONFIG_USB_SUPPORT=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_MMC=y CONFIG_MMC_MVSDIO=y CONFIG_RTC_CLASS=y -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
This patch activates every USB port provided by each SoC.
Except for Armada XP Openblocks AX3-4 board,
where we enable only the first two USB ports
until we have more information on the third one usage.
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Tested-by: Florian Fainelli flor...@openwrt.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Squashed separate per-board patches into this one,
as suggested by Arnd.
* Remove usb@d0052000 activation in OpenBlocks AX3-4
until we have more information about it.
arch/arm/boot/dts/armada-370-db.dts |8
arch/arm/boot/dts/armada-370-mirabox.dts |8
arch/arm/boot/dts/armada-xp-db.dts | 12
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |6 ++
4 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 8e66a7c..3d93902 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,5 +74,13 @@
status = disabled;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 1864820..dd0c57d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -62,5 +62,13 @@
* Wifi/Bluetooth chip
*/
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index c7035c5..c84e1fe 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,5 +97,17 @@
status = okay;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
+
+ usb@d0052000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index ec36864..3818a82 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -133,5 +133,11 @@
nr-ports = 2;
status = okay;
};
+ usb@d005 {
+ status = okay;
+ };
+ usb@d0051000 {
+ status = okay;
+ };
};
};
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
On Wed, 23 Jan 2013, victor yeo wrote: Here are the last two setup data and CBW data received. the get_next_command() is not called when CBW data is received. the It's not supposed to be _called_; it's supposed to be _woken up_. bulk_out_complete() wakes up the thread, however, get_next_command() still sleeps. Are you certain? Maybe it gets woken up and then goes back to sleep. i do not see where req-length is checked in gadget driver. It isn't _checked_; it is _set_ in set_bulk_out_req_length(). req-actual is checked in received_cbw(). g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: ep0-setup, length 8: : a1 fe 00 00 00 00 01 00 g_file_storage gadget: get max LUN g_file_storage gadget: ep0-in, length 1: : 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk_out_complete -- 0, 31/0 Why is the bulk_out_intended_length field set to 0? Doesn't set_bulk_out_req_length() work right? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Root hub autosusend delay
On Wed, 23 Jan 2013, Ming Lei wrote: On Wed, Jan 23, 2013 at 4:08 AM, Alan Stern st...@rowland.harvard.edu wrote: Lei: It turns out that your patch setting the autosuspend delay for hubs to 0 causes problems for root hubs. They need a delay of at least 30 ms. When a child device sends a remote wakeup request, the root hub generates an interrupt. The HCD's interrupt handler sees what happened and requests a runtime resume for the root hub. However it can't tell the hub driver about the wakeup request until the port resume is finished, which takes about 25 ms. During that time, the hub driver won't know what has happened and so it will try to autosuspend. The autosuspend will fail because the port is resuming, but the hub driver will go right ahead and keep trying to autosuspend. This will continue until the port resume is complete. In order to avoid all these extra autosuspend attempts, the delay for root hubs should be set to something larger than 25 ms, such as 30 ms. Do you agree? IMO, that should be the simplest fix on the problem. But, looks the delay of 25ms or 30ms is only required in the above remote wakeup case, and user can override the delay too, so maybe we need to figure out one better approach to deal with that. Other strange things seem to be happening. Take a look at the log just posted by Norbert Preining: http://www.preining.info/usb-syslog-prob.txt Starting at timestamp 400.570029, the external hub and root hub go into a strange remote wakeup loop. I don't know why; maybe some external program is trying to access the external hub over and over again. This continues for more than 10 seconds! If the delay were set to 30 ms, the amount of activity would be greatly reduced. Could we add a delay in hub_events() for handling the case? see below draft patch for explaining the idea: Yeah, we could improve the situation. But until we know what's happening with Norbert's machine, my feeling is that a short delay would be better. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB subsystem stops working
On Wed, 23 Jan 2013, Norbert Preining wrote: Hi Alan, On Di, 22 Jan 2013, Alan Stern wrote: It looks like things may improve if you do echo 50 /sys/bus/usb/devices/usb1/power/autosuspend_delay_ms I did some testing over here. It looks like in addition to increasing the autosuspend delay, the following patch is needed. In fact I *forgot* to increase the autosuspend delay and *only* used your patch, and it did work. Not increasing the delay explains why you got all those suspend failed because a port is resuming messages. Updated log is at the same place http://www.preining.info/usb-syslog-prob.txt That whole interval between 16:18:14 and 16:18:25 makes no sense. It looks like some program is trying to communicate with your hub during that time. Do you have any idea what's going on? Perhaps you can enable usbfs_snoop and run another test: echo y /sys/module/usbcore/parameters/usbfs_snoop You should post the output from the dmesg command rather than the contents of the system log. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: tegra: don't touch EMC clock
On 01/23/2013 02:45 AM, Lucas Stach wrote: Am Mittwoch, den 23.01.2013, 12:25 +0530 schrieb Venu Byravarasu: -Original Message- From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra- ow...@vger.kernel.org] On Behalf Of Stephen Warren Sent: Wednesday, January 23, 2013 5:58 AM To: Alan Stern; Greg Kroah-Hartman; Stephen Warren Cc: Venu Byravarasu; linux-te...@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-usb@vger.kernel.org; Stephen Warren Subject: [PATCH 1/2] usb: host: tegra: don't touch EMC clock From: Stephen Warren swar...@nvidia.com Clock emc is for the External Memory Controller. The USB driver has no business touching this clock directly. Remove the code that does so. Stephen, This was primarily done to make sure that EMC is set to a minimum frequency, below which data errors may occur during USB transfers. If we plan to remove this, how should we make sure that the EMC is programmed for the required frequency during USB transfers? You could use something like the API I added in ARM: tegra: add EMC clock scaling API. This needs some rework and I looked into integrating this with the DEVFREQ framework, but I don't think it fits too well. Bandwidth requirements should always be communicated to the EMC driver and not described by clock rates. I agree. Besides, on some boards there's an EMC scaling table defined already, so the EMC driver is simply overriding the value the USB driver selects anyway. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend PATCH 2/2] usb: add usb_enable/disable_remote_wakeup()
On Wed, 23 Jan 2013, Lan Tianyu wrote:
usb2.0 and usb3.0 devices have different ways to enalbe/disable
remote wakeup. This patch is to put both their operations into
the seperate functions. Otherwise, usb_control_msg() has some
long arguments and are usually nested some indentations. So
encapsulating it into seperate functions would be convienient
to use and more readable.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/hub.c | 115
+---
1 file changed, 61 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 29791a6..d04985b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2794,6 +2794,63 @@ static int usb_disable_function_remotewakeup(struct
usb_device *udev)
USB_CTRL_SET_TIMEOUT);
}
+static int usb_disable_remote_wakeup(struct usb_device *udev)
+{
+ int status = 0;
+ u16 devstatus;
+
+ if (udev-speed != USB_SPEED_SUPER) {
+ status = usb_get_status(udev, USB_RECIP_DEVICE, 0, devstatus);
+ le16_to_cpus(devstatus);
+ if (!status devstatus (1 USB_DEVICE_REMOTE_WAKEUP))
+ status = usb_control_msg(udev,
+ usb_sndctrlpipe(udev, 0),
+ USB_REQ_CLEAR_FEATURE,
+ USB_RECIP_DEVICE,
+ USB_DEVICE_REMOTE_WAKEUP, 0,
+ NULL, 0,
+ USB_CTRL_SET_TIMEOUT);
+ } else {
+ status = usb_get_status(udev, USB_RECIP_INTERFACE, 0,
+ devstatus);
+ le16_to_cpus(devstatus);
+ if (!status devstatus
+ (USB_INTRF_STAT_FUNC_RW_CAP | USB_INTRF_STAT_FUNC_RW))
+ status = usb_disable_function_remotewakeup(udev);
Don't call that function here. Just put the code here and run it
directly. Then you can get rid of the old function.
After all, it's just a call to usb_control_msg, like in the non-USB-3
case above.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drivers/usb/host/uhci-* : check buffer length to avoid memory overflow
On Wed, 23 Jan 2013, Chen Gang wrote: for function uhci_sprint_schedule: the buffer len is MAX_OUTPUT: 64 * 1024, which may not be enough: may loop UHCI_NUMFRAMES times (UHCI_NUMFRAMES is 1024) each time of loop may get more than 64 bytes so need check the buffer length to avoid memory overflow this patch fix it like this: at first, make enough room for buffering the exceeding contents judge the contents which written whether bigger than buffer length if bigger (the exceeding contents will be in the exceeding buffer) break current work flow, and return. Signed-off-by: Chen Gang gang.c...@asianux.com Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: tegra: add clocks properties to USB PHY nodes
On 01/22/2013 11:43 PM, Venu Byravarasu wrote: Stephen Warren wrote at Wednesday, January 23, 2013 6:03 AM: On 01/22/2013 05:28 PM, Stephen Warren wrote: The patch to add USB PHY nodes to device tree was written before Tegra supported the clocks property in device tree. Now that it does, add the required clocks properties to these nodes. This will allow all clk_get_sys() calls in tegra_usb_phy.c to be replaced by clk_get(phy-dev, clock_name), as part of converting the PHY driver to a platform driver. diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi + clocks = tegra_car 22, tegra_car 127; + clock-names = utmi, pll_u; ... + clocks = tegra_car 94, tegra_car 127; + clock-names = ulpi, pll_u; Hmmm. Thinking about that first clock more, if we name it just phy in both the UTMI and ULPI PHY nodes, we could make tegra_phy_init() perform the clk_get() for all PHY types, and use the same clock name everywhere, and hence remove the type-specific clk_get()s from tegra_phy_init() and utmip_pad_open(). Venu, will this work for other chips such as Tegra30/Tegra114 and so on into the future, or do chips after Tegra20 introduce any new clocks, and hence break this scheme? Should be fine, as same clocks are used across all chips. Acked-by: Venu Byravarasu vbyravar...@nvidia.com Thanks. I've applied both patches to Tegra's for-3.9/soc branch, with patch 2/2 modified to name the first clock phy rather than utmi or ulpi. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drivers/usb/host/uhci-*: beautify source code
On Wed, 23 Jan 2013, Chen Gang wrote: get rid of the line breaks in string constants. let comments within 80 with limitation. delete ' \' at the end of a statement. Signed-off-by: Chen Gang gang.c...@asianux.com This is good except for... --- a/drivers/usb/host/uhci-hub.c +++ b/drivers/usb/host/uhci-hub.c @@ -21,8 +21,10 @@ static const __u8 root_hub_hub_des[] = 0x00, /* (per-port OC, no power switching) */ 0x01, /* __u8 bPwrOn2pwrGood; 2ms */ 0x00, /* __u8 bHubContrCurrent; 0 mA */ - 0x00, /* __u8 DeviceRemovable; *** 7 Ports max *** */ - 0xff/* __u8 PortPwrCtrlMask; *** 7 ports max *** */ + 0x00, /* __u8 DeviceRemovable; *** 7 Ports max *** + */ + 0xff/* __u8 PortPwrCtrlMask; *** 7 ports max *** + */ Here you could just get rid of the second *** on each line. Or put the 7 ports max into parentheses and get rid of all the ***'s. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, On Wed, Jan 23, 2013 at 11:20:56PM +0800, victor yeo wrote: Hi, Here are the last two setup data and CBW data received. the get_next_command() is not called when CBW data is received. the bulk_out_complete() wakes up the thread, however, get_next_command() still sleeps. i do not see where req-length is checked in gadget driver. g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: ep0-setup, length 8: : a1 fe 00 00 00 00 01 00 g_file_storage gadget: get max LUN g_file_storage gadget: ep0-in, length 1: : 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12 0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: bulk_out_complete -- 0, 31/0 file_storage uses bulk_out_intended_length. You're on your own, to be fair, using a really old kernel, you never posted your UDC driver for review, so you need to fix it all up by yourself. Read the code, add prints, look at other UDC drivers. g_file_storage is next to perfect and proven to work with many, many different setups. Here is my UDC driver code. I use a kthread to poll the hardware register EP0 and EP1 interrupt. I removed the HW register access code. you should an interrupt handler to handle interrupts from your device. Also, there are way too many mistakes on your driver, run checkpatch.pl, compile it with sparse, don't hardcode addresses, don't reimplement a bunch of infrastructure the kernel already gives you and check your list_head usage! Also, you shouldn't requeue the request yourself, gadget driver owns the request. -- balbi signature.asc Description: Digital signature
Re: Root hub autosusend delay
On Thu, Jan 24, 2013 at 12:02 AM, Alan Stern st...@rowland.harvard.edu wrote: Other strange things seem to be happening. Take a look at the log just posted by Norbert Preining: http://www.preining.info/usb-syslog-prob.txt Starting at timestamp 400.570029, the external hub and root hub go into a strange remote wakeup loop. I don't know why; maybe some external program is trying to access the external hub over and over again. This From timestamp 400.570029 to 410.920195, root hub is always auto-resumed, so it might be triggered by some crazy external applications, lsusb or others? continues for more than 10 seconds! If the delay were set to 30 ms, the amount of activity would be greatly reduced. IMO, if it is a normal use case on USB bus or device, we need to consider adjusting the default delay for hub, but it is still not sure, :-) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
Hi Nobuhiro,
On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
This patch activates every USB port provided by each SoC.
Except for Armada XP Openblocks AX3-4 board,
where we enable only the first two USB ports
until we have more information on the third one usage.
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Tested-by: Florian Fainelli flor...@openwrt.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Squashed separate per-board patches into this one,
as suggested by Arnd.
* Remove usb@d0052000 activation in OpenBlocks AX3-4
until we have more information about it.
arch/arm/boot/dts/armada-370-db.dts |8
arch/arm/boot/dts/armada-370-mirabox.dts |8
arch/arm/boot/dts/armada-xp-db.dts | 12
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |6 ++
4 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 8e66a7c..3d93902 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,5 +74,13 @@
status = disabled;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 1864820..dd0c57d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -62,5 +62,13 @@
* Wifi/Bluetooth chip
*/
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index c7035c5..c84e1fe 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,5 +97,17 @@
status = okay;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
+
+ usb@d0052000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index ec36864..3818a82 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -133,5 +133,11 @@
nr-ports = 2;
status = okay;
};
+ usb@d005 {
+ status = okay;
+ };
+ usb@d0051000 {
+ status = okay;
+ };
};
};
--
1.7.8.6
I'd like to bring this patch to your attention.
As you can see, I've removed the
usb@d0052000 {
status = okay;
};
from the OpenBlocks AX3-4 board dts file, since you mentioned this
board uses that USB
port for a PCIe connector -- if I understood correctly.
It's interesting to note that Mirabox board doesn't provide direct
access to its USB ports either,
but instead they are used to connect a GL827L MMC card reader.
However, we activate USB ports anyway, since it's needed for that to work fine.
So, IMHO, if OpenBlocks uses third USB port to connect some PCIe controller,
we should activate it in the dts file.
What do you think?
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] arm: mvebu: Add support for USB host controllers in Armada 370/XP
Jason,
On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
The Armada 370 and Armada XP SoC has an Orion EHCI USB controller.
This patch adds support for this controller in Armada 370
and Armada XP SoC common device tree files.
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Tested-by: Florian Fainelli flor...@openwrt.org
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Remove uneeded USB_ARCH_HAS_EHCI selection as noted by Florian.
arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++
arch/arm/boot/dts/armada-370.dtsi|9 +
arch/arm/boot/dts/armada-xp.dtsi | 17 +
3 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 28276fe..fa025c4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -145,6 +145,21 @@
clocks = gateclk 17;
status = disabled;
};
+
+ usb@d005 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd005 0x500;
+ interrupts = 45;
+ status = disabled;
+ };
+
+ usb@d0051000 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd0051000 0x500;
+ interrupts = 46;
+ status = disabled;
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 88f9bab..8188d13 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -144,5 +144,14 @@
dmacap,memset;
};
};
+
+ usb@d005 {
+ clocks = coreclk 0;
+ };
+
+ usb@d0051000 {
+ clocks = coreclk 0;
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi
b/arch/arm/boot/dts/armada-xp.dtsi
index 2e37ef1..c22a0c8 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -134,5 +134,22 @@
dmacap,memset;
};
};
+
+ usb@d005 {
+ clocks = gateclk 18;
+ };
+
+ usb@d0051000 {
+ clocks = gateclk 19;
+ };
+
+ usb@d0052000 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd0052000 0x500;
+ interrupts = 47;
+ clocks = gateclk 20;
+ status = disabled;
+ };
+
};
};
--
1.7.8.6
Do you think we're still in time to get this series into v3.9 (given
we decide soon on the OpenBlocks issue)?
Thanks,
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] arm: mvebu: Add support for USB host controllers in Armada 370/XP
On Wed, Jan 23, 2013 at 02:06:12PM -0300, Ezequiel Garcia wrote: Jason, On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: The Armada 370 and Armada XP SoC has an Orion EHCI USB controller. This patch adds support for this controller in Armada 370 and Armada XP SoC common device tree files. Cc: Lior Amsalem al...@marvell.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org Tested-by: Florian Fainelli flor...@openwrt.org Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Changes from v1: * Remove uneeded USB_ARCH_HAS_EHCI selection as noted by Florian. arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++ arch/arm/boot/dts/armada-370.dtsi|9 + arch/arm/boot/dts/armada-xp.dtsi | 17 + 3 files changed, 41 insertions(+), 0 deletions(-) Do you think we're still in time to get this series into v3.9 (given we decide soon on the OpenBlocks issue)? That shouldn't be a problem. thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: misc: usb3503: add dt support
Added device tree support for usb3503 driver and add new document with device
tree binding information.
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
Documentation/devicetree/bindings/usb/usb3503.txt | 20 +
drivers/usb/misc/usb3503.c| 31 +
2 files changed, 46 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt
b/Documentation/devicetree/bindings/usb/usb3503.txt
new file mode 100644
index 000..6813a71
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -0,0 +1,20 @@
+SMSC USB3503 High-Speed Hub Controller
+
+Required properties:
+- compatible: Should be smsc,usb3503.
+- reg: Specifies the i2c slave address, it should be 0x08.
+- connect-gpios: Should specify GPIO for connect.
+- intn-gpios: Should specify GPIO for interrupt.
+- reset-gpios: Should specify GPIO for reset.
+- initial-mode: Should specify initial mode.
+(1 for HUB mode, 2 for STANDBY mode)
+
+Examples:
+ usb3503@08 {
+ compatible = smsc,usb3503;
+ reg = 0x08;
+ connect-gpios = gpx3 0 1;
+ intn-gpios = gpx3 4 1;
+ reset-gpios = gpx3 5 1;
+ initial-mode = 1;
+ };
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index dc2c993..471218a 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -23,6 +23,7 @@
#include linux/delay.h
#include linux/slab.h
#include linux/module.h
+#include linux/of_gpio.h
#include linux/platform_device.h
#include linux/platform_data/usb3503.h
@@ -181,8 +182,10 @@ err_hubmode:
static int usb3503_probe(struct i2c_client *i2c, const struct i2c_device_id
*id)
{
struct usb3503_platform_data *pdata = i2c-dev.platform_data;
+ struct device_node *np = i2c-dev.of_node;
struct usb3503 *hub;
int err = -ENOMEM;
+ u32 mode;
hub = kzalloc(sizeof(struct usb3503), GFP_KERNEL);
if (!hub) {
@@ -193,14 +196,23 @@ static int usb3503_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
i2c_set_clientdata(i2c, hub);
hub-client = i2c;
- if (!pdata) {
- dev_dbg(i2c-dev, missing platform data\n);
- goto err_out;
- } else {
+ if (pdata) {
hub-gpio_intn = pdata-gpio_intn;
hub-gpio_connect = pdata-gpio_connect;
hub-gpio_reset = pdata-gpio_reset;
hub-mode = pdata-initial_mode;
+ } else if (np) {
+ hub-gpio_intn = of_get_named_gpio(np, connect-gpios, 0);
+ if (hub-gpio_intn == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ hub-gpio_connect = of_get_named_gpio(np, intn-gpios, 0);
+ if (hub-gpio_connect == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ hub-gpio_reset = of_get_named_gpio(np, reset-gpios, 0);
+ if (hub-gpio_reset == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ of_property_read_u32(np, initial-mode, mode);
+ hub-mode = mode;
}
if (gpio_is_valid(hub-gpio_intn)) {
@@ -236,7 +248,7 @@ static int usb3503_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
}
}
- usb3503_switch_mode(hub, pdata-initial_mode);
+ usb3503_switch_mode(hub, hub-mode);
dev_info(i2c-dev, %s: probed on %s mode\n, __func__,
(hub-mode == USB3503_MODE_HUB) ? hub : standby);
@@ -277,9 +289,18 @@ static const struct i2c_device_id usb3503_id[] = {
};
MODULE_DEVICE_TABLE(i2c, usb3503_id);
+#ifdef CONFIG_OF
+static const struct of_device_id usb3503_of_match[] = {
+ { .compatible = smsc,usb3503, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, usb3503_of_match);
+#endif
+
static struct i2c_driver usb3503_driver = {
.driver = {
.name = USB3503_I2C_NAME,
+ .of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_probe,
.remove = usb3503_remove,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
Dear Ezequiel Garcia, On Wed, 23 Jan 2013 14:04:42 -0300, Ezequiel Garcia wrote: from the OpenBlocks AX3-4 board dts file, since you mentioned this board uses that USB port for a PCIe connector -- if I understood correctly. No. The OpenBlocks has a different USB controller that sits on the PCIe bus. There is nothing like a PCIe port that uses a USB port, that doesn't make sense. So, IMHO, if OpenBlocks uses third USB port to connect some PCIe controller, we should activate it in the dts file. What do you think? No, see above. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
Hi Thomas, On Wed, Jan 23, 2013 at 3:03 PM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: On Wed, 23 Jan 2013 14:04:42 -0300, Ezequiel Garcia wrote: from the OpenBlocks AX3-4 board dts file, since you mentioned this board uses that USB port for a PCIe connector -- if I understood correctly. No. The OpenBlocks has a different USB controller that sits on the PCIe bus. There is nothing like a PCIe port that uses a USB port, that doesn't make sense. Mmm... indeed, I got it completely wrong. So, IMHO, if OpenBlocks uses third USB port to connect some PCIe controller, we should activate it in the dts file. What do you think? No, see above. So, what do you think about the patch series to be pushed as it is? -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB subsystem stops working
On Thu, 24 Jan 2013, Ming Lei wrote: On Thu, Jan 24, 2013 at 12:08 AM, Alan Stern st...@rowland.harvard.edu wrote: Not increasing the delay explains why you got all those suspend failed because a port is resuming messages. Alan, looks the suspend failed because a port is resuming messages is nothing to do with the autosuspend delay, Not so. It's true that the message can be produced even when the delay is present, but if the delay is set to 30 ms then you will get no more than one message every 30 ms. By contrast, Norbert was getting about 8 messages per ms. and increase the delay doesn't make the messages disappear[1]. The message is produced because port change event is missed while host is sending ports resuming signal. Yes, I know. I have post one patch which may remove the message, see link[2]. I don't think sleeping is the right answer. For example, at the same time as the resume there could be a new device plugged in. What we really want to do is prevent the root hub from autosuspending while the resume signal is active. One possibility is to have the HCD call pm_runtime_get_noresume. Can you think of anything better? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB3 Not Being Detected on Intel DX79TO Desktop Board
On Wed, Jan 23, 2013 at 01:14:09PM -0500, Robert Dvoracek wrote: 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) Subsystem: Intel Corporation Device 4953 On Wed, Jan 23, 2013 at 12:28 AM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jan 23, 2013 at 12:19:41AM -0500, Robert Dvoracek wrote: It shows up in lspci as NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04). I'm not exactly sure how to go about recompiling a x86_64 kernel on Knoppix. It's based on Debian and the nice Debian manual isn't making sense to me right now. Gotta get some sleep Thank you, Robert On Tue, Jan 22, 2013 at 11:09 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Jan 22, 2013 at 11:17:22PM +, Robert Dvoracek wrote: Is there any more that can be done? Let me know if you need more information. Can you enable CONFIG_USB_DEBUG and plug your device in and send us the kernel log output? It really didn't look like you had a USB 3 controller at all on this machine, do you see it if you do 'lspci'? thanks, greg k-h knoppix@Microknoppix:~$ lspci | grep -i usb lspci.txt 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06) 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06) 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) What is the output of: lspci -k -s 02:00.0 on your system? thanks, greg k-h knoppix@Microknoppix:~/Downloads$ lspci -k -s 02:00.0 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) Subsystem: Intel Corporation Device 4953 That shows you really don't have the xhci-hcd driver loaded for this device. If you have built your own kernel, please make sure you are building it. If you are using a distro kernel, what distro and version is this? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4 v.2] USB: EHCI: fix build error in ehci-mxc
This patch (as1643b) fixes a build error in ehci-hcd when compiling for
ARM with allmodconfig:
drivers/usb/host/ehci-hcd.c:1285:0: warning: PLATFORM_DRIVER redefined
[enabled by default]
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous
definition
drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not
used [-Wunused-variable]
drivers/usb/host/ehci-hcd.c:1285:0: warning: PLATFORM_DRIVER redefined
[enabled by default]
drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous
definition
The fix is to convert ehci-mxc over to the new ehci-hcd is a library
scheme so that it can coexist peacefully with the ehci-platform
driver. As part of the conversion the ehci_mxc_priv data structure,
which was allocated dynamically, is now placed where it belongs: in
the private area at the end of struct ehci_hcd.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Shawn Guo shawn@linaro.org
---
V.2:Rebased on top of the current usb-linus and usb-next branches.
Also, hcd_name is changed back to ehci-mxc. The driver.name
field in ehci_mxc_platform_driver is explicitly set to
mxc-ehci.
drivers/usb/host/Kconfig|2
drivers/usb/host/Makefile |1
drivers/usb/host/ehci-hcd.c |6 --
drivers/usb/host/ehci-mxc.c | 120 ++--
4 files changed, 53 insertions(+), 76 deletions(-)
Index: usb-3.7/drivers/usb/host/Kconfig
===
--- usb-3.7.orig/drivers/usb/host/Kconfig
+++ usb-3.7/drivers/usb/host/Kconfig
@@ -148,7 +148,7 @@ config USB_EHCI_FSL
Variation of ARC USB block used in some Freescale chips.
config USB_EHCI_MXC
- bool Support for Freescale i.MX on-chip EHCI USB controller
+ tristate Support for Freescale i.MX on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MXC
select USB_EHCI_ROOT_HUB_TT
---help---
Index: usb-3.7/drivers/usb/host/Makefile
===
--- usb-3.7.orig/drivers/usb/host/Makefile
+++ usb-3.7/drivers/usb/host/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_PCI) += pci-quirks.o
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o
+obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
Index: usb-3.7/drivers/usb/host/ehci-hcd.c
===
--- usb-3.7.orig/drivers/usb/host/ehci-hcd.c
+++ usb-3.7/drivers/usb/host/ehci-hcd.c
@@ -1246,11 +1246,6 @@ MODULE_LICENSE (GPL);
#definePLATFORM_DRIVER ehci_fsl_driver
#endif
-#ifdef CONFIG_USB_EHCI_MXC
-#include ehci-mxc.c
-#define PLATFORM_DRIVERehci_mxc_driver
-#endif
-
#ifdef CONFIG_USB_EHCI_SH
#include ehci-sh.c
#define PLATFORM_DRIVERehci_hcd_sh_driver
@@ -1349,6 +1344,7 @@ MODULE_LICENSE (GPL);
#if !IS_ENABLED(CONFIG_USB_EHCI_PCI) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_PLATFORM) \
!IS_ENABLED(CONFIG_USB_CHIPIDEA_HOST) \
+ !IS_ENABLED(CONFIG_USB_EHCI_MXC) \
!defined(PLATFORM_DRIVER) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
Index: usb-3.7/drivers/usb/host/ehci-mxc.c
===
--- usb-3.7.orig/drivers/usb/host/ehci-mxc.c
+++ usb-3.7/drivers/usb/host/ehci-mxc.c
@@ -17,75 +17,38 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include linux/kernel.h
+#include linux/module.h
+#include linux/io.h
#include linux/platform_device.h
#include linux/clk.h
#include linux/delay.h
#include linux/usb/otg.h
#include linux/usb/ulpi.h
#include linux/slab.h
+#include linux/usb.h
+#include linux/usb/hcd.h
#include linux/platform_data/usb-ehci-mxc.h
#include asm/mach-types.h
+#include ehci.h
+
+#define DRIVER_DESC Freescale On-Chip EHCI Host driver
+
+static const char hcd_name[] = ehci-mxc;
+
#define ULPI_VIEWPORT_OFFSET 0x170
struct ehci_mxc_priv {
struct clk *usbclk, *ahbclk, *phyclk;
- struct usb_hcd *hcd;
};
-/* called during probe() after chip reset completes */
-static int ehci_mxc_setup(struct usb_hcd *hcd)
-{
- hcd-has_tt = 1;
-
- return ehci_setup(hcd);
-}
-
-static const struct hc_driver ehci_mxc_hc_driver = {
- .description = hcd_name,
- .product_desc = Freescale On-Chip EHCI Host Controller,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
-* generic hardware linkage
-*/
- .irq = ehci_irq,
- .flags = HCD_USB2 | HCD_MEMORY,
-
- /*
-* basic lifecycle operations
-*/
- .reset = ehci_mxc_setup,
- .start = ehci_run,
- .stop = ehci_stop,
-
Re: [PATCH net] net: cdc_mbim: send ZLP only for the specific buggy device
From: Bjørn Mork bj...@mork.no Date: Wed, 23 Jan 2013 11:57:02 +0100 Reverting 328d7b8 and instead adding an exception for the Sierra Wireless MC7710. commit 328d7b8 (net: cdc_mbim: send ZLP after max sized NTBs) added a workaround for an issue observed on one specific device. Concerns were raised that this workaround adds a performance penalty to all devices based on questionable, if not buggy, behaviour of a single device: If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU load, increasing interrupt load by factor of 2 in high load traffic scenario and possibly decreasing throughput for all other devices which behaves correctly. The idea of NCM was to avoid extra ZLPs. If your transfer is exactly dwNtbOutMaxSize, it's known, you can submit such request on the receiver side and you do not need any EOT indicatation, so the frametime can be used for useful data. Adding a device specific exception to prevent the workaround from affecting well behaved devices. The assumption here is that needing a ZLP is truly an *exception*. We do not yet have enough data to verify this. The generic workaround in commit 328d7b8 should be considered acceptable despite the performance penalty if the exception list becomes a maintainance hassle. Cc: Alexey ORISHKO alexey.oris...@stericsson.com Cc: Yauheni Kaliuta y.kali...@gmail.com Signed-off-by: Bjørn Mork bj...@mork.no Applied. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: UHCI: remove unused definition
From: Woody Suwalski terraluna...@gmail.com
Remove an unused (and erroneous) definition from the UHCI driver.
Signed-off: Woody Suwalski terraluna...@gmail.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
--- a/drivers/usb/host/uhci-hcd.h 2013-01-23 11:43:17.330420515 -0500
+++ b/drivers/usb/host/uhci-hcd.h 2013-01-23 13:16:48.708380367 -0500
@@ -212,10 +212,6 @@ struct uhci_qh {
#define TD_CTRL_BITSTUFF (1 17) /* Bit Stuff Error */
#define TD_CTRL_ACTLEN_MASK0x7FF /* actual length, encoded as n - 1 */
-#define TD_CTRL_ANY_ERROR (TD_CTRL_STALLED | TD_CTRL_DBUFERR | \
-TD_CTRL_BABBLE | TD_CTRL_CRCTIME | \
-TD_CTRL_BITSTUFF)
-
#define uhci_maxerr(err) ((err) TD_CTRL_C_ERR_SHIFT)
#define uhci_status_bits(ctrl_sts) ((ctrl_sts) 0xF6)
#define uhci_actual_length(ctrl_sts) (((ctrl_sts) + 1) \
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB3 Not Being Detected on Intel DX79TO Desktop Board
It's Knoppix 7.0.5, kernel 3.6.11 Thank you, Robert On Wed, Jan 23, 2013 at 1:16 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jan 23, 2013 at 01:14:09PM -0500, Robert Dvoracek wrote: 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) Subsystem: Intel Corporation Device 4953 On Wed, Jan 23, 2013 at 12:28 AM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jan 23, 2013 at 12:19:41AM -0500, Robert Dvoracek wrote: It shows up in lspci as NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04). I'm not exactly sure how to go about recompiling a x86_64 kernel on Knoppix. It's based on Debian and the nice Debian manual isn't making sense to me right now. Gotta get some sleep Thank you, Robert On Tue, Jan 22, 2013 at 11:09 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Jan 22, 2013 at 11:17:22PM +, Robert Dvoracek wrote: Is there any more that can be done? Let me know if you need more information. Can you enable CONFIG_USB_DEBUG and plug your device in and send us the kernel log output? It really didn't look like you had a USB 3 controller at all on this machine, do you see it if you do 'lspci'? thanks, greg k-h knoppix@Microknoppix:~$ lspci | grep -i usb lspci.txt 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06) 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06) 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) What is the output of: lspci -k -s 02:00.0 on your system? thanks, greg k-h knoppix@Microknoppix:~/Downloads$ lspci -k -s 02:00.0 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) Subsystem: Intel Corporation Device 4953 That shows you really don't have the xhci-hcd driver loaded for this device. If you have built your own kernel, please make sure you are building it. If you are using a distro kernel, what distro and version is this? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend PATCH 2/2] usb: add usb_enable/disable_remote_wakeup()
On Thu, 24 Jan 2013, Lan Tianyu wrote: + status = usb_disable_function_remotewakeup(udev); Don't call that function here. Just put the code here and run it directly. Then you can get rid of the old function. usb_disable_function_remotewakeup is just introduced at last patch to resolve too more indentation. So it's ok to remove it so quickly ? Or I should merge these two patches? I thought the purpose of patch 1/2 was to have something that could be applied to the -stable kernels. Isn't that what Sarah asked for? A short fix, followed by another patch that would clean up the mess. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB3 Not Being Detected on Intel DX79TO Desktop Board
A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Jan 23, 2013 at 02:49:35PM -0500, Robert Dvoracek wrote: It's Knoppix 7.0.5, kernel 3.6.11 So, if you do: modprobe xhci-hcd from the command line, as root, what happens? It looks like Knoppix isn't loading the driver properly, it's not a kernel problem (yet), so I would recommend filing a bug with them, as I bet, once the driver is loaded, it will work better :) greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend PATCH 2/2] usb: add usb_enable/disable_remote_wakeup()
On Wed, Jan 23, 2013 at 03:09:19PM -0500, Alan Stern wrote: On Thu, 24 Jan 2013, Lan Tianyu wrote: + status = usb_disable_function_remotewakeup(udev); Don't call that function here. Just put the code here and run it directly. Then you can get rid of the old function. usb_disable_function_remotewakeup is just introduced at last patch to resolve too more indentation. So it's ok to remove it so quickly ? Or I should merge these two patches? I thought the purpose of patch 1/2 was to have something that could be applied to the -stable kernels. Isn't that what Sarah asked for? A short fix, followed by another patch that would clean up the mess. Yes, I wanted patch 1/2 to be applied to stable kernels. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
Hi Thomas, Le Wed, 23 Jan 2013 19:03:52 +0100, Thomas Petazzoni thomas.petazz...@free-electrons.com a écrit : On Wed, 23 Jan 2013 14:04:42 -0300, Ezequiel Garcia wrote: from the OpenBlocks AX3-4 board dts file, since you mentioned this board uses that USB port for a PCIe connector -- if I understood correctly. No. The OpenBlocks has a different USB controller that sits on the PCIe bus. There is nothing like a PCIe port that uses a USB port, that doesn't make sense. I don't have a AX3-4 but it seems to have a MiniPCIe socket and not a PCIe one. MiniPCIe specification includes both PCIe _and_ USB2.0 signals (on pins 3638) (and also SMBus, SIM and LEDs drivers check the following table for details http://pinoutsguide.com/Slots/mini_pcie_pinout.shtml ) so the possibility to have a USB port connected to the MiniPCIe on the AX3-4 makes sense. For example most 3G MiniPCIe boards are using the USB2.0 signals and not the PCIe ones. Eric -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with a USB 2.0 device with xhci_hcd
On Mon, Jan 21, 2013 at 03:24:03PM -0800, David Moore wrote:
On Mon, Jan 21, 2013 at 11:35 AM, Sarah Sharp sarah.a.sh...@linux.intel.com
wrote:
It's possible that the device is just buggy, and it expects the Windows
enumeration scheme. Windows will send an 8-byte request for the device
descriptor, set the device address, and then ask for the whole device
descriptor. We call this the 'new' enumerating scheme. Some devices
barf when Linux first sets the device address, then asks for the device
descriptor (the 'old' enumeration scheme).
Currently, devices under xHCI will always see the old enumeration
scheme. We'd have to add new API in order to facilitate the new
enumeration scheme.
You can test that hypothesis by loading the EHCI module and forcing it
to use the old enumeration scheme:
sudo modprobe ehci old_scheme_first=1 use_both_schemes=0
If you device doesn't enumerate under EHCI with those module parameters
set, then it probably doesn't tolerate the old enumeration scheme.
Yes, you are spot-on. I tried with those module options and then ehci can't
enumerate either (btw, the module with the options was usbcore, not
ehci):
[ 208.368058] hub 1-1:1.0: state 7 ports 6 chg evt 0008
[ 208.368372] hub 1-1:1.0: port 3, status 0101, change 0001, 12 Mb/s
[ 208.471954] hub 1-1:1.0: debounce: port 3: total 100ms stable 100ms
status 0x101
[ 208.482927] hub 1-1:1.0: port 3 not reset yet, waiting 10ms
[ 208.544751] usb 1-1.3: new high-speed USB device number 12 using ehci_hcd
[ 213.542183] usb 1-1.3: khubd timed out on ep0in len=0/8
[ 213.542192] usb 1-1.3: device descriptor read/8, error -110
Ok, good to know.
So I guess my next question is: What are you plans, if any, to add the
new enumeration scheme to xHCI? Is this a huge amount of work?
Not a huge amount of work, but it does require an API change to the USB
host controller driver functions, so the patch itself is not likely to
get backported to stable kernels. And I have no idea how the current
batch of USB 3.0 devices will react to an enumeration sequence change.
I've only heard of one other device that has this issue (a very old
mouse) in the 3+ years the xHCI driver has been out. I told the
reporters they probably should get another mouse, and put the todo item
aside. However, if buggy devices like your webcam are integrated into
systems, we really should support this behavior. It's just not very
high priority on my todo list.
Either way, your information has been very helpful. This gives me some
concrete information I can provide to the camera vendor. Hopefully this is
something they can adjust in firmware and is not baked into the Freescale
MX257 microcontroller that is being used.
Ok, let me know if you can't work it out with the camera vendor. Do you
know if they're already shipping devices with this bug?
Another thing I'd like to do is operate these ports as EHCI ports instead
of XHCI in order to solve my problem. I understand that ports can be
switchable, but I've had to jump through some hoops to get them into EHCI
mode. More on that later -- let's talk about the USB 3.0 issues first.
I don't want to facilitate people switching ports between EHCI and xHCI.
I don't like the Intel xHCI/EHCI port switchover mechanism, and I
frankly don't trust the BIOS to correct switchover the ports on the fly
after boot. I would rather attempt to solve issues with USB devices
under xHCI than sweep the issues under the rug by using EHCI.
Fair enough. For the record, let me tell you what I did to get EHCI working
on the USB 3.0 ports:
First, I had to disable CONFIG_USB_XHCI_HCD completely to prevent the
EHCI-xHCI switch from happening after boot. However, that wasn't enough --
it just gave me dead ports. I also had to apply this patch:
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index eb5563a..9dc3240 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -780,6 +780,7 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
defaulting to EHCI.\n);
dev_warn(xhci_pdev-dev,
USB 3.0 devices will work at USB 2.0 speeds.\n);
+usb_disable_xhci_ports(xhci_pdev);
return;
}
@@ -832,6 +833,7 @@ void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
{
pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0);
pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0);
+dev_dbg(xhci_pdev-dev, Disabling XHCI ports forcefully\n);
}
EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
Probably because my bios leaves the ports in xHCI mode after boot, I needed
the patch to get them back into EHCI mode. BTW, I'm using a Dell Optiplex
7010.
Once I did all that, the ports work fine as EHCI.
Ok, that's a much easier fix than the one I had in mind. Would you care
to create a patch (without the debug in
Re: [PATCH v9 20/20] mdf: omap-usb-host: get rid of build warning
Quoting Roger Quadros (2013-01-23 02:38:12)
Fixes the below build warning when driver is built-in.
drivers/mfd/omap-usb-host.c:750:12: warning:
‘usbhs_omap_remove’ defined but not used [-Wunused-function]
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Hi Roger,
I just noticed that $SUBJECT says mdf instead of mfd ;)
Regards,
Mike
---
drivers/mfd/omap-usb-host.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index b21ca76..6b5edf6 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -791,7 +791,7 @@ static struct platform_driver usbhs_omap_driver = {
.owner = THIS_MODULE,
.pm = usbhsomap_dev_pm_ops,
},
- .remove = __exit_p(usbhs_omap_remove),
+ .remove = usbhs_omap_remove,
};
MODULE_AUTHOR(Keshava Munegowda keshava_mgo...@ti.com);
--
1.7.4.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: USB3 Not Being Detected on Intel DX79TO Desktop Board
-- Forwarded message -- From: Robert Dvoracek lgtng...@gmail.com Date: Wed, Jan 23, 2013 at 6:45 PM Subject: Re: USB3 Not Being Detected on Intel DX79TO Desktop Board To: Greg KH gre...@linuxfoundation.org On Wed, Jan 23, 2013 at 3:18 PM, Greg KH gre...@linuxfoundation.org wrote: A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Jan 23, 2013 at 02:49:35PM -0500, Robert Dvoracek wrote: It's Knoppix 7.0.5, kernel 3.6.11 So, if you do: modprobe xhci-hcd from the command line, as root, what happens? It looks like Knoppix isn't loading the driver properly, it's not a kernel problem (yet), so I would recommend filing a bug with them, as I bet, once the driver is loaded, it will work better :) greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html A: Sorry, I just realized Gmail has been top posting for me. Thank you for bearing with me. When I do a modprobe xhci-hcd, nothing happens. Maybe I would have to modify the udev rules to get it to load since it is compiled into the kernel? Thanks, Robert -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Binding USB devices on LAN hosts to a peripheral controller using usbip
Hi, I am planning to build a USB device based on an embedded controller board having a (High-Speed) USB peripheral port and an (Gbit) Ethernet port. My goal is to connect arbitrary USB devices (e.g. physical mass storage / serial devices or gadgets like g_mass_storage, g_serial) attached to a host somewhere on the LAN to my device's USB peripheral port, so that I can use them on a physical device (e.g. mediaplayer) w/ USB port. I am new to the linux USB stack, so before I waste days or weeks until I find out it's not possible this way, I decided to ask the specialists. ;-) Here are my questions: Is there a simple way to bind a USB device connected to a host port to a peripheral port (e.g. via an existing gadget)? (Couldn't find one so far.) Does the current usbip protocol provide enough information to make this also work for usbip'd devices? (No clue.) If not, would it be (relatively easily) possible to extend the usbip protocol to accomplish this? If I have to write my own gadget: It would be more general to bind the usbip-vhci (or whatever HCI) device to a peripheral port. On the other hand this means more overhead. The data will go through two drivers (vhci-hcd and my gadget) and both have to run on an embedded controller where I only have limited CPU power. Therefore it would be better to build one gadget that has the usbip protocol built-in. (The usbip protocol implementation could then possibly be placed into a separate kernel module.) Another question is: are there device controllers which can act as multiple (NOT multifunction composite) devices so that the attached host will see a hub? I did read something about hub controllers, but are these what I mean and are any supported by the linux USB stack? Any comments? :-) Thanks in advance, Carsten -- Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr. (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
