From: khalasa@piap.pl (Krzysztof Hałasa)
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org,
James Bottomley <JBottomley@Parallels.com>,
"David S. Miller" <davem@davemloft.net>,
Bjorn Helgaas <bhelgaas@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: DMA masks
Date: Fri, 09 Aug 2013 13:38:21 +0200 [thread overview]
Message-ID: <m338qjgklu.fsf@t19.piap.pl> (raw)
In-Reply-To: <20130809104852.GQ23006@n2100.arm.linux.org.uk> (Russell King's message of "Fri, 9 Aug 2013 11:48:52 +0100")
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> No. If dma_mask is NULL, then dma_set_mask() will return -EIO no matter
> what. If dma_mask is non-NULL, dma_set_mask() will succeed if the mask
> is supported by the hardware. For example, on x86:
> and this is the same pattern we implement on ARM. So, a valid dma_mask
> pointer pointing at a variable holding zero can have a supported mask
> set.
Right. So is it a work around systems unable to provide DMA to devices,
whose drivers would try to use the DMA (not aware of the system
limitations)?
Do you know, by chance, of any particular case using this NULL pointer
trick to prevent (I suppose) a driver from doing DMA?
> Have you looked at my massive dma-masks patch series earlier this week?
> Obviously you haven't...
Right again, no time for basically anything here :-( Will look.
> The separate coherent and streaming masks are only required for a very
> small subset of devices (rather systems - non-ARM I add). For the
> general case, especially on ARM where the above pattern seems to be
> very prevalent, this does not apply; the two masks are always the same.
> Many people took the above shortcut, and while not strictly correct, it
> is a work-around for the shortcoming in the core device code.
That's my impression, too. BTW I personally have a device (PCI card)
which have different masks (so it's also the case with devices). Old
story though.
> Greg has agreed to having stream_dma_mask in the struct device, but
> even so I think removing the direct initialization from drivers is a good
> idea.
Definitely. I'll take a look, Thanks.
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
next prev parent reply other threads:[~2013-08-09 11:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m3fvujgrcr.fsf@t19.piap.pl>
2013-08-09 9:35 ` DMA masks Russell King - ARM Linux
2013-08-09 10:34 ` Krzysztof Hałasa
2013-08-09 10:48 ` Russell King - ARM Linux
2013-08-09 11:38 ` Krzysztof Hałasa [this message]
2013-08-09 14:56 ` 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=m338qjgklu.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=JBottomley@Parallels.com \
--cc=bhelgaas@google.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/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