On 8/6/25 10:04 AM, Jorge Ramirez wrote:
> On 06/08/25 04:37:05, Dmitry Baryshkov wrote:
>> On Tue, Aug 05, 2025 at 01:27:34PM +0200, Jorge Ramirez wrote:
>>> On 05/08/25 12:44:23, Jorge Ramirez wrote:
>>>> On 05/08/25 13:04:50, Dmitry Baryshkov wrote:
>>>>> On Tue, Aug 05, 2025 at 08:44:28AM +0200, Jorge Ramirez-Ortiz wrote:
>>>>>> Add a qcm2290 compatible binding to the Cenus core.
>>>>>>
>>>>>> The maximum concurrency is video decode at 1920x1080 (FullHD) with video
>>>>>> encode at 1280x720 (HD).
>>>>>>
>>>>>> The driver is not available to firmware versions below 6.0.55 due to an
>>>>>> internal requirement for secure buffers.
>>>>>>
>>>>>> The bandwidth tables incorporate a conservative safety margin to ensure
>>>>>> stability under peak DDR and interconnect load conditions.
>>>>>>
>>>>>> Co-developed-by: Loic Poulain <loic.poulain@xxxxxxxxxxxxxxxx>
>>>>>> Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxxxxxxxxx>
>>>>>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@xxxxxxxxxxxxxxxx>
>>>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
>>>>>> Reviewed-by: Dikshita Agarwal <quic_dikshita@xxxxxxxxxxx>
>>>>>> ---
>>>>>> drivers/media/platform/qcom/venus/core.c | 50 ++++++++++++++++++++++++
>>>>>> 1 file changed, 50 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
>>>>>> index adc38fbc9d79..753a16f53622 100644
>>>>>> --- a/drivers/media/platform/qcom/venus/core.c
>>>>>> +++ b/drivers/media/platform/qcom/venus/core.c
>>>>>> @@ -1070,6 +1070,55 @@ static const struct venus_resources sc7280_res = {
>>>>>> .enc_nodename = "video-encoder",
>>>>>> };
>>>>>>
>>>>>> +static const struct bw_tbl qcm2290_bw_table_dec[] = {
>>>>>> + { 352800, 597000, 0, 746000, 0 }, /* 1080p@30 + 720p@30 */
>>>>>> + { 244800, 413000, 0, 516000, 0 }, /* 1080p@30 */
>>>>>> + { 216000, 364000, 0, 454000, 0 }, /* 720p@60 */
>>>>>> + { 108000, 182000, 0, 227000, 0 }, /* 720p@30 */
>>>>>> +};
>>>>>> +
>>>>>> +static const struct bw_tbl qcm2290_bw_table_enc[] = {
>>>>>> + { 352800, 396000, 0, 0, 0 }, /* 1080p@30 + 720p@30 */
>>>>>> + { 244800, 275000, 0, 0, 0 }, /* 1080p@30 */
>>>>>> + { 216000, 242000, 0, 0, 0 }, /* 720p@60 */
>>>>>> + { 108000, 121000, 0, 0, 0 }, /* 720p@30 */
>>>>>> +};
>>>>>> +
>>>>>> +static const struct firmware_version min_fw = {
>>>>>> + .major = 6, .minor = 0, .rev = 55,
>>>>>> +};
>>>>>
>>>>> This will make venus driver error out with the firmware which is
>>>>> available in Debian trixie (and possibly other distributions). If I
>>>>> remember correctly, the driver can work with that firmware with the
>>>>> limited functionality. Can we please support that instead of erroring
>>>>> out completely?
>>>>
>>>> yes, in V7 I did implement this functionality plus a fix for EOS
>>>> handling (broken in pre 6.0.55 firmwares).
>>>
>>> just re-reading your note, in case this was not clear, the _current_
>>> driver upstream will never work with the current firmware if that is
>>> what you were thinking (it would need v7 of this series to enable video
>>> decoding).
>>
>> I'd really prefer if we could support firmware that is present in Debian
>> trixie and that has been upstreamed more than a year ago.
>
>
> I share your view — which is why I put the effort into v7 — but I also
> understand that maintaining the extra code and EOS workaround for
> decoding needs to be justifiable. So I chose to align with the
> maintainers' perspective on this and removed it on v8 (partially also
> because I wanted to unblock the current EOS discussion).
+$0.05
I thought we were going to eventually relax/drop the fw requirement
when the driver learns some new cool tricks, but are we now straying
away from that? (particularly thinking about the EOS part)
Konrad
