Re: [RFC 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs

[Joel Fernandes]

On 03/14/2014 10:52 AM, Tony Lindgren wrote:
> * Joel Fernandes <joelf@xxxxxx> [140313 16:52]:
>> On 03/13/2014 03:48 PM, Tony Lindgren wrote:
>>> * Joel Fernandes <joelf@xxxxxx> [140313 13:43]:
>>>> We introduce functions to initialize clocksource and clockevent, use
>>>> CLOCKSOURCE_OF_DECLARE to declare the clocksource, and handle the clocksource
>>>> selection on a per-SoC basis (Currently only AM335x is supported). Powering up
>>>> of the timer will be done with the help of the mach-omap layer function that's
>>>> introduced earlier in the series.
>>>>
>>>> We make a local copy of dmtimer API for use by clocksource, the original
>>>> dmtimer API in plat-omap is kept as-is till the migration of all SoCs is
>>>> completed after which it can't be deleted.
>>>>
>>>> Signed-off-by: Joel Fernandes <joelf@xxxxxx>
>>>> ---
>>>>  drivers/clocksource/Makefile     |    1 +
>>>>  drivers/clocksource/omap-timer.c | 1157 ++++++++++++++++++++++++++++++++++++++
>>>>  drivers/clocksource/omap-timer.h |  422 ++++++++++++++
>>>>  3 files changed, 1580 insertions(+)
>>>>  create mode 100644 drivers/clocksource/omap-timer.c
>>>>  create mode 100644 drivers/clocksource/omap-timer.h
>>>
>>> Hmm this leaves duplicate arch/arm/plat-omap/dmtimer.c code, please
>>
>> Sure, ofcourse- but how else can we make sure everything works while we do
>> the migration in steps. We can get rid of the duplicate once everything is
>> migrated.
> 
> That's not doing incremental changes then. You're not even modifying
> the existing omap_dm_timer functions, so please do the changes in incremental
> steps where things keep working throughout the series.

That is much more work than appears- it is much easier to remove what you
don't want after everything is moved, than to pick things up part by part
and move it.. That way we also don't accidentally remove something we
shouldn't be and introduced more regressions.. right?

Plus this is an RFC that I whipped up in 2 days so I didn't this
expectations should be too high ;-)

>>> And not the that drivers/clocksource/omap-timer.h won't be needed at
>>> all, those defines can stay private to the drivers/clocksource/omap-timer.c.
>>
>> Actually- I wanted it separate because omap-timer.c is already huge at 1157
>> lines. Infact the largest among the clocksource drivers. Is that fair?
> 
> No need for it. We want to keep these functions private to the driver.

Ok, I can do that. I don't mind either way.

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