Hi,
I have a Suunto ANT+ stick (designed to communicate with various training
equipment) that works as a USB serial device. Unfortunately, it seems like
its PCI IDs are missing; it doesn't come up unless I add vendor= and product=
to the usbserial loading line explicitly. When I do, however, it
On Thu, Jul 25, 2013 at 09:52:29PM -0700, Greg Kroah-Hartman wrote:
Steinar, I've tested the driver below with my device and it seems to
work. If you have any problems with it, please let me know, otherwise
I'll queue it up to get into the 3.11 kernel release soon.
Backported to 3.10.3 and
On Fri, Jul 26, 2013 at 02:12:46PM -0700, Greg Kroah-Hartman wrote:
Backported to 3.10.3 and tested (with my own, old fork of gant), works fine.
Wonderful, thanks for testing.
Where is the official place for gant these days anyway?
I wish I knew. I think there are like four forks, some of
Hi,
I'm using a Sundtek DVB-C USB stick (with their userspace driver which works
over usbfs, as I understand it), and when I w_scan, after ~10 minutes or so
this happens:
Mar 8 14:22:47 gruessi kernel: [ 2429.016860] xhci_hcd :00:14.0: WARN
Event TRB for slot 1 ep 2 with no TDs queued?
On Sat, Mar 08, 2014 at 04:42:24PM +0100, Steinar H. Gunderson wrote:
I'm using a Sundtek DVB-C USB stick (with their userspace driver which works
over usbfs, as I understand it), and when I w_scan, after ~10 minutes or so
this happens:
Hi,
Did anyone have a chance to look
On Wed, Oct 21, 2015 at 10:29:11AM -0400, Alan Stern wrote:
>> Is there such a blacklist already, where I can add the devices (there are two
>> distinct IDs behaving identically) and see if it helps?
> There is a blacklist, but it does not affect LPM. See
> drivers/usb/core/quirks.c and
On Thu, Nov 12, 2015 at 05:08:32PM -0500, Alan Stern wrote:
> You're right; I got the two patch sets mixed up. Considering that it
> was written a couple of years ago, you'll probably have to do some work
> to get it to apply to the current kernel. Let me know if you need any
> help.
There
On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote:
> I guess I should either add some debug printks or else see if there's
> anything in the snooping that can help me track it down.
Interestingly enough, I get this at startup:
[ 3316.681227] x86/PAT: app:4154 map pfn RAM
On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote:
> Interesting. I hacked libusb to get the fd. Then I did USBDEVFS_ALLOC_MEMORY,
> which succeeded (well, as soon as I filled mem.size before calling),
> then mmap on it as described (which also succeeded), and everythin
On Fri, Nov 13, 2015 at 10:38:54AM -0500, Alan Stern wrote:
>> So, in general I think it's good news, although I don't fully understand why
>> I still need the kernel-to-userspace copy for isochronous transfer.
> Maybe you can add some debugging to copy_user_enhanced_fast_string().
> Add a flag,
On Fri, Nov 13, 2015 at 11:24:39AM -0500, Alan Stern wrote:
>> What exactly am I looking for, beyond the stack trace the kernel already
>> gives me?
> Find out where copy_user_enhanced_fast_string is being called from, and
> using that information, figure out why it was called. That will tell
>
On Fri, Nov 13, 2015 at 06:50:27PM +0100, Steinar H. Gunderson wrote:
> The stack trace is simple enough, although I fear there's some inlining going
> on:
OK, I guess since copy_user_enhanced_fast_string is an assembler function,
the unwinding doesn't work properly. I added a dump
On Fri, Nov 13, 2015 at 03:20:56PM -0500, Alan Stern wrote:
>> I tried just not setting as->userbuffer if usbm == NULL, and lo and behold,
>> it actually seems to help.
> In fact, there's no need to call copy_urb_data_to_user at all if the
> buffer lies in the mmap'ed area.
usbm != NULL is meant
On Fri, Nov 13, 2015 at 04:02:48PM -0500, Alan Stern wrote:
>> So what is the road from here? I guess the original questions about cache
>> coherency still apply, and that this is what I'm seeing in dmesg.
> What questions? It should be obvious that the user program should not
> touch the buffer
On Mon, Nov 16, 2015 at 01:49:50AM +0100, Steinar H. Gunderson wrote:
> Just so we're on the same page, I cleaned up the patch I'm now using, and I'm
> attaching it here. You said the next step would be changing the memory
> allocation interface; I guess I could give it a shot, but I doub
On Mon, Nov 16, 2015 at 01:29:58PM -0500, Alan Stern wrote:
> A proposed patch has been posted
> (http://marc.info/?l=linux-usb=144763502829452=2), but I'm not
> convinced that it is the best approach. For instance, it always tries
> to get contiguous pages and so is vulnerable to memory
On Mon, Nov 16, 2015 at 07:55:45PM +0100, Christoph Hellwig wrote:
>> A proposed patch has been posted
>> (http://marc.info/?l=linux-usb=144763502829452=2), but I'm not
>> convinced that it is the best approach. For instance, it always tries
>> to get contiguous pages and so is vulnerable to
ies involved.
/* Steinar */
--
Homepage: https://www.sesse.net/
>From 4cf27fbf8000eb6a5ea75c87cd6315ed82d0 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" <se...@google.com>
Date: Mon, 16 Nov 2015 01:36:38 +0100
Subject: [PATCH] Add support for usbfs zerocopy.
This is essential
On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> Check that userspace requested zerocopy (otherwise the user
> program might try to access other data stored in the same cache
> lines as the buffer while the I/O is in progres);
Needed for send only, right? For
On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote:
> 1. the memset on isochronous transfers to empty the buffers in order
> to avoid leaking raw memory to userspace (this costs a lot on intel
> Atoms and is also noticeable on other systems).
>
> 2. the memory fragmentation. Seems
On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote:
> Order 7? Maybe you're trying to put too much data into a single
> transfer and encountering problems with memory fragmentation. Try
> using more frequent, smaller transfers.
I tried going down to 128 kB; it still happens (and if I go
On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote:
> To make your life easier, here's a patch which blacklists these two
> devices for Link Power Management. Please let me know if it works
> okay.
OK, this worked brilliantly. I can now use both cards at the same time,
and I also see
On Mon, Nov 02, 2015 at 01:28:09PM -0500, Alan Stern wrote:
>> Thanks for testing. I will submit the patch in two weeks, when the
>> current merge window closes.
> Or maybe not. This may not be the best way to solve the problem, since
> you found that the two video cards worked okay with one
On Mon, Nov 02, 2015 at 11:04:42AM -0500, Alan Stern wrote:
> To make your life easier, here's a patch which blacklists these two
> devices for Link Power Management. Please let me know if it works
> okay.
Thanks! I'll give it a shot.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To
On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote:
> Order 7? Maybe you're trying to put too much data into a single
> transfer and encountering problems with memory fragmentation. Try
> using more frequent, smaller transfers.
Yes, my transfers are rather big; 512 kB or so. (They used
On Mon, Nov 02, 2015 at 03:32:46PM -0500, Alan Stern wrote:
> You don't need 4.3. Anything released within the last few years
> will contain the LPM code.
According to the bisect, the patch that broke it was from June this year
(2d2a316765d956bc5cb6bb367b2ec52ca59ab8e9), so it would really seem
On Mon, Nov 02, 2015 at 02:38:41PM -0500, Alan Stern wrote:
>> Note that the two controllers were running different kernels. The one that
>> worked had a kernel before LPM was turned on, I believe.
> Oh. Can you try running a more recent kernel on that computer? Does
> it fail with the same
Hello again,
I am (still) using libusb-1.0 to drive an USB 3.0 video card. After I turned
off power management (see previous emails :-) ) it seems stable, but after
running something like 5–6 hours, I seem to get problems on URB submission:
[82029.656250] nageru: page allocation failure:
On Thu, Nov 05, 2015 at 04:12:24PM +0800, Lu, Baolu wrote:
> 1) apply the attached patch on top the latest kernel.
> 2) build and install the kernel.
> 3) boot your machine with the new kernel.
Do you want this on top of Alan's LPM-disabling patch or on a clean
4.3.0 tree?
> 4) insert one
On Fri, Nov 06, 2015 at 08:52:52AM +0800, Lu, Baolu wrote:
>> I reproduced the U1/U2 disconnect issues several times. I didn't try the
>> issue of not enough bandwidth for two devices.
> Can you please try the not enough bandwidth issue?
It doesn't work. I can use one card (it takes 3-4 tries to
On Mon, Nov 02, 2015 at 04:00:42PM -0500, Alan Stern wrote:
> That commit was included in (approximately) the 4.1.5 or later stable
> kernel, and it is included in 4.2. You should be able to put one of
> those on a bootable USB stick.
I tried going down this route. After some back and forth, I
On Fri, Nov 06, 2015 at 08:24:15AM +0800, Lu, Baolu wrote:
> Yeah, sorry about it.
>
> 1) apply the attached patch on top the latest clean kernel.
> 2) build and install the kernel.
> 3) boot your machine with the new kernel.
> 4) insert one Blackmagic Design device into USB3 root port.
> 5)
On Fri, Nov 06, 2015 at 08:39:28AM +0800, Lu, Baolu wrote:
> Have you set CONFIG_PM?
Yes. CONFIG_PM=y.
> Can you reproduce the problem with this kernel?
I reproduced the U1/U2 disconnect issues several times. I didn't try the
issue of not enough bandwidth for two devices.
/* Steinar */
--
On Wed, Oct 21, 2015 at 09:49:16AM +0800, Lu, Baolu wrote:
> I could spend some time on this issue a week later.
> I'd like to check whether there is any bugs in the driver itself.
> Otherwise, blacklist this specific device for LPM.
I don't know if anything happened here, but if you need
On Mon, Sep 28, 2015 at 02:32:13PM +0200, Steinar H. Gunderson wrote:
> Just so that it doesn't get lost: I've reported issues with this specific
> device and LPM not too long ago. It's entirely possible that the device
> somehow is broken, although it works in Windows 7/8/10 and OS X, fr
On Wed, Oct 21, 2015 at 09:49:16AM +0800, Lu, Baolu wrote:
> I could spend some time on this issue a week later.
> I'd like to check whether there is any bugs in the driver itself.
> Otherwise, blacklist this specific device for LPM.
Is there such a blacklist already, where I can add the devices
On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
> Is there an API for allocating user memory below 4 GB? Would a new
> MMAP flag be acceptable?
MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds
more like a kludge than anything else.
/* Steinar */
--
On Tue, Nov 17, 2015 at 02:13:49PM -0500, Alan Stern wrote:
> But what other way of allocating memory is there?
For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently
map up a chunk of GPU memory for you into userspace, but you have no
guarantees as of if it's DMA-able. But
On Sat, Nov 14, 2015 at 12:09:38PM -0500, Alan Stern wrote:
> And you probably couldn't use GPU memory for this purpose because (I
> assume) the USB host controller wouldn't be able to access it via DMA.
I guess that depends a bit; on my particular system, I'm using an Intel GPU,
so memory is
Hi,
I have an USB3 device which I'm using through libusb (so usbfs) pulling
relatively large amounts of isochronous data (uncompressed 720p60 video,
so a bit under a gigabit per second) down to my X240 laptop. I submit four
isochronous requests of about ~2MB each, which seems to be enough to keep
On Sat, Aug 29, 2015 at 12:17:25AM +0200, Steinar H. Gunderson wrote:
I've noticed (with the CONFIG_PM=y kernel) that sometimes this comes up when
inserting the device:
[ 136.370917] usb 3-2: Set SEL for device-initiated U2 failed.
I don't know if it's relevant.
I've also noticed
On Mon, Aug 31, 2015 at 06:03:17PM +0300, Mathias Nyman wrote:
> It's in 4.2-rc6.
> I understood you were running 4.2-rc8, so it should be there.
Yes, the error was with 4.2-rc8.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To unsubscribe from this list: send the line "unsubscribe
On Mon, Aug 31, 2015 at 05:28:10PM +0300, Mathias Nyman wrote:
> The max exit latency should tell how long it can maximum take for the entire
> link between host
> and device to wake up and be fully functional. Isoc transfer will send a PING
> TP max exit
> latency before the first data transfer
On Mon, Sep 28, 2015 at 03:24:04PM +0300, Mathias Nyman wrote:
> Driver will tell the latency value to the host controller, when a exit
> latency time is set the host will know that the link is power managed, and
> host will start to schedule additional PING TP transfers to the device to
> wake
On Fri, Sep 25, 2015 at 10:12:51PM +0200, Steinar H. Gunderson wrote:
> I have no idea whatsoever how this breaks bandwidth management, but seemingly
> it does.
To verify; I built 4.3rc-2 with CONFIG_PM=n, and it can drive both cards
without problems whatwoever. So there's something about
On Mon, Aug 31, 2015 at 05:28:10PM +0300, Mathias Nyman wrote:
> The "ERROR Transfer event TRB DMA ptr not part of curren..." errors are a bit
> worrying.
> I was hoping these would no longer occur after the last off by one fix:
>
> commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd
> xhci: fix
On Thu, Sep 24, 2015 at 03:35:10PM +0200, Krzysztof Opasiak wrote:
>> No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations
>> are wrong.
> How do you do your calculations?
Like I said in my initial email:
>>> The interface of each card has two relevant alternates, 2 and 4.
On Thu, Sep 24, 2015 at 03:09:55PM +0200, Krzysztof Opasiak wrote:
> But still the problem may exist. Is the 2.16 GBit bandwidth for 4th altset?
No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations
are wrong.
> Remember that according to USB spec not whole bandwidth can be
On Thu, Sep 24, 2015 at 02:09:41PM +0200, Krzysztof Opasiak wrote:
> Let's start from the beginning. Your device use ISO endpoints which means
> that host allocates specific amount of bandwidth on the bus. More over,
> interfaces in your devices has many alternate settings. Probably each of
> them
On Thu, Sep 24, 2015 at 10:17:19AM -0400, Alan Stern wrote:
> However, none of this answers the question of why you can use both
> cards on a different machine but not on yours. It comes down to the
> implementations of the xHCI controller chips. In USB-3, bandwidth
> allocation is handled by
On Tue, Sep 22, 2015 at 02:58:57PM +0300, Mathias Nyman wrote:
> But can you find a "No Ping response error, Skip one Isoc TD" entry in the
> log that didn't cause any
> harm, e.g. it was not followed by a "ERROR Transfer event TRB DMA.." entry,
> and continued working
>
> If yes, then the
On Tue, Sep 22, 2015 at 02:58:57PM +0300, Mathias Nyman wrote:
> But can you find a "No Ping response error, Skip one Isoc TD" entry in the
> log that didn't cause any
> harm, e.g. it was not followed by a "ERROR Transfer event TRB DMA.." entry,
> and continued working
>
> If yes, then the
On Thu, Sep 24, 2015 at 11:22:57AM -0400, Alan Stern wrote:
>> I assume there's no way I can lie to the chip? Like, if I know for a fact
>> that the card will send less data than the alternate claims (like,
>> I'm using a video mode that will require only a few hundred megabits/second
>> in
On Thu, Sep 24, 2015 at 02:33:06PM -0700, Paul Zimmerman wrote:
> IIRC, at least some of the Intel controllers require the bandwidth
> calculations to be done by the xHCI driver, instead of doing it
> themselves in hardware. Perhaps you're tripping over a bug in the xHCI
> driver? Mathias is
On Fri, Sep 25, 2015 at 12:42:22AM +0200, Steinar H. Gunderson wrote:
> I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch.
> But I only seem to get frames back from the second one.
...and after a quick app fix, I have capture from both cards.
Does this mean I have
On Wed, Sep 23, 2015 at 10:08:05PM +0200, Steinar H. Gunderson wrote:
> I've tried on another machine and it works fine there, so my code should,
> at least on the surface of it, be fine.
PLOT TWIST:
I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch.
But I only seem
On Thu, Sep 24, 2015 at 04:46:22PM -0400, Alan Stern wrote:
> It does. Grep for max_burst in drivers/usb/host/x*.c to see where it
> gets used. (Note that in a couple of places involving USB-2 devices,
> the code uses max_burst where it really means multiplicity.)
OK, so this is very curious.
On Fri, Sep 25, 2015 at 10:26:23AM -0400, Alan Stern wrote:
>> Does this mean I have a long bisect ahead of me?
> In the absence of any better suggestions, that's the most
> straightforward way to get an answer.
Three hours of bisecting (actually three bisects; I found a git bug along the
way
On Mon, Sep 21, 2015 at 02:01:51PM +0300, Mathias Nyman wrote:
> Now this suddenly makes more sense to me.
>
> Initial problem is very much related to U1 and U2 power saving states.
> Either the device can't handle these states or then we set the max exit
> latency values incorrectly.
There's
On Mon, Sep 21, 2015 at 03:41:19PM +0300, Mathias Nyman wrote:
> If a host fails to wake up a isochronous SuperSpeed device from U1/U2
> in time for a isoch transfer it will generate a "No ping response error"
> Host will then move to the next transfer descriptor.
>
> Handle this case in the same
On Mon, Sep 21, 2015 at 08:25:22PM +0200, Steinar H. Gunderson wrote:
> I ran 4.3-rc2 with your patch applied. The problem still happens:
I turned on all tracing. Maybe it will be useful. The easiest way to provoke
it was seemingly to run lots of other stuff, and then kill my program with
SIGS
On Mon, Sep 21, 2015 at 03:41:19PM +0300, Mathias Nyman wrote:
> If a host fails to wake up a isochronous SuperSpeed device from U1/U2
> in time for a isoch transfer it will generate a "No ping response error"
> Host will then move to the next transfer descriptor.
>
> Handle this case in the same
Hi again,
I'm trying to figure out why my xHCI controller refuses me to run two very
similar video cards at the same time. I'm not sure if this is a bug or if I'm
just misunderstanding, so let me see if I understand this right:
The interface of each card has two relevant alternates, 2 and 4.
On Thu, Aug 27, 2015 at 12:26:28AM +0200, Steinar H. Gunderson wrote:
However, at the same time I get these in dmesg:
[ 221.350440] xhci_hcd :00:14.0: ERROR Unknown event condition 20, HC
probably busted
[ 221.350559] xhci_hcd :00:14.0: ERROR Unknown event condition 20, HC
rather defeats the
> purpose of zerocopy!
See previous comment on this. :-)
>> +if (remap_pfn_range(vma, vma->vm_start,
>> +virt_to_phys(usbm->mem) >> PAGE_SHIFT,
>> +size, vma->vm_page_prot) < 0)
>> +
On Thu, Dec 03, 2015 at 04:31:35PM -0500, Alan Stern wrote:
>> Seemingly controller is already a pointer, so the & is redundant. No idea why
>> it didn't crash plain out. Fixing that, I can allocate, although I have some
>> other bug causing an oops somewhere else.
> Ah, an easy mistake to miss.
On Fri, Dec 04, 2015 at 01:29:05AM +0100, Steinar H. Gunderson wrote:
> I must be doing something wrong, because I don't seem to get any frames
> from my video capture, and when I close the application, I get a slowpath
> warning:
OK, the slowpath warning is a red herring -- it's just
On Sun, Dec 06, 2015 at 01:06:08AM +0100, Steinar H. Gunderson wrote:
> I'll try to update your patch with the other suggestions tomorrow. Thanks!
Here we are. Lightly tested, I believe all comments should be addressed.
/* Steinar */
>From 73833276a4f359c35edffc2a741dba57f2e82a12 Mon Sep
at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson <se...@google.com>
Signed-off-by: Markus Rechberger <mrechber...@gmail.com>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---
drivers/usb/core/devi
On Wed, Dec 09, 2015 at 09:29:20AM -0500, Greg Kroah-Hartman wrote:
> Shouldn't there also be some sort of documentation update with this
> patch as well, so that people know of the new functionality we are
> adding?
I can write documentation if you can point me to a reasonable place.
/* Steinar
On Tue, Dec 08, 2015 at 05:01:46PM -0500, Alan Stern wrote:
> I don't see anything else to change. You can submit this to Greg KH
> and add:
>
> Acked-by: Alan Stern
Great!
How do I submit? Just do git send-email to some address?
Do you know what the status is for
cleaner.
Done.
/* Steinar */
>From 03318604cc6ad9def451784da407e6fcd6af4705 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" <se...@google.com>
Date: Thu, 26 Nov 2015 01:19:13 +0100
Subject: [PATCH] Add support for usbfs zerocopy.
Add a new interface for userspace to preallocate memory that
> } else {
> usbm = iter;
> usbm->urb_use_count++;
> }
> break;
> }
>
> (That's with the file's convention for continuation lines.)
Do
tand. You want to populate usbm (by calling
find_memory_area()) unconditionally, also for control transfers? I can't see
offhand another way to call it only once during the function, save for a bool
that says if we called it or not.
New patch attached. Note that I haven't had the chance to r
On Sat, Dec 05, 2015 at 05:12:03PM -0500, Alan Stern wrote:
> To tell the truth, I'm not sure whether it would be a problem or not.
> That's why I said it "may" not be a good idea.
Fair enough.
>>> You don't really need to do it earlier. An unnecessary calculation of
>>> num_sgs won't hurt.
On Thu, Dec 03, 2015 at 10:37:27AM -0500, Alan Stern wrote:
>> FWIW, I tried against >dev->bus->controller, and it didn't give me any
>> error messages, but still returns NULL.
> I'm at a loss.
Seemingly controller is already a pointer, so the & is redundant. No idea why
it didn't crash plain
On Thu, Dec 03, 2015 at 10:18:20PM +0100, Steinar H. Gunderson wrote:
> But you still think usb_alloc_coherent() is the better way to go? Should be
> easy enough to change, just let me know.
I must be doing something wrong, because I don't seem to get any frames
from my video capture, and
On Wed, Dec 02, 2015 at 10:54:52AM -0500, Alan Stern wrote:
>> [ 28.796244] DMAR: Allocating domain for 2-2 failed
> I don't know what the reason is for that. It may be that your kernel
> isn't configured to allocate as much coherent memory as you are asking
> for. We'll have to
On Thu, Dec 03, 2015 at 12:51:14AM +0100, Steinar H. Gunderson wrote:
> I'm thinking; maybe should the memory not be allocated against the USB
> device, but against the controller it hangs on? (Note that it complains about
> allocating the _domain_, not the memory itself.) Do you know
num_sgs = 0;
>> +}
> Braces aren't needed.
Went to the dentist to take them off.
> It looks odd repeating the "if (as->usbm)" test like this. You can merge
> the stuff here into the "else" clause of the preceding code.
Merged. Updated patch below.
/* Stein
On Wed, Dec 09, 2015 at 10:39:35AM -0500, Alan Stern wrote:
>> I can write documentation if you can point me to a reasonable place.
> The only documentation I know of for usbfs is a dreadfully out-of-date
> section in Documentation/DocBook/usb.tmpl.
I don't volunteer to get your documentation in
Software Engineer, Google Switzerland
>From 659c4025a0e182a1a205fc4d945a68b8cb3602f0 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" <se...@google.com>
Date: Thu, 26 Nov 2015 01:19:13 +0100
Subject: [PATCH] Add support for usbfs zerocopy.
To: Greg Kroah-Hartman <gre...@linuxfound
On Mon, Jan 04, 2016 at 01:42:06AM +0100, Markus Rechberger wrote:
> Don't expect anyone else seriously testing this interface aside of me
> and Steinar.
FWIW, I got an email from the OpenKinect people, who are (as far as I know)
currently testing the patch together with my libusb-1.0 patch. It
On Wed, Jan 06, 2016 at 04:22:12PM +0100, Peter Stuge wrote:
>>> Our interface for zero copy reads/writes is O_DIRECT, and that requires
>>> not special memory allocation, just proper alignment.
>> But that assumes you are using I/O using read()/write(). There's no way you
>> can shoehorn USB
On Tue, Jan 05, 2016 at 10:49:49PM -0800, Christoph Hellwig wrote:
> This is a completely broken usage of the mmap interface. if you use
> mmap on a device file you must use the actual mmap for the data
> transfer.
Really? V4L does exactly the same thing, from what I can see. It's just a way
of
On Tue, Jan 05, 2016 at 04:11:43PM -0800, Greg Kroah-Hartman wrote:
>> Add a new interface for userspace to preallocate memory that can be
>> used with usbfs. This gives two primary benefits:
> Please 'version' your patches, so that I have a chance to figure out
> what patch is what, and what
at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson <se...@google.com>
Signed-off-by: Markus Rechberger <mrechber...@gmail.com>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---
drivers/usb/core/devi
at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson <se...@google.com>
Signed-off-by: Markus Rechberger <mrechber...@gmail.com>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---
drivers/usb/core/devi
On Tue, Jan 05, 2016 at 04:31:09PM -0500, Alan Stern wrote:
> Thank you. So it looks like I was worried about nothing.
>
> Steinar, you can remove the try_module_get/module_put lines from your
> patch. Also, the list_del() and comment in usbdev_release() aren't
> needed -- at that point we
On Tue, Dec 15, 2015 at 03:32:45PM +, David Laight wrote:
> That still isn't entirely correct.
>
> Someone with more knowledge than either of us has needs to sort out
> how to handle this properly.
This discussion sort of stalled. Short of actually becoming a kernel VM
expert (not very
at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson <se...@google.com>
Signed-off-by: Markus Rechberger <mrechber...@gmail.com>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---
drivers/usb/core/devi
On Fri, Dec 25, 2015 at 09:50:50AM +0100, Oliver Neukum wrote:
> > + ret = usbfs_increase_memory_usage(size + sizeof(struct usb_memory));
> > + if (ret) {
> > + module_put(THIS_MODULE);
> > + return ret;
> > + }
>
> Could you do the error handling in
On Tue, Dec 22, 2015 at 10:38:57AM -0500, Alan Stern wrote:
> Steinar, you can look at those if you want to. But I really don't
> think anything more is needed other than the try_module_get and
> module_put calls. At least, the Linux Device Drivers book doesn't
> mention anything else.
OK.
at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson <se...@google.com>
Signed-off-by: Markus Rechberger <mrechber...@gmail.com>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---
drivers/usb/core/devi
On Fri, Dec 25, 2015 at 01:36:44PM -0500, Alan Stern wrote:
> That's okay; lots of drivers do this and people expect it. It also
> reduces the total amount of code.
Okay, fixed.
> > > > + mem = usb_alloc_coherent(ps->dev, size, GFP_KERNEL,
> > > > _handle);
> > > Shouldn't this be
On Wed, Nov 25, 2015 at 10:29:53AM -0500, Alan Stern wrote:
> I want to see a modified version of your patch. Several things need to
> be changed or fixed, but the major change needs to be the way memory is
> allocated. It should be done as part of the mmap system call, not as a
> separate
On Thu, Nov 26, 2015 at 01:26:32AM +0100, Steinar H. Gunderson wrote:
>> There are numerous smaller issues: The allocated memory needs to be
>> charged against usbfs_memory_usage
> I'll fix this.
Fixed in updated patch (attached).
> I'll fix this, too.
Also fixed.
Now als
ted memory
> rather than just at the beginning
I'll fix this, too.
> , and so on.
Clarification appreciated ;-)
/* Steinar */
--
Homepage: https://www.sesse.net/
>From 2bb0f7b91d41de0cbd1e8984612252d101fbb2ca Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" <se...@googl
On Tue, Nov 17, 2015 at 03:01:39PM -0500, Alan Stern wrote:
>> On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
>>> Is there an API for allocating user memory below 4 GB? Would a new
>>> MMAP flag be acceptable?
>> MAP_32BIT (to mmap) can seemingly do this, but from the man page, it
On Tue, Nov 17, 2015 at 03:16:55PM -0500, Alan Stern wrote:
>>> But what other way of allocating memory is there?
>> For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently
>> map up a chunk of GPU memory for you into userspace, but you have no
>> guarantees as of if it's
1 - 100 of 118 matches
Mail list logo