From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Tejun Heo <tj@kernel.org>
Cc: Yinghai Lu <yinghai@kernel.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
<linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Ingo Molnar <mingo@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"David S. Miller" <davem@davemloft.net>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>, <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
Date: Thu, 25 Jul 2013 18:33:14 -0400 [thread overview]
Message-ID: <51F1A7AA.8080700@ti.com> (raw)
In-Reply-To: <51D18DBA.6090608@ti.com>
Tejun,
On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM. As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE. Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
>
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig: select NO_BOOTMEM
>> arch/arm64/Kconfig: select NO_BOOTMEM
>> arch/sparc/Kconfig: select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log.
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
>
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
>
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
>
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.
Regards,
Santosh
next prev parent reply other threads:[~2013-07-25 22:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-29 1:01 [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM Santosh Shilimkar
2013-06-29 15:29 ` Tejun Heo
2013-06-29 17:21 ` Russell King - ARM Linux
2013-06-29 17:57 ` Tejun Heo
2013-06-29 18:23 ` H. Peter Anvin
2013-06-29 19:29 ` Yinghai Lu
2013-06-29 19:55 ` Russell King - ARM Linux
2013-06-29 20:08 ` Yinghai Lu
2013-07-01 14:10 ` Santosh Shilimkar
2013-07-25 22:33 ` Santosh Shilimkar [this message]
2013-07-25 22:36 ` Tejun Heo
2013-07-25 23:15 ` Santosh Shilimkar
2013-07-26 3:08 ` Tejun Heo
2013-08-02 21:06 ` Santosh Shilimkar
2013-08-05 15:01 ` Tejun Heo
2013-08-05 15:29 ` Santosh Shilimkar
2013-08-05 15:38 ` Tejun Heo
2013-08-05 15:47 ` Santosh Shilimkar
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=51F1A7AA.8080700@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@redhat.com \
--cc=nicolas.pitre@linaro.org \
--cc=paulus@samba.org \
--cc=sam@ravnborg.org \
--cc=sparclinux@vger.kernel.org \
--cc=tj@kernel.org \
--cc=will.deacon@arm.com \
--cc=yinghai@kernel.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).