Messages in this thread | | | Date | Fri, 10 May 2013 14:38:23 +0200 | From | Pavel Machek <> | Subject | Re: dw_apb_timer_of.c: remove parts that were picoxcell-specific |
| |
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@denx.de> > >Acked-by: Jamie Iles <jamie@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
| |