| e03b4809 | 07-May-2018 |
Jisheng Zhang <[email protected]> |
arm: berlin: remove non-necessary flush_cache_all()
I believe the flush_cache_all() after scu_enable() is to "Ensure that
the data accessed by CPU0 before the SCU was initialised is visible
to the o
arm: berlin: remove non-necessary flush_cache_all()
I believe the flush_cache_all() after scu_enable() is to "Ensure that
the data accessed by CPU0 before the SCU was initialised is visible
to the other CPUs." as commented in scu_enable(). So here
flush_cache_all() is a duplication, remove it.
Signed-off-by: Jisheng Zhang <[email protected]>
show more ...
|
| d2ca5f24 | 29-Jan-2017 |
Afzal Mohammed <[email protected]> |
ARM: 8646/1: mmu: decouple VECTORS_BASE from Kconfig
For MMU configurations, VECTORS_BASE is always 0xffff0000, a macro
definition will suffice.
For no-MMU, exception base address is dynamically de
ARM: 8646/1: mmu: decouple VECTORS_BASE from Kconfig
For MMU configurations, VECTORS_BASE is always 0xffff0000, a macro
definition will suffice.
For no-MMU, exception base address is dynamically determined in
subsequent patches. To preserve bisectability, now make the
macro applicable for no-MMU scenario too.
Thanks to 0-DAY kernel test infrastructure that found the
bisectability issue. This macro will be restricted to MMU case upon
dynamically determining exception base address for no-MMU.
Once exception address is handled dynamically for no-MMU,
VECTORS_BASE can be removed from Kconfig.
Signed-off-by: afzal mohammed <[email protected]>
Tested-by: Vladimir Murzin <[email protected]>
Signed-off-by: Russell King <[email protected]>
show more ...
|
| e3246542 | 16-Nov-2015 |
Masahiro Yamada <[email protected]> |
ARM: use "depends on" for SoC configs instead of "if" after prompt
Many ARM sub-architectures use prompts followed by "if" conditional,
but it is wrong.
Please notice the difference between
co
ARM: use "depends on" for SoC configs instead of "if" after prompt
Many ARM sub-architectures use prompts followed by "if" conditional,
but it is wrong.
Please notice the difference between
config ARCH_FOO
bool "Foo SoCs" if ARCH_MULTI_V7
and
config ARCH_FOO
bool "Foo SoCs"
depends on ARCH_MULTI_V7
These two are *not* equivalent!
In the former statement, it is not ARCH_FOO, but its prompt that
depends on ARCH_MULTI_V7. So, it is completely valid that ARCH_FOO
is selected by another, but ARCH_MULTI_V7 is still disabled. As it is
not unmet dependency, Kconfig never warns. This is probably not what
you want.
The former should be used only when you need to do so, and you really
understand what you are doing. (In most cases, it should be wrong!)
For enabling/disabling sub-architectures, the latter is always correct.
As a good side effect, this commit fixes some entries over 80 columns
(mach-imx, mach-integrator, mach-mbevu).
[Arnd: I note that there is not really a bug here, according to
the discussion that followed, but I can see value in being consistent
and in making the lines shorter]
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Acked-by: Nicolas Ferre <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
Acked-by: Patrice Chotard <[email protected]>
Acked-by: Liviu Dudau <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Jun Nie <[email protected]>
Acked-by: Matthias Brugger <[email protected]>
Acked-by: Simon Horman <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Acked-by: Shawn Guo <[email protected]>
Acked-by: Sebastian Hesselbarth <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Acked-by: Krzysztof Halasa <[email protected]>
Acked-by: Maxime Coquelin <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
show more ...
|
| a7b3d5a7 | 14-Sep-2015 |
Jisheng Zhang <[email protected]> |
arm: berlin: add CPU hotplug support
Add cpu hotplug support for berlin SoCs such as BG2 and BG2Q. These SoC
don't support power off cpu independently, but we also want cpu hotplug
support in these
arm: berlin: add CPU hotplug support
Add cpu hotplug support for berlin SoCs such as BG2 and BG2Q. These SoC
don't support power off cpu independently, but we also want cpu hotplug
support in these SoCs. We achieve this goal by putting the dying CPU in
WFI state after the coherency is disabled, then asserting the dying CPU
reset bit to put the CPU in reset state.
Signed-off-by: Jisheng Zhang <[email protected]>
Signed-off-by: Sebastian Hesselbarth <[email protected]>
show more ...
|
| ac7fc233 | 14-Sep-2015 |
Jisheng Zhang <[email protected]> |
arm: berlin: use non-self-cleared reset register to reset cpu
In Berlin SoCs, there are two kinds of cpu reset control registers: the
first one's corresponding bits will be self-cleared after some c
arm: berlin: use non-self-cleared reset register to reset cpu
In Berlin SoCs, there are two kinds of cpu reset control registers: the
first one's corresponding bits will be self-cleared after some cycles,
while the second one's bits won't. Previously the first kind of reset
control register is used, this patch uses the second kind one to prepare
for the next hotplug commit.
Signed-off-by: Jisheng Zhang <[email protected]>
Signed-off-by: Sebastian Hesselbarth <[email protected]>
show more ...
|
| 81906906 | 17-Nov-2014 |
Antoine Tenart <[email protected]> |
ARM: berlin: do not select RESET_CONTROLLER
RESET_CONTROLLER is meant to be user-selectable. To respect that,
do not select it automatically when using ARCH_BERLIN.
Signed-off-by: Antoine Tenart <a
ARM: berlin: do not select RESET_CONTROLLER
RESET_CONTROLLER is meant to be user-selectable. To respect that,
do not select it automatically when using ARCH_BERLIN.
Signed-off-by: Antoine Tenart <[email protected]>
Signed-off-by: Sebastian Hesselbarth <[email protected]>
show more ...
|