Re: [PATCH v8 5/7] media: venus: core: Add qcm2290 DT compatible and resource data

[Jorge Ramirez <jorge.ramirez@oss.qualcomm.com>]

On 06/08/25 11:01:09, Konrad Dybcio wrote:
> 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@oss.qualcomm.com>
> >>>>>> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> >>>>>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
> >>>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> >>>>>> Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
> >>>>>> ---
> >>>>>>  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)
> 

um, no not really: the decision was to simply drop support for pre
6.0.55 firmwares for the AR50_LITE.

Pre 6.0.55:

-  has a requirement for secure buffers to support encoding
-  requires a driver workaround for EOS (providing a dummy length)
-  during video encoding.

To support < 6.0.55, v7 of the driver patchset:

- uses the version to disable the encode node
- enables the video decode node
- implements the EOS workaround.

It was agreed that this complexity was not necessary and that we should
just drop <6.0.55 firmware support (which would in any case only include
video decode).

And so on v8, I removed the above.

Now I have v9 ready to post it, but Dmitry is asking why cant we have
the v7 functionality so I am waiting for direction.