[PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Li Yang]

Fix the problem that large physical address support cannot be
disabled when some platforms which only provides 36-bit support
are selected.  According to the philosophy of kernel config
enabling a platform support doesn't mean the kernel is only
running on that platform.  Remove the auto selection of PHYS_64BIT
option for these platforms.  They will need to use a 36bit default
config that selects PHYS_64BIT explicitly.

The reason why we need to keep PHYS_64BIT option configurable is
that enabling it cause negative performance impact on various
aspects like TLB miss and physical address manipulating.  We should
not enable it unless really needed, e.g. use large memory of 4GB
or bigger.

Signed-off-by: Li Yang <leoli@freescale.com>
---
 arch/powerpc/platforms/85xx/Kconfig |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index d7946be..d9bc0bd 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -80,7 +80,6 @@ config P1010_RDB
 config P1022_DS
 	bool "Freescale P1022 DS"
 	select DEFAULT_UIMAGE
-	select PHYS_64BIT	# The DTS has 36-bit addresses
 	select SWIOTLB
 	help
 	  This option enables support for the Freescale P1022DS reference board.
@@ -175,7 +174,6 @@ config P2041_RDB
 	bool "Freescale P2041 RDB"
 	select DEFAULT_UIMAGE
 	select PPC_E500MC
-	select PHYS_64BIT
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
 	select GPIO_MPC8XXX
@@ -188,7 +186,6 @@ config P3041_DS
 	bool "Freescale P3041 DS"
 	select DEFAULT_UIMAGE
 	select PPC_E500MC
-	select PHYS_64BIT
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
 	select GPIO_MPC8XXX
@@ -201,7 +198,6 @@ config P3060_QDS
 	bool "Freescale P3060 QDS"
 	select DEFAULT_UIMAGE
 	select PPC_E500MC
-	select PHYS_64BIT
 	select SWIOTLB
 	select GPIO_MPC8XXX
 	select HAS_RAPIDIO
@@ -213,7 +209,6 @@ config P4080_DS
 	bool "Freescale P4080 DS"
 	select DEFAULT_UIMAGE
 	select PPC_E500MC
-	select PHYS_64BIT
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
 	select GPIO_MPC8XXX
@@ -229,7 +224,6 @@ config P5020_DS
 	select DEFAULT_UIMAGE
 	select E500
 	select PPC_E500MC
-	select PHYS_64BIT
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
 	select GPIO_MPC8XXX
-- 
1.5.4.3

[PATCH 2/2] powerpc/85xx: add a 36-bit corenet default config

[Li Yang]

This default config should be used by platforms that only
provides 36-bit software support in tree, such as P3041DS,
P3060QDS, P4080DS, P5020DS, and etc.

Signed-off-by: Li Yang <leoli@freescale.com>
---
 arch/powerpc/configs/corenet36_smp_defconfig |  185 ++++++++++++++++++++++++++
 1 files changed, 185 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/configs/corenet36_smp_defconfig

diff --git a/arch/powerpc/configs/corenet36_smp_defconfig b/arch/powerpc/configs/corenet36_smp_defconfig
new file mode 100644
index 0000000..9765b4d
--- /dev/null
+++ b/arch/powerpc/configs/corenet36_smp_defconfig
@@ -0,0 +1,185 @@
+CONFIG_PPC_85xx=y
+CONFIG_PHYS_64BIT=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=8
+CONFIG_EXPERIMENTAL=y
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_AUDIT=y
+CONFIG_SPARSE_IRQ=y
+CONFIG_RCU_TRACE=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_P2041_RDB=y
+CONFIG_P3041_DS=y
+CONFIG_P3060_QDS=y
+CONFIG_P4080_DS=y
+CONFIG_P5020_DS=y
+CONFIG_HIGHMEM=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_BINFMT_MISC=m
+CONFIG_KEXEC=y
+CONFIG_FORCE_MAX_ZONEORDER=13
+CONFIG_FSL_LBC=y
+CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
+# CONFIG_PCIEASPM is not set
+CONFIG_RAPIDIO=y
+CONFIG_FSL_RIO=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=y
+CONFIG_XFRM_SUB_POLICY=y
+CONFIG_XFRM_STATISTICS=y
+CONFIG_NET_KEY=y
+CONFIG_NET_KEY_MIGRATE=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPIP=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+CONFIG_ARPD=y
+CONFIG_INET_AH=y
+CONFIG_INET_ESP=y
+CONFIG_INET_IPCOMP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_IP_SCTP=m
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_M25P80=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_MISC_DEVICES=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_ST=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SYM53C8XX_2=y
+CONFIG_ATA=y
+CONFIG_SATA_AHCI=y
+CONFIG_SATA_FSL=y
+CONFIG_SATA_SIL24=y
+CONFIG_SATA_SIL=y
+CONFIG_PATA_SIL680=y
+CONFIG_NETDEVICES=y
+CONFIG_FSL_PQ_MDIO=y
+CONFIG_E1000=y
+CONFIG_E1000E=y
+CONFIG_VITESSE_PHY=y
+CONFIG_FIXED_PHY=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_SERIO_LIBPS2=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_PPC_EPAPR_HV_BYTECHAN=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_DETECT_IRQ=y
+CONFIG_SERIAL_8250_RSA=y
+CONFIG_HW_RANDOM=y
+CONFIG_NVRAM=y
+CONFIG_I2C=y
+CONFIG_I2C_MPC=y
+CONFIG_SPI=y
+CONFIG_SPI_GPIO=y
+CONFIG_SPI_FSL_SPI=y
+CONFIG_SPI_FSL_ESPI=y
+# CONFIG_HWMON is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_USB_HID=m
+CONFIG_USB=y
+CONFIG_USB_DEVICEFS=y
+CONFIG_USB_MON=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_FSL=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
+CONFIG_USB_OHCI_HCD_PPC_OF_LE=y
+CONFIG_USB_STORAGE=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_EDAC=y
+CONFIG_EDAC_MM_EDAC=y
+CONFIG_EDAC_MPC85XX=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS3232=y
+CONFIG_RTC_DRV_CMOS=y
+CONFIG_UIO=y
+CONFIG_STAGING=y
+CONFIG_VIRT_DRIVERS=y
+CONFIG_FSL_HV_MANAGER=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=m
+CONFIG_VFAT_FS=y
+CONFIG_NTFS_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_HUGETLBFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_CRAMFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NFSD=m
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_MAC_PARTITION=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=m
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_SHIRQ=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEBUG_INFO=y
+CONFIG_SYSCTL_SYSCALL_CHECK=y
+CONFIG_CRYPTO_NULL=y
+CONFIG_CRYPTO_PCBC=m
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_SHA256=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_AES=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_DEV_FSL_CAAM=y
-- 
1.5.4.3

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Tabi Timur-B04825]

On Thu, Feb 16, 2012 at 6:10 AM, Li Yang <leoli@freescale.com> wrote:
>
> The reason why we need to keep PHYS_64BIT option configurable is
> that enabling it cause negative performance impact on various
> aspects like TLB miss and physical address manipulating. =A0We should
> not enable it unless really needed, e.g. use large memory of 4GB
> or bigger.

I think we should make 36-bit the only option for the upstream
defconfigs, and if we want a 32-bit "optimized" kernel for the SDK,
then we provide that on the SDK only.

--=20
Timur Tabi
Linux kernel developer at Freescale=

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Tabi Timur-B04825]

On Thu, Feb 16, 2012 at 9:56 AM, Tabi Timur-B04825 <b04825@freescale.com> w=
rote:
> I think we should make 36-bit the only option for the upstream
> defconfigs, and if we want a 32-bit "optimized" kernel for the SDK,
> then we provide that on the SDK only.

Oops, I meant to post this as a reply to "powerpc/85xx: add a 36-bit
corenet default config".

--=20
Timur Tabi
Linux kernel developer at Freescale=

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Kumar Gala]

On Feb 16, 2012, at 6:10 AM, Li Yang wrote:

> Fix the problem that large physical address support cannot be
> disabled when some platforms which only provides 36-bit support
> are selected.  According to the philosophy of kernel config
> enabling a platform support doesn't mean the kernel is only
> running on that platform.  Remove the auto selection of PHYS_64BIT
> option for these platforms.  They will need to use a 36bit default
> config that selects PHYS_64BIT explicitly.
>=20
> The reason why we need to keep PHYS_64BIT option configurable is
> that enabling it cause negative performance impact on various
> aspects like TLB miss and physical address manipulating.  We should
> not enable it unless really needed, e.g. use large memory of 4GB
> or bigger.
>=20
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig |    6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)

Nak, this isn't correct.

For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & =
P5020DS only a 36-bit physical address map is supported by u-boot and =
the device tree.  This was a decision that was made to NOT support =
32-bit address map for these boards and accept the performance =
implication of it to reduce the # of builds, etc.

Additionally, outside of maybe P2041RDB I believe the majority of these =
boards ship with 4G of DDR (but that off the top of my head) and thus =
require the 36-bit / PHYS_64BIT support to be enabled.

- k

RE: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Li Yang-R58472]

>Subject: Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents
>PHYS_64BIT from configurable
>
>
>On Feb 16, 2012, at 6:10 AM, Li Yang wrote:
>
>> Fix the problem that large physical address support cannot be disabled
>> when some platforms which only provides 36-bit support are selected.
>> According to the philosophy of kernel config enabling a platform
>> support doesn't mean the kernel is only running on that platform.
>> Remove the auto selection of PHYS_64BIT option for these platforms.
>> They will need to use a 36bit default config that selects PHYS_64BIT
>> explicitly.
>>
>> The reason why we need to keep PHYS_64BIT option configurable is that
>> enabling it cause negative performance impact on various aspects like
>> TLB miss and physical address manipulating.  We should not enable it
>> unless really needed, e.g. use large memory of 4GB or bigger.
>>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> arch/powerpc/platforms/85xx/Kconfig |    6 ------
>> 1 files changed, 0 insertions(+), 6 deletions(-)
>
>Nak, this isn't correct.
>
>For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, &
>P5020DS only a 36-bit physical address map is supported by u-boot and the
>device tree.  This was a decision that was made to NOT support 32-bit
>address map for these boards and accept the performance implication of it
>to reduce the # of builds, etc.

Ok.  Although personally I don't think # of builds matters that much.

>
>Additionally, outside of maybe P2041RDB I believe the majority of these
>boards ship with 4G of DDR (but that off the top of my head) and thus
>require the 36-bit / PHYS_64BIT support to be enabled.

I know that current support of DPAA boards requires 36-bit.  But I don't th=
ink they need to select the PHYS_64BIT option directly and make it not conf=
igurable.  It's conflicting with the logic that enabling a platform support=
 doesn't mean the kernel is only running on that platform.  Btw: what's you=
r recommendations on solving this?

- Leo

RE: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Benjamin Herrenschmidt]

On Fri, 2012-02-17 at 04:32 +0000, Li Yang-R58472 wrote:
> >Additionally, outside of maybe P2041RDB I believe the majority of
> these
> >boards ship with 4G of DDR (but that off the top of my head) and thus
> >require the 36-bit / PHYS_64BIT support to be enabled.
> 
> I know that current support of DPAA boards requires 36-bit.  But I
> don't think they need to select the PHYS_64BIT option directly and
> make it not configurable.  It's conflicting with the logic that
> enabling a platform support doesn't mean the kernel is only running on
> that platform.  Btw: what's your recommendations on solving this?

But selecting PHYS_64BIT shouldn't prevent running on the other
platforms. If it does, then this needs to be fixed.

Cheers,
Ben.

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Tabi Timur-B04825]

On Thu, Feb 16, 2012 at 7:27 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:

> For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & =
P5020DS only a 36-bit physical address map is supported by u-boot and the d=
evice tree. =A0This was a decision that was made to NOT support 32-bit addr=
ess map for these boards and accept the performance implication of it to re=
duce the # of builds, etc.

Was this a Freescale internal decision, or is this a generic 85xx decision?

For the record, I'm in favor in leaving out support for 32-bit address
map in the upstream kernel, and having it be an option on the SDK
only.  However, in order to do that, we cannot have "select
PHYS_64BIT" in the Kconfigs.  It needs to be in the defconfigs
instead.  Putting it in the defconfig will eliminate the need to have
it in every Kconfig block, so I think that's an improvement.

Then the SDK can include a defconfig that does not have PHYS_64BIT
defined.  And the SDK can include 32-bit U-Boots and 32-bit device
trees for any board where Freescale determines there is a need.

I think Leo's patch simplifies things for everyone.

--=20
Timur Tabi
Linux kernel developer at Freescale=

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Benjamin Herrenschmidt]

On Fri, 2012-02-17 at 16:22 +0000, Tabi Timur-B04825 wrote:
> Was this a Freescale internal decision, or is this a generic 85xx
> decision?
> 
> For the record, I'm in favor in leaving out support for 32-bit address
> map in the upstream kernel, and having it be an option on the SDK
> only.  However, in order to do that, we cannot have "select
> PHYS_64BIT" in the Kconfigs.  It needs to be in the defconfigs
> instead.  Putting it in the defconfig will eliminate the need to have
> it in every Kconfig block, so I think that's an improvement.
> 
> Then the SDK can include a defconfig that does not have PHYS_64BIT
> defined.  And the SDK can include 32-bit U-Boots and 32-bit device
> trees for any board where Freescale determines there is a need.
> 
> I think Leo's patch simplifies things for everyone. 

Sorry, I fail to see how... it basically makes all those boards
non-functional even when enabled...

What's wrong with the current scheme ?

Ben.

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Timur Tabi]

Benjamin Herrenschmidt wrote:
> Sorry, I fail to see how... it basically makes all those boards
> non-functional even when enabled...

So you're saying that if we allow 32-bit address spacing for a particular
board, then we must provide a 32-bit DTS to go with it?

I was hoping to use the defconfig to force 36-bit, so that we can have a
32-bit option if we want.  Just because we don't put a 32-bit DTS in the
upstream kernel, that doesn't mean that no one is allowed to have a 32-bit
kernel.

> What's wrong with the current scheme ?

It prevents the possibility of creating an "optimized" 32-bit address
environment, for people who have <= 2GB of DDR on the board.  If we want
to ship a 32-bit DTS and 32-bit U-Boot on our BSP, then we'll need to
patch the Kconfig to remove the "select" line.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Timur Tabi]

So I noticed something else.  PHYS_64BIT is not defined in
mpc85xx_smp_defconfig.  This means that if we want to build a 36-bit
kernel, we need to have "select PHYS_64BIT" in the Kconfig for that board.
 This is what we have today for the P1022DS.

However, that select statement also means that we can't build a 32-bit
kernel.  This is a problem for mpc85xx_defconfig, because that defconfig
includes support for the MPC8540ADS.  The 8540 has an e500v1 core which
doesn't support MAS7 (i.e. no 36-bit physical addresses).

So any patch that removes "select PHYS_64BIT" from an mpc85xx_defconfig
board must also turn on that option in the defconfig.  The patches from me
and Leo don't do that.


-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Scott Wood]

On 02/17/2012 05:01 PM, Timur Tabi wrote:
> So I noticed something else.  PHYS_64BIT is not defined in
> mpc85xx_smp_defconfig.

It couldn't have been, since it was selected by another kconfig option.
 defconfigs only hold non-default options.

> However, that select statement also means that we can't build a 32-bit
> kernel.  This is a problem for mpc85xx_defconfig, because that defconfig
> includes support for the MPC8540ADS.  The 8540 has an e500v1 core which
> doesn't support MAS7 (i.e. no 36-bit physical addresses).

It's not a problem for 8540, just lost optimization potential.

> So any patch that removes "select PHYS_64BIT" from an mpc85xx_defconfig
> board must also turn on that option in the defconfig.  The patches from me
> and Leo don't do that.

Yes, or maybe make it "default y", and/or require an "I know what I'm
doing" option to be set for it to be unset if a board otherwise wants it.

The ability to turn it off is potentially useful for any board, since
the address map is determined by boot software which can be changed, but
we shouldn't make it too easy to fail to select it for boards that
normally require it.

-Scott

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Benjamin Herrenschmidt]

On Fri, 2012-02-17 at 18:56 -0600, Scott Wood wrote:
> Yes, or maybe make it "default y", and/or require an "I know what I'm
> doing" option to be set for it to be unset if a board otherwise wants it.
> 
> The ability to turn it off is potentially useful for any board, since
> the address map is determined by boot software which can be changed, but
> we shouldn't make it too easy to fail to select it for boards that
> normally require it.

Don't we have CONFIG_EMBEDDED to make that sort of option visible ?

Cheers,
Ben.

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Scott Wood]

On 02/17/2012 08:19 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2012-02-17 at 18:56 -0600, Scott Wood wrote:
>> Yes, or maybe make it "default y", and/or require an "I know what I'm
>> doing" option to be set for it to be unset if a board otherwise wants it.
>>
>> The ability to turn it off is potentially useful for any board, since
>> the address map is determined by boot software which can be changed, but
>> we shouldn't make it too easy to fail to select it for boards that
>> normally require it.
> 
> Don't we have CONFIG_EMBEDDED to make that sort of option visible ?

OK, so:

config WANT_PHYS_64BIT
select PHYS_64BIT if !EMBEDDED

config PHYS_64BIT
default y if WANT_PHYS_64BIT

...and "select WANT_PHYS_64BIT" on boards that normally have 36-bit
address maps?

What about 86xx?  It looks like PHYS_64BIT can't be enabled if it's
sharing a kernel image with 82xx or 83xx (why these specific SoCs but
not 603 in general?).

-Scott

Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable

[Benjamin Herrenschmidt]

On Thu, 2012-02-16 at 20:10 +0800, Li Yang wrote:
> Fix the problem that large physical address support cannot be
> disabled when some platforms which only provides 36-bit support
> are selected.  According to the philosophy of kernel config
> enabling a platform support doesn't mean the kernel is only
> running on that platform.  Remove the auto selection of PHYS_64BIT
> option for these platforms.  They will need to use a 36bit default
> config that selects PHYS_64BIT explicitly.

No, but unless I'm wrong, with your patch, enabling those platforms will
build the code ... but they won't work unless you -also- enable
PHYS_64BIT one way or another. I thus disagree.

If I enable CONFIG_P1022_DS, I expect those boards to work.

If that's going to negatively impact perfs on other boards that I also
enabled, then so be it (and we should document it in the help text).

Cheers,
Ben.

> The reason why we need to keep PHYS_64BIT option configurable is
> that enabling it cause negative performance impact on various
> aspects like TLB miss and physical address manipulating.  We should
> not enable it unless really needed, e.g. use large memory of 4GB
> or bigger.
> 
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
>  arch/powerpc/platforms/85xx/Kconfig |    6 ------
>  1 files changed, 0 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index d7946be..d9bc0bd 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -80,7 +80,6 @@ config P1010_RDB
>  config P1022_DS
>  	bool "Freescale P1022 DS"
>  	select DEFAULT_UIMAGE
> -	select PHYS_64BIT	# The DTS has 36-bit addresses
>  	select SWIOTLB
>  	help
>  	  This option enables support for the Freescale P1022DS reference board.
> @@ -175,7 +174,6 @@ config P2041_RDB
>  	bool "Freescale P2041 RDB"
>  	select DEFAULT_UIMAGE
>  	select PPC_E500MC
> -	select PHYS_64BIT
>  	select SWIOTLB
>  	select ARCH_REQUIRE_GPIOLIB
>  	select GPIO_MPC8XXX
> @@ -188,7 +186,6 @@ config P3041_DS
>  	bool "Freescale P3041 DS"
>  	select DEFAULT_UIMAGE
>  	select PPC_E500MC
> -	select PHYS_64BIT
>  	select SWIOTLB
>  	select ARCH_REQUIRE_GPIOLIB
>  	select GPIO_MPC8XXX
> @@ -201,7 +198,6 @@ config P3060_QDS
>  	bool "Freescale P3060 QDS"
>  	select DEFAULT_UIMAGE
>  	select PPC_E500MC
> -	select PHYS_64BIT
>  	select SWIOTLB
>  	select GPIO_MPC8XXX
>  	select HAS_RAPIDIO
> @@ -213,7 +209,6 @@ config P4080_DS
>  	bool "Freescale P4080 DS"
>  	select DEFAULT_UIMAGE
>  	select PPC_E500MC
> -	select PHYS_64BIT
>  	select SWIOTLB
>  	select ARCH_REQUIRE_GPIOLIB
>  	select GPIO_MPC8XXX
> @@ -229,7 +224,6 @@ config P5020_DS
>  	select DEFAULT_UIMAGE
>  	select E500
>  	select PPC_E500MC
> -	select PHYS_64BIT
>  	select SWIOTLB
>  	select ARCH_REQUIRE_GPIOLIB
>  	select GPIO_MPC8XXX