Re: [PATCH v3 1/2] make xhci platform driver use 64 bit or 32 bit DMA
Hi Greg, On Wed, Jul 29, 2015 at 10:18 PM, Loc Ho l...@apm.com wrote: Hi, The xhci platform driver needs to work on systems that either only support 64-bit DMA or only support 32-bit DMA. Attempt to set a coherent dma mask for 64-bit DMA, and attempt again with 32-bit DMA if that fails. Signed-off-by: Mark Langsdorf mlang...@redhat.com Tested-by: Mark Salter msal...@redhat.com --- Changes from v2: None Changes from v1: Consolidated to use dma_set_mask_and_coherent Got rid of the check against sizeof(dma_addr_t) drivers/usb/host/xhci-plat.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) Any reason why this isn't pulled in already? It is already 6 months and seems to be ack'ed already. Does it work for you on 4.2-rc4? Is it still needed? Care to repost the whole patch updated? I tested this v3 patch set with 4.2-rc5 and it works fine on my X-Gene arm64 platform. The only problem is 'git am' will complain (due to line offset changed, I guess). Using 'patch -p 1' to apply the 2 patches is fine. I will repost the whole set over 4.2-rc5. Let me apply and see if it still work as is. -Loc -- Regards, Duc Dang. -- 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 v4 1/2] usb: make xhci platform driver use 64 bit or 32 bit DMA
The xhci platform driver needs to work on systems that
either only support 64-bit DMA or only support 32-bit DMA.
Attempt to set a coherent dma mask for 64-bit DMA, and
attempt again with 32-bit DMA if that fails.
[dhdang: regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Tested-by: Mark Salter msal...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v3:
Re-generate the patch over 4.2-rc5
No code change.
Changes from v2:
None
Changes from v1:
Consolidated to use dma_set_mask_and_coherent
Got rid of the check against sizeof(dma_addr_t)
drivers/usb/host/xhci-plat.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 890ad9d..5d03f8b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -93,14 +93,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq 0)
return -ENODEV;
- /* Initialize dma_mask and coherent_dma_mask to 32-bits */
- ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
- if (ret)
- return ret;
- if (!pdev-dev.dma_mask)
- pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
- else
- dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
+ if (ret) {
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+ }
+
hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd)
--
1.9.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 v4 2/2] usb: Add support for ACPI identification to xhci-platform
Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.
This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.
[dhdang: regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v3:
Regenerate the patch over 4.2-rc5
No code change
Changes from v2
Replaced tristate with a boolean as the driver doesn't
compile as a module
Correct --help-- to ---help---
Changes from v1
Renamed from add support for APM X-Gene to xhci-platform
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
drivers/usb/host/Kconfig | 7 ++-
drivers/usb/host/xhci-plat.c | 11 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..96231ee 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -32,7 +32,12 @@ config USB_XHCI_PCI
default y
config USB_XHCI_PLATFORM
- tristate
+ tristate xHCI platform driver support
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
config USB_XHCI_MVEBU
tristate xHCI support for Marvell Armada 375/38x
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5d03f8b..14b40d2 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
#include linux/usb/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
+#include linux/acpi.h
#include xhci.h
#include xhci-mvebu.h
@@ -262,6 +263,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
#endif
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* APM X-Gene USB Controller */
+ { PNP0D10, },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+#endif
+
static struct platform_driver usb_xhci_driver = {
.probe = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -269,6 +279,7 @@ static struct platform_driver usb_xhci_driver = {
.name = xhci-hcd,
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+ .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
};
MODULE_ALIAS(platform:xhci-hcd);
--
1.9.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 v4 2/2] usb: Add support for ACPI identification to xhci-platform
On Fri, Aug 07, 2015 at 06:03:36PM -0700, Duc Dang wrote:
Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.
This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.
[dhdang: regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v3:
Regenerate the patch over 4.2-rc5
No code change
Changes from v2
Replaced tristate with a boolean as the driver doesn't
compile as a module
Correct --help-- to ---help---
Changes from v1
Renamed from add support for APM X-Gene to xhci-platform
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
drivers/usb/host/Kconfig | 7 ++-
drivers/usb/host/xhci-plat.c | 11 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..96231ee 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -32,7 +32,12 @@ config USB_XHCI_PCI
default y
config USB_XHCI_PLATFORM
- tristate
+ tristate xHCI platform driver support
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
config USB_XHCI_MVEBU
tristate xHCI support for Marvell Armada 375/38x
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5d03f8b..14b40d2 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
#include linux/usb/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
+#include linux/acpi.h
#include xhci.h
#include xhci-mvebu.h
@@ -262,6 +263,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
#endif
+#ifdef CONFIG_ACPI
You shoudn't need this #ifdef, right?
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 v4 2/2] usb: Add support for ACPI identification to xhci-platform
On Fri, Aug 7, 2015 at 6:29 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Aug 07, 2015 at 06:03:36PM -0700, Duc Dang wrote:
Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.
This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.
[dhdang: regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v3:
Regenerate the patch over 4.2-rc5
No code change
Changes from v2
Replaced tristate with a boolean as the driver doesn't
compile as a module
Correct --help-- to ---help---
Changes from v1
Renamed from add support for APM X-Gene to xhci-platform
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
drivers/usb/host/Kconfig | 7 ++-
drivers/usb/host/xhci-plat.c | 11 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..96231ee 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -32,7 +32,12 @@ config USB_XHCI_PCI
default y
config USB_XHCI_PLATFORM
- tristate
+ tristate xHCI platform driver support
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
config USB_XHCI_MVEBU
tristate xHCI support for Marvell Armada 375/38x
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5d03f8b..14b40d2 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
#include linux/usb/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
+#include linux/acpi.h
#include xhci.h
#include xhci-mvebu.h
@@ -262,6 +263,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
#endif
+#ifdef CONFIG_ACPI
You shoudn't need this #ifdef, right?
You are correct, Greg.
I will post a new version that remove this #ifdef CONFIG_ACPI shortly
thanks,
greg k-h
--
Regards,
Duc Dang.
--
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 v5 1/2] usb: make xhci platform driver use 64 bit or 32 bit DMA
The xhci platform driver needs to work on systems that
either only support 64-bit DMA or only support 32-bit DMA.
Attempt to set a coherent dma mask for 64-bit DMA, and
attempt again with 32-bit DMA if that fails.
[dhdang: Regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Tested-by: Mark Salter msal...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v4:
None
Changes from v3:
Re-generate the patch over 4.2-rc5
No code change.
Changes from v2:
None
Changes from v1:
Consolidated to use dma_set_mask_and_coherent
Got rid of the check against sizeof(dma_addr_t)
drivers/usb/host/xhci-plat.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 890ad9d..5d03f8b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -93,14 +93,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq 0)
return -ENODEV;
- /* Initialize dma_mask and coherent_dma_mask to 32-bits */
- ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
- if (ret)
- return ret;
- if (!pdev-dev.dma_mask)
- pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
- else
- dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
+ if (ret) {
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+ }
+
hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd)
--
1.9.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 v5 2/2] usb: Add support for ACPI identification to xhci-platform
Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.
This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v4:
Remove #ifdef CONFIG_ACPI
Changes from v3:
Regenerate the patch over 4.2-rc5
No code change
Changes from v2
Replaced tristate with a boolean as the driver doesn't
compile as a module
Correct --help-- to ---help---
Changes from v1
Renamed from add support for APM X-Gene to xhci-platform
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
drivers/usb/host/Kconfig | 7 ++-
drivers/usb/host/xhci-plat.c | 9 +
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..96231ee 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -32,7 +32,12 @@ config USB_XHCI_PCI
default y
config USB_XHCI_PLATFORM
- tristate
+ tristate xHCI platform driver support
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
config USB_XHCI_MVEBU
tristate xHCI support for Marvell Armada 375/38x
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5d03f8b..bd282cd 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
#include linux/usb/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
+#include linux/acpi.h
#include xhci.h
#include xhci-mvebu.h
@@ -262,6 +263,13 @@ static const struct of_device_id usb_xhci_of_match[] = {
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
#endif
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* APM X-Gene USB Controller */
+ { PNP0D10, },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+
static struct platform_driver usb_xhci_driver = {
.probe = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -269,6 +277,7 @@ static struct platform_driver usb_xhci_driver = {
.name = xhci-hcd,
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+ .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
};
MODULE_ALIAS(platform:xhci-hcd);
--
1.9.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 v4 2/2] usb: Add support for ACPI identification to xhci-platform
Hello Greg,
On Sat, Aug 8, 2015 at 3:29 AM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Aug 07, 2015 at 06:03:36PM -0700, Duc Dang wrote:
Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.
This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.
[dhdang: regenerate the patch over 4.2-rc5]
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v3:
Regenerate the patch over 4.2-rc5
No code change
Changes from v2
Replaced tristate with a boolean as the driver doesn't
compile as a module
Correct --help-- to ---help---
Changes from v1
Renamed from add support for APM X-Gene to xhci-platform
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
drivers/usb/host/Kconfig | 7 ++-
drivers/usb/host/xhci-plat.c | 11 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..96231ee 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -32,7 +32,12 @@ config USB_XHCI_PCI
default y
config USB_XHCI_PLATFORM
- tristate
+ tristate xHCI platform driver support
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
config USB_XHCI_MVEBU
tristate xHCI support for Marvell Armada 375/38x
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5d03f8b..14b40d2 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
#include linux/usb/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
+#include linux/acpi.h
#include xhci.h
#include xhci-mvebu.h
@@ -262,6 +263,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
#endif
+#ifdef CONFIG_ACPI
You shoudn't need this #ifdef, right?
Why it is not needed?
The driver does .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match) and
ACPI_PTR() is NULL if CONFIG_ACPI is not enabled. Which can happen
AFAIU since the driver also supports OF. So without the #ifdef guards,
.acpi_match_table = NULL and the struct acpi_device_id
usb_xhci_acpi_match[] will be built but not used.
Or am I missing something?
thanks,
greg k-h
Best regards,
Javier
--
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 v3] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
On Fri, Aug 07, 2015 at 09:48:19PM +0300, Tal Shorer wrote: On Fri, Aug 7, 2015 at 9:40 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 07, 2015 at 09:16:00PM +0300, Tal Shorer wrote: From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Still does not look correct to me, how about you? Not sure what you mean. This is a simple copy-paste from the spec document. Do you want me to put quotation marks around the multi-word Data column? I want the columns to line up so that they look sane and someone can understand what they mean :) -- 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: [ANNOUNCE] tree closed for v4.3 merge window
On Thu, Aug 6, 2015 at 9:40 AM, Felipe Balbi ba...@ti.com wrote: Hi folks, if your patches aren't in my tree yet, it's too late, sorry. We have a total of 145 non-merge commits, here's dirstat: $ git diff --dirstat next ^cbfe8fa6cd67 | sort -rn 21.0% drivers/usb/gadget/udc/ 19.9% drivers/usb/musb/ 12.9% drivers/usb/phy/ 11.7% drivers/usb/gadget/legacy/ 7.8% drivers/usb/gadget/ 6.1% drivers/usb/gadget/function/ 5.7% drivers/usb/dwc3/ 5.0% include/linux/usb/ 4.0% drivers/usb/ 3.1% Documentation/devicetree/bindings/usb/ My tree will soak a bit on linux-next to catch any further build regressions (I couldn't find anything missing after the recent 4 patches I sent) and next week a pull request will be sent to Greg. Please, avoid sending patches until v4.3-rc1 is tagged as that goes a long way towards keeping my sanity ;-) I'm not sure I understand. What about discussion of USB patches for the next release? Can we send RFC patches amongst ourselves to the linux-usb list? -- Tim Bird Senior Software Engineer, Sony Mobile Architecture Group Chair, CE Workgroup, Linux Foundation -- 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
[GIT PULL] USB driver fixes for 4.2-rc6
The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f: Linux 4.2-rc4 (2015-07-26 12:26:21 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.2-rc6 for you to fetch changes up to 0a1b6f63198f6e51d12c8d8c4ed4e7d759b3b73d: Merge tag 'phy-for-4.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus (2015-08-05 10:12:23 -0700) USB fixes for 4.2-rc6 Here are some USB and PHY fixes for 4.2-rc6 that resolve some reported issues. All of these have been in the linux-next tree for a while, full details on the patches are in the shortlog below. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Al Cooper (1): usb: gadget: bdc: fix a driver crash on disconnect Alan Stern (1): usb: udc: core: add device_del() call to error pathway Andrzej Pietrasiewicz (2): usb: gadget: f_hid: actually limit the number of instances usb: gadget: f_printer: actually limit the number of instances Dirk Behme (1): USB: sierra: add 1199:68AB device ID Gavin Shan (1): drivers/usb: Delete XHCI command timer if necessary Greg Kroah-Hartman (5): Merge tag 'usb-ci-v4.2-rc5' of git://git.kernel.org/.../peter.chen/usb into usb-linus Merge tag 'fixes-for-v4.2-rc5' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'usb-serial-4.2-rc5' of git://git.kernel.org/.../johan/usb-serial into usb-linus Merge tag 'fixes-for-v4.2-rc6' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'phy-for-4.2-rc6' of git://git.kernel.org/.../kishon/linux-phy into usb-linus Hans de Goede (1): phy-sun4i-usb: Add missing EXPORT_SYMBOL_GPL for sun4i_usb_phy_set_squelch_detect Mathias Nyman (1): xhci: fix off by one error in TRB DMA address boundary check Peter Chen (2): usb: chipidea: ehci_init_driver is intended to call one time usb: gadget: f_uac2: fix calculation of uac2-p_interval Pieter Hollants (1): USB: qcserial: Add support for Dell Wireless 5809e 4G Modem Reinhard Speyerer (1): USB: qcserial/option: make AT URCs work for Sierra Wireless MC7305/MC7355 Roger Quadros (2): phy: ti-pipe3: i783 workaround for SATA lockup after dpll unlock/relock ARM: dts: dra7: Add syscon-pllreset syscon to SATA PHY Documentation/devicetree/bindings/phy/ti-phy.txt | 16 +++ arch/arm/boot/dts/dra7.dtsi | 1 + drivers/phy/phy-sun4i-usb.c | 1 + drivers/phy/phy-ti-pipe3.c | 61 +--- drivers/usb/chipidea/core.c | 13 - drivers/usb/chipidea/host.c | 7 ++- drivers/usb/chipidea/host.h | 6 +++ drivers/usb/gadget/function/f_hid.c | 4 ++ drivers/usb/gadget/function/f_printer.c | 10 +++- drivers/usb/gadget/function/f_uac2.c | 4 +- drivers/usb/gadget/udc/bdc/bdc_ep.c | 2 +- drivers/usb/gadget/udc/udc-core.c| 1 + drivers/usb/host/xhci-mem.c | 3 +- drivers/usb/host/xhci-ring.c | 2 +- drivers/usb/serial/option.c | 2 + drivers/usb/serial/qcserial.c| 2 +- drivers/usb/serial/sierra.c | 1 + 17 files changed, 120 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
Re: [PATCH 3/8][v2]usb:fsl:otg: Add support to add/remove usb host driver
On Wed, 15 Jul 2015, Ramneek Mehresh wrote:
Add workqueue to add/remove host driver (outside
interrupt context) upon each id change.
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
---
drivers/usb/host/ehci-fsl.c | 83
++---
drivers/usb/host/ehci-fsl.h | 20 +++
2 files changed, 84 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 5352e74..81e4bf5 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -44,6 +44,34 @@
static struct hc_driver __read_mostly fsl_ehci_hc_driver;
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
You've got these #if lines all over the place. They look ugly and make
the code hard to read. Consider removing them. Or even if you can't
remove them entirely, removing most of them would help.
Also, instead of testing both CONFIG_FSL_USB2_OTG and
CONFIG_FSL_USB2_OTG_MODULE, how about testing a single symbol? For
example:
#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
#define CHANGE_HCD 1
#else
#define CHANGE_HCD 0
#endif
Then all you need later on is #if CHANGE_HCD. Or if it's inside a
code block, just if (CHANGE_HCD).
+static struct ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
+{
+ return (struct ehci_fsl *)hcd_to_ehci(hcd)-priv;
+}
+
+static void do_change_hcd(struct work_struct *work)
+{
+ struct ehci_fsl *ehci_fsl = container_of(work, struct ehci_fsl,
+ change_hcd_work);
+ struct usb_hcd *hcd = ehci_fsl-hcd;
+ void __iomem *non_ehci = hcd-regs;
+ int retval;
+
+ if (ehci_fsl-hcd_add !ehci_fsl-have_hcd) {
+ writel(USBMODE_CM_HOST, non_ehci + FSL_SOC_USB_USBMODE);
+ /* host, gadget and otg share same int line */
+ retval = usb_add_hcd(hcd, hcd-irq, IRQF_SHARED);
+ if (retval == 0)
+ ehci_fsl-have_hcd = 1;
+ } else if (!ehci_fsl-hcd_add ehci_fsl-have_hcd) {
+ usb_remove_hcd(hcd);
+ ehci_fsl-have_hcd = 0;
Don't you have to turn off the USBMODE_CM_HOST bit here? It looks
strange to turn it on above but not turn it off again.
+ }
+}
+#endif
static int ehci_fsl_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
- struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
void __iomem *non_ehci = hcd-regs;
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+ struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
+ struct usb_bus host = hcd-self;
+#endif
+
if (of_device_is_compatible(dev-parent-of_node,
fsl,mpc5121-usb2-dr)) {
return ehci_fsl_mpc512x_drv_suspend(dev);
}
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+ if (host.is_otg) {
+ /* remove hcd */
+ ehci_fsl-hcd_add = 0;
+ schedule_work(ehci_fsl-change_hcd_work);
+ host.is_otg = 0;
Why do you set host.is_otg to 0 here? Why not do it in the work
routine?
+ return 0;
+ }
+#endif
+
ehci_prepare_ports_for_controller_suspend(hcd_to_ehci(hcd),
device_may_wakeup(dev));
if (!fsl_deep_sleep())
@@ -540,15 +571,29 @@ static int ehci_fsl_drv_suspend(struct device *dev)
static int ehci_fsl_drv_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
- struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
void __iomem *non_ehci = hcd-regs;
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+ struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
+ struct usb_bus host = hcd-self;
+#endif
if (of_device_is_compatible(dev-parent-of_node,
fsl,mpc5121-usb2-dr)) {
return ehci_fsl_mpc512x_drv_resume(dev);
}
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+ if (host.is_otg) {
+ /* add hcd */
+ ehci_fsl-hcd_add = 1;
+ schedule_work(ehci_fsl-change_hcd_work);
+ usb_hcd_resume_root_hub(hcd);
+ host.is_otg = 0;
Again, why change host.is_otg here? And for that matter, where does
host.is_otg ever get set to 1?
Also, what is the reason for calling usb_hcd_resume_root_hub()? It
won't do anything, because it will run before the scheduled work, so
there won't be a root hub for it to resume.
+ return 0;
+ }
+#endif
+
ehci_prepare_ports_for_controller_resume(ehci);
if (!fsl_deep_sleep())
return 0;
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index dbd292e..3fd1fd0
Re: [PATCH 0/2] Introduce usb charger framework to deal with the usb gadget power negotation
On Thu, Aug 06, 2015 at 03:03:47PM +0800, Baolin Wang wrote: Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not behave as they should. Providing a standard framework for doing this in the kernel. Baolin, thanks for introducing a framework for doing it, we do support USB Charger for chipidea driver at internal tree, but it is specific for imx, and still have some problems to upstream due to need to change some common code. One suggestion, would you add your user next time? In that case, we can know better for this framework. Baolin Wang (2): gadget: Introduce the usb charger framework gadget: Support for the usb charger framework drivers/usb/gadget/charger.c | 547 + drivers/usb/gadget/udc/udc-core.c | 41 +++ include/linux/usb/gadget.h| 20 ++ include/linux/usb/usb_charger.h | 101 +++ 4 files changed, 709 insertions(+) create mode 100644 drivers/usb/gadget/charger.c create mode 100644 include/linux/usb/usb_charger.h -- 1.7.9.5 -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] Introduce usb charger framework to deal with the usb gadget power negotation
Peter, Thanks for your reviewing and comments. Now I just introduce the
framework to review for more feedbacks and do not have a useful user to use
it. I just can show you some example code to show how to use it. Thanks.
Felipe may not accept the code which are no user on it, I remember he said it
before.
Besides, if no user on it, how you test it?
Peter
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH 0/2] Introduce usb charger framework to deal with the usb gadget power negotation
On 7 August 2015 at 16:31, Peter Chen peter.c...@freescale.com wrote: Peter, Thanks for your reviewing and comments. Now I just introduce the framework to review for more feedbacks and do not have a useful user to use it. I just can show you some example code to show how to use it. Thanks. Felipe may not accept the code which are no user on it, I remember he said it before. Besides, if no user on it, how you test it? Make sense of it. I'll try to build the user to test it. Thanks for your reminding. Peter -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gadget: Introduce the usb charger framework
On Thu, Aug 06, 2015 at 03:03:48PM +0800, Baolin Wang wrote:
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.
The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state.
Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.
Signed-off-by: Baolin Wang baolin.w...@linaro.org
---
drivers/usb/gadget/charger.c| 547
+++
include/linux/usb/usb_charger.h | 101
2 files changed, 648 insertions(+)
create mode 100644 drivers/usb/gadget/charger.c
create mode 100644 include/linux/usb/usb_charger.h
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
new file mode 100644
index 000..3ca0180
--- /dev/null
+++ b/drivers/usb/gadget/charger.c
@@ -0,0 +1,547 @@
+/*
+ * usb charger.c -- USB charger driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/extcon.h
+#include linux/export.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/usb.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+#include linux/usb/usb_charger.h
+
+#define DEFAULT_CUR_PROTECT (50)
+#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
+
+static LIST_HEAD(usb_charger_list);
+static DEFINE_MUTEX(usb_charger_list_lock);
+
+/*
+ * usb_charger_find_by_name - Get the usb charger device by name.
+ * @name - usb charger device name.
+ *
+ * notes: when this function walks the list and returns a charger
+ * it's dropped the lock which means that something else could come
+ * along and delete the charger before we dereference the pointer.
+ * It's very unlikely but it's a possibility so you should take care
+ * of it.
+ * Thus when you get the usb charger by name, you should call
+ * put_usb_charger() to derease the reference count of the usb charger.
+ *
+ * return the instance of usb charger device.
+ */
+struct usb_charger *usb_charger_find_by_name(char *name)
+{
+ struct usb_charger *uchger;
+
+ if (!name)
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(usb_charger_list_lock);
+ list_for_each_entry(uchger, usb_charger_list, entry) {
+ if (!strcmp(uchger-name, name)) {
+ get_usb_charger(uchger);
+ mutex_unlock(usb_charger_list_lock);
+ return uchger;
+ }
+ }
+ mutex_unlock(usb_charger_list_lock);
+
+ return NULL;
+}
+
+/*
+ * usb_charger_register_notify() - Register a notifiee to get notified by
+ * any attach status changes from the usb charger type detection.
+ * @uchger - the usb charger device which is monitored.
+ * @nb - a notifier block to be registered.
+ */
+void usb_charger_register_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(uchger-lock, flags);
+ raw_notifier_chain_register(uchger-uchger_nh, nb);
+ spin_unlock_irqrestore(uchger-lock, flags);
+}
+
+/*
+ * usb_charger_unregister_notify() - Unregister a notifiee from the usb
charger.
+ * @uchger - the usb charger device which is monitored.
+ * @nb - a notifier block to be unregistered.
+ */
+void usb_charger_unregister_notify(struct usb_charger *uchger,
+struct notifier_block *nb)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(uchger-lock, flags);
+ raw_notifier_chain_unregister(uchger-uchger_nh, nb);
+ spin_unlock_irqrestore(uchger-lock, flags);
+}
+
+/*
+ * usb_charger_register_extcon_notifier() - Register a notifiee of the usb
+ * charger to get notified by any attach status changes from
+ *
[PATCH v3 09/10] ARM: imx6: change default burst size for USB
It can improve the USB performance when choosing larger burst size at some systems (bus size is larger), there is no side effect if this burst size is larger than bus size. Signed-off-by: Peter Chen peter.c...@freescale.com --- arch/arm/boot/dts/imx6qdl.dtsi | 8 arch/arm/boot/dts/imx6sl.dtsi | 6 ++ arch/arm/boot/dts/imx6sx.dtsi | 6 ++ 3 files changed, 20 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi index 42d62b0..b9f2e3a 100644 --- a/arch/arm/boot/dts/imx6qdl.dtsi +++ b/arch/arm/boot/dts/imx6qdl.dtsi @@ -854,6 +854,8 @@ fsl,usbphy = usbphy1; fsl,usbmisc = usbmisc 0; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; @@ -866,6 +868,8 @@ fsl,usbmisc = usbmisc 1; dr_mode = host; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; @@ -877,6 +881,8 @@ fsl,usbmisc = usbmisc 2; dr_mode = host; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; @@ -888,6 +894,8 @@ fsl,usbmisc = usbmisc 3; dr_mode = host; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi index 066fac9..627549f 100644 --- a/arch/arm/boot/dts/imx6sl.dtsi +++ b/arch/arm/boot/dts/imx6sl.dtsi @@ -689,6 +689,8 @@ fsl,usbphy = usbphy1; fsl,usbmisc = usbmisc 0; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; @@ -700,6 +702,8 @@ fsl,usbphy = usbphy2; fsl,usbmisc = usbmisc 1; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; @@ -711,6 +715,8 @@ fsl,usbmisc = usbmisc 2; dr_mode = host; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi index 3656a1d..6844e9e 100644 --- a/arch/arm/boot/dts/imx6sx.dtsi +++ b/arch/arm/boot/dts/imx6sx.dtsi @@ -747,6 +747,8 @@ fsl,usbmisc = usbmisc 0; fsl,anatop = anatop; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; @@ -758,6 +760,8 @@ fsl,usbphy = usbphy2; fsl,usbmisc = usbmisc 1; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; @@ -771,6 +775,8 @@ fsl,anatop = anatop; dr_mode = host; ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; + rx-burst-size-dword = 0x10; status = disabled; }; -- 1.9.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 6/7] phy: omap-usb2: Add a new compatible string for USB2 PHY2
On 05/08/15 17:18, Kishon Vijay Abraham I wrote:
Hi Roger,
On Wednesday 05 August 2015 01:55 PM, Roger Quadros wrote:
On 05/08/15 11:23, Roger Quadros wrote:
On 04/08/15 18:20, Kishon Vijay Abraham I wrote:
The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, add a new
compatible string.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
drivers/phy/phy-omap-usb2.c |9 +
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 49e5b0c..a061077 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -31,6 +31,8 @@ OMAP USB2 PHY
Required properties:
- compatible: Should be ti,omap-usb2
+ Should be ti,dra7x-usb2-phy2 for the 2nd instance of USB2 PHY
+ in DRA7x
- reg : Address and length of the register set for the device.
- #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index b5c266a..2f7220f 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -159,6 +159,11 @@ static const struct usb_phy_data dra7x_usb2_data = {
.flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
};
+static const struct usb_phy_data dra7x_usb2_phy2_data = {
+ .label = dra7x_usb2_phy2,
+ .flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+};
+
static const struct usb_phy_data am437x_usb2_data = {
.label = am437x_usb2,
.flags = 0,
@@ -178,6 +183,10 @@ static const struct of_device_id omap_usb2_id_table[]
= {
.data = dra7x_usb2_data,
},
{
+ .compatible = ti,dra7x-usb2-phy2,
+ .data = dra7x_usb2_phy2_data,
Why is this needed? You can reuse dra7x_usb2_data as is.
OK. I see why we need it in the next patch.
Probably both patches could be squashed.
What does .label indicate?
it's actually used only in usb_add_phy() (drivers/usb/phy/phy.c). I don't
think
it's actually important unless you strongly feel so.
I leave it to you then :).
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/10] usb: chipidea: add ahb burst configuration interface
The users can change it through dts or platform data if they
want to change the default value.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/bits.h | 3 +++
drivers/usb/chipidea/core.c | 14 ++
include/linux/usb/chipidea.h | 2 ++
3 files changed, 19 insertions(+)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 831a8f6..462ad02 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -25,6 +25,9 @@
#define VERSION (0xF 25)
#define CIVERSION(0x7 29)
+/* SBUSCFG */
+#define AHBBRST_MASK 0x7
+
/* HCCPARAMS */
#define HCCPARAMS_LEN BIT(17)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 97f937f..bde49f3 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -438,6 +438,9 @@ void ci_platform_configure(struct ci_hdrc *ci)
hw_write(ci, OP_USBCMD, 0xff, ci-platdata-itc_setting 16);
+ if (ci-platdata-flags CI_HDRC_OVERRIDE_AHB_BURST)
+ hw_write_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK,
+ ci-platdata-ahb_burst_config);
}
/**
@@ -646,6 +649,17 @@ static int ci_get_platdata(struct device *dev,
}
}
+ if (of_find_property(dev-of_node, ahb-burst-config, NULL)) {
+ ret = of_property_read_u32(dev-of_node, ahb-burst-config,
+ platdata-ahb_burst_config);
+ if (ret) {
+ dev_err(dev,
+ failed to get ahb-burst-config\n);
+ return ret;
+ }
+ platdata-flags |= CI_HDRC_OVERRIDE_AHB_BURST;
+ }
+
return 0;
}
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 034f7e1..fe3c8eb 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -33,6 +33,7 @@ struct ci_hdrc_platform_data {
#define CI_HDRC_FORCE_FULLSPEEDBIT(6)
#define CI_HDRC_TURN_VBUS_EARLY_ON BIT(7)
#define CI_HDRC_SET_NON_ZERO_TTHA BIT(8)
+#define CI_HDRC_OVERRIDE_AHB_BURST BIT(9)
enum usb_dr_modedr_mode;
#define CI_HDRC_CONTROLLER_RESET_EVENT 0
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
@@ -42,6 +43,7 @@ struct ci_hdrc_platform_data {
booltpl_support;
/* interrupt threshold setting */
u32 itc_setting;
+ u32 ahb_burst_config;
};
/* Default offset of capability registers */
--
1.9.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 v3 02/10] usb: chipidea: define stream mode disable for both roles
The system bus and chipidea IP have different limitations for both host and device mode. For example, with below errata, we need to enable SDIS(Stream Disable Mode) at host mode. But we don't want it for device mode at the same system. TAR 9000378958 Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang on OUT Retry Impacted Configuration: Host mode, all transfer types Description: The host core operating in streaming mode may under run while sending the data packet of an OUT transaction. This under run can occur if there are unexpected system delays in fetching the remaining packet data from memory. The host forces a bad CRC on the packet, the device detects the error and discards the packet. The host then retries a Bulk, Interrupt, or Control transfer if an under run occurs according to the USB specification. During simulations, it was found that the host does not issue the retry of the failed bulk OUT. It does not issue any other transactions except SOF packets that have incorrect frame numbers. The second failure mode occurs if the under run occurs on an ISO OUT transaction and the next ISO transaction is a zero byte packet. The host does not issue any transactions (including SOFs). The device detects a Suspend condition, reverts to full speed, and waits for resume signaling. A third failure mode occurs when the host under runs on an ISO OUT and the next ISO in the schedule is an ISO OUT with two max packets of 1024 bytes each. The host should issue MDATA for the first OUT followed by DATA1 for the second. However, it drops the MDATA transaction, and issues the DATA1 transaction. The system impact of this bug is the same regardless of the failure mode observed. The host core hangs, the ehci_ctrl state machine waits for the protocol engine to send the completion status for the corrupted transaction, which never occurs. No indication is sent to the host controller driver, no register bits change and no interrupts occur. Eventually the requesting application times out. Detailed internal behavior: The EHCI control state machine (ehci_ctrl) in the DMA block is responsible for parsing the schedules and initiating all transactions. The ehci_ctrl state machine passes the transaction details to the protocol block by writing the transaction information in to the TxFIFO. It then asserts the pe_hst_run_pkt signal to inform the host protocol state machine (pe_hst_state) that there is a packet in the TxFIFO. A tag of 0x0 indicates a start of packet with the data providing the following information: 35:32 Tag 31:30 Reserved 29:23 Endpoint (lowest 4 bits) 22:16 Address 15:10 Reserved 9:8 Endpoint speed 7:6 Endpoint type 5:6 Data Toggle 3:0 PID The pe_hst_state reads the packet information and constructs the packet and issues it to the PHY interface. The ehci_ctrl state machine writes the start transaction information in to the TxFIFO as 0x03002910c for the OUT packet that had the under run error. However, it writes 0xC3002910C for the retry of the Out transaction, which is incorrect. The pe_hst_state enters a bus timeout state after sending the bad CRC for the packet that under ran. It then purges any data that was back filled in to the TxFIFO for the packet that under ran. The pe_hst_state machine stops purging the TxFIFO when it is empty or if it reads a location that has a tag of 0x0, indicating a start of packet command. The pe_hst_state reads 0xC3002910C and discards it as it does not decode to a start of packet command. It continues to purge the OUT data that has been pre-buffered for the OUT retry . The pe_hst_state detects the hst_packet_run signal and attempts to read the PID and address information from the TxFIFO. This location has packet data and so does not decode to a valid PID and so falls through to the PE_HST_SOF_LOAD state where the frame_num_counter is updated. The frame_num_counter is updated with the data in the TxFIFO. In this case, the data is incorrect as the ehci_ctrl state machine did not initiate the load. The hst_pe_state machine detects the SOF request signal and sends an SOF with the bad frame number. Meanwhile, the ehci_ctrl state machine waits indefinitely in the run_pkt state waiting for the completion status from pe_hst_state machine, which will never happen. The ISO failure case is similar except that there is no retry for ISO. The ehci_ctrl state machine moves to the next transfer in the periodic schedule. If the under run occurs on the last entry of the periodic list then it moves to the Async schedule. In the case of ISO OUT simulations, the next ISO is a zero byte OUT and again the start of packet command gets corrupted. The TxFIFO is empty when the hst_pe_state attempts to read the Address and PID information as the transaction is a zero byte packet. This results in the hst_pe_state machine staying in the GET_PID state, which means that it does not issue any transactions (including SOFs). The device detects a Suspend condition and reverts to full
[PATCH v3 10/10] usb: chipidea: add tx/rx burst size configuration interface
The user can adjust it through dts or platform data
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/bits.h | 4
drivers/usb/chipidea/ci.h| 1 +
drivers/usb/chipidea/core.c | 35 +++
include/linux/usb/chipidea.h | 4
4 files changed, 44 insertions(+)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 462ad02..e462f55 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -61,6 +61,10 @@
/* Set non-zero value for internal TT Hub address representation */
#define TTCTRL_TTHA(0x7fUL 24)
+/* BURSTSIZE */
+#define RX_BURST_MASK 0xff
+#define TX_BURST_MASK 0xff00
+
/* PORTSC */
#define PORTSC_CCSBIT(0)
#define PORTSC_CSCBIT(1)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index b562544..41d7cf6 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -51,6 +51,7 @@ enum ci_hw_regs {
OP_DEVICEADDR,
OP_ENDPTLISTADDR,
OP_TTCTRL,
+ OP_BURSTSIZE,
OP_PORTSC,
OP_DEVLC,
OP_OTGSC,
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index bde49f3..3feebf7 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -86,6 +86,7 @@ static const u8 ci_regs_nolpm[] = {
[OP_DEVICEADDR] = 0x14U,
[OP_ENDPTLISTADDR] = 0x18U,
[OP_TTCTRL] = 0x1CU,
+ [OP_BURSTSIZE] = 0x20U,
[OP_PORTSC] = 0x44U,
[OP_DEVLC] = 0x84U,
[OP_OTGSC] = 0x64U,
@@ -109,6 +110,7 @@ static const u8 ci_regs_lpm[] = {
[OP_DEVICEADDR] = 0x14U,
[OP_ENDPTLISTADDR] = 0x18U,
[OP_TTCTRL] = 0x1CU,
+ [OP_BURSTSIZE] = 0x20U,
[OP_PORTSC] = 0x44U,
[OP_DEVLC] = 0x84U,
[OP_OTGSC] = 0xC4U,
@@ -441,6 +443,17 @@ void ci_platform_configure(struct ci_hdrc *ci)
if (ci-platdata-flags CI_HDRC_OVERRIDE_AHB_BURST)
hw_write_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK,
ci-platdata-ahb_burst_config);
+
+ /* override burst size, take effect only when ahb_burst_config is 0 */
+ if (!hw_read_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK)) {
+ if (ci-platdata-flags CI_HDRC_OVERRIDE_TX_BURST)
+ hw_write(ci, OP_BURSTSIZE, TX_BURST_MASK,
+ ci-platdata-tx_burst_size __ffs(TX_BURST_MASK));
+
+ if (ci-platdata-flags CI_HDRC_OVERRIDE_RX_BURST)
+ hw_write(ci, OP_BURSTSIZE, RX_BURST_MASK,
+ ci-platdata-rx_burst_size);
+ }
}
/**
@@ -660,6 +673,28 @@ static int ci_get_platdata(struct device *dev,
platdata-flags |= CI_HDRC_OVERRIDE_AHB_BURST;
}
+ if (of_find_property(dev-of_node, tx-burst-size-dword, NULL)) {
+ ret = of_property_read_u32(dev-of_node, tx-burst-size-dword,
+ platdata-tx_burst_size);
+ if (ret) {
+ dev_err(dev,
+ failed to get tx-burst-size-dword\n);
+ return ret;
+ }
+ platdata-flags |= CI_HDRC_OVERRIDE_TX_BURST;
+ }
+
+ if (of_find_property(dev-of_node, rx-burst-size-dword, NULL)) {
+ ret = of_property_read_u32(dev-of_node, rx-burst-size-dword,
+ platdata-rx_burst_size);
+ if (ret) {
+ dev_err(dev,
+ failed to get rx-burst-size-dword\n);
+ return ret;
+ }
+ platdata-flags |= CI_HDRC_OVERRIDE_RX_BURST;
+ }
+
return 0;
}
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index fe3c8eb..a41833c 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -34,6 +34,8 @@ struct ci_hdrc_platform_data {
#define CI_HDRC_TURN_VBUS_EARLY_ON BIT(7)
#define CI_HDRC_SET_NON_ZERO_TTHA BIT(8)
#define CI_HDRC_OVERRIDE_AHB_BURST BIT(9)
+#define CI_HDRC_OVERRIDE_TX_BURST BIT(10)
+#define CI_HDRC_OVERRIDE_RX_BURST BIT(11)
enum usb_dr_modedr_mode;
#define CI_HDRC_CONTROLLER_RESET_EVENT 0
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
@@ -44,6 +46,8 @@ struct ci_hdrc_platform_data {
/* interrupt threshold setting */
u32 itc_setting;
u32 ahb_burst_config;
+ u32 tx_burst_size;
+ u32 rx_burst_size;
};
/* Default offset of capability registers */
--
1.9.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
[PATCH v3 08/10] Doc: usb: ci-hdrc-usb2: add tx(rx)-burst-config-dword for binding doc
It is used to override the default setting for burst size, changing burst size takes effect only when the SBUSCFG.AHBBRST = 0. Signed-off-by: Peter Chen peter.c...@freescale.com --- Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt index d52a747..d71ef07 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt @@ -37,6 +37,14 @@ Optional properties: property is used to change AHB burst configuration, check the chipidea spec for meaning of each value. If this property is not existed, it will use the reset value. +- tx-burst-size-dword: it is vendor dependent, the tx burst size in dword + (4 bytes), This register represents the maximum length of a the burst + in 32-bit words while moving data from system memory to the USB + bus, changing this value takes effect only the SBUSCFG.AHBBRST is 0. +- rx-burst-size-dword: it is vendor dependent, the rx burst size in dword + (4 bytes), This register represents the maximum length of a the burst + in 32-bit words while moving data from the USB bus to system memory, + changing this value takes effect only the SBUSCFG.AHBBRST is 0. Example: @@ -51,4 +59,6 @@ Example: gadget-itc-setting = 0x4; /* 4 micro-frames */ /* Incremental burst of unspecified length */ ahb-burst-config = 0x0; + tx-burst-size-dword = 0x10; /* 64 bytes */ + rx-burst-size-dword = 0x10; }; -- 1.9.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 v3 03/10] usb: chipidea: imx: add stream mode enable for device mode at imx6sl/imx6sx
Stream mode enable is known for better performance, this stream mode
enable patch has been passed with stress tests at device mode for
imx6sl and imx6sx, and no issue is found.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/ci_hdrc_imx.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 6d2a85a..3f41679 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -29,26 +29,31 @@ struct ci_hdrc_imx_platform_flag {
};
static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
+ CI_HDRC_DISABLE_STREAMING,
};
static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
.flags = CI_HDRC_IMX28_WRITE_FIX |
- CI_HDRC_TURN_VBUS_EARLY_ON,
+ CI_HDRC_TURN_VBUS_EARLY_ON |
+ CI_HDRC_DISABLE_STREAMING,
};
static const struct ci_hdrc_imx_platform_flag imx6q_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
- CI_HDRC_TURN_VBUS_EARLY_ON,
+ CI_HDRC_TURN_VBUS_EARLY_ON |
+ CI_HDRC_DISABLE_STREAMING,
};
static const struct ci_hdrc_imx_platform_flag imx6sl_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
- CI_HDRC_TURN_VBUS_EARLY_ON,
+ CI_HDRC_TURN_VBUS_EARLY_ON |
+ CI_HDRC_DISABLE_HOST_STREAMING,
};
static const struct ci_hdrc_imx_platform_flag imx6sx_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
- CI_HDRC_TURN_VBUS_EARLY_ON,
+ CI_HDRC_TURN_VBUS_EARLY_ON |
+ CI_HDRC_DISABLE_HOST_STREAMING,
};
static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
@@ -126,8 +131,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
struct ci_hdrc_platform_data pdata = {
.name = dev_name(pdev-dev),
.capoffset = DEF_CAPOFFSET,
- .flags = CI_HDRC_DISABLE_STREAMING |
- CI_HDRC_SET_NON_ZERO_TTHA,
+ .flags = CI_HDRC_SET_NON_ZERO_TTHA,
};
int ret;
const struct of_device_id *of_id =
--
1.9.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 v3 07/10] usb: chipidea: usbmisc_imx: add non-burst setting for imx6
With this setting and AHBBRST at SBUSCFG as Incremental burst of
unspecified length, each non-burst size can be taken as single
transfer. It is benefit for non-burst size transfer.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/usbmisc_imx.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 3cefd49..5ddab30 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -54,6 +54,7 @@
#define MX53_USB_PHYCTRL1_PLLDIV_MASK 0x3
#define MX53_USB_PLL_DIV_24_MHZ0x01
+#define MX6_BM_NON_BURST_SETTING BIT(1)
#define MX6_BM_OVER_CUR_DISBIT(7)
#define MX6_BM_WAKEUP_ENABLE BIT(10)
#define MX6_BM_ID_WAKEUP BIT(16)
@@ -255,14 +256,21 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data
*data)
if (data-index 3)
return -EINVAL;
+ spin_lock_irqsave(usbmisc-lock, flags);
+
if (data-disable_oc) {
- spin_lock_irqsave(usbmisc-lock, flags);
reg = readl(usbmisc-base + data-index * 4);
writel(reg | MX6_BM_OVER_CUR_DIS,
usbmisc-base + data-index * 4);
- spin_unlock_irqrestore(usbmisc-lock, flags);
}
+ /* SoC non-burst setting */
+ reg = readl(usbmisc-base + data-index * 4);
+ writel(reg | MX6_BM_NON_BURST_SETTING,
+ usbmisc-base + data-index * 4);
+
+ spin_unlock_irqrestore(usbmisc-lock, flags);
+
usbmisc_imx6q_set_wakeup(data, false);
return 0;
--
1.9.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 2/2] gadget: Support for the usb charger framework
/**
* struct usb_udc - describes one usb device controller @@ -127,12
+128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep, }
EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
+int usb_gadget_register_notify(struct usb_gadget *gadget,
+struct notifier_block *nb) {
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(gadget-lock, flags);
I find you use so many spin_lock_irqsave, any reasons for that?
Why mutex_lock can't be used?
The spin_lock_irqsave() can make it as a atomic notifier, that can make sure
the
gadget state event can be quickly reported to the user who register a notifier
on the gadget device. Is it OK?
I don't think it is a good reason, spin_lock_irqsave is usually used for
protecting
data which is accessed at atomic environment.
Peter
Re: [PATCH 2/2] gadget: Support for the usb charger framework
On Thu, Aug 06, 2015 at 03:03:49PM +0800, Baolin Wang wrote:
The usb charger framework is based on usb gadget, and each usb gadget
can be one usb charger to set the current limitation.
This patch adds a notifier mechanism for usb charger to report to usb
charger when the usb gadget state is changed.
Also we introduce a callback 'get_charger_type' which will implemented
by user for usb gadget operations to get the usb charger type.
Signed-off-by: Baolin Wang baolin.w...@linaro.org
---
drivers/usb/gadget/udc/udc-core.c | 41
+
include/linux/usb/gadget.h| 20 ++
2 files changed, 61 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index d69c355..d5368088 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
#include linux/usb/ch9.h
#include linux/usb/gadget.h
#include linux/usb.h
+#include linux/usb/usb_charger.h
/**
* struct usb_udc - describes one usb device controller
@@ -127,12 +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep,
}
EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
+int usb_gadget_register_notify(struct usb_gadget *gadget,
+struct notifier_block *nb)
+{
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(gadget-lock, flags);
I find you use so many spin_lock_irqsave, any reasons for that?
Why mutex_lock can't be used?
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Introduce usb charger framework to deal with the usb gadget power negotation
On 7 August 2015 at 13:34, Peter Chen peter.c...@freescale.com wrote: On Thu, Aug 06, 2015 at 03:03:47PM +0800, Baolin Wang wrote: Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not behave as they should. Providing a standard framework for doing this in the kernel. Baolin, thanks for introducing a framework for doing it, we do support USB Charger for chipidea driver at internal tree, but it is specific for imx, and still have some problems to upstream due to need to change some common code. One suggestion, would you add your user next time? In that case, we can know better for this framework. Peter, Thanks for your reviewing and comments. Now I just introduce the framework to review for more feedbacks and do not have a useful user to use it. I just can show you some example code to show how to use it. Thanks. Baolin Wang (2): gadget: Introduce the usb charger framework gadget: Support for the usb charger framework drivers/usb/gadget/charger.c | 547 + drivers/usb/gadget/udc/udc-core.c | 41 +++ include/linux/usb/gadget.h| 20 ++ include/linux/usb/usb_charger.h | 101 +++ 4 files changed, 709 insertions(+) create mode 100644 drivers/usb/gadget/charger.c create mode 100644 include/linux/usb/usb_charger.h -- 1.7.9.5 -- Best Regards, Peter Chen -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gadget: Introduce the usb charger framework
On 7 August 2015 at 13:41, Peter Chen peter.c...@freescale.com wrote:
On Thu, Aug 06, 2015 at 03:03:48PM +0800, Baolin Wang wrote:
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.
The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state.
Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.
Signed-off-by: Baolin Wang baolin.w...@linaro.org
---
drivers/usb/gadget/charger.c| 547
+++
include/linux/usb/usb_charger.h | 101
2 files changed, 648 insertions(+)
create mode 100644 drivers/usb/gadget/charger.c
create mode 100644 include/linux/usb/usb_charger.h
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
new file mode 100644
index 000..3ca0180
--- /dev/null
+++ b/drivers/usb/gadget/charger.c
@@ -0,0 +1,547 @@
+/*
+ * usb charger.c -- USB charger driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/extcon.h
+#include linux/export.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/usb.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+#include linux/usb/usb_charger.h
+
+#define DEFAULT_CUR_PROTECT (50)
+#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
+
+static LIST_HEAD(usb_charger_list);
+static DEFINE_MUTEX(usb_charger_list_lock);
+
+/*
+ * usb_charger_find_by_name - Get the usb charger device by name.
+ * @name - usb charger device name.
+ *
+ * notes: when this function walks the list and returns a charger
+ * it's dropped the lock which means that something else could come
+ * along and delete the charger before we dereference the pointer.
+ * It's very unlikely but it's a possibility so you should take care
+ * of it.
+ * Thus when you get the usb charger by name, you should call
+ * put_usb_charger() to derease the reference count of the usb charger.
+ *
+ * return the instance of usb charger device.
+ */
+struct usb_charger *usb_charger_find_by_name(char *name)
+{
+ struct usb_charger *uchger;
+
+ if (!name)
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(usb_charger_list_lock);
+ list_for_each_entry(uchger, usb_charger_list, entry) {
+ if (!strcmp(uchger-name, name)) {
+ get_usb_charger(uchger);
+ mutex_unlock(usb_charger_list_lock);
+ return uchger;
+ }
+ }
+ mutex_unlock(usb_charger_list_lock);
+
+ return NULL;
+}
+
+/*
+ * usb_charger_register_notify() - Register a notifiee to get notified by
+ * any attach status changes from the usb charger type detection.
+ * @uchger - the usb charger device which is monitored.
+ * @nb - a notifier block to be registered.
+ */
+void usb_charger_register_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(uchger-lock, flags);
+ raw_notifier_chain_register(uchger-uchger_nh, nb);
+ spin_unlock_irqrestore(uchger-lock, flags);
+}
+
+/*
+ * usb_charger_unregister_notify() - Unregister a notifiee from the usb
charger.
+ * @uchger - the usb charger device which is monitored.
+ * @nb - a notifier block to be unregistered.
+ */
+void usb_charger_unregister_notify(struct usb_charger *uchger,
+struct notifier_block *nb)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(uchger-lock, flags);
+ raw_notifier_chain_unregister(uchger-uchger_nh, nb);
+ spin_unlock_irqrestore(uchger-lock, flags);
+}
+
+/*
+ * usb_charger_register_extcon_notifier() - Register a notifiee of the usb
+ * charger
[PATCH v3 01/10] usb: chipidea: udc: zero-length packet is only needed for TX
The zero-length packet is the sendor tells the receiver that there is no more data, so it is only needed at the TX side. Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/chipidea/udc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 2a47720..15f55da 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -445,7 +445,7 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq) rest -= count; } - if (hwreq-req.zero hwreq-req.length + if (hwreq-req.zero hwreq-req.length hwep-dir == TX (hwreq-req.length % hwep-ep.maxpacket == 0)) add_td_to_list(hwep, hwreq, 0); -- 1.9.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 v3 05/10] ARM: imx6: set ahb-burst-config as 0 for USB
After setting ahb burst configuration as 0, we can increase tx/rx burst size, it will improve the USB performance Signed-off-by: Peter Chen peter.c...@freescale.com --- arch/arm/boot/dts/imx6qdl.dtsi | 4 arch/arm/boot/dts/imx6sl.dtsi | 3 +++ arch/arm/boot/dts/imx6sx.dtsi | 3 +++ 3 files changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi index e6d1359..42d62b0 100644 --- a/arch/arm/boot/dts/imx6qdl.dtsi +++ b/arch/arm/boot/dts/imx6qdl.dtsi @@ -853,6 +853,7 @@ clocks = clks IMX6QDL_CLK_USBOH3; fsl,usbphy = usbphy1; fsl,usbmisc = usbmisc 0; + ahb-burst-config = 0x0; status = disabled; }; @@ -864,6 +865,7 @@ fsl,usbphy = usbphy2; fsl,usbmisc = usbmisc 1; dr_mode = host; + ahb-burst-config = 0x0; status = disabled; }; @@ -874,6 +876,7 @@ clocks = clks IMX6QDL_CLK_USBOH3; fsl,usbmisc = usbmisc 2; dr_mode = host; + ahb-burst-config = 0x0; status = disabled; }; @@ -884,6 +887,7 @@ clocks = clks IMX6QDL_CLK_USBOH3; fsl,usbmisc = usbmisc 3; dr_mode = host; + ahb-burst-config = 0x0; status = disabled; }; diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi index a78e715..066fac9 100644 --- a/arch/arm/boot/dts/imx6sl.dtsi +++ b/arch/arm/boot/dts/imx6sl.dtsi @@ -688,6 +688,7 @@ clocks = clks IMX6SL_CLK_USBOH3; fsl,usbphy = usbphy1; fsl,usbmisc = usbmisc 0; + ahb-burst-config = 0x0; status = disabled; }; @@ -698,6 +699,7 @@ clocks = clks IMX6SL_CLK_USBOH3; fsl,usbphy = usbphy2; fsl,usbmisc = usbmisc 1; + ahb-burst-config = 0x0; status = disabled; }; @@ -708,6 +710,7 @@ clocks = clks IMX6SL_CLK_USBOH3; fsl,usbmisc = usbmisc 2; dr_mode = host; + ahb-burst-config = 0x0; status = disabled; }; diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi index 708175d..3656a1d 100644 --- a/arch/arm/boot/dts/imx6sx.dtsi +++ b/arch/arm/boot/dts/imx6sx.dtsi @@ -746,6 +746,7 @@ fsl,usbphy = usbphy1; fsl,usbmisc = usbmisc 0; fsl,anatop = anatop; + ahb-burst-config = 0x0; status = disabled; }; @@ -756,6 +757,7 @@ clocks = clks IMX6SX_CLK_USBOH3; fsl,usbphy = usbphy2; fsl,usbmisc = usbmisc 1; + ahb-burst-config = 0x0; status = disabled; }; @@ -768,6 +770,7 @@ phy_type = hsic; fsl,anatop = anatop; dr_mode = host; + ahb-burst-config = 0x0; status = disabled; }; -- 1.9.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 v3 04/10] Doc: usb: ci-hdrc-usb2: add ahb-burst-config for binding doc
It is used to change ahb burst configuration for platforms, it is vendor specific. Signed-off-by: Peter Chen peter.c...@freescale.com --- Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt index 4159c8c..d52a747 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt @@ -32,6 +32,11 @@ Optional properties: - external-vbus-divider: (FSL only) enables off-chip resistor divider for Vbus - itc-setting: interrupt threshold control register control, the setting should be aligned with ITC bits at register USBCMD. +- ahb-burst-config: it is vendor dependent, the required value should be + aligned with AHBBRST at SBUSCFG, the range is from 0x0 to 0x7. This + property is used to change AHB burst configuration, check the chipidea + spec for meaning of each value. If this property is not existed, it + will use the reset value. Example: @@ -44,4 +49,6 @@ Example: phy-names = usb-phy; vbus-supply = reg_usb0_vbus; gadget-itc-setting = 0x4; /* 4 micro-frames */ +/* Incremental burst of unspecified length */ + ahb-burst-config = 0x0; }; -- 1.9.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 v3 00/10] USB: chipidea misc patches
Hi all, In this series, I add several new interfaces for chipidea driver, they are mainly for system configuration adjustment. The USB performance may be improved with these configuration changing, but each vendor driver owner needs to consult with your IC owner which configuration parameters are suitable for your system before changing it, and only change it if necessary. The other changes are for imx, it shows how imx uses these interfaces. Shawn, the patch [5/10] and [9/10] are dts changes, help to review it please. Changes for v3: - Improve the binding doc according to Rob's comment [Patch 4/10, 8/10] Changes for v2: - Use the bit fields which are not used. [Patch 2/10, 6/10, 10/10] - According to Greg and Sascha comments, format patch 2/10's commit log. - using non-burst instead of unburst for patch 7/10 Peter Chen (10): usb: chipidea: udc: zero-length packet is only needed for TX usb: chipidea: define stream mode disable for both roles usb: chipidea: imx: add stream mode enable for device mode at imx6sl/imx6sx Doc: usb: ci-hdrc-usb2: add ahb-burst-config for binding doc ARM: imx6: set ahb-burst-config as 0 for USB usb: chipidea: add ahb burst configuration interface usb: chipidea: usbmisc_imx: add non-burst setting for imx6 Doc: usb: ci-hdrc-usb2: add tx(rx)-burst-config-dword for binding doc ARM: imx6: change default burst size for USB usb: chipidea: add tx/rx burst size configuration interface .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 17 ++ arch/arm/boot/dts/imx6qdl.dtsi | 12 + arch/arm/boot/dts/imx6sl.dtsi | 9 arch/arm/boot/dts/imx6sx.dtsi | 9 drivers/usb/chipidea/bits.h| 7 +++ drivers/usb/chipidea/ci.h | 1 + drivers/usb/chipidea/ci_hdrc_imx.c | 16 +++--- drivers/usb/chipidea/core.c| 62 +- drivers/usb/chipidea/udc.c | 2 +- drivers/usb/chipidea/usbmisc_imx.c | 12 - include/linux/usb/chipidea.h | 11 +++- 11 files changed, 147 insertions(+), 11 deletions(-) -- 1.9.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 2/2] gadget: Support for the usb charger framework
On 7 August 2015 at 13:45, Peter Chen peter.c...@freescale.com wrote:
On Thu, Aug 06, 2015 at 03:03:49PM +0800, Baolin Wang wrote:
The usb charger framework is based on usb gadget, and each usb gadget
can be one usb charger to set the current limitation.
This patch adds a notifier mechanism for usb charger to report to usb
charger when the usb gadget state is changed.
Also we introduce a callback 'get_charger_type' which will implemented
by user for usb gadget operations to get the usb charger type.
Signed-off-by: Baolin Wang baolin.w...@linaro.org
---
drivers/usb/gadget/udc/udc-core.c | 41
+
include/linux/usb/gadget.h| 20 ++
2 files changed, 61 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index d69c355..d5368088 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
#include linux/usb/ch9.h
#include linux/usb/gadget.h
#include linux/usb.h
+#include linux/usb/usb_charger.h
/**
* struct usb_udc - describes one usb device controller
@@ -127,12 +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep,
}
EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
+int usb_gadget_register_notify(struct usb_gadget *gadget,
+struct notifier_block *nb)
+{
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(gadget-lock, flags);
I find you use so many spin_lock_irqsave, any reasons for that?
Why mutex_lock can't be used?
The spin_lock_irqsave() can make it as a atomic notifier, that can
make sure the gadget state event can be quickly reported to the user
who register a notifier on the gadget device. Is it OK?
--
Best Regards,
Peter Chen
--
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode
Hey Hans, On 06-08-15 16:35, Hans de Goede wrote: Hi, On 06-08-15 10:22, Olliver Schinagl wrote: Hey Hans, I've tried getting your musb stuff working on a cubietruck, but i don't seem to see this patch on your linux-sunxi/sunxi-wip branch on github? Is your github branch fully functional at the moment? What I have done so far, is build the kernel using sunxi_defconfig and enabled USB_MUSB_SUNXI with its dependancies (musb isn't enabled there by default): USB_SUPPORT [=y] USB_MUSB_HDRC [=y] ARCH_SUNXI [=y] NOP_USB_XCEIV [=y] PHY_SUN4I_USB [=y] EXTCON [=y] GENERIC_PHY [=y] Selects: SUNXI_SRAM [=y] I changed the dts from dr_mode='otg' to dr_mode='host', a) we only need host mode anyway (the id pin isn't properly connected) If you change the dr_mode to host then you _must_ also remove any id_det and vbus_det gpio settings from the usb_phy node in the dts, as the sun4i phy code detects host vs otg mode by checking for the presence of these. Yes, this fixes it and makes it work. Thanks. Also I apologize for not noticing this patch in your queue before :) Looks like everything is all ready in your WIP branch. Now, I see that Chen-Yu found the same problems here: http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17843 So far, with your mentioned changes to remove the id and vbus gpio's you can have my Tested-by: Olliver Schinagl o.schin...@ultimaker.com and b) I got an error about an known dr_mode before and this was the quick and easy way. Dmesg produces the following related to musb. [1.691062] usb_phy_generic.0.auto supply vcc not found, using dummy regulator [1.691445] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) [1.691453] musb-hdrc: MHDRC RTL version 0.0 [1.691467] musb-hdrc: 11/11 max ep, 5184/8192 memory [1.691543] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver [1.691553] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 5 [1.692470] hub 5-0:1.0: USB hub found [1.692529] hub 5-0:1.0: 1 port detected [1.699956] sunxi-rtc 1c20d00.rtc: setting system clock to 2015-08-06 07:59:08 UTC (1438847948) [1.704733] usb0-vbus: disabling [1.765695] ldo4: disabling [1.808351] ldo3: disabling [1.848769] vcc5v0: disabling [1.848774] vcc3v0: disabling The usb_phy_generic missing shouldn't be too bad? But the usb0-vbus being disabled obviously might be related to the musb port not working? Correct. For starters I would try the dts changes I suggested above. Yep that fixed it. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gadget: Support for the usb charger framework
On 7 August 2015 at 17:07, Peter Chen peter.c...@freescale.com wrote:
/**
* struct usb_udc - describes one usb device controller @@ -127,12
+128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep, }
EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
+int usb_gadget_register_notify(struct usb_gadget *gadget,
+struct notifier_block *nb) {
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(gadget-lock, flags);
I find you use so many spin_lock_irqsave, any reasons for that?
Why mutex_lock can't be used?
The spin_lock_irqsave() can make it as a atomic notifier, that can make sure
the
gadget state event can be quickly reported to the user who register a
notifier
on the gadget device. Is it OK?
I don't think it is a good reason, spin_lock_irqsave is usually used for
protecting
data which is accessed at atomic environment.
Yes, we want the notify process is a atomic environment which do not
want to be interrupted by irq or other things to make the notice can
be quickly reported to the user.
Also i think the notify process is less cost, thus i use the spinlock. Thanks.
Peter
--
Baolin.wang
Best Regards
--
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: devio: fix spacing
Fix two occurrences of the checkpatch.pl error:
ERROR: space prohibited before that ',' (ctx:WxW)
Fix one occurrence of the checkpatch error:
ERROR: space required before the open parenthesis '('
Signed-off-by: Kris Borer kbo...@gmail.com
---
drivers/usb/core/devio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index ed6d1d5..38ae877c 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -103,7 +103,7 @@ MODULE_PARM_DESC(usbfs_snoop, true to log all usbfs
traffic);
#define snoop(dev, format, arg...) \
do {\
if (usbfs_snoop)\
- dev_info(dev , format , ## arg);\
+ dev_info(dev, format, ## arg); \
} while (0)
enum snoop_when {
@@ -1321,7 +1321,7 @@ static int proc_do_submiturb(struct usb_dev_state *ps,
struct usbdevfs_urb *uurb
is_in = (uurb-endpoint USB_ENDPOINT_DIR_MASK) != 0;
u = 0;
- switch(uurb-type) {
+ switch (uurb-type) {
case USBDEVFS_URB_TYPE_CONTROL:
if (!usb_endpoint_xfer_control(ep-desc))
return -EINVAL;
--
1.9.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
Values for SetHubDepth and GetPortErrorCount
In include/linux/usb/hcd.h, we have /* class requests from USB 3.0 hub spec, table 10-5 */ #define SetHubDepth (0x3000 | HUB_SET_DEPTH) #define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT) However, from the usb 3.1 spec I downloaded at http://www.usb.org/developers/docs/, table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed Hub Descriptor). Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port It appears the correct bmRequestType values should be: #define SetHubDepth (0x2000 | HUB_SET_DEPTH) #define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) Which are the bmRequestType values of SetHubFeature and GetPortStatus (and friends). These lines were introduced in commit 0eadcc09203349b11ca477ec367079b23d32ab91 Author: Tatyana Brokhman tlin...@codeaurora.org Date: Mon Nov 1 18:18:24 2010 +0200 usb: USB3.0 ch11 definitions Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0 spec. Signed-off-by: Tatyana Brokhman tlin...@codeaurora.org Signed-off-by: Greg Kroah-Hartman gre...@suse.de The values are only used by dummy_hcd which does nothing with them and by max3421-hcd which returns an error. Can anyone clarify what I'm missing or if the values are actually wrong? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB - Generic Serial device : Unable to read more than 4095 bytes
Hi, I am stuck with the above issue, I have some doubts regarding USB - Generic driver 1. Could you please explain me why USB - Generic driver is slow ? 2. Now I am try to study USB - Generic driver implementation , I am confused with the function usb_serial_generic_read_bulk_callback() , could you please tell me from where this function is calling ? 3. If you have any detailed doc regarding the implementation of USB - Generic serial driver, Please send to me, Regards, Arun On Thu, Aug 6, 2015 at 3:42 PM, arun k arunkarunakara...@gmail.com wrote: / # lsusb -v Bus 002 Device 006: ID 045b:0218 Bus 001 Device 001: ID 1d6b:0002 Bus 002 Device 001: ID 1d6b:0001 Bus 003 Device 001: ID 1d6b:0002 Bus 004 Device 001: ID 1d6b:0003 In this my device is Bus 002 Device 006: ID 045b:0218 I enabled data dumping in usb_serial_generic_read_bulk_callback() function and found data received in this function is losing. In this function data is received as 64 bytes packets and two continuous 64 bytes having no data loss but the next packets are lost ie 1st packet ok(64 byte) 2nd packet ok(64 byte) . . packet lossing . 7th packet ok(64 byte) 8th packet ok(64 byte) . . In this way data loss is happening. Number of packets losing is different not constant always. I think the generic USB driver ignores baud rate. Like Greg suggested, you need to use the proper driver for your hardware. I did't find any other suitable driver inside Linux. I checked this device in windows in that usbser.sys is detecting(.inf file is attached with the mail). Could you suggest any available drivers for my device. Sorry I am very new to Linux drivers. I will post my USB device descriptor values below [ 1291.908071] ## udev-descriptor.bLength 0x12 [ 1291.908089] ## udev-descriptor.bDescriptorType 0x1 [ 1291.908147] ## udev-descriptor.bcdUSB 0x200 [ 1291.908165] ## udev-descriptor.bDeviceClass 0xef [ 1291.908181] ## udev-descriptor.bDeviceSubClass 0x2 [ 1291.908196] ## udev-descriptor.bDeviceProtocol 0x1 [ 1291.908211] ## udev-descriptor.bMaxPacketSize0 0x40 [ 1291.908226] ## udev-descriptor.idVendor 0x45b [ 1291.908241] ## udev-descriptor.idProduct 0x218 [ 1291.908255] ## udev-descriptor.bcdDevice 0x1 [ 1291.908270] ## udev-descriptor.iManufacturer 0x0 [ 1291.908284] ## udev-descriptor.iProduct 0x0 [ 1291.908298] ## udev-descriptor.iSerialNumber 0x0 [ 1291.908313] ## udev-descriptor.bNumConfigurations 0x1 Regards, Arun On Wed, Aug 5, 2015 at 9:31 PM, Peter Hurley pe...@hurleysoftware.com wrote: On 08/04/2015 11:57 PM, arun k wrote: Ok, but does the sending device know how to process in-band software flow control and is it set up to respond properly? I am not sure about this. I need to check this. Also, I doubt software flow control is going to work @ 4Mbaud line rate. If you're stuck using software flow control, start with a 115kbaud line rate and see if that fixes your data loss problem I tried B115200 also but issue is still there. I think the generic USB driver ignores baud rate. Like Greg suggested, you need to use the proper driver for your hardware. What is the output from 'lsusb -v' and please identify in that output which device you are using. I am using a USB device and that sending data at a rate of *409600 bytes/sec*. Is this data rate have any relation with issue. Yes. Also, can you test this on a newer kernel like 3.18? Regards, Peter Hurley On Wed, Aug 5, 2015 at 11:24 AM, Peter Hurley pe...@hurleysoftware.com mailto:pe...@hurleysoftware.com wrote: On 08/04/2015 10:00 PM, arun k wrote: I enabled software flow control like below tty.c_iflag |= (IXON | IXOFF | IXANY); Ok, but does the sending device know how to process in-band software flow control and is it set up to respond properly? Also, I doubt software flow control is going to work @ 4Mbaud line rate. If you're stuck using software flow control, start with a 115kbaud line rate and see if that fixes your data loss problem. Regards, Peter Hurley On Wed, Aug 5, 2015 at 12:59 AM, Peter Hurley pe...@hurleysoftware.com mailto:pe...@hurleysoftware.com wrote: On 08/03/2015 10:47 PM, arun k wrote: Thank you for the reply The tty layer is limiting you, just keep reading in a loop until you run out of data, you should not ever expect to read a specific number of bytes from a tty device at a time, the read call will tell you the number that was read properly. I tried this method but in my case I found data loss. By changing any buffer size modification in driver side , can we fix this issue ? The data loss is probably occurring because you have all flow control disabled and the line speed is too fast for no flow control. Regards, Peter Hurley Please don't use the generic driver, it's slow
Re: [PATCH v4 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller
hi,
On Fri, 2015-07-31 at 14:45 +0100, Mark Rutland wrote:
Hi,
Sorry for my late reply to a prior version of this series, but I still
have concerns with some of the properties.
I'll repeat those below.
On Fri, Jul 31, 2015 at 02:03:53PM +0100, Chunfeng Yun wrote:
add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.
Signed-off-by: Chunfeng Yun chunfeng@mediatek.com
---
.../devicetree/bindings/usb/mt8173-xhci.txt| 51
++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..364be5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,51 @@
+MT65XX xhci
+
+The device node for Mediatek SOC usb3.0 host controller
+
+Required properties:
+ - compatible : Supports mediatek,mt8173-xhci
s/Supports/should contain/
done
+ - reg : Specifies physical base address and size of the registers,
+ the first one for MAC, the second for IPPC
+ - interrupts : Interrupt mode, number and trigger mode
Just specify what this logically corresponds to; the format of the
interrupts proeprty depends on the interrupt controller.
done
+ - power-domains : To enable usb's mtcmos
Please describe what this contains. I assume you exped a single power
domain to be described, covering the whole xHCI controller?
+ - vusb33-supply : Regulator of usb avdd3.3v
+ - clocks : Must support all clocks that xhci needs
- clocks: a list of phandle + clock-specifier pairs, one for each entry
in clock-names.
+ - clock-names : Should be sys_mac for sys and mac clocks, and
+ wakeup_deb_p0, wakeup_deb_p1 for wakeup debounce control
+ clocks
This would be better as a list, e.g.
- clock-names: should contain:
* sys_mac description here if necessary
* wakeup_deb_p0 description here if necessary
* wakeup_deb_p1 description here if necessary
done
Is sys_mac a single clock input line? Or is it jsut the case that a
single line feeds two inputs currently? if the latter they should be
separate entries.
It is a single clock for usb MAC, already rename it
+ - phys : List of PHY specifiers (used by generic PHY framework).
The bracketed part should go. The bidnigns should know nothing of Linux
internals.
remove it
+ - phy-names : Must be usb-phy0, usb-phy1,.., usb-phyN, based on
+ the number of PHYs as specified in @phys property.
This is useless.
You either don't need names, and can acquire the phys by index, or you
need names which correspond to those on the data sheet for the xHCI
controller.
Ok, re-write the phy driver, and here also make use of the new format.
+ - mediatek,usb-wakeup : To access usb wakeup control register
Please describe what this points to (I guess it's a syscon)/
+ - mediatek,wakeup-src : 1: Ip sleep wakeup mode; 2: line state wakeup
+ mode; others means don't enable wakeup source of usb
This sounds like a runtime decision.
No, the driver do not know whether to enable wakeup function or not and
also don't know enable which one, except tell it.
And it will set different registers of @mediatek,usb-wakeup to enable
the selected wakeup mode when system enter suspend.
_why_ do you think this needs to be in the DT?
+ - mediatek,u2port-num : The number should not greater than the number
+ of phys
This is useless. Either this is implied by the entries in the phys
property, or it should be a runtime decision.
Yes, it can be calculated from @phys, already remove it.
Thanks a lot for your suggestion
Thanks,
Mark.
+
+Optional properties:
+ - vbus-supply : Reference to the VBUS regulator;
+
+Example:
+usb: usb@1127 {
+ compatible = mediatek,mt8173-xhci;
+ reg = 0 0x1127 0 0x4000,
+ 0 0x1128 0 0x0800;
+ interrupts = GIC_SPI 115 IRQ_TYPE_LEVEL_LOW;
+ power-domains = scpsys MT8173_POWER_DOMAIN_USB;
+ clocks = topckgen CLK_TOP_USB30_SEL,
+pericfg CLK_PERI_USB0,
+pericfg CLK_PERI_USB1;
+ clock-names = sys_mac,
+ wakeup_deb_p0,
+ wakeup_deb_p1;
+ phys = u3phy 0, u3phy 1;
+ phy-names = usb-phy0, usb-phy1;
+ vusb33-supply = mt6397_vusb_reg;
+ vbus-supply = usb_p1_vbus;
+ usb3-lpm-capable;
+ mediatek,usb-wakeup = pericfg;
+ mediatek,wakeup-src = 1;
+ mediatek,u2port-num = 2;
+ status = okay;
+};
--
1.8.1.1.dirty
--
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: Values for SetHubDepth and GetPortErrorCount
On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote: In include/linux/usb/hcd.h, we have /* class requests from USB 3.0 hub spec, table 10-5 */ #define SetHubDepth (0x3000 | HUB_SET_DEPTH) #define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT) However, from the usb 3.1 spec I downloaded at http://www.usb.org/developers/docs/, table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed Hub Descriptor). Um, look at the comment you copied 3.0 hub spec, vs. the spec you downloaded and referred to 3.1 spec. Things might have changed :) Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port It appears the correct bmRequestType values should be: #define SetHubDepth (0x2000 | HUB_SET_DEPTH) #define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) Which are the bmRequestType values of SetHubFeature and GetPortStatus (and friends). These lines were introduced in commit 0eadcc09203349b11ca477ec367079b23d32ab91 Author: Tatyana Brokhman tlin...@codeaurora.org Date: Mon Nov 1 18:18:24 2010 +0200 usb: USB3.0 ch11 definitions Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0 spec. Signed-off-by: Tatyana Brokhman tlin...@codeaurora.org Signed-off-by: Greg Kroah-Hartman gre...@suse.de The values are only used by dummy_hcd which does nothing with them and by max3421-hcd which returns an error. Can anyone clarify what I'm missing or if the values are actually wrong? Can you compare the 3.1 to the 3.0 spec and see if they changed things here? 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: USB - Generic Serial device : Unable to read more than 4095 bytes
On 08/06/2015 02:42 AM, arun k wrote: / # lsusb -v Bus 002 Device 006: ID 045b:0218 Bus 001 Device 001: ID 1d6b:0002 Bus 002 Device 001: ID 1d6b:0001 Bus 003 Device 001: ID 1d6b:0002 Bus 004 Device 001: ID 1d6b:0003 In this my device is Bus 002 Device 006: ID 045b:0218 I have no idea what this device is, sorry. And the device descriptor dump below is not very helpful because it doesn't have the configurations. What is this for? I enabled data dumping in usb_serial_generic_read_bulk_callback() function and found data received in this function is losing. In this function data is received as 64 bytes packets and two continuous 64 bytes having no data loss but the next packets are lost ie 1st packet ok(64 byte) 2nd packet ok(64 byte) . . packet lossing . 7th packet ok(64 byte) 8th packet ok(64 byte) . . In this way data loss is happening. Number of packets losing is different not constant always. It's unclear what you are saying here; are you saying (a) the sending device is dropping data so the urbs do not contain the data you expect, or (b) all of the data is being received but the not all of it is being buffered. Either way, the fundamental problem you have is that your reader is not fast enough. What is your application? Have you tried a simple test jig that only reads data without processing it to see if the application is the problem? What h/w platform is this? You mentioned earlier you're running 3.4.35. That's really old; current 3.4 is .108. Where did you get this kernel? Regards, Peter Hurley PS - Please stop top-posting. See how I had to reiterate your linux version... I think the generic USB driver ignores baud rate. Like Greg suggested, you need to use the proper driver for your hardware. I did't find any other suitable driver inside Linux. I checked this device in windows in that usbser.sys is detecting(.inf file is attached with the mail). Could you suggest any available drivers for my device. Sorry I am very new to Linux drivers. I will post my USB device descriptor values below [ 1291.908071] ## udev-descriptor.bLength 0x12 [ 1291.908089] ## udev-descriptor.bDescriptorType 0x1 [ 1291.908147] ## udev-descriptor.bcdUSB 0x200 [ 1291.908165] ## udev-descriptor.bDeviceClass 0xef [ 1291.908181] ## udev-descriptor.bDeviceSubClass 0x2 [ 1291.908196] ## udev-descriptor.bDeviceProtocol 0x1 [ 1291.908211] ## udev-descriptor.bMaxPacketSize0 0x40 [ 1291.908226] ## udev-descriptor.idVendor 0x45b [ 1291.908241] ## udev-descriptor.idProduct 0x218 [ 1291.908255] ## udev-descriptor.bcdDevice 0x1 [ 1291.908270] ## udev-descriptor.iManufacturer 0x0 [ 1291.908284] ## udev-descriptor.iProduct 0x0 [ 1291.908298] ## udev-descriptor.iSerialNumber 0x0 [ 1291.908313] ## udev-descriptor.bNumConfigurations 0x1 Regards, Arun On Wed, Aug 5, 2015 at 9:31 PM, Peter Hurley pe...@hurleysoftware.com wrote: On 08/04/2015 11:57 PM, arun k wrote: Ok, but does the sending device know how to process in-band software flow control and is it set up to respond properly? I am not sure about this. I need to check this. Also, I doubt software flow control is going to work @ 4Mbaud line rate. If you're stuck using software flow control, start with a 115kbaud line rate and see if that fixes your data loss problem I tried B115200 also but issue is still there. I think the generic USB driver ignores baud rate. Like Greg suggested, you need to use the proper driver for your hardware. What is the output from 'lsusb -v' and please identify in that output which device you are using. I am using a USB device and that sending data at a rate of *409600 bytes/sec*. Is this data rate have any relation with issue. Yes. Also, can you test this on a newer kernel like 3.18? Regards, Peter Hurley On Wed, Aug 5, 2015 at 11:24 AM, Peter Hurley pe...@hurleysoftware.com mailto:pe...@hurleysoftware.com wrote: On 08/04/2015 10:00 PM, arun k wrote: I enabled software flow control like below tty.c_iflag |= (IXON | IXOFF | IXANY); Ok, but does the sending device know how to process in-band software flow control and is it set up to respond properly? Also, I doubt software flow control is going to work @ 4Mbaud line rate. If you're stuck using software flow control, start with a 115kbaud line rate and see if that fixes your data loss problem. Regards, Peter Hurley On Wed, Aug 5, 2015 at 12:59 AM, Peter Hurley pe...@hurleysoftware.com mailto:pe...@hurleysoftware.com wrote: On 08/03/2015 10:47 PM, arun k wrote: Thank you for the reply The tty layer is limiting you, just keep reading in a loop until you run out of data, you should not ever expect to read a specific number of bytes from a tty device at a time, the read call will tell you the number that was read properly. I tried this
Re: [PATCH 2/2] usb: musb: gadget: fix build break by adding missing 'break'
On Fri, Aug 07, 2015 at 02:13:34PM +0200, Robert Baldyga wrote: Add missing break after 'default' label to fix compilation error. Signed-off-by: Robert Baldyga r.bald...@samsung.com the funny thing is that this doesn't break with ARM build: $ make ARCH=arm drivers/usb/musb/ CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h UPD include/config/kernel.release CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h make[1]: 'include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh LD drivers/usb/musb/built-in.o CC [M] drivers/usb/musb/musb_core.o CC [M] drivers/usb/musb/musb_virthub.o CC [M] drivers/usb/musb/musb_host.o CC [M] drivers/usb/musb/musb_gadget_ep0.o CC [M] drivers/usb/musb/musb_gadget.o CC [M] drivers/usb/musb/musb_debugfs.o CC [M] drivers/usb/musb/omap2430.o CC [M] drivers/usb/musb/musb_dsps.o CC [M] drivers/usb/musb/musb_am335x.o CC [M] drivers/usb/musb/am35x.o CC [M] drivers/usb/musb/sunxi.o CC [M] drivers/usb/musb/tusb6010.o CC [M] drivers/usb/musb/ux500.o LD [M] drivers/usb/musb/musb_hdrc.o oh well :-p -- balbi signature.asc Description: Digital signature
[PATCH] usb: musb: gadget: fix possible build error
While building MUSB for Blackfin, a build error can surface due to the empty default branch of the switch statement. In order to avoid the problem, just add a ; with a comment. Reported-by: Fengguang Wu fengguang...@intel.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/musb/musb_gadget.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index cc503591b634..b30ed129ddf3 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1703,6 +1703,7 @@ static struct usb_ep *musb_match_ep(struct usb_gadget *g, ep = gadget_find_ep_by_name(g, ep2out); break; default: + /* nothing */ ; } if (ep usb_gadget_ep_match_desc(g, ep, desc, ep_comp)) -- 2.5.0 -- 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: Increasing TRBS_PER_SEGMENT causes DMAR/PTE faults
On 07.08.2015 15:40, linux-...@andraxin.se wrote: Hi there, Hi Moving from 4.0.4 to 4.0.5, my USB 3.0 controller became practically useless (and this same issue persists [at least] upto and including 4.1.3). Here's an excerpt from my syslog demonstrating the problem: ... Looking in ChangeLog-4.0.5 for xhci-related changes gave me 3 hits: (1) xhci: gracefully handle xhci_irq dead device commit 948fa13504f80b9765d2b753691ab94c83a10341 upstream. (2) xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256 commit 18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream. (3) xhci: fix isoc endpoint dequeue from advancing too far on transaction error commit d104d0152a97fade389f47635b73a9ccc7295d0b upstream. The first one seemed fairly irrelevant. The third one mentions DMA, but looking at the actual changes, I couldn't see an obvious connection to the 'PTE read access' issue. So, I tested reverting the second patch in my current (4.1.3) kernel and my USB 3.0 controller started working again. This is good enough for me, but I thought you might want to look more closely at the root cause, and ensure that the PTE is correctly setup even with the increased TRBS_PER_SEGMENT. We just found that the TRBS_PER_SEGMENT reveals an old off by one error in an upper boundary check. Previously a ring segment didn't use a full memory page, and each ring segment was allocated a new page, so the +1 off by one never caused any harm. Now that we use the full memory page the off by one actually allowed us going past the allocated page. This is fixed in patch commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd xhci: fix off by one error in TRB DMA address boundary check Fix is now in Greg's usb-linus branch, and should end up in linus 4.2 kernel (rc6 earliest) Does that fix help in your case? -Mathias -- 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: Values for SetHubDepth and GetPortErrorCount
On Fri, Aug 7, 2015 at 8:31 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Aug 07, 2015 at 07:56:37PM +0300, Tal Shorer wrote:
On Fri, Aug 7, 2015 at 7:37 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote:
In include/linux/usb/hcd.h, we have
/* class requests from USB 3.0 hub spec, table 10-5 */
#define SetHubDepth (0x3000 | HUB_SET_DEPTH)
#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT)
However, from the usb 3.1 spec I downloaded at
http://www.usb.org/developers/docs/,
table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed
Hub Descriptor).
Um, look at the comment you copied 3.0 hub spec, vs. the spec you
downloaded and referred to 3.1 spec. Things might have changed :)
Yeah, my bad.
Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as:
Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of
Link Errors on this port
It appears the correct bmRequestType values should be:
#define SetHubDepth (0x2000 | HUB_SET_DEPTH)
#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)
Which are the bmRequestType values of SetHubFeature and GetPortStatus
(and friends).
These lines were introduced in
commit 0eadcc09203349b11ca477ec367079b23d32ab91
Author: Tatyana Brokhman tlin...@codeaurora.org
Date: Mon Nov 1 18:18:24 2010 +0200
usb: USB3.0 ch11 definitions
Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0
spec.
Signed-off-by: Tatyana Brokhman tlin...@codeaurora.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
The values are only used by dummy_hcd which does nothing with them and
by max3421-hcd which returns an error.
Can anyone clarify what I'm missing or if the values are actually wrong?
Can you compare the 3.1 to the 3.0 spec and see if they changed things
here?
thanks,
greg k-h
USB 3.0 spec download from
http://www.usb.org/developers/docs/documents_archive/
Table 10-6. Hub Class Requests
GetPortErrorCount 1000B GET_PORT_ERR_COUNT Zero Port Two Number of
Link Errors on this port
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
It appears it wasn't changed from 3.0 to 3.1.
Looking at the code in hub.c, it appears root hubs are never called
with SetHubDepth.
1049 if (hdev-parent hub_is_superspeed(hdev)) {
1050 ret = usb_control_msg(hdev,
usb_sndctrlpipe(hdev, 0),
1051 HUB_SET_DEPTH, USB_RT_HUB,
1052 hdev-level - 1, 0, NULL, 0,
1053 USB_CTRL_SET_TIMEOUT);
There are no more uses of HUB_SET_DEPTH except for this one and the one in
hcd.h
tal@tal-H87-D3H:~/Dev/linux|0 $ git grep HUB_SET_DEPTH
drivers/usb/core/hub.c: HUB_SET_DEPTH,
USB_RT_HUB,
include/linux/usb/hcd.h:#define SetHubDepth (0x3000 |
HUB_SET_DEPTH)
include/uapi/linux/usb/ch11.h:#define HUB_SET_DEPTH 12
People use SetHubDepth today.
And HUB_GET_PORT_ERR_COUNT is never used by the hub driver:
tal@tal-H87-D3H:~/Dev/linux|1 $ git grep HUB_GET_PORT_ERR_COUNT
include/linux/usb/hcd.h:#define GetPortErrorCount (0x8000 |
HUB_GET_PORT_ERR_COUNT)
include/uapi/linux/usb/ch11.h:#define HUB_GET_PORT_ERR_COUNT13
So even if the constant was right, root hubs using it would never
reach the code handling it.
But again, GetPortErrorCount is being used.
Yes, but with the current implementation of hub.c, these uses will never
run. I don't really think it's a good idea to delete these uses, since
this feature might be implemented in the future.
Would you prefer to eliminate these completely or make them right in
case anyone uses them in the future?
We should fix these if they were incorrect.
Care to make up a patch?
Sure, I'll send it shortly.
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] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
On Fri, Aug 07, 2015 at 08:52:25PM +0300, Tal Shorer wrote: From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port This doesn't make much sense at all, can you properly format it to look correct? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index c9aa779..d2784c1 100644 --- a/include/linux/usb/hcd.h +++ b/include/linux/usb/hcd.h @@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *); /*-*/ -/* class requests from USB 3.0 hub spec, table 10-5 */ -#define SetHubDepth(0x3000 | HUB_SET_DEPTH) -#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT) +/* class requests from USB 3.1 hub spec, table 10-7 */ +#define SetHubDepth(0x2000 | HUB_SET_DEPTH) +#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) /* * Generic bandwidth allocation constants/support -- 2.4.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB - Generic Serial device : Unable to read more than 4095 bytes
On Fri, Aug 07, 2015 at 07:26:15PM +0900, arun k wrote: Hi, I am stuck with the above issue, I have some doubts regarding USB - Generic driver 1. Could you please explain me why USB - Generic driver is slow ? Because it was designed that way, it is not for high-speed data throughput at all. It is a stop-gap measure for dumb usb devices that want to emulate a serial connection. If you need a real driver, to handle high rates of data, you will need to write a new driver for it. 2. Now I am try to study USB - Generic driver implementation , I am confused with the function usb_serial_generic_read_bulk_callback() , could you please tell me from where this function is calling ? I recommend reading the USB chapter in the Linux Device Drivers book (version 3, free online) to understand how USB drivers work. After that, the answer should be obvious (hint, look at where that function pointer is assigned to something...) 3. If you have any detailed doc regarding the implementation of USB - Generic serial driver, Please send to me, The source code is pretty well documented :) 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: Values for SetHubDepth and GetPortErrorCount
On Fri, Aug 7, 2015 at 7:37 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote:
In include/linux/usb/hcd.h, we have
/* class requests from USB 3.0 hub spec, table 10-5 */
#define SetHubDepth (0x3000 | HUB_SET_DEPTH)
#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT)
However, from the usb 3.1 spec I downloaded at
http://www.usb.org/developers/docs/,
table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed
Hub Descriptor).
Um, look at the comment you copied 3.0 hub spec, vs. the spec you
downloaded and referred to 3.1 spec. Things might have changed :)
Yeah, my bad.
Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as:
Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of
Link Errors on this port
It appears the correct bmRequestType values should be:
#define SetHubDepth (0x2000 | HUB_SET_DEPTH)
#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)
Which are the bmRequestType values of SetHubFeature and GetPortStatus
(and friends).
These lines were introduced in
commit 0eadcc09203349b11ca477ec367079b23d32ab91
Author: Tatyana Brokhman tlin...@codeaurora.org
Date: Mon Nov 1 18:18:24 2010 +0200
usb: USB3.0 ch11 definitions
Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0
spec.
Signed-off-by: Tatyana Brokhman tlin...@codeaurora.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
The values are only used by dummy_hcd which does nothing with them and
by max3421-hcd which returns an error.
Can anyone clarify what I'm missing or if the values are actually wrong?
Can you compare the 3.1 to the 3.0 spec and see if they changed things
here?
thanks,
greg k-h
USB 3.0 spec download from http://www.usb.org/developers/docs/documents_archive/
Table 10-6. Hub Class Requests
GetPortErrorCount 1000B GET_PORT_ERR_COUNT Zero Port Two Number of
Link Errors on this port
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
It appears it wasn't changed from 3.0 to 3.1.
Looking at the code in hub.c, it appears root hubs are never called
with SetHubDepth.
1049 if (hdev-parent hub_is_superspeed(hdev)) {
1050 ret = usb_control_msg(hdev,
usb_sndctrlpipe(hdev, 0),
1051 HUB_SET_DEPTH, USB_RT_HUB,
1052 hdev-level - 1, 0, NULL, 0,
1053 USB_CTRL_SET_TIMEOUT);
There are no more uses of HUB_SET_DEPTH except for this one and the one in hcd.h
tal@tal-H87-D3H:~/Dev/linux|0 $ git grep HUB_SET_DEPTH
drivers/usb/core/hub.c: HUB_SET_DEPTH,
USB_RT_HUB,
include/linux/usb/hcd.h:#define SetHubDepth (0x3000 | HUB_SET_DEPTH)
include/uapi/linux/usb/ch11.h:#define HUB_SET_DEPTH 12
And HUB_GET_PORT_ERR_COUNT is never used by the hub driver:
tal@tal-H87-D3H:~/Dev/linux|1 $ git grep HUB_GET_PORT_ERR_COUNT
include/linux/usb/hcd.h:#define GetPortErrorCount (0x8000 |
HUB_GET_PORT_ERR_COUNT)
include/uapi/linux/usb/ch11.h:#define HUB_GET_PORT_ERR_COUNT13
So even if the constant was right, root hubs using it would never
reach the code handling it.
Would you prefer to eliminate these completely or make them right in
case anyone uses them in the future?
--
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: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
On Fri, Aug 07, 2015 at 08:52:25PM +0300, Tal Shorer wrote: From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index c9aa779..6a24416 100644 --- a/include/linux/usb/hcd.h +++ b/include/linux/usb/hcd.h @@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *); /*-*/ -/* class requests from USB 3.0 hub spec, table 10-5 */ -#define SetHubDepth (0x3000 | HUB_SET_DEPTH) -#define GetPortErrorCount(0x8000 | HUB_GET_PORT_ERR_COUNT) +/* class requests from USB 3.1 hub spec, table 10-7 */ +#define SetHubDepth (0x2000 | HUB_SET_DEPTH) +#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) Why did you loose the indentation? -- 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 v3] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
On Fri, Aug 07, 2015 at 09:16:00PM +0300, Tal Shorer wrote: From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Still does not look correct to me, how about you? -- 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: Values for SetHubDepth and GetPortErrorCount
On Fri, Aug 07, 2015 at 07:56:37PM +0300, Tal Shorer wrote:
On Fri, Aug 7, 2015 at 7:37 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Aug 07, 2015 at 12:49:39PM +0300, Tal Shorer wrote:
In include/linux/usb/hcd.h, we have
/* class requests from USB 3.0 hub spec, table 10-5 */
#define SetHubDepth (0x3000 | HUB_SET_DEPTH)
#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT)
However, from the usb 3.1 spec I downloaded at
http://www.usb.org/developers/docs/,
table 10-5 appears to be unrelated (Table 10-5. Enhanced SuperSpeed
Hub Descriptor).
Um, look at the comment you copied 3.0 hub spec, vs. the spec you
downloaded and referred to 3.1 spec. Things might have changed :)
Yeah, my bad.
Table 10-7 (Table 10-7. Hub Class Requests) lists the two values as:
Request bmRequestType bRequest wValue wIndex wLength Data
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of
Link Errors on this port
It appears the correct bmRequestType values should be:
#define SetHubDepth (0x2000 | HUB_SET_DEPTH)
#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT)
Which are the bmRequestType values of SetHubFeature and GetPortStatus
(and friends).
These lines were introduced in
commit 0eadcc09203349b11ca477ec367079b23d32ab91
Author: Tatyana Brokhman tlin...@codeaurora.org
Date: Mon Nov 1 18:18:24 2010 +0200
usb: USB3.0 ch11 definitions
Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0
spec.
Signed-off-by: Tatyana Brokhman tlin...@codeaurora.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
The values are only used by dummy_hcd which does nothing with them and
by max3421-hcd which returns an error.
Can anyone clarify what I'm missing or if the values are actually wrong?
Can you compare the 3.1 to the 3.0 spec and see if they changed things
here?
thanks,
greg k-h
USB 3.0 spec download from
http://www.usb.org/developers/docs/documents_archive/
Table 10-6. Hub Class Requests
GetPortErrorCount 1000B GET_PORT_ERR_COUNT Zero Port Two Number of
Link Errors on this port
SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None
It appears it wasn't changed from 3.0 to 3.1.
Looking at the code in hub.c, it appears root hubs are never called
with SetHubDepth.
1049 if (hdev-parent hub_is_superspeed(hdev)) {
1050 ret = usb_control_msg(hdev,
usb_sndctrlpipe(hdev, 0),
1051 HUB_SET_DEPTH, USB_RT_HUB,
1052 hdev-level - 1, 0, NULL, 0,
1053 USB_CTRL_SET_TIMEOUT);
There are no more uses of HUB_SET_DEPTH except for this one and the one in
hcd.h
tal@tal-H87-D3H:~/Dev/linux|0 $ git grep HUB_SET_DEPTH
drivers/usb/core/hub.c: HUB_SET_DEPTH,
USB_RT_HUB,
include/linux/usb/hcd.h:#define SetHubDepth (0x3000 |
HUB_SET_DEPTH)
include/uapi/linux/usb/ch11.h:#define HUB_SET_DEPTH 12
People use SetHubDepth today.
And HUB_GET_PORT_ERR_COUNT is never used by the hub driver:
tal@tal-H87-D3H:~/Dev/linux|1 $ git grep HUB_GET_PORT_ERR_COUNT
include/linux/usb/hcd.h:#define GetPortErrorCount (0x8000 |
HUB_GET_PORT_ERR_COUNT)
include/uapi/linux/usb/ch11.h:#define HUB_GET_PORT_ERR_COUNT13
So even if the constant was right, root hubs using it would never
reach the code handling it.
But again, GetPortErrorCount is being used.
Would you prefer to eliminate these completely or make them right in
case anyone uses them in the future?
We should fix these if they were incorrect.
Care to make up a patch?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index c9aa779..6a24416 100644 --- a/include/linux/usb/hcd.h +++ b/include/linux/usb/hcd.h @@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *); /*-*/ -/* class requests from USB 3.0 hub spec, table 10-5 */ -#define SetHubDepth(0x3000 | HUB_SET_DEPTH) -#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT) +/* class requests from USB 3.1 hub spec, table 10-7 */ +#define SetHubDepth (0x2000 | HUB_SET_DEPTH) +#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) /* * Generic bandwidth allocation constants/support -- 2.4.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gadget: Support for the usb charger framework
On Fri, Aug 07, 2015 at 05:22:47PM +0800, Baolin Wang wrote:
On 7 August 2015 at 17:07, Peter Chen peter.c...@freescale.com wrote:
/**
* struct usb_udc - describes one usb device controller @@ -127,12
+128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep, }
EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
+int usb_gadget_register_notify(struct usb_gadget *gadget,
+struct notifier_block *nb) {
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(gadget-lock, flags);
I find you use so many spin_lock_irqsave, any reasons for that?
Why mutex_lock can't be used?
The spin_lock_irqsave() can make it as a atomic notifier, that can make
sure the
gadget state event can be quickly reported to the user who register a
notifier
on the gadget device. Is it OK?
I don't think it is a good reason, spin_lock_irqsave is usually used for
protecting
data which is accessed at atomic environment.
Yes, we want the notify process is a atomic environment which do not
want to be interrupted by irq or other things to make the notice can
be quickly reported to the user.
No, this is a slow event, you don't need to notify anyone under atomic
context, that's crazy.
Also i think the notify process is less cost, thus i use the spinlock. Thanks.
No, use a mutex please, that's the safe thing. This is not
time-critical code at all.
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 0/2] Introduce usb charger framework to deal with the usb gadget power negotation
On Fri, Aug 07, 2015 at 04:19:40PM +0800, Baolin Wang wrote: On 7 August 2015 at 13:34, Peter Chen peter.c...@freescale.com wrote: On Thu, Aug 06, 2015 at 03:03:47PM +0800, Baolin Wang wrote: Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not behave as they should. Providing a standard framework for doing this in the kernel. Baolin, thanks for introducing a framework for doing it, we do support USB Charger for chipidea driver at internal tree, but it is specific for imx, and still have some problems to upstream due to need to change some common code. One suggestion, would you add your user next time? In that case, we can know better for this framework. Peter, Thanks for your reviewing and comments. Now I just introduce the framework to review for more feedbacks and do not have a useful user to use it. I just can show you some example code to show how to use it. Thanks. Without a real, in-tree user, I can not accept this code. We don't add frameworks for non-existant things, otherwise it will be instantly ripped out the next kernel release. Please come up with at least 2 users, ideally 3, otherwise there's no real way to know if the framework is sufficient. 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 v2] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
Please ignore v2, I missed that you On Fri, Aug 7, 2015 at 9:13 PM, Tal Shorer tal.sho...@gmail.com wrote: From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index c9aa779..d2784c1 100644 --- a/include/linux/usb/hcd.h +++ b/include/linux/usb/hcd.h @@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *); /*-*/ -/* class requests from USB 3.0 hub spec, table 10-5 */ -#define SetHubDepth(0x3000 | HUB_SET_DEPTH) -#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT) +/* class requests from USB 3.1 hub spec, table 10-7 */ +#define SetHubDepth(0x2000 | HUB_SET_DEPTH) +#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) /* * Generic bandwidth allocation constants/support -- 2.4.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v3] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index c9aa779..d2784c1 100644 --- a/include/linux/usb/hcd.h +++ b/include/linux/usb/hcd.h @@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *); /*-*/ -/* class requests from USB 3.0 hub spec, table 10-5 */ -#define SetHubDepth(0x3000 | HUB_SET_DEPTH) -#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT) +/* class requests from USB 3.1 hub spec, table 10-7 */ +#define SetHubDepth(0x2000 | HUB_SET_DEPTH) +#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) /* * Generic bandwidth allocation constants/support -- 2.4.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v3] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
On Fri, Aug 7, 2015 at 9:40 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 07, 2015 at 09:16:00PM +0300, Tal Shorer wrote: From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequest wValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth Zero Zero None GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero Port Two Number of Link Errors on this port Still does not look correct to me, how about you? Not sure what you mean. This is a simple copy-paste from the spec document. Do you want me to put quotation marks around the multi-word Data column? -- 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 v4] usb: hcd.h: Fix the values of SetHubDepth and GetPortErrorCount to match USB 3.1 specification
From the usb 3.1 spec available at http://www.usb.org/developers/docs/ table 10-7 (Hub Class Requests) specifies the values for SetHubDepth and GetPortErrorCount as: Request bmRequestType bRequestwValue wIndex wLength Data SetHubDepth 0010B SET_HUB_DEPTH Hub Depth ZeroZeroNone GetPortErrorCount 10100011B GET_PORT_ERR_COUNT Zero PortTwo Number of Link Errors on this port Fix these two values to match the spec. Signed-off-by: Tal Shorer tal.sho...@gmail.com --- include/linux/usb/hcd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index c9aa779..d2784c1 100644 --- a/include/linux/usb/hcd.h +++ b/include/linux/usb/hcd.h @@ -564,9 +564,9 @@ extern void usb_ep0_reinit(struct usb_device *); /*-*/ -/* class requests from USB 3.0 hub spec, table 10-5 */ -#define SetHubDepth(0x3000 | HUB_SET_DEPTH) -#define GetPortErrorCount (0x8000 | HUB_GET_PORT_ERR_COUNT) +/* class requests from USB 3.1 hub spec, table 10-7 */ +#define SetHubDepth(0x2000 | HUB_SET_DEPTH) +#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) /* * Generic bandwidth allocation constants/support -- 2.4.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: gadget: goku_udc: fix build break by adding missing 'break'
Hi Felipe, I see that you already fixed this in your tree. So only the second patch is needed. Thanks, Robert On 08/07/2015 02:13 PM, Robert Baldyga wrote: Add missing break after 'default' label to fix compilation error. Signed-off-by: Robert Baldyga r.bald...@samsung.com --- drivers/usb/gadget/udc/goku_udc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/udc/goku_udc.c b/drivers/usb/gadget/udc/goku_udc.c index 2b628b3..dbb51a4 100644 --- a/drivers/usb/gadget/udc/goku_udc.c +++ b/drivers/usb/gadget/udc/goku_udc.c @@ -1013,6 +1013,7 @@ static struct usb_ep *goku_match_ep(struct usb_gadget *g, } break; default: + break; } return NULL; -- 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 v5 4/5] xhci: mediatek: support MTK xHCI host controller
MTK xhci host controller defines some extra SW scheduling
parameters for HW to minimize the scheduling effort for
synchronous and interrupt endpoints. The parameters are
put into reseved DWs of slot context and endpoint context
Signed-off-by: Chunfeng Yun chunfeng@mediatek.com
---
drivers/usb/host/Kconfig| 9 +
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-mtk-sch.c | 436 +
drivers/usb/host/xhci-mtk.c | 837
drivers/usb/host/xhci-mtk.h | 133 +++
drivers/usb/host/xhci-ring.c| 35 +-
drivers/usb/host/xhci.c | 19 +-
drivers/usb/host/xhci.h | 1 +
8 files changed, 1467 insertions(+), 7 deletions(-)
create mode 100644 drivers/usb/host/xhci-mtk-sch.c
create mode 100644 drivers/usb/host/xhci-mtk.c
create mode 100644 drivers/usb/host/xhci-mtk.h
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..358ab6d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -34,6 +34,15 @@ config USB_XHCI_PCI
config USB_XHCI_PLATFORM
tristate
+config USB_XHCI_MTK
+ tristate xHCI support for Mediatek MT65xx
+ select MFD_SYSCON
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Mediatek MT65xx SoCs.
+ If unsure, say N.
+
config USB_XHCI_MVEBU
tristate xHCI support for Marvell Armada 375/38x
select USB_XHCI_PLATFORM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 754efaa..00401f9 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -13,6 +13,9 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
xhci-hcd-y := xhci.o xhci-mem.o
xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
xhci-hcd-y += xhci-trace.o
+ifneq ($(CONFIG_USB_XHCI_MTK), )
+ xhci-hcd-y += xhci-mtk-sch.o
+endif
xhci-plat-hcd-y := xhci-plat.o
ifneq ($(CONFIG_USB_XHCI_MVEBU), )
@@ -30,6 +33,7 @@ endif
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
new file mode 100644
index 000..d4b41a6
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -0,0 +1,436 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author:
+ * Zhigang.Wei zhigang@mediatek.com
+ * Chunfeng.Yun chunfeng@mediatek.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+
+#include xhci.h
+#include xhci-mtk.h
+
+#define SS_BW_BOUNDARY 51000
+/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
+#define HS_BW_BOUNDARY 6144
+/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
+#define FS_PAYLOAD_MAX 188
+
+/* mtk scheduler bitmasks */
+#define EP_BPKTS(p)((p) 0x3f)
+#define EP_BCSCOUNT(p) (((p) 0x7) 8)
+#define EP_BBM(p) ((p) 11)
+#define EP_BOFFSET(p) ((p) 0x3fff)
+#define EP_BREPEAT(p) (((p) 0x7fff) 16)
+
+static int is_fs_or_ls(enum usb_device_speed speed)
+{
+ return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}
+
+static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
+ struct usb_host_endpoint *ep)
+{
+ int bw_index;
+ int port_id;
+ struct xhci_virt_device *virt_dev;
+
+ virt_dev = xhci-devs[udev-slot_id];
+ port_id = virt_dev-real_port;
+
+ if (udev-speed == USB_SPEED_SUPER) {
+ if (usb_endpoint_dir_out(ep-desc))
+ bw_index = (port_id - 1) * 2;
+ else
+ bw_index = (port_id - 1) * 2 + 1;
+ } else {
+ bw_index = port_id + xhci-num_usb3_ports - 1;
+ }
+
+ return bw_index;
+}
+
+static void setup_sch_info(struct usb_device *udev,
+ struct xhci_ep_ctx *ep_ctx, struct mu3h_sch_ep_info *sch_ep)
+{
+ u32 ep_type;
+ u32 ep_interval;
+ u32 max_packet_size;
+ u32 max_burst;
+ u32 mult;
+ u32 esit_pkts;
+
+ ep_type = CTX_TO_EP_TYPE(le32_to_cpu(ep_ctx-ep_info2));
+ ep_interval = CTX_TO_EP_INTERVAL(le32_to_cpu(ep_ctx-ep_info));
+ max_packet_size = MAX_PACKET_DECODED(le32_to_cpu(ep_ctx-ep_info2));
+ max_burst = CTX_TO_MAX_BURST(le32_to_cpu(ep_ctx-ep_info2));
+ mult =
Mediatek xHCI support
From 5c00619366ce4e7ff2bad050697dd6b3294f38ec Mon Sep 17 00:00:00 2001 From: Chunfeng Yun chunfeng@mediatek.com Date: Fri, 7 Aug 2015 20:16:42 +0800 Subject: [PATCH v5 0/5] Mediatek xHCI support The patch supports MediaTek's xHCI controller. There are some differences from xHCI spec: 1. The interval is specified in 250 * 8ns increments for Interrupt Moderation Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as much as that defined in xHCI spec. 2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a number of packets that remain to be transferred for a TD after processing all Max packets in all previous TRBs,that means don't include the current TRB's, but in xHCI spec it includes the current ones. 3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK architecture defines some extra SW scheduling parameters for HW. According to these parameters provided by SW, the xHC can easily decide whether a synchronous endpoint should be scheduled in a specific uFrame. The extra SW scheduling parameters are put into reserved DWs in Slot and Endpoint Context. And a bandwidth scheduler algorithm is added to support such feature. A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it supports two usb2.0 ports and one usb3.0 port. Change in v5: 1. descripte more exactly for each specifiers in xHCI binding 2. make use of new multi-phy feature for phy driver Chunfeng Yun (5): dt-bindings: Add usb3.0 phy binding for MT65xx SoCs dt-bindings: Add a binding for Mediatek xHCI host controller usb: phy: add usb3.0 phy driver for mt65xx SoCs xhci: mediatek: support MTK xHCI host controller arm64: dts: mediatek: add xHCI usb phy for mt8173 .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 ++ .../devicetree/bindings/usb/mt8173-xhci.txt| 52 ++ arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 16 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 44 ++ drivers/phy/Kconfig| 9 + drivers/phy/Makefile | 1 + drivers/phy/phy-mt65xx-usb3.c | 467 drivers/usb/host/Kconfig | 9 + drivers/usb/host/Makefile | 4 + drivers/usb/host/xhci-mtk-sch.c| 436 +++ drivers/usb/host/xhci-mtk.c| 837 + drivers/usb/host/xhci-mtk.h| 133 drivers/usb/host/xhci-ring.c | 35 +- drivers/usb/host/xhci.c| 19 +- drivers/usb/host/xhci.h| 1 + 15 files changed, 2125 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt create mode 100644 drivers/phy/phy-mt65xx-usb3.c create mode 100644 drivers/usb/host/xhci-mtk-sch.c create mode 100644 drivers/usb/host/xhci-mtk.c create mode 100644 drivers/usb/host/xhci-mtk.h -- 1.8.1.1.dirty -- 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 v5 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs
support usb3.0 phy of mt65xx SoCs Signed-off-by: Chunfeng Yun chunfeng@mediatek.com --- drivers/phy/Kconfig | 9 + drivers/phy/Makefile | 1 + drivers/phy/phy-mt65xx-usb3.c | 467 ++ 3 files changed, 477 insertions(+) create mode 100644 drivers/phy/phy-mt65xx-usb3.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index c0e6ede..019cf8b 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA help Support for SATA PHY on Hisilicon hix5hd2 Soc. +config PHY_MT65XX_USB3 + tristate Mediatek USB3.0 PHY Driver + depends on ARCH_MEDIATEK OF + select GENERIC_PHY + help + Say 'Y' here to add support for Mediatek USB3.0 PHY driver + for mt65xx SoCs. it supports two usb2.0 ports and + one usb3.0 port. + config PHY_SUN4I_USB tristate Allwinner sunxi SoC USB PHY driver depends on ARCH_SUNXI HAS_IOMEM OF diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index f344e1b..3ceff2a 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3)+= phy-ti-pipe3.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o +obj-$(CONFIG_PHY_MT65XX_USB3) += phy-mt65xx-usb3.o obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c new file mode 100644 index 000..6835bff --- /dev/null +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -0,0 +1,467 @@ +/* + * Copyright (c) 2015 MediaTek Inc. + * Author: Chunfeng Yun chunfeng@mediatek.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include dt-bindings/phy/phy.h +#include linux/clk.h +#include linux/delay.h +#include linux/io.h +#include linux/module.h +#include linux/of_address.h +#include linux/phy/phy.h +#include linux/platform_device.h + +/* + * for sifslv2 register, but exclude port's; + * relative to USB3_SIF2_BASE base address + */ +#define SSUSB_SIFSLV_SPLLC 0x + +/* offsets of sub-segment in each port registers */ +#define SSUSB_SIFSLV_U2PHY_COM_BASE0x +#define SSUSB_SIFSLV_U3PHYD_BASE 0x0100 +#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300 +#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400 + +#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) +#define PA0_RG_U2PLL_FORCE_ON BIT(15) + +#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) +#define PA2_RG_SIF_U2PLL_FORCE_EN BIT(18) + +#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) +#define PA5_RG_U2_HSTX_SRCTRL (0x7 12) +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 (x)) 12) +#define PA5_RG_U2_HS_100U_U3_ENBIT(11) + +#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) +#define PA6_RG_U2_ISO_EN BIT(31) +#define PA6_RG_U2_BC11_SW_EN BIT(23) +#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) + +#define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) +#define P2C_RG_USB20_GPIO_CTL BIT(9) +#define P2C_USB20_GPIO_MODEBIT(8) +#define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE) + +#define U3D_U2PHYDCR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) +#define P2C_RG_SIF_U2PLL_FORCE_ON BIT(24) + +#define U3P_U2PHYDTM0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) +#define P2C_FORCE_UART_EN BIT(26) +#define P2C_FORCE_DATAIN BIT(23) +#define P2C_FORCE_DM_PULLDOWN BIT(21) +#define P2C_FORCE_DP_PULLDOWN BIT(20) +#define P2C_FORCE_XCVRSEL BIT(19) +#define P2C_FORCE_SUSPENDM BIT(18) +#define P2C_FORCE_TERMSEL BIT(17) +#define P2C_RG_DATAIN (0xf 10) +#define P2C_RG_DATAIN_VAL(x) ((0xf (x)) 10) +#define P2C_RG_DMPULLDOWN BIT(7) +#define P2C_RG_DPPULLDOWN BIT(6) +#define P2C_RG_XCVRSEL (0x3 4) +#define P2C_RG_XCVRSEL_VAL(x) ((0x3 (x)) 4) +#define P2C_RG_SUSPENDMBIT(3) +#define P2C_RG_TERMSEL BIT(2) +#define P2C_DTM0_PART_MASK \ + (P2C_FORCE_DATAIN | P2C_FORCE_DM_PULLDOWN | \ +
[PATCH v5 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller
add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.
Signed-off-by: Chunfeng Yun chunfeng@mediatek.com
---
.../devicetree/bindings/usb/mt8173-xhci.txt| 52 ++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..8e6e463
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,52 @@
+mt65XX xHCI
+
+The device node for Mediatek SOC usb3.0 host controller
+
+Required properties:
+ - compatible : should contain mediatek,mt8173-xhci
+ - reg : specifies physical base address and size of the registers,
+ the first one for MAC, the second for IPPC
+ - interrupts : interrupt used by the controller
+ - power-domains : a phandle to USB power domain node to control usb's
+ mtcmos
+ - vusb33-supply : regulator of usb avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ sys_ck: for clock of xHCI MAC
+ wakeup_deb_p0: for usb wakeup debounce clock of port0
+ wakeup_deb_p0: for usb wakeup debounce clock of port1
+
+ - phys : a list of phandle + phy specifier pairs
+ - usb3-lpm-capable : supports USB3 LPM
+ - mediatek,syscon-wakeup : phandle to syscon used to access usb wakeup
+ control register
+ - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
+ mode; others means don't enable wakeup source of usb
+
+Optional properties:
+ - vbus-supply : Reference to the VBUS regulator;
+
+Example:
+usb30: usb@1127 {
+ compatible = mediatek,mt8173-xhci;
+ reg = 0 0x1127 0 0x4000,
+ 0 0x1128 0 0x0800;
+ interrupts = GIC_SPI 115 IRQ_TYPE_LEVEL_LOW;
+ power-domains = scpsys MT8173_POWER_DOMAIN_USB;
+ clocks = topckgen CLK_TOP_USB30_SEL,
+pericfg CLK_PERI_USB0,
+pericfg CLK_PERI_USB1;
+ clock-names = sys_ck,
+ wakeup_deb_p0,
+ wakeup_deb_p1;
+ phys = phy_port0 PHY_TYPE_USB3,
+ phy_port1 PHY_TYPE_USB2;
+ vusb33-supply = mt6397_vusb_reg;
+ vbus-supply = usb_p1_vbus;
+ usb3-lpm-capable;
+ mediatek,syscon-wakeup = pericfg;
+ mediatek,wakeup-src = 1;
+ status = okay;
+};
--
1.8.1.1.dirty
--
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 v5 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
add a DT binding documentation of usb3.0 phy for MT65xx
SoCs from Mediatek.
Signed-off-by: Chunfeng Yun chunfeng@mediatek.com
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 ++
1 file changed, 69 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
new file mode 100644
index 000..5812d20
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -0,0 +1,69 @@
+mt65xx USB3.0 PHY binding
+--
+
+This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+
+Required properties (controller (parent) node):
+ - compatible : should be mediatek,mt8173-u3phy
+ - reg : offset and length of register for phy, exclude port's
+ register.
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ u3phya_ref: for reference clock of usb3.0 analog phy.
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology. These nodes are translated
+ by the driver's .xlate() function.
+
+Required properties (port (child) node):
+- reg : address and length of the register set for the port.
+- #phy-cells : should be 1 (See second example)
+ cell after port phandle is phy type from:
+ - PHY_TYPE_USB2
+ - PHY_TYPE_USB3
+
+Example:
+
+u3phy: usb-phy@1129 {
+ compatible = mediatek,mt8173-u3phy;
+ reg = 0 0x1129 0 0x800;
+ clocks = apmixedsys CLK_APMIXED_REF2USB_TX;
+ clock-names = u3phya_ref;
+ #address-cells = 2;
+ #size-cells = 2;
+ ranges;
+ status = okay;
+
+ phy_port0: port@11290800 {
+ reg = 0 0x11290800 0 0x800;
+ #phy-cells = 1;
+ status = okay;
+ };
+
+ phy_port1: port@11291000 {
+ reg = 0 0x11291000 0 0x800;
+ #phy-cells = 1;
+ status = okay;
+ };
+};
+
+Specifying phy control of devices
+-
+
+Device nodes should specify the configuration required in their phys
+property, containing a phandle to the phy port node and a device type;
+phy-names for each port are optional.
+
+Example:
+
+#include dt-bindings/phy/phy.h
+
+usb30: usb@1127 {
+ ...
+ phys = phy_port0 PHY_TYPE_USB3;
+ phy-names = usb3-0;
+ ...
+};
--
1.8.1.1.dirty
--
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: musb: gadget: fix build break by adding missing 'break'
Add missing break after 'default' label to fix compilation error. Signed-off-by: Robert Baldyga r.bald...@samsung.com --- drivers/usb/musb/musb_gadget.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 5f52bcb..31049d3 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1706,6 +1706,7 @@ static struct usb_ep *musb_match_ep(struct usb_gadget *g, ep = gadget_find_ep_by_name(g, ep2out); break; default: + break; } if (ep usb_gadget_ep_match_desc(g, ep, desc, ep_comp)) -- 1.9.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/2] usb: gadget: goku_udc: fix build break by adding missing 'break'
Add missing break after 'default' label to fix compilation error. Signed-off-by: Robert Baldyga r.bald...@samsung.com --- drivers/usb/gadget/udc/goku_udc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/udc/goku_udc.c b/drivers/usb/gadget/udc/goku_udc.c index 2b628b3..dbb51a4 100644 --- a/drivers/usb/gadget/udc/goku_udc.c +++ b/drivers/usb/gadget/udc/goku_udc.c @@ -1013,6 +1013,7 @@ static struct usb_ep *goku_match_ep(struct usb_gadget *g, } break; default: + break; } return NULL; -- 1.9.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 v5 5/5] arm64: dts: mediatek: add xHCI usb phy for mt8173
add xHCI and phy drivers for MT8173-EVB
Signed-off-by: Chunfeng Yun chunfeng@mediatek.com
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 16 +++
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 44 +
2 files changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index f433c21..112f3f3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -13,6 +13,7 @@
*/
/dts-v1/;
+#include dt-bindings/gpio/gpio.h
#include mt8173.dtsi
/ {
@@ -32,6 +33,15 @@
};
chosen { };
+
+ usb_p1_vbus: regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = usb_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = pio 130 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
};
pwrap {
@@ -211,3 +221,9 @@
uart0 {
status = okay;
};
+
+usb30 {
+ vusb33-supply = mt6397_vusb_reg;
+ vbus-supply = usb_p1_vbus;
+ mediatek,wakeup-src = 1;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 0696f8f..f88b2f9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,8 @@
#include dt-bindings/clock/mt8173-clk.h
#include dt-bindings/interrupt-controller/irq.h
#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/phy/phy.h
+#include dt-bindings/power/mt8173-power.h
#include dt-bindings/reset-controller/mt8173-resets.h
#include mt8173-pinfunc.h
@@ -393,6 +395,48 @@
#size-cells = 0;
status = disabled;
};
+
+ usb30: usb@1127 {
+ compatible = mediatek,mt8173-xhci;
+ reg = 0 0x1127 0 0x4000,
+ 0 0x1128 0 0x0800;
+ interrupts = GIC_SPI 115 IRQ_TYPE_LEVEL_LOW;
+ power-domains = scpsys MT8173_POWER_DOMAIN_USB;
+ clocks = topckgen CLK_TOP_USB30_SEL,
+pericfg CLK_PERI_USB0,
+pericfg CLK_PERI_USB1;
+ clock-names = sys_ck,
+ wakeup_deb_p0,
+ wakeup_deb_p1;
+ phys = phy_port0 PHY_TYPE_USB3,
+ phy_port1 PHY_TYPE_USB2;
+ usb3-lpm-capable;
+ mediatek,syscon-wakeup = pericfg;
+ status = okay;
+ };
+
+ u3phy: usb-phy@1129 {
+ compatible = mediatek,mt8173-u3phy;
+ reg = 0 0x1129 0 0x800;
+ clocks = apmixedsys CLK_APMIXED_REF2USB_TX;
+ clock-names = u3phya_ref;
+ #address-cells = 2;
+ #size-cells = 2;
+ ranges;
+ status = okay;
+
+ phy_port0: port@11290800 {
+ reg = 0 0x11290800 0 0x800;
+ #phy-cells = 1;
+ status = okay;
+ };
+
+ phy_port1: port@11291000 {
+ reg = 0 0x11291000 0 0x800;
+ #phy-cells = 1;
+ status = okay;
+ };
+ };
};
};
--
1.8.1.1.dirty
--
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
Increasing TRBS_PER_SEGMENT causes DMAR/PTE faults
Hi there, Moving from 4.0.4 to 4.0.5, my USB 3.0 controller became practically useless (and this same issue persists [at least] upto and including 4.1.3). Here's an excerpt from my syslog demonstrating the problem: -=-=- Jun 24 23:15:22 eleven kernel: usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd Jun 24 23:15:22 eleven kernel: usb 2-4: New USB device found, idVendor=0781, idProduct=5588 Jun 24 23:15:22 eleven kernel: usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jun 24 23:15:22 eleven kernel: usb 2-4: Product: ExtremePro Jun 24 23:15:22 eleven kernel: usb 2-4: Manufacturer: SanDisk Jun 24 23:15:22 eleven kernel: usb 2-4: SerialNumber: AA010602150045080168 Jun 24 23:15:22 eleven kernel: usb-storage 2-4:1.0: USB Mass Storage device detected Jun 24 23:15:22 eleven kernel: scsi host8: usb-storage 2-4:1.0 Jun 24 23:15:21 eleven mtp-probe[19425]: checking bus 2, device 2: /sys/devices/pci:00/:00:1c.4/:03:00.0/usb2/2-4 Jun 24 23:15:21 eleven mtp-probe[19425]: bus: 2, device: 2 was not an MTP device Jun 24 23:15:23 eleven kernel: scsi 8:0:0:0: Direct-Access SanDisk ExtremePro 0001 PQ: 0 ANSI: 6 Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] 250069680 512-byte logical blocks: (128 GB/119 GiB) Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] Write Protect is off Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] Mode Sense: 53 00 00 08 Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Jun 24 23:15:23 eleven kernel: sdi: sdi1 sdi2 sdi3 sdi4 Jun 24 23:15:23 eleven kernel: sd 8:0:0:0: [sdi] Attached SCSI removable disk Jun 24 23:15:23 eleven kernel: dmar: DRHD: handling fault status reg 2 Jun 24 23:15:23 eleven kernel: dmar: DMAR:[DMA Read] Request device [03:00.0] fault addr fffbd000 \x0aDMAR:[fault reason 06] PTE Read access is not set Jun 24 23:15:23 eleven kernel: dmar: DRHD: handling fault status reg 2 Jun 24 23:15:23 eleven kernel: dmar: DMAR:[DMA Read] Request device [03:00.0] fault addr fffbd000 \x0aDMAR:[fault reason 06] PTE Read access is not set Jun 24 23:15:23 eleven kernel: xhci_hcd :03:00.0: WARNING: Host System Error Jun 24 23:16:13 eleven kernel: xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead Jun 24 23:16:15 eleven kernel: xhci_hcd :03:00.0: Abort command ring failed Jun 24 23:16:15 eleven kernel: xhci_hcd :03:00.0: HC died; cleaning up Jun 24 23:16:15 eleven kernel: xhci_hcd :03:00.0: Timeout while waiting for setup device command Jun 24 23:16:15 eleven kernel: usb 1-1: USB disconnect, device number 2 Jun 24 23:16:15 eleven kernel: usb 2-4: USB disconnect, device number 0 -=-=- This is a VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller inserted into an older Gigabyte board with Intel Q35 chipset, VT-d enabled... Looking in ChangeLog-4.0.5 for xhci-related changes gave me 3 hits: (1) xhci: gracefully handle xhci_irq dead device commit 948fa13504f80b9765d2b753691ab94c83a10341 upstream. (2) xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256 commit 18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream. (3) xhci: fix isoc endpoint dequeue from advancing too far on transaction error commit d104d0152a97fade389f47635b73a9ccc7295d0b upstream. The first one seemed fairly irrelevant. The third one mentions DMA, but looking at the actual changes, I couldn't see an obvious connection to the 'PTE read access' issue. So, I tested reverting the second patch in my current (4.1.3) kernel and my USB 3.0 controller started working again. This is good enough for me, but I thought you might want to look more closely at the root cause, and ensure that the PTE is correctly setup even with the increased TRBS_PER_SEGMENT. Kind regards, --@; PS I'd _love_ to help, but I have very little screen time. I'm lucky if I can turn on this box once a week... (That's also why it took me almost 2 months to figure out what the problem was.) DS -- 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
