Re: [PATCH] clockevents: Add a clkevt-of mechanism like clksrc-of

[Daniel Lezcano]

On Mon, Jan 30, 2017 at 02:04:42PM +0300, Alexander Kochetkov wrote:
> 
> > 25 ÑÐÐ. 2017 Ð., Ð 15:21, Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> ÐÐÐÐÑÐÐ(Ð):
> > 
> > Hopefully, that can help to do some housework in the directory, perhaps
> > split the drivers in to entities, for example:
> > 	- clksrc-rockchip.c
> > 	- clkevt-rockchip.c
> > 
> > Also, it gives the possibility to declare clocksources separately in the
> > DT and then use a clocksource from IP block while while clockevents are
> > used from another IP block.
> 
> Hello, Daniel!
> 
> There is no way to do declare clocksources and clockevents in the DT now.
> As I understood, it is incorrect to add properties like âclocksourceâ or âclockeventâ
> to timer entries because this sounds like linux specific configuration. While
> device tree must contain only hardware description. Thus many timer
> drivers has implicit assumption: first DT timer became clocksource, second
> clockevent.

Hi Alexander,

actually, if we keep the current definition, the macro can help to split the
drivers, for instance:

CLOCKEVENT_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer",
			rk3288_clkevt_init);

CLOCKSOURCE_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer",
			rk3288_clksrc_init);

So in the code, there will be clearly a code path for the clocksource
initialization and another one for the clockevent. That will help to clarify the code
and will let to replace the global 'already initialized' variable by something
more adequate.

I'm realizing it would be simpler to do the changes with a driver directly
instead of giving a long explanation of what we can do.

Beside, Adding a 'clksrc' / 'clkevt' property (or whatever the name) is
acceptable, but the node name *must* remain 'timer'.

> If we can find the way to describe timer role in the DT, than many timer drivers
> could be rewritten such a way.
> 
> Also, there is timers what use single IP to provide clocksource and clockevent
> at the same time. So splitting them into two files result into more complex code.

Yes, physically both can be in the same IP and that is usually the case. IMO,
we should not stick necessarly to a physical view of the hardware but to a
software vision of what the hardware provides. The only pitfall is code
duplication, but I will be watching to prevent that ;)

As mentionned above, I will send a patchset with a driver using the macro and
the resulting changes, that will help to illustrate the purpose of this patch.

  -- Daniel

-- 

 <http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog