From: David Brownell <david-b@pacbell.net>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: James.bottomley@steeleye.com, linux-kernel@vger.kernel.org,
manfred@colorfulllife.com
Subject: Re: [RFT][PATCH] generic device DMA implementation
Date: Sat, 28 Dec 2002 08:59:56 -0800 [thread overview]
Message-ID: <3E0DD88C.5080708@pacbell.net> (raw)
In-Reply-To: 200212281541.HAA00512@baldur.yggdrasil.com
Hi,
>>>>Isn't the goal to make sure that for every kind of "struct device *"
> ^^^^^
>>>>it should be possible to use those dma_*() calls, without BUGging
>>>>out.
>>That sounds like a "yes", not a "no" ... except for devices on busses
> ^^^^^^
> Then it's not "every", which was your question. I guess I need
> to understand better how to interpret your questions.
My bad ... I meant "every" kind of device doing memory mapped I/O, which
is all that had been mentioned so far. This needs to work on more than
just the "platform bus"; "layered busses" shouldn't need special casing,
they are just as common. You had mentioned SCSI busses; USB, FireWire,
and others also exist. (Though I confess I still don't like BUG() as a
way to fail much of anything!)
That's likely a better way to present one of my points: if it's "generic",
then it must work on more than just the lowest level platform bus.
>>that don't have do memory mapped I/O. It's what I described: dma_*()
>>calls being used with struct device, without BUGging out.
>
>
> Let's see if we agree. The behavior I expect is:
>
> addr = dma_malloc(&some_usb_device->dev,size, &dma_addr,DMA_CONSISTENT)
> ===> BUG()
That's not consistent with what I thought what you said. USB devices
use memory mapped I/O, so this should work. (And using BUG instead
of returning null still seems wrong...)
However, we could agree that some kind of dma_malloc() should exist !!
> addr = dma_malloc(host_dev(some_usb_device), &dma_addr, DMA_CONSISTENT)
> ===> some consistent memory (or NULL).
>
> where host_dev would be something like:
>
> struct device *host_dev(struct usb_device *usbdev)
> {
> struct usb_hcd *hcd = usbdev->bus->hcpriv;
> return &hcd->pdev->device; /* actually, this would become &hcd->dev */
> }
Please look at the 2.5.53 tree with my "usbcore dma updates (and doc)"
patch, which Greg has now merged and submitted to Linus.
The pre-existing USB DMA API syntax did not change, so it looks only
"something" like what you wrote there.
- Dave
next prev parent reply other threads:[~2002-12-28 16:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-28 15:41 [RFT][PATCH] generic device DMA implementation Adam J. Richter
2002-12-28 16:59 ` David Brownell [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-28 22:19 Adam J. Richter
2002-12-30 23:23 ` David Brownell
2002-12-28 20:11 Adam J. Richter
2002-12-28 3:39 Adam J. Richter
2002-12-30 0:45 ` Alan Cox
2002-12-28 2:48 Adam J. Richter
2002-12-28 15:05 ` David Brownell
2002-12-27 22:57 Manfred Spraul
2002-12-27 23:55 ` James Bottomley
2002-12-28 0:20 ` Manfred Spraul
2002-12-28 16:26 ` James Bottomley
2002-12-28 17:54 ` Manfred Spraul
2002-12-28 18:13 ` James Bottomley
2002-12-28 18:25 ` Manfred Spraul
2002-12-28 18:40 ` James Bottomley
2002-12-28 20:05 ` Manfred Spraul
2002-12-27 20:21 David Brownell
2002-12-27 21:40 ` James Bottomley
2002-12-28 1:29 ` David Brownell
2002-12-28 16:18 ` James Bottomley
2002-12-28 18:16 ` David Brownell
2002-12-28 1:56 ` David Brownell
2002-12-28 16:13 ` James Bottomley
2002-12-28 17:41 ` David Brownell
2002-12-27 21:47 ` James Bottomley
2002-12-28 2:28 ` David Brownell
2002-12-18 3:01 James Bottomley
2002-12-18 3:13 ` David Mosberger
2002-12-28 18:14 ` Russell King
2002-12-28 18:19 ` James Bottomley
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=3E0DD88C.5080708@pacbell.net \
--to=david-b@pacbell.net \
--cc=James.bottomley@steeleye.com \
--cc=adam@yggdrasil.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfulllife.com \
/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: link
Be 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.