From: Daniel Mack <daniel@caiaq.de> To: Andi Kleen <andi@firstfloor.org> Cc: Alan Stern <stern@rowland.harvard.edu>, Pedro Ribeiro <pedrib@gmail.com>, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, Greg KH <gregkh@suse.de>, alsa-devel@alsa-project.org, linux-usb@vger.kernel.org Subject: Re: USB transfer_buffer allocations on 64bit systems Date: Mon, 12 Apr 2010 19:56:09 +0200 [thread overview] Message-ID: <20100412175609.GC30801@buzzloop.caiaq.de> (raw) In-Reply-To: <20100412172233.GR18855@one.firstfloor.org> On Mon, Apr 12, 2010 at 07:22:33PM +0200, Andi Kleen wrote: > On Mon, Apr 12, 2010 at 07:15:07PM +0200, Daniel Mack wrote: > > Given that - at least for non-64-aware host controllers - we want memory > > <4GB anyway for USB transfers to avoid DMA bouncing buffers, maybe we > > should just do that and fix the problem at this level? I already started > > to implement usb_[mz]alloc() and use it in some USB drivers. > > If the area is not mapped correctly it will fail in other situations, > e.g. with an IOMMU active or in virtualized setups. So the bug > has to be eventually tracked down. Ok, agreed. But we all agree to the fact that we need an interface for such allocations to avoid bounce buffers? If that is the case, we could already start to implement that while we're tracking down the actual bug. [...] > > Can anyone explain which is the right way to go? > > The right thing would be to define a proper interface for it. > > I had an attempt for it a couple of years ago with the mask allocator, > but it didn't make it into the tree. Any plans to continue on this? Or can you dig it out again so others can pick up the idea? Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Mack <daniel@caiaq.de> To: Andi Kleen <andi@firstfloor.org> Cc: alsa-devel@alsa-project.org, linux-usb@vger.kernel.org, Greg KH <gregkh@suse.de>, linux-kernel@vger.kernel.org, Alan Stern <stern@rowland.harvard.edu>, Pedro Ribeiro <pedrib@gmail.com>, akpm@linux-foundation.org Subject: Re: USB transfer_buffer allocations on 64bit systems Date: Mon, 12 Apr 2010 19:56:09 +0200 [thread overview] Message-ID: <20100412175609.GC30801@buzzloop.caiaq.de> (raw) In-Reply-To: <20100412172233.GR18855@one.firstfloor.org> On Mon, Apr 12, 2010 at 07:22:33PM +0200, Andi Kleen wrote: > On Mon, Apr 12, 2010 at 07:15:07PM +0200, Daniel Mack wrote: > > Given that - at least for non-64-aware host controllers - we want memory > > <4GB anyway for USB transfers to avoid DMA bouncing buffers, maybe we > > should just do that and fix the problem at this level? I already started > > to implement usb_[mz]alloc() and use it in some USB drivers. > > If the area is not mapped correctly it will fail in other situations, > e.g. with an IOMMU active or in virtualized setups. So the bug > has to be eventually tracked down. Ok, agreed. But we all agree to the fact that we need an interface for such allocations to avoid bounce buffers? If that is the case, we could already start to implement that while we're tracking down the actual bug. [...] > > Can anyone explain which is the right way to go? > > The right thing would be to define a proper interface for it. > > I had an attempt for it a couple of years ago with the mask allocator, > but it didn't make it into the tree. Any plans to continue on this? Or can you dig it out again so others can pick up the idea? Daniel
next prev parent reply other threads:[~2010-04-12 17:56 UTC|newest] Thread overview: 221+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-04-07 9:06 USB transfer_buffer allocations on 64bit systems Daniel Mack 2010-04-07 9:06 ` Daniel Mack [not found] ` <p2g581ef6d61004070220z1153d40ez955b356e01220848@mail.gmail.com> 2010-04-07 9:26 ` USB HID gadget driver (was: Re: USB transfer_buffer allocations on 64bit systems) Daniel Mack 2010-04-07 9:26 ` Daniel Mack 2010-04-07 14:59 ` USB transfer_buffer allocations on 64bit systems Alan Stern 2010-04-07 14:59 ` Alan Stern 2010-04-07 15:11 ` Daniel Mack 2010-04-07 15:11 ` Daniel Mack 2010-04-07 15:31 ` Greg KH 2010-04-07 15:31 ` Greg KH 2010-04-07 15:35 ` Daniel Mack 2010-04-07 15:35 ` Daniel Mack 2010-04-07 15:51 ` Greg KH 2010-04-07 15:51 ` Greg KH 2010-04-07 16:04 ` Alan Stern 2010-04-07 16:04 ` Alan Stern 2010-04-08 6:09 ` Oliver Neukum 2010-04-08 11:07 ` Daniel Mack 2010-04-08 11:07 ` Daniel Mack 2010-04-07 15:55 ` Alan Stern 2010-04-07 15:55 ` Alan Stern 2010-04-07 16:16 ` Daniel Mack 2010-04-07 16:16 ` Daniel Mack 2010-04-07 16:47 ` Alan Stern 2010-04-07 16:47 ` Alan Stern 2010-04-07 17:55 ` Takashi Iwai 2010-04-07 17:55 ` Takashi Iwai 2010-04-07 17:59 ` Daniel Mack 2010-04-07 17:59 ` Daniel Mack 2010-04-07 18:06 ` Takashi Iwai 2010-04-07 18:06 ` Takashi Iwai 2010-04-07 19:13 ` Alan Stern 2010-04-07 19:13 ` Alan Stern 2010-04-07 23:59 ` Robert Hancock 2010-04-07 23:59 ` Robert Hancock 2010-04-08 0:33 ` Greg KH 2010-04-08 0:33 ` Greg KH 2010-04-09 0:01 ` Robert Hancock 2010-04-09 16:50 ` Sarah Sharp 2010-04-09 16:50 ` Sarah Sharp 2010-04-09 23:38 ` Robert Hancock 2010-04-09 23:38 ` Robert Hancock 2010-04-10 8:34 ` [alsa-devel] " Daniel Mack 2010-04-10 8:34 ` Daniel Mack 2010-04-10 17:02 ` [alsa-devel] " Robert Hancock 2010-04-12 18:56 ` Sarah Sharp 2010-04-12 20:39 ` Robert Hancock 2010-04-12 20:39 ` Robert Hancock 2010-04-12 20:58 ` Sarah Sharp 2010-04-12 11:17 ` [PATCH] USB: rename usb_buffer_alloc() and usb_buffer_free() Daniel Mack 2010-04-12 11:17 ` Daniel Mack 2010-04-13 18:16 ` Daniel Mack 2010-04-13 18:16 ` Daniel Mack 2010-04-13 19:27 ` Alan Stern 2010-04-13 19:27 ` Alan Stern 2010-04-13 20:26 ` Greg KH 2010-04-13 21:47 ` Daniel Mack 2010-04-13 21:47 ` Daniel Mack 2010-04-07 17:52 ` USB transfer_buffer allocations on 64bit systems Takashi Iwai 2010-04-07 17:52 ` Takashi Iwai 2010-04-07 15:46 ` Alan Stern 2010-04-07 15:46 ` Alan Stern 2010-04-08 6:12 ` Oliver Neukum 2010-04-08 16:59 ` Alan Stern 2010-04-08 16:59 ` Alan Stern 2010-04-08 21:24 ` Oliver Neukum 2010-04-08 22:20 ` Alan Stern 2010-04-08 22:20 ` Alan Stern 2010-04-09 6:04 ` Oliver Neukum 2010-04-09 14:41 ` Alan Stern 2010-04-09 14:41 ` Alan Stern 2010-04-09 14:50 ` Oliver Neukum 2010-04-09 14:50 ` Oliver Neukum 2010-04-09 15:15 ` Alan Stern 2010-04-09 15:15 ` Alan Stern 2010-04-09 20:51 ` Oliver Neukum 2010-04-09 20:51 ` Oliver Neukum 2010-04-09 21:21 ` Alan Stern 2010-04-09 21:21 ` Alan Stern 2010-04-07 16:54 ` Oliver Neukum 2010-04-07 16:54 ` Oliver Neukum 2010-04-07 17:00 ` Daniel Mack 2010-04-07 17:00 ` Daniel Mack 2010-04-07 23:55 ` Robert Hancock 2010-04-07 23:55 ` Robert Hancock 2010-04-08 2:10 ` Alan Stern 2010-04-08 2:10 ` Alan Stern 2010-04-08 7:30 ` Daniel Mack 2010-04-08 7:30 ` Daniel Mack 2010-04-08 16:57 ` Alan Stern 2010-04-08 16:57 ` Alan Stern 2010-04-08 17:17 ` Pedro Ribeiro 2010-04-08 18:17 ` Alan Stern 2010-04-08 23:13 ` Pedro Ribeiro 2010-04-08 23:13 ` Pedro Ribeiro 2010-04-09 16:01 ` Alan Stern 2010-04-09 16:01 ` Alan Stern 2010-04-09 18:09 ` Daniel Mack 2010-04-09 18:19 ` Pedro Ribeiro 2010-04-09 18:19 ` Pedro Ribeiro 2010-04-09 19:34 ` Alan Stern 2010-04-09 19:34 ` Alan Stern 2010-04-09 20:14 ` Daniel Mack 2010-04-09 20:14 ` Daniel Mack 2010-04-09 20:25 ` [LKML] " Konrad Rzeszutek Wilk 2010-04-09 20:25 ` Konrad Rzeszutek Wilk 2010-04-09 21:23 ` Alan Stern 2010-04-09 21:23 ` Alan Stern 2010-04-09 22:11 ` Robert Hancock 2010-04-12 10:48 ` Daniel Mack 2010-04-12 10:48 ` Daniel Mack 2010-04-12 12:06 ` Pedro Ribeiro 2010-04-10 12:49 ` Daniel Mack 2010-04-10 12:49 ` Daniel Mack 2010-04-10 13:21 ` Pedro Ribeiro 2010-04-10 13:21 ` Pedro Ribeiro 2010-04-12 8:59 ` Andi Kleen 2010-04-12 8:59 ` Andi Kleen 2010-04-12 11:14 ` Daniel Mack 2010-04-12 11:14 ` Daniel Mack 2010-04-12 11:53 ` Andi Kleen 2010-04-12 11:53 ` Andi Kleen 2010-04-12 12:11 ` Pedro Ribeiro 2010-04-12 12:12 ` Andi Kleen 2010-04-12 12:12 ` Andi Kleen 2010-04-12 12:32 ` Daniel Mack 2010-04-12 12:47 ` Andi Kleen 2010-04-12 12:54 ` Daniel Mack 2010-04-12 12:54 ` Daniel Mack 2010-04-12 15:43 ` Andi Kleen 2010-04-12 16:17 ` Alan Stern 2010-04-12 16:17 ` Alan Stern 2010-04-12 16:29 ` Andi Kleen 2010-04-12 16:57 ` Alan Stern 2010-04-12 16:57 ` Alan Stern 2010-04-12 17:15 ` Daniel Mack 2010-04-12 17:15 ` Daniel Mack 2010-04-12 17:22 ` Andi Kleen 2010-04-12 17:22 ` Andi Kleen 2010-04-12 17:56 ` Daniel Mack [this message] 2010-04-12 17:56 ` Daniel Mack 2010-04-12 17:52 ` [LKML] " Konrad Rzeszutek Wilk 2010-04-12 17:52 ` Konrad Rzeszutek Wilk 2010-04-13 18:22 ` Daniel Mack 2010-04-13 18:22 ` Daniel Mack 2010-04-13 23:46 ` Pedro Ribeiro 2010-04-13 23:46 ` Pedro Ribeiro 2010-04-14 10:09 ` Daniel Mack 2010-04-14 10:09 ` Daniel Mack 2010-04-14 10:47 ` Pedro Ribeiro 2010-04-14 11:02 ` Pedro Ribeiro 2010-04-14 13:18 ` [LKML] " Konrad Rzeszutek Wilk 2010-04-14 14:08 ` Alan Stern 2010-04-14 14:08 ` Alan Stern 2010-04-14 16:36 ` Daniel Mack 2010-04-14 16:36 ` Daniel Mack 2010-04-14 17:21 ` Pedro Ribeiro 2010-04-14 17:21 ` Pedro Ribeiro 2010-04-14 18:23 ` Alan Stern 2010-04-14 18:27 ` Pedro Ribeiro 2010-04-14 18:53 ` Alan Stern 2010-04-15 7:35 ` Daniel Mack 2010-04-15 7:35 ` Daniel Mack 2010-04-14 18:15 ` Alan Stern 2010-04-14 18:36 ` David Woodhouse 2010-04-14 21:12 ` Pedro Ribeiro 2010-04-14 22:25 ` Chris Wright 2010-04-14 22:56 ` Pedro Ribeiro 2010-04-14 23:37 ` Chris Wright 2010-04-15 1:20 ` Pedro Ribeiro 2010-04-15 15:20 ` Alan Stern 2010-04-20 0:16 ` Pedro Ribeiro 2010-05-07 7:48 ` Daniel Mack 2010-05-07 7:48 ` Daniel Mack 2010-05-07 9:47 ` [alsa-devel] " Clemens Ladisch 2010-05-07 9:47 ` Clemens Ladisch 2010-05-07 10:24 ` [alsa-devel] " Daniel Mack 2010-05-07 10:24 ` Daniel Mack 2010-05-07 14:51 ` [alsa-devel] " Alan Stern 2010-05-07 14:51 ` Alan Stern 2010-05-10 2:50 ` FUJITA Tomonori 2010-05-10 9:21 ` David Woodhouse 2010-05-10 9:21 ` David Woodhouse 2010-05-10 14:58 ` [alsa-devel] " Alan Stern 2010-05-10 14:58 ` Alan Stern 2010-05-11 1:06 ` FUJITA Tomonori 2010-05-11 1:06 ` FUJITA Tomonori 2010-05-11 14:00 ` Alan Stern 2010-05-11 14:00 ` Alan Stern 2010-05-11 14:22 ` FUJITA Tomonori 2010-05-11 14:24 ` Konrad Rzeszutek Wilk 2010-05-11 14:38 ` FUJITA Tomonori 2010-05-11 15:04 ` Alan Stern 2010-05-11 15:04 ` Alan Stern 2010-05-11 15:34 ` FUJITA Tomonori 2010-05-11 16:06 ` Alan Stern 2010-05-11 16:09 ` Daniel Mack 2010-05-11 16:48 ` Pedro Ribeiro 2010-05-11 17:10 ` Daniel Mack 2010-05-11 17:32 ` Pedro Ribeiro 2010-05-11 17:38 ` Daniel Mack 2010-05-12 23:50 ` Pedro Ribeiro 2010-05-13 9:36 ` Daniel Mack 2010-05-14 0:17 ` Pedro Ribeiro 2010-05-11 14:57 ` Alan Stern 2010-05-11 15:05 ` Daniel Mack 2010-05-10 14:31 ` Konrad Rzeszutek Wilk 2010-05-10 14:31 ` Konrad Rzeszutek Wilk 2010-05-07 11:42 ` Oliver Neukum 2010-05-07 11:42 ` Oliver Neukum 2010-05-07 11:47 ` Oliver Neukum 2010-05-07 11:47 ` Oliver Neukum 2010-05-07 11:58 ` Daniel Mack 2010-05-07 11:58 ` Daniel Mack 2010-05-07 14:45 ` [alsa-devel] " Alan Stern 2010-05-07 14:45 ` Alan Stern 2010-04-14 18:38 ` Chris Wright 2010-04-14 20:29 ` Alan Stern 2010-04-14 21:01 ` Konrad Rzeszutek Wilk 2010-04-14 21:12 ` Pedro Ribeiro 2010-04-15 1:50 ` Alan Stern
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100412175609.GC30801@buzzloop.caiaq.de \ --to=daniel@caiaq.de \ --cc=akpm@linux-foundation.org \ --cc=alsa-devel@alsa-project.org \ --cc=andi@firstfloor.org \ --cc=gregkh@suse.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=pedrib@gmail.com \ --cc=stern@rowland.harvard.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.