Re: [patch 2.6.25-rc2-git 2/2] atmel_tc clocksource/clockevent code

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Haavard Skinnemoen
Date: Sunday, February 24, 2008 - 11:21 am

Again, sorry for the delay...it really sucks that I haven't been able
to look at this stuff closely until now. Hopefully a late review is
better than no review.

On Fri, 22 Feb 2008 17:28:37 -0800
David Brownell <david-b@pacbell.net> wrote:


Why do you need to use the raw version?


Did you just open-code a do/while loop using goto? ;-)


Can't you just use #ifndef CONFIG_ARCH_AT91RM9200 and avoid the whole
ifdef/define/undef dance above?


Hmm. Do you really want to stop it? Won't you get better accuracy if
you let it run and program the next event as (prev_event + delta)?


I don't think you need to define this statically. You can call
request_irq() at arch_initcall() time.


I don't think it is safe to assume that one clock per channel always
means one irq per channel as well...

What's wrong with

	irq = platform_get_irq(pdev, 2);
	if (irq < 0)
		irq = platform_get_irq(pdev, 0);

?


Hmm...I don't like the direction this is going...

How about we make tcb_clksrc_init() global and call it from the
platform code with whatever TCB the platform thinks is appropriate?

Perhaps remove the prompt from ATMEL_TCB_CLKSRC and have the platform
select it as well? I certainly want to force this stuff on on the
AP7000...otherwise we'll just get lots of complaints that the thing is
using 4x more power than it's supposed to...

Haavard
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [patch 2.6.25-rc2-git 2/2] atmel_tc clocksource/clocke ..., Haavard Skinnemoen, (Sun Feb 24, 11:21 am)
Re: [patch 2.6.25-rc2-git 2/2] atmel_tc clocksource/clocke ..., Haavard Skinnemoen, (Mon Feb 25, 4:31 am)
Re: [patch 2.6.25-rc2-git 2/2] atmel_tc clocksource/clocke ..., Haavard Skinnemoen, (Tue Feb 26, 2:16 am)