From: Scott Wood <scottwood@freescale•com>
To: leroy christophe <christophe.leroy@c-s•fr>
Cc: linuxppc-dev@lists•ozlabs.org, Paul Mackerras <paulus@samba•org>,
linux-kernel@vger•kernel.org
Subject: Re: [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
Date: Fri, 20 Sep 2013 16:22:21 -0500 [thread overview]
Message-ID: <1379712141.16231.36.camel@aoeu.buserror.net> (raw)
In-Reply-To: <5238860F.4030405@c-s.fr>
On Tue, 2013-09-17 at 18:40 +0200, leroy christophe wrote:
> Le 16/09/2013 23:02, Scott Wood a =C3=A9crit :
> > On Fri, 2013-09-13 at 07:04 +0200, leroy christophe wrote:
> >> Le 12/09/2013 20:44, Scott Wood a =C3=A9crit :
> >>> On Thu, 2013-09-12 at 20:25 +0200, Christophe Leroy wrote:
> >>>> This is a reorganisation of the setup of the TLB at kernel startup=
, in order
> >>>> to handle the CONFIG_PIN_TLB case in accordance with chapter 8.10.=
3 of MPC866
> >>>> and MPC885 reference manuals.
> >>>>
> >>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s•fr>
> >>>>
> >>>> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/=
arch/powerpc/kernel/head_8xx.S
> >>>> --- linux-3.11.org/arch/powerpc/kernel/head_8xx.S 2013-09-02 22:46=
:10.000000000 +0200
> >>>> +++ linux-3.11/arch/powerpc/kernel/head_8xx.S 2013-09-09 11:28:54.=
000000000 +0200
> >>>> @@ -785,27 +785,24 @@
> >>>> * these mappings is mapped by page tables.
> >>>> */
> >>>> initial_mmu:
> >>>> - tlbia /* Invalidate all TLB entries */
> >>>> -/* Always pin the first 8 MB ITLB to prevent ITLB
> >>>> - misses while mucking around with SRR0/SRR1 in asm
> >>>> -*/
> >>>> - lis r8, MI_RSV4I@h
> >>>> - ori r8, r8, 0x1c00
> >>>> -
> >>>> + lis r8, MI_RESETVAL@h
> >>>> mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */
> >>>> =20
> >>>> -#ifdef CONFIG_PIN_TLB
> >>>> - lis r10, (MD_RSV4I | MD_RESETVAL)@h
> >>>> - ori r10, r10, 0x1c00
> >>>> - mr r8, r10
> >>>> -#else
> >>>> lis r10, MD_RESETVAL@h
> >>>> -#endif
> >>>> #ifndef CONFIG_8xx_COPYBACK
> >>>> oris r10, r10, MD_WTDEF@h
> >>>> #endif
> >>>> mtspr SPRN_MD_CTR, r10 /* Set data TLB control */
> >>>> =20
> >>>> + tlbia /* Invalidate all TLB entries */
> >>> Is this change to make sure we invalidate everything even if the
> >>> bootloader set RSV4I?
> >> Most probably. It is step 2 of the process defined in MPC866 and MPC=
885
> >> Reference Manuals:
> >>
> >> =C2=A78.10.3 Loading Locked TLB Entries:
> >> The process of loading a single reserved entry in the TLB is as foll=
ows:
> > To minimize code churn we should just fix actual problems, rather tha=
n
> > shuffle things around to conform to a suggested sequence. After all,
> > we're not just trying to load a single entry.
> Ok, I'll try again.
> >
> >>>> + ori r8, r8, 0x1c00
> >>>> + mtspr SPRN_MI_CTR, r8 /* Set instruction MMU control */
> >>>> +#ifdef CONFIG_PIN_TLB
> >>>> + ori r10, r10, 0x1c00
> >>>> + mtspr SPRN_MD_CTR, r10 /* Set data TLB control */
> >>>> +#endif
> >>> Still 0x1c00?
> >> Yes, I kept the same entries in order to limit modifications:
> >> * 28 =3D First 8Mbytes page
> >> * 29 =3D IMMR
> >> * 30 =3D Second 8Mbytes page
> >> * 31 =3D Third 8Mbytes page
> > If you actually want to program them in increasing order then it look=
s
> > like you're still missing a write to CTR between the last two 8M entr=
ies
> > -- thus you'll overwrite the IMMR with the last 8M entry. That was t=
he
> > same problem that v1 fixed -- did that change get lost accidentally?
> Oops, no, in fact I diffed from the version which was including it=20
> already. My mistake.
> >
> > The hardware wants to decrement; why fight it?
> I see your point.
> However it is not clear in the documentation if the decrement is done=20
> really after the update, or at xTLB interrupt. So I propose to still se=
t=20
> the CTR ourself as described in the reference Manual and not assume tha=
t=20
> the HW decrements it.
It says "every update" -- do you have any reason to believe that's
wrong? It could be tested...
-Scott
next prev parent reply other threads:[~2013-09-20 21:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-12 18:25 [PATCH v2] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB Christophe Leroy
2013-09-12 18:44 ` Scott Wood
2013-09-13 5:04 ` leroy christophe
2013-09-16 21:02 ` Scott Wood
2013-09-17 16:40 ` leroy christophe
2013-09-20 21:22 ` Scott Wood [this message]
2013-09-24 8:00 ` leroy christophe
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=1379712141.16231.36.camel@aoeu.buserror.net \
--to=scottwood@freescale$(echo .)com \
--cc=christophe.leroy@c-s$(echo .)fr \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox