From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
alsa-devel@alsa-project.org, linux-usb@vger.kernel.org,
tiwai@suse.de, gregkh@suse.de, clemens@ladisch.de,
linux-kernel@vger.kernel.org, chrisw@sous-sol.org,
iommu@lists.linux-foundation.org, andi@firstfloor.org,
daniel@caiaq.de, pedrib@gmail.com, akpm@linux-foundation.org,
dwmw2@infradead.org
Subject: Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems
Date: Tue, 11 May 2010 10:24:40 -0400 [thread overview]
Message-ID: <20100511142439.GA4898@phenom.dumpdata.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1005110956330.1834-100000@iolanthe.rowland.org>
> > > Either the data isn't getting written to the buffer correctly or else
> > > the buffer isn't getting sent to the device correctly. Can anybody
> > > suggest a means of determining which is the case?
> >
> > I can't say anything about this log that including only DMA addresses.
> > I'm not familiar with how the USB core does DMA stuff. And the USB
> > stack design that the USB core does DMA stuff (allocating, mappings,
> > etc) makes debugging DMA issues really difficult.
>
> The DMA stuff is simple enough in this case. The urb->transfer_buffer
> address is passed to dma_map_single(), and the DMA address it returns
> is stored in urb->transfer_dma. Those are the two values printed out
> by the debugging patch.
Is that address (urb->transfer_dma) the same as 'virt_to_phys(urb->transfer_buffer)'
(if not, then SWIOTLB is being utilized) and is the dma_sync_* done on the
urb->transfer_dma (to properly sync the data from the SWIOTLB to the
transfer_buffer) before you start using the urb->transfer_buffer?
next prev parent reply other threads:[~2010-05-11 14:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <g2h74fd948d1004141820ladc1941eo732d059dd678df0a@mail.gmail.com>
[not found] ` <Pine.LNX.4.44L0.1004151114490.1562-100000@iolanthe.rowland.org>
[not found] ` <t2r74fd948d1004191716l49dedc2p25a27da39bcc614a@mail.gmail.com>
2010-05-07 7:48 ` USB transfer_buffer allocations on 64bit systems Daniel Mack
2010-05-07 9:47 ` Clemens Ladisch
2010-05-07 10:24 ` Daniel Mack
2010-05-07 14:51 ` [alsa-devel] " Alan Stern
2010-05-10 2:50 ` FUJITA Tomonori
2010-05-10 9:21 ` David Woodhouse
[not found] ` <1273483265.372.3383.camel-uXGAPMMVk8bAQYKIod7YupZV94DADvEd@public.gmane.org>
2010-05-10 14:58 ` [alsa-devel] " Alan Stern
[not found] ` <Pine.LNX.4.44L0.1005101049100.1626-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2010-05-11 1:06 ` FUJITA Tomonori
[not found] ` <20100511100637D.fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2010-05-11 14:00 ` Alan Stern
2010-05-11 14:22 ` FUJITA Tomonori
2010-05-11 14:24 ` Konrad Rzeszutek Wilk [this message]
2010-05-11 14:38 ` FUJITA Tomonori
2010-05-11 15:04 ` Alan Stern
2010-05-11 15:34 ` FUJITA Tomonori
[not found] ` <20100507102408.GM30801-ahpEBR4enfnCULTFXS99ULNAH6kLmebB@public.gmane.org>
2010-05-10 14:31 ` Konrad Rzeszutek Wilk
[not found] ` <4BE3E1B9.5020602-P6GI/4k7KOmELgA04lAiVw@public.gmane.org>
2010-05-07 11:42 ` Oliver Neukum
[not found] ` <201005071342.34923.oneukum-l3A5Bk7waGM@public.gmane.org>
2010-05-07 11:47 ` Oliver Neukum
2010-05-07 11:58 ` Daniel Mack
[not found] ` <20100507115810.GN30801-ahpEBR4enfnCULTFXS99ULNAH6kLmebB@public.gmane.org>
2010-05-07 14:45 ` [alsa-devel] " Alan Stern
2010-04-07 17:55 Takashi Iwai
2010-04-07 19:13 ` Alan Stern
2010-04-08 0:33 ` Greg KH
2010-04-09 0:01 ` Robert Hancock
2010-04-09 16:50 ` Sarah Sharp
2010-04-09 23:38 ` Robert Hancock
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:58 ` Sarah Sharp
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=20100511142439.GA4898@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alsa-devel@alsa-project.org \
--cc=andi@firstfloor.org \
--cc=chrisw@sous-sol.org \
--cc=clemens@ladisch.de \
--cc=daniel@caiaq.de \
--cc=dwmw2@infradead.org \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=gregkh@suse.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pedrib@gmail.com \
--cc=stern@rowland.harvard.edu \
--cc=tiwai@suse.de \
/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).