From: Tony Lindgren <tony@atomide.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Kevin Hilman <khilman@ti.com>,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: [GIT PULL] omap cleanup part1 for v3.2 merge window
Date: Fri, 23 Sep 2011 15:53:09 -0700 [thread overview]
Message-ID: <20110923225309.GA6324@atomide.com> (raw)
In-Reply-To: <87d3et4zj9.fsf@ti.com>
Arnd,
* Kevin Hilman <khilman@ti.com> [110921 09:09]:
> Hi Arnd,
>
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote:
> >
> >> It seems that you replace the #ifdef in the board-flash.c file
> >> with a similar #ifdef in the header that replaces this with an
> >> empty inline function when the object is not built.
> >
> > Found another similar problem over night, presumably in the voltage series:
> >
>
> Found. Patch below.
>
> If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which
> is already pulled into arm-soc/next/voltage) so just re-pulling will
> pick up the fix.
Arnd, care to pull this in directly from Kevin into voltage branch?
It's available at:
git://gitorious.org/khilman/linux-omap-pm for_3.2/voltage-cleanup
Regards,
Tony
> From 473dc975c3ea468049732155467ff08fe3701f98 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@ti.com>
> Date: Wed, 21 Sep 2011 09:24:53 -0700
> Subject: [PATCH] ARM: OMAP: voltage layer present, even when CONFIG_PM=n
>
> Even when CONFIG_PM=n, we try to scale the boot voltage to a sane,
> known value using OPP table to find matching voltage based on boot
> frequency. This should be done, even when CONFIG_PM=n to avoid
> mis-configured bootloaders and/or boot voltage assumptions made by
> boot loaders.
>
> Also fixes various compile problems due to depenencies between voltage
> domain and powerdomain code (also present when CONFIG_PM=n).
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Compile tested with CONFIG_PM=n
> Applies to arm-soc/next/voltage
>
> arch/arm/mach-omap2/Makefile | 2 --
> arch/arm/mach-omap2/voltage.h | 14 --------------
> 2 files changed, 0 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 8bd389d..5129785 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -89,7 +89,6 @@ obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
> vp44xx_data.o
>
> # OMAP voltage domains
> -ifeq ($(CONFIG_PM),y)
> voltagedomain-common := voltage.o vc.o vp.o
> obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) \
> voltagedomains2xxx_data.o
> @@ -97,7 +96,6 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \
> voltagedomains3xxx_data.o
> obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \
> voltagedomains44xx_data.o
> -endif
>
> # OMAP powerdomain framework
> powerdomain-common += powerdomain.o powerdomain-common.o
> diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
> index 4c09809..16a1b09 100644
> --- a/arch/arm/mach-omap2/voltage.h
> +++ b/arch/arm/mach-omap2/voltage.h
> @@ -148,25 +148,11 @@ void omap_voltage_get_volttable(struct voltagedomain *voltdm,
> struct omap_volt_data **volt_data);
> struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm,
> unsigned long volt);
> -#ifdef CONFIG_PM
> int omap_voltage_register_pmic(struct voltagedomain *voltdm,
> struct omap_voltdm_pmic *pmic);
> void omap_change_voltscale_method(struct voltagedomain *voltdm,
> int voltscale_method);
> int omap_voltage_late_init(void);
> -#else
> -static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
> - struct omap_voltdm_pmic *pmic)
> -{
> - return -EINVAL;
> -}
> -static inline void omap_change_voltscale_method(struct voltagedomain *voltdm,
> - int voltscale_method) {}
> -static inline int omap_voltage_late_init(void)
> -{
> - return -EINVAL;
> -}
> -#endif
>
> extern void omap2xxx_voltagedomains_init(void);
> extern void omap3xxx_voltagedomains_init(void);
> --
> 1.7.6
>
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] omap cleanup part1 for v3.2 merge window
Date: Fri, 23 Sep 2011 15:53:09 -0700 [thread overview]
Message-ID: <20110923225309.GA6324@atomide.com> (raw)
In-Reply-To: <87d3et4zj9.fsf@ti.com>
Arnd,
* Kevin Hilman <khilman@ti.com> [110921 09:09]:
> Hi Arnd,
>
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote:
> >
> >> It seems that you replace the #ifdef in the board-flash.c file
> >> with a similar #ifdef in the header that replaces this with an
> >> empty inline function when the object is not built.
> >
> > Found another similar problem over night, presumably in the voltage series:
> >
>
> Found. Patch below.
>
> If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which
> is already pulled into arm-soc/next/voltage) so just re-pulling will
> pick up the fix.
Arnd, care to pull this in directly from Kevin into voltage branch?
It's available at:
git://gitorious.org/khilman/linux-omap-pm for_3.2/voltage-cleanup
Regards,
Tony
> From 473dc975c3ea468049732155467ff08fe3701f98 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@ti.com>
> Date: Wed, 21 Sep 2011 09:24:53 -0700
> Subject: [PATCH] ARM: OMAP: voltage layer present, even when CONFIG_PM=n
>
> Even when CONFIG_PM=n, we try to scale the boot voltage to a sane,
> known value using OPP table to find matching voltage based on boot
> frequency. This should be done, even when CONFIG_PM=n to avoid
> mis-configured bootloaders and/or boot voltage assumptions made by
> boot loaders.
>
> Also fixes various compile problems due to depenencies between voltage
> domain and powerdomain code (also present when CONFIG_PM=n).
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Compile tested with CONFIG_PM=n
> Applies to arm-soc/next/voltage
>
> arch/arm/mach-omap2/Makefile | 2 --
> arch/arm/mach-omap2/voltage.h | 14 --------------
> 2 files changed, 0 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 8bd389d..5129785 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -89,7 +89,6 @@ obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
> vp44xx_data.o
>
> # OMAP voltage domains
> -ifeq ($(CONFIG_PM),y)
> voltagedomain-common := voltage.o vc.o vp.o
> obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) \
> voltagedomains2xxx_data.o
> @@ -97,7 +96,6 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \
> voltagedomains3xxx_data.o
> obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \
> voltagedomains44xx_data.o
> -endif
>
> # OMAP powerdomain framework
> powerdomain-common += powerdomain.o powerdomain-common.o
> diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
> index 4c09809..16a1b09 100644
> --- a/arch/arm/mach-omap2/voltage.h
> +++ b/arch/arm/mach-omap2/voltage.h
> @@ -148,25 +148,11 @@ void omap_voltage_get_volttable(struct voltagedomain *voltdm,
> struct omap_volt_data **volt_data);
> struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm,
> unsigned long volt);
> -#ifdef CONFIG_PM
> int omap_voltage_register_pmic(struct voltagedomain *voltdm,
> struct omap_voltdm_pmic *pmic);
> void omap_change_voltscale_method(struct voltagedomain *voltdm,
> int voltscale_method);
> int omap_voltage_late_init(void);
> -#else
> -static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
> - struct omap_voltdm_pmic *pmic)
> -{
> - return -EINVAL;
> -}
> -static inline void omap_change_voltscale_method(struct voltagedomain *voltdm,
> - int voltscale_method) {}
> -static inline int omap_voltage_late_init(void)
> -{
> - return -EINVAL;
> -}
> -#endif
>
> extern void omap2xxx_voltagedomains_init(void);
> extern void omap3xxx_voltagedomains_init(void);
> --
> 1.7.6
>
next prev parent reply other threads:[~2011-09-23 22:53 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-17 1:46 [GIT PULL] omap cleanup part1 for v3.2 merge window Tony Lindgren
2011-09-17 1:46 ` Tony Lindgren
2011-09-20 20:01 ` Arnd Bergmann
2011-09-20 20:01 ` Arnd Bergmann
2011-09-20 20:55 ` Tony Lindgren
2011-09-20 20:55 ` Tony Lindgren
2011-09-20 21:34 ` Arnd Bergmann
2011-09-20 21:34 ` Arnd Bergmann
2011-09-20 21:46 ` Arnd Bergmann
2011-09-20 21:46 ` Arnd Bergmann
2011-09-20 22:33 ` Tony Lindgren
2011-09-20 22:33 ` Tony Lindgren
2011-09-21 7:06 ` Arnd Bergmann
2011-09-21 7:06 ` Arnd Bergmann
2011-09-22 0:52 ` Tony Lindgren
2011-09-22 0:52 ` Tony Lindgren
2011-09-21 9:28 ` Arnd Bergmann
2011-09-21 9:28 ` Arnd Bergmann
2011-09-21 13:51 ` Tony Lindgren
2011-09-21 13:51 ` Tony Lindgren
2011-09-21 16:43 ` Kevin Hilman
2011-09-21 16:43 ` Kevin Hilman
2011-09-22 14:33 ` Arnd Bergmann
2011-09-22 14:33 ` Arnd Bergmann
2011-09-22 16:15 ` Kevin Hilman
2011-09-22 16:15 ` Kevin Hilman
2011-09-23 22:53 ` Tony Lindgren [this message]
2011-09-23 22:53 ` Tony Lindgren
2011-09-30 20:04 ` Arnd Bergmann
2011-09-30 20:04 ` Arnd Bergmann
2011-09-20 23:25 ` [PATCH] ARM: OMAP2+: Fix missing inline functions for Makefile cleanup (Re: [GIT PULL] omap cleanup part1 for v3.2 merge window) Tony Lindgren
2011-09-20 23:25 ` Tony Lindgren
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=20110923225309.GA6324@atomide.com \
--to=tony@atomide.com \
--cc=arnd@arndb.de \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.