Re: [alsa-devel] Buffer size for ALSA USB PCM audio
On Mon, Aug 26, 2013 at 7:37 PM, Alan Stern st...@rowland.harvard.edu wrote: Clemens and everyone else: Not having heard any responses to the patch posted last Wednesday, I have updated and completed it. The version below is ready for testing. Please let me know what you find. It is not very different from the previous version. I got rid of the nrpacks module parameter and figured out how to pass the frames/period and periods/buffer values to data_ep_set_params(). (Maybe this isn't the best way to do it, but it works.) I also fixed up the calculation that limits URBs to a sync interval. Of greater interest, I decided to limit each URB to 6 ms and the total queue to 18 ms, thereby encouraging the driver to use three URBs rather than two. (These values could be increased to 8 and 24, respectively.) This helps to reduce the effects of an underrun, as follows: With only two URBs, following an underrun the driver would submit URB1 and URB2. Because of the delay, it can easily happen that the last packet of URB1 comes before the isochronous scheduling threshold. The URB gets scheduled, but the hardware never sees it. Consequently there is no completion interrupt until URB2 finishes, at which point the queue is empty, causing a secondary underrun. I actually saw this happen several times during testing. James, this patch should be tested along with Clemens's original maxpacket is too large patch and my EHCI accepts late iso URBs patches. It should allow you to go down to ridiculously low parameter values, provided only that the total latency is higher than ~1.2 ms. For example, at 48 KHz this patch should work okay with 8 frames/period and 8 periods/buffer. Of course, larger values will provide greater resilience against underruns. This does not help at all with running jackd at lower latencies. With this patch, I get xruns at 128 frames/period or less with jackd (accompanied by iso underrun messages), whereas with vanilla 3.10.9 (which now has both yours and Clemen's patches applied), performance is extremely good (64 frames per period possible). James -- 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 V3 net-next 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
Hi guys!! :) First of all - I would like to thank both of you for your interest and time in my patches. I agree with Joe's point of view, completely. The Coding style document tries to leverage on the developer's good sense, even when defining some rules. Apart from that - checkpatch.po informed me about those very long lines, but I decided to leave them as they are due to the fact that they would look even more horrible than they look now. My braille display is 80-chars long (at least, the one I use normally), so I understand very well the problem of not passing that limit. Even so, the coding style says you might do so if you think the code is more readable this way, and that's why. My git usage is very bad as you may have observed (and I'm working on improving myself of course), but this was something I took into consideration. I remember when this cameto discussion: http://lkml.org/lkml/2009/12/17/229 still I know perfectly that one of the line you're blaming is indeed 139 characters. I understand and appreciate the fact that we _shouldn't_ take as reference worst cases (but only bbetter cases) to improve our practice life, but in various drivers you can find examples like those. Is this still a problem? I will re-work the code and send the patch again as soon as I can. thank you again! -- 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 v15 00/13] Add tested id switch and vbus connect detect support for Chipidea
Dear Peter, On 08/27/2013 04:51 AM, Peter Chen wrote: On Mon, Aug 26, 2013 at 06:24:48PM +0200, Hector Palacios wrote: Dear Peter, On 08/12/2013 03:22 AM, Peter Chen wrote: This patchset adds tested otg id switch function and vbus connect and disconnect detection for chipidea driver. And fix kinds of bugs found at chipidea drivers after enabling id and vbus detection. This patch are fully tested at imx6 sabresd and imx28evk platform by me. Besides, marek tested it on two STMP3780-based boards (not yet mainline) and two MX28-based boards. My chipidea repo: https://github.com/hzpeterchen/linux-usb.git Changes for v15: - Mark otgsc API as static line, and move them to otg.h [4/13] - Remove some redundant comments [6/13] - Fix some typos [8/13] - Retire flag CI_HDRC_PULLUP_ON_VBUS [12/13] [13/13] Patches 6 and 12 in this series seem to be incomplete or malformed. Please check. Would you post what's the problem for them or what's problem at your system after using them? I'm sorry, I thought it was evident. Patches 6 and 12 were posted incomplete. See how they end: http://permalink.gmane.org/gmane.linux.usb.general/92231 http://permalink.gmane.org/gmane.linux.usb.general/92237 In patch 12 the modified file include/linux/usb/chipidea.h does not even appear. Something happened during the generation or posting of these patches. Best regards, -- Hector Palacios -- 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: [alsa-devel] Buffer size for ALSA USB PCM audio
Alan Stern wrote: All the difficulty arises from the fact that we don't know beforehand how many URBs will constitute an ALSA period since for playback endpoints, the URB sizes can vary. [...] the number of URBs per period is fixed, and the number of packets in each URB is adjusted during playback so that all the URBs end up having roughly the same number of frames. [...] The parameter calculation now ends up being the same for both recording and playback endpoints. This may seem odd, but it follows from the reasoning above. There is no reasoning about capture endpoints. The driver cannot control how many samples actually end up in a capture packet, so it is possible that URBs end up being one USB frame longer than a period, in which case the ALSA period interrupts will accumulate delays of up to one period, or that URBs end up being one USB frame shorter than a period, in which case the ALSA period interrupt will be delayed to the end of the _next_ URB. The current algorithm uses very short capture URBs to ensure that _some_ URB is completed as soon as possible after a period ends. Your patch makes things worse for running jackd at lower latencies because playback and capture period interrupts are expected to be more or less synchronous (jackd waits for both interrupts before acting on one period). With only two periods per buffer and the capture period interrupt randomly delayed by up to one period, the time available for processing one period is reduced to zero. I'd suggest to keep the old calculation for capture URBs. It would make sense to use longer capture URBs only if the period size is relatively large. Note: for capturing, the number of URBs has no effect on latency and just reduces the risk of overruns, so it is desirable to make the queue as long as possible (for a given URB length). Not having heard any responses to the patch posted last Wednesday, Sorry, my #patches / free_time quotient is rather large. 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: [alsa-devel] Buffer size for ALSA USB PCM audio
On 27.8.2013 09:19, Clemens Ladisch wrote: The driver cannot control how many samples actually end up in a capture packet,... Does this reasoning apply to asynchronous playback too? I understand the driver has some control, but has to satisfy the endpoint feedback requests. Sorry if this is cluelessly offtopic :-) Regards, Pavel. -- 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 v15 00/13] Add tested id switch and vbus connect detect support for Chipidea
Hector Palacios hector.palac...@digi.com writes: Dear Peter, On 08/27/2013 04:51 AM, Peter Chen wrote: On Mon, Aug 26, 2013 at 06:24:48PM +0200, Hector Palacios wrote: Dear Peter, On 08/12/2013 03:22 AM, Peter Chen wrote: This patchset adds tested otg id switch function and vbus connect and disconnect detection for chipidea driver. And fix kinds of bugs found at chipidea drivers after enabling id and vbus detection. This patch are fully tested at imx6 sabresd and imx28evk platform by me. Besides, marek tested it on two STMP3780-based boards (not yet mainline) and two MX28-based boards. My chipidea repo: https://github.com/hzpeterchen/linux-usb.git Changes for v15: - Mark otgsc API as static line, and move them to otg.h [4/13] - Remove some redundant comments [6/13] - Fix some typos [8/13] - Retire flag CI_HDRC_PULLUP_ON_VBUS [12/13] [13/13] Patches 6 and 12 in this series seem to be incomplete or malformed. Please check. Would you post what's the problem for them or what's problem at your system after using them? I'm sorry, I thought it was evident. Patches 6 and 12 were posted incomplete. See how they end: http://permalink.gmane.org/gmane.linux.usb.general/92231 http://permalink.gmane.org/gmane.linux.usb.general/92237 In patch 12 the modified file include/linux/usb/chipidea.h does not even appear. Something happened during the generation or posting of these patches. Or something's wrong with gmane. http://www.spinics.net/lists/linux-usb/msg91695.html -- 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/4] usb: r8a66597-hcd: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/host/r8a66597-hcd.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index a6fd8f5..90a 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -2393,7 +2393,7 @@ static const struct dev_pm_ops r8a66597_dev_pm_ops = {
static int r8a66597_remove(struct platform_device *pdev)
{
- struct r8a66597 *r8a66597 = dev_get_drvdata(pdev-dev);
+ struct r8a66597 *r8a66597 = platform_get_drvdata(pdev);
struct usb_hcd *hcd = r8a66597_to_hcd(r8a66597);
del_timer_sync(r8a66597-rh_timer);
@@ -2466,7 +2466,7 @@ static int r8a66597_probe(struct platform_device *pdev)
}
r8a66597 = hcd_to_r8a66597(hcd);
memset(r8a66597, 0, sizeof(struct r8a66597));
- dev_set_drvdata(pdev-dev, r8a66597);
+ platform_set_drvdata(pdev, r8a66597);
r8a66597-pdata = pdev-dev.platform_data;
r8a66597-irq_sense_low = irq_trigger == IRQF_TRIGGER_LOW;
--
1.7.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: [alsa-devel] Buffer size for ALSA USB PCM audio
Pavel Hofman wrote: On 27.8.2013 09:19, Clemens Ladisch wrote: The driver cannot control how many samples actually end up in a capture packet,... Does this reasoning apply to asynchronous playback too? No. I understand the driver has some control, but has to satisfy the endpoint feedback requests. When the driver wants to submit a playback URB, it knows how many samples it is copying into the packets. (There is a delay between the device reporting its desired rate and the driver actually using it.) 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
[PATCH 3/4] usb: phy-tegra-usb: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/phy/phy-tegra-usb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index cec0855..68bc93f 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -859,7 +859,7 @@ static int tegra_usb_phy_probe(struct platform_device *pdev)
tegra_phy-u_phy.shutdown = tegra_usb_phy_close;
tegra_phy-u_phy.set_suspend = tegra_usb_phy_suspend;
- dev_set_drvdata(pdev-dev, tegra_phy);
+ platform_set_drvdata(pdev, tegra_phy);
return 0;
}
--
1.7.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 v15 00/13] Add tested id switch and vbus connect detect support for Chipidea
On 08/27/2013 10:09 AM, Alexander Shishkin wrote: Hector Palacios hector.palac...@digi.com writes: Dear Peter, On 08/27/2013 04:51 AM, Peter Chen wrote: On Mon, Aug 26, 2013 at 06:24:48PM +0200, Hector Palacios wrote: Dear Peter, On 08/12/2013 03:22 AM, Peter Chen wrote: This patchset adds tested otg id switch function and vbus connect and disconnect detection for chipidea driver. And fix kinds of bugs found at chipidea drivers after enabling id and vbus detection. This patch are fully tested at imx6 sabresd and imx28evk platform by me. Besides, marek tested it on two STMP3780-based boards (not yet mainline) and two MX28-based boards. My chipidea repo: https://github.com/hzpeterchen/linux-usb.git Changes for v15: - Mark otgsc API as static line, and move them to otg.h [4/13] - Remove some redundant comments [6/13] - Fix some typos [8/13] - Retire flag CI_HDRC_PULLUP_ON_VBUS [12/13] [13/13] Patches 6 and 12 in this series seem to be incomplete or malformed. Please check. Would you post what's the problem for them or what's problem at your system after using them? I'm sorry, I thought it was evident. Patches 6 and 12 were posted incomplete. See how they end: http://permalink.gmane.org/gmane.linux.usb.general/92231 http://permalink.gmane.org/gmane.linux.usb.general/92237 In patch 12 the modified file include/linux/usb/chipidea.h does not even appear. Something happened during the generation or posting of these patches. Or something's wrong with gmane. http://www.spinics.net/lists/linux-usb/msg91695.html Oops. My fault, then. Sorry about that. Best regards, -- Hector Palacios -- 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 0/4] usb: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Libo Chen (4):
usb: fotg210-udc: use platform_{get,set}_drvdata()
usb: r8a66597-hcd: use platform_{get,set}_drvdata()
usb: phy-tegra-usb: use platform_{get,set}_drvdata()
usb: renesas_usbhs: use platform_{get,set}_drvdata()
drivers/usb/gadget/fotg210-udc.c |4 ++--
drivers/usb/host/r8a66597-hcd.c|4 ++--
drivers/usb/phy/phy-tegra-usb.c|2 +-
drivers/usb/renesas_usbhs/common.c |2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] usb: renesas_usbhs: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/renesas_usbhs/common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index cfd2050..b097aa3 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -499,7 +499,7 @@ static int usbhs_probe(struct platform_device *pdev)
goto probe_end_fifo_exit;
/* dev_set_drvdata should be called after usbhs_mod_init */
- dev_set_drvdata(pdev-dev, priv);
+ platform_set_drvdata(pdev, priv);
/*
* deviece reset here because
--
1.7.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 1/4] usb: fotg210-udc: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/gadget/fotg210-udc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/fotg210-udc.c b/drivers/usb/gadget/fotg210-udc.c
index 10cd18d..32db2ee 100644
--- a/drivers/usb/gadget/fotg210-udc.c
+++ b/drivers/usb/gadget/fotg210-udc.c
@@ -1076,7 +1076,7 @@ static struct usb_gadget_ops fotg210_gadget_ops = {
static int fotg210_udc_remove(struct platform_device *pdev)
{
- struct fotg210_udc *fotg210 = dev_get_drvdata(pdev-dev);
+ struct fotg210_udc *fotg210 = platform_get_drvdata(pdev);
usb_del_gadget_udc(fotg210-gadget);
iounmap(fotg210-reg);
@@ -1134,7 +1134,7 @@ static int fotg210_udc_probe(struct platform_device *pdev)
spin_lock_init(fotg210-lock);
- dev_set_drvdata(pdev-dev, fotg210);
+ platform_set_drvdata(pdev, fotg210);
fotg210-gadget.ops = fotg210_gadget_ops;
--
1.7.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 v2 4/5] usb: chipidea: Fix memleak for ci-hw_bank.regmap when driver removal
It needs to free ci-hw_bank.regmap explicitly since it is not managed resource. Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/chipidea/core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 9462640..23763dc 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -605,6 +605,7 @@ static int ci_hdrc_remove(struct platform_device *pdev) dbg_remove_files(ci); free_irq(ci-irq, ci); ci_role_destroy(ci); + kfree(ci-hw_bank.regmap); return 0; } -- 1.7.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 v2 0/5] Chipidea Misc patchset
Changed for v2: - Fixed the build error for patch 5/5 Below are un-queued chipidea patches, some of them were reviewed. Peter Chen (5): usb: host: delete chipidea dependency usb: chipidea: udc: Consolidate the calling of ci-driver-disconnect usb: chipidea: udc: fix the oops when plugs in usb cable after rmmod gadget usb: chipidea: Fix memleak for ci-hw_bank.regmap when driver removal usb: chipidea: move more platform related things to ci_get_platdata drivers/usb/chipidea/core.c | 20 ++-- drivers/usb/chipidea/udc.c | 12 drivers/usb/host/Kconfig|4 ++-- 3 files changed, 20 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] usb: chipidea: move more platform related things to ci_get_platdata
Like vbus, the dr_mode and phy_mode are also got from glue layer's
platform data or device node.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/core.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 23763dc..c47a6b4 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -381,6 +381,15 @@ static int ci_get_platdata(struct device *dev,
return PTR_ERR(platdata-reg_vbus);
}
+ if (!platdata-phy_mode)
+ platdata-phy_mode = of_usb_get_phy_mode(dev-of_node);
+
+ if (!platdata-dr_mode)
+ platdata-dr_mode = of_usb_get_dr_mode(dev-of_node);
+
+ if (platdata-dr_mode == USB_DR_MODE_UNKNOWN)
+ platdata-dr_mode = USB_DR_MODE_OTG;
+
return 0;
}
@@ -473,7 +482,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
void __iomem*base;
int ret;
enum usb_dr_mode dr_mode;
- struct device_node *of_node = dev-of_node ?: dev-parent-of_node;
if (!dev-platform_data) {
dev_err(dev, platform data missing\n);
@@ -514,17 +522,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci_get_otg_capable(ci);
- if (!ci-platdata-phy_mode)
- ci-platdata-phy_mode = of_usb_get_phy_mode(of_node);
-
hw_phymode_configure(ci);
- if (!ci-platdata-dr_mode)
- ci-platdata-dr_mode = of_usb_get_dr_mode(of_node);
-
- if (ci-platdata-dr_mode == USB_DR_MODE_UNKNOWN)
- ci-platdata-dr_mode = USB_DR_MODE_OTG;
-
dr_mode = ci-platdata-dr_mode;
/* initialize role(s) before the interrupt is requested */
if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
--
1.7.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 v2 3/5] usb: chipidea: udc: fix the oops when plugs in usb cable after rmmod gadget
When we rmmod gadget, the ci-driver needs to be cleared. Otherwise, when we plug in usb cable again, the driver will consider gadget is there, and go to enumeration procedure, but in fact, it was removed. ci_hdrc ci_hdrc.0: Connected to host Unable to handle kernel paging request at virtual address 7f02a42c pgd = 80004000 [7f02a42c] *pgd=3f13d811, *pte=, *ppte= Internal error: Oops: 7 [#1] SMP ARM Modules linked in: usb_f_acm u_serial libcomposite configfs [last unloaded: g_serial] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0+ #42 task: 807dba88 ti: 807d task.ti: 807d PC is at udc_irq+0x8fc/0xea4 LR is at l2x0_cache_sync+0x5c/0x6c pc : [803de7f4]lr : [8001d0f0]psr: 2193 sp : 807d1d98 ip : 807d1d80 fp : 807d1df4 r10: af809900 r9 : 808184d4 r8 : 00080001 r7 : 00082001 r6 : afb711f8 r5 : afb71010 r4 : ffea r3 : 7f02a41c r2 : afb71010 r1 : 807d1dc0 r0 : afb71068 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 3f01804a DAC: 0017 Process swapper/0 (pid: 0, stack limit = 0x807d0238) Stack: (0x807d1d98 to 0x807d2000) 1d80: afb71014 1da0: 40f6 0001 7530 afb71010 001dcd65 1dc0: 01000680 0040 807d1e2c afb71010 004e 004b 1de0: 808184d4 af809900 807d1e0c 807d1df8 803dbc24 803ddf04 afba75c0 004e 1e00: 807d1e44 807d1e10 8007a19c 803dbb9c 8108e7e0 8108e7e0 9ceddce0 af809900 1e20: 004e 807d 004b 0010 807d1e5c 807d1e48 1e40: 8007a334 8007a154 af809900 004e 807d1e74 807d1e60 8007d3b4 8007a2f0 1e60: 004b 807cce3c 807d1e8c 807d1e78 80079b08 8007d300 0180 807d8ba0 1e80: 807d1eb4 807d1e90 8000eef4 80079aec f400010c 807d8ce4 807d1ed8 1ea0: f4000100 96d5c75d 807d1ed4 807d1eb8 80008600 8000eeac 8042699c 6013 1ec0: 807d1f0c 807d1f54 807d1ed8 8000e180 800085dc 807d1f20 0046 1ee0: 9cedd275 0010 8108f080 807de294 0001 807de248 96d5c75d 0010 1f00: 807d1f54 807d1f20 8005ff54 8042699c 6013 1f20: 9cedd275 0010 0005 8108f080 8108f080 0001 807de248 8086bd00 1f40: 807d 0001 807d1f7c 807d1f58 80426af0 80426950 807d 1f60: 808184c0 808184c0 807d8954 805b886c 807d1f8c 807d1f80 8000f294 80426a44 1f80: 807d1fac 807d1f90 8005f110 8000f288 807d1fac 807d8908 805b4748 807dc86c 1fa0: 807d1fbc 807d1fb0 805aa58c 8005f068 807d1ff4 807d1fc0 8077c860 805aa530 1fc0: 8077c330 807bef88 10c53c7d 1fe0: 807d88d0 807bef84 807d1ff8 10008074 8077c594 Backtrace: [803ddef8] (udc_irq+0x0/0xea4) from [803dbc24] (ci_irq+0x94/0x14c) [803dbb90] (ci_irq+0x0/0x14c) from [8007a19c] (handle_irq_event_percpu+0x54/0x19c) r5:004e r4:afba75c0 [8007a148] (handle_irq_event_percpu+0x0/0x19c) from [8007a334] (handle_irq_event+0x50/0x70) [8007a2e4] (handle_irq_event+0x0/0x70) from [8007d3b4] (handle_fasteoi_irq+0xc0/0x16c) r5:004e r4:af809900 [8007d2f4] (handle_fasteoi_irq+0x0/0x16c) from [80079b08] (generic_handle_irq+0x28/0x38) r5:807cce3c r4:004b [80079ae0] (generic_handle_irq+0x0/0x38) from [8000eef4] (handle_IRQ+0x54/0xb4) r4:807d8ba0 r3:0180 [8000eea0] (handle_IRQ+0x0/0xb4) from [80008600] (gic_handle_irq+0x30/0x64) r8:96d5c75d r7:f4000100 r6:807d1ed8 r5:807d8ce4 r4:f400010c r3: [800085d0] (gic_handle_irq+0x0/0x64) from [8000e180] (__irq_svc+0x40/0x54) Exception stack(0x807d1ed8 to 0x807d1f20) 1ec0: 807d1f20 0046 1ee0: 9cedd275 0010 8108f080 807de294 0001 807de248 96d5c75d 0010 1f00: 807d1f54 807d1f20 8005ff54 8042699c 6013 r7:807d1f0c r6: r5:6013 r4:8042699c [80426944] (cpuidle_enter_state+0x0/0xf4) from [80426af0] (cpuidle_idle_call+0xb8/0x174) r9:0001 r8:807d r7:8086bd00 r6:807de248 r5:0001 r4:8108f080 [80426a38] (cpuidle_idle_call+0x0/0x174) from [8000f294] (arch_cpu_idle+0x18/0x5c) [8000f27c] (arch_cpu_idle+0x0/0x5c) from [8005f110] (cpu_startup_entry+0xb4/0x148) [8005f05c] (cpu_startup_entry+0x0/0x148) from [805aa58c] (rest_init+0x68/0x80) r7:807dc86c [805aa524] (rest_init+0x0/0x80) from [8077c860] (start_kernel+0x2d8/0x334) [8077c588] (start_kernel+0x0/0x334) from [10008074] (0x10008074) Code: e59031e0 e51b203c e24b1034 e2820058 (e5933010) ---[ end trace f874b2c5533c04bc ]--- Kernel panic - not syncing: Fatal exception in interrupt Tested-by: Marek Vasut ma...@denx.de Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/chipidea/udc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 858f535..2ea5871 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1671,13 +1671,13 @@ static int ci_udc_stop(struct usb_gadget *gadget,
RE: [PATCH 0/2] fs: supply inode uid/gid setting interface
Subject: Re: [PATCH 0/2] fs: supply inode uid/gid setting interface On 2013/8/23 12:10, Greg KH wrote: On Fri, Aug 23, 2013 at 10:48:36AM +0800, Rui Xiang wrote: This patchset implements an accessor functions to set uid/gid in inode struct. Just finish code clean up. Why? It can introduce a new function to reduce some codes. Just clean up. In what sense is it a 'cleanup' ? To my mind it just means that anyone reading the code has to go and look at another file in order to see what the function does (it might be expected to be more complex). It also adds run time cost, while probably not directly measurable I suspect it more than doubles the execution time of that code fragment - do that everywhere and the system will run like a sick pig. The only real use for accessor functions is when you don't want the structure offset to be public. In this case that is obviously not the case since all the drivers are directly accessing other members of the structure. David -- 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 v15 00/13] Add tested id switch and vbus connect detect support for Chipidea
On 08/27/2013 10:12 AM, Hector Palacios wrote: On 08/27/2013 10:09 AM, Alexander Shishkin wrote: Hector Palacios hector.palac...@digi.com writes: Dear Peter, On 08/27/2013 04:51 AM, Peter Chen wrote: On Mon, Aug 26, 2013 at 06:24:48PM +0200, Hector Palacios wrote: Dear Peter, On 08/12/2013 03:22 AM, Peter Chen wrote: This patchset adds tested otg id switch function and vbus connect and disconnect detection for chipidea driver. And fix kinds of bugs found at chipidea drivers after enabling id and vbus detection. This patch are fully tested at imx6 sabresd and imx28evk platform by me. Besides, marek tested it on two STMP3780-based boards (not yet mainline) and two MX28-based boards. My chipidea repo: https://github.com/hzpeterchen/linux-usb.git Changes for v15: - Mark otgsc API as static line, and move them to otg.h [4/13] - Remove some redundant comments [6/13] - Fix some typos [8/13] - Retire flag CI_HDRC_PULLUP_ON_VBUS [12/13] [13/13] Patches 6 and 12 in this series seem to be incomplete or malformed. Please check. Would you post what's the problem for them or what's problem at your system after using them? I'm sorry, I thought it was evident. Patches 6 and 12 were posted incomplete. See how they end: http://permalink.gmane.org/gmane.linux.usb.general/92231 http://permalink.gmane.org/gmane.linux.usb.general/92237 In patch 12 the modified file include/linux/usb/chipidea.h does not even appear. Something happened during the generation or posting of these patches. Or something's wrong with gmane. http://www.spinics.net/lists/linux-usb/msg91695.html Oops. My fault, then. Sorry about that. For what is worth, I successfully tested these series with serial, ethernet and mass storage gadget drivers on a custom board (not upstream) based on i.MX28. Tested-by: Hector Palacios hector.palac...@digi.com Best regards, -- Hector Palacios -- 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: staging:DWC2 USB driver issues
Hi Dinh, Any chance anyone has a similar experience with this DWC2 driver, any help will greatly appreciated. Of course, I will go back and verify the initialization between the DWC2 and the old driver to see if I can spot anything. At first glance, the symptoms (getting transaction errors on every transaction attempt) looks similar to what I was seeing a while back: http://comments.gmane.org/gmane.linux.usb.general/86117 However, in my case it seems there was some hardware issue (possibly even a hardware fault in a single unit) that caused it, so I doubt this will really help you... What hardware are you working with? Gr. Matthijs -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] USB: EHCI: disable IAA_WATCHDOG and START_UNLINK_INTR if they needn't to be handled
On Tue, Aug 27, 2013 at 4:05 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 26 Aug 2013, Ming Lei wrote: The problem is that once an interrupt QH has been unlinked, relinking it might not make it visible to the hardware until the next frame starts. Therefore interrupt endpoints with an interval of 1 ms would not work correctly; they would get unlinked and relinked in every second frame. Suppose so, I ague it still need be fixed without the giveback URB in tasklet patches, since HCDs should support submitting intr URB not from completion directly(tasklet, workqueue, or simple task). So sort of the change on interrupt unlinking isn't only for supporting giveback URB in tasklet, but also a fix on current HCDs. I don't understand your argument. The uhci-hcd _does_ support interrupt URBs being submitted from tasklets, workqueues, kernel threads, or whatever. The guarantee is that the interrupt URB will be scheduled right away if the endpoint queue has not emptied out. Considered it is common for interrupt queue that only one URB is submitted, there is no the guarantee if drivers submit URB in tasklet scheduled from complete(), so the URB isn't submitted right away always for the driver. _All_ the HCDs behave this way; there's nothing special about uhci-hcd. There's no promise to schedule an interrupt URB right away if the endpoint queue is empty. Actually the interrupt URB can be scheduled right away if the queue is idle, and no such constraint on other types of queue, so people is really confused about the difference. Submitting an URB from within the completion handler is a simple way to guarantee that the endpoint queue will never become empty. Or rather, it _was_ a simple way to guarantee this -- when the driver switches over to tasklets, that guarantee isn't valid any more. Also, the 1ms interval delay problem might exist on your RFC approach, when the tasklet schedule delay is a bit long, the resubmitting is still very late than the complete time from view of hardware. That is not relevant. Obviously we can do nothing about tasklet delay. I'm talking about the delay caused by unlinking and relinking the QH. But you mentioned the result of the delay, no matter what the reason is, the result is same. Could you explain it in detail? I mean we only discuss the change on isoc schedule in case of underrun when giveback in tasklet. The code in iso_stream_schedule() knows that any URB scheduled to end before ehci-last_iso_frame will already have been given back, and any Yes, the patch doesn't change the fact. resubmissions by the completion handler will have occurred already. That's what this comment means: /* * Use ehci-last_iso_frame as the base. There can't be any * TDs scheduled for earlier than that. */ But with your tasklet, this isn't true any more. Even though the It is still true, with the giveback urb in tasklet patch, ehci-last_iso_frame is updated to 'now' in scan_isoc(), then URBs scheduled in tasklet is always after 'now' in scan_isoc(). This is examined in greater detail below. Also even without my patches, HCD should support isoc URBs submitted by tasklet or workqueue which is scheduled in its complete(), right? No, none of the HCDs support that. More precisely, they will accept such URBs but they don't guarantee that the URB will be scheduled for the next slot after the last one used by the preceding URB. If you think there is problem caused by the patchset, the problem should have been existed in HCDs already, then it is unfair to count the change on my patch, :-) The problem is that the HCDs currently _do_ guarantee the isochronous URBs submitted by the completion handler will be scheduled immediately following the preceding URB (to the best of their ability -- not all the HCDs can do this). Maintaining this guarantee while giving back URBs in a tasklet is difficult. See the 3/3 patch in the RFC series I just posted to get an idea of the required changes. There are already several drivers which submits URB from tasklet scheduled in complete(), which doesn't submit URB directly. Is there any difference with what does in giveback in tasklet patch from view of HCD? It is still easy to extend my patch to support the case, just store the 'urb-ep' into percpu variable and compare it with resubmited urb-ep because urb-ep has to be correct before completing and during submitting. See the attachment patch. The 1/3 patch in my new RFC series is nearly the same as your attachment without the use of percpu variables (which makes it rather simpler). I suppose it could be simplified even farther by storing the the current urb-ep value in the giveback_urb_bh structure instead of adding a giveback_in_progress flag to the usb_host_endpoint. OK. There's a much simpler way to solve this problem. I
Re: staging:DWC2 USB driver issues
On Tue 2013-08-27 12:22:59, Matthijs Kooijman wrote: Hi Dinh, Any chance anyone has a similar experience with this DWC2 driver, any help will greatly appreciated. Of course, I will go back and verify the initialization between the DWC2 and the old driver to see if I can spot anything. At first glance, the symptoms (getting transaction errors on every transaction attempt) looks similar to what I was seeing a while back: http://comments.gmane.org/gmane.linux.usb.general/86117 However, in my case it seems there was some hardware issue (possibly even a hardware fault in a single unit) that caused it, so I doubt this will really help you... What hardware are you working with? Very probably Altera Socfpga Cyclone V board. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: 3.4.4: disabling irq
Hello Alan, On 2013-08-23 21:33, Alan Stern wrote: Well, I replaced the motherboard by one of the same type and same BIOS version. And the problem is still here. kernel:[ 3013.199945] Disabling IRQ #18 So what can we conclude? Kernel bug? Hardware bug? Something else? Any of the above. On the new hardware, is it still true that /proc/interrupts shows IRQ 18 being used by ohci_hcd:usb1, 2, 3, and nothing else? $ cat /proc/interrupts |grep 18: 104556 35248 IR-IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb8, ohci_hcd:usb9 Suppose you don't use the webcam, or better yet, unplug it (so that it can't possibly be used without your knowledge). If you do, does the IRQ still get disabled? If I simply stop the `motion` daemon I did not see the errors in the past. Replacing the pwc webcam did not help. By the way, you aren't still running a 3.4 kernel are you? We move up with the releases so yes we have 3.10 kernels. Assuming you are using 3.10 or later, here's something else you can do. Turn on CONFIG_DUMMY_IRQ in the kernel config. Then do rmmod ohci-pci modprobe dummy-irq irq=18 and see if the IRQ line gets disabled after that. Can I actually use that irq/ports that way? (as with no usage the problem does not occur) Also: $ lsmod|grep pci ehci_pci 12432 0 ehci_hcd 56916 1 ehci_pci No ohci_pci, is that a problem? FWIW: on these boards (same type, BIOS, etc) I also see the issue described at http://marc.info/?l=linux-kernelm=137749729105329w=2. Any correlation? Kind regards, Udo -- 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: staging:DWC2 USB driver issues
Hi! I was wondering if anyone has come across the problem I am experiencing with the staging DWC2 driver. The problem is that the driver is failing to detect a device when connected. I know that HW works because I have an older version of the driver for this IP and it seems to work OK, barring a few issues(DMA, Split Transactions), this older driver is able to function adequately on a mass storage device. But the DWC2 driver is not able to detect a device at all, unless I force it into HOST mode only. With Host mode only, its able to see a device but fails to enumerate correctly. What needs to be done to get DWC2 to detect? So far I tried checking out your g...@github.com:dinh-linux/linux-socfpga.git for-next tree, and patching it so that VIRT_TO_BUS is configurable. But I suspect I still need patch for dts? Thanks, Pavel diff --git a/mm/Kconfig b/mm/Kconfig index 8028dcc..84bbc9d 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -292,7 +292,7 @@ config NR_QUICK default 1 config VIRT_TO_BUS - bool + bool Virt_to_bus help An architecture should select this if it implements the deprecated interface virt_to_bus(). All new architectures -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 2/3] EHCI: convert the IRQ handler to a tasklet
On Tue, 27 Aug 2013, Ming Lei wrote: Yes. A new spinlock would be needed to synchronize the top half and the bottom half. The same spinlock would also be used to avoid scheduling the tasklet when it is already running, like in your implementation. Then every HCD need to copy these kind of implementation... Yes. The pattern would be pretty much the same in each case. So when the above implementation is required in each HCDs change, I am wondering if it is 'pretty easy'. I think it is pretty easy for each HCD. Changing all of them would be a large job. Still not sure it is pretty easy since extra lock things have to be considered: (such as, order between two locks, disabling irq and acquiring lock) Those things would definitely need to be considered. But doing them properly wouldn't require much code. Even though interrupts are masked, the tasklet can still check the EHCI status register to see if new events have occurred while the tasklet was running, as I described above. The tasklet could do this check before returning. Yes, the tasklet can do it but some events(IAA, connection, fata error, ...) are handled with delay. That's true. It's also true that the existing driver handles them with delay. If an IAA, connection, or fatal error event occurs while ehci_work() is running, the event won't be handled until after ehci_work() finishes. I agree that masking interrupts while the bottom half runs would increase this delay, but I don't think it matters much. For example, consider disconnect events. Leaving interrupts masked might delay the event report for 10 ms (probably a lot less). But compare that to what happens when a device disconnects from an external hub -- hubs are polled for port status changes with an interval of 128 ms! By comparison, a 10-ms delay for the root hub is unimportant. More things done in top half, the change will become more complicated since more synchronizations need to consider. Not at all. ehci-lock will synchronize things perfectly well. It isn't good to hold ehci-lock in ehci_irq(), otherwise, ehci_irq has to spin on this lock when is held in tasklet. That was my point. We are in agreement that it is bad for the top half and the bottom half both to acquire ehci-lock. Your solution is to put everything but the givebacks (which don't need the lock) in the top half, whereas my solution is to put everything in the bottom half. But now you're complaining because that means some of the work won't get done in the top half! You can't have it both ways. If the lock isn't used in both places then the top half has to do either all or none of the work. I prefer to enabling EHCI interrupt during tasklet handling. What for? It seems likely that the top half would have to acquire the So we can respond some events(IAA, fatal error, connection change) quickly. For example, when fatal error happened, ehci transfer descriptors might be written incorrectly by host, so it is better to let tasklet see it asap and handle transfer effectively(maybe correctly). You haven't thought this through. _Every_ QH and TD written by the host controller eventually gets scanned by ehci-hcd. This is true whether or not a fatal error occurs. The existing driver doesn't do anything special about incorrect TDs, and it never has. So why should we have to start doing it now? Similar considerations apply to connect and disconnect handling. Suppose a connect event occurs while ehci_work() is running. Suppose that the event can be handled without acquiring ehci-lock, so that the event is reported to usbcore immediately. What would happen next? Answer: Before doing anything else, khubd would issue a Get-Port-Status request, which acquires ehci-lock! Thus the response to the connect event would end up being delayed anyway. The one disadvantage to leaving interrupts masked while the tasklet runs is that new events won't be detected until all the existing givebacks are finished. In the old driver, new events could be detected as soon as the next giveback occurred, because the lock would be released then. In the end, this comes down to a decision about priorities. Do you want to give higher priority to new events or to givebacks? Overall, I don't think it matters. 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 v1] USB: EHCI: disable IAA_WATCHDOG and START_UNLINK_INTR if they needn't to be handled
On Tue, 27 Aug 2013, Ming Lei wrote: I don't understand your argument. The uhci-hcd _does_ support interrupt URBs being submitted from tasklets, workqueues, kernel threads, or whatever. The guarantee is that the interrupt URB will be scheduled right away if the endpoint queue has not emptied out. Considered it is common for interrupt queue that only one URB is submitted, there is no the guarantee if drivers submit URB in tasklet scheduled from complete(), so the URB isn't submitted right away always for the driver. Yes. I'm not sure what is the best way to explain this... Think about it this way: Why did you write the USB: EHCI: improve interrupt qh unlink patch in the first place? Essentially the same reason applies to uhci-hcd and ohci-hcd, and they will need similar patches. The problem is that the HCDs currently _do_ guarantee the isochronous URBs submitted by the completion handler will be scheduled immediately following the preceding URB (to the best of their ability -- not all the HCDs can do this). Maintaining this guarantee while giving back URBs in a tasklet is difficult. See the 3/3 patch in the RFC series I just posted to get an idea of the required changes. There are already several drivers which submits URB from tasklet scheduled in complete(), which doesn't submit URB directly. Is there any difference with what does in giveback in tasklet patch from view of HCD? No. There is a difference only when the completion submits an isochronous URB directly. Suppose an URB is submitted while the endpoint queue is non-empty, so it is scheduled to start in the next slot after the end of the last URB in the queue. Does that next slot occur after the frame stored in ehci-last_iso_frame? I think it is yes, actually the new slot is always after current uframe during iso_stream_schedule from tasklet, and it is behind ehci-last_iso_frame which is updated in ehci_irq path. Wrong. Here are a couple of examples. Assume first that the endpoint's interval is 8 frames (it's a full-speed device): The last packet of the last URB on the queue is scheduled for frame 100. Because of an SMI, IRQs are delayed until the controller reaches frame 105. When the interrupt occurs, ehci-hcd will scan the siTDs for the endpoint and give them all back. At the end, last_iso_frame will be set to 104 (it lags one behind the current frame number). Let's say the tasklet takes 1 ms to start up, so the completion handler runs during frame 106. It submits an URB. This URB is scheduled for the next unused slot, which is 108 (i.e., 8 frames after the last packet of the last URB). Since 108 is larger than both 104 and 106, the next slot does indeed come after both ehci-last_iso_frame and the current frame number. Yes, but the TDs(URB) can't be missed, suppose there are 8 packets, so the last packet of the new URB will be completed in 164, when IRQ comes at 165, ehci_irq() will scan from 104 to 165, so the URB can be completed successfully, then update last_iso_frame as 164. Then what is wrong? Nothing is wrong, either with my example or with yours. Now assume the endpoint's interval is 1 frame: The last packet of the last URB on the queue is scheduled for frame 200. Because of an SMI, IRQs are delayed until the controller reaches frame 205. When the interrupt occurs, ehci-hcd will scan the siTDs for the endpoint and give them all back. At the end, last_iso_frame will be set to 204. The tasklet takes 1 ms to start up, so the completion handler runs during frame 206. It submits an URB. This URB is scheduled for the next unused slot, which is 201 (i.e., 1 frame after the last packet of the last URB). Since 201 is smaller than both 204 and 206, the next slot does indeed come before both ehci-last_iso_frame and the current frame number. iso_stream_schedule() will figure out that the next slot(201) is behind the scheduling threshold(case of 'start next'), then update the next slot as one new slot which is larger 206 if URB_ISO_ASAP, so looks the TDs(USB) can't be missed too. Without URB_ISO_ASAP, there might be problem since 201 won't be scanned next time in scan_isoc, so is it what your RFC3 is fixing? Yes, it is. Now you understand my point. If I understand the above problem correctly, the same problem exists on drivers which submit URB in tasklet scheduled from complete() too before the moving, doesn't it? That's right. Probably those drivers always use URB_ISO_ASAP, so the problem doesn't arise. If they don't use URB_ISO_ASAP ... well, then they will get inconsistent results when an underrun occurs. Below is an updated version of the last 1/3 RFC patch
[PATCH 2/4] staging: ozwpan: Reset PORT_ENABLE bit.
Reset PORT_ENABLE bit of port status on loosing PD. Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com --- drivers/staging/ozwpan/ozhcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c index b0398c5..39f5066 100644 --- a/drivers/staging/ozwpan/ozhcd.c +++ b/drivers/staging/ozwpan/ozhcd.c @@ -756,7 +756,7 @@ void oz_hcd_pd_departed(struct oz_port *port) port-config_num = 0; port-flags = ~(OZ_PORT_F_PRESENT | OZ_PORT_F_DYING); port-flags |= OZ_PORT_F_CHANGED; - port-status = ~USB_PORT_STAT_CONNECTION; + port-status = ~(USB_PORT_STAT_CONNECTION | USB_PORT_STAT_ENABLE); port-status |= (USB_PORT_STAT_C_CONNECTION 16); /* If there is an endpont 0 then clear the pointer while we hold * the spinlock be we deallocate it after releasing the lock. -- 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
[PATCH 3/4] staging: ozwpan: Add debounce time before unregistering.
Fixes following error caused during unloading driver.
[ 1127.542888] usb 5-1: USB disconnect, device number 2
[ 1127.542909] ozwpan ozwpan: remove, state 1
[ 1127.542933] usb usb5: USB disconnect, device number 1
[ 1127.618634] hub 5-0:1.0: hub_port_status failed (err = -19)
[ 1127.618647] hub_port_connect_change: 45 callbacks suppressed
[ 1127.618657] hub 5-0:1.0: connect-debounce failed, port 1 disabled
[ 1127.618668] hub 5-0:1.0: cannot disable port 1 (err = -19)
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozhcd.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c
index 39f5066..d9c43c3 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -57,6 +57,10 @@
*/
#define EP0_TIMEOUT_COUNTER 13
+/* Debounce time HCD driver should wait before unregistering.
+ */
+#define OZ_HUB_DEBOUNCE_TIMEOUT 1500
+
/*
* Used to link urbs together and also store some status information for each
* urb.
@@ -2355,6 +2359,7 @@ error:
*/
void oz_hcd_term(void)
{
+ msleep(OZ_HUB_DEBOUNCE_TIMEOUT);
tasklet_kill(g_urb_process_tasklet);
tasklet_kill(g_urb_cancel_tasklet);
platform_device_unregister(g_plat_dev);
--
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
[PATCH 4/4] staging: ozwpan: Return error, if PD is not connected.
Return error if we receive write(), while PD is not connected.
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozcdev.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 03b41ee..22cb2ae 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -162,6 +162,8 @@ static ssize_t oz_cdev_write(struct file *filp, const char
__user *buf,
spin_unlock_bh(g_cdev.lock);
if (pd == NULL)
return -1;
+ if (!(pd-state OZ_PD_S_CONNECTED))
+ return -ENXIO;
eb = pd-elt_buff;
ei = oz_elt_info_alloc(eb);
if (ei == NULL) {
--
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
[PATCH 1/4] staging: ozwpan: Increase ISOC IN buffer depth
Increase ISOC IN buffer depth to 100 units. Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com --- drivers/staging/ozwpan/ozhcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c index 3548860..b0398c5 100644 --- a/drivers/staging/ozwpan/ozhcd.c +++ b/drivers/staging/ozwpan/ozhcd.c @@ -39,7 +39,7 @@ * Number of units of buffering to capture for an isochronous IN endpoint before * allowing data to be indicated up. */ -#define OZ_IN_BUFFERING_UNITS 50 +#define OZ_IN_BUFFERING_UNITS 100 /* Name of our platform device. */ -- 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: [alsa-devel] Buffer size for ALSA USB PCM audio
On Tue, 27 Aug 2013, Clemens Ladisch wrote: There is no reasoning about capture endpoints. The driver cannot control how many samples actually end up in a capture packet, so it is possible that URBs end up being one USB frame longer than a period, in which case the ALSA period interrupts will accumulate delays of up to one period, or that URBs end up being one USB frame shorter than a period, in which case the ALSA period interrupt will be delayed to the end of the _next_ URB. The current algorithm uses very short capture URBs to ensure that _some_ URB is completed as soon as possible after a period ends. Your patch makes things worse for running jackd at lower latencies because playback and capture period interrupts are expected to be more or less synchronous (jackd waits for both interrupts before acting on one period). With only two periods per buffer and the capture period interrupt randomly delayed by up to one period, the time available for processing one period is reduced to zero. I'd suggest to keep the old calculation for capture URBs. It would make sense to use longer capture URBs only if the period size is relatively large. Okay. What about playback endpoints with implicit sync? The current driver treats them the same as capture endpoints. Is that really the right thing to do? Note: for capturing, the number of URBs has no effect on latency and just reduces the risk of overruns, so it is desirable to make the queue as long as possible (for a given URB length). Sure. It looks like the only limit that will matter here is MAX_URBS. Not having heard any responses to the patch posted last Wednesday, Sorry, my #patches / free_time quotient is rather large. Me too. And don't forget bug reports. :-) 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] clk: samsung: pll: Use new registration method for PLL6552 and PLL6553
On 08/27/13 10:14, Mike Turquette wrote: Quoting Tomasz Figa (2013-08-20 17:33:21) This patch modifies PLL6552 and PLL6553 clock drivers to use recently added common Samsung PLL registration method. Signed-off-by: Tomasz Figatomasz.f...@gmail.com Sigh. This change won't apply on top of clk-next-s3c64xx since it requires Yadwinder's change (amongst) others. The best I could do was spin out another topic branch with the relevant changes and apply this patch on top. It is a subset of clk-next but it is almost entirely Samsung patches: git://git.linaro.org/people/mturquette/linux.git clk-next-s3c64xx-delta Kukjin Tomasz, let me know if this OK for you to add as a dependency to the Samsung tree. If it is I will merge it into clk-next, but I want your OK that this branch is OK for you to take. Hi Mike, I merged the branch clk-next-s3c64xx-delta you provided on top of previous clk-next-s3c64xx for common-clk-s3c64xx and dt-s3c64xx and it looks fine to me. Thanks, Kukjin -- 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: [Bug] [Sony VAIO SVT15117CXS] USB 2.0 ports not working with any USB device
On Mon, 26 Aug 2013, Kevin Archer wrote: I think the link in my first email was wrong here is the correct link https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1210858 I did run 2.6.33 and 2.6.39 in which the 2 usb ports did appear to work, but the Xserver did not work correctly so I only had command line. That's okay; you don't need anything more than the command line to copy the dmesg log. What does the dmesg log for 2.6.39 say when you plug in an external device? In 3.11, does it make any difference if you rmmod xhci-hcd before plugging in the device? 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 4/4] staging: ozwpan: Return error, if PD is not connected.
Hello. On 08/27/2013 07:53 PM, Rupesh Gujare wrote: Return error if we receive write(), while PD is not connected. Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com --- drivers/staging/ozwpan/ozcdev.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c index 03b41ee..22cb2ae 100644 --- a/drivers/staging/ozwpan/ozcdev.c +++ b/drivers/staging/ozwpan/ozcdev.c @@ -162,6 +162,8 @@ static ssize_t oz_cdev_write(struct file *filp, const char __user *buf, spin_unlock_bh(g_cdev.lock); if (pd == NULL) return -1; Note that returning -EPERM here is hardly correct. + if (!(pd-state OZ_PD_S_CONNECTED)) + return -ENXIO; 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: 3.4.4: disabling irq
On Tue, 27 Aug 2013, Udo van den Heuvel wrote: Hello Alan, On 2013-08-23 21:33, Alan Stern wrote: Well, I replaced the motherboard by one of the same type and same BIOS version. And the problem is still here. kernel:[ 3013.199945] Disabling IRQ #18 So what can we conclude? Kernel bug? Hardware bug? Something else? Any of the above. On the new hardware, is it still true that /proc/interrupts shows IRQ 18 being used by ohci_hcd:usb1, 2, 3, and nothing else? $ cat /proc/interrupts |grep 18: 104556 35248 IR-IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb8, ohci_hcd:usb9 Different bus numbers, but probably the same controllers. All right. Suppose you don't use the webcam, or better yet, unplug it (so that it can't possibly be used without your knowledge). If you do, does the IRQ still get disabled? If I simply stop the `motion` daemon I did not see the errors in the past. Replacing the pwc webcam did not help. rmmod ohci-pci modprobe dummy-irq irq=18 and see if the IRQ line gets disabled after that. Can I actually use that irq/ports that way? (as with no usage the problem does not occur) No, if you unload the ohci-hcd driver then the webcam won't be used. Are you certain that merely stopping the daemon program will prevent the problem? Also: $ lsmod|grep pci ehci_pci 12432 0 ehci_hcd 56916 1 ehci_pci No ohci_pci, is that a problem? Sorry, for 3.10 it should be ohci_hcd. In 3.11 it changed to ohci_pci. Have you tried getting a USB-2 hub and plugging the webcam into it? That will make a good test: You'll be able to use the webcam without it affecting the ohci-hcd driver. As a second test, you can try plugging everything _except_ the webcam into the hub. FWIW: on these boards (same type, BIOS, etc) I also see the issue described at http://marc.info/?l=linux-kernelm=137749729105329w=2. Any correlation? Not that I can see. 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: Bug report: 045e:0721 Microsoft LifeCam NX-3000 not detected
On Tue, 27 Aug 2013, Jürgen Liebmann wrote: Alan, sorry your mail was redirect in the recycle folder of my email account and I read this at first today. Please can you help me, how I can get this both kernels without doing a new bisect? The results of bisect I'd already delete. I'm unfortunately not a expert for kernel development! Jürgen, can you post usbmon traces taken from a kernel with the 74a6af256b48 commit present and a kernel with that commit reverted? I'd like to compare them for differences. Instructions are in the kernel source file Documentation/usb/usbmon.txt. You don't have to go through an entire bisect. Assuming you still have the git repository, you can just do git checkout 74a6af256b48 to build a kernel with the commit present, and git checkout 74a6af256b48^ to build a kernel without the commit. Then in each of the kernels, start collecting a usbmon trace before you plug in the camera. 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: failure to resume from suspend cause by 84ebc102
On Tue, 27 Aug 2013, Adam Borowski wrote: What happens if go back to a kernel without that commit and enable CONFIG_USB_SUSPEND? The behavior should be identical -- basically the commit is supposed to have the effect of always assuming that CONFIG_USB_SUSPEND has the same value as CONFIG_PM_RUNTIME, except in one spot where it is assumed to have the same value as CONFIG_PM. Going to the parent of that commit but enabling CONFIG_USB_SUSPEND indeed causes the lockup. So it's not that commit what's the culprit -- it's just that Debian kernels did not have the option enabled but do have CONFIG_PM_RUNTIME which you merged it with. Surprisingly, though, today's next with CONFIG_PM_RUNTIME unset _does_ lock up. I also tried removing all USB devices: * none attached: ok * USB keyboard: ok * USB mouse (two different manufacturers): lockup So what else should I test? Is there any way to get the dmesg information when the system locks up? For example, serial console, or netconsole? Seeing that, along with CONFIG_USB_DEBUG enabled, would help. Even if you can't do that, you should at least post a dmesg log showing the boot-up. I tried to reproduce your problem on my computer, but I couldn't. Maybe I wasn't using the right combination of kernel version and config options. Meow! Woof woof! 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 2/3] xhci: fix port BESL LPM capability checking
From: Mathias Nyman mathias.ny...@linux.intel.com Wrong capability bit was checked for best effort service latency. bit 20 indicate port is BESL LPM capable (BLC), bit 19 is hardware LPM capable (HLC) This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 usb: xhci: add USB2 Link power management BESL support Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Reported-by: Steve Cotton st...@s.cotton.clara.co.uk Cc: sta...@vger.kernel.org --- drivers/usb/host/xhci-ext-caps.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h index 8d7a132..9fe3225 100644 --- a/drivers/usb/host/xhci-ext-caps.h +++ b/drivers/usb/host/xhci-ext-caps.h @@ -71,7 +71,7 @@ /* USB 2.0 xHCI 1.0 hardware LMP capability - section 7.2.2.1.3.2 */ #define XHCI_HLC (1 19) -#define XHCI_BLC (1 19) +#define XHCI_BLC (1 20) /* command register values to disable interrupts and halt the HC */ /* start/stop HC execution - do not write unless HC is halted*/ -- 1.8.3.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
[PATCH 1/3] usb: xhci: Disable runtime PM suspend for quirky controllers
From: Shawn Nematbakhsh sha...@chromium.org
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device triggered the resume (the open call will fail).
Note that this change is only relevant when persist_enabled is not set
for USB devices.
This patch should be backported to kernels as old as 3.0, that
contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 xhci: Add
reset on resume quirk for asrock p67 host.
Signed-off-by: Shawn Nematbakhsh sha...@chromium.org
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ba0ec0a..349d346 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3557,10 +3557,21 @@ void xhci_free_dev(struct usb_hcd *hcd, struct
usb_device *udev)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_virt_device *virt_dev;
+ struct device *dev = hcd-self.controller;
unsigned long flags;
u32 state;
int i, ret;
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+ /*
+* We called pm_runtime_get_noresume when the device was attached.
+* Decrement the counter here to allow controller to runtime suspend
+* if no devices remain.
+*/
+ if (xhci-quirks XHCI_RESET_ON_RESUME)
+ pm_runtime_put_noidle(dev);
+#endif
+
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
/* If the host is halted due to driver unload, we still need to free the
* device.
@@ -3634,6 +3645,7 @@ static int xhci_reserve_host_control_ep_resources(struct
xhci_hcd *xhci)
int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct device *dev = hcd-self.controller;
unsigned long flags;
int timeleft;
int ret;
@@ -3686,6 +3698,16 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct
usb_device *udev)
goto disable_slot;
}
udev-slot_id = xhci-slot_id;
+
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+ /*
+* If resetting upon resume, we can't put the controller into runtime
+* suspend if there is a device attached.
+*/
+ if (xhci-quirks XHCI_RESET_ON_RESUME)
+ pm_runtime_get_noresume(dev);
+#endif
+
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
return 1;
--
1.8.3.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
[PATCH 3/3] xhci:prevent callbacks suppressed when debug is not enabled
From: Dmitry Kasatkin d.kasat...@samsung.com
When debug is not enabled and dev_dbg() will expand to nothing,
log might be flooded with callbacks suppressed. If it was not
done on purpose, better to use dev_dbg_ratelimited() instead.
Signed-off-by: Dmitry Kasatkin d.kasat...@samsung.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7b35af1..411da1f 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3087,14 +3087,10 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
* to set the polling interval (once the API is added).
*/
if (xhci_interval != ep_interval) {
- if (printk_ratelimit())
- dev_dbg(urb-dev-dev, Driver uses different interval
-(%d microframe%s) than xHCI
- (%d microframe%s)\n,
- ep_interval,
- ep_interval == 1 ? : s,
- xhci_interval,
- xhci_interval == 1 ? : s);
+ dev_dbg_ratelimited(urb-dev-dev,
+ Driver uses different interval (%d
microframe%s) than xHCI (%d microframe%s)\n,
+ ep_interval, ep_interval == 1 ? : s,
+ xhci_interval, xhci_interval == 1 ? : s);
urb-interval = xhci_interval;
/* Convert back to frames for LS/FS devices */
if (urb-dev-speed == USB_SPEED_LOW ||
@@ -3876,14 +3872,10 @@ int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci,
gfp_t mem_flags,
* to set the polling interval (once the API is added).
*/
if (xhci_interval != ep_interval) {
- if (printk_ratelimit())
- dev_dbg(urb-dev-dev, Driver uses different interval
-(%d microframe%s) than xHCI
- (%d microframe%s)\n,
- ep_interval,
- ep_interval == 1 ? : s,
- xhci_interval,
- xhci_interval == 1 ? : s);
+ dev_dbg_ratelimited(urb-dev-dev,
+ Driver uses different interval (%d
microframe%s) than xHCI (%d microframe%s)\n,
+ ep_interval, ep_interval == 1 ? : s,
+ xhci_interval, xhci_interval == 1 ? : s);
urb-interval = xhci_interval;
/* Convert back to frames for LS/FS devices */
if (urb-dev-speed == USB_SPEED_LOW ||
--
1.8.3.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] USB: gadget: audit sysfs attribute permissions
On Fri, Aug 23, 2013 at 04:34:43PM -0700, Greg Kroah-Hartman wrote: From: Greg Kroah-Hartman gre...@linuxfoundation.org Convert all USB gadget sysfs attributes to use the _RO or _RW variants, to make them easier to audit and ensure that the permissions are correct. Note, two are left using the DEVICE_ATTR() macro, as there is no DEVICE_ATTR_WO() in Linus's tree, that will happen after 3.12-rc1 is out, a follow-on patch will be sent then. Cc: Felipe Balbi ba...@ti.com looks good, thank you: Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree
On Tue, Aug 13, 2013 at 02:11:27PM +0530, Tushar Behera wrote: On 12 July 2013 12:27, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote: Hi Felipe, This is intended to pull down a reset signal line, not to switch power to the device. I could implement that with the regulator framework too, but I think that would just be confusing and harder to understand without providing any benefit. It's really just a plain old GPIO. alright, in that case how about using drivers/reset/ ? IIUC, reset-gpio driver only provides APIs for reset controls (reset, assert, deassert). We still need to find out the location from where we would be calling the reset function. that's fair, but at least you reuse a bunch of boilerplate code to claim the GPIO, set proper direction and value. No need to duplicate that in your driver. -- balbi signature.asc Description: Digital signature
Re: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Wed, Aug 14, 2013 at 12:28:17PM +0300, Ivan T. Ivanov wrote: Hi, On Mon, 2013-08-12 at 13:24 -0500, Felipe Balbi wrote: On Fri, Aug 09, 2013 at 07:09:18PM +0300, Ivan T. Ivanov wrote: Hi, On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote: Hi, On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote: diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c new file mode 100644 index 000..e509abc --- /dev/null +++ b/drivers/usb/dwc3/dwc3-msm.c @@ -0,0 +1,175 @@ +#undef CONFIG_REGULATOR why ?? 1. This shows that driver is still not fully tested Regulators support is still missing in the MSM 2. Helps me to load driver successfully. Then remove all the regulator-related code from this. I would like to keep them. I will just remove #undef line. Code will continue to build fine. And once regulators drivers are upstreamed this driver 'will not' require further modifications. fair enough. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding
Hi, On Tue, Aug 13, 2013 at 02:34:10PM +0100, Mark Rutland wrote: On Mon, Aug 12, 2013 at 07:05:53PM +0100, Felipe Balbi wrote: On Fri, Aug 09, 2013 at 01:42:15PM -0500, Kumar Gala wrote: On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote: On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: The binding spec wasn't clear that the order of the phandles in the usb-phy array has meaning. Clarify this point in the binding that it should be USB2-HS-PHY, USB3-SS-PHY. Signed-off-by: Kumar Gala ga...@codeaurora.org --- Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 7a95c65..8a9770b 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -6,7 +6,9 @@ Required properties: - compatible: must be synopsys,dwc3 - reg : Address and length of the register set for the device - interrupts: Interrupts used by the dwc3 controller. - - usb-phy : array of phandle for the PHY device + - usb-phy : array of phandle for the PHY device. The first element + in the array is expected to be a handle to the USB2/HS PHY and + the second element is expected to be a handle to the USB3/SS PHY Just to check - it's not valid to have a USB3 phy without a USB2 phy? Don't know, hopefully Felipe will chime in on that. that'd be a really non-standard implementation. Per-spec, USB3 is *always* backwards compatible with USB2. I'm slightly confused here. From a quick look at the driver, it expects two separate phys to be present -- one handling only USB2, and one handling USB3 (with USB2 backwards compatibility). So it's not physically possible for someone to just wire up a single phy to the device, either USB2-only or USB3? of course it is :-) In fact, TI has done it. But it causes a whole bunch of other problems to support that sort of model. For one, in some systems, a clock generated by the USB3 PHY is backfed into the IP and if USB3 PHY isn't running, the dwc3 IP won't start. I even wrote a patch making USB3 PHY optional, but didn't push it exactly because it broke some other systems and I can't guarantee users won't mess up their DTS/pdata. You can describe the USB2-only case in the dt by only listing the first phy (though the driver won't support it as it expects both to be present), but it's impossible to describe that you've wired up a single phy that's USB3 capable. you might be right there... -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget/composite : Avoid crash with bad gadget drivers
On Thu, Aug 15, 2013 at 01:40:01AM +0300, Philippe De Swert wrote: Hi, On 12/08/13 21:08, Felipe Balbi wrote: On Fri, Aug 09, 2013 at 09:23:08PM +0300, Philippe De Swert wrote: Some bad gadget drivers do not check the return status of usb_add_config. fix the gadget driver As stated in my comment (see below) that is indeed what should happen. But we cannot fix it in future new gadget drivers, is it thus not better to avoid a crash? The gadget driver will not work as expected anyway when this occurs and the print will at least give an indication why. if we avoid a crash, we will be decreasing the urgency of fixing the gadget driver bug. Let's leave it as is. I can't live thinking that maybe in the future there will be gadget drivers doing different things... -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/4] staging: ozwpan: Increase ISOC IN buffer depth
On Tue, Aug 27, 2013 at 04:53:40PM +0100, Rupesh Gujare wrote: Increase ISOC IN buffer depth to 100 units. This change log is not useful. What are the user visible effects of this bug? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] usb: dwc3: PHY should be selected when glue is enabled
Hi, On Fri, Aug 16, 2013 at 03:21:07PM +0800, Huang Rui wrote: Hi Felipe, USB transceivers should be selected when platform glues are enabled. Because it need initialize usb phy platform device for binding related phy driver when gules are probing. Patch 1 and patch 2 add NOP USB transceivers into Kconfig of PCI and Exynos glue. I tested them based on PCI glue. For patch 3 on OMAP platform, it need confirm with you. Patches are generated on balbi/next. this will cause problems, most likely. dwc3-exynos and dwc3-omap are likely going to be used with many different devices. That has the potential of those glue layers to be used with different PHYs, we will end up with: select A if B select C if D select E if F and so on... OTOH, we want to make Kconfig easy to use too... not sure what to do. Greg, any suggestions ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v11 0/8] PHY framework
Hi, On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing Looks like there are not further comments on this series. Can you take this in your misc tree? Do you want me to queue these for you ? There are quite a few users for this framework already and I know of at least 2 others which will show up for v3.13. Let me know. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/4] usb: chipidea: USB_CHIPIDEA should depend on HAS_DMA
On Mon, Aug 19, 2013 at 09:24:01AM +0800, Peter Chen wrote: On Sun, Aug 18, 2013 at 10:20:44PM +0200, Geert Uytterhoeven wrote: If NO_DMA=y: drivers/built-in.o: In function `dma_set_coherent_mask': include/linux/dma-mapping.h:93: undefined reference to `dma_supported' Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/usb/chipidea/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index d1bd8ef..dbd5232 100644 --- a/drivers/usb/chipidea/Kconfig +++ b/drivers/usb/chipidea/Kconfig @@ -1,6 +1,6 @@ config USB_CHIPIDEA tristate ChipIdea Highspeed Dual Role Controller - depends on USB || USB_GADGET + depends on (USB || USB_GADGET) HAS_DMA help Say Y here if your system has a dual role high speed USB controller based on ChipIdea silicon IP. Currently, only the I can't understand why the DMA can't be changed to fix this instead of changing every driver? I'm with you. It'd be nicer to just provide empty stubs when !HAS_DMA -- balbi signature.asc Description: Digital signature
Re: [PATCH] davinci: fix resources passed to MUSB driver for DM6467
Hello. On 08/12/2013 12:20 AM, Sergei Shtylyov wrote: After commit 09fc7d22b024692b2fe8a943b246de1af307132b (usb: musb: fix incorrect usage of resource pointer), CPPI DMA driver on DaVinci DM6467 can't detect its dedicated IRQ and so the MUSB IRQ is erroneously used instead. This is because only 2 resources are passed to the MUSB driver from the DaVinci glue layer, so fix this by always copying 3 resources (it's safe since a placeholder for the 3rd resource is always there) and passing 'pdev-num_resources' instead of the size of musb_resources[] to platform_device_add_resources(). Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- The patch is against the 'fixes' branch of Felipe Balbi's 'usb.git' repo. Felipe, are you going to apply this patch at least for 3.12? I heard nothing from you for 2+ weeks... 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 4/4] usb: chipidea: USB_CHIPIDEA should depend on HAS_DMA
On Tue, Aug 27, 2013 at 9:16 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Aug 19, 2013 at 09:24:01AM +0800, Peter Chen wrote:
On Sun, Aug 18, 2013 at 10:20:44PM +0200, Geert Uytterhoeven wrote:
If NO_DMA=y:
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
drivers/usb/chipidea/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index d1bd8ef..dbd5232 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -1,6 +1,6 @@
config USB_CHIPIDEA
tristate ChipIdea Highspeed Dual Role Controller
- depends on USB || USB_GADGET
+ depends on (USB || USB_GADGET) HAS_DMA
help
Say Y here if your system has a dual role high speed USB
controller based on ChipIdea silicon IP. Currently, only the
I can't understand why the DMA can't be changed to fix this instead
of changing every driver?
I'm with you. It'd be nicer to just provide empty stubs when !HAS_DMA
That would give us drivers that compile but don't work.
Not having stubs is intentional, cfr. the comment at the top of
include/asm-generic/dma-mapping-broken.h:
/* define the dma api to allow compilation but not linking of
* dma dependent code. Code that depends on the dma-mapping
* API needs to set 'depends on HAS_DMA' in its Kconfig
*/
and the comments in the commit that introduced it:
commit 1b0fac45878bb88759eec347c273285195649ff7
Author: Dan Williams dan.j.willi...@intel.com
Date: Sun Jul 15 23:40:26 2007 -0700
dma-mapping: prevent dma dependent code from linking on !HAS_DMA archs
Continuing the work started in 411f0f3edc141a582190d3605cadd1d993abb6df ...
This enables code with a dma path, that compiles away, to build without
requiring additional code factoring. It also prevents code that calls
dma_alloc_coherent and dma_free_coherent from linking whereas previously
the code would hit a BUG() at run time. Finally, it allows archs that set
!HAS_DMA to delete their asm/dma-mapping.h file.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi, On Thu, Aug 22, 2013 at 09:24:49PM +, Paul Zimmerman wrote: From: Ivan T. Ivanov [mailto:iiva...@mm-sol.com] Sent: Tuesday, August 20, 2013 8:26 AM On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote: On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote: Hi, On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote: On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote: I think they are SNPS DesignWare PHY's, additionally wrapped with Qualcomm logic. I could substitute dwc3 with just dw, which will be more correct. alright, thank you. Let's add Paul to the loop since he might have very good insight in the synopsys PHYs. mental note: if any other platform shows up with Synopsys PHY, ask them to use this driver instead :-) I really doubt that this will bi possible. Control of the PHY's is not directly trough ULPI, UTMI or PIPE3 interfaces, but trough QSCRATCH registers, which of course is highly Qualcomm specific. isn't it a memory mapped IP ? doesn't synopsys provide their own set of registers ? From what I see it is not directly mapped. How QSCRATCH write and reads transactions are translated to DW IP is unclear to me. I think the question is how does SW access them? USB QSCRATCH Hardware registers don't ask me what is this :-) or like Pawel says: it depends on the SOC . To answer the question doesn't synopsys provide their own set of registers, we provide registers in our USB cores to access the PHYs through I2C, ULPI/UTMI, or PIPE3 interfaces. But if someone wants to use our PHY with some other controller that doesn't provide that, then they may need to implement their own register set, as Qualcomm has apparently done. thanks for clarifying. that pretty much hinders writing any sort of generic drivers for Synopsys' PHYs though :-s But I guess that's alright. -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: gadget: audit sysfs attribute permissions
On Tue, Aug 27, 2013 at 01:28:41PM -0500, Felipe Balbi wrote: On Fri, Aug 23, 2013 at 04:34:43PM -0700, Greg Kroah-Hartman wrote: From: Greg Kroah-Hartman gre...@linuxfoundation.org Convert all USB gadget sysfs attributes to use the _RO or _RW variants, to make them easier to audit and ensure that the permissions are correct. Note, two are left using the DEVICE_ATTR() macro, as there is no DEVICE_ATTR_WO() in Linus's tree, that will happen after 3.12-rc1 is out, a follow-on patch will be sent then. Cc: Felipe Balbi ba...@ti.com looks good, thank you: Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com Thanks for the review. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pull Request] xhci: Bug fixes for 3.12.
On Tue, Aug 27, 2013 at 11:26:55AM -0700, Sarah Sharp wrote: The following changes since commit 154547c4fe0fbe92185e69a6cdc2b0502b361995: USB: serial: clean up attribute permissions (2013-08-25 15:12:03 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-next-2013-08-27 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] davinci: fix resources passed to MUSB driver for DM6467
On Tue, Aug 27, 2013 at 11:23:43PM +0400, Sergei Shtylyov wrote: Hello. On 08/12/2013 12:20 AM, Sergei Shtylyov wrote: After commit 09fc7d22b024692b2fe8a943b246de1af307132b (usb: musb: fix incorrect usage of resource pointer), CPPI DMA driver on DaVinci DM6467 can't detect its dedicated IRQ and so the MUSB IRQ is erroneously used instead. This is because only 2 resources are passed to the MUSB driver from the DaVinci glue layer, so fix this by always copying 3 resources (it's safe since a placeholder for the 3rd resource is always there) and passing 'pdev-num_resources' instead of the size of musb_resources[] to platform_device_add_resources(). Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- The patch is against the 'fixes' branch of Felipe Balbi's 'usb.git' repo. Felipe, are you going to apply this patch at least for 3.12? I heard nothing from you for 2+ weeks... doesn't apply -- balbi signature.asc Description: Digital signature
Re: [alsa-devel] Buffer size for ALSA USB PCM audio
On Tue, 27 Aug 2013, Clemens Ladisch wrote: Alan Stern wrote: On Tue, 27 Aug 2013, Clemens Ladisch wrote: The current algorithm uses very short capture URBs to ensure that _some_ URB is completed as soon as possible after a period ends. [...] I'd suggest to keep the old calculation for capture URBs. It would make sense to use longer capture URBs only if the period size is relatively large. Okay. What about playback endpoints with implicit sync? The current driver treats them the same as capture endpoints. Is that really the right thing to do? The only reason to not have an interrupt after each packet is to avoid the interrupt overhead (for both CPU and power); shorter URBs would result in a more precise DMA position reported to user space. If there is already an interrupt for some capture URB (or for the feedback packet in case of explicit feedback), we might as well handle the playback packets so far. I don't quite understand. Are you saying that playback endpoints with implicit sync may as well use the same values for urb_packs and ep-nurbs as other playback endpoints, rather than using the values calculated for capture endpoints (which is what the current driver does)? 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: [alsa-devel] Buffer size for ALSA USB PCM audio
Alan Stern wrote: On Tue, 27 Aug 2013, Clemens Ladisch wrote: The current algorithm uses very short capture URBs to ensure that _some_ URB is completed as soon as possible after a period ends. [...] I'd suggest to keep the old calculation for capture URBs. It would make sense to use longer capture URBs only if the period size is relatively large. Okay. What about playback endpoints with implicit sync? The current driver treats them the same as capture endpoints. Is that really the right thing to do? The only reason to not have an interrupt after each packet is to avoid the interrupt overhead (for both CPU and power); shorter URBs would result in a more precise DMA position reported to user space. If there is already an interrupt for some capture URB (or for the feedback packet in case of explicit feedback), we might as well handle the playback packets so far. 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: [patch] usb: musb: unlock on error in cppi41_dma_callback()
On Wed, Aug 21, 2013 at 11:38:21AM +0300, Dan Carpenter wrote: We need to unlock and enable IRQs before returning on error. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com doesn't apply -- balbi signature.asc Description: Digital signature
[GIT PULL] USB patches for v3.12 merge window (part 2)
Hi Greg, As promissed, here's a set of important fixes for the first v3.12-rc release. If you want me to change anything, just let me know. The following changes since commit 154547c4fe0fbe92185e69a6cdc2b0502b361995: USB: serial: clean up attribute permissions (2013-08-25 15:12:03 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.12-part2 for you to fetch changes up to 0f2aa8caeaa043f6cbe6281eb72efba5ff860904: usb: musb: ux500: Add check for NULL board data (2013-08-27 15:05:39 -0500) usb: patches for v3.12 merge window (part 2) Here's a set of important fixes for v3.12 merge window which have been pending in the mailing list for quite some time. We have use-after-free fixes, signedness fixes, more of HAS_DMA dependencies, fixes for NULL pointer deferences, build fixes and some other fixes to the musb driver caused by recent patches. Patches are quite small and contain valuable fixes which will give us a much better -rc1 release. Please consider merging Signed-of-by: Felipe Balbi ba...@ti.com Anatolij Gustschin (1): usb: phy: fix build breakage Andrzej Pietrasiewicz (1): usb: gadget: configfs: keep a function if it is not successfully added Dan Carpenter (4): usb: gadget: gadgetfs: use after free in dev_release() usb: gadget: gadgetfs: potential use after free in unbind() usb: phy: signedness bugs in suspend/resume functions usb: gadget: double unlocks on error in atmel_usba_start() Geert Uytterhoeven (3): usb: gadget: USB_FUSB300 should depend on HAS_DMA usb: gadget: USB_R8A66597 should depend on HAS_DMA usb: gadget: USB_NET2272_DMA should depend on HAS_DMA Julia Lawall (1): usb: musb: dsps: fix devm_ioremap_resource error detection code Lee Jones (1): usb: musb: ux500: Add check for NULL board data Maarten ter Huurne (1): usb: musb: avoid null pointer dereference in debug logging Sachin Kamat (1): usb: dwc3: Remove duplicate inclusion of otg.h Sebastian Andrzej Siewior (11): usb: musb: honour the return value of dma_map_single() usb: phy: am335x-control: make it compile with dma: cpp41: make it compile with CONFIG_BUG=n usb: musb: only remove host/udc if it has been added usb: musb: dsps fix the typo in reg-names of the dma node usb: usb: dsps: update device tree bindings usb: usb: dsps: update code according to the binding document usb: musb: dsps: do not set is_active on the first drvbus interrupt usb: musb: am335x-evm: Do not remove the session bit HOST-only mode usb: musb: am335x: add second port to beagle bone dma: cpp41: enable pm_runtime during init Wei Yongjun (1): usb: musb: cppi41: fix missing unlock on error in cppi41_dma_callback() .../devicetree/bindings/usb/am33xx-usb.txt | 222 ++--- arch/arm/boot/dts/am335x-bone.dts | 15 +- arch/arm/boot/dts/am335x-evm.dts | 7 +- arch/arm/boot/dts/am335x-evmsk.dts | 2 +- arch/arm/boot/dts/am33xx.dtsi | 69 +++ drivers/dma/cppi41.c | 13 +- drivers/usb/dwc3/core.c| 1 - drivers/usb/gadget/Kconfig | 5 +- drivers/usb/gadget/atmel_usba_udc.c| 10 +- drivers/usb/gadget/configfs.c | 4 +- drivers/usb/gadget/f_fs.c | 2 +- drivers/usb/gadget/inode.c | 4 - drivers/usb/musb/musb_cppi41.c | 4 +- drivers/usb/musb/musb_dsps.c | 61 -- drivers/usb/musb/musb_gadget.c | 15 +- drivers/usb/musb/musb_host.c | 2 + drivers/usb/musb/ux500_dma.c | 4 +- drivers/usb/phy/phy-am335x-control.c | 4 +- drivers/usb/phy/phy-fsl-usb.h | 2 +- drivers/usb/phy/phy-fsm-usb.c | 2 +- drivers/usb/phy/phy-omap-usb2.c| 7 +- 21 files changed, 329 insertions(+), 126 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling
*Ping!* Are there still unanswered concerns left with this patch? I hope my prior mails could clear up why I think that the PMU register description in the device tree for a specific PHY is represents the hardware more accurately after my patch, and my analysis of the Exynos4 situation currently not being implemented (and therefore not needing to be addressed by this patch) was correct. Please let me know if you have further objections... and if not, could we agree to have this picked up somewhere? Thanks, Julius -- 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] davinci: fix resources passed to MUSB driver for DM6467
On 08/28/2013 12:06 AM, Felipe Balbi wrote: After commit 09fc7d22b024692b2fe8a943b246de1af307132b (usb: musb: fix incorrect usage of resource pointer), CPPI DMA driver on DaVinci DM6467 can't detect its dedicated IRQ and so the MUSB IRQ is erroneously used instead. This is because only 2 resources are passed to the MUSB driver from the DaVinci glue layer, so fix this by always copying 3 resources (it's safe since a placeholder for the 3rd resource is always there) and passing 'pdev-num_resources' instead of the size of musb_resources[] to platform_device_add_resources(). Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- The patch is against the 'fixes' branch of Felipe Balbi's 'usb.git' repo. Felipe, are you going to apply this patch at least for 3.12? I heard nothing from you for 2+ weeks... doesn't apply Which branch are you applying it to? It was against the 'fixes' branch and still should apply to it. Should I rebase to the 'next' branch? 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: [GIT PULL] USB patches for v3.12 merge window (part 2)
On Tue, Aug 27, 2013 at 03:16:05PM -0500, Felipe Balbi wrote: Hi Greg, As promissed, here's a set of important fixes for the first v3.12-rc release. If you want me to change anything, just let me know. The following changes since commit 154547c4fe0fbe92185e69a6cdc2b0502b361995: USB: serial: clean up attribute permissions (2013-08-25 15:12:03 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.12-part2 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: staging:DWC2 USB driver issues
On Tue, 2013-08-27 at 14:13 +0200, ZY - pavel wrote: On Tue 2013-08-27 12:22:59, Matthijs Kooijman wrote: Hi Dinh, Any chance anyone has a similar experience with this DWC2 driver, any help will greatly appreciated. Of course, I will go back and verify the initialization between the DWC2 and the old driver to see if I can spot anything. At first glance, the symptoms (getting transaction errors on every transaction attempt) looks similar to what I was seeing a while back: http://comments.gmane.org/gmane.linux.usb.general/86117 Thanks for the pointer. However, in my case it seems there was some hardware issue (possibly even a hardware fault in a single unit) that caused it, so I doubt this will really help you... What hardware are you working with? Very probably Altera Socfpga Cyclone V board. Yes, I am working on the Altera Socfpga Cyclone V devkit. It appears that I did get the driver to work. The old driver had set the TX/RX FIFO to 512, so I also modified the DWC2 driver to 512, then slowly walked it up to 2560. This appears to be threshold for the TX/RX FIFO on the SOCFPGA sytem. params-enable_dynamic_fifo = 1; params-host_rx_fifo_size = 0xa00; params-host_nperio_tx_fifo_size = 0xa00; params-host_perio_tx_fifo_size = 0xa00; I still have to force the driver into Host Mode. I pushed a branch to git://git.rocketboards.org/linux-socfpga-next.git socfpga-3.10_dwc2, in case you're interested. Also, the driver does not support Split Transactions yet in DMA mode right? Thanks, Dinh Pavel -- 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 0/2] Various fixes for dummy_hcd driver
These two patches fix some minor issues in the dummy_hcd driver. Both errors were detected with the help of coverity analysis. Philippe De Swert (2): usb:gadget:dummy_hcd : Avoid infinite loop usb:gadget:dummy_hcd : Detect port and link state correctly to avoid unreachable code drivers/usb/gadget/dummy_hcd.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- 1.8.1.2 -- 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:gadget:dummy_hcd : Avoid infinite loop
When an error occurs adding a platform device there is a risk of an infinite
loop.
If more than one platform device was added i will remain = than 0. The
intention seems
to clean up all the different already added platform devices before the failure
occurs,
so fixed the code to actually do so. We decrement first because the adding at
the current
index of i is the one that failed.
Found with coverity : CID 751073
Signed-off-by: Philippe De Swert philippe.desw...@jollamobile.com
---
drivers/usb/gadget/dummy_hcd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index c588e8e..5c506fb 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -2705,9 +2705,10 @@ static int __init init(void)
for (i = 0; i mod_data.num; i++) {
retval = platform_device_add(the_udc_pdev[i]);
if (retval 0) {
- i--;
- while (i = 0)
+ while (i = 0) {
+ i--;
platform_device_del(the_udc_pdev[i]);
+ }
goto err_add_udc;
}
}
--
1.8.1.2
--
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:gadget:dummy_hcd : Detect port and link state correctly to avoid unreachable code
Since USB_SS_PORT_LS_U0 is 0x the operation with the port state would always be 0. Thus the if would never be true. The code tries to check if the port is enabled and link is active (U0 state). This means the port_status should be 0x0001, so the right check is an | with USB_SS_PORT_LS_U0. Found with coverity: CID 744367, CID 145679 Signed-off-by: Philippe De Swert philippe.desw...@jollamobile.com --- drivers/usb/gadget/dummy_hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c index 5c506fb..22cd01c 100644 --- a/drivers/usb/gadget/dummy_hcd.c +++ b/drivers/usb/gadget/dummy_hcd.c @@ -313,7 +313,7 @@ static void set_link_state_by_speed(struct dummy_hcd *dum_hcd) (USB_PORT_STAT_C_CONNECTION 16); if ((dum_hcd-port_status USB_PORT_STAT_ENABLE) == 1 - (dum_hcd-port_status + (dum_hcd-port_status | USB_SS_PORT_LS_U0) == 1 dum_hcd-rh_state != DUMMY_RH_SUSPENDED) dum_hcd-active = 1; -- 1.8.1.2 -- 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: staging:DWC2 USB driver issues
From: Dinh Nguyen [mailto:dingu...@altera.com] Sent: Tuesday, August 27, 2013 2:09 PM On Tue, 2013-08-27 at 14:13 +0200, ZY - pavel wrote: On Tue 2013-08-27 12:22:59, Matthijs Kooijman wrote: What hardware are you working with? Very probably Altera Socfpga Cyclone V board. Yes, I am working on the Altera Socfpga Cyclone V devkit. It appears that I did get the driver to work. The old driver had set the TX/RX FIFO to 512, so I also modified the DWC2 driver to 512, then slowly walked it up to 2560. This appears to be threshold for the TX/RX FIFO on the SOCFPGA sytem. params-enable_dynamic_fifo = 1; params-host_rx_fifo_size = 0xa00; params-host_nperio_tx_fifo_size = 0xa00; params-host_perio_tx_fifo_size = 0xa00; I still have to force the driver into Host Mode. I pushed a branch to git://git.rocketboards.org/linux-socfpga-next.git socfpga-3.10_dwc2, in case you're interested. Also, the driver does not support Split Transactions yet in DMA mode right? It does support splits in DMA mode. Splits in Descriptor DMA mode don't work because the HW does not support that. -- Paul
Re: Memory synchronization vs. interrupt handlers
On Mon, Aug 26, 2013 at 11:49:15AM -0400, Alan Stern wrote: David and Paul: Here's a question that doesn't seem to be answered in Documentation/memory-barriers.txt. Are memory accesses within an interrupt handler synchronized with respect to interrupts? In more detail, suppose we have an interrupt handler that uses a memory variable A. The device attached to the IRQ line sends two interrupt requests, and we get: CPU 0 CPU 1 - - Receive IRQ Call the interrupt handler Write A Finish IRQ processing Receive IRQ Call the interrupt handler Read A Finish IRQ processing Is CPU 0's write to A guaranteed to be visible on CPU 1? Given that interrupts on an IRQ line are serialized, and that IRQ processing must involve some amount of memory barriers, I would expect the answer to be Yes. I have no idea. I would hope that it did, but a lot depends on how or whether the end-of-interrupt processing is handled by the I/O hardware. Does the answer change if the IRQ line is shared? I wouldn't expect it to be. Now, if the handler were bound to multiple IRQ (or MSI) lines, then there'd be no reason to expect this to work. However, even in this case, it seems that as long as we restrict our attention to handler invocations in response to interrupt requests from one particular IRQ line, the answer should be Yes. (For example, if device X on IRQ I and device Y on IRQ J both used the same handler, a write to A in response to an interrupt from device X should be visible the next time X sends an interrupt.) Do you know the answers? I believe that we need to ask the architecture maintainers. And maybe also someone who knows about the devices in question. Thanx, Paul -- 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: OHCI: Allow runtime PM without system sleep
On Mon, Aug 26, 2013 at 03:01:40PM -0400, Alan Stern wrote: Since ohci-hcd supports runtime PM, the .pm field in its pci_driver structure should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. Without this change, OHCI controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by: Alan Stern st...@rowland.harvard.edu cc: sta...@vger.kernel.org --- Greg: I marked this for -stable because it fixes a bug. But the bug is a benign one (under some configs, OHCI controllers won't go to low power at times when they could) and nobody has complained about it. You can decide whether or not this is really suitable for the stable kernels. Thanks, this seems like it would be good for stable kernels, so I left it in. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
