* Tero Kristo <t-kristo@xxxxxx> [180301 07:05]: > On 28/02/18 23:58, Tony Lindgren wrote: > > Then omap_dm_timer_init_one() can configure the source clock > > which is bit 24. My guess is that 138f7ca78f is really a > > workaround for set_parent() not working properly for clkctrl > > clock :) > > set_parent() can't work for clkctrl clock, as it only has one parent. The > mux is a separate component, so you need to fetch the parent of the clkctrl > part and set the parent for that one; unless we want to implement some sort > of composite clock support for it. Hmm OK probably good idea to avoid any composite clocks here :) I guess in timer1 example, clkctrl bit 0 is gate for both GPT1_FCLK and WKUP_L4_ICLK2? And then bit 24 sets the parent of WKUP_L4_ICLK2. Or am I still confused? So what should we call clkctrl bit 24 then? It seems we can have up to 8 opt clocks and also "parent" clocks for the fck. > I'd say it is more like a transitional patch to support both legacy and > clkctrl way of handling clocks. The patch can most likely be dropped once > the transition is done, but this was the only way I could see how to get it > fixed in short term. OK > > Then a board can specify it's desired source clock for system > > timer(s) by configure "assigned-lcok-parents" and set it to > > 32KiHz clock or SYS_CLK. > > Yeah, that will definitely work. We can have those aliases for the timer driver, I guess we just need a suitable name for the clkctrl parent bit(s). Anyways, no objections to this series of fixes, just wondering: Acked-by: Tony Lindgren <tony@xxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
