* Re: [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
2014-11-05 10:04 [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock Geert Uytterhoeven
@ 2014-11-10 0:52 ` Simon Horman
2014-11-12 0:34 ` Simon Horman
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Simon Horman @ 2014-11-10 0:52 UTC (permalink / raw)
To: linux-sh
On Wed, Nov 05, 2014 at 11:04:33AM +0100, Geert Uytterhoeven wrote:
> According to the datasheet, the operating clock for IIC0 is the HPP
> (RT Peri) clock, not the SUB (Peri) clock. Both clocks run at the same
> speed (50 Mhz).
>
> This is consistent with IIC0 being located in the A4R PM domain, and
> IIC1 in the A3SP PM domain.
Thanks, I have queued this up.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> arch/arm/mach-shmobile/clock-r8a7740.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
> index dbb0ab283e2fe91f..9cac8247c72b6e45 100644
> --- a/arch/arm/mach-shmobile/clock-r8a7740.c
> +++ b/arch/arm/mach-shmobile/clock-r8a7740.c
> @@ -470,7 +470,7 @@ static struct clk mstp_clks[MSTP_NR] = {
> [MSTP127] = SH_CLK_MSTP32(&div4_clks[DIV4_S], SMSTPCR1, 27, 0), /* CEU20 */
> [MSTP125] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 25, 0), /* TMU0 */
> [MSTP117] = SH_CLK_MSTP32(&div4_clks[DIV4_B], SMSTPCR1, 17, 0), /* LCDC1 */
> - [MSTP116] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 16, 0), /* IIC0 */
> + [MSTP116] = SH_CLK_MSTP32(&div4_clks[DIV4_HPP], SMSTPCR1, 16, 0), /* IIC0 */
> [MSTP111] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 11, 0), /* TMU1 */
> [MSTP100] = SH_CLK_MSTP32(&div4_clks[DIV4_B], SMSTPCR1, 0, 0), /* LCDC0 */
>
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
2014-11-05 10:04 [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock Geert Uytterhoeven
2014-11-10 0:52 ` Simon Horman
@ 2014-11-12 0:34 ` Simon Horman
2014-11-12 2:27 ` Simon Horman
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Simon Horman @ 2014-11-12 0:34 UTC (permalink / raw)
To: linux-sh
On Mon, Nov 10, 2014 at 09:52:38AM +0900, Simon Horman wrote:
> On Wed, Nov 05, 2014 at 11:04:33AM +0100, Geert Uytterhoeven wrote:
> > According to the datasheet, the operating clock for IIC0 is the HPP
> > (RT Peri) clock, not the SUB (Peri) clock. Both clocks run at the same
> > speed (50 Mhz).
> >
> > This is consistent with IIC0 being located in the A4R PM domain, and
> > IIC1 in the A3SP PM domain.
>
> Thanks, I have queued this up.
Hi Geert,
As this appears to be a bug fix I would like to accompany this patch with
some text describing when the problem was introduced and what its effects
are. In short a rough guide to if it should be applied to -stable. To that
end I prepared the following which I would appreciate your feedback on.
* ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
This problem appears to have been introduced when IIC0 support was
added to the r8a7740 by 6831f3a9184a1c540 ("ARM: mach-shmobile: r8a7740:
add i2c support") in v3.2.
I am not aware of any run-time effect of this problem
>
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > arch/arm/mach-shmobile/clock-r8a7740.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
> > index dbb0ab283e2fe91f..9cac8247c72b6e45 100644
> > --- a/arch/arm/mach-shmobile/clock-r8a7740.c
> > +++ b/arch/arm/mach-shmobile/clock-r8a7740.c
> > @@ -470,7 +470,7 @@ static struct clk mstp_clks[MSTP_NR] = {
> > [MSTP127] = SH_CLK_MSTP32(&div4_clks[DIV4_S], SMSTPCR1, 27, 0), /* CEU20 */
> > [MSTP125] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 25, 0), /* TMU0 */
> > [MSTP117] = SH_CLK_MSTP32(&div4_clks[DIV4_B], SMSTPCR1, 17, 0), /* LCDC1 */
> > - [MSTP116] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 16, 0), /* IIC0 */
> > + [MSTP116] = SH_CLK_MSTP32(&div4_clks[DIV4_HPP], SMSTPCR1, 16, 0), /* IIC0 */
> > [MSTP111] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 11, 0), /* TMU1 */
> > [MSTP100] = SH_CLK_MSTP32(&div4_clks[DIV4_B], SMSTPCR1, 0, 0), /* LCDC0 */
> >
> > --
> > 1.9.1
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
2014-11-05 10:04 [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock Geert Uytterhoeven
2014-11-10 0:52 ` Simon Horman
2014-11-12 0:34 ` Simon Horman
@ 2014-11-12 2:27 ` Simon Horman
2014-11-12 9:06 ` Geert Uytterhoeven
2014-11-12 9:10 ` Simon Horman
4 siblings, 0 replies; 6+ messages in thread
From: Simon Horman @ 2014-11-12 2:27 UTC (permalink / raw)
To: linux-sh
On Wed, Nov 12, 2014 at 09:34:23AM +0900, Simon Horman wrote:
> On Mon, Nov 10, 2014 at 09:52:38AM +0900, Simon Horman wrote:
> > On Wed, Nov 05, 2014 at 11:04:33AM +0100, Geert Uytterhoeven wrote:
> > > According to the datasheet, the operating clock for IIC0 is the HPP
> > > (RT Peri) clock, not the SUB (Peri) clock. Both clocks run at the same
> > > speed (50 Mhz).
> > >
> > > This is consistent with IIC0 being located in the A4R PM domain, and
> > > IIC1 in the A3SP PM domain.
> >
> > Thanks, I have queued this up.
>
> Hi Geert,
>
> As this appears to be a bug fix I would like to accompany this patch with
> some text describing when the problem was introduced and what its effects
> are. In short a rough guide to if it should be applied to -stable. To that
> end I prepared the following which I would appreciate your feedback on.
>
> * ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
>
> This problem appears to have been introduced when IIC0 support was
> added to the r8a7740 by 6831f3a9184a1c540 ("ARM: mach-shmobile: r8a7740:
> add i2c support") in v3.2.
s/v3.2/v3.3/
> I am not aware of any run-time effect of this problem
>
> >
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > arch/arm/mach-shmobile/clock-r8a7740.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
> > > index dbb0ab283e2fe91f..9cac8247c72b6e45 100644
> > > --- a/arch/arm/mach-shmobile/clock-r8a7740.c
> > > +++ b/arch/arm/mach-shmobile/clock-r8a7740.c
> > > @@ -470,7 +470,7 @@ static struct clk mstp_clks[MSTP_NR] = {
> > > [MSTP127] = SH_CLK_MSTP32(&div4_clks[DIV4_S], SMSTPCR1, 27, 0), /* CEU20 */
> > > [MSTP125] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 25, 0), /* TMU0 */
> > > [MSTP117] = SH_CLK_MSTP32(&div4_clks[DIV4_B], SMSTPCR1, 17, 0), /* LCDC1 */
> > > - [MSTP116] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 16, 0), /* IIC0 */
> > > + [MSTP116] = SH_CLK_MSTP32(&div4_clks[DIV4_HPP], SMSTPCR1, 16, 0), /* IIC0 */
> > > [MSTP111] = SH_CLK_MSTP32(&div6_clks[DIV6_SUB], SMSTPCR1, 11, 0), /* TMU1 */
> > > [MSTP100] = SH_CLK_MSTP32(&div4_clks[DIV4_B], SMSTPCR1, 0, 0), /* LCDC0 */
> > >
> > > --
> > > 1.9.1
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
2014-11-05 10:04 [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock Geert Uytterhoeven
` (2 preceding siblings ...)
2014-11-12 2:27 ` Simon Horman
@ 2014-11-12 9:06 ` Geert Uytterhoeven
2014-11-12 9:10 ` Simon Horman
4 siblings, 0 replies; 6+ messages in thread
From: Geert Uytterhoeven @ 2014-11-12 9:06 UTC (permalink / raw)
To: linux-sh
Hi Simon,
On Wed, Nov 12, 2014 at 3:27 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Nov 12, 2014 at 09:34:23AM +0900, Simon Horman wrote:
>> On Mon, Nov 10, 2014 at 09:52:38AM +0900, Simon Horman wrote:
>> > On Wed, Nov 05, 2014 at 11:04:33AM +0100, Geert Uytterhoeven wrote:
>> > > According to the datasheet, the operating clock for IIC0 is the HPP
>> > > (RT Peri) clock, not the SUB (Peri) clock. Both clocks run at the same
>> > > speed (50 Mhz).
>> > >
>> > > This is consistent with IIC0 being located in the A4R PM domain, and
>> > > IIC1 in the A3SP PM domain.
>> >
>> > Thanks, I have queued this up.
>>
>> Hi Geert,
>>
>> As this appears to be a bug fix I would like to accompany this patch with
>> some text describing when the problem was introduced and what its effects
>> are. In short a rough guide to if it should be applied to -stable. To that
>> end I prepared the following which I would appreciate your feedback on.
>>
>> * ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
>>
>> This problem appears to have been introduced when IIC0 support was
>> added to the r8a7740 by 6831f3a9184a1c540 ("ARM: mach-shmobile: r8a7740:
>> add i2c support") in v3.2.
That's the commit where it became effective. The bug was introduced in
commit 6c01ba445cecb2d8 ("ARM: mach-shmobile: R-Mobile A1 support.").
> s/v3.2/v3.3/
>
>
>> I am not aware of any run-time effect of this problem
Indeed. Both clocks run at the same frequency, and TTBOMK the HPP clock
cannot be disabled (is that correct?), so the IIC0 clock cannot be inadvertently
be disabled because the common part is disabled through another clock.
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] 6+ messages in thread* Re: [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
2014-11-05 10:04 [PATCH 1/2] ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock Geert Uytterhoeven
` (3 preceding siblings ...)
2014-11-12 9:06 ` Geert Uytterhoeven
@ 2014-11-12 9:10 ` Simon Horman
4 siblings, 0 replies; 6+ messages in thread
From: Simon Horman @ 2014-11-12 9:10 UTC (permalink / raw)
To: linux-sh
On Wed, Nov 12, 2014 at 10:06:34AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Wed, Nov 12, 2014 at 3:27 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Nov 12, 2014 at 09:34:23AM +0900, Simon Horman wrote:
> >> On Mon, Nov 10, 2014 at 09:52:38AM +0900, Simon Horman wrote:
> >> > On Wed, Nov 05, 2014 at 11:04:33AM +0100, Geert Uytterhoeven wrote:
> >> > > According to the datasheet, the operating clock for IIC0 is the HPP
> >> > > (RT Peri) clock, not the SUB (Peri) clock. Both clocks run at the same
> >> > > speed (50 Mhz).
> >> > >
> >> > > This is consistent with IIC0 being located in the A4R PM domain, and
> >> > > IIC1 in the A3SP PM domain.
> >> >
> >> > Thanks, I have queued this up.
> >>
> >> Hi Geert,
> >>
> >> As this appears to be a bug fix I would like to accompany this patch with
> >> some text describing when the problem was introduced and what its effects
> >> are. In short a rough guide to if it should be applied to -stable. To that
> >> end I prepared the following which I would appreciate your feedback on.
> >>
> >> * ARM: shmobile: r8a7740 legacy: Correct IIC0 parent clock
> >>
> >> This problem appears to have been introduced when IIC0 support was
> >> added to the r8a7740 by 6831f3a9184a1c540 ("ARM: mach-shmobile: r8a7740:
> >> add i2c support") in v3.2.
>
> That's the commit where it became effective. The bug was introduced in
> commit 6c01ba445cecb2d8 ("ARM: mach-shmobile: R-Mobile A1 support.").
Thanks, I have updated my description accordingly.
> > s/v3.2/v3.3/
> >
> >
> >> I am not aware of any run-time effect of this problem
>
> Indeed. Both clocks run at the same frequency, and TTBOMK the HPP clock
> cannot be disabled (is that correct?), so the IIC0 clock cannot be inadvertently
> be disabled because the common part is disabled through another clock.
That sounds like a question for Morimoto-san :)
^ permalink raw reply [flat|nested] 6+ messages in thread