* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Lorenzo Pieralisi @ 2012-12-12 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50C7C16B.7050106@codeaurora.org>
On Tue, Dec 11, 2012 at 11:27:39PM +0000, Stephen Boyd wrote:
> On 12/11/12 08:38, Will Deacon wrote:
> > diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> > index cd95664..f58248f 100644
> > --- a/arch/arm/mm/cache-v7.S
> > +++ b/arch/arm/mm/cache-v7.S
> > @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all)
> > ENTRY(v7_flush_dcache_louis)
> > dmb @ ensure ordering with previous memory accesses
> > mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr
> > - ands r3, r0, #0xe00000 @ extract LoUIS from clidr
> > + ALT_SMP(ands r3, r0, #(7 << 21)) @ extract LoUIS from clidr
> > + ALT_UP(ands r3, r0, #(7 << 27)) @ extract LoUU from clidr
> > mov r3, r3, lsr #20 @ r3 = LoUIS * 2
>
> You need to fix this mov as well, right?
And after doing that I think the suspend finisher will still have
to call flush_cache_all() since LoUU = 1 on A8, L2 is not cleaned
and that's probably what we want if it can be retained.
What about this (compile tested) ?
Lorenzo
--->8
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index cd95664..036f80f 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -44,8 +44,9 @@ ENDPROC(v7_flush_icache_all)
ENTRY(v7_flush_dcache_louis)
dmb @ ensure ordering with previous memory accesses
mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr
- ands r3, r0, #0xe00000 @ extract LoUIS from clidr
- mov r3, r3, lsr #20 @ r3 = LoUIS * 2
+ ALT_SMP(lsr r3, r0, #20) @ r3 = clidr[31:20]
+ ALT_UP(lsr r3, r0, #26) @ r3 = clidr[31:26]
+ ands r3, r3, #0xe @ r3 = LoUIS/LoUU * 2
moveq pc, lr @ return if level = 0
mov r10, #0 @ r10 (starting level) = 0
b flush_levels @ start flushing cache levels
^ permalink raw reply related
* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Will Deacon @ 2012-12-12 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50C7C16B.7050106@codeaurora.org>
On Tue, Dec 11, 2012 at 11:27:39PM +0000, Stephen Boyd wrote:
> On 12/11/12 08:38, Will Deacon wrote:
> > diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> > index cd95664..f58248f 100644
> > --- a/arch/arm/mm/cache-v7.S
> > +++ b/arch/arm/mm/cache-v7.S
> > @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all)
> > ENTRY(v7_flush_dcache_louis)
> > dmb @ ensure ordering with previous memory accesses
> > mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr
> > - ands r3, r0, #0xe00000 @ extract LoUIS from clidr
> > + ALT_SMP(ands r3, r0, #(7 << 21)) @ extract LoUIS from clidr
> > + ALT_UP(ands r3, r0, #(7 << 27)) @ extract LoUU from clidr
> > mov r3, r3, lsr #20 @ r3 = LoUIS * 2
>
> You need to fix this mov as well, right?
Ha, nice catch. So the original patch ended up with a ridiculously high
level number and would've flushed L2, hence we will need to retest with the
fix below...
Will
--->8
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index cd95664..7539ec2 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -44,8 +44,10 @@ ENDPROC(v7_flush_icache_all)
ENTRY(v7_flush_dcache_louis)
dmb @ ensure ordering with previous memory accesses
mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr
- ands r3, r0, #0xe00000 @ extract LoUIS from clidr
- mov r3, r3, lsr #20 @ r3 = LoUIS * 2
+ ALT_SMP(ands r3, r0, #(7 << 21)) @ extract LoUIS from clidr
+ ALT_UP(ands r3, r0, #(7 << 27)) @ extract LoUU from clidr
+ ALT_SMP(mov r3, r3, lsr #20) @ r3 = LoUIS * 2
+ ALT_UP(mov r3, r3, lsr #26) @ r3 = LoUU * 2
moveq pc, lr @ return if level = 0
mov r10, #0 @ r10 (starting level) = 0
b flush_levels @ start flushing cache levels
^ permalink raw reply related
* Re: [PATCH v2] ARM: shmobile: r8a7779: Fix GPIO input reg addresses
From: phil.edworthy @ 2012-12-12 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2861660.bMP77HcQxX@avalon>
Hi Simon, Laurent,
(resend as plain text)
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> To: Phil Edworthy <phil.edworthy@renesas.com>,
> Cc: Simon <horms@verge.net.au>, linux-sh@vger.kernel.org, linux-arm-
> kernel@lists.infradead.org, Magnus <magnus.damm@gmail.com>, Laurent
> Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Date: 11/12/2012 11:39
> Subject: Re: [PATCH v2] ARM: shmobile: r8a7779: Fix GPIO input reg
addresses
>
> On Tuesday 11 December 2012 11:34:17 Phil Edworthy wrote:
> > The INDTx register addresses were wrong.
> >
> > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
>
> You can add
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Please scrap this patch. I just found out that it screws up the GPIO
outputs. The current code assumes the same register is used for both input
and output, which is not the case. It needs a bit of work to fix this.
Thanks
Phil
^ permalink raw reply
* [PATCH] ARM: shmobile: r8a7740: add TMU timer support
From: Kuninori Morimoto @ 2012-12-12 10:08 UTC (permalink / raw)
To: linux-sh
This patch enabled TMU0 timer on r8a7740.
But TMU1 timer is not supported yet
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/arm/mach-shmobile/clock-r8a7740.c | 6 +-
arch/arm/mach-shmobile/setup-r8a7740.c | 94 ++++++++++++++++++++++++++++++++
2 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 6729e00..f35a51b 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -554,10 +554,14 @@ static struct clk_lookup lookups[] = {
/* MSTP32 clocks */
CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", &mstp_clks[MSTP100]),
- CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP111]),
+ CLKDEV_DEV_ID("sh_tmu.3", &mstp_clks[MSTP111]),
+ CLKDEV_DEV_ID("sh_tmu.4", &mstp_clks[MSTP111]),
+ CLKDEV_DEV_ID("sh_tmu.5", &mstp_clks[MSTP111]),
CLKDEV_DEV_ID("i2c-sh_mobile.0", &mstp_clks[MSTP116]),
CLKDEV_DEV_ID("sh_mobile_lcdc_fb.1", &mstp_clks[MSTP117]),
CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP125]),
+ CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP125]),
+ CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP125]),
CLKDEV_DEV_ID("sh_mobile_ceu.0", &mstp_clks[MSTP127]),
CLKDEV_DEV_ID("sh_mobile_ceu.1", &mstp_clks[MSTP128]),
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 11bb1d9..9cb0eb5 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -268,6 +268,97 @@ static struct platform_device cmt10_device = {
.num_resources = ARRAY_SIZE(cmt10_resources),
};
+/* TMU */
+static struct sh_timer_config tmu00_platform_data = {
+ .name = "TMU00",
+ .channel_offset = 0x4,
+ .timer_bit = 0,
+ .clockevent_rating = 200,
+};
+
+static struct resource tmu00_resources[] = {
+ [0] = {
+ .name = "TMU00",
+ .start = 0xfff80008,
+ .end = 0xfff80014 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0xe80),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device tmu00_device = {
+ .name = "sh_tmu",
+ .id = 0,
+ .dev = {
+ .platform_data = &tmu00_platform_data,
+ },
+ .resource = tmu00_resources,
+ .num_resources = ARRAY_SIZE(tmu00_resources),
+};
+
+static struct sh_timer_config tmu01_platform_data = {
+ .name = "TMU01",
+ .channel_offset = 0x10,
+ .timer_bit = 1,
+ .clocksource_rating = 200,
+};
+
+static struct resource tmu01_resources[] = {
+ [0] = {
+ .name = "TMU01",
+ .start = 0xfff80014,
+ .end = 0xfff80020 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0xea0),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device tmu01_device = {
+ .name = "sh_tmu",
+ .id = 1,
+ .dev = {
+ .platform_data = &tmu01_platform_data,
+ },
+ .resource = tmu01_resources,
+ .num_resources = ARRAY_SIZE(tmu01_resources),
+};
+
+static struct sh_timer_config tmu02_platform_data = {
+ .name = "TMU02",
+ .channel_offset = 0x1C,
+ .timer_bit = 2,
+ .clocksource_rating = 200,
+};
+
+static struct resource tmu02_resources[] = {
+ [0] = {
+ .name = "TMU02",
+ .start = 0xfff80020,
+ .end = 0xfff8002C - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0xec0),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device tmu02_device = {
+ .name = "sh_tmu",
+ .id = 2,
+ .dev = {
+ .platform_data = &tmu02_platform_data,
+ },
+ .resource = tmu02_resources,
+ .num_resources = ARRAY_SIZE(tmu02_resources),
+};
+
static struct platform_device *r8a7740_early_devices[] __initdata = {
&scif0_device,
&scif1_device,
@@ -279,6 +370,9 @@ static struct platform_device *r8a7740_early_devices[] __initdata = {
&scif7_device,
&scifb_device,
&cmt10_device,
+ &tmu00_device,
+ &tmu01_device,
+ &tmu02_device,
};
/* DMA */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 00/77] SH pin control and GPIO rework with OF support
From: Laurent Pinchart @ 2012-12-12 1:43 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1353974596-30033-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Linus,
On Friday 07 December 2012 19:35:33 Laurent Pinchart wrote:
> On Thursday 06 December 2012 02:34:39 Laurent Pinchart wrote:
> > On Saturday 01 December 2012 23:55:35 Linus Walleij wrote:
> > > On Tue, Nov 27, 2012 at 1:01 AM, Laurent Pinchart wrote:
> > > > Here's the second version of the SH pin control and GPIO rework
> > > > patches.
> > > > I've added OF support for PFC instantiation and GPIO mappings that was
> > > > missing from v1. PINCTRL bindings are still missing and will come
> > > > soon.
> > >
> > > So I've tried the only way I could to review this by cloning your tree
> > > and actually inspecting the end result ... overall it's looking very
> > > good!
>
> > > Here are assorted comments:
> [snip]
>
> > > - You're using the method to add ranges from the pinctrl side of
> > > things. This is basically deprecated with the changes to gpiolib
> > > I make in this merge window. If you study the way I changed
> > > the pinctrl-u300.c and pinctrl-coh901.c to switch the registration
> > > from being done in the pin controller to being done in the
> > > gpiolib part, you will get the picture. The big upside is that
> > > (A) makes the pin and GPIO references to the local GPIO
> > > chip and pin controller and (B) that this supports adding ranges
> > > from the device tree, which is probably what you want in the
> > > end...
> >
> > OK, I will have a look at the code.
>
> Do you have a tree with those patches ?
I should have looked myself for the tree before asking, sorry. I'll have a
look at the changes you've added there and will rework the PFC driver
accordingly.
I will send a v3 with fixes based on your comments. I might omit the DT
patches this time and send a pull request, as the patch set is getting too big
for my taste. Even though the result won't be perfect (yet :-)), it's still an
improvement, and I'll send additional patches on top of that.
> > > - This stuff in setup_data_regs():
> > > rp->reg_shadow = gpio_read_raw_reg(drp->mapped_reg, drp->reg_width);
> > >
> > > You know, I think shadow registers is just another name for
> > > regmap-mmio. Please consult drivers/base/regmap/regmap-mmio.c and
> > > tell me if I'm wrong. It's not like I'm going to require you to
> > > convert this to regmap from day 1 if this is legacy stuff but it's
> > > probably the same thing.
> >
> > I'll have a look at it.
>
> I've considered regmap but I think it's a bit overkill. True, the reg_shadow
> is a different name for regmap-mmio (or rather for a small subset of it),
> but I already have a data structure instance for each register due to other
> requirements of the driver, so storing the cached value there is pretty
> much free.
>
> I might end up reworking the data registers related code in which case I
> will try to use regmap.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Stephen Boyd @ 2012-12-11 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121211163843.GH16759@mudshark.cambridge.arm.com>
On 12/11/12 08:38, Will Deacon wrote:
> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> index cd95664..f58248f 100644
> --- a/arch/arm/mm/cache-v7.S
> +++ b/arch/arm/mm/cache-v7.S
> @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all)
> ENTRY(v7_flush_dcache_louis)
> dmb @ ensure ordering with previous memory accesses
> mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr
> - ands r3, r0, #0xe00000 @ extract LoUIS from clidr
> + ALT_SMP(ands r3, r0, #(7 << 21)) @ extract LoUIS from clidr
> + ALT_UP(ands r3, r0, #(7 << 27)) @ extract LoUU from clidr
> mov r3, r3, lsr #20 @ r3 = LoUIS * 2
You need to fix this mov as well, right?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Guennadi Liakhovetski @ 2012-12-11 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121211163843.GH16759@mudshark.cambridge.arm.com>
On Tue, 11 Dec 2012, Will Deacon wrote:
> On Tue, Dec 11, 2012 at 04:33:13PM +0000, Will Deacon wrote:
> > On Tue, Dec 11, 2012 at 04:07:56PM +0000, Guennadi Liakhovetski wrote:
> > > Git bisect identified this patch, in the mainline as
> > >
> > > commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560
> > > Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Date: Fri Sep 7 11:06:57 2012 +0530
> > >
> > > ARM: kernel: update cpu_suspend code to use cache LoUIS operations
> > >
> > > as the culprit of the broken wake up from STR on mackerel, based on an
> > > sh7372 A8 SoC. .config attached.
> >
> > My guess is that because Cortex-A8 does not implement the MP extensions,
> > the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at
> > all (I can see an early exit in v7_flush_dcache_louis).
> >
> > Lorenzo -- how is this supposed to work for uniprocessor CPUs?
>
> Bah, forgot to ask you if the following patch helps...
>
> Will
>
> --->8
>
> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> index cd95664..f58248f 100644
> --- a/arch/arm/mm/cache-v7.S
> +++ b/arch/arm/mm/cache-v7.S
> @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all)
> ENTRY(v7_flush_dcache_louis)
> dmb @ ensure ordering with previous memory accesses
> mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr
> - ands r3, r0, #0xe00000 @ extract LoUIS from clidr
> + ALT_SMP(ands r3, r0, #(7 << 21)) @ extract LoUIS from clidr
> + ALT_UP(ands r3, r0, #(7 << 27)) @ extract LoUU from clidr
> mov r3, r3, lsr #20 @ r3 = LoUIS * 2
> moveq pc, lr @ return if level = 0
> mov r10, #0 @ r10 (starting level) = 0
[... later]
> > Yes, it does.
>
> Cracking, can I add you tested-by please?
Sure:
Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Will Deacon @ 2012-12-11 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1212111807170.2140@axis700.grange>
On Tue, Dec 11, 2012 at 05:07:35PM +0000, Guennadi Liakhovetski wrote:
> Hi Will
>
> On Tue, 11 Dec 2012, Will Deacon wrote:
>
> > On Tue, Dec 11, 2012 at 04:33:13PM +0000, Will Deacon wrote:
> > > On Tue, Dec 11, 2012 at 04:07:56PM +0000, Guennadi Liakhovetski wrote:
> > > > Git bisect identified this patch, in the mainline as
> > > >
> > > > commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560
> > > > Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > > Date: Fri Sep 7 11:06:57 2012 +0530
> > > >
> > > > ARM: kernel: update cpu_suspend code to use cache LoUIS operations
> > > >
> > > > as the culprit of the broken wake up from STR on mackerel, based on an
> > > > sh7372 A8 SoC. .config attached.
> > >
> > > My guess is that because Cortex-A8 does not implement the MP extensions,
> > > the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at
> > > all (I can see an early exit in v7_flush_dcache_louis).
> > >
> > > Lorenzo -- how is this supposed to work for uniprocessor CPUs?
> >
> > Bah, forgot to ask you if the following patch helps...
>
> Yes, it does.
Cracking, can I add you tested-by please?
Will
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Guennadi Liakhovetski @ 2012-12-11 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121211163843.GH16759@mudshark.cambridge.arm.com>
Hi Will
On Tue, 11 Dec 2012, Will Deacon wrote:
> On Tue, Dec 11, 2012 at 04:33:13PM +0000, Will Deacon wrote:
> > On Tue, Dec 11, 2012 at 04:07:56PM +0000, Guennadi Liakhovetski wrote:
> > > Git bisect identified this patch, in the mainline as
> > >
> > > commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560
> > > Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Date: Fri Sep 7 11:06:57 2012 +0530
> > >
> > > ARM: kernel: update cpu_suspend code to use cache LoUIS operations
> > >
> > > as the culprit of the broken wake up from STR on mackerel, based on an
> > > sh7372 A8 SoC. .config attached.
> >
> > My guess is that because Cortex-A8 does not implement the MP extensions,
> > the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at
> > all (I can see an early exit in v7_flush_dcache_louis).
> >
> > Lorenzo -- how is this supposed to work for uniprocessor CPUs?
>
> Bah, forgot to ask you if the following patch helps...
Yes, it does.
Thanks
Guennadi
>
> Will
>
> --->8
>
> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> index cd95664..f58248f 100644
> --- a/arch/arm/mm/cache-v7.S
> +++ b/arch/arm/mm/cache-v7.S
> @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all)
> ENTRY(v7_flush_dcache_louis)
> dmb @ ensure ordering with previous memory accesses
> mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr
> - ands r3, r0, #0xe00000 @ extract LoUIS from clidr
> + ALT_SMP(ands r3, r0, #(7 << 21)) @ extract LoUIS from clidr
> + ALT_UP(ands r3, r0, #(7 << 27)) @ extract LoUU from clidr
> mov r3, r3, lsr #20 @ r3 = LoUIS * 2
> moveq pc, lr @ return if level = 0
> mov r10, #0 @ r10 (starting level) = 0
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Will Deacon @ 2012-12-11 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121211163313.GG16759@mudshark.cambridge.arm.com>
On Tue, Dec 11, 2012 at 04:33:13PM +0000, Will Deacon wrote:
> On Tue, Dec 11, 2012 at 04:07:56PM +0000, Guennadi Liakhovetski wrote:
> > Git bisect identified this patch, in the mainline as
> >
> > commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560
> > Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Date: Fri Sep 7 11:06:57 2012 +0530
> >
> > ARM: kernel: update cpu_suspend code to use cache LoUIS operations
> >
> > as the culprit of the broken wake up from STR on mackerel, based on an
> > sh7372 A8 SoC. .config attached.
>
> My guess is that because Cortex-A8 does not implement the MP extensions,
> the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at
> all (I can see an early exit in v7_flush_dcache_louis).
>
> Lorenzo -- how is this supposed to work for uniprocessor CPUs?
Bah, forgot to ask you if the following patch helps...
Will
--->8
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index cd95664..f58248f 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all)
ENTRY(v7_flush_dcache_louis)
dmb @ ensure ordering with previous memory accesses
mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr
- ands r3, r0, #0xe00000 @ extract LoUIS from clidr
+ ALT_SMP(ands r3, r0, #(7 << 21)) @ extract LoUIS from clidr
+ ALT_UP(ands r3, r0, #(7 << 27)) @ extract LoUU from clidr
mov r3, r3, lsr #20 @ r3 = LoUIS * 2
moveq pc, lr @ return if level = 0
mov r10, #0 @ r10 (starting level) = 0
^ permalink raw reply related
* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Will Deacon @ 2012-12-11 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1212111655050.29758@axis700.grange>
On Tue, Dec 11, 2012 at 04:07:56PM +0000, Guennadi Liakhovetski wrote:
> Hi all
>
> On Thu, 20 Sep 2012, Dave Martin wrote:
>
> > On Thu, Sep 20, 2012 at 11:25:14AM +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Sep 19, 2012 at 02:46:58PM +0100, Dave Martin wrote:
> > > > On Tue, Sep 18, 2012 at 05:35:33PM +0100, Lorenzo Pieralisi wrote:
> > > > > In processors like A15/A7 L2 cache is unified and integrated within the
> > > > > processor cache hierarchy, so that it is not considered an outer cache
> > > > > anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
> > > > > all cache levels up to Level of Coherency (LoC) that includes
> > > > > the L2 unified cache.
> > > > >
> > > > > When a single CPU is suspended (CPU idle) a complete L2 clean is not
> > > > > required, so generic cpu_suspend code must clean the data cache using the
> > > > > newly introduced cache LoUIS function.
>
> Git bisect identified this patch, in the mainline as
>
> commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560
> Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Date: Fri Sep 7 11:06:57 2012 +0530
>
> ARM: kernel: update cpu_suspend code to use cache LoUIS operations
>
> as the culprit of the broken wake up from STR on mackerel, based on an
> sh7372 A8 SoC. .config attached.
My guess is that because Cortex-A8 does not implement the MP extensions,
the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at
all (I can see an early exit in v7_flush_dcache_louis).
Lorenzo -- how is this supposed to work for uniprocessor CPUs?
Will
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
From: Guennadi Liakhovetski @ 2012-12-11 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120920110439.GB2117@linaro.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1303 bytes --]
Hi all
On Thu, 20 Sep 2012, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:25:14AM +0100, Lorenzo Pieralisi wrote:
> > On Wed, Sep 19, 2012 at 02:46:58PM +0100, Dave Martin wrote:
> > > On Tue, Sep 18, 2012 at 05:35:33PM +0100, Lorenzo Pieralisi wrote:
> > > > In processors like A15/A7 L2 cache is unified and integrated within the
> > > > processor cache hierarchy, so that it is not considered an outer cache
> > > > anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
> > > > all cache levels up to Level of Coherency (LoC) that includes
> > > > the L2 unified cache.
> > > >
> > > > When a single CPU is suspended (CPU idle) a complete L2 clean is not
> > > > required, so generic cpu_suspend code must clean the data cache using the
> > > > newly introduced cache LoUIS function.
Git bisect identified this patch, in the mainline as
commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560
Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Date: Fri Sep 7 11:06:57 2012 +0530
ARM: kernel: update cpu_suspend code to use cache LoUIS operations
as the culprit of the broken wake up from STR on mackerel, based on an
sh7372 A8 SoC. .config attached.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
[-- Attachment #2: Type: TEXT/PLAIN, Size: 5075 bytes --]
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_EXPERIMENTAL=y
CONFIG_CROSS_COMPILE="arm-none-linux-gnueabi-"
CONFIG_LOCALVERSION="-ap4"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_ARCH_SHMOBILE=y
CONFIG_ARCH_SH7372=y
CONFIG_MACH_AP4EVB=y
CONFIG_MACH_MACKEREL=y
CONFIG_MEMORY_SIZE=0x20000000
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_EM_TIMER_STI is not set
# CONFIG_ARM_THUMB is not set
CONFIG_AEABI=y
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_USE_OF=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CMDLINE="console=ttySC0,115200 console=tty1 earlyprintk=sh-sci.0,115200"
CONFIG_KEXEC=y
CONFIG_VFP=y
CONFIG_NEON=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_PM_RUNTIME=y
CONFIG_NET=y
CONFIG_PACKET=m
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_DIAG=m
CONFIG_INET_UDP_DIAG=m
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_IPV6_SIT is not set
CONFIG_CFG80211=m
CONFIG_CFG80211_WEXT=y
CONFIG_MAC80211=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_PROC_DEVICETREE=y
# CONFIG_BLK_DEV is not set
CONFIG_NETDEVICES=y
CONFIG_NETCONSOLE=y
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_VENDOR_CHELSIO is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_SEEQ is not set
CONFIG_SMSC911X=y
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_MDIO_BITBANG=y
# CONFIG_WLAN is not set
CONFIG_INPUT_MOUSEDEV=m
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_KEYBOARD_ATKBD is not set
CONFIG_KEYBOARD_TCA6416=y
CONFIG_KEYBOARD_SH_KEYSC=y
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_TSC2007=y
CONFIG_TOUCHSCREEN_ST1232=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_ADXL34X=m
# CONFIG_SERIO is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=8
CONFIG_SERIAL_SH_SCI_CONSOLE=y
CONFIG_SERIAL_SH_SCI_DMA=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_SH_MOBILE=y
CONFIG_SPI=y
CONFIG_SPI_GPIO=m
CONFIG_GPIO_SYSFS=y
CONFIG_POWER_SUPPLY=y
# CONFIG_HWMON is not set
CONFIG_SSB=m
CONFIG_SSB_SDIOHOST=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DUMMY=y
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
CONFIG_VIDEO_ADV_DEBUG=y
CONFIG_VIDEO_OV7670=m
CONFIG_VIDEO_VIVI=m
CONFIG_V4L_PLATFORM_DRIVERS=y
CONFIG_VIDEO_SH_VOU=m
CONFIG_SOC_CAMERA=m
CONFIG_SOC_CAMERA_IMX074=m
CONFIG_SOC_CAMERA_MT9M111=m
CONFIG_SOC_CAMERA_MT9T112=m
CONFIG_SOC_CAMERA_MT9V022=m
CONFIG_SOC_CAMERA_PLATFORM=m
CONFIG_SOC_CAMERA_OV5642=m
CONFIG_VIDEO_SH_MOBILE_CSI2=m
CONFIG_VIDEO_SH_MOBILE_CEU=m
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_VIDEO_MEM2MEM_TESTDEV=m
CONFIG_FB=y
CONFIG_FB_SH_MOBILE_LCDC=y
# CONFIG_LCD_CLASS_DEVICE is not set
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_SOUND=m
CONFIG_SND=m
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_DRIVERS is not set
# CONFIG_SND_ARM is not set
# CONFIG_SND_SPI is not set
CONFIG_SND_SOC=m
CONFIG_SND_SOC_SH4_FSI=m
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=m
CONFIG_MMC_CLKGATE=y
CONFIG_MMC_SDHI=m
CONFIG_MMC_SH_MMCIF=m
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
CONFIG_DMADEVICES=y
CONFIG_SH_DMAE=m
CONFIG_DMATEST=m
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
# CONFIG_DNOTIFY is not set
CONFIG_FANOTIFY=y
CONFIG_VFAT_FS=m
CONFIG_TMPFS=y
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NFS_FS=y
CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_15=m
CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_FREE=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_FTRACE is not set
# CONFIG_ARM_UNWIND is not set
CONFIG_DEBUG_USER=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_DES=m
^ permalink raw reply
* Re: [PATCH 1/6] ARM: clocksource: Initialise early
From: Laurent Pinchart @ 2012-12-11 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355195254-4563-2-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
Thanks for the patch.
Could you please CC LKML on this one ? It targets a wider audience than the
SH-specific patches.
On Tuesday 11 December 2012 12:07:29 Simon Horman wrote:
> Initialise clock sources early, since some subsystems rely on them to
> initialize
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> ---
>
> v3
> * Initial post
> ---
> drivers/Makefile | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index a16a8d0..eba9b58 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -37,6 +37,11 @@ obj-$(CONFIG_XEN) += xen/
> # regulators early, since some subsystems rely on them to initialize
> obj-$(CONFIG_REGULATOR) += regulator/
>
> +# clocksource early, since some subsystems rely on them to initialize
> +ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
> +obj-y += clocksource/
> +endif
> +
> # tty/ comes before char/ so that the VT console is the boot-time
> # default.
> obj-y += tty/
> @@ -114,9 +119,6 @@ obj-y += firmware/
> obj-$(CONFIG_CRYPTO) += crypto/
> obj-$(CONFIG_SUPERH) += sh/
> obj-$(CONFIG_ARCH_SHMOBILE) += sh/
> -ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
> -obj-y += clocksource/
> -endif
> obj-$(CONFIG_DCA) += dca/
> obj-$(CONFIG_HID) += hid/
> obj-$(CONFIG_PPC_PS3) += ps3/
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 1/2] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
From: Laurent Pinchart @ 2012-12-11 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121211.191042.313387652.hdk@igel.co.jp>
Hi Eiraku-san,
On Tuesday 11 December 2012 19:10:42 Hideki EIRAKU wrote:
> On Mon, 10 Dec 2012 16:55:58 +0100 Laurent Pinchart wrote:
> > On Monday 15 October 2012 17:34:52 Hideki EIRAKU wrote:
> >> This is the Renesas IPMMU driver and IOMMU API implementation.
> >>
> >> The IPMMU module supports the MMU function and the PMB function.
> >
> > That sentence make me believe that both MMU and PMB were supported by the
> > driver, as "module" often refers to Linux kernel modules in this context.
> > Maybe you could replace "module" by "hardware module".
>
> OK,
>
> >> The MMU function provides address translation by pagetable compatible
> >> with ARMv6. The PMB function provides address translation including
> >> tile-linear translation. This patch implements the MMU function.
> >>
> >> The iommu driver does not register a platform driver directly because:
> >> - the register space of the MMU function and the PMB function
> >> have a common register (used for settings flush), so they should
> >> ideally have a way to appropriately share this register.
> >> - the MMU function uses the IOMMU API while the PMB function does not.
> >> - the two functions may be used independently.
> >>
> >> Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
> >> ---
> >>
> >> arch/arm/mach-shmobile/Kconfig | 6 +
> >> arch/arm/mach-shmobile/Makefile | 3 +
> >> arch/arm/mach-shmobile/include/mach/ipmmu.h | 16 ++
> >> arch/arm/mach-shmobile/ipmmu.c | 150 ++++++++++++
> >> drivers/iommu/Kconfig | 56 +++++
> >> drivers/iommu/Makefile | 1 +
> >> drivers/iommu/shmobile-iommu.c | 352 +++++++++++++++++++++
> >> 7 files changed, 584 insertions(+), 0 deletions(-)
> >> create mode 100644 arch/arm/mach-shmobile/include/mach/ipmmu.h
> >> create mode 100644 arch/arm/mach-shmobile/ipmmu.c
> >> create mode 100644 drivers/iommu/shmobile-iommu.c
> >
> > What is the reason for splitting the driver in two files ? Can't you put
> > all the code in drivers/iommu/shmobile-iommu.c ? Storing driver code in
> > arch/* is discouraged.
>
> The reason is that I described in the above text. The PMB function is
> completely different from the MMU function but both functions are on
> the same IPMMU hardware module and sharing the register space. I think
> that a driver using the PMB part which is not yet released should not
> depend on the Linux's iommu interface, so I split the driver in two
> files: the IPMMU platform driver part (in arch/arm/mach-shmobile/) and
> Linux's iommu part (in drivers/iommu/). For the IPMMU platform driver part,
> do you have any suggestions other than arch/* where this should go? It is a
> generic platform device.
I think both parts should go to drivers/iommu/. You can keep the code split
across two files, but I think you should register a single platform driver.
The IPMMU is a single hardware module, so it should be handled by a single
driver. That driver can expose two different APIs (IOMMU and whatever API will
be used for PMB), and you can make those APIs selectable as Kconfig options,
but they should in my opinion be implemented in a single driver.
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program; if not, write to the Free Software
> >> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
> >> USA
> >
> > You can remove this last paragraph, we don't want to patch every file in
> > the kernel if the FSF moves to a new building :-)
>
> OK, I will remove the paragraph.
>
> >> + for (dev = ipmmu_devices; dev; dev = dev->archdata.iommu) {
> >> + if (arm_iommu_attach_device(dev, iommu_mapping))
> >> + pr_err("arm_iommu_attach_device failed\n");
> >> + }
> >> +err:
> >> + spin_unlock(&lock_add);
> >> + return 0;
> >> +}
> >> +
> >> +void ipmmu_add_device(struct device *dev)
> >> +{
> >> + spin_lock(&lock_add);
> >> + dev->archdata.iommu = ipmmu_devices;
> >> + ipmmu_devices = dev;
> >
> > That looks a bit hackish to me. I'd like to suggest a different approach,
> > that would be compatible with supporting multiple IPMMU instances.
> >
> > dev->archdata.iommu should point to a new sh_ipmmu_arch_data structure
> > that would contain an IPMMU name (const char *) and a pointer to a struct
> > shmobile_iommu_priv.
> >
> > ipmmu_add_device() would take a new IPMMU name argument, allocate an
> > sh_ipmmu_arch_data instance dynamically and initialize its name field to
> > the name passed to the function. The shmobile_iommu_priv pointer would be
> > set to NULL. No other operation would be performed (you will likely get
> > rid of the global ipmmu_devices and iommu_mapping variables).
> >
> > Then, the attach_dev operation handler would retrieve the
> > dev->archdata.iommu pointer, cast that to an sh_ipmmu_arch_data, and
> > retrieve the IPMMU associated with the name (either by walking a
> > driver-global list of IPMMUs, or by using driver_find_device()).
> >
> > This mechanism would get rid of several global variables in the driver
> > (several of them would move to the shmobile_ipmmu_priv structure - which I
> > would have named shmobile_ipmmu or even sh_ipmmu, but that's up to you)
> > and add support for several IPMMU instances (there's 3 of them in the
> > sh7372, even if we only need to support one right now it's still a good
> > practice to design the driver in a way that multiple instances can be
> > supported).
> >
> > Could you try to rework the driiver in that direction ? You can have a
> > look at the OMAP IOMMU driver if you need sample code, and obviously feel
> > free to contact me if you have any question.
>
> I agree about this is hackish. I don't mean to make an excuse,
And I'm not blaming you :-)
> but I could not find good sample code because no other drivers in the
> upstream kernel use the arm_iommu_attach_device() API.
This is all pretty new code, so reference implementations are missing, that's
true.
> But I will try to modify the driver to support for several IPMMU
> instances.
Thank you. I can also give it a try if you want, just drop me an e-mail.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] ARM: shmobile: r8a7779: Fix GPIO input reg addresses
From: Laurent Pinchart @ 2012-12-11 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355225657-18731-1-git-send-email-phil.edworthy@renesas.com>
On Tuesday 11 December 2012 11:34:17 Phil Edworthy wrote:
> The INDTx register addresses were wrong.
>
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
You can add
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
:-)
> ---
> v2:
> Included SoB line this time - doh!
>
> arch/arm/mach-shmobile/pfc-r8a7779.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/pfc-r8a7779.c
> b/arch/arm/mach-shmobile/pfc-r8a7779.c index 15f6a48..717e058 100644
> --- a/arch/arm/mach-shmobile/pfc-r8a7779.c
> +++ b/arch/arm/mach-shmobile/pfc-r8a7779.c
> @@ -2585,13 +2585,13 @@ static struct pinmux_cfg_reg pinmux_config_regs[] > { };
>
> static struct pinmux_data_reg pinmux_data_regs[] = {
> - { PINMUX_DATA_REG("INDT0", 0xffc40008, 32) { GP_INDT(0) } },
> - { PINMUX_DATA_REG("INDT1", 0xffc41008, 32) { GP_INDT(1) } },
> - { PINMUX_DATA_REG("INDT2", 0xffc42008, 32) { GP_INDT(2) } },
> - { PINMUX_DATA_REG("INDT3", 0xffc43008, 32) { GP_INDT(3) } },
> - { PINMUX_DATA_REG("INDT4", 0xffc44008, 32) { GP_INDT(4) } },
> - { PINMUX_DATA_REG("INDT5", 0xffc45008, 32) { GP_INDT(5) } },
> - { PINMUX_DATA_REG("INDT6", 0xffc46008, 32) {
> + { PINMUX_DATA_REG("INDT0", 0xffc4000c, 32) { GP_INDT(0) } },
> + { PINMUX_DATA_REG("INDT1", 0xffc4100c, 32) { GP_INDT(1) } },
> + { PINMUX_DATA_REG("INDT2", 0xffc4200c, 32) { GP_INDT(2) } },
> + { PINMUX_DATA_REG("INDT3", 0xffc4300c, 32) { GP_INDT(3) } },
> + { PINMUX_DATA_REG("INDT4", 0xffc4400c, 32) { GP_INDT(4) } },
> + { PINMUX_DATA_REG("INDT5", 0xffc4500c, 32) { GP_INDT(5) } },
> + { PINMUX_DATA_REG("INDT6", 0xffc4600c, 32) {
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, GP_6_8_DATA,
> GP_6_7_DATA, GP_6_6_DATA, GP_6_5_DATA, GP_6_4_DATA,
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2] ARM: shmobile: r8a7779: Fix GPIO input reg addresses
From: Phil Edworthy @ 2012-12-11 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16942826.W5hEBZUpzF@avalon>
The INDTx register addresses were wrong.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
---
v2:
Included SoB line this time - doh!
arch/arm/mach-shmobile/pfc-r8a7779.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-shmobile/pfc-r8a7779.c b/arch/arm/mach-shmobile/pfc-r8a7779.c
index 15f6a48..717e058 100644
--- a/arch/arm/mach-shmobile/pfc-r8a7779.c
+++ b/arch/arm/mach-shmobile/pfc-r8a7779.c
@@ -2585,13 +2585,13 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
};
static struct pinmux_data_reg pinmux_data_regs[] = {
- { PINMUX_DATA_REG("INDT0", 0xffc40008, 32) { GP_INDT(0) } },
- { PINMUX_DATA_REG("INDT1", 0xffc41008, 32) { GP_INDT(1) } },
- { PINMUX_DATA_REG("INDT2", 0xffc42008, 32) { GP_INDT(2) } },
- { PINMUX_DATA_REG("INDT3", 0xffc43008, 32) { GP_INDT(3) } },
- { PINMUX_DATA_REG("INDT4", 0xffc44008, 32) { GP_INDT(4) } },
- { PINMUX_DATA_REG("INDT5", 0xffc45008, 32) { GP_INDT(5) } },
- { PINMUX_DATA_REG("INDT6", 0xffc46008, 32) {
+ { PINMUX_DATA_REG("INDT0", 0xffc4000c, 32) { GP_INDT(0) } },
+ { PINMUX_DATA_REG("INDT1", 0xffc4100c, 32) { GP_INDT(1) } },
+ { PINMUX_DATA_REG("INDT2", 0xffc4200c, 32) { GP_INDT(2) } },
+ { PINMUX_DATA_REG("INDT3", 0xffc4300c, 32) { GP_INDT(3) } },
+ { PINMUX_DATA_REG("INDT4", 0xffc4400c, 32) { GP_INDT(4) } },
+ { PINMUX_DATA_REG("INDT5", 0xffc4500c, 32) { GP_INDT(5) } },
+ { PINMUX_DATA_REG("INDT6", 0xffc4600c, 32) {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, GP_6_8_DATA,
GP_6_7_DATA, GP_6_6_DATA, GP_6_5_DATA, GP_6_4_DATA,
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] ARM: shmobile: r8a7779: Fix GPIO input reg addresses
From: Laurent Pinchart @ 2012-12-11 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355219295-4279-1-git-send-email-phil.edworthy@renesas.com>
Hi Phil,
Thank you for the patch.
Your SoB line is missing, have you forgotten to commit with -s ?
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
On Tuesday 11 December 2012 09:48:15 Phil Edworthy wrote:
> The INDTx register addresses were wrong.
> ---
> arch/arm/mach-shmobile/pfc-r8a7779.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/pfc-r8a7779.c
> b/arch/arm/mach-shmobile/pfc-r8a7779.c index 15f6a48..717e058 100644
> --- a/arch/arm/mach-shmobile/pfc-r8a7779.c
> +++ b/arch/arm/mach-shmobile/pfc-r8a7779.c
> @@ -2585,13 +2585,13 @@ static struct pinmux_cfg_reg pinmux_config_regs[] > { };
>
> static struct pinmux_data_reg pinmux_data_regs[] = {
> - { PINMUX_DATA_REG("INDT0", 0xffc40008, 32) { GP_INDT(0) } },
> - { PINMUX_DATA_REG("INDT1", 0xffc41008, 32) { GP_INDT(1) } },
> - { PINMUX_DATA_REG("INDT2", 0xffc42008, 32) { GP_INDT(2) } },
> - { PINMUX_DATA_REG("INDT3", 0xffc43008, 32) { GP_INDT(3) } },
> - { PINMUX_DATA_REG("INDT4", 0xffc44008, 32) { GP_INDT(4) } },
> - { PINMUX_DATA_REG("INDT5", 0xffc45008, 32) { GP_INDT(5) } },
> - { PINMUX_DATA_REG("INDT6", 0xffc46008, 32) {
> + { PINMUX_DATA_REG("INDT0", 0xffc4000c, 32) { GP_INDT(0) } },
> + { PINMUX_DATA_REG("INDT1", 0xffc4100c, 32) { GP_INDT(1) } },
> + { PINMUX_DATA_REG("INDT2", 0xffc4200c, 32) { GP_INDT(2) } },
> + { PINMUX_DATA_REG("INDT3", 0xffc4300c, 32) { GP_INDT(3) } },
> + { PINMUX_DATA_REG("INDT4", 0xffc4400c, 32) { GP_INDT(4) } },
> + { PINMUX_DATA_REG("INDT5", 0xffc4500c, 32) { GP_INDT(5) } },
> + { PINMUX_DATA_REG("INDT6", 0xffc4600c, 32) {
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, GP_6_8_DATA,
> GP_6_7_DATA, GP_6_6_DATA, GP_6_5_DATA, GP_6_4_DATA,
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 1/2] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
From: Hideki EIRAKU @ 2012-12-11 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3581114.cp3kRzV18i@avalon>
Hi Laurent,
Thank you for your comments.
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v4 1/2] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
Date: Mon, 10 Dec 2012 16:55:58 +0100
> On Monday 15 October 2012 17:34:52 Hideki EIRAKU wrote:
>> This is the Renesas IPMMU driver and IOMMU API implementation.
>>
>> The IPMMU module supports the MMU function and the PMB function.
>
> That sentence make me believe that both MMU and PMB were supported by the
> driver, as "module" often refers to Linux kernel modules in this context.
> Maybe you could replace "module" by "hardware module".
OK,
>> The MMU function provides address translation by pagetable compatible with
>> ARMv6. The PMB function provides address translation including tile-linear
>> translation. This patch implements the MMU function.
>>
>> The iommu driver does not register a platform driver directly because:
>> - the register space of the MMU function and the PMB function
>> have a common register (used for settings flush), so they should ideally
>> have a way to appropriately share this register.
>> - the MMU function uses the IOMMU API while the PMB function does not.
>> - the two functions may be used independently.
>>
>> Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
>> ---
>> arch/arm/mach-shmobile/Kconfig | 6 +
>> arch/arm/mach-shmobile/Makefile | 3 +
>> arch/arm/mach-shmobile/include/mach/ipmmu.h | 16 ++
>> arch/arm/mach-shmobile/ipmmu.c | 150 ++++++++++++
>> drivers/iommu/Kconfig | 56 +++++
>> drivers/iommu/Makefile | 1 +
>> drivers/iommu/shmobile-iommu.c | 352 ++++++++++++++++++++++++
>> 7 files changed, 584 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/mach-shmobile/include/mach/ipmmu.h
>> create mode 100644 arch/arm/mach-shmobile/ipmmu.c
>> create mode 100644 drivers/iommu/shmobile-iommu.c
>
> What is the reason for splitting the driver in two files ? Can't you put all
> the code in drivers/iommu/shmobile-iommu.c ? Storing driver code in arch/* is
> discouraged.
The reason is that I described in the above text. The PMB function is
completely different from the MMU function but both functions are on
the same IPMMU hardware module and sharing the register space. I think
that a driver using the PMB part which is not yet released should not
depend on the Linux's iommu interface, so I split the driver in two
files: the IPMMU platform driver part (in arch/arm/mach-shmobile/) and
Linux's iommu part (in drivers/iommu/). For the IPMMU platform driver part,
do you have any suggestions other than arch/* where this should go? It is
a generic platform device.
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
>> USA
>
> You can remove this last paragraph, we don't want to patch every file in the
> kernel if the FSF moves to a new building :-)
OK, I will remove the paragraph.
>> + for (dev = ipmmu_devices; dev; dev = dev->archdata.iommu) {
>> + if (arm_iommu_attach_device(dev, iommu_mapping))
>> + pr_err("arm_iommu_attach_device failed\n");
>> + }
>> +err:
>> + spin_unlock(&lock_add);
>> + return 0;
>> +}
>> +
>> +void ipmmu_add_device(struct device *dev)
>> +{
>> + spin_lock(&lock_add);
>> + dev->archdata.iommu = ipmmu_devices;
>> + ipmmu_devices = dev;
>
> That looks a bit hackish to me. I'd like to suggest a different approach, that
> would be compatible with supporting multiple IPMMU instances.
>
> dev->archdata.iommu should point to a new sh_ipmmu_arch_data structure that
> would contain an IPMMU name (const char *) and a pointer to a struct
> shmobile_iommu_priv.
>
> ipmmu_add_device() would take a new IPMMU name argument, allocate an
> sh_ipmmu_arch_data instance dynamically and initialize its name field to the
> name passed to the function. The shmobile_iommu_priv pointer would be set to
> NULL. No other operation would be performed (you will likely get rid of the
> global ipmmu_devices and iommu_mapping variables).
>
> Then, the attach_dev operation handler would retrieve the dev->archdata.iommu
> pointer, cast that to an sh_ipmmu_arch_data, and retrieve the IPMMU associated
> with the name (either by walking a driver-global list of IPMMUs, or by using
> driver_find_device()).
>
> This mechanism would get rid of several global variables in the driver
> (several of them would move to the shmobile_ipmmu_priv structure - which I
> would have named shmobile_ipmmu or even sh_ipmmu, but that's up to you) and
> add support for several IPMMU instances (there's 3 of them in the sh7372, even
> if we only need to support one right now it's still a good practice to design
> the driver in a way that multiple instances can be supported).
>
> Could you try to rework the driiver in that direction ? You can have a look at
> the OMAP IOMMU driver if you need sample code, and obviously feel free to
> contact me if you have any question.
I agree about this is hackish. I don't mean to make an excuse, but I
could not find good sample code because no other drivers in the
upstream kernel use the arm_iommu_attach_device() API.
But I will try to modify the driver to support for several IPMMU
instances.
--
Hideki EIRAKU <hdk@igel.co.jp>
^ permalink raw reply
* [PATCH] ARM: shmobile: r8a7779: Fix GPIO input reg addresses
From: Phil Edworthy @ 2012-12-11 9:48 UTC (permalink / raw)
To: linux-arm-kernel
The INDTx register addresses were wrong.
---
arch/arm/mach-shmobile/pfc-r8a7779.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-shmobile/pfc-r8a7779.c b/arch/arm/mach-shmobile/pfc-r8a7779.c
index 15f6a48..717e058 100644
--- a/arch/arm/mach-shmobile/pfc-r8a7779.c
+++ b/arch/arm/mach-shmobile/pfc-r8a7779.c
@@ -2585,13 +2585,13 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
};
static struct pinmux_data_reg pinmux_data_regs[] = {
- { PINMUX_DATA_REG("INDT0", 0xffc40008, 32) { GP_INDT(0) } },
- { PINMUX_DATA_REG("INDT1", 0xffc41008, 32) { GP_INDT(1) } },
- { PINMUX_DATA_REG("INDT2", 0xffc42008, 32) { GP_INDT(2) } },
- { PINMUX_DATA_REG("INDT3", 0xffc43008, 32) { GP_INDT(3) } },
- { PINMUX_DATA_REG("INDT4", 0xffc44008, 32) { GP_INDT(4) } },
- { PINMUX_DATA_REG("INDT5", 0xffc45008, 32) { GP_INDT(5) } },
- { PINMUX_DATA_REG("INDT6", 0xffc46008, 32) {
+ { PINMUX_DATA_REG("INDT0", 0xffc4000c, 32) { GP_INDT(0) } },
+ { PINMUX_DATA_REG("INDT1", 0xffc4100c, 32) { GP_INDT(1) } },
+ { PINMUX_DATA_REG("INDT2", 0xffc4200c, 32) { GP_INDT(2) } },
+ { PINMUX_DATA_REG("INDT3", 0xffc4300c, 32) { GP_INDT(3) } },
+ { PINMUX_DATA_REG("INDT4", 0xffc4400c, 32) { GP_INDT(4) } },
+ { PINMUX_DATA_REG("INDT5", 0xffc4500c, 32) { GP_INDT(5) } },
+ { PINMUX_DATA_REG("INDT6", 0xffc4600c, 32) {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, GP_6_8_DATA,
GP_6_7_DATA, GP_6_6_DATA, GP_6_5_DATA, GP_6_4_DATA,
--
1.7.5.4
^ permalink raw reply related
* [PATCH 6/6] ARM: mach-shmobile: kzm9g: Reference DT implementation
From: Simon Horman @ 2012-12-11 3:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355195254-4563-1-git-send-email-horms+renesas@verge.net.au>
Provide alternate board code for the kzm9g to demonstrate
how DT may be used given the current state of driver
device tree support. This is intended to act as a reference
for mach-shmobile developers.
Some notes:
* Brings up the GIC interrupt handler using device tree
* Brings up the following device using device tree:
- MMCIF (MMC)
* Does not bring up the INTC interrupt controller at all,
thus external devices may not be used. In particular,
the SMSC ethernet device may not be used and thus
NFS root may not be used.
* Uses existing C code and not device tree to initialise the following,
which are needed for a working board:
- SCIF (Serial)
- CMT (Clock)
- PFC (GPIO)
To use this alternate board code instead of the normal board code,
CONFIG_MACH_KZM9G_REFERENCE should be selected in the kernel config.
And the sh73a0-kzm9g-reference.dtb flattened device tree blob should be used.
*** Please note that the clock initialisation shcheme used in
this patch does not currently work with SMP as there
is a yet to be resolved lock-up in workqueue initialisation.
CONFIG_SMP must be disabled when using this code. ***
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3
* Compile board-kzm9g.c even if CONFIG_MACH_KZM9G_REFERENCE is selected,
it can co-exist with board-kzm9g-reference.c
v2
* Do not initialise touchscreen, it requires the INTC interrupt controller
but for now this configuration only has the GIC interrupt controller.
* Define mmcif and sdhi in SoC dtsi and reference in board dts.
* Do not initialise SDHI, the driver needs to be updated
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 37 +++++++++
arch/arm/mach-shmobile/Kconfig | 10 +++
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/board-kzm9g-reference.c | 99 ++++++++++++++++++++++++
5 files changed, 149 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
create mode 100644 arch/arm/mach-shmobile/board-kzm9g-reference.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..c606375 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -77,7 +77,8 @@ dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb
dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
r8a7740-armadillo800eva.dtb \
- sh73a0-kzm9g.dtb
+ sh73a0-kzm9g.dtb \
+ sh73a0-kzm9g-reference.dtb
dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
spear1340-evb.dtb
dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
new file mode 100644
index 0000000..588016e
--- /dev/null
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -0,0 +1,37 @@
+/*
+ * Device Tree Source for the KZM-A9-GT board
+ *
+ * Copyright (C) 2012 Horms Solutions Ltd.
+ *
+ * Based on sh73a0-kzm9g.dts
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "sh73a0-reference.dtsi"
+
+/ {
+ model = "KZM-A9-GT";
+ compatible = "renesas,kzm9g-reference", "renesas,sh73a0";
+
+ memory {
+ device_type = "memory";
+ reg = <0x41000000 0x1e800000>;
+ };
+
+ fixedregulator1v8: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+};
+
+&mmcif {
+ vmmc-supply = <&fixedregulator1v8>;
+ vqmmc-supply = <&fixedregulator1v8>;
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 8ae100c..ca95c2b 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -136,6 +136,16 @@ config MACH_KZM9G
select SND_SOC_AK4642 if SND_SIMPLE_CARD
select USE_OF
+config MACH_KZM9G_REFERENCE
+ bool "KZM-A9-GT board - Reference Device Tree Implementation"
+ depends on MACH_KZM9G
+ ---help---
+ Use reference implementation of KZM-A9-GT board support
+ which makes as greater use of device tree at the expense
+ of not supporting a number of devices.
+
+ This is intended to aid developers
+
comment "SH-Mobile System Configuration"
config CPU_HAS_INTEVT
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index e3556c6..b4d3920 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_MACH_MARZEN) += board-marzen.o
obj-$(CONFIG_MACH_ARMADILLO800EVA) += board-armadillo800eva.o
obj-$(CONFIG_MACH_KZM9D) += board-kzm9d.o
obj-$(CONFIG_MACH_KZM9G) += board-kzm9g.o
+obj-$(CONFIG_MACH_KZM9G_REFERENCE) += board-kzm9g-reference.o
# Framework support
obj-$(CONFIG_SMP) += $(smp-y)
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
new file mode 100644
index 0000000..140781c
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -0,0 +1,99 @@
+/*
+ * KZM-A9-GT board support - Reference Device Tree Implementation
+ *
+ * Copyright (C) 2012 Horms Solutions Ltd.
+ *
+ * Based on board-kzm9g.c
+ * Copyright (C) 2012 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/input.h>
+#include <linux/of_platform.h>
+#include <mach/sh73a0.h>
+#include <mach/common.h>
+#include <asm/hardware/cache-l2x0.h>
+#include <asm/hardware/gic.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static void __init kzm_init(void)
+{
+ /* enable SCIFA4 */
+ gpio_request(GPIO_FN_SCIFA4_TXD, NULL);
+ gpio_request(GPIO_FN_SCIFA4_RXD, NULL);
+ gpio_request(GPIO_FN_SCIFA4_RTS_, NULL);
+ gpio_request(GPIO_FN_SCIFA4_CTS_, NULL);
+
+ /* enable MMCIF */
+ gpio_request(GPIO_FN_MMCCLK0, NULL);
+ gpio_request(GPIO_FN_MMCCMD0_PU, NULL);
+ gpio_request(GPIO_FN_MMCD0_0_PU, NULL);
+ gpio_request(GPIO_FN_MMCD0_1_PU, NULL);
+ gpio_request(GPIO_FN_MMCD0_2_PU, NULL);
+ gpio_request(GPIO_FN_MMCD0_3_PU, NULL);
+ gpio_request(GPIO_FN_MMCD0_4_PU, NULL);
+ gpio_request(GPIO_FN_MMCD0_5_PU, NULL);
+ gpio_request(GPIO_FN_MMCD0_6_PU, NULL);
+ gpio_request(GPIO_FN_MMCD0_7_PU, NULL);
+
+ /* I2C 3 */
+ gpio_request(GPIO_FN_PORT27_I2C_SCL3, NULL);
+ gpio_request(GPIO_FN_PORT28_I2C_SDA3, NULL);
+
+#ifdef CONFIG_CACHE_L2X0
+ /* Early BRESP enable, Shared attribute override enable, 64K*8way */
+ l2x0_init(IOMEM(0xf0100000), 0x40460000, 0x82000fff);
+#endif
+
+ sh73a0_add_standard_devices_dt();
+}
+
+static void kzm9g_restart(char mode, const char *cmd)
+{
+#define RESCNT2 IOMEM(0xe6188020)
+ /* Do soft power on reset */
+ writel((1 << 31), RESCNT2);
+}
+
+static const char *kzm9g_boards_compat_dt[] __initdata = {
+ "renesas,kzm9g-reference",
+ NULL,
+};
+
+/* Please note that the clock initialisation shcheme used in
+ * sh73a0_add_early_devices_dt() and sh73a0_add_standard_devices_dt()
+ * does not work with SMP as there is a yet to be resolved lock-up in
+ * workqueue initialisation.
+ *
+ * CONFIG_SMP should be disabled when using this code.
+ */
+DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
+ .smp = smp_ops(sh73a0_smp_ops),
+ .map_io = sh73a0_map_io,
+ .init_early = sh73a0_add_early_devices_dt,
+ .nr_irqs = NR_IRQS_LEGACY,
+ .init_irq = sh73a0_init_irq_dt,
+ .handle_irq = gic_handle_irq,
+ .init_machine = kzm_init,
+ .init_late = shmobile_init_late,
+ .timer = &shmobile_timer,
+ .restart = kzm9g_restart,
+ .dt_compat = kzm9g_boards_compat_dt,
+MACHINE_END
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/6] ARM: mach-shmobile: kzm9g: use voltage regulators by default
From: Simon Horman @ 2012-12-11 3:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355195254-4563-1-git-send-email-horms+renesas@verge.net.au>
This is needed to initialise the MMCIF device in the
absence of platform data.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3
* Also enable CONFIG_REGULATOR_DUMMY.
This is needed for SMSC.
v2
* First post
---
arch/arm/configs/kzm9g_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index c88b578..8c31b44 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -83,6 +83,8 @@ CONFIG_I2C_CHARDEV=y
CONFIG_I2C_SH_MOBILE=y
CONFIG_GPIO_PCF857X=y
# CONFIG_HWMON is not set
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_DUMMY=y
CONFIG_FB=y
CONFIG_FB_SH_MOBILE_LCDC=y
CONFIG_FRAMEBUFFER_CONSOLE=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/6] ARM: mach-shmobile: sh73a0: Initialise MMCIF using DT
From: Simon Horman @ 2012-12-11 3:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355195254-4563-1-git-send-email-horms+renesas@verge.net.au>
This device also requires a voltage regulator which
should be defined in a board-specific maner. An example
dts snipped follows.
/ {
fixedregulator1v8: fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
};
&mmcif {
vmmc-supply = <&fixedregulator1v8>;
vqmmc-supply = <&fixedregulator1v8>;
};
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3
* No change
v2
* Removed SDHI initialisation as the driver needs updating first
* Moved MMC DT from sh73a0.dtsi to sh73a0-reference.dtsi
as it is not appropriate for use by sh73a0-kzm9g.dts yet.
This is because sh73a0-kzm9g.dts and board-kzm9g.c use
both the GIC and INTC interrupt controllers to provide
access to a rich set of devices. This is achieved by initialising
the interrupt controllers using C code. Work on allowing the INC
controller to be initialised using DT is in progress, however,
until that is complete only GIC may be initialised using DT.
* Add extra entries to clock-sh73a0.c:lookups[] and
remove auxdata. Ultimately the clocks will be described
in DT, but the code isn't there yet.
---
arch/arm/boot/dts/sh73a0-reference.dtsi | 24 ++++++++++++++++++++++++
arch/arm/mach-shmobile/clock-sh73a0.c | 1 +
2 files changed, 25 insertions(+)
create mode 100644 arch/arm/boot/dts/sh73a0-reference.dtsi
diff --git a/arch/arm/boot/dts/sh73a0-reference.dtsi b/arch/arm/boot/dts/sh73a0-reference.dtsi
new file mode 100644
index 0000000..d4bb012
--- /dev/null
+++ b/arch/arm/boot/dts/sh73a0-reference.dtsi
@@ -0,0 +1,24 @@
+/*
+ * Device Tree Source for the SH73A0 SoC
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "sh73a0.dtsi"
+
+/ {
+ compatible = "renesas,sh73a0";
+
+ mmcif: mmcif@0x10010000 {
+ compatible = "renesas,sh-mmcif";
+ reg = <0xe6bd0000 0x100>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 140 0x4
+ 0 141 0x4>;
+ reg-io-width = <4>;
+ };
+};
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 22af74f2..2216b6b 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -583,6 +583,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_mobile_sdhi.0", &mstp_clks[MSTP314]), /* SDHI0 */
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP313]), /* SDHI1 */
CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP312]), /* MMCIF0 */
+ CLKDEV_DEV_ID("e6bd0000.mmcif", &mstp_clks[MSTP312]), /* MMCIF0 */
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP311]), /* SDHI2 */
CLKDEV_DEV_ID("leds-renesas-tpu.12", &mstp_clks[MSTP303]), /* TPU1 */
CLKDEV_DEV_ID("leds-renesas-tpu.21", &mstp_clks[MSTP302]), /* TPU2 */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/6] ARM: mach-shmobile: sh73a0: Minimal setup using DT
From: Simon Horman @ 2012-12-11 3:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355195254-4563-1-git-send-email-horms+renesas@verge.net.au>
Allow a minimal setup of the sh73a0 SoC using a flattened device tree.
In particular, Configure the i2c controllers using a flattened device tree.
SCI serial controller and CMT clock source, whose drivers do not yet
support configuration using a flattened device tree, are still configured
using C code in order to allow booting of a board with this SoC.
*** Please note that the clock initialisation shcheme used in
this patch does not currently work with SMP as there
is a yet to be resolved lock-up in workqueue initialisation.
CONFIG_SMP must be disabled when using this code. ***
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3
* Late initialisation of clocks
* Add DT_MACHINE_START()
* Add comment about duplicate entries in clock-sh73a0.c:lookups[]
v2
* Add extra entries to clock-sh73a0.c:lookups[] and
remove auxdata. Ultimtely the clocks will be described
in DT, but the code isn't there yet.
* Use shmobile_setup_delay() and perform late initialisation of clocks
---
arch/arm/boot/dts/sh73a0.dtsi | 60 +++++++++++++++++++++++
arch/arm/mach-shmobile/clock-sh73a0.c | 12 +++++
arch/arm/mach-shmobile/include/mach/common.h | 2 +
arch/arm/mach-shmobile/setup-sh73a0.c | 68 +++++++++++++++++++++++++-
4 files changed, 141 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 77c8e43..fc7f0fd 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -38,4 +38,64 @@
reg = <0xf0001000 0x1000>,
<0xf0000100 0x100>;
};
+
+ i2c0: i2c@0xe6820000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,rmobile-iic";
+ reg = <0xe6820000 0x425>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 167 0x4
+ 0 168 0x4
+ 0 169 0x4
+ 0 170 0x4>;
+ };
+
+ i2c1: i2c@0xe6822000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,rmobile-iic";
+ reg = <0xe6822000 0x425>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 51 0x4
+ 0 52 0x4
+ 0 53 0x4
+ 0 54 0x4>;
+ };
+
+ i2c2: i2c@0xe6824000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,rmobile-iic";
+ reg = <0xe6824000 0x425>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 171 0x4
+ 0 172 0x4
+ 0 173 0x4
+ 0 174 0x4>;
+ };
+
+ i2c3: i2c@0xe6826000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,rmobile-iic";
+ reg = <0xe6826000 0x425>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 183 0x4
+ 0 184 0x4
+ 0 185 0x4
+ 0 186 0x4>;
+ };
+
+ i2c4: i2c@0xe6828000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,rmobile-iic";
+ reg = <0xe6828000 0x425>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 187 0x4
+ 0 188 0x4
+ 0 189 0x4
+ 0 190 0x4>;
+ };
};
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 516ff7f..22af74f2 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -525,6 +525,13 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP403] = MSTP(&r_clk, SMSTPCR4, 3, 0), /* KEYSC */
};
+/* The lookups structure below includes duplicate entries for some clocks
+ * with alternate names.
+ * - The traditional name used when a device is initialised with platform data
+ * - The name used when a device is initialised using device tree
+ * The longer-term aim is to remove these duplicates, and indeed the
+ * lookups table entirely, by describing clocks using device tree.
+ */
static struct clk_lookup lookups[] = {
/* main clocks */
CLKDEV_CON_ID("r_clk", &r_clk),
@@ -545,6 +552,7 @@ static struct clk_lookup lookups[] = {
/* MSTP32 clocks */
CLKDEV_DEV_ID("i2c-sh_mobile.2", &mstp_clks[MSTP001]), /* I2C2 */
+ CLKDEV_DEV_ID("e6824000.i2c", &mstp_clks[MSTP001]), /* I2C2 */
CLKDEV_DEV_ID("sh_mobile_ceu.1", &mstp_clks[MSTP129]), /* CEU1 */
CLKDEV_DEV_ID("sh-mobile-csi2.1", &mstp_clks[MSTP128]), /* CSI2-RX1 */
CLKDEV_DEV_ID("sh_mobile_ceu.0", &mstp_clks[MSTP127]), /* CEU0 */
@@ -553,6 +561,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP125]), /* TMU01 */
CLKDEV_DEV_ID("sh-mipi-dsi.0", &mstp_clks[MSTP118]), /* DSITX */
CLKDEV_DEV_ID("i2c-sh_mobile.0", &mstp_clks[MSTP116]), /* I2C0 */
+ CLKDEV_DEV_ID("e6820000.i2c", &mstp_clks[MSTP116]), /* I2C0 */
CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", &mstp_clks[MSTP100]), /* LCDC0 */
CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP219]), /* SCIFA7 */
CLKDEV_DEV_ID("sh-dma-engine.0", &mstp_clks[MSTP218]), /* SY-DMAC */
@@ -569,6 +578,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_fsi2", &mstp_clks[MSTP328]), /* FSI */
CLKDEV_DEV_ID("sh_irda.0", &mstp_clks[MSTP325]), /* IrDA */
CLKDEV_DEV_ID("i2c-sh_mobile.1", &mstp_clks[MSTP323]), /* I2C1 */
+ CLKDEV_DEV_ID("e6822000.i2c", &mstp_clks[MSTP323]), /* I2C1 */
CLKDEV_DEV_ID("renesas_usbhs", &mstp_clks[MSTP322]), /* USB */
CLKDEV_DEV_ID("sh_mobile_sdhi.0", &mstp_clks[MSTP314]), /* SDHI0 */
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP313]), /* SDHI1 */
@@ -579,7 +589,9 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("leds-renesas-tpu.30", &mstp_clks[MSTP301]), /* TPU3 */
CLKDEV_DEV_ID("leds-renesas-tpu.41", &mstp_clks[MSTP300]), /* TPU4 */
CLKDEV_DEV_ID("i2c-sh_mobile.3", &mstp_clks[MSTP411]), /* I2C3 */
+ CLKDEV_DEV_ID("e6826000.i2c", &mstp_clks[MSTP411]), /* I2C3 */
CLKDEV_DEV_ID("i2c-sh_mobile.4", &mstp_clks[MSTP410]), /* I2C4 */
+ CLKDEV_DEV_ID("e6828000.i2c", &mstp_clks[MSTP410]), /* I2C4 */
CLKDEV_DEV_ID("sh_keysc.0", &mstp_clks[MSTP403]), /* KEYSC */
};
diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index b50447e..06b905e 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -52,7 +52,9 @@ extern void sh73a0_init_irq(void);
extern void sh73a0_init_irq_dt(void);
extern void sh73a0_map_io(void);
extern void sh73a0_add_early_devices(void);
+extern void sh73a0_add_early_devices_dt(void);
extern void sh73a0_add_standard_devices(void);
+extern void sh73a0_add_standard_devices_dt(void);
extern void sh73a0_clock_init(void);
extern void sh73a0_pinmux_init(void);
extern struct clk sh73a0_extal1_clk;
diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index eab1bae..dcf467b 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -23,6 +23,7 @@
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/platform_device.h>
+#include <linux/of_platform.h>
#include <linux/delay.h>
#include <linux/input.h>
#include <linux/io.h>
@@ -35,6 +36,7 @@
#include <mach/irqs.h>
#include <mach/sh73a0.h>
#include <mach/common.h>
+#include <asm/hardware/gic.h>
#include <asm/mach-types.h>
#include <asm/mach/map.h>
#include <asm/mach/arch.h>
@@ -779,7 +781,7 @@ static struct platform_device pmu_device = {
.resource = pmu_resources,
};
-static struct platform_device *sh73a0_early_devices[] __initdata = {
+static struct platform_device *sh73a0_early_devices_dt[] __initdata = {
&scif0_device,
&scif1_device,
&scif2_device,
@@ -790,6 +792,9 @@ static struct platform_device *sh73a0_early_devices[] __initdata = {
&scif7_device,
&scif8_device,
&cmt10_device,
+};
+
+static struct platform_device *sh73a0_early_devices[] __initdata = {
&tmu00_device,
&tmu01_device,
};
@@ -812,6 +817,8 @@ void __init sh73a0_add_standard_devices(void)
/* Clear software reset bit on SY-DMAC module */
__raw_writel(__raw_readl(SRCR2) & ~(1 << 18), SRCR2);
+ platform_add_devices(sh73a0_early_devices_dt,
+ ARRAY_SIZE(sh73a0_early_devices_dt));
platform_add_devices(sh73a0_early_devices,
ARRAY_SIZE(sh73a0_early_devices));
platform_add_devices(sh73a0_late_devices,
@@ -830,6 +837,8 @@ static void __init sh73a0_earlytimer_init(void)
void __init sh73a0_add_early_devices(void)
{
+ early_platform_add_devices(sh73a0_early_devices_dt,
+ ARRAY_SIZE(sh73a0_early_devices_dt));
early_platform_add_devices(sh73a0_early_devices,
ARRAY_SIZE(sh73a0_early_devices));
@@ -839,3 +848,60 @@ void __init sh73a0_add_early_devices(void)
/* override timer setup with soc-specific code */
shmobile_timer.init = sh73a0_earlytimer_init;
}
+
+#ifdef CONFIG_USE_OF
+
+/* Please note that the clock initialisation shcheme used in
+ * sh73a0_add_early_devices_dt() and sh73a0_add_standard_devices_dt()
+ * does not work with SMP as there is a yet to be resolved lock-up in
+ * workqueue initialisation.
+ *
+ * CONFIG_SMP should be disabled when using this code.
+ */
+
+static const struct of_dev_auxdata sh73a0_auxdata_lookup[] __initconst = {
+ {},
+};
+
+void __init sh73a0_add_early_devices_dt(void)
+{
+ shmobile_setup_delay(1196, 44, 46); /* Cortex-A9 @ 1196MHz */
+
+ early_platform_add_devices(sh73a0_early_devices_dt,
+ ARRAY_SIZE(sh73a0_early_devices_dt));
+
+ /* setup early console here as well */
+ shmobile_setup_console();
+}
+
+static const struct of_dev_auxdata sh73a0_auxdata_lookup[] __initconst = {
+ {},
+};
+
+void __init sh73a0_add_standard_devices_dt(void)
+{
+ /* clocks are setup late during boot in the case of DT */
+ sh73a0_clock_init();
+
+ platform_add_devices(sh73a0_early_devices_dt,
+ ARRAY_SIZE(sh73a0_early_devices_dt));
+ of_platform_populate(NULL, of_default_bus_match_table,
+ sh73a0_auxdata_lookup, NULL);
+}
+
+static const char *sh73a0_boards_compat_dt[] __initdata = {
+ "renesas,sh73a0",
+ NULL,
+};
+
+DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
+ .map_io = sh73a0_map_io,
+ .init_early = sh73a0_add_early_devices_dt,
+ .nr_irqs = NR_IRQS_LEGACY,
+ .init_irq = sh73a0_init_irq_dt,
+ .handle_irq = gic_handle_irq,
+ .init_machine = sh73a0_add_standard_devices_dt,
+ .timer = &shmobile_timer,
+ .dt_compat = sh73a0_boards_compat_dt,
+MACHINE_END
+#endif /* CONFIG_USE_OF */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/6] ARM: mach-shmobile: sh73a0: Allow initialisation of GIC by DT
From: Simon Horman @ 2012-12-11 3:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355195254-4563-1-git-send-email-horms+renesas@verge.net.au>
This allows the GIC interrupt controller of the sh73a0 SoC to be
initialised using a flattened device tree blob.
It does not allow the INTC interrupt controller which is also present on
the sh73a0 SoC to be enabled via device tree. Nor does it handle sharing
of interrupts between the GIC and INTC interrupt controllers.
This limits the usefulness of this code to applications which only wish to
access devices which use interrupts that can be handled by the GIC
interrupt controller. Other applications should, for now, continue using
non-device tree initialisation of the sh72a0 interrupt controllers.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3
* No change
v2
* No change
---
arch/arm/boot/dts/sh73a0.dtsi | 9 +++++++++
arch/arm/mach-shmobile/include/mach/common.h | 1 +
arch/arm/mach-shmobile/intc-sh73a0.c | 14 ++++++++++++++
3 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 6b374ff..77c8e43 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -29,4 +29,13 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ gic: interrupt-controller@f0001000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0xf0001000 0x1000>,
+ <0xf0000100 0x100>;
+ };
};
diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index d47e215..b50447e 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -49,6 +49,7 @@ extern struct clk sh7372_extal1_clk;
extern struct clk sh7372_extal2_clk;
extern void sh73a0_init_irq(void);
+extern void sh73a0_init_irq_dt(void);
extern void sh73a0_map_io(void);
extern void sh73a0_add_early_devices(void);
extern void sh73a0_add_standard_devices(void);
diff --git a/arch/arm/mach-shmobile/intc-sh73a0.c b/arch/arm/mach-shmobile/intc-sh73a0.c
index f0c5e51..e492350 100644
--- a/arch/arm/mach-shmobile/intc-sh73a0.c
+++ b/arch/arm/mach-shmobile/intc-sh73a0.c
@@ -21,6 +21,7 @@
#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/irq.h>
+#include <linux/of_irq.h>
#include <linux/io.h>
#include <linux/sh_intc.h>
#include <mach/intc.h>
@@ -464,3 +465,16 @@ void __init sh73a0_init_irq(void)
sh73a0_pint1_cascade.handler = sh73a0_pint1_demux;
setup_irq(gic_spi(34), &sh73a0_pint1_cascade);
}
+
+#ifdef CONFIG_OF
+static const struct of_device_id irq_of_match[] __initconst = {
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ { },
+};
+
+void __init sh73a0_init_irq_dt(void)
+{
+ of_irq_init(irq_of_match);
+ gic_arch_extn.irq_set_wake = sh73a0_set_wake;
+}
+#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/6] ARM: clocksource: Initialise early
From: Simon Horman @ 2012-12-11 3:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355195254-4563-1-git-send-email-horms+renesas@verge.net.au>
Initialise clock sources early, since some subsystems rely on them to initialize
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3
* Initial post
---
drivers/Makefile | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index a16a8d0..eba9b58 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -37,6 +37,11 @@ obj-$(CONFIG_XEN) += xen/
# regulators early, since some subsystems rely on them to initialize
obj-$(CONFIG_REGULATOR) += regulator/
+# clocksource early, since some subsystems rely on them to initialize
+ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
+obj-y += clocksource/
+endif
+
# tty/ comes before char/ so that the VT console is the boot-time
# default.
obj-y += tty/
@@ -114,9 +119,6 @@ obj-y += firmware/
obj-$(CONFIG_CRYPTO) += crypto/
obj-$(CONFIG_SUPERH) += sh/
obj-$(CONFIG_ARCH_SHMOBILE) += sh/
-ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
-obj-y += clocksource/
-endif
obj-$(CONFIG_DCA) += dca/
obj-$(CONFIG_HID) += hid/
obj-$(CONFIG_PPC_PS3) += ps3/
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox