From: Santosh Shilimkar <santosh.shilimkar@ti.com> To: Tejun Heo <tj@kernel.org> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>, linux-arch@vger.kernel.org, Russell King - ARM Linux <linux@arm.linux.org.uk>, Sam Ravnborg <sam@ravnborg.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, "H. Peter Anvin" <hpa@zytor.com>, "sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>, Paul Mackerras <paulus@samba.org>, Andrew Morton <akpm@linux-foundation.org>, Yinghai Lu <yinghai@kernel.org>, "David S. Miller" <davem@davemloft.net>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM Date: Mon, 5 Aug 2013 11:29:46 -0400 [thread overview] Message-ID: <51FFC4EA.40908@ti.com> (raw) In-Reply-To: <20130805150127.GC19631@mtj.dyndns.org> On Monday 05 August 2013 11:01 AM, Tejun Heo wrote: > Hello, > > On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote: >> Looking at the situation, how about proceeding with patch updating >> the bootmem API signatures to use phys_addr_t which can unblock me >> to get my machine working. > > I'm not sure about that. No matter how you play it, it'll end up > duplicating memblock interface. > fair enough. >> Introduction of new API, conversions of core kernel code and then > > What new API are we talking about? Wasn't the plan to convert core > kernel code to use memblock and let bootmem emulate bootmem API? > There's no new API. > So looks like I am bit confused here. The current memblock_alloc() API just returns the physical address which not mapped memory. Most of the bootmem users including core code expects the mapped memory pointer which the code can directly operate on. So the current memblock_alloc() isn't going to help. The nobootmem.c has __alloc_memory_core_early() which is actually used by most of the bootmem wrappers to achieve the same. So my assumption was that we need an equivalent exported memblock API. What am I missing? >> arches moving away from bootmem is going to take significant time > > And arches moving away from bootmem doesn't have to happen now. > I agree. The core code conversion is more of an issue. Regards, Santosh
WARNING: multiple messages have this Message-ID (diff)
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: Mon, 5 Aug 2013 11:29:46 -0400 [thread overview] Message-ID: <51FFC4EA.40908@ti.com> (raw) Message-ID: <20130805152946.NNKwqPi2F4RtlI3MQQ6xJh82tmuSSsdq46L9UoTQcy0@z> (raw) In-Reply-To: <20130805150127.GC19631@mtj.dyndns.org> On Monday 05 August 2013 11:01 AM, Tejun Heo wrote: > Hello, > > On Fri, Aug 02, 2013 at 05:06:02PM -0400, Santosh Shilimkar wrote: >> Looking at the situation, how about proceeding with patch updating >> the bootmem API signatures to use phys_addr_t which can unblock me >> to get my machine working. > > I'm not sure about that. No matter how you play it, it'll end up > duplicating memblock interface. > fair enough. >> Introduction of new API, conversions of core kernel code and then > > What new API are we talking about? Wasn't the plan to convert core > kernel code to use memblock and let bootmem emulate bootmem API? > There's no new API. > So looks like I am bit confused here. The current memblock_alloc() API just returns the physical address which not mapped memory. Most of the bootmem users including core code expects the mapped memory pointer which the code can directly operate on. So the current memblock_alloc() isn't going to help. The nobootmem.c has __alloc_memory_core_early() which is actually used by most of the bootmem wrappers to achieve the same. So my assumption was that we need an equivalent exported memblock API. What am I missing? >> arches moving away from bootmem is going to take significant time > > And arches moving away from bootmem doesn't have to happen now. > I agree. The core code conversion is more of an issue. Regards, Santosh
next prev parent reply other threads:[~2013-08-05 15:29 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <1372467663-31425-1-git-send-email-santosh.shilimkar@ti.com> [not found] ` <20130629152959.GB31339@mtj.dyndns.org> [not found] ` <20130629172123.GA3353@n2100.arm.linux.org.uk> 2013-06-29 17:57 ` [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM 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 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 20:08 ` Yinghai Lu 2013-06-29 20:08 ` Yinghai Lu 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: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-26 3:08 ` Tejun Heo 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:29 ` Santosh Shilimkar [this message] 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=51FFC4EA.40908@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: linkBe 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).