From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: DMA over USB
Date: Tue, 1 Jul 2014 23:25:29 -0700 [thread overview]
Message-ID: <20140702062529.GB2051@kroah.com> (raw)
In-Reply-To: <53B3A220.9020603@cdac.in>
On Wed, Jul 02, 2014 at 11:39:36AM +0530, Raghavendra wrote:
> On Wednesday 02 July 2014 11:42 AM, Greg KH wrote:
> >On Wed, Jul 02, 2014 at 11:32:47AM +0530, Raghavendra wrote:
> >>On Wednesday 02 July 2014 11:02 AM, Greg KH wrote:
> >>>On Tue, Jul 01, 2014 at 10:29:39PM -0700, Greg KH wrote:
> >>>>On Wed, Jul 02, 2014 at 10:40:21AM +0530, Raghavendra wrote:
> >>>>>Hello,
> >>>>>
> >>>>>I have a query regarding DMA(Direct Memory Access) for the usb devices.
> >>>>>
> >>>>>The understanding of DMA actions over PCI is straight forward. PCI
> >>>>>devices support bus mastering capability, such that the PCI devices
> >>>>>could take the ownership of the bus and perform access to the memory
> >>>>>directly, and a software support exists for the same in Linux.
> >>>>>
> >>>>>As far as USB devices are concerned, they don?t have the bus mastering
> >>>>>capability like the PCI devices.
> >>>>>But the USB URB structure have a field named 'dma_addr_t transfer_dma',
> >>>>>used for DMA access. The USB driver allocate the DMA buffers coherently
> >>>>>and pass the DMA address to the URBs during its initialization.
> >>>>>As far as Linux is concerned, how the DMA action being taking place for
> >>>>>USB devices. As per my understanding, the USB host controller is taking
> >>>>>care of the DMA operations. But I require a little more insight into it.
> >>>>Why, what exactly are you concerned about? What are you trying to do?
> >>>Also, you _have_ read the USB DMA documentation, right?
> >>>
> >>>What about the documentation in this area is unclear?
> >>Yes, I have read the documentation and its fine. I am mostly concerned about
> >>the all the heavy lifting happening in the background.
> >Why? What exactly are you "concerned" about? What hardware controller?
> >Is something not working properly?
> Everything is fine. This is more of a theoretical understanding.
The code is there for your theoretical research :)
next prev parent reply other threads:[~2014-07-02 6:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 5:10 DMA over USB Raghavendra
2014-07-02 5:25 ` Mandeep Sandhu
2014-07-02 5:29 ` Greg KH
2014-07-02 5:32 ` Greg KH
2014-07-02 6:02 ` Raghavendra
2014-07-02 6:12 ` Greg KH
2014-07-02 6:09 ` Raghavendra
2014-07-02 6:25 ` Greg KH [this message]
2014-07-02 6:29 ` Raghavendra
2014-07-02 5:35 ` Chan Kim
2014-07-02 6:12 ` Raghavendra
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=20140702062529.GB2051@kroah.com \
--to=greg@kroah.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).