lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 21 Aug 2017 14:37:27 +0300
From:   Stanimir Varbanov <stanimir.varbanov@...aro.org>
To:     Hans Verkuil <hverkuil@...all.nl>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Pawel Osciak <pawel@...iak.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 1/7 v2] media: vb2: add bidirectional flag in vb2_queue

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@...aro.org>
>>
>> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ