[PATCH net] net: usbnet: fix softirq storm on suspend
Suspending an open usbnet device results in constant
rescheduling of usbnet_bh.
commit 65841fd5 "usbnet: handle remote wakeup asap"
refactored the usbnet_bh code to allow sharing the
urb allocate and submit code with usbnet_resume. In
this process, a test for, and immediate return on,
ENOLINK from rx_submit was unintentionally dropped.
The rx queue will not grow if rx_submit fails,
making usbnet_bh reschedule itself. This results
in a softirq storm if the error is persistent.
rx_submit translates the usb_submit_urb error
EHOSTUNREACH into ENOLINK, so this is an expected
and persistent error for a suspended device. The
old code tested for this condition and avoided
rescheduling. Putting this test back.
Cc: # v3.5
Cc: Ming Lei
Cc: Oliver Neukum
Signed-off-by: Bjørn Mork
---
Sorry for not noticing this before, but commit 65841fd5
makes usbnet autosuspend completely unusable. The device
is suspended fine, but burning one CPU core at full load
uses a tiny bit more power making the power saving
negative...
I hope this can go into 3.6 and 3.5-stable ASAP. It is
a hard to notice regression, but all the same a serious
one.
Thanks,
Bjørn
drivers/net/usb/usbnet.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index fd4b26d..fc9f578 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1201,19 +1201,26 @@ deferred:
}
EXPORT_SYMBOL_GPL(usbnet_start_xmit);
-static void rx_alloc_submit(struct usbnet *dev, gfp_t flags)
+static int rx_alloc_submit(struct usbnet *dev, gfp_t flags)
{
struct urb *urb;
int i;
+ int ret = 0;
/* don't refill the queue all at once */
for (i = 0; i < 10 && dev->rxq.qlen < RX_QLEN(dev); i++) {
urb = usb_alloc_urb(0, flags);
if (urb != NULL) {
- if (rx_submit(dev, urb, flags) == -ENOLINK)
- return;
+ ret = rx_submit(dev, urb, flags);
+ if (ret)
+ goto err;
+ } else {
+ ret = -ENOMEM;
+ goto err;
}
}
+err:
+ return ret;
}
/*-*/
@@ -1257,7 +1264,8 @@ static void usbnet_bh (unsigned long param)
int temp = dev->rxq.qlen;
if (temp < RX_QLEN(dev)) {
- rx_alloc_submit(dev, GFP_ATOMIC);
+ if (rx_alloc_submit(dev, GFP_ATOMIC) == -ENOLINK)
+ return;
if (temp != dev->rxq.qlen)
netif_dbg(dev, link, dev->net,
"rxqlen %d --> %d\n",
--
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
OMAP: USB: EHCI: usbhost suspend/resume
Hi, I'm facing some problems with USB power management on OMAP3 (Beagleboard-Xm). Lately I have tried kernel 3.6-rc3 for omap but usb bus suspend/resume is switched off there due to some problems with clocks: This is described in: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue (http://thread.gmane.org/gmane.linux.usb.general/66239/focus=66866) Does anyone know if usb pm has worked in any kernel version from 2.6.37 for omap. I know that 2.6.37 is quite old as concerns usb pm but partially it works there - there are some problems with clocks to usbhost which are managed form ehci driver level (not system pm). I would prefer to fix this in 2.6.37 because of other android related issues. The problem occurs when sleep_when_idle is on and core, usbhost power domains hit retention and usb device (with autosuspend) is connected to host port. The clocks to usbhost are enabled/disabled but sometimes usbhost_48m_fck can't be enabled (randomly) and whole usbhost register operations are unstable. Other thing is that when sleep_when_idle is 0 (disabled) and usb pm is enabled it always fail and I can see "cm: Module associated with clock usbhost_48m_fck didn't enable in 10 tries clk reg is fa005420" but I can't figure out which other thing is related with usbhost_48m_fck that it fails to enable the clock. Karol -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] net: cx82310_eth: use common match macro
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cx82310_eth.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index 49ab45e..1e207f0 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -302,18 +302,9 @@ static const struct driver_infocx82310_info = {
.tx_fixup = cx82310_tx_fixup,
};
-#define USB_DEVICE_CLASS(vend, prod, cl, sc, pr) \
- .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
- USB_DEVICE_ID_MATCH_DEV_INFO, \
- .idVendor = (vend), \
- .idProduct = (prod), \
- .bDeviceClass = (cl), \
- .bDeviceSubClass = (sc), \
- .bDeviceProtocol = (pr)
-
static const struct usb_device_id products[] = {
{
- USB_DEVICE_CLASS(0x0572, 0xcb01, 0xff, 0, 0),
+ USB_DEVICE_AND_INTERFACE_INFO(0x0572, 0xcb01, 0xff, 0, 0),
.driver_info = (unsigned long) &cx82310_info
},
{ },
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/2] net: sierra_net: make private symbols static
Signed-off-by: Bjørn Mork
---
drivers/net/usb/sierra_net.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 7be49ea..596ddaa 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -560,7 +560,7 @@ static void sierra_net_defer_kevent(struct usbnet *dev, int
work)
/*
* Sync Retransmit Timer Handler. On expiry, kick the work queue
*/
-void sierra_sync_timer(unsigned long syncdata)
+static void sierra_sync_timer(unsigned long syncdata)
{
struct usbnet *dev = (struct usbnet *)syncdata;
@@ -866,8 +866,8 @@ static int sierra_net_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
}
/* Transmit data path --*/
-struct sk_buff *sierra_net_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
- gfp_t flags)
+static struct sk_buff *sierra_net_tx_fixup(struct usbnet *dev,
+ struct sk_buff *skb, gfp_t flags)
{
struct sierra_net_data *priv = sierra_net_get_private(dev);
u16 len;
--
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
[PATCH net-next 2/2] net: sierra_net: rx_urb_size is constant
The rx_urb_size is set to the same value for every device
supported by this driver. No need to keep a per-device
data structure to do that. Replacing with a macro constant.
This was the last device specific info, and removing it
allows us to delete the sierra_net_info_data struct.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/sierra_net.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 596ddaa..7ae70e9 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -68,9 +68,8 @@ staticatomic_t iface_counter = ATOMIC_INIT(0);
*/
#define SIERRA_NET_USBCTL_BUF_LEN 1024
-struct sierra_net_info_data {
- u16 rx_urb_size;
-};
+/* Overriding the default usbnet rx_urb_size */
+#define SIERRA_NET_RX_URB_SIZE (8 * 1024)
/* Private data structure */
struct sierra_net_data {
@@ -678,9 +677,6 @@ static int sierra_net_bind(struct usbnet *dev, struct
usb_interface *intf)
static const u8 shdwn_tmplate[sizeof(priv->shdwn_msg)] = {
0x00, 0x00, SIERRA_NET_HIP_SHUTD_ID, 0x00};
- struct sierra_net_info_data *data =
- (struct sierra_net_info_data *)dev->driver_info->data;
-
dev_dbg(&dev->udev->dev, "%s", __func__);
ifacenum = intf->cur_altsetting->desc.bInterfaceNumber;
@@ -725,9 +721,9 @@ static int sierra_net_bind(struct usbnet *dev, struct
usb_interface *intf)
sierra_net_set_ctx_index(priv, 0);
/* decrease the rx_urb_size and max_tx_size to 4k on USB 1.1 */
- dev->rx_urb_size = data->rx_urb_size;
+ dev->rx_urb_size = SIERRA_NET_RX_URB_SIZE;
if (dev->udev->speed != USB_SPEED_HIGH)
- dev->rx_urb_size = min_t(size_t, 4096, data->rx_urb_size);
+ dev->rx_urb_size = min_t(size_t, 4096, SIERRA_NET_RX_URB_SIZE);
dev->net->hard_header_len += SIERRA_NET_HIP_EXT_HDR_LEN;
dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
@@ -918,10 +914,6 @@ static struct sk_buff *sierra_net_tx_fixup(struct usbnet
*dev,
return NULL;
}
-static const struct sierra_net_info_data sierra_net_info_data_direct_ip = {
- .rx_urb_size = 8 * 1024,
-};
-
static const struct driver_info sierra_net_info_direct_ip = {
.description = "Sierra Wireless USB-to-WWAN Modem",
.flags = FLAG_WWAN | FLAG_SEND_ZLP,
@@ -930,7 +922,6 @@ static const struct driver_info sierra_net_info_direct_ip =
{
.status = sierra_net_status,
.rx_fixup = sierra_net_rx_fixup,
.tx_fixup = sierra_net_tx_fixup,
- .data = (unsigned long)&sierra_net_info_data_direct_ip,
};
#define DIRECT_IP_DEVICE(vend, prod) \
--
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
[PATCH 1/3] usb: gadget: s3c-hsudc: Use devm_* functions
devm_* functions are used to replace kzalloc, request_mem_region, ioremap
clk_get and request_irq functions in probe call. With the usage of devm_*
functions explicit freeing and unmapping is not required.
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c | 41 ---
1 files changed, 9 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index e26a4e7..fe4a461 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -135,7 +135,6 @@ struct s3c_hsudc_req {
* @dev: The device reference used by probe function.
* @lock: Lock to synchronize the usage of Endpoints (EP's are indexed).
* @regs: Remapped base address of controller's register space.
- * @mem_rsrc: Device memory resource used for remapping device register space.
* irq: IRQ number used by the controller.
* uclk: Reference to the controller clock.
* ep0state: Current state of EP0.
@@ -150,7 +149,6 @@ struct s3c_hsudc {
struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsudc_supply_names)];
spinlock_t lock;
void __iomem *regs;
- struct resource *mem_rsrc;
int irq;
struct clk *uclk;
int ep0state;
@@ -1271,7 +1269,7 @@ static int __devinit s3c_hsudc_probe(struct
platform_device *pdev)
struct s3c24xx_hsudc_platdata *pd = pdev->dev.platform_data;
int ret, i;
- hsudc = kzalloc(sizeof(struct s3c_hsudc) +
+ hsudc = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsudc) +
sizeof(struct s3c_hsudc_ep) * pd->epnum,
GFP_KERNEL);
if (!hsudc) {
@@ -1296,25 +1294,12 @@ static int __devinit s3c_hsudc_probe(struct
platform_device *pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "unable to obtain driver resource data\n");
- ret = -ENODEV;
- goto err_res;
- }
-
- hsudc->mem_rsrc = request_mem_region(res->start, resource_size(res),
- dev_name(&pdev->dev));
- if (!hsudc->mem_rsrc) {
- dev_err(dev, "failed to reserve register area\n");
- ret = -ENODEV;
- goto err_res;
- }
- hsudc->regs = ioremap(res->start, resource_size(res));
+ hsudc->regs = devm_request_and_ioremap(&pdev->dev, res);
if (!hsudc->regs) {
dev_err(dev, "error mapping device register area\n");
ret = -EBUSY;
- goto err_remap;
+ goto err_res;
}
spin_lock_init(&hsudc->lock);
@@ -1337,21 +1322,22 @@ static int __devinit s3c_hsudc_probe(struct
platform_device *pdev)
ret = platform_get_irq(pdev, 0);
if (ret < 0) {
dev_err(dev, "unable to obtain IRQ number\n");
- goto err_irq;
+ goto err_res;
}
hsudc->irq = ret;
- ret = request_irq(hsudc->irq, s3c_hsudc_irq, 0, driver_name, hsudc);
+ ret = devm_request_irq(&pdev->dev, hsudc->irq, s3c_hsudc_irq, 0,
+ driver_name, hsudc);
if (ret < 0) {
dev_err(dev, "irq request failed\n");
- goto err_irq;
+ goto err_res;
}
- hsudc->uclk = clk_get(&pdev->dev, "usb-device");
+ hsudc->uclk = devm_clk_get(&pdev->dev, "usb-device");
if (IS_ERR(hsudc->uclk)) {
dev_err(dev, "failed to find usb-device clock source\n");
ret = PTR_ERR(hsudc->uclk);
- goto err_clk;
+ goto err_res;
}
clk_enable(hsudc->uclk);
@@ -1377,21 +1363,12 @@ err_add_udc:
device_unregister(&hsudc->gadget.dev);
err_add_device:
clk_disable(hsudc->uclk);
- clk_put(hsudc->uclk);
-err_clk:
- free_irq(hsudc->irq, hsudc);
-err_irq:
- iounmap(hsudc->regs);
-
-err_remap:
- release_mem_region(res->start, resource_size(res));
err_res:
if (!IS_ERR_OR_NULL(hsudc->transceiver))
usb_put_phy(hsudc->transceiver);
regulator_bulk_free(ARRAY_SIZE(hsudc->supplies), hsudc->supplies);
err_supplies:
- kfree(hsudc);
return 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 2/3] usb: gadget: s3c-hsudc: Add missing braces around sizeof
Silences the following checkpatch warning:
WARNING: sizeof *hsreq should be sizeof(*hsreq)
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index fe4a461..35cdc6a 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -833,7 +833,7 @@ static struct usb_request *s3c_hsudc_alloc_request(struct
usb_ep *_ep,
{
struct s3c_hsudc_req *hsreq;
- hsreq = kzalloc(sizeof *hsreq, gfp_flags);
+ hsreq = kzalloc(sizeof(*hsreq), gfp_flags);
if (!hsreq)
return 0;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] usb: gadget: s3c-hsudc: Replace 0 with NULL for pointers
Silences the following type of sparse warnings:
warning: Using plain integer as NULL pointer
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index 35cdc6a..d8e785d 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -835,7 +835,7 @@ static struct usb_request *s3c_hsudc_alloc_request(struct
usb_ep *_ep,
hsreq = kzalloc(sizeof(*hsreq), gfp_flags);
if (!hsreq)
- return 0;
+ return NULL;
INIT_LIST_HEAD(&hsreq->queue);
return &hsreq->req;
@@ -904,16 +904,16 @@ static int s3c_hsudc_queue(struct usb_ep *_ep, struct
usb_request *_req,
csr = readl((u32)hsudc->regs + offset);
if (!(csr & S3C_ESR_TX_SUCCESS) &&
(s3c_hsudc_write_fifo(hsep, hsreq) == 1))
- hsreq = 0;
+ hsreq = NULL;
} else {
csr = readl((u32)hsudc->regs + offset);
if ((csr & S3C_ESR_RX_SUCCESS)
&& (s3c_hsudc_read_fifo(hsep, hsreq) == 1))
- hsreq = 0;
+ hsreq = NULL;
}
}
- if (hsreq != 0)
+ if (hsreq)
list_add_tail(&hsreq->queue, &hsep->queue);
spin_unlock_irqrestore(&hsudc->lock, flags);
--
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] usb: gadget: s3c-hsotg: Use devm_clk_get function
devm_* functions are already used in this file. Hence
convert clk_get to devm_clk_get for completeness.
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsotg.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 0bb617e..1c8789a 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -3516,7 +3516,7 @@ static int __devinit s3c_hsotg_probe(struct
platform_device *pdev)
hsotg->dev = dev;
hsotg->plat = plat;
- hsotg->clk = clk_get(&pdev->dev, "otg");
+ hsotg->clk = devm_clk_get(&pdev->dev, "otg");
if (IS_ERR(hsotg->clk)) {
dev_err(dev, "cannot get otg clock\n");
return PTR_ERR(hsotg->clk);
@@ -3667,7 +3667,6 @@ err_supplies:
err_clk:
clk_disable_unprepare(hsotg->clk);
- clk_put(hsotg->clk);
return ret;
}
@@ -3693,7 +3692,6 @@ static int __devexit s3c_hsotg_remove(struct
platform_device *pdev)
regulator_bulk_free(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
clk_disable_unprepare(hsotg->clk);
- clk_put(hsotg->clk);
device_unregister(&hsotg->gadget.dev);
return 0;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] usb: gadget: s3c-hsudc: Replace 0 with NULL for pointers
Hi, On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat wrote: > Silences the following type of sparse warnings: > warning: Using plain integer as NULL pointer > > Signed-off-by: Sachin Kamat > --- > drivers/usb/gadget/s3c-hsudc.c |8 > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c > index 35cdc6a..d8e785d 100644 > --- a/drivers/usb/gadget/s3c-hsudc.c > +++ b/drivers/usb/gadget/s3c-hsudc.c > @@ -835,7 +835,7 @@ static struct usb_request *s3c_hsudc_alloc_request(struct > usb_ep *_ep, > > hsreq = kzalloc(sizeof(*hsreq), gfp_flags); > if (!hsreq) > - return 0; > + return NULL; shouldn't this be -ENOMEM? 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 3/3] usb: gadget: s3c-hsudc: Replace 0 with NULL for pointers
Hi On 3 September 2012 16:37, ABRAHAM, KISHON VIJAY wrote: > Hi, > > On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat wrote: >> Silences the following type of sparse warnings: >> warning: Using plain integer as NULL pointer >> >> Signed-off-by: Sachin Kamat >> --- >> drivers/usb/gadget/s3c-hsudc.c |8 >> 1 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c >> index 35cdc6a..d8e785d 100644 >> --- a/drivers/usb/gadget/s3c-hsudc.c >> +++ b/drivers/usb/gadget/s3c-hsudc.c >> @@ -835,7 +835,7 @@ static struct usb_request >> *s3c_hsudc_alloc_request(struct usb_ep *_ep, >> >> hsreq = kzalloc(sizeof(*hsreq), gfp_flags); >> if (!hsreq) >> - return 0; >> + return NULL; > > shouldn't this be -ENOMEM? That should have been the obvious return value. However, I thought probably it was made so with some reasoning and did not change it as I am not familiar with this driver. > > Thanks > Kishon -- With warm regards, Sachin -- 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: [RFC] How to handle delays in isochronous transfers?
Alan Stern wrote: > How should the lower USB layers handle delays in transferring > isochronous data? [...] when this happens the endpoint's queue > drains completely. > > Clearly this will cause a glitch in the data stream. The question is: > What should we do to recover and re-synchronize? The ALSA API promises that the samples in a stream run at a fixed clock, i.e., samples are never delayed or accelerated. > We could pretend nothing happened and continue to handle URBs normally, > scheduling each submission for the next available slot. But for an > isochronous-OUT transfer, this would mean that all the future data > values are delayed by some 40 ms relative to the earlier data. If > another glitch occurs then the following data will be delayed by even > more. For some applications this might not matter, but for others > (real-time things like voice) it could be quite bad. Similar problems > arise with IN transfers. This would not be acceptable; future samples must be scheduled for the same frame for which they would have been scheduled without the delay. > Alternatively, the host controller driver could fail the next 40 ms > worth of isochronous URBs, so that the higher-level client catches up > to where it should be. The failure could occur during submission, or > the URBs could be accepted and then forced to complete immediately, > with no data transferred. Both would be possible. At the moment, a submission failure would cause the driver to stop the stream and report an error to the application. In this kind of situation (where it's known that multiple packets have not been transferred), it would be somewhat preferrable to report the error instead of ignoring it. > What's the right thing to do? My feeling is that the behavior > should be decided not by the host controller driver but rather by the > higher-level client. Yeah, "schedule directly after the previous packet, or fail" and "schedule for the next possible frame" might be useful. (But the audio driver would always use the first option.) Regards, Clemens -- 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: [RFC] How to handle delays in isochronous transfers?
Peter Chen wrote: >> How should the lower USB layers handle delays in transferring >> isochronous data? >> I have seen reports from users where URB completion interrupts were >> delayed by as much as 50 ms. >> >> What should we do to recover and re-synchronize? > > I am not sure if feedback endpoint is implemented at our ISO-transfer > class driver. > If it is implemented, the class driver will take responsible to speed up/slow > down transferring according to the device's feedback information. In such a situation, the delay is much bigger than the device's buffer, so just sending more samples afterwards will not help. Furthermore, if packets are lost, frequency feedback becomes impossible because the device doesn't know how many samples were lost. Regards, Clemens -- 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: [RFC ebeam PATCH v4 2/2] input: misc: New USB eBeam input driver.
On Friday 24 August 2012 16:42:20 Yann Cantin wrote: > Hi, > > Le 24/08/2012 13:41, Oliver Neukum a écrit : > > On Friday 24 August 2012 11:37:45 Yann Cantin wrote: > >> Hi, > >> > >> Le 23/08/2012 09:23, Oliver Neukum a écrit : > >>> On Thursday 23 August 2012 00:11:54 Yann Cantin wrote: > > > >>> These functions are identical. You should unify them. > >> > >> Removed reset_resume from the driver (optional, and not needed > >> for this hardware). > > > > Why did you do that? It is always better to have reset_resume(). > > And you cannot tell whether it will be needed. > > This function was used in usbtouchscreen (which this driver is based on) > for some hardware specific init after reset. eBeam devices doesn't need that, > and i didn't mention the similarity of the 2 functions after stripping the > code. > > According to power-management.txt, reset_resume is optional, and lot of input > driver lack it. Anyway, if you think it's worth the code, i'll re-add a > reset_resume function proxing resume like wacom_sys.c do. It is always better to have reset_resume() if it can be easily done. 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 resend] Input: usbtouchscreen - initialize eGalax devices
On Fri, Aug 31, 2012 at 08:37:26PM -0400, Forest Bond wrote:
> From: Forest Bond
>
> Certain eGalax devices expose an interface with class HID and protocol
> None. Some work with usbhid and some work with usbtouchscreen, but
> there is no easy way to differentiate. Sending an eGalax diagnostic
> packet seems to kick them all into using the right protocol for
> usbtouchscreen, so we can continue to bind them all there (as opposed to
> handing some off to usbhid).
>
> This fixes a regression for devices that were claimed by (and worked
> with) usbhid prior to commit 139ebe8dc80dd74cb2ac9f5603d18fbf5cff049f
> ("Input: usbtouchscreen - fix eGalax HID ignoring"), which made
> usbtouchscreen claim them instead. With this patch they will still be
> claimed by usbtouchscreen, but they will actually report events
> usbtouchscreen can understand. Note that these devices will be limited
> to the usbtouchscreen feature set so e.g. dual touch features are not
> supported.
>
> I have the distinct pleasure of needing to support devices of both types
> and have tested accordingly.
>
> Signed-off-by: Forest Bond
> ---
> drivers/input/touchscreen/usbtouchscreen.c | 36
>
> 1 files changed, 36 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/touchscreen/usbtouchscreen.c
> b/drivers/input/touchscreen/usbtouchscreen.c
> index e32709e..64b4b17 100644
> --- a/drivers/input/touchscreen/usbtouchscreen.c
> +++ b/drivers/input/touchscreen/usbtouchscreen.c
> @@ -304,6 +304,41 @@ static int e2i_read_data(struct usbtouch_usb *dev,
> unsigned char *pkt)
> #define EGALAX_PKT_TYPE_REPT 0x80
> #define EGALAX_PKT_TYPE_DIAG 0x0A
>
> +static int egalax_init(struct usbtouch_usb *usbtouch)
> +{
> + int ret, i;
> + unsigned char *buf;
> + struct usb_device *udev = interface_to_usbdev(usbtouch->interface);
> +
> + /* An eGalax diagnostic packet kicks the device into using the right
> + * protocol. We send a "check active" packet. The response will be
> + * read later and ignored.
> + */
> +
> + buf = kmalloc(3, GFP_KERNEL);
if (!buf)
return -ENOMEM;
> + buf[0] = EGALAX_PKT_TYPE_DIAG;
> + buf[1] = 1; /* length */
> + buf[2] = 'A'; /* command - check active */
> +
> + for (i = 0; i < 3; i++) {
> + ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
> + 0,
> + USB_DIR_OUT | USB_TYPE_VENDOR |
> USB_RECIP_DEVICE,
> + 0, 0, buf, 3,
> + USB_CTRL_SET_TIMEOUT);
> + if (ret >= 0) {
> + ret = 0;
> + break;
> + }
> + if (ret != -EPIPE)
> + break;
> + }
> +
> + kfree(buf);
> +
> + return ret;
> +}
signature.asc
Description: Digital signature
Re: [PATCH 3/3] usb: gadget: s3c-hsudc: Replace 0 with NULL for pointers
On Mon, Sep 03, 2012 at 05:00:44PM +0530, Sachin Kamat wrote: > Hi > > On 3 September 2012 16:37, ABRAHAM, KISHON VIJAY wrote: > > Hi, > > > > On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat > > wrote: > >> Silences the following type of sparse warnings: > >> warning: Using plain integer as NULL pointer > >> > >> Signed-off-by: Sachin Kamat > >> --- > >> drivers/usb/gadget/s3c-hsudc.c |8 > >> 1 files changed, 4 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/usb/gadget/s3c-hsudc.c > >> b/drivers/usb/gadget/s3c-hsudc.c > >> index 35cdc6a..d8e785d 100644 > >> --- a/drivers/usb/gadget/s3c-hsudc.c > >> +++ b/drivers/usb/gadget/s3c-hsudc.c > >> @@ -835,7 +835,7 @@ static struct usb_request > >> *s3c_hsudc_alloc_request(struct usb_ep *_ep, > >> > >> hsreq = kzalloc(sizeof(*hsreq), gfp_flags); > >> if (!hsreq) > >> - return 0; > >> + return NULL; > > > > shouldn't this be -ENOMEM? > > That should have been the obvious return value. However, I thought > probably it was made so with some reasoning and did not change it as I > am not familiar with this driver. it's just the way the API was designed. If we fail to allocate a usb_request, we must return NULL so function/gadget drivers can check if it was successful or not. Of course it could be changed into ERR_PTR(-ENOMEM) or something, but that's an API change... ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: otg: Move phy interface to separate file.
Hi, On Wed, Aug 29, 2012 at 12:17:01PM +0530, Venu Byravarasu wrote: > As otg.h is containing lots of phy interface related > stuff, moving all phy interface related stuff to new > file named phy.h > > Signed-off-by: Venu Byravarasu this doesn't apply to my "xceiv" branch. Please rebase there so I don't cause any issues to your patch ;-) -- balbi signature.asc Description: Digital signature
[PATCH RFC] USB: EHCI on imx53
Hi,
this is my first try on activating EHCI on imx53 (primarily via dt). However,
probe() still hangs on the first ehci_writel() l.189. I guess some
clock/enabling is still missing?
Sascha, do you already have EHCI running on imx53?
Any hint would be very much appreciated.
Thanks in advance,
Roland
---
arch/arm/boot/dts/imx53.dtsi |8
arch/arm/mach-imx/Kconfig |1 +
arch/arm/mach-imx/devices-imx53.h |4
arch/arm/mach-imx/imx53-dt.c |7 +++
drivers/usb/host/ehci-mxc.c | 12
5 files changed, 32 insertions(+)
--- linux-2.6.orig/arch/arm/boot/dts/imx53.dtsi
+++ linux-2.6/arch/arm/boot/dts/imx53.dtsi
@@ -135,6 +135,14 @@
};
};
+ ehci@53f8 {
+ compatible = "fsl,mxc-ehci";
+ interrupt-parent = <&tzic>;
+ interrupts = <14>;
+ reg = <0x53f8 0x4000>;
+ status = "disabled";
+ };
+
gpio1: gpio@53f84000 {
compatible = "fsl,imx53-gpio", "fsl,imx35-gpio";
reg = <0x53f84000 0x4000>;
--- linux-2.6.orig/arch/arm/mach-imx/Kconfig
+++ linux-2.6/arch/arm/mach-imx/Kconfig
@@ -799,6 +799,7 @@ config MACH_MX53_DIMM
select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
select IMX_HAVE_PLATFORM_SPI_IMX
select IMX_HAVE_PLATFORM_MXC_NAND
+ select IMX_HAVE_PLATFORM_MXC_EHCI
select LEDS_GPIO_REGISTER
help
Include support for DIMM MX53 platform. This includes specific
--- linux-2.6.orig/arch/arm/mach-imx/devices-imx53.h
+++ linux-2.6/arch/arm/mach-imx/devices-imx53.h
@@ -45,4 +45,8 @@ extern const struct imx_pata_imx_data im
#define imx53_add_pata_imx() \
imx_add_pata_imx(&imx53_pata_imx_data)
+extern const struct imx_mxc_ehci_data imx53_mxc_ehci_data;
+#define imx53_add_mxc_ehci(pdata) \
+ imx_add_mxc_ehci(&imx53_mxc_ehci_data, pdata)
+
extern struct platform_device *__init imx53_add_ahci_imx(void);
--- linux-2.6.orig/arch/arm/mach-imx/imx53-dt.c
+++ linux-2.6/arch/arm/mach-imx/imx53-dt.c
@@ -23,6 +23,12 @@
#include
#include
+#include
+
+static struct mxc_usbh_platform_data otg_pdata __initdata = {
+ .portsc = MXC_EHCI_MODE_SERIAL,
+};
+
/*
* Lookup table for attaching a specific name and platform_data pointer to
* devices as they get created by of_platform_populate(). Ideally this table
@@ -48,6 +54,7 @@ static const struct of_dev_auxdata imx53
OF_DEV_AUXDATA("fsl,imx53-i2c", MX53_I2C3_BASE_ADDR, "imx-i2c.2", NULL),
OF_DEV_AUXDATA("fsl,imx53-sdma", MX53_SDMA_BASE_ADDR, "imx35-sdma",
NULL),
OF_DEV_AUXDATA("fsl,imx53-wdt", MX53_WDOG1_BASE_ADDR, "imx2-wdt.0",
NULL),
+ OF_DEV_AUXDATA("fsl,mxc-ehci", MX53_OTG_BASE_ADDR, "mxc-ehci.0",
&otg_pdata),
{ /* sentinel */ }
};
--- linux-2.6.orig/drivers/usb/host/ehci-mxc.c
+++ linux-2.6/drivers/usb/host/ehci-mxc.c
@@ -18,6 +18,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -311,11 +313,21 @@ static void ehci_mxc_drv_shutdown(struct
MODULE_ALIAS("platform:mxc-ehci");
+#ifdef CONFIG_OF
+static const struct of_device_id mxc_ehci_dt_ids[] = {
+ { .compatible = "fsl,mxc-ehci" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, mxc_ehci_dt_ids);
+#endif
+
static struct platform_driver ehci_mxc_driver = {
.probe = ehci_mxc_drv_probe,
.remove = __exit_p(ehci_mxc_drv_remove),
.shutdown = ehci_mxc_drv_shutdown,
.driver = {
.name = "mxc-ehci",
+ .of_match_table = of_match_ptr(mxc_ehci_dt_ids),
},
};
--
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: EHCI on imx53
Hi Roland, On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote: > Hi, > > this is my first try on activating EHCI on imx53 (primarily via dt). However, > probe() still hangs on the first ehci_writel() l.189. I guess some > clock/enabling is still missing? > > Sascha, do you already have EHCI running on imx53? I'm sorry to say that you are sitting on a dead end. Please google for chipidea, Richard Zhao, Marc Kleine-Budde. They are regularly dropping large patch bombs on linux-usb. I have no idea how to merge the patches together to some working state. Maybe Marc can give you a pointer. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: EHCI on imx53
On 09/03/2012 04:37 PM, Sascha Hauer wrote: > Hi Roland, > > On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote: >> Hi, >> >> this is my first try on activating EHCI on imx53 (primarily via dt). However, >> probe() still hangs on the first ehci_writel() l.189. I guess some >> clock/enabling is still missing? >> >> Sascha, do you already have EHCI running on imx53? > > I'm sorry to say that you are sitting on a dead end. Please google for > chipidea, Richard Zhao, Marc Kleine-Budde. They are regularly dropping > large patch bombs on linux-usb. I have no idea how to merge the patches > together to some working state. Maybe Marc can give you a pointer. We've a running version of mx53 here, the patches are not ready for posting. However several other chipidea related patches are still under review. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[RFC PATCH V2 1/2] usb: usb port power off mechanism add "auto" option
This patch is to add "auto" option to attribute portX/control.
When echo "auto", the port's feature PORT_POWER would be clear
if the port's connect type was mark not-used(connectability and
visibility are both cleared) and with no device attached.
Signed-off-by: Lan Tianyu
---
This patchset is based on the following patchset
http://marc.info/?l=linux-usb&m=134517695007182&w=2
usb: make usb port a real device
usb: move children to struct usb_port
usb/acpi: Bind ACPI node to USB port, not usb_device.
usb/acpi: Store info on device removability.
xhci: Handle clear PORT_POWER feature.
usb/acpi: Use ACPI methods to power off ports.
usb: Fail a get config when the port is powered off.
usb : Add sysfs files to control port power.
v2: add "auto" option process in the hub_power_on()
---
drivers/usb/core/hub.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3def91e..07c62dd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -42,6 +42,7 @@
enum port_power_policy {
USB_PORT_POWER_ON = 0,
USB_PORT_POWER_OFF,
+ USB_PORT_POWER_AUTO,
};
struct usb_port {
@@ -101,6 +102,7 @@ struct usb_hub {
static const char on_string[] = "on";
static const char off_string[] = "off";
+static const char auto_string[] = "auto";
static const struct attribute_group *port_dev_group[];
static inline int hub_is_superspeed(struct usb_device *hdev)
@@ -842,6 +844,7 @@ static unsigned hub_power_on(struct usb_hub *hub, bool
do_delay)
unsigned delay;
u16 wHubCharacteristics =
le16_to_cpu(hub->descriptor->wHubCharacteristics);
+ struct usb_port *pport;
/* Enable power on each port. Some hubs have reserved values
* of LPSM (> 2) in their descriptors, even though they are
@@ -854,13 +857,18 @@ static unsigned hub_power_on(struct usb_hub *hub, bool
do_delay)
else
dev_dbg(hub->intfdev, "trying to enable port power on "
"non-switchable hub\n");
- for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++)
- if (hub->ports[port1 - 1]->port_power_policy
- == USB_PORT_POWER_ON)
- set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
- else
+ for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++) {
+ pport = hub->ports[port1 - 1];
+
+ if (pport->port_power_policy == USB_PORT_POWER_OFF ||
+ (pport->port_power_policy == USB_PORT_POWER_AUTO
+&& pport->connect_type == USB_PORT_NOT_USED
+&& !pport->child))
clear_port_feature(hub->hdev, port1,
- USB_PORT_FEAT_POWER);
+ USB_PORT_FEAT_POWER);
+ else
+ set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
+ }
/* Wait at least 100 msec for power to become stable */
delay = max(pgood_delay, (unsigned) 100);
@@ -4703,6 +4711,9 @@ static ssize_t show_port_power_control(struct device *dev,
case USB_PORT_POWER_OFF:
result = off_string;
break;
+ case USB_PORT_POWER_AUTO:
+ result = auto_string;
+ break;
default:
return -EINVAL;
}
@@ -4741,6 +4752,18 @@ static ssize_t store_port_power_control(struct device
*dev,
usb_autopm_put_interface(intf);
if (ret < 0)
return -EIO;
+ } else if (len == sizeof(auto_string) - 1
+ && strncmp(buf, auto_string, len) == 0) {
+ hub_port->port_power_policy = USB_PORT_POWER_AUTO;
+ if (hub_port->connect_type
+ == USB_PORT_NOT_USED && !hub_port->child) {
+ usb_autopm_get_interface(intf);
+ ret = clear_port_feature(hdev, port1,
+ USB_PORT_FEAT_POWER);
+ usb_autopm_put_interface(intf);
+ if (ret < 0)
+ return -EIO;
+ }
} else
return -EINVAL;
--
1.7.9.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
[RFC PATCH V2 2/2] USB: Set usb port's DevicerRemovable according acpi information in EHCI
ACPI provide "_PLD" and "_UPC" aml methods to describe usb port
visibility and connectability. This patch is to use those information
to set usb port's DeviceRemovable.
Signed-off-by: Lan Tianyu
---
v2: Set DeviceRemovable according acpi infomation in the hub_configure()
instead of calling get_hub_descriptor().
---
drivers/usb/core/hub.c | 22 ++
drivers/usb/core/usb.h |4
drivers/usb/host/ehci-hub.c |9 +
include/linux/usb.h |4
4 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 07c62dd..a411a36 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1566,6 +1566,25 @@ static int hub_configure(struct usb_hub *hub,
dev_err(hub->intfdev,
"couldn't create port%d device.\n", i + 1);
+ if (hub_is_superspeed(hdev)) {
+ for (i = 1; i <= hdev->maxchild; i++)
+ if (hub->ports[i - 1]->connect_type
+ == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+ hub->descriptor->u.hs.DeviceRemovable[i/8]
+ |= 1 << (i%8);
+ } else {
+ u16 port_removable = 0;
+
+ for (i = i; i <= hdev->maxchild; i++)
+ if (hub->ports[i - 1]->connect_type
+ == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+ port_removable |= 1 << i;
+
+ memset(&hub->descriptor->u.ss.DeviceRemovable,
+ (__force __u16) cpu_to_le16(port_removable),
+ sizeof(__u16));
+ }
+
hub_activate(hub, HUB_INIT);
return 0;
@@ -5260,6 +5279,9 @@ usb_get_hub_port_connect_type(struct usb_device *hdev,
int port1)
{
struct usb_hub *hub = hdev_to_hub(hdev);
+ if (!hub)
+ return USB_PORT_CONNECT_TYPE_UNKNOWN;
+
return hub->ports[port1 - 1]->connect_type;
}
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 1c528c1..1633f6e 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -169,10 +169,6 @@ extern void usb_notify_add_device(struct usb_device *udev);
extern void usb_notify_remove_device(struct usb_device *udev);
extern void usb_notify_add_bus(struct usb_bus *ubus);
extern void usb_notify_remove_bus(struct usb_bus *ubus);
-extern enum usb_port_connect_type
- usb_get_hub_port_connect_type(struct usb_device *hdev, int port1);
-extern void usb_set_hub_port_connect_type(struct usb_device *hdev, int port1,
- enum usb_port_connect_type type);
#ifdef CONFIG_ACPI
extern int usb_acpi_register(void);
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index c788022..5ad3a11 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -636,6 +636,7 @@ ehci_hub_descriptor (
struct usb_hub_descriptor *desc
) {
int ports = HCS_N_PORTS (ehci->hcs_params);
+ int i;
u16 temp;
desc->bDescriptorType = 0x29;
@@ -650,6 +651,14 @@ ehci_hub_descriptor (
memset(&desc->u.hs.DeviceRemovable[0], 0, temp);
memset(&desc->u.hs.DeviceRemovable[temp], 0xff, temp);
+ for (i = 1; i <= ports; i++) {
+ if (usb_get_hub_port_connect_type(
+ ehci_to_hcd(ehci)->self.root_hub, i)
+ == USB_PORT_CONNECT_TYPE_HARD_WIRED)
+ desc->u.hs.DeviceRemovable[i/8] |= 1 << (i%8);
+ }
+
+
temp = 0x0008; /* per-port overcurrent reporting */
if (HCS_PPC (ehci->hcs_params))
temp |= 0x0001; /* per-port power control */
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 07915a3..0928f2a 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -575,6 +575,10 @@ static inline struct usb_device
*interface_to_usbdev(struct usb_interface *intf)
return to_usb_device(intf->dev.parent);
}
+extern enum usb_port_connect_type
+ usb_get_hub_port_connect_type(struct usb_device *hdev, int port1);
+extern void usb_set_hub_port_connect_type(struct usb_device *hdev, int port1,
+ enum usb_port_connect_type type);
extern struct usb_device *usb_get_dev(struct usb_device *dev);
extern void usb_put_dev(struct usb_device *dev);
extern struct usb_device *usb_hub_find_child(struct usb_device *hdev,
--
1.7.9.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
Re: JMicron 20337 (152d:2338) and 3TB
On Sun, 2 Sep 2012, Matthew Hall wrote: > > > What about a quirk which gets the blocksize from the smaller commands and > > > combines with the device size from the larger command? > > > > It's not quite that simple. The trace showed that two different > > commands gave the right block size, and we don't know which one Windows > > believed. I suppose we could figure out the answer to that. > > > > It might work. But the only justification would be "That's the way > > Windows does it"... which might not be strong enough. Especially since > > different versions of Windows might do it in different ways. One thing I failed to mention before... The READ FORMAT CAPACITIES and READ CAPACITY(10) results in Alon's usbmon trace had an incorrect device size along with a correct block size. The responses to these commands contain the size as a number of blocks, limited to a 32-bit value. Thus they cannot handle more then about 4 billion blocks. If the block size is 512 bytes then 4 billion blocks is only 2 TB. But with a 4096-byte block size, the limit is 16 TB and so the size could have easily fit. Nevertheless, the responses sent by the JMicron had the size fields set to all ones. > How about a dummy read which only can work when you've discovered the size > correctly? You noticed one failed right that occurred due to the mismatch in > the block size. At some point it stops being worthwhile to try supporting devices which are simply too buggy. The devices sold by JMicron passed my personal threshold some years ago. 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 RFC] USB: EHCI on imx53
Hi Marc and Sascha, On 09/03/2012 04:49 PM, Marc Kleine-Budde wrote: >> On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote: >>> Hi, >>> >>> this is my first try on activating EHCI on imx53 (primarily via >>> dt). However, probe() still hangs on the first ehci_writel() >>> l.189. I guess some clock/enabling is still missing? >>> >>> Sascha, do you already have EHCI running on imx53? >> >> I'm sorry to say that you are sitting on a dead end. Please >> google for chipidea, Richard Zhao, Marc Kleine-Budde. They are >> regularly dropping large patch bombs on linux-usb. I have no idea >> how to merge the patches together to some working state. Maybe >> Marc can give you a pointer. > > We've a running version of mx53 here, the patches are not ready > for posting. Maybe I can already test sth. and give feedback? Or is it reasonable to use some patches you posted previously (the ones Sascha mentioned)? (Which one?) Thanks in advance, Roland -- 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: OMAP: USB: EHCI: usbhost suspend/resume
Only this part of the question about kernel 3.x is actual. In older kernel I have problems with clock domains and their dependencies. -- 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: EHCI on imx53
On 09/03/2012 05:39 PM, Roland Stigge wrote: > Hi Marc and Sascha, > > On 09/03/2012 04:49 PM, Marc Kleine-Budde wrote: >>> On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote: Hi, this is my first try on activating EHCI on imx53 (primarily via dt). However, probe() still hangs on the first ehci_writel() l.189. I guess some clock/enabling is still missing? Sascha, do you already have EHCI running on imx53? >>> >>> I'm sorry to say that you are sitting on a dead end. Please >>> google for chipidea, Richard Zhao, Marc Kleine-Budde. They are >>> regularly dropping large patch bombs on linux-usb. I have no idea >>> how to merge the patches together to some working state. Maybe >>> Marc can give you a pointer. >> >> We've a running version of mx53 here, the patches are not ready >> for posting. > > Maybe I can already test sth. and give feedback? > > Or is it reasonable to use some patches you posted previously (the > ones Sascha mentioned)? (Which one?) I think I can prepare something for you tomorrow. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [RFC] How to handle delays in isochronous transfers?
On Mon, 3 Sep 2012, Clemens Ladisch wrote: > Alan Stern wrote: > > How should the lower USB layers handle delays in transferring > > isochronous data? [...] when this happens the endpoint's queue > > drains completely. > > > > Clearly this will cause a glitch in the data stream. The question is: > > What should we do to recover and re-synchronize? > > The ALSA API promises that the samples in a stream run at a fixed clock, > i.e., samples are never delayed or accelerated. > > > We could pretend nothing happened and continue to handle URBs normally, > > scheduling each submission for the next available slot. But for an > > isochronous-OUT transfer, this would mean that all the future data > > values are delayed by some 40 ms relative to the earlier data. If > > another glitch occurs then the following data will be delayed by even > > more. For some applications this might not matter, but for others > > (real-time things like voice) it could be quite bad. Similar problems > > arise with IN transfers. > > This would not be acceptable; future samples must be scheduled for the > same frame for which they would have been scheduled without the delay. I suspected as much. It's good to have the suspicions confirmed. > > Alternatively, the host controller driver could fail the next 40 ms > > worth of isochronous URBs, so that the higher-level client catches up > > to where it should be. The failure could occur during submission, or > > the URBs could be accepted and then forced to complete immediately, > > with no data transferred. > > Both would be possible. At the moment, a submission failure would cause > the driver to stop the stream and report an error to the application. A submission failure is cleaner than an immediate completion, because we could then avoid making a whole series of doomed submissions (and using up a lot of stack space). On the other hand, it would be necessary to tell the client how many slots have to be skipped. Any idea how to do that? And of course, it would be necessary to change the clients to take this new information and new failure mode into account. > In this kind of situation (where it's known that multiple packets have > not been transferred), it would be somewhat preferrable to report the > error instead of ignoring it. That's a good idea. I can add a warning message to ehci-hcd. Should it trigger when any packets have been skipped, or only when the number of skipped packets is so large that an entire URB has to be rejected? > > What's the right thing to do? My feeling is that the behavior > > should be decided not by the host controller driver but rather by the > > higher-level client. > > Yeah, "schedule directly after the previous packet, or fail" and > "schedule for the next possible frame" might be useful. (But the > audio driver would always use the first option.) I'll use URB_ISO_ASAP to mean "the next possible slot". Leaving that flag turned off will mean "the slot after the previous packet". I can do this for ehci-hcd, ohci-hcd, and uhci-hcd. I don't know if xhci-hcd will be able to support this, however. 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: [RFC] How to handle delays in isochronous transfers?
On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern wrote: > Clemens and Laurent (and anyone else who's interested): > > How should the lower USB layers handle delays in transferring > isochronous data? I'm asking you because the most common usages of > isochronous transfers are for audio and video. > > Here's an example to illustrate what I mean. Typically an audio or > video driver will keep a queue of around 10 ms of data submitted to an > isochronous endpoint. I have seen reports from users where URB > completion interrupts were delayed by as much as 50 ms. In one case > the delay was caused by a bug in a wireless drivers that left > interrupts disabled; in another case the cause was unknown -- it might > have been a hardware problem. At any rate, when this happens the > endpoint's queue drains completely. > > Clearly this will cause a glitch in the data stream. The question is: > What should we do to recover and re-synchronize? > How about effectively increasing the queue length from 10ms to 50ms (max anticipated latency) ? -- 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 resend2] Input: usbtouchscreen - initialize eGalax devices
From: Forest Bond
Certain eGalax devices expose an interface with class HID and protocol
None. Some work with usbhid and some work with usbtouchscreen, but
there is no easy way to differentiate. Sending an eGalax diagnostic
packet seems to kick them all into using the right protocol for
usbtouchscreen, so we can continue to bind them all there (as opposed to
handing some off to usbhid).
This fixes a regression for devices that were claimed by (and worked
with) usbhid prior to commit 139ebe8dc80dd74cb2ac9f5603d18fbf5cff049f
("Input: usbtouchscreen - fix eGalax HID ignoring"), which made
usbtouchscreen claim them instead. With this patch they will still be
claimed by usbtouchscreen, but they will actually report events
usbtouchscreen can understand. Note that these devices will be limited
to the usbtouchscreen feature set so e.g. dual touch features are not
supported.
I have the distinct pleasure of needing to support devices of both types
and have tested accordingly.
Signed-off-by: Forest Bond
---
drivers/input/touchscreen/usbtouchscreen.c | 39
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c
b/drivers/input/touchscreen/usbtouchscreen.c
index e32709e..c5f4dc0 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -304,6 +304,44 @@ static int e2i_read_data(struct usbtouch_usb *dev,
unsigned char *pkt)
#define EGALAX_PKT_TYPE_REPT 0x80
#define EGALAX_PKT_TYPE_DIAG 0x0A
+static int egalax_init(struct usbtouch_usb *usbtouch)
+{
+ int ret, i;
+ unsigned char *buf;
+ struct usb_device *udev = interface_to_usbdev(usbtouch->interface);
+
+ /* An eGalax diagnostic packet kicks the device into using the right
+* protocol. We send a "check active" packet. The response will be
+* read later and ignored.
+*/
+
+ buf = kmalloc(3, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = EGALAX_PKT_TYPE_DIAG;
+ buf[1] = 1; /* length */
+ buf[2] = 'A'; /* command - check active */
+
+ for (i = 0; i < 3; i++) {
+ ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ 0,
+ USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ 0, 0, buf, 3,
+ USB_CTRL_SET_TIMEOUT);
+ if (ret >= 0) {
+ ret = 0;
+ break;
+ }
+ if (ret != -EPIPE)
+ break;
+ }
+
+ kfree(buf);
+
+ return ret;
+}
+
static int egalax_read_data(struct usbtouch_usb *dev, unsigned char *pkt)
{
if ((pkt[0] & EGALAX_PKT_TYPE_MASK) != EGALAX_PKT_TYPE_REPT)
@@ -1056,6 +1094,7 @@ static struct usbtouch_device_info usbtouch_dev_info[] = {
.process_pkt= usbtouch_process_multi,
.get_pkt_len= egalax_get_pkt_len,
.read_data = egalax_read_data,
+ .init = egalax_init,
},
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] net: usbnet: fix softirq storm on suspend
From: Bjørn Mork Date: Mon, 3 Sep 2012 10:26:18 +0200 > Suspending an open usbnet device results in constant > rescheduling of usbnet_bh. > > commit 65841fd5 "usbnet: handle remote wakeup asap" > refactored the usbnet_bh code to allow sharing the > urb allocate and submit code with usbnet_resume. In > this process, a test for, and immediate return on, > ENOLINK from rx_submit was unintentionally dropped. > > The rx queue will not grow if rx_submit fails, > making usbnet_bh reschedule itself. This results > in a softirq storm if the error is persistent. > rx_submit translates the usb_submit_urb error > EHOSTUNREACH into ENOLINK, so this is an expected > and persistent error for a suspended device. The > old code tested for this condition and avoided > rescheduling. Putting this test back. > > Cc: # v3.5 > Cc: Ming Lei > Cc: Oliver Neukum > Signed-off-by: Bjørn Mork Applied, thanks. -- 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 net-next] net: cx82310_eth: use common match macro
From: Bjørn Mork Date: Mon, 3 Sep 2012 11:20:31 +0200 > Signed-off-by: Bjørn Mork Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/2] net: sierra_net: make private symbols static
From: Bjørn Mork Date: Mon, 3 Sep 2012 11:20:32 +0200 > Signed-off-by: Bjørn Mork Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/2] net: sierra_net: rx_urb_size is constant
From: Bjørn Mork Date: Mon, 3 Sep 2012 11:20:33 +0200 > The rx_urb_size is set to the same value for every device > supported by this driver. No need to keep a per-device > data structure to do that. Replacing with a macro constant. > > This was the last device specific info, and removing it > allows us to delete the sierra_net_info_data struct. > > Signed-off-by: Bjørn Mork Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: PLAT_ORION fulfils USB_ARCH_HAS_EHCI
The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0 and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this. Reported-by: Sebastian Hesselbarth Signed-off-by: Andrew Lunn --- drivers/usb/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index a7773a3..723efcc 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -48,6 +48,7 @@ config USB_ARCH_HAS_EHCI default y if SPARC_LEON default y if ARCH_MMP default y if MACH_LOONGSON1 + default y if PLAT_ORION default PCI # some non-PCI HCDs implement xHCI -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: PLAT_ORION fulfils USB_ARCH_HAS_EHCI
Andrew Lunn wrote: >The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0 >and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this. > >Reported-by: Sebastian Hesselbarth >Signed-off-by: Andrew Lunn >--- > drivers/usb/Kconfig |1 + > 1 file changed, 1 insertion(+) > >diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig >index a7773a3..723efcc 100644 >--- a/drivers/usb/Kconfig >+++ b/drivers/usb/Kconfig >@@ -48,6 +48,7 @@ config USB_ARCH_HAS_EHCI > default y if SPARC_LEON > default y if ARCH_MMP > default y if MACH_LOONGSON1 >+ default y if PLAT_ORION PLAT_ORION_LEGACY? thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to handle delays in isochronous transfers?
Alan Stern wrote: > On Mon, 3 Sep 2012, Clemens Ladisch wrote: >> Alan Stern wrote: >>> Alternatively, the host controller driver could fail the next 40 ms >>> worth of isochronous URBs, so that the higher-level client catches up >>> to where it should be. The failure could occur during submission, or >>> the URBs could be accepted and then forced to complete immediately, >>> with no data transferred. >> >> Both would be possible. At the moment, a submission failure would cause >> the driver to stop the stream and report an error to the application. > > A submission failure is cleaner than an immediate completion, because > we could then avoid making a whole series of doomed submissions (and > using up a lot of stack space). On the other hand, it would be > necessary to tell the client how many slots have to be skipped. The audio driver wouldn't care. Logically, it starts a new stream. >> In this kind of situation (where it's known that multiple packets have >> not been transferred), it would be somewhat preferrable to report the >> error instead of ignoring it. > > That's a good idea. I can add a warning message to ehci-hcd. I meant report to the client as an error, instead of silently dropping packets. Regards, Clemens -- 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: [RFC] How to handle delays in isochronous transfers?
On Mon, 3 Sep 2012, Jassi Brar wrote: > On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern > wrote: > > Clemens and Laurent (and anyone else who's interested): > > > > How should the lower USB layers handle delays in transferring > > isochronous data? I'm asking you because the most common usages of > > isochronous transfers are for audio and video. > > > > Here's an example to illustrate what I mean. Typically an audio or > > video driver will keep a queue of around 10 ms of data submitted to an > > isochronous endpoint. I have seen reports from users where URB > > completion interrupts were delayed by as much as 50 ms. In one case > > the delay was caused by a bug in a wireless drivers that left > > interrupts disabled; in another case the cause was unknown -- it might > > have been a hardware problem. At any rate, when this happens the > > endpoint's queue drains completely. > > > > Clearly this will cause a glitch in the data stream. The question is: > > What should we do to recover and re-synchronize? > > > How about effectively increasing the queue length from 10ms to 50ms > (max anticipated latency) ? There are two problems with that approach. First, 50 ms isn't really the max anticipated latency; it's merely the largest that I've seen so far. (In fact, the max anticipated latency is probably < 10 ms; these 50-ms delays were definitely exceptional.) Second, people involved in real-time programming (such as audio or video) generally want to keep latency to a minimum. 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: [RFC] How to handle delays in isochronous transfers?
On Mon, 3 Sep 2012, Clemens Ladisch wrote: > Alan Stern wrote: > > On Mon, 3 Sep 2012, Clemens Ladisch wrote: > >> Alan Stern wrote: > >>> Alternatively, the host controller driver could fail the next 40 ms > >>> worth of isochronous URBs, so that the higher-level client catches up > >>> to where it should be. The failure could occur during submission, or > >>> the URBs could be accepted and then forced to complete immediately, > >>> with no data transferred. > >> > >> Both would be possible. At the moment, a submission failure would cause > >> the driver to stop the stream and report an error to the application. > > > > A submission failure is cleaner than an immediate completion, because > > we could then avoid making a whole series of doomed submissions (and > > using up a lot of stack space). On the other hand, it would be > > necessary to tell the client how many slots have to be skipped. > > The audio driver wouldn't care. Logically, it starts a new stream. Really? Why not just skip a few packets and carry on with the existing stream? Does the behavior vary (or need to vary) according to the stream's direction? Logically, the situation isn't very different from what happens when packets are lost in transit (except for the fact that outgoing packets can be lost without the host's knowledge). Isochronous makes no guarantees about packet delivery, and never retries. > >> In this kind of situation (where it's known that multiple packets have > >> not been transferred), it would be somewhat preferrable to report the > >> error instead of ignoring it. > > > > That's a good idea. I can add a warning message to ehci-hcd. > > I meant report to the client as an error, instead of silently dropping > packets. In fact this missing data is already reported. The status member of the usb_iso_packet_descriptor structure returns -EXDEV if a packet was submitted too late for its scheduled time slot. (The error-codes.txt documentation file says "partially completed", which isn't a very good description.) My reason for bringing this up is because I want to improve the way ehci-hcd handles such things. Right now it doesn't do a very good job; when faced with delays longer than the built-in "slop" setting (currently 10 ms) it completely loses track of what's happening. It thinks the late submissions are actually far too early (it's dealing with a hardware schedule arranged as a ring buffer with length 512 or 1024 ms) and never gets back on track. I've got a patch ready for testing that improves this behavior, but it fixes only part of the problem. Resynchronization afterward remains an issue. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] usb: ohci: Fix Kconfig dependency on USB_ISP1301
With "select USB_ISP1301 ...", it could happen that I2C isn't selected although USB_ISP1301 depends on it. Fixing with "depends on ..." and emulating the condition via "|| !()". Signed-off-by: Roland Stigge Acked-by: Alan Stern --- drivers/usb/host/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.orig/drivers/usb/host/Kconfig +++ linux-2.6/drivers/usb/host/Kconfig @@ -292,7 +292,7 @@ config USB_OHCI_HCD depends on USB && USB_ARCH_HAS_OHCI select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 select USB_OTG_UTILS if ARCH_OMAP - select USB_ISP1301 if ARCH_LPC32XX + depends on USB_ISP1301 || !ARCH_LPC32XX ---help--- The Open Host Controller Interface (OHCI) is a standard for accessing USB 1.1 host controller hardware. It does more in hardware than Intel's -- 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: loosing data on usb?
Dnia sobota, 1 września 2012 o 22:51:42 Alan Stern napisał(a): > On Sat, 1 Sep 2012, Marek Floriańczyk wrote: > > > It's possible that data is getting lost, but it's pretty unlikely. The > > > only way to get more detailed debugging information is to use a USB bus > > > analyzer. > > > > HI, > > > > You mean hardware device that is connected into the usb bus something > > like this: http://www.fte.com/products/FTS4USB.aspx > > Yes, that or something like it. For example: > http://www.totalphase.com/products/beagle_usb480 > > > Or do you mean some software that I can use on linux, if so could you > > please recommend any, all I can find is for windows :( > > No, not software. No Linux software will be able to display any more > information than usbmon. > > > > You could do more testing. For example, run the same program but > > > comment out the parts that talk to the device on bus 3. Or plug the > > > devices into each other's ports, or swap the serial numbers in the > > > program. > > > > I can send commands separately to each device, and then there is no > > problem. Changing serial numbers won't work, application has class > > usb-manager that during start creates objects MyUsb and each object is > > given device id vendor id and serial number, to connect to CKOZ gateway. > > You could change the order of which device you send the command to > first. HI, Debian testing, kernel 3.2.0-3 and results are the same. Order in which I call devices is important, first device I call always gives reply, second one almost never, no matter on what bus number they are. When I insert some delay between commands (500 ms) everything works fine - i got reply from both devices, always. Unfortunately I don't have usb tester, but maybe I will try to do test app on windows, so I will get some confirmation. regards Marek > > 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: loosing data on usb?
On Mon, 3 Sep 2012, Marek Floriańczyk wrote: > HI, > > Debian testing, kernel 3.2.0-3 and results are the same. Order in which I > call > devices is important, first device I call always gives reply, second one > almost > never, no matter on what bus number they are. When I insert some delay > between > commands (500 ms) everything works fine - i got reply from both devices, > always. > Unfortunately I don't have usb tester, but maybe I will try to do test app on > windows, so I will get some confirmation. This is puzzling. Since the devices are on different buses, they should be totally independent, right? Unless they can communicate over some other medium (not USB). Can you try running the program on a different computer, to help rule out USB hardware problems on the motherboard? 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: loosing data on usb?
Dnia poniedziałek, 3 września 2012 o 22:00:03 Alan Stern napisał(a): > On Mon, 3 Sep 2012, Marek Floriańczyk wrote: > > HI, > > > > Debian testing, kernel 3.2.0-3 and results are the same. Order in which I > > call devices is important, first device I call always gives reply, > > second one almost never, no matter on what bus number they are. When I > > insert some delay between commands (500 ms) everything works fine - i > > got reply from both devices, always. > > Unfortunately I don't have usb tester, but maybe I will try to do test > > app on windows, so I will get some confirmation. > > This is puzzling. Since the devices are on different buses, they > should be totally independent, right? Unless they can communicate over > some other medium (not USB). > > Can you try running the program on a different computer, to help rule > out USB hardware problems on the motherboard? I did this today, I installed new system on different machine to test new kernel, and they behave identically. But you know, devices are communicating with remote actuators by radio frequency, and remote actuators are sending status by radiograms. I was told that devices have some system to distinguish between commands that are directed to them or to other device, but there is always a chance that radiograms somehow interfere with each other. I can always write to manufacturer of this devices and ask for confirmation, and I probably will. regards. Marek > > 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: [RFC] How to handle delays in isochronous transfers?
Alan Stern wrote: > On Mon, 3 Sep 2012, Clemens Ladisch wrote: >> The audio driver wouldn't care. Logically, it starts a new stream. > > Really? Why not just skip a few packets and carry on with the existing > stream? > Logically, the situation isn't very different from what happens when > packets are lost in transit (except for the fact that outgoing packets > can be lost without the host's knowledge). A few lost packets do not affect the timing of completion interrupts/ callbacks. However, when the queuing is broken, the completions arrive in a way that makes the stream to appear to slow down, and then to speed up when the HCD is trying to resynchronize. Some jitter in the reported stream progress is acceptable (and USB audio already is infamous for that, due to the 1 ms frame granularity and the fact that URBs often span many frames). But when the timing errors become too big, synchronization with other real-time events gets lost. Where exactly the boundary between small errors to be ignored and big fatal errors lies is of course rather fuzzy. However, by selecting a particular queue length, drivers have control over this boundary. > Does the behavior vary (or need to vary) according to the stream's > direction? Oh well. There are no sample counters, so if any capture packet is dropped, we do not know how many samples are missing. (I've never heard of this happening in practice though.) > My reason for bringing this up is because I want to improve the way > ehci-hcd handles such things. Right now it doesn't do a very good job; > when faced with delays longer than the built-in "slop" setting > (currently 10 ms) it completely loses track of what's happening. It > thinks the late submissions are actually far too early (it's dealing > with a hardware schedule arranged as a ring buffer with length 512 or > 1024 ms) and never gets back on track. > > I've got a patch ready for testing that improves this behavior, but it > fixes only part of the problem. Resynchronization afterward remains an > issue. >From the audio driver's point of view, resynchronization by the HCD is not even necessary. Regards, Clemens -- 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: [RFC] How to handle delays in isochronous transfers?
On Mon, 3 Sep 2012, Clemens Ladisch wrote: > Alan Stern wrote: > > On Mon, 3 Sep 2012, Clemens Ladisch wrote: > >> The audio driver wouldn't care. Logically, it starts a new stream. > > > > Really? Why not just skip a few packets and carry on with the existing > > stream? > > Logically, the situation isn't very different from what happens when > > packets are lost in transit (except for the fact that outgoing packets > > can be lost without the host's knowledge). > > A few lost packets do not affect the timing of completion interrupts/ > callbacks. However, when the queuing is broken, the completions arrive > in a way that makes the stream to appear to slow down, and then to speed > up when the HCD is trying to resynchronize. ... > From the audio driver's point of view, resynchronization by the HCD is > not even necessary. There are two possibilities to consider when an URB containing several packets of data is submitted: 1. The slots for the first few packets have already expired, but the remaining packets will be transferred okay. 2. The slots for all the packets in the URB have expired. In case 1 there is data loss but the queuing remains intact. In case 2 the queuing is broken. It sounds like you're saying that case 1 submissions should succeed (and return -EXDEV status for the statuses of the missed packets), whereas case 2 submissions should fail outright (say with an -EXDEV error, which is currently not used for URB submission). Then resynchronization becomes the audio driver's problem entirely. Would that be okay? 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: surfstick K5006-Z in 3.6.0-rc4
Despite the patch
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1018, 0xff, 0xff,
0xff),
.driver_info = (kernel_ulong_t)&net_intf3_blacklist },
is included in option, it has no effect.
[ 1109.116127] usb 1-4: new high-speed USB device number 3 using ehci_hcd
[ 1109.251733] usb 1-4: New USB device found, idVendor=19d2, idProduct=1017
[ 1109.251750] usb 1-4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[ 1109.251764] usb 1-4: Product: ZTE LTE Technologies MSM
[ 1109.251777] usb 1-4: Manufacturer: ZTE,Incorporated
[ 1109.251788] usb 1-4: SerialNumber: MF821VVDFS02
[ 1109.298493] usbcore: registered new interface driver uas
[ 1109.305952] Initializing USB Mass Storage driver...
[ 1109.312239] scsi4 : usb-storage 1-4:1.0
[ 1109.312541] usbcore: registered new interface driver usb-storage
[ 1109.312547] USB Mass Storage support registered.
[ 1112.473337] usb 1-4: USB disconnect, device number 3
[ 1116.932128] usb 1-4: new high-speed USB device number 4 using ehci_hcd
[ 1117.067894] usb 1-4: New USB device found, idVendor=19d2, idProduct=1018
[ 1117.067908] usb 1-4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[ 1117.067918] usb 1-4: Product: ZTE LTE Technologies MSM
[ 1117.067926] usb 1-4: Manufacturer: ZTE,Incorporated
[ 1117.067934] usb 1-4: SerialNumber: MF821VVDFS02
[ 1117.073642] scsi5 : usb-storage 1-4:1.4
[ 1117.116156] usbcore: registered new interface driver cdc_wdm
[ 1117.125924] qmi_wwan 1-4:1.3: cdc-wdm0: USB WDM device
[ 1117.126454] qmi_wwan 1-4:1.3: wwan0: register 'qmi_wwan' at
usb-:00:1d.7-4, WWAN/QMI device, 46:91:ff:c8:e6:8e
[ 1117.126558] usbcore: registered new interface driver qmi_wwan
[ 1118.073723] scsi 5:0:0:0: CD-ROMVodafone USB SCSI CD-ROM 2.31
PQ: 0 ANSI: 0
[ 1118.074384] scsi 5:0:0:0: Attached scsi generic sg1 type 5
[ 1118.075607] scsi 5:0:0:1: Direct-Access Vodafone Storage 2.31
PQ: 0 ANSI: 0
[ 1118.077038] sd 5:0:0:1: Attached scsi generic sg2 type 0
[ 1118.083514] sd 5:0:0:1: [sdb] Attached SCSI removable disk
[ 1118.100971] sr0: scsi-1 drive
[ 1118.100980] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 1118.101388] sr 5:0:0:0: Attached scsi CD-ROM sr0
I don't have the module "option" blacklisted.
All other devices I have (two from huawei, two from zte ) with the combination
option/qmi still work.
echo-ing to new_id works too.
Thomas
--
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: [RFC] How to handle delays in isochronous transfers?
> In such a situation, the delay is much bigger than the device's buffer, > so just sending more samples afterwards will not help. > It is ISO transfer, if the delay is too much, and the buffer at device side is empty, it is normal the screen is stopped like we watch movie on Internet (buffering). So if the delay is too much, I don't think there is a way can deal with it as host does not send any data to device. > Furthermore, if packets are lost, frequency feedback becomes impossible > because the device doesn't know how many samples were lost. Where the packets are lost? If the packets are lost at class driver/usb driver, class driver will know it and should take the responsible to re-send it. If the packets are lost on the USB bus (during the transfer), as it is ISO transfer, then the data should be lost, and host doesn't know the data is lost, how can it re-sends the packet? > > > Regards, > Clemens > -- 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: [RFC] How to handle delays in isochronous transfers?
[CC'ing an USB audio heavyweight - Daniel Mack] On Tue, Sep 4, 2012 at 12:39 AM, Alan Stern wrote: > On Mon, 3 Sep 2012, Jassi Brar wrote: > >> On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern >> wrote: >> > Clemens and Laurent (and anyone else who's interested): >> > >> > How should the lower USB layers handle delays in transferring >> > isochronous data? I'm asking you because the most common usages of >> > isochronous transfers are for audio and video. >> > >> > Here's an example to illustrate what I mean. Typically an audio or >> > video driver will keep a queue of around 10 ms of data submitted to an >> > isochronous endpoint. I have seen reports from users where URB >> > completion interrupts were delayed by as much as 50 ms. In one case >> > the delay was caused by a bug in a wireless drivers that left >> > interrupts disabled; in another case the cause was unknown -- it might >> > have been a hardware problem. At any rate, when this happens the >> > endpoint's queue drains completely. >> > >> > Clearly this will cause a glitch in the data stream. The question is: >> > What should we do to recover and re-synchronize? >> > >> How about effectively increasing the queue length from 10ms to 50ms >> (max anticipated latency) ? > > There are two problems with that approach. First, 50 ms isn't really > the max anticipated latency; it's merely the largest that I've seen so > far. (In fact, the max anticipated latency is probably < 10 ms; these > 50-ms delays were definitely exceptional.) > It doesn't have to be hardcoded - maybe USB audio/video code could get the hint via some module parameter? > Second, people involved in real-time programming (such as audio or > video) generally want to keep latency to a minimum. > If we progress the h/w pointer of ALSA ring buffer at URB completion (and not at URB submission), this shouldn't affect the latency. And IIRC, USB isn't anyway recommended for real-time usage. 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
Re: [PATCH net] net: usbnet: fix softirq storm on suspend
On Mon, Sep 3, 2012 at 4:26 PM, Bjørn Mork wrote: > Suspending an open usbnet device results in constant > rescheduling of usbnet_bh. > > commit 65841fd5 "usbnet: handle remote wakeup asap" > refactored the usbnet_bh code to allow sharing the > urb allocate and submit code with usbnet_resume. In > this process, a test for, and immediate return on, > ENOLINK from rx_submit was unintentionally dropped. > > The rx queue will not grow if rx_submit fails, > making usbnet_bh reschedule itself. This results > in a softirq storm if the error is persistent. > rx_submit translates the usb_submit_urb error > EHOSTUNREACH into ENOLINK, so this is an expected > and persistent error for a suspended device. The > old code tested for this condition and avoided > rescheduling. Putting this test back. > > Cc: # v3.5 > Cc: Ming Lei > Cc: Oliver Neukum > Signed-off-by: Bjørn Mork > --- > Sorry for not noticing this before, but commit 65841fd5 > makes usbnet autosuspend completely unusable. The device > is suspended fine, but burning one CPU core at full load > uses a tiny bit more power making the power saving > negative... I am wondering how you can reproduce the issue. usbnet_terminate_urbs is called inside usbnet_suspend to consume all URBs and SKBs, and rx_alloc_submit can't be called during the period because of !netif_device_present(). Once usbnet_terminate_urbs and netif_device_attach() are completed, who will schedule tasklet to trigger rx_alloc_submit? > > I hope this can go into 3.6 and 3.5-stable ASAP. It is > a hard to notice regression, but all the same a serious > one. 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
[PATCH] usb: phy: add R-Car R8A7779 USB phy driver.
This patch adds Renesas R-Car USB phy driver.
It supports R8A7779 chip at this point.
Signed-off-by: Kuninori Morimoto
---
drivers/usb/phy/Kconfig| 11
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/rcar-phy.c | 137
3 files changed, 149 insertions(+)
create mode 100644 drivers/usb/phy/rcar-phy.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 2838adb..f55b6f6 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -23,3 +23,14 @@ config MV_U3D_PHY
help
Enable this to support Marvell USB 3.0 phy controller for Marvell
SoC.
+
+config USB_RCAR_PHY
+ tristate "Renesas R-Car USB phy support"
+ depends on (USB || USB_GADGET) && ARCH_R8A7779
+ help
+ Say Y here to add support for the Renesas R-Car USB phy driver.
+ This chip is typically used as USB phy for USB host, gadget.
+ This driver supports: R8A7779
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-phy.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index cf38f08..9af83f0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -6,3 +6,4 @@ ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
+obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c
new file mode 100644
index 000..deec078
--- /dev/null
+++ b/drivers/usb/phy/rcar-phy.c
@@ -0,0 +1,137 @@
+/*
+ * Renesas R-Car USB phy driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+/* USBH common register */
+#define USBPCTRL0 0x0800
+#define USBPCTRL1 0x0804
+#define USBST 0x0808
+#define USBEH0 0x080C
+#define USBOH0 0x081C
+#define USBCTL00x0858
+#define EIIBC1 0x0094
+#define EIIBC2 0x009C
+
+#ifdef CONFIG_ARCH_SUPPORTS_BIG_ENDIAN
+# define PHY_ENDIAN "BIG"
+# define PHY_NO_SWAP 0x0003
+#else
+# define PHY_ENDIAN "LITTLE"
+# define PHY_NO_SWAP 0x
+#endif
+
+/*
+ * USB initial/install operation.
+ *
+ * This function setup USB phy.
+ * The used value and setting order came from
+ * [USB :: Initial setting] on datasheet.
+ */
+static int rcar_phy_probe(struct platform_device *pdev)
+{
+ struct resource *res0, *res1;
+ void __iomem *reg0, *reg1;
+ int i, ret = 0;
+ u32 val;
+
+ res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res0 || !res1) {
+ dev_err(&pdev->dev, "Not enough platform resources\n");
+ return -ENODEV;
+ }
+
+ reg0 = ioremap_nocache(res0->start, resource_size(res0));
+ reg1 = ioremap_nocache(res1->start, resource_size(res1));
+ if (!reg0 || !reg1) {
+ dev_err(&pdev->dev, "ioremap error.\n");
+ ret = -ENOMEM;
+ goto end;
+ }
+
+ /**
+* USB phy start-up
+**/
+
+ /* (1) USB-PHY standby release */
+ iowrite32(0x0001, (reg0 + USBPCTRL1));
+
+ /* (2) start USB-PHY internal PLL */
+ iowrite32(0x0003, (reg0 + USBPCTRL1));
+
+ /* (3) USB module status check */
+ for (i = 0; i < 1024; i++) {
+ udelay(10);
+ val = ioread32(reg0 + USBST);
+ if (0xc000 == val)
+ goto usb_module_is_working;
+ }
+ dev_err(&pdev->dev, "USB module not ready\n");
+ ret = -EIO;
+ goto end;
+
+usb_module_is_working:
+ /* (4) USB-PHY reset clear */
+ iowrite32(0x0007, (reg0 + USBPCTRL1));
+
+ /* set platform specific port settings */
+ iowrite32(0x, (reg0 + USBPCTRL0));
+
+ /**
+* EHCI IP Internal Buffer Setting
+**/
+
+ /* (1) EHCI IP internal buffer setting */
+ iowrite32(0x00ff0040, (reg0 + EIIBC1));
+ iowrite32(0x00ff0040, (reg1 + EIIBC1));
+
+ /* (2) EHCI IP internal buffer enable */
+ iowrite32(0x0001, (reg0 + EIIBC2));
+ iowrite32(0x0001, (reg1 + EIIBC2));
+
+ /**
+* Bus alignment settings
+**/
+
+ /* (1) EHCI bus alignment */
+ iowrite32(PHY_NO_SWAP, (reg0 + USBEH0));
+
+ /* (1) OHCI bus alignment */
+ iowri
