* [RFC/PATCH 5/7] ARM: Move get_thread_info macro definition to <asm/assembler.h>
From: Catalin Marinas @ 2011-10-13 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013143420.GB21648@n2100.arm.linux.org.uk>
On Thu, Oct 13, 2011 at 03:34:20PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 12, 2011 at 02:04:33AM -0400, gdavis at mvista.com wrote:
> > diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> > index 78397d0..eaf4939 100644
> > --- a/arch/arm/include/asm/assembler.h
> > +++ b/arch/arm/include/asm/assembler.h
> > @@ -36,6 +36,20 @@
> > .endm
> > #endif /* !CONFIG_THUMB2_KERNEL */
> >
> > + .macro preempt_disable, tsk, cnt
> > + get_thread_info \tsk
> > + ldr \cnt, [\tsk, #TI_PREEMPT]
> > + add \cnt, \cnt, #1
> > + str \cnt, [\tsk, #TI_PREEMPT]
> > + .endm
> > +
> > + .macro preempt_enable, tsk, cnt
> > + get_thread_info \tsk
> > + ldr \cnt, [\tsk, #TI_PREEMPT]
> > + sub \cnt, \cnt, #1
> > + str \cnt, [\tsk, #TI_PREEMPT]
> > + .endm
> > +
> > /*
> > * Endian independent macros for shifting bytes within registers.
> > */
> >
> >
> > Not as efficient as it could be but I imagine the macros could
> > be written to support optional load of \tsk and/or optional \tmp
> > parameters to cover other common cases.
>
> It's actually not that simple either: if you disable preemption, then you
> need to check for a preempt event after re-enabling preemption.
That's not easily possible in assembly as calling a function would
corrupt some registers. Is there any disadvantage with just doing the
equivalent of preempt_enable_no_resched() for a few asm cases where this
is needed?
--
Catalin
^ permalink raw reply
* [PATCH] UART: add CSR SiRFprimaII SoC on-chip uart drivers
From: Barry Song @ 2011-10-13 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013152721.6abcbbdc@bob.linux.org.uk>
2011/10/13 Alan Cox <alan@linux.intel.com>:
>> >> +static struct console sirfsoc_uart_console = {
>> >> + ? ? .name ? ? ? ? ? = "ttyS",
>> >
>> > ttyS is 8250 devces. Pick a new name for your own.
>>
>> ok. most devices have names like ttySQ, ttySA, ttySG... since our SoC
>> is named SiRFprimaII, i'd like to have ttySI?
>
> If nobody else is using it for anything mainstream sure. Or ttySiRF0 ..
> etc might be more definitively unique
well. the later in v2.
>
>
> Alan
>
-barry
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Arnd Bergmann @ 2011-10-13 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110130932350.17040@xanadu.home>
On Thursday 13 October 2011, Nicolas Pitre wrote:
> On Thu, 13 Oct 2011, Russell King - ARM Linux wrote:
> > Bypassing maintainers stinks - especially when there are unaddressed
> > comments outstanding. Nicolas has "simplified" my objections in this
> > request for you to pull - and has completely ignored the problem that
> > it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx
> > with no way for that to be provided.
I've removed it from the arm-soc for-next branch now and won't push it
unless you specifically ask me to.
> I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that
> this was approved by the EP93xx maintainers.
>
> Furthermore I said that I intended to make ZBOOT_ROM dependent on
> CONFIG_PHYS_OFFSET, given that PHYS_OFFSEt and zreladdr are intimately
> related which I also explained previously. This doesn't have to go in
> right away though. But if this is one of your _requirements_, I'd have
> appreciated you made it clearer instead of letting me to dry without any
> feedback, especially when I re-re-re-pinged you last week and before.
>
> So much for having lectured me on proper communication.
There is no point in arguing about who miscommunicated, or in assuming
evil intentions.
The rule for the arm-soc tree is very simple: if someone asks for a
branch to be included and it looks reasonable to me, it goes in.
If else someone has reasonable concerns over the code, it gets
removed again until the concerns are all resolved. Judging what
is reasonable is of course the hard part, but 90% of the time it's
pretty obvious.
Arnd
^ permalink raw reply
* [PATCH] atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes
From: Peter Korsgaard @ 2011-10-13 14:52 UTC (permalink / raw)
To: linux-arm-kernel
Allow framebuffer to be configured in 16bit mode when panel is wired in
(the default) BGR configuration, and don't claim to support 15bit input
modes, which the LCD controller cannot handle.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
drivers/video/atmel_lcdfb.c | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 7ca3eaf..143f6d9 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -418,24 +418,18 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
var->red.length = var->green.length = var->blue.length
= var->bits_per_pixel;
break;
- case 15:
case 16:
if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
/* RGB:565 mode */
var->red.offset = 11;
var->blue.offset = 0;
- var->green.length = 6;
- } else if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB555) {
- var->red.offset = 10;
- var->blue.offset = 0;
- var->green.length = 5;
} else {
- /* BGR:555 mode */
+ /* BGR:565 mode */
var->red.offset = 0;
- var->blue.offset = 10;
- var->green.length = 5;
+ var->blue.offset = 11;
}
var->green.offset = 5;
+ var->green.length = 6;
var->red.length = var->blue.length = 5;
break;
case 32:
--
1.7.6.3
^ permalink raw reply related
* [PATCH] arm: omap: Fix errors and warnings when building for one board
From: Sanjeev Premi @ 2011-10-13 14:53 UTC (permalink / raw)
To: linux-arm-kernel
When customizing omap2plus_defconfig to build for only
one board (omap3evm), I came across these warnings and
errors (filenames truncated):
arch/arm/mach-omap2/board-generic.c:76:20: warning: 'omap4_init' defined but not used
arch/arm/mach-omap2/built-in.o: In function `omap2420_init_early':
arch/arm/mach-omap2/io.c:364: undefined reference to `omap2_set_globals_242x'
arch/arm/mach-omap2/io.c:366: undefined reference to `omap2xxx_voltagedomains_init'
arch/arm/mach-omap2/io.c:367: undefined reference to `omap242x_powerdomains_init'
arch/arm/mach-omap2/io.c:368: undefined reference to `omap242x_clockdomains_init'
arch/arm/mach-omap2/io.c:369: undefined reference to `omap2420_hwmod_init'
arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early':
arch/arm/mach-omap2/io.c:376: undefined reference to `omap2_set_globals_243x'
arch/arm/mach-omap2/io.c:378: undefined reference to `omap2xxx_voltagedomains_init'
arch/arm/mach-omap2/io.c:379: undefined reference to `omap243x_powerdomains_init'
arch/arm/mach-omap2/io.c:380: undefined reference to `omap243x_clockdomains_init'
arch/arm/mach-omap2/io.c:381: undefined reference to `omap2430_hwmod_init'
arch/arm/mach-omap2/built-in.o: In function `omap4430_init_early':
arch/arm/mach-omap2/io.c:436: undefined reference to `omap2_set_globals_443x'
arch/arm/mach-omap2/io.c:438: undefined reference to `omap44xx_voltagedomains_init'
arch/arm/mach-omap2/io.c:439: undefined reference to `omap44xx_powerdomains_init'
arch/arm/mach-omap2/io.c:440: undefined reference to `omap44xx_clockdomains_init'
arch/arm/mach-omap2/io.c:441: undefined reference to `omap44xx_hwmod_init'
This patch fixes them.
Signed-off-by: Sanjeev Premi <premi@ti.com>
---
Adding ifdefs makes the code bit ugly and is prone to propagate
further. Not sure if DT will help here, but this patch would be
useful for people trying to build for individual boards.
Compile tested for OMAP3EVM.
Applies to linux-omap/master at:
fb4df0f : ARM: OMAP1: Fix warnings about enabling 32 KiHz timer
arch/arm/mach-omap2/board-generic.c | 8 ++++++++
arch/arm/mach-omap2/io.c | 6 ++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index d9ccb9d..b39ce79 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -34,20 +34,24 @@ static struct twl4030_platform_data sdp4430_twldata = {
.irq_end = TWL6030_IRQ_END,
};
+#if defined(CONFIG_ARCH_OMAP4)
static void __init omap4_i2c_init(void)
{
omap4_pmic_init("twl6030", &sdp4430_twldata);
}
+#endif
static struct twl4030_platform_data beagle_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end = TWL4030_IRQ_END,
};
+#if defined(CONFIG_ARCH_OMAP3)
static void __init omap3_i2c_init(void)
{
omap3_pmic_init("twl4030", &beagle_twldata);
}
+#endif
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = "simple-bus", },
@@ -73,17 +77,21 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
+#if defined(CONFIG_ARCH_OMAP4)
static void __init omap4_init(void)
{
omap4_i2c_init();
omap_generic_init();
}
+#endif
+#if defined(CONFIG_ARCH_OMAP3)
static void __init omap3_init(void)
{
omap3_i2c_init();
omap_generic_init();
}
+#endif
#if defined(CONFIG_SOC_OMAP2420)
static const char *omap242x_boards_compat[] __initdata = {
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index aa96538..ef3fb1e 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -359,6 +359,7 @@ static void __init omap_hwmod_init_postsetup(void)
omap_pm_if_early_init();
}
+#if defined(CONFIG_ARCH_OMAP2)
void __init omap2420_init_early(void)
{
omap2_set_globals_242x();
@@ -382,11 +383,13 @@ void __init omap2430_init_early(void)
omap_hwmod_init_postsetup();
omap2430_clk_init();
}
+#endif
/*
* Currently only board-omap3beagle.c should call this because of the
* same machine_id for 34xx and 36xx beagle.. Will get fixed with DT.
*/
+#if defined(CONFIG_ARCH_OMAP3)
void __init omap3_init_early(void)
{
omap2_set_globals_3xxx();
@@ -430,7 +433,9 @@ void __init ti816x_init_early(void)
omap_hwmod_init_postsetup();
omap3xxx_clk_init();
}
+#endif
+#if defined(CONFIG_ARCH_OMAP4)
void __init omap4430_init_early(void)
{
omap2_set_globals_443x();
@@ -442,6 +447,7 @@ void __init omap4430_init_early(void)
omap_hwmod_init_postsetup();
omap4xxx_clk_init();
}
+#endif
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
--
1.7.0.4
^ permalink raw reply related
* [RFC/PATCH 5/7] ARM: Move get_thread_info macro definition to <asm/assembler.h>
From: Russell King - ARM Linux @ 2011-10-13 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013144923.GE6300@arm.com>
On Thu, Oct 13, 2011 at 03:49:23PM +0100, Catalin Marinas wrote:
> On Thu, Oct 13, 2011 at 03:34:20PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Oct 12, 2011 at 02:04:33AM -0400, gdavis at mvista.com wrote:
> > > diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> > > index 78397d0..eaf4939 100644
> > > --- a/arch/arm/include/asm/assembler.h
> > > +++ b/arch/arm/include/asm/assembler.h
> > > @@ -36,6 +36,20 @@
> > > .endm
> > > #endif /* !CONFIG_THUMB2_KERNEL */
> > >
> > > + .macro preempt_disable, tsk, cnt
> > > + get_thread_info \tsk
> > > + ldr \cnt, [\tsk, #TI_PREEMPT]
> > > + add \cnt, \cnt, #1
> > > + str \cnt, [\tsk, #TI_PREEMPT]
> > > + .endm
> > > +
> > > + .macro preempt_enable, tsk, cnt
> > > + get_thread_info \tsk
> > > + ldr \cnt, [\tsk, #TI_PREEMPT]
> > > + sub \cnt, \cnt, #1
> > > + str \cnt, [\tsk, #TI_PREEMPT]
> > > + .endm
> > > +
> > > /*
> > > * Endian independent macros for shifting bytes within registers.
> > > */
> > >
> > >
> > > Not as efficient as it could be but I imagine the macros could
> > > be written to support optional load of \tsk and/or optional \tmp
> > > parameters to cover other common cases.
> >
> > It's actually not that simple either: if you disable preemption, then you
> > need to check for a preempt event after re-enabling preemption.
>
> That's not easily possible in assembly as calling a function would
> corrupt some registers. Is there any disadvantage with just doing the
> equivalent of preempt_enable_no_resched() for a few asm cases where this
> is needed?
It means you drop preemption reschedule events, which means that you can
no longer do hard-RT in any shape or form (because you're dropping the
reschedule for an indefinite amount of time.)
preempt_enable_no_resched() is fine if you're going to also put an
explicit check a bit later in the code path when it is convenient to
do so.
^ permalink raw reply
* [PATCH] arm: omap: Fix errors and warnings when building for one board
From: Russell King - ARM Linux @ 2011-10-13 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318517623-16066-1-git-send-email-premi@ti.com>
On Thu, Oct 13, 2011 at 08:23:43PM +0530, Sanjeev Premi wrote:
> +#if defined(CONFIG_ARCH_OMAP4)
Please use #ifdef unless you're intending to expand the condition.
^ permalink raw reply
* [PATCH 4/9] ARM: SPMP8000: Add ADC driver
From: Arnd Bergmann @ 2011-10-13 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013143857.GH5193@opensource.wolfsonmicro.com>
On Thursday 13 October 2011, Mark Brown wrote:
> > So. No new drivers in arch/arm. And I'm going to be saying no to any
> > new per-driver data structures in mach/*.h for stuff which should be
> > generic which haven't been justified for why they need to be different
> > from someone elses.
>
> The driver specific data structures should probably just be moving to
> include/linux/platform_data which is the approved location for that sort
> of thing.
Note that we also need someone to watch over that and say no to silly
platform_data definitions being put in there, e.g. using wildly different
ways of expressing the same things in almost-identical drivers, or
using function pointers where a simple data structure is enough.
Arnd
^ permalink raw reply
* [PATCH] arm: omap: Fix errors and warnings when building for one board
From: Premi, Sanjeev @ 2011-10-13 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013145615.GB22076@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Thursday, October 13, 2011 8:26 PM
> To: Premi, Sanjeev
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] arm: omap: Fix errors and warnings when
> building for one board
>
> On Thu, Oct 13, 2011 at 08:23:43PM +0530, Sanjeev Premi wrote:
> > +#if defined(CONFIG_ARCH_OMAP4)
>
> Please use #ifdef unless you're intending to expand the condition.
>
I tried to be consistent with existing use of #if defined() in the
file(s). Will change it.
Should I change the other instances as well?
~sanjeev
^ permalink raw reply
* [PATCH] arm: fix handling of nr_cpus
From: Russell King - ARM Linux @ 2011-10-13 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318508268.2300.67.camel@deneb.redhat.com>
On Thu, Oct 13, 2011 at 08:17:47AM -0400, Mark Salter wrote:
> On Wed, 2011-10-12 at 18:26 +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 11, 2011 at 09:31:04AM -0400, Mark Salter wrote:
> > > The current code duplicates the setup of the cpu_possible bitmap in the
> > > platform smp_init_cpus() function. Unfortunately, all of those places
> > > have the same bug where the nr_cpus kernel parameter is ignored. This patch
> > > consolidates the duplicated code in one place and fixes it to honor the
> > > nr_cpus parameter. This is accomplished by having smp_init_cpus() return
> > > the platform specific number of cores so that the caller (setup_arch) can
> > > set up the cpu_possible bitmap correctly for all platforms.
> >
> > Who says every platform we're going to see will always have CPUs 0..N ?
> > It's entirely possible that someone might want to have CPUs 0, 2, 3 as
> > possible CPUs but omit CPU1 for platform reasons.
>
> Good point. We could do that by not setting the cpu_present bit for the
> CPU we want to omit. Or we could leave the current platform cpu_possible
> setup as-is and add something like:
>
> for (i = nr_cpu_ids; i < NR_CPUS; i++)
> set_cpu_possible(i, false);
>
> to setup_arch after the call to smp_init_cpus.
As long as the mask bitmaps remain allocated above nr_cpu_ids, then yes.
If that changes in generic code, I suspect this kind of thing may be
missed.
I still wonder if doing this wouldn't be easier though - it results in
a consistent message across all platforms, which is important if we're
going to be checking against a user-passed value.
arch/arm/mach-exynos4/platsmp.c | 10 ++++------
arch/arm/mach-omap2/omap-smp.c | 10 ++++------
arch/arm/mach-realview/platsmp.c | 10 ++++------
arch/arm/mach-tegra/platsmp.c | 8 ++++----
arch/arm/mach-ux500/platsmp.c | 10 ++++------
5 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
index df6ef1b..7381f56 100644
--- a/arch/arm/mach-exynos4/platsmp.c
+++ b/arch/arm/mach-exynos4/platsmp.c
@@ -193,12 +193,10 @@ void __init smp_init_cpus(void)
ncores = scu_base ? scu_get_core_count(scu_base) : 1;
/* sanity check */
- if (ncores > NR_CPUS) {
- printk(KERN_WARNING
- "EXYNOS4: no. of cores (%d) greater than configured "
- "maximum of %d - clipping\n",
- ncores, NR_CPUS);
- ncores = NR_CPUS;
+ if (ncores > nr_cpu_ids) {
+ pr_warn("EXYNOS4: %u cores greater than maximum (%u), clipping\n",
+ ncores, nr_cpu_ids);
+ ncores = nr_cpu_ids;
}
for (i = 0; i < ncores; i++)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index ce65e93..ec95516 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -109,12 +109,10 @@ void __init smp_init_cpus(void)
ncores = scu_get_core_count(scu_base);
/* sanity check */
- if (ncores > NR_CPUS) {
- printk(KERN_WARNING
- "OMAP4: no. of cores (%d) greater than configured "
- "maximum of %d - clipping\n",
- ncores, NR_CPUS);
- ncores = NR_CPUS;
+ if (ncores > nr_cpu_ids) {
+ pr_warn("OMAP4: %u cores greater than maximum (%u), clipping\n",
+ ncores, nr_cpu_ids);
+ ncores = nr_cpu_ids;
}
for (i = 0; i < ncores; i++)
diff --git a/arch/arm/mach-realview/platsmp.c b/arch/arm/mach-realview/platsmp.c
index 4ae943b..4b33a72 100644
--- a/arch/arm/mach-realview/platsmp.c
+++ b/arch/arm/mach-realview/platsmp.c
@@ -52,12 +52,10 @@ void __init smp_init_cpus(void)
ncores = scu_base ? scu_get_core_count(scu_base) : 1;
/* sanity check */
- if (ncores > NR_CPUS) {
- printk(KERN_WARNING
- "Realview: no. of cores (%d) greater than configured "
- "maximum of %d - clipping\n",
- ncores, NR_CPUS);
- ncores = NR_CPUS;
+ if (ncores > nr_cpu_ids) {
+ pr_warn("Realview: %u cores greater than maximum (%u), clipping\n",
+ ncores, nr_cpu_ids);
+ ncores = nr_cpu_ids;
}
for (i = 0; i < ncores; i++)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 0886cbc..f779d5e 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -114,10 +114,10 @@ void __init smp_init_cpus(void)
{
unsigned int i, ncores = scu_get_core_count(scu_base);
- if (ncores > NR_CPUS) {
- printk(KERN_ERR "Tegra: no. of cores (%u) greater than configured (%u), clipping\n",
- ncores, NR_CPUS);
- ncores = NR_CPUS;
+ if (ncores > nr_cpu_ids) {
+ pr_warn("Tegra: %u cores greater than maximum (%u), clipping\n",
+ ncores, nr_cpu_ids);
+ ncores = nr_cpu_ids;
}
for (i = 0; i < ncores; i++)
diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
index a33df5f..3af3e5c 100644
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@ -156,12 +156,10 @@ void __init smp_init_cpus(void)
ncores = scu_base ? scu_get_core_count(scu_base) : 1;
/* sanity check */
- if (ncores > NR_CPUS) {
- printk(KERN_WARNING
- "U8500: no. of cores (%d) greater than configured "
- "maximum of %d - clipping\n",
- ncores, NR_CPUS);
- ncores = NR_CPUS;
+ if (ncores > nr_cpu_ids) {
+ pr_warn("U8500: %u cores greater than maximum (%u), clipping\n",
+ ncores, nr_cpu_ids);
+ ncores = nr_cpu_ids;
}
for (i = 0; i < ncores; i++)
^ permalink raw reply related
* [GIT PULL] Please pull tegra cleanups for 3.2
From: Arnd Bergmann @ 2011-10-13 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjVAJK2ArOdpYNmKa11vqCfppi8Ofc0qGn4WxuMxLvd_Q@mail.gmail.com>
On Thursday 13 October 2011, Olof Johansson wrote:
> Hi Arnd,
>
> Please pull the below branch of cleanups for the 3.2 merge window.
> They have been included in linux-next for a couple of days already.
I saw Russell had a comment on the macro name should be addressed.
I've put your series plus an additional commit to fix this up
into the tegra/cleanup branch. When you ack this patch, I'll include
this branch into next/cleanup and the for-next branch.
Thanks,
Arnd
---
ARM: tegra renamed __IOVADDR to IOMEM
This matches how other platforms name the same macro, as pointed
out by Russell King.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm/mach-tegra/include/mach/io.h b/arch/arm/mach-tegra/include/mach/io.h
index 971be4b..35a011f 100644
--- a/arch/arm/mach-tegra/include/mach/io.h
+++ b/arch/arm/mach-tegra/include/mach/io.h
@@ -34,25 +34,25 @@
*/
#ifdef __ASSEMBLY__
-#define __IOVADDR(x) (x)
+#define IOMEM(x) (x)
#else
-#define __IOVADDR(x) ((void __force __iomem *)(x))
+#define IOMEM(x) ((void __force __iomem *)(x))
#endif
#define IO_IRAM_PHYS 0x40000000
-#define IO_IRAM_VIRT __IOVADDR(0xFE400000)
+#define IO_IRAM_VIRT IOMEM(0xFE400000)
#define IO_IRAM_SIZE SZ_256K
#define IO_CPU_PHYS 0x50040000
-#define IO_CPU_VIRT __IOVADDR(0xFE000000)
+#define IO_CPU_VIRT IOMEM(0xFE000000)
#define IO_CPU_SIZE SZ_16K
#define IO_PPSB_PHYS 0x60000000
-#define IO_PPSB_VIRT __IOVADDR(0xFE200000)
+#define IO_PPSB_VIRT IOMEM(0xFE200000)
#define IO_PPSB_SIZE SZ_1M
#define IO_APB_PHYS 0x70000000
-#define IO_APB_VIRT __IOVADDR(0xFE300000)
+#define IO_APB_VIRT IOMEM(0xFE300000)
#define IO_APB_SIZE SZ_1M
#define IO_TO_VIRT_BETWEEN(p, st, sz) ((p) >= (st) && (p) < ((st) + (sz)))
^ permalink raw reply related
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Ming Lei @ 2011-10-13 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1110131029510.2026-100000@iolanthe.rowland.org>
Hi,
On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern <stern@rowland.harvard.edu>
>> Maybe we should understand the correct model of the ordering constraints
>> for the multiple device dependancies first, could you give a description or
>> some examples about it?
>
> The requirement is that devices must be capable of resuming in the
> order given by dpm_list, and they must be capable of suspending in
> the reverse order.
>
> Therefore if device A can't work unless device B is functional, then B
> must come before A in dpm_list.
If all devices can support async suspend and resume correctly, looks like
the device order given by dpm_list is not needed any longer, doesn't it?
thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH] arm: omap: Fix errors and warnings when building for one board
From: Russell King - ARM Linux @ 2011-10-13 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930257A57F4E@dbde02.ent.ti.com>
On Thu, Oct 13, 2011 at 08:36:19PM +0530, Premi, Sanjeev wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Thursday, October 13, 2011 8:26 PM
> > To: Premi, Sanjeev
> > Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH] arm: omap: Fix errors and warnings when
> > building for one board
> >
> > On Thu, Oct 13, 2011 at 08:23:43PM +0530, Sanjeev Premi wrote:
> > > +#if defined(CONFIG_ARCH_OMAP4)
> >
> > Please use #ifdef unless you're intending to expand the condition.
> >
>
> I tried to be consistent with existing use of #if defined() in the
> file(s). Will change it.
Thanks.
> Should I change the other instances as well?
I'd suggest not - though I can't really tell as I don't have a version
with that to look at.
^ permalink raw reply
* [PATCH v5 00/10] Per SoC descriptor
From: Marc Zyngier @ 2011-10-13 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013103237.GS21648@n2100.arm.linux.org.uk>
On 13/10/11 11:32, Russell King - ARM Linux wrote:
> On Mon, Oct 10, 2011 at 03:02:12PM +0100, Marc Zyngier wrote:
[...]
>> 65 files changed, 569 insertions(+), 149 deletions(-)
>
> This isn't particularly appealing for something that's supposed to
> be a clean up - it's introducing 400+ new lines of code. It looks like
> most of this comes from the platform stuff rather than core stuff.
>
> Can't we do any better with this? We really need things to be going
> in the other direction.
There is definitely room for improvement, by factoring in some common
code across platforms. But I see that as a second phase, and started by
just moving things to the SoC descriptor, all the code staying mostly
the same.
If we agree the method, then I'll start looking at reducing the platform
footprint by offering common methods that plug into the SMP ops.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v5 00/10] Per SoC descriptor
From: Russell King - ARM Linux @ 2011-10-13 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E9702F0.4070000@arm.com>
On Thu, Oct 13, 2011 at 04:25:36PM +0100, Marc Zyngier wrote:
> On 13/10/11 11:32, Russell King - ARM Linux wrote:
> > On Mon, Oct 10, 2011 at 03:02:12PM +0100, Marc Zyngier wrote:
>
> [...]
>
> >> 65 files changed, 569 insertions(+), 149 deletions(-)
> >
> > This isn't particularly appealing for something that's supposed to
> > be a clean up - it's introducing 400+ new lines of code. It looks like
> > most of this comes from the platform stuff rather than core stuff.
> >
> > Can't we do any better with this? We really need things to be going
> > in the other direction.
>
> There is definitely room for improvement, by factoring in some common
> code across platforms. But I see that as a second phase, and started by
> just moving things to the SoC descriptor, all the code staying mostly
> the same.
I was meaning without that - what concerns me is the size of increase
just to introduce this. It seems needlessly large.
I've also never been convinced by attempts to consolidate the hotplug
code - I've said this every time it's been suggested: I believe many
platforms just aren't trying to support hotplug CPU properly.
They've just copied the noddy Realview platform version - which is
noddy because ARMs platforms tend to have a total lack of power
management support on them. The best we can do is put them in a WFI
loop waiting to be re-awoken.
Real platforms surely must have better PM support than that, and so
copying the Realview implementation does not make sense - it's good
to see that _some_ platforms have made an effort, though they still
just return from platform_cpu_die(), rather than the intended path of
re-awaking via the standard bringup path. The return path from
platform_cpu_die() is supposed to be the last-ditch attempt if all else
has failed.
Note that doing that _also_ fixes the kexec problem that Will is
struggling with - if we can get that sorted we don't need to pen the
CPUs in a reserved area of memory while we kexec from one kernel to
the next - they can be kept in the boot loader while the kernel is
changed.
^ permalink raw reply
* [PATCH] [RESEND] ARM: tegra: devices.c should include devices.h
From: Stephen Warren @ 2011-10-13 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318467801-12184-1-git-send-email-olof@lixom.net>
Olof Johansson wrote at Wednesday, October 12, 2011 7:03 PM:
> Resolves lots of sparse warnings:
>
> arch/arm/mach-tegra/devices.c:102:24: warning: symbol 'tegra_i2c_device1' was not declared. Should it
> be static?
> arch/arm/mach-tegra/devices.c:112:24: warning: symbol 'tegra_i2c_device2' was not declared. Should it
> be static?
> arch/arm/mach-tegra/devices.c:122:24: warning: symbol 'tegra_i2c_device3' was not declared. Should it
> be static?
> arch/arm/mach-tegra/devices.c:132:24: warning: symbol 'tegra_i2c_device4' was not declared. Should it
> be static?
> [...]
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Stephen Warren <swarren@nvidia.com>
--
nvpublic
^ permalink raw reply
* [PATCH] ARM imx51: Add Armadeus systems APF51 support
From: Julien Boibessot @ 2011-10-13 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013143432.GB27048@S2100-06.ap.freescale.net>
On 13/10/2011 16:34, Shawn Guo wrote:
> NAK.
>
> It makes no sense to add yet another non-dt board file for imx51 at
> this point.
Ok. Sorry I didn't notice your previous patches for device tree on MX5.
> Why not starting using device tree?
As I am a total beginner with this thing, I will wait until it is
mainlined with one of the i.MX51 boards and resend my patch at that time.
Regards,
Julien
^ permalink raw reply
* [PATCH v4 8/8] ARM: pxa: move macros into gpio-pxa.c
From: Arnd Bergmann @ 2011-10-13 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318478825-17187-9-git-send-email-haojian.zhuang@marvell.com>
On Thursday 13 October 2011, Haojian Zhuang wrote:
> Move macro like PXA_GPLR(). Use pxa_gpio_bank_read()/pxa_gpio_bank_write()
> instead. And append pxa_gpio_pin_get()/ pxa_gpio_pin_set() /
> pxa_gpio_pin_clear() for operation on single GPIO pin.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Thanks, reading the patch I understand much more about the background of
how things are done in the gpio-pxa driver, but it also raises a few
more points:
> @@ -90,7 +91,8 @@ static int corgi_should_wakeup(unsigned int resume_on_alarm)
> {
> int is_resume = 0;
>
> - dev_dbg(sharpsl_pm.dev, "PXA_GPLR0 = %x,%x\n", PXA_GPLR(0), PEDR);
> + dev_dbg(sharpsl_pm.dev, "PXA_GPLR0 = %x,%x\n",
> + pxa_gpio_bank_read(PXA_GPLR, 0), PEDR);
>
> if ((PEDR & PXA_GPIO_bit(CORGI_GPIO_AC_IN))) {
> if (sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_ACIN)) {
> @@ -124,15 +126,18 @@ static int corgi_should_wakeup(unsigned int resume_on_alarm)
>
> static unsigned long corgi_charger_wakeup(void)
> {
> - return ~PXA_GPLR(CORGI_GPIO_AC_IN) & ( PXA_GPIO_bit(CORGI_GPIO_AC_IN)
> - | PXA_GPIO_bit(CORGI_GPIO_KEY_INT) | PXA_GPIO_bit(CORGI_GPIO_WAKEUP) );
> + unsigned long ret;
> + ret = pxa_gpio_pin_get(PXA_GPLR, CORGI_GPIO_AC_IN)
> + | pxa_gpio_pin_get(PXA_GPLR, CORGI_GPIO_KEY_INT)
> + | pxa_gpio_pin_get(PXA_GPLR, CORGI_GPIO_WAKEUP);
> + return !ret;
> }
Having code like this in the platform code suggests that there is still
something wrong: it would be much better if the platform could rely on
the generic GPIO API functions and not directly call functions from the
device driver. However, fixing this could become a larger effort and
the cleanups you do are definitely moving in the right direction,
so I'd say this can be left for another time. Maybe you could add a
FIXME comment here as a reminder.
> switch (gpio_type) {
> case PXA25X_GPIO:
> case PXA26X_GPIO:
> case PXA27X_GPIO:
> - af = (PXA_GAFR(gpio) >> ((gpio & 0xf) * 2)) & 0x3;
> - dir = PXA_GPDR(gpio) & PXA_GPIO_bit(gpio);
> + bank = pxa_gpio_to_bank(gpio);
> + data = readl_relaxed(pxa_gpio_regbase + PXA_GAFR
> + + PXA_BANK_OFF(bank));
> + af = (data >> ((gpio & 0xf) * 2)) & 0x3;
> + data = readl_relaxed(pxa_gpio_regbase + PXA_GPDR
> + + PXA_BANK_OFF(bank));
> + dir = pxa_gpio_pin_get(PXA_GPDR, gpio);
This looks much safer than before. I would have used the pxa_gpio_bank_read
function here to encapsulate the address computation, but that is just a
matter of personal preference, not of correctness.
> @@ -169,12 +206,12 @@ static int pxa_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
>
> spin_lock_irqsave(&gpio_lock, flags);
>
> - value = __raw_readl(base + GPDR_OFFSET);
> + value = __raw_readl(base + PXA_GPDR);
> if (__gpio_is_inverted(chip->base + offset))
> value |= mask;
> else
> value &= ~mask;
> - __raw_writel(value, base + GPDR_OFFSET);
> + __raw_writel(value, base + PXA_GPDR);
>
> spin_unlock_irqrestore(&gpio_lock, flags);
> return 0;
It would be better to convert all MMIO accesses to
readl_relaxed/writel_relaxed here. There is no strice need to do that
yet, but since you are touching these lines anyway, just use the
preferred interface. Same for all the other locations.
Note that according to the definition of the __raw MMIO accessors, the
acess is allowed to leaks outside of the spinlock, although that does
not currently happen on ARM AFAIK.
> +enum pxa_gpios {
> + PXA_GPLR = 0x00, /* GPIO Pin Level Registers */
> + PXA_GPDR = 0x0C, /* GPIO Pin Direction Registers */
> + PXA_GPSR = 0x18, /* GPIO Pin Output Set Registers */
> + PXA_GPCR = 0x24, /* GPIO Pin Output Clear Registers */
> + PXA_GRER = 0x30, /* GPIO Rising Edge Detect Registers */
> + PXA_GFER = 0x3C, /* GPIO Falling Edge Detect Registers */
> + PXA_GEDR = 0x48, /* GPIO Edge Detect Status Registers */
> + PXA_GAFR = 0x54, /* GPIO Alternate Function Select Registers */
> + PXA_ED_MASK = 0x9C, /* GPIO edge detection for AP side */
> +};
>
> /* NOTE: some PXAs have fewer on-chip GPIOs (like PXA255, with 85).
> * Those cases currently cause holes in the GPIO number space, the
> @@ -75,8 +44,17 @@ extern struct pxa_gpio_regs pxa_gpio_regs;
> */
> extern int pxa_last_gpio;
>
> -typedef int (*set_wake_t)(struct irq_data *d, unsigned int on);
> -
> extern int pxa_irq_to_gpio(int irq);
>
> +extern unsigned int pxa_gpio_pin_get(enum pxa_gpios reg, unsigned int gpio);
> +
> +extern void pxa_gpio_pin_set(enum pxa_gpios reg, unsigned int gpio);
> +
> +extern void pxa_gpio_pin_clear(enum pxa_gpios reg, unsigned int gpio);
> +
> +extern unsigned int pxa_gpio_bank_read(enum pxa_gpios reg, unsigned int bank);
> +
> +extern void pxa_gpio_bank_write(enum pxa_gpios reg, unsigned int value,
> + unsigned int bank);
Unfortunately, it seems that you still need to keep the header file around
because of the way it's used by the platform code. Again, I would suggest
adding a comment in the header explaining that this is not actually the
desired situation.
Arnd
^ permalink raw reply
* [PATCH v3.1-rc9] ARM: populate processor tag in proc-cpuinfo for Uni-processor.
From: Srinivas KANDAGATLA @ 2011-10-13 15:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
This patch populates processor tag in /proc/cpuinfo for uni-processor too.
All the processors in kernel code do that.
Without this patch tools like cyclesoak which use processor tag to determine number of
cpus will be broken.
run cyclesoak -C on uniprocessor system to reproduce.
originally detected as part of
https://bugzilla.stlinux.com/show_bug.cgi?id=14674 triage.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Chris Smith <chris.smith@st.com>
---
Hi All,
We recently encountered issue while running cyclesoak on ARM-uniprocessor system,
What we have noticed it that /proc/cpuinfo does not have "processor" tag when its uniprocessor, which looked incorrect.
All the processors code in kernel do populate this tag for both uni and multi processor systems.
This patch just add processor tag for cpuinfo for ARM uni-processor systems.
Thanks,
srini
arch/arm/kernel/setup.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 621acad..4364071 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -807,7 +807,7 @@ static const char *hwcap_str[] = {
static int c_show(struct seq_file *m, void *v)
{
- int i;
+ int i = 0;
seq_printf(m, "Processor\t: %s rev %d (%s)\n",
cpu_name, read_cpuid_id() & 15, elf_platform);
@@ -825,6 +825,7 @@ static int c_show(struct seq_file *m, void *v)
(per_cpu(cpu_data, i).loops_per_jiffy / (5000UL/HZ)) % 100);
}
#else /* CONFIG_SMP */
+ seq_printf(m, "processor\t: %d\n", i);
seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
loops_per_jiffy / (500000/HZ),
(loops_per_jiffy / (5000/HZ)) % 100);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/4] mmc: mmci: Bugfix in pio read for small packets
From: Russell King - ARM Linux @ 2011-10-13 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E92AB66.1030406@stericsson.com>
On Mon, Oct 10, 2011 at 10:23:02AM +0200, Ulf Hansson wrote:
> Linus Walleij wrote:
>> On Sat, Oct 8, 2011 at 11:10 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Fri, Oct 07, 2011 at 03:45:48PM +0200, Ulf Hansson wrote:
>>>
>>> Well, the patch system says that each one depends on the previous one,
>>> and the first one in the series contains the PIO read thing.
>>>
>>> Do 7108/1 onwards depend on 7106/1 and 7107/1 ?
>>
>> Probably my fault, since I was helping Ulf out with the patch tracker
>> introduction.
>>
>> The patches should be pretty much semantically orthogonal as
>> far as I can tell, the only reason dependency was stated that way
>> was that I couldn't tell from head-parsing whether there were
>> syntactical dependencies. (And wanted to avoid the annoyance
>> of non-applying patches...)
>>
>> So if they apply, they are independent AFAICT.
>
> 7108/1 and 7109/1, have real dependencies. Otherwise there none.
Ok, I assume that those depend on the first two patches.
So, I tried applying 7110/1 .. 7112/1 but the first rejects because it
doesn't have the non-power-of-2 support patch applied (7107/1). And
it seems sensible that 7107/1 depends on 7106/1 (the PIO patch) which
I believe to be a problem.
Therefore, I don't think any of these can be applied without the
initial PIO patch.
One thing I haven't yet mentioned is about the non-power-of-2 support -
surely this can only be supported if blksz_datactrl16 is set? If so,
shouldn't it key off that? I don't see how it could otherwise support
non-power of 2 block sizes with just a log2 of the block size programmed
into the data control register.
^ permalink raw reply
* [PATCH] ARM: tegra: update defconfig
From: Stephen Warren @ 2011-10-13 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318478219-9462-1-git-send-email-olof@lixom.net>
Olof Johansson wrote at Wednesday, October 12, 2011 9:57 PM:
> Refresh tegra_defconfig:
>
> New options enabled: RTC, SPI, USB and USB_STORAGE together with
> corresponding tegra drivers. Also enable some of the common usb ethernet
> adapters.
>
> Finally, enable new merged boards (Ventana) and the generic devicetree board.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
This transitively enables USE_OF by default. For Tegra, that's a good
thing. However, it does mean we won't be able to detect code that only
compiles with USE_OF enabled, which might affect other platform's
buildability if we're talking about core code. I'm not sure if we should
be concerned about this or not, or if ARM should select USE_OF now?
--
nvpublic
^ permalink raw reply
* [PATCH] mmc: mmci: Do not release spinlock in request_end
From: Jon Medhurst (Tixy) @ 2011-10-13 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013142914.GZ21648@n2100.arm.linux.org.uk>
On Thu, 2011-10-13 at 15:29 +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 11, 2011 at 04:06:41PM +0200, Ulf Hansson wrote:
> > The patch "mmc: core: move ->request() call from atomic context",
> > is the reason to why this change is possible. This simplifies the
> > error handling code execution path quite a lot and potentially also
> > fixes some error handling hang problems.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
>
> This doesn't look right:
>
> void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
> {
> if (err && cmd->retries) {
> host->ops->request(host, mrq);
>
> So, not dropping the spinlock results in calling the request function
> with the spinlock held - and as the request function then goes on to
> lock the spinlock, we will deadlock.
Indeed, deadlock behaviour at this point is what I see with this patch
on a Versatile Express board running 3.0-rc9.
--
Tixy
^ permalink raw reply
* [PATCH] ARM: tegra: update defconfig
From: Stephen Warren @ 2011-10-13 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318478219-9462-1-git-send-email-olof@lixom.net>
Olof Johansson wrote at Wednesday, October 12, 2011 9:57 PM:
> Refresh tegra_defconfig:
>
> New options enabled: RTC, SPI, USB and USB_STORAGE together with
> corresponding tegra drivers. Also enable some of the common usb ethernet
> adapters.
>
> Finally, enable new merged boards (Ventana) and the generic devicetree board.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
We should also enable ASoC (sound) support. Do you want to rev the patch, or
should I submit a patch on top of yours?
--
nvpublic
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Alan Stern @ 2011-10-13 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACVXFVMoac7psbfO6UdDvNux4c8bQYS4YNUdz1C-o+CiJzyuZA@mail.gmail.com>
On Thu, 13 Oct 2011, Ming Lei wrote:
> Hi,
>
> On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern <stern@rowland.harvard.edu>
> >> Maybe we should understand the correct model of the ordering constraints
> >> for the multiple device dependancies first, could you give a description or
> >> some examples about it?
> >
> > The requirement is that devices must be capable of resuming in the
> > order given by dpm_list, and they must be capable of suspending in
> > the reverse order.
> >
> > Therefore if device A can't work unless device B is functional, then B
> > must come before A in dpm_list.
>
> If all devices can support async suspend and resume correctly, looks like
> the device order given by dpm_list is not needed any longer, doesn't it?
It _is_ needed, because the user can disable async suspend/resume via
/sys/power/pm_async.
Also, not all devices do support async suspend/resume.
Alan Stern
^ permalink raw reply
* [PATCH 2/2] arm/mx5: add device tree support for imx51 babbage
From: Julien Boibessot @ 2011-10-13 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317389747-24589-3-git-send-email-shawn.guo@linaro.org>
On 30/09/2011 15:35, Shawn Guo wrote:
> It adds device tree support for imx51 babbage board.
>
cut
> diff --git a/arch/arm/mach-mx5/imx51-dt.c b/arch/arm/mach-mx5/imx51-dt.c
> new file mode 100644
> index 0000000..0878441
> --- /dev/null
> +++ b/arch/arm/mach-mx5/imx51-dt.c
> @@ -0,0 +1,116 @@
cut
> +
> +static void __init imx51_timer_init(void)
> +{
> + mx51_clocks_init(32768, 24000000, 22579200, 0);
> +}
^ 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