From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features
Date: Thu, 2 Jun 2016 07:34:49 -0500 [thread overview]
Message-ID: <575027E9.3070202@ti.com> (raw)
In-Reply-To: <cdbd2482-de98-569b-7ff0-c8963037de53@oracle.com>
On 06/01/2016 06:26 PM, Santosh Shilimkar wrote:
[...]
>>> Side note on LPAE:
>>> For our current device tree and u-boot, LPAE is mandatory to bootup
>>> for current Keystone boards - but this is not a SoC requirement,
>>> booting without LPAE/HIGHMEM results in non-coherent DDR accesses.
>>
>> This sounds like a regression, I thought we had this working when
>> keystone was initially merged and we got both the coherent and
>> non-coherent mode working with the same DT.
>>
> Yes and it works. The coherent memory space itself is beyond 4GB so
Hmm... True, I just tested next-20160602 with mem_lpae set to 0 in
u-boot and it seems to boot just fine.
> I don't understand a requirement of having coherent memory without
> LPAE.
Looks like a messed up description on my end, Looks like I have to
update my automated test framework to incorporate the manual steps
involved.
--
Regards,
Nishanth Menon
WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Menon <nm@ti.com>
To: Santosh Shilimkar <santosh.shilimkar@oracle.com>,
Arnd Bergmann <arnd@arndb.de>,
<linux-arm-kernel@lists.infradead.org>
Cc: Russell King <linux@armlinux.org.uk>,
Santosh Shilimkar <ssantosh@kernel.org>,
Grygorii Strashko <grygorii.strashko@ti.com>,
Lokesh Vutla <lokeshvutla@ti.com>, <linux-kernel@vger.kernel.org>,
Tero Kristo <t-kristo@ti.com>,
Murali Karicheri <m-karicheri2@ti.com>,
Bill Mills <wmills@ti.com>
Subject: Re: [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features
Date: Thu, 2 Jun 2016 07:34:49 -0500 [thread overview]
Message-ID: <575027E9.3070202@ti.com> (raw)
In-Reply-To: <cdbd2482-de98-569b-7ff0-c8963037de53@oracle.com>
On 06/01/2016 06:26 PM, Santosh Shilimkar wrote:
[...]
>>> Side note on LPAE:
>>> For our current device tree and u-boot, LPAE is mandatory to bootup
>>> for current Keystone boards - but this is not a SoC requirement,
>>> booting without LPAE/HIGHMEM results in non-coherent DDR accesses.
>>
>> This sounds like a regression, I thought we had this working when
>> keystone was initially merged and we got both the coherent and
>> non-coherent mode working with the same DT.
>>
> Yes and it works. The coherent memory space itself is beyond 4GB so
Hmm... True, I just tested next-20160602 with mem_lpae set to 0 in
u-boot and it seems to boot just fine.
> I don't understand a requirement of having coherent memory without
> LPAE.
Looks like a messed up description on my end, Looks like I have to
update my automated test framework to incorporate the manual steps
involved.
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2016-06-02 12:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 21:31 [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features Nishanth Menon
2016-06-01 21:31 ` Nishanth Menon
2016-06-01 22:31 ` Arnd Bergmann
2016-06-01 22:31 ` Arnd Bergmann
2016-06-01 22:49 ` Nishanth Menon
2016-06-01 22:49 ` Nishanth Menon
2016-06-01 23:27 ` Santosh Shilimkar
2016-06-01 23:27 ` Santosh Shilimkar
2016-06-07 4:28 ` Tony Lindgren
2016-06-07 4:28 ` Tony Lindgren
2016-06-07 8:09 ` Arnd Bergmann
2016-06-07 8:09 ` Arnd Bergmann
2016-06-07 8:09 ` Arnd Bergmann
2016-06-07 12:04 ` Mark Brown
2016-06-07 12:04 ` Mark Brown
2016-06-08 9:47 ` Tony Lindgren
2016-06-08 9:47 ` Tony Lindgren
2016-06-08 16:04 ` Arnd Bergmann
2016-06-08 16:04 ` Arnd Bergmann
2016-06-09 6:50 ` Tony Lindgren
2016-06-09 6:50 ` Tony Lindgren
2016-06-09 10:32 ` Mark Brown
2016-06-09 10:32 ` Mark Brown
2016-06-01 23:26 ` Santosh Shilimkar
2016-06-01 23:26 ` Santosh Shilimkar
2016-06-02 12:34 ` Nishanth Menon [this message]
2016-06-02 12:34 ` Nishanth Menon
2016-06-02 18:10 ` Santosh Shilimkar
2016-06-02 18:10 ` 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=575027E9.3070202@ti.com \
--to=nm@ti.com \
--cc=linux-arm-kernel@lists.infradead.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.