Messages in this thread | | | From | (Krzysztof Hałasa) | Date | Fri, 09 Aug 2013 13:38:21 +0200 | Subject | Re: DMA masks |
| |
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
| |