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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Nov 2013 09:08:01 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Joel Fernandes <joelf@...com>
Cc:	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, benoit.cousson@...aro.org,
	santosh.shilimkar@...com, jgchunter@...il.com, rnayak@...com,
	balbi@...com
Subject: Re: [PATCH 6/8] devicetree: doc: Document ti,timer-parent property

* Joel Fernandes <joelf@...com> [131122 08:37]:
> Hi Tony,
> 
> Thanks for your comments, few replies inline below..
> 
> On 11/22/2013 09:58 AM, Tony Lindgren wrote:
> > * Joel Fernandes <joelf@...com> [131121 18:00]:
> >> +Required properties for system timers (clockevents/clocksource):
> >> +- ti,timer-parent:	System timer's parent mux clock needs to be setup.
> >> +			This is currently hardcoded in code, for DT boot we
> >> +			move this to DT.
> >> +
> > 
> > This can be replaced with just clk_set_rate, or clk_set_parent if needed.
> > Or by having a clocks = <&32k_clk> property in the dmtimer node in the
> > .dts file.
> > 
> 
> Sure, but clock-data is still not available to make this possible in mainline.
> We also discussed earlier right that we don't want dependencies as much as
> possible to get one chunk in and working at a time. I was thinking like for a
> first-pass since there's a lot of unrelated code that doesn't have dependencies,
> but needs this to work, we can introduce this property for now and drop it later
> as a "cost of migration"?

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.
 
> >>  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?

> > Then for the users of a specific dmtimer, they can select the right one using
> > the interrupt-parent property:
> > 
> > timer1: timer@...800abcd {
> > 	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?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/