usbserial_generic, idVendor=1a28, idProduct=6010
Hi, I have a device (thermal printer) which communicates through rs232. It has also usb adapter/converter build-in. root@emanuel-laptop:/home/emanuel# lsusb Bus 004 Device 004: ID 8086:0189 Intel Corp. Bus 004 Device 008: ID 1a28:6010 -- here Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 003: ID 0458:003a KYE Systems Corp. (Mouse Systems) NetScroll+ Mini Traveler / Genius NetScroll 120 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 05ca:181f Ricoh Co., Ltd Bus 001 Device 003: ID 138a:0011 Validity Sensors, Inc. VFS5011 Fingerprint Reader Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@emanuel-laptop:/home/emanuel# lsusb -d 1a28:6010 -v Bus 004 Device 008: ID 1a28:6010 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1a28 idProduct 0x6010 bcdDevice5.00 iManufacturer 4 (error) iProduct 14 (error) iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 55 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 90mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 14 (error) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 14 (error) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0001 Self Powered After 'modprobe usbserial vendor=0x1a28 product=0x6010' the device is working, /dev/ttyUSB0 pops out. I can read and write to /dev/ttyUSB0 and it responds. [34449.932999] usb 4-1.3: new full-speed USB device number 8 using ehci-pci [34450.029508] usb 4-1.3: string descriptor 0 read error: -32 [34450.029521] usb 4-1.3: New USB device found, idVendor=1a28, idProduct=6010 [34450.029526] usb 4-1.3: New USB device strings: Mfr=4, Product=14, SerialNumber=0 [34450.029927] usbserial_generic 4-1.3:1.0: The generic usb-serial driver is only for testing and one-off prototypes. [34450.029932] usbserial_generic 4-1.3:1.0: Tell linux-usb@vger.kernel.orgto add your device to a proper driver. [34450.029936] usbserial_generic 4-1.3:1.0: generic converter detected [34450.030331] usb 4-1.3: generic converter now attached to ttyUSB0 [34450.030410] usbserial_generic 4-1.3:1.1: The generic usb-serial driver is only for testing and
Re: some questions about bandwidth calculation
hi alan: 2014-02-14 23:36 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Fri, 14 Feb 2014, vichy wrote: hi Alan: I don't understand your question. At full speed (12 Mb/s), the time required to transfer 188 bytes is (188 bytes) * (8 bits/byte) / (12 b/us) = 125.33 us, which is greater than 125 us. @@ -1412,7 +1412,7 @@ sitd_slot_ok ( */ uf = uframe 7; if (!tt_available(ehci, period_uframes 3, - stream-udev, frame, uf, stream-tt_usecs)) + stream-udev, frame, uf, stream-usecs)) if so, shall we modify code like above? Use transfer time instead of bus budget to calculate tt_avaiable? No. stream-usecs is the time required on the high-speed bus, and stream-tt_usecs is the time required on the full/low-speed bus. tt_available makes its decisions based on whether there is enough available time on the full/low-speed bus. Therefore it needs to use stream-tt_usecs. it makes me a little confused. if we try to send 108 bytes to FS iso ep over HS hub. shouldn't we use below formula to calculate what bus time need for? NS_TO_US (think_time + usb_calc_bus_time ( dev-speed, is_input, 1, 108)); it seems no matter we transfer 108, 118, 140, even 188 bytes to FS iso ep over HS hub. The full/low bus time are all the same. appreciate your help -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
On Sun, 16 Feb 2014, vichy wrote: it makes me a little confused. if we try to send 108 bytes to FS iso ep over HS hub. shouldn't we use below formula to calculate what bus time need for? NS_TO_US (think_time + usb_calc_bus_time ( dev-speed, is_input, 1, 108)); That should have the maxpacket size, not 108. it seems no matter we transfer 108, 118, 140, even 188 bytes to FS iso ep over HS hub. The full/low bus time are all the same. That's right. The driver doesn't know how many bytes are going to be sent to the isochronous endpoint. All it knows is the maxpacket size. Therefore it has to assume that all packets will be the maximum size. See section 11.18.2 in the USB 2.0 spec: The host always uses the maximum data payload size for a full-/low-speed endpoint in doing its budgeting. 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 1/2] usb: host: remove USB_ARCH_HAS_?HCI
USB_ARCH_HAS_EHCI, USB_ARCH_HAS_OHCI, and USB_ARCH_HAS_XHCI were made obsolete in v3.11. They have not been used ever since. Setting them has no effect. They can safely be removed. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Tested with git grep. Note that the comment in this Kconfig file (that is also removed) suggests to first remove the select statements for these symbols and then the symbols themselves. But I think it makes more sense to first delete these three symbols and then remove the selects statements (as that is removing a second order effect). But it could just as well be done with just one patch, I'd say. drivers/usb/Kconfig | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 2e6b832..e0cad44 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -2,10 +2,6 @@ # USB device configuration # -# These are unused now, remove them once they are no longer selected -config USB_ARCH_HAS_OHCI - bool - config USB_OHCI_BIG_ENDIAN_DESC bool @@ -17,18 +13,12 @@ config USB_OHCI_LITTLE_ENDIAN default n if STB03xxx || PPC_MPC52xx default y -config USB_ARCH_HAS_EHCI - bool - config USB_EHCI_BIG_ENDIAN_MMIO bool config USB_EHCI_BIG_ENDIAN_DESC bool -config USB_ARCH_HAS_XHCI - bool - menuconfig USB_SUPPORT bool USB support depends on HAS_IOMEM -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: host: remove selects of USB_ARCH_HAS_?HCI
USB_ARCH_HAS_EHCI, USB_ARCH_HAS_OHCI, and USB_ARCH_HAS_XHCI were just removed. Selecting them is a nop. The select statements for these symbols can be removed too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Tested with git grep. Sending this as a few separate patches to the maintainers of the arches involved seemed inefficient. arch/arm/Kconfig | 3 --- arch/arm/mach-exynos/Kconfig | 1 - arch/arm/mach-omap2/Kconfig| 2 -- arch/arm/mach-shmobile/Kconfig | 4 arch/arm/mach-tegra/Kconfig| 1 - arch/mips/Kconfig | 7 --- arch/mips/ath79/Kconfig| 8 arch/mips/ralink/Kconfig | 6 -- arch/powerpc/platforms/44x/Kconfig | 1 - arch/powerpc/platforms/ps3/Kconfig | 2 -- arch/sh/Kconfig| 9 - 11 files changed, 44 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e254198..e607f08 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -534,7 +534,6 @@ config ARCH_DOVE select PINCTRL select PINCTRL_DOVE select PLAT_ORION_LEGACY - select USB_ARCH_HAS_EHCI help Support for the Marvell Dove SoC 88AP510 @@ -633,7 +632,6 @@ config ARCH_LPC32XX select GENERIC_CLOCKEVENTS select HAVE_IDE select HAVE_PWM - select USB_ARCH_HAS_OHCI select USE_OF help Support for the NXP LPC32XX family of processors @@ -770,7 +768,6 @@ config ARCH_S3C64XX select SAMSUNG_ATAGS select SAMSUNG_WAKEMASK select SAMSUNG_WDT_RESET - select USB_ARCH_HAS_OHCI help Samsung S3C64XX series based systems diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 4c414af..8d197dc 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -36,7 +36,6 @@ config ARCH_EXYNOS5 select HAVE_ARM_SCU if SMP select HAVE_SMP select PINCTRL - select USB_ARCH_HAS_XHCI help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb51eeb..9deaa92 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -21,7 +21,6 @@ config ARCH_OMAP3 select PM_OPP if PM select PM_RUNTIME if CPU_IDLE select SOC_HAS_OMAP2_SDRC - select USB_ARCH_HAS_EHCI if USB_SUPPORT config ARCH_OMAP4 bool TI OMAP4 @@ -42,7 +41,6 @@ config ARCH_OMAP4 select PL310_ERRATA_727915 select PM_OPP if PM select PM_RUNTIME if CPU_IDLE - select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_ERRATA_754322 select ARM_ERRATA_775420 diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index 3386406..bbdf684 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -102,8 +102,6 @@ config ARCH_R8A7778 select CPU_V7 select SH_CLK_CPG select ARM_GIC - select USB_ARCH_HAS_EHCI - select USB_ARCH_HAS_OHCI config ARCH_R8A7779 bool R-Car H1 (R8A77790) @@ -111,8 +109,6 @@ config ARCH_R8A7779 select ARM_GIC select CPU_V7 select SH_CLK_CPG - select USB_ARCH_HAS_EHCI - select USB_ARCH_HAS_OHCI select RENESAS_INTC_IRQPIN config ARCH_R8A7790 diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index b1232d8..4926bd1 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -19,7 +19,6 @@ config ARCH_TEGRA select RESET_CONTROLLER select SOC_BUS select SPARSE_IRQ - select USB_ARCH_HAS_EHCI if USB_SUPPORT select USB_ULPI if USB_PHY select USB_ULPI_VIEWPORT if USB_PHY select USE_OF diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index b3bf596..1f51db8 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -67,8 +67,6 @@ config MIPS_ALCHEMY select SYS_SUPPORTS_APM_EMULATION select ARCH_REQUIRE_GPIOLIB select SYS_SUPPORTS_ZBOOT - select USB_ARCH_HAS_OHCI - select USB_ARCH_HAS_EHCI config AR7 bool Texas Instruments AR7 @@ -360,7 +358,6 @@ config MIPS_SEAD3 select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_SMARTMIPS select SYS_SUPPORTS_MICROMIPS - select USB_ARCH_HAS_EHCI select USB_EHCI_BIG_ENDIAN_DESC select USB_EHCI_BIG_ENDIAN_MMIO select USE_OF @@ -718,8 +715,6 @@ config CAVIUM_OCTEON_SOC select SWAP_IO_SPACE select HW_HAS_PCI select ZONE_DMA32 - select USB_ARCH_HAS_OHCI - select USB_ARCH_HAS_EHCI select HOLES_IN_ZONE select ARCH_REQUIRE_GPIOLIB help @@ -756,8 +751,6 @@ config NLM_XLR_BOARD select ZONE_DMA32 if 64BIT select SYNC_R4K select SYS_HAS_EARLY_PRINTK - select USB_ARCH_HAS_OHCI if USB_SUPPORT - select USB_ARCH_HAS_EHCI
Re: [PATCH 1/2] usb: host: remove USB_ARCH_HAS_?HCI
On Sun, 16 Feb 2014, Paul Bolle wrote: USB_ARCH_HAS_EHCI, USB_ARCH_HAS_OHCI, and USB_ARCH_HAS_XHCI were made obsolete in v3.11. They have not been used ever since. Setting them has no effect. They can safely be removed. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Tested with git grep. Note that the comment in this Kconfig file (that is also removed) suggests to first remove the select statements for these symbols and then the symbols themselves. But I think it makes more sense to first delete these three symbols and then remove the selects statements (as that is removing a second order effect). But it could just as well be done with just one patch, I'd say. There's a simple reason for not getting rid of the symbols first. Doing it that way, as you did, leaves a window in which it's possible to select a non-existent symbol. If that's not an error, it ought to be. Regardless, for both patches: Acked-by: Alan Stern st...@rowland.harvard.edu Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: remove USB_ARCH_HAS_?HCI
On Sun, 2014-02-16 at 15:02 -0500, Alan Stern wrote: On Sun, 16 Feb 2014, Paul Bolle wrote: Note that the comment in this Kconfig file (that is also removed) suggests to first remove the select statements for these symbols and then the symbols themselves. But I think it makes more sense to first delete these three symbols and then remove the selects statements (as that is removing a second order effect). But it could just as well be done with just one patch, I'd say. There's a simple reason for not getting rid of the symbols first. Doing it that way, as you did, leaves a window in which it's possible to select a non-existent symbol. If that's not an error, it ought to be. It is silently ignored. I've contemplated diving in the kconfig code to see whether doing that could be made to trigger an error or, perhaps better, a warning. I've not made up my mind yet. It's trivial to merge these two patches, though. So feel free to ask me to do that. Regardless, for both patches: Acked-by: Alan Stern st...@rowland.harvard.edu Thanks. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] usb: musb dsps updates
Hi, On Fri, Jan 17, 2014 at 10:22:34AM +0100, Markus Pargmann wrote: Hi, The two remaining patches from the previous series usb: musb bugfixes. In v4 I used the device name for the debugfs root dir and added a commit message to the second patch. Felipe, could you please have a look at this? Thanks, Markus Regards, Markus Markus Pargmann (2): usb: musb: dsps, debugfs files usb: musb: dsps, use devm_kzalloc drivers/usb/musb/musb_dsps.c | 58 +--- 1 file changed, 55 insertions(+), 3 deletions(-) -- 1.8.5.2 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] usb: dwc2/s3c-hsotg: Combine drivers into a single DRD
On Friday, February 14, 2014 6:44 PM, Robert Baldyga wrote:
On 02/13/2014 10:10 PM, dingu...@altera.com wrote:
From: Dinh Nguyen dingu...@altera.com
Hello,
This patch series combines the dwc2 host driver and the s3c-hsotg peripheral
driver into a single dual-roler driver similar to the dwc3.
Hi.
It looks like it doesn't work on Samsung platforms without device-tree
support.
Hi Robert Baldyga,
In order to test this patch, the current mainline kernel requires
additional patches to support device-tree. The following patches
are necessary.
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/179920.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/179921.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/179922.html
The last one should be modified for your machine.
Best regards,
Jingoo Han
Best regards
Robert Baldyga
Samsung RD Institute Poland
The patch series moves the s3c-hsotg files into the /dwc2 folder, so this is
the final location of the driver. When the driver is built as a kernel
module,
it will be dwc2.ko and dwc2_platform.ko.
patch 1/7 : Edit the defines in dwc2/hw.h so that the s3c-hsotg driver can
use
the defines in hw.h. So we can remove s3c-hsotg.h in a
subsequent
patch.
patch 2/7 : Moves the s3c-hsotg driver into /dwc2 folder. Building the
s3c-hsotg
driver will now be a Kconfig option under DWC2. Also replaces
the
s3c-hsotg.h header file for dwc2/hw.h.
patch 3/7 : Moves the s3c-hsotg data structure into a common place, core.h,
so
that final DRD can use it.
patch 4/7 : Add the gadget data structure to a common data structure,
dwc2_hsotg, which is the data structure that will encapsulate
host
and peripheral modes for the final DRD. The bulk for this patch
is edits the in s3c-hsotg.c to reference the new data structure.
patch 5/7 : Replaces the s3c_hostg_irq handler with the
dwc2_handle_common_intr
in dwc2. Updates the dwc2 IRQ routines to call the s3c-hsotg
gadget
functions for peripheral mode.
patch 6/7 : Update the Kconfig and Makefile to enable building of the single
DRD. At this stage the the driver is behaving as a dual-role
driver.
patch 7/7 : Decouple host/peripheral functionality when buildling the
driver in
host or peripheral mode only.
This patchset is based on 3.14-rc2. I have only tested on the SOCFPGA
platform
which has v2.93a of dual-role IP.
Thanks,
Dinh Nguyen (7):
usb: dwc2: Add defines to support the s3c-hsotg driver
usb: s3c-hsotg: Move s3c-hsotg into dwc2 folder
usb: s3c-hsotg: Move s3c-hsotg data structures
usb: dwc2: Add the s3c-hsotg data structures to main dwc2_hsotg data
structure
usb: dwc2: combine the dwc2 and s3c_hsotg to use a single IRQ handler
usb: dwc2: Enable the dwc2/s3c-hsotg to be a single dual-role driver
usb: dwc2: Split out the dwc2/sc3-hsotg driver mode's build
dependency
drivers/usb/dwc2/Kconfig | 28 +
drivers/usb/dwc2/Makefile| 17 +-
drivers/usb/dwc2/core.c |1 +
drivers/usb/dwc2/core.h | 225 +++-
drivers/usb/dwc2/core_intr.c | 108 +-
drivers/usb/dwc2/hcd.c |7 +-
drivers/usb/dwc2/hcd.h | 23 +-
drivers/usb/dwc2/hw.h| 23 +-
drivers/usb/dwc2/platform.c | 50 +-
drivers/usb/{gadget = dwc2}/s3c-hsotg.c | 1807
+++---
drivers/usb/gadget/Kconfig |7 -
drivers/usb/gadget/Makefile |1 -
drivers/usb/gadget/s3c-hsotg.h | 378 ---
13 files changed, 1128 insertions(+), 1547 deletions(-)
rename drivers/usb/{gadget = dwc2}/s3c-hsotg.c (57%)
delete mode 100644 drivers/usb/gadget/s3c-hsotg.h
---
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Paul Zimmerman pa...@synopsys.com
Cc: Felipe Balbi ba...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Matt Porter mpor...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Matthijs Kooijman matth...@stdin.nl
Cc: Jingoo Han jg1@samsung.com
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Robert Baldyga r.bald...@samsung.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Add documentation on writing an musb glue layer
Hello, Following a few patches already in tree that add support for the USB device controller of the Ingenic JZ4740 MIPS SoC, I documented the process of writing an MUSB glue layer. The JZ4740 MUSB controller offers a basic feature set, which makes the glue layer implementation more simple than most current glue layers in tree. The patch that comes as a follow-up of this message is an attempt to provide a step-by-step walk-through of the process of writing an MUSB glue layer. Changes since v1: - add a line in legal notice paragraph to refer to COPYING file in kernel source tree. I'm also adding linux-usb in Cc: to let people there know about this just in case it went under the radar before. Please review and let me know if there's something that need to be fixed in the document. Changes were rebased on top of Linus Torvalds' tree, with the documentation built and tested successfully. The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2: Linux 3.14-rc3 are available in the git repository at: git://git.seketeli.net/~apelete/linux.git writing-musb-glue-layer Apelete Seketeli (1): documentation: docbook: document process of writing an musb glue layer Documentation/DocBook/Makefile |3 +- Documentation/DocBook/writing_musb_glue_layer.tmpl | 873 2 files changed, 875 insertions(+), 1 deletion(-) create mode 100644 Documentation/DocBook/writing_musb_glue_layer.tmpl -- Apelete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] documentation: docbook: document process of writing an musb glue layer
Document the process of writing an musb glue layer by taking the Ingenic JZ4740 glue layer as an example, as it seems more simple than most glue layers due to the basic feature set of the JZ4740 USB device controller. Signed-off-by: Apelete Seketeli apel...@seketeli.net --- Documentation/DocBook/Makefile |3 +- Documentation/DocBook/writing_musb_glue_layer.tmpl | 873 2 files changed, 875 insertions(+), 1 deletion(-) create mode 100644 Documentation/DocBook/writing_musb_glue_layer.tmpl diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 0f9c6ff..0bf7370 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml + tracepoint.xml drm.xml media_api.xml \ + writing_musb_glue_layer.xml include $(srctree)/Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/writing_musb_glue_layer.tmpl b/Documentation/DocBook/writing_musb_glue_layer.tmpl new file mode 100644 index 000..837eca7 --- /dev/null +++ b/Documentation/DocBook/writing_musb_glue_layer.tmpl @@ -0,0 +1,873 @@ +?xml version=1.0 encoding=UTF-8? +!DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN + http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; [] + +book id=Writing-MUSB-Glue-Layer + bookinfo + titleWriting an MUSB Glue Layer/title + + authorgroup + author +firstnameApelete/firstname +surnameSeketeli/surname +affiliation + address + emailapelete at seketeli.net/email + /address +/affiliation + /author + /authorgroup + + copyright + year2014/year + holderApelete Seketeli/holder + /copyright + + legalnotice + para + This documentation is free software; you can redistribute it + and/or modify it under the terms of the GNU General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + /para + + para + This documentation is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the GNU General Public License for more details. + /para + + para + You should have received a copy of the GNU General Public License + along with this documentation; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA + /para + + para + For more details see the file COPYING in the Linux kernel source + tree. + /para + /legalnotice + /bookinfo + +toc/toc + + chapter id=introduction +titleIntroduction/title +para + The Linux MUSB subsystem is part of the larger Linux USB + subsystem. It provides support for embedded USB Device Controllers + (UDC) that do not use Universal Host Controller Interface (UHCI) + or Open Host Controller Interface (OHCI). +/para +para + Instead, these embedded UDC rely on the USB On-the-Go (OTG) + specification which they implement at least partially. The silicon + reference design used in most cases is the Multipoint USB + Highspeed Dual-Role Controller (MUSB HDRC) found in the Mentor + Graphics Inventra™ design. +/para +para + As a self-taught exercise I have written an MUSB glue layer for + the Ingenic JZ4740 SoC, modelled after the many MUSB glue layers + in the kernel source tree. This layer can be found at + drivers/usb/musb/jz4740.c. In this documentation I will walk + through the basics of the jz4740.c glue layer, explaining the + different pieces and what needs to be done in order to write your + own device glue layer. +/para + /chapter + + chapter id=linux-musb-basics +titleLinux MUSB Basics/title +para + To get started on the topic, please read USB On-the-Go Basics (see + Resources) which provides an introduction of USB OTG operation at + the hardware level. A couple of wiki pages by Texas Instruments + and Analog Devices also provide an overview of the Linux kernel + MUSB configuration, albeit focused on some specific devices + provided by these companies. Finally, getting acquainted with the + USB specification at USB home page may come in handy, with + practical instance provided through the Writing USB Device Drivers + documentation (again, see Resources). +/para +para + Linux USB stack is a layered architecture in which the MUSB + controller hardware sits at the lowest. The MUSB controller driver + abstract the MUSB
Re: [PATCH 0/7] usb: dwc2/s3c-hsotg: Combine drivers into a single DRD
On 02/16/2014 05:37 PM, Jingoo Han wrote: On Friday, February 14, 2014 6:44 PM, Robert Baldyga wrote: On 02/13/2014 10:10 PM, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com Hello, This patch series combines the dwc2 host driver and the s3c-hsotg peripheral driver into a single dual-roler driver similar to the dwc3. Hi. It looks like it doesn't work on Samsung platforms without device-tree support. Hi Robert Baldyga, In order to test this patch, the current mainline kernel requires additional patches to support device-tree. The following patches are necessary. DT is supposed to be an ABI (old DTs must work with newer SW), so you shouldn't/can't change the code in a way that requires changes to the DT, at least for features that are working and stable and already have sensible stable DT bindings. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: chipidea: imx: Fix probing HSIC ports
On Fri, Feb 14, 2014 at 04:53:36PM +0100, Rolf Evers-Fischer wrote: Dear Peter, I hope that I didn't make any mistake, because this is my first linux kernel patch. If you don't mind, I'll send it directly to you as an attachment (and not to the kernel mailing list). Please always feel free to send patch and questions to mail list, we have worked at open kernel source. For how to submit a patch: cumentation/SubmittingPatches If you are using git, it is easy to create a patch (git add, git submit) and format a patch (git format-patch), then you can use git send-email to send your patch. After upgrade to kernel 3.13 my colleague discovered that the HSIC ports of our IMX6 board (usbh2 and usbh3) were no longer available. I discovered that the 'devm_usb_get_phy_by_phandle()' returns an -ENODEV error, which causes that the 'ci_hdrc_imx_probe()' function will not be completely executed. This patch helps to probe the HSIC ports. Until now I didn't see any negative impact after applying this patch on my IMX6 board. Yes, your finding is correct, but your fix more like a temp workaround for current kernel version. In fact, we also need a **PHY** for usb driver no matter it exists physically or not. For HSIC controller, you can use usb_phy_gen_xceiv as virtual PHY, the driver is at: drivers/ usb/phy/phy-generic.c. At dts file, the hsic node has phandle to points to usb_phy_gen_xceiv. I have a work version for hsic at internal branch, I will keep you posted when I submit hsic enable patchset, of course, you can also send that with above changes. -- 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: HSIC on imx6
On Fri, Feb 14, 2014 at 01:59:56PM +0100, Christian Gmeiner wrote: Hi Peter. I am currently trying to get HSIC working on an imx6d based board. Some time ago I asked if somebody has some patches etc. and got this: http://www.spinics.net/lists/arm-kernel/msg303281.html I needed some other changes to get it booting without any oops. But I have some questions: * usbhc2/3 can only do HSCI. And I do not need any PHY for it. That means I need to change ci_hdrc_imx.c in order to work without a PHY. No, add generic phy node to dts, and points to it at hsic node. http://marc.info/?l=linux-usbm=139260274919538w=2 * Here are some logs: http://dpaste.com/hold/1617947/ It looks like EHCI takes over and does one port (the HSIC?). The problem seems now that the port never changes its status to connected, but I am 100% sure that there is a LAN9730 [1] connected to that usbhc. [1] http://www.microchip.com/wwwproducts/Devices.aspx?product=LAN9730 Yes, there is one ehci port, but never connected, so there is no bus reset interrupt, and no enumeration. It seems more and more guys are working at hsic controller, I will try to submit hsic support asap. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] usb: dwc2/s3c-hsotg: Combine drivers into a single DRD
On Monday, February 17, 2014 10:56 AM, Stephen Warren wrote:
On 02/16/2014 05:37 PM, Jingoo Han wrote:
On Friday, February 14, 2014 6:44 PM, Robert Baldyga wrote:
On 02/13/2014 10:10 PM, dingu...@altera.com wrote:
From: Dinh Nguyen dingu...@altera.com
Hello,
This patch series combines the dwc2 host driver and the s3c-hsotg
peripheral
driver into a single dual-roler driver similar to the dwc3.
Hi.
It looks like it doesn't work on Samsung platforms without device-tree
support.
Hi Robert Baldyga,
In order to test this patch, the current mainline kernel requires
additional patches to support device-tree. The following patches
are necessary.
DT is supposed to be an ABI (old DTs must work with newer SW), so you
shouldn't/can't change the code in a way that requires changes to the
DT, at least for features that are working and stable and already have
sensible stable DT bindings.
Right, we know it. We should keep DT bindings because these are
Supposed to be an ABI.
I didn't mean to change DT bindings that were already defined at
./Documentation/devicetree/bindings/usb/samsung-hsotg.txt and
./Documentation/devicetree/bindings/usb/samsung-usbphy.txt.
I just suggest that ARCH-DT support code is necessary for Exynos HSOTG
as below.
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -119,6 +119,15 @@
status = disabled;
};
+ hsotg at 1248 {
+ compatible = samsung,s3c6400-hsotg;
+ reg = 0x1248 0x2;
+ interrupts = 0 71 0;
+ clocks = clock 305;
+ clock-names = otg;
+ status = disabled;
+ };
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -114,6 +114,21 @@
interrupts = 2 4;
};
+ usbphy at 125B {
+ compatible = samsung,exynos4210-usb2phy;
+ reg = 0x125B 0x100;
+ clocks = clock 305;
+ clock-names = otg;
+ status = disabled;
+ ranges;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ usbphy-sys {
+ reg = 0x10020704 0x8;
+ };
+ };
Best regards,
Jingoo Han
--
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] u_ether: move receiving to RX workqueue
In order to reduce the interrupt times in the embedded system,
a receiving workqueue is introduced.
This modification also enhanced the overall throughput as the
benefits of reducing interrupt occurrence.
Signed-off-by: Clanlab (Taiwan) Linux Project clanlab.p...@gmail.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: David S. Miller da...@davemloft.net
Cc: Stephen Hemminger shemmin...@vyatta.com
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Oliver Neukum oli...@neukum.org
---
drivers/usb/gadget/u_ether.c | 111 +--
1 file changed, 76 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index b7d4f82..a96a8d9 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -72,6 +72,7 @@ struct eth_dev {
struct sk_buff_head *list);
struct work_struct work;
+ struct work_struct rx_work;
unsigned long todo;
#defineWORK_RX_MEMORY 0
@@ -81,6 +82,8 @@ struct eth_dev {
u8 dev_mac[ETH_ALEN];
};
+static struct workqueue_struct *gether_wq;
+
/*-*/
#define RX_EXTRA 20 /* bytes guarding against rx overflows */
@@ -253,18 +256,16 @@ enomem:
DBG(dev, rx submit -- %d\n, retval);
if (skb)
dev_kfree_skb_any(skb);
- spin_lock_irqsave(dev-req_lock, flags);
- list_add(req-list, dev-rx_reqs);
- spin_unlock_irqrestore(dev-req_lock, flags);
}
return retval;
}
static void rx_complete(struct usb_ep *ep, struct usb_request *req)
{
- struct sk_buff *skb = req-context, *skb2;
+ struct sk_buff *skb = req-context;
struct eth_dev *dev = ep-driver_data;
int status = req-status;
+ boolrx_queue = 0;
switch (status) {
@@ -288,30 +289,8 @@ static void rx_complete(struct usb_ep *ep, struct
usb_request *req)
} else {
skb_queue_tail(dev-rx_frames, skb);
}
- skb = NULL;
-
- skb2 = skb_dequeue(dev-rx_frames);
- while (skb2) {
- if (status 0
- || ETH_HLEN skb2-len
- || skb2-len VLAN_ETH_FRAME_LEN) {
- dev-net-stats.rx_errors++;
- dev-net-stats.rx_length_errors++;
- DBG(dev, rx length %d\n, skb2-len);
- dev_kfree_skb_any(skb2);
- goto next_frame;
- }
- skb2-protocol = eth_type_trans(skb2, dev-net);
- dev-net-stats.rx_packets++;
- dev-net-stats.rx_bytes += skb2-len;
-
- /* no buffer copies needed, unless hardware can't
-* use skb buffers.
-*/
- status = netif_rx(skb2);
-next_frame:
- skb2 = skb_dequeue(dev-rx_frames);
- }
+ if (!status)
+ rx_queue = 1;
break;
/* software-driven interface shutdown */
@@ -334,22 +313,20 @@ quiesce:
/* FALLTHROUGH */
default:
+ rx_queue = 1;
+ dev_kfree_skb_any(skb);
dev-net-stats.rx_errors++;
DBG(dev, rx status %d\n, status);
break;
}
- if (skb)
- dev_kfree_skb_any(skb);
- if (!netif_running(dev-net)) {
clean:
spin_lock(dev-req_lock);
list_add(req-list, dev-rx_reqs);
spin_unlock(dev-req_lock);
- req = NULL;
- }
- if (req)
- rx_submit(dev, req, GFP_ATOMIC);
+
+ if (rx_queue)
+ queue_work(gether_wq, dev-rx_work);
}
static int prealloc(struct list_head *list, struct usb_ep *ep, unsigned n)
@@ -414,16 +391,24 @@ static void rx_fill(struct eth_dev *dev, gfp_t gfp_flags)
{
struct usb_request *req;
unsigned long flags;
+ int rx_counts = 0;
/* fill unused rxq slots with some skb */
spin_lock_irqsave(dev-req_lock, flags);
while (!list_empty(dev-rx_reqs)) {
+
+ if (++rx_counts qlen(dev-gadget, dev-qmult))
+ break;
+
req = container_of(dev-rx_reqs.next,
struct usb_request, list);
list_del_init(req-list);
spin_unlock_irqrestore(dev-req_lock, flags);
if (rx_submit(dev, req, gfp_flags)
Re: HSIC on imx6
Hi Peter 2014-02-17 2:22 GMT+01:00 Peter Chen peter.c...@freescale.com: On Fri, Feb 14, 2014 at 01:59:56PM +0100, Christian Gmeiner wrote: Hi Peter. I am currently trying to get HSIC working on an imx6d based board. Some time ago I asked if somebody has some patches etc. and got this: http://www.spinics.net/lists/arm-kernel/msg303281.html I needed some other changes to get it booting without any oops. But I have some questions: * usbhc2/3 can only do HSCI. And I do not need any PHY for it. That means I need to change ci_hdrc_imx.c in order to work without a PHY. No, add generic phy node to dts, and points to it at hsic node. http://marc.info/?l=linux-usbm=139260274919538w=2 Okay, this sounds like a good plan - will try it. * Here are some logs: http://dpaste.com/hold/1617947/ It looks like EHCI takes over and does one port (the HSIC?). The problem seems now that the port never changes its status to connected, but I am 100% sure that there is a LAN9730 [1] connected to that usbhc. [1] http://www.microchip.com/wwwproducts/Devices.aspx?product=LAN9730 Yes, there is one ehci port, but never connected, so there is no bus reset interrupt, and no enumeration. How should this bus reset be done? It seems more and more guys are working at hsic controller, I will try to submit hsic support asap. If you have something working it would be really cool to get those patches. I am working some days on this topic but without much success and I am running out of time :/ greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner -- 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
