[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55585c99-2359-1e21-51ac-1a211150defd@quicinc.com>
Date: Wed, 20 Dec 2023 14:02:54 +0530
From: Vikash Garodia <quic_vgarodia@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
Dmitry Baryshkov
<dmitry.baryshkov@...aro.org>,
Dikshita Agarwal <quic_dikshita@...cinc.com>,
<linux-media@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<stanimir.k.varbanov@...il.com>, <agross@...nel.org>,
<andersson@...nel.org>, <konrad.dybcio@...aro.org>,
<mchehab@...nel.org>, <bryan.odonoghue@...aro.org>
CC: <linux-arm-msm@...r.kernel.org>, <quic_abhinavk@...cinc.com>
Subject: Re: [PATCH v2 00/34] Qualcomm video encoder and decoder driver
Hi Krzysztof,
On 12/20/2023 1:45 PM, Krzysztof Kozlowski wrote:
> On 20/12/2023 07:32, Vikash Garodia wrote:
>>> From what I see from you bindings, the hardware is pretty close to what we see
>>> in the latest venus generations. I asssme that there was a change in the vcodec
>>> inteface to the firmware and other similar changes. Could you please point out,
>>> which parts of Venus driver do no longer work or are not applicable for sm8550
>>
>> The motivation behind having a separate IRIS driver was discussed earlier in [1]
>> In the same discussion, it was ellaborated on how the impact would be with
>> change in the new firmware interface and other video layers in the driver. I can
>> add this in cover letter in the next revision.
>>
>> We see some duplication of code and to handle the same, the series brings in a
>> common code reusability between iris and venus. Aligning the common peices of
>> venus and iris will be a work in progress, once we land the base driver for iris.
>>
>> Again qualcomm video team does not have a plan to support sm8550/x1e80100 on
>
> If you want it to get merged, then create such plan, please.
>
>> venus as the changes are too interleaved to absorb in venus driver. And there is
>> significant interest in community to start validating video driver on sm8550 or
>> x1e80100.
>
> Community does not want duplicated drivers leading to maintenance costs.
> Your approach to this is not how upstreaming process works.
If you go over the pseudo code which i explained in [1], you can see that the
maintenance cost would be higher if try to impose the new interface in existing
driver. Video team, alongwith Stan, have considered the aspect of maintenance
before starting on this new driver.
[1] https://lore.kernel.org/lkml/8c97d866-1cab-0106-4ab3-3ca070945ef7@quicinc.com/
Regards,
Vikash
Powered by blists - more mailing lists