On 11/9/23 12:30, 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 csid_res_sc8280xp[] = {
+ /* CSID0 */
+ {
+ .regulators = { "vdda-phy", "vdda-pll" },
+ .clock = { "vfe0_csid", "vfe0_cphy_rx", "vfe0", "vfe0_axi" },
+ .clock_rate = { { 400000000, 400000000, 480000000, 600000000, 600000000, 600000000 },
(why is it 400, 400, 480, 600, 600, 600 and not 400, 480, 600?)
+ { 0 },
+ { 0 },
+ { 0 } },
There's a funny bug..
camss-csiphy.c and camss-vfe.c (sounds like room for commonization):
while (res->clock_rate[i][clock->nfreqs])
clock->nfreqs++;
this works fine in this case, because the last frequency is followed
by a zero, so overflowing the 2nd dimension of the array into the last+1
member (meaning the first member of the following entry in the 1st dimension)
stops this loop
however
[...]
+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, 80000000, 80000000, 80000000},
+ { 19200000, 150000000, 266666667, 320000000, 400000000, 480000000 },
+ { 400000000, 558000000, 637000000, 760000000 },
+ { 0 }, },
Not the case here!
I'd suggest moving this to something like:
struct res_clk_data {
const char * const names;
const u64 * const rates; (or unsigned long / unsigned long long / uint?
there was some capping for arm32)
const u8 num_clks;
}
OR even better
separate out clocks that just need to be on/off ("intf/interface clocks" sounds
like a good name for these) from ones that require scaling, use clk_bulk apis
for the former and OPP for the latter to make sure the correct performance state
is requested on the RPMhPDs
Konrad
