* Michael Turquette <mturquette@xxxxxxxxxxxx> [161209 13:28]: > Quoting Tony Lindgren (2016-12-09 12:40:16) > > Yeah that's what we already have with hwmod and PM runtime for the > > clockctrl register. But hwmod currently directly manages the clkctrl > > register, we just want to move that part to be a clock driver. > > > > The children of the interconnect target modules just need to use > > PM runtime, but the interconnect target module driver needs to know > > it's clkctrl clock. > > OK, that sounds good to me but I'm not quite sure about the difference > between "children of interconnect target modules" versus just the > "interconnect target module". The interconnect target module specific registers are "sysc", "syss" and "revision". Those are usually stuffed to random addresses, and currently managed by hwmod. Each interconnect target module has a module gate clock "clkctrl" in some clockdomain. Each clockdomain has multiple similar "clckctrl" clocks. > Can you give an example on each? I just want to understand for my own > curiosity. For example, musb on am335x has these as children of a single interconnect target module: - Two instances of musb wrapper IP - Two instances of musb IP - One instance of CPP41 DMA The on omap4, the whole system control module is just a single interconnect target module with tens of devices in it like padconf, clocks, pbias regulator and whatever random devices. > > I don't think the clockdomain should be a genpd provider because > > that creates a genpd network of dependencies instead of a tree > > structure. If we end up setting the clockdomains with genpd, then > > only the other clockdomains should use them, but I don't know how > > we ever keep drivers from directly tinkering with them.. > > Genpd is set up as an arbitrary graph, not strictly a tree, so these > types of dependencies should be OK. Well maybe that works then, worth checking for sure. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
