dw_apb_timer_of.c: remove parts that were picoxcell-specific

[Pavel Machek]

On Tue 2013-05-07 17:30:52, John Stultz wrote:
> On 05/07/2013 01:11 PM, Pavel Machek wrote:
> >It seems we made a mistake when creating dw_apb_timer_of.c:
> >picoxcell sched_clock had parts that were not related to
> >dw_apb_timer, yet we moved them to dw_apb_timer_of, and tried to
> >use them on socfpga.
> >
> >This results in system where user/system time is not measured
> >properly, as demonstrated by
> >     time dd if=/dev/urandom of=/dev/zero bs=100000 count=100
> >So this patch switches sched_clock to hardware that exists on both
> >platforms, and adds missing of_node_put() in dw_apb_timer_init().
> >Signed-off-by: Pavel Machek <pavel at denx.de>
> >Acked-by: Jamie Iles <jamie at jamieiles.com>
> 
> Ok. I'm still not a happy about the general issue of
> sched_clock/clockevent code being in drivers/clocksources (I know,
> everyone is sick of my griping about it :), so reviewing this sucks,
> but at least this patch technically isn't making that issue worse.

Is there anything concrete you'd like to improve?

Yes, clocksource/clockevent split is confusing, doubly so because it
is same hardware driving both. Would it make sense to create "use this
clocksource for sched_clock()" helper?

> Additionally, this is an *ugly* driver in my opinion. Its split
> between arch specific logic in arch/x86/kernel/apb_timer.c,
> arch/arm/mach-picoxcell/common.c, and
> arch/arm/mach-socfpga/socfpga.c, and 

Can you elaborate? There's very little logic in socfpga.c, just single
line

        .timer          = &dw_apb_timer,

> then arch independent logic in
> drivers/clocksource/dw_apb_timer.c and
> drivers/clocksource/dw_apb_timer_of.c, but then it seems like much
> of drivers/clocksource/dw_apb_timer_of.c is actually ARM specific.

dw_apb_timer_of.c ... it should not be arm specific. Yes, it was
originally separated from picoxcell code, and so far only picoxcell &
socfpga use it, but it should work on other architectures, too..

> Are there any plans to clean this up in the future?

I can try, but I'd need a bit better idea what needs to be done. Would
"use this clocksource for sched_clock()" helper be acceptable?

> But I've gone ahead and queued this for 3.11.

Thanks!
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html