Patchwork [GIT,PULL] dmtimer changes for v3.2 merge window

login
register
mail settings
Submitter Tony Lindgren
Date Sept. 28, 2011, 10:02 p.m.
Message ID <20110928220237.GE6324@atomide.com>
Download mbox
Permalink /patch/116858/
State New
Headers show

Pull-request

git://github.com/tmlind/linux.git dmtimer

Comments

Tony Lindgren - Sept. 28, 2011, 10:02 p.m.
Hi Arnd,

Please pull omap dmtimer changes from:

git://github.com/tmlind/linux.git dmtimer

This series completes the system timer separation from the
driver like features. It also adds support for v2 ip that is
available for some timers starting with omap4.

After this series arch/arm/plat-omap/dmtimer.c could be
moved to live under drivers somewhere, but there is still
discussion going on which features should be supported in
a generic way.

This series depends on the cleanup you pulled earlier.
As this series adds some new features like runtime PM suppport,
I've kept it separate from cleanup.

Regards,

Tony


The following changes since commit ceb1c532ba6220900e61ec7073a9234661efa450:
  Tony Lindgren (1):
        Merge branch 'omap_chip_remove_cleanup_3.2' of git://git.pwsan.com/linux-2.6 into cleanup

are available in the git repository at:

  git://github.com/tmlind/linux.git dmtimer

Tarun Kanti DebBarma (8):
      ARM: OMAP2+: dmtimer: add device names to flck nodes
      ARM: OMAP1: dmtimer: conversion to platform devices
      ARM: OMAP2+: dmtimer: convert to platform devices
      ARM: OMAP: dmtimer: platform driver
      ARM: OMAP: dmtimer: switch-over to platform device driver
      ARM: OMAP: dmtimer: pm_runtime support
      ARM: OMAP: dmtimer: low-power mode support
      ARM: OMAP: dmtimer: add error handling to export APIs

Tony Lindgren (2):
      ARM: OMAP: Add support for dmtimer v2 ip
      ARM: OMAP: dmtimer: skip reserved timers

 arch/arm/mach-omap1/Makefile               |    2 +-
 arch/arm/mach-omap1/timer.c                |  173 +++++++
 arch/arm/mach-omap2/clock2420_data.c       |   48 ++
 arch/arm/mach-omap2/clock2430_data.c       |   48 ++
 arch/arm/mach-omap2/clock3xxx_data.c       |   36 ++
 arch/arm/mach-omap2/clock44xx_data.c       |   33 ++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   22 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   22 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   27 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   22 +
 arch/arm/mach-omap2/timer.c                |  194 +++++++-
 arch/arm/plat-omap/dmtimer.c               |  713 ++++++++++++++++------------
 arch/arm/plat-omap/include/plat/dmtimer.h  |  233 +++++++---
 13 files changed, 1185 insertions(+), 388 deletions(-)
 create mode 100644 arch/arm/mach-omap1/timer.c
Arnd Bergmann - Sept. 30, 2011, 8:13 p.m.
On Thursday 29 September 2011, Tony Lindgren wrote:
> Please pull omap dmtimer changes from:
> 
> git://github.com/tmlind/linux.git dmtimer
> 
> This series completes the system timer separation from the
> driver like features. It also adds support for v2 ip that is
> available for some timers starting with omap4.
> 
> After this series arch/arm/plat-omap/dmtimer.c could be
> moved to live under drivers somewhere, but there is still
> discussion going on which features should be supported in
> a generic way.
> 
> This series depends on the cleanup you pulled earlier.
> As this series adds some new features like runtime PM suppport,
> I've kept it separate from cleanup.

Looks really nice. I've put it into another top-level branch
named next/dmtimer for now. I'm open for suggestions on whether
I should generally push branches like this separately Linuswards
or better aggregate multiple standalone features into a single
branch. 

	Arnd
Tony Lindgren - Sept. 30, 2011, 8:43 p.m.
* Arnd Bergmann <arnd@arndb.de> [110930 12:40]:
> On Thursday 29 September 2011, Tony Lindgren wrote:
> > Please pull omap dmtimer changes from:
> > 
> > git://github.com/tmlind/linux.git dmtimer
> > 
> > This series completes the system timer separation from the
> > driver like features. It also adds support for v2 ip that is
> > available for some timers starting with omap4.
> > 
> > After this series arch/arm/plat-omap/dmtimer.c could be
> > moved to live under drivers somewhere, but there is still
> > discussion going on which features should be supported in
> > a generic way.
> > 
> > This series depends on the cleanup you pulled earlier.
> > As this series adds some new features like runtime PM suppport,
> > I've kept it separate from cleanup.
> 
> Looks really nice. I've put it into another top-level branch
> named next/dmtimer for now. I'm open for suggestions on whether
> I should generally push branches like this separately Linuswards
> or better aggregate multiple standalone features into a single
> branch. 

How about a branch called driver?

There are still lots of pieces of code under arch/arm that should
be eventually moved to live under drivers. For example the mux
code and most of PM code can eventually be under drivers.

But before that can be done some preparation is often needed,
the actual move to live under drivers should be handled then
by the driver and subsystem maintainers.

Regards,

Tony
Arnd Bergmann - Sept. 30, 2011, 8:52 p.m.
On Friday 30 September 2011, Tony Lindgren wrote:
> How about a branch called driver?
> 
> There are still lots of pieces of code under arch/arm that should
> be eventually moved to live under drivers. For example the mux
> code and most of PM code can eventually be under drivers.

Yes, good idea! For the omap/voltage series, I currently plan to
group that with pm changes for that I got for the other socs
this time, but if there was less of it, that could also be drivers.

> But before that can be done some preparation is often needed,
> the actual move to live under drivers should be handled then
> by the driver and subsystem maintainers.

I think in some cases we first need to nominate a subsystem
maintainer who can take the drivers, but that's a different
issue.

	Arnd
Tony Lindgren - Oct. 4, 2011, 12:07 a.m.
* Arnd Bergmann <arnd@arndb.de> [111001 09:12]:
> On Friday 30 September 2011 22:13:42 Arnd Bergmann wrote:
> > On Thursday 29 September 2011, Tony Lindgren wrote:
> > > Please pull omap dmtimer changes from:
> > > 
> > > git://github.com/tmlind/linux.git dmtimer
> > > 
> > > This series completes the system timer separation from the
> > > driver like features. It also adds support for v2 ip that is
> > > available for some timers starting with omap4.
> > > 
> > > After this series arch/arm/plat-omap/dmtimer.c could be
> > > moved to live under drivers somewhere, but there is still
> > > discussion going on which features should be supported in
> > > a generic way.
> > > 
> > > This series depends on the cleanup you pulled earlier.
> > > As this series adds some new features like runtime PM suppport,
> > > I've kept it separate from cleanup.
> > 
> > Looks really nice. I've put it into another top-level branch
> > named next/dmtimer for now. I'm open for suggestions on whether
> > I should generally push branches like this separately Linuswards
> > or better aggregate multiple standalone features into a single
> > branch. 
> 
> I'm adding the patch below to fix a trivial randconfig build regression
> in this series.
> 
> 	Arnd
> 
> 8<---
> 
> Subject: [PATCH] ARM: omap: use __devexit_p in dmtimer driver
> 
> The omap_dm_timer_remove function gets discarded when
> CONFIG_HOTPLUG is not set, so we must not reference it
> unconditionally.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Great, thanks!

Acked-by: Tony Lindgren <tony@atomide.com>
 
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index de7896f..2def4e1 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -723,7 +723,7 @@ static int __devexit omap_dm_timer_remove(struct platform_device *pdev)
>  
>  static struct platform_driver omap_dm_timer_driver = {
>  	.probe  = omap_dm_timer_probe,
> -	.remove = omap_dm_timer_remove,
> +	.remove = __devexit_p(omap_dm_timer_remove),
>  	.driver = {
>  		.name   = "omap_timer",
>  	},
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html