10:02 <kbingham> jbrunet, narmstrong, Would either of you be able to support looking at powerdomains / clocks for the camera inputs on the A311d board? We tried looking at the ISP already but reading the registers hangs the board ... so I guess the power domains are unimplemented.

10:05 <narmstrong> kbingham: probably yes, let me check the datasheet

10:10 <narmstrong> kbingham: can't find anything, are you sure the clock are on ?

10:16 <kbingham> narmstrong, Not sure of anything yet. That's the issue ;-)

10:16 <lvrp16> I'll see if I can get something.

10:17 <kbingham> I'm acting as an IRC bridge ... which is not great - trying to pull djrscally and pinchartl in here ;-)

10:17 <kbingham> Oh there's one ...

10:18 <kbingham> djrscally, meet everyone... everyone meet djrscally ;-)

10:19 <mkorpershoek> \o/

10:19 <lvrp16> kbingham: which registers are you probing?

10:19 <lvrp16> Hi djrscally

10:20 <kbingham> lvrp16, it was Laurent who did the test. It will have been the version register of the ISP.

10:20 <narmstrong> yeah it would need the cts_mipi_isp_clk enabled

10:21 <narmstrong> you can dump the meson clk msr in debugfs to know if it's enabled or not

10:21 <lvrp16> I'll play with it tomorrow, sun is coming up.

10:21 <djrscally> o/ hello evertibe

10:22 <kbingham> lvrp16, Long nights ;-)

10:22 <djrscally> Well...that went well

10:22 <kbingham> lvrp16, thanks for your help

10:22 <djrscally> s/evertibe/everyone :D

10:23 <narmstrong> \o/

10:24 <kbingham> djrscally, Sounds like quick steps are to replicate Laurents' test - and then update the DT with a clock. Should be 'that easy' right ;-)

10:25 <narmstrong> ah ah, we never added the csi clocks, but it should be quite straighforward

10:28 <lvrp16> If you need a quick and dirty dt change: https://github.com/libre-computer-project/libretech-wiring-tool/tree/master/libre-computer/aml-a311d-cc/dt

10:29 <lvrp16> It will take the current board DT from proc, merge the overlay, and then spit it out based on the file in the parent directly. u-boot then picks that up.

10:36 <djrscally> Well that's quite nifty

10:50 <jbrunet> When reading registers fail or hangs on Amlogic it is usually because you are missing a peripheral clock. It is a powerdomain per-se even if it could be viewed as such.

10:50 <jbrunet> Most of the time it is just clock you need to get and enable from main clock controller. If you look at DTs in the amlogic directory, you'll see a lot of 'pclk'

10:51 <lvrp16> djrscally: once you have the overlay run make and then ./ldto merge OVERLAY and reboot. Dynamic enablement won't work for clocks.

10:52 <jbrunet> Another way to approach the problem if can't pin point which clock you need, is to manually turn everything on with devmem (writing 0xffffffff in 2 or 3 regs)

10:52 <jbrunet> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/meson/g12a.c?h=v6.6#n4174

10:55 <jbrunet> If you then can access your reg space, you know you got the one(s) you needed ... then a bit of dichotomy and you'll know what you are missing

15:02 <f_> now thinking about it...

15:02 <f_> bl2.v3.bin could be based on a new TF-A codebase

15:02 <f_> (TF-A codebase, not amlogic codebase)

15:03 <f_> with all amlogic changes ported, probably.

15:05 <f_> bl31.bin and bl31.bin v1.3 are clearly based on a different TF-A

15:07 <f_> Simple `strings bl31{.v1_3}.bin | grep v1` confirms that guess.

15:07 <f_> but wait

15:08 <f_> TF-A v3 doesn't exist :P

15:10 <f_> so it's either bl2 v1.3 or a custom versioning and the TF-A codebase remained unchanged

15:10 <f_> not that it matters much for gxl...