Hi, On 08/21/2017 01:21 PM, Hans Verkuil wrote: > On 08/21/2017 11:29 AM, Marek Szyprowski wrote: >> Hi Stanimir, >> >> On 2017-08-21 11:09, Stanimir Varbanov wrote: >>> This change is intended to give to the v4l2 drivers a choice to >>> change the default behavior of the v4l2-core DMA mapping direction >>> from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or >>> OUTPUT) to DMA_BIDIRECTIONAL during queue_init time. >>> >>> Initially the issue with DMA mapping direction has been found in >>> Venus encoder driver where the hardware (firmware side) adds few >>> lines padding on bottom of the image buffer, and the consequence >>> is triggering of IOMMU protection faults. >>> >>> This will help supporting venus encoder (and probably other drivers >>> in the future) which wants to map output type of buffers as >>> read/write. >>> >>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx> >> >> This has been already discussed about a year ago, but it got lost in >> meantime, probably due to lack of users. I hope that this time it >> finally will get into vb2. >> >> For the reference, see https://patchwork.kernel.org/patch/9388163/ > > Interesting. > > Stanimir, I like your implementation better than the macro in the old > patch. But as it said there, videobuf2-dma-sg/contig/vmalloc.c have references > to DMA_FROM_DEVICE that won't work with BIDIRECTIONAL, so those need > to be adapted as well. I missed that when I reviewed your patch :-( Thanks for catching this, I didn't thought too much about usrptr. Sent v3. -- regards, Stan -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
