From: Simon Horman <horms@verge.net.au>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: shmobile: Check r8a7791 MD21 at SMP boot
Date: Thu, 13 Mar 2014 02:02:35 +0000 [thread overview]
Message-ID: <20140313020231.GC16719@verge.net.au> (raw)
In-Reply-To: <CAMuHMdU9CPsvV-MdO88QG3Xd0QQJxK0w9nH5ky6b+t7_rXsFGw@mail.gmail.com>
On Thu, Feb 27, 2014 at 09:08:06AM +0100, Geert Uytterhoeven wrote:
> Hi Magnus,
>
> On Thu, Feb 27, 2014 at 4:33 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> >>> This is a reworked version of the APMU patch previously posted as
> >>> [PATCH] ARM: shmobile: Check MD21 at SMP boot in case of APMU
> >>
> >> Your previous version also affected r8a7790/Lager.
> >> Isn't this check no longer needed there? According to the Lager manual,
> >> MD21 also enables hardware debug mode, and is also controlled by
> >> SW8-4. Of course the CPU may behave differently, as the CPU cores
> >> are different.
> >
> > Yes, you are correct that the previous version of the patch also
> > affected Lager. And that both r8a7790 and r8a7791 mention the MD21 bit
> > together with JTAG debugging.
> >
> > I recently used the patch on Lager and I discovered that I apparently
> > had been running with MD21 on my Lager since forever, and surprisingly
> > it worked regardless. Since there is no documentation on r8a7790 or
> > r8a7791 I simply decided to handle them separately and only enable
> > where it is needed.
>
> You could have been lucky?
>
> On Koelsch, I only had failures after Real Cold Boot, i.e. on boot up in the
> morning. And not always, so there could be a timing issue involved.
>
> > I've also been told that it is possible to allow SMP operation
> > together with JTAG, apparently some magic with RST is needed. It seems
> > that the power domains are treated differently depending on the MD21
> > setting. Not sure if this applies to both r8a7790 and r8a7791, but if
> > we end up with similar fixes we can consolidate. Until then I think
> > dealing with them one by one makes sense.
>
> Furthermore, I haven't seen any SPI timeouts after I disabled MD21 (holding
> wood, and rabbit legs ;-). So the SMP memory (in)coherency I saw there
> could have been caused by a wobbly SMP setup.
Hi Magnus,
I am a little confused about the status of this patch?
Would you like me to queue it up?
WARNING: multiple messages have this Message-ID (diff)
From: horms@verge.net.au (Simon Horman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: shmobile: Check r8a7791 MD21 at SMP boot
Date: Thu, 13 Mar 2014 11:02:35 +0900 [thread overview]
Message-ID: <20140313020231.GC16719@verge.net.au> (raw)
In-Reply-To: <CAMuHMdU9CPsvV-MdO88QG3Xd0QQJxK0w9nH5ky6b+t7_rXsFGw@mail.gmail.com>
On Thu, Feb 27, 2014 at 09:08:06AM +0100, Geert Uytterhoeven wrote:
> Hi Magnus,
>
> On Thu, Feb 27, 2014 at 4:33 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> >>> This is a reworked version of the APMU patch previously posted as
> >>> [PATCH] ARM: shmobile: Check MD21 at SMP boot in case of APMU
> >>
> >> Your previous version also affected r8a7790/Lager.
> >> Isn't this check no longer needed there? According to the Lager manual,
> >> MD21 also enables hardware debug mode, and is also controlled by
> >> SW8-4. Of course the CPU may behave differently, as the CPU cores
> >> are different.
> >
> > Yes, you are correct that the previous version of the patch also
> > affected Lager. And that both r8a7790 and r8a7791 mention the MD21 bit
> > together with JTAG debugging.
> >
> > I recently used the patch on Lager and I discovered that I apparently
> > had been running with MD21 on my Lager since forever, and surprisingly
> > it worked regardless. Since there is no documentation on r8a7790 or
> > r8a7791 I simply decided to handle them separately and only enable
> > where it is needed.
>
> You could have been lucky?
>
> On Koelsch, I only had failures after Real Cold Boot, i.e. on boot up in the
> morning. And not always, so there could be a timing issue involved.
>
> > I've also been told that it is possible to allow SMP operation
> > together with JTAG, apparently some magic with RST is needed. It seems
> > that the power domains are treated differently depending on the MD21
> > setting. Not sure if this applies to both r8a7790 and r8a7791, but if
> > we end up with similar fixes we can consolidate. Until then I think
> > dealing with them one by one makes sense.
>
> Furthermore, I haven't seen any SPI timeouts after I disabled MD21 (holding
> wood, and rabbit legs ;-). So the SMP memory (in)coherency I saw there
> could have been caused by a wobbly SMP setup.
Hi Magnus,
I am a little confused about the status of this patch?
Would you like me to queue it up?
next prev parent reply other threads:[~2014-03-13 2:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-26 9:59 [PATCH] ARM: shmobile: Check r8a7791 MD21 at SMP boot Magnus Damm
2014-02-26 9:59 ` Magnus Damm
2014-02-26 10:11 ` Geert Uytterhoeven
2014-02-26 10:11 ` Geert Uytterhoeven
2014-02-27 3:33 ` Magnus Damm
2014-02-27 3:33 ` Magnus Damm
2014-02-27 8:08 ` Geert Uytterhoeven
2014-02-27 8:08 ` Geert Uytterhoeven
2014-03-13 2:02 ` Simon Horman [this message]
2014-03-13 2:02 ` Simon Horman
2014-03-13 4:59 ` Magnus Damm
2014-03-13 4:59 ` Magnus Damm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140313020231.GC16719@verge.net.au \
--to=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.