Yes this is interesting and I think I’m missing something. Suppose we used “extperiph2” for a reference clock. According to the clk_tree we would be using a 24 Mhz Clock signal from the board/SOM and sending it to the tc358743 chip.
But according to the Toshiba spec it needs a 26/27 Mhz or 42 Mhz for a ref clock.
So this makes sense with what I see in the driver and the device tree as it’s all hardcoded to 27 Mhz. Based on what we see in the clk_tree there are no clocks running at 27 Mhz. Somebody figured they could just hardcode it.
refclk_hz = <27000000>; // refclk_hz -> regclk
// state->pdata.refclk_hz = clk_get_rate(refclk); state->pdata.refclk_hz = 27000000;
However what doesn’t make any sense to me is that in the driver function “tc358743_probe_of” there are all these lines of code that are getting and using the clock signal but they are commented out. Ex:
// refclk = devm_clk_get(dev, "cam_mclk1");
So, the question becomes… where is the tc358743 chip getting it’s ref clock signal? In my mind one cannot just hardcode a reference clock value and it just works.
So I modified the driver code to get the clock from extperiph1 and then I print it out (it appears in dmesg on boot).
refclk = devm_clk_get(dev, "extperiph1");
[ 3.583164] tc358743 clk_get_rate 37090909
And what we see that we get is the value from the clk_tree. This is what I expected but not what I wanted.
extperiph1 0 37090909 0 0
I also saw this line was commented out. Don’t understand why but thought it might help to have it back in there having to do with csi endpoints but it didn’t do anythng of value:
state->bus = endpoint->bus.mipi_csi2;