* Joel Fernandes <joelf@xxxxxx> [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@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@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
--
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
