> Gesendet: Freitag, 17. Juni 2022 um 19:22 Uhr > Von: "Robin Murphy" <robin.mur...@arm.com> > An: "Frank Wunderlich" <fran...@public-files.de>, "Christoph Hellwig" > <h...@lst.de> > Cc: linux-ker...@vger.kernel.org, iommu@lists.linux-foundation.org, "Marek > Szyprowski" <m.szyprow...@samsung.com> > Betreff: Re: helping with remapping vmem for dma > > On 2022-06-17 17:17, Frank Wunderlich wrote: > > Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig <h...@lst.de>: > >> On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote: > >>> Put simply, if you want to call dma_map_single() on a buffer, then that > >>> buffer needs to be allocated with kmalloc() (or technically alloc_pages(), > >>> but then dma_map_page() would make more sense when dealing with entire > >>> pages. > >> > >> Yes. It sounds like the memory here comes from the dma coherent > >> allocator, in which case the code need to use the address returned > >> by that and not create another mapping. > > > > Hi > > > > traced it to buffer allocated as simple uint8-array [1]: > > > > UINT_8 aucBuffer[sizeof(INIT_HIF_RX_HEADER_T) + > > sizeof(INIT_EVENT_CMD_RESULT)]; > > Ah, so it's trying to do DMA with a stack variable? CONFIG_DMA_API_DEBUG > is your friend; it should have screamed about that specifically. > Allocate this buffer properly to begin with, and free it again on the > way out of the function (it's surely not worth having to make a > temporary copy further down the callchain). The kmalloc flags can > probably be regular GFP_KERNEL, unless this can be called from more > restrictive contexts like an IRQ handler - the fact that it might be > mapped for DMA later is essentially irrelevant in that respect.
Hi, simply replaced the stack-vars to uint_8-pointers and using kmalloc/kfree for memory handling (needed to replace some returns to goto to always free memory). Thanks very much for support, driver is now working again :) https://github.com/frank-w/BPI-R2-4.14/commit/7f3a721d5b0d8ca44935c23d5513a19cc57786c0 > Thanks, > Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu