[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

This partially reverts 58079fa7d54a0929d304054ee759187a2ccd3cdf
(ARM: shmobile: r8a7779: Correct TMU clock support) and fixes
a regression introduced by that patch.

Although the documentation I have indicates that the patch above is
correct it appears that the change causes the Marzen board to fail to boot
as follows.

...
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 2, t=279640 jiffies, g=4294967052, c=4294967051, q=38)
Task dump for CPU 1:
swapper/0       R running      0     1      0 0x00000002
[<c02b8f5c>] (__schedule+0x1b0/0x4c0) from [<c013c590>] (__loop_delay+0x4/0xc)

 { 1}  (t=279640 jiffies g=4294967052 c=4294967052 q=37)
[<c000ef9c>] (unwind_backtrace+0x0/0xf8) from [<c0068488>] (rcu_check_callbacks+0x218/0x6b8)
[<c0068488>] (rcu_check_callbacks+0x218/0x6b8) from [<c0026774>] (update_process_times+0x38/0x4c)
[<c0026774>] (update_process_times+0x38/0x4c) from [<c00569e0>] (tick_nohz_handler+0xb4/0x11c)
[<c00569e0>] (tick_nohz_handler+0xb4/0x11c) from [<c000e518>] (twd_handler+0x34/0x44)
[<c000e518>] (twd_handler+0x34/0x44) from [<c0063484>] (handle_percpu_devid_irq+0x68/0x80)
[<c0063484>] (handle_percpu_devid_irq+0x68/0x80) from [<c005febc>] (generic_handle_irq+0x20/0x30)
[<c005febc>] (generic_handle_irq+0x20/0x30) from [<c000a5ec>] (handle_IRQ+0x40/0x90)
[<c000a5ec>] (handle_IRQ+0x40/0x90) from [<c000934c>] (gic_handle_irq+0x2c/0x5c)
[<c000934c>] (gic_handle_irq+0x2c/0x5c) from [<c0009a40>] (__irq_svc+0x40/0x50)
Exception stack(0xef03ddf8 to 0xef03de40)
dde0:                                                       000001c1 ffffffff
de00: 000001d8 01bf01bf ef35ec40 ef35e800 ef35ec6c 0000002b ef35ec68 c013c560
de20: c0392994 60000113 00000000 ef03de40 c01a5d40 c013c590 20000113 ffffffff
[<c0009a40>] (__irq_svc+0x40/0x50) from [<c013c590>] (__loop_delay+0x4/0xc)

Cc: Denis Oliver Kropp <dok@directfb.org>
Cc: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7779.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index 202370d..83369c9 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -161,7 +161,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
-	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
+	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
 	CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
 	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
 	CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
-- 
1.7.10.4

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Kuninori Morimoto]

Hi Simon

> This partially reverts 58079fa7d54a0929d304054ee759187a2ccd3cdf
> (ARM: shmobile: r8a7779: Correct TMU clock support) and fixes
> a regression introduced by that patch.
> 
> Although the documentation I have indicates that the patch above is
> correct it appears that the change causes the Marzen board to fail to boot
> as follows.
(snip)
> --- a/arch/arm/mach-shmobile/clock-r8a7779.c
> +++ b/arch/arm/mach-shmobile/clock-r8a7779.c
> @@ -161,7 +161,7 @@ static struct clk_lookup lookups[] = {
>  	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
>  	CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
>  	CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> -	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> +	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
>  	CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
>  	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
>  	CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */

Really ???
Is MSTP value of TMU01 same as TMU00 ?

Please wail, I ask it to hardware guys.

Best regards
---
Kuninori Morimoto

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Magnus Damm]

On Thu, Feb 14, 2013 at 1:03 PM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
> Hi Simon
>
>> This partially reverts 58079fa7d54a0929d304054ee759187a2ccd3cdf
>> (ARM: shmobile: r8a7779: Correct TMU clock support) and fixes
>> a regression introduced by that patch.
>>
>> Although the documentation I have indicates that the patch above is
>> correct it appears that the change causes the Marzen board to fail to boot
>> as follows.
> (snip)
>> --- a/arch/arm/mach-shmobile/clock-r8a7779.c
>> +++ b/arch/arm/mach-shmobile/clock-r8a7779.c
>> @@ -161,7 +161,7 @@ static struct clk_lookup lookups[] = {
>>       CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
>>       CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
>>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
>> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
>> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
>>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
>>       CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
>>       CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
>
> Really ???
> Is MSTP value of TMU01 same as TMU00 ?

Usually, the TMU channels are bundled together. So TMU00 may be for
channel 0->3 and TMU01 for 4->6.

Thanks,

/ magnus

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Kuninori Morimoto]

Hi Magnus, Simon

Thank you for your explain

> >> --- a/arch/arm/mach-shmobile/clock-r8a7779.c
> >> +++ b/arch/arm/mach-shmobile/clock-r8a7779.c
> >> @@ -161,7 +161,7 @@ static struct clk_lookup lookups[] = {
> >>       CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
> >>       CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
> >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
> >>       CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
> >>       CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
> >
> > Really ???
> > Is MSTP value of TMU01 same as TMU00 ?
> 
> Usually, the TMU channels are bundled together. So TMU00 may be for
> channel 0->3 and TMU01 for 4->6.

This means that current TMU02 numbering seems doubtful too ?
How about just rever 58079fa7d54a0929d304054ee759187a2ccd3cdf ?

Best regards
---
Kuninori Morimoto

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Kuninori Morimoto]

Hi Magnus, Simon again

> > Usually, the TMU channels are bundled together. So TMU00 may be for
> > channel 0->3 and TMU01 for 4->6.
> 
> This means that current TMU02 numbering seems doubtful too ?
> How about just rever 58079fa7d54a0929d304054ee759187a2ccd3cdf ?

I meant there is no tmu2 code on setup.c

Best regards
---
Kuninori Morimoto

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

On Thu, Feb 14, 2013 at 01:04:35PM +0900, Magnus Damm wrote:
> On Thu, Feb 14, 2013 at 1:03 PM, Kuninori Morimoto
> <kuninori.morimoto.gx@renesas.com> wrote:
> >
> > Hi Simon
> >
> >> This partially reverts 58079fa7d54a0929d304054ee759187a2ccd3cdf
> >> (ARM: shmobile: r8a7779: Correct TMU clock support) and fixes
> >> a regression introduced by that patch.
> >>
> >> Although the documentation I have indicates that the patch above is
> >> correct it appears that the change causes the Marzen board to fail to boot
> >> as follows.
> > (snip)
> >> --- a/arch/arm/mach-shmobile/clock-r8a7779.c
> >> +++ b/arch/arm/mach-shmobile/clock-r8a7779.c
> >> @@ -161,7 +161,7 @@ static struct clk_lookup lookups[] = {
> >>       CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
> >>       CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
> >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
> >>       CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
> >>       CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
> >
> > Really ???

I am surprised too!

> > Is MSTP value of TMU01 same as TMU00 ?

With the patch above the board appears to boot.
Without the patch, it doesn't.

> Usually, the TMU channels are bundled together. So TMU00 may be for
> channel 0->3 and TMU01 for 4->6.

Ok, so in that case the correct value for "sh_tmu.2" might actually
be MSTP016 or MSTP015 depending on the bundle size. I am unsure how to test
sh_tmu.2.

However, the documentation I have seems to talk about channels
being TMU0..TMU2 and control of them being via MSTP016..MSTP014.
I.e. what the code currently is but not what seems to work for
TMU1 in practice.

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

On Wed, Feb 13, 2013 at 08:12:24PM -0800, Kuninori Morimoto wrote:
> 
> Hi Magnus, Simon
> 
> Thank you for your explain
> 
> > >> --- a/arch/arm/mach-shmobile/clock-r8a7779.c
> > >> +++ b/arch/arm/mach-shmobile/clock-r8a7779.c
> > >> @@ -161,7 +161,7 @@ static struct clk_lookup lookups[] = {
> > >>       CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
> > >>       CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
> > >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> > >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> > >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> > >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
> > >>       CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
> > >>       CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
> > >
> > > Really ???
> > > Is MSTP value of TMU01 same as TMU00 ?
> > 
> > Usually, the TMU channels are bundled together. So TMU00 may be for
> > channel 0->3 and TMU01 for 4->6.
> 
> This means that current TMU02 numbering seems doubtful too ?
> How about just rever 58079fa7d54a0929d304054ee759187a2ccd3cdf ?

Perhaps that is a good idea.

The original motivation for this patch was to add the TMU02 line.
And "fixing" TMU01 was an afterthought. However, I am also
now doubtful about the correctness of the TMU02 line and thus
the usefulness of the original patch.

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Kuninori Morimoto]

Hi Simon

> > >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> > >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> > >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> > >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
(snip)
> > This means that current TMU02 numbering seems doubtful too ?
> > How about just rever 58079fa7d54a0929d304054ee759187a2ccd3cdf ?
> 
> Perhaps that is a good idea.
> 
> The original motivation for this patch was to add the TMU02 line.
> And "fixing" TMU01 was an afterthought. However, I am also
> now doubtful about the correctness of the TMU02 line and thus
> the usefulness of the original patch.

I think this comment out is creating confusion ?

/* TMU00 */ -> /* TMU0 channel 0 */
/* TMU01 */ -> /* TMU0 channel 1 */
/* TMU02 */ -> /* TMU0 channel 2 */

Best regards
---
Kuninori Morimoto

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

On Wed, Feb 13, 2013 at 08:25:45PM -0800, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> > > >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> > > >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> > > >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> > > >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
> (snip)
> > > This means that current TMU02 numbering seems doubtful too ?
> > > How about just rever 58079fa7d54a0929d304054ee759187a2ccd3cdf ?
> > 
> > Perhaps that is a good idea.
> > 
> > The original motivation for this patch was to add the TMU02 line.
> > And "fixing" TMU01 was an afterthought. However, I am also
> > now doubtful about the correctness of the TMU02 line and thus
> > the usefulness of the original patch.
> 
> I think this comment out is creating confusion ?
> 
> /* TMU00 */ -> /* TMU0 channel 0 */
> /* TMU01 */ -> /* TMU0 channel 1 */
> /* TMU02 */ -> /* TMU0 channel 2 */

That does make things a little clearer,
but I for one wasn't confused by the existing comments.

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

On Thu, Feb 14, 2013 at 01:36:49PM +0900, Simon Horman wrote:
> On Wed, Feb 13, 2013 at 08:25:45PM -0800, Kuninori Morimoto wrote:
> > 
> > Hi Simon
> > 
> > > > >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> > > > >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> > > > >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> > > > >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
> > (snip)
> > > > This means that current TMU02 numbering seems doubtful too ?
> > > > How about just rever 58079fa7d54a0929d304054ee759187a2ccd3cdf ?
> > > 
> > > Perhaps that is a good idea.
> > > 
> > > The original motivation for this patch was to add the TMU02 line.
> > > And "fixing" TMU01 was an afterthought. However, I am also
> > > now doubtful about the correctness of the TMU02 line and thus
> > > the usefulness of the original patch.
> > 
> > I think this comment out is creating confusion ?
> > 
> > /* TMU00 */ -> /* TMU0 channel 0 */
> > /* TMU01 */ -> /* TMU0 channel 1 */
> > /* TMU02 */ -> /* TMU0 channel 2 */
> 
> That does make things a little clearer,
> but I for one wasn't confused by the existing comments.

Ok, now I think I see what you are getting at.

MSTP016 is for channel 0..n of TMU0
MSTP015 is for channel 1..n of TMU1
MSTP014 is for channel 2..n of TMU2

And all the TMU values set by CLKDEV_DEV_ID statements above
relate to channels of TMU0.

That does seem to be a valid interpretation of the documentation
now that I read it again.

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Magnus Damm]

On Thu, Feb 14, 2013 at 1:42 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Feb 14, 2013 at 01:36:49PM +0900, Simon Horman wrote:
>> On Wed, Feb 13, 2013 at 08:25:45PM -0800, Kuninori Morimoto wrote:
>> >
>> > Hi Simon
>> >
>> > > > >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
>> > > > >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
>> > > > >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
>> > > > >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
>> > (snip)
>> > > > This means that current TMU02 numbering seems doubtful too ?
>> > > > How about just rever 58079fa7d54a0929d304054ee759187a2ccd3cdf ?
>> > >
>> > > Perhaps that is a good idea.
>> > >
>> > > The original motivation for this patch was to add the TMU02 line.
>> > > And "fixing" TMU01 was an afterthought. However, I am also
>> > > now doubtful about the correctness of the TMU02 line and thus
>> > > the usefulness of the original patch.
>> >
>> > I think this comment out is creating confusion ?
>> >
>> > /* TMU00 */ -> /* TMU0 channel 0 */
>> > /* TMU01 */ -> /* TMU0 channel 1 */
>> > /* TMU02 */ -> /* TMU0 channel 2 */
>>
>> That does make things a little clearer,
>> but I for one wasn't confused by the existing comments.
>
> Ok, now I think I see what you are getting at.
>
> MSTP016 is for channel 0..n of TMU0
> MSTP015 is for channel 1..n of TMU1
> MSTP014 is for channel 2..n of TMU2
>
> And all the TMU values set by CLKDEV_DEV_ID statements above
> relate to channels of TMU0.
>
> That does seem to be a valid interpretation of the documentation
> now that I read it again.

Hm, your channel assignment above seems a tad different from what I believe:

MSTP016 is for channel 0..n of TMU0
MSTP015 is for channel 0..n of TMU1
MSTP014 is for channel 0..n of TMU2

Actually, you can check how the TMU channels are bundled together
based on the I/O memory and interrupts.
The TMU driver configuration in setup-sh73a0 contains these:

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	= 0xfff60008,
		.end	= 0xfff60013,
		.flags	= IORESOURCE_MEM,
	},
	[1] = {
		.start	= intcs_evt2irq(0x0e80), /* TMU0_TUNI00 */
		.flags	= IORESOURCE_IRQ,
	},
};

and

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	= 0xfff60014,
		.end	= 0xfff6001f,
		.flags	= IORESOURCE_MEM,
	},
	[1] = {
		.start	= intcs_evt2irq(0x0ea0), /* TMU0_TUNI01 */
		.flags	= IORESOURCE_IRQ,
	},
};

Note how the IORESOURCE_MEM ranges for tmu00 and tmu01 are closely
located. Also check the channel_offset platform data that point out
the shared start-stop register. The timer bit is the per-channel
start-stop bit. Another hint is in the IORESOURCE_IRQ and the
TMU0_TUNI00 + TMU0_TUNI01 comments that both start with TMU0_.

So basically, in this case both tmu00 and tmu01 should be assigned to
MSTP016 aka TMU00.

This line must be correct from my point of view:

CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU00 */

Cheers,

/ magnus

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

On Thu, Feb 14, 2013 at 02:20:07PM +0900, Magnus Damm wrote:
> On Thu, Feb 14, 2013 at 1:42 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Feb 14, 2013 at 01:36:49PM +0900, Simon Horman wrote:
> >> On Wed, Feb 13, 2013 at 08:25:45PM -0800, Kuninori Morimoto wrote:
> >> >
> >> > Hi Simon
> >> >
> >> > > > >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> >> > > > >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> >> > > > >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> >> > > > >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
> >> > (snip)
> >> > > > This means that current TMU02 numbering seems doubtful too ?
> >> > > > How about just rever 58079fa7d54a0929d304054ee759187a2ccd3cdf ?
> >> > >
> >> > > Perhaps that is a good idea.
> >> > >
> >> > > The original motivation for this patch was to add the TMU02 line.
> >> > > And "fixing" TMU01 was an afterthought. However, I am also
> >> > > now doubtful about the correctness of the TMU02 line and thus
> >> > > the usefulness of the original patch.
> >> >
> >> > I think this comment out is creating confusion ?
> >> >
> >> > /* TMU00 */ -> /* TMU0 channel 0 */
> >> > /* TMU01 */ -> /* TMU0 channel 1 */
> >> > /* TMU02 */ -> /* TMU0 channel 2 */
> >>
> >> That does make things a little clearer,
> >> but I for one wasn't confused by the existing comments.
> >
> > Ok, now I think I see what you are getting at.
> >
> > MSTP016 is for channel 0..n of TMU0
> > MSTP015 is for channel 1..n of TMU1
> > MSTP014 is for channel 2..n of TMU2
> >
> > And all the TMU values set by CLKDEV_DEV_ID statements above
> > relate to channels of TMU0.
> >
> > That does seem to be a valid interpretation of the documentation
> > now that I read it again.
> 
> Hm, your channel assignment above seems a tad different from what I believe:
> 
> MSTP016 is for channel 0..n of TMU0
> MSTP015 is for channel 0..n of TMU1
> MSTP014 is for channel 0..n of TMU2

Yes, thats is what I wanted to say too.

> Actually, you can check how the TMU channels are bundled together
> based on the I/O memory and interrupts.
> The TMU driver configuration in setup-sh73a0 contains these:
> 
> 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	= 0xfff60008,
> 		.end	= 0xfff60013,
> 		.flags	= IORESOURCE_MEM,
> 	},
> 	[1] = {
> 		.start	= intcs_evt2irq(0x0e80), /* TMU0_TUNI00 */
> 		.flags	= IORESOURCE_IRQ,
> 	},
> };
> 
> and
> 
> 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	= 0xfff60014,
> 		.end	= 0xfff6001f,
> 		.flags	= IORESOURCE_MEM,
> 	},
> 	[1] = {
> 		.start	= intcs_evt2irq(0x0ea0), /* TMU0_TUNI01 */
> 		.flags	= IORESOURCE_IRQ,
> 	},
> };
> 
> Note how the IORESOURCE_MEM ranges for tmu00 and tmu01 are closely
> located. Also check the channel_offset platform data that point out
> the shared start-stop register. The timer bit is the per-channel
> start-stop bit. Another hint is in the IORESOURCE_IRQ and the
> TMU0_TUNI00 + TMU0_TUNI01 comments that both start with TMU0_.
> 
> So basically, in this case both tmu00 and tmu01 should be assigned to
> MSTP016 aka TMU00.
> 
> This line must be correct from my point of view:
> 
> CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU00 */

That seems sane. But we are still left guessing about sh_tmu.2.
Can we assume it is channel 2 or TMU0 ?

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Paul Mundt]

On Thu, Feb 14, 2013 at 01:16:52PM +0900, Simon Horman wrote:
> On Thu, Feb 14, 2013 at 01:04:35PM +0900, Magnus Damm wrote:
> > On Thu, Feb 14, 2013 at 1:03 PM, Kuninori Morimoto
> > <kuninori.morimoto.gx@renesas.com> wrote:
> > >
> > > Hi Simon
> > >
> > >> This partially reverts 58079fa7d54a0929d304054ee759187a2ccd3cdf
> > >> (ARM: shmobile: r8a7779: Correct TMU clock support) and fixes
> > >> a regression introduced by that patch.
> > >>
> > >> Although the documentation I have indicates that the patch above is
> > >> correct it appears that the change causes the Marzen board to fail to boot
> > >> as follows.
> > > (snip)
> > >> --- a/arch/arm/mach-shmobile/clock-r8a7779.c
> > >> +++ b/arch/arm/mach-shmobile/clock-r8a7779.c
> > >> @@ -161,7 +161,7 @@ static struct clk_lookup lookups[] = {
> > >>       CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
> > >>       CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
> > >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> > >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> > >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> > >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
> > >>       CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
> > >>       CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
> > >
> > > Really ???
> 
> I am surprised too!
> 
> > > Is MSTP value of TMU01 same as TMU00 ?
> 
> With the patch above the board appears to boot.
> Without the patch, it doesn't.
> 
> > Usually, the TMU channels are bundled together. So TMU00 may be for
> > channel 0->3 and TMU01 for 4->6.
> 
> Ok, so in that case the correct value for "sh_tmu.2" might actually
> be MSTP016 or MSTP015 depending on the bundle size. I am unsure how to test
> sh_tmu.2.
> 
> However, the documentation I have seems to talk about channels
> being TMU0..TMU2 and control of them being via MSTP016..MSTP014.
> I.e. what the code currently is but not what seems to work for
> TMU1 in practice.

I think you are getting caught up on naming semantics. The MSTP bit
controls a block, which in turn usually has multiple TMU channels
associated with it, so it's quite reasonable to register the same bit
multiple times for each channel it impacts (that's what refcounting is
for, after all).

The TMU driver only handles individual channels, so sh_tmu.0/1/2 are just
channel numbers, you don't have any insight in to which block they are a
subset of or how any of their MSTP bits relate to each other, nor should
you, as this gets handled by the clk API.

Consider the following example for SH7786:

        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.0", &mstp_clks[MSTP008]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.1", &mstp_clks[MSTP008]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.2", &mstp_clks[MSTP008]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.3", &mstp_clks[MSTP009]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.4", &mstp_clks[MSTP009]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.5", &mstp_clks[MSTP009]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.6", &mstp_clks[MSTP010]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.7", &mstp_clks[MSTP010]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.8", &mstp_clks[MSTP010]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.9", &mstp_clks[MSTP011]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.10", &mstp_clks[MSTP011]),
        CLKDEV_ICK_ID("tmu_fck", "sh_tmu.11", &mstp_clks[MSTP011]),

registers a tmu_fck lookup that maps back appropriately for each channel,
regardless of MSTP overlap. In practice these channels are split between 4 TMU
blocks, but the driver doesn't know or care.

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

On Thu, Feb 14, 2013 at 06:10:40PM +0900, Paul Mundt wrote:
> On Thu, Feb 14, 2013 at 01:16:52PM +0900, Simon Horman wrote:
> > On Thu, Feb 14, 2013 at 01:04:35PM +0900, Magnus Damm wrote:
> > > On Thu, Feb 14, 2013 at 1:03 PM, Kuninori Morimoto
> > > <kuninori.morimoto.gx@renesas.com> wrote:
> > > >
> > > > Hi Simon
> > > >
> > > >> This partially reverts 58079fa7d54a0929d304054ee759187a2ccd3cdf
> > > >> (ARM: shmobile: r8a7779: Correct TMU clock support) and fixes
> > > >> a regression introduced by that patch.
> > > >>
> > > >> Although the documentation I have indicates that the patch above is
> > > >> correct it appears that the change causes the Marzen board to fail to boot
> > > >> as follows.
> > > > (snip)
> > > >> --- a/arch/arm/mach-shmobile/clock-r8a7779.c
> > > >> +++ b/arch/arm/mach-shmobile/clock-r8a7779.c
> > > >> @@ -161,7 +161,7 @@ static struct clk_lookup lookups[] = {
> > > >>       CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
> > > >>       CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
> > > >>       CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
> > > >> -     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
> > > >> +     CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
> > > >>       CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
> > > >>       CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
> > > >>       CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
> > > >
> > > > Really ???
> > 
> > I am surprised too!
> > 
> > > > Is MSTP value of TMU01 same as TMU00 ?
> > 
> > With the patch above the board appears to boot.
> > Without the patch, it doesn't.
> > 
> > > Usually, the TMU channels are bundled together. So TMU00 may be for
> > > channel 0->3 and TMU01 for 4->6.
> > 
> > Ok, so in that case the correct value for "sh_tmu.2" might actually
> > be MSTP016 or MSTP015 depending on the bundle size. I am unsure how to test
> > sh_tmu.2.
> > 
> > However, the documentation I have seems to talk about channels
> > being TMU0..TMU2 and control of them being via MSTP016..MSTP014.
> > I.e. what the code currently is but not what seems to work for
> > TMU1 in practice.
> 
> I think you are getting caught up on naming semantics. The MSTP bit
> controls a block, which in turn usually has multiple TMU channels
> associated with it, so it's quite reasonable to register the same bit
> multiple times for each channel it impacts (that's what refcounting is
> for, after all).
> 
> The TMU driver only handles individual channels, so sh_tmu.0/1/2 are just
> channel numbers, you don't have any insight in to which block they are a
> subset of or how any of their MSTP bits relate to each other, nor should
> you, as this gets handled by the clk API.
> 
> Consider the following example for SH7786:
> 
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.0", &mstp_clks[MSTP008]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.1", &mstp_clks[MSTP008]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.2", &mstp_clks[MSTP008]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.3", &mstp_clks[MSTP009]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.4", &mstp_clks[MSTP009]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.5", &mstp_clks[MSTP009]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.6", &mstp_clks[MSTP010]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.7", &mstp_clks[MSTP010]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.8", &mstp_clks[MSTP010]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.9", &mstp_clks[MSTP011]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.10", &mstp_clks[MSTP011]),
>         CLKDEV_ICK_ID("tmu_fck", "sh_tmu.11", &mstp_clks[MSTP011]),
> 
> registers a tmu_fck lookup that maps back appropriately for each channel,
> regardless of MSTP overlap. In practice these channels are split between 4 TMU
> blocks, but the driver doesn't know or care.

Right. But the above does know which MSTP000X to use for each sh_tmu.X.
Getting that information correct for sh_tmu.2 on the r8a7779 problem I'm
not completely sure of the correct answer to. Though I now strongly suspect
it is MSTP016.

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Paul Mundt]

On Fri, Feb 15, 2013 at 01:08:42AM +0900, Simon Horman wrote:
> On Thu, Feb 14, 2013 at 06:10:40PM +0900, Paul Mundt wrote:
> > On Thu, Feb 14, 2013 at 01:16:52PM +0900, Simon Horman wrote:
> > > Ok, so in that case the correct value for "sh_tmu.2" might actually
> > > be MSTP016 or MSTP015 depending on the bundle size. I am unsure how to test
> > > sh_tmu.2.

[snip]

> Getting that information correct for sh_tmu.2 on the r8a7779 problem I'm
> not completely sure of the correct answer to. Though I now strongly suspect
> it is MSTP016.

Testing shouldn't be that difficult, just switch your clocksource to it
and make sure all TMU-related MSTP bits are first cleared?

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

Empirically it appears that "sh_tmu.1" is controlled by MSTP016
and after discussion it appears likely the same is true for sh_tmu.2.

The sh_tmu.1 portion of this change resolves a regression introduced in
58079fa7d54a0929d304054ee759187a2ccd3cdf (ARM: shmobile: r8a7779: Correct
TMU clock support) and fixes a regression introduced by that patch. That
patch is queued up for v3.9.

...
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on
+CPUs/tasks: { 1} (detected by 2, t=279640 jiffies, g=4294967052, c=4294967051,
+q=38)
Task dump for CPU 1:
swapper/0       R running      0     1      0 0x00000002
[<c02b8f5c>] (__schedule+0x1b0/0x4c0) from [<c013c590>] (__loop_delay+0x4/0xc)

 { 1}  (t=279640 jiffies g=4294967052 c=4294967052 q=37)
[<c000ef9c>] (unwind_backtrace+0x0/0xf8) from [<c0068488>]
+(rcu_check_callbacks+0x218/0x6b8)
[<c0068488>] (rcu_check_callbacks+0x218/0x6b8) from [<c0026774>]
+(update_process_times+0x38/0x4c)
[<c0026774>] (update_process_times+0x38/0x4c) from [<c00569e0>]
+(tick_nohz_handler+0xb4/0x11c)
[<c00569e0>] (tick_nohz_handler+0xb4/0x11c) from [<c000e518>]
+(twd_handler+0x34/0x44)
[<c000e518>] (twd_handler+0x34/0x44) from [<c0063484>]
+(handle_percpu_devid_irq+0x68/0x80)
[<c0063484>] (handle_percpu_devid_irq+0x68/0x80) from [<c005febc>]
+(generic_handle_irq+0x20/0x30)
[<c005febc>] (generic_handle_irq+0x20/0x30) from [<c000a5ec>]
+(handle_IRQ+0x40/0x90)
[<c000a5ec>] (handle_IRQ+0x40/0x90) from [<c000934c>] (gic_handle_irq+0x2c/0x5c)
[<c000934c>] (gic_handle_irq+0x2c/0x5c) from [<c0009a40>] (__irq_svc+0x40/0x50)
Exception stack(0xef03ddf8 to 0xef03de40)
dde0:                                                       000001c1 ffffffff
de00: 000001d8 01bf01bf ef35ec40 ef35e800 ef35ec6c 0000002b ef35ec68 c013c560
de20: c0392994 60000113 00000000 ef03de40 c01a5d40 c013c590 20000113 ffffffff
[<c0009a40>] (__irq_svc+0x40/0x50) from [<c013c590>] (__loop_delay+0x4/0xc)

Cc: Denis Oliver Kropp <dok@directfb.org>
Cc: Magnus Damm <damm@opensource.se>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7779.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index 202370d..1db3653 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -161,8 +161,8 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
-	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
-	CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
+	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
+	CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP016]), /* TMU02 */
 	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
 	CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
 	CLKDEV_DEV_ID("i2c-rcar.2", &mstp_clks[MSTP028]), /* I2C2 */
-- 
1.7.10.4

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

On Fri, Feb 15, 2013 at 01:18:11AM +0900, Paul Mundt wrote:
> On Fri, Feb 15, 2013 at 01:08:42AM +0900, Simon Horman wrote:
> > On Thu, Feb 14, 2013 at 06:10:40PM +0900, Paul Mundt wrote:
> > > On Thu, Feb 14, 2013 at 01:16:52PM +0900, Simon Horman wrote:
> > > > Ok, so in that case the correct value for "sh_tmu.2" might actually
> > > > be MSTP016 or MSTP015 depending on the bundle size. I am unsure how to test
> > > > sh_tmu.2.
> 
> [snip]
> 
> > Getting that information correct for sh_tmu.2 on the r8a7779 problem I'm
> > not completely sure of the correct answer to. Though I now strongly suspect
> > it is MSTP016.
> 
> Testing shouldn't be that difficult, just switch your clocksource to it
> and make sure all TMU-related MSTP bits are first cleared?

Thanks, I will try that.

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

On Fri, Feb 15, 2013 at 10:53:24PM +0900, Simon Horman wrote:
> On Fri, Feb 15, 2013 at 01:18:11AM +0900, Paul Mundt wrote:
> > On Fri, Feb 15, 2013 at 01:08:42AM +0900, Simon Horman wrote:
> > > On Thu, Feb 14, 2013 at 06:10:40PM +0900, Paul Mundt wrote:
> > > > On Thu, Feb 14, 2013 at 01:16:52PM +0900, Simon Horman wrote:
> > > > > Ok, so in that case the correct value for "sh_tmu.2" might actually
> > > > > be MSTP016 or MSTP015 depending on the bundle size. I am unsure how to test
> > > > > sh_tmu.2.
> > 
> > [snip]
> > 
> > > Getting that information correct for sh_tmu.2 on the r8a7779 problem I'm
> > > not completely sure of the correct answer to. Though I now strongly suspect
> > > it is MSTP016.
> > 
> > Testing shouldn't be that difficult, just switch your clocksource to it
> > and make sure all TMU-related MSTP bits are first cleared?
> 
> Thanks, I will try that.

Thanks again. I did try this and it appears to work.

[PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again

[Simon Horman]

After discussion on the linux-sh mailing list and reference to the
hardware documentation it appears that 'TMU00', 'TMU01' and 'TMU02'
use a common clock.

The sh_tmu.1 portion of this change resolves a regression introduced in
58079fa7d54a0929d304054ee759187a2ccd3cdf (ARM: shmobile: r8a7779: Correct
TMU clock support) and fixes a regression introduced by that patch. That
patch is queued up for v3.9.

...
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
INFO: rcu_sched self-detected stall on CPUINFO: rcu_sched detected stalls on
+CPUs/tasks: { 1} (detected by 2, t=279640 jiffies, g=4294967052, c=4294967051,
+q=38)
Task dump for CPU 1:
swapper/0       R running      0     1      0 0x00000002
[<c02b8f5c>] (__schedule+0x1b0/0x4c0) from [<c013c590>] (__loop_delay+0x4/0xc)

 { 1}  (t=279640 jiffies g=4294967052 c=4294967052 q=37)
[<c000ef9c>] (unwind_backtrace+0x0/0xf8) from [<c0068488>]
+(rcu_check_callbacks+0x218/0x6b8)
[<c0068488>] (rcu_check_callbacks+0x218/0x6b8) from [<c0026774>]
+(update_process_times+0x38/0x4c)
[<c0026774>] (update_process_times+0x38/0x4c) from [<c00569e0>]
+(tick_nohz_handler+0xb4/0x11c)
[<c00569e0>] (tick_nohz_handler+0xb4/0x11c) from [<c000e518>]
+(twd_handler+0x34/0x44)
[<c000e518>] (twd_handler+0x34/0x44) from [<c0063484>]
+(handle_percpu_devid_irq+0x68/0x80)
[<c0063484>] (handle_percpu_devid_irq+0x68/0x80) from [<c005febc>]
+(generic_handle_irq+0x20/0x30)
[<c005febc>] (generic_handle_irq+0x20/0x30) from [<c000a5ec>]
+(handle_IRQ+0x40/0x90)
[<c000a5ec>] (handle_IRQ+0x40/0x90) from [<c000934c>] (gic_handle_irq+0x2c/0x5c)
[<c000934c>] (gic_handle_irq+0x2c/0x5c) from [<c0009a40>] (__irq_svc+0x40/0x50)
Exception stack(0xef03ddf8 to 0xef03de40)
dde0:                                                       000001c1 ffffffff
de00: 000001d8 01bf01bf ef35ec40 ef35e800 ef35ec6c 0000002b ef35ec68 c013c560
de20: c0392994 60000113 00000000 ef03de40 c01a5d40 c013c590 20000113 ffffffff
[<c0009a40>] (__irq_svc+0x40/0x50) from [<c013c590>] (__loop_delay+0x4/0xc)

Cc: Denis Oliver Kropp <dok@directfb.org>
Cc: Magnus Damm <damm@opensource.se>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7779.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index 202370d..1db3653 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -161,8 +161,8 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("ehci-platform.0", &mstp_clks[MSTP100]), /* USB EHCI port0/1 */
 	CLKDEV_DEV_ID("ohci-platform.0", &mstp_clks[MSTP100]), /* USB OHCI port0/1 */
 	CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP016]), /* TMU00 */
-	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* TMU01 */
-	CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP014]), /* TMU02 */
+	CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP016]), /* TMU01 */
+	CLKDEV_DEV_ID("sh_tmu.2", &mstp_clks[MSTP016]), /* TMU02 */
 	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
 	CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP029]), /* I2C1 */
 	CLKDEV_DEV_ID("i2c-rcar.2", &mstp_clks[MSTP028]), /* I2C2 */
-- 
1.7.10.4