linux-kernel - Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399

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]

Message-Id: <85C6CA4D-CC54-422B-BC2B-25EA10701696@soulik.info>
Date:   Mon, 7 Jan 2019 01:29:54 +0800
From:   Ayaka <ayaka@...lik.info>
To:     Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
Cc:     Ezequiel Garcia <ezequiel@...labora.com>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Nicolas Dufresne <nicolas.dufresne@...labora.com>,
        myy@...uyouyou.fr,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media <linux-media@...r.kernel.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        Heiko Stuebner <heiko@...ech.de>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] arm64: dts: rockchip: add video codec for rk3399

Hello Ezequiel

Sent from my iPad

> On Jan 7, 2019, at 1:21 AM, Ezequiel Garcia <ezequiel@...guardiasur.com.ar> wrote:
> 
>> On Sun, 6 Jan 2019 at 13:16, Ayaka <ayaka@...lik.info> wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jan 7, 2019, at 12:04 AM, Ezequiel Garcia <ezequiel@...labora.com> wrote:
>>> 
>>> On Sun, 2019-01-06 at 23:05 +0800, Ayaka wrote:
>>>>> On Jan 6, 2019, at 10:22 PM, Ezequiel Garcia <ezequiel@...labora.com> wrote:
>>>>> 
>>>>> Hi Randy,
>>>>> 
>>>>> Thanks a lot for this patches. They are really useful
>>>>> to provide more insight into the VPU hardware.
>>>>> 
>>>>> This change will make the vpu encoder and vpu decoder
>>>>> completely independent, can they really work in parallel?
>>>> As I said it depends on the platform, but with this patch, the user space would think they can work at the same time.
>>> 
>>> 
>>> I think there is some confusion.
>>> 
>>> The devicetree is one thing: it is a hardware representation,
>>> a way to describe the hardware, for the kernel/bootloader to
>>> parse.
>>> 
>>> The userspace view will depend on the driver implementation.
>>> 
>>> The current devicetree and driver (without your patches),
>>> model the VPU as a single piece of hardware, exposing a decoder
>>> and an encoder.
>>> 
>>> The V4L driver will then create two video devices, i.e. /dev/videoX
>>> and /dev/videoY. So userspace sees an independent view of the
>>> devices.
>>> 
>> I knew that, the problem is that the driver should not always create a decoder and encoder pair, they may not exist at some platforms, even some platforms doesn’t have a encoder. You may have a look on the rk3328 I post on the first email as example.
> 
> That is correct. But that still doesn't tackle my question: is the
> hardware able to run a decoding and an encoding job in parallel?
> 
For rk3328, yes, you see I didn’t draw them in the same box.
> If not, then it's wrong to describe them as independent entities.
> 
>>> However, they are internally connected, and thus we can
>>> easily avoid two jobs running in parallel.
>>> 
>> That is what the mpp service did in my patches, handing the relationship between each devices. And it is not a easy work, maybe a 4k decoder would be blocked by another high frame rate encoding work or another decoder session. The vendor kernel have more worry about this,  but not in this version.
> 
> Right. That is one way to design it. Another way is having a single
> devicetree node for the VPU encoder/decoder "complex".
No, you can’t assume which one is in the combo group, it can be various. you see, in the rk3328, the vdpu is paired with an avs+ decoder. That is why I use a virtual device standing for scheduler.
> 
> Thanks for the input!
> -- 
> Ezequiel García, VanguardiaSur
> www.vanguardiasur.com.ar