[PATCH 2/8] usb/dwc3: Fix missed isoc
There are two reasons to generate missed isoc.
1. when the host does not poll for all the data.
2. because of application-side delays that prevent all the data from
being transferred in programmed microframe.
Current code was able to handle first case only. Now we take following
approach to handle missed isoc.
If missed isoc occurred and there is no request queued then issue END
TRANSFER, so that core generates next xfernotready and we will issue a
fresh START TRANSFER.
If there are still queued request then wait, do not issue either END or
UPDATE TRANSFER, just attach next request in request_list during giveback.
If any future queued request is successfully transferred then we will issue
UPDATE TRANSFER for all request in the request_list.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/core.h |2 --
drivers/usb/dwc3/gadget.c | 36
2 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4999563..1dae91d 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -405,7 +405,6 @@ struct dwc3_event_buffer {
* @number: endpoint number (1 - 15)
* @type: set to bmAttributes USB_ENDPOINT_XFERTYPE_MASK
* @resource_index: Resource transfer index
- * @current_uf: Current uf received through last event parameter
* @interval: the intervall on which the ISOC transfer is started
* @name: a human readable name e.g. ep1out-bulk
* @direction: true for TX, false for RX
@@ -439,7 +438,6 @@ struct dwc3_ep {
u8 number;
u8 type;
u8 resource_index;
- u16 current_uf;
u32 interval;
charname[20];
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 74d2496..bbbcd2e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1117,16 +1117,6 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
dep-name);
}
- /*
-* 3. Missed ISOC Handling. We need to start isoc transfer on the saved
-* uframe number.
-*/
- if (usb_endpoint_xfer_isoc(dep-endpoint.desc)
- (dep-flags DWC3_EP_MISSED_ISOC)) {
- __dwc3_gadget_start_isoc(dwc, dep, dep-current_uf);
- dep-flags = ~DWC3_EP_MISSED_ISOC;
- }
-
return 0;
}
@@ -1688,14 +1678,29 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
if (trb_status == DWC3_TRBSTS_MISSED_ISOC) {
dev_dbg(dwc-dev, incomplete IN
transfer %s\n,
dep-name);
- dep-current_uf = event-parameters
- ~(dep-interval - 1);
+ /*
+* If missed isoc occurred and there is
+* no request queued then issue END
+* TRANSFER, so that core generates
+* next xfernotready and we will issue
+* a fresh START TRANSFER.
+* If there are still queued request
+* then wait, do not issue either END
+* or UPDATE TRANSFER, just attach next
+* request in request_list during
+* giveback.If any future queued request
+* is successfully transferred then we
+* will issue UPDATE TRANSFER for all
+* request in the request_list.
+*/
dep-flags |= DWC3_EP_MISSED_ISOC;
} else {
dev_err(dwc-dev, incomplete IN
transfer %s\n,
dep-name);
status = -ECONNRESET;
}
+ } else {
+ dep-flags = ~DWC3_EP_MISSED_ISOC;
}
} else {
if (count (event-status DEPEVT_STATUS_SHORT))
@@ -1722,6 +1727,13 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
break;
} while (1);
+ if (list_empty(dep-req_queued)
+ (dep-flags DWC3_EP_MISSED_ISOC)) {
+
[PATCH 4/8] usb/dwc3: fix isoc END TRANSFER Condition
There were still some corner cases where isoc transfer was not able to
restart, specially when missed isoc does not happen , and in fact gadget does
not queue any new request during giveback.
Cleanup function calls giveback first, which provides a way to queue
another request to gadget. But gadget did not had any data. So , it did
not call ep_queue. To twist it further, gadget did not queue till
cleanup for last queued TRB is called. If we ever reach this scenario,
we must call END TRANSFER, so that we receive a new xfernotready with
information about current microframe number.
Also insure that there is no request submitted to core when issuing END
TRANSFER.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c | 23 ++-
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4d24711..45db6df 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1089,7 +1089,10 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
* notion of current microframe.
*/
if (usb_endpoint_xfer_isoc(dep-endpoint.desc)) {
- dwc3_stop_active_transfer(dwc, dep-number);
+ if (list_empty(dep-req_queued)) {
+ dwc3_stop_active_transfer(dwc, dep-number);
+ dep-flags = DWC3_EP_ENABLED;
+ }
return 0;
}
@@ -1727,10 +1730,20 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
break;
} while (1);
- if (list_empty(dep-req_queued)
- (dep-flags DWC3_EP_MISSED_ISOC)) {
- dwc3_stop_active_transfer(dwc, dep-number);
- dep-flags = ~DWC3_EP_MISSED_ISOC;
+ if (usb_endpoint_xfer_isoc(dep-endpoint.desc)
+ (list_empty(dep-req_queued))) {
+ if (list_empty(dep-request_list)) {
+ /*
+* If there is no entry in request list then do
+* not issue END TRANSFER now. Just set PENDING
+* flag, so that END TRANSFER is issued when an
+* entry is added into request list.
+*/
+ dep-flags = DWC3_EP_PENDING_REQUEST;
+ } else {
+ dwc3_stop_active_transfer(dwc, dep-number);
+ dep-flags = DWC3_EP_ENABLED;
+ }
return 1;
}
--
1.7.5.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 6/8] usb/dwc3: No need to pass params in case of UPDATE TRANSFER
UPDATE transfer does not need any parameters. So, no need to prepare it.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 55d8bfd..d263b71 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -974,13 +974,14 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep
*dep, u16 cmd_param,
}
memset(params, 0, sizeof(params));
- params.param0 = upper_32_bits(req-trb_dma);
- params.param1 = lower_32_bits(req-trb_dma);
- if (start_new)
+ if (start_new) {
+ params.param0 = upper_32_bits(req-trb_dma);
+ params.param1 = lower_32_bits(req-trb_dma);
cmd = DWC3_DEPCMD_STARTTRANSFER;
- else
+ } else {
cmd = DWC3_DEPCMD_UPDATETRANSFER;
+ }
cmd |= DWC3_DEPCMD_PARAM(cmd_param);
ret = dwc3_send_gadget_ep_cmd(dwc, dep-number, cmd, params);
--
1.7.5.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/8] usb/dwc3: Correct Return from ep_queue
Its better to return from each if condition as they are mutually
exclusive.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index bbbcd2e..4d24711 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1082,8 +1082,6 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
*
*/
if (dep-flags DWC3_EP_PENDING_REQUEST) {
- int ret;
-
/*
* If xfernotready is already elapsed and it is a case
* of isoc transfer, then issue END TRANSFER, so that
@@ -1099,6 +1097,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
if (ret ret != -EBUSY)
dev_dbg(dwc-dev, %s: failed to kick transfers\n,
dep-name);
+ return ret;
}
/*
@@ -1115,6 +1114,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
if (ret ret != -EBUSY)
dev_dbg(dwc-dev, %s: failed to kick transfers\n,
dep-name);
+ return ret;
}
return 0;
--
1.7.5.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 8/8] usb/dwc3: req-queued must be forced to false in cleanup
I am not sure, why I found it during SG debugging. But, I noticed that even when req_queued list was empty, there were some request in request_list having queued flag true. If I run test second time, it first removes all request from request_list and hence busy_slot was wrongly incremented. Signed-off-by: Pratyush Anand pratyush.an...@st.com --- drivers/usb/dwc3/gadget.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 3d52876..a511cde 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -257,6 +257,7 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct dwc3_request *req, usb_endpoint_xfer_isoc(dep-endpoint.desc)) dep-busy_slot++; } while (++i req-request.num_mapped_sgs); + req-queued = false; } list_del(req-list); req-trb = NULL; -- 1.7.5.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/8] usb/dwc3: Fix scatter gather implementation
To work with scatter gather properly, fixes have been done in number of
functions. I will explain requirement of each fixes one by one.
start_slot: used to retrieve all request of SG during cleanup
dwc3_gadget_giveback: We need to skip link TRB if it was one of the
intermediate TRB of SG.
dwc3_prepare_one_trb: We need to track all submitted TRBs during
cleanup. Since, all TRBs would be serially allocated, so we can just
keep starting slot info and we can always find rest of them. We need to
pass sg node number, so that we cab appropriately program ISOC_FIRST/ISOC,
Chain etc.
dwc3_prepare_trbs: last_one should be set when it is last node
of SG as well as last node of request_list.
__dwc3_cleanup_done_trbs: It has been prepared after re-factorization of
dwc3_cleanup_done_reqs. It is called for each TRB of SG.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/core.h |1 +
drivers/usb/dwc3/gadget.c | 218 ++---
2 files changed, 127 insertions(+), 92 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 1dae91d..9925f29 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -579,6 +579,7 @@ struct dwc3_request {
struct usb_request request;
struct list_headlist;
struct dwc3_ep *dep;
+ u32 start_slot;
u8 epnum;
struct dwc3_trb *trb;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index d263b71..3d52876 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -241,21 +241,22 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct
dwc3_request *req,
int status)
{
struct dwc3 *dwc = dep-dwc;
+ int i;
if (req-queued) {
- if (req-request.num_mapped_sgs)
- dep-busy_slot += req-request.num_mapped_sgs;
- else
+ i = 0;
+ do {
dep-busy_slot++;
-
- /*
-* Skip LINK TRB. We can't use req-trb and check for
-* DWC3_TRBCTL_LINK_TRB because it points the TRB we just
-* completed (not the LINK TRB).
-*/
- if (((dep-busy_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1)
+ /*
+* Skip LINK TRB. We can't use req-trb and check for
+* DWC3_TRBCTL_LINK_TRB because it points the TRB we
+* just completed (not the LINK TRB).
+*/
+ if (((dep-busy_slot DWC3_TRB_MASK) ==
+ DWC3_TRB_NUM - 1)
usb_endpoint_xfer_isoc(dep-endpoint.desc))
- dep-busy_slot++;
+ dep-busy_slot++;
+ } while (++i req-request.num_mapped_sgs);
}
list_del(req-list);
req-trb = NULL;
@@ -749,7 +750,7 @@ static void dwc3_gadget_ep_free_request(struct usb_ep *ep,
*/
static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
struct dwc3_request *req, dma_addr_t dma,
- unsigned length, unsigned last, unsigned chain)
+ unsigned length, unsigned last, unsigned chain, unsigned node)
{
struct dwc3 *dwc = dep-dwc;
struct dwc3_trb *trb;
@@ -765,14 +766,16 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
dep-free_slot++;
trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK];
- dep-free_slot++;
if (!req-trb) {
dwc3_gadget_move_request_queued(req);
req-trb = trb;
req-trb_dma = dwc3_trb_dma_offset(dep, trb);
+ req-start_slot = dep-free_slot DWC3_TRB_MASK;
}
+ dep-free_slot++;
+
trb-size = DWC3_TRB_SIZE_LENGTH(length);
trb-bpl = lower_32_bits(dma);
trb-bph = upper_32_bits(dma);
@@ -783,9 +786,12 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
break;
case USB_ENDPOINT_XFER_ISOC:
- trb-ctrl = DWC3_TRBCTL_ISOCHRONOUS_FIRST;
+ if (!node)
+ trb-ctrl = DWC3_TRBCTL_ISOCHRONOUS_FIRST;
+ else
+ trb-ctrl = DWC3_TRBCTL_ISOCHRONOUS;
- if (!req-request.no_interrupt)
+ if (!req-request.no_interrupt !chain)
trb-ctrl |= DWC3_TRB_CTRL_IOC;
break;
@@ -804,14 +810,13 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
if (usb_endpoint_xfer_isoc(dep-endpoint.desc)) {
trb-ctrl |= DWC3_TRB_CTRL_ISP_IMI;
trb-ctrl |= DWC3_TRB_CTRL_CSP;
- } else {
- if (chain)
- trb-ctrl |=
Re: [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
Hi Kishon, On 01/10/2013 07:19 AM, kishon wrote: On Friday 28 December 2012 12:05 AM, Aaro Koskinen wrote: Hi, On Thu, Sep 20, 2012 at 05:21:15AM +0200, Benoit Cousson wrote: On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include ARM: dts: * Added reg property and interrupt property for usb_otg_hs. Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data Thanks for the update. I've just pulled the series for 3.7. I wonder what happened to the patch #3 (Add usb_otg and glue data) of this series? Why was it dropped? I cannot see it in 3.7 or 3.8-rc1. I don't remember the context, can you repost it rebased on 3.8-rc2? Did it generate some discussion at that time? Benoit -- 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 autosuspend vs. URB submission
On Thursday 10 January 2013 13:13:58 Ming Lei wrote: IMO, there is a minor fault in the error handling path of uvc_status_start() inside uvc_v4l2_open(), and the 'users' count should have been decreased before usb_autopm_put_interface(). In theory, the warning can be triggered when the device is opened just between usb_autopm_put_interface() and atomic_dec(stream-dev-users), but I don't think it is the cause of the report. Hi, the analysis is sound. Good catch. As the fix is trivial, I am making a quick patch. Regards Oliver -- 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] uvc: fix race of open and suspend in error case
Ming Lei reported:
IMO, there is a minor fault in the error handling path of
uvc_status_start() inside uvc_v4l2_open(), and the 'users' count
should have been decreased before usb_autopm_put_interface().
In theory, the warning can be triggered when the device is
opened just between usb_autopm_put_interface() and
atomic_dec(stream-dev-users).
The fix is trivial.
Signed-off-by:Oliver Neukum oneu...@suse.de
---
drivers/media/usb/uvc/uvc_v4l2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index f2ee8c6..74937b7 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -501,8 +501,8 @@ static int uvc_v4l2_open(struct file *file)
if (atomic_inc_return(stream-dev-users) == 1) {
ret = uvc_status_start(stream-dev);
if (ret 0) {
- usb_autopm_put_interface(stream-dev-intf);
atomic_dec(stream-dev-users);
+ usb_autopm_put_interface(stream-dev-intf);
kfree(handle);
return ret;
}
--
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
[BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
Hi, Some recent patch has caused fsl_mxc_udc.c driver to fail compilation because it can't find mach/hardware.h anymore. I would like this to be fixed still during this -rc cycle. Thank you -- balbi signature.asc Description: Digital signature
[PATCH 5/8] usb/dwc3: Fix skip LINK-TRB on ISOC
When we reach to link trb, we just need to increase free_slot and then
calculate TRB. Return is not correct, as it will cause wrong TRB DMA
address to fetch in case of update transfer.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 45db6df..55d8bfd 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -754,21 +754,18 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
struct dwc3 *dwc = dep-dwc;
struct dwc3_trb *trb;
- unsigned intcur_slot;
-
dev_vdbg(dwc-dev, %s: req %p dma %08llx length %d%s%s\n,
dep-name, req, (unsigned long long) dma,
length, last ? last : ,
chain ? chain : );
- trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK];
- cur_slot = dep-free_slot;
- dep-free_slot++;
-
/* Skip the LINK-TRB on ISOC */
- if (((cur_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1)
+ if (((dep-free_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1)
usb_endpoint_xfer_isoc(dep-endpoint.desc))
- return;
+ dep-free_slot++;
+
+ trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK];
+ dep-free_slot++;
if (!req-trb) {
dwc3_gadget_move_request_queued(req);
--
1.7.5.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: gadget: move the global the_dev variable to their users
On Thu, Nov 08, 2012 at 07:24:13PM +0100, Sebastian Andrzej Siewior wrote: the u_ether.c file has a global variable named the_dev which keeps a pointer to the network device after it has been created via gether_setup_name(). It is only used internally by u_ether. This patches moves the variable to its users and passes it via the port.ioport where it is saved later anyway. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de care to refresh ? patching file drivers/usb/gadget/cdc2.c Hunk #1 succeeded at 106 with fuzz 2 (offset 3 lines). Hunk #2 succeeded at 121 (offset -4 lines). Hunk #3 succeeded at 153 (offset -13 lines). Hunk #4 succeeded at 186 (offset -13 lines). Hunk #5 succeeded at 193 with fuzz 2 (offset -14 lines). patching file drivers/usb/gadget/ether.c patching file drivers/usb/gadget/f_ecm.c patching file drivers/usb/gadget/f_eem.c patching file drivers/usb/gadget/f_ncm.c Hunk #1 succeeded at 1287 (offset 4 lines). Hunk #2 succeeded at 1322 (offset 4 lines). patching file drivers/usb/gadget/f_rndis.c patching file drivers/usb/gadget/f_subset.c patching file drivers/usb/gadget/g_ffs.c patching file drivers/usb/gadget/multi.c Hunk #1 succeeded at 136 (offset 2 lines). Hunk #2 succeeded at 151 (offset -5 lines). Hunk #3 succeeded at 202 (offset -24 lines). Hunk #4 succeeded at 256 (offset -36 lines). Hunk #5 succeeded at 303 (offset -36 lines). Hunk #6 succeeded at 310 with fuzz 2 (offset -42 lines). patching file drivers/usb/gadget/ncm.c patching file drivers/usb/gadget/nokia.c Hunk #1 succeeded at 100 with fuzz 2 (offset 1 line). Hunk #2 FAILED at 152. Hunk #3 succeeded at 158 (offset -25 lines). Hunk #4 succeeded at 193 (offset -25 lines). Hunk #5 succeeded at 206 with fuzz 1 (offset -27 lines). 1 out of 5 hunks FAILED -- saving rejects to file drivers/usb/gadget/nokia.c.rej patching file drivers/usb/gadget/u_ether.c Hunk #1 succeeded at 50 (offset 1 line). Hunk #2 succeeded at 728 (offset 1 line). Hunk #3 succeeded at 755 (offset 1 line). Hunk #4 succeeded at 801 (offset 1 line). Hunk #5 succeeded at 813 (offset 1 line). Hunk #6 succeeded at 822 (offset 1 line). Hunk #7 succeeded at 850 (offset 1 line). Hunk #8 succeeded at 885 (offset 1 line). Hunk #9 succeeded at 978 (offset 1 line). patching file drivers/usb/gadget/u_ether.h -- balbi signature.asc Description: Digital signature
Re: [V2 PATCH 01/27] usb: gadget: mv_udc: use udc_start and udc_stop functions
On Tue, Nov 27, 2012 at 10:06:00PM -0500, Chao Xie wrote: This patches converts the driver into the new style start/stop interface. As a result the driver no longer uses the static global the_conroller variable. Signed-off-by: Chao Xie chao@marvell.com Care to refresh ? patching file drivers/usb/gadget/mv_udc_core.c Hunk #9 FAILED at 2106. 1 out of 15 hunks FAILED -- saving rejects to file drivers/usb/gadget/mv_udc_core.c.rej -- balbi signature.asc Description: Digital signature
RE: [PATCH 1/1]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
Dear Sebastian:
-Original Message-
From: Sebastian Andrzej Siewior [mailto:sebast...@breakpoint.cc]
Sent: Thursday, January 10, 2013 5:30 AM
To: Fangxiaozhi (Franko)
Cc: Linlei (Lei Lin); Huqiao (C); linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/1]linux-usb:optimize to match the Huawei USB storage
devices and support new switch command
keep the CC list please.
On Wed, Jan 09, 2013 at 07:28:43AM +, Fangxiaozhi (Franko) wrote:
+/* This function will send
+ * a scsi switch command called rewind' to huawei dongle.
+ * When the dongle receives this command at the first time,
+ * it will reboot immediately,
+ * after rebooted, it will ignore this command and do nothing,
+ * if it receives this command again.
+ * So it is unnecessary to read its response. */
This is not how a proper multi line comment looks like. The line
break in the middle of the sentence does not look good IMHO.
---Sorry, but if not do that, the comment is longer than 80 characters
in
one line.
Don't cross 80 lines but you don't need a line break after send and
immediately, if you look at your initial patch.
+static int usb_stor_huawei_scsi_init(struct us_data *us) {
+ int result = 0;
+ int act_len = 0;
+ struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us-iobuf;
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01,
0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+ memset(bcbw, 0, sizeof(struct bulk_cb_wrap));
-set the whole bcbw to be 0.
+ bcbw-Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw-Tag = 0;
+ bcbw-DataTransferLength = 0;
+ bcbw-Flags = bcbw-Lun = 0;
+ bcbw-Length = sizeof(rewind_cmd);
--initialize every elements of the struct bulk_cb_wrap.
I asked earlier and I ask again: why memset to zero followed by init to
zero.
Could we stick to one thing?
-So these codes maybe seem to be redundant, but I think it can make the
codes to more clear.
It is point less. Looking at drivers/usb/storage/transport.c at other users
and
nobody is doing it. I don't see the point in assigning a values a few times
to zero.
Please remove the = 0 assignments.
You mean that we have to write as follows?
+ memset(bcbw, 0, sizeof(struct bulk_cb_wrap));
+ bcbw-Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw-Length = sizeof(rewind_cmd);
Right?
+ memcpy(bcbw-CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
bcbw,
+ US_BULK_CB_WRAP_LEN, act_len);
This looks like it could work. Was it really tested before sending
this time? :P
-Yes, it is tested OK before our submitting.
okay then.
+ US_DEBUGP(transfer actual length=%d, result=%d\n, act_len,
result);
+ return result;
+}
+
+/* usb_stor_huawei_dongles_pid: try to find the supported Huawei
+USB dongles
+ * In Huawei, they assign the following product IDs
+ * for all of their mobile broadband dongles,
+ * including the new dongles in the future.
+ * So if the product ID is not included in this list,
+ * it means it is not Huawei's mobile broadband dongles.
+ */
Not a proper multiple line comment. Kernel doc format is different
btw. and is described in Documentation/kernel-doc-nano-HOWTO.txt
--Do you mean to write the comment like that:
Example kernel-doc function comment:
/**
* foobar() - short function description of foobar
* @arg1: Describe the first argument to foobar.
* @arg2: Describe the second argument to foobar.
* One can provide multiple line descriptions
* for arguments.
*
* A longer description, with more discussion of the function foobar()
* that might be useful to those using or modifying it. Begins with
* empty comment line, and may include additional embedded empty
* comment lines.
*
* The longer description can have multiple paragraphs.
*
* Return: Describe the return value of foobar.
*/
Yes, something like that. A short comment would work, too. However since you
added the function name in top of your comment you should stick to a
standard form.
+static int usb_stor_huawei_dongles_pid(struct us_data *us) {
+ struct usb_interface_descriptor *idesc;
+ int idProduct;
+
+ idesc = us-pusb_intf-cur_altsetting-desc;
+ idProduct = us-pusb_dev-descriptor.idProduct;
+ /* The first port is CDROM,
+* means the dongle in the single port mode,
+* and a switch command is required to be sent. */
+ if (idesc idesc-bInterfaceNumber == 0) {
+ if ((idProduct == 0x1001)
+
Re: [V2 PATCH 02/27] usb: gadget: mv_udc: use devm_xxx for probe
On Tue, Nov 27, 2012 at 10:06:01PM -0500, Chao Xie wrote: use devm_xxx for udc driver probe. So we do need care about the resources release in driver remove or failure handling in driver probe. Signed-off-by: Chao Xie chao@marvell.com care to refresh ? patching file drivers/usb/gadget/mv_udc_core.c Hunk #1 FAILED at 2115. Hunk #2 FAILED at 2129. Hunk #3 FAILED at 2185. Hunk #4 succeeded at 2279 (offset 14 lines). Hunk #5 succeeded at 2291 (offset 14 lines). Hunk #6 succeeded at 2302 (offset 14 lines). Hunk #7 succeeded at 2330 (offset 14 lines). Hunk #8 succeeded at 2352 (offset 14 lines). Hunk #9 succeeded at 2368 (offset 14 lines). Hunk #10 succeeded at 2380 (offset 14 lines). Hunk #11 FAILED at 2384. Hunk #12 FAILED at 2491. 5 out of 12 hunks FAILED -- saving rejects to file drivers/usb/gadget/mv_udc_core.c.rej -- balbi signature.asc Description: Digital signature
Re: [V2 PATCH 08/27] usb: gadget: mv_udc: fix the value of tranceiver
On Tue, Nov 27, 2012 at 10:06:07PM -0500, Chao Xie wrote: usally we will use udc-tranceiver == NULL or udc-tranceiver != NULL. So when failed to get the udc-tranceiver by usb_get_phy(), we directly set udc-tranceiver to be NULL. Then the source code will not need macro IS_ERR_OR_NULL() for udc-tranceiver judgement. It can reduce the line size and make the judgement simple. Signed-off-by: Chao Xie chao@marvell.com care to refresh ? patching file drivers/usb/gadget/mv_udc_core.c Hunk #1 succeeded at 1408 with fuzz 2 (offset 14 lines). Hunk #2 FAILED at 2174. Hunk #3 succeeded at 2363 (offset 44 lines). Hunk #4 succeeded at 2442 with fuzz 1 (offset 56 lines). Hunk #5 succeeded at 2475 with fuzz 1 (offset 54 lines). 1 out of 5 hunks FAILED -- saving rejects to file drivers/usb/gadget/mv_udc_core.c.rej -- balbi signature.asc Description: Digital signature
Re: [V2 PATCH 20/27] usb: gadget: mv_udc: add extern chip support
On Tue, Nov 27, 2012 at 10:06:19PM -0500, Chao Xie wrote: Because arch-mmp will make use of irq domain for irq allocation, the irqs allocated for PMIC is dynamical. The vbus/idpin irqs from PMIC can not be passed by platform data. Using the extern chip APIs provides by PHY driver can solve this problem. Marvell usb PHY driver provides a middle layer. The PMIC usb drivers will help to register the callbacks in the marvell usb PHY driver. udc/otg/ehci driver will call the callbacks. Then we do not need pass the information in platform data. It will remove another block in the way of enabling device tree for usb. Signed-off-by: Chao Xie chao@marvell.com care to refresh ? patching file drivers/usb/gadget/mv_udc.h patching file drivers/usb/gadget/mv_udc_core.c Hunk #2 succeeded at 1125 (offset 3 lines). Hunk #3 succeeded at 1151 (offset 3 lines). Hunk #4 succeeded at 2231 with fuzz 2 (offset 36 lines). Hunk #5 FAILED at 2208. 1 out of 5 hunks FAILED -- saving rejects to file drivers/usb/gadget/mv_udc_core.c.rej -- balbi signature.asc Description: Digital signature
Re: [V2 PATCH 20/27] usb: gadget: mv_udc: add extern chip support
On Tue, Nov 27, 2012 at 10:06:19PM -0500, Chao Xie wrote: Because arch-mmp will make use of irq domain for irq allocation, the irqs allocated for PMIC is dynamical. The vbus/idpin irqs from PMIC can not be passed by platform data. Using the extern chip APIs provides by PHY driver can solve this problem. Marvell usb PHY driver provides a middle layer. The PMIC usb drivers will help to register the callbacks in the marvell usb PHY driver. udc/otg/ehci driver will call the callbacks. Then we do not need pass the information in platform data. It will remove another block in the way of enabling device tree for usb. Signed-off-by: Chao Xie chao@marvell.com previous mail was wrong, still needs to refresh: patching file drivers/usb/gadget/mv_udc.h Hunk #1 succeeded at 178 with fuzz 1. patching file drivers/usb/gadget/mv_udc_core.c Hunk #1 succeeded at 2091 (offset 14 lines). Hunk #2 succeeded at 2109 (offset 14 lines). Hunk #3 succeeded at 2138 (offset 11 lines). Hunk #4 FAILED at 2175. Hunk #5 FAILED at 2325. Hunk #6 succeeded at 2390 (offset 45 lines). Hunk #7 FAILED at 2370. Hunk #8 FAILED at 2388. Hunk #9 succeeded at 2453 with fuzz 1 (offset 58 lines). 4 out of 9 hunks FAILED -- saving rejects to file drivers/usb/gadget/mv_udc_core.c.rej -- balbi signature.asc Description: Digital signature
Re: [V2 PATCH 25/27] usb: gadget: mv_udc: add device tree support
On Tue, Nov 27, 2012 at 10:06:24PM -0500, Chao Xie wrote: In original driver, we have callbacks in platform data, and some dynamically allocations variables in platform data. Now, these blocks are removed, the device tree support is easier now. Signed-off-by: Chao Xie chao@marvell.com care to refresh ? patching file drivers/usb/gadget/mv_udc.h Hunk #1 FAILED at 179. Hunk #2 succeeded at 219 with fuzz 1 (offset -3 lines). 1 out of 2 hunks FAILED -- saving rejects to file drivers/usb/gadget/mv_udc.h.rej patching file drivers/usb/gadget/mv_udc_core.c Hunk #1 succeeded at 34 with fuzz 2. Hunk #2 FAILED at 2154. Hunk #3 FAILED at 2176. Hunk #4 FAILED at 2192. Hunk #5 succeeded at 2513 (offset 46 lines). Hunk #6 succeeded at 2528 (offset 46 lines). 3 out of 6 hunks FAILED -- saving rejects to file drivers/usb/gadget/mv_udc_core.c.rej -- balbi signature.asc Description: Digital signature
Re: [V2 PATCH 00/27] mv-usb fix and enhancement patches
Hi, On Tue, Jan 08, 2013 at 04:32:41PM +0800, Chao Xie wrote: On Sat, Jan 5, 2013 at 9:35 AM, Chao Xie xiechao.m...@gmail.com wrote: hi, Felipe How about these patches? i see that 3.8-rc2 is tagged but these patches are not merged. Thanks. On Tue, Dec 4, 2012 at 3:34 PM, Haojian Zhuang haojian.zhu...@gmail.com wrote: On Fri, Nov 30, 2012 at 10:10 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Nov 27, 2012 at 10:05:59PM -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 clk APIs usb: otg: mv_otg: use devm_xxx for probe usb: otg: mv_otg: fix the clk APIs usb: host: ehci-mv: fix clk APIs usb: host: ehci-mv: remove unused variable usb: gadget: mv_udc: fix the value of tranceiver Above patches are bug fixes. The gadget and OTG parts I will start queueing once v3.8-rc1 is tagged, please hang on. -- balbi Acked for all patches in arch-mmp. hi, Felipe How about the patches for 2. PHY driver 3. external chip support? Do i need re-submit the patches? Thanks. please refresh against v3.8-rc3 and add Haojian's acked-by to all arch/* patches. thank you -- balbi signature.asc Description: Digital signature
Re: [PATCH] uvc: fix race of open and suspend in error case
Hi Oliver,
Thank you for the patch.
On Thursday 10 January 2013 11:04:55 Oliver Neukum wrote:
Ming Lei reported:
IMO, there is a minor fault in the error handling path of
uvc_status_start() inside uvc_v4l2_open(), and the 'users' count
should have been decreased before usb_autopm_put_interface().
In theory, the warning can be triggered when the device is
opened just between usb_autopm_put_interface() and
atomic_dec(stream-dev-users).
The fix is trivial.
Signed-off-by:Oliver Neukum oneu...@suse.de
I've slightly modified the commit message with more details about the warning:
uvcvideo: Fix race of open and suspend in error case
Ming Lei reported:
IMO, there is a minor fault in the error handling path of
uvc_status_start() inside uvc_v4l2_open(), and the 'users' count should
have been decreased before usb_autopm_put_interface(). In theory, a [URB
resubmission] warning can be triggered when the device is opened just
between usb_autopm_put_interface() and atomic_dec(stream-dev-users).
The fix is trivial.
Reported-by: Ming Lei tom.leim...@gmail.com
Signed-off-by: Oliver Neukum oneu...@suse.de
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
The patch is in my tree, I'll push it to v3.9.
---
drivers/media/usb/uvc/uvc_v4l2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
b/drivers/media/usb/uvc/uvc_v4l2.c index f2ee8c6..74937b7 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -501,8 +501,8 @@ static int uvc_v4l2_open(struct file *file)
if (atomic_inc_return(stream-dev-users) == 1) {
ret = uvc_status_start(stream-dev);
if (ret 0) {
- usb_autopm_put_interface(stream-dev-intf);
atomic_dec(stream-dev-users);
+ usb_autopm_put_interface(stream-dev-intf);
kfree(handle);
return ret;
}
--
Regards,
Laurent Pinchart
--
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/8] usb/dwc3: Fix missed isoc
On Thu, Jan 10, 2013 at 03:23:16PM +0530, Pratyush Anand wrote: There are two reasons to generate missed isoc. 1. when the host does not poll for all the data. 2. because of application-side delays that prevent all the data from being transferred in programmed microframe. Current code was able to handle first case only. Now we take following approach to handle missed isoc. If missed isoc occurred and there is no request queued then issue END TRANSFER, so that core generates next xfernotready and we will issue a fresh START TRANSFER. If there are still queued request then wait, do not issue either END or UPDATE TRANSFER, just attach next request in request_list during giveback. If any future queued request is successfully transferred then we will issue UPDATE TRANSFER for all request in the request_list. Signed-off-by: Pratyush Anand pratyush.an...@st.com this is the *THIRD* patch fixing for missed ISOC. Something is going on, make sure to test this properly and fix missed ISOC once and for all. I will wait for testcases which show how to reproduce the problem and after applying this patch fixes it. Also, make sure to let me know how you tested it, which gadget drivers have you used ? I would like to have g_zero, g_audio and g_webcam tested to make sure different use cases are exercised. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
Hi, On Thursday 10 January 2013 03:28 PM, Benoit Cousson wrote: Hi Kishon, On 01/10/2013 07:19 AM, kishon wrote: On Friday 28 December 2012 12:05 AM, Aaro Koskinen wrote: Hi, On Thu, Sep 20, 2012 at 05:21:15AM +0200, Benoit Cousson wrote: On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include ARM: dts: * Added reg property and interrupt property for usb_otg_hs. Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data Thanks for the update. I've just pulled the series for 3.7. I wonder what happened to the patch #3 (Add usb_otg and glue data) of this series? Why was it dropped? I cannot see it in 3.7 or 3.8-rc1. I don't remember the context, can you repost it rebased on 3.8-rc2? Did it generate some discussion at that time? That patch also has SCM register. It might be rejected because of that. Will work on the that. Thanks Kishon -- 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/8] usb/dwc3: Fix missed isoc
On 1/10/2013 4:20 PM, Felipe Balbi wrote: On Thu, Jan 10, 2013 at 03:23:16PM +0530, Pratyush Anand wrote: There are two reasons to generate missed isoc. 1. when the host does not poll for all the data. 2. because of application-side delays that prevent all the data from being transferred in programmed microframe. Current code was able to handle first case only. Now we take following approach to handle missed isoc. If missed isoc occurred and there is no request queued then issue END TRANSFER, so that core generates next xfernotready and we will issue a fresh START TRANSFER. If there are still queued request then wait, do not issue either END or UPDATE TRANSFER, just attach next request in request_list during giveback. If any future queued request is successfully transferred then we will issue UPDATE TRANSFER for all request in the request_list. Signed-off-by: Pratyush Anand pratyush.an...@st.com this is the *THIRD* patch fixing for missed ISOC. Something is going I think its second. ;) It was sent in aug -12 but not applied. Therefore I have resend it again after rebasing with latest tag. http://comments.gmane.org/gmane.linux.usb.general/69889 on, make sure to test this properly and fix missed ISOC once and for all. I will wait for testcases which show how to reproduce the problem and after applying this patch fixes it. Also, make sure to let me know how you tested it, which gadget drivers have you used ? I would like to have g_zero, g_audio and g_webcam tested to make sure different use cases are exercised. We have a custom gadget which supports f_sourcesink, f_uac2 and a custom video function (based on g_webcam) in a single composite device. Both audio and video gadget uses different isoc endpoint and at same time we run bulk in using testusb. Patches have been tested with this device. But, I think it can be reproduced easily by only g_zero too. Keep bInterval = 1 and then introduce delay of 150 us deliberately in source_sink_complete (to generate second condition as stated in commit log). Code should not work without this patch. Regards Pratyush cheers -- 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
xhci module fails when booting in UEFI mode
I've got a HP EliteBook 8470p on which I installed Debian Wheezy in UEFI mode. With both the 3.2 kernel from Wheezy, as the 3.7.1 kernel from experimental, xhci fails to initialize and my USB mouse connected to one of these ports is not recognized at all. The USB3 ports work fine in Windows. [1.316248] xhci_hcd :00:14.0: can't derive routing for PCI INT A [1.316251] xhci_hcd :00:14.0: PCI INT A: no GSI [1.316253] [1.316277] xhci_hcd :00:14.0: setting latency timer to 64 [1.316281] xhci_hcd :00:14.0: xHCI Host Controller [1.316287] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 1 [1.316393] xhci_hcd :00:14.0: cache line size of 64 is not supported [1.316395] xhci_hcd :00:14.0: request interrupt 255 failed [1.316447] xhci_hcd :00:14.0: USB bus 1 deregistered [1.316466] xhci_hcd :00:14.0: can't derive routing for PCI INT A [1.316467] xhci_hcd :00:14.0: init :00:14.0 fail, -22 [1.316505] xhci_hcd: probe of :00:14.0 failed with error -22 Full dmesg, lspci, lsusb and lsmod can be found here: http://artipc10.vub.ac.be/~frederik/uefi-xhci/ I found this report about the same problem on a HP Probook system: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072918 -- Frederik Himpe -- 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: ux500: use clk_prepare_enable and clk_disable_unprepare
On Mon, Jan 7, 2013 at 5:47 PM, Fabio Baltieri fabio.balti...@linaro.org wrote: This patch converts the module to use clk_prepare_enable and clk_disable_unprepare variants as required by common clock framework. Without this the system crash during probe function. Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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/8] usb/dwc3: Fix missed isoc
On Thu, Jan 10, 2013 at 04:47:05PM +0530, Pratyush Anand wrote: On 1/10/2013 4:20 PM, Felipe Balbi wrote: On Thu, Jan 10, 2013 at 03:23:16PM +0530, Pratyush Anand wrote: There are two reasons to generate missed isoc. 1. when the host does not poll for all the data. 2. because of application-side delays that prevent all the data from being transferred in programmed microframe. Current code was able to handle first case only. Now we take following approach to handle missed isoc. If missed isoc occurred and there is no request queued then issue END TRANSFER, so that core generates next xfernotready and we will issue a fresh START TRANSFER. If there are still queued request then wait, do not issue either END or UPDATE TRANSFER, just attach next request in request_list during giveback. If any future queued request is successfully transferred then we will issue UPDATE TRANSFER for all request in the request_list. Signed-off-by: Pratyush Anand pratyush.an...@st.com this is the *THIRD* patch fixing for missed ISOC. Something is going I think its second. ;) $ git log --oneline --grep=missed v3.8-rc3 -- drivers/usb/dwc3/gadget.c 79c9046 usb: dwc3: gadget: correct missed isoc when endpoint is busy d6d6ec7 usb: dwc3: Fix missed isoc IN transaction on, make sure to test this properly and fix missed ISOC once and for all. I will wait for testcases which show how to reproduce the problem and after applying this patch fixes it. Also, make sure to let me know how you tested it, which gadget drivers have you used ? I would like to have g_zero, g_audio and g_webcam tested to make sure different use cases are exercised. We have a custom gadget which supports f_sourcesink, f_uac2 and a custom video function (based on g_webcam) in a single composite device. Both audio and video gadget uses different isoc endpoint and at same time we run bulk in using testusb. Patches have been tested with this device. But, I think it can be reproduced easily by only g_zero too. Keep bInterval = 1 and then introduce delay of 150 us deliberately in source_sink_complete (to generate second condition as stated in commit log). Code should not work without this patch. ok, thanks for the update. Make sure to explain how you test on your commit log. It's important to have enough information specially judging that we already have 2 commits fixing missed ISOC in tree. -- balbi signature.asc Description: Digital signature
Re: [PATCH] cppi_dma: mark cppi_controller_create() and cppi_pool_init() as '__devinit'
On Mon, Nov 12, 2012 at 09:01:33PM +0300, Sergei Shtylyov wrote: This patch fixes the following: WARNING: vmlinux.o(.devinit.text+0x24ac): Section mismatch in reference from the function dma_controller_create() to the function .init.text:cppi_controller_start() The function __devinit dma_controller_create() references a function __init cppi_controller_start(). If cppi_controller_start is only used by dma_controller_create then annotate cppi_controller_start with a matching annotation. This warning is there due to the deficiency in the commit 07a67bbb (usb: musb: Make dma_controller_create __devinit). Since the start() method is only called from musb_init_controller() which is marked '__devinit', mark cppi_controller_start() '__devinit' and also mark cppi_pool_init() as such since it gets called from that function, to avoid another section mismatch warning... Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com Cc: sta...@vger.kernel.org # 3.7+ is this still necessary provided all __dev* were removed ? -- balbi signature.asc Description: Digital signature
Re: [V2 PATCH 00/27] mv-usb fix and enhancement patches
On Tue, Nov 27, 2012 at 10:05:59PM -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 clk APIs usb: otg: mv_otg: use devm_xxx for probe usb: otg: mv_otg: fix the clk APIs usb: host: ehci-mv: fix clk APIs usb: host: ehci-mv: remove unused variable usb: gadget: mv_udc: fix the value of tranceiver 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. please refresh entire series against v3.8-rc3 and resend. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: musb: Double buffering issues in host mode TX
On Fri, Jan 04, 2013 at 05:10:33PM +0530, Supriya Karanth wrote: From: supriya karanth supriya.kara...@stericsson.com Whenever an URB is programmed for transfer, the TXFIFO is flushed. This results in valid packets of the previous transfer to get flushed when double buffering is enabled (The MUSB_TXCSR_FIFONOTEMPTY bit in TXCSR is set indicating that a packet in the FIFO is yet to be sent) For ex:- In Host mode Audio, noise is heard in the headset when double buffering is enabled on the ISO endpoint. The fifo flush is removed for double buffering case. The fifo is now flushed only in cases of error or when aborting a transfer. Also, In Host MSC case, data toggle errors are seen when double buffering is enabled on the bulk endpoint. Whenever an URB is programmed for transfer, the data toggle is set manually resulting in data toggle errors on the bus. Leave the data toggle handling upto the hardware in the double buffering case. Signed-off-by: supriya karanth supriya.kara...@stericsson.com Signed-off-by: Praveena NADAHALLY praveen.nadaha...@stericsson.com Acked-by: Linus Walleij linus.wall...@linaro.org how was this one tested ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] usb/acpi: binding xhci root hub usb port with ACPI
Hello. On 10-01-2013 10:52, Lan Tianyu wrote: This patch is to bind xhci root hub usb port with its acpi node. The port num in the acpi table matches with the sequence in the xhci extended capabilities table. So call usb_hcd_find_raw_port_number() to transfer hub port num into raw port number which associates with s/transfer/translate/? s/num/number/ the sequence in the xhci extended capabilities table before binding. Signed-off-by: Lan Tianyu tianyu@intel.com WBR, Sergei -- 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
ehci-hcd compile error
Hi Alan, with v3.8-rc3, ehci-hcd fails to compile for ARM if I use 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 Looks like the recent ARM multi-arch patches didn't take into account EHCI-hcd. Now it becomes easy to see why giving ehci its own platform_device/driver would've been a lot easier ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/8] usb/dwc3: fix isoc END TRANSFER Condition
Hello.
On 10-01-2013 13:53, Pratyush Anand wrote:
There were still some corner cases where isoc transfer was not able to
restart, specially when missed isoc does not happen , and in fact gadget does
not queue any new request during giveback.
Cleanup function calls giveback first, which provides a way to queue
another request to gadget. But gadget did not had any data. So , it did
not call ep_queue. To twist it further, gadget did not queue till
cleanup for last queued TRB is called. If we ever reach this scenario,
we must call END TRANSFER, so that we receive a new xfernotready with
information about current microframe number.
Also insure that there is no request submitted to core when issuing END
TRANSFER.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c | 23 ++-
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4d24711..45db6df 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
[...]
@@ -1727,10 +1730,20 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
break;
} while (1);
- if (list_empty(dep-req_queued)
- (dep-flags DWC3_EP_MISSED_ISOC)) {
- dwc3_stop_active_transfer(dwc, dep-number);
- dep-flags = ~DWC3_EP_MISSED_ISOC;
+ if (usb_endpoint_xfer_isoc(dep-endpoint.desc)
+ (list_empty(dep-req_queued))) {
Parens not needed at all around list_empty() invocation.
WBR, Sergei
--
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 2/2] usb: host: ohci-tmio: fix compile warning
Fix the following compile warning: In file included from drivers/usb/host/ohci-hcd.c:1170:0: drivers/usb/host/ohci-tmio.c: In function 'tmio_start_hc': drivers/usb/host/ohci-tmio.c:130:2: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'resource_size_t' [-Wformat] seen on ARM 32-bit builds. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/host/ohci-tmio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index d370245..5e3a6de 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -128,7 +128,8 @@ static void tmio_start_hc(struct platform_device *dev) tmio_iowrite8(2, tmio-ccr + CCR_INTC); dev_info(dev-dev, revision %d @ 0x%08llx, irq %d\n, - tmio_ioread8(tmio-ccr + CCR_REVID), hcd-rsrc_start, hcd-irq); + tmio_ioread8(tmio-ccr + CCR_REVID), + (u64) hcd-rsrc_start, hcd-irq); } static int ohci_tmio_start(struct usb_hcd *hcd) -- 1.8.1.rc1.5.g7e0651a -- 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] usb: host: imx21: fix compile error
Fix the following compile errors: drivers/usb/host/imx21-hcd.c:1929:20: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1930:15: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1931:16: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1932:14: error: expected declaration specifiers or '...' before string constant by including linux/module.h Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/host/imx21-hcd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/imx21-hcd.c b/drivers/usb/host/imx21-hcd.c index bd6a744..2637dba 100644 --- a/drivers/usb/host/imx21-hcd.c +++ b/drivers/usb/host/imx21-hcd.c @@ -50,6 +50,7 @@ */ #include linux/clk.h +#include linux/module.h #include linux/io.h #include linux/kernel.h #include linux/list.h -- 1.8.1.rc1.5.g7e0651a -- 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] cppi_dma: mark cppi_controller_create() and cppi_pool_init() as '__devinit'
Hello. On 10-01-2013 15:59, Felipe Balbi wrote: This patch fixes the following: WARNING: vmlinux.o(.devinit.text+0x24ac): Section mismatch in reference from the function dma_controller_create() to the function .init.text:cppi_controller_start() The function __devinit dma_controller_create() references a function __init cppi_controller_start(). If cppi_controller_start is only used by dma_controller_create then annotate cppi_controller_start with a matching annotation. This warning is there due to the deficiency in the commit 07a67bbb (usb: musb: Make dma_controller_create __devinit). Since the start() method is only called from musb_init_controller() which is marked '__devinit', mark cppi_controller_start() '__devinit' and also mark cppi_pool_init() as such since it gets called from that function, to avoid another section mismatch warning... Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com Cc: sta...@vger.kernel.org # 3.7+ is this still necessary provided all __dev* were removed ? I already told you it's not and posted a new patch. The only use it may have is to commit it to 3.7.y ISO that new patch since '__devinit' was still used in 3.7. WBR, Sergei -- 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: imx21: fix compile error
On Thu, Jan 10, 2013 at 10:41:44AM -0200, Fabio Estevam wrote: On Thu, Jan 10, 2013 at 10:32 AM, Felipe Balbi ba...@ti.com wrote: Fix the following compile errors: drivers/usb/host/imx21-hcd.c:1929:20: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1930:15: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1931:16: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1932:14: error: expected declaration specifiers or '...' before string constant by including linux/module.h Signed-off-by: Felipe Balbi ba...@ti.com I have already sent this fix: http://www.spinics.net/lists/linux-usb/msg75850.html my bad, didn't see this. Ignore this patch then ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] driver core: add helper macro for platform_driver_probe() boilerplate
Hi Greg,
I'm sorry, In the previous email I used your wrong email address,
in this email I've used your correct email address.
Best regards
Fabio Porcedda
On Wed, Jan 9, 2013 at 12:15 PM, Fabio Porcedda
fabio.porce...@gmail.com wrote:
For simple modules that contain a single platform_driver without any
additional setup code then ends up being a block of duplicated
boilerplate. This patch adds a new macro,
module_platform_driver_probe(), which replaces the
module_init()/module_exit() registrations with template functions.
This macro use the same idea of module_platform_driver().
This macro is useful to stop the misuse of module_platform_driver() for
removing the platform_driver_probe() boilerplate.
Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Greg Kroah-Hartman (linuxfoundation.org)
---
include/linux/platform_device.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index a9ded9a..c082c71 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -204,6 +204,24 @@ static inline void platform_set_drvdata(struct
platform_device *pdev, void *data
module_driver(__platform_driver, platform_driver_register, \
platform_driver_unregister)
+/* module_platform_driver_probe() - Helper macro for drivers that don't do
+ * anything special in module init/exit. This eliminates a lot of
+ * boilerplate. Each module may only use this macro once, and
+ * calling it replaces module_init() and module_exit()
+ */
+#define module_platform_driver_probe(__platform_driver, __platform_probe) \
+static int __init __platform_driver##_init(void) \
+{ \
+ return platform_driver_probe((__platform_driver), \
+__platform_probe);\
+} \
+module_init(__platform_driver##_init); \
+static void __exit __platform_driver##_exit(void) \
+{ \
+ platform_driver_unregister((__platform_driver)); \
+} \
+module_exit(__platform_driver##_exit);
+
extern struct platform_device *platform_create_bundle(struct platform_driver
*driver,
int (*probe)(struct platform_device
*),
struct resource *res, unsigned int
n_res,
--
1.8.0.3
--
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 RFC] usb: dwc3: Remove dwc3 dependency on gadget.
Hi,
On Mon, Dec 24, 2012 at 07:28:33PM +0530, Vivek Gautam wrote:
DWC3 controller curretly depends on CONFIG_USB and CONFIG_USB_GADGET.
Some hardware may like to use only host feature on dwc3.
So, removing the dependency of USB_DWC3 on USB_GADGET
and further modulating the dwc3 core to enable gadget features
only with USB_GADGET.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Doug Anderson diand...@chromium.org
right, right... Eventually we need to do it, but you're only making
gadget side optional. Host side should be optional too, but then you
need to make sure we don't build dwc3 without gadget and host.
Maybe make a mode selection for Host-only, Peripheral-only, Dual-Role
Device ??
More comments below...
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f6a6e07..b70dcf1 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,7 +1,7 @@
config USB_DWC3
tristate DesignWare USB3 DRD Core Support
- depends on (USB USB_GADGET)
- select USB_OTG_UTILS
+ depends on USB
+ select USB_OTG_UTILS if USB_GADGET
we want USB_OTG_UTILS also on host-only builds because host side,
eventually, will have to learn how to control its PHYs.
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 4502648..8f469cb 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -5,7 +5,7 @@ obj-$(CONFIG_USB_DWC3)+= dwc3.o
dwc3-y := core.o
dwc3-y += host.o
-dwc3-y += gadget.o ep0.o
+obj-$(CONFIG_USB_GADGET) += gadget.o ep0.o
this is wrong. CONFIG_USB_GADGET is tristate, so this should be:
ifneq($(CONFIG_USB_GADGET),)
dwc3-y += gadget.o ep0.o
endif
or something similar
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4999563..4dc7ef2 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -865,7 +865,14 @@ int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
int dwc3_host_init(struct dwc3 *dwc);
void dwc3_host_exit(struct dwc3 *dwc);
+#ifdef CONFIG_USB_GADGET
not taking into account module builds.
int dwc3_gadget_init(struct dwc3 *dwc);
void dwc3_gadget_exit(struct dwc3 *dwc);
+#else
+static inline int dwc3_gadget_init(struct dwc3 *dwc)
+{ return -EINVAL; }
+static inline void dwc3_gadget_exit(struct dwc3 *dwc)
+{ }
+#endif
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index d4a30f1..553bbaa 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -535,7 +535,8 @@ static ssize_t dwc3_testmode_write(struct file *file,
testmode = 0;
spin_lock_irqsave(dwc-lock, flags);
- dwc3_gadget_set_test_mode(dwc, testmode);
+ if (dwc3_gadget_set_test_mode(dwc, testmode))
+ dev_dbg(dwc-dev, host: Invalid request\n);
spin_unlock_irqrestore(dwc-lock, flags);
return count;
wrong, if you don't have gadget mode, you just don't create this file.
@@ -638,7 +639,8 @@ static ssize_t dwc3_link_state_write(struct file *file,
return -EINVAL;
spin_lock_irqsave(dwc-lock, flags);
- dwc3_gadget_set_link_state(dwc, state);
+ if (dwc3_gadget_set_link_state(dwc, state))
+ dev_dbg(dwc-dev, host: Invalid request\n);
likewise.
spin_unlock_irqrestore(dwc-lock, flags);
return count;
diff --git a/drivers/usb/dwc3/gadget.h b/drivers/usb/dwc3/gadget.h
index 99e6d72..28e82db 100644
--- a/drivers/usb/dwc3/gadget.h
+++ b/drivers/usb/dwc3/gadget.h
@@ -105,8 +105,16 @@ static inline void
dwc3_gadget_move_request_queued(struct dwc3_request *req)
void dwc3_gadget_giveback(struct dwc3_ep *dep, struct dwc3_request *req,
int status);
+#ifdef CONFIG_USB_GADGET
not taking into account CONFIG_USB_GADGET=m
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2] usb: host: imx21: fix compile error
On Thu, Jan 10, 2013 at 10:32 AM, Felipe Balbi ba...@ti.com wrote: Fix the following compile errors: drivers/usb/host/imx21-hcd.c:1929:20: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1930:15: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1931:16: error: expected declaration specifiers or '...' before string constant drivers/usb/host/imx21-hcd.c:1932:14: error: expected declaration specifiers or '...' before string constant by including linux/module.h Signed-off-by: Felipe Balbi ba...@ti.com I have already sent this fix: http://www.spinics.net/lists/linux-usb/msg75850.html Regards, Fabio Estevam -- 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: ux500: use clk_prepare_enable and clk_disable_unprepare
Hello Linus, On Thu, Jan 10, 2013 at 12:23:32PM +0100, Linus Walleij wrote: On Mon, Jan 7, 2013 at 5:47 PM, Fabio Baltieri fabio.balti...@linaro.org wrote: This patch converts the module to use clk_prepare_enable and clk_disable_unprepare variants as required by common clock framework. Without this the system crash during probe function. Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org Acked-by: Linus Walleij linus.wall...@linaro.org Thanks for the ACK. This bug was here unnoticed since 3.6 merge window, do you think it may make sense to add this driver to u8500_defconfig? I can send a patch if you say so... Thanks, Fabio -- Fabio Baltieri -- 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] CDC_NCM adding support IFF_NOARP for buggy device
Signed-off-by: Wei Shuai cpuw...@gmail.com
---
drivers/net/usb/cdc_ncm.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 71b6e92..9903f79 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -545,6 +545,7 @@ EXPORT_SYMBOL_GPL(cdc_ncm_unbind);
static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
{
int ret;
+ struct usb_device *udev = interface_to_usbdev(intf);
/* The MBIM spec defines a NCM compatible default altsetting,
* which we may have matched:
@@ -572,6 +573,10 @@ static int cdc_ncm_bind(struct usbnet *dev, struct
usb_interface *intf)
cdc_ncm_comm_intf_is_mbim(intf-cur_altsetting))
return -ENODEV;
#endif
+ /* this buggy device cannot do ARP */
+ if( (le16_to_cpu(udev-descriptor.idVendor) == 0x) ) {
+ dev-net-flags |= IFF_NOARP;
+ }
/* NCM data altsetting is always 1 */
ret = cdc_ncm_bind_common(dev, intf, 1);
@@ -1186,6 +1191,16 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long) wwan_info,
},
+ /* buggy device cannot send ARP */
+ { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+ | USB_DEVICE_ID_MATCH_VENDOR,
+ .idVendor = 0x,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_NCM,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long) wwan_info,
+ },
+
/* Huawei NCM devices disguised as vendor specific */
{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16),
.driver_info = (unsigned long)wwan_info,
--
1.7.6.5
--
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
[balbi-usb:gadget 13/13] drivers/usb/gadget/m66592-udc.c:1756:1: warning: data definition has no type or storage class
Hi Fabio,
FYI, there are new compile warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git gadget
head: df2167b3770a6ed33eb567d390b1a24a7efddcd9
commit: df2167b3770a6ed33eb567d390b1a24a7efddcd9 [13/13] usb: convert
drivers/usb/* to use module_platform_driver_probe()
config: make ARCH=x86_64 allmodconfig
All warnings:
drivers/usb/gadget/m66592-udc.c:1756:1: warning: data definition has no type or
storage class [enabled by default]
drivers/usb/gadget/m66592-udc.c:1756:1: warning: type defaults to 'int' in
declaration of 'module_platform_driver_probe' [-Wimplicit-int]
drivers/usb/gadget/m66592-udc.c:1756:1: warning: parameter names (without
types) in function declaration [enabled by default]
drivers/usb/gadget/m66592-udc.c:1598:19: warning: 'm66592_probe' defined but
not used [-Wunused-function]
drivers/usb/gadget/m66592-udc.c:1748:31: warning: 'm66592_driver' defined but
not used [-Wunused-variable]
--
drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: data definition has no type
or storage class [enabled by default]
drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: type defaults to 'int' in
declaration of 'module_platform_driver_probe' [-Wimplicit-int]
drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: parameter names (without
types) in function declaration [enabled by default]
drivers/usb/gadget/r8a66597-udc.c:1869:19: warning: 'r8a66597_probe' defined
but not used [-Wunused-function]
drivers/usb/gadget/r8a66597-udc.c:2028:31: warning: 'r8a66597_driver' defined
but not used [-Wunused-variable]
--
drivers/usb/otg/gpio_vbus.c:412:1: warning: data definition has no type or
storage class [enabled by default]
drivers/usb/otg/gpio_vbus.c:412:1: warning: type defaults to 'int' in
declaration of 'module_platform_driver_probe' [-Wimplicit-int]
drivers/usb/otg/gpio_vbus.c:412:1: warning: parameter names (without types) in
function declaration [enabled by default]
drivers/usb/otg/gpio_vbus.c:239:19: warning: 'gpio_vbus_probe' defined but not
used [-Wunused-function]
drivers/usb/otg/gpio_vbus.c:401:31: warning: 'gpio_vbus_driver' defined but not
used [-Wunused-variable]
vim +1756 drivers/usb/gadget/m66592-udc.c
4cf2503c Yoshihiro Shimoda 2007-05-10 1592 }
4cf2503c Yoshihiro Shimoda 2007-05-10 1593
598f22e1 Yoshihiro Shimoda 2007-07-17 1594 static void
nop_completion(struct usb_ep *ep, struct usb_request *r)
598f22e1 Yoshihiro Shimoda 2007-07-17 1595 {
598f22e1 Yoshihiro Shimoda 2007-07-17 1596 }
598f22e1 Yoshihiro Shimoda 2007-07-17 1597
4cf2503c Yoshihiro Shimoda 2007-05-10 @1598 static int __init
m66592_probe(struct platform_device *pdev)
4cf2503c Yoshihiro Shimoda 2007-05-10 1599 {
2c59b0b7 Magnus Damm 2009-07-22 1600 struct resource *res,
*ires;
4cf2503c Yoshihiro Shimoda 2007-05-10 1601 void __iomem *reg =
NULL;
4cf2503c Yoshihiro Shimoda 2007-05-10 1602 struct m66592 *m66592 =
NULL;
af5be79a Magnus Damm 2008-10-31 1603 char clk_name[8];
4cf2503c Yoshihiro Shimoda 2007-05-10 1604 int ret = 0;
4cf2503c Yoshihiro Shimoda 2007-05-10 1605 int i;
4cf2503c Yoshihiro Shimoda 2007-05-10 1606
0a2e5b9b Magnus Damm 2008-11-13 1607 res =
platform_get_resource(pdev, IORESOURCE_MEM, 0);
4cf2503c Yoshihiro Shimoda 2007-05-10 1608 if (!res) {
4cf2503c Yoshihiro Shimoda 2007-05-10 1609 ret = -ENODEV;
0a2e5b9b Magnus Damm 2008-11-13 1610
pr_err(platform_get_resource error.\n);
4cf2503c Yoshihiro Shimoda 2007-05-10 1611 goto clean_up;
4cf2503c Yoshihiro Shimoda 2007-05-10 1612 }
4cf2503c Yoshihiro Shimoda 2007-05-10 1613
2c59b0b7 Magnus Damm 2009-07-22 1614 ires =
platform_get_resource(pdev, IORESOURCE_IRQ, 0);
2c59b0b7 Magnus Damm 2009-07-22 1615 if (!ires) {
4cf2503c Yoshihiro Shimoda 2007-05-10 1616 ret = -ENODEV;
2c59b0b7 Magnus Damm 2009-07-22 1617
dev_err(pdev-dev,
2c59b0b7 Magnus Damm 2009-07-22 1618
platform_get_resource IORESOURCE_IRQ error.\n);
4cf2503c Yoshihiro Shimoda 2007-05-10 1619 goto clean_up;
4cf2503c Yoshihiro Shimoda 2007-05-10 1620 }
4cf2503c Yoshihiro Shimoda 2007-05-10 1621
0a2e5b9b Magnus Damm 2008-11-13 1622 reg =
ioremap(res-start, resource_size(res));
4cf2503c Yoshihiro Shimoda 2007-05-10 1623 if (reg == NULL) {
4cf2503c Yoshihiro Shimoda 2007-05-10 1624 ret = -ENOMEM;
00274921 David Brownell2007-11-19 1625 pr_err(ioremap
error.\n);
4cf2503c Yoshihiro Shimoda 2007-05-10 1626 goto clean_up;
4cf2503c Yoshihiro Shimoda 2007-05-10 1627 }
4cf2503c Yoshihiro
Re: [PATCH] CDC_NCM adding support IFF_NOARP for buggy device
On Thursday 10 January 2013 21:59:28 Wei Shuai wrote:
Hi,
I am afraid this is done in an unclean manner.
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 71b6e92..9903f79 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -545,6 +545,7 @@ EXPORT_SYMBOL_GPL(cdc_ncm_unbind);
static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
{
int ret;
+ struct usb_device *udev = interface_to_usbdev(intf);
/* The MBIM spec defines a NCM compatible default altsetting,
* which we may have matched:
@@ -572,6 +573,10 @@ static int cdc_ncm_bind(struct usbnet *dev, struct
usb_interface *intf)
cdc_ncm_comm_intf_is_mbim(intf-cur_altsetting))
return -ENODEV;
#endif
+ /* this buggy device cannot do ARP */
+ if( (le16_to_cpu(udev-descriptor.idVendor) == 0x) ) {
+ dev-net-flags |= IFF_NOARP;
So either you do a check here ...
+ }
/* NCM data altsetting is always 1 */
ret = cdc_ncm_bind_common(dev, intf, 1);
@@ -1186,6 +1191,16 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long) wwan_info,
},
+ /* buggy device cannot send ARP */
+ { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+ | USB_DEVICE_ID_MATCH_VENDOR,
+ .idVendor = 0x,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_NCM,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long) wwan_info,
... or you define a matching id here and give it a flag in driver_info
But not both.
Regards
Oliver
--
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: [balbi-usb:gadget 13/13] drivers/usb/gadget/m66592-udc.c:1756:1: warning: data definition has no type or storage class
Hi, On Thu, Jan 10, 2013 at 10:10:02PM +0800, Fengguang Wu wrote: Hi Fabio, FYI, there are new compile warnings show up in tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git gadget head: df2167b3770a6ed33eb567d390b1a24a7efddcd9 commit: df2167b3770a6ed33eb567d390b1a24a7efddcd9 [13/13] usb: convert drivers/usb/* to use module_platform_driver_probe() config: make ARCH=x86_64 allmodconfig All warnings: drivers/usb/gadget/m66592-udc.c:1756:1: warning: data definition has no type or storage class [enabled by default] drivers/usb/gadget/m66592-udc.c:1756:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] drivers/usb/gadget/m66592-udc.c:1756:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/usb/gadget/m66592-udc.c:1598:19: warning: 'm66592_probe' defined but not used [-Wunused-function] drivers/usb/gadget/m66592-udc.c:1748:31: warning: 'm66592_driver' defined but not used [-Wunused-variable] -- drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: data definition has no type or storage class [enabled by default] drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/usb/gadget/r8a66597-udc.c:1869:19: warning: 'r8a66597_probe' defined but not used [-Wunused-function] drivers/usb/gadget/r8a66597-udc.c:2028:31: warning: 'r8a66597_driver' defined but not used [-Wunused-variable] -- drivers/usb/otg/gpio_vbus.c:412:1: warning: data definition has no type or storage class [enabled by default] drivers/usb/otg/gpio_vbus.c:412:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] drivers/usb/otg/gpio_vbus.c:412:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/usb/otg/gpio_vbus.c:239:19: warning: 'gpio_vbus_probe' defined but not used [-Wunused-function] drivers/usb/otg/gpio_vbus.c:401:31: warning: 'gpio_vbus_driver' defined but not used [-Wunused-variable] right, it's a dependency we're solving off line. Thanks for catching it. -- balbi signature.asc Description: Digital signature
Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
On Thu, Jan 10, 2013 at 12:08:35PM +0200, Felipe Balbi wrote: Hi, Some recent patch has caused fsl_mxc_udc.c driver to fail compilation because it can't find mach/hardware.h anymore. I would like this to be fixed still during this -rc cycle. Me too, who's sending a patch? :) -- 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: [balbi-usb:gadget 13/13] drivers/usb/gadget/m66592-udc.c:1756:1: warning: data definition has no type or storage class
On Thu, Jan 10, 2013 at 04:12:16PM +0200, Felipe Balbi wrote: Hi, On Thu, Jan 10, 2013 at 10:10:02PM +0800, Fengguang Wu wrote: Hi Fabio, FYI, there are new compile warnings show up in tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git gadget head: df2167b3770a6ed33eb567d390b1a24a7efddcd9 commit: df2167b3770a6ed33eb567d390b1a24a7efddcd9 [13/13] usb: convert drivers/usb/* to use module_platform_driver_probe() config: make ARCH=x86_64 allmodconfig All warnings: drivers/usb/gadget/m66592-udc.c:1756:1: warning: data definition has no type or storage class [enabled by default] drivers/usb/gadget/m66592-udc.c:1756:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] drivers/usb/gadget/m66592-udc.c:1756:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/usb/gadget/m66592-udc.c:1598:19: warning: 'm66592_probe' defined but not used [-Wunused-function] drivers/usb/gadget/m66592-udc.c:1748:31: warning: 'm66592_driver' defined but not used [-Wunused-variable] -- drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: data definition has no type or storage class [enabled by default] drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] drivers/usb/gadget/r8a66597-udc.c:2035:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/usb/gadget/r8a66597-udc.c:1869:19: warning: 'r8a66597_probe' defined but not used [-Wunused-function] drivers/usb/gadget/r8a66597-udc.c:2028:31: warning: 'r8a66597_driver' defined but not used [-Wunused-variable] -- drivers/usb/otg/gpio_vbus.c:412:1: warning: data definition has no type or storage class [enabled by default] drivers/usb/otg/gpio_vbus.c:412:1: warning: type defaults to 'int' in declaration of 'module_platform_driver_probe' [-Wimplicit-int] drivers/usb/otg/gpio_vbus.c:412:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/usb/otg/gpio_vbus.c:239:19: warning: 'gpio_vbus_probe' defined but not used [-Wunused-function] drivers/usb/otg/gpio_vbus.c:401:31: warning: 'gpio_vbus_driver' defined but not used [-Wunused-variable] right, it's a dependency we're solving off line. Thanks for catching it. See, I told you we would get emails about build problems, Fengguang is fast :) -- 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: fsl-mph-dr-of: fix regression on mpc5121e
Hi Greg, On Tue, 4 Dec 2012 14:23:21 +0100 Anatolij Gustschin ag...@denx.de wrote: fsl-ehci probing fails on mpc5121e: ... ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 fsl-ehci fsl-ehci.0: Could not get controller version fsl-ehci fsl-ehci.0: can't setup fsl-ehci fsl-ehci.0: USB bus 1 deregistered fsl-ehci fsl-ehci.0: init fsl-ehci.0 fail, -22 fsl-ehci: probe of fsl-ehci.0 failed with error -22 Fix it by returning appropriate version info for mpc5121, too. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/usb/host/fsl-mph-dr-of.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Ping. Thanks, Anatolij -- 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] USB: ehci-fsl: fix regression on mpc5121e
Hi Greg, On Tue, 4 Dec 2012 10:22:06 -0500 (EST) Alan Stern st...@rowland.harvard.edu wrote: On Tue, 4 Dec 2012, Anatolij Gustschin wrote: mpc5121e doesn't have system interface registers, accessing this register address space cause the machine check exception and a kernel crash: ... Machine check in kernel mode. Caused by (from SRR1=49030): Transfer error ack signal Oops: Machine check, sig: 7 [#1] MPC5121 ADS Modules linked in: NIP: c025fd60 LR: c0265bb4 CTR: REGS: df82dac0 TRAP: 0200 Not tainted (3.7.0-rc7-00641-g81e6c91) MSR: 00049030 EE,ME,IR,DR CR: 42002024 XER: 2000 TASK = df824b70[1] 'swapper' THREAD: df82c000 GPR00: df82db70 df824b70 df3ed0f0 0003 GPR08: 0020 3200 c03550ec 2000 22002028 c0003f5c GPR16: c0423898 c045 GPR24: 0077 0002 e5086180 1c000c00 e5086000 df33ec00 0003 df34e000 NIP [c025fd60] ehci_fsl_setup_phy+0xd0/0x354 LR [c0265bb4] ehci_fsl_setup+0x220/0x284 ... Fix it by checking 'have_sysif_regs' flag before register access. Signed-off-by: Anatolij Gustschin ag...@denx.de Acked-by: Alan Stern st...@rowland.harvard.edu Ping. Thanks, Anatolij -- 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 autosuspend vs. URB submission
On Thu, 10 Jan 2013, Laurent Pinchart wrote: Hi Josh, On Tuesday 08 January 2013 11:03:22 Josh Boyer wrote: On Tue, Jan 08, 2013 at 10:51:20AM -0500, Alan Stern wrote: On Mon, 7 Jan 2013, Josh Boyer wrote: Hi, We've had a few reports in Fedora of users hitting the WARN_ONCE in drivers/usb/core/urb.c that prints a warning about a usb_submit_urb being called on an active URB. One of them[1] is from the ums_realtek driver and the other[2] is from the uvcvideo driver. However, I noticed that in both instances it seems the devices were coming back from what I think is autosuspend. I didn't immediately find any similar reports, and to my rather inexperienced eyes the drivers didn't seem to be doing anything clearly wrong. I'm wondering if anyone has some possible ideas for debugging and whether or not this might be a general issue? I don't see anything wrong either. Can you ask the users to collect a usbmon trace covering the period when the problem occurs? I'll certainly ask. I'm not particularly hopeful for great results though, as the problems seem to be rather intermittent. Thanks for taking a look. I've never heard of such problems with the uvcvideo driver, and I don't see Such problems could have existed silently. The new kernel calls WARN_ONCE but otherwise treats the error the same as the old kernels. anything wrong with the code at first sight. The driver only submits URBs when starting the video capture (at that point no URB should be in flight) or in the URB completion handler (by definition the URB has completed then). I've had a quick look at the trace posted at https://bugzilla.redhat.com/show_bug.cgi?id=879462 but usbmon only shows URBs that are successfully submitted. I'm not sure what useful information I could get from the trace. As Ming Lei pointed out, we would have to combine the dmesg information with the usbmon trace. The WARN_ONCE and usbmon both provide the URB's address, so we could tell if that URB really was still pending when the WARN_ONCE was triggered. We also might be able to tell (by looking at the URB's contents) what piece of code had submitted it the first time. 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/3] usb: add find_raw_port_number callback to struct hc_driver()
On Thu, 10 Jan 2013, Lan Tianyu wrote:
xhci driver divides the root hub into two logical hubs which work
respectively for usb 2.0 and usb 3.0 devices. They are independent
devices in the usb core. But in the ACPI table, it's one device node
and all usb2.0 and usb3.0 ports are under it. Binding usb port with
its acpi node needs the raw port number which is reflected in the xhci
extended capabilities table. This patch is to add find_raw_port_number
callback to struct hc_driver() and fill it with xhci_find_raw_port_number().
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/hcd.c |9 +
drivers/usb/host/xhci-pci.c |1 +
drivers/usb/host/xhci.c | 22 ++
drivers/usb/host/xhci.h |1 +
include/linux/usb/hcd.h |2 ++
5 files changed, 35 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 4225d5e..7d695ea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2364,6 +2364,15 @@ int usb_hcd_is_primary_hcd(struct usb_hcd *hcd)
}
EXPORT_SYMBOL_GPL(usb_hcd_is_primary_hcd);
+int usb_hcd_find_raw_port_number(struct usb_hcd *hcd, int port1)
+{
+ if (!hcd-driver-find_raw_port_number)
+ return port1;
+
+ return hcd-driver-find_raw_port_number(hcd, port1);
+}
+EXPORT_SYMBOL_GPL(usb_hcd_find_raw_port_number);
Does this really need to be EXPORTed? The routine doesn't have any
users outside of usbcore.
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 autosuspend vs. URB submission
On Thu, 10 Jan 2013, Oliver Neukum wrote:
On Thursday 10 January 2013 00:05:55 Laurent Pinchart wrote:
I've had a quick look at the trace posted at
https://bugzilla.redhat.com/show_bug.cgi?id=879462 but usbmon only shows
URBs
that are successfully submitted. I'm not sure what useful information I
could
get from the trace.
The test is at the very start of usb_submit_urb()
if (!urb || !urb-complete)
return -EINVAL;
if (urb-hcpriv) {
WARN_ONCE(1, URB %p submitted while active\n, urb);
return -EBUSY;
}
usbmon will never see such URBs
Not quite -- it will see them the first time they are submitted, when
the submission succeeds.
I suggest that for debugging you change the WARN_ONCE into a WARN and compare
the URB pointers of usbmon and dmesg.
Good idea.
In the long run it is probably a good idea to pass duplicated URBs to usbmon
by
a special code path.
I'd prefer to add extra information to the WARN_ONCE message. Even
though it would require the extra effort of correlating the dmesg
output with the usbmon output.
You know, it's possible that the URB really was not submitted before
but instead the urb-hcpriv field got overwritten. Of course, that
would also be a bug.
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 2/2] usb: host: ohci-tmio: fix compile warning
On Thu, 10 Jan 2013, Felipe Balbi wrote: Fix the following compile warning: In file included from drivers/usb/host/ohci-hcd.c:1170:0: drivers/usb/host/ohci-tmio.c: In function 'tmio_start_hc': drivers/usb/host/ohci-tmio.c:130:2: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'resource_size_t' [-Wformat] seen on ARM 32-bit builds. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/host/ohci-tmio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c index d370245..5e3a6de 100644 --- a/drivers/usb/host/ohci-tmio.c +++ b/drivers/usb/host/ohci-tmio.c @@ -128,7 +128,8 @@ static void tmio_start_hc(struct platform_device *dev) tmio_iowrite8(2, tmio-ccr + CCR_INTC); dev_info(dev-dev, revision %d @ 0x%08llx, irq %d\n, - tmio_ioread8(tmio-ccr + CCR_REVID), hcd-rsrc_start, hcd-irq); + tmio_ioread8(tmio-ccr + CCR_REVID), + (u64) hcd-rsrc_start, hcd-irq); } 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 1/3] usb: add find_raw_port_number callback to struct hc_driver()
于 2013/1/10 23:14, Alan Stern 写道:
On Thu, 10 Jan 2013, Lan Tianyu wrote:
xhci driver divides the root hub into two logical hubs which work
respectively for usb 2.0 and usb 3.0 devices. They are independent
devices in the usb core. But in the ACPI table, it's one device node
and all usb2.0 and usb3.0 ports are under it. Binding usb port with
its acpi node needs the raw port number which is reflected in the xhci
extended capabilities table. This patch is to add find_raw_port_number
callback to struct hc_driver() and fill it with xhci_find_raw_port_number().
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/hcd.c |9 +
drivers/usb/host/xhci-pci.c |1 +
drivers/usb/host/xhci.c | 22 ++
drivers/usb/host/xhci.h |1 +
include/linux/usb/hcd.h |2 ++
5 files changed, 35 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 4225d5e..7d695ea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2364,6 +2364,15 @@ int usb_hcd_is_primary_hcd(struct usb_hcd *hcd)
}
EXPORT_SYMBOL_GPL(usb_hcd_is_primary_hcd);
+int usb_hcd_find_raw_port_number(struct usb_hcd *hcd, int port1)
+{
+ if (!hcd-driver-find_raw_port_number)
+ return port1;
+
+ return hcd-driver-find_raw_port_number(hcd, port1);
+}
+EXPORT_SYMBOL_GPL(usb_hcd_find_raw_port_number);
Does this really need to be EXPORTed? The routine doesn't have any
users outside of usbcore.
Yeah. I will remove it.
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
--
Best regards
Tianyu Lan
--
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: select USB_ARCH_HAS_EHCI for MXS
Commit 09f6ffde introduced a dependency on USB_EHCI_HCD for the chipidea USB host driver, that in turns depends on USB_ARCH_HAS_EHCI. If this symbol is not set for MXS, the MXS boards are not able to use the chipidea driver anymore. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com --- drivers/usb/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 4c90b51..640ae6c 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -37,6 +37,7 @@ config USB_ARCH_HAS_EHCI default y if ARCH_W90X900 default y if ARCH_AT91 default y if ARCH_MXC + default y if ARCH_MXS default y if ARCH_OMAP3 default y if ARCH_CNS3XXX default y if ARCH_VT8500 -- 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: ehci-hcd compile error
On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi Alan, with v3.8-rc3, ehci-hcd fails to compile for ARM if I use 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 Looks like the recent ARM multi-arch patches didn't take into account EHCI-hcd. Do you know why this problem didn't occur in 3.6-rc2? I don't see any changes in -rc3 that would account for it (although I didn't look terribly thoroughly). Now it becomes easy to see why giving ehci its own platform_device/driver would've been a lot easier ;-) Not at all. We merely need to finish the conversion that I started. It should be pretty easy to convert ehci-mxc over to the new scheme. I don't have time to do it right now, but soon... 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 autosuspend vs. URB submission
On Thursday 10 January 2013 10:20:42 Alan Stern wrote: On Thu, 10 Jan 2013, Oliver Neukum wrote: In the long run it is probably a good idea to pass duplicated URBs to usbmon by a special code path. I'd prefer to add extra information to the WARN_ONCE message. Even though it would require the extra effort of correlating the dmesg output with the usbmon output. A stack_trace() I presume. But what is the use of needing two logs? You know, it's possible that the URB really was not submitted before but instead the urb-hcpriv field got overwritten. Of course, that would also be a bug. We could log a corrupted URB generically speaking. Regards Oliver -- 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: select USB_ARCH_HAS_EHCI for MXS
Hello. On 01/10/2013 06:35 PM, Maxime Ripard wrote: Commit 09f6ffde introduced a dependency on USB_EHCI_HCD for the chipidea Please also specify the summary of that commit in parens (or however you like). USB host driver, that in turns depends on USB_ARCH_HAS_EHCI. If this symbol is not set for MXS, the MXS boards are not able to use the chipidea driver anymore. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com WBR, Sergei -- 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] CDC_NCM adding support IFF_NOARP for buggy device
Hello.
On 01/10/2013 04:59 PM, Wei Shuai wrote:
Signed-off-by: Wei Shuai cpuw...@gmail.com
---
drivers/net/usb/cdc_ncm.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 71b6e92..9903f79 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
[...]
@@ -572,6 +573,10 @@ static int cdc_ncm_bind(struct usbnet *dev, struct
usb_interface *intf)
cdc_ncm_comm_intf_is_mbim(intf-cur_altsetting))
return -ENODEV;
#endif
+ /* this buggy device cannot do ARP */
+ if( (le16_to_cpu(udev-descriptor.idVendor) == 0x) ) {
Please run the patch thru scripts/checkpatch.pl and resubmit.
WBR, Sergei
--
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: ehci-hcd compile error
Hi, On Thu, Jan 10, 2013 at 10:36:27AM -0500, Alan Stern wrote: On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi Alan, with v3.8-rc3, ehci-hcd fails to compile for ARM if I use 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 Looks like the recent ARM multi-arch patches didn't take into account EHCI-hcd. Do you know why this problem didn't occur in 3.6-rc2? I don't see any changes in -rc3 that would account for it (although I didn't look terribly thoroughly). It's probably there, I just didn't look at it either :-) Now it becomes easy to see why giving ehci its own platform_device/driver would've been a lot easier ;-) Not at all. We merely need to finish the conversion that I started. It should be pretty easy to convert ehci-mxc over to the new scheme. I don't have time to do it right now, but soon... ehci-mxc isn't the only one redefining PLATFORM_DRIVER. All of below are potential offenders: drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_fsl_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_mxc_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sh_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_hcd_omap_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_orion_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_w90x900_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_atmel_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_octeon_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER vt8500_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER spear_ehci_hcd_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_msm_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_tilegx_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_msp_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER tegra_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER s5p_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_grlib_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_mv_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sead3_driver By adding a platform_device to struct ehci-hcd.c we wouldn't need all of those defines. Also note that not all of them will be able to simply use ehci-platform.c. OMAP, for instance, needs to reimplement parts of ehci_hub_control() due to silicon erratas (we need to reparent a clock at a specific spot during bus suspend), this means we will always have, at a minimum, ehci-omap.c. Tegra has other silicon erratas on and reimplements other ehci functions and so forth. But fair enough, I just want to see this fixed but, like yourself, no time to look at that :-s -- balbi signature.asc Description: Digital signature
[PATCH 12/14] ARM: OMAP2+: omap4panda: Adapt HUB power to regulator framework
We model the HUB_POWER GPIO as a fixed regulator device. This regulator
is then used as vcc supply for the USB PHY device and is managed
by the PHY driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 38 +++
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 350c4db..a4831cc 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -132,12 +132,45 @@ static struct platform_device btwilink_device = {
.id = -1,
};
+/* Regulator for USB HUB supply */
+static struct regulator_consumer_supply hub_power_supplies[] = {
+/* Link PHY device to USB HUB supply so it gets enabled in the PHY driver */
+ REGULATOR_SUPPLY(vcc, nop_usb_xceiv.0),
+};
+
+static struct regulator_init_data hub_power_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hub_power_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hub_power_supplies),
+};
+
+static struct fixed_voltage_config hub_power_config = {
+ .supply_name= vhub,
+ .microvolts = 330,
+ .gpio = GPIO_HUB_POWER,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = hub_power_data,
+};
+
+static struct platform_device hub_power_device = {
+ .name = reg-fixed-voltage,
+ .id = 2,
+ .dev = {
+ .platform_data = hub_power_config,
+ },
+};
+
static struct platform_device *panda_devices[] __initdata = {
leds_gpio,
wl1271_device,
panda_abe_audio,
panda_hdmi_audio_codec,
btwilink_device,
+ hub_power_device,
};
static struct nop_usb_xceiv_platform_data phy_pdata0 = {
@@ -164,7 +197,6 @@ static struct usbhs_omap_platform_data usbhs_bdata
__initdata = {
};
static struct gpio panda_ehci_gpios[] __initdata = {
- { GPIO_HUB_POWER, GPIOF_OUT_INIT_LOW, hub_power },
{ GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, hub_nreset },
};
@@ -180,7 +212,6 @@ static void __init omap4_ehci_init(void)
return;
}
- gpio_export(GPIO_HUB_POWER, 0);
gpio_export(GPIO_HUB_NRESET, 0);
gpio_set_value(GPIO_HUB_NRESET, 1);
@@ -190,9 +221,6 @@ static void __init omap4_ehci_init(void)
pr_err(Failed to add main_clk alias to auxclk3_ck\n);
usbhs_init(usbhs_bdata);
-
- /* enable power to hub */
- gpio_set_value(GPIO_HUB_POWER, 1);
}
static struct omap_musb_board_data musb_board_data = {
--
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 14/14] ARM: OMAP2+: omap4panda: Remove irrelevant USB host platform data
These platform data bits are no longer used so remove them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index fd2f907..cde7316 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -220,12 +220,6 @@ static struct usbhs_phy_config phy_config0 = {
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,
- .phy_reset = false,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL,
.phy_config[0] = phy_config0,
};
--
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 13/14] ARM: OMAP2+: omap4panda: Adapt HUB reset to regulator framework
We model the HUB_RESET GPIO as a fixed regulator device. This regulator
is then used as reset supply for the USB PHY device and is managed
by the PHY driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 48 ++--
1 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a4831cc..fd2f907 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -132,6 +132,38 @@ static struct platform_device btwilink_device = {
.id = -1,
};
+/* Regulator for USB HUB/PHY reset */
+static struct regulator_consumer_supply hub_reset_supplies[] = {
+/* Link PHY device to reset supply so it gets used in the PHY driver */
+ REGULATOR_SUPPLY(reset, nop_usb_xceiv.0),
+};
+
+static struct regulator_init_data hub_reset_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hub_reset_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hub_reset_supplies),
+};
+
+static struct fixed_voltage_config hub_reset_config = {
+ .supply_name= hub_reset,
+ .microvolts = 330,
+ .gpio = GPIO_HUB_NRESET,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0, /* keep in RESET */
+ .init_data = hub_reset_data,
+};
+
+static struct platform_device hub_reset_device = {
+ .name = reg-fixed-voltage,
+ .id = 3,
+ .dev = {
+ .platform_data = hub_reset_config,
+ },
+};
+
/* Regulator for USB HUB supply */
static struct regulator_consumer_supply hub_power_supplies[] = {
/* Link PHY device to USB HUB supply so it gets enabled in the PHY driver */
@@ -171,6 +203,7 @@ static struct platform_device *panda_devices[] __initdata =
{
panda_hdmi_audio_codec,
btwilink_device,
hub_power_device,
+ hub_reset_device,
};
static struct nop_usb_xceiv_platform_data phy_pdata0 = {
@@ -196,25 +229,10 @@ static struct usbhs_omap_platform_data usbhs_bdata
__initdata = {
.phy_config[0] = phy_config0,
};
-static struct gpio panda_ehci_gpios[] __initdata = {
- { GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, hub_nreset },
-};
-
static void __init omap4_ehci_init(void)
{
int ret;
- /* disable the power to the usb hub prior to init and reset phy+hub */
- ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
- if (ret) {
- pr_err(Unable to initialize EHCI power/reset\n);
- return;
- }
-
- gpio_export(GPIO_HUB_NRESET, 0);
- gpio_set_value(GPIO_HUB_NRESET, 1);
-
/* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
ret = clk_add_alias(main_clk, nop_usb_xceiv.0, auxclk3_ck, NULL);
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 07/14] usb: ehci-omap: Instantiate PHY devices if required
If the OMAP's Host controller is in PHY mode then we instantiate
a platform device for the PHY (one for each port in PHY mode) and
hold a reference to it so that we can use the usb_phy API, e.g.
while suspend/resume.
The platform data for the PHY must be supplied in the newly added
.phy_config parameter in struct usbhs_omap_platform_data.
The end goal is to move the PHY's reset and power handling code
out of the ehci-omap driver and into the phy driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c | 83 ++-
include/linux/platform_data/usb-omap.h |8 +++
2 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index b96a4bf..e6a2d76 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -61,6 +61,11 @@
static const struct hc_driver ehci_omap_hc_driver;
+struct omap_ehci_hcd {
+ struct usb_hcd *hcd;
+ struct usb_phy **phy; /* one PHY for each port */
+ int nports;
+};
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
{
@@ -179,6 +184,8 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
struct usbhs_omap_platform_data *pdata = dev-platform_data;
struct resource *res;
struct usb_hcd *hcd;
+ struct omap_ehci_hcd*omap_hcd;
+ struct usb_phy *phy;
void __iomem*regs;
int ret = -ENODEV;
int irq;
@@ -193,6 +200,25 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ if (!pdata) {
+ dev_err(dev, Missing platform data\n);
+ return -ENODEV;
+ }
+
+ omap_hcd = devm_kzalloc(pdev-dev, sizeof(*omap_hcd), GFP_KERNEL);
+ if (!omap_hcd) {
+ dev_err(dev, Memory allocation failed\n);
+ return -ENOMEM;
+ }
+
+ omap_hcd-nports = pdata-nports;
+ i = sizeof(struct usb_phy *) * omap_hcd-nports;
+ omap_hcd-phy = devm_kzalloc(pdev-dev, i, GFP_KERNEL);
+ if (!omap_hcd-phy) {
+ dev_err(dev, Memory allocation failed\n);
+ return -ENOMEM;
+ }
+
irq = platform_get_irq_byname(pdev, ehci-irq);
if (irq 0) {
dev_err(dev, EHCI irq failed\n);
@@ -223,9 +249,15 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
hcd-regs = regs;
+ omap_hcd-hcd = hcd;
+
+ platform_set_drvdata(pdev, omap_hcd);
/* get ehci regulator and enable */
- for (i = 0 ; i OMAP3_HS_USB_PORTS ; i++) {
+ for (i = 0 ; i omap_hcd-nports ; i++) {
+ struct platform_device *phy_pdev;
+ struct usbhs_phy_config *phy_config;
+
if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY) {
pdata-regulator[i] = NULL;
continue;
@@ -239,6 +271,33 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
} else {
regulator_enable(pdata-regulator[i]);
}
+
+ /* instantiate PHY */
+ if (!pdata-phy_config[i]) {
+ dev_dbg(dev, missing phy_config for port %d\n, i);
+ continue;
+ }
+
+ phy_config = pdata-phy_config[i];
+ phy_pdev = platform_device_register_data(pdev-dev,
+ phy_config-name, i, phy_config-pdata,
+ phy_config-pdata_size);
+ if (IS_ERR(phy_pdev)) {
+ dev_dbg(dev, error creating PHY device for port %d\n,
+ i);
+ }
+
+ phy = usb_get_phy_from_dev(phy_pdev-dev);
+ if (IS_ERR(phy)) {
+ dev_dbg(dev, could not get USB PHY for port %d\n, i);
+ platform_device_unregister(phy_pdev);
+ continue;
+ }
+
+ usb_phy_init(phy);
+ omap_hcd-phy[i] = phy;
+ /* bring PHY out of suspend */
+ usb_phy_set_suspend(omap_hcd-phy[i], 0);
}
pm_runtime_enable(dev);
@@ -269,6 +328,12 @@ err_pm_runtime:
disable_put_regulator(pdata);
pm_runtime_put_sync(dev);
usb_put_hcd(hcd);
+ for (i = 0 ; i omap_hcd-nports ; i++) {
+ phy = omap_hcd-phy[i];
+ if (!phy)
+ continue;
+ platform_device_unregister(to_platform_device(phy-dev));
+ }
err_io:
iounmap(regs);
@@ -286,14 +351,26 @@ err_io:
[PATCH 06/14] mfd: omap-usb-host: update nports in platform_data
EHCI driver would need to know the number of ports available on the platform. We set the nports parameter of platform_data based on IP version if it was not already provided. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mfd/omap-usb-host.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index 7180b00..5c1c3ae 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -564,6 +564,7 @@ static int usbhs_omap_probe(struct platform_device *pdev) omap-usbhs_rev, omap-nports); break; } + pdata-nports = omap-nports; } i = sizeof(struct clk *) * omap-nports; -- 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 01/14] 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.
Signed-off-by: Roger Quadros rog...@ti.com
---
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 | 30 +++---
arch/arm/mach-omap2/usb.h | 21 +
drivers/mfd/omap-usb-host.c| 46
drivers/mfd/omap-usb-tll.c |8 ++--
drivers/usb/host/ehci-omap.c |6 ++--
include/linux/platform_data/usb-omap.h | 26
22 files changed, 56 insertions(+), 115 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 cm_t3517_init_rtc(void) {}
#define HSUSB2_RESET_GPIO (147)
#define USB_HUB_RESET_GPIO (152)
-static struct usbhs_omap_board_data
[PATCH 11/14] ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data
Provide platform data for the USB host's PHY.
Also get rid of managing PHY clock. This will now be done by the phy driver.
For that to work we create a clock alias that links the PHY clock name to the
PHY device name.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 31 ---
1 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index ee76830..350c4db 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -30,6 +30,7 @@
#include linux/regulator/fixed.h
#include linux/ti_wilink_st.h
#include linux/usb/musb.h
+#include linux/usb/nop-usb-xceiv.h
#include linux/wl12xx.h
#include linux/platform_data/omap-abe-twl6040.h
@@ -139,6 +140,18 @@ static struct platform_device *panda_devices[] __initdata
= {
btwilink_device,
};
+static struct nop_usb_xceiv_platform_data phy_pdata0 = {
+ .type = USB_PHY_TYPE_UNDEFINED,
+ /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+ .clk_rate = 1920,
+};
+
+static struct usbhs_phy_config phy_config0 = {
+ .name = nop_usb_xceiv,
+ .pdata = phy_pdata0,
+ .pdata_size = sizeof(phy_pdata0),
+};
+
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,
@@ -146,7 +159,8 @@ static struct usbhs_omap_platform_data usbhs_bdata
__initdata = {
.phy_reset = false,
.reset_gpio_port[0] = -EINVAL,
.reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
+ .reset_gpio_port[2] = -EINVAL,
+ .phy_config[0] = phy_config0,
};
static struct gpio panda_ehci_gpios[] __initdata = {
@@ -157,16 +171,6 @@ static struct gpio panda_ehci_gpios[] __initdata = {
static void __init omap4_ehci_init(void)
{
int ret;
- struct clk *phy_ref_clk;
-
- /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
- phy_ref_clk = clk_get(NULL, auxclk3_ck);
- if (IS_ERR(phy_ref_clk)) {
- pr_err(Cannot request auxclk3\n);
- return;
- }
- clk_set_rate(phy_ref_clk, 1920);
- clk_prepare_enable(phy_ref_clk);
/* disable the power to the usb hub prior to init and reset phy+hub */
ret = gpio_request_array(panda_ehci_gpios,
@@ -180,6 +184,11 @@ static void __init omap4_ehci_init(void)
gpio_export(GPIO_HUB_NRESET, 0);
gpio_set_value(GPIO_HUB_NRESET, 1);
+ /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+ ret = clk_add_alias(main_clk, nop_usb_xceiv.0, auxclk3_ck, NULL);
+ if (ret)
+ pr_err(Failed to add main_clk alias to auxclk3_ck\n);
+
usbhs_init(usbhs_bdata);
/* enable power to hub */
--
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 10/14] usb: ehci-omap: Remove PHY regulator handling code
PHY regulator handling must be done in the PHY driver
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c | 31 +--
1 files changed, 1 insertions(+), 30 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 46b28d6..02475c7 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -39,7 +39,6 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/usb/ulpi.h
-#include linux/regulator/consumer.h
#include linux/pm_runtime.h
#include linux/gpio.h
#include linux/clk.h
@@ -105,19 +104,6 @@ static int omap_ehci_init(struct usb_hcd *hcd)
return rc;
}
-static void disable_put_regulator(
- struct usbhs_omap_platform_data *pdata)
-{
- int i;
-
- for (i = 0 ; i OMAP3_HS_USB_PORTS ; i++) {
- if (pdata-regulator[i]) {
- regulator_disable(pdata-regulator[i]);
- regulator_put(pdata-regulator[i]);
- }
- }
-}
-
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -140,7 +126,6 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
int ret = -ENODEV;
int irq;
int i;
- charsupply[7];
if (usb_disabled())
return -ENODEV;
@@ -203,24 +188,12 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, omap_hcd);
- /* get ehci regulator and enable */
for (i = 0 ; i omap_hcd-nports ; i++) {
struct platform_device *phy_pdev;
struct usbhs_phy_config *phy_config;
- if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY) {
- pdata-regulator[i] = NULL;
+ if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
continue;
- }
- snprintf(supply, sizeof(supply), hsusb%d, i);
- pdata-regulator[i] = regulator_get(dev, supply);
- if (IS_ERR(pdata-regulator[i])) {
- pdata-regulator[i] = NULL;
- dev_dbg(dev,
- failed to get ehci port%d regulator\n, i);
- } else {
- regulator_enable(pdata-regulator[i]);
- }
/* instantiate PHY */
if (!pdata-phy_config[i]) {
@@ -275,7 +248,6 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
return 0;
err_pm_runtime:
- disable_put_regulator(pdata);
pm_runtime_put_sync(dev);
usb_put_hcd(hcd);
for (i = 0 ; i omap_hcd-nports ; i++) {
@@ -307,7 +279,6 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
int i;
usb_remove_hcd(hcd);
- disable_put_regulator(dev-platform_data);
iounmap(hcd-regs);
usb_put_hcd(hcd);
--
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 03/14] usb: xceiv: nop: Manage PHY clock
If the PHY has a clock associated to it then manage the clock.
We just enable the clock in .init() and disable it in .shutdown().
Add clk_rate parameter in platform data and configure the
clock rate during probe if supplied.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/otg/nop-usb-xceiv.c | 49 +
include/linux/usb/nop-usb-xceiv.h |1 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index a3ce24b..163f972 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -32,10 +32,12 @@
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
#include linux/slab.h
+#include linux/clk.h
struct nop_usb_xceiv {
struct usb_phy phy;
struct device *dev;
+ struct clk *clk;
};
static struct platform_device *pd;
@@ -64,6 +66,24 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)
return 0;
}
+static int nop_init(struct usb_phy *phy)
+{
+ struct nop_usb_xceiv *nop = dev_get_drvdata(phy-dev);
+
+ if (nop-clk)
+ clk_enable(nop-clk);
+
+ return 0;
+}
+
+static void nop_shutdown(struct usb_phy *phy)
+{
+ struct nop_usb_xceiv *nop = dev_get_drvdata(phy-dev);
+
+ if (nop-clk)
+ clk_disable(nop-clk);
+}
+
static int nop_set_peripheral(struct usb_otg *otg, struct usb_gadget *gadget)
{
if (!otg)
@@ -113,10 +133,36 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
if (pdata)
type = pdata-type;
+ nop-clk = devm_clk_get(pdev-dev, main_clk);
+ if (IS_ERR(nop-clk)) {
+ dev_dbg(pdev-dev, Can't get phy clock\n);
+ nop-clk = NULL;
+ }
+
+ if (nop-clk pdata pdata-clk_rate) {
+ err = clk_set_rate(nop-clk, pdata-clk_rate);
+ if (err) {
+ dev_err(pdev-dev,
+ Error setting clock rate\n);
+ goto exit;
+ }
+ }
+
+ if (nop-clk) {
+ err = clk_prepare(nop-clk);
+ if (err) {
+ dev_err(pdev-dev,
+ Error preparing clock\n);
+ goto exit;
+ }
+ }
+
nop-dev= pdev-dev;
nop-phy.dev= nop-dev;
nop-phy.label = nop-xceiv;
nop-phy.set_suspend= nop_set_suspend;
+ nop-phy.init = nop_init;
+ nop-phy.shutdown = nop_shutdown;
nop-phy.state = OTG_STATE_UNDEFINED;
nop-phy.otg-phy = nop-phy;
@@ -145,6 +191,9 @@ static int nop_usb_xceiv_remove(struct platform_device
*pdev)
{
struct nop_usb_xceiv *nop = platform_get_drvdata(pdev);
+ if (nop-clk)
+ clk_unprepare(nop-clk);
+
usb_remove_phy(nop-phy);
platform_set_drvdata(pdev, NULL);
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index 28884c7..3265b61 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -5,6 +5,7 @@
struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
+ unsigned long clk_rate;
};
#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE)
defined(MODULE))
--
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 09/14] usb: ehci-omap: Remove PHY reset handling code
Reset GPIO handling for the PHY must be done in the PHY
driver. We use the PHY helpers instead to reset the PHY.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c | 70 ++
1 files changed, 10 insertions(+), 60 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index e6a2d76..46b28d6 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -77,79 +77,29 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
-
-static void omap_ehci_soft_phy_reset(struct usb_hcd *hcd, u8 port)
-{
- unsigned long timeout = jiffies + msecs_to_jiffies(1000);
- unsigned reg = 0;
-
- reg = ULPI_FUNC_CTRL_RESET
- /* FUNCTION_CTRL_SET register */
- | (ULPI_SET(ULPI_FUNC_CTRL) EHCI_INSNREG05_ULPI_REGADD_SHIFT)
- /* Write */
- | (2 EHCI_INSNREG05_ULPI_OPSEL_SHIFT)
- /* PORTn */
- | ((port + 1) EHCI_INSNREG05_ULPI_PORTSEL_SHIFT)
- /* start ULPI access*/
- | (1 EHCI_INSNREG05_ULPI_CONTROL_SHIFT);
-
- ehci_write(hcd-regs, EHCI_INSNREG05_ULPI, reg);
-
- /* Wait for ULPI access completion */
- while ((ehci_read(hcd-regs, EHCI_INSNREG05_ULPI)
-(1 EHCI_INSNREG05_ULPI_CONTROL_SHIFT))) {
- cpu_relax();
-
- if (time_after(jiffies, timeout)) {
- dev_dbg(hcd-self.controller,
- phy reset operation timed out\n);
- break;
- }
- }
-}
-
static int omap_ehci_init(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- int rc;
- struct usbhs_omap_platform_data *pdata;
+ struct omap_ehci_hcd*omap_hcd;
+ int rc, i;
- pdata = hcd-self.controller-platform_data;
+ omap_hcd = dev_get_drvdata(hcd-self.controller);
/* Hold PHYs in reset while initializing EHCI controller */
- if (pdata-phy_reset) {
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- gpio_set_value_cansleep(pdata-reset_gpio_port[0], 0);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- gpio_set_value_cansleep(pdata-reset_gpio_port[1], 0);
-
- /* Hold the PHY in RESET for enough time till DIR is high */
- udelay(10);
+ for (i = 0; i omap_hcd-nports; i++) {
+ if (omap_hcd-phy[i])
+ usb_phy_shutdown(omap_hcd-phy[i]);
}
- /* Soft reset the PHY using PHY reset command over ULPI */
- if (pdata-port_mode[0] == OMAP_EHCI_PORT_MODE_PHY)
- omap_ehci_soft_phy_reset(hcd, 0);
- if (pdata-port_mode[1] == OMAP_EHCI_PORT_MODE_PHY)
- omap_ehci_soft_phy_reset(hcd, 1);
-
/* we know this is the memory we want, no need to ioremap again */
ehci-caps = hcd-regs;
rc = ehci_setup(hcd);
- if (pdata-phy_reset) {
- /* Hold the PHY in RESET for enough time till
-* PHY is settled and ready
-*/
- udelay(10);
-
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1);
+ /* Bring PHYs out of reset */
+ for (i = 0; i omap_hcd-nports; i++) {
+ if (omap_hcd-phy[i])
+ usb_phy_init(omap_hcd-phy[i]);
}
return rc;
--
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 08/14] mfd: omap-usb-host: Remove PHY reset handling code
PHY reset GPIO handling will be done in the PHY driver
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 47 ---
1 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 5c1c3ae..7547448 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -430,24 +430,10 @@ static unsigned omap_usbhs_rev2_hostconfig(struct
usbhs_hcd_omap *omap,
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;
unsignedreg;
dev_dbg(dev, starting TI HSUSB Controller\n);
- if (pdata-phy_reset) {
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- gpio_request_one(pdata-reset_gpio_port[0],
-GPIOF_OUT_INIT_LOW, USB1 PHY reset);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- gpio_request_one(pdata-reset_gpio_port[1],
-GPIOF_OUT_INIT_LOW, USB2 PHY reset);
-
- /* Hold the PHY in RESET for enough time till DIR is high */
- udelay(10);
- }
-
pm_runtime_get_sync(dev);
reg = usbhs_read(omap-uhh_base, OMAP_UHH_HOSTCONFIG);
@@ -467,37 +453,8 @@ static void omap_usbhs_init(struct device *dev)
dev_dbg(dev, UHH setup done, uhh_hostconfig=%x\n, reg);
pm_runtime_put_sync(dev);
- if (pdata-phy_reset) {
- /* Hold the PHY in RESET for enough time till
-* PHY is settled and ready
-*/
- udelay(10);
-
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- gpio_set_value_cansleep
- (pdata-reset_gpio_port[0], 1);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- gpio_set_value_cansleep
- (pdata-reset_gpio_port[1], 1);
- }
-}
-
-static void omap_usbhs_deinit(struct device *dev)
-{
- struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = omap-pdata;
-
- 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]);
- }
}
-
/**
* usbhs_omap_probe - initialize TI-based HCDs
*
@@ -705,8 +662,6 @@ static int usbhs_omap_probe(struct platform_device *pdev)
return 0;
err_alloc:
- omap_usbhs_deinit(pdev-dev);
-
for (i = 0; i omap-nports; i++) {
clk_put(omap-utmi_clk[i]);
clk_put(omap-hsic60m_clk[i]);
@@ -747,8 +702,6 @@ static int usbhs_omap_remove(struct platform_device *pdev)
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
int i;
- omap_usbhs_deinit(pdev-dev);
-
for (i = 0; i omap-nports; i++) {
clk_put(omap-utmi_clk[i]);
clk_put(omap-hsic60m_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 05/14] usb: phy: nop: Handle RESET for the PHY
We expect the RESET line to be modeled as a regulator with supply
name reset. The regulator should be modeled such that enabling
the regulator brings the PHY device out of RESET and disabling the
regulator holds the device in RESET.
They PHY will be held in RESET in .shutdown() and brought out of
RESET in .init().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/otg/nop-usb-xceiv.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 1c6db10..8fd49a8 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -40,6 +40,7 @@ struct nop_usb_xceiv {
struct device *dev;
struct clk *clk;
struct regulator*vcc;
+ struct regulator*reset;
};
static struct platform_device *pd;
@@ -80,6 +81,12 @@ static int nop_init(struct usb_phy *phy)
if (nop-clk)
clk_enable(nop-clk);
+ if (nop-reset) {
+ /* De-assert RESET */
+ if (regulator_enable(nop-reset))
+ dev_err(phy-dev, Failed to de-assert reset\n);
+ }
+
return 0;
}
@@ -87,6 +94,12 @@ static void nop_shutdown(struct usb_phy *phy)
{
struct nop_usb_xceiv *nop = dev_get_drvdata(phy-dev);
+ if (nop-reset) {
+ /* Assert RESET */
+ if (regulator_disable(nop-reset))
+ dev_err(phy-dev, Failed to assert reset\n);
+ }
+
if (nop-clk)
clk_disable(nop-clk);
@@ -175,6 +188,12 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
nop-vcc = NULL;
}
+ nop-reset = devm_regulator_get(pdev-dev, reset);
+ if (IS_ERR(nop-reset)) {
+ dev_dbg(pdev-dev, Error getting reset regulator\n);
+ nop-reset = NULL;
+ }
+
nop-dev= pdev-dev;
nop-phy.dev= nop-dev;
nop-phy.label = nop-xceiv;
--
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 00/14] USB: omap-ehci: Move PHY management to PHY driver
The OMAP's High Speed Host controller can interface to ULPI/UTMI PHY's transparently i.e. whithout requiring the device drivers to access the PHY [1]. However, the OS must ensure that the PHY has the necessary resources (power/clock/reset) enabled before it is used. Till now, the omap-ehci driver was managing the power and reset of the PHY whereas, clock enabling was left to the bootloader or board files. In this patchset we make the NOP PHY driver (nop-usb-xceiv.c) handle all the PHY resources that are available so that it can be used by platforms like OMAP. The omap-ehci driver instantiates a PHY platform device for each port that is in PHY mode. It then uses the USB PHY APIs to manage the PHY. All this results in a much cleaner code and makes USB PHY resource management work properly on OMAP. NOTE: Only omap4panda board is adapted for the changes. So USB Host will break for other boards. Once we have done a priliminary review, I can adapt other boards as well. This patchset depends on the series https://lkml.org/lkml/2013/1/2/144 git://github.com/rogerq/linux.git arm-for-next-usbhost9-part -- cheeer, -roger [1] - In practice we would need to access the PHY to work around Silicon Erratas in the OMAP's USB Host IP. Roger Quadros (14): mfd: omap-usb-host: Consolidate OMAP USB-HS platform data usb: phy: Add new API usb_get_phy_from_dev() usb: xceiv: nop: Manage PHY clock usb: phy: nop: Handle power supply regulator for the PHY usb: phy: nop: Handle RESET for the PHY mfd: omap-usb-host: update nports in platform_data usb: ehci-omap: Instantiate PHY devices if required mfd: omap-usb-host: Remove PHY reset handling code usb: ehci-omap: Remove PHY reset handling code usb: ehci-omap: Remove PHY regulator handling code ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data ARM: OMAP2+: omap4panda: Adapt HUB power to regulator framework ARM: OMAP2+: omap4panda: Adapt HUB reset to regulator framework ARM: OMAP2+: omap4panda: Remove irrelevant USB host platform data 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 | 117 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-zoom.c |2 +- arch/arm/mach-omap2/usb-host.c | 30 + arch/arm/mach-omap2/usb.h | 21 +--- drivers/mfd/omap-usb-host.c| 64 +- drivers/mfd/omap-usb-tll.c |8 +- drivers/usb/host/ehci-omap.c | 182 ++-- drivers/usb/otg/nop-usb-xceiv.c| 86 + drivers/usb/otg/otg.c | 36 ++ include/linux/platform_data/usb-omap.h | 28 ++--- include/linux/usb/nop-usb-xceiv.h |1 + include/linux/usb/phy.h|6 + 26 files changed, 345 insertions(+), 266 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 02/14] usb: phy: Add new API usb_get_phy_from_dev()
This API allows PHY users to get the usb_phy data structure
from a device handle.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/otg/otg.c | 36
include/linux/usb/phy.h |6 ++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..ba3a568 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -35,6 +35,21 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__usb_find_phy_dev(struct list_head *list,
+ struct device *dev)
+{
+ struct usb_phy *phy;
+
+ list_for_each_entry(phy, list, head) {
+ if (phy-dev != dev)
+ continue;
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -77,6 +92,27 @@ struct usb_phy *devm_usb_get_phy(struct device *dev, enum
usb_phy_type type)
}
EXPORT_SYMBOL(devm_usb_get_phy);
+struct usb_phy *usb_get_phy_from_dev(struct device *dev)
+{
+ struct usb_phy *phy = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __usb_find_phy_dev(phy_list, dev);
+ if (IS_ERR(phy)) {
+ dev_err(dev, %s: unable to find PHY\n, __func__);
+ goto done;
+ }
+
+ get_device(phy-dev);
+
+done:
+ spin_unlock_irqrestore(phy_lock, flags);
+ return phy;
+}
+EXPORT_SYMBOL(usb_get_phy_from_dev);
+
/**
* usb_get_phy - find the USB PHY
* @type - the type of the phy the controller requires
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index a29ae1e..cd798c4 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -147,6 +147,7 @@ usb_phy_shutdown(struct usb_phy *x)
/* for usb host and peripheral controller drivers */
#ifdef CONFIG_USB_OTG_UTILS
extern struct usb_phy *usb_get_phy(enum usb_phy_type type);
+extern struct usb_phy *usb_get_phy_from_dev(struct device *dev);
extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
extern void usb_put_phy(struct usb_phy *);
@@ -157,6 +158,11 @@ static inline struct usb_phy *usb_get_phy(enum
usb_phy_type type)
return NULL;
}
+static inline struct usb_phy *usb_get_phy_from_dev(struct device *dev)
+{
+ return NULL;
+}
+
static inline struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type)
{
--
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
Re: ehci-hcd compile error
On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi, On Thu, Jan 10, 2013 at 10:36:27AM -0500, Alan Stern wrote: On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi Alan, with v3.8-rc3, ehci-hcd fails to compile for ARM if I use 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 Looks like the recent ARM multi-arch patches didn't take into account EHCI-hcd. Do you know why this problem didn't occur in 3.6-rc2? I don't see any changes in -rc3 that would account for it (although I didn't look terribly thoroughly). It's probably there, I just didn't look at it either :-) It seems clear that CONFIG_EHCI_HCD_PLATFORM needs to be mutually exclusive with all the old-style drivers, in order to prevent this sort of conflict. I just don't see why it never came up before... Now it becomes easy to see why giving ehci its own platform_device/driver would've been a lot easier ;-) Not at all. We merely need to finish the conversion that I started. It should be pretty easy to convert ehci-mxc over to the new scheme. I don't have time to do it right now, but soon... ehci-mxc isn't the only one redefining PLATFORM_DRIVER. All of below are potential offenders: drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_fsl_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_mxc_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sh_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_hcd_omap_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_orion_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_w90x900_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_atmel_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_octeon_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER vt8500_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER spear_ehci_hcd_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_msm_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_tilegx_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_msp_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER tegra_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER s5p_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_grlib_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_mv_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sead3_driver Yes; those all are old-style drivers. Most of them can be converted to the new scheme with relatively little effort; a few will require more work. In fact, the only drivers that _have_ been converted so far are ehci-pci, chipidea, and ehci-platform. By adding a platform_device to struct ehci-hcd.c we wouldn't need all of those defines. And indeed, each time a driver is converted to the new scheme, its #define gets removed. Also note that not all of them will be able to simply use ehci-platform.c. OMAP, for instance, needs to reimplement parts of ehci_hub_control() due to silicon erratas (we need to reparent a clock at a specific spot during bus suspend), this means we will always have, at a minimum, ehci-omap.c. Tegra has other silicon erratas on and reimplements other ehci functions and so forth. That's right. But a driver can follow the new scheme without using ehci-platform.c. For example, neither ehci-pci.c nor chipidea/host.c does. But fair enough, I just want to see this fixed but, like yourself, no time to look at that :-s I can fix up ehci-mxc easily enough. Don't all those other drivers cause similar build problems, though? It wouldn't hurt to add some restrictions to the Kconfig entry for CONFIG_USB_EHCI_HCD_PLATFORM too. 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 04/14] usb: phy: nop: Handle power supply regulator for the PHY
Hello.
On 01/10/2013 07:51 PM, Roger Quadros wrote:
We use vcc as the supply name for the PHY's power supply.
The power supply will be enabled during .init() and disabled
during .shutdown()
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/otg/nop-usb-xceiv.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 163f972..1c6db10 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
[...]
@@ -70,6 +72,11 @@ static int nop_init(struct usb_phy *phy)
{
struct nop_usb_xceiv *nop = dev_get_drvdata(phy-dev);
+ if (nop-vcc) {
+ if (regulator_enable(nop-vcc))
+ dev_err(phy-dev, Failed to enable power\n);
+ }
Could be collapsed into single *if*.
+
if (nop-clk)
clk_enable(nop-clk);
@@ -82,6 +89,11 @@ static void nop_shutdown(struct usb_phy *phy)
if (nop-clk)
clk_disable(nop-clk);
+
+ if (nop-vcc) {
+ if (regulator_disable(nop-vcc))
+ dev_err(phy-dev, Failed to disable power\n);
+ }
Same here.
WBR, Sergei
--
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: ehci-hcd compile error
Hi On Thu, Jan 10, 2013 at 12:01:09PM -0500, Alan Stern wrote: On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi, On Thu, Jan 10, 2013 at 10:36:27AM -0500, Alan Stern wrote: On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi Alan, with v3.8-rc3, ehci-hcd fails to compile for ARM if I use 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 Looks like the recent ARM multi-arch patches didn't take into account EHCI-hcd. Do you know why this problem didn't occur in 3.6-rc2? I don't see any changes in -rc3 that would account for it (although I didn't look terribly thoroughly). It's probably there, I just didn't look at it either :-) It seems clear that CONFIG_EHCI_HCD_PLATFORM needs to be mutually exclusive with all the old-style drivers, in order to prevent this sort of conflict. I just don't see why it never came up before... you can't do that as you will break ARM single zImage builds. Now it becomes easy to see why giving ehci its own platform_device/driver would've been a lot easier ;-) Not at all. We merely need to finish the conversion that I started. It should be pretty easy to convert ehci-mxc over to the new scheme. I don't have time to do it right now, but soon... ehci-mxc isn't the only one redefining PLATFORM_DRIVER. All of below are potential offenders: drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_fsl_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_mxc_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sh_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_hcd_omap_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_orion_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_w90x900_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_atmel_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_octeon_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER vt8500_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER spear_ehci_hcd_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_msm_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_tilegx_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_msp_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER tegra_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER s5p_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_grlib_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_mv_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sead3_driver Yes; those all are old-style drivers. Most of them can be converted to the new scheme with relatively little effort; a few will require more work. In fact, the only drivers that _have_ been converted so far are ehci-pci, chipidea, and ehci-platform. Fair enough... Roger Quadros (now in Cc) can probably help converting ehci-omap to the new scheme if you're willing to provide your review :-) By adding a platform_device to struct ehci-hcd.c we wouldn't need all of those defines. And indeed, each time a driver is converted to the new scheme, its #define gets removed. good, then I withdraw my previous comment :-) Also note that not all of them will be able to simply use ehci-platform.c. OMAP, for instance, needs to reimplement parts of ehci_hub_control() due to silicon erratas (we need to reparent a clock at a specific spot during bus suspend), this means we will always have, at a minimum, ehci-omap.c. Tegra has other silicon erratas on and reimplements other ehci functions and so forth. That's right. But a driver can follow the new scheme without using ehci-platform.c. For example, neither ehci-pci.c nor chipidea/host.c does. that's good :-) But fair enough, I just want to see this fixed but, like yourself, no time to look at that :-s I can fix up ehci-mxc easily enough. Don't all those other drivers cause similar build problems, though? they either already do, or will eventually. It wouldn't hurt to add some restrictions to the Kconfig entry for CONFIG_USB_EHCI_HCD_PLATFORM too. Ok, maybe add a #warn fix your freaking driver dude!! to the
Re: ehci-hcd compile error
-ENOROGER :-p On Thu, Jan 10, 2013 at 08:23:56PM +0200, Felipe Balbi wrote: Hi On Thu, Jan 10, 2013 at 12:01:09PM -0500, Alan Stern wrote: On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi, On Thu, Jan 10, 2013 at 10:36:27AM -0500, Alan Stern wrote: On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi Alan, with v3.8-rc3, ehci-hcd fails to compile for ARM if I use 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 Looks like the recent ARM multi-arch patches didn't take into account EHCI-hcd. Do you know why this problem didn't occur in 3.6-rc2? I don't see any changes in -rc3 that would account for it (although I didn't look terribly thoroughly). It's probably there, I just didn't look at it either :-) It seems clear that CONFIG_EHCI_HCD_PLATFORM needs to be mutually exclusive with all the old-style drivers, in order to prevent this sort of conflict. I just don't see why it never came up before... you can't do that as you will break ARM single zImage builds. Now it becomes easy to see why giving ehci its own platform_device/driver would've been a lot easier ;-) Not at all. We merely need to finish the conversion that I started. It should be pretty easy to convert ehci-mxc over to the new scheme. I don't have time to do it right now, but soon... ehci-mxc isn't the only one redefining PLATFORM_DRIVER. All of below are potential offenders: drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_fsl_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_mxc_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sh_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_hcd_omap_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_orion_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_w90x900_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_atmel_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_octeon_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER vt8500_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER spear_ehci_hcd_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_msm_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_tilegx_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_msp_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER tegra_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER s5p_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_grlib_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_mv_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sead3_driver Yes; those all are old-style drivers. Most of them can be converted to the new scheme with relatively little effort; a few will require more work. In fact, the only drivers that _have_ been converted so far are ehci-pci, chipidea, and ehci-platform. Fair enough... Roger Quadros (now in Cc) can probably help converting ehci-omap to the new scheme if you're willing to provide your review :-) By adding a platform_device to struct ehci-hcd.c we wouldn't need all of those defines. And indeed, each time a driver is converted to the new scheme, its #define gets removed. good, then I withdraw my previous comment :-) Also note that not all of them will be able to simply use ehci-platform.c. OMAP, for instance, needs to reimplement parts of ehci_hub_control() due to silicon erratas (we need to reparent a clock at a specific spot during bus suspend), this means we will always have, at a minimum, ehci-omap.c. Tegra has other silicon erratas on and reimplements other ehci functions and so forth. That's right. But a driver can follow the new scheme without using ehci-platform.c. For example, neither ehci-pci.c nor chipidea/host.c does. that's good :-) But fair enough, I just want to see this fixed but, like yourself, no time to look at that :-s I can
Re: ehci-hcd compile error
On Thu, 10 Jan 2013, Felipe Balbi wrote: -ENOROGER :-p On Thu, Jan 10, 2013 at 08:23:56PM +0200, Felipe Balbi wrote: Hi On Thu, Jan 10, 2013 at 12:01:09PM -0500, Alan Stern wrote: On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi, On Thu, Jan 10, 2013 at 10:36:27AM -0500, Alan Stern wrote: On Thu, 10 Jan 2013, Felipe Balbi wrote: Hi Alan, with v3.8-rc3, ehci-hcd fails to compile for ARM if I use 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 Looks like the recent ARM multi-arch patches didn't take into account EHCI-hcd. Do you know why this problem didn't occur in 3.6-rc2? I don't see any changes in -rc3 that would account for it (although I didn't look terribly thoroughly). It's probably there, I just didn't look at it either :-) It seems clear that CONFIG_EHCI_HCD_PLATFORM needs to be mutually exclusive with all the old-style drivers, in order to prevent this sort of conflict. I just don't see why it never came up before... you can't do that as you will break ARM single zImage builds. As you point out below, they are already broken. Now it becomes easy to see why giving ehci its own platform_device/driver would've been a lot easier ;-) Not at all. We merely need to finish the conversion that I started. It should be pretty easy to convert ehci-mxc over to the new scheme. I don't have time to do it right now, but soon... ehci-mxc isn't the only one redefining PLATFORM_DRIVER. All of below are potential offenders: drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_fsl_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_mxc_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sh_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_hcd_omap_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_orion_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_w90x900_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_atmel_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_octeon_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER vt8500_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER spear_ehci_hcd_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_msm_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_tilegx_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_msp_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER tegra_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER s5p_ehci_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_grlib_driver drivers/usb/host/ehci-hcd.c:#definePLATFORM_DRIVER ehci_mv_driver drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sead3_driver Yes; those all are old-style drivers. Most of them can be converted to the new scheme with relatively little effort; a few will require more work. In fact, the only drivers that _have_ been converted so far are ehci-pci, chipidea, and ehci-platform. Fair enough... Roger Quadros (now in Cc) can probably help converting ehci-omap to the new scheme if you're willing to provide your review :-) Yes, I saw that and was going to recommend to him that the conversion should be done before his changes are applied. :-) Roger, I'll send you a patch for ehci-omap.c shortly. You should base your work on top of it (after testing to make sure that it works okay). It wouldn't hurt to add some restrictions to the Kconfig entry for CONFIG_USB_EHCI_HCD_PLATFORM too. Ok, maybe add a #warn fix your freaking driver dude!! to the non-converted ones would make people help ? Heh. :-) Here's my attempt to convert ehci-mxc. I don't have any simple way even to compile it. Please try it out to make sure that it fixes the build problem without introducing any other errors. Alan Stern Index: usb-3.7/drivers/usb/host/Kconfig
Re: [PATCH 07/14] usb: ehci-omap: Instantiate PHY devices if required
On Thu, 10 Jan 2013, Roger Quadros wrote:
If the OMAP's Host controller is in PHY mode then we instantiate
a platform device for the PHY (one for each port in PHY mode) and
hold a reference to it so that we can use the usb_phy API, e.g.
while suspend/resume.
The platform data for the PHY must be supplied in the newly added
.phy_config parameter in struct usbhs_omap_platform_data.
The end goal is to move the PHY's reset and power handling code
out of the ehci-omap driver and into the phy driver.
As mentioned in another thread, I would prefer to have these changes to
ehci-omap.c made after the driver is converted to the new ehci-hcd is
a library scheme. The patch below does the conversion; it is meant to
apply on top of the similar patch for ehci-mxc posted recently on the
linux-usb mailing list.
After this conversion, the omap_ehci_hcd private data structure doesn't
have to be allocated specifically. It can be handled in the same way
as the private data structure in the ehci-mxc patch.
I haven't even tried to compile this. Please let me know how it works.
Alan Stern
Index: usb-3.7/drivers/usb/host/Kconfig
===
--- usb-3.7.orig/drivers/usb/host/Kconfig
+++ usb-3.7/drivers/usb/host/Kconfig
@@ -155,7 +155,7 @@ config USB_EHCI_MXC
Variation of ARC USB block used in some Freescale chips.
config USB_EHCI_HCD_OMAP
- bool EHCI support for OMAP3 and later chips
+ tristate EHCI support for OMAP3 and later chips
depends on USB_EHCI_HCD ARCH_OMAP
default y
---help---
Index: usb-3.7/drivers/usb/host/Makefile
===
--- usb-3.7.orig/drivers/usb/host/Makefile
+++ usb-3.7/drivers/usb/host/Makefile
@@ -27,6 +27,7 @@ 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_EHCI_HCD_OMAP)+= ehci-omap.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
@@ -1255,11 +1255,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_hcd_sh_driver
#endif
-#ifdef CONFIG_USB_EHCI_HCD_OMAP
-#include ehci-omap.c
-#definePLATFORM_DRIVER ehci_hcd_omap_driver
-#endif
-
#ifdef CONFIG_PPC_PS3
#include ehci-ps3.c
#definePS3_SYSTEM_BUS_DRIVER ps3_ehci_driver
@@ -1349,6 +1344,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_EHCI_HCD_PLATFORM) \
!defined(CONFIG_USB_CHIPIDEA_HOST) \
!defined(CONFIG_USB_EHCI_MXC) \
+ !defined(CONFIG_USB_EHCI_HCD_OMAP) \
!defined(PLATFORM_DRIVER) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
Index: usb-3.7/drivers/usb/host/ehci-omap.c
===
--- usb-3.7.orig/drivers/usb/host/ehci-omap.c
+++ usb-3.7/drivers/usb/host/ehci-omap.c
@@ -36,6 +36,9 @@
* - convert to use hwmod and runtime PM
*/
+#include linux/kernel.h
+#include linux/module.h
+#include linux/io.h
#include linux/platform_device.h
#include linux/slab.h
#include linux/usb/ulpi.h
@@ -44,6 +47,10 @@
#include linux/pm_runtime.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ehci.h
/* EHCI Register Set */
#define EHCI_INSNREG04 (0xA0)
@@ -56,11 +63,13 @@
#defineEHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#defineEHCI_INSNREG05_ULPI_WRDATA_SHIFT0
-/*-*/
+#define DRIVER_DESC = OMAP-EHCI Host Controller driver;
-static const struct hc_driver ehci_omap_hc_driver;
+static const char hcd_name[] = ehci-omap;
+/*-*/
+
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
{
__raw_writel(val, base + reg);
@@ -165,6 +174,12 @@ static void disable_put_regulator(
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
+static struct hc_driver __read_mostly ehci_omap_hc_driver;
+
+static const struct ehci_driver_overrides ehci_omap_overrides __initdata = {
+ .reset =omap_ehci_init,
+};
+
/**
* ehci_hcd_omap_probe - initialize TI-based HCDs
*
@@ -322,56 +337,33 @@ static struct platform_driver ehci_hcd_o
/*.suspend = ehci_hcd_omap_suspend, */
/*.resume = ehci_hcd_omap_resume, */
.driver = {
- .name = ehci-omap,
+
Problem with
Hi, While I was writing a basic v4l2 video grabber I got a wierd bug which I've been discussing with pinchartl and devinheitmueller on freenode #v4l2. The problem is that my /dev/video0 devices disappears when I start my application and press CTRL-C without handling the signal/interupt and closing the devices correctly. When I run my application, and let it grab like 60 frames, then shutdown everything nicely the /dev/video0 is not removed. I can run my app multiple times w/o problems. This problem thus only occurs when I do not close/shutdown the camera correctly. I get this problem with both my own capturer, which I pasted here: https://gist.github.com/6b17e49bc33502f35c74 and also when I use this example app: http://linuxtv.org/downloads/legacy/video4linux/API/V4L2_API/v4l2spec/capture.c When I press CTRL-C when the app runs and my /dev/video0 is removed, I see this in /var/log/kern.log: Jan 10 23:03:15 gtx kernel: [ 121.474062] usb 3-1: Not enough bandwidth for altsetting 0 Jan 10 23:03:20 gtx kernel: [ 126.477528] xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command. Jan 10 23:03:20 gtx kernel: [ 126.477533] xhci_hcd :00:14.0: Assuming host is dying, halting host. Jan 10 23:03:20 gtx kernel: [ 126.477553] xhci_hcd :00:14.0: HC died; cleaning up Jan 10 23:03:20 gtx kernel: [ 126.477595] usb 3-1: USB disconnect, device number 2 Jan 10 23:03:20 gtx kernel: [ 126.486697] xhci_hcd :00:14.0: Slot 1 endpoint 14 not removed from BW list! Jan 10 23:03:20 gtx kernel: [ 126.486712] usb 3-2: USB disconnect, device number 3 Jan 10 23:03:20 gtx kernel: [ 126.486714] usb 3-2.2: USB disconnect, device number 4 Jan 10 23:03:20 gtx kernel: [ 126.533588] xhci_hcd :00:14.0: Slot 3 endpoint 2 not removed from BW list! Jan 10 23:03:20 gtx kernel: [ 126.533593] xhci_hcd :00:14.0: Slot 3 endpoint 4 not removed from BW list! Jan 10 23:03:20 gtx kernel: [ 126.533809] xhci_hcd :00:14.0: Slot 2 endpoint 2 not removed from BW list! Another thing to mention, is that my USB keyboard, which is on the same usb-bus also fails; I've to reboot (using ssh :-) ) to enable the devices again. Some more info which might tell more $ v4l2-ctl --list-devices UVC Camera (046d:09a6) (usb-:00:14.0-1): /dev/video0 $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 002: ID 046d:09a6 Logitech, Inc. QuickCam Vision Pro Bus 003 Device 003: ID 05ac:1006 Apple, Inc. Hub in Aluminum Keyboard Bus 005 Device 002: ID 2109:0811 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 004: ID 05ac:0221 Apple, Inc. Aluminum Keyboard (ISO) Bus 005 Device 003: ID 045e:076c Microsoft Corp. Ubuntu 12.10 (GNU/Linux 3.5.0-21-generic x86_64) What can I do to look more into this and figure out why it's failing or how to find a workaround? Best roxlu -- 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 01/14] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data
* Roger Quadros rog...@ti.com [130110 08:54]:
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.
I can apply just this patch alone into an immutable branch that
we all can merge in as needed as long as we have acks for the USB
and MFD parts.
Or does this one need to be changed based on Alan's comments
on the EHCI lib related changes?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
---
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 | 30 +++---
arch/arm/mach-omap2/usb.h | 21 +
drivers/mfd/omap-usb-host.c| 46
drivers/mfd/omap-usb-tll.c |8 ++--
drivers/usb/host/ehci-omap.c |6 ++--
include/linux/platform_data/usb-omap.h | 26
22 files changed, 56 insertions(+), 115 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
Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
On Thu, Jan 10, 2013 at 06:30:06AM -0800, Greg KH wrote: On Thu, Jan 10, 2013 at 12:08:35PM +0200, Felipe Balbi wrote: Hi, Some recent patch has caused fsl_mxc_udc.c driver to fail compilation because it can't find mach/hardware.h anymore. I would like this to be fixed still during this -rc cycle. Me too, who's sending a patch? :) Let me have a look, and try to send a patch as soon as possible -- 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 -- 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
Re: [PATCH 1/4] ARM: dts: mxs-phy: Change mxs phy clock usage
On Thu, Jan 10, 2013 at 04:35:51PM +0800, Peter Chen wrote: For mxs-phy user i.mx6q, the PHY's clock is controlled by hardware automatically, the software only needs to enable it at probe, this clock should be used like below: - Enable at mxs-phy's probe, and disable at mxs-phy's remove, so The clk framework doesn't need to know it. But other mxs-phy user mx28/mx23 may need it, so we give mxs-phy a dummy clock for imx6q. - During the runtime, we don't need to control it. Turning it into a dummy clock, you will have no way to maintain the use count. It could possibly cause parent clock be turned off while usbphy is in use. Let's try to find some other way. Shawn -- 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] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
Cc netdev and usb lists. On Fri, Jan 11, 2013 at 9:17 AM, fre...@asix.com.tw wrote: From: Freddy Xin fre...@asix.com.tw This patch adds a driver for ASIX's AX88179 family of USB 3.0/2.0 to gigabit ethernet adapters. It's based on the AX88xxx driver but the usb commands used to access registers for AX88179 are completely different. This driver had been verified on x86 system with AX88179/AX88178A and Sitcomm LN-032 USB dongles. Signed-off-by: Freddy Xin fre...@asix.com.tw --- drivers/net/usb/Kconfig| 18 + drivers/net/usb/Makefile |1 + drivers/net/usb/ax88179_178a.c | 1457 3 files changed, 1476 insertions(+) create mode 100644 drivers/net/usb/ax88179_178a.c diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index ef97621..75af401 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -158,6 +158,24 @@ config USB_NET_AX8817X This driver creates an interface named ethX, where X depends on what other networking devices you have in use. +config USB_NET_AX88179_178A + tristate ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet + depends on USB_USBNET + select CRC32 + select PHYLIB + default y + help + This option adds support for ASIX AX88179 based USB 3.0/2.0 + to Gigabit Ethernet adapters. + + This driver should work with at least the following devices: + * ASIX AX88179 + * ASIX AX88178A + * Sitcomm LN-032 + + This driver creates an interface named ethX, where X depends on + what other networking devices you have in use. + config USB_NET_CDCETHER tristate CDC Ethernet support (smart devices such as cable modems) depends on USB_USBNET diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile index 4786913..ce01578 100644 --- a/drivers/net/usb/Makefile +++ b/drivers/net/usb/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_USB_RTL8150) += rtl8150.o obj-$(CONFIG_USB_HSO) += hso.o obj-$(CONFIG_USB_NET_AX8817X) += asix.o asix-y := asix_devices.o asix_common.o ax88172a.o +obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o obj-$(CONFIG_USB_NET_DM9601) += dm9601.o diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c new file mode 100644 index 000..47504ea --- /dev/null +++ b/drivers/net/usb/ax88179_178a.c @@ -0,0 +1,1457 @@ +/* + * ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet Devices + * + * Copyright (C) 20011-2012 ASIX + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + */ + +#include linux/module.h +#include linux/etherdevice.h +#include linux/mii.h +#include linux/usb.h +#include linux/crc32.h +#include linux/usb/usbnet.h + + +#define AX88179_PHY_ID 0x03 +#define AX_EEPROM_LEN 0x100 +#define AX_MCAST_FILTER_SIZE 8 +#define AX_MAX_MCAST 64 +#define AX_RX_CHECKSUM 1 +#define AX_TX_CHECKSUM 2 +#define AX_INT_PPLS_LINK BIT(0) +#define AX_RXHDR_L4_TYPE_UDP 1 +#define AX_RXHDR_L4_TYPE_TCP 4 +#define AX_ACCESS_MAC 0x01 +#define AX_ACCESS_PHY 0x02 +#define AX_ACCESS_EEPROM 0x04 +#define AX_ACCESS_EFUSE0x05 +#define AX_PAUSE_WATERLVL_HIGH 0x54 +#define AX_PAUSE_WATERLVL_LOW 0x55 + +#define PHYSICAL_LINK_STATUS 0x02 + #define AX_USB_SS 0x04 + #define AX_USB_HS 0x02 + #define AX_USB_FS 0x01 + +#define GENERAL_STATUS 0x03 +/* Check AX88179 version. UA1:Bit2 = 0, UA2:Bit2 = 1 */ + #define AX_SECLD0x04 + +#define AX_SROM_ADDR 0x07 +#define AX_SROM_CMD0x0a + #define EEP_RD 0x04 + #define EEP_BUSY0x10 +
Re: [PATCH 1/2] usbnet: allow status interrupt URB to always be active
On Sat, Jan 5, 2013 at 9:26 AM, Dan Williams d...@redhat.com wrote: On Fri, 2013-01-04 at 23:16 +0100, Oliver Neukum wrote: On Friday 04 January 2013 10:48:16 Dan Williams wrote: Some drivers (ex sierra_net) need the status interrupt URB active even when the device is closed, because they receive custom indications from firmware. Allow sub-drivers to set a flag that submits the status interrupt URB on probe and keeps the URB alive over device open/close. The URB is still killed/re-submitted for suspend/resume, as before. Signed-off-by: Dan Williams d...@redhat.com --- Oliver: alternatively, is there a problem with *always* submitting the interrupt URB, and then simply not calling the subdriver's .status function when the netdev is closed? That would be a much simpler patch. That is quite radical. We have no idea what a device does when we do not react to a status update. I would much prefer to not take the risk. Besides, we don't use bandwidth if we don't have to. Ok, so scratch the alternative. Thus, does the posted patch look like the right course of action? If I wasn't clear enough before, sierra_net needs to listen to the status interrupt URB to receive the custom Restart indication as part of the driver's device setup. Thus for sierra_net at least, tying the I am curious who are interested in the 'custom Restart indication' information after the interface is closed. If sierra_net provides ways(such as read registers) to query the indication event, you can just query the information and setup the device in driver_info-reset() during device open, so you can avoid submitting interrupt URB always. status interrupt URB submission to device open/close isn't right. In theory, drivers should support to report its link status even it is closed, but looks no much actual usage, so guys opt to submit the interrupt URB only after it is opened. 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 1/4] ARM: dts: mxs-phy: Change mxs phy clock usage
On Thu, Jan 10, 2013 at 04:35:51PM +0800, Peter Chen wrote: For mxs-phy user i.mx6q, the PHY's clock is controlled by hardware automatically, the software only needs to enable it at probe, this clock should be used like below: - Enable at mxs-phy's probe, and disable at mxs-phy's remove, so The clk framework doesn't need to know it. But other mxs-phy user mx28/mx23 may need it, so we give mxs-phy a dummy clock for imx6q. - During the runtime, we don't need to control it. Turning it into a dummy clock, you will have no way to maintain the use count. It could possibly cause parent clock be turned off while usbphy is in use. Let's try to find some other way. I will keep the phyclk unchanged, but just let it control a reserved bit In that case, the clk framework will know USB is using PLL. Meanwhile, the real USB PHY clk gate will only be open one time at phy driver's probe. Shawn -- 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: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
-Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, January 10, 2013 10:30 PM To: Felipe Balbi Cc: Li Yang-R58472; linux-usb@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3 On Thu, Jan 10, 2013 at 12:08:35PM +0200, Felipe Balbi wrote: Hi, Some recent patch has caused fsl_mxc_udc.c driver to fail compilation because it can't find mach/hardware.h anymore. I would like this to be fixed still during this -rc cycle. Me too, who's sending a patch? :) Hi Peter, Who is currently working on the i.mx USB? Regards, Leo -- 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: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
Some recent patch has caused fsl_mxc_udc.c driver to fail compilation because it can't find mach/hardware.h anymore. I would like this to be fixed still during this -rc cycle. Me too, who's sending a patch? :) Hi Peter, Who is currently working on the i.mx USB? I am working on it, but there are two versions, this one and chipidea's. Anyway, I will send a patch to fix this problem. Regards, Leo -- 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 redirection
Hello everyone, I've been focusing (for now) on getting USBIP to work and its been an uphill battle. On LinuxMint 14 64bit I am able to build all the modules. I'm also able to load usbip-core.ko. But when I load vhci-hcd.ko, the load is successful but immediately after that the system just hangs completely - no response to keyboard or mouse, but no kernel crash. Only way out is to do a power cycle. On LinuxMint 13 64 bit (kernel 3.2.0.23) I'm unable to build the kernel modules if I use the code that comes with the distro. Here is the error I get: make M=/usr/src/modules/usbip/src LD /usr/src/modules/usbip/src/built-in.o CC [M] /usr/src/modules/usbip/src/stub_dev.o /usr/src/modules/usbip/src/stub_dev.c: In function ‘stub_probe’: /usr/src/modules/usbip/src/stub_dev.c:392:42: error: ‘struct device’ has no member named ‘bus_id’ If I use the sources from kernel.org, then I'm able to build ok and load all the modules, but system hangs in the same way as above the moment I run 'usbip attach' Has anyone been able to successfully build and run USBIP on 3.1 or 3.2 kernels? If yes, your help would be greatly appreciated! thanks Chirkut On Tue, Jan 8, 2013 at 12:44 AM, Anil Nair anilcol...@gmail.com wrote: Hello Abhijit and David, Thanks for pointing that out. And thanks for the help. :) -- Regards, Anil Nair -- 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 redirection
Hello Chirkut, On LinuxMint 14 64bit I am able to build all the modules. I'm also able to load usbip-core.ko. But when I load vhci-hcd.ko, the load is successful but immediately after that the system just hangs completely - no response to keyboard or mouse, but no kernel crash. Only way out is to do a power cycle. I tested the usb-vhci source in Ubuntu distro 32-bit edition having Linux kernel version 2.6.34, the usb-vhci source isnt compatible with Linux kernel version 3.0+, i tried porting it but it gave me unknown symbols error while loading the module. try the usb-vhci source in 32-bit distros with linux kernel version 2.6+ also before loading the vhci-hcd.ko you will have to load a module named iocifc.ko i don't know its exact name but it ends with iocifc. About USBIP i have no clue i haven't tried it. -- Regards, Anil Nair -- 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] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
From: Ming Lei ming@canonical.com Date: Fri, 11 Jan 2013 10:45:38 +0800 Cc netdev and usb lists. That doesn't work for patches, sorry. It will have to be submitted freshly and cleanly to the appropriate lists, not as a quoted reply. -- 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 4/8] usb/dwc3: fix isoc END TRANSFER Condition
On 1/10/2013 6:02 PM, Sergei Shtylyov wrote:
Hello.
On 10-01-2013 13:53, Pratyush Anand wrote:
There were still some corner cases where isoc transfer was not able to
restart, specially when missed isoc does not happen , and in fact gadget does
not queue any new request during giveback.
Cleanup function calls giveback first, which provides a way to queue
another request to gadget. But gadget did not had any data. So , it did
not call ep_queue. To twist it further, gadget did not queue till
cleanup for last queued TRB is called. If we ever reach this scenario,
we must call END TRANSFER, so that we receive a new xfernotready with
information about current microframe number.
Also insure that there is no request submitted to core when issuing END
TRANSFER.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c | 23 ++-
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4d24711..45db6df 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
[...]
@@ -1727,10 +1730,20 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
break;
} while (1);
- if (list_empty(dep-req_queued)
- (dep-flags DWC3_EP_MISSED_ISOC)) {
- dwc3_stop_active_transfer(dwc, dep-number);
- dep-flags = ~DWC3_EP_MISSED_ISOC;
+ if (usb_endpoint_xfer_isoc(dep-endpoint.desc)
+ (list_empty(dep-req_queued))) {
Parens not needed at all around list_empty() invocation.
Ok, will remove parenthesis and will send v2.
Will wait for 3-4 more days for any other comments before I send v2.
Regards
Pratyush
WBR, Sergei
.
--
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 redirection
On 01/11/2013 09:27 AM, Chirkut Daruwalla wrote: Hello everyone, I've been focusing (for now) on getting USBIP to work and its been an uphill battle. On LinuxMint 14 64bit I am able to build all the modules. I'm also able to load usbip-core.ko. But when I load vhci-hcd.ko, the load is successful but immediately after that the system just hangs completely - no response to keyboard or mouse, but no kernel crash. Only way out is to do a power cycle. can you try inserting vhci module on client linux machine from where you want to see the virtual usb device? On LinuxMint 13 64 bit (kernel 3.2.0.23) I'm unable to build the kernel modules if I use the code that comes with the distro. Here is the error I get: make M=/usr/src/modules/usbip/src LD /usr/src/modules/usbip/src/built-in.o CC [M] /usr/src/modules/usbip/src/stub_dev.o /usr/src/modules/usbip/src/stub_dev.c: In function ‘stub_probe’: /usr/src/modules/usbip/src/stub_dev.c:392:42: error: ‘struct device’ has no member named ‘bus_id’ If I use the sources from kernel.org, then I'm able to build ok and load all the modules, but system hangs in the same way as above the moment I run 'usbip attach' Has anyone been able to successfully build and run USBIP on 3.1 or 3.2 kernels? If yes, your help would be greatly appreciated! I have tested it on 32 bit fedora with stock kernel 3.1.0-7.fc16.i686. It works as expected. thanks Chirkut On Tue, Jan 8, 2013 at 12:44 AM, Anil Nair anilcol...@gmail.com wrote: Hello Abhijit and David, Thanks for pointing that out. And thanks for the help. :) -- Regards, Anil Nair -- - Abhijit -- 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
