search for: sgtabl

...urn non-consistent memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent...

Change the sg_alloc_table_from_pages() allocation that was hardwired to GFP_KERNEL to use the gfp parameter like the other allocations in this function. Auditing says this is never called from an atomic context, so it is safe as is, but reads wrong. Signed-off-by: Jason Gunthorpe <jgg at nvidia.com> --- drivers/iommu/dma-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Change the sg_alloc_table_from_pages() allocation that was hardwired to GFP_KERNEL to use the gfp parameter like the other allocations in this function. Auditing says this is never called from an atomic context, so it is safe as is, but reads wrong. Signed-off-by: Jason Gunthorpe <jgg at nvidia.com> --- drivers/iommu/dma-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

...points for this memory > in the driver should it choose to return non-consistent memory." > > $ git grep dma_cache_sync drivers/media > $ AFAIK dma_cache_sync() isn't the only way to perform the cache synchronization. The earlier patch series that I reviewed relied on dma_get_sgtable() and then dma_sync_sg_*() (which existed in the vb2-dc since forever [1]). However, it looks like with the final code the sgtable isn't acquired and the synchronization isn't happening, so you have a point. FWIW, I asked back in time what the plan is for non-coherent allocations and it s...

...c_table_from_pages() allocation that was hardwired to > GFP_KERNEL to use the gfp parameter like the other allocations in this > function. > > Auditing says this is never called from an atomic context, so it is safe > as is, but reads wrong. I think the point may have been that the sgtable metadata is a logically-distinct allocation from the buffer pages themselves. Much like the allocation of the pages array itself further down in __iommu_dma_alloc_pages(). I see these days it wouldn't be catastrophic to pass GFP_HIGHMEM into __get_free_page() via sg_kmalloc(), but still,...

...the driver should it choose to return non-consistent memory." >> >> $ git grep dma_cache_sync drivers/media >> $ > > AFAIK dma_cache_sync() isn't the only way to perform the cache > synchronization. The earlier patch series that I reviewed relied on > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > vb2-dc since forever [1]). However, it looks like with the final code > the sgtable isn't acquired and the synchronization isn't happening, so > you have a point. Using the streaming sync calls on coherent allocations has also al...

...r > management and then it wouldn't be any problem to do what you > suggested. However, other subsystems have generic frameworks for > buffer management, like videobuf2 for V4L2. Those assume regular > DMA-bufs that can be handled with regular dma_buf_() API and described > using sgtables and/or pfn vectors and/or DMA addresses. "other subsystem sucks" doesn't sound like a good design paradigm to me. Forced midlayers are a bad design decision isn't really new at all ... > > - Once you've upcasted at runtime by checking for ->ops, you can add > &...

...;t be any problem to do what you > > > suggested. However, other subsystems have generic frameworks for > > > buffer management, like videobuf2 for V4L2. Those assume regular > > > DMA-bufs that can be handled with regular dma_buf_() API and described > > > using sgtables and/or pfn vectors and/or DMA addresses. > > > > "other subsystem sucks" doesn't sound like a good design paradigm to me. > > Forced midlayers are a bad design decision isn't really new at all ... > > > > Sorry, I don't think that's an argu...

...t; > > > suggested. However, other subsystems have generic frameworks for > > > > > buffer management, like videobuf2 for V4L2. Those assume regular > > > > > DMA-bufs that can be handled with regular dma_buf_() API and described > > > > > using sgtables and/or pfn vectors and/or DMA addresses. > > > > > > > > "other subsystem sucks" doesn't sound like a good design paradigm to me. > > > > Forced midlayers are a bad design decision isn't really new at all ... > > > > > > >...

Hi Christoph, On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig <hch at lst.de> wrote: > > The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, Could you explain what makes you think it's unused? It's a feature of the UAPI generally supported by the videobuf2 framework and relied on by Chromium OS to get any kind of reasonable performance when accessing V4L2 buffers

Hi, This is third approach (complete this time) for replacing struct dma_attrs with unsigned long. The main patch (2/45) doing the change is split into many subpatches for easier review (3-43). They should be squashed together when applying. *Important:* Patchset is *only* build tested on allyesconfigs: ARM, ARM64, i386, x86_64 and powerpc. Please provide reviewes and tests for other

.............G.... 0030: 39 8b c7 65 36 00 01 00 00 00 08 f7 ca aa 00 00 9..e6........... 0040: 00 00 .. SSDT @ 0xaafe8000 0000: 53 53 44 54 b1 0d 00 00 01 e7 53 67 52 65 66 00 SSDT......SgRef. 0010: 53 67 54 61 62 6c 00 00 00 10 00 00 49 4e 54 4c SgTabl......INTL 0020: 09 11 06 20 10 45 62 5c 2f 03 5f 53 42 5f 50 43 ... .Eb\/._SB_PC 0030: 49 30 47 46 58 30 14 4e 05 4d 58 56 4c 09 08 54 I0GFX0.N.MXVL..T 0040: 4d 50 30 11 04 0a 04 00 8c 54 4d 50 30 00 44 54 MP0......TMP0.DT 0050: 59 50 8c 54 4d 50 30 01 44 44 53 50 8c 54 4d 50 YP.TMP0.DD...