* [PATCH 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Paul Walmsley @ 2011-01-04 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-2-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh
On Tue, 4 Jan 2011, Santosh Shilimkar wrote:
> struct clockdomain member clktrctrl_mask is available for only for OMAP2
> and OMAP3 architectures. Technially it is also used only for these archs
> but this breaks the build with custom OMAP4 configuration.
>
> CC arch/arm/mach-omap2/clockdomain.o
> arch/arm/mach-omap2/clockdomain.c: In function '_enable_hwsup':
> arch/arm/mach-omap2/clockdomain.c:251: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c:254: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function '_disable_hwsup':
> arch/arm/mach-omap2/clockdomain.c:277: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c:280: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_sleep':
> arch/arm/mach-omap2/clockdomain.c:744: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_wakeup':
> arch/arm/mach-omap2/clockdomain.c:789: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_enable':
> arch/arm/mach-omap2/clockdomain.c:922: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c:926: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_disable':
> arch/arm/mach-omap2/clockdomain.c:994: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> arch/arm/mach-omap2/clockdomain.c:998: error: 'struct clockdomain' has no member named 'clktrctrl_mask'
> make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
> make: *** [arch/arm/mach-omap2] Error 2
>
> Fix the build break with use of ARCH_OMAP2PLUS instead of OMAP2 or OMAP3
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/clockdomain.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h
> index de3faa2..6fa82f5 100644
> --- a/arch/arm/mach-omap2/clockdomain.h
> +++ b/arch/arm/mach-omap2/clockdomain.h
> @@ -103,7 +103,7 @@ struct clockdomain {
> const char *name;
> struct powerdomain *ptr;
> } pwrdm;
> -#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> +#ifdef CONFIG_ARCH_OMAP2PLUS
No need for this, just drop the #ifdef...
> const u16 clktrctrl_mask;
- Paul
^ permalink raw reply
* [PATCH 3/5] omap2plus: voltage: Trivial warning fix 'no return statement'
From: Nishanth Menon @ 2011-01-04 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-4-git-send-email-santosh.shilimkar@ti.com>
Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the following:
[..]
> diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
> index 0ff1233..710f4ea 100644
> --- a/arch/arm/plat-omap/include/plat/voltage.h
> +++ b/arch/arm/plat-omap/include/plat/voltage.h
> @@ -134,7 +134,10 @@ void omap_change_voltscale_method(struct voltagedomain *voltdm,
> int omap_voltage_late_init(void);
> #else
> static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
> - struct omap_volt_pmic_info *pmic_info) {}
> + struct omap_volt_pmic_info *pmic_info)
> +{
> + return 0;
since we dont really succeed registering the pmic to voltage layer,
return -EINVAL?
[..]
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Santosh Shilimkar @ 2011-01-04 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101041139110.19319@utopia.booyaka.com>
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Wednesday, January 05, 2011 12:11 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 2/5] omap2plus: prm: Trvial build break fix for
> undefined reference to 'omap2_prm_read_mod_reg'
>
> Hi Santosh,
>
> On Tue, 4 Jan 2011, Santosh Shilimkar wrote:
>
> > omap2plus_defocnfig build breaks when customised with only
> ARCH_OMAP4
> > selected. This is because common files make references to the
> functions
> > which are defined only for omap2xxx and omap3xxx.
> >
> > LD .tmp_vmlinux1
> > arch/arm/mach-omap2/built-in.o: In function `pm_dbg_regset_store':
> > arch/arm/mach-omap2/pm-debug.c:335: undefined reference to
> `omap2_prm_read_mod_reg'
> > arch/arm/mach-omap2/built-in.o: In function `omap2_pm_dump':
> > arch/arm/mach-omap2/pm-debug.c:121: undefined reference to
> `omap2_prm_read_mod_reg'
> > arch/arm/mach-omap2/pm-debug.c:123: undefined reference to
> `omap2_prm_read_mod_reg'
> > arch/arm/mach-omap2/pm-debug.c:124: undefined reference to
> `omap2_prm_read_mod_reg'
> > arch/arm/mach-omap2/pm-debug.c:125: undefined reference to
> `omap2_prm_read_mod_reg'
> > arch/arm/mach-omap2/built-in.o: In function
> `omap_prcm_arch_reset':
> > arch/arm/mach-omap2/prcm.c:106: undefined reference to
> `omap2_prm_set_mod_reg_bits'
> > arch/arm/mach-omap2/prcm.c:108: undefined reference to
> `omap2_prm_read_mod_reg'
> > arch/arm/mach-omap2/built-in.o: In function
> `omap_prcm_get_reset_sources':
> > arch/arm/mach-omap2/prcm.c:53: undefined reference to
> `omap2_prm_read_mod_reg'
> > arch/arm/mach-omap2/built-in.o: In function
> `clkdm_clear_all_wkdeps':
> > arch/arm/mach-omap2/clockdomain.c:545: undefined reference to
> `omap2_prm_clear_mod_reg_bits'
> > arch/arm/mach-omap2/built-in.o: In function `clkdm_del_wkdep':
> > arch/arm/mach-omap2/clockdomain.c:475: undefined reference to
> `omap2_prm_clear_mod_reg_bits'
> > arch/arm/mach-omap2/built-in.o: In function `clkdm_read_wkdep':
> > arch/arm/mach-omap2/clockdomain.c:511: undefined reference to
> `omap2_prm_read_mod_bits_shift'
> > arch/arm/mach-omap2/built-in.o: In function `clkdm_add_wkdep':
> > arch/arm/mach-omap2/clockdomain.c:440: undefined reference to
> `omap2_prm_set_mod_reg_bits'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > This patch adds stubs for these functions so that build continues
> to work.
> >
> > Probably alternately the build can be fixed as below but that not
> seems to
> > be the right way.
>
> Since these functions now return 0, maybe it would be better to call
> WARN() or BUG() in these functions for OMAP4. Otherwise, they are
> going
> to silently do the wrong thing, and someone needs to fix any usage
> of
> these functions where they shouldn't be used. e.g., in mach-
> omap2/prcm.c
> or mach-omap2/pm-debug.c ...
>
Good point. Will update the patch accordingly and repost.
Regards,
Santosh
^ permalink raw reply
* [PATCH 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Santosh Shilimkar @ 2011-01-04 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101041141260.19319@utopia.booyaka.com>
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Wednesday, January 05, 2011 12:13 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/5] omap2plus: clockdomain: Trivial fix for
> build break because of clktrctrl_mask
>
> Hi Santosh
>
> On Tue, 4 Jan 2011, Santosh Shilimkar wrote:
>
> > struct clockdomain member clktrctrl_mask is available for only for
> OMAP2
> > and OMAP3 architectures. Technially it is also used only for these
> archs
> > but this breaks the build with custom OMAP4 configuration.
> >
> > CC arch/arm/mach-omap2/clockdomain.o
> > arch/arm/mach-omap2/clockdomain.c: In function '_enable_hwsup':
> > arch/arm/mach-omap2/clockdomain.c:251: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c:254: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c: In function '_disable_hwsup':
> > arch/arm/mach-omap2/clockdomain.c:277: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c:280: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c: In function
> 'omap2_clkdm_sleep':
> > arch/arm/mach-omap2/clockdomain.c:744: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c: In function
> 'omap2_clkdm_wakeup':
> > arch/arm/mach-omap2/clockdomain.c:789: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c: In function
> 'omap2_clkdm_clk_enable':
> > arch/arm/mach-omap2/clockdomain.c:922: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c:926: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c: In function
> 'omap2_clkdm_clk_disable':
> > arch/arm/mach-omap2/clockdomain.c:994: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > arch/arm/mach-omap2/clockdomain.c:998: error: 'struct clockdomain'
> has no member named 'clktrctrl_mask'
> > make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
> > make: *** [arch/arm/mach-omap2] Error 2
> >
> > Fix the build break with use of ARCH_OMAP2PLUS instead of OMAP2 or
> OMAP3
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > ---
> > arch/arm/mach-omap2/clockdomain.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-
> omap2/clockdomain.h
> > index de3faa2..6fa82f5 100644
> > --- a/arch/arm/mach-omap2/clockdomain.h
> > +++ b/arch/arm/mach-omap2/clockdomain.h
> > @@ -103,7 +103,7 @@ struct clockdomain {
> > const char *name;
> > struct powerdomain *ptr;
> > } pwrdm;
> > -#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> > +#ifdef CONFIG_ARCH_OMAP2PLUS
>
> No need for this, just drop the #ifdef...
>
Perfect. Will fix this in v2
> > const u16 clktrctrl_mask;
>
>
> - Paul
^ permalink raw reply
* [PATCH 4/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
From: Nishanth Menon @ 2011-01-04 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-5-git-send-email-santosh.shilimkar@ti.com>
Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the following:
[..]
> diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
> index 710f4ea..c095351 100644
> --- a/arch/arm/plat-omap/include/plat/voltage.h
> +++ b/arch/arm/plat-omap/include/plat/voltage.h
> @@ -65,9 +65,6 @@ struct voltagedomain {
> char *name;
> };
>
> -/* API to get the voltagedomain pointer */
> -struct voltagedomain *omap_voltage_domain_lookup(char *name);
> -
> /**
> * struct omap_volt_data - Omap voltage specific data.
> * @voltage_nominal: The possible voltage value in uV
> @@ -131,6 +128,9 @@ int omap_voltage_register_pmic(struct voltagedomain *voltdm,
> struct omap_volt_pmic_info *pmic_info);
> void omap_change_voltscale_method(struct voltagedomain *voltdm,
> int voltscale_method);
> +/* API to get the voltagedomain pointer */
> +struct voltagedomain *omap_voltage_domain_lookup(char *name);
> +
> int omap_voltage_late_init(void);
> #else
> static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
> @@ -144,6 +144,10 @@ static inline int omap_voltage_late_init(void)
> {
> return -EINVAL;
> }
> +static inline struct voltagedomain *omap_voltage_domain_lookup(char *name)
> +{
> + return NULL;
the omap_voltage_domain_lookup uses ERR_PTR() for all return values
which are handled by the callers with IS_ERR()
I think you should return ERR_PTR(-EINVAL)
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 3/5] omap2plus: voltage: Trivial warning fix 'no return statement'
From: Santosh Shilimkar @ 2011-01-04 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D236A5D.9040803@ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Wednesday, January 05, 2011 12:14 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
> linux-arm-kernel at lists.infradead.org; Thara Gopinath; Kevin Hilman
> Subject: Re: [PATCH 3/5] omap2plus: voltage: Trivial warning fix 'no
> return statement'
>
> Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the
> following:
> [..]
> > diff --git a/arch/arm/plat-omap/include/plat/voltage.h
> b/arch/arm/plat-omap/include/plat/voltage.h
> > index 0ff1233..710f4ea 100644
> > --- a/arch/arm/plat-omap/include/plat/voltage.h
> > +++ b/arch/arm/plat-omap/include/plat/voltage.h
> > @@ -134,7 +134,10 @@ void omap_change_voltscale_method(struct
> voltagedomain *voltdm,
> > int omap_voltage_late_init(void);
> > #else
> > static inline int omap_voltage_register_pmic(struct voltagedomain
> *voltdm,
> > - struct omap_volt_pmic_info *pmic_info) {}
> > + struct omap_volt_pmic_info *pmic_info)
> > +{
> > + return 0;
> since we dont really succeed registering the pmic to voltage layer,
> return -EINVAL?
>
Ok. Will take this in v2
Regards,
Santosh
^ permalink raw reply
* [PATCH 4/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
From: Santosh Shilimkar @ 2011-01-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D236AFB.2050301@ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Wednesday, January 05, 2011 12:16 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
> linux-arm-kernel at lists.infradead.org; Thara Gopinath; Kevin Hilman
> Subject: Re: [PATCH 4/5] omap2plus: voltage: Trivial linking fix
> 'undefined reference'
>
> Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the
> following:
> [..]
>
> > diff --git a/arch/arm/plat-omap/include/plat/voltage.h
> b/arch/arm/plat-omap/include/plat/voltage.h
> > index 710f4ea..c095351 100644
> > --- a/arch/arm/plat-omap/include/plat/voltage.h
> > +++ b/arch/arm/plat-omap/include/plat/voltage.h
> > @@ -65,9 +65,6 @@ struct voltagedomain {
> > char *name;
> > };
> >
> > -/* API to get the voltagedomain pointer */
> > -struct voltagedomain *omap_voltage_domain_lookup(char *name);
> > -
> > /**
> > * struct omap_volt_data - Omap voltage specific data.
> > * @voltage_nominal: The possible voltage value in uV
> > @@ -131,6 +128,9 @@ int omap_voltage_register_pmic(struct
> voltagedomain *voltdm,
> > struct omap_volt_pmic_info *pmic_info);
> > void omap_change_voltscale_method(struct voltagedomain *voltdm,
> > int voltscale_method);
> > +/* API to get the voltagedomain pointer */
> > +struct voltagedomain *omap_voltage_domain_lookup(char *name);
> > +
> > int omap_voltage_late_init(void);
> > #else
> > static inline int omap_voltage_register_pmic(struct voltagedomain
> *voltdm,
> > @@ -144,6 +144,10 @@ static inline int
> omap_voltage_late_init(void)
> > {
> > return -EINVAL;
> > }
> > +static inline struct voltagedomain
> *omap_voltage_domain_lookup(char *name)
> > +{
> > + return NULL;
> the omap_voltage_domain_lookup uses ERR_PTR() for all return values
> which are handled by the callers with IS_ERR()
>
> I think you should return ERR_PTR(-EINVAL)
>
The expected return value is pointer type and hence used
NULL.
^ permalink raw reply
* [PATCH 2/3] perf: add OMAP support for the new power events
From: Paul Walmsley @ 2011-01-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294138484-24729-1-git-send-email-j-pihet@ti.com>
Hello Jean,
On Tue, 4 Jan 2011, jean.pihet at newoldbits.com wrote:
> From: Jean Pihet <j-pihet@ti.com>
>
> The patch adds the new power management trace points for
> the OMAP architecture.
>
> The trace points are for:
> - default idle handler. Since the cpuidle framework is
> instrumented in the generic way there is no need to
> add trace points in the OMAP specific cpuidle handler;
> - cpufreq (DVFS),
> - clocks changes (enable, disable, set_rate),
A question about these. Are these only meant to track calls to these
functions from outside the clock code? Or meant to track actual hardware
clock changes? If the latter, then it might make sense to put these
trace points into the functions that actually change the hardware
registers, e.g., omap2_dflt_clk_{enable,disable}(), etc., since a
clk_enable() on a leaf clock may result in many internal system clocks
being enabled up the clock tree.
- Paul
> - change of power domains next power states.
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
> ---
> arch/arm/mach-omap2/pm34xx.c | 7 +++++++
> arch/arm/mach-omap2/powerdomain.c | 3 +++
> arch/arm/plat-omap/clock.c | 13 ++++++++++---
> 3 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 0ec8a04..0ee0b0e 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -29,6 +29,7 @@
> #include <linux/delay.h>
> #include <linux/slab.h>
> #include <linux/console.h>
> +#include <trace/events/power.h>
>
> #include <plat/sram.h>
> #include <plat/clockdomain.h>
> @@ -506,8 +507,14 @@ static void omap3_pm_idle(void)
> if (omap_irq_pending() || need_resched())
> goto out;
>
> + trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> + trace_cpu_idle(1, smp_processor_id());
> +
> omap_sram_idle();
>
> + trace_power_end(smp_processor_id());
> + trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
> +
> out:
> local_fiq_enable();
> local_irq_enable();
> diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
> index 6527ec3..73cbe9a 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -23,6 +23,7 @@
> #include <linux/errno.h>
> #include <linux/err.h>
> #include <linux/io.h>
> +#include <trace/events/power.h>
>
> #include <asm/atomic.h>
>
> @@ -440,6 +441,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
> pr_debug("powerdomain: setting next powerstate for %s to %0x\n",
> pwrdm->name, pwrst);
>
> + trace_power_domain_target(pwrdm->name, pwrst, smp_processor_id());
> +
> prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
> (pwrst << OMAP_POWERSTATE_SHIFT),
> pwrdm->prcm_offs, pwrstctrl_reg_offs);
> diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
> index fc62fb5..7cbb09b 100644
> --- a/arch/arm/plat-omap/clock.c
> +++ b/arch/arm/plat-omap/clock.c
> @@ -21,6 +21,7 @@
> #include <linux/cpufreq.h>
> #include <linux/debugfs.h>
> #include <linux/io.h>
> +#include <trace/events/power.h>
>
> #include <plat/clock.h>
>
> @@ -43,8 +44,10 @@ int clk_enable(struct clk *clk)
> return -EINVAL;
>
> spin_lock_irqsave(&clockfw_lock, flags);
> - if (arch_clock->clk_enable)
> + if (arch_clock->clk_enable) {
> + trace_clock_enable(clk->name, 1, smp_processor_id());
> ret = arch_clock->clk_enable(clk);
> + }
> spin_unlock_irqrestore(&clockfw_lock, flags);
>
> return ret;
> @@ -66,8 +69,10 @@ void clk_disable(struct clk *clk)
> goto out;
> }
>
> - if (arch_clock->clk_disable)
> + if (arch_clock->clk_disable) {
> + trace_clock_disable(clk->name, 0, smp_processor_id());
> arch_clock->clk_disable(clk);
> + }
>
> out:
> spin_unlock_irqrestore(&clockfw_lock, flags);
> @@ -120,8 +125,10 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
> return ret;
>
> spin_lock_irqsave(&clockfw_lock, flags);
> - if (arch_clock->clk_set_rate)
> + if (arch_clock->clk_set_rate) {
> + trace_clock_set_rate(clk->name, rate, smp_processor_id());
> ret = arch_clock->clk_set_rate(clk, rate);
> + }
> if (ret == 0) {
> if (clk->recalc)
> clk->rate = clk->recalc(clk);
> --
> 1.7.2.3
>
- Paul
^ permalink raw reply
* [PATCH 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
From: Nishanth Menon @ 2011-01-04 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-6-git-send-email-santosh.shilimkar@ti.com>
Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the following:
> CC arch/arm/mach-omap2/omap_hwmod_common_data.o
> In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
> from arch/arm/mach-omap2/omap_hwmod_common_data.c:20:
> arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_late_init':
> arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL' undeclared (first use in this function)
> arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each undeclared identifier is reported only once
> arch/arm/plat-omap/include/plat/voltage.h:145: error: for each function it appears in.)
> make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1
> make: *** [arch/arm/mach-omap2] Error 2
>
> The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Thara Gopinath <thara@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> ---
> arch/arm/plat-omap/include/plat/voltage.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h
> index c095351..2b776f0 100644
> --- a/arch/arm/plat-omap/include/plat/voltage.h
> +++ b/arch/arm/plat-omap/include/plat/voltage.h
> @@ -14,6 +14,8 @@
> #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
> #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
>
> +#include <linux/err.h>
> +
Not sure if this is better OR including the err.h in c files is better,
since the c file is the location where the error code is actually used..
but no strong feelings about either personally.
[..]
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/3] hvc_dcc: Fix bad code generation by marking assembly volatile
From: Tony Lindgren @ 2011-01-04 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1012201638150.10437@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [101220 13:38]:
> On Mon, 20 Dec 2010, Stephen Boyd wrote:
>
> > Without marking the asm __dcc_getstatus() volatile my compiler
> > decides it can cache the value of __ret in a register and then
> > check the value of it continually in hvc_dcc_put_chars() (I had
> > to replace get_wait/put_wait with 1 and fixup the branch
> > otherwise my disassembler barfed on __dcc_(get|put)char).
> >
> > 00000000 <hvc_dcc_put_chars>:
> > 0: ee103e11 mrc 14, 0, r3, cr0, cr1, {0}
> > 4: e3a0c000 mov ip, #0 ; 0x0
> > 8: e2033202 and r3, r3, #536870912 ; 0x20000000
> > c: ea000006 b 2c <hvc_dcc_put_chars+0x2c>
> > 10: e3530000 cmp r3, #0 ; 0x0
> > 14: 1afffffd bne 10 <hvc_dcc_put_chars+0x10>
> > 18: e7d1000c ldrb r0, [r1, ip]
> > 1c: ee10fe11 mrc 14, 0, pc, cr0, cr1, {0}
> > 20: 2afffffd bcs 1c <hvc_dcc_put_chars+0x1c>
> > 24: ee000e15 mcr 14, 0, r0, cr0, cr5, {0}
> > 28: e28cc001 add ip, ip, #1 ; 0x1
> > 2c: e15c0002 cmp ip, r2
> > 30: bafffff6 blt 10 <hvc_dcc_put_chars+0x10>
> > 34: e1a00002 mov r0, r2
> > 38: e12fff1e bx lr
> >
> > As you can see, the value of the mrc is checked against
> > DCC_STATUS_TX (bit 29) and then stored in r3 for later use.
> > Marking the asm volatile produces the following:
> >
> > 00000000 <hvc_dcc_put_chars>:
> > 0: e3a03000 mov r3, #0 ; 0x0
> > 4: ea000007 b 28 <hvc_dcc_put_chars+0x28>
> > 8: ee100e11 mrc 14, 0, r0, cr0, cr1, {0}
> > c: e3100202 tst r0, #536870912 ; 0x20000000
> > 10: 1afffffc bne 8 <hvc_dcc_put_chars+0x8>
> > 14: e7d10003 ldrb r0, [r1, r3]
> > 18: ee10fe11 mrc 14, 0, pc, cr0, cr1, {0}
> > 1c: 2afffffd bcs 18 <hvc_dcc_put_chars+0x18>
> > 20: ee000e15 mcr 14, 0, r0, cr0, cr5, {0}
> > 24: e2833001 add r3, r3, #1 ; 0x1
> > 28: e1530002 cmp r3, r2
> > 2c: bafffff5 blt 8 <hvc_dcc_put_chars+0x8>
> > 30: e1a00002 mov r0, r2
> > 34: e12fff1e bx lr
> >
> > which looks better and actually works. Mark all the inline
> > assembly in this file as volatile since we don't want the
> > compiler to optimize away these statements or move them around
> > in any way.
> >
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> > Cc: Daniel Walker <dwalker@codeaurora.org>
> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 4/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
From: Santosh Shilimkar @ 2011-01-04 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a7055e7c506648a2a48a0454756687b@mail.gmail.com>
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> Sent: Wednesday, January 05, 2011 12:18 AM
> To: Nishanth Menon
> Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com;
> linux-arm-kernel at lists.infradead.org; Thara Gopinath; Kevin Hilman
> Subject: RE: [PATCH 4/5] omap2plus: voltage: Trivial linking fix
> 'undefined reference'
>
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > owner at vger.kernel.org] On Behalf Of Nishanth Menon
> > Sent: Wednesday, January 05, 2011 12:16 AM
> > To: Santosh Shilimkar
> > Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
> > linux-arm-kernel at lists.infradead.org; Thara Gopinath; Kevin Hilman
> > Subject: Re: [PATCH 4/5] omap2plus: voltage: Trivial linking fix
> > 'undefined reference'
> >
> > Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the
> > following:
> > [..]
> >
[..]
> > > +static inline struct voltagedomain
> > *omap_voltage_domain_lookup(char *name)
> > > +{
> > > + return NULL;
> > the omap_voltage_domain_lookup uses ERR_PTR() for all return
> values
> > which are handled by the callers with IS_ERR()
> >
> > I think you should return ERR_PTR(-EINVAL)
> >
> The expected return value is pointer type and hence used
> NULL.
'ERR_PTR(-EINVAL)' is also ok.
^ permalink raw reply
* [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
From: Sergei Shtylyov @ 2011-01-04 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104184244.GC2647@legolas.emea.dhcp.ti.com>
Hello.
Felipe Balbi wrote:
> On Tue, Jan 04, 2011 at 11:41:05PM +0800, Ming Lei wrote:
>> OMAP GPIOs have many usages or use cases, so we can use gpiolib
>> to simplify access to GPIOs. If GPIOs has only one usage or use case,
>> it is not necessary to access GPIOs by gpiolib.
>> Now this kind of DMA controllers are only used by MUSB or only for
>> MUSB, so it doesn't matter to access them by dmaengine or not.
> Not entirely true. TUSB uses OMAP system DMA and AFAICT CPPI is used
> also for ethernet.
Yes, but the CPPI registers are not compatible between MUSB and EMAC, only
the descriptors are, AFAIK.
WBR, Sergei
^ permalink raw reply
* [PATCH 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
From: Santosh Shilimkar @ 2011-01-04 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D236BA0.8010002@ti.com>
> -----Original Message-----
> From: Nishanth Menon [mailto:nm at ti.com]
> Sent: Wednesday, January 05, 2011 12:19 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
> linux-arm-kernel at lists.infradead.org; Thara Gopinath; Kevin Hilman
> Subject: Re: [PATCH 5/5] omap2plus: voltage: Trivial linking fix for
> 'EINVAL' undeclared
>
> Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the
> following:
> > CC arch/arm/mach-omap2/omap_hwmod_common_data.o
> > In file included from arch/arm/plat-
> omap/include/plat/omap_hwmod.h:38,
> > from arch/arm/mach-
> omap2/omap_hwmod_common_data.c:20:
> > arch/arm/plat-omap/include/plat/voltage.h: In function
> 'omap_voltage_late_init':
> > arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL'
> undeclared (first use in this function)
> > arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each
> undeclared identifier is reported only once
> > arch/arm/plat-omap/include/plat/voltage.h:145: error: for each
> function it appears in.)
> > make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error
> 1
> > make: *** [arch/arm/mach-omap2] Error 2
> >
> > The error is reported when omap2plus_defconfig built with
> CONFIG_PM disabled
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Thara Gopinath <thara@ti.com>
> > Cc: Kevin Hilman <khilman@deeprootsystems.com>
> > ---
> > arch/arm/plat-omap/include/plat/voltage.h | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/include/plat/voltage.h
> b/arch/arm/plat-omap/include/plat/voltage.h
> > index c095351..2b776f0 100644
> > --- a/arch/arm/plat-omap/include/plat/voltage.h
> > +++ b/arch/arm/plat-omap/include/plat/voltage.h
> > @@ -14,6 +14,8 @@
> > #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
> > #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
> >
> > +#include <linux/err.h>
> > +
>
> Not sure if this is better OR including the err.h in c files is
> better,
> since the c file is the location where the error code is actually
> used..
>
> but no strong feelings about either personally.
>
The error is because of 'EINVAL' usage in header file. How
Will this error get fixed by including err.h is C file ?
^ permalink raw reply
* [PATCH 4/5] omap2plus: voltage: Trivial linking fix 'undefined reference'
From: Nishanth Menon @ 2011-01-04 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7800f7a785b294a089ea8772607d232@mail.gmail.com>
Santosh Shilimkar had written, on 01/04/2011 12:50 PM, the following:
[..]
>>>> +static inline struct voltagedomain
>>> *omap_voltage_domain_lookup(char *name)
>>>> +{
>>>> + return NULL;
>>> the omap_voltage_domain_lookup uses ERR_PTR() for all return
>> values
>>> which are handled by the callers with IS_ERR()
>>>
>>> I think you should return ERR_PTR(-EINVAL)
>>>
>> The expected return value is pointer type and hence used
>> NULL.
>
> 'ERR_PTR(-EINVAL)' is also ok.
looking at the implementation (when CONFIG_PM is enabled),
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/voltage.c;h=ed6079c94c57bae30f599bbad5e25a38fc676fa8;hb=refs/heads/omap-for-linus#l1487
ERR_PTR(-EINVAL) looks more appropriate to me.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 3/3] hvc_dcc: Simplify assembly for v6 and v7 ARM
From: Tony Lindgren @ 2011-01-04 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1012201644110.10437@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [101220 13:44]:
> On Mon, 20 Dec 2010, Stephen Boyd wrote:
>
> > The inline assembly differences for v6 vs. v7 in the hvc_dcc
> > driver are purely optimizations. On a v7 processor, an mrc with
> > the pc sets the condition codes to the 28-31 bits of the register
> > being read. It just so happens that the TX/RX full bits the DCC
> > driver is testing for are high enough in the register to be put
> > into the condition codes. On a v6 processor, this "feature" isn't
> > implemented and thus we have to do the usual read, mask, test
> > operations to check for TX/RX full.
> >
> > Since we already test the RX/TX full bits before calling
> > __dcc_getchar() and __dcc_putchar() we don't actually need to do
> > anything special for v7 over v6. The only difference is in
> > hvc_dcc_get_chars(). We would test RX full, poll RX full, and
> > then read a character from the buffer, whereas now we will test
> > RX full, read a character from the buffer, and then test RX full
> > again for the second iteration of the loop. It doesn't seem
> > possible for the buffer to go from full to empty between testing
> > the RX full and reading a character. Therefore, replace the v7
> > versions with the v6 versions and everything works the same.
> >
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> > Cc: Daniel Walker <dwalker@codeaurora.org>
> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 5/5] omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
From: Nishanth Menon @ 2011-01-04 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd04d3678881a910a0639746ed04043d@mail.gmail.com>
Santosh Shilimkar had written, on 01/04/2011 12:51 PM, the following:
>> -----Original Message-----
>> From: Nishanth Menon [mailto:nm at ti.com]
>> Sent: Wednesday, January 05, 2011 12:19 AM
>> To: Santosh Shilimkar
>> Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
>> linux-arm-kernel at lists.infradead.org; Thara Gopinath; Kevin Hilman
>> Subject: Re: [PATCH 5/5] omap2plus: voltage: Trivial linking fix for
>> 'EINVAL' undeclared
>>
>> Santosh Shilimkar had written, on 01/04/2011 12:26 PM, the
>> following:
>>> CC arch/arm/mach-omap2/omap_hwmod_common_data.o
>>> In file included from arch/arm/plat-
>> omap/include/plat/omap_hwmod.h:38,
>>> from arch/arm/mach-
>> omap2/omap_hwmod_common_data.c:20:
>>> arch/arm/plat-omap/include/plat/voltage.h: In function
>> 'omap_voltage_late_init':
>>> arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL'
>> undeclared (first use in this function)
>>> arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each
>> undeclared identifier is reported only once
>>> arch/arm/plat-omap/include/plat/voltage.h:145: error: for each
>> function it appears in.)
>>> make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error
>> 1
>>> make: *** [arch/arm/mach-omap2] Error 2
>>>
>>> The error is reported when omap2plus_defconfig built with
>> CONFIG_PM disabled
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> Cc: Thara Gopinath <thara@ti.com>
>>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>>> ---
>>> arch/arm/plat-omap/include/plat/voltage.h | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/plat-omap/include/plat/voltage.h
>> b/arch/arm/plat-omap/include/plat/voltage.h
>>> index c095351..2b776f0 100644
>>> --- a/arch/arm/plat-omap/include/plat/voltage.h
>>> +++ b/arch/arm/plat-omap/include/plat/voltage.h
>>> @@ -14,6 +14,8 @@
>>> #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
>>> #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
>>>
>>> +#include <linux/err.h>
>>> +
>> Not sure if this is better OR including the err.h in c files is
>> better,
>> since the c file is the location where the error code is actually
>> used..
>>
>> but no strong feelings about either personally.
>>
> The error is because of 'EINVAL' usage in header file. How
> Will this error get fixed by including err.h is C file ?
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -16,6 +16,7 @@
* data and their integration with other OMAP modules and Linux.
*/
+#include <linux/err.h>
#include <plat/omap_hwmod.h>
#include "omap_hwmod_common_data.h"
no?
Basically, this points that omap_hwmod_common_data.c does not use the
error return values, which probably gets hidden by including err.h in
the header itself.. in this particular case, maynot be important, and
probably apis which should have return values checked should be marked
so.. anyways, just my 2 cents - no hard opinions about either as far as
I am concerned.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/4] ARM: runtime patching of __virt_to_phys() and __phys_to_virt()
From: David Brown @ 2011-01-04 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101041330450.22191@xanadu.home>
On Tue, Jan 04 2011, Nicolas Pitre wrote:
> On Tue, 4 Jan 2011, David Brown wrote:
>
>> Any idea how much it would hurt other targets to have the
>> __virt_to_phys() and __phys_to_virt() have a 16-bit fixup, even if only
>> the upper 8 bits are used?
>
> Probably not that much. But let's make it work satisfactorily for the
> general case first, and then we might consider and test variations that
> could accommodate msm.
Sounds like a good plan. We've got quite a few other things to clean up
before we can build for more than one arch anyway.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
From: Tony Lindgren @ 2011-01-04 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110103204952.GB2240@legolas.emea.dhcp.ti.com>
* Felipe Balbi <balbi@ti.com> [110103 12:49]:
> Hi,
>
> On Mon, Jan 03, 2011 at 05:19:45PM +0000, Russell King - ARM Linux wrote:
> >> Frankly speaking, I doubt that drivers/dma/ will have place for the
> >>purely MUSB specific DMA engines such as the named ones (there's no TUSB
> >>DMA BTW -- it uses OMAP DMA).
> >
> >Long term, we need to kill off all these platform private DMA interfaces.
> >There's a growing amount of IP that's being shared not only between ARM
> >silicon vendors, but also across architectures, and having to re-implement
> >drivers because the underlying DMA engine is different is not feasible.
> >
> >For example, we're seeing ARMs primecells being used with various
> >different DMA controllers in various different ARM SoCs. I've heard
> >rumours of them appearing in MIPS or PPC stuff as well. We're seeing
> >PXA peripheral IP appearing in x86 stuff too.
> >
> >We can't have drivers tied to their SoC DMA engines, and we can't continue
> >having SoC DMA engines implementing their own unique APIs. We do need to
> >get on top of this before it becomes a major problem (if it hasn't
> >already).
> >
> >The DMA engine API is still evolving, and should not be taken as concrete
> >- I've recently been bringing up a number of points with Dan on various
> >aspects of the API, some of which ultimately will lead to changes to the
> >async-tx API, and others which hopefully will mean that the DMA slave
> >API is better documented.
>
> I couldn't agree more with you Russell. If the API isn't enough
> currently, we can always propose an extension.
>
> Having all sorts of SoC-specific "APIs" has already caused enough
> problems and it still does (non-generic IRQ handling on
> twl?030, menelaus, cbus - which isn't in mainline yet -, etc,
> non-generic McBSP usage, non-generic GPMC usage, etc etc). So, if we can
> plan for making use of generic APIs, let's do so.
Yes I too agree with this. We just need to do whatever it takes to
make the DMA engine suitable for all drivers.
Regards,
Tony
^ permalink raw reply
* [PATCH] omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE
From: Tony Lindgren @ 2011-01-04 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinc1xopSYvaJmN_hHaQq1TP=i_HNy5vX_LhdQOh@mail.gmail.com>
* Ohad Ben-Cohen <ohad@wizery.com> [110104 10:04]:
> On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> > Power to the wl12xx wlan device is controlled by a fixed regulator.
> >
> > Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so
> > users will not be baffled.
> >
> > Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> > ---
>
> Hi Tony,
>
> Gentle reminder,
This is queued for 2.6.38 in omap-for-linus as commit
7c50152f0851e44ef7491546a29fddbbea47735b?
Tony
^ permalink raw reply
* [PATCH] omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE
From: Ohad Ben-Cohen @ 2011-01-04 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104191732.GI7771@atomide.com>
On Tue, Jan 4, 2011 at 9:17 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ohad Ben-Cohen <ohad@wizery.com> [110104 10:04]:
>> On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> > Power to the wl12xx wlan device is controlled by a fixed regulator.
>> >
>> > Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so
>> > users will not be baffled.
>> >
>> > Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
>> > ---
>>
>> Hi Tony,
>>
>> Gentle reminder,
>
> This is queued for 2.6.38 in omap-for-linus as commit
> 7c50152f0851e44ef7491546a29fddbbea47735b?
Thanks!
>
> Tony
>
^ permalink raw reply
* [patch 2/5] ulpi: handle ULPI_OTG_CTRL_CHRGVBUS
From: Arnaud Patard (Rtp) @ 2011-01-04 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D22D256.2040504@compulab.co.il>
Igor Grinberg <grinberg@compulab.co.il> writes:
Adding Matt Sealey in CC:. he's the product development analyst so he
knows the hardware (unlike me).
> On 01/03/11 16:04, Arnaud Patard (Rtp) wrote:
>> Igor Grinberg <grinberg@compulab.co.il> writes:
>>> On 01/03/11 13:41, Arnaud Patard (Rtp) wrote:
>>>> Igor Grinberg <grinberg@compulab.co.il> writes:
>>>> Hi,
>>>>> On 12/23/10 22:11, Arnaud Patard (Rtp) wrote:
>>>>>> Igor Grinberg <grinberg@compulab.co.il> writes:
>>>>>>> Hi Arnaud,
>>>>>>>
>>>>>>> On 12/20/10 17:48, Arnaud Patard (Rtp) wrote:
>>>>>>>> Current code doesn't handle setting CHRGVBUS when enabling vbus.
>>>>>>>> Add support for it
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>>>>>>>> Index: tst-usb/drivers/usb/otg/ulpi.c
>>>>>>>> ===================================================================
>>>>>>>> --- tst-usb.orig/drivers/usb/otg/ulpi.c 2010-12-20 15:38:41.000000000 +0100
>>>>>>>> +++ tst-usb/drivers/usb/otg/ulpi.c 2010-12-20 15:38:57.000000000 +0100
>>>>>>>> @@ -234,7 +234,8 @@
>>>>>>>> {
>>>>>>>> unsigned int flags = otg_io_read(otg, ULPI_OTG_CTRL);
>>>>>>>>
>>>>>>>> - flags &= ~(ULPI_OTG_CTRL_DRVVBUS | ULPI_OTG_CTRL_DRVVBUS_EXT);
>>>>>>>> + flags &= ~(ULPI_OTG_CTRL_DRVVBUS | ULPI_OTG_CTRL_DRVVBUS_EXT |
>>>>>>>> + ULPI_OTG_CTRL_CHRGVBUS);
>>>>>>>>
>>>>>>>> if (on) {
>>>>>>>> if (otg->flags & ULPI_OTG_DRVVBUS)
>>>>>>>> @@ -242,6 +243,9 @@
>>>>>>>>
>>>>>>>> if (otg->flags & ULPI_OTG_DRVVBUS_EXT)
>>>>>>>> flags |= ULPI_OTG_CTRL_DRVVBUS_EXT;
>>>>>>>> +
>>>>>>>> + if (otg->flags & ULPI_OTG_CHRGVBUS)
>>>>>>>> + flags |= ULPI_OTG_CTRL_CHRGVBUS;
>>>>>>>> }
>>>>>>>>
>>>>>>>> return otg_io_write(otg, flags, ULPI_OTG_CTRL);
>>>>>>> I think this is a wrong place to set the ChrgVbus bit.
>>>>>>> As for ULPI spec. 1.1:
>>>>>>> "3.8.7.1 Session Request Protocol (SRP)
>>>>>>> ULPI provides full SRP support. The Link uses the ChrgVbus and DischrgVbus bits
>>>>>>> in the OTG Control register to begin and end a session."
>>>>>>>
>>>>>>> So it is used for SRP.
>>>>>>> May be it is better to implement
>>>>>>> int (*start_srp)(struct otg_transceiver *otg);
>>>>>>> method for setting this bit?
>>>>>>>
>>>>>> I was not sure on where to put this so I took the same approach as the
>>>>>> fsl bsp which was to set it in this function and to call this function
>>>>>> _after_ usb_add_hcd() [ see my previous patch ]. Indeed, it fixed my
>>>>>> issue so I believe it not so bad given that there has already been some
>>>>>> troubles on the ehci-mxc init.
>>>>> Well, the problem is that this is supposed to be a generic driver and it should
>>>>> somehow follow the ULPI spec.
>>>>> This patch makes it more like mxc specific.
>>>>>
>>>>> As far as I understand, Session Request Protocol (SRP) allows a B-device (Peripheral)
>>>>> to nudge an A-device (Host) to turn on the USB's Vbus.
>>>>> This patch enables SRP along with Vbus, which seems incorrect completely.
>>>>> ulpi_set_vbus() should set the Vbus (as its name says) and that's it.
>>>> so, if I add a srp hook as you're suggesting, which part of the driver
>>>> should call it ?
>>> It should be called from outside the ulpi driver by the OTG logic
>>> (just like ulpi_set_vbus() is called).
>>> But, again, SRP should be set by the B-device (peripheral) and Vbus by the A-device (Host).
>>> Usually, the A-device and B-device are on the opposite sides of the USB cable.
>>>
>>>>> Have you tried without this patch or have you just applied it along with other
>>>>> patches from the fsl bsp?
>>>> I already tried without this patch and without it, things are not
>>>> working on my systems.
>>>>> Also, if this specific patch (2/5) makes your USB (Host as I understand) work,
>>>>> it makes me think that there could be some problem with your Vbus supply.
>>>>> Have you checked that?
>>>> I don't have any schematics and I've access only to the source code of
>>>> the kernel running on the efika nettop and smartbook [1]. I've not seen
>>>> anything (even remotely) related to vbus supply except in the ulpi code
>>>> and from what I've heard, it's unlikely that there's something to
>>>> control it on theses systems. Of course, I'll be happy to be proven
>>>> wrong. Without usb theses systems are useless so anything the can reduce
>>>> the number of patches needed to get the systems working with mainline is
>>>> welcome.
>>> Well, I was certain you are trying to use that port in Host mode (A-device), but
>>> now I'm confused...
>>> You say "things are not working" - what are those things?
>>> Can you, please, describe what are you trying to do?
>>> What are you trying to connect to this USB port? What cable do you
>>> use?
>> I thought it was clear that "things" was everything connected on the usb
>> ports. The problem is that this also means that the nettop/smartbook are
>> kind of not working too as ethernet/wifi/bt/hid devs are all connected
>> on usb [ they're all on the pcb ]. So, even if you boot on the mmc aka
>> the only storage available which doesn't need usb, you won't be able to
>> login.
>>
>
> Well, "everything connected on the usb ports" can be confusing, because
> you can connect devices (usb disk drives, keyboards, mice, etc..) and hosts
> (desktop PCs, mobile computers, etc..) to the OTG port.
> That's why I wanted to be sure, what devices do you connect to that port.
> Now it is clear, that your port should be in the Host mode and you should _not_
> issue an SRP.
>
> "ethernet/wifi/bt/hid devs are all connected on usb" - this means,
> that they are either connected to several (different) usb ports or there is a usb hub
> connected to that port and those devices are connected to it.
> Can you confirm how those devices are connected?
>
>>> Also, what ulpi vendor/product id is reported in ulpi_init()?
>> ULPI transceiver vendor/product ID 0x0424/0x0006
>> Found SMSC USB3319 ULPI transceiver.
>
> SMSC USB3319 does not have either an integrated Vbus switch or Charge Pump,
> For the device connected to that transceiver could work properly,
> there is a need in _external Vbus switch_ , that should be enabled using
> some kind of CPEN pin (can be GPIO).
> This means, that you don't even need to call ulpi_set_vbus().
>
> Either way, this patch is NAK.
> I think you need to check your hardware (in particular Vbus supply).
^ permalink raw reply
* [patch 2/5] ulpi: handle ULPI_OTG_CTRL_CHRGVBUS
From: Matt Sealey @ 2011-01-04 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sjx8783g.fsf@lechat.rtp-net.org>
On Tue, Jan 4, 2011 at 2:00 PM, Arnaud Patard <arnaud.patard@rtp-net.org> wrote:
> Igor Grinberg <grinberg@compulab.co.il> writes:
>
> Adding Matt Sealey in CC:. he's the product development analyst so he
> knows the hardware (unlike me).
>>>> Also, what ulpi vendor/product id is reported in ulpi_init()?
>>> ULPI transceiver vendor/product ID 0x0424/0x0006
>>> Found SMSC USB3319 ULPI transceiver.
>>
>> SMSC USB3319 does not have either an integrated Vbus switch or Charge Pump,
>> For the device connected to that transceiver could work properly,
>> there is a need in _external Vbus switch_ , that should be enabled using
>> some kind of CPEN pin (can be GPIO).
>> This means, that you don't even need to call ulpi_set_vbus().
>>
>> Either way, this patch is NAK.
>> I think you need to check your hardware (in particular Vbus supply).
Hey guys,
On the Smartbook at least both USB host ports (H1 and H2) on the board
(one port each) are connected directly to 4-port USB hubs (SMSC2514).
We don't have anything on there except that connection: the hub should
handle VBUS properly. Both ports use an SMSC3317 (just a 3311 with a
built in 3.3V supply so the id and behavior should be identical).
On the Smarttop H1 is connected to a 4-port USB hub (Terminus FE1.1)
with the same configuration. Same PHY. The DR port is connected
directly to an ASIX ethernet controller. VBUS seems routed to a test
point.
I'm curious exactly what the real problem here is: that VBUS is
basically not being handled correctly? It should be driven or not? I'm
not entirely familiar with the specification.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH 0/5] OMAP2+: trivial sparse fixes
From: Nishanth Menon @ 2011-01-04 20:07 UTC (permalink / raw)
To: linux-arm-kernel
Source: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
branch: omap-for-linus (dc69d1a omap2: Make OMAP2PLUS select OMAP_DM_TIMER)
Building for sparse warnings result in the following warnings:
http://pastebin.mozilla.org/907954
This is series 2 of the sparse fixes
(series 1:
http://marc.info/?t=129408118000003&r=1&w=2
and
http://marc.info/?t=129408352700002&r=1&w=2)
Nishanth Menon (5):
omap3|4: mux: make local structures static
omap3: zoom: use static for pointer passing
omap3: igep3: make igep3_flash_init static
omap2+: wdt: trivial sparse fixes
omap2+: pm_bus: make functions used as pointers as static
arch/arm/mach-omap2/board-igep0030.c | 4 ++--
arch/arm/mach-omap2/board-zoom-peripherals.c | 4 ++--
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/mux34xx.c | 4 ++--
arch/arm/mach-omap2/mux44xx.c | 6 +++---
arch/arm/mach-omap2/pm_bus.c | 4 ++--
arch/arm/mach-omap2/wd_timer.c | 2 ++
7 files changed, 14 insertions(+), 12 deletions(-)
---
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/5] omap3|4: mux: make local structures static
From: Nishanth Menon @ 2011-01-04 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294171634-13943-1-git-send-email-nm@ti.com>
Mux data is passed by pointers to mux.c from the SoC specific
mux file, these variables dont really need to be global scope.
This fixes the following sparse warnings:
arch/arm/mach-omap2/mux44xx.c:547:29: warning: symbol 'omap4_core_cbl_ball' was not declared. Should it be static?
arch/arm/mach-omap2/mux44xx.c:1265:29: warning: symbol 'omap4_core_cbs_ball' was not declared. Should it be static?
arch/arm/mach-omap2/mux44xx.c:1549:29: warning: symbol 'omap4_wkup_cbl_cbs_ball' was not declared. Should it be static?
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/mux34xx.c | 4 ++--
arch/arm/mach-omap2/mux44xx.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/mux34xx.c b/arch/arm/mach-omap2/mux34xx.c
index 440c98e..17f80e4 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -703,7 +703,7 @@ static struct omap_mux __initdata omap3_muxmodes[] = {
* Signals different on CBC package compared to the superset
*/
#if defined(CONFIG_OMAP_MUX) && defined(CONFIG_OMAP_PACKAGE_CBC)
-struct omap_mux __initdata omap3_cbc_subset[] = {
+static struct omap_mux __initdata omap3_cbc_subset[] = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
@@ -721,7 +721,7 @@ struct omap_mux __initdata omap3_cbc_subset[] = {
*/
#if defined(CONFIG_OMAP_MUX) && defined(CONFIG_DEBUG_FS) \
&& defined(CONFIG_OMAP_PACKAGE_CBC)
-struct omap_ball __initdata omap3_cbc_ball[] = {
+static struct omap_ball __initdata omap3_cbc_ball[] = {
_OMAP3_BALLENTRY(CAM_D0, "ae16", NULL),
_OMAP3_BALLENTRY(CAM_D1, "ae15", NULL),
_OMAP3_BALLENTRY(CAM_D10, "d25", NULL),
diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
index 980f11d..c322e7b 100644
--- a/arch/arm/mach-omap2/mux44xx.c
+++ b/arch/arm/mach-omap2/mux44xx.c
@@ -544,7 +544,7 @@ static struct omap_mux __initdata omap4_core_muxmodes[] = {
*/
#if defined(CONFIG_OMAP_MUX) && defined(CONFIG_DEBUG_FS) \
&& defined(CONFIG_OMAP_PACKAGE_CBL)
-struct omap_ball __initdata omap4_core_cbl_ball[] = {
+static struct omap_ball __initdata omap4_core_cbl_ball[] = {
_OMAP4_BALLENTRY(GPMC_AD0, "c12", NULL),
_OMAP4_BALLENTRY(GPMC_AD1, "d12", NULL),
_OMAP4_BALLENTRY(GPMC_AD2, "c13", NULL),
@@ -1262,7 +1262,7 @@ static struct omap_mux __initdata omap4_es2_core_muxmodes[] = {
*/
#if defined(CONFIG_OMAP_MUX) && defined(CONFIG_DEBUG_FS) \
&& defined(CONFIG_OMAP_PACKAGE_CBS)
-struct omap_ball __initdata omap4_core_cbs_ball[] = {
+static struct omap_ball __initdata omap4_core_cbs_ball[] = {
_OMAP4_BALLENTRY(GPMC_AD0, "c12", NULL),
_OMAP4_BALLENTRY(GPMC_AD1, "d12", NULL),
_OMAP4_BALLENTRY(GPMC_AD2, "c13", NULL),
@@ -1546,7 +1546,7 @@ static struct omap_mux __initdata omap4_wkup_muxmodes[] = {
*/
#if defined(CONFIG_OMAP_MUX) && defined(CONFIG_DEBUG_FS) \
&& defined(CONFIG_OMAP_PACKAGE_CBL)
-struct omap_ball __initdata omap4_wkup_cbl_cbs_ball[] = {
+static struct omap_ball __initdata omap4_wkup_cbl_cbs_ball[] = {
_OMAP4_BALLENTRY(SIM_IO, "h4", NULL),
_OMAP4_BALLENTRY(SIM_CLK, "j2", NULL),
_OMAP4_BALLENTRY(SIM_RESET, "g2", NULL),
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/5] omap3: zoom: use static for pointer passing
From: Nishanth Menon @ 2011-01-04 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294171634-13943-1-git-send-email-nm@ti.com>
omap_zoom_wlan_data and zoom2_set_hs_extmute are not used beyond
the scope of zoom-peripherals directly, instead pointers are used.
make them static instead.
Fixes sparse warnings:
arch/arm/mach-omap2/board-zoom-peripherals.c:193:29: warning: symbol 'omap_zoom_wlan_data' was not declared. Should it be static?
arch/arm/mach-omap2/board-zoom-peripherals.c:245:6: warning: symbol 'zoom2_set_hs_extmute' was not declared. Should it be static?
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 3fbd0ed..3d1f9ab 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -190,7 +190,7 @@ static struct platform_device omap_vwlan_device = {
},
};
-struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
+static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
.irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
/* ZOOM ref clock is 26 MHz */
.board_ref_clock = 1,
@@ -242,7 +242,7 @@ static int zoom_twl_gpio_setup(struct device *dev,
}
/* EXTMUTE callback function */
-void zoom2_set_hs_extmute(int mute)
+static void zoom2_set_hs_extmute(int mute)
{
gpio_set_value(ZOOM2_HEADSET_EXTMUTE_GPIO, mute);
}
--
1.6.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox