@@ -1725,8 +1725,9 @@ config HW_PERF_EVENTSsource"mm/Kconfig"configFORCE_MAX_ZONEORDER-int"Maximum zone order"ifARCH_SHMOBILE-range1164ifARCH_SHMOBILE+int"Maximum zone order"+depends onARCH_SHMOBILE||SOC_AM33XX+range1164ifARCH_SHMOBILE||SOC_AM33XXdefault"9"ifSA1111default"11"help
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -1725,8 +1725,9 @@ config HW_PERF_EVENTSsource"mm/Kconfig"configFORCE_MAX_ZONEORDER-int"Maximum zone order"ifARCH_SHMOBILE-range1164ifARCH_SHMOBILE+int"Maximum zone order"+depends onARCH_SHMOBILE||SOC_AM33XX+range1164ifARCH_SHMOBILE||SOC_AM33XXdefault"9"ifSA1111default"11"help--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -1725,8 +1725,9 @@ config HW_PERF_EVENTSsource"mm/Kconfig"configFORCE_MAX_ZONEORDER-int"Maximum zone order"ifARCH_SHMOBILE-range1164ifARCH_SHMOBILE+int"Maximum zone order"+depends onARCH_SHMOBILE||SOC_AM33XX+range1164ifARCH_SHMOBILE||SOC_AM33XXdefault"9"ifSA1111default"11"
NAK. This patch breaks SA1111 platforms. To see why, read the patch.
OK let's drop this.
How should I change the patch to make it proper? SA1111 is broken anyway:
config FORCE_MAX_ZONEORDER
int "Maximum zone order" if ARCH_SHMOBILE
range 11 64 if ARCH_SHMOBILE
default "9" if SA1111
default "11"
AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE, so SA1111 won't be evaluated (at least if I select SA1111 include/generated/autoconf.h shows "11"). If I add SA1111 to dependency list like this:
depends on ARCH_SHMOBILE || SOC_AM33XX || SA1111
the prompt in "Kernel features" becomes visible, but it doesn't have the default value of "9", but "11".
Am I missing something?
Yegor
From: Russell King - ARM Linux <hidden> Date: 2012-09-25 08:14:49
On Tue, Sep 25, 2012 at 10:05:30AM +0200, Yegor Yefremov wrote:
How should I change the patch to make it proper? SA1111 is broken anyway:
No it isn't. This is what it produces _today_, and has done for the last
5-10 years without modification
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=9
CONFIG_LEDS=y
CONFIG_LEDS_CPU=y
config FORCE_MAX_ZONEORDER
int "Maximum zone order" if ARCH_SHMOBILE
range 11 64 if ARCH_SHMOBILE
default "9" if SA1111
default "11"
AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE,
No it doens't.
int "Maximum zone order" if ARCH_SHMOBILE
is far from being the same as:
int "Maximum zone order"
depends on ARCH_SHMOBILE
The former defines a condition upon which the option is offered in GUIs -
or to put it another way, it defines the visibility of the option.
The latter defines a dependency which must be met for the option to be
both visible and appear in the resulting configuration file.
so SA1111 won't be evaluated (at least if I select SA1111
And did you check that SA1111 remains selected? I bet you didn't. Or
maybe you tested your patched version. Whatever. The original works,
and has been known to work for years. Your patch breaks it. It's
really as simple as that.
On 25.09.2012 10:14, Russell King - ARM Linux wrote:
On Tue, Sep 25, 2012 at 10:05:30AM +0200, Yegor Yefremov wrote:
quoted
How should I change the patch to make it proper? SA1111 is broken anyway:
No it isn't. This is what it produces _today_, and has done for the last
5-10 years without modification
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=9
CONFIG_LEDS=y
CONFIG_LEDS_CPU=y
quoted
config FORCE_MAX_ZONEORDER
int "Maximum zone order" if ARCH_SHMOBILE
range 11 64 if ARCH_SHMOBILE
default "9" if SA1111
default "11"
AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE,
No it doens't.
int "Maximum zone order" if ARCH_SHMOBILE
is far from being the same as:
int "Maximum zone order"
depends on ARCH_SHMOBILE
The former defines a condition upon which the option is offered in GUIs -
or to put it another way, it defines the visibility of the option.
The latter defines a dependency which must be met for the option to be
both visible and appear in the resulting configuration file.
quoted
so SA1111 won't be evaluated (at least if I select SA1111
And did you check that SA1111 remains selected? I bet you didn't. Or
maybe you tested your patched version. Whatever. The original works,
and has been known to work for years. Your patch breaks it. It's
really as simple as that.
Thanks for explanation. I think I've got it now. Please review the v2 version.
Yegor
Dear Tony
Thank you for applying this patch. I am quite new in such things as is
posting patched to the community, therefore Yegor help me on this manner.
Anyway, I have one more challenging question/request.
I and my colleagues have developed a brand new very enhanced board having
AM35xx CPU, 512MB DDR2, DVI, true dual Ethernet support (not using PRUSS),
CAN, SPI, I2C, 7 USBs, etc?Board is already materialized and operational.
According to our board we have create new machine type in the kernel
(version: linux-3.2-psp04.06.00.07.sdk) and all other required stuff to
support our board, modify some things, like adding support for dual eth,
etc. Our goal is to provide this new board to the market (let say with
large quantity) and therefore I am wondering how to start or if it is even
possible to transfer our kernel change the main stream of this distro?
During this kernel modification process we have been looking to not
changing anything in kernel, what could affect other machine types.
Thank you for you answer, and looking forward to receive your replay.
Best regards,
Dejan
2012/9/25 Yegor Yefremov [off-list ref]
On 25.09.2012 10:14, Russell King - ARM Linux wrote:
quoted
On Tue, Sep 25, 2012 at 10:05:30AM +0200, Yegor Yefremov wrote:
quoted
How should I change the patch to make it proper? SA1111 is broken
anyway:
quoted
No it isn't. This is what it produces _today_, and has done for the last
5-10 years without modification
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=9
CONFIG_LEDS=y
CONFIG_LEDS_CPU=y
quoted
config FORCE_MAX_ZONEORDER
int "Maximum zone order" if ARCH_SHMOBILE
range 11 64 if ARCH_SHMOBILE
default "9" if SA1111
default "11"
AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE,
No it doens't.
int "Maximum zone order" if ARCH_SHMOBILE
is far from being the same as:
int "Maximum zone order"
depends on ARCH_SHMOBILE
The former defines a condition upon which the option is offered in GUIs -
or to put it another way, it defines the visibility of the option.
The latter defines a dependency which must be met for the option to be
both visible and appear in the resulting configuration file.
quoted
so SA1111 won't be evaluated (at least if I select SA1111
And did you check that SA1111 remains selected? I bet you didn't. Or
maybe you tested your patched version. Whatever. The original works,
and has been known to work for years. Your patch breaks it. It's
really as simple as that.
Thanks for explanation. I think I've got it now. Please review the v2
version.
Yegor
I and my colleagues have developed a brand new very enhanced board having
AM35xx CPU, 512MB DDR2, DVI, true dual Ethernet support (not using PRUSS),
CAN, SPI, I2C, 7 USBs, etc?Board is already materialized and operational.
According to our board we have create new machine type in the kernel
(version: linux-3.2-psp04.06.00.07.sdk) and all other required stuff to
support our board, modify some things, like adding support for dual eth,
etc. Our goal is to provide this new board to the market (let say with
large quantity) and therefore I am wondering how to start or if it is even
possible to transfer our kernel change the main stream of this distro?
During this kernel modification process we have been looking to not
changing anything in kernel, what could affect other machine types.
For the mainline kernel, you should go with device tree based booting
to start with, we are no longer adding new board-*.c files. For older
distro kernels you need to maintain a separate board-*.c file until
we have moved everything to use device tree and distros are using
that kernel.
Regards,
Tony