From: Atul Dahiya
This patch adds rtc clock for S5P6450.
Signed-off-by: Atul Dahiya
Signed-off-by: Sangbeom Kim
---
arch/arm/mach-s5p64x0/clock-s5p6450.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5p64x0/clock-s5p6450.c
b/arch/arm/mach-s5p64x
Vasily Khoruzhick wrote:
>
> Currently the {set,get}_pull callbacks of the s3c24xx_gpiocfg_default
> structure
> are initalized via s3c_gpio_{get,set}pull_1up. This results in a linker
> error when only CONFIG_CPU_S3C2442 is selected:
>
> arch/arm/plat-s3c24xx/built-in.o:(.data+0x13f4): undefined
Currently the {set,get}_pull callbacks of the s3c24xx_gpiocfg_default structure
are initalized via s3c_gpio_{get,set}pull_1up. This results in a linker
error when only CONFIG_CPU_S3C2442 is selected:
arch/arm/plat-s3c24xx/built-in.o:(.data+0x13f4): undefined reference to
`s3c_gpio_getpull_1up'
arc
On Wed, Dec 1, 2010 at 5:02 AM, Russell King - ARM Linux
wrote:
> On Tue, Nov 30, 2010 at 08:16:58PM +0300, Anton Vorontsov wrote:
[...]
>> + sub r4, r4, r5
>> + add r6, r6, r4
>> +#if __LINUX_ARM_ARCH__ >= 7
>> + dsb
>> +#endif
>
> Another question though - probably for Linu
On Wednesday 01 December 2010 07:28:17 Kukjin Kim wrote:
> > > else if (pup == S3C_GPIO_PULL_NONE)
>
> pull == S3C_GPIO_PULL_NONE?
Yep, thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
Lars-Peter Clausen wrote:
>
> > +static int s3c_gpio_setpull_1(struct s3c_gpio_chip *chip,
> > +unsigned int off, s3c_gpio_pull_t pull,
> > +s3c_gpio_pull_t updown)
> > {
> > void __iomem *reg = chip->base + 0x08;
> > u32 pup = __raw_readl(reg);
> >
Lars-Peter Clausen wrote:
>
> >> -#ifdef CONFIG_S3C_GPIO_PULL_UP
> >> -int s3c_gpio_setpull_1up(struct s3c_gpio_chip *chip,
> >> - unsigned int off, s3c_gpio_pull_t pull)
> >> +#if defined(CONFIG_S3C_GPIO_PULL_UP) ||
> > defined(CONFIG_S3C_GPIO_PULL_DOWN)
> >> +static int s3c_gpi
On Tue, Nov 30, 2010 at 11:32:04PM +, Russell King - ARM Linux wrote:
> Note that I'll go with factoring this out into arch/arm/kernel/smp_scu.c
> for the time being, but I'm not convinced about the other parts yet.
IOW, something like the attached. I've gone a little further and removed
the
On Tue, Nov 30, 2010 at 08:16:58PM +0300, Anton Vorontsov wrote:
> +/*
> + * Initialise the CPU possible map early - this describes the CPUs
> + * which may be present or become present in the system.
> + */
> +void __init scu_init_cpus(void __iomem *scu_base)
> +{
> + unsigned int ncores = scu
On Tue, Nov 30, 2010 at 08:17:01PM +0300, Anton Vorontsov wrote:
> +/* If there are more than one CPU let them know where to start. */
> +static void __init smp_point_cpus(void)
> +{
> + if (num_present_cpus() <= 1)
> + return;
>
> - for (i = 0; i < ncores; i++)
> -
On Tue, Nov 30, 2010 at 08:16:58PM +0300, Anton Vorontsov wrote:
> For CNS3xxx we want to reuse the original ARM approach of booting
> secondary CPUs. This patch factors out VExpress' code into a common
> file, so that now platform code can call these routines.
>
> Note that this patch doesn't con
On Tue, Nov 30, 2010 at 08:31:05PM +0300, Anton Vorontsov wrote:
> This greatly reduces amount of platform-specific code, and thus
> makes it easier to add local timers for new platforms.
>
> Technically, it's not very nice to place machine-specific (i.e.
> local_timer_setup()) routine into the ma
Currently the {set,get}_pull callbacks of the s3c24xx_gpiocfg_default structure
are initalized via s3c_gpio_{get,set}pull_1up. This results in a linker
error when only CONFIG_CPU_S3C2442 is selected:
arch/arm/plat-s3c24xx/built-in.o:(.data+0x13f4): undefined reference to
`s3c_gpio_getpull_1up'
arc
On Tuesday 30 November 2010 21:59:01 Lars-Peter Clausen wrote:
> On 11/30/2010 08:46 PM, Vasily Khoruzhick wrote:
> > Currently the {set,get}_pull callbacks of the s3c24xx_gpiocfg_default
> > structure are initalized via s3c_gpio_{get,set}pull_1up. This results in
> > a linker error when only CONFI
On 11/30/2010 08:46 PM, Vasily Khoruzhick wrote:
> Currently the {set,get}_pull callbacks of the s3c24xx_gpiocfg_default
> structure
> are initalized via s3c_gpio_{get,set}pull_1up. This results in a linker
> error when only CONFIG_CPU_S3C2442 is selected:
>
> arch/arm/plat-s3c24xx/built-in.o:(.d
Currently the {set,get}_pull callbacks of the s3c24xx_gpiocfg_default structure
are initalized via s3c_gpio_{get,set}pull_1up. This results in a linker
error when only CONFIG_CPU_S3C2442 is selected:
arch/arm/plat-s3c24xx/built-in.o:(.data+0x13f4): undefined reference to
`s3c_gpio_getpull_1up'
arc
On Tue, Nov 30, 2010 at 08:17:00PM +0300, Anton Vorontsov wrote:
> Nothing fancy needs to be done, just use generic SCU routines.
>
> Signed-off-by: Anton Vorontsov
This I assume is an age old patch.
> diff --git a/arch/arm/mach-cns3xxx/include/mach/smp.h
> b/arch/arm/mach-cns3xxx/include/mach
This shrinks platform-specific code a little bit.
Signed-off-by: Anton Vorontsov
---
arch/arm/mach-tegra/platsmp.c | 36 ++--
1 files changed, 2 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 1c0f
This shrinks platform-specific code quite a bit.
Signed-off-by: Anton Vorontsov
---
arch/arm/mach-ux500/Makefile |2 +-
arch/arm/mach-ux500/headsmp.S | 38 ---
arch/arm/mach-ux500/hotplug.c |5 +-
arch/arm/mach-ux500/include/mach/smp.h |3 -
arch
This shrinks platform-specific code a little bit.
Signed-off-by: Anton Vorontsov
---
arch/arm/mach-omap2/omap-smp.c | 64 ++--
1 files changed, 3 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
ind
Nothing fancy needs to be done, just use generic SCU routines.
Signed-off-by: Anton Vorontsov
---
arch/arm/Kconfig |2 +-
arch/arm/mach-cns3xxx/Kconfig|1 +
arch/arm/mach-cns3xxx/Makefile |1 +
arch/arm/mach-cns3xxx/include/mach/smp.h |
For CNS3xxx we want to reuse the original ARM approach of booting
secondary CPUs. This patch factors out VExpress' code into a common
file, so that now platform code can call these routines.
Note that this patch doesn't convert VExpress platform to the
generic routines. Plus, there are also a lot
This shrinks platform-specific code quite a bit.
Signed-off-by: Anton Vorontsov
---
arch/arm/mach-realview/Makefile |2 +-
arch/arm/mach-realview/headsmp.S | 39 -
arch/arm/mach-realview/hotplug.c |5 +-
arch/arm/mach-realview/platsmp.c | 161 +++--
This shrinks platform-specific code quite a bit.
Signed-off-by: Anton Vorontsov
---
arch/arm/mach-vexpress/Makefile |2 +-
arch/arm/mach-vexpress/headsmp.S | 39 --
arch/arm/mach-vexpress/platsmp.c | 150 --
3 files changed, 15 insertions(+), 1
This shrinks platform-specific code quite a bit.
Signed-off-by: Anton Vorontsov
---
arch/arm/mach-s5pv310/Makefile |2 +-
arch/arm/mach-s5pv310/headsmp.S | 41 -
arch/arm/mach-s5pv310/hotplug.c |5 +-
arch/arm/mach-s5pv310/platsmp.c | 125 ++---
Hello everyone,
This is a reincarnation of my old series that was posted some time
ago, i.e. http://www.spinics.net/lists/arm-kernel/msg94291.html
The main change is that boot protocol routines were split into
its own file, i.e. smp_scu_boot.c. And now there are all platforms
converted to the com
This greatly reduces amount of platform-specific code, and thus
makes it easier to add local timers for new platforms.
Technically, it's not very nice to place machine-specific (i.e.
local_timer_setup()) routine into the machine-agnostic code.
But the true thing is: currently all machines want the
Hi Ben, Kukjin,
could you please both find out who must 'handle' it?
Do you think it's normal to force people to ping you for the same four
lines patch for 4 months or more?
I think, it's at least not optimal and not good for kernel development process.
thanks,
Darius
On Tue, Nov 30, 2010 at 2:
On Tuesday 30 November 2010 16:53:09 Lars-Peter Clausen wrote:
> Both the cpu init code and the machine init code are run at arch_initcall.
Yeah, you're right.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
Mor
On 11/30/2010 03:33 PM, Vasily Khoruzhick wrote:
> On Tuesday 30 November 2010 15:12:37 Lars-Peter Clausen wrote:
>
>> Hi
>>
>> While this might work for setting the pullup, what to you want to return in
>> get_pull?
>
> Some custom value like S3C_GPIO_PULL_ENABLED?
Well, or we could use a custom
On Tuesday 30 November 2010 15:12:37 Lars-Peter Clausen wrote:
> Hi
>
> While this might work for setting the pullup, what to you want to return in
> get_pull?
Some custom value like S3C_GPIO_PULL_ENABLED?
> The reason why s3c24xx_gpiocfg_default needs to have {get,set}_pull set at
> compile t
On 11/30/2010 01:01 PM, Vasily Khoruzhick wrote:
> On Tuesday 30 November 2010 13:53:43 Lars-Peter Clausen wrote:
>
>>> Hmm...how about s3c_gpio_setpull_1updown(...)?
>>> And actually, not used 3rd argument, "pull" now.
>>> I prefer follwoing.
>>
>> You need the 4th arguemnt, because the s3c2440 o
On Tuesday 30 November 2010 13:53:43 Lars-Peter Clausen wrote:
> > Hmm...how about s3c_gpio_setpull_1updown(...)?
> > And actually, not used 3rd argument, "pull" now.
> > I prefer follwoing.
>
> You need the 4th arguemnt, because the s3c2440 only supports pullups and
> the s3c2442 only supports p
On 11/30/2010 07:18 AM, Kukjin Kim wrote:
> Vasily Khoruzhick wrote:
>>
>> Currently the {set,get}_pull callbacks of the s3c24xx_gpiocfg_default
>> structure
>> are initalized via s3c_gpio_{get,set}pull_1up. This results in a linker
>> error when compiling kernel for s3c2442:
>>
>> arch/arm/plat-s3
34 matches
Mail list logo
