lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <447caa6d-13d2-2e75-5f33-6df9b2fd6d69@quicinc.com>
Date: Thu, 7 Aug 2025 22:05:10 +0530
From: Vikash Garodia <quic_vgarodia@...cinc.com>
To: Jorge Ramirez <jorge.ramirez@....qualcomm.com>
CC: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Dmitry Baryshkov
	<dmitry.baryshkov@....qualcomm.com>,
        <bryan.odonoghue@...aro.org>, <quic_dikshita@...cinc.com>,
        <konradybcio@...nel.org>, <krzk+dt@...nel.org>, <mchehab@...nel.org>,
        <conor+dt@...nel.org>, <andersson@...nel.org>,
        <linux-media@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 5/7] media: venus: core: Add qcm2290 DT compatible and
 resource data



On 8/7/2025 7:22 PM, Jorge Ramirez wrote:
> On 07/08/25 16:36:41, Vikash Garodia wrote:
>>
>>> 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.
>>
>> the issue is in firmware for both encoder and decoder. Didn't like the idea of
>> driver carrying the hack for a firmware issue. Just because, for encoder, we are
>> unable to hack it in driver, we are ok to have it enabled in a newer version of
>> the firmware, we can follow the same for decoders as well.
> 
> if that is the only reason please do explain what do you mean by hack.

I meant that the EOS handling was not needed in driver after fixing it in
firmware, isn't it ? Was trying to avoid carrying this in driver.

I tend to agree with the comment made by Dmitry in another thread to have decode
enabled with existing firmware, no option but to support the *already* published
bins.

Having said that, these limitation of having a separate EOS dummy buffer is well
sorted out in gen2 HFI which have an explicit DRAIN cmd for it. Hope this
motivates you to migrate to iris soon for AR50LITE variants :)

Regards,
Vikash

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ