[PATCH 3.14 63/77] ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Petazzoni
commit e55355453600a33bb5ca4f71f2d7214875f3b061 upstream.
Enabling the hardware I/O coherency on Armada 370, Armada 375, Armada
38x and Armada XP requires a certain number of conditions:
- On Armada 370, the cache policy must be set to write-allocate.
- On Armada 375, 38x and XP, the cache policy must be set to
write-allocate, the pages must be mapped with the shareable
attribute, and the SMP bit must be set
Currently, on Armada XP, when CONFIG_SMP is enabled, those conditions
are met. However, when Armada XP is used in a !CONFIG_SMP kernel, none
of these conditions are met. With Armada 370, the situation is worse:
since the processor is single core, regardless of whether CONFIG_SMP
or !CONFIG_SMP is used, the cache policy will be set to write-back by
the kernel and not write-allocate.
Since solving this problem turns out to be quite complicated, and we
don't want to let users with a mainline kernel known to have
infrequent but existing data corruptions, this commit proposes to
simply disable hardware I/O coherency in situations where it is known
not to work.
And basically, the is_smp() function of the kernel tells us whether it
is OK to enable hardware I/O coherency or not, so this commit slightly
refactors the coherency_type() function to return
COHERENCY_FABRIC_TYPE_NONE when is_smp() is false, or the appropriate
type of the coherency fabric in the other case.
Thanks to this, the I/O coherency fabric will no longer be used at all
in !CONFIG_SMP configurations. It will continue to be used in
CONFIG_SMP configurations on Armada XP, Armada 375 and Armada 38x
(which are multiple cores processors), but will no longer be used on
Armada 370 (which is a single core processor).
In the process, it simplifies the implementation of the
coherency_type() function, and adds a missing call to of_node_put().
Signed-off-by: Thomas Petazzoni
Fixes: e60304f8cb7bb545e79fe62d9b9762460c254ec2 ("arm: mvebu: Add hardware I/O
Coherency support")
Acked-by: Gregory CLEMENT
Link:
https://lkml.kernel.org/r/1415871540-20302-3-git-send-email-thomas.petazz...@free-electrons.com
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/mach-mvebu/coherency.c | 26 ++
1 file changed, 26 insertions(+)
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -125,6 +125,29 @@ int __init coherency_init(void)
{
struct device_node *np;
+ /*
+* The coherency fabric is needed:
+* - For coherency between processors on Armada XP, so only
+* when SMP is enabled.
+* - For coherency between the processor and I/O devices, but
+* this coherency requires many pre-requisites (write
+* allocate cache policy, shareable pages, SMP bit set) that
+* are only meant in SMP situations.
+*
+* Note that this means that on Armada 370, there is currently
+* no way to use hardware I/O coherency, because even when
+* CONFIG_SMP is enabled, is_smp() returns false due to the
+* Armada 370 being a single-core processor. To lift this
+* limitation, we would have to find a way to make the cache
+* policy set to write-allocate (on all Armada SoCs), and to
+* set the shareable attribute in page tables (on all Armada
+* SoCs except the Armada 370). Unfortunately, such decisions
+* are taken very early in the kernel boot process, at a point
+* where we don't know yet on which SoC we are running.
+*/
+ if (!is_smp())
+ return 0;
+
np = of_find_matching_node(NULL, of_coherency_table);
if (np) {
struct resource res;
@@ -151,6 +174,9 @@ static int __init coherency_late_init(vo
{
struct device_node *np;
+ if (!is_smp())
+ return 0;
+
np = of_find_matching_node(NULL, of_coherency_table);
if (np) {
bus_register_notifier(_bus_type,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.14 63/77] ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
commit e55355453600a33bb5ca4f71f2d7214875f3b061 upstream.
Enabling the hardware I/O coherency on Armada 370, Armada 375, Armada
38x and Armada XP requires a certain number of conditions:
- On Armada 370, the cache policy must be set to write-allocate.
- On Armada 375, 38x and XP, the cache policy must be set to
write-allocate, the pages must be mapped with the shareable
attribute, and the SMP bit must be set
Currently, on Armada XP, when CONFIG_SMP is enabled, those conditions
are met. However, when Armada XP is used in a !CONFIG_SMP kernel, none
of these conditions are met. With Armada 370, the situation is worse:
since the processor is single core, regardless of whether CONFIG_SMP
or !CONFIG_SMP is used, the cache policy will be set to write-back by
the kernel and not write-allocate.
Since solving this problem turns out to be quite complicated, and we
don't want to let users with a mainline kernel known to have
infrequent but existing data corruptions, this commit proposes to
simply disable hardware I/O coherency in situations where it is known
not to work.
And basically, the is_smp() function of the kernel tells us whether it
is OK to enable hardware I/O coherency or not, so this commit slightly
refactors the coherency_type() function to return
COHERENCY_FABRIC_TYPE_NONE when is_smp() is false, or the appropriate
type of the coherency fabric in the other case.
Thanks to this, the I/O coherency fabric will no longer be used at all
in !CONFIG_SMP configurations. It will continue to be used in
CONFIG_SMP configurations on Armada XP, Armada 375 and Armada 38x
(which are multiple cores processors), but will no longer be used on
Armada 370 (which is a single core processor).
In the process, it simplifies the implementation of the
coherency_type() function, and adds a missing call to of_node_put().
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Fixes: e60304f8cb7bb545e79fe62d9b9762460c254ec2 (arm: mvebu: Add hardware I/O
Coherency support)
Acked-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Link:
https://lkml.kernel.org/r/1415871540-20302-3-git-send-email-thomas.petazz...@free-electrons.com
Signed-off-by: Jason Cooper ja...@lakedaemon.net
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
arch/arm/mach-mvebu/coherency.c | 26 ++
1 file changed, 26 insertions(+)
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -125,6 +125,29 @@ int __init coherency_init(void)
{
struct device_node *np;
+ /*
+* The coherency fabric is needed:
+* - For coherency between processors on Armada XP, so only
+* when SMP is enabled.
+* - For coherency between the processor and I/O devices, but
+* this coherency requires many pre-requisites (write
+* allocate cache policy, shareable pages, SMP bit set) that
+* are only meant in SMP situations.
+*
+* Note that this means that on Armada 370, there is currently
+* no way to use hardware I/O coherency, because even when
+* CONFIG_SMP is enabled, is_smp() returns false due to the
+* Armada 370 being a single-core processor. To lift this
+* limitation, we would have to find a way to make the cache
+* policy set to write-allocate (on all Armada SoCs), and to
+* set the shareable attribute in page tables (on all Armada
+* SoCs except the Armada 370). Unfortunately, such decisions
+* are taken very early in the kernel boot process, at a point
+* where we don't know yet on which SoC we are running.
+*/
+ if (!is_smp())
+ return 0;
+
np = of_find_matching_node(NULL, of_coherency_table);
if (np) {
struct resource res;
@@ -151,6 +174,9 @@ static int __init coherency_late_init(vo
{
struct device_node *np;
+ if (!is_smp())
+ return 0;
+
np = of_find_matching_node(NULL, of_coherency_table);
if (np) {
bus_register_notifier(platform_bus_type,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
