From: subashrp@gmail•com (Subash Patel)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v4 02/13] ARM: LPAE: use phys_addr_t in alloc_init_pud()
Date: Fri, 01 Feb 2013 12:32:07 -0800 [thread overview]
Message-ID: <510C2647.3080305@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1302011310090.6300@xanadu.home>
On Friday 01 February 2013 10:14 AM, Nicolas Pitre wrote:
> On Fri, 1 Feb 2013, Subash Patel wrote:
>
>> Hi Nicolas,
>>
>> On Thursday 31 January 2013 07:35 PM, Nicolas Pitre wrote:
>>> On Fri, 1 Feb 2013, Hui Wang wrote:
>>>
>>>> Cyril Chemparathy wrote:
>>>>> From: Vitaly Andrianov <vitalya@ti•com>
>>>>>
>>>>> This patch fixes the alloc_init_pud() function to use phys_addr_t
>>>>> instead of
>>>>> unsigned long when passing in the phys argument.
>>>>>
>>>>> This is an extension to commit 97092e0c56830457af0639f6bd904537a150ea4a
>>>>> (ARM:
>>>>> pgtable: use phys_addr_t for physical addresses), which applied similar
>>>>> changes
>>>>> elsewhere in the ARM memory management code.
>>>>>
>>>>> Signed-off-by: Vitaly Andrianov <vitalya@ti•com>
>>>>> Signed-off-by: Cyril Chemparathy <cyril@ti•com>
>>>>> Acked-by: Nicolas Pitre <nico@linaro•org>
>>>>> Acked-by: Catalin Marinas <catalin.marinas@arm•com>
>>>>> ---
>>>>> arch/arm/mm/mmu.c | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>>>>> index 9f06102..ef43689 100644
>>>>> --- a/arch/arm/mm/mmu.c
>>>>> +++ b/arch/arm/mm/mmu.c
>>>>> @@ -612,7 +612,8 @@ static void __init alloc_init_section(pud_t *pud,
>>>>> unsigned long addr,
>>>>> }
>>>>> static void __init alloc_init_pud(pgd_t *pgd, unsigned long addr,
>>>>> - unsigned long end, unsigned long phys, const struct mem_type *type)
>>>>> + unsigned long end, phys_addr_t phys,
>>>>> + const struct mem_type *type)
>>>>>
>>>> The change is correct but seems useless so far. This function only be
>>>> called
>>>> from map_lowmem and devicemaps_init, from i know neither lowmem nor device
>>>> io
>>>> registers of existing platforms exceed 32bit address.
>>>
>>> It is not because you are not aware of any existing platforms with RAM
>>> or device IO above the 4GB mark that they don't exist.
>>>
>>> For example, some LPAE systems have all their RAM located above the 4G
>>> physical address mark. A simple (potentially non DMA capable) alias
>>> exists in the low 32-bit address space to allow the system to boot and
>>> switch to the real physical RAM addresses once the MMU is turned on.
>>> Some of that RAM is still qualified as "low mem" i.e. the portion of RAM
>>> that the kernel keeps permanently mapped in the 32-bit virtual space
>>> even if all of it is above the 4G mark in physical space.
>>
>> I think he is right. You cannot have low_mem and devices in 36-bit areas.
>> Atleast this is what I saw in one of the platforms on which I tested these
>> patches. I am not sure what you mean by hardware address aliasing(as I have
>> real RAM), but we need 32-bit areas to boot the CPU and I have mapped them for
>> the LOW_MEM. But, I have used 36-bit areas for the HIGH_MEM. Since you said
>> about aliasing DDR area in 32-bits, and then switching to 36-bit RAM, does the
>> dma of the devices still use 32-bit aliased addresses?
>>
>> I haven't tested a configuration where LOW_MEM can have both 32-bit and 36-bit
>> DDR PA though. I think its not possible too.
>
> Don't get confused by the 36-bit supersections introduced with ARMv6.
> This patch series is about LPAE capable systems using a completely
> different page table format providing physical addressing beyond 36
> bits.
Yes, I mean LPAE capable MMU's introduced with Cortex-A15. Infact I have
programmed that MMU with 1G super-section for non-linux usage :) Cyril
explained his platform and aliasing. My platform has a real memory in
32-bit area, and we use it for 32-bit DMA's as well. So it looks we are
speaking of various configurations of LPAE systems here.
Regards,
Subash
>
>
> Nicolas
>
next prev parent reply other threads:[~2013-02-01 20:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-31 21:58 [PATCH v4 00/13] ARM LPAE Fixes - Part 1 Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 01/13] ARM: LPAE: use signed arithmetic for mask definitions Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 02/13] ARM: LPAE: use phys_addr_t in alloc_init_pud() Cyril Chemparathy
2013-02-01 3:11 ` Hui Wang
2013-02-01 3:35 ` Nicolas Pitre
2013-02-01 5:40 ` Hui Wang
2013-02-01 17:33 ` Subash Patel
2013-02-01 17:56 ` Cyril Chemparathy
2013-02-01 18:14 ` Nicolas Pitre
2013-02-01 20:32 ` Subash Patel [this message]
2013-01-31 21:58 ` [PATCH v4 03/13] ARM: LPAE: use phys_addr_t in free_memmap() Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 04/13] ARM: LPAE: use phys_addr_t for initrd location Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 05/13] ARM: LPAE: use phys_addr_t in switch_mm() Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 06/13] ARM: LPAE: use 64-bit accessors for TTBR registers Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 07/13] ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem Cyril Chemparathy
2013-02-01 3:42 ` Nicolas Pitre
2013-01-31 21:58 ` [PATCH v4 08/13] ARM: LPAE: factor out T1SZ and TTBR1 computations Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 09/13] ARM: LPAE: accomodate >32-bit addresses for page table base Cyril Chemparathy
2013-02-01 3:48 ` Nicolas Pitre
2013-01-31 21:58 ` [PATCH v4 10/13] ARM: mm: use physical addresses in highmem sanity checks Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 11/13] ARM: mm: cleanup checks for membank overlap with vmalloc area Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 12/13] ARM: mm: clean up membank size limit checks Cyril Chemparathy
2013-01-31 21:58 ` [PATCH v4 13/13] ARM: fix type of PHYS_PFN_OFFSET to unsigned long Cyril Chemparathy
2013-02-01 3:51 ` Nicolas Pitre
2013-02-01 4:00 ` [PATCH v4 00/13] ARM LPAE Fixes - Part 1 Nicolas Pitre
2013-02-01 15:10 ` Cyril Chemparathy
2013-02-01 15:14 ` Russell King - ARM Linux
2013-02-01 16:13 ` Cyril Chemparathy
2013-02-01 17:56 ` Nicolas Pitre
2013-02-01 20:21 ` Subash Patel
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=510C2647.3080305@gmail.com \
--to=subashrp@gmail$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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