13:28 <bryanodonoghue> so mal I will attribute you with "Suggested-by" since "Reported-by" requires a Closes: tag to lore.kernel.org

13:55 <mal> bryanodonoghue: ok

15:43 <mal> bryanodonoghue: I have some trouble understand the clocks in the camss code, for example in camss-vfe.c the vfe_set_clock_rates function only sets the vfe* clock rates, what is then setting the rates for the other clocks defined in camss.c for vfe? those seem to be left at the default value, not the one defined in camss.c

15:46 <mal> for comparison same function in camss-csid.c sets also other clock rates

16:30 <bryanodonoghue> eh well on some platforms VFE lives outside of CSID and on some platforms inside of it

16:31 <bryanodonoghue> generally though I'd say the downstream clock declaration is complete for each block and should be replicated

16:36 <mal> bryanodonoghue: what about those extra clocks in vfe of 8250 for example (which seem to come from cam-cpas in downstream)?

16:37 <bryanodonoghue> cpas_ahb

16:37 <bryanodonoghue> -> AHB

16:37 <bryanodonoghue> not to be omitted

16:38 <bryanodonoghue> I even try to keep the ordering of the clocks the same

16:38 <bryanodonoghue> on the assumption that there is potential buried engineering knowledge in the order

16:41 <mal> I'm starting to run out of ideas what could be wrong with my setup

16:50 <bryanodonoghue> eh - post a branch and a dmesg

17:07 <mal> bryanodonoghue: now I finally found a working combination of clocks and managed to get test pattern out of csid (partially broken though, only top half of the image looks correct)