* [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support
@ 2013-02-05 3:28 Simon Horman
2013-02-05 3:30 ` Magnus Damm
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Simon Horman @ 2013-02-05 3:28 UTC (permalink / raw)
To: linux-arm-kernel
During code review it was noticed that the clock value for
TMU01 was incorrect and the value for TMU02 was missing.
For reference: As of 3.8-rc6 there are no in-tree consumes of these clocks.
Reported-by: Denis Oliver Kropp <dok@directfb.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/clock-r8a7779.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c b/arch/arm/mach-shmobile/clock-r8a7779.c
index c019609..202370d 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -161,7 +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[MSTP016]), /* TMU01 */
+ CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP015]), /* 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 */
CLKDEV_DEV_ID("i2c-rcar.2", &mstp_clks[MSTP028]), /* I2C2 */
--
1.7.10.4
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support 2013-02-05 3:28 [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support Simon Horman @ 2013-02-05 3:30 ` Magnus Damm 2013-02-14 3:43 ` [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again Simon Horman 2013-02-15 13:35 ` Simon Horman 2 siblings, 0 replies; 21+ messages in thread From: Magnus Damm @ 2013-02-05 3:30 UTC (permalink / raw) To: linux-arm-kernel Hey Simon, On Tue, Feb 5, 2013 at 12:28 PM, Simon Horman <horms+renesas@verge.net.au> wrote: > During code review it was noticed that the clock value for > TMU01 was incorrect and the value for TMU02 was missing. > > For reference: As of 3.8-rc6 there are no in-tree consumes of these clocks. > > Reported-by: Denis Oliver Kropp <dok@directfb.org> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Looking good, thanks for fixing. Reviewed-by: Magnus Damm <damm@opensource.se> / magnus ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-05 3:28 [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support Simon Horman 2013-02-05 3:30 ` Magnus Damm @ 2013-02-14 3:43 ` Simon Horman 2013-02-14 4:03 ` Kuninori Morimoto 2013-02-15 13:35 ` Simon Horman 2 siblings, 1 reply; 21+ messages in thread From: Simon Horman @ 2013-02-14 3:43 UTC (permalink / raw) To: linux-arm-kernel 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'9640 jiffies, gB94967052, cB94967051, q8) 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'9640 jiffies gB94967052 cB94967052 q7) [<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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 3:43 ` [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again Simon Horman @ 2013-02-14 4:03 ` Kuninori Morimoto 2013-02-14 4:04 ` Magnus Damm 0 siblings, 1 reply; 21+ messages in thread From: Kuninori Morimoto @ 2013-02-14 4:03 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:03 ` Kuninori Morimoto @ 2013-02-14 4:04 ` Magnus Damm 2013-02-14 4:12 ` Kuninori Morimoto 2013-02-14 4:16 ` Simon Horman 0 siblings, 2 replies; 21+ messages in thread From: Magnus Damm @ 2013-02-14 4:04 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:04 ` Magnus Damm @ 2013-02-14 4:12 ` Kuninori Morimoto 2013-02-14 4:14 ` Kuninori Morimoto 2013-02-14 4:20 ` Simon Horman 2013-02-14 4:16 ` Simon Horman 1 sibling, 2 replies; 21+ messages in thread From: Kuninori Morimoto @ 2013-02-14 4:12 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:12 ` Kuninori Morimoto @ 2013-02-14 4:14 ` Kuninori Morimoto 2013-02-14 4:20 ` Simon Horman 1 sibling, 0 replies; 21+ messages in thread From: Kuninori Morimoto @ 2013-02-14 4:14 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:12 ` Kuninori Morimoto 2013-02-14 4:14 ` Kuninori Morimoto @ 2013-02-14 4:20 ` Simon Horman 2013-02-14 4:25 ` Kuninori Morimoto 1 sibling, 1 reply; 21+ messages in thread From: Simon Horman @ 2013-02-14 4:20 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:20 ` Simon Horman @ 2013-02-14 4:25 ` Kuninori Morimoto 2013-02-14 4:36 ` Simon Horman 0 siblings, 1 reply; 21+ messages in thread From: Kuninori Morimoto @ 2013-02-14 4:25 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:25 ` Kuninori Morimoto @ 2013-02-14 4:36 ` Simon Horman 2013-02-14 4:42 ` Simon Horman 0 siblings, 1 reply; 21+ messages in thread From: Simon Horman @ 2013-02-14 4:36 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:36 ` Simon Horman @ 2013-02-14 4:42 ` Simon Horman 2013-02-14 5:20 ` Magnus Damm 0 siblings, 1 reply; 21+ messages in thread From: Simon Horman @ 2013-02-14 4:42 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:42 ` Simon Horman @ 2013-02-14 5:20 ` Magnus Damm 2013-02-14 8:34 ` Simon Horman 0 siblings, 1 reply; 21+ messages in thread From: Magnus Damm @ 2013-02-14 5:20 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 5:20 ` Magnus Damm @ 2013-02-14 8:34 ` Simon Horman 0 siblings, 0 replies; 21+ messages in thread From: Simon Horman @ 2013-02-14 8:34 UTC (permalink / raw) To: linux-arm-kernel 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 ? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:04 ` Magnus Damm 2013-02-14 4:12 ` Kuninori Morimoto @ 2013-02-14 4:16 ` Simon Horman 2013-02-14 9:10 ` Paul Mundt 1 sibling, 1 reply; 21+ messages in thread From: Simon Horman @ 2013-02-14 4:16 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 4:16 ` Simon Horman @ 2013-02-14 9:10 ` Paul Mundt 2013-02-14 16:08 ` Simon Horman 0 siblings, 1 reply; 21+ messages in thread From: Paul Mundt @ 2013-02-14 9:10 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 9:10 ` Paul Mundt @ 2013-02-14 16:08 ` Simon Horman 2013-02-14 16:18 ` Paul Mundt 0 siblings, 1 reply; 21+ messages in thread From: Simon Horman @ 2013-02-14 16:08 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 16:08 ` Simon Horman @ 2013-02-14 16:18 ` Paul Mundt 2013-02-15 13:53 ` Simon Horman 0 siblings, 1 reply; 21+ messages in thread From: Paul Mundt @ 2013-02-14 16:18 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-14 16:18 ` Paul Mundt @ 2013-02-15 13:53 ` Simon Horman 2013-02-18 0:52 ` Simon Horman 0 siblings, 1 reply; 21+ messages in thread From: Simon Horman @ 2013-02-15 13:53 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-15 13:53 ` Simon Horman @ 2013-02-18 0:52 ` Simon Horman 0 siblings, 0 replies; 21+ messages in thread From: Simon Horman @ 2013-02-18 0:52 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-05 3:28 [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support Simon Horman 2013-02-05 3:30 ` Magnus Damm 2013-02-14 3:43 ` [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again Simon Horman @ 2013-02-15 13:35 ` Simon Horman 2 siblings, 0 replies; 21+ messages in thread From: Simon Horman @ 2013-02-15 13:35 UTC (permalink / raw) To: linux-arm-kernel 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'9640 jiffies, gB94967052, cB94967051, +q8) 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'9640 jiffies gB94967052 cB94967052 q7) [<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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [GIT PULL] Renesas ARM-based SoC for v3.9 #5
@ 2013-02-19 3:49 Simon Horman
2013-02-19 3:49 ` [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again Simon Horman
0 siblings, 1 reply; 21+ messages in thread
From: Simon Horman @ 2013-02-19 3:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Arnd,
The following changes since commit dbe1c3defb3844772634446492ea6c13882596ec:
ARM: shmobile: Register ARM architected timer (2013-02-05 17:13:55 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc5-for-v3.9
for you to fetch changes up to f9047306fd7332d682898dd689152bb3b45a3e73:
ARM: shmobile: r8a7779: Correct TMU clock support again (2013-02-19 10:05:27 +0900)
----------------------------------------------------------------
This resolves a panic-on-boot regression introduced by me when incorrectly
updating TMU clock definitions.
----------------------------------------------------------------
Simon Horman (1):
ARM: shmobile: r8a7779: Correct TMU clock support again
arch/arm/mach-shmobile/clock-r8a7779.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again 2013-02-19 3:49 [GIT PULL] Renesas ARM-based SoC for v3.9 #5 Simon Horman @ 2013-02-19 3:49 ` Simon Horman 0 siblings, 0 replies; 21+ messages in thread From: Simon Horman @ 2013-02-19 3:49 UTC (permalink / raw) To: linux-arm-kernel 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'9640 jiffies, gB94967052, cB94967051, +q8) 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'9640 jiffies gB94967052 cB94967052 q7) [<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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-02-19 3:49 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-02-05 3:28 [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support Simon Horman 2013-02-05 3:30 ` Magnus Damm 2013-02-14 3:43 ` [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again Simon Horman 2013-02-14 4:03 ` Kuninori Morimoto 2013-02-14 4:04 ` Magnus Damm 2013-02-14 4:12 ` Kuninori Morimoto 2013-02-14 4:14 ` Kuninori Morimoto 2013-02-14 4:20 ` Simon Horman 2013-02-14 4:25 ` Kuninori Morimoto 2013-02-14 4:36 ` Simon Horman 2013-02-14 4:42 ` Simon Horman 2013-02-14 5:20 ` Magnus Damm 2013-02-14 8:34 ` Simon Horman 2013-02-14 4:16 ` Simon Horman 2013-02-14 9:10 ` Paul Mundt 2013-02-14 16:08 ` Simon Horman 2013-02-14 16:18 ` Paul Mundt 2013-02-15 13:53 ` Simon Horman 2013-02-18 0:52 ` Simon Horman 2013-02-15 13:35 ` Simon Horman -- strict thread matches above, loose matches on Subject: below -- 2013-02-19 3:49 [GIT PULL] Renesas ARM-based SoC for v3.9 #5 Simon Horman 2013-02-19 3:49 ` [PATCH] ARM: shmobile: r8a7779: Correct TMU clock support again Simon Horman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).