07:03 <narmstrong> lumag: I did add it to me test initramfs but never tested it… let me test it!

07:25 <Marijn[m]> lumag: sure, done

07:25 <lumag> Marijn[m], narmstrong thx!

09:31 <marc|gonzalez> bamse: I did not understand the point you were trying to make wrt clock-names prop. Suppose a HW block has 3 incoming clock signals "foo", "bar", "baz", and lists them as

09:31 <marc|gonzalez> clks = <CLK_FOO>, <CLK_BAR>, <CLK_BAZ>;

09:31 <marc|gonzalez> clk-names = "foo", "bar", "baz";

09:32 <marc|gonzalez> Suppose the driver needs foo & baz

09:33 <marc|gonzalez> I would expect the driver to just do clk_foo = lookup_clk_by_name("foo"); clk_baz = lookup_clk_by_name("baz");

09:33 <marc|gonzalez> and have a helper parse the clk-names prop to find the proper index i, and return clks[i]

14:14 <Marijn[m]> marc|gonzalez: It may not have been explained, but that's what `clk_get(dev, "foo")` does. And if it cannot find `"foo"` as a firmware (= devicetree) clock, it looks it up by that name in the global clock tree

14:15 <Marijn[m]> Though implicit dependencies on global clock tree names are frowned upon instead of having explicit references in DT, but previous series to clean that up have been NAKed :/

14:17 <bamse> marc|gonzalez: the entries in clocks = <> are in "provider namespace" and the clock-names are in "consumer namespace"

14:18 <marc|gonzalez> "provider namespace" means the clock is an output?

14:18 <bamse> marc|gonzalez: e.g. that first entry probably isn't CLK_FOO, but rather <&clk_provider CLK_A>...but the driver only needs to know about its input

14:18 <bamse> marc|gonzalez: and on another platform it might be &clk_providerB CLK_C...and you don't have to change the driver

14:18 <bamse> marc|gonzalez: right, "CLK_FOO" in your example denotes a clock-source/provider/output

14:19 <bamse> marc|gonzalez: while "foo" denotes the sink/consumer/input

14:19 <marc|gonzalez> OK, I still don't understand, but maybe it will click at a later point when I write actual code...

14:20 <bamse> marc|gonzalez: it used to be that the drivers would just clk_get(CLK_FOO)...which meant that the driver code would need to change if you reused the same block/driver in another soc with different clock names

14:21 <marc|gonzalez> bamse: I'll post the HDMI (mac & phy) DTSI nodes written by Arnaud. Can you give them a look later?

14:26 <bamse> marc|gonzalez: related to resolving the clock names etc?

14:27 <marc|gonzalez> Well, I'm trying to get HDMI supported on the apq8098, and there's several road blocks

14:28 <marc|gonzalez> So yeah the DT needs vetting, and the HDMI phy driver

14:28 <marc|gonzalez> and for our specific board, a signal redriver gizmo

14:28 <marc|gonzalez> and everything just feels alien to me