[PATCH V5 4/6] USB: OHCI: make ohci-spear a separate driver
Separate the ST OHCI SPEAr host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Deepak Saxena dsax...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu
Cc: Viresh Kumar viresh.li...@gmail.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-ohci_setup() removed because it is called in .reset member
of the ohci_hc_driver structure.
-debugging stuff isn't needed any more that's what removed.
V3:
No change.
V4:
No change.
V5:
No change.
---
drivers/usb/host/Kconfig |8 +++
drivers/usb/host/Makefile |1 +
drivers/usb/host/ohci-hcd.c | 18 --
drivers/usb/host/ohci-spear.c | 140 +
4 files changed, 65 insertions(+), 102 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3eab432..a5a34a3 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -382,6 +382,14 @@ config USB_OHCI_HCD_OMAP1
---help---
Enables support for the OHCI controller on OMAP1/2 chips.
+config USB_OHCI_HCD_SPEAR
+tristate Support for ST SPEAr on-chip OHCI USB controller
+depends on USB_OHCI_HCD PLAT_SPEAR
+default y
+---help---
+ Enables support for the on-chip OHCI controller on
+ ST SPEAr chips.
+
config USB_OHCI_HCD_OMAP3
tristate OHCI support for OMAP3 and later chips
depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index a0064a6..8cc3f63 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PLATFORM) += ohci-platform.o
obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o
obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o
obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
+obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index cad51d2..34ec156 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1212,11 +1212,6 @@ MODULE_LICENSE (GPL);
#define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver
#endif
-#ifdef CONFIG_PLAT_SPEAR
-#include ohci-spear.c
-#define SPEAR_PLATFORM_DRIVER spear_ohci_hcd_driver
-#endif
-
#ifdef CONFIG_PPC_PS3
#include ohci-ps3.c
#define PS3_SYSTEM_BUS_DRIVER ps3_ohci_driver
@@ -1333,19 +1328,9 @@ static int __init ohci_hcd_mod_init(void)
goto error_davinci;
#endif
-#ifdef SPEAR_PLATFORM_DRIVER
- retval = platform_driver_register(SPEAR_PLATFORM_DRIVER);
- if (retval 0)
- goto error_spear;
-#endif
-
return retval;
/* Error path */
-#ifdef SPEAR_PLATFORM_DRIVER
- platform_driver_unregister(SPEAR_PLATFORM_DRIVER);
- error_spear:
-#endif
#ifdef DAVINCI_PLATFORM_DRIVER
platform_driver_unregister(DAVINCI_PLATFORM_DRIVER);
error_davinci:
@@ -1403,9 +1388,6 @@ module_init(ohci_hcd_mod_init);
static void __exit ohci_hcd_mod_exit(void)
{
-#ifdef SPEAR_PLATFORM_DRIVER
- platform_driver_unregister(SPEAR_PLATFORM_DRIVER);
-#endif
#ifdef DAVINCI_PLATFORM_DRIVER
platform_driver_unregister(DAVINCI_PLATFORM_DRIVER);
#endif
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index cc9dd9e..31ff3fc 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -11,92 +11,37 @@
* warranty of any kind, whether express or implied.
*/
-#include linux/signal.h
-#include linux/platform_device.h
#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/of.h
+#include linux/platform_device.h
+#include linux/signal.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ohci.h
+#define DRIVER_DESC OHCI SPEAr driver
+
+static const char hcd_name[] = SPEAr-ohci;
struct spear_ohci {
- struct ohci_hcd ohci;
struct clk *clk;
};
-#define to_spear_ohci(hcd) (struct spear_ohci *)hcd_to_ohci(hcd)
-
-static void spear_start_ohci(struct spear_ohci *ohci)
-{
- clk_prepare_enable(ohci-clk);
-}
-
-static void spear_stop_ohci(struct spear_ohci *ohci)
-{
- clk_disable_unprepare(ohci-clk);
-}
-
-static int ohci_spear_start(struct usb_hcd *hcd)
-{
- struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- int ret;
-
- ret = ohci_init(ohci);
- if (ret 0)
- return ret;
- ohci-regs = hcd-regs;
-
- ret = ohci_run(ohci);
- if (ret 0) {
- dev_err(hcd-self.controller, can't start\n);
- ohci_stop(hcd);
- return ret;
- }
-
-
[PATCH V5 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
Separate the Samsung OHCI S3C24xx/S3C64xx host controller driver from ohci-hcd host code so that it can be built as a separate driver module.This work is part of enabling multi-platform kernels on ARM;it would be nice to have in 3.12. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Signed-off-by: Deepak Saxena dsax...@linaro.org Acked-by: Alan Stern st...@rowland.harvard.edu Cc: Arnd Bergmann a...@arndb.de Cc: Greg KH g...@kroah.com Cc: linux-usb@vger.kernel.org V2: -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather than relying on an expanded struct ohci_driver_overrides. -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than relying on ohci_hub_control and hub_status_data being exported. V3: -Kconfig wrong parentheses discription fixed. -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. V4: - Removed extra space before the '='. - Moved /* forward definitions */ line before the declarations of functions. V5: - String s3c is replaced by s3c2410. --- drivers/usb/host/Kconfig|8 +++ drivers/usb/host/Makefile |1 + drivers/usb/host/ohci-hcd.c | 18 -- drivers/usb/host/ohci-s3c2410.c | 128 +-- 4 files changed, 66 insertions(+), 89 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 693560a..ac7df55 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR Enables support for the on-chip OHCI controller on ST SPEAr chips. +config USB_OHCI_HCD_S3C2410 +tristate OHCI support for Samsung S3C24xx/S3C64xx SoC series +depends on USB_OHCI_HCD (ARCH_S3C24XX || ARCH_S3C64XX) +default y +---help--- + Enables support for the on-chip OHCI controller on + S3C24xx/S3C64xx chips. + config USB_OHCI_HCD_AT91 tristate Support for Atmel on-chip OHCI USB controller depends on USB_OHCI_HCD ARCH_AT91 diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index a0ac663..cc5beaf 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -49,6 +49,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o +obj-$(CONFIG_USB_OHCI_HCD_S3C2410) += ohci-s3c2410.o obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o obj-$(CONFIG_USB_FHCI_HCD) += fhci.o diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index b48c892..b69a49e 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1177,11 +1177,6 @@ MODULE_LICENSE (GPL); #define SA_DRIVER ohci_hcd_sa_driver #endif -#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX) -#include ohci-s3c2410.c -#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver -#endif - #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx) #include ohci-pxa27x.c #define PLATFORM_DRIVERohci_hcd_pxa27x_driver @@ -1293,12 +1288,6 @@ static int __init ohci_hcd_mod_init(void) goto error_tmio; #endif -#ifdef S3C2410_PLATFORM_DRIVER - retval = platform_driver_register(S3C2410_PLATFORM_DRIVER); - if (retval 0) - goto error_s3c2410; -#endif - #ifdef EP93XX_PLATFORM_DRIVER retval = platform_driver_register(EP93XX_PLATFORM_DRIVER); if (retval 0) @@ -1332,10 +1321,6 @@ static int __init ohci_hcd_mod_init(void) platform_driver_unregister(EP93XX_PLATFORM_DRIVER); error_ep93xx: #endif -#ifdef S3C2410_PLATFORM_DRIVER - platform_driver_unregister(S3C2410_PLATFORM_DRIVER); - error_s3c2410: -#endif #ifdef TMIO_OHCI_DRIVER platform_driver_unregister(TMIO_OHCI_DRIVER); error_tmio: @@ -1382,9 +1367,6 @@ static void __exit ohci_hcd_mod_exit(void) #ifdef EP93XX_PLATFORM_DRIVER platform_driver_unregister(EP93XX_PLATFORM_DRIVER); #endif -#ifdef S3C2410_PLATFORM_DRIVER - platform_driver_unregister(S3C2410_PLATFORM_DRIVER); -#endif #ifdef TMIO_OHCI_DRIVER platform_driver_unregister(TMIO_OHCI_DRIVER); #endif diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c index e125770..61f9aea 100644 --- a/drivers/usb/host/ohci-s3c2410.c +++ b/drivers/usb/host/ohci-s3c2410.c @@ -19,19 +19,36 @@ * This file is licenced under the GPL. */ -#include linux/platform_device.h #include linux/clk.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h +#include linux/platform_device.h #include linux/platform_data/usb-ohci-s3c2410.h +#include linux/usb.h +#include linux/usb/hcd.h + +#include ohci.h + #define valid_port(idx) ((idx) == 1 || (idx) == 2) /* clock device associated with the hcd */ + +#define DRIVER_DESC OHCI S3C2410 driver +
[PATCH V5 5/6] USB: OHCI: make ohci-at91 a separate driver
Separate the TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Deepak Saxena dsax...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
-Set non-standard fields in ohci_at91_hc_driver manually, rather than
relying on an expanded struct ohci_driver_overrides.
-Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
relying on ohci_hub_control and hub_status_data being exported.
-ohci_setup() has been removed because it is called in .reset member
of the ohci_hc_driver structure.
V3:
-The ohci_restart() function is not required in current scenario,
only discarding connection state of integrated transceivers is sufficient,
for this directly handling ohci-hc_control.
V4:
- Removed extra space after tristate.
- Removed extra space between function name and '(' characters.
- MODULE_ALIAS line moved to last statement of ohci-at91 file.
V5:
-No change.
---
drivers/usb/host/Kconfig |8 +++
drivers/usb/host/Makefile|1 +
drivers/usb/host/ohci-at91.c | 153 +++---
drivers/usb/host/ohci-hcd.c | 18 -
4 files changed, 77 insertions(+), 103 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a5a34a3..693560a 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
Enables support for the on-chip OHCI controller on
ST SPEAr chips.
+config USB_OHCI_HCD_AT91
+tristate Support for Atmel on-chip OHCI USB controller
+depends on USB_OHCI_HCD ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip OHCI controller on
+ Atmel chips.
+
config USB_OHCI_HCD_OMAP3
tristate OHCI support for OMAP3 and later chips
depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 8cc3f63..a0ac663 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o
obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o
obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
+obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9677f68..08e28eb 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -13,27 +13,41 @@
*/
#include linux/clk.h
-#include linux/platform_device.h
+#include linux/dma-mapping.h
#include linux/of_platform.h
#include linux/of_gpio.h
+#include linux/platform_device.h
#include linux/platform_data/atmel.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/hcd.h
#include mach/hardware.h
#include asm/gpio.h
#include mach/cpu.h
-#ifndef CONFIG_ARCH_AT91
-#error CONFIG_ARCH_AT91 must be defined.
-#endif
+
+#include ohci.h
#define valid_port(index) ((index) = 0 (index) AT91_MAX_USBH_PORTS)
#define at91_for_each_port(index) \
for ((index) = 0; (index) AT91_MAX_USBH_PORTS; (index)++)
/* interface and function clocks; sometimes also an AHB clock */
+
+#define DRIVER_DESC OHCI Atmel driver
+
+static const char hcd_name[] = ohci-atmel;
+
+static struct hc_driver __read_mostly ohci_at91_hc_driver;
static struct clk *iclk, *fclk, *hclk;
static int clocked;
+static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
+ u16 wValue, u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
extern int usb_disabled(void);
@@ -111,6 +125,8 @@ static void usb_hcd_at91_remove (struct usb_hcd *, struct
platform_device *);
static int usb_hcd_at91_probe(const struct hc_driver *driver,
struct platform_device *pdev)
{
+ struct at91_usbh_data *board;
+ struct ohci_hcd *ohci;
int retval;
struct usb_hcd *hcd = NULL;
@@ -163,8 +179,10 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
goto err5;
}
+ board = hcd-self.controller-platform_data;
+ ohci = hcd_to_ohci(hcd);
+ ohci-num_ports = board-ports;
at91_start_hc(pdev);
- ohci_hcd_init(hcd_to_ohci(hcd));
retval = usb_add_hcd(hcd, pdev-resource[1].start, IRQF_SHARED);
if (retval == 0)
@@ -221,36 +239,6 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
}
[3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used
Hi, Tejun Heo wrote: This avoids the described deadlock because iosched module doesn't use async and thus wouldn't invoke async_synchronize_full(). This is hacky and incomplete. It will deadlock if async module loading nests; however, this works around the known problem case and seems to be the best of bad options. For more details, please refer to the following thread. http://thread.gmane.org/gmane.linux.kernel/1420814 My laptop fails to boot[1] with the message 'Volume group data not found'. Bisects to v3.8-rc4~17 (the above commit). Reverting that commit on top of current master (d92581fcad18, 2013-08-10) produces a working kernel. dmesg output from that working kernel attached. More details, including .config, at [2]. Any ideas for tracking this down? Thanks, Jonathan [1] Screenshot: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=bad_3.10.3-1.jpg;att=1;bug=719464 Screenshot in recovery mode: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=bad_3.10.3-1_recovery.jpg;att=2;bug=719464 [2] http://bugs.debian.org/719464 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11.0-rc4+ (jrn@elie) (gcc version 4.7.3 (Debian 4.7.3-6) ) #2 SMP Sun Aug 11 23:20:20 PDT 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.11.0-rc4+ root=/dev/mapper/data-root ro quiet [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x6e545fff] usable [0.00] BIOS-e820: [mem 0x6e546000-0x6e745fff] ACPI NVS [0.00] BIOS-e820: [mem 0x6e746000-0x6fd3efff] usable [0.00] BIOS-e820: [mem 0x6fd3f000-0x6fdbefff] reserved [0.00] BIOS-e820: [mem 0x6fdbf000-0x6febefff] ACPI NVS [0.00] BIOS-e820: [mem 0x6febf000-0x6fef6fff] ACPI data [0.00] BIOS-e820: [mem 0x6fef7000-0x6fef] usable [0.00] BIOS-e820: [mem 0xf800-0xf8ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffe0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: TOSHIBA Satellite C650D/Portable PC, BIOS 1.60 09/02/2010 [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x6ff00 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base mask C000 write-back [0.00] 1 base 4000 mask E000 write-back [0.00] 2 base 6000 mask F000 write-back [0.00] 3 base 6FEBE000 mask F000 uncachable [0.00] 4 base FFE0 mask FFE0 write-protect [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x0184c000, 0x0184cfff] PGTABLE [0.00] BRK [0x0184d000, 0x0184dfff] PGTABLE [0.00] BRK [0x0184e000, 0x0184efff] PGTABLE [0.00] init_memory_mapping: [mem 0x6fa0-0x6fbf] [0.00] [mem 0x6fa0-0x6fbf] page 2M [0.00] BRK [0x0184f000, 0x0184] PGTABLE [0.00] init_memory_mapping: [mem 0x6c00-0x6e545fff] [0.00] [mem 0x6c00-0x6e3f] page 2M [0.00] [mem 0x6e40-0x6e545fff] page 4k [0.00] BRK [0x0185, 0x01850fff] PGTABLE [0.00] init_memory_mapping: [mem 0x6e746000-0x6f9f] [0.00] [mem 0x6e746000-0x6e7f] page 4k [0.00] [mem 0x6e80-0x6f9f] page 2M [0.00] init_memory_mapping: [mem 0x0010-0x6bff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x6bff] page 2M [0.00]
Re: [PATCH] usb: chipidea: enable to build host support as module
Hi Peter, On Mon, Aug 12, 2013 at 09:28:28AM +0800, Peter Chen wrote: On Sun, Aug 11, 2013 at 01:00:49PM +0200, Luka Perkov wrote: USB_CHIPIDEA_HOST does not need to depend on USB=y, USB_CHIPIDEA_HOST will work just fine even if USB=m is used. The depends line can be safely removed since USB_CHIPIDEA already depends on USB. ... Lothar has already posted a solution for it. http://marc.info/?l=linux-usbm=137533651927159w=2 Great, didn't know that. Luka -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] staging: dwc2: add NAK holdoff patch from downstream Pi kernel
Hi Paul,
Add the NAK holdoff patch from the downstream Raspberry Pi kernel.
This allows the transfer scheduler to better handle cheeky devices
that just hold off using NAKs.
@@ -365,6 +366,7 @@ struct dwc2_hsotg {
u8 otg_port;
u32 *frame_list;
dma_addr_t frame_list_dma;
+ int next_sched_frame;
This variable is still not really used, I think. Most of the mentions in
the patch are assignments, except for these two:
+ if (list_empty(hsotg-periodic_sched_inactive) ||
+ dwc2_frame_num_le(qh-sched_frame, hsotg-next_sched_frame))
+ hsotg-next_sched_frame = qh-sched_frame;
+
...
+ if (!dwc2_frame_num_le(hsotg-next_sched_frame,
+qh-sched_frame))
+ hsotg-next_sched_frame =
+ qh-sched_frame;
However, these two uses of the variable have only the single purpose
of updating the variable itself, no other behaviour is influenced by it.
In effect, the variable does not influence the code at all and can be
dropped, significantly simplifying this patch.
Gr.
Matthijs
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] staging: dwc2: add microframe scheduler from downstream Pi kernel
Hi Paul Dom,
I haven't got time to look closely right now, but at first glance most
of my comments have been resolved. One thing that is still in there, is
this piece of code for which I'm not sure if it is really related to the
topic of the patch:
@@ -780,6 +784,10 @@ static void dwc2_assign_and_init_hc(struct dwc2_hsotg
*hsotg,
chan-data_pid_start = qh-data_toggle;
chan-multi_count = 1;
+ if ((urb-actual_length 0 || urb-actual_length urb-length)
+ !dwc2_hcd_is_pipe_in(urb-pipe_info))
+ urb-actual_length = urb-length;
+
if (hsotg-core_params-dma_enable 0) {
chan-xfer_dma = urb-dma + urb-actual_length;
Paul, did you try the patch without this hunk?
Dom, can you tell use why this hunk is needed?
Gr.
Matthijs
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] staging: dwc2: 2nd try at uframe scheduler patch
Hi Paul, Matthijs' concern about periodic endpoints with bInterval=1 seems to be unfounded. I tried a webcam, which uses a bInterval=1 isoc endpoint, on my PCI-based dev board, and it still works fine with this patch applied. For the record, I still think this concern actually exists, but you will need to completely fill up the available bandwidth to notice the problem, since the scheduler is now too optimistic about how much bandwidth is availble when devices with bInterval 8 are present (but pessimistic for devices with bInterval 8). However, this is something I think we can easily fix later, so getting this series in is a step forward anyway. I haven't got time to properly review and test these patches now, since I'm about to leave for a two-week vacation though. I did a quick scan just now and replied with some comments that occured to me. Gr. Matthijs -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/13] staging: dwc2: unshift non-bool register value constants
Hey Paul, OK, I'm kind of on the fence about this one, so if you prefer it this way I guess it's OK with me. Acked-by: Paul Zimmerman pa...@synopsys.com Thanks. What platforms have you tested this on, BTW? You said you have a Raspberry Pi, so I'd like you to test these patches there before resubmitting them. And I'll test them on my PCI-based platform. I mostly tested the patches on the Ralink RT3052 SoC. I think I did some basic testing on the Pi at some point, but I'll have to look again to do some proper testing on there as well. I had hoped to get around to this last week, but unfortunately that didn't work out. Since I'm leaving on a vacation today, I won't be able to resubmit this series until over two weeks at the earliest. Gr. Matthijs -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FUSB200 xhci issue
Am 10.08.2013 13:57, schrieb Alan Stern: On Sat, 10 Aug 2013, Oleksij Rempel wrote: usb reset do not affect behaviour of firmware. At least after i remove all attempts to reboot FW from driver. If adapter will got reset signal, FW will be notified about it. Then FW will remove reset flag and will just continue to work. After usb reset, lsusb show correct, update information - EP3 and EP4 was updated from INT to BULK. I assume, no i need to add to the driver some kind of firmware check. What is the proper way to do it? The simplest way is to put a new value for the device descriptor's bcdDevice value in the firmware. Then all you have to do is check that value. Since adding fw check will need fw version update. I would like to do quick fix for current kernel and firmware version. I will revert EP3 and EP4 from bulk back to interrupt. But, before sending patch to the list i would like to know, how to reproduce the bug which was fixed by converting this endpoints from interrupt to bulk. -- Regards, Oleksij -- Regards, Oleksij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] staging: dwc2: add microframe scheduler from downstream Pi kernel
On Sun, Aug 11, 2013 at 12:50:19PM -0700, Paul Zimmerman wrote:
+static int dwc2_find_single_uframe(struct dwc2_hsotg *hsotg, struct dwc2_qh
*qh)
+{
+ unsigned short utime = qh-usecs;
+ int done = 0;
+ int i = 0;
+ int ret = -1;
+
+ while (!done) {
I don't care for these while (!done) loops. If there is nothing
else to use as a limitter then just do while (1). In this case, we
are count from 0 to 7 so it should be:
static int dwc2_find_single_uframe(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
{
unsigned short utime = qh-usecs;
int i;
for (i = 0; i 8; i++) {
if (utime = hsotg-frame_usecs[i]) {
hsotg-frame_usecs[i] -= utime;
qh-frame_usecs[i] += utime;
return i;
}
}
return -1;
}
Notice how I've separated out the success and failure paths?
Now we don't it's immediately clear what the success and return
values are. The error code is returned to dwc2_schedule_periodic()
which has some spaghetti code and then prints a misleading error
message.
+ /* At the start hsotg-frame_usecs[i] = max_uframe_usecs[i] */
+ if (utime = hsotg-frame_usecs[i]) {
+ hsotg-frame_usecs[i] -= utime;
+ qh-frame_usecs[i] += utime;
+ ret = i;
+ done = 1;
+ } else {
+ i++;
+ if (i == 8)
+ done = 1;
+ }
+ }
+
+ return ret;
+}
+
+/*
+ * use this for FS apps that can span multiple uframes
+ */
+static int dwc2_find_multi_uframe(struct dwc2_hsotg *hsotg, struct dwc2_qh
*qh)
+{
+ unsigned short utime = qh-usecs;
+ unsigned short xtime;
+ int t_left = utime;
No need to set t_left here.
+ int done = 0;
+ int i = 0;
+ int j;
+ int ret = -1;
+
+ while (!done) {
for (i = 0; i 8; i++) {
+ if (hsotg-frame_usecs[i] = 0) {
This test is worrying because -frame_usecs[] is unsigned and can't
be less than zero.
+ i++;
+ if (i == 8) {
+ ret = -1;
+ done = 1;
+ }
+ continue;
+ }
This chunk becomes:
if (hsotg-frame_usecs[i] = 0)
continue;
+
+ /*
+ * we need n consecutive slots so use j as a start slot
+ * j plus j+1 must be enough time (for now)
+ */
+ xtime = hsotg-frame_usecs[i];
+ for (j = i + 1; j 8; j++) {
+ /*
+ * if we add this frame remaining time to xtime we may
+ * be OK, if not we need to test j for a complete frame
+ */
+ if (xtime + hsotg-frame_usecs[j] utime) {
+ if (hsotg-frame_usecs[j]
+ max_uframe_usecs[j]) {
+ ret = -1;
+ break;
+ }
+ }
+ if (xtime = utime) {
+ ret = i;
I would like to move the code from after the loop to here but we
would run into the 80 character limit. One option is to add a
variable and then test it when we have fewer indents, but a better
option is to create a new function. Anyway, here is what it looks
like:
t_left = utime;
for (j = i; j 8; j++) {
t_left -= hsotg-frame_usecs[j];
if (t_left = 0) {
qh-frame_usecs[j] +=
hsotg-frame_usecs[j] +
t_left;
hsotg-frame_usecs[j] = -t_left;
return i;
}
qh-frame_usecs[j] +=
hsotg-frame_usecs[j];
hsotg-frame_usecs[j] = 0;
}
I'm not sure we should be saying j = i or if it should be
j = i + 1. I removed the t_left 0 because we just return
directly now.
+ break;
+ }
+ /* add the frame time to x time */
+ xtime += hsotg-frame_usecs[j];
+ /* we must have a fully available next frame or break */
+ if (xtime utime
+hsotg-frame_usecs[j] == max_uframe_usecs[j]) {
+ ret = -1;
+
Re: [PATCH v2 3/6] usb: phy: msm: Migrate to Managed Device Resource allocation
Hi,
On Mon, 2013-07-29 at 15:25 +0300, Felipe Balbi wrote:
Hi,
On Mon, Jul 29, 2013 at 10:04:21AM +0300, Ivan T. Ivanov wrote:
motg-irq = platform_get_irq(pdev, 0);
- if (!motg-irq) {
+ if (motg-irq 0) {
looks like this particular hunk isn't part of $subject.
Indeed. Will remove it.
Thanks,
Ivan
--
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: Non-enumerable devices on USB and other enumerable buses
On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote: On Sun, 11 Aug 2013, Mark Brown wrote: One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. On the surface, this seems like a particularly simple case. Why wait until the SoC's USB controller has started? Why not plug in the hub via the GPIOs right from the beginning? I tried that, it doesn't seem to work - for some reason it seems that the hub is only successfully enumerated if it starts after its parent is running. I don't know enough about USB to speculate on why that might be, the GPIOs are brining the device out of reset not applying power or anything. Another case that's going to be problematic once it's in mainline is Slimbus - this is a bus used in some embedded audio subsystems which is enumerable in a similar manner to USB but where the devices on the bus are normally powered up only on demand (causing them to hotplug when used and unplug when idle) and have at least interrupt lines wired to the SoC using a normal interrupt outside the enumerable bus. That is indeed more difficult, because it requires geniune cooperation between the bus and platform subsystems. Yeah. You might want to do the same with for example a USB network controller when you're in flight only mode, that seems to be one of the more common reasons for doing this sort of thing with USB. signature.asc Description: Digital signature
[PATCH 2/2] USB: chipidea: i.MX: simplify usbmisc
The chipidea i.MX driver is split into two drivers. The ci_hdrc_imx driver
handles the chipidea cores and the usbmisc_imx driver handles the noncore
registers common to all chipidea cores (but SoC specific). Current flow is:
- usbmisc sets an ops pointer in the ci_hdrc_imx driver during probe
- ci_hdrc_imx checks if the pointer is valid during probe, if yes calls
the functions in the ops pointer.
- usbmisc_imx calls back into the ci_hdrc_imx driver to get additional
data
This is overly complicated and has problems if the drivers are compiled
as modules. In this case the usbmisc_imx driver can be unloaded even if
the ci_hdrc_imx driver still needs usbmisc functionality.
This patch changes this by letting the ci_hdrc_imx driver calling functions
from the usbmisc_imx driver. This way the symbol resolving during module
load makes sure the ci_hdrc_imx driver depends on the usbmisc_imx driver.
Also instead of letting the usbmisc_imx driver call back into the ci_hdrc_imx
driver, pass the needed data in the first place.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/usb/chipidea/ci_hdrc_imx.c | 71 +---
drivers/usb/chipidea/ci_hdrc_imx.h | 17 ++-
drivers/usb/chipidea/usbmisc_imx.c | 95 +-
3 files changed, 76 insertions(+), 107 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 11ed423..b9464ff 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -29,57 +29,48 @@ struct ci_hdrc_imx_data {
struct platform_device *ci_pdev;
struct clk *clk;
struct regulator *reg_vbus;
+ struct imx_usbmisc_data *usbmisc_data;
};
-static const struct usbmisc_ops *usbmisc_ops;
-
/* Common functions shared by usbmisc drivers */
-int usbmisc_set_ops(const struct usbmisc_ops *ops)
-{
- if (usbmisc_ops)
- return -EBUSY;
-
- usbmisc_ops = ops;
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(usbmisc_set_ops);
-
-void usbmisc_unset_ops(const struct usbmisc_ops *ops)
-{
- usbmisc_ops = NULL;
-}
-EXPORT_SYMBOL_GPL(usbmisc_unset_ops);
-
-int usbmisc_get_init_data(struct device *dev, struct usbmisc_usb_device
*usbdev)
+static struct imx_usbmisc_data *usbmisc_get_init_data(struct device *dev)
{
struct device_node *np = dev-of_node;
struct of_phandle_args args;
+ struct imx_usbmisc_data *data;
int ret;
- usbdev-dev = dev;
+ /*
+* In case the fsl,usbmisc property is not present this device doesn't
+* need usbmisc. Return NULL (which is no error here)
+*/
+ if (!of_get_property(np, fsl,usbmisc, NULL))
+ return NULL;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
ret = of_parse_phandle_with_args(np, fsl,usbmisc, #index-cells,
0, args);
if (ret) {
dev_err(dev, Failed to parse property fsl,usbmisc, errno %d\n,
ret);
- memset(usbdev, 0, sizeof(*usbdev));
- return ret;
+ return ERR_PTR(ret);
}
- usbdev-index = args.args[0];
+
+ data-index = args.args[0];
of_node_put(args.np);
if (of_find_property(np, disable-over-current, NULL))
- usbdev-disable_oc = 1;
+ data-disable_oc = 1;
if (of_find_property(np, external-vbus-divider, NULL))
- usbdev-evdo = 1;
+ data-evdo = 1;
- return 0;
+ return data;
}
-EXPORT_SYMBOL_GPL(usbmisc_get_init_data);
/* End of common functions shared by usbmisc drivers*/
@@ -96,10 +87,6 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
struct resource *res;
int ret;
- if (of_find_property(pdev-dev.of_node, fsl,usbmisc, NULL)
-!usbmisc_ops)
- return -EPROBE_DEFER;
-
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data) {
dev_err(pdev-dev, Failed to allocate ci_hdrc-imx data!\n);
@@ -112,6 +99,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
return -ENOENT;
}
+ data-usbmisc_data = usbmisc_get_init_data(pdev-dev);
+ if (IS_ERR(data-usbmisc_data))
+ return PTR_ERR(data-usbmisc_data);
+
data-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(data-clk)) {
dev_err(pdev-dev,
@@ -159,11 +150,11 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
if (!pdev-dev.coherent_dma_mask)
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
- if (usbmisc_ops usbmisc_ops-init) {
- ret = usbmisc_ops-init(pdev-dev);
+ if (data-usbmisc_data) {
+ ret = imx_usbmisc_init(data-usbmisc_data);
if (ret) {
-
[PATCH v2] USB chipidea i.MX: Fix module loading
The Chipidea i.MX driver has some issues with module loading dependencies. This fixes this. It is an alternative approach to the one Peter Chen suggested that does without changing the dt binding. Sascha changes since v1: - make usbmisc optional when fsl,usbmisc property is not present. Needed for i.MX23/28 as suggested by Peter Chen Sascha Hauer (2): USB: chipidea: i.MX: remove unused define USB: chipidea: i.MX: simplify usbmisc drivers/usb/chipidea/ci_hdrc_imx.c | 74 + drivers/usb/chipidea/ci_hdrc_imx.h | 17 ++- drivers/usb/chipidea/usbmisc_imx.c | 95 +- 3 files changed, 76 insertions(+), 110 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] USB: chipidea: i.MX: remove unused define
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/usb/chipidea/ci_hdrc_imx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 14362c0..11ed423 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -24,9 +24,6 @@
#include ci.h
#include ci_hdrc_imx.h
-#define pdev_to_phy(pdev) \
- ((struct usb_phy *)platform_get_drvdata(pdev))
-
struct ci_hdrc_imx_data {
struct usb_phy *phy;
struct platform_device *ci_pdev;
--
1.8.4.rc1
--
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: Non-enumerable devices on USB and other enumerable buses
[Adding Olof] On Mon, Aug 12, 2013 at 10:51:36AM +0100, Mark Brown wrote: On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote: On Sun, 11 Aug 2013, Mark Brown wrote: One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. On the surface, this seems like a particularly simple case. Why wait until the SoC's USB controller has started? Why not plug in the hub via the GPIOs right from the beginning? I tried that, it doesn't seem to work - for some reason it seems that the hub is only successfully enumerated if it starts after its parent is running. I don't know enough about USB to speculate on why that might be, the GPIOs are brining the device out of reset not applying power or anything. Another case that's going to be problematic once it's in mainline is Slimbus - this is a bus used in some embedded audio subsystems which is enumerable in a similar manner to USB but where the devices on the bus are normally powered up only on demand (causing them to hotplug when used and unplug when idle) and have at least interrupt lines wired to the SoC using a normal interrupt outside the enumerable bus. That is indeed more difficult, because it requires geniune cooperation between the bus and platform subsystems. Yeah. You might want to do the same with for example a USB network controller when you're in flight only mode, that seems to be one of the more common reasons for doing this sort of thing with USB. As I understand it, the wifi chip on the Snow Chromebook has a similar issue -- it hangs off of a probeable SDIO bus, but needs a regulator poked for it to turn on and become probeable (see exynos_wifi_bt_set_power in [1]). Thanks, Mark. [1] http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=blob;f=arch/arm/mach-exynos/mach-exynos5-dt.c;h=d131241ea78b7d89df21e676e284ddfd369b4da0;hb=refs/heads/chromeos-3.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote: On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote: I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? As these are usually bus-specific things, and really, platform-specific I don't think they're bus specific - the main issue with a lot of this is that they're outside the infrastructure that the bus standardises so we should have a general way of understanding this. There will be bits where the bus needs to get involved but the overall pattern is generic. things, I'd fall back and just recommend a platform driver that knows about where these gpios are, and how/when to enable them, which will cause the discoverable bus logic to kick in now that it notices a device is present/removed. This doesn't work in general. These things aren't really platform specific at all, they're features of the devices that apply to any system using them and while for some use cases (like WiFi and BT power) an external thing that just manually applies power will be enough in other cases we want to know about the device even while it's off and the driver might be able to do extra things at runtime if it knows about for example having some control over signals to the device. For example in the Slimbus case we're normally talking about audio CODECs. In order to preserve the userspace API the device has to appear to be present at all times, the driver will remember the settings the user is making to be applied when it actually powers up and indeed the powering up should be kicked off as a result of userspac acting on the apparently present device. Another example here (including USB devices) is interrupt signals wired directly back to the processor, completely outside of the bus. Perhaps a semi-generic platform driver could be created, that knows how to handle these settings in the DT, but odds are, that might be difficult to make generic enough to cover a wide range of boards, but without specifics, it's hard to tell. There's things like the rfkill stuff already, and the reset controller on the way, but again this only covers a fairly small subset of the issues. signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 12:07:14PM +0100, Mark Rutland wrote: As I understand it, the wifi chip on the Snow Chromebook has a similar issue -- it hangs off of a probeable SDIO bus, but needs a regulator poked for it to turn on and become probeable (see exynos_wifi_bt_set_power in [1]). Yes, that's another example - this stuff is really common in practical systems, especially the power control for radios since that's how rfkill tends to end up being implemented. signature.asc Description: Digital signature
kernel Oops: 0003 on usbhid_submit_report
When communicating with AT90USB1287, at random intervals (1/25 boots) the linux hid_output_field Oopses and kills the communicating thread. The AT90USB1287 microcontroller uses LUFA library for usb/hid communication. It is trigged by a ioctl call from userspace and fails in a kernel paging request. The system is after the oops in a state where no hid commands is sent anymore and only a boot can fix the system. Keywords: usbhid hid Kernel version: Linux version 3.8.13-03081301-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201305311535 SMP Fri May 31 19:44:30 UTC 2013 Oopses: http://paste.debian.net/24305 http://paste.debian.net/24306 http://paste.debian.net/24307 Code: The error is triggered by: ioctl(fd,HIDIOCSUSAGES, ref_multi_u); ioctl(fd,HIDIOCSREPORT, rep_info_u); Notes: It is very hard to reproduce so seems like race condition… Any tips to resolve/workaround this issue is appreciated and please let me know if my information is incomplete (This is my first kernel bug report) Andreas Lillebø Holm -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH] usb-audio: Fix invalid volume resolution for Logitech HD Webcam C525
At Sat, 10 Aug 2013 12:20:02 +0400, Maksim A. Boyko wrote: Add the volume control quirk for avoiding the kernel warning for the Logitech HD Webcam C525 as in the similar commit 36691e1be6ec551eef4a5225f126a281f8c051c2 for the Logitech HD Webcam C310. Reported-by: Maksim Boyko maksim.a.bo...@gmail.com Tested-by: Maksim Boyko maksim.a.bo...@gmail.com Cc: sta...@vger.kernel.org # 3.10.5+ Signed-off-by: Maksim Boyko maksim.a.bo...@gmail.com Thanks, applied. Takashi -- sound/usb/mixer.c |1 + 1 file changed, 1 insertion(+) --- linux-3.10.5-orig/sound/usb/mixer.c 2013-08-04 12:51:49.0 +0400 +++ linux-3.10.5/sound/usb/mixer.c2013-08-06 21:12:42.274197287 +0400 @@ -888,6 +888,7 @@ static void volume_control_quirks(struct case USB_ID(0x046d, 0x081b): /* HD Webcam c310 */ case USB_ID(0x046d, 0x081d): /* HD Webcam c510 */ case USB_ID(0x046d, 0x0825): /* HD Webcam c270 */ + case USB_ID(0x046d, 0x0826): /* HD Webcam c525 */ case USB_ID(0x046d, 0x0991): /* Most audio usb devices lie about volume resolution. * Most Logitech webcams have res = 384. -- WBR, Maksim P.S. Please, use this patch due to it should have correct tab symbols. ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- 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 5/6] usb: phy: tegra: Program new PHY parameters
The Tegra30 TRM recommends configuration of certain PHY parameters for
optimal quality. Program the following registers based on device tree
parameters:
- UTMIP_XCVR_HSSLEW: HS slew rate control.
- UTMIP_HSSQUELCH_LEVEL: HS squelch detector level
- UTMIP_HSDISCON_LEVEL: HS disconnect detector level.
These registers exist in Tegra20, but programming them hasn't been
necessary, so these parameters won't be set on Tegra20 to keep the
device trees backward compatible.
Additionally, the UTMIP_XCVR_SETUP parameter can be set from fuses
instead of a software-programmed value, as the optimal value can
vary between invidual boards. The boolean property
nvidia,xcvr-setup-use-fuses can be used to enable this behaviour.
Signed-off-by: Tuomas Tynkkynen ttynkky...@nvidia.com
Tested-by: Stephen Warren swar...@nvidia.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
v2: Don't touch new PHY params under T20
v2: Change register bitmasks to not contain shifted-out bits
drivers/usb/phy/phy-tegra-usb.c | 81 ++-
include/linux/usb/tegra_usb_phy.h | 4 ++
2 files changed, 67 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 1ad184a..3bfb3d1 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -99,11 +99,15 @@
#define UTMIP_FORCE_PD2_POWERDOWN(1 16)
#define UTMIP_FORCE_PDZI_POWERDOWN (1 18)
#define UTMIP_XCVR_LSBIAS_SEL(1 21)
-#define UTMIP_XCVR_HSSLEW_MSB(x) (((x) 0x7f) 25)
+#define UTMIP_XCVR_HSSLEW(x) (((x) 0x3) 4)
+#define UTMIP_XCVR_HSSLEW_MSB(x) x) 0x1fc) 2) 25)
#define UTMIP_BIAS_CFG00x80c
#define UTMIP_OTGPD (1 11)
#define UTMIP_BIASPD (1 10)
+#define UTMIP_HSSQUELCH_LEVEL(x) (((x) 0x3) 0)
+#define UTMIP_HSDISCON_LEVEL(x) (((x) 0x3) 2)
+#define UTMIP_HSDISCON_LEVEL_MSB(x) x) 0x4) 2) 24)
#define UTMIP_HSRX_CFG00x810
#define UTMIP_ELASTIC_LIMIT(x) (((x) 0x1f) 10)
@@ -255,6 +259,7 @@ static void utmip_pad_power_on(struct tegra_usb_phy *phy)
{
unsigned long val, flags;
void __iomem *base = phy-pad_regs;
+ struct tegra_utmip_config *config = phy-config;
clk_prepare_enable(phy-pad_clk);
@@ -263,6 +268,16 @@ static void utmip_pad_power_on(struct tegra_usb_phy *phy)
if (utmip_pad_count++ == 0) {
val = readl(base + UTMIP_BIAS_CFG0);
val = ~(UTMIP_OTGPD | UTMIP_BIASPD);
+
+ if (phy-soc_config-requires_extra_tuning_parameters) {
+ val = ~(UTMIP_HSSQUELCH_LEVEL(~0) |
+ UTMIP_HSDISCON_LEVEL(~0) |
+ UTMIP_HSDISCON_LEVEL_MSB(~0));
+
+ val |= UTMIP_HSSQUELCH_LEVEL(config-hssquelch_level);
+ val |= UTMIP_HSDISCON_LEVEL(config-hsdiscon_level);
+ val |= UTMIP_HSDISCON_LEVEL_MSB(config-hsdiscon_level);
+ }
writel(val, base + UTMIP_BIAS_CFG0);
}
@@ -431,12 +446,20 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
val = ~(UTMIP_FORCE_PD_POWERDOWN | UTMIP_FORCE_PD2_POWERDOWN |
UTMIP_FORCE_PDZI_POWERDOWN | UTMIP_XCVR_LSBIAS_SEL |
UTMIP_XCVR_SETUP(~0) | UTMIP_XCVR_SETUP_MSB(~0) |
-UTMIP_XCVR_LSFSLEW(~0) | UTMIP_XCVR_LSRSLEW(~0) |
-UTMIP_XCVR_HSSLEW_MSB(~0));
- val |= UTMIP_XCVR_SETUP(config-xcvr_setup);
- val |= UTMIP_XCVR_SETUP_MSB(config-xcvr_setup);
+UTMIP_XCVR_LSFSLEW(~0) | UTMIP_XCVR_LSRSLEW(~0));
+
+ if (!config-xcvr_setup_use_fuses) {
+ val |= UTMIP_XCVR_SETUP(config-xcvr_setup);
+ val |= UTMIP_XCVR_SETUP_MSB(config-xcvr_setup);
+ }
val |= UTMIP_XCVR_LSFSLEW(config-xcvr_lsfslew);
val |= UTMIP_XCVR_LSRSLEW(config-xcvr_lsrslew);
+
+ if (phy-soc_config-requires_extra_tuning_parameters) {
+ val = ~(UTMIP_XCVR_HSSLEW(~0) | UTMIP_XCVR_HSSLEW_MSB(~0));
+ val |= UTMIP_XCVR_HSSLEW(config-xcvr_hsslew);
+ val |= UTMIP_XCVR_HSSLEW_MSB(config-xcvr_hsslew);
+ }
writel(val, base + UTMIP_XCVR_CFG0);
val = readl(base + UTMIP_XCVR_CFG1);
@@ -450,14 +473,14 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
val |= UTMIP_BIAS_PDTRK_COUNT(0x5);
writel(val, base + UTMIP_BIAS_CFG1);
- if (phy-is_legacy_phy) {
- val = readl(base + UTMIP_SPARE_CFG0);
- if (phy-mode == USB_DR_MODE_PERIPHERAL)
- val = ~FUSE_SETUP_SEL;
- else
- val |= FUSE_SETUP_SEL;
- writel(val, base + UTMIP_SPARE_CFG0);
- } else {
+ val = readl(base + UTMIP_SPARE_CFG0);
+
[PATCH v3 6/6] usb: host: tegra: Tegra30 support
The Tegra30 EHCI controller is mostly compatible with the Tegra20
controller, except Tegra30 includes the HOSTPC register extension.
The has_hostpc capability bit must be set in the ehci_hcd structure if
the controller has such extensions. The new tegra_ehci_soc_config
structure is added to describe the differences between the SoCs.
Signed-off-by: Tuomas Tynkkynen ttynkky...@nvidia.com
Tested-by: Stephen Warren swar...@nvidia.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
v3: Removed useless cast
drivers/usb/host/ehci-tegra.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index db8031f..78fa76d 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -25,6 +25,7 @@
#include linux/irq.h
#include linux/module.h
#include linux/of.h
+#include linux/of_device.h
#include linux/of_gpio.h
#include linux/platform_device.h
#include linux/pm_runtime.h
@@ -50,6 +51,10 @@
static struct hc_driver __read_mostly tegra_ehci_hc_driver;
+struct tegra_ehci_soc_config {
+ bool has_hostpc;
+};
+
static int (*orig_hub_control)(struct usb_hcd *hcd,
u16 typeReq, u16 wValue, u16 wIndex,
char *buf, u16 wLength);
@@ -320,8 +325,24 @@ static void tegra_ehci_unmap_urb_for_dma(struct usb_hcd
*hcd, struct urb *urb)
free_dma_aligned_buffer(urb);
}
+static const struct tegra_ehci_soc_config tegra30_soc_config = {
+ .has_hostpc = true,
+};
+
+static const struct tegra_ehci_soc_config tegra20_soc_config = {
+ .has_hostpc = false,
+};
+
+static struct of_device_id tegra_ehci_of_match[] = {
+ { .compatible = nvidia,tegra30-ehci, .data = tegra30_soc_config },
+ { .compatible = nvidia,tegra20-ehci, .data = tegra20_soc_config },
+ { },
+};
+
static int tegra_ehci_probe(struct platform_device *pdev)
{
+ const struct of_device_id *match;
+ const struct tegra_ehci_soc_config *soc_config;
struct resource *res;
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
@@ -330,6 +351,13 @@ static int tegra_ehci_probe(struct platform_device *pdev)
int irq;
struct usb_phy *u_phy;
+ match = of_match_device(tegra_ehci_of_match, pdev-dev);
+ if (!match) {
+ dev_err(pdev-dev, Error: No device match found\n);
+ return -ENODEV;
+ }
+ soc_config = match-data;
+
/* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
* Once we have dma capability bindings this can go away.
@@ -391,6 +419,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
goto cleanup_clk_en;
}
ehci-caps = hcd-regs + 0x100;
+ ehci-has_hostpc = soc_config-has_hostpc;
err = usb_phy_init(hcd-phy);
if (err) {
@@ -468,11 +497,6 @@ static void tegra_ehci_hcd_shutdown(struct platform_device
*pdev)
hcd-driver-shutdown(hcd);
}
-static struct of_device_id tegra_ehci_of_match[] = {
- { .compatible = nvidia,tegra20-ehci, },
- { },
-};
-
static struct platform_driver tegra_ehci_driver = {
.probe = tegra_ehci_probe,
.remove = tegra_ehci_remove,
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/6] Documentation: New DT parameters for tegra30-usb-phy
Document the new device tree parameters for Tegra30 USB PHY. Signed-off-by: Tuomas Tynkkynen ttynkky...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com --- .../devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt| 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt index 4c8ade8..ba797d3 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt @@ -3,7 +3,7 @@ Tegra SOC USB PHY The device node for Tegra SOC USB PHY: Required properties : - - compatible : Should be nvidia,tegra20-usb-phy. + - compatible : Should be nvidia,tegrachip-usb-phy. - reg : Defines the following set of registers, in the order listed: - The PHY's own register set. Always present. @@ -24,17 +24,26 @@ Required properties : Required properties for phy_type == ulpi: - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. -Required PHY timing params for utmi phy: +Required PHY timing params for utmi phy, for all chips: - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before start of sync launches RxActive - nvidia,elastic-limit : Variable FIFO Depth of elastic input store - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait before declare IDLE. - nvidia,term-range-adj : Range adjusment on terminations - - nvidia,xcvr-setup : HS driver output control + - Either one of the following for HS driver output control: +- nvidia,xcvr-setup : integer, uses the provided value. +- nvidia,xcvr-setup-use-fuses : boolean, indicates that the value is read + from the on-chip fuses +If both are provided, nvidia,xcvr-setup-use-fuses takes precedence. - nvidia,xcvr-lsfslew : LS falling slew rate control. - nvidia,xcvr-lsrslew : LS rising slew rate control. +Required PHY timing params for utmi phy, only on Tegra30 and above: + - nvidia,xcvr-hsslew : HS slew rate control. + - nvidia,hssquelch-level : HS squelch detector level. + - nvidia,hsdiscon-level : HS disconnect detector level. + Optional properties: - nvidia,has-legacy-mode : boolean indicates whether this controller can operate in legacy mode (as APX 2500 / 2600). In legacy mode some -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/6] usb: phy: tegra: Fix wrong PHY parameters
Some of the PHY parameters are not set according to the TRMs:
- UTMIP_FS_PREABMLE_J should be set, not cleared
- UTMIP_XCVR_LSBIAS_SEL should be cleared, not set
- UTMIP_PD_CHRG should be set in host mode and cleared in device mode
- UTMIP_XCVR_SETUP is a two-part field; the upper bits were not set
properly
Signed-off-by: Tuomas Tynkkynen ttynkky...@nvidia.com
Tested-by: Stephen Warren swar...@nvidia.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
v2: Change register bitmasks to not contain shifted-out bits
drivers/usb/phy/phy-tegra-usb.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 49fa2da..ebbf85f 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -86,11 +86,13 @@
#define UTMIP_XCVR_CFG00x808
#define UTMIP_XCVR_SETUP(x) (((x) 0xf) 0)
+#define UTMIP_XCVR_SETUP_MSB(x) x) 0x70) 4) 22)
#define UTMIP_XCVR_LSRSLEW(x)(((x) 0x3) 8)
#define UTMIP_XCVR_LSFSLEW(x)(((x) 0x3) 10)
#define UTMIP_FORCE_PD_POWERDOWN (1 14)
#define UTMIP_FORCE_PD2_POWERDOWN(1 16)
#define UTMIP_FORCE_PDZI_POWERDOWN (1 18)
+#define UTMIP_XCVR_LSBIAS_SEL(1 21)
#define UTMIP_XCVR_HSSLEW_MSB(x) (((x) 0x7f) 25)
#define UTMIP_BIAS_CFG00x80c
@@ -342,7 +344,7 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
}
val = readl(base + UTMIP_TX_CFG0);
- val = ~UTMIP_FS_PREABMLE_J;
+ val |= UTMIP_FS_PREABMLE_J;
writel(val, base + UTMIP_TX_CFG0);
val = readl(base + UTMIP_HSRX_CFG0);
@@ -381,16 +383,26 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
val = readl(base + USB_SUSP_CTRL);
val = ~(USB_WAKE_ON_CNNT_EN_DEV | USB_WAKE_ON_DISCON_EN_DEV);
writel(val, base + USB_SUSP_CTRL);
+
+ val = readl(base + UTMIP_BAT_CHRG_CFG0);
+ val = ~UTMIP_PD_CHRG;
+ writel(val, base + UTMIP_BAT_CHRG_CFG0);
+ } else {
+ val = readl(base + UTMIP_BAT_CHRG_CFG0);
+ val |= UTMIP_PD_CHRG;
+ writel(val, base + UTMIP_BAT_CHRG_CFG0);
}
utmip_pad_power_on(phy);
val = readl(base + UTMIP_XCVR_CFG0);
val = ~(UTMIP_FORCE_PD_POWERDOWN | UTMIP_FORCE_PD2_POWERDOWN |
-UTMIP_FORCE_PDZI_POWERDOWN | UTMIP_XCVR_SETUP(~0) |
+UTMIP_FORCE_PDZI_POWERDOWN | UTMIP_XCVR_LSBIAS_SEL |
+UTMIP_XCVR_SETUP(~0) | UTMIP_XCVR_SETUP_MSB(~0) |
UTMIP_XCVR_LSFSLEW(~0) | UTMIP_XCVR_LSRSLEW(~0) |
UTMIP_XCVR_HSSLEW_MSB(~0));
val |= UTMIP_XCVR_SETUP(config-xcvr_setup);
+ val |= UTMIP_XCVR_SETUP_MSB(config-xcvr_setup);
val |= UTMIP_XCVR_LSFSLEW(config-xcvr_lsfslew);
val |= UTMIP_XCVR_LSRSLEW(config-xcvr_lsrslew);
writel(val, base + UTMIP_XCVR_CFG0);
@@ -401,10 +413,6 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
val |= UTMIP_XCVR_TERM_RANGE_ADJ(config-term_range_adj);
writel(val, base + UTMIP_XCVR_CFG1);
- val = readl(base + UTMIP_BAT_CHRG_CFG0);
- val = ~UTMIP_PD_CHRG;
- writel(val, base + UTMIP_BAT_CHRG_CFG0);
-
val = readl(base + UTMIP_BIAS_CFG1);
val = ~UTMIP_BIAS_PDTRK_COUNT(~0);
val |= UTMIP_BIAS_PDTRK_COUNT(0x5);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/6] USB tree changes for Tegra30 and Tegra114 USB Host support
Hi all, Here are the patches for the USB tree to enable USB Host support on Tegra30 and Tegra114. These are based on my and Mikko's cleanup patches that just got merged to Felipe's tree. The first one touches the core hub code to prevent certain (non-standard) clock disable features as our controller doesn't support those. The rest are changes to our PHY and EHCI drivers to deal with a few changed register addresses and a few additional PHY parameters that need to be set for proper signal quality. v2 diff: Patch 1: Added Alan's ack Patch 2 5: Change register bitmasks to not contain shifted-out bits Changed the order of patches 4 5 Patch 5: Don't touch new PHY params under T20 v3 diff: Patch 6: Removed useless cast Added Stephen's Reviewed-by Tested-by to all patches Tuomas Tynkkynen (6): usb: host: add has_tdi_phy_lpm capability bit usb: phy: tegra: Fix wrong PHY parameters usb: phy: tegra: Tegra30 support Documentation: New DT parameters for tegra30-usb-phy usb: phy: tegra: Program new PHY parameters usb: host: tegra: Tegra30 support .../bindings/usb/nvidia,tegra20-usb-phy.txt| 15 +- drivers/usb/chipidea/host.c| 1 + drivers/usb/host/ehci-hub.c| 14 +- drivers/usb/host/ehci-tegra.c | 34 +++- drivers/usb/host/ehci.h| 1 + drivers/usb/phy/phy-tegra-usb.c| 220 - include/linux/usb/tegra_usb_phy.h | 23 +++ 7 files changed, 242 insertions(+), 66 deletions(-) -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/6] usb: host: add has_tdi_phy_lpm capability bit
The has_hostpc capability bit indicates that the host controller has the
HOSTPC register extensions, but at the same time enables clock disabling
power saving features with the PHY Low Power Clock Disable (PHCD) bit.
However, some host controllers have the HOSTPC extensions but don't
support the low-power feature, so the PHCD bit must not be set on those
controllers. Add a separate capability bit for the low-power feature
instead, and change all existing users of has_hostpc to use this new
capability bit.
The idea for this commit is taken from an old 2012 commit that never got
merged (disociate chipidea PHY low power suspend control from hostpc)
Inspired-by: Matthieu CASTET matthieu.cas...@parrot.com
Signed-off-by: Tuomas Tynkkynen ttynkky...@nvidia.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Stephen Warren swar...@nvidia.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
v2: Add Alan's ack
drivers/usb/chipidea/host.c | 1 +
drivers/usb/host/ehci-hub.c | 14 +++---
drivers/usb/host/ehci.h | 1 +
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 40d0fda..9b3aaf1 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -63,6 +63,7 @@ static int host_start(struct ci_hdrc *ci)
ehci = hcd_to_ehci(hcd);
ehci-caps = ci-hw_bank.cap;
ehci-has_hostpc = ci-hw_bank.lpm;
+ ehci-has_tdi_phy_lpm = ci-hw_bank.lpm;
ret = usb_add_hcd(hcd, 0, 0);
if (ret)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 6e69ee1..6d5ad37 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -183,7 +183,7 @@ static void ehci_adjust_port_wakeup_flags(struct ehci_hcd
*ehci,
spin_lock_irq(ehci-lock);
/* clear phy low-power mode before changing wakeup flags */
- if (ehci-has_hostpc) {
+ if (ehci-has_tdi_phy_lpm) {
port = HCS_N_PORTS(ehci-hcs_params);
while (port--) {
u32 __iomem *hostpc_reg = ehci-regs-hostpc[port];
@@ -217,7 +217,7 @@ static void ehci_adjust_port_wakeup_flags(struct ehci_hcd
*ehci,
}
/* enter phy low-power mode again */
- if (ehci-has_hostpc) {
+ if (ehci-has_tdi_phy_lpm) {
port = HCS_N_PORTS(ehci-hcs_params);
while (port--) {
u32 __iomem *hostpc_reg = ehci-regs-hostpc[port];
@@ -309,7 +309,7 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
}
}
- if (changed ehci-has_hostpc) {
+ if (changed ehci-has_tdi_phy_lpm) {
spin_unlock_irq(ehci-lock);
msleep(5); /* 5 ms for HCD to enter low-power mode */
spin_lock_irq(ehci-lock);
@@ -435,7 +435,7 @@ static int ehci_bus_resume (struct usb_hcd *hcd)
goto shutdown;
/* clear phy low-power mode before resume */
- if (ehci-bus_suspended ehci-has_hostpc) {
+ if (ehci-bus_suspended ehci-has_tdi_phy_lpm) {
i = HCS_N_PORTS(ehci-hcs_params);
while (i--) {
if (test_bit(i, ehci-bus_suspended)) {
@@ -788,7 +788,7 @@ static int ehci_hub_control (
goto error;
/* clear phy low-power mode before resume */
- if (ehci-has_hostpc) {
+ if (ehci-has_tdi_phy_lpm) {
temp1 = ehci_readl(ehci, hostpc_reg);
ehci_writel(ehci, temp1 ~HOSTPC_PHCD,
hostpc_reg);
@@ -1025,12 +1025,12 @@ static int ehci_hub_control (
/* After above check the port must be connected.
* Set appropriate bit thus could put phy into low power
-* mode if we have hostpc feature
+* mode if we have tdi_phy_lpm feature
*/
temp = ~PORT_WKCONN_E;
temp |= PORT_WKDISC_E | PORT_WKOC_E;
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
- if (ehci-has_hostpc) {
+ if (ehci-has_tdi_phy_lpm) {
spin_unlock_irqrestore(ehci-lock, flags);
msleep(5);/* 5ms for HCD enter low pwr mode */
spin_lock_irqsave(ehci-lock, flags);
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 64f9a08..d034d94 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -210,6 +210,7 @@ struct ehci_hcd { /* one per controller */
#define OHCI_HCCTRL_LEN 0x4
__hc32 *ohci_hcctrl_reg;
unsignedhas_hostpc:1;
+ unsigned
[PATCH v3 3/6] usb: phy: tegra: Tegra30 support
The Tegra30 USB PHY is a bit different than the Tegra20 PHY:
- The EHCI controller supports the HOSTPC register extension, and some
of the fields that the PHY needs to modify (PHCD and PTS) have moved
to the new HOSTPC register.
- Some of the UTMI PLL configuration registers have moved from the USB
register space to the Clock-And-Reset controller space. In Tegra30
the clock driver is responsible for configuring the UTMI PLL.
- The USBMODE register must be explicitly written to enter host mode.
- Certain PHY parameters need to be programmed for optimal signal
quality. Support for this will be added in the next patch.
The new tegra_phy_soc_config structure is added to describe the
differences between the SoCs.
Signed-off-by: Tuomas Tynkkynen ttynkky...@nvidia.com
Tested-by: Stephen Warren swar...@nvidia.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
drivers/usb/phy/phy-tegra-usb.c | 121 +-
include/linux/usb/tegra_usb_phy.h | 19 ++
2 files changed, 112 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index ebbf85f..1ad184a 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -28,6 +28,7 @@
#include linux/io.h
#include linux/gpio.h
#include linux/of.h
+#include linux/of_device.h
#include linux/of_gpio.h
#include linux/usb/otg.h
#include linux/usb/ulpi.h
@@ -39,11 +40,16 @@
#define ULPI_VIEWPORT 0x170
-/* PORTSC registers */
+/* PORTSC PTS/PHCD bits, Tegra20 only */
#define TEGRA_USB_PORTSC1 0x184
#define TEGRA_USB_PORTSC1_PTS(x) (((x) 0x3) 30)
#define TEGRA_USB_PORTSC1_PHCD (1 23)
+/* HOSTPC1 PTS/PHCD bits, Tegra30 and above */
+#define TEGRA_USB_HOSTPC1_DEVLC0x1b4
+#define TEGRA_USB_HOSTPC1_DEVLC_PTS(x) (((x) 0x7) 29)
+#define TEGRA_USB_HOSTPC1_DEVLC_PHCD (1 22)
+
/* Bits of PORTSC1, which will get cleared by writing 1 into them */
#define TEGRA_PORTSC1_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC)
@@ -141,6 +147,12 @@
#define UTMIP_BIAS_CFG10x83c
#define UTMIP_BIAS_PDTRK_COUNT(x)(((x) 0x1f) 3)
+/* For Tegra30 and above only, the address is different in Tegra20 */
+#define USB_USBMODE0x1f8
+#define USB_USBMODE_MASK (3 0)
+#define USB_USBMODE_HOST (3 0)
+#define USB_USBMODE_DEVICE (2 0)
+
static DEFINE_SPINLOCK(utmip_pad_lock);
static int utmip_pad_count;
@@ -193,10 +205,17 @@ static void set_pts(struct tegra_usb_phy *phy, u8 pts_val)
void __iomem *base = phy-regs;
unsigned long val;
- val = readl(base + TEGRA_USB_PORTSC1) ~TEGRA_PORTSC1_RWC_BITS;
- val = ~TEGRA_USB_PORTSC1_PTS(3);
- val |= TEGRA_USB_PORTSC1_PTS(pts_val 3);
- writel(val, base + TEGRA_USB_PORTSC1);
+ if (phy-soc_config-has_hostpc) {
+ val = readl(base + TEGRA_USB_HOSTPC1_DEVLC);
+ val = ~TEGRA_USB_HOSTPC1_DEVLC_PTS(~0);
+ val |= TEGRA_USB_HOSTPC1_DEVLC_PTS(pts_val);
+ writel(val, base + TEGRA_USB_HOSTPC1_DEVLC);
+ } else {
+ val = readl(base + TEGRA_USB_PORTSC1) ~TEGRA_PORTSC1_RWC_BITS;
+ val = ~TEGRA_USB_PORTSC1_PTS(~0);
+ val |= TEGRA_USB_PORTSC1_PTS(pts_val);
+ writel(val, base + TEGRA_USB_PORTSC1);
+ }
}
static void set_phcd(struct tegra_usb_phy *phy, bool enable)
@@ -204,12 +223,21 @@ static void set_phcd(struct tegra_usb_phy *phy, bool
enable)
void __iomem *base = phy-regs;
unsigned long val;
- val = readl(base + TEGRA_USB_PORTSC1) ~TEGRA_PORTSC1_RWC_BITS;
- if (enable)
- val |= TEGRA_USB_PORTSC1_PHCD;
- else
- val = ~TEGRA_USB_PORTSC1_PHCD;
- writel(val, base + TEGRA_USB_PORTSC1);
+ if (phy-soc_config-has_hostpc) {
+ val = readl(base + TEGRA_USB_HOSTPC1_DEVLC);
+ if (enable)
+ val |= TEGRA_USB_HOSTPC1_DEVLC_PHCD;
+ else
+ val = ~TEGRA_USB_HOSTPC1_DEVLC_PHCD;
+ writel(val, base + TEGRA_USB_HOSTPC1_DEVLC);
+ } else {
+ val = readl(base + TEGRA_USB_PORTSC1) ~PORT_RWC_BITS;
+ if (enable)
+ val |= TEGRA_USB_PORTSC1_PHCD;
+ else
+ val = ~TEGRA_USB_PORTSC1_PHCD;
+ writel(val, base + TEGRA_USB_PORTSC1);
+ }
}
static int utmip_pad_open(struct tegra_usb_phy *phy)
@@ -367,17 +395,21 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
val = ~UTMIP_SUSPEND_EXIT_ON_EDGE;
writel(val, base + UTMIP_MISC_CFG0);
- val = readl(base + UTMIP_MISC_CFG1);
- val = ~(UTMIP_PLL_ACTIVE_DLY_COUNT(~0) | UTMIP_PLLU_STABLE_COUNT(~0));
- val |= UTMIP_PLL_ACTIVE_DLY_COUNT(phy-freq-active_delay) |
Re: [PATCH] dwc3: dwc3-pci: Use SIMPLE_DEV_PM_OPS
On Wed, Aug 07, 2013 at 08:51:27AM -0300, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Using SIMPLE_DEV_PM_OPS can make the code simpler and cleaner. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Reviewed-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
dealing with enclosures that don't handle READ_CAPACITY10
Hi,
I got a bug report about an enclosure that mishandles READ_CAPACITY10.
I don't want to introduce yet another quirk. So what about basing this
on USB version?
Regards
Oliver
From 58cb3cd4b8a58d986b74e0a41d52de989dbe64bc Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Mon, 12 Aug 2013 14:49:02 +0200
Subject: [PATCH] storage: use READ_CAPACITY16 first on 3.00 devices
Some old devices crash when confronted with READ_CAPACITY16. Therefore
READ_CAPACITY10 is used first and we depend on devices with more
than 2TB correctly reporting an overflow. However some 3.0 devices
do not report an overflow but capacity % 2TB. The value reported thus
is entirely plausible. As these devices also work with another OS
without partition tables, that should copy the expected behavior.
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/usb/storage/scsiglue.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 92b05d9..04bf91d 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -108,6 +108,7 @@ static int slave_alloc (struct scsi_device *sdev)
static int slave_configure(struct scsi_device *sdev)
{
struct us_data *us = host_to_us(sdev-host);
+ u16 usb_version;
/* Many devices have trouble transferring more than 32KB at a time,
* while others have trouble with more than 64K. At this time we
@@ -211,8 +212,12 @@ static int slave_configure(struct scsi_device *sdev)
/*
* Many devices do not respond properly to READ_CAPACITY_16.
* Tell the SCSI layer to try READ_CAPACITY_10 first.
+ * However some USB 3.0 drive enclosures return capacity
+ * modulo 2TB
*/
- sdev-try_rc_10_first = 1;
+ usb_version = le16_to_cpu(us-pusb_dev-descriptor.bcdUSB);
+ if (usb_version '3' * 0x100)
+ sdev-try_rc_10_first = 1;
/* assume SPC3 or latter devices support sense size 18 */
if (sdev-scsi_level SCSI_SPC_2)
--
1.8.3.1
Re: [alsa-devel] Buffer size for ALSA USB PCM audio
At Thu, 1 Aug 2013 13:37:45 -0400 (EDT),
Alan Stern wrote:
On Mon, 29 Jul 2013, Clemens Ladisch wrote:
Alan Stern wrote:
Clemens remarked some time ago that keeping the queue full would be
trivial, if only he knew how full it needed to be. The answer to that
is given above. I have been trying to make the appropriate changes,
but I'm not finding it trivial.
What I meant was that it would be trivial to change the lower bound of
the period size (from which many queueing parameters are derived).
Here's what I've got. In turns out the predicting the optimum number
of URBs needed is extremely difficult. I decided it would be better to
make an overestimate and then to submit URBs as needed, rather than
keeping all of them active all the time.
I ended up with this patch (untested). It is certainly incomplete
because it doesn't address endpoints with implicit sync. It also
suffers from a race between snd_submit_urbs() and deactivate_urbs():
an URB may be resubmitted after it has been deactivated.
What's the reason to clear ep-active_mask at the beginning of
snd_complete_urb()?
(In all
fairness, I think this race probably exists in the current code too --
there are no spinlocks for synchronization.)
The calls of usb_submit_urb() and usb_unlink_urb() might race indeed.
The current code somehow assumed that the USB accepts such concurrent
calls. deactivate_urbs() just kills the pending urbs and it doesn't
change ep-active_mask bit by itself, and the synchronization is done
in wait_clear_urbs(). So, if the concurrent calls of usb_submit_urb()
and usb_unlink_urbs() were allowed, it should work as is (in the worst
case, the complete will be called once again, but then it goes to
exit_clear).
thanks,
Takashi
The patch also fixes a couple of unrelated items: MAX_PACKS vs.
MAX_PACKS_HS, and the maxsize calculation should realize that a packet
can't contain a partial frame.
What do you think of this approach?
Alan Stern
sound/usb/card.h |7 +
sound/usb/endpoint.c | 185
+--
sound/usb/pcm.c |3
3 files changed, 114 insertions(+), 81 deletions(-)
Index: usb-3.11/sound/usb/card.h
===
--- usb-3.11.orig/sound/usb/card.h
+++ usb-3.11/sound/usb/card.h
@@ -4,7 +4,7 @@
#define MAX_NR_RATES 1024
#define MAX_PACKS20
#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */
-#define MAX_URBS 8
+#define MAX_URBS 11
#define SYNC_URBS4 /* always four urbs for sync */
#define MAX_QUEUE24 /* try not to exceed this queue length, in ms */
@@ -43,6 +43,7 @@ struct snd_urb_ctx {
struct snd_usb_endpoint *ep;
int index; /* index for urb array */
int packets;/* number of packets per urb */
+ int data_packets; /* current number of data packets */
int packet_size[MAX_PACKS_HS]; /* size of packets for next submission */
struct list_head ready_list;
};
@@ -99,6 +100,10 @@ struct snd_usb_endpoint {
int skip_packets; /* quirks for devices to ignore the
first n packets
in a stream */
+ unsigned int min_queued_packs; /* USB hardware queue requirement */
+ unsigned int queued_packs; /* number of packets currently queued */
+ unsigned int queued_urbs; /* number of URBs currently queued */
+ int next_urb; /* next to submit */
spinlock_t lock;
struct list_head list;
};
Index: usb-3.11/sound/usb/pcm.c
===
--- usb-3.11.orig/sound/usb/pcm.c
+++ usb-3.11/sound/usb/pcm.c
@@ -1328,7 +1328,7 @@ static void prepare_playback_urb(struct
stride = runtime-frame_bits 3;
frames = 0;
- urb-number_of_packets = 0;
+ ctx-data_packets = urb-number_of_packets = 0;
spin_lock_irqsave(subs-lock, flags);
for (i = 0; i ctx-packets; i++) {
if (ctx-packet_size[i])
@@ -1341,6 +1341,7 @@ static void prepare_playback_urb(struct
urb-iso_frame_desc[i].length = counts * ep-stride;
frames += counts;
urb-number_of_packets++;
+ ctx-data_packets++;
subs-transfer_done += counts;
if (subs-transfer_done = runtime-period_size) {
subs-transfer_done -= runtime-period_size;
Index: usb-3.11/sound/usb/endpoint.c
===
--- usb-3.11.orig/sound/usb/endpoint.c
+++ usb-3.11/sound/usb/endpoint.c
@@ -217,6 +217,7 @@ static void prepare_outbound_urb(struct
}
urb-number_of_packets = ctx-packets;
+ ctx-data_packets = ctx-packets;
urb-transfer_buffer_length
Re: [PATCH 1/2] USB: chipidea: i.MX: remove unused define
On Mon, Aug 12, 2013 at 12:29:41PM +0200, Sascha Hauer wrote: Signed-off-by: Sascha Hauer s.ha...@pengutronix.de --- drivers/usb/chipidea/ci_hdrc_imx.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index 14362c0..11ed423 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -24,9 +24,6 @@ #include ci.h #include ci_hdrc_imx.h -#define pdev_to_phy(pdev) \ - ((struct usb_phy *)platform_get_drvdata(pdev)) - This one has already submitted by me, and queued by alex. -- 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 2/2] USB: chipidea: i.MX: simplify usbmisc
On Mon, Aug 12, 2013 at 12:29:42PM +0200, Sascha Hauer wrote:
The chipidea i.MX driver is split into two drivers. The ci_hdrc_imx driver
handles the chipidea cores and the usbmisc_imx driver handles the noncore
registers common to all chipidea cores (but SoC specific). Current flow is:
- usbmisc sets an ops pointer in the ci_hdrc_imx driver during probe
- ci_hdrc_imx checks if the pointer is valid during probe, if yes calls
the functions in the ops pointer.
- usbmisc_imx calls back into the ci_hdrc_imx driver to get additional
data
This is overly complicated and has problems if the drivers are compiled
as modules. In this case the usbmisc_imx driver can be unloaded even if
the ci_hdrc_imx driver still needs usbmisc functionality.
This patch changes this by letting the ci_hdrc_imx driver calling functions
from the usbmisc_imx driver. This way the symbol resolving during module
load makes sure the ci_hdrc_imx driver depends on the usbmisc_imx driver.
Also instead of letting the usbmisc_imx driver call back into the ci_hdrc_imx
driver, pass the needed data in the first place.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/usb/chipidea/ci_hdrc_imx.c | 71 +---
drivers/usb/chipidea/ci_hdrc_imx.h | 17 ++-
drivers/usb/chipidea/usbmisc_imx.c | 95
+-
3 files changed, 76 insertions(+), 107 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 11ed423..b9464ff 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -29,57 +29,48 @@ struct ci_hdrc_imx_data {
struct platform_device *ci_pdev;
struct clk *clk;
struct regulator *reg_vbus;
+ struct imx_usbmisc_data *usbmisc_data;
};
-static const struct usbmisc_ops *usbmisc_ops;
-
/* Common functions shared by usbmisc drivers */
-int usbmisc_set_ops(const struct usbmisc_ops *ops)
-{
- if (usbmisc_ops)
- return -EBUSY;
-
- usbmisc_ops = ops;
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(usbmisc_set_ops);
-
-void usbmisc_unset_ops(const struct usbmisc_ops *ops)
-{
- usbmisc_ops = NULL;
-}
-EXPORT_SYMBOL_GPL(usbmisc_unset_ops);
-
-int usbmisc_get_init_data(struct device *dev, struct usbmisc_usb_device
*usbdev)
+static struct imx_usbmisc_data *usbmisc_get_init_data(struct device *dev)
{
struct device_node *np = dev-of_node;
struct of_phandle_args args;
+ struct imx_usbmisc_data *data;
int ret;
- usbdev-dev = dev;
+ /*
+ * In case the fsl,usbmisc property is not present this device doesn't
+ * need usbmisc. Return NULL (which is no error here)
+ */
+ if (!of_get_property(np, fsl,usbmisc, NULL))
+ return NULL;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
ret = of_parse_phandle_with_args(np, fsl,usbmisc, #index-cells,
0, args);
if (ret) {
dev_err(dev, Failed to parse property fsl,usbmisc, errno %d\n,
ret);
- memset(usbdev, 0, sizeof(*usbdev));
- return ret;
+ return ERR_PTR(ret);
}
- usbdev-index = args.args[0];
+
+ data-index = args.args[0];
of_node_put(args.np);
if (of_find_property(np, disable-over-current, NULL))
- usbdev-disable_oc = 1;
+ data-disable_oc = 1;
if (of_find_property(np, external-vbus-divider, NULL))
- usbdev-evdo = 1;
+ data-evdo = 1;
- return 0;
+ return data;
}
-EXPORT_SYMBOL_GPL(usbmisc_get_init_data);
/* End of common functions shared by usbmisc drivers*/
@@ -96,10 +87,6 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
struct resource *res;
int ret;
- if (of_find_property(pdev-dev.of_node, fsl,usbmisc, NULL)
- !usbmisc_ops)
- return -EPROBE_DEFER;
-
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data) {
dev_err(pdev-dev, Failed to allocate ci_hdrc-imx data!\n);
@@ -112,6 +99,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
return -ENOENT;
}
+ data-usbmisc_data = usbmisc_get_init_data(pdev-dev);
+ if (IS_ERR(data-usbmisc_data))
+ return PTR_ERR(data-usbmisc_data);
+
data-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(data-clk)) {
dev_err(pdev-dev,
@@ -159,11 +150,11 @@ static int ci_hdrc_imx_probe(struct platform_device
*pdev)
if (!pdev-dev.coherent_dma_mask)
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
- if (usbmisc_ops usbmisc_ops-init) {
- ret = usbmisc_ops-init(pdev-dev);
+ if (data-usbmisc_data) {
+
Re: [PATCH] usb: gadget: at91_udc: add usb_clk for transition to common clk framework
On 01/08/2013 08:18, Boris BREZILLON :
The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.
This patch adds support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable it).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/usb/gadget/at91_udc.c | 17 -
drivers/usb/gadget/at91_udc.h |2 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index fce8e4e..ae06585 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -870,6 +870,11 @@ static void clk_on(struct at91_udc *udc)
if (udc-clocked)
return;
udc-clocked = 1;
+
+ if (!IS_ERR(udc-uclk)) {
+ clk_set_rate(udc-uclk, 4800);
+ clk_prepare_enable(udc-uclk);
+ }
clk_prepare_enable(udc-iclk);
clk_prepare_enable(udc-fclk);
}
@@ -882,6 +887,8 @@ static void clk_off(struct at91_udc *udc)
udc-gadget.speed = USB_SPEED_UNKNOWN;
clk_disable_unprepare(udc-fclk);
clk_disable_unprepare(udc-iclk);
+ if (!IS_ERR(udc-uclk))
+ clk_disable_unprepare(udc-uclk);
}
/*
@@ -1774,10 +1781,10 @@ static int at91udc_probe(struct platform_device *pdev)
/* get interface and function clocks */
udc-iclk = clk_get(dev, udc_clk);
udc-fclk = clk_get(dev, udpck);
+ udc-uclk = clk_get(dev, usb_clk);
if (IS_ERR(udc-iclk) || IS_ERR(udc-fclk)) {
DBG(clocks missing\n);
retval = -ENODEV;
- /* NOTE: we know here that refcounts on these are NOPs */
goto fail1;
}
@@ -1851,6 +1858,12 @@ fail3:
fail2:
free_irq(udc-udp_irq, udc);
fail1:
+ if (!IS_ERR(udc-uclk))
+ clk_put(udc-uclk);
+ if (!IS_ERR(udc-fclk))
+ clk_put(udc-fclk);
+ if (!IS_ERR(udc-iclk))
+ clk_put(udc-iclk);
iounmap(udc-udp_baseaddr);
fail0a:
if (cpu_is_at91rm9200())
@@ -1894,6 +1907,8 @@ static int __exit at91udc_remove(struct platform_device
*pdev)
clk_put(udc-iclk);
clk_put(udc-fclk);
+ if (!IS_ERR(udc-uclk))
+ clk_put(udc-uclk);
return 0;
}
diff --git a/drivers/usb/gadget/at91_udc.h b/drivers/usb/gadget/at91_udc.h
index e647d1c..0175246 100644
--- a/drivers/usb/gadget/at91_udc.h
+++ b/drivers/usb/gadget/at91_udc.h
@@ -126,7 +126,7 @@ struct at91_udc {
unsignedactive_suspend:1;
u8 addr;
struct at91_udc_databoard;
- struct clk *iclk, *fclk;
+ struct clk *iclk, *fclk, *uclk;
struct platform_device *pdev;
struct proc_dir_entry *pde;
void __iomem*udp_baseaddr;
--
Nicolas Ferre
--
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: ohci-at91: add usb_clk for transition to common clk framework
On 01/08/2013 19:09, Boris BREZILLON :
The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.
This patch adds support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable it).
Changes since v1:
- use IS_ENABLED(CONFIG_COMMON_CLK) to isolate new at91 clk support
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Well, for this v2 as well:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
(even if it is too late)
Bye,
---
drivers/usb/host/ohci-at91.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9677f68..db60048 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -31,8 +31,8 @@
#define at91_for_each_port(index) \
for ((index) = 0; (index) AT91_MAX_USBH_PORTS; (index)++)
-/* interface and function clocks; sometimes also an AHB clock */
-static struct clk *iclk, *fclk, *hclk;
+/* interface, function and usb clocks; sometimes also an AHB clock */
+static struct clk *iclk, *fclk, *uclk, *hclk;
static int clocked;
extern int usb_disabled(void);
@@ -41,6 +41,10 @@ extern int usb_disabled(void);
static void at91_start_clock(void)
{
+ if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+ clk_set_rate(uclk, 4800);
+ clk_prepare_enable(uclk);
+ }
clk_prepare_enable(hclk);
clk_prepare_enable(iclk);
clk_prepare_enable(fclk);
@@ -52,6 +56,8 @@ static void at91_stop_clock(void)
clk_disable_unprepare(fclk);
clk_disable_unprepare(iclk);
clk_disable_unprepare(hclk);
+ if (IS_ENABLED(CONFIG_COMMON_CLK))
+ clk_disable_unprepare(uclk);
clocked = 0;
}
@@ -162,6 +168,14 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
retval = PTR_ERR(hclk);
goto err5;
}
+ if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+ uclk = clk_get(pdev-dev, usb_clk);
+ if (IS_ERR(uclk)) {
+ dev_err(pdev-dev, failed to get uclk\n);
+ retval = PTR_ERR(uclk);
+ goto err6;
+ }
+ }
at91_start_hc(pdev);
ohci_hcd_init(hcd_to_ohci(hcd));
@@ -173,6 +187,9 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
/* Error handling */
at91_stop_hc(pdev);
+ if (IS_ENABLED(CONFIG_COMMON_CLK))
+ clk_put(uclk);
+ err6:
clk_put(hclk);
err5:
clk_put(fclk);
@@ -212,6 +229,8 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
+ if (IS_ENABLED(CONFIG_COMMON_CLK))
+ clk_put(uclk);
clk_put(hclk);
clk_put(fclk);
clk_put(iclk);
--
Nicolas Ferre
--
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: dealing with enclosures that don't handle READ_CAPACITY10
On Mon, 12 Aug 2013, Oliver Neukum wrote: Hi, I got a bug report about an enclosure that mishandles READ_CAPACITY10. I don't want to introduce yet another quirk. So what about basing this on USB version? @@ -211,8 +212,12 @@ static int slave_configure(struct scsi_device *sdev) /* * Many devices do not respond properly to READ_CAPACITY_16. * Tell the SCSI layer to try READ_CAPACITY_10 first. +* However some USB 3.0 drive enclosures return capacity +* modulo 2TB */ - sdev-try_rc_10_first = 1; + usb_version = le16_to_cpu(us-pusb_dev-descriptor.bcdUSB); + if (usb_version '3' * 0x100) Don't you mean 0x300? '3' * 0x100 is really equal to 0x3300. + sdev-try_rc_10_first = 1; This may be a reasonable thing to do, although there's always a risk that it will cause a regression. I have definitely seen one or two reports about drives doing this, but I don't remember whether they claimed to be USB-2 or USB-3. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dealing with enclosures that don't handle READ_CAPACITY10
On Mon, 2013-08-12 at 10:36 -0400, Alan Stern wrote: On Mon, 12 Aug 2013, Oliver Neukum wrote: Hi, I got a bug report about an enclosure that mishandles READ_CAPACITY10. I don't want to introduce yet another quirk. So what about basing this on USB version? @@ -211,8 +212,12 @@ static int slave_configure(struct scsi_device *sdev) /* * Many devices do not respond properly to READ_CAPACITY_16. * Tell the SCSI layer to try READ_CAPACITY_10 first. +* However some USB 3.0 drive enclosures return capacity +* modulo 2TB */ - sdev-try_rc_10_first = 1; + usb_version = le16_to_cpu(us-pusb_dev-descriptor.bcdUSB); + if (usb_version '3' * 0x100) Don't you mean 0x300? '3' * 0x100 is really equal to 0x3300. Thanks. + sdev-try_rc_10_first = 1; This may be a reasonable thing to do, although there's always a risk that it will cause a regression. I have definitely seen one or two reports about drives doing this, but I don't remember whether they claimed to be USB-2 or USB-3. Well, if it is USB2 we may need a quirk in addition. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Buffer size for ALSA USB PCM audio
On Mon, 12 Aug 2013, Takashi Iwai wrote: Here's what I've got. In turns out the predicting the optimum number of URBs needed is extremely difficult. I decided it would be better to make an overestimate and then to submit URBs as needed, rather than keeping all of them active all the time. I ended up with this patch (untested). It is certainly incomplete because it doesn't address endpoints with implicit sync. It also suffers from a race between snd_submit_urbs() and deactivate_urbs(): an URB may be resubmitted after it has been deactivated. What's the reason to clear ep-active_mask at the beginning of snd_complete_urb()? In order to keep ep-active_mask accurate. snd_complete_urb() might not resubmit the URB. (In all fairness, I think this race probably exists in the current code too -- there are no spinlocks for synchronization.) The calls of usb_submit_urb() and usb_unlink_urb() might race indeed. The current code somehow assumed that the USB accepts such concurrent calls. The USB API does indeed allow concurrent calls of usb_submit_urb() and usb_unlink_urb(). They are serialized by a spinlock in the host controller driver, and if the usb_unlink_urb() call ends up coming first, it will fail. (Ironically, in the EHCI driver, trying to unlink an isochronous URB doesn't do anything at all. The URB will complete in the usual way, when all its time slots expire.) deactivate_urbs() just kills the pending urbs and it doesn't change ep-active_mask bit by itself, and the synchronization is done in wait_clear_urbs(). Oh, so that's where ep-active_mask gets used. Why call bitmap_weight()? Why not simply see if the mask value is equal to 0? So, if the concurrent calls of usb_submit_urb() and usb_unlink_urbs() were allowed, it should work as is (in the worst case, the complete will be called once again, but then it goes to exit_clear). I see. Assuming there's always at least one active URB while the endpoint is running, wait_clear_urbs() should work okay. The patch won't violate this assumption, so it's good. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Buffer size for ALSA USB PCM audio
At Mon, 12 Aug 2013 10:53:36 -0400 (EDT), Alan Stern wrote: On Mon, 12 Aug 2013, Takashi Iwai wrote: Here's what I've got. In turns out the predicting the optimum number of URBs needed is extremely difficult. I decided it would be better to make an overestimate and then to submit URBs as needed, rather than keeping all of them active all the time. I ended up with this patch (untested). It is certainly incomplete because it doesn't address endpoints with implicit sync. It also suffers from a race between snd_submit_urbs() and deactivate_urbs(): an URB may be resubmitted after it has been deactivated. What's the reason to clear ep-active_mask at the beginning of snd_complete_urb()? In order to keep ep-active_mask accurate. snd_complete_urb() might not resubmit the URB. (In all fairness, I think this race probably exists in the current code too -- there are no spinlocks for synchronization.) The calls of usb_submit_urb() and usb_unlink_urb() might race indeed. The current code somehow assumed that the USB accepts such concurrent calls. The USB API does indeed allow concurrent calls of usb_submit_urb() and usb_unlink_urb(). They are serialized by a spinlock in the host controller driver, and if the usb_unlink_urb() call ends up coming first, it will fail. (Ironically, in the EHCI driver, trying to unlink an isochronous URB doesn't do anything at all. The URB will complete in the usual way, when all its time slots expire.) deactivate_urbs() just kills the pending urbs and it doesn't change ep-active_mask bit by itself, and the synchronization is done in wait_clear_urbs(). Oh, so that's where ep-active_mask gets used. Why call bitmap_weight()? Why not simply see if the mask value is equal to 0? Yeah, it can be so. Though, the number of pending urbs is printed in the error message, thus bitmap_weight() is needed there instead. So, if the concurrent calls of usb_submit_urb() and usb_unlink_urbs() were allowed, it should work as is (in the worst case, the complete will be called once again, but then it goes to exit_clear). I see. Assuming there's always at least one active URB while the endpoint is running, wait_clear_urbs() should work okay. The patch won't violate this assumption, so it's good. OK. So... Clemens, Daniel, Eldad, could you guys review the latest version of Alan's patch? I'd love to sort this out for 3.12. thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used
Hello, Jonathan. On Mon, Aug 12, 2013 at 12:04:11AM -0700, Jonathan Nieder wrote: My laptop fails to boot[1] with the message 'Volume group data not found'. Bisects to v3.8-rc4~17 (the above commit). Reverting that commit on top of current master (d92581fcad18, 2013-08-10) produces a working kernel. dmesg output from that working kernel attached. More details, including .config, at [2]. Any ideas for tracking this down? Which initrd / boot script are you using? It looks like lvm assemble scripts are running before sdX are detected leading to volume assembly failure. Before the patch, any module loading would end up synchronizing async probes but after the patch modprobe invocations which don't schedule them won't be. Does your boot script happen to run multiple modprobes in parallel and proceed to configure lvm without waiting for modprobes of libata drivers to finish? Thanks. -- tejun -- 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] wusbcore: clean up list locking in urb enqueue
wa_urb_enqueue_run locks and unlocks its list lock as it traverses the
list of queued transfers. This was done to prevent deadlocking due to
acquiring locks in reverse order in different places. The problem is that
releasing the lock during the list traversal could allow the dequeue
routine to corrupt the list while it is being iterated over. This patch
moves all list entries to a temp list while holding the list lock, then
traverses the temp list with no lock held.
Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com
diff --git a/drivers/usb/wusbcore/wa-xfer.c b/drivers/usb/wusbcore/wa-xfer.c
index d3493ca..cef940f 100644
--- a/drivers/usb/wusbcore/wa-xfer.c
+++ b/drivers/usb/wusbcore/wa-xfer.c
@@ -928,7 +928,7 @@ static void wa_xfer_delayed_run(struct wa_rpipe *rpipe)
spin_lock_irqsave(rpipe-seg_lock, flags);
while (atomic_read(rpipe-segs_available) 0
!list_empty(rpipe-seg_list)) {
- seg = list_entry(rpipe-seg_list.next, struct wa_seg,
+ seg = list_first_entry((rpipe-seg_list), struct wa_seg,
list_node);
list_del(seg-list_node);
xfer = seg-xfer;
@@ -1093,30 +1093,35 @@ error_xfer_submit:
*
* We need to be careful here, as dequeue() could be called in the
* middle. That's why we do the whole thing under the
- * wa-xfer_list_lock. If dequeue() jumps in, it first locks urb-lock
+ * wa-xfer_list_lock. If dequeue() jumps in, it first locks xfer-lock
* and then checks the list -- so as we would be acquiring in inverse
- * order, we just drop the lock once we have the xfer and reacquire it
- * later.
+ * order, we move the delayed list to a separate list while locked and then
+ * submit them without the list lock held.
*/
void wa_urb_enqueue_run(struct work_struct *ws)
{
struct wahc *wa = container_of(ws, struct wahc, xfer_work);
struct wa_xfer *xfer, *next;
struct urb *urb;
+ LIST_HEAD(tmp_list);
+ /* Create a copy of the wa-xfer_delayed_list while holding the lock */
spin_lock_irq(wa-xfer_list_lock);
- list_for_each_entry_safe(xfer, next, wa-xfer_delayed_list,
-list_node) {
+ list_cut_position(tmp_list, wa-xfer_delayed_list,
+ wa-xfer_delayed_list.prev);
+ spin_unlock_irq(wa-xfer_list_lock);
+
+ /*
+* enqueue from temp list without list lock held since wa_urb_enqueue_b
+* can take xfer-lock as well as lock mutexes.
+*/
+ list_for_each_entry_safe(xfer, next, tmp_list, list_node) {
list_del_init(xfer-list_node);
- spin_unlock_irq(wa-xfer_list_lock);
urb = xfer-urb;
wa_urb_enqueue_b(xfer);
usb_put_urb(urb); /* taken when queuing */
-
- spin_lock_irq(wa-xfer_list_lock);
}
- spin_unlock_irq(wa-xfer_list_lock);
}
EXPORT_SYMBOL_GPL(wa_urb_enqueue_run);
--
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: xhci: Disable runtime PM suspend for quirky controllers.
Hi Sarah, I will resubmit the patch with these changes shortly. On Fri, Aug 9, 2013 at 10:22 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Hi Shawn, I noticed that the ChromeOS kernel tree is still using this particular patch, and thought it was probably time to revisit it. On Sat, May 25, 2013 at 09:57:57AM -0700, Shawn Nematbakhsh wrote: Hi Sarah and Alan, Thanks for the comments. I will make the following revisions: 1. Call pm_runtime_get_noresume only when the first device is connected, and call pm_runtime_put when the last device is disconnected. 2. Wrap the calls in an ifdef CONFIG_USB_DEFAULT_PERSIST. 3. Make sure that all pm_runtime_get_noresume calls have a corresponding pm_runtime_put somewhere (originally the intent was to disable runtime suspend forever, but no longer). In principle, would the patch be acceptable with these revisions? The thread petered off with all other options turning out to be dead-ends, so yes, if you made those changes, you could get that patch upstream. I would like the ChromeOS kernel to be as close to upstream as possible, so please resubmit this patch with those changes. Thanks, Sarah Sharp On Sat, May 25, 2013 at 7:11 AM, Alan Stern st...@rowland.harvard.eduwrote: On Fri, 24 May 2013, Sarah Sharp wrote: On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote: If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend, a reset will be performed upon runtime resume. Any previously suspended devices attached to the controller will be re-enumerated at this time. This will cause problems, for example, if an open system call on the device triggered the resume (the open call will fail). That's ugly, but disabling runtime PM is going to have a big impact on the power consumption of those systems. Alan, do you think this is really the right thing to be doing here? It feels like userspace should just be able to deal with devices disconnecting on resume. After all, there are lots of USB devices that can't handle USB device suspend at all. This is a complicated issue. It depends on the runtime PM settings for both the device and the host controller. As just one aspect, consider the fact that if it wants to, userspace can already prevent the controller from going into runtime suspend. Always preventing this at the kernel level, even when no devices are plugged in, does seem too heavy-handed. Shouldn't userspace just disable runtime PM for the USB device classes that don't have a reset resume callback? That's not so easy, because the kernel changes over time. Userspace has no general way to tell which drivers have reset-resume support. Note that this change is only relevant when persist_enabled is not set for USB devices. Could we at least wrap the call in an ifdef CONFIG_USB_DEFAULT_PERSIST? That way if people have USB persist turned off in their configuration, their host will still be able to suspend. Not just that; the patch is incorrect on the face of it... @@ -4687,6 +4687,12 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks) get_quirks(dev, xhci); + /* If we are resetting upon resume, we must disable runtime PM. +* Otherwise, an open() syscall to a device on our runtime suspended +* controller will trigger controller reset and device re-enumeration */ + if (xhci-quirks XHCI_RESET_ON_RESUME) + pm_runtime_get_noresume(dev); + It adds a pm_runtime_get call with no corresponding pm_runtime_put. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Buffer size for ALSA USB PCM audio
On Mon, 12 Aug 2013, Takashi Iwai wrote:
So... Clemens, Daniel, Eldad, could you guys review the latest version
of Alan's patch? I'd love to sort this out for 3.12.
Here's a revised version of the patch (still untested). The difference
is that this version tries always to keep a period's worth of bytes in
the USB hardware queue. This will provide better protection against
underruns when the period is larger than the queue's minimum
requirement.
Alan Stern
sound/usb/card.h |9 ++
sound/usb/endpoint.c | 200 ++-
sound/usb/pcm.c |4 -
3 files changed, 132 insertions(+), 81 deletions(-)
Index: usb-3.11/sound/usb/card.h
===
--- usb-3.11.orig/sound/usb/card.h
+++ usb-3.11/sound/usb/card.h
@@ -4,7 +4,7 @@
#define MAX_NR_RATES 1024
#define MAX_PACKS 20
#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */
-#define MAX_URBS 8
+#define MAX_URBS 11
#define SYNC_URBS 4 /* always four urbs for sync */
#define MAX_QUEUE 24 /* try not to exceed this queue length, in ms */
@@ -43,6 +43,8 @@ struct snd_urb_ctx {
struct snd_usb_endpoint *ep;
int index; /* index for urb array */
int packets;/* number of packets per urb */
+ int data_packets; /* current number of data packets */
+ int data_frames;/* current number of data frames */
int packet_size[MAX_PACKS_HS]; /* size of packets for next submission */
struct list_head ready_list;
};
@@ -99,6 +101,11 @@ struct snd_usb_endpoint {
int skip_packets; /* quirks for devices to ignore the
first n packets
in a stream */
+ unsigned int min_queued_packs; /* USB hardware queue requirement */
+ unsigned int queued_packs; /* number of packets on the queue */
+ unsigned int queued_urbs; /* number of URBs on the queue */
+ unsigned int queued_frames; /* number of data frames on the queue */
+ int next_urb; /* next to submit */
spinlock_t lock;
struct list_head list;
};
Index: usb-3.11/sound/usb/pcm.c
===
--- usb-3.11.orig/sound/usb/pcm.c
+++ usb-3.11/sound/usb/pcm.c
@@ -1328,7 +1328,7 @@ static void prepare_playback_urb(struct
stride = runtime-frame_bits 3;
frames = 0;
- urb-number_of_packets = 0;
+ ctx-data_packets = urb-number_of_packets = 0;
spin_lock_irqsave(subs-lock, flags);
for (i = 0; i ctx-packets; i++) {
if (ctx-packet_size[i])
@@ -1341,6 +1341,7 @@ static void prepare_playback_urb(struct
urb-iso_frame_desc[i].length = counts * ep-stride;
frames += counts;
urb-number_of_packets++;
+ ctx-data_packets++;
subs-transfer_done += counts;
if (subs-transfer_done = runtime-period_size) {
subs-transfer_done -= runtime-period_size;
@@ -1370,6 +1371,7 @@ static void prepare_playback_urb(struct
!snd_usb_endpoint_implicit_feedback_sink(subs-data_endpoint)) /* finish at the
period boundary */
break;
}
+ ctx-data_frames = frames;
bytes = frames * ep-stride;
if (unlikely(subs-pcm_format == SNDRV_PCM_FORMAT_DSD_U16_LE
Index: usb-3.11/sound/usb/endpoint.c
===
--- usb-3.11.orig/sound/usb/endpoint.c
+++ usb-3.11/sound/usb/endpoint.c
@@ -203,6 +203,7 @@ static void prepare_outbound_urb(struct
} else {
/* no data provider, so send silence */
unsigned int offs = 0;
+
for (i = 0; i ctx-packets; ++i) {
int counts;
@@ -217,6 +218,8 @@ static void prepare_outbound_urb(struct
}
urb-number_of_packets = ctx-packets;
+ ctx-data_packets = ctx-packets;
+ ctx-data_frames = offs;
urb-transfer_buffer_length = offs * ep-stride;
memset(urb-transfer_buffer, ep-silence_value,
offs * ep-stride);
@@ -273,6 +276,7 @@ static inline void prepare_inbound_urb(s
urb-transfer_buffer_length = offs;
urb-number_of_packets = urb_ctx-packets;
+ urb_ctx-data_packets = urb_ctx-packets;
break;
case SND_USB_ENDPOINT_TYPE_SYNC:
@@ -341,6 +345,55 @@ static void queue_pending_output_urbs(st
}
}
+/**
+ * snd_submit_urbs: Submit data URBs for endpoints without implicit feedback
+ *
+ * @ep: The endpoint to use
+ * @ctx: Context for the first URB on the
[PATCH 1/1] USB-Serial: Fix error handling of usb_wwan
This fixes an issue where the bulk-in urb used for incoming data transfer
is not resubmitted if the packet recieved contains an error status. This
results in the driver locking until the port is closed and re-opened.
Tested on a custom board with a Cinterion GSM module.
Signed-off-by: Matt Burtch m...@grid-net.com
---
drivers/usb/serial/usb_wwan.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/serial/usb_wwan.c b/drivers/usb/serial/usb_wwan.c
index 8257d30..9eefc33 100644
--- a/drivers/usb/serial/usb_wwan.c
+++ b/drivers/usb/serial/usb_wwan.c
@@ -291,18 +291,18 @@ static void usb_wwan_indat_callback(struct urb *urb)
tty_flip_buffer_push(port-port);
} else
dev_dbg(dev, %s: empty read urb received\n, __func__);
-
- /* Resubmit urb so we continue receiving */
- err = usb_submit_urb(urb, GFP_ATOMIC);
- if (err) {
- if (err != -EPERM) {
- dev_err(dev, %s: resubmit read urb failed.
(%d)\n, __func__, err);
- /* busy also in error unless we are killed */
- usb_mark_last_busy(port-serial-dev);
- }
- } else {
+ }
+ /* Resubmit urb so we continue receiving */
+ err = usb_submit_urb(urb, GFP_ATOMIC);
+ if (err) {
+ if (err != -EPERM) {
+ dev_err(dev, %s: resubmit read urb failed. (%d)\n,
+ __func__, err);
+ /* busy also in error unless we are killed */
usb_mark_last_busy(port-serial-dev);
}
+ } else {
+ usb_mark_last_busy(port-serial-dev);
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] USB-Serial: Fix error handling of usb_wwan
On Mon, Aug 12, 2013 at 10:11:39AM -0700, Matt Burtch wrote: This fixes an issue where the bulk-in urb used for incoming data transfer is not resubmitted if the packet recieved contains an error status. This results in the driver locking until the port is closed and re-opened. Tested on a custom board with a Cinterion GSM module. Signed-off-by: Matt Burtch m...@grid-net.com Ah, nice catch, thanks for this, I'll also mark it for the stable tree as it's something that those kernels would want to pick up. 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: [RFC/PATCH 2/2] usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET
Hi, On Fri, Aug 09, 2013 at 11:04:48AM -0400, Alan Stern wrote: heh, it doesn't need to be entirely in the core. Core could have the generic calls and HCDs could implement some callbacks, but I think quite a bit of the code will be similar if we implement the same thing on all HCDs. What generic calls and callbacks would you suggest? I assume you want enough to cover not just this one test but the entire USB-CV suite. maybe a single callback for supporting 'testmodes' ? which receives the test mode as argument ? I don't have a clear picture of how you would apply such an approach to this case. There would have to be a way to tell the HCD to insert a 15-second delay between the Setup and Data stages of a particular control URB. How would you do that? Whatever method you choose, each test is started after enumerating a known Vid/Pid pair. Based on that, you *know* which test to run. implementing it in every HCD would be a huge amount of work. sure, we can support different HCDs with time, but once SINGLE_STEP is implemented in e.g. EHCI, it should be simple to port it to OHCI/xHCI/MUSB/etc. What other test modes would you want to support? anything that USB[23]0CV supports today. There are even link layer tests for USB3 and a bunch of others. This SINGLE_STEP_SET_FEATURE is but one of a large(-ish) test suite which needs to be supported. Is it worth adding this support to the standard host controller drivers, or should there be a special version (a Kconfig option like CONFIG_RCU_TORTURE_TEST) to enable it? Putting a lot of testing code in distribution kernels where it will never be used seems like a big waste. right, I think it should be hidden by Kconfig, not arguing against that. -- balbi signature.asc Description: Digital signature
Re: DWC3 role switch cause IRQ request failed
On Fri, Aug 09, 2013 at 03:16:20PM +, Wang, Yu Y wrote: On Fri, Aug 09, 2013 at 01:34:09PM +, Wang, Yu Y wrote: On Wed, Aug 07, 2013 at 12:03:34PM +, Wang, Yu Y wrote: Hi Balbi, Because dwc3 driver request_threaded_irq with flags IRQF_ONESHOT and IRQF_SHARED. But xHCI driver will not set IRQF_ONESHOT. Then will met IRQ request failed if use same IRQ number. 4[1.019248] Call Trace: 4[1.019270] [c18c9f0f] dump_stack+0x16/0x18 4[1.019292] [c18c723c] __schedule_bug+0x65/0x77 4[1.019313] [c18cf48d] __schedule+0x7ad/0x830 4[1.019335] [c18b8080] ? rest_init+0xc0/0xc0 4[1.019358] [c1204b02] ? printk_address+0x32/0x40 4[1.019380] [c1293ae0] ? __module_text_address+0x10/0x60 4[1.019402] [c12991fb] ? is_module_text_address+0x2b/0x50 4[1.019424] [c125707f] ? __kernel_text_address+0x4f/0x70 4[1.019444] [c18cf583] schedule+0x23/0x60 4[1.019466] [c18cc765] schedule_timeout+0x125/0x1f0 4[1.019488] [c18ce66b] ? wait_for_completion+0x2b/0xe0 4[1.019509] [c18ce6d8] ? wait_for_completion+0x98/0xe0 4[1.019530] [c18ce6df] wait_for_completion+0x9f/0xe0 4[1.019551] [c12699f0] ? try_to_wake_up+0x280/0x280 4[1.019572] [c1259fb1] kthread_stop+0x41/0x100 4[1.019595] [c12a8256] __setup_irq+0xd6/0x460 4[1.019617] [c1641520] ? dwc3_gadget_set_selfpowered+0x60/0x60 4[1.019639] [c12a8682] request_threaded_irq+0xa2/0x120 4[1.019660] [c16437f0] ? dwc3_gadget_reset_interrupt+0x1a0/0x1a0 4[1.019681] [c1642c54] dwc3_gadget_start+0x1a4/0x1f0 4[1.019703] [c166ff47] udc_bind_to_driver+0x57/0x100 4[1.019724] [c1670481] usb_gadget_probe_driver+0xa1/0xe0 4[1.019745] [c153c618] ? device_create_file+0x38/0xb0 4[1.019766] [c167142f] usb_composite_probe+0x6f/0x90 4[1.019788] [c1c762c5] init+0x147/0x19f 4[1.019809] [c1c7617e] ? acmmod_init+0xf/0xf 4[1.019829] [c12001aa] do_one_initcall+0xba/0x170 4[1.019853] [c1c3fb32] kernel_init_freeable+0x119/0x1b8 4[1.019875] [c1c3f4dc] ? do_early_param+0x7a/0x7a 4[1.019896] [c18b8090] kernel_init+0x10/0xd0 4[1.019917] [c18d17f7] ret_from_kernel_thread+0x1b/0x28 4[1.019937] [c18b8080] ? rest_init+0xc0/0xc0 3[1.020082] dwc3 dwc3.0.auto: failed to request irq #34 -- -16 This is one known issue or new issue? I have already removed IRQF_ONESHOT, it'll be on v3.12 [Yu:] Thanks balbi. Can you please share the patch link? http://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=nextid=e8 adfc30ff9282a728fd8b666b6418308164c415 as usual, it's in my 'next' branch. you really need to fix your mailer btw, I got many copies of this same message. [Yu:] Thanks balbi. Don't know the reason. I send the email to you, and always get send failed response. So I tried more times. Sorry about that. BTW, Where can I find your git server link? I want to clone it to get latest code base. on git.kernel.org, in the link above, click on 'summary' and scroll down to the end of the page. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
On Fri, Aug 09, 2013 at 10:31:58AM -0500, Kumar Gala wrote: On Aug 9, 2013, at 4:53 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) probably good to spell out Synopsys rather than SNPS Synopsys (the company) has always used snps in their bindings though. +Required properities : +- compatible : sould be qcom,dwc3-hsphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + sleep_a_clk : Sleep clock, used when USB3 core goes into low + power mode (U3). +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for HSPHY + v3p3 : 3.3v supply for HSPHY + vbus : vbus supply for host mode + vddcx : vdd supply for HS-PHY digital circuit operation I believe these regulators belong to the PHY, not DWC3. Please write a PHY driver. +Required properities : +- compatible : sould be qcom,dwc3-ssphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + ref_clk : Reference clock - used in host mode. +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for SS-PHY + vddcx : vdd supply for SS-PHY digital circuit operation likewise, these regulators should be moved to the PHY driver. +Required properties : +- compatible : should be qcom,dwc3 +- reg : offset and length of the register set in the memory map + offset and length of the TCSR register for routing USB + signals to either picoPHY0 or picoPHY1. +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + core_clk : Master/Core clock, have to be = 125 MHz for SS + operation and = 60MHz for HS operation + iface_clk : System bus AXI clock + sleep_clk : Sleep clock, used when USB3 core goes into low + power mode (U3). + utmi_clk : Generated by HS-PHY. Used to clock the low power + parts of thr HS Link layer. + +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. + +Sub nodes: +- Sub node for DWC3 USB3 controller. + This sub node is required property for device node. The properties + of this subnode are specified in dwc3.txt. Is tx-fifo-resize required for qcom,dwc3? if so we should call that out in the binding. AFAICT that's only needed for OMAP5 ES1.0. Unless Qualcomm also screwed up default TX FIFO sizes :-p -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding
On Fri, Aug 09, 2013 at 01:42:15PM -0500, Kumar Gala wrote: On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote: On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: The binding spec wasn't clear that the order of the phandles in the usb-phy array has meaning. Clarify this point in the binding that it should be USB2-HS-PHY, USB3-SS-PHY. Signed-off-by: Kumar Gala ga...@codeaurora.org --- Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 7a95c65..8a9770b 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -6,7 +6,9 @@ Required properties: - compatible: must be synopsys,dwc3 - reg : Address and length of the register set for the device - interrupts: Interrupts used by the dwc3 controller. - - usb-phy : array of phandle for the PHY device + - usb-phy : array of phandle for the PHY device. The first element + in the array is expected to be a handle to the USB2/HS PHY and + the second element is expected to be a handle to the USB3/SS PHY Just to check - it's not valid to have a USB3 phy without a USB2 phy? Don't know, hopefully Felipe will chime in on that. that'd be a really non-standard implementation. Per-spec, USB3 is *always* backwards compatible with USB2. -- balbi signature.asc Description: Digital signature
Re: Non-enumerable devices on USB and other enumerable buses
On 08/12/2013 05:07 AM, Mark Rutland wrote: [Adding Olof] On Mon, Aug 12, 2013 at 10:51:36AM +0100, Mark Brown wrote: On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote: On Sun, 11 Aug 2013, Mark Brown wrote: One example that's bugging me right now is that on the Insignal Arndale platform there's a USB hub connected to one of the USB ports on the SoC (not as a PHY, it seems we also need the internal PHY running to talk to the device). The hub needs to be plugged into the SoC after the SoC USB controller has started with some GPIOs so we need to tell the system that the hub exists and needs to be synchronised with the USB controller. ... As I understand it, the wifi chip on the Snow Chromebook has a similar issue -- it hangs off of a probeable SDIO bus, but needs a regulator poked for it to turn on and become probeable (see exynos_wifi_bt_set_power in [1]). In this case, I wonder if it makes sense to model the extra requirements as part of the bus/socket/... itself rather than as part of the device that's attached to the bus. It seems quite common for SDIO-based WiFi devices to need a few things: * Regulator * 32KHz clock * Enable GPIO (- rfkill?) * Perhaps a reset GPIO Physically, these are provided to the socket into which the WiFi device plugs in. Perhaps we should try to explicitly model the socket (which I guess is really the SDIO bus in a way) rather than attaching these new resources to the controller or the device itself. In a similar way, I wonder if the USB case can be considered the same way? This seems less like a good fit since I don't expect the resources are always so similar there, and also there's the case of the bus being potentially behind a few levels of USB hub. And of course it all gets a little more messy when you get board-specific logic that needs setup, rather than something more common across multiple devices. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget/composite : Avoid crash with bad gadget drivers
On Fri, Aug 09, 2013 at 09:23:08PM +0300, Philippe De Swert wrote:
Some bad gadget drivers do not check the return status of usb_add_config.
fix the gadget driver
Thus they get a not correctly initialized config and when this gadget gets
deactivated the whole kernel crashes. Since on initialization failure cdev
is set to NULL it can be used to detect this problem situation. It can be
argued that the faulty gadget driver should be fixed, but imho it is better
to avoid crashing the kernel and letting the gadget developer know he/she
is making a mistake. And have the developer of said gadget driver then fix
the problem of course.
Signed-off-by: Philippe De Swert philippe.desw...@jollamobile.com
---
drivers/usb/gadget/composite.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 55f4df6..e019bb5 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -848,12 +848,18 @@ void usb_remove_config(struct usb_composite_dev *cdev,
{
unsigned long flags;
+ if (config-cdev == NULL) {
+ pr_warn(Calling usb_remove_config without a matching
usb_add_config!\n);
+ goto end;
+ }
I would take a WARN() only, but let the crash happen and fix the gadget
driver.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: gadget: at91_udc: add usb_clk for transition to common clk framework
On Mon, Aug 12, 2013 at 03:52:01PM +0200, Nicolas Ferre wrote: On 01/08/2013 08:18, Boris BREZILLON : The AT91 PMC (Power Management Controller) provides an USB clock used by USB Full Speed host (ohci) and USB Full Speed device (udc). The usb drivers (ohci and udc) must configure this clock to 48Mhz. This configuration was formely done in mach-at91/clock.c, but this implementation will be removed when moving to common clk framework. This patch adds support for usb clock retrieval and configuration, and is backward compatible with the current at91 clk implementation (if usb clk is not found, it does not configure/enable it). Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com I don't have the original, where is it ? Was it not Cced to linux-usb ? Can someone resend with Nicolas' Acked-by in place ? -- balbi signature.asc Description: Digital signature
[PATCH v3] usb: rh_call_control tbuf overflow fix
rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.
tbuf is currently statically allocated on the stack with a size
of 15 bytes, regardless of the size specified in the URB.
This patch dynamically allocates tbuf, and ensures that tbuf is
at least as big as the buffer in the URB.
If an hcd attempts to write a descriptor containing more than
15 bytes ( such as the Standard BOS Descriptor for hubs, defined
in the USB3.0 Spec, section 10.13.1 ) the write would overflow
the buffer and corrupt the stack. This patch addresses this
behavior.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Sean O. Stalley sean.stal...@intel.com
---
drivers/usb/core/hcd.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 014dc99..88d6e6e 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -464,17 +464,13 @@ static int rh_call_control (struct usb_hcd *hcd, struct
urb *urb)
struct usb_ctrlrequest *cmd;
u16 typeReq, wValue, wIndex, wLength;
u8 *ubuf = urb-transfer_buffer;
- /*
-* tbuf should be as big as the BOS descriptor and
-* the USB hub descriptor.
-*/
- u8 tbuf[USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE]
- __attribute__((aligned(4)));
- const u8*bufp = tbuf;
unsignedlen = 0;
int status;
u8 patch_wakeup = 0;
u8 patch_protocol = 0;
+ u16 tbuf_size;
+ u8 *tbuf;
+ const u8*bufp;
might_sleep();
@@ -494,6 +490,18 @@ static int rh_call_control (struct usb_hcd *hcd, struct
urb *urb)
if (wLength urb-transfer_buffer_length)
goto error;
+ /*
+* tbuf should be at least as big as the
+* USB hub descriptor.
+*/
+ tbuf_size = max_t(u16, sizeof(struct usb_hub_descriptor), wLength);
+ tbuf = kzalloc(tbuf_size, GFP_KERNEL);
+ if (!tbuf)
+ return -ENOMEM;
+
+ bufp = tbuf;
+
+
urb-actual_length = 0;
switch (typeReq) {
@@ -691,6 +699,8 @@ error:
bDeviceProtocol = USB_HUB_PR_HS_SINGLE_TT;
}
+ kfree(tbuf);
+
/* any errors get returned through the urb completion */
spin_lock_irq(hcd_root_hub_lock);
usb_hcd_unlink_urb_from_ep(hcd, urb);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] usb: misc: usb3503: Support operation with no I2C control
Reviewed-by: Dongjin Kim tobet...@gmail.com
I like this patch series, I dropped my changes to support non-i2c
based operation.
On Fri, Aug 9, 2013 at 7:41 PM, Mark Brown broo...@kernel.org wrote:
From: Mark Brown broo...@linaro.org
Refactor so that register writes for configuration are only performed if
the device has a regmap provided and also register as a platform driver.
This allows the driver to be used to manage GPIO based control of the
device.
Signed-off-by: Mark Brown broo...@linaro.org
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/usb/usb3503.txt | 3 +-
drivers/usb/misc/usb3503.c| 93
++-
2 files changed, 78 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt
b/Documentation/devicetree/bindings/usb/usb3503.txt
index 44a03f3..a018da4 100644
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -2,9 +2,10 @@ SMSC USB3503 High-Speed Hub Controller
Required properties:
- compatible: Should be smsc,usb3503 or smsc,usb3503a.
-- reg: Specifies the i2c slave address, it should be 0x08.
Optional properties:
+- reg: Specifies the i2c slave address, it is required and should be 0x08
+ if I2C is used.
- connect-gpios: Should specify GPIO for connect.
- disabled-ports: Should specify the ports unused.
'1' or '2' or '3' are availe for this property to describe the port
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index da45ed9..a31641e 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -78,22 +78,21 @@ static int usb3503_reset(struct usb3503 *hub, int state)
return 0;
}
-static int usb3503_switch_mode(struct usb3503 *hub, enum usb3503_mode mode)
+static int usb3503_connect(struct usb3503 *hub)
{
struct device *dev = hub-dev;
- int err = 0;
+ int err;
- switch (mode) {
- case USB3503_MODE_HUB:
- usb3503_reset(hub, 1);
+ usb3503_reset(hub, 1);
+ if (hub-regmap) {
/* SP_ILOCK: set connect_n, config_n for config */
err = regmap_write(hub-regmap, USB3503_SP_ILOCK,
- (USB3503_SPILOCK_CONNECT
+ (USB3503_SPILOCK_CONNECT
| USB3503_SPILOCK_CONFIG));
if (err 0) {
dev_err(dev, SP_ILOCK failed (%d)\n, err);
- goto err_hubmode;
+ return err;
}
/* PDS : Disable For Self Powered Operation */
@@ -103,7 +102,7 @@ static int usb3503_switch_mode(struct usb3503 *hub, enum
usb3503_mode mode)
hub-port_off_mask);
if (err 0) {
dev_err(dev, PDS failed (%d)\n, err);
- goto err_hubmode;
+ return err;
}
}
@@ -113,7 +112,7 @@ static int usb3503_switch_mode(struct usb3503 *hub, enum
usb3503_mode mode)
USB3503_SELF_BUS_PWR);
if (err 0) {
dev_err(dev, CFG1 failed (%d)\n, err);
- goto err_hubmode;
+ return err;
}
/* SP_LOCK: clear connect_n, config_n for hub connect */
@@ -122,14 +121,27 @@ static int usb3503_switch_mode(struct usb3503 *hub,
enum usb3503_mode mode)
| USB3503_SPILOCK_CONFIG), 0);
if (err 0) {
dev_err(dev, SP_ILOCK failed (%d)\n, err);
- goto err_hubmode;
+ return err;
}
+ }
- if (gpio_is_valid(hub-gpio_connect))
- gpio_set_value_cansleep(hub-gpio_connect, 1);
+ if (gpio_is_valid(hub-gpio_connect))
+ gpio_set_value_cansleep(hub-gpio_connect, 1);
- hub-mode = mode;
- dev_info(dev, switched to HUB mode\n);
+ hub-mode = USB3503_MODE_HUB;
+ dev_info(dev, switched to HUB mode\n);
+
+ return 0;
+}
+
+static int usb3503_switch_mode(struct usb3503 *hub, enum usb3503_mode mode)
+{
+ struct device *dev = hub-dev;
+ int err = 0;
+
+ switch (mode) {
+ case USB3503_MODE_HUB:
+ err = usb3503_connect(hub);
break;
case USB3503_MODE_STANDBY:
@@ -145,7 +157,6 @@ static int usb3503_switch_mode(struct usb3503 *hub, enum
usb3503_mode mode)
break;
}
-err_hubmode:
return err;
}
@@ -198,6 +209,9 @@ static int usb3503_probe(struct usb3503 *hub)
hub-mode = mode;
}
+
RE: [PATCH 3/3] staging: dwc2: add microframe scheduler from downstream Pi kernel
From: popcornmix [mailto:popcorn...@gmail.com] Sent: Monday, August 12, 2013 6:39 AM On Mon, Aug 12, 2013 at 8:40 AM, Matthijs Kooijman matth...@stdin.nl wrote: Paul, did you try the patch without this hunk? Dom, can you tell use why this hunk is needed? The microframe patch originally came from here: http://git.denx.de/?p=linux-denx.git;a=commit;h=661a47d4cec90545dce32926757ee0a95b9100d2 which should be acknowledged. I don't see the that hunk in this patch, or our implementation of it: https://github.com/raspberrypi/linux/commit/5cc98c1e75700e51e4a31d8a05b4a55a7d29648c Can you point at the raspberry pi commit it came from? Hi Greg, Is it necessary to also get signed-off-bys from whoever at Denx did the original work on the patch? Or can I just acknowledge that in the commit message? Hi Dom, Please use plain text when replying to messages that are CCed to any of the Linux mailing lists. They reject all emails that are not plain text. It look like the part of the patch in question came from an update to the Synopsys driver, and is not part of the microframe scheduler. So I will split that into a separate patch. And I will add an acknowledgement of denx.de in the commit message for the microframe scheduler patch, or try to get signed-off-bys if necessary. -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Fri, Aug 09, 2013 at 07:09:18PM +0300, Ivan T. Ivanov wrote:
Hi,
On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote:
Hi,
On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote:
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..e509abc
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,175 @@
+#undef CONFIG_REGULATOR
why ??
1. This shows that driver is still not fully tested
Regulators support is still missing in the MSM
2. Helps me to load driver successfully.
Then remove all the regulator-related code from this.
+ clk_prepare_enable(mdwc-core_clk);
+ clk_prepare_enable(mdwc-iface_clk);
+ clk_prepare_enable(mdwc-sleep_clk);
+ clk_prepare_enable(mdwc-utmi_clk);
do you really need to enable your clocks here ? Why don't you enable
them on runtime_resume and disable on runtime_suspend ?
I will like to make it working first and then will improve
power management.
alright, makes sense.
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tcsr = devm_ioremap_resource(pdev-dev, res);
+ if (!tcsr) {
+ dev_dbg(pdev-dev, tcsr ioremap failed\n);
no need to ioremap, also you're likely leaking clocks and regulators
enabled here.
Make sure to have something like:
if (!tcsr)
goto err_disable_clocks;
/* TODO This has to be revised */\
[...]
Sure.
just to make it clear, I meant to say that you don't need to print the
error message :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/3] staging: dwc2: add microframe scheduler from downstream Pi kernel
On Mon, Aug 12, 2013 at 06:18:00PM +, Paul Zimmerman wrote: From: popcornmix [mailto:popcorn...@gmail.com] Sent: Monday, August 12, 2013 6:39 AM On Mon, Aug 12, 2013 at 8:40 AM, Matthijs Kooijman matth...@stdin.nl wrote: Paul, did you try the patch without this hunk? Dom, can you tell use why this hunk is needed? The microframe patch originally came from here: http://git.denx.de/?p=linux-denx.git;a=commit;h=661a47d4cec90545dce32926757ee0a95b9100d2 which should be acknowledged. I don't see the that hunk in this patch, or our implementation of it: https://github.com/raspberrypi/linux/commit/5cc98c1e75700e51e4a31d8a05b4a55a7d29648c Can you point at the raspberry pi commit it came from? Hi Greg, Is it necessary to also get signed-off-bys from whoever at Denx did the original work on the patch? Or can I just acknowledge that in the commit message? You can acknowledge it, if there's no way to get a signed-off-by from them (and it looks like it will be hard.). 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: Commit 09fc7d22b0 (usb: musb: fix incorrect usage of resource pointer) questions
On Mon, Aug 12, 2013 at 12:35:25AM +0400, Sergei Shtylyov wrote: Hello. On 08/11/2013 03:08 AM, Sergei Shtylyov wrote: I have basically two questions on this change: [...] 2) why you omitted am35x.c from this commit? mistake Are you going to fix it, or should I? I'm just not sure how many resources there are with all these hwmod complications... tell me about it. Kishon was going to send a patch which would allocate and copy those resources dynamically based on pdev-num_resources. I haven't seen the patch yet. -- balbi signature.asc Description: Digital signature
Re: [RFC/PATCH 2/2] usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET
On Mon, 12 Aug 2013, Felipe Balbi wrote: maybe a single callback for supporting 'testmodes' ? which receives the test mode as argument ? I don't have a clear picture of how you would apply such an approach to this case. There would have to be a way to tell the HCD to insert a 15-second delay between the Setup and Data stages of a particular control URB. How would you do that? Whatever method you choose, each test is started after enumerating a known Vid/Pid pair. Based on that, you *know* which test to run. That's not what I meant. Yes, the test-device driver knows what test it wants to run, based on the VID/PID. I was asking how it would communicate this knowledge to the HCD. For example, it doesn't make sense to have a callback that means Insert a 15-second delay into the next URB that I submit, because the HCD doesn't know where URBs come from. What other test modes would you want to support? anything that USB[23]0CV supports today. There are even link layer tests for USB3 and a bunch of others. This SINGLE_STEP_SET_FEATURE is but one of a large(-ish) test suite which needs to be supported. That's what I'm trying to find out. What are the special features that we would need to implement in order to support the entire test suite? Is it worth adding this support to the standard host controller drivers, or should there be a special version (a Kconfig option like CONFIG_RCU_TORTURE_TEST) to enable it? Putting a lot of testing code in distribution kernels where it will never be used seems like a big waste. right, I think it should be hidden by Kconfig, not arguing against that. Therefore we both agree the $SUBJECT patch should not be accepted in its current form. At the very least, the new code in ehci-hcd should be conditional on a CONFIG_USB_HCD_TEST_MODE option. In addition, we may want some of the work (though at this point I'm not still clear on exactly what parts) to be moved into usbcore. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: musb: dsps: make it depend on OF_IRQ
musb_dsps.c utilizes a symbol which is only available when CONFIG_OF_IRQ is set, so make it depend on that. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/musb/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 04658d7..c64ee09a7 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -84,6 +84,7 @@ config USB_MUSB_AM35X config USB_MUSB_DSPS tristate TI DSPS platforms select USB_MUSB_AM335X_CHILD + depends on OF_IRQ config USB_MUSB_BLACKFIN tristate Blackfin -- 1.8.3.4.840.g6a90778 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Documentation sysfs-bus-usb: Document all files used by libusb
On Sat, Aug 03, 2013 at 04:37:51PM +0200, Hans de Goede wrote: Signed-off-by: Hans de Goede hdego...@redhat.com --- Documentation/ABI/testing/sysfs-bus-usb | 38 + 1 file changed, 38 insertions(+) This patch doesn't apply at all, can you redo it against the usb-next branch and resend? 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: EHCI: make ehci-w90X900 a separate driver
On Sat, Aug 10, 2013 at 01:04:33PM +0530, Manjunath Goudar wrote: Separate the W90X900(W90P910) on-chip host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before W90X900(W90P910) can be booted with a multi-platform kernel and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 USB: EHCI: prepare to make ehci-hcd a library module, we can avoid this problem by turning a bus glue into a separate module, as we do here for the w90X900 bus glue. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Signed-off-by: Deepak Saxena dsax...@linaro.org Acked-by: Arnd Bergmann a...@arndb.de Acked-by: Wan ZongShun mcuos@gmail.com Acked-by: Alan Stern st...@rowland.harvard.edu Cc: Greg KH g...@kroah.com Cc: linux-usb@vger.kernel.org Cc: linux-ker...@vger.kernel.org V2: -Arranged #include's in alphabetical order. -Replaced w90p910 by w90x900 because it is supports all series of w90x900. drivers/usb/host/Kconfig|2 +- drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-hcd.c |5 --- drivers/usb/host/ehci-w90x900.c | 85 --- 4 files changed, 37 insertions(+), 56 deletions(-) This patch fails to apply: checking file drivers/usb/host/Kconfig Hunk #1 succeeded at 236 with fuzz 1 (offset -8 lines). checking file drivers/usb/host/Makefile Hunk #1 FAILED at 35. 1 out of 1 hunk FAILED checking file drivers/usb/host/ehci-hcd.c Hunk #1 succeeded at 1246 (offset -3 lines). checking file drivers/usb/host/ehci-w90x900.c Hunk #2 FAILED at 114. 1 out of 3 hunks FAILED Please redo it against the latest usb-next branch and resend. 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: OHCI: make ohci-nxp a separate driver
On Sat, Aug 10, 2013 at 01:14:15PM +0530, Manjunath Goudar wrote:
Separate the OHCI NXP host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Many place function name and struct name started with usb,
current scenario replaced usb with ohci for proper naming.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Deepak Saxena dsax...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V2:
- Directive check NXP_PLATFORM_DRIVER block has been removed.
---
drivers/usb/host/Kconfig|8 +++
drivers/usb/host/Makefile |1 +
drivers/usb/host/ohci-hcd.c | 18 ---
drivers/usb/host/ohci-nxp.c | 124
+--
4 files changed, 58 insertions(+), 93 deletions(-)
Also failed to apply:
checking file drivers/usb/host/Kconfig
Hunk #1 FAILED at 398.
1 out of 1 hunk FAILED
checking file drivers/usb/host/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED
checking file drivers/usb/host/ohci-hcd.c
Hunk #1 succeeded at 1212 with fuzz 1 (offset 18 lines).
Hunk #2 succeeded at 1349 with fuzz 1 (offset 53 lines).
Hunk #3 FAILED at 1309.
Hunk #4 FAILED at 1357.
2 out of 4 hunks FAILED
checking file drivers/usb/host/ohci-nxp.c
{sigh}
That's why I required a senior Linaro developer to approve these
patches. You just wasted a bunch of my time, and it was obvious that no
one else actually tried these patches out, as they can't even be
applied!
Deepak, come on, you know better :(
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 v3] usb: rh_call_control tbuf potential future overflow fix
On Mon, Aug 12, 2013 at 11:09:25AM -0700, Sean O. Stalley wrote: rh_call_control() contains a buffer, tbuf, which it uses to hold USB descriptors. These discriptors are eventually copied into the transfer_buffer in the URB. The buffer in the URB is dynamically defined and is always large enough to hold the amount of data it requests. tbuf is currently statically allocated on the stack with a size of 15 bytes, regardless of the size specified in the URB. This patch dynamically allocates tbuf, and ensures that tbuf is at least as big as the buffer in the URB. If an hcd attempts to write a descriptor containing more than 15 bytes ( such as the Standard BOS Descriptor for hubs, defined in the USB3.0 Spec, section 10.13.1 ) the write would overflow the buffer and corrupt the stack. This patch addresses this behavior. Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Sean O. Stalley sean.stal...@intel.com --- drivers/usb/core/hcd.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) Applying this patch produces a complier warning that shows the patch is buggy: drivers/usb/core/hcd.c: In function ‘usb_hcd_submit_urb’: drivers/usb/core/hcd.c:704:7: warning: ‘tbuf’ may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/usb/core/hcd.c:474:7: note: ‘tbuf’ was declared here gcc is correct here, please fix this, and _never_ ignore complier warnings. 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: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 12:08:17PM -0600, Stephen Warren wrote: In a similar way, I wonder if the USB case can be considered the same way? This seems less like a good fit since I don't expect the resources are always so similar there, and also there's the case of the bus being potentially behind a few levels of USB hub. That won't work for the hub on Arndale in a system where it's fully wired up - it's got an I2C interface for control and the idea is that you bring it out of reset, write the configuration out via I2C and then you can complete startup using a GPIO or another I2C command. And of course it all gets a little more messy when you get board-specific logic that needs setup, rather than something more common across multiple devices. I think we could probably cover many cases by putting common things onto the bus but we still need to confront the cases where the device driver really does need to get involved in what's going on. Things like the SDIO WiFi cards seem very interchangable as you say and would probably benefit a lot but there's other applications that are less regular. signature.asc Description: Digital signature
Re: [RFC 0/2] USB port power off bug fixes
On Tue, Aug 06, 2013 at 01:16:50PM -0700, Sarah Sharp wrote: On Tue, Aug 06, 2013 at 02:48:57PM -0400, Alan Stern wrote: On Tue, 6 Aug 2013, Sarah Sharp wrote: On Tue, Aug 06, 2013 at 10:16:15AM -0400, Alan Stern wrote: Patch 1 has been rendered out of date by intervening changes (commit 4fae6f0fa86f in Greg's usb-next tree). Greg, could that be marked for stable? I'm not sure why it's in usb-next; it should really be in usb-linus, since it's a bug fix. The USB port power off mechanism doesn't work for suspended USB devices without it. That commit does not do exactly the same thing as your patch 1. It keeps the NO_POWER_OFF check in usb_port_suspend(), among other things. I didn't mean to imply that patch 1 was unnecessary, just that it was out of date and would cause a merge conflict when Greg tried to apply it to the current tree. Ah, ok. It sounds like we need both patches for stable, and I should rebase patch 1 against yours. I can either queue the rebased patch for usb-next and mention that it (and your patch) should be queued for stable, or Greg could revert yours from usb-next, move it to usb-linus, and I could send my patch to usb-linus. Greg, how do you want to handle this? I tried to cherry pick this patch from my usb-next branch to my usb-linus branch, but it fails :( So, could you port it, add a cc: stable line, and then resend these 3 for me to apply? Or pull, either is fine. 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: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote: On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote: On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote: I know there's been some discussion of this topic but do we have any general consensus on how to handle such things both from a Linux driver model point of view and from a DT/ACPI point of view? As these are usually bus-specific things, and really, platform-specific I don't think they're bus specific - the main issue with a lot of this is that they're outside the infrastructure that the bus standardises so we should have a general way of understanding this. There will be bits where the bus needs to get involved but the overall pattern is generic. The pattern is generic, yes, we've been dealing with that for well over a decade now (pci hotplug controllers are out of line and control when/if a PCI is device is added/removed.) I'd argue that each bus needs special logic to handle this, just like PCI hotplug did it with their hotplug controller logic. Due to the nature of this type of thing, it's all out-of-line hardware that is custom to each device type / bus. things, I'd fall back and just recommend a platform driver that knows about where these gpios are, and how/when to enable them, which will cause the discoverable bus logic to kick in now that it notices a device is present/removed. This doesn't work in general. These things aren't really platform specific at all, they're features of the devices that apply to any system using them and while for some use cases (like WiFi and BT power) an external thing that just manually applies power will be enough in other cases we want to know about the device even while it's off and the driver might be able to do extra things at runtime if it knows about for example having some control over signals to the device. No, the device isn't platform specific, but the logic needed to turn on/off is platform specific, otherwise the device would just work properly as the bus is self-discoverable. Much like rfkill is, as you point out. Those are all platform specific. For example in the Slimbus case we're normally talking about audio CODECs. In order to preserve the userspace API the device has to appear to be present at all times, the driver will remember the settings the user is making to be applied when it actually powers up and indeed the powering up should be kicked off as a result of userspac acting on the apparently present device. That's some horrible hardware, who thought of that? Another example here (including USB devices) is interrupt signals wired directly back to the processor, completely outside of the bus. Like rfkill switches that just power on/off a USB device built onto the laptop motherboard :) Perhaps a semi-generic platform driver could be created, that knows how to handle these settings in the DT, but odds are, that might be difficult to make generic enough to cover a wide range of boards, but without specifics, it's hard to tell. There's things like the rfkill stuff already, and the reset controller on the way, but again this only covers a fairly small subset of the issues. small subset? How common is this type of thing? 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: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET added to usb tree
On Mon, 12 Aug 2013 gre...@linuxfoundation.org wrote: This is a note to let you know that I've just added the patch titled usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. From 9841f37a1cca5357c1fd198b1068c12955aa632f Mon Sep 17 00:00:00 2001 From: Manu Gautam mgau...@codeaurora.org Date: Thu, 8 Aug 2013 16:49:24 -0700 Subject: usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET The USB Embedded High-speed Host Electrical Test (EHSET) defines the SINGLE_STEP_SET_FEATURE test as follows: 1) The host enumerates the test device with VID:0x1A0A, PID:0x0108 2) The host sends the SETUP stage of a GetDescriptor(Device) 3) The device ACKs the request 4) The host issues SOFs for 15 seconds allowing the test operator to raise the scope trigger just above the SOF voltage level 5) The host sends the IN packet 6) The device sends data in response, triggering the scope 7) The host sends an ACK in response to the data This patch adds additional handling to the EHCI hub driver and allows the EHSET driver to initiate this test mode by issuing a a SetFeature request to the root hub with a Test Selector value of 0x06. From there it mimics ehci_urb_enqueue() but separately submits QTDs for the SETUP and DATA/STATUS stages in order to insert a delay in between. Signed-off-by: Manu Gautam mgau...@codeaurora.org Acked-by: Alan Stern st...@rowland.harvard.edu [ja...@codeaurora.org: imported from commit c2084930 on codeaurora.org; minor cleanup and updated author email] Signed-off-by: Jack Pham ja...@codeaurora.org Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Okay, I was a little too late and Greg has merged the patch. Jack or Manu, can you write a follow-on patch that adds a Kconfig option to enable test modes in the HCDs, and then avoids compiling the new code added to ehci-hcd if the config option is disabled? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote: On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote: I don't think they're bus specific - the main issue with a lot of this is that they're outside the infrastructure that the bus standardises so we should have a general way of understanding this. There will be bits where the bus needs to get involved but the overall pattern is generic. The pattern is generic, yes, we've been dealing with that for well over a decade now (pci hotplug controllers are out of line and control when/if a PCI is device is added/removed.) I'd argue that each bus needs special logic to handle this, just like PCI hotplug did it with their hotplug controller logic. Due to the nature of this type of thing, it's all out-of-line hardware that is custom to each device type / bus. I agree that the bus will need some logic to handle this and I also think Stephen is right that there are going to be some common patterns for some device classes. However I do think that this is a common problem for pretty much all buses so we should be factoring out as much as possible from the buses so they only have to deal with their bit of things. Most of the stuff that's worrying me is not anything the bus should have any idea about beyond tunnelling the data to the device. This doesn't work in general. These things aren't really platform specific at all, they're features of the devices that apply to any system using them and while for some use cases (like WiFi and BT power) an external thing that just manually applies power will be enough in other cases we want to know about the device even while it's off and the driver might be able to do extra things at runtime if it knows about for example having some control over signals to the device. No, the device isn't platform specific, but the logic needed to turn on/off is platform specific, otherwise the device would just work properly as the bus is self-discoverable. Much like rfkill is, as you point out. Those are all platform specific. This is not just about power control - that's one of the simpler applications but you're talking about essentially anything that might be handled by platform data (or by the configuration SEPROMs on a freestanding device for that matter, why would you put down an extra part to configure the device when you can just load things from the AP). For example in the Slimbus case we're normally talking about audio CODECs. In order to preserve the userspace API the device has to appear to be present at all times, the driver will remember the settings the user is making to be applied when it actually powers up and indeed the powering up should be kicked off as a result of userspac acting on the apparently present device. That's some horrible hardware, who thought of that? It's actually pretty nice hardware in many regards; the bus is a bit underspecified for maximum bandwidth in modern systems but it gives you standardised multi-drop data streaming over two wires muxed with control which helps with the pin counts and with simplifying the system hardware design. The disappearing from the bus thing is because you're aiming to hit low power idle (but still functioning) states consuming very small numbers of microamps, even having a clock running is measurable. Perhaps a semi-generic platform driver could be created, that knows how to handle these settings in the DT, but odds are, that might be difficult to make generic enough to cover a wide range of boards, but without specifics, it's hard to tell. There's things like the rfkill stuff already, and the reset controller on the way, but again this only covers a fairly small subset of the issues. small subset? How common is this type of thing? Well, for Slimbus it's absolutely the norm, I've never seen a Slimbus device that didn't have a need for platform data. The small subset there is of the problems rather than the devices - you'll cover a large set of devices with a common helper like rfkill but trying to handle everything with that pattern doesn't seem like it'll work. signature.asc Description: Digital signature
[RFC 3/3] xhci: trace debug statements related to ring expansion
This patch defines a new trace event, which is called xhci_dbg_ring_expansion
and belongs to the event class xhci_log_msg, and adds tracepoints that trace
the debug messages associated with the expansion of endpoint ring when there
is not enough space allocated to hold all pending TRBs.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
---
drivers/usb/host/xhci-mem.c | 3 ++-
drivers/usb/host/xhci-ring.c | 4 ++--
drivers/usb/host/xhci-trace.h | 5 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ef27470..b150360 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -348,7 +348,8 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct
xhci_ring *ring,
return -ENOMEM;
xhci_link_rings(xhci, ring, first, last, num_segs);
- xhci_dbg(xhci, ring expansion succeed, now has %d segments\n,
+ xhci_dbg_trace(xhci, trace_xhci_dbg_ring_expansion,
+ ring expansion succeed, now has %d segments,
ring-num_segs);
return 0;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 3a2277b..a8f9e05 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2904,8 +2904,8 @@ static int prepare_ring(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
return -ENOMEM;
}
- xhci_dbg(xhci, ERROR no room on ep ring,
- try ring expansion\n);
+ xhci_dbg_trace(xhci, trace_xhci_dbg_ring_expansion,
+ ERROR no room on ep ring, try ring expansion);
num_trbs_needed = num_trbs - ep_ring-num_trbs_free;
if (xhci_ring_expansion(xhci, ep_ring, num_trbs_needed,
mem_flags)) {
diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
index 11025fe..20364cc 100644
--- a/drivers/usb/host/xhci-trace.h
+++ b/drivers/usb/host/xhci-trace.h
@@ -62,6 +62,11 @@ DEFINE_EVENT(xhci_log_msg, xhci_dbg_init,
TP_ARGS(vaf)
);
+DEFINE_EVENT(xhci_log_msg, xhci_dbg_ring_expansion,
+ TP_PROTO(struct va_format *vaf),
+ TP_ARGS(vaf)
+);
+
DECLARE_EVENT_CLASS(xhci_log_ctx,
TP_PROTO(struct xhci_hcd *xhci, struct xhci_container_ctx *ctx,
unsigned int ep_num),
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] staging: ozwpan: Increment port number for new device.
On Mon, Aug 05, 2013 at 06:40:13PM +0100, Rupesh Gujare wrote: This patch fixes crash issue when there is quick cycle of de-enumeration enumeration due to loss of wireless link. It is found that sometimes new device (or coming back device) returns very fast, even before USB core read out hub status, resulting in allocation of same port, which results in unstable system crash. Above issue is resolved by making sure that we always assign new port to new device, making sure that USB core reads correct hub status. Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com --- drivers/staging/ozwpan/ozhcd.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) No, don't paper over this, fix it correctly with reference counting as Dan has suggested. 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 v3] usb: rh_call_control tbuf potential future overflow fix
On Mon, Aug 12, 2013 at 11:16:24PM +, Stalley, Sean wrote: -Original Message- From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] Sent: Monday, August 12, 2013 1:32 PM To: Stalley, Sean Cc: linux-usb@vger.kernel.org; Sarah Sharp; Ismail, Abdul R; Alan Stern Subject: Re: [PATCH v3] usb: rh_call_control tbuf potential future overflow fix On Mon, Aug 12, 2013 at 11:09:25AM -0700, Sean O. Stalley wrote: rh_call_control() contains a buffer, tbuf, which it uses to hold USB descriptors. These discriptors are eventually copied into the transfer_buffer in the URB. The buffer in the URB is dynamically defined and is always large enough to hold the amount of data it requests. tbuf is currently statically allocated on the stack with a size of 15 bytes, regardless of the size specified in the URB. This patch dynamically allocates tbuf, and ensures that tbuf is at least as big as the buffer in the URB. If an hcd attempts to write a descriptor containing more than 15 bytes ( such as the Standard BOS Descriptor for hubs, defined in the USB3.0 Spec, section 10.13.1 ) the write would overflow the buffer and corrupt the stack. This patch addresses this behavior. Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Sean O. Stalley sean.stal...@intel.com --- drivers/usb/core/hcd.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) Applying this patch produces a complier warning that shows the patch is buggy: drivers/usb/core/hcd.c: In function ‘usb_hcd_submit_urb’: I should note that tbuf isn't in function 'usb_hcd_submit_urb', it is in the static function 'rh_call_control'. 'usb_hcd_submit_urb' calls 'rh_urb_enqueue', which calls 'rh_call_control' Odd, the joys of inline functions? Very strange, but the warning is still correct. drivers/usb/core/hcd.c:704:7: warning: ‘tbuf’ may be used uninitialized in this function [-Wmaybe-uninitialized] This line is kfree(tbuf); drivers/usb/core/hcd.c:474:7: note: ‘tbuf’ was declared here I do not see how tbuf could not be initialized by the time it gets to 'kfree'. Look closer... Unless 'kzalloc' fails, 'kzalloc' and 'kfree' are unconditional and sequential, so I'm not sure how you could get one without the other. All of the goto's in this function are below the 'kzalloc' and above 'kfree', so allocation (and release) cannot be jumped over. Look earlier in the function, you could jump to error, which would eventually call kfree(tbuf) with tbuf being undefined. gcc is correct here, please fix this, and _never_ ignore complier warnings. If I set tbuf to NULL when I declare it, the warning goes away. Is this an acceptable solution? Yes, that's the correct solution. 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: RTL8192CU module device HW:ID support
On Tue, Aug 13, 2013 at 01:50:55AM +0200, srenau...@free.fr wrote: Hello ! Is it possible to add the Hercules mini 300m v2 in the device list of rtl8192cu. The ID of this one is 0x06F8, 0xE035. Does the driver work with these new device ids? If so, great, can you send us a patch adding them? The instructions on how to do this are in the Documentation/SubmittingPatches file. 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: RTL8192CU module device HW:ID support
On Mon, Aug 12, 2013 at 8:50 PM, srenau...@free.fr wrote:
Hello !
Is it possible to add the Hercules mini 300m v2 in the device list of
rtl8192cu.
The ID of this one is 0x06F8, 0xE035.
Does this work for you?
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index 2bd5985..89da62c 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -300,6 +300,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
{RTL_USB_DEVICE(0x050d, 0x1102, rtl92cu_hal_cfg)}, /*Belkin - Edimax*/
{RTL_USB_DEVICE(0x050d, 0x11f2, rtl92cu_hal_cfg)}, /*Belkin - ISY*/
{RTL_USB_DEVICE(0x06f8, 0xe033, rtl92cu_hal_cfg)}, /*Hercules - Edimax*/
+ {RTL_USB_DEVICE(0x06f8, 0xe035, rtl92cu_hal_cfg)}, /*Hercules - Mini*/
{RTL_USB_DEVICE(0x07b8, 0x8188, rtl92cu_hal_cfg)}, /*Abocom - Abocom*/
{RTL_USB_DEVICE(0x07b8, 0x8189, rtl92cu_hal_cfg)}, /*Funai - Abocom*/
{RTL_USB_DEVICE(0x0846, 0x9041, rtl92cu_hal_cfg)}, /*NetGear WNA1000M*/
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Non-enumerable devices on USB and other enumerable buses
On Mon, 12 Aug 2013, Mark Brown wrote: On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote: On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote: I don't think they're bus specific - the main issue with a lot of this is that they're outside the infrastructure that the bus standardises so we should have a general way of understanding this. There will be bits where the bus needs to get involved but the overall pattern is generic. The pattern is generic, yes, we've been dealing with that for well over a decade now (pci hotplug controllers are out of line and control when/if a PCI is device is added/removed.) I'd argue that each bus needs special logic to handle this, just like PCI hotplug did it with their hotplug controller logic. Due to the nature of this type of thing, it's all out-of-line hardware that is custom to each device type / bus. I agree that the bus will need some logic to handle this and I also think Stephen is right that there are going to be some common patterns for some device classes. However I do think that this is a common problem for pretty much all buses so we should be factoring out as much as possible from the buses so they only have to deal with their bit of things. Most of the stuff that's worrying me is not anything the bus should have any idea about beyond tunnelling the data to the device. In theory, the matching of device IDs can be done in the driver core, provided the IDs are assigned based on the bus topology (as is the case for USB). But what should happen when there's a match? The bus code would need hooks installed wherever the platform wants to do something extra. This could end up growing to a lot of hooks. How can the whole thing be done in a reasonable fashion? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DWC3 role switch cause IRQ request failed
On Fri, Aug 09, 2013 at 03:16:20PM +, Wang, Yu Y wrote: On Fri, Aug 09, 2013 at 01:34:09PM +, Wang, Yu Y wrote: On Wed, Aug 07, 2013 at 12:03:34PM +, Wang, Yu Y wrote: Hi Balbi, Because dwc3 driver request_threaded_irq with flags IRQF_ONESHOT and IRQF_SHARED. But xHCI driver will not set IRQF_ONESHOT. Then will met IRQ request failed if use same IRQ number. 4[1.019248] Call Trace: 4[1.019270] [c18c9f0f] dump_stack+0x16/0x18 4[1.019292] [c18c723c] __schedule_bug+0x65/0x77 4[1.019313] [c18cf48d] __schedule+0x7ad/0x830 4[1.019335] [c18b8080] ? rest_init+0xc0/0xc0 4[1.019358] [c1204b02] ? printk_address+0x32/0x40 4[1.019380] [c1293ae0] ? __module_text_address+0x10/0x60 4[1.019402] [c12991fb] ? is_module_text_address+0x2b/0x50 4[1.019424] [c125707f] ? __kernel_text_address+0x4f/0x70 4[1.019444] [c18cf583] schedule+0x23/0x60 4[1.019466] [c18cc765] schedule_timeout+0x125/0x1f0 4[1.019488] [c18ce66b] ? wait_for_completion+0x2b/0xe0 4[1.019509] [c18ce6d8] ? wait_for_completion+0x98/0xe0 4[1.019530] [c18ce6df] wait_for_completion+0x9f/0xe0 4[1.019551] [c12699f0] ? try_to_wake_up+0x280/0x280 4[1.019572] [c1259fb1] kthread_stop+0x41/0x100 4[1.019595] [c12a8256] __setup_irq+0xd6/0x460 4[1.019617] [c1641520] ? dwc3_gadget_set_selfpowered+0x60/0x60 4[1.019639] [c12a8682] request_threaded_irq+0xa2/0x120 4[1.019660] [c16437f0] ? dwc3_gadget_reset_interrupt+0x1a0/0x1a0 4[1.019681] [c1642c54] dwc3_gadget_start+0x1a4/0x1f0 4[1.019703] [c166ff47] udc_bind_to_driver+0x57/0x100 4[1.019724] [c1670481] usb_gadget_probe_driver+0xa1/0xe0 4[1.019745] [c153c618] ? device_create_file+0x38/0xb0 4[1.019766] [c167142f] usb_composite_probe+0x6f/0x90 4[1.019788] [c1c762c5] init+0x147/0x19f 4[1.019809] [c1c7617e] ? acmmod_init+0xf/0xf 4[1.019829] [c12001aa] do_one_initcall+0xba/0x170 4[1.019853] [c1c3fb32] kernel_init_freeable+0x119/0x1b8 4[1.019875] [c1c3f4dc] ? do_early_param+0x7a/0x7a 4[1.019896] [c18b8090] kernel_init+0x10/0xd0 4[1.019917] [c18d17f7] ret_from_kernel_thread+0x1b/0x28 4[1.019937] [c18b8080] ? rest_init+0xc0/0xc0 3[1.020082] dwc3 dwc3.0.auto: failed to request irq #34 -- -16 This is one known issue or new issue? I have already removed IRQF_ONESHOT, it'll be on v3.12 [Yu:] Thanks balbi. Can you please share the patch link? http://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h= nextid=e8 adfc30ff9282a728fd8b666b6418308164c415 as usual, it's in my 'next' branch. you really need to fix your mailer btw, I got many copies of this same message. [Yu:] Thanks balbi. Don't know the reason. I send the email to you, and always get send failed response. So I tried more times. Sorry about that. BTW, Where can I find your git server link? I want to clone it to get latest code base. on git.kernel.org, in the link above, click on 'summary' and scroll down to the end of the page. [Yu:] Get it. Thanks. -- balbi -- 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
Bug 60738 - USB 3.0 connection delay seems to be too short for HP USB 3.0 hard drive
Hi, As requested by Greg Kroah, please see bug 60738 - Summary: USB 3.0 connection delay seems to be too short for HP USB 3.0 hard drive. I'll be pleased to help you as much as possible. -- Alexandre Demers -- 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: core: don't try to reset_device() a port that got just disconnected
On Tue, Aug 06, 2013 at 08:40:56PM -0700, Sarah Sharp wrote: On Tue, Aug 06, 2013 at 06:04:36AM +0800, Greg Kroah-Hartman wrote: On Mon, Aug 05, 2013 at 09:46:46AM -0700, Sarah Sharp wrote: I wanted to test it for a kernel release to make sure it didn't cause any issues before sending it off to stable. I'm sure it fixes Julius' issues on his Intel xHCI host, but I want to make sure it doesn't cause issues on other host controllers. Ok, so you will remember to send it to stable@ after a bit? Yes. It's in my todo list. No need to, I've picked it up now, 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: Regression: USB memory stick stalls and no longer automounts under 3.11-rc1
On Mon, Aug 05, 2013 at 09:07:51PM -0400, Alan Stern wrote: On Tue, 6 Aug 2013, Greg KH wrote: Have you tried this patch? http://marc.info/?l=linux-usbm=137523956310060w=2 What is the status of this patch, I'm starting to get lots of complaints about this :( James Bottomley has merged it into his Fixes branch, but I don't think he has sent it to Linus yet. It's now merged. 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
