On Wed, Jun 08, 2016 at 11:50:35PM -0700, Tony Lindgren wrote:
> * Arnd Bergmann [160608 09:06]:
> > The downside would be any users that want the options we enable there
> > turned off and have them silently enabled when upgrading the kernel.
> I think the long term solution
On Wed, Jun 08, 2016 at 11:50:35PM -0700, Tony Lindgren wrote:
> * Arnd Bergmann [160608 09:06]:
> > The downside would be any users that want the options we enable there
> > turned off and have them silently enabled when upgrading the kernel.
> I think the long term solution here might be to
* Arnd Bergmann [160608 09:06]:
> On Wednesday, June 8, 2016 2:47:48 AM CEST Tony Lindgren wrote:
> >
> > So we could have ARCH_MULTIPLATFORM_TYPICAL, then have the old
> > ARCH_OMAP2PLUS_TYPICAL select that one. That should keep things
> > behaving just fine if the old .config
* Arnd Bergmann [160608 09:06]:
> On Wednesday, June 8, 2016 2:47:48 AM CEST Tony Lindgren wrote:
> >
> > So we could have ARCH_MULTIPLATFORM_TYPICAL, then have the old
> > ARCH_OMAP2PLUS_TYPICAL select that one. That should keep things
> > behaving just fine if the old .config had
On Wednesday, June 8, 2016 2:47:48 AM CEST Tony Lindgren wrote:
>
> * Arnd Bergmann [160607 01:11]:
> > A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON,
> > PM, REGULATOR and VFP are things that we probably want to default to enabled
> > whenever we
On Wednesday, June 8, 2016 2:47:48 AM CEST Tony Lindgren wrote:
>
> * Arnd Bergmann [160607 01:11]:
> > A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON,
> > PM, REGULATOR and VFP are things that we probably want to default to enabled
> > whenever we build a MULTI_V7
Hi,
* Arnd Bergmann [160607 01:11]:
> A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON,
> PM, REGULATOR and VFP are things that we probably want to default to enabled
> whenever we build a MULTI_V7 kernel, some also for V5 or V6, we just
> need to come
Hi,
* Arnd Bergmann [160607 01:11]:
> A lot of these options are typical for all ARMv7 machines: AEABI, I2C, NEON,
> PM, REGULATOR and VFP are things that we probably want to default to enabled
> whenever we build a MULTI_V7 kernel, some also for V5 or V6, we just
> need to come up with a good
On Tue, Jun 07, 2016 at 10:09:46AM +0200, Arnd Bergmann wrote:
Please start new threads for things like this - there's no obvious
relevance to me in either the subject or even the first couple of pages
of the message so it very nearly got deleted unread. It's very common
to get copied on
On Tue, Jun 07, 2016 at 10:09:46AM +0200, Arnd Bergmann wrote:
Please start new threads for things like this - there's no obvious
relevance to me in either the subject or even the first couple of pages
of the message so it very nearly got deleted unread. It's very common
to get copied on
On Monday, June 6, 2016 9:28:54 PM CEST Tony Lindgren wrote:
> * Nishanth Menon [160601 15:51]:
> > On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> > > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> > >>
> > >> Hence the "KEYSTONE_TYPICAL" option is designed
On Monday, June 6, 2016 9:28:54 PM CEST Tony Lindgren wrote:
> * Nishanth Menon [160601 15:51]:
> > On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> > > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> > >>
> > >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit
* Nishanth Menon [160601 15:51]:
> On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> >>
> >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit
> >> 8d9166b519fd
> >> ("omap2/3/4: Add Kconfig option to
* Nishanth Menon [160601 15:51]:
> On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> > On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> >>
> >> Hence the "KEYSTONE_TYPICAL" option is designed similar to commit
> >> 8d9166b519fd
> >> ("omap2/3/4: Add Kconfig option to compile in
On 6/2/2016 5:34 AM, Nishanth Menon wrote:
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
On 6/2/2016 5:34 AM, Nishanth Menon wrote:
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
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.
>>
>>
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.
>>
>>
On 6/1/2016 3:49 PM, Nishanth Menon wrote:
On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
[...]
Santosh, Bill, Lokesh, Grygorii: could you help feedback on the above
comments from Arnd?
Already responded to Arnds email.
On 6/1/2016 3:31 PM, Arnd Bergmann wrote:
On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone
platforms. This is particularly useful when custom optimized defconfig
builds are created for Keystone architecture
On 6/1/2016 3:49 PM, Nishanth Menon wrote:
On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
[...]
Santosh, Bill, Lokesh, Grygorii: could you help feedback on the above
comments from Arnd?
Already responded to Arnds email.
On 6/1/2016 3:31 PM, Arnd Bergmann wrote:
On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone
platforms. This is particularly useful when custom optimized defconfig
builds are created for Keystone architecture
On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
>> Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone
>> platforms. This is particularly useful when custom optimized defconfig
>> builds are created for Keystone
On 06/01/2016 05:31 PM, Arnd Bergmann wrote:
> On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
>> Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone
>> platforms. This is particularly useful when custom optimized defconfig
>> builds are created for Keystone
On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone
> platforms. This is particularly useful when custom optimized defconfig
> builds are created for Keystone architecture platforms.
>
> An example of the same would
On Wednesday, June 1, 2016 4:31:54 PM CEST Nishanth Menon wrote:
> Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone
> platforms. This is particularly useful when custom optimized defconfig
> builds are created for Keystone architecture platforms.
>
> An example of the same would
Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone
platforms. This is particularly useful when custom optimized defconfig
builds are created for Keystone architecture platforms.
An example of the same would be a sample fragment ks_only.cfg:
http://pastebin.ubuntu.com/16904991/ -
Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone
platforms. This is particularly useful when custom optimized defconfig
builds are created for Keystone architecture platforms.
An example of the same would be a sample fragment ks_only.cfg:
http://pastebin.ubuntu.com/16904991/ -
28 matches
Mail list logo