On 6 June 2018 at 22:32, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote: >> On Tue, May 08, 2018 at 03:38:05PM +0000, Luis R. Rodriguez wrote: >> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: >> > > >> > > I think the Qualcomm folks owning this (Andy, David, Bjorn, already >> > > cc'd here) are better suited to answer that question. >> > >> > Andy, David, Bjorn? >> >> Andy, David, Bjorn? > > A month now with no answer... > > Perhaps someone who has this hardware can find out empirically for us, as > follows (mm folks is this right?): > > page = virt_to_page(address); > if (!page) > fail closed... > if (page_zone(page) == ZONE_DMA || page_zone(page) == ZONE_DMA32) > this is a DMA buffer > else > not DMA! > As I replied in the other thread, this code makes no sense. In general, any address covered by the kernel direct mapping can be passed to the streaming DMA api and be mapped for device read xor device write. Only DMA mappings that will be accessed randomly by the device and the CPU at the same time require the use of dma_alloc_coherent(), so it can take special precautions (e.g, create an uncached mapping if DMA is non cache coherent) The DMA zone thing is primarily about reserving low memory ranges for DMA because some hardware may not have sufficient address lines wired up to access all of DRAM. > Note that when request_firmware_into_buf() was being reviewed Mimi had asked back > in 2016 [0] that if a DMA buffer was going to be used READING_FIRMWARE_DMA should be > used otherwise READING_FIRMWARE_PREALLOC_BUFFER was fine. > > If it is a DMA buffer *now*, why / how did this change? > > [0] https://patchwork.kernel.org/patch/9074611/ > > Luis _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
