linux-kernel - Re: [PATCH v2 06/13] media: qcom: camss: Assign the correct number of RDIs per VFE

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1f52f47a-d3d9-4740-a9c7-ef0bc99d7925@linaro.org>
Date:   Fri, 18 Aug 2023 14:26:13 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>, rfoss@...nel.org,
        todor.too@...il.com, agross@...nel.org, andersson@...nel.org,
        mchehab@...nel.org, hverkuil-cisco@...all.nl,
        laurent.pinchart@...asonboard.com, sakari.ailus@...ux.intel.com,
        andrey.konovalov@...aro.org
Cc:     linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 06/13] media: qcom: camss: Assign the correct number of
 RDIs per VFE

On 17.08.2023 16:38, Bryan O'Donoghue wrote:
> Each Video Front End - VFE - has a variable number of Raw Data Interfaces -
> RDIs associated with it.
> 
> The CAMSS code started from a naive implementation where a fixed define was
> used as a control in a for(){} loop iterating through RDIs.
> 
> That model scales badly. An attempt was made with  VFE_LINE_NUM_GEN2 and
> VFE_LINE_NUM_GEN1 to differentiate between SoCs but, the problem with that
> is "gen1" and "gen2" have no meaning in the silicon. There is no fixed
> constraint in the silicon between VFE and RDI, it is entirely up to the SoC
> designers how many VFEs are populated and how many RDIs to associate with
> each VFE.
> 
> As an example sdm845 has VFE version 175 and sm8250 VFE version 480.
> sdm845 has 2 VFEs with 4 RDIs and 1 VFE Lite with 4 RDIs.
> sm8250 has 2 VFEs with 3 RDIs and 2 VFE Lite with 4 RDIs.
> 
> Clearly then we need a more granular model to capture the necessary data.
> 
> The defines have gone away to be replaced with per-SoC data but, we haven't
> populated the parameter data with the real values.
> 
> Let's call those values out now
> 
> msm8916:
> 1 x VFE
> 3 x RDI per VFE (not 4)
> 
> msm8996:
> 2 x VFE
> 3 x RDI per VFE (not 4)
> 
> sdm660:
> 2 x VFE
> 3 x RDI per VFE (not 4)
> 
> sdm845:
> 2 x VFE
> 4 x RDI per VFE (not 3)
> 1 x VFE Lite
> 4 x RDI per VFE Lite (not 3)
> 
> sm8250:
> 2 x VFE
> 3 x RDI per VFE (not 4)
> 2 x VFE Lite
> 4 x RDI per VFE
> 
> This more complex and correct mapping was not possible prior to passing
> values via driver data. Now that we have that change in place we can
> correctly map VFEs to RDIs for each VFE.
> 
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@...aro.org>

Konrad