All of lore.kernel.org
 help / color / mirror / Atom feed
From: Subash Patel <subashrp@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
	'Olof Johansson' <olof@lixom.net>,
	linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: About LPAE supporting on EXYNOS5440
Date: Wed, 12 Jun 2013 10:16:38 +0530	[thread overview]
Message-ID: <51B7FD2E.9030306@gmail.com> (raw)
In-Reply-To: <15605927.1Yi6Xe5hWs@wuerfel>



On 06/11/2013 06:13 PM, Arnd Bergmann wrote:
> On Tuesday 11 June 2013 19:05:22 Kukjin Kim wrote:
>> Arnd Bergmann wrote:
>>>
>>> On Tuesday 11 June 2013 17:33:33 Kukjin Kim wrote:
>>>> Hi all,
>>>>
>>>> The exynos5440 can support LPAE and referece boards, SSDK5440 and SD5v1
>>> have
>>>> over 8GiB memory.
>>>>
>>>> Current exynos_defconfig selects every EXYNOS SoCs including exynos5440
>>> it
>>>> means supporting LPAE will be selected for other EXYNOS SoCs.
>>>>
>>>> I'm wondering if seleting LPAE causes some problem for multiplatform.
>>> Can we
>>>> support LPAE enabled and disabled platform together with single zImage?
>>>
>>> No, that isn't possible.
>>
>> Yeah, I know that.
>>
>>> I think we should enable all exynos support in
>>> the
>>> regular multi_v7_defconfig and leave LPAE turned off for that,
>>
>> But if so, problem will happen in the memory parsing without LPAE
>> enabling...so I'm wondering I should deselect exynos5440 in the defconfig
>> for other exynos SoCs...
>
> I think there is a bug in the memory parsing code and already two people
> have submitted independent fixes for that. It really should just work
> even if you have more memory that ends up getting ignored.
>
>>> but create
>>> another multi_lpae_defconfig that has all LPAE capable machines turned on.
>>> This is also what I expect the distros to do.
>>>
>> Yeah, it could be a solution for multiplatform at this moment. And if so,
>> probably I should deselect exynos5440 in the exynos_defconfig and need to
>> add another defconfig for exynos lpae stuff.
>
> I would definitely leave on exynos5440 support in defconfig. It's not a
> lot of extra code, and if you have a system with less than 4GB memory,
> you really don't want to enable LPAE because of the overhead.

Even if we have <= 4GB memory, and the system designers have placed the 
memory banks in addresses > 2^32 bytes, then we need LPAE support. I 
think we may have such systems in future. So memory capacity is not the 
only parameter to judge if we need to enable LPAE or not.

Regards,
Subash

>
>> BTW, do you know what SoCs can support LPAE now?
>
> Upstream I think we support exynos, vexpress (using A15, A7 and A12
> core tiles), omap5 (partially), mvebu (Armada XP), highbank (Midway)
> and some of the shmobile parts we added in 3.10.
>
> In mach-sunxi, there will soon be support for Allwinner-A20 and -A31,
> which are both Cortex-A7 based. MSM also has support for Cortex-A7
> but not upstream. A couple of new platforms are under discussion
> already that will also have LPAE, mostly server parts.
>
> 	Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

WARNING: multiple messages have this Message-ID (diff)
From: subashrp@gmail.com (Subash Patel)
To: linux-arm-kernel@lists.infradead.org
Subject: About LPAE supporting on EXYNOS5440
Date: Wed, 12 Jun 2013 10:16:38 +0530	[thread overview]
Message-ID: <51B7FD2E.9030306@gmail.com> (raw)
In-Reply-To: <15605927.1Yi6Xe5hWs@wuerfel>



On 06/11/2013 06:13 PM, Arnd Bergmann wrote:
> On Tuesday 11 June 2013 19:05:22 Kukjin Kim wrote:
>> Arnd Bergmann wrote:
>>>
>>> On Tuesday 11 June 2013 17:33:33 Kukjin Kim wrote:
>>>> Hi all,
>>>>
>>>> The exynos5440 can support LPAE and referece boards, SSDK5440 and SD5v1
>>> have
>>>> over 8GiB memory.
>>>>
>>>> Current exynos_defconfig selects every EXYNOS SoCs including exynos5440
>>> it
>>>> means supporting LPAE will be selected for other EXYNOS SoCs.
>>>>
>>>> I'm wondering if seleting LPAE causes some problem for multiplatform.
>>> Can we
>>>> support LPAE enabled and disabled platform together with single zImage?
>>>
>>> No, that isn't possible.
>>
>> Yeah, I know that.
>>
>>> I think we should enable all exynos support in
>>> the
>>> regular multi_v7_defconfig and leave LPAE turned off for that,
>>
>> But if so, problem will happen in the memory parsing without LPAE
>> enabling...so I'm wondering I should deselect exynos5440 in the defconfig
>> for other exynos SoCs...
>
> I think there is a bug in the memory parsing code and already two people
> have submitted independent fixes for that. It really should just work
> even if you have more memory that ends up getting ignored.
>
>>> but create
>>> another multi_lpae_defconfig that has all LPAE capable machines turned on.
>>> This is also what I expect the distros to do.
>>>
>> Yeah, it could be a solution for multiplatform at this moment. And if so,
>> probably I should deselect exynos5440 in the exynos_defconfig and need to
>> add another defconfig for exynos lpae stuff.
>
> I would definitely leave on exynos5440 support in defconfig. It's not a
> lot of extra code, and if you have a system with less than 4GB memory,
> you really don't want to enable LPAE because of the overhead.

Even if we have <= 4GB memory, and the system designers have placed the 
memory banks in addresses > 2^32 bytes, then we need LPAE support. I 
think we may have such systems in future. So memory capacity is not the 
only parameter to judge if we need to enable LPAE or not.

Regards,
Subash

>
>> BTW, do you know what SoCs can support LPAE now?
>
> Upstream I think we support exynos, vexpress (using A15, A7 and A12
> core tiles), omap5 (partially), mvebu (Armada XP), highbank (Midway)
> and some of the shmobile parts we added in 3.10.
>
> In mach-sunxi, there will soon be support for Allwinner-A20 and -A31,
> which are both Cortex-A7 based. MSM also has support for Cortex-A7
> but not upstream. A couple of new platforms are under discussion
> already that will also have LPAE, mostly server parts.
>
> 	Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

  reply	other threads:[~2013-06-12  4:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11  8:33 About LPAE supporting on EXYNOS5440 Kukjin Kim
2013-06-11  8:33 ` Kukjin Kim
2013-06-11  9:53 ` Arnd Bergmann
2013-06-11  9:53   ` Arnd Bergmann
2013-06-11 10:05   ` Kukjin Kim
2013-06-11 10:05     ` Kukjin Kim
2013-06-11 12:43     ` Arnd Bergmann
2013-06-11 12:43       ` Arnd Bergmann
2013-06-12  4:46       ` Subash Patel [this message]
2013-06-12  4:46         ` Subash Patel
2013-06-12  9:58         ` Arnd Bergmann
2013-06-12  9:58           ` Arnd Bergmann
2013-06-13 12:53           ` Kukjin Kim
2013-06-13 12:53             ` Kukjin Kim
2013-06-12  0:11   ` Olof Johansson
2013-06-12  0:11     ` Olof Johansson

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=51B7FD2E.9030306@gmail.com \
    --to=subashrp@gmail.com \
    --cc=arnd@arndb.de \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    /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.