search for: videobuf2

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 in the userspace. > and causes > weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > unimplemented except on PARISC and some MIPS configs, and about to be > remov...

..._CONSISTENT flag, which is unimplemented except on PARISC and some MIPS configs, and about to be removed. Signed-off-by: Christoph Hellwig <hch at lst.de> --- .../userspace-api/media/v4l/buffer.rst | 17 --------- .../media/v4l/vidioc-reqbufs.rst | 1 - .../media/common/videobuf2/videobuf2-core.c | 36 +------------------ .../common/videobuf2/videobuf2-dma-contig.c | 19 ---------- .../media/common/videobuf2/videobuf2-dma-sg.c | 3 +- .../media/common/videobuf2/videobuf2-v4l2.c | 12 ------- include/media/videobuf2-core.h | 3 +- include/uapi/linux/vi...

...> > 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 in the userspace. > >> and causes >> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is >> unimplemented except on PARISC and some MIPS configs,...

...ozhatsky <sergey.senozhatsky at gmail.com> Signed-off-by: Christoph Hellwig <hch at lst.de> --- .../userspace-api/media/v4l/buffer.rst | 17 ------- .../media/v4l/vidioc-create-bufs.rst | 6 +-- .../media/v4l/vidioc-reqbufs.rst | 12 +---- .../media/common/videobuf2/videobuf2-core.c | 46 +++---------------- .../common/videobuf2/videobuf2-dma-contig.c | 19 -------- .../media/common/videobuf2/videobuf2-dma-sg.c | 3 +- .../media/common/videobuf2/videobuf2-v4l2.c | 18 +------- drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 10 +--- drivers/media/v4l2-c...

...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 in the userspace. > > > >> and causes > >> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is > >> unimplemented except on...

Split out subsystem specific changes for easier reviews. This will be squashed with main commit. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- drivers/media/platform/sti/bdisp/bdisp-hw.c | 26 +++++++--------------- drivers/media/v4l2-core/videobuf2-dma-contig.c | 30 +++++++++++--------------- drivers/media/v4l2-core/videobuf2-dma-sg.c | 19 ++++------------ include/media/videobuf2-dma-contig.h | 7 ++---- 4 files changed, 26 insertions(+), 56 deletions(-) diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c b/drivers/medi...

...Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote: > > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > > > 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 in the userspace. > > > > > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > &g...

...| 8 drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 drivers/iommu/dma-iommu.c | 2 drivers/iommu/intel/iommu.c | 6 drivers/media/common/videobuf2/videobuf2-core.c | 36 -- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 19 - drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 drivers/media/common/videobuf2/videobuf2-v4l2.c | 12 drivers/net/ethernet/amd/au1000_eth.c | 15...

...is of course another story and, as I mentioned too, I'm willing to look into fixing them. I'm of course happy to review the rest of the series and even more happy to help migrating this code to whatever is added there, as long as the functionality is preserved. > > By the way, as a videobuf2 reviewer, I'd appreciate being CC'd on any > > series related to the subsystem-facing DMA API changes, since > > videobuf2 is one of the biggest users of it. > > The cc list is too long - I cc lists and key maintainers. As a reviewer > should should watch your subsyste...

On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote: > > > 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 in the userspace. > > > > Because it doesn't do anything except on PARISC and non-coherent MIPS, > > so by definition it isn't used by...

On Thu, Aug 20, 2020 at 6:54 PM Christoph Hellwig <hch at lst.de> wrote: > > On Thu, Aug 20, 2020 at 12:05:29PM +0200, Tomasz Figa wrote: > > The UAPI and V4L2/videobuf2 changes are in good shape and the only > > wrong part is the use of DMA API, which was based on an earlier email > > guidance anyway, and a change to the synchronization part . I find > > conclusions like the above insulting for people who put many hours > > into designing a...

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. As a follow up I

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a

...| 12 +- drivers/iommu/dma-iommu.c | 8 +- drivers/iommu/intel-iommu.c | 12 +- .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 4 - drivers/media/platform/sti/bdisp/bdisp-hw.c | 26 ++--- drivers/media/v4l2-core/videobuf2-dma-contig.c | 28 ++--- drivers/media/v4l2-core/videobuf2-dma-sg.c | 21 +--- drivers/media/v4l2-core/videobuf2-vmalloc.c | 2 +- drivers/misc/mic/host/mic_boot.c | 20 ++-- drivers/parisc/ccio-dma.c | 16 +-- drivers/parisc/sba_i...

...the > > > > > display and GPU in a pipeline manner, which can only be implemented > > > > > efficiently by sharing the buffers between producers and consumers. > > > > > > > > > > Existing buffer management framework in Linux, such as the videobuf2 > > > > > framework in V4L2, implements all the DMA-buf handling inside generic > > > > > code and do not expose any low level information about the buffers to > > > > > the drivers. > > > > > > > > > > To seamlessly enable...

...display and GPU in a pipeline manner, which can only be implemented > > > > > > > efficiently by sharing the buffers between producers and consumers. > > > > > > > > > > > > > > Existing buffer management framework in Linux, such as the videobuf2 > > > > > > > framework in V4L2, implements all the DMA-buf handling inside generic > > > > > > > code and do not expose any low level information about the buffers to > > > > > > > the drivers. > > > > > > > > &...

...to perform the cache > synchronization. Yes, it is the only documented way to do it. And if you read the whole series instead of screaming you'd see that it provides a proper way to deal with non-coherent memory which will also work with arm64. instead of screaming > By the way, as a videobuf2 reviewer, I'd appreciate being CC'd on any > series related to the subsystem-facing DMA API changes, since > videobuf2 is one of the biggest users of it. The cc list is too long - I cc lists and key maintainers. As a reviewer should should watch your subsystems lists closely.

On Wed, Aug 19, 2020 at 04:11:52PM +0200, Tomasz Figa wrote: > > > By the way, as a videobuf2 reviewer, I'd appreciate being CC'd on any > > > series related to the subsystem-facing DMA API changes, since > > > videobuf2 is one of the biggest users of it. > > > > The cc list is too long - I cc lists and key maintainers. As a reviewer > > should s...

On Thu, Aug 20, 2020 at 6:45 AM Christoph Hellwig <hch at lst.de> wrote: > > On Wed, Aug 19, 2020 at 04:11:52PM +0200, Tomasz Figa wrote: > > > > By the way, as a videobuf2 reviewer, I'd appreciate being CC'd on any > > > > series related to the subsystem-facing DMA API changes, since > > > > videobuf2 is one of the biggest users of it. > > > > > > The cc list is too long - I cc lists and key maintainers. As a reviewe...

On Thu, Aug 20, 2020 at 12:05:29PM +0200, Tomasz Figa wrote: > The UAPI and V4L2/videobuf2 changes are in good shape and the only > wrong part is the use of DMA API, which was based on an earlier email > guidance anyway, and a change to the synchronization part . I find > conclusions like the above insulting for people who put many hours > into designing and implementing the...