Hi, On Thursday 31 May 2018 08:56 PM, Tony Lindgren wrote: > * Tero Kristo <t-kri...@ti.com> [180531 06:18]: >> On 30/05/18 18:54, Tony Lindgren wrote: >>> * Tero Kristo <t-kri...@ti.com> [180530 15:44]: >>>> On 30/05/18 18:28, Tony Lindgren wrote: >>>>> * Tero Kristo <t-kri...@ti.com> [180530 15:18]: >>>>>> For the OCP if part, I think that is still needed until we switch over to >>>>>> full sysc driver. clkctrl_offs you probably also need because that is >>>>>> used >>>>>> for mapping the omap_hwmod against a specific clkctrl clock. Those can be >>>>>> only removed once we are done with hwmod (or figure out some other way to >>>>>> assign the clkctrl clock to a hwmod.) >>>>> >>>>> Hmm might be worth testing. I thought your commit 70f05be32133 >>>>> ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available") >>>>> already parses the clkctrl from dts? >>>> >>>> It maps the clkctrl clock to be used by hwmod, if those are available. We >>>> didn't add any specific clock entries to DT for mapping the actual clkctrl >>>> clock without the hwmod_data hints yet though, as that was deemed temporary >>>> solution only due to transition to interconnect driver. I.e., you would >>>> need >>>> something like this in DT for every device node: >>>> >>>> &uart3 { >>>> clocks = <l4per_clkctrl UART3_CLK 0>; >>>> clock-names = "clkctrl"; >>>> }; >>>> >>>> ... which is currently not present. >>> >>> Hmm is that not the "fck" clkctrl clock we have already in >>> the dts files for the interconnect target modules? >> >> Oh okay, yeah, we could parse that one, but currently it is not done, and is >> not present for everything either I believe. >> >>> We can also use pdata callbacks to pass the clock node if >>> needed. But I guess I don't quite still understand what we >>> are missing :) >> >> So, what is missing is the glue logic only from the hwmod codebase. Right >> now this is not supported but should be relatively trivial thing to add if >> we really want to do this. > > OK let's think about this a bit for v4.19 then. >
I am not sure what the conclusion is. Should I try removing the clkctrl_offsets, clkdm_name, and main_clk? Thanks, Faiz