From: leroy christophe <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
Date: Tue, 17 Dec 2013 06:54:21 +0100 [thread overview]
Message-ID: <52AFE70D.70407@c-s.fr> (raw)
In-Reply-To: <1387234621.10013.408.camel@snotra.buserror.net>
Le 16/12/2013 23:57, Scott Wood a écrit :
> On Wed, 2013-12-11 at 00:36 +0100, leroy christophe wrote:
>> Le 11/12/2013 00:18, Scott Wood a écrit :
>>> There wasn't previously an ifdef specifically around the setting of
>>> SPRN_MD_CTR. That's new. There was an ifdef around the entire block,
>>> which has gone away because you are now trying to map more than 8M
>>> regardless of CONFIG_PIN_TLB, but that has nothing to do with whether
>>> there should be an ifdef around SPRN_MD_CTR.
>>>
>>>
>> Euh, ok, but then we have to fix it in the whole function, not only in
>> this block. Do you think it is worth doing it ?
> Fix what in the whole function? I was asking what harm there would be
> if you just remove all the CONFIG_PIN_TLB ifdefs except around the
> actual RSV4I setting -- do we really care what value goes in MD_CTR for
> the non-pinned case, as long as it's different for each entry?
>
>
MD_CTR is decremented after each entry added.
However, the function populates entry 28, then 29, then 30, then 31. At
the end MD_CTR has then value 30, ready to overide entry 30 then 29 then
28 then 27 .....
So I will remove all the CONFIG_PIN_TLB, but I'll also have to fix the
value set in MD_CTR to start from 31, won't I ?
Do you have any comment/recommendation on my tentative v3 patch where I
have tried to implement based on the use of r7 as you recommended ?
Christophe
WARNING: multiple messages have this Message-ID (diff)
From: leroy christophe <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
Date: Tue, 17 Dec 2013 06:54:21 +0100 [thread overview]
Message-ID: <52AFE70D.70407@c-s.fr> (raw)
In-Reply-To: <1387234621.10013.408.camel@snotra.buserror.net>
Le 16/12/2013 23:57, Scott Wood a écrit :
> On Wed, 2013-12-11 at 00:36 +0100, leroy christophe wrote:
>> Le 11/12/2013 00:18, Scott Wood a écrit :
>>> There wasn't previously an ifdef specifically around the setting of
>>> SPRN_MD_CTR. That's new. There was an ifdef around the entire block,
>>> which has gone away because you are now trying to map more than 8M
>>> regardless of CONFIG_PIN_TLB, but that has nothing to do with whether
>>> there should be an ifdef around SPRN_MD_CTR.
>>>
>>>
>> Euh, ok, but then we have to fix it in the whole function, not only in
>> this block. Do you think it is worth doing it ?
> Fix what in the whole function? I was asking what harm there would be
> if you just remove all the CONFIG_PIN_TLB ifdefs except around the
> actual RSV4I setting -- do we really care what value goes in MD_CTR for
> the non-pinned case, as long as it's different for each entry?
>
>
MD_CTR is decremented after each entry added.
However, the function populates entry 28, then 29, then 30, then 31. At
the end MD_CTR has then value 30, ready to overide entry 30 then 29 then
28 then 27 .....
So I will remove all the CONFIG_PIN_TLB, but I'll also have to fix the
value set in MD_CTR to start from 31, won't I ?
Do you have any comment/recommendation on my tentative v3 patch where I
have tried to implement based on the use of r7 as you recommended ?
Christophe
next prev parent reply other threads:[~2013-12-17 5:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-10 11:29 [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB Christophe Leroy
2013-12-10 11:29 ` Christophe Leroy
2013-12-10 22:24 ` Scott Wood
2013-12-10 22:24 ` Scott Wood
2013-12-10 23:05 ` leroy christophe
2013-12-10 23:05 ` leroy christophe
2013-12-10 23:18 ` Scott Wood
2013-12-10 23:18 ` Scott Wood
2013-12-10 23:36 ` leroy christophe
2013-12-10 23:36 ` leroy christophe
2013-12-16 22:57 ` Scott Wood
2013-12-16 22:57 ` Scott Wood
2013-12-17 5:54 ` leroy christophe [this message]
2013-12-17 5:54 ` leroy christophe
2013-12-17 22:38 ` Scott Wood
2013-12-17 22:38 ` Scott Wood
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=52AFE70D.70407@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=scottwood@freescale.com \
/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.