Re: [PATCH v5 4/6] media: qcom: camss: Add sc8280xp resource details

From: Bryan O'Donoghue
Date: Mon Nov 13 2023 - 07:17:44 EST


On 13/11/2023 11:57, Konrad Dybcio wrote:
On 10.11.2023 02:04, Bryan O'Donoghue wrote:
This commit describes the hardware layout for the sc8280xp for the
following hardware blocks:

- 4 x VFE, 4 RDI per VFE
- 4 x VFE Lite, 4 RDI per VFE
- 4 x CSID
- 4 x CSID Lite
- 4 x CSI PHY

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
---
[...]

+static const struct camss_subdev_resources vfe_res_sc8280xp[] = {
+ /* IFE0 */
+ {
+ .regulators = {},
+ .clock = { "gcc_axi_hf", "gcc_axi_sf", "cpas_ahb", "camnoc_axi", "vfe0", "vfe0_axi" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 19200000, 80000000},
+ { 19200000, 150000000, 266666667, 320000000, 400000000, 480000000 },
+ { 400000000, 558000000, 637000000, 760000000 },
+ { 0 }, },
+ .reg = { "vfe0" },
+ .interrupt = { "vfe0" },
+ .pd_name = "ife0",
So, the comments before each array member, the reg/intr and pd names
are all over the place between IFE and VFE.. Is there a reason to this?

So what we have is older VFE - video front end, IFE - image front end and SFE - Sensor Front End, which do different things -> VFE raw, IFE pixel processing i.e. hw accel processing and SFE - sensor specific stuff I'm not across the detail of.

For our purposes in CAMSS => delivering simple bayer to user-space at the moment VFE = IFE = SFE.

We could rename vfe -> xfe but then again the presupposes the next iteration of this hardware block's name != xfe.

I do not believe there is a namespace deliniation for power-domains between 'stock' VFE and IFE.

The PD name in qcom namespace is 'IFE' the existing upstream code VFE but the capabilities we support are basically VFE, for now anyway.

On top of that, another ideas to add onto your cleanup stack:

- Are VFEs within a CAMSS block actually different? Can we just do "vfe
data" and "vfe number" + "vfe_lite data" & "vfe_lite number"?

Yes.

The last VFE in sm8250 is "pix" capable. VFE Lite is not individually power collapsible and I'm quite sure if you start trying to "push" more advanced features Lite unsurprisingly has fewer..

- Should we move these platform structs into separate files?

Yes. I'm aware of a group working on this and anticipate their patches soon.

- Reminder about the clk_bulk_enable for clk_rate=0 clocks suggestion

- OPP

There's a Jira ticket in Linaro's system for this if you look..

- Use _num instead of sentinels and magic scary while (not null)

---
bod