[PATCH 6/8] devicetree: doc: Document ti,timer-parent property

[tony@atomide.com (Tony Lindgren)]

* Joel Fernandes <joelf@ti.com> [131122 16:32]:
> On 11/22/2013 11:08 AM, Tony Lindgren wrote:
> > 
> > I don't think there's a dependency here to the omap clocks as the dmtimer
> > can implement the clocksource separately and internally still use clk_get
> > using the clock alias table.
> 
> You mean implement clock-tree separately? Sorry I'm confused can you clarify
> what you mean?

You could implement the needed clocks for client drivers to use in dmtimer.c
directly if dmtimer.c is the gating those clocks.
 
> In clock tree data (not upstream), here is the system clock for am335x for example:
> sys_clkin_ck: sys_clkin_ck at 44e10040 {
>         #clock-cells = <0>;
>         compatible = "mux-clock";
> 
> It uses the mux-clock driver. Are you saying we duplicate clock-tree stuff? I
> don't think that's a good idea specially since once clock dt data is available,
> we will switch to using it.

Oh OK, then that naturally could be used directly too.
 
> >>>>  Optional properties:
> >>>>  - ti,timer-alwon:	Indicates the timer is in an alway-on power domain.
> >>>
> >>> Hmm this we may not need, this can probably be deciphered from the compatible
> >>> flag already?
> >>
> >> How? Compatible contains the same string, for example for OMAP4:
> >>
> >> timer8 has:
> >>                         compatible = "ti,omap4430-timer";
> >>                         ti,timer-pwm;
> >>                         ti,timer-dsp;
> >>
> >> and timer9 has:
> >>                         compatible = "ti,omap4430-timer";
> >>                         ti,hwmods = "timer9";
> >>                         ti,timer-pwm;
> >>
> > 
> > Some of these features are always hardwired certain way and could be mapped to
> > the right timer based on the timer offset and the compatible flag if we want
> > to avoid adding the ti,timer-alwon property. It seems that most omaps have
> > just one always on timer that's the first timer, and only on am33xx it does
> > not exist?
> > 
> > I'm fine adding ti,timer-alwon if it help to leave out static data in the
> > driver and avoid patching the driver for every new SoC. But sounds like in
> > this case we really have just the am33xx exception to the rule?
> 
> ti,timer-alwon may not be needed yes, since on all platforms I've observed first
> timer has this property. However from OMAP3 dt, timer12 has it too. Not sure
> what that implies.

I guess you could mark timer1 and 12 as always on if the compatible flag 
matches ti,omap3430-timer.
 
> I think what Jon was trying to do is to find a DT node by property, he had no
> other way of getting a device_node * otherwise.
> 
> But notice this macro used for HS (secure devices):
> OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
>                         2, "timer_sys_ck", NULL);
> 
> How would you specify in DT that you want a node with the timer-secure property
> as the clocksource if we drop these kind of properties?

timer {
	interrupt-parent = <&timer12>;
	...
}

Should do the trick I think :)
 
> >>> Then for the users of a specific dmtimer, they can select the right one using
> >>> the interrupt-parent property:
> >>>
> >>> timer1: timer at 0x4800abcd {
> >>> 	compatible = "ti,omap5430-timer";
> >>> 	#interrupt-cells = <1>;		/* needs irqchip implemented for dmtimer */
> >>> 	interrupt-controller;
> >>> 	#clock-cells = <1>;		/* needs clocksource implemented for dmtimer */
> >>> 	clock-output-names = "32k", "sys_ck";
> >>> 	...
> >>> };
> >>
> >> In reference to my last thread reply, irqchip may not be available early in the
> >> boot process (.init_time) for system timer usage?
> > 
> > Hmm it should be, looks like we have in arch/arm/kernel/irq.c:
> > 
> > void __init init_IRQ(void)
> > {
> > 	if (IS_ENABLED(CONFIG_OF) && !machine_desc->init_irq)
> > 		irqchip_init();
> > 	else    
> > 		machine_desc->init_irq();
> > }               
> > 
> > Then in init/main.c has:
> > 	...
> > 	early_irq_init();
> > 	init_IRQ();
> > 	tick_init();
> > 	init_timers();
> > 	hrtimers_init();
> > 	softirq_init();
> > 	timekeeping_init();
> > 	time_init();
> > 	...
> > 
> > So looks like we should have irqchip available?
> 
> Right. I think your idea of using irqchip is certainly a clean way. Let me go
> back to the drawing board and try to see if we have all the pieces we need and
> there are no surprises in doing it this way.

OK cool.
 
> Then we can have a general purpose clocksource driver that uses the irqchip
> driver. I still worry about things like hwmod that may be need to be called on
> specific timer, and runtime PM is not available that early in the boot process.

Yeah we may still need a piece of code in mach-omap2 for now if runtime PM is
not available at that point yet.

Regards,

Tony