Re: [PATCH 0/9] usb: gadget/uvc: stability and usability fixes
Hi Laurent, On Sat, Jun 22, 2013 at 02:30:12AM +0200, Laurent Pinchart wrote: Hi Michael, On Tuesday 18 June 2013 17:12:53 Michael Grzeschik wrote: On Tue, Jun 04, 2013 at 05:08:19PM +0200, Michael Grzeschik wrote: Hi, this series is fixing some stability and usability issues found with the usb uvc-gadget. It's needed to make the device usable as an v4l2sink with gstreamer. Thanks, Michael Laurent Pinchart (1): usb: gadget/uvc: Fix error handling in uvc_queue_buffer() Michael Grzeschik (8): usb: gadget/uvc: cancel the video queue if buffers could not be enqueued usb: gadget/uvc: also handle v4l2 ioctl ENUM_FMT usb: gadget/uvc: free buffers after streamoff usb: gadget/uvc: Add monotonic time stamp flag usb: gadget/uvc: change KERN_INFO to KERN_DEBUG on request shutdown usb: gadget/uvc: set sizes in queue_setup to 0 when memorytype is USERPTR usb: gadget/uvc: fix S_FMT always assume sizeimage for MJPEG usb: gadget/uvc: add uvc suspend resume functions drivers/usb/gadget/f_uvc.c | 17 + drivers/usb/gadget/uvc_queue.c | 9 +++-- drivers/usb/gadget/uvc_v4l2.c | 33 +++-- drivers/usb/gadget/uvc_video.c | 5 - 4 files changed, 59 insertions(+), 5 deletions(-) Ping! Did you find time to look into that series? I'll try to review it on Sunday. This is just a short ping to let you know that it's Sunday again! ;-) Thanks, Michael -- 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] Memory mapping for USBFS
On Sun, Sep 29, 2013 at 5:10 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 29 Sep 2013, Markus Rechberger wrote: to follow up I know why it doesn't happen anymore because customers are using a kernel module which does optimized transfers and pre-allocated the URBs and transfer buffer in kernelspace, the interface just copies the datastream to our actual driver which sits in userspace. Goal is to get rid of that kernel module which is working around that allocation bug. Allan, Greg, can we add another IOCTL for telling USBFS to not use SG transfers (it also allocates 15k buffers and will lead to the same problem)? The old behavior was already broke, the SG transfers won't improve the situation in that case either. Then how will not using SG make the situation any better? You'll just be back with the old, broken behavior. I was moreover writing about mmap vs SG transfers. Basically at the moment on lower end systems SG transfers will introduce more problems than before. I guess the ioctl would not be required, I'd just allocate the memory (transfer_buffer) on driver start up, and once mmap'ed buffers are passed to the ioctl it should bypass the SG transfers. By experience I can say that on driver startup and early driver runtime I've never seen any allocation failures it only happens during runtime after some time on low end systems. There have been such discussions on regular kernel drivers too to allocate memory during boot up vs during runtime in the past. I think there was some time where 15k buffers were allowed and non SG. The experience with the chipset which stops to transfer data on latency issues made me sensitive about any change in that area. Original behavior: (Linux 2.6.32 and a few newer ones) don't allow 15k buffers (this behavior breaks at least the chipset which has those latency issues when transferring 6mb/sec only on Broadcom Chipsets). Second stage: allow 15k buffers (Linux 3.5 at least) (by increasing the transfer buffer to 50k it fixes the latency issue, the test was running for several days) Those broadcom chipsets have 1.3ghz 1GB Ram. Third stage: add SG transfers and split everything back to 15k buffers (behavior is unknown at the moment, only the STB manufacturer can provide the new kernel so I can't even test anything here the issue only came up with those Broadcom Chipsets). Those Sheevaplugs have 128mb memory, regular routers and NAS systems don't necessarily have more either. If you're trying to do big I/O transfers with large buffers in a highly memory constrained system, you're already in trouble. Fiddling around with the kernel won't help. sure, but using the kernel module which also pre-allocates the memory has no problem at all. I searched with google, obviously no one is using USBFS/userspace USB drivers that intensive as we do because (streaming 6mb for DVB or 20mb for Analog over days) the only bug reports that come up are related to our devices and point to our forum. In fact, you might find the best answer is to do lots of small transfers (i.e., 8 KB or even 4 KB). I agree, but here not only small buffers are the problem, also latency. I will send another patch version which overrides the SG transfer once a preallocated buffer is submitted. The current patch will only use the pre-allocated buffers if the buffer size is smaller than 15-16k. Markus -- 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] Memory mapping for USBFS
On Sun, Sep 29, 2013 at 7:51 PM, Markus Rechberger mrechber...@gmail.com wrote: I agree, but here not only small buffers are the problem, also latency. I will send another patch version which overrides the SG transfer once a preallocated buffer is submitted. The current patch will only use the pre-allocated buffers if the buffer size is smaller than 15-16k. If you put much attention to performance latency, I am wondering why you don't write a kernel mode usb driver to fix your problem? With usbfs and user mode driver, both performance and latency won't be very good: - URB can only be submitted in process context with context switch cost - URB complete is notified by signal, which might introduce much latency With one kernel mode driver, you can get better performance/latency much easily. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Memory mapping for USBFS
On Sun, Sep 29, 2013 at 2:07 PM, Ming Lei tom.leim...@gmail.com wrote: On Sun, Sep 29, 2013 at 7:51 PM, Markus Rechberger mrechber...@gmail.com wrote: I agree, but here not only small buffers are the problem, also latency. I will send another patch version which overrides the SG transfer once a preallocated buffer is submitted. The current patch will only use the pre-allocated buffers if the buffer size is smaller than 15-16k. If you put much attention to performance latency, I am wondering why you don't write a kernel mode usb driver to fix your problem? With usbfs and user mode driver, both performance and latency won't be very good: Userspace drivers work with all systems from Linux 2.6.15 on in our case. One driver for all. USBFS has been designed to write such drivers, and we are using it. - URB can only be submitted in process context with context switch cost - URB complete is notified by signal, which might introduce much latency With one kernel mode driver, you can get better performance/latency much easily. nearly all embedded systems are usually shipped without third party kernel modules and in some cases they don't even provide the kernel source (additionally said I do not want to provide kernel drivers for each system it's a big waste of time, not even thinking about the time trying to get the kernel sources for a system). We have our glue module which we could ship but once a manufacturer decides to update their system the game starts again the driver would not load (they do not ship any modules which do not belong to their system). The current problems are maybe less than 0.1% on our side but we also want to have them fixed. Markus Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Memory mapping for USBFS
On Sun, Sep 29, 2013 at 8:18 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sun, Sep 29, 2013 at 2:07 PM, Ming Lei tom.leim...@gmail.com wrote: On Sun, Sep 29, 2013 at 7:51 PM, Markus Rechberger mrechber...@gmail.com wrote: I agree, but here not only small buffers are the problem, also latency. I will send another patch version which overrides the SG transfer once a preallocated buffer is submitted. The current patch will only use the pre-allocated buffers if the buffer size is smaller than 15-16k. If you put much attention to performance latency, I am wondering why you don't write a kernel mode usb driver to fix your problem? With usbfs and user mode driver, both performance and latency won't be very good: Userspace drivers work with all systems from Linux 2.6.15 on in our case. One driver for all. USBFS has been designed to write such drivers, and we are using it. If it does work from 2.6.15 on, why do you post the patch now? Is there any recent change which breaks your driver? - URB can only be submitted in process context with context switch cost - URB complete is notified by signal, which might introduce much latency With one kernel mode driver, you can get better performance/latency much easily. nearly all embedded systems are usually shipped without third party kernel modules and in some cases they don't even provide the kernel source (additionally said I do not want to provide kernel drivers for each system it's a big waste of time, not even thinking about the time trying to get the kernel sources for a system). You can submit patch and ask to merge the driver into kernel tree. We have our glue module which we could ship but once a manufacturer decides to update their system the game starts again the driver would not load (they do not ship any modules which do not belong to their system). The current problems are maybe less than 0.1% on our side but we also want to have them fixed. I mean with usbfs and user space driver, you can't expect very good performance and latency. I didn't review your patch in detail, but looks your patch doesn't handle cache problem, for example, user space may write data to mmap area, but the data may stay in cache and don't reach memory, so it might be be transferred to device mistakenly. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] memory mapping for usbfs (v0.4)
This patch adds memory mapping support to USBFS for isochronous and bulk
data transfers, it allows to pre-allocate usb transfer buffers.
The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook
The CPU usage decreases 6-8% on an Intel Atom n270 when
transferring 20mbyte/sec (isochronous), it should be more interesting to
see those
statistics on embedded systems where copying data is more expensive.
Usage from userspace:
allocation:
rv = ioctl(priv-usbfd, USBDEVFS_ALLOC_MEMORY, mem);
if (rv == 0)
buffer = mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_SHARED, priv-usbfd, mem.offset);
use the mapped buffer with urb-buffer.
release:
rv = munmap(buffer, size);
memset(mem, 0x0, sizeof(struct usbdevfs_memory));
mem.buffer = buffer;
rv = ioctl(priv-usbfd, USBDEVFS_RELEASE_MEMORY, mem);
non freed memory buffers are collected and will be released when closing
the node.
I tested this patch with Bulk and Isochronous, with and without memory
mapping (applications which don't use mmap will just fall back to the
legacy mechanism).
Version 0.3:
* Removed comment
* Renamed USBDEVFS_FREE_MEMORY to USBDEVFS_RELEASE_MEMORY
* Clearing allocated memory
Version 0.4:
* overriding SG transfers once memory mapped buffers are allocated for
BULK
* adding pgprot_noncached to ensure that the IO memory is not cached
(thanks to Ming Lei for mentioning that)
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Markus Rechberger patc...@sundtek.com
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 737e3c1..a32fb70 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -69,6 +69,7 @@ struct dev_state {
spinlock_t lock;/* protects the async urb lists */
struct list_head async_pending;
struct list_head async_completed;
+ struct list_head memory_list;
wait_queue_head_t wait; /* wake up if a request completed */
unsigned int discsignr;
struct pid *disc_pid;
@@ -96,6 +97,16 @@ struct async {
u8 bulk_status;
};
+struct usb_memory {
+ struct list_head memlist;
+ int vma_use_count;
+ int usb_use_count;
+ u32 offset;
+ u32 size;
+ void *mem;
+ unsigned long vm_start;
+};
+
static bool usbfs_snoop;
module_param(usbfs_snoop, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(usbfs_snoop, true to log all usbfs traffic);
@@ -288,6 +299,9 @@ static struct async *alloc_async(unsigned int numisoframes)
static void free_async(struct async *as)
{
+ struct usb_memory *usbm = NULL, *usbm_iter;
+ unsigned long flags;
+ struct dev_state *ps = as-ps;
int i;
put_pid(as-pid);
@@ -297,8 +311,22 @@ static void free_async(struct async *as)
if (sg_page(as-urb-sg[i]))
kfree(sg_virt(as-urb-sg[i]));
}
+
+ spin_lock_irqsave(ps-lock, flags);
+ list_for_each_entry(usbm_iter, ps-memory_list, memlist) {
+ if (usbm_iter-mem == as-urb-transfer_buffer) {
+ usbm = usbm_iter;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(ps-lock, flags);
+
kfree(as-urb-sg);
- kfree(as-urb-transfer_buffer);
+ if (usbm == NULL)
+ kfree(as-urb-transfer_buffer);
+ else
+ usbm-usb_use_count--;
+
kfree(as-urb-setup_packet);
usb_free_urb(as-urb);
usbfs_decrease_memory_usage(as-mem_usage);
@@ -811,6 +839,7 @@ static int usbdev_open(struct inode *inode, struct file
*file)
INIT_LIST_HEAD(ps-list);
INIT_LIST_HEAD(ps-async_pending);
INIT_LIST_HEAD(ps-async_completed);
+ INIT_LIST_HEAD(ps-memory_list);
init_waitqueue_head(ps-wait);
ps-discsignr = 0;
ps-disc_pid = get_pid(task_pid(current));
@@ -839,6 +868,8 @@ static int usbdev_release(struct inode *inode, struct file
*file)
struct dev_state *ps = file-private_data;
struct usb_device *dev = ps-dev;
unsigned int ifnum;
+ struct list_head *p, *q;
+ struct usb_memory *tmp;
struct async *as;
usb_lock_device(dev);
@@ -863,6 +894,14 @@ static int usbdev_release(struct inode *inode, struct file
*file)
free_async(as);
as = async_getcompleted(ps);
}
+
+ list_for_each_safe(p, q, ps-memory_list) {
+ tmp = list_entry(p, struct usb_memory, memlist);
+ list_del(p);
+ if (tmp-mem)
+ free_pages_exact(tmp-mem, tmp-size);
+ kfree(tmp);
+ }
kfree(ps);
return 0;
}
@@ -1173,6 +1212,7 @@ static int proc_do_submiturb(struct dev_state *ps, struct
usbdevfs_urb *uurb,
struct usb_host_endpoint *ep;
struct async *as = NULL;
struct usb_ctrlrequest *dr = NULL;
+ struct usb_memory *usbm
Re: [PATCH] memory mapping for usbfs (v0.4)
On Sun, Sep 29, 2013 at 10:02 PM, Markus Rechberger mrechber...@gmail.com wrote: This patch adds memory mapping support to USBFS for isochronous and bulk data transfers, it allows to pre-allocate usb transfer buffers. The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook The CPU usage decreases 6-8% on an Intel Atom n270 when transferring 20mbyte/sec (isochronous), it should be more interesting to see those statistics on embedded systems where copying data is more expensive. X86 platform should be memory coherent, which means uncached mapping might not affect memory access performance from CPU, so you might need provide performance data on other non-coherent ARCH. Usage from userspace: allocation: rv = ioctl(priv-usbfd, USBDEVFS_ALLOC_MEMORY, mem); if (rv == 0) buffer = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, priv-usbfd, mem.offset); use the mapped buffer with urb-buffer. release: rv = munmap(buffer, size); memset(mem, 0x0, sizeof(struct usbdevfs_memory)); mem.buffer = buffer; rv = ioctl(priv-usbfd, USBDEVFS_RELEASE_MEMORY, mem); non freed memory buffers are collected and will be released when closing the node. I tested this patch with Bulk and Isochronous, with and without memory mapping (applications which don't use mmap will just fall back to the legacy mechanism). Version 0.3: * Removed comment * Renamed USBDEVFS_FREE_MEMORY to USBDEVFS_RELEASE_MEMORY * Clearing allocated memory Version 0.4: * overriding SG transfers once memory mapped buffers are allocated for BULK Why do you want to override SG transfer? * adding pgprot_noncached to ensure that the IO memory is not cached Accessing non-cached mapping on some ARCHs is extremely slow, so I an wondering if it is good way to map the area as non-cached. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Le 26/09/2013 17:59, Christoph Fritz a écrit : Their software fix: As first attemp at fixing this issue, one may try to switch LINK to ULPI mode before configuring MUX and pads for USB operation. Fear is that this could cause unexpected transfer from PHY to LINK, somehow preventing proper initialization I'll try that here with the smsc3340-phy. What a mess, it is also important in what order the muxing of USB-Pins is done beside the fact that some USBOTG pins had a GPIO_OUT configured wrongly. Don't ask how I hit this, but with that and the info from above finally both smsc3340 phys on OTG and USBH2 get detected: pure *voodooo*! @Sascha in arch/arm/mach-imx/include/mach/iomux-mx27.h why were the USBOTG pins configured with GPIO_OUT all along? :-) -- Christoph -- 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] memory mapping for usbfs (v0.4)
On Sun, Sep 29, 2013 at 04:02:56PM +0200, Markus Rechberger wrote: This patch adds memory mapping support to USBFS for isochronous and bulk data transfers, it allows to pre-allocate usb transfer buffers. The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook The CPU usage decreases 6-8% on an Intel Atom n270 when transferring 20mbyte/sec (isochronous), it should be more interesting to see those statistics on embedded systems where copying data is more expensive. Do you have a userspace test program that we can use to verify that this does work, and that others can use to run on some different platforms to verify that this is actually faster? 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: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Sun, Sep 29, 2013 at 11:32 AM, Christoph Fritz chf.fr...@googlemail.com wrote: Le 26/09/2013 17:59, Christoph Fritz a écrit : Their software fix: As first attemp at fixing this issue, one may try to switch LINK to ULPI mode before configuring MUX and pads for USB operation. Fear is that this could cause unexpected transfer from PHY to LINK, somehow preventing proper initialization I'll try that here with the smsc3340-phy. What a mess, it is also important in what order the muxing of USB-Pins is done beside the fact that some USBOTG pins had a GPIO_OUT configured wrongly. Don't ask how I hit this, but with that and the info from above finally both smsc3340 phys on OTG and USBH2 get detected: pure Can you show a patch or code so that others could fix this problem as well? Regards, Fabio Estevam -- 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] Memory mapping for USBFS
On Sun, Sep 29, 2013 at 01:51:58PM +0200, Markus Rechberger wrote: I searched with google, obviously no one is using USBFS/userspace USB drivers that intensive as we do because (streaming 6mb for DVB or 20mb for Analog over days) the only bug reports that come up are related to our devices and point to our forum. Not true at all, I know of at least one company, and odds are there are many others, that have been doing this type of thing since the 2.2 kernel days, in their embedded systems for the military. They do it all in userspace, for vision systems, using usbfs. So you aren't alone at all, just the only ones with reported problems :) 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: EHCI bus glue driver works for storage, fails for a WiFi module
On 09/28/2013 09:57 PM, Alan Stern wrote:
On Sun, 29 Sep 2013, Arokux X wrote:
What happens if you back-port your glue driver to the vendor's kernel?
I have now 200 lines of code which are (almost) identical. They work
in vendor's kernel and fail in mainline.
This indicates that the problem isn't in your glue driver, but is
somewhere else in the kernel.
This isn't surprising. The errors you are getting are hardware errors,
not protocol errors. They could be caused by excessive noise in the
USB data lines. Or there could be some sort of timing issue.
I've noticed there is ehci-timer.c now. It wasn't present at 3.4
times. The main clock of the SoC I'm working on is running at 24Mhz.
There are no hstimers implemented. Do you think it can be the problem?
I tend to doubt it. In the traces you posted, almost every transfer
worked. Only a few of them got errors. If timers were a problem then
none of the transfers would have worked.
A have tested several other USB devices: keyboard and Ethernet
adapter. They worked. I'm not sure whether these test are clean
since I connect them to the USB ports which are behind on-board 4-port
USB hub. The hub is connected to the first USB host controller. The
wifi module however is connected to the second USB host controller
directly.
Do you have any ideas how can I troubleshoot this issue further? Is
there any chance of regression in EHCI stack?
There's always a chance of a regression.
Can you try connecting the WiFi module to a regular PC? Maybe that
will provide some new ideas.
In your traces, the working case had about 200 us between each URB
completion and the following submission, whereas the non-working case
had much less time -- around 20 us. Maybe in the new kernel, the bulk
transfers occur too rapidly for the WiFi module to handle.
Or maybe the problem lies in the EHCI hardware. Have you checked for
errata?
On PCs, the driver has some problems with stability of the radio connections,
and I am currently working on that problem; however, there are no difficulties
in communicating over the USB system.
One problem that was recently discovered on ARM architecture is that the private
area at the end of the main structure was not aligned. The fix has been added to
the wireless-testing tree as commit 60ce314d1750fef. It is on its way to
mainline, but is not there yet. Fortunately, it is a one-liner as follows:
diff --git a/drivers/net/wireless/rtlwifi/wifi.h
b/drivers/net/wireless/rtlwifi/wifi.h
index cc03e7c..7032587 100644
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -2057,7 +2057,7 @@ struct rtl_priv {
that it points to the data allocated
beyond this structure like:
rtl_pci_priv or rtl_usb_priv */
- u8 priv[0];
+ u8 priv[0] __aligned(sizeof(void *));
};
#define rtl_priv(hw) (((struct rtl_priv *)(hw)-priv))
The patch is line-wrapped, and probably has its white space mangled by this
route of transmission, but it is easily applied manually.
My suspicion is that this fix is not your problem, but I know of no other driver
problems that might affect your SoC.
Larry
--
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: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Sun, 2013-09-29 at 12:19 -0300, Fabio Estevam wrote:
On Sun, Sep 29, 2013 at 11:32 AM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Le 26/09/2013 17:59, Christoph Fritz a écrit :
Their software fix:
As first attemp at fixing this issue, one may try to switch LINK to
ULPI mode before configuring MUX and pads for USB operation. Fear is
that this could cause unexpected transfer from PHY to LINK, somehow
preventing proper initialization
I'll try that here with the smsc3340-phy.
What a mess, it is also important in what order the muxing of USB-Pins
is done beside the fact that some USBOTG pins had a GPIO_OUT configured
wrongly. Don't ask how I hit this, but with that and the info from above
finally both smsc3340 phys on OTG and USBH2 get detected: pure
Can you show a patch or code so that others could fix this problem as well?
Sure, attached to this mail are 4 of my work-in-progress patches, two
for barebox and two for the kernel. Consider them RFC. The ULPI-mode
switching before muxing is already part of barebox.
Thanks
-- Christoph
From a5f16b4cee15ea239d90bc4c18db3d9628afecec Mon Sep 17 00:00:00 2001
From: Christoph Fritz chf.fr...@googlemail.com
Date: Sat, 28 Sep 2013 12:41:30 +0200
Subject: [PATCH 2/2] i.MX27: fix USBOTG muxing
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/mach-imx/include/mach/iomux-mx27.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-imx/include/mach/iomux-mx27.h b/arch/arm/mach-imx/include/mach/iomux-mx27.h
index 23e448b..6ff8651 100644
--- a/arch/arm/mach-imx/include/mach/iomux-mx27.h
+++ b/arch/arm/mach-imx/include/mach/iomux-mx27.h
@@ -38,13 +38,13 @@
#define PB25_PF_USBH1_RCV (GPIO_PORTB | GPIO_PF | 25)
#define PC5_PF_I2C2_SDA (GPIO_PORTC | GPIO_PF | GPIO_IN | 5)
#define PC6_PF_I2C2_SCL (GPIO_PORTC | GPIO_PF | GPIO_IN | 6)
-#define PC7_PF_USBOTG_DATA5 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 7)
-#define PC8_PF_USBOTG_DATA6 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 8)
-#define PC9_PF_USBOTG_DATA0 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 9)
-#define PC10_PF_USBOTG_DATA2 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 10)
-#define PC11_PF_USBOTG_DATA1 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 11)
-#define PC12_PF_USBOTG_DATA4 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 12)
-#define PC13_PF_USBOTG_DATA3 (GPIO_PORTC | GPIO_PF | GPIO_OUT | 13)
+#define PC7_PF_USBOTG_DATA5 (GPIO_PORTC | GPIO_PF | 7)
+#define PC8_PF_USBOTG_DATA6 (GPIO_PORTC | GPIO_PF | 8)
+#define PC9_PF_USBOTG_DATA0 (GPIO_PORTC | GPIO_PF | 9)
+#define PC10_PF_USBOTG_DATA2 (GPIO_PORTC | GPIO_PF | 10)
+#define PC11_PF_USBOTG_DATA1 (GPIO_PORTC | GPIO_PF | 11)
+#define PC12_PF_USBOTG_DATA4 (GPIO_PORTC | GPIO_PF | 12)
+#define PC13_PF_USBOTG_DATA3 (GPIO_PORTC | GPIO_PF | 13)
#define PC16_PF_SSI4_FS (GPIO_PORTC | GPIO_PF | GPIO_IN | 16)
#define PC17_PF_SSI4_RXD (GPIO_PORTC | GPIO_PF | GPIO_IN | 17)
#define PC18_PF_SSI4_TXD (GPIO_PORTC | GPIO_PF | GPIO_IN | 18)
@@ -66,11 +66,11 @@
#define PD14_PF_ATA_DATA12 (GPIO_PORTD | GPIO_PF | 14)
#define PD15_PF_ATA_DATA13 (GPIO_PORTD | GPIO_PF | 15)
#define PD16_PF_ATA_DATA14 (GPIO_PORTD | GPIO_PF | 16)
-#define PE0_PF_USBOTG_NXT (GPIO_PORTE | GPIO_PF | GPIO_OUT | 0)
-#define PE1_PF_USBOTG_STP (GPIO_PORTE | GPIO_PF | GPIO_OUT | 1)
-#define PE2_PF_USBOTG_DIR (GPIO_PORTE | GPIO_PF | GPIO_OUT | 2)
-#define PE24_PF_USBOTG_CLK (GPIO_PORTE | GPIO_PF | GPIO_OUT | 24)
-#define PE25_PF_USBOTG_DATA7 (GPIO_PORTE | GPIO_PF | GPIO_OUT | 25)
+#define PE0_PF_USBOTG_NXT (GPIO_PORTE | GPIO_PF | 0)
+#define PE1_PF_USBOTG_STP (GPIO_PORTE | GPIO_PF | 1)
+#define PE2_PF_USBOTG_DIR (GPIO_PORTE | GPIO_PF | 2)
+#define PE24_PF_USBOTG_CLK (GPIO_PORTE | GPIO_PF | 24)
+#define PE25_PF_USBOTG_DATA7 (GPIO_PORTE | GPIO_PF | 25)
#define PF1_PF_NFCLE (GPIO_PORTF | GPIO_PF | 1)
#define PF3_PF_NFCE (GPIO_PORTF | GPIO_PF | 3)
#define PF7_PF_PC_POE (GPIO_PORTF | GPIO_PF | 7)
--
1.7.10.4
From d6390bcfa4435af350f3c76a369954824fec76ea Mon Sep 17 00:00:00 2001
From: Christoph Fritz chf.fr...@googlemail.com
Date: Fri, 27 Sep 2013 17:07:43 +0200
Subject: [PATCH 1/2] ARM: pca100: fix USB muxing order
The order of muxing USB-Pins seems to be important when ULPI-Mode
is configured. ULPI-Mode is and needs to be set before muxing, which
is already done for pca100.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/boards/phycard-i.MX27/pca100.c | 40 +--
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boards/phycard-i.MX27/pca100.c b/arch/arm/boards/phycard-i.MX27/pca100.c
index 8ea7b0d..03be662 100644
--- a/arch/arm/boards/phycard-i.MX27/pca100.c
+++ b/arch/arm/boards/phycard-i.MX27/pca100.c
@@ -201,6 +201,33 @@ static int pca100_devices_init(void)
struct device_d *nand;
unsigned int mode[] = {
+ /* USB host 2 */
+ PA2_PF_USBH2_DATA7,
+ PD21_AF_USBH2_DATA6,
+ PD26_AF_USBH2_DATA5,
+ PD19_AF_USBH2_DATA4,
+
Re: [PATCH] memory mapping for usbfs (v0.4)
On Sun, Sep 29, 2013 at 5:14 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Sep 29, 2013 at 04:02:56PM +0200, Markus Rechberger wrote: This patch adds memory mapping support to USBFS for isochronous and bulk data transfers, it allows to pre-allocate usb transfer buffers. The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook The CPU usage decreases 6-8% on an Intel Atom n270 when transferring 20mbyte/sec (isochronous), it should be more interesting to see those statistics on embedded systems where copying data is more expensive. Do you have a userspace test program that we can use to verify that this does work, and that others can use to run on some different platforms to verify that this is actually faster? You will need one of our devices for testing I guess. Some scanners (which use USBFS) or other low speed devices won't really utilize usbfs too much. I think I could provide some grabber device for testing if you want to. I don't even know another device which is transferring 20mb/sec other than our ones with USBFS. I figured out another company is doing grabber drivers in userspace for industrial cameras but that's also proprietary. Searching the kernel messages with google usually links back to our customers which are using our high speed devices. Markus 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] memory mapping for usbfs (v0.4)
On Sun, Sep 29, 2013 at 4:24 PM, Ming Lei tom.leim...@gmail.com wrote: On Sun, Sep 29, 2013 at 10:02 PM, Markus Rechberger mrechber...@gmail.com wrote: This patch adds memory mapping support to USBFS for isochronous and bulk data transfers, it allows to pre-allocate usb transfer buffers. The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook The CPU usage decreases 6-8% on an Intel Atom n270 when transferring 20mbyte/sec (isochronous), it should be more interesting to see those statistics on embedded systems where copying data is more expensive. X86 platform should be memory coherent, which means uncached mapping might not affect memory access performance from CPU, so you might need provide performance data on other non-coherent ARCH. Usage from userspace: allocation: rv = ioctl(priv-usbfd, USBDEVFS_ALLOC_MEMORY, mem); if (rv == 0) buffer = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, priv-usbfd, mem.offset); use the mapped buffer with urb-buffer. release: rv = munmap(buffer, size); memset(mem, 0x0, sizeof(struct usbdevfs_memory)); mem.buffer = buffer; rv = ioctl(priv-usbfd, USBDEVFS_RELEASE_MEMORY, mem); non freed memory buffers are collected and will be released when closing the node. I tested this patch with Bulk and Isochronous, with and without memory mapping (applications which don't use mmap will just fall back to the legacy mechanism). Version 0.3: * Removed comment * Renamed USBDEVFS_FREE_MEMORY to USBDEVFS_RELEASE_MEMORY * Clearing allocated memory Version 0.4: * overriding SG transfers once memory mapped buffers are allocated for BULK Why do you want to override SG transfer? please read up the previous emails to the mailinglist I provided a bunch of links with bugreports. * adding pgprot_noncached to ensure that the IO memory is not cached Accessing non-cached mapping on some ARCHs is extremely slow, so I an wondering if it is good way to map the area as non-cached. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Memory mapping for USBFS
On Sun, Sep 29, 2013 at 5:22 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Sep 29, 2013 at 01:51:58PM +0200, Markus Rechberger wrote: I searched with google, obviously no one is using USBFS/userspace USB drivers that intensive as we do because (streaming 6mb for DVB or 20mb for Analog over days) the only bug reports that come up are related to our devices and point to our forum. Not true at all, I know of at least one company, and odds are there are many others, that have been doing this type of thing since the 2.2 kernel days, in their embedded systems for the military. military and high speed transfer? Must be some party losing the war because of stalled transfers ha ha. Maybe that's how and why Iran caught the US drone back then. (joking). I think back then the isochronous transfer buffers were also quite small, and we lost some data packets back then. It worked but the driver did skip some frames with systems 2.6.32 systems once some other load came up on the system. They do it all in userspace, for vision systems, using usbfs. So you aren't alone at all, just the only ones with reported problems :) yes however there are problems as indicated. They rarely happen with normal PC systems (if at all). One problem (latency issue due too small buffers) is happening because of the particular chipset on those embedded systems, SG transfer behavior is unknown since there's no uptodate kernel is available on that system. I'd prefer to support both mechanisms before forcing the SG behavior on everything. Markus -- 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] memory mapping for usbfs (v0.4)
On Sun, Sep 29, 2013 at 07:32:56PM +0200, Markus Rechberger wrote: On Sun, Sep 29, 2013 at 5:14 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Sep 29, 2013 at 04:02:56PM +0200, Markus Rechberger wrote: This patch adds memory mapping support to USBFS for isochronous and bulk data transfers, it allows to pre-allocate usb transfer buffers. The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook The CPU usage decreases 6-8% on an Intel Atom n270 when transferring 20mbyte/sec (isochronous), it should be more interesting to see those statistics on embedded systems where copying data is more expensive. Do you have a userspace test program that we can use to verify that this does work, and that others can use to run on some different platforms to verify that this is actually faster? You will need one of our devices for testing I guess. Some scanners (which use USBFS) or other low speed devices won't really utilize usbfs too much. I think I could provide some grabber device for testing if you want to. So no test userspace program you can knock up for us? I really hate adding new core functionality to the kernel that I have no way of testing at all, that's a recipe for it quickly breaking... 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] memory mapping for usbfs (v0.4)
On Sun, Sep 29, 2013 at 9:01 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Sep 29, 2013 at 07:32:56PM +0200, Markus Rechberger wrote: On Sun, Sep 29, 2013 at 5:14 PM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Sep 29, 2013 at 04:02:56PM +0200, Markus Rechberger wrote: This patch adds memory mapping support to USBFS for isochronous and bulk data transfers, it allows to pre-allocate usb transfer buffers. The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook The CPU usage decreases 6-8% on an Intel Atom n270 when transferring 20mbyte/sec (isochronous), it should be more interesting to see those statistics on embedded systems where copying data is more expensive. Do you have a userspace test program that we can use to verify that this does work, and that others can use to run on some different platforms to verify that this is actually faster? You will need one of our devices for testing I guess. Some scanners (which use USBFS) or other low speed devices won't really utilize usbfs too much. I think I could provide some grabber device for testing if you want to. So no test userspace program you can knock up for us? I really hate adding new core functionality to the kernel that I have no way of testing at all, that's a recipe for it quickly breaking... Well do you have any device which has a userspace driver? Without a device you can barely test it. There's a settopbox company which added the backported patch to Linux 3.2 they use USB cardreaders and even tested the devices with and without mmap support. I doubt that the SG support has any good testing on low end systems, I'm worried that it will introduce those latency issues again which we saw with 15k buffers. Markus -- 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] memory mapping for usbfs (v0.4)
On Sun, 29 Sep 2013, Markus Rechberger wrote: Do you have a userspace test program that we can use to verify that this does work, and that others can use to run on some different platforms to verify that this is actually faster? You will need one of our devices for testing I guess. Some scanners (which use USBFS) or other low speed devices won't really utilize usbfs too much. I think I could provide some grabber device for testing if you want to. So no test userspace program you can knock up for us? I really hate adding new core functionality to the kernel that I have no way of testing at all, that's a recipe for it quickly breaking... Well do you have any device which has a userspace driver? Without a device you can barely test it. There's a settopbox company which added the backported patch to Linux 3.2 they use USB cardreaders and even tested the devices with and without mmap support. I doubt that the SG support has any good testing on low end systems, I'm worried that it will introduce those latency issues again which we saw with 15k buffers. There are lots of userspace drivers based on libusb or libusbx. If you post an enhancement for libusbx to make use of your buffer mappings, many people will be able to test it. 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: EHCI bus glue driver works for storage, fails for a WiFi module
Hi Arokux,
Allan already pointed on timing issue. If you compare bad and working
logs you will see that interval on bad log is match more shorter. On my
expiriance with other wifi adapter it is critical. Beside, it has
nothing todo with wifi at all.
In many cases usb controller insight of adapter is produced by some
other company. For example faraday-tech which produce FUSB200,
FUSB220,.. IP cores.
If interval is less then hardware can handle, it can overfill FIFOs on
endpoints. If firmware can't handle this error, then device will be just
unresponsive.
Am 29.09.2013 19:03, schrieb Arokux X:
Dear Larry,
On PCs, the driver has some problems with stability of the radio
connections, and I am currently working on that problem; however, there are
no difficulties in communicating over the USB system.
Do you have any idea how I can localize the problem to find out at
what stage it fails? You know, same 200 lines of code work with one
kernel (3.4), but fail with another (mainline). Fist I thought it
might be a bug in my USB bus glue driver, but it doesn't look like
this. I've run out of ideas how to troubleshoot this issue.
One problem that was recently discovered on ARM architecture is that the
private area at the end of the main structure was not aligned. The fix has
been added to the wireless-testing tree as commit 60ce314d1750fef. It is on
its way to mainline, but is not there yet. Fortunately, it is a one-liner as
follows:
diff --git a/drivers/net/wireless/rtlwifi/wifi.h
b/drivers/net/wireless/rtlwifi/wifi.h
index cc03e7c..7032587 100644
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -2057,7 +2057,7 @@ struct rtl_priv {
that it points to the data allocated
beyond this structure like:
rtl_pci_priv or rtl_usb_priv */
- u8 priv[0];
+ u8 priv[0] __aligned(sizeof(void *));
};
#define rtl_priv(hw) (((struct rtl_priv *)(hw)-priv))
The patch is line-wrapped, and probably has its white space mangled by this
route of transmission, but it is easily applied manually.
Yes, I had this problem too and found that one liner already. I can
confirm - it works. But yes, USB problem is different one.
Best regards,
Arokux
--
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
--
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
[GIT PATCH] USB fixes for 3.12-rc3
The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.12-rc3 for you to fetch changes up to 85601f8cf67c56a561a6dd5e130e65fdc179047d: usb: dwc3: add support for Merrifield (2013-09-26 16:22:29 -0700) USB fixes for 3.12-rc3 Here are a number of USB driver fixes for 3.12-rc3. These are all for host controller issues that have been reported, and there's a fix for an annoying error message that gets printed every time you remove a USB 3 device from the system that's been bugging me for a while. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Al Viro (1): USB: Fix breakage in ffs_fs_mount() Alan Stern (4): USB: iMX21: accept very late isochronous URBs USB: UHCI: accept very late isochronous URBs USB: OHCI: accept very late isochronous URBs USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd David Cohen (1): usb: dwc3: add support for Merrifield Florian Wolter (1): xhci: Fix race between ep halt and URB cancellation Geert Uytterhoeven (1): usb: chipidea: USB_CHIPIDEA should depend on HAS_DMA Greg Kroah-Hartman (1): Merge tag 'for-usb-linus-2013-09-23' of git://git.kernel.org/.../sarah/xhci into usb-linus Kurt Garloff (1): usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit Mathias Nyman (2): xhci: Fix oops happening after address device timeout xhci: Ensure a command structure points to the correct trb on the command ring Peter Chen (4): usb: chipidea: udc: fix the oops after rmmod gadget usb: chipidea: Fix memleak for ci-hw_bank.regmap when removal usb: chipidea: imx: Add usb_phy_shutdown at probe's error path usb: chipidea: udc: free pending TD at removal procedure Ramneek Mehresh (1): fsl/usb: Resolve PHY_CLK_VLD instability issue for ULPI phy Sarah Sharp (1): usb: Fix xHCI host issues on remote wakeup. Shengzhou Liu (1): USB: fsl/ehci: fix failure of checking PHY_CLK_VALID during reinitialization Xenia Ragiadakou (1): usbcore: check usb device's state before sending a Set SEL control transfer drivers/usb/chipidea/Kconfig | 2 +- drivers/usb/chipidea/ci_hdrc_imx.c | 7 +++-- drivers/usb/chipidea/core.c| 1 + drivers/usb/chipidea/udc.c | 4 ++- drivers/usb/core/devio.c | 16 ++ drivers/usb/core/hub.c | 3 ++ drivers/usb/dwc3/dwc3-pci.c| 2 ++ drivers/usb/gadget/f_fs.c | 60 +- drivers/usb/host/ehci-fsl.c| 17 --- drivers/usb/host/ehci-pci.c| 2 +- drivers/usb/host/imx21-hcd.c | 8 ++--- drivers/usb/host/ohci-hcd.c| 22 +++--- drivers/usb/host/ohci-q.c | 26 ++--- drivers/usb/host/uhci-pci.c| 2 +- drivers/usb/host/uhci-q.c | 12 +--- drivers/usb/host/xhci-hub.c| 47 ++--- drivers/usb/host/xhci-mem.c| 2 ++ drivers/usb/host/xhci-pci.c| 2 +- drivers/usb/host/xhci-ring.c | 37 +-- drivers/usb/host/xhci.c| 25 drivers/usb/host/xhci.h| 11 +++ 21 files changed, 201 insertions(+), 107 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] memory mapping for usbfs (v0.4)
On Sun, Sep 29, 2013 at 9:58 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 29 Sep 2013, Markus Rechberger wrote: Do you have a userspace test program that we can use to verify that this does work, and that others can use to run on some different platforms to verify that this is actually faster? You will need one of our devices for testing I guess. Some scanners (which use USBFS) or other low speed devices won't really utilize usbfs too much. I think I could provide some grabber device for testing if you want to. So no test userspace program you can knock up for us? I really hate adding new core functionality to the kernel that I have no way of testing at all, that's a recipe for it quickly breaking... Well do you have any device which has a userspace driver? Without a device you can barely test it. There's a settopbox company which added the backported patch to Linux 3.2 they use USB cardreaders and even tested the devices with and without mmap support. I doubt that the SG support has any good testing on low end systems, I'm worried that it will introduce those latency issues again which we saw with 15k buffers. There are lots of userspace drivers based on libusb or libusbx. If you post an enhancement for libusbx to make use of your buffer mappings, those are free to adapt their libraries to use that feature (see first post how to use the ioctls). You need to find a reasonable application for those patches, I do not know anyone else using such a heavy bulk or isochronous application on low end systems not even on high end systems (otherwise you'd very likely be able to find more such kernel allocation messages on the internet and not only from us, obviously they all link to our forum or devices). VMWare, Qemu or Xen might be a good target for testing (when passing through windows requests and using a camera in windows). I'll try to post some videos from the intel atom using our driver with the legacy mode (basically the normal way without mmap) and enhanced one with mmap isochronous and bulk. Markus -- 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: EHCI bus glue driver works for storage, fails for a WiFi module
Hi Oleksij, On Sun, Sep 29, 2013 at 10:01 PM, Oleksij Rempel li...@rempel-privat.de wrote: Hi Arokux, Allan already pointed on timing issue. If you compare bad and working logs you will see that interval on bad log is match more shorter. On my expiriance with other wifi adapter it is critical. Beside, it has nothing todo with wifi at all. In many cases usb controller insight of adapter is produced by some other company. For example faraday-tech which produce FUSB200, FUSB220,.. IP cores. If interval is less then hardware can handle, it can overfill FIFOs on endpoints. If firmware can't handle this error, then device will be just unresponsive. thanks for the explanation. The hardware is the same in both cases. So the only difference is in software. What do you think can influence such difference in timing on software side? Maybe some clock has higher frequency then it should? Best regards, Arokux -- 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: gadget: mark init as late_initcall
Dear Peter Chen, Since we introduce -EPROBE_DEFER for udc driver, it will be probed at late_initcall if it is defered. When the gadget is built in, it will return couldn't find an available UDC at such case. That's the problem we met at below link: http://marc.info/?l=linux-usbm=137706435611447w=2 We have no driver's probe at gadget driver, so we can't return -EPROBE_DEFER. And it is also not suitable to defer udc_bind_to_driver if the udc is not found temporarily, since it is hard to decide the return value for usb_gadget_probe_driver. Due to above reasons, mark gadget's init as late_initcall may be a moderate solution. Signed-off-by: Peter Chen peter.c...@freescale.com Seems this tries to paper over an issue with module dependencies , no? Best regards, Marek Vasut -- 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: gadget: mark init as late_initcall
Since we introduce -EPROBE_DEFER for udc driver, it will be probed at late_initcall if it is defered. When the gadget is built in, it will return couldn't find an available UDC at such case. That's the problem we met at below link: http://marc.info/?l=linux-usbm=137706435611447w=2 We have no driver's probe at gadget driver, so we can't return -EPROBE_DEFER. And it is also not suitable to defer udc_bind_to_driver if the udc is not found temporarily, since it is hard to decide the return value for usb_gadget_probe_driver. Due to above reasons, mark gadget's init as late_initcall may be a moderate solution. Signed-off-by: Peter Chen peter.c...@freescale.com Seems this tries to paper over an issue with module dependencies , no? In fact, there are module dependencies between udc and composite gadget. The udc must be created before composite gadget. If the creation of udc (or its controller driver) is deferred, the composite gadget driver has no way to know it, unless we change gadget framework a lot, eg add probe API for composite driver, create a thread to check udc creation if there is no udc, etc. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 net-next 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
Some drivers implementing NCM-like protocols, may re-use those functions, as is
the case in the huawei_cdc_ncm driver.
Export them via EXPORT_SYMBOL_GPL, in accordance with how other functions have
been exported.
Signed-off-by: Enrico Mioso mrkiko...@gmail.com
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 43afde8..62686be 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -858,7 +858,7 @@ static void cdc_ncm_txpath_bh(unsigned long param)
}
}
-static struct sk_buff *
+struct sk_buff *
cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
{
struct sk_buff *skb_out;
@@ -885,6 +885,7 @@ error:
return NULL;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_tx_fixup);
/* verify NTB header and return offset of first NDP, or negative error */
int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in)
@@ -965,7 +966,7 @@ error:
}
EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_ndp16);
-static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
+int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
{
struct sk_buff *skb;
struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev-data[0];
@@ -1040,6 +1041,7 @@ err_ndp:
error:
return 0;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_rx_fixup);
static void
cdc_ncm_speed_change(struct cdc_ncm_ctx *ctx,
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index cc25b70..163244b 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -133,3 +133,6 @@ extern void cdc_ncm_unbind(struct usbnet *dev, struct
usb_interface *intf);
extern struct sk_buff *cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct
sk_buff *skb, __le32 sign);
extern int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff
*skb_in);
extern int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset);
+struct sk_buff *
+cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags);
+int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in);
--
1.8.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
[PATCH V5 net-next 3/3] net: cdc_ncm: remove non-standard NCM device IDs
Remove device IDs of NCM-like (but not NCM-conformant) devices, that are
handled by the huawwei_cdc_ncm driver now.
Signed-off-by: Enrico Mioso mrkiko...@gmail.com
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 62686be..31f43f7 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1236,17 +1236,6 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long)wwan_info,
},
- /* Huawei NCM devices disguised as vendor specific */
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16),
- .driver_info = (unsigned long)wwan_info,
- },
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x46),
- .driver_info = (unsigned long)wwan_info,
- },
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x76),
- .driver_info = (unsigned long)wwan_info,
- },
-
/* Infineon(now Intel) HSPA Modem platform */
{ USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
USB_CLASS_COMM,
--
1.8.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
[PATCH V5 net-next 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This drivers approach was
heavily inspired by the qmi_wwan/cdc_mbim approach code model.
Suggested-by: Bjorn Mork bj...@mork.no
Signed-off-by: Enrico Mioso mrkiko...@gmail.com
create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 40db312..85e4a01 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -242,6 +242,21 @@ config USB_NET_CDC_NCM
* ST-Ericsson M343 HSPA Mobile Broadband Modem (reference design)
* Ericsson F5521gw Mobile Broadband Module
+config USB_NET_HUAWEI_CDC_NCM
+ tristate Huawei NCM embedded AT channel support
+ depends on USB_USBNET
+ select USB_WDM
+ select USB_NET_CDC_NCM
+ help
+ This driver supports huawei-style NCM devices, that use NCM as a
+ transport for other protocols, usually an embedded AT channel.
+ Good examples are:
+ * Huawei E3131
+ * Huawei E3251
+
+ To compile this driver as a module, choose M here: the module
will be
+ called huawei_cdc_ncm.ko.
+
config USB_NET_CDC_MBIM
tristate CDC MBIM support
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 8b342cf..b17b5e8 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_IPHETH) += ipheth.o
obj-$(CONFIG_USB_SIERRA_NET) += sierra_net.o
obj-$(CONFIG_USB_NET_CX82310_ETH) += cx82310_eth.o
obj-$(CONFIG_USB_NET_CDC_NCM) += cdc_ncm.o
+obj-$(CONFIG_USB_NET_HUAWEI_CDC_NCM) += huawei_cdc_ncm.o
obj-$(CONFIG_USB_VL600)+= lg-vl600.o
obj-$(CONFIG_USB_NET_QMI_WWAN) += qmi_wwan.o
obj-$(CONFIG_USB_NET_CDC_MBIM) += cdc_mbim.o
diff --git a/drivers/net/usb/huawei_cdc_ncm.c b/drivers/net/usb/huawei_cdc_ncm.c
new file mode 100644
index 000..ff07b18
--- /dev/null
+++ b/drivers/net/usb/huawei_cdc_ncm.c
@@ -0,0 +1,228 @@
+/* huawei_cdc_ncm.c - handles Huawei devices using the CDC NCM protocol as
+ * transport layer.
+ * Copyright (C) 2013 Enrico Mioso mrkiko...@gmail.com
+ *
+ *
+ * ABSTRACT:
+ * This driver handles devices resembling the CDC NCM standard, but
+ * encapsulating another protocol inside it. An example are some Huawei 3G
+ * devices, exposing an embedded AT channel where you can set up the NCM
+ * connection.
+ * This code has been heavily inspired by the cdc_mbim.c driver, which is
+ * Copyright (c) 2012 Smith Micro Software, Inc.
+ * Copyright (c) 2012 Bjørn Mork bj...@mork.no
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/ethtool.h
+#include linux/if_vlan.h
+#include linux/ip.h
+#include linux/mii.h
+#include linux/usb.h
+#include linux/usb/cdc.h
+#include linux/usb/usbnet.h
+#include linux/usb/cdc-wdm.h
+#include linux/usb/cdc_ncm.h
+
+/* Driver data */
+struct huawei_cdc_ncm_state {
+ struct cdc_ncm_ctx *ctx;
+ atomic_t pmcount;
+ struct usb_driver *subdriver;
+ struct usb_interface *control;
+ struct usb_interface *data;
+};
+
+static int huawei_cdc_ncm_manage_power(struct usbnet *usbnet_dev, int on)
+{
+ struct huawei_cdc_ncm_state *drvstate = (void *)usbnet_dev-data;
+ int rv = 0;
+
+ if ((on atomic_add_return(1, drvstate-pmcount) == 1) ||
+ (!on atomic_dec_and_test(drvstate-pmcount))) {
+ rv = usb_autopm_get_interface(usbnet_dev-intf);
+ if (rv 0)
+ goto err;
+ usbnet_dev-intf-needs_remote_wakeup = on;
+ usb_autopm_put_interface(usbnet_dev-intf);
+ }
+err:
+ return rv;
+}
+
+static int huawei_cdc_ncm_wdm_manage_power(struct usb_interface *intf, int
status)
+{
+ struct usbnet *usbnet_dev = usb_get_intfdata(intf);
+
+ /* can be called while disconnecting */
+ if (!usbnet_dev)
+ return 0;
+
+ return huawei_cdc_ncm_manage_power(usbnet_dev, status);
+}
+
+
+static int huawei_cdc_ncm_bind(struct usbnet *usbnet_dev, struct usb_interface
*intf)
+{
+ struct cdc_ncm_ctx *ctx;
+ struct usb_driver *subdriver = ERR_PTR(-ENODEV);
+ int ret = -ENODEV;
+ struct huawei_cdc_ncm_state *drvstate = (void *)usbnet_dev-data;
+
+ /* altsetting should always be 1 for NCM devices - so we hard-coded
+* it here
+*/
+ ret = cdc_ncm_bind_common(usbnet_dev, intf, 1);
+ if (ret)
+ goto err;
+
+ ctx = drvstate-ctx;
+
+ if (usbnet_dev-status)
+ /* CDC-WMC r1.1 requires wMaxCommand to be at least 256
+* decimal
[PATCH V5 net-next 0/3] The huawei_cdc_ncm driver
So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which
supports devices resembling the NCM standard, but using it also as a mean
to encapsulate other protocols, as is the case for the Huawei E3131 and
E3251 modem devices.
Some precisations are needed however - and I encourage discussion on this: and
that's why I'm sending this message with a broader CC.
Merging those patches might change:
- the way Modem Manager interacts with those devices
- some regressions might be possible if there are some unknown firmware
variants around (Franko?)
First of all: I observed the behaviours of two devices.
Huawei E3131: this device doesn't accept NDIS setup requests unless they're
sent via the embedded AT channel exposed by this driver.
So actually we gain funcionality in this case!
The second case, is the Huawei E3251: which works with standard NCM driver,
still exposing an AT embedded channel. Whith this patch set applied, you gain
some funcionality, loosing the ability to catch standard NCM events for now.
The device will work in both ways with no problems, but this has to be
acknowledged and discussed. Might be we can develop this driver further to
change this, when more devices are tested.
We where thinking Huawei changed their interfaces on new devices - but probably
this driver only works around a nice firmware bug present in E3131, which
prevented the modem from being used in NDIS mode.
I think committing this is definitely wortth-while, since it will allow for
more Huawei devices to be used without serial connection. Some devices like the
E3251 also, reports some status information only via the embedded AT channel,
at least in my case.
Note: I'm not subscribed to any list except the Modem Manager's one, so please
CC me, thanks!!
Enrico Mioso (3):
net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
net: cdc_ncm: remove non-standard NCM device IDs
drivers/net/usb/Kconfig | 15 +++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/cdc_ncm.c| 17 +--
drivers/net/usb/huawei_cdc_ncm.c | 228 +++
include/linux/usb/cdc_ncm.h | 3 +
5 files changed, 251 insertions(+), 13 deletions(-)
create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
--
1.8.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: [Pull request] Fix moxa firmware filenames
On Thu, 2013-09-05 at 13:30 +0200, Andrew Lunn wrote: Hi David, Ben. I messed up with the Moxa firmware. I have the filenames wrong, due to one too many decimal to hex conversions of the USB product ID. I could work around this in the driver, but it would be a lot better to rename the files. Here is a pull request to fix the issue. Pulled, thanks. Ben. Thanks Andrew The following changes since commit e7c85b24a5e5107e9911c6b80f536b6bbc5d465d: moxa: Fix firmware file names. (2013-09-05 13:18:07 +0200) are available in the git repository at: g...@github.com:lunn/linux-firmware.git moxa for you to fetch changes up to e7c85b24a5e5107e9911c6b80f536b6bbc5d465d: moxa: Fix firmware file names. (2013-09-05 13:18:07 +0200) -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. signature.asc Description: This is a digitally signed message part
Re: [PATCH] memory mapping for usbfs (v0.4)
Hi Markus, Do you have a userspace test program that we can use to verify that this does work, and that others can use to run on some different platforms to verify that this is actually faster? You will need one of our devices for testing I guess. Some scanners (which use USBFS) or other low speed devices won't really utilize usbfs too much. I think I could provide some grabber device for testing if you want to. So no test userspace program you can knock up for us? I really hate adding new core functionality to the kernel that I have no way of testing at all, that's a recipe for it quickly breaking... Well do you have any device which has a userspace driver? Without a device you can barely test it. There's a settopbox company which added the backported patch to Linux 3.2 they use USB cardreaders and even tested the devices with and without mmap support. I doubt that the SG support has any good testing on low end systems, I'm worried that it will introduce those latency issues again which we saw with 15k buffers. There are lots of userspace drivers based on libusb or libusbx. If you post an enhancement for libusbx to make use of your buffer mappings, those are free to adapt their libraries to use that feature (see first post how to use the ioctls). You need to find a reasonable application for those patches, I do not know anyone else using such a heavy bulk or isochronous application on low end systems not even on high end systems (otherwise you'd very likely be able to find more such kernel allocation messages on the internet and not only from us, obviously they all link to our forum or devices). VMWare, Qemu or Xen might be a good target for testing (when passing through windows requests and using a camera in windows). I think the same can be done with any standard Bluetooth controller and using SCO audio data for a headset connection. These also use ISOC transfers and as of today, do not work inside KVM. So if anybody wants to see if these changes actually make a difference, then a Qemu/KVM using them might be a good test case. Regards Marcel -- 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/5] usb: musb_am335x: Remove redundant of_match_ptr
The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/usb/musb/musb_am335x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_am335x.c b/drivers/usb/musb/musb_am335x.c
index 41ac5b5..8be9b02 100644
--- a/drivers/usb/musb/musb_am335x.c
+++ b/drivers/usb/musb/musb_am335x.c
@@ -46,7 +46,7 @@ static struct platform_driver am335x_child_driver = {
.remove = am335x_child_remove,
.driver = {
.name = am335x-usb-childs,
- .of_match_table = of_match_ptr(am335x_child_of_match),
+ .of_match_table = am335x_child_of_match,
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] usb: musb_dsps: Remove redundant of_match_ptr
The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Ravi B ravib...@ti.com
---
drivers/usb/musb/musb_dsps.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 4047cbb..c7fe16d 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -628,7 +628,7 @@ static struct platform_driver dsps_usbss_driver = {
.remove = dsps_remove,
.driver = {
.name = musb-dsps,
- .of_match_table = of_match_ptr(musb_dsps_of_match),
+ .of_match_table = musb_dsps_of_match,
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] usb: phy: am335x-control: Remove redundant of_match_ptr
The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/usb/phy/phy-am335x-control.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-am335x-control.c
b/drivers/usb/phy/phy-am335x-control.c
index 22cf07d..6adca06 100644
--- a/drivers/usb/phy/phy-am335x-control.c
+++ b/drivers/usb/phy/phy-am335x-control.c
@@ -129,7 +129,7 @@ static struct platform_driver am335x_control_driver = {
.driver = {
.name = am335x-control-usb,
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(omap_control_usb_id_table),
+ .of_match_table = omap_control_usb_id_table,
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] usb: phy: tegra-usb: Remove redundant of_match_ptr
The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: linux-te...@vger.kernel.org
---
drivers/usb/phy/phy-tegra-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index e9cb1cb..82232ac 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -1090,7 +1090,7 @@ static struct platform_driver tegra_usb_phy_driver = {
.driver = {
.name = tegra-phy,
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(tegra_usb_phy_id_table),
+ .of_match_table = tegra_usb_phy_id_table,
},
};
module_platform_driver(tegra_usb_phy_driver);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] usb: phy: am335x: Remove redundant of_match_ptr
The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/usb/phy/phy-am335x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index c4d614d..b653be8 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -91,7 +91,7 @@ static struct platform_driver am335x_phy_driver = {
.driver = {
.name = am335x-phy-driver,
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(am335x_phy_ids),
+ .of_match_table = am335x_phy_ids,
},
};
--
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
