Re: USB instabilities with Atheros AR9344
Thank you very much for another detailed reply. On Sat, Nov 30, 2013 at 4:55 PM, Alan Stern st...@rowland.harvard.edu wrote: By device, I mean the piece of hardware that is supposed to reply to the host. In your case that would be the modem (the hub does not make up replies to packets that were sent to the modem). On the other hand, it is true that in some circumstances, problems in the hub could mess up communications between the host and the modem. This could happen if the hub communicates at high speed (480 Mb/s) and the modem communicates at full speed (12 Mb/s). Thanks for this pointer. It turns out there was one detail I had completely overlooked. Even though I used different modems, they are all based on the same chipset (Qualcomm's MDM9200). Since I did not see this issue on with another SoC, I doubt it is a chipset-issue, but it is worth investigating. Both modems and hub are high-speed (and they are enumerated as high-speed), so that part should be fine. Thanks again, Kristian -- 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: some question about period scheduleing
On Sun, 1 Dec 2013, vichy wrote: hi Alan: 2013/12/1 Alan Stern st...@rowland.harvard.edu: On Fri, 29 Nov 2013, vichy wrote: hi all: My connection like below ehci -- high speed hub - full speed device I have some questions about period scheduling. 1. when creating qh for full speed device, why we set EHCI_TUNE_RL_TT. Are you asking why EHCI_TUNE_RL_TT is equal to 0? I don't know -- it looks like a mistake. Do you find that changing it to 3 makes any difference? Yes, when I change EHCI_TUNE_RL_TT as not 0. The transaction can keep going. But if EHCI_TUNE_RL_TT is 0, the transfer doesn't work? isn't it possible the full speed device return NAK during transaction? Of course it is possible. If so, why we use EHCI_TUNE_RL_TT default as 0? Like I said above, I don't know -- it looks like a mistake. 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: some question about EXDEV status in period schedule
On Sun, 1 Dec 2013, yoma sophian wrote: Suppose itds are submitted then ehci_work is triggered by bulk interrupt and ehci-isoc_count 0. The race condition may happen if hardware hasn't handled those itds, right? I don't know what race condition you are talking about. Please explain in more detail. 1. submit iso urbs ehci-periodic_count ++ 2. interrupt for bulk happen 3. scan async 4. scan iso schedule, since ehci-periodic_count != 0 5. clear urb if host hasn't enough time to handle it This isn't a race condition, because the driver does not terminate isochronous URBs before they are scheduled to end. For example, suppose there was an isochronous URB that was scheduled to transmit packets during microframes 100, 180, 260, and 340. If an interrupt for a bulk URB happens during microframe 212, the driver will not terminate the isochronous URB, because it is not scheduled to end yet. But if an interrupt for a bulk URB happens during microframe 347, then the driver will terminate the isochronous URB, because that is after the scheduled end (which is microframe 340). If the periodic count has just dropped to 0, it's quite likely that the periodic count will increase again in the near future. Therefore the driver leaves the periodic schedule running for a little while. That's better than stopping the schedule and starting it again a few milliseconds later. why in the previous kernel version, take v3.1-rc1 for example, turn off period schedule directly? I don't know why; I didn't write that code in the earlier kernels. is there any bug then we change the turn off policy? No, it was not a bug. The new code is an improvement, that's all. 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
xhci regression: usb 3.0 hdd disconnects immediately
Hi folks. I have received a new dell precision 4800 with USB 3.0. I've compiled the gentoo for it. Currently I run Linux genlap 3.12.1-gentoo #23 SMP Sat Nov 30 19:47:03 CET 2013 x86_64 Intel(R) Core(TM) i7-4900MQ CPU @ 2.80GHz GenuineIntel GNU/Linux I have problems connecting my usb 3.0 external drive which works on ubuntu with kernel Linux vdr 3.8.0-33-generic #48~precise1-Ubuntu SMP Thu Oct 24 16:28:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux very well. This i what here happens when i connect it to my laptop [19880.463997] usb 2-5: new SuperSpeed USB device number 6 using xhci_hcd [19880.475685] usb 2-5: New USB device found, idVendor=152d, idProduct=0539 [19880.475689] usb 2-5: New USB device strings: Mfr=1, Product=11, SerialNumber=3 [19880.475690] usb 2-5: Product: USB3.0 Device [19880.475692] usb 2-5: Manufacturer: JMicron [19880.475693] usb 2-5: SerialNumber: BBA000BF [19880.476213] usb 2-5: Set SEL for device-initiated U1 failed. [19885.481844] usb 2-5: Set SEL for device-initiated U2 failed. [19885.481942] usb-storage 2-5:1.0: USB Mass Storage device detected [19885.481994] scsi15 : usb-storage 2-5:1.0 [19890.487903] usb 2-5: Set SEL for device-initiated U1 failed. [19895.493882] usb 2-5: Set SEL for device-initiated U2 failed. [19909.699012] zeitgeist-daemo[15893]: segfault at 0 ip 7fc610ad7f0a sp 7fffdf12b7c0 error 4 in libglib-2.0.so.0.3800.2[7fc610a51000+126000] [19917.931018] usb 2-5: reset SuperSpeed USB device number 6 using xhci_hcd [19917.952026] usb 2-5: device descriptor read/8, error -71 [19918.052803] usb 2-5: reset SuperSpeed USB device number 6 using xhci_hcd [19918.074425] usb 2-5: device descriptor read/8, error -71 [19918.252099] usb 2-5: USB disconnect, device number 6 [19918.252138] scsi 15:0:0:0: Device offlined - not ready after error recovery [19918.252374] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88041f86a480 [19918.252377] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88041f86a4c0 Pleas check this, thi seems to be the exact same problem, but on ubuntu https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1254261 Is there any problem with usb 3.0 Support newest kernels? With regards, Lado -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
On Saturday, November 30, 2013 06:20 PM, Peter Chen wrote:
usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
* init the sts flag to 0 (missed)
* Set PORTCS_STS only if VUSB_HS_PHY_TYPE 1
otherwise the register is ReadOnly
* Set/Reset correct BIT(28)/BIT(29) for STS
Signed-off-by: Chris Ruehlchris.ru...@gtsys.com.hk
---
drivers/usb/chipidea/core.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5075407..2c634c1 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -243,7 +243,7 @@ static int hw_device_init(struct ci_hdrc *ci, void
__iomem *base)
static void hw_phymode_configure(struct ci_hdrc *ci)
{
- u32 portsc, lpm, sts;
+ u32 portsc, lpm, sts = 0;
switch (ci-platdata-phy_mode) {
case USBPHY_INTERFACE_MODE_UTMI:
@@ -273,10 +273,24 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
- hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+ if ( sts )
+ hw_write(ci, OP_DEVLC, DEVLC_STS, BIT(28));
+ else
+ hw_write(ci, OP_DEVLC, DEVLC_STS, ~BIT(28));
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
- hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+ if (((portsc 30) 0x3) 1) {
+ if (sts) {
+ hw_write(ci, OP_PORTSC, PORTSC_STS, BIT(29));
+ }
+ else {
+ portsc =
(ioread32(ci-hw_bank.regmap[OP_PORTSC])
+ PORTSC_STS);
+ if (portsc)
+ hw_write(ci, OP_PORTSC, PORTSC_STS,
+ ~BIT(29));
+ }
+ }
}
}
--
At my chipidea datasheet, the VUSB_HS_PHY_SERIAL is at HWGENERAL (bit[10..11]),
We are still not sure the portsc_sts is needed to set or clear, and how to do
it. My suggestion is just use v2 patch (except fixing one code style problem)
Peter
Peter,
Thanks you for your comments.
If you have a look into the function hw_write() you will see that there is no
effect if hw_write(...,sts) is called with sts=0/1, because the mask will cut
off all bits beside BIT(29).
I used BIT(29) rather then PORTCS_STS to make it more clear what going on.
A write to PORTCS will always be 0 for the STS Register no matter if sts is 1
or 0 within Patch v2. Patch v3 will take care of the registers bit position and
set 1 or 0 to PORTCS_STS.
I used the imx27 reference manual Capital 30.8.1.5.12 PORTSCx.
Please comment.
Chris
--
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 1/2] lib/scatterlist: export sg_miter_skip()
On Sat, Nov 30, 2013 at 6:23 AM, Tejun Heo t...@kernel.org wrote: On Tue, Nov 26, 2013 at 12:43:37PM +0800, Ming Lei wrote: sg_copy_buffer() can't meet demand for some drrivers(such usb mass storage), so we have to use the sg_miter_* APIs to access sg buffer, then need export sg_miter_skip() for these drivers. The API is needed for converting to sg_miter_* APIs in USB storage driver for accessing sg buffer. Acked-by: Andrew Morton a...@linux-foundation.org Cc: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Cc: Tejun Heo t...@kernel.org Cc: Jens Axboe ax...@kernel.dk Signed-off-by: Ming Lei ming@canonical.com Reviewed-by: Tejun Heo t...@kernel.org Thanks. I suppose this should go through -mm? Last round, Andrew said it can be though whatever tree, so given dependency reason, it is better to merge via greg's tree. Greg, could you merge these two patches via your usb-next tree? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/2] lib/scatterlist: export sg_miter_skip()
On Mon, Dec 02, 2013 at 10:11:21AM +0800, Ming Lei wrote: On Sat, Nov 30, 2013 at 6:23 AM, Tejun Heo t...@kernel.org wrote: On Tue, Nov 26, 2013 at 12:43:37PM +0800, Ming Lei wrote: sg_copy_buffer() can't meet demand for some drrivers(such usb mass storage), so we have to use the sg_miter_* APIs to access sg buffer, then need export sg_miter_skip() for these drivers. The API is needed for converting to sg_miter_* APIs in USB storage driver for accessing sg buffer. Acked-by: Andrew Morton a...@linux-foundation.org Cc: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Cc: Tejun Heo t...@kernel.org Cc: Jens Axboe ax...@kernel.dk Signed-off-by: Ming Lei ming@canonical.com Reviewed-by: Tejun Heo t...@kernel.org Thanks. I suppose this should go through -mm? Last round, Andrew said it can be though whatever tree, so given dependency reason, it is better to merge via greg's tree. Greg, could you merge these two patches via your usb-next tree? Yes, will do. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: phy-mxs-usb: Check the return value from clk_prepare_enable()
From: Fabio Estevam fabio.este...@freescale.com
clk_prepare_enable() may fail, so let's check its return value and propagate it
in the case of error.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/usb/phy/phy-mxs-usb.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 545844b..2d0bc5a 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -63,9 +63,13 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
static int mxs_phy_init(struct usb_phy *phy)
{
+ int ret;
struct mxs_phy *mxs_phy = to_mxs_phy(phy);
- clk_prepare_enable(mxs_phy-clk);
+ ret = clk_prepare_enable(mxs_phy-clk);
+ if (ret)
+ return ret;
+
return mxs_phy_hw_init(mxs_phy);
}
@@ -81,6 +85,7 @@ static void mxs_phy_shutdown(struct usb_phy *phy)
static int mxs_phy_suspend(struct usb_phy *x, int suspend)
{
+ int ret;
struct mxs_phy *mxs_phy = to_mxs_phy(x);
if (suspend) {
@@ -89,7 +94,9 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
x-io_priv + HW_USBPHY_CTRL_SET);
clk_disable_unprepare(mxs_phy-clk);
} else {
- clk_prepare_enable(mxs_phy-clk);
+ ret = clk_prepare_enable(mxs_phy-clk);
+ if (ret)
+ return ret;
writel(BM_USBPHY_CTRL_CLKGATE,
x-io_priv + HW_USBPHY_CTRL_CLR);
writel(0, x-io_priv + HW_USBPHY_PWD);
--
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: [PATCH] usb: phy: phy-mxs-usb: Check the return value from clk_prepare_enable()
clk_prepare_enable() may fail, so let's check its return value and
propagate it
in the case of error.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/usb/phy/phy-mxs-usb.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-
usb.c
index 545844b..2d0bc5a 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -63,9 +63,13 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
static int mxs_phy_init(struct usb_phy *phy)
{
+ int ret;
struct mxs_phy *mxs_phy = to_mxs_phy(phy);
- clk_prepare_enable(mxs_phy-clk);
+ ret = clk_prepare_enable(mxs_phy-clk);
+ if (ret)
+ return ret;
+
return mxs_phy_hw_init(mxs_phy);
}
@@ -81,6 +85,7 @@ static void mxs_phy_shutdown(struct usb_phy *phy)
static int mxs_phy_suspend(struct usb_phy *x, int suspend)
{
+ int ret;
struct mxs_phy *mxs_phy = to_mxs_phy(x);
if (suspend) {
@@ -89,7 +94,9 @@ static int mxs_phy_suspend(struct usb_phy *x, int
suspend)
x-io_priv + HW_USBPHY_CTRL_SET);
clk_disable_unprepare(mxs_phy-clk);
} else {
- clk_prepare_enable(mxs_phy-clk);
+ ret = clk_prepare_enable(mxs_phy-clk);
+ if (ret)
+ return ret;
writel(BM_USBPHY_CTRL_CLKGATE,
x-io_priv + HW_USBPHY_CTRL_CLR);
writel(0, x-io_priv + HW_USBPHY_PWD);
--
Acked-by: Peter Chen peter.c...@freescale.com
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
On Monday, December 02, 2013 01:10 PM, Peter Chen wrote:
If you have a look into the function hw_write() you will see that there
is no
effect if hw_write(...,sts) is called with sts=0/1, because the mask will
cut
off all bits beside BIT(29).
Yes, it is my careless. I thought sts is PORTCS_STS.
I used BIT(29) rather then PORTCS_STS to make it more clear what going on.
It is not a good coding style, you do need use MACRO to instead of raw number
directly.
A write to PORTCS will always be 0 for the STS Register no matter if
sts is 1
or 0 within Patch v2. Patch v3 will take care of the registers bit
position and
set 1 or 0 to PORTCS_STS.
My suggestion like below:
if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
- hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+ if (sts)
+ hw_write(ci, OP_DEVLC, DEVLC_STS, DEVLC_STS);
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
- hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+ if (sts)
+ hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
}
I think we just need to fix the original bug, and do not add any new fixes
since we don't know which one is correct for every platform. My proposal is
just set PORTSC_STS (DEVLC_STS is lpm) if it is serial PHY. For any other PHYS,
just keep
the reset value.
Peter
I used the imx27 reference manual Capital 30.8.1.5.12 PORTSCx.
I can follow your arguments, ACK.
I prepare a patch set with this solution if not other people have better
ideas.
Chris
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] usb: phy-ulpi: Add EXTVBUSIND,CHRGVBUS flag support
usb: phy-ulpi: Add EXTVBUSIND,CHRGVBUS flag support
ULPI like ISP1504 support external vbus power indication
used in combination with vbus switches mic2075.
Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk
---
drivers/usb/phy/phy-ulpi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-ulpi.c b/drivers/usb/phy/phy-ulpi.c
index 217339d..e2f15c4 100644
--- a/drivers/usb/phy/phy-ulpi.c
+++ b/drivers/usb/phy/phy-ulpi.c
@@ -180,6 +180,8 @@ static int ulpi_init(struct usb_phy *phy)
int i, vid, pid, ret;
u32 ulpi_id = 0;
+ pr_info(ULPI Viewport 0x%p\n,phy-io_priv);
+
for (i = 0; i 4; i++) {
ret = usb_phy_io_read(phy, ULPI_PRODUCT_ID_HIGH - i);
if (ret 0)
@@ -237,7 +239,8 @@ static int ulpi_set_vbus(struct usb_otg *otg, bool on)
struct usb_phy *phy = otg-phy;
unsigned int flags = usb_phy_io_read(phy, ULPI_OTG_CTRL);
- flags = ~(ULPI_OTG_CTRL_DRVVBUS | ULPI_OTG_CTRL_DRVVBUS_EXT);
+ flags = ~(ULPI_OTG_CTRL_DRVVBUS | ULPI_OTG_CTRL_DRVVBUS_EXT |
+ ULPI_OTG_CTRL_EXTVBUSIND | ULPI_OTG_CTRL_CHRGVBUS);
if (on) {
if (phy-flags ULPI_OTG_DRVVBUS)
@@ -245,6 +248,12 @@ static int ulpi_set_vbus(struct usb_otg *otg, bool on)
if (phy-flags ULPI_OTG_DRVVBUS_EXT)
flags |= ULPI_OTG_CTRL_DRVVBUS_EXT;
+
+ if (phy-flags ULPI_OTG_EXTVBUSIND)
+ flags |= ULPI_OTG_CTRL_EXTVBUSIND;
+
+ if (phy-flags ULPI_OTG_CHRGVBUS)
+ flags |= ULPI_OTG_CTRL_CHRGVBUS;
}
return usb_phy_io_write(phy, flags, ULPI_OTG_CTRL);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
