All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Yinghai Lu <yinghai@kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Tejun Heo <tj@kernel.org>
Cc: <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: Mon, 1 Jul 2013 10:10:02 -0400	[thread overview]
Message-ID: <51D18DBA.6090608@ti.com> (raw)
In-Reply-To: <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>

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.

Regards,
Santosh 

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Yinghai Lu <yinghai@kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Tejun Heo <tj@kernel.org>
Cc: 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: Mon, 1 Jul 2013 10:10:02 -0400	[thread overview]
Message-ID: <51D18DBA.6090608@ti.com> (raw)
In-Reply-To: <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>

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.

Regards,
Santosh 

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Yinghai Lu <yinghai@kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Tejun Heo <tj@kernel.org>
Cc: 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: Mon, 01 Jul 2013 14:10:02 +0000	[thread overview]
Message-ID: <51D18DBA.6090608@ti.com> (raw)
In-Reply-To: <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>

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.

Regards,
Santosh 

WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
Date: Mon, 1 Jul 2013 10:10:02 -0400	[thread overview]
Message-ID: <51D18DBA.6090608@ti.com> (raw)
In-Reply-To: <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>

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.

Regards,
Santosh 

  reply	other threads:[~2013-07-01 14:10 UTC|newest]

Thread overview: 63+ 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  1:01 ` Santosh Shilimkar
2013-06-29 15:29 ` Tejun Heo
2013-06-29 15:29   ` Tejun Heo
2013-06-29 17:21   ` Russell King - ARM Linux
2013-06-29 17:21     ` Russell King - ARM Linux
2013-06-29 17:57     ` Tejun Heo
2013-06-29 17:57       ` Tejun Heo
2013-06-29 17:57       ` Tejun Heo
2013-06-29 18:23       ` H. Peter Anvin
2013-06-29 18:23         ` H. Peter Anvin
2013-06-29 18:23         ` H. Peter Anvin
2013-06-29 18:23         ` H. Peter Anvin
2013-06-29 19:29       ` Yinghai Lu
2013-06-29 19:29         ` Yinghai Lu
2013-06-29 19:29         ` Yinghai Lu
2013-06-29 19:55         ` Russell King - ARM Linux
2013-06-29 19:55           ` Russell King - ARM Linux
2013-06-29 19:55           ` Russell King - ARM Linux
2013-06-29 19:55           ` Russell King - ARM Linux
2013-06-29 20:08           ` Yinghai Lu
2013-06-29 20:08             ` Yinghai Lu
2013-06-29 20:08             ` Yinghai Lu
2013-07-01 14:10             ` Santosh Shilimkar [this message]
2013-07-01 14:10               ` Santosh Shilimkar
2013-07-01 14:10               ` Santosh Shilimkar
2013-07-01 14:10               ` Santosh Shilimkar
2013-07-25 22:33               ` Santosh Shilimkar
2013-07-25 22:33                 ` Santosh Shilimkar
2013-07-25 22:33                 ` Santosh Shilimkar
2013-07-25 22:33                 ` Santosh Shilimkar
2013-07-25 22:33                 ` Santosh Shilimkar
2013-07-25 22:36                 ` Tejun Heo
2013-07-25 22:36                   ` Tejun Heo
2013-07-25 22:36                   ` Tejun Heo
2013-07-25 23:15                   ` Santosh Shilimkar
2013-07-25 23:15                     ` Santosh Shilimkar
2013-07-25 23:15                     ` Santosh Shilimkar
2013-07-25 23:15                     ` Santosh Shilimkar
2013-07-25 23:15                     ` Santosh Shilimkar
2013-07-26  3:08                     ` Tejun Heo
2013-07-26  3:08                       ` Tejun Heo
2013-07-26  3:08                       ` Tejun Heo
2013-08-02 21:06                       ` Santosh Shilimkar
2013-08-02 21:06                         ` Santosh Shilimkar
2013-08-02 21:06                         ` Santosh Shilimkar
2013-08-02 21:06                         ` Santosh Shilimkar
2013-08-02 21:06                         ` Santosh Shilimkar
2013-08-05 15:01                         ` Tejun Heo
2013-08-05 15:01                           ` Tejun Heo
2013-08-05 15:01                           ` Tejun Heo
2013-08-05 15:29                           ` Santosh Shilimkar
2013-08-05 15:29                             ` Santosh Shilimkar
2013-08-05 15:29                             ` Santosh Shilimkar
2013-08-05 15:29                             ` Santosh Shilimkar
2013-08-05 15:29                             ` Santosh Shilimkar
2013-08-05 15:38                             ` Tejun Heo
2013-08-05 15:38                               ` Tejun Heo
2013-08-05 15:38                               ` Tejun Heo
2013-08-05 15:47                               ` Santosh Shilimkar
2013-08-05 15:47                                 ` Santosh Shilimkar
2013-08-05 15:47                                 ` Santosh Shilimkar
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=51D18DBA.6090608@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.