* Bugs in usb-skeleton.c??? :)
@ 2006-07-13 11:26 Sergej Pupykin
2006-07-13 11:58 ` Arjan van de Ven
0 siblings, 1 reply; 6+ messages in thread
From: Sergej Pupykin @ 2006-07-13 11:26 UTC (permalink / raw)
To: linux-kernel
Hello, All!
As I understand, USB subsystem uses urb->transfer_buffer directly with
DMA. I see that usb-skeleton.c and (at least) bluez's hci_usb allocates it
without GFP_DMA flag. (skeleton with GFP_KERNEL, bluez with GFP_ATOMIC)
(checked versions are 2.4.32 and 2.6.17, ohci only)
Please advise.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bugs in usb-skeleton.c??? :)
2006-07-13 11:26 Bugs in usb-skeleton.c??? :) Sergej Pupykin
@ 2006-07-13 11:58 ` Arjan van de Ven
2006-07-13 12:33 ` Sergej Pupykin
0 siblings, 1 reply; 6+ messages in thread
From: Arjan van de Ven @ 2006-07-13 11:58 UTC (permalink / raw)
To: Sergej Pupykin; +Cc: linux-kernel
On Thu, 2006-07-13 at 15:26 +0400, Sergej Pupykin wrote:
> Hello, All!
>
> As I understand, USB subsystem uses urb->transfer_buffer directly with
> DMA. I see that usb-skeleton.c and (at least) bluez's hci_usb allocates it
> without GFP_DMA flag. (skeleton with GFP_KERNEL, bluez with GFP_ATOMIC)
Hi,
I think GFP_DMA means something different than that you think it means.
GFP_DMA is a bad old hack that means "this is for ISA bus cards to DMA
to/from". Since there are no ISA bus USB controllers... the USB code
doesn't need to use GFP_DMA.
Greetings,
Arjan van de Ven
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bugs in usb-skeleton.c??? :)
2006-07-13 11:58 ` Arjan van de Ven
@ 2006-07-13 12:33 ` Sergej Pupykin
2006-07-13 13:00 ` Arjan van de Ven
0 siblings, 1 reply; 6+ messages in thread
From: Sergej Pupykin @ 2006-07-13 12:33 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel
>> As I understand, USB subsystem uses urb->transfer_buffer directly with
>> DMA. I see that usb-skeleton.c and (at least) bluez's hci_usb allocates it
>> without GFP_DMA flag. (skeleton with GFP_KERNEL, bluez with GFP_ATOMIC)
AvdV> I think GFP_DMA means something different than that you think it means.
AvdV> GFP_DMA is a bad old hack that means "this is for ISA bus cards to DMA
AvdV> to/from". Since there are no ISA bus USB controllers... the USB code
AvdV> doesn't need to use GFP_DMA.
Does kmalloc always allocate pages that can be used in DMA?
I see pci_map_single gives address that incremented later without page
boundary checking. Are allocated pages sequented? (usb-ohci.c)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bugs in usb-skeleton.c??? :)
2006-07-13 12:33 ` Sergej Pupykin
@ 2006-07-13 13:00 ` Arjan van de Ven
2006-07-13 13:10 ` Sergej Pupykin
0 siblings, 1 reply; 6+ messages in thread
From: Arjan van de Ven @ 2006-07-13 13:00 UTC (permalink / raw)
To: Sergej Pupykin; +Cc: linux-kernel
On Thu, 2006-07-13 at 16:33 +0400, Sergej Pupykin wrote:
> >> As I understand, USB subsystem uses urb->transfer_buffer directly with
> >> DMA. I see that usb-skeleton.c and (at least) bluez's hci_usb allocates it
> >> without GFP_DMA flag. (skeleton with GFP_KERNEL, bluez with GFP_ATOMIC)
>
> AvdV> I think GFP_DMA means something different than that you think it means.
> AvdV> GFP_DMA is a bad old hack that means "this is for ISA bus cards to DMA
> AvdV> to/from". Since there are no ISA bus USB controllers... the USB code
> AvdV> doesn't need to use GFP_DMA.
>
> Does kmalloc always allocate pages that can be used in DMA?
normally yes. HOWEVER....
>
> I see pci_map_single gives address that incremented later without page
> boundary checking. Are allocated pages sequented? (usb-ohci.c)
..it is nicer to use the DMA allocation API (which internally may fall
back to kmalloc etc), while kmalloc may work, it can be quite slow in
how it's made to work. So it's just nicer to just use the DMA memory
allocators... (see Documentation/DMA-API.txt file for a description of
this)
Greetings,
Arjan van de Ven
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bugs in usb-skeleton.c??? :)
2006-07-13 13:00 ` Arjan van de Ven
@ 2006-07-13 13:10 ` Sergej Pupykin
2006-07-13 14:24 ` Manuel Lauss
0 siblings, 1 reply; 6+ messages in thread
From: Sergej Pupykin @ 2006-07-13 13:10 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel
>> Does kmalloc always allocate pages that can be used in DMA?
AvdV> normally yes. HOWEVER....
I use sh4 cpu...
AvdV> ..it is nicer to use the DMA allocation API (which internally may fall
AvdV> back to kmalloc etc), while kmalloc may work, it can be quite slow in
AvdV> how it's made to work. So it's just nicer to just use the DMA memory
AvdV> allocators... (see Documentation/DMA-API.txt file for a description of
AvdV> this)
Thanks, I'll try it.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bugs in usb-skeleton.c??? :)
2006-07-13 13:10 ` Sergej Pupykin
@ 2006-07-13 14:24 ` Manuel Lauss
0 siblings, 0 replies; 6+ messages in thread
From: Manuel Lauss @ 2006-07-13 14:24 UTC (permalink / raw)
To: Sergej Pupykin; +Cc: Arjan van de Ven, linux-kernel
On Thu, Jul 13, 2006 at 05:10:20PM +0400, Sergej Pupykin wrote:
> >> Does kmalloc always allocate pages that can be used in DMA?
>
> AvdV> normally yes. HOWEVER....
>
> I use sh4 cpu...
on SH-4 traditionally the whole memory space is mapped all the
time, so any space returned by kmalloc is DMA-able.
(I don't know if this applies to the SH-4A core, too)
> AvdV> ..it is nicer to use the DMA allocation API (which internally may fall
> AvdV> back to kmalloc etc), while kmalloc may work, it can be quite slow in
> AvdV> how it's made to work. So it's just nicer to just use the DMA memory
> AvdV> allocators... (see Documentation/DMA-API.txt file for a description of
> AvdV> this)
agree
--
ml.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-07-13 14:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-13 11:26 Bugs in usb-skeleton.c??? :) Sergej Pupykin
2006-07-13 11:58 ` Arjan van de Ven
2006-07-13 12:33 ` Sergej Pupykin
2006-07-13 13:00 ` Arjan van de Ven
2006-07-13 13:10 ` Sergej Pupykin
2006-07-13 14:24 ` Manuel Lauss
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox