| Message ID | 1470922605-27803-1-git-send-email-yamada.masahiro@socionext.com |
|---|---|
| State | Rejected |
| Delegated to: | Tom Rini |
| Headers | show |
On 11.08.16 15:36, Masahiro Yamada wrote: > As you see in arch/arm/include/asm/types.h, CONFIG_PHYS_64BIT > determines the size of phys_addr_t. The ARM Large Physical Address > Extension allows CPUs to access a physical address space larger than > 4GB, so the physical address may not fit in 32bit long phys_addr_t. > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > --- > > I did Buildman test, but not run-time test. > > Looks like bcm283x (RPI) is the only arch that selects ARMV7_LPAE, > so I hope Stephen will check this patch. Well, the bcm2837 still only has a 32bit bus, so we can't actually make use of addresses bigger than 32bits. I think it would make most sense to select PHYS_64BIT on whatever 32bit SoC actually needs to accesses memory above 4GB. The main reason for having LPAE support for armv7 is not to support higher addresses (we still map everything 1:1 usually), it's to allow running in HYP mode which requires LPAE style page tables. Alex
On 08/11/2016 07:36 AM, Masahiro Yamada wrote: > As you see in arch/arm/include/asm/types.h, CONFIG_PHYS_64BIT > determines the size of phys_addr_t. The ARM Large Physical Address > Extension allows CPUs to access a physical address space larger than > 4GB, so the physical address may not fit in 32bit long phys_addr_t. > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > --- > > I did Buildman test, but not run-time test. > > Looks like bcm283x (RPI) is the only arch that selects ARMV7_LPAE, > so I hope Stephen will check this patch. Tested-by: Stephen Warren <swarren@wwwdotorg.org>
Hi Alex, 2016-08-11 22:50 GMT+09:00 Alexander Graf <agraf@suse.de>: > > > On 11.08.16 15:36, Masahiro Yamada wrote: >> As you see in arch/arm/include/asm/types.h, CONFIG_PHYS_64BIT >> determines the size of phys_addr_t. The ARM Large Physical Address >> Extension allows CPUs to access a physical address space larger than >> 4GB, so the physical address may not fit in 32bit long phys_addr_t. >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> --- >> >> I did Buildman test, but not run-time test. >> >> Looks like bcm283x (RPI) is the only arch that selects ARMV7_LPAE, >> so I hope Stephen will check this patch. > > Well, the bcm2837 still only has a 32bit bus, so we can't actually make > use of addresses bigger than 32bits. > > I think it would make most sense to select PHYS_64BIT on whatever 32bit > SoC actually needs to accesses memory above 4GB. > > The main reason for having LPAE support for armv7 is not to support > higher addresses (we still map everything 1:1 usually), it's to allow > running in HYP mode which requires LPAE style page tables. Thanks for explaining this. Then, please forget about this patch.
diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig index 0560178..1697e61 100644 --- a/arch/arm/cpu/armv7/Kconfig +++ b/arch/arm/cpu/armv7/Kconfig @@ -45,6 +45,7 @@ config ARMV7_PSCI_NR_CPUS config ARMV7_LPAE boolean "Use LPAE page table format" if EXPERT depends on CPU_V7 + select PHYS_64BIT default n ---help--- Say Y here to use the long descriptor page table format. This is
As you see in arch/arm/include/asm/types.h, CONFIG_PHYS_64BIT determines the size of phys_addr_t. The ARM Large Physical Address Extension allows CPUs to access a physical address space larger than 4GB, so the physical address may not fit in 32bit long phys_addr_t. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- I did Buildman test, but not run-time test. Looks like bcm283x (RPI) is the only arch that selects ARMV7_LPAE, so I hope Stephen will check this patch. arch/arm/cpu/armv7/Kconfig | 1 + 1 file changed, 1 insertion(+)