Re: [PATCH 0/5] PM / clock_ops: provide default runtime ops and cleanup users

2015-04-27 Thread Simon Horman 
On Fri, Apr 24, 2015 at 04:51:03PM +0200, Geert Uytterhoeven wrote:
 On Fri, Apr 24, 2015 at 4:41 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
  On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote:
  Most users of PM clocks do the exact same thing in runtime callbacks.
  Provide default callbacks and cleanup the existing users (keystone/davinci
  /omap1/sh)
 
  Rajendra Nayak (5):
PM / clock_ops: Provide default runtime ops to users
arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
 
   arch/arm/mach-davinci/pm_domain.c  | 32 +-
   arch/arm/mach-keystone/pm_domain.c | 33 +-
   arch/arm/mach-omap1/pm_bus.c   | 37 ++
   drivers/base/power/clock_ops.c | 38 ++
   drivers/sh/pm_runtime.c| 47 
  ++
   include/linux/pm_clock.h   | 10 
   6 files changed, 54 insertions(+), 143 deletions(-)
 
  It is not particularly clear to me who is supposed to apply this series, but
  I can do that if people don't have problems with that.
 
 All later patches depend on the first patch.
 
 For shmobile, Simon has queued up changes for drivers/sh/pm_runtime.c,
 but I think they don't conflict with this series.

Yes, that is the case. I have some patches (from Geert) queued up for v4.1.
I have confirmed that they do not conflict with the shmobile (last) patch
if this series.

details
The patches are in the sh-drivers-for-v4.1 branch of my renesas tree; I
rebased them yesterday; they should hit next today if there is a next
today; I plan to send a pull request to Linus in the not to distant future;
and I envisage they should end up in v4.1-rc2 or rc3.  /details

On Fri, Apr 24, 2015 at 08:34:33AM -0700, santosh shilimkar wrote:
 On 4/24/2015 7:41 AM, Rafael J. Wysocki wrote:
 On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote:

[snip]

 It is not particularly clear to me who is supposed to apply this series, but
 I can do that if people don't have problems with that.
 
 
 I am fine by that given dependency with first patch.
 Another way is, you pick up the first patch and give us an
 immutable branch.
 
 Either way is fine by me.

Likewise.

Here is an ack for the shmobile (last) patch if you decide to take it
through your tree.

Acked-by: Simon Horman horms+rene...@verge.net.au

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page

2015-03-27 Thread Simon Horman 
On Fri, Mar 27, 2015 at 10:06:12AM +, Will Deacon wrote:
 On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote:
  On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
   On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote:
On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote:
On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
 I think we now have a new error: (seen with omap2plus_defconfig)
 on next-20150324 :
 ./arch/arm/kernel/vmlinux.lds:677: undefined symbol 
 `__hyp_idmap_size'
 referenced in expression
 make: *** [vmlinux] Error 1
   
Thanks, I am seeing that too.
   
My armchair suggestion is that the following should be reverted.
   
e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL())
06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page)
   
Can you try again with the latest -next please? We've merged an 
additional
patch aimed at sorting this out. Reverting isn't really an option, as
there's an awful lot of code that depends on the bounce page removal.
   
   Here are the kernelci.org -next results[1], if you click the build
   status you can dig down into the build failures. next-20150326 has now
   hit a compiler bug, Arnd mentioned he was looking into this issue.
  
  I have confirmed that next-20150326 does not compile without
  the following reverted:
  
  12eb3e833961 (ARM: kvm: assert on HYP section boundaries not actual code 
  size)
  e60a1fec44a2 (ARM: kvm: implement replacement for ld's LOG2CEIL())
  06f75a1f6200 (ARM, arm64: kvm: get rid of the bounce page)
 
 Thanks for testing this and sorry for the continued breakage. Which
 toolchain did you say you were using? Ard has some more patches trying to
 fix this, but none of our toolchains seem to tickle the issue.

It seems that a fix has emerged (thanks! local testing looks good so far)
but for the record I am using the arm (32) tool chain for x86_84
on kernel.org.

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/

# arm-unknown-linux-gnueabi-gcc --version
arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# arm-unknown-linux-gnueabi-ld --version
GNU ld (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page

2015-03-26 Thread Simon Horman 
On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
 On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote:
  On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote:
  On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
   I think we now have a new error: (seen with omap2plus_defconfig)
   on next-20150324 :
   ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
   referenced in expression
   make: *** [vmlinux] Error 1
 
  Thanks, I am seeing that too.
 
  My armchair suggestion is that the following should be reverted.
 
  e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL())
  06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page)
 
  Can you try again with the latest -next please? We've merged an additional
  patch aimed at sorting this out. Reverting isn't really an option, as
  there's an awful lot of code that depends on the bounce page removal.
 
 Here are the kernelci.org -next results[1], if you click the build
 status you can dig down into the build failures. next-20150326 has now
 hit a compiler bug, Arnd mentioned he was looking into this issue.

I have confirmed that next-20150326 does not compile without
the following reverted:

12eb3e833961 (ARM: kvm: assert on HYP section boundaries not actual code size)
e60a1fec44a2 (ARM: kvm: implement replacement for ld's LOG2CEIL())
06f75a1f6200 (ARM, arm64: kvm: get rid of the bounce page)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page

2015-03-25 Thread Simon Horman 
Hi Nishanth,

On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
 On 09:31-20150324, Ard Biesheuvel wrote:
  On 24 March 2015 at 01:45, Simon Horman ho...@verge.net.au wrote:
   Hi Ard,
  
   I have observe what appears to be a build regression in next-20150323
   caused by 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page).
  
   # make
   ...
   arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax 
   error
  
   I have observed this using the cross-compiler that is available on 
   kernel.org:
  
   https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
  
   # arm-unknown-linux-gnueabi-gcc --version
   arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
   Copyright (C) 2011 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
   PURPOSE.
  
   # arm-unknown-linux-gnueabi-ld --version
   GNU ld (GNU Binutils) 2.22
   Copyright 2011 Free Software Foundation, Inc.
   This program is free software; you may redistribute it under the terms of
   the GNU General Public License version 3 or (at your option) a later 
   version.
   This program has absolutely no warranty.
  
  
  Hi all,
  
  This is fixed now in next-20150324.
  Sorry for the trouble
 
 I think we now have a new error: (seen with omap2plus_defconfig)
 on next-20150324 :
 ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
 referenced in expression
 make: *** [vmlinux] Error 1

Thanks, I am seeing that too.

My armchair suggestion is that the following should be reverted.

e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL())
06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page)

 cross compiler (from ubuntu 12.04):
 $ arm-linux-gnueabi-ld --version
 GNU ld (GNU Binutils for Ubuntu) 2.22
 Copyright 2011 Free Software Foundation, Inc.
 This program is free software; you may redistribute it under the terms of
 the GNU General Public License version 3 or (at your option) a later version.
 This program has absolutely no warranty.
 $ arm-linux-gnueabi-gcc --version
 arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
 Copyright (C) 2011 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
 next-20150320 was the last kernel which was successfully built

I have also confirmed that.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression with legacy IRQ numbers caused by 9a1091ef0017

2015-01-16 Thread Simon Horman 
On Fri, Jan 16, 2015 at 05:23:05PM +, Marc Zyngier wrote:
 On 16/01/15 16:56, Arnd Bergmann wrote:
  On Thursday 15 January 2015 07:37:48 Tony Lindgren wrote:
  * Marc Zyngier marc.zyng...@arm.com [150115 06:46]:
  On Thu, Jan 15 2015 at  2:27:56 pm GMT, Arnd Bergmann a...@arndb.de 
  wrote:
  On Thursday 15 January 2015 13:42:57 Marc Zyngier wrote:
  Probably there is a workable strategy, but my knowledge about OMAP is
  close to *nothing*...
 
  I have a feeling this might bite other platforms too and we just have
  not noticed it yet..
  
  I'm looking through the entire tree now, scanning for machines that have
  GIC and use IORESOURCE_IRQ or DEFINE_RES_IRQ in their platform code.
  Most platforms using GIC are completely converted to DT and have no
  hardcoded legacy IRQs.
  
  I have checked that cns3xxx and realview are both fine by inspection.
  
  The only one I'm not sure about is shmobile, which looks like it might
  suffer from the same problem. Simon/Magnus, could you verify this
  with a multiplatform kernel on any SoC that has GIC and uses devices
  that have interrupts defined in setup-*.c or board-*.c?
 
 There are 3 patches floating around for shmobile, converting their
 non-DT support to directly initializing the GIC instead of relying on
 irqchip_init().

There is also a fourth patch pending to fix one last SoC, the r8a73a4.
My understanding is that should be the end of the problems that
we have been seeing in this area.

 That's assuming their DT implementation doesn't use any
 of these device declarations.

I believe that assumption is correct. shmobile does not use any
devices that have interrupts defined in setup-*.c or board-*.c when
booting using multiplatform.

 If they do, we could use a hack similar to the one I implemented for
 OMAP, populating the virtual IRQ in the resource at boot time, just
 after the irqchip initialization.
 
 Thanks,
 
   M.
 -- 
 Jazz is not dead. It just smells funny...
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP completely

2014-09-15 Thread Simon Horman 
On Fri, Sep 12, 2014 at 10:38:31AM +0200, Paul Bolle wrote:
 The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit
 049d595a4db3 (PM / OPP: Make OPP invisible to users in Kconfig)
 removed the only dependency that used it. Setting it had no effect
 anymore.
 
 So commit 78c5e0bb145d (PM / OPP: Remove ARCH_HAS_OPP) removed it. For
 some reason that commit did not remove all select statements for that
 symbol. These statements are useless. Remove them too.
 
 Signed-off-by: Paul Bolle pebo...@tiscali.nl
 ---
 Done on top of next-20140912. Tested with git grep only!

Hi Paul,

could you break the shmobile portion out into a separate patch
for me to take through my renesas tree?

I am concerned that taking those changes via a different
route will result in conflicts as arch/arm/mach-shmobile/Kconfig
is often updated.

  arch/arm/mach-omap2/Kconfig| 5 -
  arch/arm/mach-shmobile/Kconfig | 1 -
  drivers/devfreq/Kconfig| 1 -
  3 files changed, 7 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index 5b103099626d..f138bd33a463 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -22,7 +22,6 @@ config ARCH_OMAP4
   bool TI OMAP4
   depends on ARCH_MULTI_V7
   select ARCH_OMAP2PLUS
 - select ARCH_HAS_OPP
   select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
   select ARM_CPU_SUSPEND if PM
   select ARM_ERRATA_720789
 @@ -41,7 +40,6 @@ config SOC_OMAP5
   bool TI OMAP5
   depends on ARCH_MULTI_V7
   select ARCH_OMAP2PLUS
 - select ARCH_HAS_OPP
   select ARM_CPU_SUSPEND if PM
   select ARM_GIC
   select HAVE_ARM_SCU if SMP
 @@ -53,14 +51,12 @@ config SOC_AM33XX
   bool TI AM33XX
   depends on ARCH_MULTI_V7
   select ARCH_OMAP2PLUS
 - select ARCH_HAS_OPP
   select ARM_CPU_SUSPEND if PM
  
  config SOC_AM43XX
   bool TI AM43x
   depends on ARCH_MULTI_V7
   select ARCH_OMAP2PLUS
 - select ARCH_HAS_OPP
   select ARM_GIC
   select MACH_OMAP_GENERIC
   select MIGHT_HAVE_CACHE_L2X0
 @@ -69,7 +65,6 @@ config SOC_DRA7XX
   bool TI DRA7XX
   depends on ARCH_MULTI_V7
   select ARCH_OMAP2PLUS
 - select ARCH_HAS_OPP
   select ARM_CPU_SUSPEND if PM
   select ARM_GIC
   select HAVE_ARM_ARCH_TIMER
 diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
 index 21f457b56c01..f59019dd986e 100644
 --- a/arch/arm/mach-shmobile/Kconfig
 +++ b/arch/arm/mach-shmobile/Kconfig
 @@ -36,7 +36,6 @@ menuconfig ARCH_SHMOBILE_MULTI
   select NO_IOPORT_MAP
   select PINCTRL
   select ARCH_REQUIRE_GPIOLIB
 - select ARCH_HAS_OPP
  
  if ARCH_SHMOBILE_MULTI
  
 diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
 index 3dced0a9eae3..2227e9bf3884 100644
 --- a/drivers/devfreq/Kconfig
 +++ b/drivers/devfreq/Kconfig
 @@ -80,7 +80,6 @@ config ARM_EXYNOS4_BUS_DEVFREQ
  config ARM_EXYNOS5_BUS_DEVFREQ
   bool ARM Exynos5250 Bus DEVFREQ Driver
   depends on SOC_EXYNOS5250
 - select ARCH_HAS_OPP
   select DEVFREQ_GOV_SIMPLE_ONDEMAND
   select PM_OPP
   help
 -- 
 1.9.3
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP completely

2014-09-15 Thread Simon Horman 
On Tue, Sep 16, 2014 at 09:09:17AM +0900, Simon Horman wrote:
 On Fri, Sep 12, 2014 at 10:38:31AM +0200, Paul Bolle wrote:
  The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit
  049d595a4db3 (PM / OPP: Make OPP invisible to users in Kconfig)
  removed the only dependency that used it. Setting it had no effect
  anymore.
  
  So commit 78c5e0bb145d (PM / OPP: Remove ARCH_HAS_OPP) removed it. For
  some reason that commit did not remove all select statements for that
  symbol. These statements are useless. Remove them too.
  
  Signed-off-by: Paul Bolle pebo...@tiscali.nl
  ---
  Done on top of next-20140912. Tested with git grep only!
 
 Hi Paul,
 
 could you break the shmobile portion out into a separate patch
 for me to take through my renesas tree?
 
 I am concerned that taking those changes via a different
 route will result in conflicts as arch/arm/mach-shmobile/Kconfig
 is often updated.

Of course the above comment is redundant if Rafael
has already taken this patch.

 
   arch/arm/mach-omap2/Kconfig| 5 -
   arch/arm/mach-shmobile/Kconfig | 1 -
   drivers/devfreq/Kconfig| 1 -
   3 files changed, 7 deletions(-)
  
  diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
  index 5b103099626d..f138bd33a463 100644
  --- a/arch/arm/mach-omap2/Kconfig
  +++ b/arch/arm/mach-omap2/Kconfig
  @@ -22,7 +22,6 @@ config ARCH_OMAP4
  bool TI OMAP4
  depends on ARCH_MULTI_V7
  select ARCH_OMAP2PLUS
  -   select ARCH_HAS_OPP
  select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
  select ARM_CPU_SUSPEND if PM
  select ARM_ERRATA_720789
  @@ -41,7 +40,6 @@ config SOC_OMAP5
  bool TI OMAP5
  depends on ARCH_MULTI_V7
  select ARCH_OMAP2PLUS
  -   select ARCH_HAS_OPP
  select ARM_CPU_SUSPEND if PM
  select ARM_GIC
  select HAVE_ARM_SCU if SMP
  @@ -53,14 +51,12 @@ config SOC_AM33XX
  bool TI AM33XX
  depends on ARCH_MULTI_V7
  select ARCH_OMAP2PLUS
  -   select ARCH_HAS_OPP
  select ARM_CPU_SUSPEND if PM
   
   config SOC_AM43XX
  bool TI AM43x
  depends on ARCH_MULTI_V7
  select ARCH_OMAP2PLUS
  -   select ARCH_HAS_OPP
  select ARM_GIC
  select MACH_OMAP_GENERIC
  select MIGHT_HAVE_CACHE_L2X0
  @@ -69,7 +65,6 @@ config SOC_DRA7XX
  bool TI DRA7XX
  depends on ARCH_MULTI_V7
  select ARCH_OMAP2PLUS
  -   select ARCH_HAS_OPP
  select ARM_CPU_SUSPEND if PM
  select ARM_GIC
  select HAVE_ARM_ARCH_TIMER
  diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
  index 21f457b56c01..f59019dd986e 100644
  --- a/arch/arm/mach-shmobile/Kconfig
  +++ b/arch/arm/mach-shmobile/Kconfig
  @@ -36,7 +36,6 @@ menuconfig ARCH_SHMOBILE_MULTI
  select NO_IOPORT_MAP
  select PINCTRL
  select ARCH_REQUIRE_GPIOLIB
  -   select ARCH_HAS_OPP
   
   if ARCH_SHMOBILE_MULTI
   
  diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
  index 3dced0a9eae3..2227e9bf3884 100644
  --- a/drivers/devfreq/Kconfig
  +++ b/drivers/devfreq/Kconfig
  @@ -80,7 +80,6 @@ config ARM_EXYNOS4_BUS_DEVFREQ
   config ARM_EXYNOS5_BUS_DEVFREQ
  bool ARM Exynos5250 Bus DEVFREQ Driver
  depends on SOC_EXYNOS5250
  -   select ARCH_HAS_OPP
  select DEVFREQ_GOV_SIMPLE_ONDEMAND
  select PM_OPP
  help
  -- 
  1.9.3
  
  
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP

2014-06-06 Thread Simon Horman 
On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
 From: Mark Brown broo...@linaro.org
 
 Since the OPP layer is a kernel library which has been converted to be
 directly selectable by its callers rather than user selectable and
 requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
 has become redundant and can be removed. Do so.
 
 Signed-off-by: Mark Brown broo...@linaro.org
 ---
  Documentation/power/opp.txt| 3 ---
  arch/arm/mach-exynos/Kconfig   | 1 -
  arch/arm/mach-highbank/Kconfig | 1 -
  arch/arm/mach-imx/Kconfig  | 1 -
  arch/arm/mach-omap2/Kconfig| 1 -
  arch/arm/mach-shmobile/Kconfig | 2 --
  arch/arm/mach-vexpress/Kconfig | 1 -
  arch/arm/mach-zynq/Kconfig | 1 -
  drivers/devfreq/Kconfig| 1 -
  kernel/power/Kconfig   | 3 ---
  10 files changed, 15 deletions(-)

shmobile portion:

Acked-by: Simon Horman horms+rene...@verge.net.au

 diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
 index a9adad8..c6279c2 100644
 --- a/Documentation/power/opp.txt
 +++ b/Documentation/power/opp.txt
 @@ -51,9 +51,6 @@ Typical usage of the OPP library is as follows:
  SoC framework- modifies on required cases certain OPPs  - OPP 
 layer
   - queries to search/retrieve information   -
  
 -Architectures that provide a SoC framework for OPP should select ARCH_HAS_OPP
 -to make the OPP layer available.
 -
  OPP layer expects each domain to be represented by a unique device pointer. 
 SoC
  framework registers a set of initial OPPs per device with the OPP layer. This
  list is expected to be an optimally small number typically around 5 per 
 device.
 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index d58995c9..3f78c45 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -103,7 +103,6 @@ config SOC_EXYNOS5440
   default y
   depends on ARCH_EXYNOS5
   select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
 - select ARCH_HAS_OPP
   select HAVE_ARM_ARCH_TIMER
   select AUTO_ZRELADDR
   select MIGHT_HAVE_PCI
 diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
 index 830b76e..bef970f 100644
 --- a/arch/arm/mach-highbank/Kconfig
 +++ b/arch/arm/mach-highbank/Kconfig
 @@ -3,7 +3,6 @@ config ARCH_HIGHBANK
   select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
   select ARCH_HAS_CPUFREQ
   select ARCH_HAS_HOLES_MEMORYMODEL
 - select ARCH_HAS_OPP
   select ARCH_SUPPORTS_BIG_ENDIAN
   select ARM_AMBA
   select ARM_ERRATA_764369 if SMP
 diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
 index 4cce93d..95690e4 100644
 --- a/arch/arm/mach-imx/Kconfig
 +++ b/arch/arm/mach-imx/Kconfig
 @@ -1,7 +1,6 @@
  config ARCH_MXC
   bool Freescale i.MX family if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
   select ARCH_HAS_CPUFREQ
 - select ARCH_HAS_OPP
   select ARCH_REQUIRE_GPIOLIB
   select ARM_CPU_SUSPEND if PM
   select CLKSRC_MMIO
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index 0ba4826..524b027 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -12,7 +12,6 @@ config ARCH_OMAP3
   bool TI OMAP3
   depends on ARCH_MULTI_V7
   select ARCH_OMAP2PLUS
 - select ARCH_HAS_OPP
   select ARM_CPU_SUSPEND if PM
   select OMAP_INTERCONNECT
   select PM_OPP if PM
 diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
 index dbd954e..b51d142 100644
 --- a/arch/arm/mach-shmobile/Kconfig
 +++ b/arch/arm/mach-shmobile/Kconfig
 @@ -86,7 +86,6 @@ config ARCH_R8A73A4
   select SH_CLK_CPG
   select RENESAS_IRQC
   select ARCH_HAS_CPUFREQ
 - select ARCH_HAS_OPP
   select SYS_SUPPORTS_SH_CMT
   select SYS_SUPPORTS_SH_TMU
  
 @@ -265,7 +264,6 @@ config MACH_KZM9G
   bool KZM-A9-GT board
   depends on ARCH_SH73A0
   select ARCH_HAS_CPUFREQ
 - select ARCH_HAS_OPP
   select ARCH_REQUIRE_GPIOLIB
   select REGULATOR_FIXED_VOLTAGE if REGULATOR
   select SND_SOC_AK4642 if SND_SIMPLE_CARD
 diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
 index 90249cf..71629fe 100644
 --- a/arch/arm/mach-vexpress/Kconfig
 +++ b/arch/arm/mach-vexpress/Kconfig
 @@ -66,7 +66,6 @@ config ARCH_VEXPRESS_DCSCB
  config ARCH_VEXPRESS_SPC
   bool Versatile Express Serial Power Controller (SPC)
   select ARCH_HAS_CPUFREQ
 - select ARCH_HAS_OPP
   select PM_OPP
   help
 The TC2 (A15x2 A7x3) versatile express core tile integrates a logic
 diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
 index 573e0db..bc485f2 100644
 --- a/arch/arm/mach-zynq/Kconfig
 +++ b/arch/arm/mach-zynq/Kconfig
 @@ -1,7 +1,6 @@
  config ARCH_ZYNQ
   bool Xilinx Zynq ARM Cortex A9 Platform if ARCH_MULTI_V7
   select ARCH_HAS_CPUFREQ
 - select ARCH_HAS_OPP
   select ARCH_SUPPORTS_BIG_ENDIAN
   select ARM_AMBA

Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP

2014-06-06 Thread Simon Horman 
On Fri, Jun 06, 2014 at 09:14:01PM +0900, Magnus Damm wrote:
 On Fri, Jun 6, 2014 at 8:14 PM, Simon Horman ho...@verge.net.au wrote:
  On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
  From: Mark Brown broo...@linaro.org
 
  Since the OPP layer is a kernel library which has been converted to be
  directly selectable by its callers rather than user selectable and
  requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
  has become redundant and can be removed. Do so.
 
  Signed-off-by: Mark Brown broo...@linaro.org
  ---
   Documentation/power/opp.txt| 3 ---
   arch/arm/mach-exynos/Kconfig   | 1 -
   arch/arm/mach-highbank/Kconfig | 1 -
   arch/arm/mach-imx/Kconfig  | 1 -
   arch/arm/mach-omap2/Kconfig| 1 -
   arch/arm/mach-shmobile/Kconfig | 2 --
   arch/arm/mach-vexpress/Kconfig | 1 -
   arch/arm/mach-zynq/Kconfig | 1 -
   drivers/devfreq/Kconfig| 1 -
   kernel/power/Kconfig   | 3 ---
   10 files changed, 15 deletions(-)
 
  shmobile portion:
 
  Acked-by: Simon Horman horms+rene...@verge.net.au
 
 Hi Simon, Mark,
 
 Nice to see cleanups in this area. Reducing the number of Kconfig
 symbols must be a good thing.
 
 I'm not sure about the expected merge order for this kind of change vs
 queued up stuff in the renesas git tree, but I believe the following
 patch selects ARCH_HAS_OPP:
 
 [PATCH v3] ARM: shmobile: Mark all SoCs in shmobile as CPUFreq, capable

I propose that we fix that up by adding an incremental patch to
mach-shmobile via my renesas tree once the dependency (assuming there is
one) is in Linus's tree.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 resend 00/11] improve PWM lookup support without device tree

2014-05-19 Thread Simon Horman 
[ CCed Laurent Pinchart ]

The renesas and shmobile portions of this seem reasonable to me
and I have checked that there do not seem to be any conflicts
with changes I already have queued up for v3.16 (and v3.17).

I have CCed Laurent Pinchart as I believe he most recently
did work on the renesas and shmobile code in question.

On Mon, May 19, 2014 at 10:42:31PM +0200, Alexandre Belloni wrote:
 Hi,
 
 Originally sent on Apr 14th, note that this series is blocking another 16
 patches series, I would like it to be taken in 3.16 if we can agree on this
 implementation.
 
 A patch set as suggested by Thierry to make lookup with the lookup table
 instead of device tree behave more like when using device tree.
 
 The first patch adds a period and a polarity member to the lookup table and 
 use
 those to set period and polarity.
 
 Patch 2, 4 and 5 are making use of those new members from the board files.
 Patch 3 removes useless code since setting the polarity is now handled by the
 PWM core.
 
 I couldn't decide on a good name for the extended PWM_LOOKUP macro and I 
 believe
 we won't have to add members to that structure soon so:
 Patch 6 modifies the PWM_LOOKUP macro to also initialize period and polarity
 and
 Patch 7-9 are making use of the new PWM_LOOKUP macro in the board files
 
 Patch 10 and 11 are making the leds-pwm and pwm_bl drivers get the period from
 the PWM before using pwm_period_ns if it is not already set.
 
 Patch 10 will obviously conflict with the series of Russell reworking the
 leds-pwm probing. I can rebase if necessary
 
 The final goal would be to get rid of .pwm_period_ns in leds-pwm and pwm_bl
 after moving all the remaining users (still around 25) to pwm_lookup.
 
 Changes in v2:
  - correctly unlock the pwm_lookup_lock mutex before returning.
  - don't change PWM_LOOKUP atomically
  - remove tpu_pwm_platform_data and the associated header file
  - make the leds-pwm and pwm_bl drivers get the period from the PWM
 
 Alexandre Belloni (11):
   pwm: add period and polarity to struct pwm_lookup
   ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup
 members
   pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data

The above two patches:
Acked-by: Simon Horman horms+rene...@verge.net.au

   ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
   ARM: pxa: hx4700: initialize all the struct pwm_lookup members
   pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members
   ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
   ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct
 pwm_lookup

The above patch:
Acked-by: Simon Horman horms+rene...@verge.net.au

   ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup
   leds: leds-pwm: retrieve configured pwm period
   backlight: pwm_bl: retrieve configured pwm period
 
  Documentation/pwm.txt  |  3 ++-
  arch/arm/mach-omap2/board-omap3beagle.c|  3 ++-
  arch/arm/mach-pxa/hx4700.c |  3 ++-
  arch/arm/mach-shmobile/board-armadillo800eva.c | 14 +++---
  drivers/leds/leds-pwm.c|  5 -
  drivers/pwm/core.c |  8 +++-
  drivers/pwm/pwm-renesas-tpu.c  | 19 +++
  drivers/video/backlight/pwm_bl.c   |  8 +---
  include/linux/platform_data/pwm-renesas-tpu.h  | 16 
  include/linux/pwm.h|  6 +-
  10 files changed, 33 insertions(+), 52 deletions(-)
  delete mode 100644 include/linux/platform_data/pwm-renesas-tpu.h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP

2014-04-30 Thread Simon Horman 
On Tue, Apr 29, 2014 at 10:17:01AM -0600, Stephen Warren wrote:
 On 04/28/2014 06:02 PM, Simon Horman wrote:
  On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote:
  Since we now automatically enable early BRESP in core L2C-310 code when
  we detect a Cortex-A9, we don't need platforms/SoCs to set this bit
  explicitly.  Instead, they should seek to preserve the value of bit 30
  in the auxiliary control register.
 
  Acked-by: Tony Lindgren t...@atomide.com
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
  
  I would prefer if this patch was broken out into individual patches
  for each board or SoC file and that they were then picked up
  by their respective platform maintainers.
  
  Likewise for patch 66/97. Although it is only for shmobile
  I would prefer it broken out.
 
 There are far too many dependencies in this series to break out the
 board file patches to be merged separately; it'd take either a whole
 bunch of kernel releases to merge it all that way, or a twisty maze of
 tiny topic branches cross-merged all over the place. Neither option is
 realistic.

Understood, that seems reasonable to me.

For the shmobile portions this patch and 66/97.

Acked-by: Simon Horman horms+rene...@verge.net.au

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP

2014-04-28 Thread Simon Horman 
On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote:
 Since we now automatically enable early BRESP in core L2C-310 code when
 we detect a Cortex-A9, we don't need platforms/SoCs to set this bit
 explicitly.  Instead, they should seek to preserve the value of bit 30
 in the auxiliary control register.
 
 Acked-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

I would prefer if this patch was broken out into individual patches
for each board or SoC file and that they were then picked up
by their respective platform maintainers.

Likewise for patch 66/97. Although it is only for shmobile
I would prefer it broken out.

 ---
  arch/arm/mach-berlin/berlin.c| 2 +-
  arch/arm/mach-exynos/exynos.c| 4 ++--
  arch/arm/mach-omap2/omap4-common.c   | 3 +--
  arch/arm/mach-shmobile/board-armadillo800eva-reference.c | 4 ++--
  arch/arm/mach-shmobile/board-armadillo800eva.c   | 4 ++--
  arch/arm/mach-shmobile/board-kzm9g-reference.c   | 4 ++--
  arch/arm/mach-shmobile/board-kzm9g.c | 4 ++--
  arch/arm/mach-shmobile/setup-r8a7778.c   | 4 ++--
  arch/arm/mach-shmobile/setup-r8a7779.c   | 4 ++--
  arch/arm/mach-spear/spear13xx.c  | 2 +-
  arch/arm/mach-tegra/tegra.c  | 4 ++--
  11 files changed, 19 insertions(+), 20 deletions(-)
 
 diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
 index 025bcb5473eb..6709d2a6bec8 100644
 --- a/arch/arm/mach-berlin/berlin.c
 +++ b/arch/arm/mach-berlin/berlin.c
 @@ -24,7 +24,7 @@ static void __init berlin_init_machine(void)
* with DT probing for L2CCs, berlin_init_machine can be removed.
* Note: 88DE3005 (Armada 1500-mini) uses pl310 l2cc
*/
 - l2x0_of_init(0x70c0, 0xfeff);
 + l2x0_of_init(0x30c0, 0xfeff);
   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
  }
  
 diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
 index b32a907d021d..e6828fb46034 100644
 --- a/arch/arm/mach-exynos/exynos.c
 +++ b/arch/arm/mach-exynos/exynos.c
 @@ -32,8 +32,8 @@
  #include mfc.h
  #include regs-pmu.h
  
 -#define L2_AUX_VAL 0x7C470001
 -#define L2_AUX_MASK 0xC200
 +#define L2_AUX_VAL 0x3c470001
 +#define L2_AUX_MASK 0xc200
  
  static struct map_desc exynos4_iodesc[] __initdata = {
   {
 diff --git a/arch/arm/mach-omap2/omap4-common.c 
 b/arch/arm/mach-omap2/omap4-common.c
 index dc9844a55443..9ce52548a484 100644
 --- a/arch/arm/mach-omap2/omap4-common.c
 +++ b/arch/arm/mach-omap2/omap4-common.c
 @@ -220,8 +220,7 @@ static int __init omap_l2_cache_init(void)
  L2C_AUX_CTRL_WAY_SIZE(3) |
  L2C_AUX_CTRL_SHARED_OVERRIDE |
  L310_AUX_CTRL_DATA_PREFETCH |
 -L310_AUX_CTRL_INSTR_PREFETCH |
 -L310_AUX_CTRL_EARLY_BRESP;
 +L310_AUX_CTRL_INSTR_PREFETCH;
  
   outer_cache.write_sec = omap4_l2c310_write_sec;
   if (of_have_populated_dt())
 diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c 
 b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
 index 57d1a78367b6..34e7f3c17dd2 100644
 --- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
 +++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
 @@ -164,8 +164,8 @@ static void __init eva_init(void)
   r8a7740_meram_workaround();
  
  #ifdef CONFIG_CACHE_L2X0
 - /* Early BRESP enable, Shared attribute override enable, 32K*8way */
 - l2x0_init(IOMEM(0xf0002000), 0x4044, 0x82000fff);
 + /* Shared attribute override enable, 32K*8way */
 + l2x0_init(IOMEM(0xf0002000), 0x0044, 0xc2000fff);
  #endif
  
   r8a7740_add_standard_devices_dt();
 diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c 
 b/arch/arm/mach-shmobile/board-armadillo800eva.c
 index 2858f380beae..7688990edd3a 100644
 --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
 +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
 @@ -1270,8 +1270,8 @@ static void __init eva_init(void)
  
  
  #ifdef CONFIG_CACHE_L2X0
 - /* Early BRESP enable, Shared attribute override enable, 32K*8way */
 - l2x0_init(IOMEM(0xf0002000), 0x4044, 0x82000fff);
 + /* Shared attribute override enable, 32K*8way */
 + l2x0_init(IOMEM(0xf0002000), 0x0044, 0xc2000fff);
  #endif
  
   i2c_register_board_info(0, i2c0_devices, ARRAY_SIZE(i2c0_devices));
 diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c 
 b/arch/arm/mach-shmobile/board-kzm9g-reference.c
 index 598e32488410..85873f186d77 100644
 --- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
 +++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
 @@ -36,8 +36,8 @@ static void __init kzm_init(void)
   sh73a0_add_standard_devices_dt();
  
  #ifdef CONFIG_CACHE_L2X0
 - /* Early BRESP enable, Shared

Re: [PATCHv2 07/11] ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup

2014-04-15 Thread Simon Horman 
On Tue, Apr 15, 2014 at 10:01:44AM +0300, Peter Ujfalusi wrote:
 On 04/15/2014 12:59 AM, Alexandre Belloni wrote:
  Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
  ---
   arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
   1 file changed, 2 insertions(+), 8 deletions(-)
  
  diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
  b/arch/arm/mach-omap2/board-omap3beagle.c
  index f27e1ec90b5e..54c135a5b4f7 100644
  --- a/arch/arm/mach-omap2/board-omap3beagle.c
  +++ b/arch/arm/mach-omap2/board-omap3beagle.c
  @@ -61,14 +61,8 @@
   
   static struct pwm_lookup pwm_lookup[] = {
  /* LEDB - PMU_STAT */
  -   {
  -   .provider = twl-pwmled,
  -   .index = 1,
  -   .dev_id = leds_pwm,
  -   .con_id = beagleboard::pmu_stat,
  -   .period = 7812500,
  -   .polarity = PWM_POLARITY_NORMAL,
  -   },
  +   PWM_LOOKUP(twl-pwmled, 1, leds_pwm, beagleboard::pmu_stat,
  +  7812500, PWM_POLARITY_NORMAL),
 
 Why do you need to do this in two steps?
 In patch 4 you removed the existing PWM_LOOKUP() and now you are adding it 
 back.
 Would not be simpler if you just add the two new parameters in patch 4 (the
 812500, PWM_POLARITY_NORMAL)?

Such an approach would apply an atomic change to both the infrastructure
and the users.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 02/11] ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup members

2014-04-14 Thread Simon Horman 
On Mon, Apr 14, 2014 at 11:59:44PM +0200, Alexandre Belloni wrote:
 Initializing all the struct pwm_lookup members allows to get rid of the struct
 tpu_pwm_platform_data as the polarity initialization will be taken care of by
 the PWM core.
 
 Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com


This looks good to me.
Please let me know when the driver code has been merged and
I'll take this patch. Likewise for the other shmobile patch in this series.

 ---
  arch/arm/mach-shmobile/board-armadillo800eva.c | 20 +---
  1 file changed, 9 insertions(+), 11 deletions(-)
 
 diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c 
 b/arch/arm/mach-shmobile/board-armadillo800eva.c
 index 2858f380beae..1bf61dad9a35 100644
 --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
 +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
 @@ -31,7 +31,7 @@
  #include linux/gpio_keys.h
  #include linux/regulator/driver.h
  #include linux/pinctrl/machine.h
 -#include linux/platform_data/pwm-renesas-tpu.h
 +#include linux/pwm.h
  #include linux/pwm_backlight.h
  #include linux/regulator/fixed.h
  #include linux/regulator/gpio-regulator.h
 @@ -399,24 +399,22 @@ static struct resource pwm_resources[] = {
   },
  };
  
 -static struct tpu_pwm_platform_data pwm_device_data = {
 - .channels[2] = {
 - .polarity = PWM_POLARITY_INVERSED,
 - }
 -};
 -
  static struct platform_device pwm_device = {
   .name = renesas-tpu-pwm,
   .id = -1,
 - .dev = {
 - .platform_data = pwm_device_data,
 - },
   .num_resources = ARRAY_SIZE(pwm_resources),
   .resource = pwm_resources,
  };
  
  static struct pwm_lookup pwm_lookup[] = {
 - PWM_LOOKUP(renesas-tpu-pwm, 2, pwm-backlight.0, NULL),
 + {
 + .provider = renesas-tpu-pwm,
 + .index = 2,
 + .dev_id = pwm-backlight.0,
 + .con_id = NULL,
 + .period = 3,
 + .polarity = PWM_POLARITY_INVERSED,
 + },
  };
  
  /* LCDC and backlight */
 -- 
 1.8.3.2
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] pwm: use PWM_LOOKUP to set the period and polarity

2014-04-13 Thread Simon Horman 
On Thu, Apr 10, 2014 at 09:37:03AM +0200, Alexandre Belloni wrote:
 On 10/04/2014 at 08:15:49 +0900, Simon Horman wrote :
  On Wed, Apr 09, 2014 at 08:04:09PM +0200, Alexandre Belloni wrote:
   Now that the PWM core is able to set the period and polarity based on
   the lookup table, add those to PWM_LOOKUP to ease their usage.
  
  I would prefer if this change was made in a non-atomic manner.
  
  1. Add new infrastructure
  2. Update users individually
  3. Remove old infrastructure
  
 
 I agree this would be better but I'm not sure how you can modify a macro
 without renaming it or changing it everywhere at once. Like said, I'm
 open to creating a new macro.

I for one would prefer the new macro approach.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] pwm: use PWM_LOOKUP to set the period and polarity

2014-04-09 Thread Simon Horman 
On Wed, Apr 09, 2014 at 08:04:09PM +0200, Alexandre Belloni wrote:
 Now that the PWM core is able to set the period and polarity based on
 the lookup table, add those to PWM_LOOKUP to ease their usage.

I would prefer if this change was made in a non-atomic manner.

1. Add new infrastructure
2. Update users individually
3. Remove old infrastructure

 
 Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
 ---
  Documentation/pwm.txt  | 3 ++-
  arch/arm/mach-omap2/board-omap3beagle.c| 3 ++-
  arch/arm/mach-pxa/hx4700.c | 3 ++-
  arch/arm/mach-shmobile/board-armadillo800eva.c | 3 ++-
  include/linux/pwm.h| 4 +++-
  5 files changed, 11 insertions(+), 5 deletions(-)
 
 diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
 index 93cb97974986..f38f99cda64f 100644
 --- a/Documentation/pwm.txt
 +++ b/Documentation/pwm.txt
 @@ -19,7 +19,8 @@ should instead register a static mapping that can be used 
 to match PWM
  consumers to providers, as given in the following example:
  
   static struct pwm_lookup board_pwm_lookup[] = {
 - PWM_LOOKUP(tegra-pwm, 0, pwm-backlight, NULL),
 + PWM_LOOKUP(tegra-pwm, 0, pwm-backlight, NULL,
 +5, PWM_POLARITY_NORMAL),
   };
  
   static void __init board_init(void)
 diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
 b/arch/arm/mach-omap2/board-omap3beagle.c
 index d6ed819ff15c..54c135a5b4f7 100644
 --- a/arch/arm/mach-omap2/board-omap3beagle.c
 +++ b/arch/arm/mach-omap2/board-omap3beagle.c
 @@ -61,7 +61,8 @@
  
  static struct pwm_lookup pwm_lookup[] = {
   /* LEDB - PMU_STAT */
 - PWM_LOOKUP(twl-pwmled, 1, leds_pwm, beagleboard::pmu_stat),
 + PWM_LOOKUP(twl-pwmled, 1, leds_pwm, beagleboard::pmu_stat,
 +7812500, PWM_POLARITY_NORMAL),
  };
  
  static struct led_pwm pwm_leds[] = {
 diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
 index a7c30eb0c8db..c66ad4edc5e3 100644
 --- a/arch/arm/mach-pxa/hx4700.c
 +++ b/arch/arm/mach-pxa/hx4700.c
 @@ -574,7 +574,8 @@ static struct platform_device backlight = {
  };
  
  static struct pwm_lookup hx4700_pwm_lookup[] = {
 - PWM_LOOKUP(pxa27x-pwm.1, 0, pwm-backlight, NULL),
 + PWM_LOOKUP(pxa27x-pwm.1, 0, pwm-backlight, NULL,
 +30923, PWM_POLARITY_NORMAL),
  };
  
  /*
 diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c 
 b/arch/arm/mach-shmobile/board-armadillo800eva.c
 index 2858f380beae..e2c4c5010f19 100644
 --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
 +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
 @@ -416,7 +416,8 @@ static struct platform_device pwm_device = {
  };
  
  static struct pwm_lookup pwm_lookup[] = {
 - PWM_LOOKUP(renesas-tpu-pwm, 2, pwm-backlight.0, NULL),
 + PWM_LOOKUP(renesas-tpu-pwm, 2, pwm-backlight.0, NULL,
 +3, PWM_POLARITY_NORMAL),
  };
  
  /* LCDC and backlight */
 diff --git a/include/linux/pwm.h b/include/linux/pwm.h
 index 2f45e2fe5b93..e90628cac8fa 100644
 --- a/include/linux/pwm.h
 +++ b/include/linux/pwm.h
 @@ -278,12 +278,14 @@ struct pwm_lookup {
   enum pwm_polarity polarity;
  };
  
 -#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id)  \
 +#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id, _period, _polarity) \
   {   \
   .provider = _provider,  \
   .index = _index,\
   .dev_id = _dev_id,  \
   .con_id = _con_id,  \
 + .period = _period,  \
 + .polarity = _polarity   \
   }
  
  #if IS_ENABLED(CONFIG_PWM)
 -- 
 1.8.3.2
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] pwm-backlight: Add GPIO and power supply support

2013-09-24 Thread Simon Horman 
[ Cc: Olof Johansson, Kevin Hilman and Arnd Bergman: arm-soc maintainers ]

On Mon, Sep 23, 2013 at 11:40:57PM +0200, Thierry Reding wrote:
 This series adds the ability to specify a GPIO and a power supply to
 enable a backlight.
 
 Patch 1 refactors the power on and power off sequences into separate
 functions in preparation for subsequent patches.
 
 Patch 2 adds an optional GPIO to enable a backlight. This patch only
 includes the field within the platform data so that it can be properly
 setup before actually being put to use.
 
 Patches 3 to 7 convert all users of the pwm-backlight driver to use the
 new field. For most of them, this just initializes the field to -1,
 marking the field as unused.

 Patch 8 uses the new field within the pwm-backlight driver and at the
 same time allows it to be parsed from device tree.
 
 Patch 9 implements support for an optional power supply. This relies on
 the regulator core to return a dummy regulator when no supply has been
 otherwise setup so the driver doesn't have to handle that specially nor
 require all users to be updated.
 
 Patch 10 adds a way to keep a backlight turned off at boot. This is
 useful when hooking up a backlight with a subsystem such as DRM which
 has more explicit semantics as to when a backlight should be turned on.
 
 Due to the dependencies within the series, I propose to take all these
 patches through the PWM tree, so I'll need acks from OMAP, PXA, Samsung,
 shmobile and Unicore32 maintainers.

I received some feedback regarding shmobile conflicts when
arm-soc was merged between v3.11 and v3.12-rc1. With this
in mind I now have a strong preference for changes inside
arch/arm/mach-shmobile/ to be taken through my renesas
tree and thus more importantly through arm-soc if possible.

 Thierry
 
 Thierry Reding (10):
   pwm-backlight: Refactor backlight power on/off
   pwm-backlight: Add optional enable GPIO
   ARM: OMAP: Initialize PWM backlight enable_gpio field
   ARM: pxa: Initialize PWM backlight enable_gpio field
   ARM: SAMSUNG: Initialize PWM backlight enable_gpio field
   ARM: shmobile: Initialize PWM backlight enable_gpio field
   unicore32: Initialize PWM backlight enable_gpio field
   pwm-backlight: Use new enable_gpio field
   pwm-backlight: Use an optional power supply
   pwm-backlight: Allow backlight to remain disabled on boot
 
  .../bindings/video/backlight/pwm-backlight.txt |   6 +
  arch/arm/mach-omap2/board-zoom-peripherals.c   |   1 +
  arch/arm/mach-pxa/cm-x300.c|   1 +
  arch/arm/mach-pxa/colibri-pxa270-income.c  |   1 +
  arch/arm/mach-pxa/ezx.c|   1 +
  arch/arm/mach-pxa/hx4700.c |   1 +
  arch/arm/mach-pxa/lpd270.c |   1 +
  arch/arm/mach-pxa/magician.c   |   1 +
  arch/arm/mach-pxa/mainstone.c  |   1 +
  arch/arm/mach-pxa/mioa701.c|   1 +
  arch/arm/mach-pxa/palm27x.c|   1 +
  arch/arm/mach-pxa/palmtc.c |  35 +
  arch/arm/mach-pxa/palmte2.c|   1 +
  arch/arm/mach-pxa/pcm990-baseboard.c   |   1 +
  arch/arm/mach-pxa/raumfeld.c   |   1 +
  arch/arm/mach-pxa/tavorevb.c   |   2 +
  arch/arm/mach-pxa/viper.c  |   1 +
  arch/arm/mach-pxa/z2.c |   2 +
  arch/arm/mach-pxa/zylonite.c   |   1 +
  arch/arm/mach-s3c24xx/mach-h1940.c |   1 +
  arch/arm/mach-s3c24xx/mach-rx1950.c|   1 +
  arch/arm/mach-s3c64xx/mach-crag6410.c  |   1 +
  arch/arm/mach-s3c64xx/mach-hmt.c   |   1 +
  arch/arm/mach-s3c64xx/mach-smartq.c|   1 +
  arch/arm/mach-s3c64xx/mach-smdk6410.c  |   1 +
  arch/arm/mach-s5p64x0/mach-smdk6440.c  |   1 +
  arch/arm/mach-s5p64x0/mach-smdk6450.c  |   1 +
  arch/arm/mach-s5pc100/mach-smdkc100.c  |   1 +
  arch/arm/mach-s5pv210/mach-smdkv210.c  |   1 +
  arch/arm/mach-shmobile/board-armadillo800eva.c |   1 +
  arch/arm/plat-samsung/dev-backlight.c  |   5 +
  arch/unicore32/kernel/puv3-nb0916.c|   1 +
  drivers/video/backlight/pwm_bl.c   | 142 
 -
  include/linux/pwm_backlight.h  |   7 +
  34 files changed, 162 insertions(+), 64 deletions(-)
 
 -- 
 1.8.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] pwm-backlight: Add GPIO and power supply support

2013-09-24 Thread Simon Horman 
On Tue, Sep 24, 2013 at 11:00:24AM +0200, Thierry Reding wrote:
 On Tue, Sep 24, 2013 at 05:14:46PM +0900, Simon Horman wrote:
  [ Cc: Olof Johansson, Kevin Hilman and Arnd Bergman: arm-soc maintainers ]
  
  On Mon, Sep 23, 2013 at 11:40:57PM +0200, Thierry Reding wrote:
   This series adds the ability to specify a GPIO and a power supply to
   enable a backlight.
   
   Patch 1 refactors the power on and power off sequences into separate
   functions in preparation for subsequent patches.
   
   Patch 2 adds an optional GPIO to enable a backlight. This patch only
   includes the field within the platform data so that it can be properly
   setup before actually being put to use.
   
   Patches 3 to 7 convert all users of the pwm-backlight driver to use the
   new field. For most of them, this just initializes the field to -1,
   marking the field as unused.
  
   Patch 8 uses the new field within the pwm-backlight driver and at the
   same time allows it to be parsed from device tree.
   
   Patch 9 implements support for an optional power supply. This relies on
   the regulator core to return a dummy regulator when no supply has been
   otherwise setup so the driver doesn't have to handle that specially nor
   require all users to be updated.
   
   Patch 10 adds a way to keep a backlight turned off at boot. This is
   useful when hooking up a backlight with a subsystem such as DRM which
   has more explicit semantics as to when a backlight should be turned on.
   
   Due to the dependencies within the series, I propose to take all these
   patches through the PWM tree, so I'll need acks from OMAP, PXA, Samsung,
   shmobile and Unicore32 maintainers.
  
  I received some feedback regarding shmobile conflicts when
  arm-soc was merged between v3.11 and v3.12-rc1. With this
  in mind I now have a strong preference for changes inside
  arch/arm/mach-shmobile/ to be taken through my renesas
  tree and thus more importantly through arm-soc if possible.
 
 I understand. Unfortunately the nature of patche series such as this is
 that they require the whole series to be applied atomically (or at least
 in a very specific order). So the patch that uses the new enable_gpio
 field can only be applied after all previous patches. The only
 reasonable way to ensure that is to take all of the patches through one
 tree. Furthermore this patch is tiny (it adds a single line) and touches
 code that's unlikely to be modified by anyone else.
 
 But if it makes you more comfortable, I could provide a stable branch
 that contains this series for you to merge into the shmobile tree. That
 should enable you to handle all conflict resolution prior to submitting
 to arm-soc.

After some further thought I have reasoned that:

1. It is only a one line change on the shmobile side
2. It is to a file that is not seeing much chainge and in
   a block of code that is seeing even less change.

And thus the chance of a conflict is small.

With this in mind I will ack the shmobile patch.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/10] ARM: shmobile: Initialize PWM backlight enable_gpio field

2013-09-24 Thread Simon Horman 
On Mon, Sep 23, 2013 at 11:41:03PM +0200, Thierry Reding wrote:
 The GPIO API defines 0 as being a valid GPIO number, so this field needs
 to be initialized explicitly.
 
 Signed-off-by: Thierry Reding tred...@nvidia.com
 ---
  arch/arm/mach-shmobile/board-armadillo800eva.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c 
 b/arch/arm/mach-shmobile/board-armadillo800eva.c
 index 7f8f607..6ccb854 100644
 --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
 +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
 @@ -423,6 +423,7 @@ static struct platform_pwm_backlight_data 
 pwm_backlight_data = {
   .max_brightness = 255,
   .dft_brightness = 255,
   .pwm_period_ns = 3, /* 30kHz */
 + .enable_gpio = -1,
  };
  
  static struct platform_device pwm_backlight_device = {

Acked-by: Simon Horman horms+rene...@verge.net.au

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init

2013-04-10 Thread Simon Horman 
[ CC Magnus Damm ]

On Wed, Apr 10, 2013 at 06:17:31PM -0500, Rob Herring wrote:
 On 04/04/2013 12:56 AM, Simon Horman wrote:
  On Mon, Apr 01, 2013 at 05:21:12PM -0500, Rob Herring wrote:
  From: Rob Herring rob.herr...@calxeda.com
 
  This converts arm and arm64 to use CLKSRC_OF DT based initialization for
  the arch timer. A new function arch_timer_arch_init is added to allow for
  arch specific setup.
 
  This has a side effect of enabling sched_clock on omap5 and exynos5. There
  should not be any reason not to use the arch timers for sched_clock.
  
  Would it be possible for you to either delay the removal of
  shmobile_timer_init. In general I am in favour of the following
  approach to wide changes such as this one:
 
 I will simply change shmobile_timer_init to call clocksource_of_init
 rather than deleting it. That should keep the new users working and then
 it can be deleted latter.

Thanks.

  1. Add new feature
  2. Convert users to new feature
  3. Remove old feature.
  
  If it is not possible to delay the removal of shmobile_timer_init could you
  update your base such that you also remove its usage from the following
  files:
  
  arch/arm/mach-shmobile/board-kzm9g-reference.c
  arch/arm/mach-shmobile/setup-r8a73a4.c
  arch/arm/mach-shmobile/setup-r8a7779.c
  arch/arm/mach-shmobile/board-lager.c
  arch/arm/mach-shmobile/board-ape6evm.c
  arch/arm/mach-shmobile/setup-r8a7778.c
  arch/arm/mach-shmobile/board-marzen-reference.c
  arch/arm/mach-shmobile/setup-r8a7790.c
  arch/arm/mach-shmobile/board-bockw.c
 
 Why so many boards? There's been prior discussions about whether to add
 DT into existing board files or start with a minimal DT board file and
 add to it. The fact that there are 14 mach desc's using
 shmobile_timer_init which is a function only used for DT and 17 DT mach
 descs total for shmobile tells me perhaps the latter approach is needed.
 
 Either way, it is good to see progress on DT support in shmobile.

I've CCed Magnus who can answer that question better than I.
But in general I believe the answer is that because DT support for
many of the drivers that the boards and SoCs rely on isn't quite (or
in some cases at all) ready yet we need to bring things up using C code.

I realise that there are other approaches to this problem, but
this is the one we're taking at this time.

 
 Rob
 
  The above files are all present in the arm-soc/next/boards2 branch
  of the arm-soc tree which has pulled the renesas-boards3-for-v3.10 tag
  of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git.
  I am happy for you use the later as a base if you wish.
  
  Signed-off-by: Rob Herring rob.herr...@calxeda.com
  Cc: Russell King li...@arm.linux.org.uk
  Cc: Kukjin Kim kgene@samsung.com
  Cc: Tony Lindgren t...@atomide.com
  Cc: Simon Horman ho...@verge.net.au
  Cc: Magnus Damm magnus.d...@gmail.com
  Cc: Catalin Marinas catalin.mari...@arm.com
  Cc: Will Deacon will.dea...@arm.com
  Cc: John Stultz john.stu...@linaro.org
  Cc: Thomas Gleixner t...@linutronix.de
  Cc: linux-samsung-...@vger.kernel.org
  Cc: linux-omap@vger.kernel.org
  Cc: linux...@vger.kernel.org
  ---
   arch/arm/include/asm/arch_timer.h|   13 +
   arch/arm/kernel/arch_timer.c |   17 +++--
   arch/arm/mach-exynos/mach-exynos5-dt.c   |1 -
   arch/arm/mach-exynos/mct.c   |6 --
   arch/arm/mach-highbank/highbank.c|5 +
   arch/arm/mach-omap2/timer.c  |5 +
   arch/arm/mach-shmobile/board-kzm9d.c |1 -
  
  I have boot tested the board-kzm9d change on the kzm9d board, it seems fine.
  
   arch/arm/mach-shmobile/include/mach/common.h |1 -
   arch/arm/mach-shmobile/setup-emev2.c |1 -
  
  I am not able to test the setup-emev2 portion properly at this time,
  booting the kzm9d board without the board-kzm9d file seems broken without
  your patch. However, your change seems reasonable to me.
  
   arch/arm/mach-shmobile/setup-r8a7740.c   |1 -
  
  I am not able to test the setup-r8a7740 portion properly at this time,
  booting the armadillo800eva board without the board-armadillo800eva file
  seems broken without your patch. However, your change seems reasonable to
  me.
  
   arch/arm/mach-shmobile/setup-sh7372.c|1 -
  
  I am not able to test the setup-sh7372 portion properly at this time,
  booting the mackerel board without the board-mackerel file seems broken 
  without
  your patch. However, your change seems reasonable to me.
  
   arch/arm/mach-shmobile/setup-sh73a0.c|1 -
  
  I have boot tested the setup-sh73a0 change on the kzm9g board, it seems 
  fine.
  
  
  The tests above were made by merging
  
  git://sources.calxeda.com/kernel/linux.git arm-timers
  head commit: df3f518db302caf9fc0511917c5e9021037f6fcd
   (devtree: add binding documentation for sp804)
  
  and the renesas-next-20130403 tag of the renesas tree

Re: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init

2013-04-03 Thread Simon Horman 
On Mon, Apr 01, 2013 at 05:21:12PM -0500, Rob Herring wrote:
 From: Rob Herring rob.herr...@calxeda.com
 
 This converts arm and arm64 to use CLKSRC_OF DT based initialization for
 the arch timer. A new function arch_timer_arch_init is added to allow for
 arch specific setup.
 
 This has a side effect of enabling sched_clock on omap5 and exynos5. There
 should not be any reason not to use the arch timers for sched_clock.

Would it be possible for you to either delay the removal of
shmobile_timer_init. In general I am in favour of the following
approach to wide changes such as this one:

1. Add new feature
2. Convert users to new feature
3. Remove old feature.

If it is not possible to delay the removal of shmobile_timer_init could you
update your base such that you also remove its usage from the following
files:

arch/arm/mach-shmobile/board-kzm9g-reference.c
arch/arm/mach-shmobile/setup-r8a73a4.c
arch/arm/mach-shmobile/setup-r8a7779.c
arch/arm/mach-shmobile/board-lager.c
arch/arm/mach-shmobile/board-ape6evm.c
arch/arm/mach-shmobile/setup-r8a7778.c
arch/arm/mach-shmobile/board-marzen-reference.c
arch/arm/mach-shmobile/setup-r8a7790.c
arch/arm/mach-shmobile/board-bockw.c

The above files are all present in the arm-soc/next/boards2 branch
of the arm-soc tree which has pulled the renesas-boards3-for-v3.10 tag
of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git.
I am happy for you use the later as a base if you wish.

 Signed-off-by: Rob Herring rob.herr...@calxeda.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Kukjin Kim kgene@samsung.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Simon Horman ho...@verge.net.au
 Cc: Magnus Damm magnus.d...@gmail.com
 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: John Stultz john.stu...@linaro.org
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: linux-samsung-...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org
 Cc: linux...@vger.kernel.org
 ---
  arch/arm/include/asm/arch_timer.h|   13 +
  arch/arm/kernel/arch_timer.c |   17 +++--
  arch/arm/mach-exynos/mach-exynos5-dt.c   |1 -
  arch/arm/mach-exynos/mct.c   |6 --
  arch/arm/mach-highbank/highbank.c|5 +
  arch/arm/mach-omap2/timer.c  |5 +
  arch/arm/mach-shmobile/board-kzm9d.c |1 -

I have boot tested the board-kzm9d change on the kzm9d board, it seems fine.

  arch/arm/mach-shmobile/include/mach/common.h |1 -
  arch/arm/mach-shmobile/setup-emev2.c |1 -

I am not able to test the setup-emev2 portion properly at this time,
booting the kzm9d board without the board-kzm9d file seems broken without
your patch. However, your change seems reasonable to me.

  arch/arm/mach-shmobile/setup-r8a7740.c   |1 -

I am not able to test the setup-r8a7740 portion properly at this time,
booting the armadillo800eva board without the board-armadillo800eva file
seems broken without your patch. However, your change seems reasonable to
me.

  arch/arm/mach-shmobile/setup-sh7372.c|1 -

I am not able to test the setup-sh7372 portion properly at this time,
booting the mackerel board without the board-mackerel file seems broken without
your patch. However, your change seems reasonable to me.

  arch/arm/mach-shmobile/setup-sh73a0.c|1 -

I have boot tested the setup-sh73a0 change on the kzm9g board, it seems fine.


The tests above were made by merging

git://sources.calxeda.com/kernel/linux.git arm-timers
head commit: df3f518db302caf9fc0511917c5e9021037f6fcd
 (devtree: add binding documentation for sp804)

and the renesas-next-20130403 tag of the renesas tree (URL above).

  arch/arm/mach-shmobile/timer.c   |6 --
  arch/arm/mach-vexpress/v2m.c |7 ++-
  arch/arm/mach-virt/virt.c|9 -
  arch/arm64/include/asm/arch_timer.h  |5 +
  arch/arm64/kernel/time.c |6 --
  drivers/clocksource/Kconfig  |1 +
  drivers/clocksource/arm_arch_timer.c |   23 +--
  include/clocksource/arm_arch_timer.h |6 --
  20 files changed, 27 insertions(+), 89 deletions(-)
 
 diff --git a/arch/arm/include/asm/arch_timer.h 
 b/arch/arm/include/asm/arch_timer.h
 index 7ade91d..7c1bfc0 100644
 --- a/arch/arm/include/asm/arch_timer.h
 +++ b/arch/arm/include/asm/arch_timer.h
 @@ -10,8 +10,7 @@
  #include clocksource/arm_arch_timer.h
  
  #ifdef CONFIG_ARM_ARCH_TIMER
 -int arch_timer_of_register(void);
 -int arch_timer_sched_clock_init(void);
 +int arch_timer_arch_init(void);
  
  /*
   * These register accessors are marked inline so the compiler can
 @@ -110,16 +109,6 @@ static inline void __cpuinit 
 arch_counter_set_user_access(void)
  
   asm volatile(mcr p15, 0, %0, c14, c1, 0 : : r (cntkctl));
  }
 -#else
 -static inline int arch_timer_of_register

Re: [RFC PATCH 3/6] usb: otg: utils: change the phy lib to support multiple PHYs of same type

2013-01-16 Thread Simon Horman 
On Wed, Jan 16, 2013 at 08:30:59PM +0530, Kishon Vijay Abraham I wrote:
 In order to add support for multipe PHY's of the same type, the API's
 for adding PHY and getting PHY has been changed. Now the binding
 information of the PHY and controller should be done in platform file
 using usb_bind_phy API. And for getting a PHY, the device pointer of the
 USB controller and an index should be passed. Based on the binding
 information that is added in the platform file, get_phy will return the
 approappropriate PHY.
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  arch/arm/mach-shmobile/board-marzen.c |2 +-

Modification to the above file:

Acked-by: Simon Horman horms+rene...@verge.net.au
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: sh7372: fix cache clean / invalidate order

2012-12-28 Thread Simon Horman 
On Fri, Dec 28, 2012 at 12:32:54PM +0100, Guennadi Liakhovetski wrote:
 According to the Cortex A8 TRM the L2 cache should be first cleaned and 
 then disabled. Fix the swapped order on sh7372.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com

Thanks, applied to the soc branch of the renesas tree.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] smsc95xx: Add module parameter to override MAC address

2010-06-24 Thread Simon Horman 
On Thu, Jun 24, 2010 at 10:14:14AM +0200, Sebastien Jan wrote:
 Define a new module parameter 'macaddr' to override the MAC address
 fetched either from eeprom, or randomly generated.
 
 The expected MAC address shall be in the 01:23:45:67:89:AB format.

I'm confused as to why this is desirable when the mac address
can already be configured after module insertion via
smsc95xx_netdev_ops.eth_mac_addr().

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html