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 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).

At this point, I have v9 ready based on v8, addressing the latest round
of comments. However, if we need to revert to the features in v7, it
will require reworking a significant amount of code.

To avoid going in circles, I’d appreciate some clarity on the direction
from Vikash, Bryan, and Dkishita:

ok to post v9 based on v8 or should I bring back v7 support (decoding)
for firmwares before 6.0.55?