Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d80b5338-2eca-0223-d2a7-d6f7d39a28ba@gmail.com>
Date:   Mon, 14 Aug 2023 15:58:03 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH 00/33] Qualcomm video decoder/encoder driver
Content-Language: en-US, bg-BG
To:     Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Vikash Garodia <quic_vgarodia@quicinc.com>, agross@kernel.org,
        andersson@kernel.org, konrad.dybcio@linaro.org, mchehab@kernel.org,
        hans.verkuil@cisco.com, linux-kernel@vger.kernel.org,
        linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org
Cc:     quic_dikshita@quicinc.com
References: <1690550624-14642-1-git-send-email-quic_vgarodia@quicinc.com>
 <e18b951e-7f15-2c67-9099-c45ea7f67daa@linaro.org>
From:   Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
In-Reply-To: <e18b951e-7f15-2c67-9099-c45ea7f67daa@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Dmitry,

On 28.07.23 г. 17:01 ч., Dmitry Baryshkov wrote:
> On 28/07/2023 16:23, Vikash Garodia wrote:
>> This patch series introduces support for Qualcomm new video acceleration
>> hardware architecture, used for video stream decoding/encoding. This 
>> driver
>> is based on new communication protocol between video hardware and 
>> application
>> processor.
>>
>> This driver comes with below capabilities:
>> - V4L2 complaint video driver with M2M and STREAMING capability.
>> - Supports H264, H265, VP9 decoders.
>> - Supports H264, H265 encoders.
> 
> Please describe, why is it impossible to support this hardware in the 
> venus driver. We do not usually add new drivers for the new generations 
> of the hardware, unless it is fully incompatible with the previous 
> generations. Let me point you to camss or drm/msm drivers. They have 
> successfully solved the issue of supporting multiple generations of the 
> hardware in the same driver.
> 
> Unless the "iris3" is completely different from all the previous 
> generations, I strongly suggest spending time on restructuring existing 
> venus driver and then adding support for the new hardware there instead 
> of dumping out something completely new.

AFAIK the major differences are HW IP and firmware interface (by 
firmware interface I mean a protocol, API and API behavior). The 
firmware and its interface has been re-written to align closely with the 
current v4l2 specs for encoders/decoders state machines [1][2]. On the 
other side current mainline Venus driver firmware is following interface 
similar to OpenMAX.

There are incompatibilities between both firmware interfaces which 
cannot easily combined in a common driver. Even if there is a 
possibility to do that it will lead us to a unreadable driver source 
code and maintenance burden.

Vikash, could elaborate more on firmware interface differences.

[1] 
https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-decoder.html

[2] 
https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-encoder.html

-- 
regards,
Stan