linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: joelf@ti.com (Joel Fernandes)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs
Date: Fri, 14 Mar 2014 14:32:51 -0500	[thread overview]
Message-ID: <53235963.4080503@ti.com> (raw)
In-Reply-To: <20140314155202.GA27560@atomide.com>

On 03/14/2014 10:52 AM, Tony Lindgren wrote:
> * Joel Fernandes <joelf@ti.com> [140313 16:52]:
>> On 03/13/2014 03:48 PM, Tony Lindgren wrote:
>>> * Joel Fernandes <joelf@TI.com> [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@ti.com>
>>>> ---
>>>>  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

  reply	other threads:[~2014-03-14 19:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-13 20:35 [RFC 0/5] Clocksource driver for OMAP SoCs Joel Fernandes
2014-03-13 20:35 ` [RFC 1/5] ARM: dts: am33xx: Add clock nodes for timer1 and timer2 Joel Fernandes
2014-03-13 20:35 ` [RFC 2/5] ARM: dts: am33xx: Set parent clock for timer through DT Joel Fernandes
2014-03-14  8:08   ` Tero Kristo
2014-03-13 20:35 ` [RFC 3/5] ARM: OMAP2+: timer: Add clocksource initialization and powerup support Joel Fernandes
2014-03-13 21:52   ` Rob Herring
2014-03-13 23:36     ` Joel Fernandes
2014-03-14  8:03       ` Tero Kristo
2014-03-14 21:09       ` Kevin Hilman
2014-03-14 21:16         ` Rob Herring
2014-03-13 20:35 ` [RFC 4/5] clocksource: omap-timer: Introduce clocksource driver for OMAP SoCs Joel Fernandes
2014-03-13 20:48   ` Tony Lindgren
2014-03-13 23:49     ` Joel Fernandes
2014-03-14 15:52       ` Tony Lindgren
2014-03-14 19:32         ` Joel Fernandes [this message]
2014-03-14 19:33           ` Joel Fernandes
2014-03-15  0:13   ` Suman Anna
2014-03-15  1:11     ` Joel Fernandes
2014-03-13 20:35 ` [RFC 5/5] ARM: AM33xx: Move to using omap_generic_timer_init for init_time Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53235963.4080503@ti.com \
    --to=joelf@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).