David Brownell wrote:
On Thursday 07 October 2004 9:32 am, Feyd wrote:
Are the usb controllers s/g capable?
For some definitions of s/g, yes...
What are the definitions? s/g on pages would be enough.
If so, the usb_buffer_alloc could
use vmalloc for high order allocations.
... no, because if
On Thursday 07 October 2004 9:32 am, Feyd wrote:
>
> Are the usb controllers s/g capable?
For some definitions of s/g, yes...
> If so, the usb_buffer_alloc could
> use vmalloc for high order allocations.
... no, because if you read Documentation/DMA-mapping.txt
you'll see an informative "Wh
Am Donnerstag, 7. Oktober 2004 18:32 schrieb Feyd:
> Oliver Neukum wrote:
> > Am Donnerstag, 7. Oktober 2004 16:26 schrieb Duncan Sands:
> >
> >>>And would be quite wrong. The 2.6 code allows users to trigger
> >>>an allocation of 32K in kernel space. The impact on the VM can be
> >>>dreadful. If
Oliver Neukum wrote:
Am Donnerstag, 7. Oktober 2004 16:26 schrieb Duncan Sands:
And would be quite wrong. The 2.6 code allows users to trigger
an allocation of 32K in kernel space. The impact on the VM can be
dreadful. If anything you should port Manuel's code to 2.6.
Don't you mean 16k? Also, did
Am Donnerstag, 7. Oktober 2004 16:26 schrieb Duncan Sands:
> > And would be quite wrong. The 2.6 code allows users to trigger
> > an allocation of 32K in kernel space. The impact on the VM can be
> > dreadful. If anything you should port Manuel's code to 2.6.
>
> Don't you mean 16k? Also, did you
> And would be quite wrong. The 2.6 code allows users to trigger
> an allocation of 32K in kernel space. The impact on the VM can be
> dreadful. If anything you should port Manuel's code to 2.6.
Don't you mean 16k? Also, did you really see a bad effect in practice?
If so, proc_submiturb should be
Am Donnerstag, 7. Oktober 2004 14:52 schrieb Duncan Sands:
> On Thursday 07 October 2004 14:33, Manuel Odendahl wrote:
> > Hi!
> >
> > On Thu, 7 Oct 2004, Duncan Sands wrote:
> > > Surely you are confusing with control transfers?
> >
> > This is the code that I have in proc_bulk in the 2.4.26 ker
On Thu, 7 Oct 2004, Manuel Odendahl wrote:
> Here is the new patch.
I forgot to attach the file, sorry.
Manuel--- devio-old.c Thu Oct 7 14:27:00 2004
+++ devio.c Thu Oct 7 14:23:28 2004
@@ -19,7 +19,7 @@
* along with this program; if not, write to the Free Software
* Foundatio
On Thursday 07 October 2004 14:33, Manuel Odendahl wrote:
> Hi!
>
> On Thu, 7 Oct 2004, Duncan Sands wrote:
> > Surely you are confusing with control transfers?
>
> This is the code that I have in proc_bulk in the 2.4.26 kernel:
>
> ...
>if (len1 > PAGE_SIZE)
> return -EINVAL;
>if
On Thursday 07 October 2004 13:57, Oliver Neukum wrote:
> Am Donnerstag, 7. Oktober 2004 12:52 schrieb Duncan Sands:
> > > For example, in order to do a 64k BULK OUT transfer, assuming an
> > > endpoint maxPacketSize of 32 bytes, I had to do 2048 ioctls, each
> > > triggering a context switch.
> >
Hi!
On Thu, 7 Oct 2004, Duncan Sands wrote:
> No, you do one ioctl, sending 64k. The host controller will indeed
> send it in 32 byte bits, but that's not your problem.
As Duncan pointed out, my approach was badly flawed, as indeed
partitioning the bulk request in the kernel instead of leaving i
Am Donnerstag, 7. Oktober 2004 12:52 schrieb Duncan Sands:
> > For example, in order to do a 64k BULK OUT transfer, assuming an
> > endpoint maxPacketSize of 32 bytes, I had to do 2048 ioctls, each
> > triggering a context switch.
>
> No, you do one ioctl, sending 64k. The host controller will in
Am Donnerstag, 7. Oktober 2004 11:13 schrieb Manuel Odendahl:
> The patch was applied onto a 2.4.26 kernel, and does not apply to a 2.6
> kernel, but should be no problem to adapt. The changes itself are pretty
> trivial, the proc_bulk function now makes use of proc_bulk_read and
> proc_bulk_write
> For example, in order to do a 64k BULK OUT transfer, assuming an
> endpoint maxPacketSize of 32 bytes, I had to do 2048 ioctls, each
> triggering a context switch.
No, you do one ioctl, sending 64k. The host controller will indeed
send it in 32 byte bits, but that's not your problem.
All the b
Hi!
I am accessing USB devices through the usbdevfs filesystem. I have to do
a lot of big bulk transfers in a very short time frame, and stumbled
upon the limitation that each IOCTL_USB_BULK ioctl could only trigger a
single usb BULK transfer.
For example, in order to do a 64k BULK OUT transfer,
15 matches
Mail list logo
