From: Scott Wood <scottwood@freescale.com>
To: Becky Bruce <becky.bruce@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v2] POWERPC: Allow 32-bit pgtable code to support 36-bit physical
Date: Wed, 27 Aug 2008 18:43:51 -0500 [thread overview]
Message-ID: <48B5E6B7.3000903@freescale.com> (raw)
In-Reply-To: <1219876690-21163-1-git-send-email-becky.bruce@freescale.com>
Becky Bruce wrote:
> #if _PAGE_HASHPTE != 0
> +#ifndef CONFIG_PTE_64BIT
> pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) & ~_PAGE_HASHPTE);
> #else
> + /*
> + * We have to do the write of the 64b pte as 2 stores. This
> + * code assumes that the entry we're storing to is currently
> + * not valid and that all callers have the page table lock.
> + * Having the entry be not valid protects readers who might read
> + * between the first and second stores.
> + */
> + unsigned int tmp;
> +
> + __asm__ __volatile__("\
> +1: lwarx %0,0,%4\n\
> + rlwimi %L2,%0,0,30,30\n\
> + stw %2,0(%3)\n\
> + eieio\n\
> + stwcx. %L2,0,%4\n\
> + bne- 1b"
> + : "=&r" (tmp), "=m" (*ptep)
> + : "r" (pte), "r" (ptep), "r" ((unsigned long)(ptep) + 4), "m" (*ptep)
> + : "cc");
> +#endif /* CONFIG_PTE_64BIT */
Could the stw to the same reservation granule as the stwcx cancel the
reservation on some implementations? Plus, if you're assuming that the
entry is currently invalid and all callers have the page table lock, do
we need the lwarx/stwcx at all? At the least, it should check
PTE_ATOMIC_UPDATES.
%2 should be "+&r", not "r".
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 7f65127..ca5b58b 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -128,18 +128,22 @@ config FSL_EMB_PERFMON
>
> config PTE_64BIT
> bool
> - depends on 44x || E500
> + depends on 44x || E500 || 6xx
> default y if 44x
> - default y if E500 && PHYS_64BIT
> + default y if PHYS_64BIT
How is this different from PHYS_64BIT?
> config PHYS_64BIT
> - bool 'Large physical address support' if E500
> - depends on 44x || E500
> + bool 'Large physical address support' if E500 || 6xx
Maybe "if !44x", or have 44x "select" this, rather than listing all
arches where it's optional.
> + depends on 44x || E500 || 6xx
> select RESOURCES_64BIT
> default y if 44x
> ---help---
> This option enables kernel support for larger than 32-bit physical
> - addresses. This features is not be available on all e500 cores.
> + addresses. This features is not be available on all cores.
"This features is not be"?
-Scott
next prev parent reply other threads:[~2008-08-27 23:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 22:38 [PATCH v2] POWERPC: Allow 32-bit pgtable code to support 36-bit physical Becky Bruce
2008-08-27 23:43 ` Scott Wood [this message]
2008-08-28 15:36 ` Becky Bruce
2008-08-28 16:07 ` Scott Wood
2008-08-28 19:37 ` Becky Bruce
2008-08-28 20:28 ` Scott Wood
2008-08-28 21:13 ` Becky Bruce
2008-08-28 22:42 ` Benjamin Herrenschmidt
2008-08-30 16:24 ` Scott Wood
2008-08-31 8:22 ` Benjamin Herrenschmidt
2008-09-01 5:28 ` Benjamin Herrenschmidt
2008-09-01 5:19 ` Benjamin Herrenschmidt
2008-09-02 16:19 ` Becky Bruce
2008-09-02 21:21 ` Benjamin Herrenschmidt
2008-09-03 15:10 ` Becky Bruce
2008-09-04 2:53 ` Benjamin Herrenschmidt
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=48B5E6B7.3000903@freescale.com \
--to=scottwood@freescale.com \
--cc=becky.bruce@freescale.com \
--cc=linuxppc-dev@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).