* [PATCH 3/3] ARM: dts: cfa10049: Add PCA9555 GPIO expander to the device tree
From: Maxime Ripard @ 2012-11-08 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352394113-19513-1-git-send-email-maxime.ripard@free-electrons.com>
Add the GPIO expander found on the i2c1 bus, behind the muxer to the
device tree.
This gpio expander will be used to get tachymeters values and data ready
interruptions from the nuvoton NAU7802 ADCs.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/imx28-cfa10049.dts | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index bdc80a4..714953b 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -22,8 +22,9 @@
apb at 80000000 {
apbh at 80000000 {
pinctrl at 80018000 {
- pinctrl-names = "default", "default";
+ pinctrl-names = "default", "default", "default";
pinctrl-1 = <&hog_pins_cfa10049>;
+ pinctrl-2 = <&hog_pins_cfa10049_pullup>;
hog_pins_cfa10049: hog-10049 at 0 {
reg = <0>;
@@ -38,6 +39,16 @@
fsl,pull-up = <0>;
};
+ hog_pins_cfa10049_pullup: hog-10049-pullup at 0 {
+ reg = <0>;
+ fsl,pinmux-ids = <
+ 0x2133 /* MX28_PAD_SSP2_D3__GPIO_2_19 */
+ >;
+ fsl,drive-strength = <0>;
+ fsl,voltage = <1>;
+ fsl,pull-up = <1>;
+ };
+
spi3_pins_cfa10049: spi3-cfa10049 at 0 {
reg = <0>;
fsl,pinmux-ids = <
@@ -113,6 +124,19 @@
i2c@3 {
reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pca9555: pca9555 at 20 {
+ compatible = "nxp,pca9555";
+ interrupt-parent = <&gpio2>;
+ interrupts = <19 0x2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x20>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Hiremath, Vaibhav @ 2012-11-08 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509BDAF5.1010703@ti.com>
On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
>
> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
> > On 11/07/12 23:36, Jon Hunter wrote:
> >> Hi Igor,
> >>
> >> On 11/07/2012 08:42 AM, Igor Grinberg wrote:
> >>> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
> >>> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
> >>> setting.
> >>> To remove the dependancy, several conversions/additions had to be done:
> >>> 1) Timer structures and initialization functions are named by the platform
> >>> name and the clock source in use. The decision which timer is
> >>> used is done statically from the machine_desc structure. In the
> >>> future it should come from DT.
> >>> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
> >>> separate timer structures along with the timer init functions.
> >>> This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
> >>> 3) Since we have all the timers defined inside machine_desc structure
> >>> and we no longer need the fallback to gp_timer clock source in case
> >>> 32k_timer clock source is unavailable (namely on AM33xx), we no
> >>> longer need the #ifdef around __omap2_sync32k_clocksource_init()
> >>> function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
> >>> __omap2_sync32k_clocksource_init() function.
> >>>
> >>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> >>> Cc: Jon Hunter <jon-hunter@ti.com>
> >>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >>> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> >>
> >> [snip]
> >>
> >>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> >>> index 684d2fc..a4ad7a0 100644
> >>> --- a/arch/arm/mach-omap2/timer.c
> >>> +++ b/arch/arm/mach-omap2/timer.c
> >>> @@ -63,20 +63,8 @@
> >>> #define OMAP2_32K_SOURCE "func_32k_ck"
> >>> #define OMAP3_32K_SOURCE "omap_32k_fck"
> >>> #define OMAP4_32K_SOURCE "sys_32k_ck"
> >>> -
> >>> -#ifdef CONFIG_OMAP_32K_TIMER
> >>> -#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
> >>> -#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
> >>> -#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
> >>> -#define OMAP3_SECURE_TIMER 12
> >>> #define TIMER_PROP_SECURE "ti,timer-secure"
> >>> -#else
> >>> -#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
> >>> -#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
> >>> -#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
> >>> -#define OMAP3_SECURE_TIMER 1
> >>> -#define TIMER_PROP_SECURE "ti,timer-alwon"
> >>> -#endif
> >>> +#define TIMER_PROP_ALWON "ti,timer-alwon"
> >>
> >> Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
> >> "ti,timer-secure" and "ti,timer-alwon" directly?
> >>
> >> Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
> >> was to drop this and use the property string directly to remove any
> >> abstraction.
> >
> > Well, I don't understand what do you mean by "any abstraction".
> > The purpose of defining those two was to eliminate multiple occurrences
> > of the string in the code, so for example if someone decides to change the
> > property string for some currently unknown reason - it will be easy and small.
> > Defines are a common practice for that, no?
> > If you still think it should be inlined, I will do.
>
> I understand your point, but right now I don't anticipate that we will
> have many options here and so I think that we should drop these.
>
> >>> #define REALTIME_COUNTER_BASE 0x48243200
> >>> #define INCREMENTER_NUMERATOR_OFFSET 0x10
> >>> @@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
> >>>
> >>> /* If we are a secure device, remove any secure timer nodes */
> >>> if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
> >>> - np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
> >>> + np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
> >>> if (np)
> >>> of_node_put(np);
> >>> }
> >>> @@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
> >>> return 0;
> >>> }
> >>>
> >>> -#ifdef CONFIG_OMAP_32K_TIMER
> >>> /* Setup free-running counter for clocksource */
> >>> -static int __init omap2_sync32k_clocksource_init(void)
> >>> +static int __init __omap2_sync32k_clocksource_init(void)
> >>
> >> Not sure I follow why you renamed this function here ...
> >
> > I didn't want to add unused arguments to this function, so I've made a
> > wrapper below to have both the sync32k and the gp functions have the same
> > signature (argument list) and be called from a single macro.
> > Anyway, see below.
>
> Ok.
>
> >>
> >>> {
> >>> int ret;
> >>> struct device_node *np = NULL;
> >>> @@ -439,15 +426,9 @@ static int __init omap2_sync32k_clocksource_init(void)
> >>>
> >>> return ret;
> >>> }
> >>> -#else
> >>> -static inline int omap2_sync32k_clocksource_init(void)
> >>> -{
> >>> - return -ENODEV;
> >>> -}
> >>> -#endif
> >>>
> >>> -static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> >>> - const char *fck_source)
> >>> +static void __init omap2_gp_clocksource_init(int gptimer_id,
> >>> + const char *fck_source)
> >>
> >> Nit, I personally prefer keeping gptimer, because gp just means
> >> "general-purpose" and does not imply a timer per-se.
> >
> > I've made this change, so we will not get something like:
> > omapx_gptimer_timer_init(), but this really does not meter to me,
> > so no problem will do for v2.
>
> Thanks.
>
> >>
> >>> {
> >>> int res;
> >>>
> >>> @@ -466,23 +447,10 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> >>> gptimer_id, clksrc.rate);
> >>> }
> >>>
> >>> -static void __init omap2_clocksource_init(int gptimer_id,
> >>> - const char *fck_source)
> >>> +static void __init omap2_sync32k_clocksource_init(int gptimer_id,
> >>> + const char *fck_source)
> >>> {
> >>> - /*
> >>> - * First give preference to kernel parameter configuration
> >>> - * by user (clocksource="gp_timer").
> >>> - *
> >>> - * In case of missing kernel parameter for clocksource,
> >>> - * first check for availability for 32k-sync timer, in case
> >>> - * of failure in finding 32k_counter module or registering
> >>> - * it as clocksource, execution will fallback to gp-timer.
> >>> - */
> >>> - if (use_gptimer_clksrc == true)
> >>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
> >>> - else if (omap2_sync32k_clocksource_init())
> >>> - /* Fall back to gp-timer code */
> >>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
> >>> + __omap2_sync32k_clocksource_init();
> >>> }
> >>
> >> ... this just appears to be a wrapper function, but I don't see why this
> >> is needed? Do we need this wrapper?
> >
> > no, not really, just consider the explanation above.
> > I will remove the wrapper for v2.
>
> Ok, thanks.
>
> >>
> >>> #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
> >>> @@ -563,52 +531,64 @@ static inline void __init realtime_counter_init(void)
> >>> {}
> >>> #endif
> >>>
> >>> -#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
> >>> - clksrc_nr, clksrc_src) \
> >>> -static void __init omap##name##_timer_init(void) \
> >>> +#define OMAP_SYS_TIMER_INIT(n, clksrc_name, clkev_nr, clkev_src, \
> >>> + clkev_prop, clksrc_nr, clksrc_src) \
> >>> +static void __init omap##n##_##clksrc_name##_timer_init(void) \
> >>
> >>
> >>> { \
> >>> omap_dmtimer_init(); \
> >>> omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop); \
> >>> - omap2_clocksource_init((clksrc_nr), clksrc_src); \
> >>> + \
> >>> + if (use_gptimer_clksrc) \
> >>> + omap2_gp_clocksource_init((clksrc_nr), clksrc_src); \
> >>> + else \
> >>> + omap2_##clksrc_name##_clocksource_init((clksrc_nr), \
> >>> + clksrc_src); \
> >>
> >> Something here seems a little odd. If "clksrc_name" is "gp", then the
> >> if-else parts will call the same function. Or am I missing something here?
> >
> > Yes, you are right - this is odd.
> > What do you think of:
> >
> > if (use_gptimer_clksrc) {
> > omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
> > return;
> > }
> > omap2_##clksrc_name##_clocksource_init((clksrc_nr), clksrc_src);
>
> Yes, but it still seems a little odd that we could have ...
>
> if (use_gptimer_clksrc) {
> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
> return;
> }
> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
>
> >>
> >> I think that I prefer how it works today where we call just
> >> omap2_clocksource_init(), and it determines whether to use the gptimer
> >> or the 32k-sync.
> >
> > There is no reliable way to determine which source should be used in runtime
> > for boards that do not have the 32k oscillator wired.
>
> Hmmm ... well for OMAP devices the 32kHz clock is mandatory AFAIK. At
> least for OMAP devices and I would need to check on the AM33xx but I
> would imagine they are the same. Which devices are you referring to
> where the 32kHz is optional?
>
No we do not have 32k_counter block in AM335x.
If you are referring to 32Khz clock availability alone, then yes, we need to
get persistent clock and we use RTC 32Khz clock source for it.
But please note that this is not a 32k_counter block which OMAP family of
devices has.
The way AM335x works is, we have timers (0-7), timer0 being secure timer.
We use timer1 and timer2 for clockevent and clocksource and they are driven
by 26MHz OSC clock currently. So when you go into Low power state, OSC is turned off and you need persistent clock for time keeping, right?
And only persistent clock available is RTC 32khz crystal clock, being RTC is
in wakeup domain.
Thanks,
Vaibhav
> >> For OMAP I think that it is fine to default to the 32k-sync and then if
> >> the gptimer is selected, it uses the higher frequency sys_clk as the
> >> timer source.
> >
> > I agree for the 32k-sync as a default, but gptimer will not be selected
> > on SoC that have 32k while board does not have the 32k wired.
>
> Ok, again let me know which device(s) this applies too.
>
> >>
> >> For AMxxx, devices, sync-32k does not exist, and so I understand it does
> >> not work the same.
> >>
> >> I am wondering if the use_gptimer_clksrc, should become
> >> use_sysclk_clksrc, and then ...
> >>
> >> For OMAP ...
> >> use_sysclk_clksrc = 0 --> use sync-32k (default)
> >> use_sysclk_clksrc = 1 --> use gptimer with sys_clk
> >>
> >> For AM33xx ...
> >> use_sysclk_clksrc = 0 --> use gptimer with 32khz clock (default)
> >> use_sysclk_clksrc = 1 --> use gptimer with sys_clk
> >
> > Well, this is more or less how it works today, but it does not consider
> > the board wiring information that after all defines which source should
> > be used. (Not all boards out there are clones of beagles and evms...)
> > And the generic code should be flexible enough
> > to enable any legal configuration.
>
> My whole thought here was that the 32kHz is always present. If that is
> not the case then I would agree this would not work.
>
> >>
> >>> }
> >>>
> >>> -#define OMAP_SYS_TIMER(name) \
> >>> -struct sys_timer omap##name##_timer = { \
> >>> - .init = omap##name##_timer_init, \
> >>> -};
> >>> +#define OMAP_SYS_TIMER(n, clksrc) \
> >>> +struct sys_timer omap##n##_##clksrc##_timer = { \
> >>> + .init = omap##n##_##clksrc##_timer_init, \
> >>> +}
> >>>
> >>> #ifdef CONFIG_ARCH_OMAP2
> >>> -OMAP_SYS_TIMER_INIT(2, 1, OMAP2_CLKEV_SOURCE, "ti,timer-alwon",
> >>> - 2, OMAP2_MPU_SOURCE)
> >>> -OMAP_SYS_TIMER(2)
> >>> +OMAP_SYS_TIMER_INIT(2, sync32k, 1, OMAP2_32K_SOURCE, TIMER_PROP_ALWON,
> >>> + 2, OMAP2_MPU_SOURCE);
> >>> +OMAP_SYS_TIMER(2, sync32k);
> >>> +OMAP_SYS_TIMER_INIT(2, gp, 1, OMAP2_MPU_SOURCE, TIMER_PROP_ALWON,
> >>> + 2, OMAP2_MPU_SOURCE);
> >>> +OMAP_SYS_TIMER(2, gp);
> >>
> >> It would be good if we can avoid having two timer_init functions for
> >> each OMAP generation.
> >
> > Yes, but then we will not have the right description of the hardware
> > but IMHO workarounds on workarounds on...
> >
> > There are several clock sources - all can be used,
> > why not have them described and ready for use?
>
> Well we really want to simplify this code and so I was thinking that if
> a device has a 32k-sync timer AND there is a 32kHz source, then what's
> the point in having an option to use a gptimer with a 32kHz source for
> that device? I guess I don't see the benefit there, at least for OMAP2-5
> devices specifically.
>
> Cheers
> Jon
>
>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Hiremath, Vaibhav @ 2012-11-08 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121108162004.GA6801@atomide.com>
On Thu, Nov 08, 2012 at 21:50:05, Tony Lindgren wrote:
> * Igor Grinberg <grinberg@compulab.co.il> [121107 23:15]:
> > On 11/07/12 19:33, Tony Lindgren wrote:
> > >
> > > I think this should be the default for the timers as that counter
> > > does not stop during deeper idle states.
> >
> > Well, it is the default as you can see from the patch.
> > The problem is that for boards that for some reason do not have
> > the 32k wired and rely on MPU/GP timer source, the default will not work
> > and currently there is no way for board to specify which timer source
> > it can use.
>
> Yes. I was just wondering if we can avoid patching all the board
> files by doing it the other way around by introducing a new
> omap_gp_timer rather than renaming all the existing ones?
>
> > We have discussed this in San Diego (remember?) and you actually proposed
> > this way as a solution. Well, may be I took it a bit further than you
> > thought, but this is because the board code cannot know which timer source
> > should be used at runtime and the fall back described below, does not work.
>
> Yes thanks I agree we should get rid of that Kconfig option for sure.
>
> > >> --- a/arch/arm/mach-omap2/board-2430sdp.c
> > >> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> > >> @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
> > >> .handle_irq = omap2_intc_handle_irq,
> > >> .init_machine = omap_2430sdp_init,
> > >> .init_late = omap2430_init_late,
> > >> - .timer = &omap2_timer,
> > >> + .timer = &omap2_sync32k_timer,
> > >> .restart = omap_prcm_restart,
> > >> MACHINE_END
> > >> --- a/arch/arm/mach-omap2/board-3430sdp.c
> > >> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> > >> @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board")
> > >> .handle_irq = omap3_intc_handle_irq,
> > >> .init_machine = omap_3430sdp_init,
> > >> .init_late = omap3430_init_late,
> > >> - .timer = &omap3_timer,
> > >> + .timer = &omap3_sync32k_timer,
> > >> .restart = omap_prcm_restart,
> > >> MACHINE_END
> > > ...
> > >
> > > Can't we assume that the default timer is omap[234]_sync32k_timer to
> > > avoid renaming the timer entries in all the board files?
> >
> > Hmmm...
> > How will this work with the macros defining the sys_timer structure?
> > I would also not want to hide the exact timer used under the default name.
>
> Can't you just add a new sys_timer (or a new macro) for GP only setups?
>
> > > Then we just need a new timer entries for the hardware that does
> > > not have the sycn32k_timer available?
> >
> > Well, I tried to make it small patch just for the hardware that needs it,
> > but I always found some corner case where, IMHO, this does not work/look good.
>
> Can you explain a bit further?
>
> I guess what I'm after is just to avoid renaming the existing
> timers in the board-*.c files and only rename the ones that
> need gp timer only.
>
That would be AM33xx family :)
Thanks,
Vaibhav
> Regards,
>
> Tony
>
^ permalink raw reply
* [PATCH 2/2] pinctrl/nomadik: make independent of prcmu driver
From: Stephen Warren @ 2012-11-08 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352375742-29611-1-git-send-email-linus.walleij@stericsson.com>
On 11/08/2012 04:55 AM, Linus Walleij wrote:
> From: Jonas Aaberg <jonas.aberg@stericsson.com>
>
> Currently there are some unnecessary criss-cross
> dependencies between the PRCMU driver in MFD and a lot of
> other drivers, mainly because other drivers need to poke
> around in the PRCM register range.
>
> In cases like this there are actually just a few select
> registers that the pinctrl driver need to read/modify/write,
> and it turns out that no other driver is actually using
> these registers, so there are no concurrency issues
> whatsoever.
>
> So: don't let the location of the register range complicate
> things, just poke into these registers directly and skip
> a layer of indirection.
Do you actually need to store the run-time data in struct
nmk_pinctrl_soc_data too? I would have expected all the soc_data
pointers to remain const, and to store the runtime register pointer
somewhere else, and perhaps pass it as a separate parameter to the
relevant init functions; wouldn't that make the patch much smaller?
^ permalink raw reply
* [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
From: Jon Hunter @ 2012-11-08 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107234403.GS6801@atomide.com>
On 11/07/2012 05:44 PM, Tony Lindgren wrote:
> Hi Jon,
>
> * Tony Lindgren <tony@atomide.com> [121106 16:48]:
>> * Jon Hunter <jon-hunter@ti.com> [121102 12:01]:
>>>
>>> git at github.com:jonhunter/linux.git dev-dt-timer
>>
>> Thanks pulling into omap-for-v3.8/dt branch.
>
> Looks like omap-for-v3.8/dt boots OK on blaze when booted
> with device tree, but then current omap-for-v3.8/tmp-merge
> oopses.
That's a bugger. I completely missed your patch last week sorry (I will blame the Danish
beer) and had clearly not folded in to my testing!
> I guess we should apply the following fix somewhere or
> do we need to check other places too?
I will re-test your master branch today and put it through my dmtimer tests to double check.
However, in general I did ensure that we checked pdata was not NULL before accessing when
I introduced the dt stuff. In my changelog [1] I had ...
"5. When device-tree is present the platform_data structure will be NULL and so check for
this."
I just need to make sure that get_context_loss_count() is not called before checking it is
populated.
> Regards,
>
> Tony
>
> [<c04e3d30>] (omap_dm_timer_probe+0x110/0x310) from [<c0334a18>] (platform_drv_probe+0x1c/0x24)
> [<c0334a18>] (platform_drv_probe+0x1c/0x24) from [<c03335d4>] (really_probe+0x60/0x1f4)
> [<c03335d4>] (really_probe+0x60/0x1f4) from [<c033379c>] (driver_probe_device+0x34/0x50)
> [<c033379c>] (driver_probe_device+0x34/0x50) from [<c033384c>] (__driver_attach+0x94/0x98)
> [<c033384c>] (__driver_attach+0x94/0x98) from [<c0331df8>] (bus_for_each_dev+0x60/0x8c)
> [<c0331df8>] (bus_for_each_dev+0x60/0x8c) from [<c03326c4>] (bus_add_driver+0x18c/0x254)
> [<c03326c4>] (bus_add_driver+0x18c/0x254) from [<c0333e44>] (driver_register+0x5c/0x150)
> [<c0333e44>] (driver_register+0x5c/0x150) from [<c0008868>] (do_one_initcall+0x2c/0x178)
> [<c0008868>] (do_one_initcall+0x2c/0x178) from [<c06df2a0>] (do_basic_setup+0x94/0xd0)
> [<c06df2a0>] (do_basic_setup+0x94/0xd0) from [<c06df358>] (kernel_init_freeable+0x7c/0x124)
> [<c06df358>] (kernel_init_freeable+0x7c/0x124) from [<c04e1810>] (kernel_init+0x8/0x1a8)
> [<c04e1810>] (kernel_init+0x8/0x1a8) from [<c0014410>] (ret_from_fork+0x14/0x24)
>
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -803,8 +803,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
>
> timer->irq = irq->start;
> timer->pdev = pdev;
> - timer->capability = pdata->timer_capability;
> - timer->get_context_loss_count = pdata->get_context_loss_count;
> +
> + if (pdata) {
> + timer->capability = pdata->timer_capability;
You don't need this it is already handled a few lines before.
> + timer->get_context_loss_count = pdata->get_context_loss_count;
We could probably move this too. For example ...
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 38c12ef..9dca23e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
timer->id = pdev->id;
timer->capability = pdata->timer_capability;
timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
+ timer->get_context_loss_count = pdata->get_context_loss_count;
}
timer->irq = irq->start;
timer->pdev = pdev;
- timer->capability = pdata->timer_capability;
- timer->get_context_loss_count = pdata->get_context_loss_count;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
Cheers
Jon
[1] http://marc.info/?l=linux-omap&m=135065877008624&w=2
^ permalink raw reply related
* [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
From: Tony Lindgren @ 2012-11-08 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509BE9B0.5040608@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121108 09:21]:
>
> On 11/07/2012 05:44 PM, Tony Lindgren wrote:
>
> That's a bugger. I completely missed your patch last week sorry (I will blame the Danish
> beer) and had clearly not folded in to my testing!
:)
> > I guess we should apply the following fix somewhere or
> > do we need to check other places too?
>
> I will re-test your master branch today and put it through my dmtimer tests to double check.
> However, in general I did ensure that we checked pdata was not NULL before accessing when
> I introduced the dt stuff. In my changelog [1] I had ...
>
> "5. When device-tree is present the platform_data structure will be NULL and so check for
> this."
>
> I just need to make sure that get_context_loss_count() is not called before checking it is
> populated.
OK
> > +
> > + if (pdata) {
> > + timer->capability = pdata->timer_capability;
>
> You don't need this it is already handled a few lines before.
>
> > + timer->get_context_loss_count = pdata->get_context_loss_count;
>
> We could probably move this too. For example ...
OK yeah makes sense to me.
Regards,
Tony
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index 38c12ef..9dca23e 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
> timer->id = pdev->id;
> timer->capability = pdata->timer_capability;
> timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
> + timer->get_context_loss_count = pdata->get_context_loss_count;
> }
>
> timer->irq = irq->start;
> timer->pdev = pdev;
> - timer->capability = pdata->timer_capability;
> - timer->get_context_loss_count = pdata->get_context_loss_count;
>
> /* Skip pm_runtime_enable for OMAP1 */
> if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
>
> Cheers
> Jon
>
> [1] http://marc.info/?l=linux-omap&m=135065877008624&w=2
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-08 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB68589@DBDE01.ent.ti.com>
On 11/08/2012 11:08 AM, Hiremath, Vaibhav wrote:
> On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
>>
>> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
>>> On 11/07/12 23:36, Jon Hunter wrote:
>>>> Hi Igor,
>>>>
>>>> On 11/07/2012 08:42 AM, Igor Grinberg wrote:
>>>>> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
>>>>> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
>>>>> setting.
>>>>> To remove the dependancy, several conversions/additions had to be done:
>>>>> 1) Timer structures and initialization functions are named by the platform
>>>>> name and the clock source in use. The decision which timer is
>>>>> used is done statically from the machine_desc structure. In the
>>>>> future it should come from DT.
>>>>> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
>>>>> separate timer structures along with the timer init functions.
>>>>> This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
>>>>> 3) Since we have all the timers defined inside machine_desc structure
>>>>> and we no longer need the fallback to gp_timer clock source in case
>>>>> 32k_timer clock source is unavailable (namely on AM33xx), we no
>>>>> longer need the #ifdef around __omap2_sync32k_clocksource_init()
>>>>> function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
>>>>> __omap2_sync32k_clocksource_init() function.
>>>>>
>>>>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
>>>>> Cc: Jon Hunter <jon-hunter@ti.com>
>>>>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>>> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
>>>>
>>>> [snip]
>>>>
>>>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>>>> index 684d2fc..a4ad7a0 100644
>>>>> --- a/arch/arm/mach-omap2/timer.c
>>>>> +++ b/arch/arm/mach-omap2/timer.c
>>>>> @@ -63,20 +63,8 @@
>>>>> #define OMAP2_32K_SOURCE "func_32k_ck"
>>>>> #define OMAP3_32K_SOURCE "omap_32k_fck"
>>>>> #define OMAP4_32K_SOURCE "sys_32k_ck"
>>>>> -
>>>>> -#ifdef CONFIG_OMAP_32K_TIMER
>>>>> -#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
>>>>> -#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
>>>>> -#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
>>>>> -#define OMAP3_SECURE_TIMER 12
>>>>> #define TIMER_PROP_SECURE "ti,timer-secure"
>>>>> -#else
>>>>> -#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
>>>>> -#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
>>>>> -#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
>>>>> -#define OMAP3_SECURE_TIMER 1
>>>>> -#define TIMER_PROP_SECURE "ti,timer-alwon"
>>>>> -#endif
>>>>> +#define TIMER_PROP_ALWON "ti,timer-alwon"
>>>>
>>>> Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
>>>> "ti,timer-secure" and "ti,timer-alwon" directly?
>>>>
>>>> Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
>>>> was to drop this and use the property string directly to remove any
>>>> abstraction.
>>>
>>> Well, I don't understand what do you mean by "any abstraction".
>>> The purpose of defining those two was to eliminate multiple occurrences
>>> of the string in the code, so for example if someone decides to change the
>>> property string for some currently unknown reason - it will be easy and small.
>>> Defines are a common practice for that, no?
>>> If you still think it should be inlined, I will do.
>>
>> I understand your point, but right now I don't anticipate that we will
>> have many options here and so I think that we should drop these.
>>
>>>>> #define REALTIME_COUNTER_BASE 0x48243200
>>>>> #define INCREMENTER_NUMERATOR_OFFSET 0x10
>>>>> @@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
>>>>>
>>>>> /* If we are a secure device, remove any secure timer nodes */
>>>>> if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
>>>>> - np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
>>>>> + np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
>>>>> if (np)
>>>>> of_node_put(np);
>>>>> }
>>>>> @@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> -#ifdef CONFIG_OMAP_32K_TIMER
>>>>> /* Setup free-running counter for clocksource */
>>>>> -static int __init omap2_sync32k_clocksource_init(void)
>>>>> +static int __init __omap2_sync32k_clocksource_init(void)
>>>>
>>>> Not sure I follow why you renamed this function here ...
>>>
>>> I didn't want to add unused arguments to this function, so I've made a
>>> wrapper below to have both the sync32k and the gp functions have the same
>>> signature (argument list) and be called from a single macro.
>>> Anyway, see below.
>>
>> Ok.
>>
>>>>
>>>>> {
>>>>> int ret;
>>>>> struct device_node *np = NULL;
>>>>> @@ -439,15 +426,9 @@ static int __init omap2_sync32k_clocksource_init(void)
>>>>>
>>>>> return ret;
>>>>> }
>>>>> -#else
>>>>> -static inline int omap2_sync32k_clocksource_init(void)
>>>>> -{
>>>>> - return -ENODEV;
>>>>> -}
>>>>> -#endif
>>>>>
>>>>> -static void __init omap2_gptimer_clocksource_init(int gptimer_id,
>>>>> - const char *fck_source)
>>>>> +static void __init omap2_gp_clocksource_init(int gptimer_id,
>>>>> + const char *fck_source)
>>>>
>>>> Nit, I personally prefer keeping gptimer, because gp just means
>>>> "general-purpose" and does not imply a timer per-se.
>>>
>>> I've made this change, so we will not get something like:
>>> omapx_gptimer_timer_init(), but this really does not meter to me,
>>> so no problem will do for v2.
>>
>> Thanks.
>>
>>>>
>>>>> {
>>>>> int res;
>>>>>
>>>>> @@ -466,23 +447,10 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
>>>>> gptimer_id, clksrc.rate);
>>>>> }
>>>>>
>>>>> -static void __init omap2_clocksource_init(int gptimer_id,
>>>>> - const char *fck_source)
>>>>> +static void __init omap2_sync32k_clocksource_init(int gptimer_id,
>>>>> + const char *fck_source)
>>>>> {
>>>>> - /*
>>>>> - * First give preference to kernel parameter configuration
>>>>> - * by user (clocksource="gp_timer").
>>>>> - *
>>>>> - * In case of missing kernel parameter for clocksource,
>>>>> - * first check for availability for 32k-sync timer, in case
>>>>> - * of failure in finding 32k_counter module or registering
>>>>> - * it as clocksource, execution will fallback to gp-timer.
>>>>> - */
>>>>> - if (use_gptimer_clksrc == true)
>>>>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
>>>>> - else if (omap2_sync32k_clocksource_init())
>>>>> - /* Fall back to gp-timer code */
>>>>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
>>>>> + __omap2_sync32k_clocksource_init();
>>>>> }
>>>>
>>>> ... this just appears to be a wrapper function, but I don't see why this
>>>> is needed? Do we need this wrapper?
>>>
>>> no, not really, just consider the explanation above.
>>> I will remove the wrapper for v2.
>>
>> Ok, thanks.
>>
>>>>
>>>>> #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
>>>>> @@ -563,52 +531,64 @@ static inline void __init realtime_counter_init(void)
>>>>> {}
>>>>> #endif
>>>>>
>>>>> -#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
>>>>> - clksrc_nr, clksrc_src) \
>>>>> -static void __init omap##name##_timer_init(void) \
>>>>> +#define OMAP_SYS_TIMER_INIT(n, clksrc_name, clkev_nr, clkev_src, \
>>>>> + clkev_prop, clksrc_nr, clksrc_src) \
>>>>> +static void __init omap##n##_##clksrc_name##_timer_init(void) \
>>>>
>>>>
>>>>> { \
>>>>> omap_dmtimer_init(); \
>>>>> omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop); \
>>>>> - omap2_clocksource_init((clksrc_nr), clksrc_src); \
>>>>> + \
>>>>> + if (use_gptimer_clksrc) \
>>>>> + omap2_gp_clocksource_init((clksrc_nr), clksrc_src); \
>>>>> + else \
>>>>> + omap2_##clksrc_name##_clocksource_init((clksrc_nr), \
>>>>> + clksrc_src); \
>>>>
>>>> Something here seems a little odd. If "clksrc_name" is "gp", then the
>>>> if-else parts will call the same function. Or am I missing something here?
>>>
>>> Yes, you are right - this is odd.
>>> What do you think of:
>>>
>>> if (use_gptimer_clksrc) {
>>> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
>>> return;
>>> }
>>> omap2_##clksrc_name##_clocksource_init((clksrc_nr), clksrc_src);
>>
>> Yes, but it still seems a little odd that we could have ...
>>
>> if (use_gptimer_clksrc) {
>> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
>> return;
>> }
>> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
>>
>>>>
>>>> I think that I prefer how it works today where we call just
>>>> omap2_clocksource_init(), and it determines whether to use the gptimer
>>>> or the 32k-sync.
>>>
>>> There is no reliable way to determine which source should be used in runtime
>>> for boards that do not have the 32k oscillator wired.
>>
>> Hmmm ... well for OMAP devices the 32kHz clock is mandatory AFAIK. At
>> least for OMAP devices and I would need to check on the AM33xx but I
>> would imagine they are the same. Which devices are you referring to
>> where the 32kHz is optional?
>>
> No we do not have 32k_counter block in AM335x.
I am painfully aware of that :-)
> If you are referring to 32Khz clock availability alone, then yes, we need to
> get persistent clock and we use RTC 32Khz clock source for it.
> But please note that this is not a 32k_counter block which OMAP family of
> devices has.
>
> The way AM335x works is, we have timers (0-7), timer0 being secure timer.
> We use timer1 and timer2 for clockevent and clocksource and they are driven
> by 26MHz OSC clock currently. So when you go into Low power state, OSC is turned off and you need persistent clock for time keeping, right?
>
> And only persistent clock available is RTC 32khz crystal clock, being RTC is
> in wakeup domain.
I think you are missing the point here. For OMAP devices we have two
main external clock sources which are the 32kHz clock and the sys_clk
(can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
for OMAP these clock sources are always present and AFAIK there is no
h/w configuration that allows you not to have the 32kHz clock source.
PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
serves).
Igor was mentioning a h/w scenario where the 32kHz source is not
present. However, I am not sure which devices support this and is
applicable too.
So we are not discussing the 32k-sync-timer here. We are discussing
whether there are any device configurations where a 32k clock source
would not be available for the gptimer.
Jon
^ permalink raw reply
* How does atomic operation work on smp
From: anish kumar @ 2012-11-08 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107164507.GA3571@opentech.at>
On Wed, 2012-11-07 at 17:45 +0100, Nicholas Mc Guire wrote:
> On Wed, 07 Nov 2012, Hendrik Visage wrote:
>
> > On Thu, Nov 8, 2012 at 9:01 AM, Jimmy Pan <dspjmt@gmail.com> wrote:
> > > I understand how atomic operation work on unary core processors, I think it just disables the interrupt and dominate the cpu until it finished.
>
> Atomic operations do not need to disable interrupts - a test-and-set operation does not disable interrupts. Locking primitives like spin-locks that allow you to get consistent access to non-atomic critical sections may disable interrupts.
>
> It seems to me that you are identifying atomic operations with critical sections, which is not really the same thing - but maybe I missunderstood you.
>
> > > While, how do we implement this on multi processor computers?
> > > Suppose cpu A is performing an atomic operation on variable a. At the same time, cpu B is also performing the operation on a. In such the result may be overwritten.
> > > Of course we can use spinlocks, but on the atomic operation's behalf, how does it gurantee to prevent such case?
> > > Can anyone explain the crux of it? Thanks.
> >
> > Basically you make use of machine specific instructions that will do
> > that for you.
> > In other words, get the datasheets of the specific system you intent
> > to code on/for (I assume here you are refering to assembler level
> > codes, as higher up you make use of the relevant libraries that does
> > that for you).
> >
>
> More or less any (sane) architecture will provide some very basic atoicity
Architecture provides minimum atomicity in the form of assembly
instructions.So below is the code of how in arm atomic_add() is
implemented which is SMP safe,
/*
* ARMv6 UP and SMP safe atomic ops. We use load exclusive and
* store exclusive to ensure that these are atomic. We may loop
* to ensure that the update happens.
*/
static inline void atomic_add(int i, atomic_t *v)
{
__asm__ __volatile__("@ atomic_add\n"
"1: ldrex %0, [%3]\n"
" add %0, %0, %4\n"
" strex %1, %0, [%3]\n"
" teq %1, #0\n"
" bne 1b"
: "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
: "r" (&v->counter), "Ir" (i)
: "cc");
}
Above function is SMP safe(but sometimes this also needs memory barrier
(/Documentation/memory-barriers.txt-ATOMIC OPERATIONS) and be careful
with the name of the functions as atomic in the function name doesn't
guaranty anything as below:
CPU 1 CPU 2
=============== ===============
x = 0; y = x;
atomic_add_return(x)
what do you think would be the value of y in CPU2?Legally it can have
any value i.e. 0 or 1 as CPU1 can reorder the instructions any time(when
does it see fit to reorder?).However if atomic_add_return is implemented
with explicit memory barriers then it wouldn't happen and you will see a
correct result as below:
CPU 1 CPU 2
=============== ===============
x = 0;
atomic_add_return(x)
y = x; //x will be 1 here
>From arch/arm/include/asm/atomic.h
static inline int atomic_add_return(int i, atomic_t *v)
{
smp_mb(); <BARRIER HERE>
__asm__ __volatile__("@ atomic_add_return\n"
"1: ldrex %0, [%3]\n"
" add %0, %0, %4\n"
" strex %1, %0, [%3]\n"
" teq %1, #0\n"
" bne 1b"
: "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
: "r" (&v->counter), "Ir" (i)
: "cc");
smp_mb(); <BARRIER HERE>
}
so atomic variable is just like any other variable except it comes with
some set of operations which combined with barriers make it really
_atomic_.
> capabilities. a 32bit (or 64bit on 64bit boxes) data object is guaranteed
> to be consistent (that is you will never be able to get half of the old and
> half of the new value if there were a concurrent read and write). Some form
> of Compare and Swap (CAS) / Test and Set bit assembler instructuion will be
> provided that can overcome the lowest level race that would be incured by
> setting and then testing in separate steps. And finally low level
> mechanisms are provided to ensure consistency over cores by load/store
> fences (memory barriers).
>
> In the above case where you have a concurrent reader and writer of variable
> "a" you do not need any lock provided the data object is only a single 32/64
> bit object - if it is say a struct then you need locking to ensure consistency
> of the retrieved data. The atomic instructions are then actually only needed
> for the locks (but note that locks here are pure advisory locks not enforced
> in any way by HW).
>
> so if you have a writer updating a variable and a reader reading it concurently
> then the reader is guaranteed to always read a consistent 32bit (or 64bit)
> entity - but it is not guaranteed of course that you actually read all
> intermediate values (that is completness is not guaranteed). If the variable
> is more than a primitive data object then you need to protect it by associating
> a lock with the data object (always lock data not code...)
>
>
> thx!
> hofrat
> --
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Xen-devel] BUG: ARM build failures due to Xen
From: Arnd Bergmann @ 2012-11-08 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1211081554220.2689@kaball.uk.xensource.com>
On Thursday 08 November 2012, Stefano Stabellini wrote:
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> xen/arm: Fix compile errors when drivers are compiled as modules.
>
> We end up with:
>
> ERROR: "HYPERVISOR_event_channel_op" [drivers/xen/xen-gntdev.ko] undefined!
> ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined!
> ERROR: "HYPERVISOR_grant_table_op" [drivers/net/xen-netback/xen-netback.ko] undefined!
>
> and this patch exports said function (which is implemented in hypercall.S).
>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
I guess it's best to merge that through the Xen tree.
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Hiremath, Vaibhav @ 2012-11-08 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509BEE6D.9000902@ti.com>
On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
>
> On 11/08/2012 11:08 AM, Hiremath, Vaibhav wrote:
> > On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
> >>
> >> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
> >>> On 11/07/12 23:36, Jon Hunter wrote:
> >>>> Hi Igor,
> >>>>
> >>>> On 11/07/2012 08:42 AM, Igor Grinberg wrote:
> >>>>> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
> >>>>> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
> >>>>> setting.
> >>>>> To remove the dependancy, several conversions/additions had to be done:
> >>>>> 1) Timer structures and initialization functions are named by the platform
> >>>>> name and the clock source in use. The decision which timer is
> >>>>> used is done statically from the machine_desc structure. In the
> >>>>> future it should come from DT.
> >>>>> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
> >>>>> separate timer structures along with the timer init functions.
> >>>>> This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
> >>>>> 3) Since we have all the timers defined inside machine_desc structure
> >>>>> and we no longer need the fallback to gp_timer clock source in case
> >>>>> 32k_timer clock source is unavailable (namely on AM33xx), we no
> >>>>> longer need the #ifdef around __omap2_sync32k_clocksource_init()
> >>>>> function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
> >>>>> __omap2_sync32k_clocksource_init() function.
> >>>>>
> >>>>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> >>>>> Cc: Jon Hunter <jon-hunter@ti.com>
> >>>>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >>>>> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> >>>>
> >>>> [snip]
> >>>>
> >>>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> >>>>> index 684d2fc..a4ad7a0 100644
> >>>>> --- a/arch/arm/mach-omap2/timer.c
> >>>>> +++ b/arch/arm/mach-omap2/timer.c
> >>>>> @@ -63,20 +63,8 @@
> >>>>> #define OMAP2_32K_SOURCE "func_32k_ck"
> >>>>> #define OMAP3_32K_SOURCE "omap_32k_fck"
> >>>>> #define OMAP4_32K_SOURCE "sys_32k_ck"
> >>>>> -
> >>>>> -#ifdef CONFIG_OMAP_32K_TIMER
> >>>>> -#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
> >>>>> -#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
> >>>>> -#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
> >>>>> -#define OMAP3_SECURE_TIMER 12
> >>>>> #define TIMER_PROP_SECURE "ti,timer-secure"
> >>>>> -#else
> >>>>> -#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
> >>>>> -#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
> >>>>> -#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
> >>>>> -#define OMAP3_SECURE_TIMER 1
> >>>>> -#define TIMER_PROP_SECURE "ti,timer-alwon"
> >>>>> -#endif
> >>>>> +#define TIMER_PROP_ALWON "ti,timer-alwon"
> >>>>
> >>>> Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
> >>>> "ti,timer-secure" and "ti,timer-alwon" directly?
> >>>>
> >>>> Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
> >>>> was to drop this and use the property string directly to remove any
> >>>> abstraction.
> >>>
> >>> Well, I don't understand what do you mean by "any abstraction".
> >>> The purpose of defining those two was to eliminate multiple occurrences
> >>> of the string in the code, so for example if someone decides to change the
> >>> property string for some currently unknown reason - it will be easy and small.
> >>> Defines are a common practice for that, no?
> >>> If you still think it should be inlined, I will do.
> >>
> >> I understand your point, but right now I don't anticipate that we will
> >> have many options here and so I think that we should drop these.
> >>
> >>>>> #define REALTIME_COUNTER_BASE 0x48243200
> >>>>> #define INCREMENTER_NUMERATOR_OFFSET 0x10
> >>>>> @@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
> >>>>>
> >>>>> /* If we are a secure device, remove any secure timer nodes */
> >>>>> if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
> >>>>> - np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
> >>>>> + np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
> >>>>> if (np)
> >>>>> of_node_put(np);
> >>>>> }
> >>>>> @@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
> >>>>> return 0;
> >>>>> }
> >>>>>
> >>>>> -#ifdef CONFIG_OMAP_32K_TIMER
> >>>>> /* Setup free-running counter for clocksource */
> >>>>> -static int __init omap2_sync32k_clocksource_init(void)
> >>>>> +static int __init __omap2_sync32k_clocksource_init(void)
> >>>>
> >>>> Not sure I follow why you renamed this function here ...
> >>>
> >>> I didn't want to add unused arguments to this function, so I've made a
> >>> wrapper below to have both the sync32k and the gp functions have the same
> >>> signature (argument list) and be called from a single macro.
> >>> Anyway, see below.
> >>
> >> Ok.
> >>
> >>>>
> >>>>> {
> >>>>> int ret;
> >>>>> struct device_node *np = NULL;
> >>>>> @@ -439,15 +426,9 @@ static int __init omap2_sync32k_clocksource_init(void)
> >>>>>
> >>>>> return ret;
> >>>>> }
> >>>>> -#else
> >>>>> -static inline int omap2_sync32k_clocksource_init(void)
> >>>>> -{
> >>>>> - return -ENODEV;
> >>>>> -}
> >>>>> -#endif
> >>>>>
> >>>>> -static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> >>>>> - const char *fck_source)
> >>>>> +static void __init omap2_gp_clocksource_init(int gptimer_id,
> >>>>> + const char *fck_source)
> >>>>
> >>>> Nit, I personally prefer keeping gptimer, because gp just means
> >>>> "general-purpose" and does not imply a timer per-se.
> >>>
> >>> I've made this change, so we will not get something like:
> >>> omapx_gptimer_timer_init(), but this really does not meter to me,
> >>> so no problem will do for v2.
> >>
> >> Thanks.
> >>
> >>>>
> >>>>> {
> >>>>> int res;
> >>>>>
> >>>>> @@ -466,23 +447,10 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> >>>>> gptimer_id, clksrc.rate);
> >>>>> }
> >>>>>
> >>>>> -static void __init omap2_clocksource_init(int gptimer_id,
> >>>>> - const char *fck_source)
> >>>>> +static void __init omap2_sync32k_clocksource_init(int gptimer_id,
> >>>>> + const char *fck_source)
> >>>>> {
> >>>>> - /*
> >>>>> - * First give preference to kernel parameter configuration
> >>>>> - * by user (clocksource="gp_timer").
> >>>>> - *
> >>>>> - * In case of missing kernel parameter for clocksource,
> >>>>> - * first check for availability for 32k-sync timer, in case
> >>>>> - * of failure in finding 32k_counter module or registering
> >>>>> - * it as clocksource, execution will fallback to gp-timer.
> >>>>> - */
> >>>>> - if (use_gptimer_clksrc == true)
> >>>>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
> >>>>> - else if (omap2_sync32k_clocksource_init())
> >>>>> - /* Fall back to gp-timer code */
> >>>>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
> >>>>> + __omap2_sync32k_clocksource_init();
> >>>>> }
> >>>>
> >>>> ... this just appears to be a wrapper function, but I don't see why this
> >>>> is needed? Do we need this wrapper?
> >>>
> >>> no, not really, just consider the explanation above.
> >>> I will remove the wrapper for v2.
> >>
> >> Ok, thanks.
> >>
> >>>>
> >>>>> #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
> >>>>> @@ -563,52 +531,64 @@ static inline void __init realtime_counter_init(void)
> >>>>> {}
> >>>>> #endif
> >>>>>
> >>>>> -#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
> >>>>> - clksrc_nr, clksrc_src) \
> >>>>> -static void __init omap##name##_timer_init(void) \
> >>>>> +#define OMAP_SYS_TIMER_INIT(n, clksrc_name, clkev_nr, clkev_src, \
> >>>>> + clkev_prop, clksrc_nr, clksrc_src) \
> >>>>> +static void __init omap##n##_##clksrc_name##_timer_init(void) \
> >>>>
> >>>>
> >>>>> { \
> >>>>> omap_dmtimer_init(); \
> >>>>> omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop); \
> >>>>> - omap2_clocksource_init((clksrc_nr), clksrc_src); \
> >>>>> + \
> >>>>> + if (use_gptimer_clksrc) \
> >>>>> + omap2_gp_clocksource_init((clksrc_nr), clksrc_src); \
> >>>>> + else \
> >>>>> + omap2_##clksrc_name##_clocksource_init((clksrc_nr), \
> >>>>> + clksrc_src); \
> >>>>
> >>>> Something here seems a little odd. If "clksrc_name" is "gp", then the
> >>>> if-else parts will call the same function. Or am I missing something here?
> >>>
> >>> Yes, you are right - this is odd.
> >>> What do you think of:
> >>>
> >>> if (use_gptimer_clksrc) {
> >>> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
> >>> return;
> >>> }
> >>> omap2_##clksrc_name##_clocksource_init((clksrc_nr), clksrc_src);
> >>
> >> Yes, but it still seems a little odd that we could have ...
> >>
> >> if (use_gptimer_clksrc) {
> >> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
> >> return;
> >> }
> >> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
> >>
> >>>>
> >>>> I think that I prefer how it works today where we call just
> >>>> omap2_clocksource_init(), and it determines whether to use the gptimer
> >>>> or the 32k-sync.
> >>>
> >>> There is no reliable way to determine which source should be used in runtime
> >>> for boards that do not have the 32k oscillator wired.
> >>
> >> Hmmm ... well for OMAP devices the 32kHz clock is mandatory AFAIK. At
> >> least for OMAP devices and I would need to check on the AM33xx but I
> >> would imagine they are the same. Which devices are you referring to
> >> where the 32kHz is optional?
> >>
> > No we do not have 32k_counter block in AM335x.
>
> I am painfully aware of that :-)
>
> > If you are referring to 32Khz clock availability alone, then yes, we need to
> > get persistent clock and we use RTC 32Khz clock source for it.
> > But please note that this is not a 32k_counter block which OMAP family of
> > devices has.
> >
> > The way AM335x works is, we have timers (0-7), timer0 being secure timer.
> > We use timer1 and timer2 for clockevent and clocksource and they are driven
> > by 26MHz OSC clock currently. So when you go into Low power state, OSC is turned off and you need persistent clock for time keeping, right?
> >
> > And only persistent clock available is RTC 32khz crystal clock, being RTC is
> > in wakeup domain.
>
> I think you are missing the point here. For OMAP devices we have two
> main external clock sources which are the 32kHz clock and the sys_clk
> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
> for OMAP these clock sources are always present and AFAIK there is no
> h/w configuration that allows you not to have the 32kHz clock source.
> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
> serves).
>
> Igor was mentioning a h/w scenario where the 32kHz source is not
> present. However, I am not sure which devices support this and is
> applicable too.
>
> So we are not discussing the 32k-sync-timer here. We are discussing
> whether there are any device configurations where a 32k clock source
> would not be available for the gptimer.
>
Exactly that is the point I am trying to make here,
In case of AM33xx, it is certainly possible to build the system without
this 32Khz clock.
Interesting point here is, this 32KHz clock is external clock coming from
crystal connected to in-built RTC module.
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Paul Walmsley @ 2012-11-08 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509BEE6D.9000902@ti.com>
On Thu, 8 Nov 2012, Jon Hunter wrote:
> Igor was mentioning a h/w scenario where the 32kHz source is not
> present. However, I am not sure which devices support this and is
> applicable too.
Pretty sure Igor is referring to the AM3517/3505. This is very poorly
documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure
4-23 "PRM Clock Generator" and the AM3517 DM Rev C (SPRS550C) Section 4
"Clock Specifications".
- Paul
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-08 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB68654@DBDE01.ent.ti.com>
On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote:
> On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
[snip]
>> I think you are missing the point here. For OMAP devices we have two
>> main external clock sources which are the 32kHz clock and the sys_clk
>> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
>> for OMAP these clock sources are always present and AFAIK there is no
>> h/w configuration that allows you not to have the 32kHz clock source.
>> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
>> serves).
>>
>> Igor was mentioning a h/w scenario where the 32kHz source is not
>> present. However, I am not sure which devices support this and is
>> applicable too.
>>
>> So we are not discussing the 32k-sync-timer here. We are discussing
>> whether there are any device configurations where a 32k clock source
>> would not be available for the gptimer.
>>
>
> Exactly that is the point I am trying to make here,
>
> In case of AM33xx, it is certainly possible to build the system without
> this 32Khz clock.
>
> Interesting point here is, this 32KHz clock is external clock coming from
> crystal connected to in-built RTC module.
Thanks. Looking at the AM3358 data manual it states ...
"The OSC1 oscillator provides a 32.768-kHz reference clock to the
real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT
terminals. OSC1 is disabled by default after power is applied. This
clock input is optional and may not be required if the RTC is configured
to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or
peripheral PLL (CLK_32KHZ) which receives a reference clock from the
OSC0 input."
So what is clear to me that an external 32k clock source is optional.
However, it still appears that you will always have an internal 32k
source and so regardless of the h/w configuration, a gptimer will always
have an 32k clock available on the AM335x devices. Is that correct?
Jon
^ permalink raw reply
* [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Paul Walmsley @ 2012-11-08 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211071655000.20704@utopia.booyaka.com>
On Wed, 7 Nov 2012, Paul Walmsley wrote:
> On Wed, 7 Nov 2012, Paul Walmsley wrote:
>
> > On Tue, 6 Nov 2012, Tony Lindgren wrote:
> >
> > > I'm getting errors with the allnoconfig ones, there are total four
> > > omap defconfigs there not counting the randconfigs.
> >
> > That might indeed explain the discrepancy; so far only have been building
> > his oldconfig seeds here. Will add his allnoconfig seeds and test again.
>
> Can reproduce this here. Thanks for catching this. Will fix and send a
> new pull request today and ensure that the two allnoconfigs are added to
> the build tests from now on.
Just a quick followup on this one: I observed a couple of minor
regressions during the retest, so, will deal with those before sending out
a new pull request.
- Paul
^ permalink raw reply
* [PATCH v2 3/5] ARM: zynq: use zynq clk bindings
From: Josh Cartwright @ 2012-11-08 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1352400580.git.josh.cartwright@ni.com>
Make the Zynq platform use the newly created zynq clk bindings.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/zynq-7000.dtsi | 56 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/zynq-zc702.dts | 4 +++
arch/arm/mach-zynq/common.c | 11 ++++++++
drivers/clk/Makefile | 1 +
5 files changed, 73 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 21ed87b..ccfe0ab 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -959,6 +959,7 @@ config ARCH_ZYNQ
bool "Xilinx Zynq ARM Cortex A9 Platform"
select ARM_AMBA
select ARM_GIC
+ select COMMON_CLK
select CPU_V7
select GENERIC_CLOCKEVENTS
select ICST
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 8b30e59..bb3085c 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -53,5 +53,61 @@
interrupts = <0 50 4>;
clock = <50000000>;
};
+
+ slcr: slcr at f8000000 {
+ compatible = "xlnx,zynq-slcr";
+ reg = <0xF8000000 0x1000>;
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ps_clk: ps_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ /* clock-frequency set in board-specific file */
+ clock-output-names = "ps_clk";
+ };
+ armpll: armpll {
+ #clock-cells = <0>;
+ compatible = "xlnx,zynq-pll";
+ clocks = <&ps_clk>;
+ reg = <0x100 0x110>;
+ clock-output-names = "armpll";
+ };
+ ddrpll: ddrpll {
+ #clock-cells = <0>;
+ compatible = "xlnx,zynq-pll";
+ clocks = <&ps_clk>;
+ reg = <0x104 0x114>;
+ clock-output-names = "ddrpll";
+ };
+ iopll: iopll {
+ #clock-cells = <0>;
+ compatible = "xlnx,zynq-pll";
+ clocks = <&ps_clk>;
+ reg = <0x108 0x118>;
+ clock-output-names = "iopll";
+ };
+ uart_clk: uart_clk {
+ #clock-cells = <1>;
+ compatible = "xlnx,zynq-periph-clock";
+ clocks = <&iopll &armpll &ddrpll>;
+ reg = <0x154>;
+ clock-output-names = "uart0_ref_clk",
+ "uart1_ref_clk";
+ };
+ cpu_clk: cpu_clk {
+ #clock-cells = <1>;
+ compatible = "xlnx,zynq-cpu-clock";
+ clocks = <&iopll &armpll &ddrpll>;
+ reg = <0x120 0x1C4>;
+ clock-output-names = "cpu_6x4x",
+ "cpu_3x2x",
+ "cpu_2x",
+ "cpu_1x";
+ };
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index e25a307..86f44d5 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -28,3 +28,7 @@
};
};
+
+&ps_clk {
+ clock-frequency = <33333330>;
+};
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 5441323..79bf5fb 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -19,6 +19,8 @@
#include <linux/cpumask.h>
#include <linux/platform_device.h>
#include <linux/clk.h>
+#include <linux/clk/zynq.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/of.h>
@@ -96,6 +98,15 @@ static struct map_desc io_desc[] __initdata = {
static void __init xilinx_zynq_timer_init(void)
{
+ struct device_node *np;
+ void __iomem *slcr;
+
+ np = of_find_compatible_node(NULL, NULL, "xlnx,zynq-slcr");
+ slcr = of_iomap(np, 0);
+ WARN_ON(!slcr);
+
+ xilinx_zynq_clocks_init(slcr);
+
xttcpss_timer_init();
}
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71a25b9..d35a34c 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -19,6 +19,7 @@ endif
obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
+obj-$(CONFIG_ARCH_ZYNQ) += clk-zynq.o
# Chip specific
obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
--
1.8.0
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Hiremath, Vaibhav @ 2012-11-08 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509BF2DD.2090308@ti.com>
On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote:
>
> On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote:
> > On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
>
> [snip]
>
> >> I think you are missing the point here. For OMAP devices we have two
> >> main external clock sources which are the 32kHz clock and the sys_clk
> >> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
> >> for OMAP these clock sources are always present and AFAIK there is no
> >> h/w configuration that allows you not to have the 32kHz clock source.
> >> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
> >> serves).
> >>
> >> Igor was mentioning a h/w scenario where the 32kHz source is not
> >> present. However, I am not sure which devices support this and is
> >> applicable too.
> >>
> >> So we are not discussing the 32k-sync-timer here. We are discussing
> >> whether there are any device configurations where a 32k clock source
> >> would not be available for the gptimer.
> >>
> >
> > Exactly that is the point I am trying to make here,
> >
> > In case of AM33xx, it is certainly possible to build the system without
> > this 32Khz clock.
> >
> > Interesting point here is, this 32KHz clock is external clock coming from
> > crystal connected to in-built RTC module.
>
> Thanks. Looking at the AM3358 data manual it states ...
>
> "The OSC1 oscillator provides a 32.768-kHz reference clock to the
> real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT
> terminals. OSC1 is disabled by default after power is applied. This
> clock input is optional and may not be required if the RTC is configured
> to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or
> peripheral PLL (CLK_32KHZ) which receives a reference clock from the
> OSC0 input."
>
> So what is clear to me that an external 32k clock source is optional.
> However, it still appears that you will always have an internal 32k
> source and so regardless of the h/w configuration, a gptimer will always
> have an 32k clock available on the AM335x devices. Is that correct?
>
Internal RC oscillator is not accurate at all, so not guaranteed to give
accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz.
So it may not be useful as a system clocks, right?
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH 14/26] ARM: OMAP3: clock: Add 3xxx data using common struct clk
From: Paul Walmsley @ 2012-11-08 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352337181-29427-15-git-send-email-mturquette@ti.com>
On Wed, 7 Nov 2012, Mike Turquette wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> The patch is the output from a python script which converts
> from the old OMAP clk format to COMMON clk format using a
> JSON parser in between which was developed by Paul Walmsley.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> [paul at pwsan.com: AM3517/05: dropped bogus hsotgusb "ick" and "fck"
> clkdev aliases; added hsotgusb_fck alias; added emac_ick and emac_fck
> aliases; replace omap2_init_clksel_parent() with
> omap2_clksel_find_parent_index(); reflow macros and parent name
> lists; add clkdm_name argument to DEFINE_STRUCT_CLK_HW_OMAP macros]
> Signed-off-by: Mike Turquette <mturquette@ti.com>
Am seeing warnings during the disable-unused-clocks phase of the boot
on the OMAP3 test boards here. Log is included at the bottom of this
E-mail, with some debugging added for extra context. The problem
appears to be that the clock code is disabling clocks that are active
in the hardware, but for which the clockdomain use count is 0, since
they've never been enabled.
Ideally there would be some way for the core CCF code to indicate to the
underlying clock hardware implementation that the disable-unused-clock
process is a 'force disable'. The OMAP clock hardware implementation code
could then also put the clockdomain to sleep (and skip the warning) in
such a circumstance.
- Paul
[ 2.685943] disabling sys_clkout1: ec = 0
[ 2.690277] disabling wdt1_ick: ec = 0
[ 2.694366] disabling cam_mclk: ec = 0
[ 2.698333] ------------[ cut here ]------------
[ 2.703216] WARNING: at arch/arm/mach-omap2/clockdomain.c:961 _clkdm_clk_hwmod_disable+0xc4/0xd8()
[ 2.712646] Modules linked in:
[ 2.715911] [<c001c38c>] (unwind_backtrace+0x0/0xf0) from [<c0043cd8>] (warn_slowpath_common+0x4c/0x64)
[ 2.725799] [<c0043cd8>] (warn_slowpath_common+0x4c/0x64) from [<c0043d0c>] (warn_slowpath_null+0x1c/0x24)
[ 2.735961] [<c0043d0c>] (warn_slowpath_null+0x1c/0x24) from [<c003705c>] (_clkdm_clk_hwmod_disable+0xc4/0xd8)
[ 2.746520] [<c003705c>] (_clkdm_clk_hwmod_disable+0xc4/0xd8) from [<c0437bd0>] (clk_disable_unused_subtree+0xb0/0xbc)
[ 2.757781] [<c0437bd0>] (clk_disable_unused_subtree+0xb0/0xbc) from [<c0437b40>] (clk_disable_unused_subtree+0x20/0xbc)
[ 2.769226] ---[ end trace ebefd5468131571a ]---
[ 2.774261] disabling mspro_fck: ec = 0
[ 2.778320] disabling ssi_ssr_fck_3430es2: ec = 0
[ 2.783355] disabling pka_ick: ec = 0
[ 2.787231] disabling sad2d_ick: ec = 0
[ 2.791259] ------------[ cut here ]------------
[ 2.796142] WARNING: at arch/arm/mach-omap2/clockdomain.c:961 _clkdm_clk_hwmod_disable+0xc4/0xd8()
[ 2.805572] Modules linked in:
[ 2.808807] [<c001c38c>] (unwind_backtrace+0x0/0xf0) from [<c0043cd8>] (warn_slowpath_common+0x4c/0x64)
[ 2.818695] [<c0043cd8>] (warn_slowpath_common+0x4c/0x64) from [<c0043d0c>] (warn_slowpath_null+0x1c/0x24)
[ 2.828857] [<c0043d0c>] (warn_slowpath_null+0x1c/0x24) from [<c003705c>] (_clkdm_clk_hwmod_disable+0xc4/0xd8)
[ 2.839416] [<c003705c>] (_clkdm_clk_hwmod_disable+0xc4/0xd8) from [<c0437bd0>] (clk_disable_unused_subtree+0xb0/0xbc)
[ 2.850677] [<c0437bd0>] (clk_disable_unused_subtree+0xb0/0xbc) from [<c0437b40>] (clk_disable_unused_subtree+0x20/0xbc)
[ 2.862121] ---[ end trace ebefd5468131571b ]---
[ 2.867065] disabling wdt3_ick: ec = 0
[ 2.871032] disabling des1_ick: ec = 0
[ 2.875030] disabling sha11_ick: ec = 0
[ 2.879089] disabling rng_ick: ec = 0
[ 2.882995] disabling aes1_ick: ec = 0
[ 2.886932] disabling ssi_ick_3430es2: ec = 0
[ 2.891601] disabling mspro_ick: ec = 0
[ 2.895660] disabling des2_ick: ec = 0
[ 2.899658] disabling sha12_ick: ec = 0
[ 2.903686] disabling aes2_ick: ec = 0
[ 2.907684] disabling icr_ick: ec = 0
[ 2.911621] disabling wdt3_fck: ec = 0
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-08 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211081754390.20703@utopia.booyaka.com>
On 11/08/2012 11:58 AM, Paul Walmsley wrote:
> On Thu, 8 Nov 2012, Jon Hunter wrote:
>
>> Igor was mentioning a h/w scenario where the 32kHz source is not
>> present. However, I am not sure which devices support this and is
>> applicable too.
>
> Pretty sure Igor is referring to the AM3517/3505. This is very poorly
> documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure
> 4-23 "PRM Clock Generator" and the AM3517 DM Rev C (SPRS550C) Section 4
> "Clock Specifications".
Thanks Paul. But AFAICT, even in that h/w configuration the internal 32k
oscillator will be used and so the gptimer will still have a 32k clock
source.
So I still don't see a use-case where the gptimer would not have a 32k
source available. Admittedly, I could be missing one somewhere or I am
just plain old wrong ...
Cheers
Jon
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-08 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB686AC@DBDE01.ent.ti.com>
On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote:
> On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote:
>>
>> On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote:
>>> On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
>>
>> [snip]
>>
>>>> I think you are missing the point here. For OMAP devices we have two
>>>> main external clock sources which are the 32kHz clock and the sys_clk
>>>> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
>>>> for OMAP these clock sources are always present and AFAIK there is no
>>>> h/w configuration that allows you not to have the 32kHz clock source.
>>>> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
>>>> serves).
>>>>
>>>> Igor was mentioning a h/w scenario where the 32kHz source is not
>>>> present. However, I am not sure which devices support this and is
>>>> applicable too.
>>>>
>>>> So we are not discussing the 32k-sync-timer here. We are discussing
>>>> whether there are any device configurations where a 32k clock source
>>>> would not be available for the gptimer.
>>>>
>>>
>>> Exactly that is the point I am trying to make here,
>>>
>>> In case of AM33xx, it is certainly possible to build the system without
>>> this 32Khz clock.
>>>
>>> Interesting point here is, this 32KHz clock is external clock coming from
>>> crystal connected to in-built RTC module.
>>
>> Thanks. Looking at the AM3358 data manual it states ...
>>
>> "The OSC1 oscillator provides a 32.768-kHz reference clock to the
>> real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT
>> terminals. OSC1 is disabled by default after power is applied. This
>> clock input is optional and may not be required if the RTC is configured
>> to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or
>> peripheral PLL (CLK_32KHZ) which receives a reference clock from the
>> OSC0 input."
>>
>> So what is clear to me that an external 32k clock source is optional.
>> However, it still appears that you will always have an internal 32k
>> source and so regardless of the h/w configuration, a gptimer will always
>> have an 32k clock available on the AM335x devices. Is that correct?
>>
>
> Internal RC oscillator is not accurate at all, so not guaranteed to give
> accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz.
>
> So it may not be useful as a system clocks, right?
So I admit I am not familiar with the details on the AMxxxx stuff side
so much.
So maybe I should ask this question ...
Do you support a configuration where there is no external 32k clock AND
the internal oscillator and hence, RTC are not used?
I would have expected that you would always want the RTC running, but if
you are saying that you don't require an external 32k and the internal
32k is not accurate, then I assume that having the RTC available is not
mandatory either.
Jon
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Paul Walmsley @ 2012-11-08 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509BF525.80309@ti.com>
On Thu, 8 Nov 2012, Jon Hunter wrote:
> On 11/08/2012 11:58 AM, Paul Walmsley wrote:
> > On Thu, 8 Nov 2012, Jon Hunter wrote:
> >
> >> Igor was mentioning a h/w scenario where the 32kHz source is not
> >> present. However, I am not sure which devices support this and is
> >> applicable too.
> >
> > Pretty sure Igor is referring to the AM3517/3505. This is very poorly
> > documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure
> > 4-23 "PRM Clock Generator" and the AM3517 DM Rev C (SPRS550C) Section 4
> > "Clock Specifications".
>
> But AFAICT, even in that h/w configuration the internal 32k
> oscillator will be used
Just to clarify, there's no internal 32k oscillator used on the 3517/3505;
just a divider from the HF clock.
> and so the gptimer will still have a 32k clock source.
That's a good question and you might want to check with Igor on that one,
the AM3517 TRM conflicts with the DM as to whether it's available to the
GPTIMER or not :-(
- Paul
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Hiremath, Vaibhav @ 2012-11-08 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509BF64B.5060405@ti.com>
On Thu, Nov 08, 2012 at 23:43:31, Hunter, Jon wrote:
>
> On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote:
> > On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote:
> >>
> >> On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote:
> >>> On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
> >>
> >> [snip]
> >>
> >>>> I think you are missing the point here. For OMAP devices we have two
> >>>> main external clock sources which are the 32kHz clock and the sys_clk
> >>>> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
> >>>> for OMAP these clock sources are always present and AFAIK there is no
> >>>> h/w configuration that allows you not to have the 32kHz clock source.
> >>>> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
> >>>> serves).
> >>>>
> >>>> Igor was mentioning a h/w scenario where the 32kHz source is not
> >>>> present. However, I am not sure which devices support this and is
> >>>> applicable too.
> >>>>
> >>>> So we are not discussing the 32k-sync-timer here. We are discussing
> >>>> whether there are any device configurations where a 32k clock source
> >>>> would not be available for the gptimer.
> >>>>
> >>>
> >>> Exactly that is the point I am trying to make here,
> >>>
> >>> In case of AM33xx, it is certainly possible to build the system without
> >>> this 32Khz clock.
> >>>
> >>> Interesting point here is, this 32KHz clock is external clock coming from
> >>> crystal connected to in-built RTC module.
> >>
> >> Thanks. Looking at the AM3358 data manual it states ...
> >>
> >> "The OSC1 oscillator provides a 32.768-kHz reference clock to the
> >> real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT
> >> terminals. OSC1 is disabled by default after power is applied. This
> >> clock input is optional and may not be required if the RTC is configured
> >> to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or
> >> peripheral PLL (CLK_32KHZ) which receives a reference clock from the
> >> OSC0 input."
> >>
> >> So what is clear to me that an external 32k clock source is optional.
> >> However, it still appears that you will always have an internal 32k
> >> source and so regardless of the h/w configuration, a gptimer will always
> >> have an 32k clock available on the AM335x devices. Is that correct?
> >>
> >
> > Internal RC oscillator is not accurate at all, so not guaranteed to give
> > accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz.
> >
> > So it may not be useful as a system clocks, right?
>
> So I admit I am not familiar with the details on the AMxxxx stuff side
> so much.
>
> So maybe I should ask this question ...
>
> Do you support a configuration where there is no external 32k clock AND
> the internal oscillator and hence, RTC are not used?
>
Why not, you could give-up on persistent time across suspend/resume and use
OSC clock as a input clock to timer.
And the timer code, which we have we have added fallback mechanism for this,
First make sure that timer is properly set for RTC32K, if yes, then use it,
and if no, then fall back to OSC clock.
> I would have expected that you would always want the RTC running, but if
> you are saying that you don't require an external 32k and the internal
> 32k is not accurate, then I assume that having the RTC available is not
> mandatory either.
>
Yes, it is not mandatory, considering fact that, you will not have
persistent time and other low-power modes.
Actually it depends on board/EVM use-case, right?
Thanks,
Vaibhav
> Jon
>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-08 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211081809470.20703@utopia.booyaka.com>
On 11/08/2012 12:17 PM, Paul Walmsley wrote:
> On Thu, 8 Nov 2012, Jon Hunter wrote:
>
>> On 11/08/2012 11:58 AM, Paul Walmsley wrote:
>>> On Thu, 8 Nov 2012, Jon Hunter wrote:
>>>
>>>> Igor was mentioning a h/w scenario where the 32kHz source is not
>>>> present. However, I am not sure which devices support this and is
>>>> applicable too.
>>>
>>> Pretty sure Igor is referring to the AM3517/3505. This is very poorly
>>> documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure
>>> 4-23 "PRM Clock Generator" and the AM3517 DM Rev C (SPRS550C) Section 4
>>> "Clock Specifications".
>>
>> But AFAICT, even in that h/w configuration the internal 32k
>> oscillator will be used
>
> Just to clarify, there's no internal 32k oscillator used on the 3517/3505;
> just a divider from the HF clock.
Ah yes I see that now!
>> and so the gptimer will still have a 32k clock source.
>
> That's a good question and you might want to check with Igor on that one,
> the AM3517 TRM conflicts with the DM as to whether it's available to the
> GPTIMER or not :-(
Well the external 32k and internal divided down version go through the
same mux and so that seems to imply either they are both available to
the gptimer or neither is.
Cheers
Jon
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-08 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB6872B@DBDE01.ent.ti.com>
On 11/08/2012 12:28 PM, Hiremath, Vaibhav wrote:
> On Thu, Nov 08, 2012 at 23:43:31, Hunter, Jon wrote:
>>
>> On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote:
>>> On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote:
>>>>
>>>> On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote:
>>>>> On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
>>>>
>>>> [snip]
>>>>
>>>>>> I think you are missing the point here. For OMAP devices we have two
>>>>>> main external clock sources which are the 32kHz clock and the sys_clk
>>>>>> (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
>>>>>> for OMAP these clock sources are always present and AFAIK there is no
>>>>>> h/w configuration that allows you not to have the 32kHz clock source.
>>>>>> PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
>>>>>> serves).
>>>>>>
>>>>>> Igor was mentioning a h/w scenario where the 32kHz source is not
>>>>>> present. However, I am not sure which devices support this and is
>>>>>> applicable too.
>>>>>>
>>>>>> So we are not discussing the 32k-sync-timer here. We are discussing
>>>>>> whether there are any device configurations where a 32k clock source
>>>>>> would not be available for the gptimer.
>>>>>>
>>>>>
>>>>> Exactly that is the point I am trying to make here,
>>>>>
>>>>> In case of AM33xx, it is certainly possible to build the system without
>>>>> this 32Khz clock.
>>>>>
>>>>> Interesting point here is, this 32KHz clock is external clock coming from
>>>>> crystal connected to in-built RTC module.
>>>>
>>>> Thanks. Looking at the AM3358 data manual it states ...
>>>>
>>>> "The OSC1 oscillator provides a 32.768-kHz reference clock to the
>>>> real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT
>>>> terminals. OSC1 is disabled by default after power is applied. This
>>>> clock input is optional and may not be required if the RTC is configured
>>>> to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or
>>>> peripheral PLL (CLK_32KHZ) which receives a reference clock from the
>>>> OSC0 input."
>>>>
>>>> So what is clear to me that an external 32k clock source is optional.
>>>> However, it still appears that you will always have an internal 32k
>>>> source and so regardless of the h/w configuration, a gptimer will always
>>>> have an 32k clock available on the AM335x devices. Is that correct?
>>>>
>>>
>>> Internal RC oscillator is not accurate at all, so not guaranteed to give
>>> accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz.
>>>
>>> So it may not be useful as a system clocks, right?
>>
>> So I admit I am not familiar with the details on the AMxxxx stuff side
>> so much.
>>
>> So maybe I should ask this question ...
>>
>> Do you support a configuration where there is no external 32k clock AND
>> the internal oscillator and hence, RTC are not used?
>>
>
> Why not, you could give-up on persistent time across suspend/resume and use
> OSC clock as a input clock to timer.
>
> And the timer code, which we have we have added fallback mechanism for this,
> First make sure that timer is properly set for RTC32K, if yes, then use it,
> and if no, then fall back to OSC clock.
You mean sync-32k and not rtc32k right? We are just detecting the
presence of the sync-32k counter and if so use it, otherwise use a gptimer.
>> I would have expected that you would always want the RTC running, but if
>> you are saying that you don't require an external 32k and the internal
>> 32k is not accurate, then I assume that having the RTC available is not
>> mandatory either.
>>
>
> Yes, it is not mandatory, considering fact that, you will not have
> persistent time and other low-power modes.
> Actually it depends on board/EVM use-case, right?
Yes absolutely, just trying to understand if that is a valid use-case or
not. So for AM33xx the external 32k is not mandatory. Thanks.
Jon
^ permalink raw reply
* [PATCH v2 0/5] zynq clk support
From: Josh Cartwright @ 2012-11-08 18:49 UTC (permalink / raw)
To: linux-arm-kernel
This set is a v2 of my original patchset "zynq COMMON_CLK support" [1].
This patchset is on top of the arm-next in the Xilinx tree[2], and also
dependent on my patch "serial: xilinx_uartps: kill CONFIG_OF
conditional", which I've removed from this patchset at Michal Simek's request.
For easy testing, I've made available a branch with my changes here[3].
Changes since v1:
- Dropped the moving of the TTC driver. This will be done in a later
patchset.
- Fixed TTC periodic tick frequency calculation
- Updated basic peripheral clk to support devices with less than two
derivative clks.
- Fixed dts issues in the uart and ttc (thanks to Lars-Peter Clausen and Michal Simek).
- Split out the creation of the clk drivers and the enabling of the
drivers for the platform into separate patches.
- Updated clk initialization functions to 'bail out' when an error
condition is hit.
- Addressed stylistic feedback from Lars-Peter Clausen.
---
Patch 1 performs a dts file split for zynq, creating a generic zynq-7000.dtsi
snippet and a zynq-zc702.dts board specific description.
Patch 2 introduces the zynq clock drivers and bindings.
Patch 3 enables the zynq clock drivers when building for zynq, and
adds updates the zynq device trees to use the bindings.
Patch 4 updates the xilinx uartps driver to acquire rate information via
the clk bindings.
Patch 5 updates the xilinx ttc driver to acquire rate information via
the clk bindings.
---
[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-October/129295.html
[2]: git://git.xilinx.com/linux-xlnx.git#arm-next
[3]: git://gi.teric.us/linux-zynq.git#of_clk_v2
---
Josh Cartwright (5):
ARM: zynq: dts: split up device tree
clk: Add support for fundamental zynq clks
ARM: zynq: use zynq clk bindings
serial: xilinx_uartps: get clock rate info from dts
ARM: zynq: add clk binding support to the ttc
.../devicetree/bindings/clock/zynq-7000.txt | 55 +++
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zynq-7000.dtsi | 166 +++++++++
arch/arm/boot/dts/zynq-ep107.dts | 70 ----
arch/arm/boot/dts/zynq-zc702.dts | 44 +++
arch/arm/mach-zynq/common.c | 14 +-
arch/arm/mach-zynq/timer.c | 287 ++++++++-------
drivers/clk/Makefile | 1 +
drivers/clk/clk-zynq.c | 383 +++++++++++++++++++++
drivers/tty/serial/xilinx_uartps.c | 30 +-
include/linux/clk/zynq.h | 24 ++
12 files changed, 870 insertions(+), 206 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/zynq-7000.txt
create mode 100644 arch/arm/boot/dts/zynq-7000.dtsi
delete mode 100644 arch/arm/boot/dts/zynq-ep107.dts
create mode 100644 arch/arm/boot/dts/zynq-zc702.dts
create mode 100644 drivers/clk/clk-zynq.c
create mode 100644 include/linux/clk/zynq.h
--
1.8.0
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-08 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509B666F.6080507@compulab.co.il>
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
[snip]
> There is no reliable way to determine which source should be used in runtime
> for boards that do not have the 32k oscillator wired.
So thinking about this some more and given that we are moving away from
board files, if a board does not provide a 32kHz clock source, then this
should be reflected in the device-tree source file for that board.
Hence, at boot time we should be able to determine if a 32kHz clock
source can be used.
Cheers
Jon
^ permalink raw reply
* [Xen-devel] BUG: ARM build failures due to Xen
From: konrad @ 2012-11-08 18:54 UTC (permalink / raw)
To: linux-arm-kernel
Sorry about top posting - on the phone. I will send to Linus tomorrow.
Ian Campbell <ian.campbell@citrix.com> wrote:
>On Thu, 2012-11-08 at 15:28 +0000, Arnd Bergmann wrote:
>> On Tuesday 06 November 2012, Russell King - ARM Linux wrote:
>> > My build system is giving me the following errors against an OMAP4
>> > randconfig build against the latest Linus' kernel plus arm-soc:
>> >
>> > ERROR: "privcmd_call" [drivers/xen/xen-privcmd.ko] undefined!
>> > make[2]: *** [__modpost] Error 1
>> > make[2]: Target `_modpost' not remade because of errors.
>> > make[1]: *** [modules] Error 2
>> > make: *** [sub-make] Error 2
>> > make: Target `uImage' not remade because of errors.
>> > make: Target `modules' not remade because of errors.
>> >
>> > Full build results and configuration are here:
>> >
>> > http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=2627
>> > http://www.arm.linux.org.uk/developer/build/file.php?type=config&idx=2627
>> >
>>
>> I can reproduce the same thing with mainline v3.7-rc4.
>> 8<------
>> xen/arm: export privcmd_call
>
>Thanks, Konrad posted a fix for this on Tuesday which covers a few other
>cases too: http://marc.info/?l=linux-kernel&m=135224075902642&w=2 I
>added Russell to my response but forgot to add l-a-k@ too, sorry.
>
>Is one of you going to pick it up and send to mainline?
>
>Ian.
>
>> privcmd_call may get called from a module, so it has to be exported.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index 59bcb96..ff5e300 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -17,6 +17,9 @@
>> #include <linux/of_irq.h>
>> #include <linux/of_address.h>
>>
>> +/* from hypercall.S */
>> +EXPORT_SYMBOL_GPL(privcmd_call);
>> +
>> struct start_info _xen_start_info;
>> struct start_info *xen_start_info = &_xen_start_info;
>> EXPORT_SYMBOL_GPL(xen_start_info);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel at lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
^ permalink raw reply
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