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@xxxxxxxxxx>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
Konrad
