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

Li Yang-R58472 r58472 at freescale.com
Fri Feb 17 15:32:53 EST 2012


>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 at 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 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?

- Leo



More information about the Linuxppc-dev mailing list