* Re: [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups
2014-04-23 11:15 [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups Laurent Pinchart
@ 2014-04-25 1:35 ` Simon Horman
2014-05-11 2:24 ` Simon Horman
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Simon Horman @ 2014-04-25 1:35 UTC (permalink / raw)
To: linux-sh
On Wed, Apr 23, 2014 at 01:15:07PM +0200, Laurent Pinchart wrote:
> Hello,
>
> This patch set switches all Renesas platforms to the new style CMT, MTU2 and
> TMU device platform data. All patches have been previously posted as part of
> the "[PATCH v3 00/52] Renesas CMT and TMU cleanups" and "[PATCH 00/22] SH MTU2
> DT support" patch series.
>
> This new version fixes an interrupt-related bug introduced when switching the
> sh7372 and sh73a0 platforms to the new style TMU device, caused by mistakenly
> using evt2irq instead of intcs_evt2irq for the IRQ resources.
>
> Simon, I've tested this on Mackerel and the board now boots correctly. Could
> you please assist me in debugging the Bock-W boot hang issue, as I don't have
> access to that board ?
Yes, of course I am happy to help.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups
2014-04-23 11:15 [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups Laurent Pinchart
2014-04-25 1:35 ` Simon Horman
@ 2014-05-11 2:24 ` Simon Horman
2014-05-12 12:11 ` Geert Uytterhoeven
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Simon Horman @ 2014-05-11 2:24 UTC (permalink / raw)
To: linux-sh
On Wed, Apr 23, 2014 at 01:15:07PM +0200, Laurent Pinchart wrote:
> Hello,
>
> This patch set switches all Renesas platforms to the new style CMT, MTU2 and
> TMU device platform data. All patches have been previously posted as part of
> the "[PATCH v3 00/52] Renesas CMT and TMU cleanups" and "[PATCH 00/22] SH MTU2
> DT support" patch series.
>
> This new version fixes an interrupt-related bug introduced when switching the
> sh7372 and sh73a0 platforms to the new style TMU device, caused by mistakenly
> using evt2irq instead of intcs_evt2irq for the IRQ resources.
>
> Simon, I've tested this on Mackerel and the board now boots correctly. Could
> you please assist me in debugging the Bock-W boot hang issue, as I don't have
> access to that board ?
Thanks Laurent,
I have queued this up locally using v6 of patch 12 after resolving some
conflicts which I will highlight by responding to the patches that are
affected.
I plan to push this once I have done some testing: especially of the
resolution to the bockw problem. (I am on a plane with neither internet
access nor a consignment of boards.)
> Laurent Pinchart (15):
> sh: Switch to new style CMT device
> ARM: shmobile: sh7372: Switch to new style CMT device
> ARM: shmobile: sh73a0: Switch to new style CMT device
> ARM: shmobile: r8a73a4: Switch to new style CMT device
> ARM: shmobile: r8a7740: Switch to new style CMT device
> ARM: shmobile: r8a7790: Switch to new style CMT device
> ARM: shmobile: r8a7791: Switch to new style CMT device
> sh: Switch to new style TMU device
> ARM: shmobile: sh7372: Switch to new style TMU device
> ARM: shmobile: sh73a0: Switch to new style TMU device
> ARM: shmobile: r8a7740: Switch to new style TMU device
> ARM: shmobile: r8a7778: Switch to new style TMU device
> ARM: shmobile: r8a7779: Switch to new style TMU device
> sh: Switch to new style MTU2 device
> ARM: shmobile: r7s72100: Switch to new style MTU2 device
>
> arch/arm/mach-shmobile/board-koelsch-reference.c | 2 +-
> arch/arm/mach-shmobile/board-lager-reference.c | 2 +-
> arch/arm/mach-shmobile/clock-r7s72100.c | 2 +-
> arch/arm/mach-shmobile/clock-r8a73a4.c | 2 +-
> arch/arm/mach-shmobile/clock-r8a7740.c | 10 +-
> arch/arm/mach-shmobile/clock-r8a7778.c | 4 +-
> arch/arm/mach-shmobile/clock-r8a7779.c | 4 +-
> arch/arm/mach-shmobile/clock-r8a7790.c | 2 +-
> arch/arm/mach-shmobile/clock-r8a7791.c | 2 +-
> arch/arm/mach-shmobile/clock-sh7372.c | 9 +-
> arch/arm/mach-shmobile/clock-sh73a0.c | 5 +-
> arch/arm/mach-shmobile/setup-r7s72100.c | 26 +-
> arch/arm/mach-shmobile/setup-r8a73a4.c | 17 +-
> arch/arm/mach-shmobile/setup-r8a7740.c | 133 ++--------
> arch/arm/mach-shmobile/setup-r8a7778.c | 30 +--
> arch/arm/mach-shmobile/setup-r8a7779.c | 66 +----
> arch/arm/mach-shmobile/setup-r8a7790.c | 17 +-
> arch/arm/mach-shmobile/setup-r8a7791.c | 17 +-
> arch/arm/mach-shmobile/setup-sh7372.c | 89 ++-----
> arch/arm/mach-shmobile/setup-sh73a0.c | 92 ++-----
> arch/sh/kernel/cpu/clock-cpg.c | 10 +-
> arch/sh/kernel/cpu/sh2/setup-sh7619.c | 66 +----
> arch/sh/kernel/cpu/sh2a/clock-sh7264.c | 4 +-
> arch/sh/kernel/cpu/sh2a/clock-sh7269.c | 4 +-
> arch/sh/kernel/cpu/sh2a/setup-mxg.c | 98 +-------
> arch/sh/kernel/cpu/sh2a/setup-sh7201.c | 98 +-------
> arch/sh/kernel/cpu/sh2a/setup-sh7203.c | 133 ++--------
> arch/sh/kernel/cpu/sh2a/setup-sh7206.c | 164 ++-----------
> arch/sh/kernel/cpu/sh2a/setup-sh7264.c | 140 ++---------
> arch/sh/kernel/cpu/sh2a/setup-sh7269.c | 133 ++--------
> arch/sh/kernel/cpu/sh3/setup-sh7705.c | 78 +-----
> arch/sh/kernel/cpu/sh3/setup-sh770x.c | 78 +-----
> arch/sh/kernel/cpu/sh3/setup-sh7710.c | 78 +-----
> arch/sh/kernel/cpu/sh3/setup-sh7720.c | 228 ++---------------
> arch/sh/kernel/cpu/sh4/setup-sh4-202.c | 78 +-----
> arch/sh/kernel/cpu/sh4/setup-sh7750.c | 138 ++---------
> arch/sh/kernel/cpu/sh4/setup-sh7760.c | 78 +-----
> arch/sh/kernel/cpu/sh4a/clock-sh7343.c | 2 +-
> arch/sh/kernel/cpu/sh4a/clock-sh7366.c | 2 +-
> arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 6 +-
> arch/sh/kernel/cpu/sh4a/clock-sh7723.c | 10 +-
> arch/sh/kernel/cpu/sh4a/clock-sh7724.c | 10 +-
> arch/sh/kernel/cpu/sh4a/clock-sh7734.c | 12 +-
> arch/sh/kernel/cpu/sh4a/clock-sh7757.c | 4 +-
> arch/sh/kernel/cpu/sh4a/clock-sh7785.c | 8 +-
> arch/sh/kernel/cpu/sh4a/clock-sh7786.c | 16 +-
> arch/sh/kernel/cpu/sh4a/clock-shx3.c | 8 +-
> arch/sh/kernel/cpu/sh4a/setup-sh7343.c | 96 +-------
> arch/sh/kernel/cpu/sh4a/setup-sh7366.c | 96 +-------
> arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 96 +-------
> arch/sh/kernel/cpu/sh4a/setup-sh7723.c | 172 ++-----------
> arch/sh/kernel/cpu/sh4a/setup-sh7724.c | 173 ++-----------
> arch/sh/kernel/cpu/sh4a/setup-sh7734.c | 235 ++----------------
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c | 48 +---
> arch/sh/kernel/cpu/sh4a/setup-sh7763.c | 154 +-----------
> arch/sh/kernel/cpu/sh4a/setup-sh7770.c | 230 ++---------------
> arch/sh/kernel/cpu/sh4a/setup-sh7780.c | 154 +-----------
> arch/sh/kernel/cpu/sh4a/setup-sh7785.c | 154 +-----------
> arch/sh/kernel/cpu/sh4a/setup-sh7786.c | 299 ++---------------------
> arch/sh/kernel/cpu/sh4a/setup-shx3.c | 150 +-----------
> arch/sh/kernel/cpu/sh5/setup-sh5.c | 79 +-----
> 61 files changed, 554 insertions(+), 3797 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups
2014-04-23 11:15 [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups Laurent Pinchart
2014-04-25 1:35 ` Simon Horman
2014-05-11 2:24 ` Simon Horman
@ 2014-05-12 12:11 ` Geert Uytterhoeven
2014-05-12 12:30 ` Geert Uytterhoeven
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2014-05-12 12:11 UTC (permalink / raw)
To: linux-sh
Hi Laurent, Simon,
On Sun, May 11, 2014 at 4:24 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Apr 23, 2014 at 01:15:07PM +0200, Laurent Pinchart wrote:
>> This patch set switches all Renesas platforms to the new style CMT, MTU2 and
>> TMU device platform data. All patches have been previously posted as part of
>> the "[PATCH v3 00/52] Renesas CMT and TMU cleanups" and "[PATCH 00/22] SH MTU2
>> DT support" patch series.
>>
>> This new version fixes an interrupt-related bug introduced when switching the
>> sh7372 and sh73a0 platforms to the new style TMU device, caused by mistakenly
>> using evt2irq instead of intcs_evt2irq for the IRQ resources.
>>
>> Simon, I've tested this on Mackerel and the board now boots correctly. Could
>> you please assist me in debugging the Bock-W boot hang issue, as I don't have
>> access to that board ?
>
> Thanks Laurent,
>
> I have queued this up locally using v6 of patch 12 after resolving some
> conflicts which I will highlight by responding to the patches that are
> affected.
>
> I plan to push this once I have done some testing: especially of the
> resolution to the bockw problem. (I am on a plane with neither internet
> access nor a consignment of boards.)
Tested on Koelsch/r8a7791 (legacy and reference), Armadillo/r8a7740
(legacy and reference), and Genmai/r7s72100 (legacy, reference, and
multiplatform+CCF).
On Koelsch (both legacy and reference), I get:
-sh_cmt sh_cmt.0: used for clock events
-sh_cmt sh_cmt.0: used for periodic clock events
+sh_cmt sh-cmt-48-gen2.0: ch0: used for clock events
+sh_cmt sh-cmt-48-gen2.0: ch0: used for periodic clock events
+sh_cmt sh-cmt-48-gen2.0: ch1: used as clock source
+Switched to clocksource sh-cmt-48-gen2.0
+Clockevents: could not switch to one-shot mode:
+Clockevents: could not switch to one-shot mode: dummy_timer is not functional.
+Could not switch to high resolution mode on CPU 1
+ dummy_timer is not functional.
+Could not switch to high resolution mode on CPU 0
What's up with the high resolution mode?
Armadillo-legacy:
- sh_tmu.0: used for clock events
- sh_tmu.0: used for periodic clock events
- sh_tmu.1: used as clock source
+ sh-tmu.0: ch0: used for clock events
+ sh-tmu.0: ch0: used for periodic clock events
+ sh-tmu.0: ch1: used as clock source
+ sh-cmt-48.1: ch0: used for clock events
+ sh-cmt-48.1: ch1: used as clock source
-sh_cmt sh_cmt.10: used for clock events
-sh_cmt sh_cmt.10: used as clock source
-sh_tmu sh_tmu.0: kept as earlytimer
-sh_tmu sh_tmu.1: kept as earlytimer
-sh_tmu sh_tmu.2: used as clock source
+sh_cmt sh-cmt-48.1: kept as earlytimer
+sh_tmu sh-tmu.0: kept as earlytimer
Armadillo-reference:
-sh_cmt sh_cmt.10: used for clock events
-sh_cmt sh_cmt.10: used for periodic clock events
-sh_cmt sh_cmt.10: used as clock source
+sh_cmt sh-cmt-48.1: ch0: used for clock events
+sh_cmt sh-cmt-48.1: ch0: used for periodic clock events
+sh_cmt sh-cmt-48.1: ch1: used as clock source
Advanced Linux Sound Architecture Driver Initialized.
-Switched to clocksource sh_cmt.10
+Switched to clocksource sh-cmt-48.1
Genmai-legacy/reference:
-sh_mtu2 sh_mtu2.0: no of_node; not parsing pinctrl DT
-sh_mtu2 sh_mtu2.0: used for clock events
-sh_mtu2 sh_mtu2.0: used for periodic clock events
+sh_mtu2 sh-mtu2: no of_node; not parsing pinctrl DT
+sh_mtu2 sh-mtu2: ch0: used for clock events
+sh_mtu2 sh-mtu2: ch0: used for periodic clock events
Genmai-multiplatform+CCF (note: needs addtional patches):
-sh_mtu2 sh_mtu2.0: no of_node; not parsing pinctrl DT
-sh_mtu2 sh_mtu2.0: used for clock events
-sh_mtu2 sh_mtu2.0: used for periodic clock events
+sh_mtu2 sh-mtu2: no of_node; not parsing pinctrl DT
+sh_mtu2 sh-mtu2: using pinctrl dummy state (default)
+sh_mtu2 sh-mtu2: using pinctrl dummy state (sleep)
+sh_mtu2 sh-mtu2: using pinctrl dummy state (idle)
+sh_mtu2 sh-mtu2: ch0: used for clock events
+sh_mtu2 sh-mtu2: ch0: used for periodic clock events
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups
2014-04-23 11:15 [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups Laurent Pinchart
` (2 preceding siblings ...)
2014-05-12 12:11 ` Geert Uytterhoeven
@ 2014-05-12 12:30 ` Geert Uytterhoeven
2014-05-12 14:03 ` Laurent Pinchart
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2014-05-12 12:30 UTC (permalink / raw)
To: linux-sh
On Mon, May 12, 2014 at 2:11 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Genmai-legacy/reference:
>
> -sh_mtu2 sh_mtu2.0: no of_node; not parsing pinctrl DT
> -sh_mtu2 sh_mtu2.0: used for clock events
> -sh_mtu2 sh_mtu2.0: used for periodic clock events
> +sh_mtu2 sh-mtu2: no of_node; not parsing pinctrl DT
> +sh_mtu2 sh-mtu2: ch0: used for clock events
> +sh_mtu2 sh-mtu2: ch0: used for periodic clock events
Correction: this is only for -legacy, -reference behaves like
-multiplatform+CCF below:
> Genmai-multiplatform+CCF (note: needs addtional patches):
>
> -sh_mtu2 sh_mtu2.0: no of_node; not parsing pinctrl DT
> -sh_mtu2 sh_mtu2.0: used for clock events
> -sh_mtu2 sh_mtu2.0: used for periodic clock events
> +sh_mtu2 sh-mtu2: no of_node; not parsing pinctrl DT
> +sh_mtu2 sh-mtu2: using pinctrl dummy state (default)
> +sh_mtu2 sh-mtu2: using pinctrl dummy state (sleep)
> +sh_mtu2 sh-mtu2: using pinctrl dummy state (idle)
> +sh_mtu2 sh-mtu2: ch0: used for clock events
> +sh_mtu2 sh-mtu2: ch0: used for periodic clock events
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups
2014-04-23 11:15 [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups Laurent Pinchart
` (3 preceding siblings ...)
2014-05-12 12:30 ` Geert Uytterhoeven
@ 2014-05-12 14:03 ` Laurent Pinchart
2014-05-12 17:00 ` Geert Uytterhoeven
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Laurent Pinchart @ 2014-05-12 14:03 UTC (permalink / raw)
To: linux-sh
Hi Geert,
Thank you for testing the patch series.
On Monday 12 May 2014 14:11:13 Geert Uytterhoeven wrote:
> On Sun, May 11, 2014 at 4:24 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Apr 23, 2014 at 01:15:07PM +0200, Laurent Pinchart wrote:
> >> This patch set switches all Renesas platforms to the new style CMT, MTU2
> >> and TMU device platform data. All patches have been previously posted as
> >> part of the "[PATCH v3 00/52] Renesas CMT and TMU cleanups" and "[PATCH
> >> 00/22] SH MTU2 DT support" patch series.
> >>
> >> This new version fixes an interrupt-related bug introduced when switching
> >> the sh7372 and sh73a0 platforms to the new style TMU device, caused by
> >> mistakenly using evt2irq instead of intcs_evt2irq for the IRQ resources.
> >>
> >> Simon, I've tested this on Mackerel and the board now boots correctly.
> >> Could you please assist me in debugging the Bock-W boot hang issue, as I
> >> don't have access to that board ?
> >
> > Thanks Laurent,
> >
> > I have queued this up locally using v6 of patch 12 after resolving some
> > conflicts which I will highlight by responding to the patches that are
> > affected.
> >
> > I plan to push this once I have done some testing: especially of the
> > resolution to the bockw problem. (I am on a plane with neither internet
> > access nor a consignment of boards.)
>
> Tested on Koelsch/r8a7791 (legacy and reference), Armadillo/r8a7740
> (legacy and reference), and Genmai/r7s72100 (legacy, reference, and
> multiplatform+CCF).
>
> On Koelsch (both legacy and reference), I get:
>
> -sh_cmt sh_cmt.0: used for clock events
> -sh_cmt sh_cmt.0: used for periodic clock events
> +sh_cmt sh-cmt-48-gen2.0: ch0: used for clock events
> +sh_cmt sh-cmt-48-gen2.0: ch0: used for periodic clock events
> +sh_cmt sh-cmt-48-gen2.0: ch1: used as clock source
> +Switched to clocksource sh-cmt-48-gen2.0
> +Clockevents: could not switch to one-shot mode:
> +Clockevents: could not switch to one-shot mode: dummy_timer is not
> functional.
> +Could not switch to high resolution mode on CPU 1
> + dummy_timer is not functional.
> +Could not switch to high resolution mode on CPU 0
>
> What's up with the high resolution mode?
That's surprising, I haven't noticed anything similar before. I've just tested
Simon's latest devel branch on both Koelsch legacy and Koelsch reference, and
I can't reproduce the problem.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups
2014-04-23 11:15 [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups Laurent Pinchart
` (4 preceding siblings ...)
2014-05-12 14:03 ` Laurent Pinchart
@ 2014-05-12 17:00 ` Geert Uytterhoeven
2014-05-12 20:00 ` Laurent Pinchart
2014-05-12 20:43 ` Geert Uytterhoeven
7 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2014-05-12 17:00 UTC (permalink / raw)
To: linux-sh
Hi Laurent,
On Mon, May 12, 2014 at 4:03 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> On Koelsch (both legacy and reference), I get:
>>
>> -sh_cmt sh_cmt.0: used for clock events
>> -sh_cmt sh_cmt.0: used for periodic clock events
>> +sh_cmt sh-cmt-48-gen2.0: ch0: used for clock events
>> +sh_cmt sh-cmt-48-gen2.0: ch0: used for periodic clock events
>> +sh_cmt sh-cmt-48-gen2.0: ch1: used as clock source
>> +Switched to clocksource sh-cmt-48-gen2.0
>> +Clockevents: could not switch to one-shot mode:
>> +Clockevents: could not switch to one-shot mode: dummy_timer is not
>> functional.
>> +Could not switch to high resolution mode on CPU 1
>> + dummy_timer is not functional.
>> +Could not switch to high resolution mode on CPU 0
>>
>> What's up with the high resolution mode?
>
> That's surprising, I haven't noticed anything similar before. I've just tested
> Simon's latest devel branch on both Koelsch legacy and Koelsch reference, and
> I can't reproduce the problem.
I did some digging, as I'm usually not running directly from Simon's
latest devel branch (currently I have 183 local commits on top of
git:///git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#renesas-drivers-v3.15-rc5-2014-05-12).
The one-shot mode failures I can reproduce with koelsch_defconfig on
renesas-devel-v3.15-rc5-20140511.
For the high resolution mode errors you have to enable HIGH_RES_TIMERS.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups
2014-04-23 11:15 [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups Laurent Pinchart
` (5 preceding siblings ...)
2014-05-12 17:00 ` Geert Uytterhoeven
@ 2014-05-12 20:00 ` Laurent Pinchart
2014-05-12 20:43 ` Geert Uytterhoeven
7 siblings, 0 replies; 9+ messages in thread
From: Laurent Pinchart @ 2014-05-12 20:00 UTC (permalink / raw)
To: linux-sh
Hi Geert,
On Monday 12 May 2014 19:00:28 Geert Uytterhoeven wrote:
> On Mon, May 12, 2014 at 4:03 PM, Laurent Pinchart wrote:
> >> On Koelsch (both legacy and reference), I get:
> >>
> >> -sh_cmt sh_cmt.0: used for clock events
> >> -sh_cmt sh_cmt.0: used for periodic clock events
> >> +sh_cmt sh-cmt-48-gen2.0: ch0: used for clock events
> >> +sh_cmt sh-cmt-48-gen2.0: ch0: used for periodic clock events
> >> +sh_cmt sh-cmt-48-gen2.0: ch1: used as clock source
> >> +Switched to clocksource sh-cmt-48-gen2.0
> >> +Clockevents: could not switch to one-shot mode:
> >> +Clockevents: could not switch to one-shot mode: dummy_timer is not
> >> functional.
> >> +Could not switch to high resolution mode on CPU 1
> >> + dummy_timer is not functional.
> >> +Could not switch to high resolution mode on CPU 0
> >>
> >> What's up with the high resolution mode?
> >
> > That's surprising, I haven't noticed anything similar before. I've just
> > tested Simon's latest devel branch on both Koelsch legacy and Koelsch
> > reference, and I can't reproduce the problem.
>
> I did some digging, as I'm usually not running directly from Simon's
> latest devel branch (currently I have 183 local commits on top of
> git:///git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#ren
> esas-drivers-v3.15-rc5-2014-05-12).
>
> The one-shot mode failures I can reproduce with koelsch_defconfig on
> renesas-devel-v3.15-rc5-20140511.
>
> For the high resolution mode errors you have to enable HIGH_RES_TIMERS.
Actually, after investigating the issue, this isn't really surprising, but
it's a mess nonetheless.
First of all the problem is caused by the combination of the CMT, MTU2 and TMU
cleanups *and* commit 521c42990e9d561ed5ed9f501f07639d0512b3c9 ("tick-common:
Fix wrong check in tick_check_replacement()"). The latter has been merged in
v3.15-rc2, which explains why I haven't noticed the problem before.
Then, please note that the problem only occurs when the architected timer is
disabled in the kernel configuration, which is the case with
koelsch_defconfig. If you enable the architected timer the error messages will
disappear. Please also note that our current timers implementation is broken
when the architected timer is disabled with CONFIG_PREEMPT set. We should
discuss whether that should be fixed, but it's unrelated to this patch series.
Finally, while the kernel log diff seems to imply that the patch series
introduced a regression in high resolution timer support, the reality is that
high resolution timer support was silently disabled before the series.
The timers core code includes a heuristic to assign a use for every clock
event device registered with the kernel. In the r8a7791 case we use a single
clock event device, both before and after this patch series. As we have more
than one CPU we can't dedicate the clock event device to one particular CPU,
so the device gets used as a broadcast timer with one per-cpu dummy timer
triggered by the broadcast timer using IPI. In this mode of operation the
dummy timer only relays the broadcast timer's ticks, and the broadcast timer
must is used in periodic mode. Neither tickless kernel nor high resolution
timers are available in that case.
The reason why this patch set causes alarming messages being printed to the
kernel log is related to nohz mode. With the patches applied a clock source
device is registered, which wasn't the case before. The hrtimer interrupt
calls the tick_check_oneshot_change() function, which checks whether oneshot
mode is possible. Before this patch set no clock source device was available,
and the timekeeping_valid_for_hres() call returning false resulted in
tick_check_oneshot_change() returning early. After this patch set
timekeeping_valid_for_hres() returns true and tick_check_oneshot_change()
calls tick_nohz_switch_to_nohz() which in turn calls tick_switch_to_oneshot()
to switch the timer to oneshot mode. That function fails and prints the
messages you've noticed, as the per-cpu dummy timers can't be switched to
oneshot mode.
I thus believe that the new messages can be ignored.
Please note that the above description corresponds to my understanding of the
existing timers code. There could be bugs both in the code and in my
understanding thereof :-) Daniel, I'd appreciate if you could shed some
additional light on this.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups
2014-04-23 11:15 [PATCH v5 00/15] Renesas CMT, MTU2 and TMU platform cleanups Laurent Pinchart
` (6 preceding siblings ...)
2014-05-12 20:00 ` Laurent Pinchart
@ 2014-05-12 20:43 ` Geert Uytterhoeven
7 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2014-05-12 20:43 UTC (permalink / raw)
To: linux-sh
Hi Laurent,
On Mon, May 12, 2014 at 10:00 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday 12 May 2014 19:00:28 Geert Uytterhoeven wrote:
>> On Mon, May 12, 2014 at 4:03 PM, Laurent Pinchart wrote:
>> >> On Koelsch (both legacy and reference), I get:
>> >> -sh_cmt sh_cmt.0: used for clock events
>> >> -sh_cmt sh_cmt.0: used for periodic clock events
>> >> +sh_cmt sh-cmt-48-gen2.0: ch0: used for clock events
>> >> +sh_cmt sh-cmt-48-gen2.0: ch0: used for periodic clock events
>> >> +sh_cmt sh-cmt-48-gen2.0: ch1: used as clock source
>> >> +Switched to clocksource sh-cmt-48-gen2.0
>> >> +Clockevents: could not switch to one-shot mode:
>> >> +Clockevents: could not switch to one-shot mode: dummy_timer is not
>> >> functional.
>> >> +Could not switch to high resolution mode on CPU 1
>> >> + dummy_timer is not functional.
>> >> +Could not switch to high resolution mode on CPU 0
>> >>
>> >> What's up with the high resolution mode?
>> >
>> > That's surprising, I haven't noticed anything similar before. I've just
>> > tested Simon's latest devel branch on both Koelsch legacy and Koelsch
>> > reference, and I can't reproduce the problem.
>>
>> I did some digging, as I'm usually not running directly from Simon's
>> latest devel branch (currently I have 183 local commits on top of
>> git:///git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#ren
>> esas-drivers-v3.15-rc5-2014-05-12).
>>
>> The one-shot mode failures I can reproduce with koelsch_defconfig on
>> renesas-devel-v3.15-rc5-20140511.
>>
>> For the high resolution mode errors you have to enable HIGH_RES_TIMERS.
>
> Actually, after investigating the issue, this isn't really surprising, but
> it's a mess nonetheless.
>
> First of all the problem is caused by the combination of the CMT, MTU2 and TMU
> cleanups *and* commit 521c42990e9d561ed5ed9f501f07639d0512b3c9 ("tick-common:
> Fix wrong check in tick_check_replacement()"). The latter has been merged in
> v3.15-rc2, which explains why I haven't noticed the problem before.
>
> Then, please note that the problem only occurs when the architected timer is
> disabled in the kernel configuration, which is the case with
> koelsch_defconfig. If you enable the architected timer the error messages will
> disappear.
Indeed. shmobile_defconfig, which uses the architected tiimer, doesn't
show the messages.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread