* [PATCH v13 2/7] arm: arm64: Add routine to determine cpuid of other cpus
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
It is helpful if we can read the cpuid/midr of other CPUs
in the system independent of arm/arm64.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm/include/asm/cputype.h | 4 ++++
arch/arm/kernel/setup.c | 2 +-
arch/arm64/include/asm/cputype.h | 3 +++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 522b5fe..1e87d06 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -235,6 +235,10 @@ static inline unsigned int __attribute_const__ read_cpuid_mpidr(void)
#define cpu_is_sa1100() (read_cpuid_part() == ARM_CPU_PART_SA1100)
#define cpu_is_sa1110() (read_cpuid_part() == ARM_CPU_PART_SA1110)
+#define read_specific_cpuid(cpu_num) (is_smp() ? \
+ per_cpu_ptr(&cpu_data, cpu_num)->cpuid \
+ : read_cpuid_id())
+
/*
* Intel's XScale3 core supports some v6 features (supersections, L2)
* but advertises itself as v5 as it does not support the v6 ISA. For
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 34e3f3c..d443c97 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1217,7 +1217,7 @@ static int c_show(struct seq_file *m, void *v)
* "processor". Give glibc what it expects.
*/
seq_printf(m, "processor\t: %d\n", i);
- cpuid = is_smp() ? per_cpu(cpu_data, i).cpuid : read_cpuid_id();
+ cpuid = read_specific_cpuid(i);
seq_printf(m, "model name\t: %s rev %d (%s)\n",
cpu_name, cpuid & 15, elf_platform);
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 26a68dd..a6d26e1 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -124,6 +124,9 @@ static inline u32 __attribute_const__ read_cpuid_cachetype(void)
{
return read_cpuid(CTR_EL0);
}
+
+#define read_specific_cpuid(cpu_num) per_cpu_ptr(&cpu_data, cpu_num)->reg_midr
+
#endif /* __ASSEMBLY__ */
#endif
--
2.5.5
^ permalink raw reply related
* [PATCH v13 3/7] arm64: pmu: Cache PMU interrupt numbers from MADT parse
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
From: Mark Salter <msalter@redhat.com>
In the case of ACPI, the PMU IRQ information is contained in the
MADT table. Also, since the PMU does not exist as a device in the
ACPI DSDT table, it is necessary to create a platform device so
that the appropriate driver probing is triggered. Since the platform
device creation needs to happen after the CPU's have been started, and
the MADT parsing needs to happen before, we save off the interrupt
numbers discovered during the parsing.
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/smp.c | 5 +++++
drivers/perf/Kconfig | 4 ++++
drivers/perf/Makefile | 1 +
drivers/perf/arm_pmu_acpi.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/linux/perf/arm_pmu.h | 7 +++++++
5 files changed, 57 insertions(+)
create mode 100644 drivers/perf/arm_pmu_acpi.c
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 8ea244c..cbaab44 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -37,6 +37,7 @@
#include <linux/completion.h>
#include <linux/of.h>
#include <linux/irq_work.h>
+#include <linux/perf/arm_pmu.h>
#include <asm/alternative.h>
#include <asm/atomic.h>
@@ -552,6 +553,7 @@ acpi_verify_and_map_madt(struct acpi_madt_generic_interrupt *processor)
}
bootcpu_valid = true;
early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
+ arm_pmu_parse_acpi(0, processor);
return;
}
@@ -572,6 +574,9 @@ acpi_verify_and_map_madt(struct acpi_madt_generic_interrupt *processor)
*/
acpi_set_mailbox_entry(cpu_count, processor);
+ /* get PMU irq info */
+ arm_pmu_parse_acpi(cpu_count, processor);
+
early_map_cpu_to_node(cpu_count, acpi_numa_get_nid(cpu_count, hwid));
cpu_count++;
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 4d5c5f9..697df05 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -19,4 +19,8 @@ config XGENE_PMU
help
Say y if you want to use APM X-Gene SoC performance monitors.
+config ARM_PMU_ACPI
+ def_bool y
+ depends on ARM_PMU && ACPI
+
endmenu
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index b116e98..d1d7762 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARM_PMU) += arm_pmu.o
obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
+obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
new file mode 100644
index 0000000..2008001
--- /dev/null
+++ b/drivers/perf/arm_pmu_acpi.c
@@ -0,0 +1,40 @@
+/*
+ * ARM ACPI PMU support
+ *
+ * Copyright (C) 2015 Red Hat Inc.
+ * Author: Mark Salter <msalter@redhat.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include <asm/cpu.h>
+#include <linux/acpi.h>
+#include <linux/irq.h>
+#include <linux/irqdesc.h>
+#include <linux/list.h>
+#include <linux/perf/arm_pmu.h>
+#include <linux/platform_device.h>
+
+struct pmu_irq {
+ int gsi;
+ int trigger;
+ bool used;
+};
+
+static struct pmu_irq pmu_irqs[NR_CPUS];
+
+/*
+ * Called from acpi_verify_and_map_madt()'s MADT parsing during boot.
+ * This routine saves off the GSI's and their trigger state for use when we are
+ * ready to build the PMU platform device.
+ */
+void __init arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic)
+{
+ pmu_irqs[cpu].gsi = gic->performance_interrupt;
+ if (gic->flags & ACPI_MADT_PERFORMANCE_IRQ_MODE)
+ pmu_irqs[cpu].trigger = ACPI_EDGE_SENSITIVE;
+ else
+ pmu_irqs[cpu].trigger = ACPI_LEVEL_SENSITIVE;
+}
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 8462da2..df1ba55 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -164,4 +164,11 @@ int arm_pmu_device_probe(struct platform_device *pdev,
#endif /* CONFIG_ARM_PMU */
+#ifdef CONFIG_ARM_PMU_ACPI
+struct acpi_madt_generic_interrupt;
+void arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic);
+#else
+#define arm_pmu_parse_acpi(a, b) do { } while (0)
+#endif /* CONFIG_ARM_PMU_ACPI */
+
#endif /* __ARM_PMU_H__ */
--
2.5.5
^ permalink raw reply related
* [PATCH v13 4/7] arm: arm64: pmu: Assign platform PMU CPU affinity
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
On systems with multiple PMU types the PMU to CPU affinity
needs to be detected and set. The CPU to interrupt affinity
should also be set.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/perf/arm_pmu.c | 43 +++++++++++++++++++++++++++++++++----------
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 6d93358..37e241f 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -11,6 +11,7 @@
*/
#define pr_fmt(fmt) "hw perfevents: " fmt
+#include <linux/acpi.h>
#include <linux/bitmap.h>
#include <linux/cpumask.h>
#include <linux/cpu_pm.h>
@@ -24,6 +25,7 @@
#include <linux/irq.h>
#include <linux/irqdesc.h>
+#include <asm/cpu.h>
#include <asm/cputype.h>
#include <asm/irq_regs.h>
@@ -889,25 +891,47 @@ static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
}
/*
- * CPU PMU identification and probing.
+ * CPU PMU identification and probing. Its possible to have
+ * multiple CPU types in an ARM machine. Assure that we are
+ * picking the right PMU types based on the CPU in question
*/
-static int probe_current_pmu(struct arm_pmu *pmu,
- const struct pmu_probe_info *info)
+static int probe_plat_pmu(struct arm_pmu *pmu,
+ const struct pmu_probe_info *info,
+ unsigned int pmuid)
{
- int cpu = get_cpu();
- unsigned int cpuid = read_cpuid_id();
int ret = -ENODEV;
+ int cpu;
+ int aff_ctr = 0;
+ struct platform_device *pdev = pmu->plat_device;
+ int irq = platform_get_irq(pdev, 0);
- pr_info("probing PMU on CPU %d\n", cpu);
+ if (irq >= 0 && !irq_is_percpu(irq)) {
+ pmu->irq_affinity = kcalloc(pdev->num_resources, sizeof(int),
+ GFP_KERNEL);
+ if (!pmu->irq_affinity)
+ return -ENOMEM;
+ }
+
+ for_each_possible_cpu(cpu) {
+ unsigned int cpuid = read_specific_cpuid(cpu);
+
+ if (cpuid == pmuid) {
+ cpumask_set_cpu(cpu, &pmu->supported_cpus);
+ if (pmu->irq_affinity) {
+ pmu->irq_affinity[aff_ctr] = cpu;
+ aff_ctr++;
+ }
+ }
+ }
+ /* find the type of PMU given the CPU */
for (; info->init != NULL; info++) {
- if ((cpuid & info->mask) != info->cpuid)
+ if ((pmuid & info->mask) != info->cpuid)
continue;
ret = info->init(pmu);
break;
}
- put_cpu();
return ret;
}
@@ -1043,8 +1067,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
if (!ret)
ret = init_fn(pmu);
} else if (probe_table) {
- cpumask_setall(&pmu->supported_cpus);
- ret = probe_current_pmu(pmu, probe_table);
+ ret = probe_plat_pmu(pmu, probe_table, read_cpuid_id());
}
if (ret) {
--
2.5.5
^ permalink raw reply related
* [PATCH v13 5/7] arm64: pmu: Detect multiple generic PMUs and append counter
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
In heterogeneous CPU systems its likely that there are multiple
PMU types. If a system is using the generic armv8_pmuv3 rather
than a PMU with a hard-coded set of events then we want to uniquely
identify each PMU in /sys. We do this by appending an "_x" to the
pmu name. This then creates PMUs like, "armv8_pmuv3" and
"armv8_pmuv3_1", "armv8_pmuv3_2" for a system with 3 PMU types.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/perf_event.c | 2 +-
drivers/perf/arm_pmu.c | 20 ++++++++++++++++++++
include/linux/perf/arm_pmu.h | 1 +
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 57ae9d9..0fbd7ef 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -1002,7 +1002,7 @@ static void armv8_pmu_init(struct arm_pmu *cpu_pmu)
static int armv8_pmuv3_init(struct arm_pmu *cpu_pmu)
{
armv8_pmu_init(cpu_pmu);
- cpu_pmu->name = "armv8_pmuv3";
+ cpu_pmu->name = ARMV8_PMUV3_DESCRIPTION;
cpu_pmu->map_event = armv8_pmuv3_map_event;
cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_EVENTS] =
&armv8_pmuv3_events_attr_group;
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 37e241f..85566f6 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -1035,6 +1035,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
const struct of_device_id *of_table,
const struct pmu_probe_info *probe_table)
{
+ static int duplicate_pmus;
const struct of_device_id *of_id;
const int (*init_fn)(struct arm_pmu *);
struct device_node *node = pdev->dev.of_node;
@@ -1075,6 +1076,25 @@ int arm_pmu_device_probe(struct platform_device *pdev,
goto out_free;
}
+ /*
+ * if this pmu declaration is a generic pmu and we have
+ * previously found a generic pmu on this platform
+ * then append a PMU number to the pmu name. This avoids
+ * changing the names of PMUs that are specific to a class
+ * of CPUs. The assumption is that if we match a specific PMU
+ * then it's unique, and another PMU in the system will match
+ * a different entry rather than needing the _number to
+ * assure its unique.
+ */
+ if (!strcmp(pmu->name, ARMV8_PMUV3_DESCRIPTION)) {
+ if (duplicate_pmus) {
+ pmu->name = kasprintf(GFP_KERNEL, "%s_%d",
+ pmu->name, duplicate_pmus);
+ if (!pmu->name)
+ goto out_free;
+ }
+ duplicate_pmus++;
+ }
ret = cpu_pmu_init(pmu);
if (ret)
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index df1ba55..42b5edb 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -161,6 +161,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
const struct pmu_probe_info *probe_table);
#define ARMV8_PMU_PDEV_NAME "armv8-pmu"
+#define ARMV8_PMUV3_DESCRIPTION "armv8_pmuv3"
#endif /* CONFIG_ARM_PMU */
--
2.5.5
^ permalink raw reply related
* [PATCH v13 6/7] arm64: pmu: Detect and enable multiple PMUs in an ACPI system
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
Its possible that an ACPI system has multiple CPU types in it
with differing PMU counters. Iterate the CPU's and make a determination
about how many of each type exist in the system. Then take and create
a PMU platform device for each type, and assign it the interrupts parsed
from the MADT. Creating a platform device is necessary because the PMUs
are not described as devices in the DSDT table.
This code is loosely based on earlier work by Mark Salter.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/perf/arm_pmu.c | 8 +-
drivers/perf/arm_pmu_acpi.c | 231 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 238 insertions(+), 1 deletion(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 85566f6..77ec1ae 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -1068,7 +1068,13 @@ int arm_pmu_device_probe(struct platform_device *pdev,
if (!ret)
ret = init_fn(pmu);
} else if (probe_table) {
- ret = probe_plat_pmu(pmu, probe_table, read_cpuid_id());
+ if (acpi_disabled) {
+ /* use the current cpu. */
+ ret = probe_plat_pmu(pmu, probe_table,
+ read_cpuid_id());
+ } else {
+ ret = probe_plat_pmu(pmu, probe_table, pdev->id);
+ }
}
if (ret) {
diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
index 2008001..6e0488f 100644
--- a/drivers/perf/arm_pmu_acpi.c
+++ b/drivers/perf/arm_pmu_acpi.c
@@ -2,13 +2,17 @@
* ARM ACPI PMU support
*
* Copyright (C) 2015 Red Hat Inc.
+ * Copyright (C) 2016 ARM Ltd.
* Author: Mark Salter <msalter@redhat.com>
+ * Jeremy Linton <jeremy.linton@arm.com>
*
* This work is licensed under the terms of the GNU GPL, version 2. See
* the COPYING file in the top-level directory.
*
*/
+#define pr_fmt(fmt) "ACPI-PMU: " fmt
+
#include <asm/cpu.h>
#include <linux/acpi.h>
#include <linux/irq.h>
@@ -20,9 +24,16 @@
struct pmu_irq {
int gsi;
int trigger;
+ int irq;
bool used;
};
+struct pmu_types {
+ struct list_head list;
+ int cpu_type;
+ int cpu_count;
+};
+
static struct pmu_irq pmu_irqs[NR_CPUS];
/*
@@ -38,3 +49,223 @@ void __init arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic)
else
pmu_irqs[cpu].trigger = ACPI_LEVEL_SENSITIVE;
}
+
+static void __init arm_pmu_acpi_handle_alloc_failure(struct list_head *pmus)
+{
+ int i;
+ struct pmu_types *pmu, *safe_temp;
+
+ list_for_each_entry_safe(pmu, safe_temp, pmus, list) {
+ list_del(&pmu->list);
+ kfree(pmu);
+ }
+
+ for_each_possible_cpu(i)
+ if (pmu_irqs[i].irq > 0)
+ acpi_unregister_gsi(pmu_irqs[i].gsi);
+}
+
+/*
+ * Count number and type of CPU cores in the system. Returns the number
+ * of "unused" MADT entries we could not associate with a PMU. This can
+ * be the result of CPU's not being online, or errors in the MADT.
+ * Under normal circumstances this will be 0.
+ */
+static int __init arm_pmu_acpi_determine_cpu_types(struct list_head *pmus)
+{
+ int i;
+ int unused_madt_entries = 0;
+
+ for_each_possible_cpu(i) {
+ u32 reg_midr = read_specific_cpuid(i);
+ struct pmu_types *pmu;
+
+ /*
+ * Ignore GSI registration failure for now, as
+ * some of the MADT entries may not be used.
+ */
+ pmu_irqs[i].irq = acpi_register_gsi(NULL, pmu_irqs[i].gsi,
+ pmu_irqs[i].trigger,
+ ACPI_ACTIVE_HIGH);
+ /* likely not online */
+ if (reg_midr == 0) {
+ unused_madt_entries++;
+ continue;
+ }
+
+ list_for_each_entry(pmu, pmus, list) {
+ if (pmu->cpu_type == reg_midr) {
+ pmu->cpu_count++;
+ break;
+ }
+ }
+
+ /* we didn't find the CPU type, add an entry to identify it */
+ if (&pmu->list == pmus) {
+ pmu = kzalloc(sizeof(struct pmu_types), GFP_KERNEL);
+ if (!pmu) {
+ pr_err("Unable to allocate pmu_types\n");
+ arm_pmu_acpi_handle_alloc_failure(pmus);
+ break;
+ }
+ pmu->cpu_type = reg_midr;
+ pmu->cpu_count++;
+ list_add_tail(&pmu->list, pmus);
+ }
+ }
+
+ return unused_madt_entries;
+}
+
+static int __init arm_pmu_acpi_register_device(int count, struct resource *res,
+ int cpu_id)
+{
+ struct platform_device *pdev;
+ int err = -ENOMEM;
+
+ pdev = platform_device_alloc(ARMV8_PMU_PDEV_NAME, cpu_id);
+ if (pdev) {
+ err = platform_device_add_resources(pdev, res, count);
+ if (!err)
+ err = platform_device_add(pdev);
+ if (err) {
+ pr_warn("Unable to register PMU device\n");
+ platform_device_put(pdev);
+ }
+ } else {
+ pr_warn("Unable to allocate platform device\n");
+ }
+
+ return err;
+}
+
+static void __init arm_pmu_acpi_unregister_pmu_gsi(int cpu_id)
+{
+ int i;
+
+ for_each_possible_cpu(i) {
+
+ if (read_specific_cpuid(i) == cpu_id) {
+ pmu_irqs[i].used = false;
+ if (pmu_irqs[i].irq > 0)
+ acpi_unregister_gsi(pmu_irqs[i].gsi);
+ pmu_irqs[i].gsi = -ENODEV;
+ }
+ }
+}
+
+/*
+ * Registers the group of PMU interfaces which correspond to the 'cpu_id'.
+ * This group utilizes 'count' resources in the 'res'.
+ */
+static int __init arm_pmu_acpi_register_pmu(int count, struct resource *res,
+ int cpu_id)
+{
+ int err;
+
+ err = arm_pmu_acpi_register_device(count, res, cpu_id);
+
+ /* unmark and unregister GSIs for this PMU */
+ if (err)
+ arm_pmu_acpi_unregister_pmu_gsi(cpu_id);
+
+ return err;
+}
+
+int arm_pmu_acpi_retrieve_irq(struct resource *res, int cpu)
+{
+ int irq = -ENODEV;
+
+ if (pmu_irqs[cpu].used) {
+ pr_info("CPU %d's interrupt is already used\n", cpu);
+ } else {
+ pmu_irqs[cpu].used = true;
+ res->start = pmu_irqs[cpu].irq;
+ res->end = pmu_irqs[cpu].irq;
+ res->flags = IORESOURCE_IRQ;
+ if (pmu_irqs[cpu].trigger == ACPI_EDGE_SENSITIVE)
+ res->flags |= IORESOURCE_IRQ_HIGHEDGE;
+ else
+ res->flags |= IORESOURCE_IRQ_HIGHLEVEL;
+ }
+ return irq;
+}
+
+/*
+ * For the given cpu/pmu type, walk all known GSIs, register them, and add
+ * them to the resource structure. Return the number of GSI's contained
+ * in the res structure, and the id of the last CPU/PMU we added.
+ */
+static int __init arm_pmu_acpi_gsi_res(struct pmu_types *pmus,
+ struct resource *res)
+{
+ int i, count;
+
+ /* lets group all the PMU's from similar CPU's together */
+ count = 0;
+ for_each_possible_cpu(i) {
+ u32 reg_midr = read_specific_cpuid(i);
+
+ if (pmus->cpu_type == reg_midr) {
+ if ((pmu_irqs[i].gsi == 0) && (reg_midr != 0))
+ continue;
+
+ /* likely not online */
+ if (!reg_midr)
+ continue;
+
+ arm_pmu_acpi_retrieve_irq(&res[count], i);
+ count++;
+ }
+ }
+ return count;
+}
+
+static int __init pmu_acpi_register(struct pmu_types *pmu)
+{
+ int count;
+ int err = -ENOMEM;
+ struct resource *res;
+
+ res = kcalloc(pmu->cpu_count, sizeof(struct resource), GFP_KERNEL);
+
+ /* for a given PMU type, collect all the GSIs. */
+ if (res) {
+ count = arm_pmu_acpi_gsi_res(pmu, res);
+ /* register this set of interrupts with a new PMU device */
+ err = arm_pmu_acpi_register_pmu(pmu->cpu_count, res,
+ pmu->cpu_type);
+ if (!err)
+ pr_info("Register %d devices for %X\n", count,
+ pmu->cpu_type);
+ kfree(res);
+ } else {
+ pr_warn("PMU unable to allocate interrupt resource\n");
+ arm_pmu_acpi_unregister_pmu_gsi(pmu->cpu_type);
+ }
+ return err;
+}
+
+static int __init pmu_acpi_init(void)
+{
+ struct pmu_types *pmu, *safe_temp;
+ int unused_madt_entries;
+ LIST_HEAD(pmus);
+
+ if (acpi_disabled)
+ return 0;
+
+ unused_madt_entries = arm_pmu_acpi_determine_cpu_types(&pmus);
+
+ list_for_each_entry_safe(pmu, safe_temp, &pmus, list) {
+ pmu->cpu_count += unused_madt_entries;
+ pmu_acpi_register(pmu);
+
+ list_del(&pmu->list);
+ kfree(pmu);
+ }
+
+ return 0;
+}
+
+arch_initcall(pmu_acpi_init);
--
2.5.5
^ permalink raw reply related
* [PATCH v13 7/7] arm: pmu: Add PMU definitions for cores not initially online
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
ACPI CPUs aren't associated with a PMU until they have been put
online. This means that we potentially have to update a PMU
definition the first time a CPU is hot added to the machine.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/perf/arm_pmu.c | 34 ++++++++++++++++++++++++++++++++--
include/linux/perf/arm_pmu.h | 4 ++++
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 77ec1ae..cf5122f 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -711,6 +711,26 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
return 0;
}
+static void arm_perf_associate_new_cpu(struct arm_pmu *lpmu, unsigned int cpu)
+{
+ struct platform_device *pdev = lpmu->plat_device;
+ struct resource *res;
+ struct pmu_hw_events *events;
+ int num_res;
+
+ for (num_res = 0; num_res < pdev->num_resources; num_res++) {
+ if (!pdev->resource[num_res].flags)
+ break;
+ }
+ res = &pdev->resource[num_res];
+ arm_pmu_acpi_retrieve_irq(res, cpu);
+ events = per_cpu_ptr(lpmu->hw_events, cpu);
+ cpumask_set_cpu(cpu, &lpmu->supported_cpus);
+ if (lpmu->irq_affinity)
+ lpmu->irq_affinity[num_res] = cpu;
+ events->percpu_pmu = lpmu;
+}
+
/*
* PMU hardware loses all context when a CPU goes offline.
* When a CPU is hotplugged back in, since some hardware registers are
@@ -721,10 +741,18 @@ static int arm_perf_starting_cpu(unsigned int cpu, struct hlist_node *node)
{
struct arm_pmu *pmu = hlist_entry_safe(node, struct arm_pmu, node);
- if (!cpumask_test_cpu(cpu, &pmu->supported_cpus))
- return 0;
+ if (!cpumask_test_cpu(cpu, &pmu->supported_cpus)) {
+ unsigned int cpuid = read_specific_cpuid(cpu);
+
+ if (acpi_disabled)
+ return 0;
+ if (cpuid != pmu->id)
+ return 0;
+ arm_perf_associate_new_cpu(pmu, cpu);
+ }
if (pmu->reset)
pmu->reset(pmu);
+
return 0;
}
@@ -905,6 +933,8 @@ static int probe_plat_pmu(struct arm_pmu *pmu,
struct platform_device *pdev = pmu->plat_device;
int irq = platform_get_irq(pdev, 0);
+ pmu->id = pmuid;
+
if (irq >= 0 && !irq_is_percpu(irq)) {
pmu->irq_affinity = kcalloc(pdev->num_resources, sizeof(int),
GFP_KERNEL);
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 42b5edb..f652cd1 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -112,6 +112,7 @@ struct arm_pmu {
struct mutex reserve_mutex;
u64 max_period;
bool secure_access; /* 32-bit ARM only */
+ unsigned int id;
#define ARMV8_PMUV3_MAX_COMMON_EVENTS 0x40
DECLARE_BITMAP(pmceid_bitmap, ARMV8_PMUV3_MAX_COMMON_EVENTS);
struct platform_device *plat_device;
@@ -168,8 +169,11 @@ int arm_pmu_device_probe(struct platform_device *pdev,
#ifdef CONFIG_ARM_PMU_ACPI
struct acpi_madt_generic_interrupt;
void arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic);
+int arm_pmu_acpi_retrieve_irq(struct resource *pdev, int cpu);
#else
#define arm_pmu_parse_acpi(a, b) do { } while (0)
+#define arm_pmu_acpi_retrieve_irq(pdev, cpu) \
+ do { } while (0)
#endif /* CONFIG_ARM_PMU_ACPI */
#endif /* __ARM_PMU_H__ */
--
2.5.5
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Maxime Ripard @ 2017-01-17 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPdbbzoqNLg=iRGC8ijVPdpLD5+CFyqysfM49vkx6o3rRQ@mail.gmail.com>
On Tue, Jan 17, 2017 at 01:31:19PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Jan 17, 2017 at 11:38 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Mon, Jan 16, 2017 at 08:49:06PM +0200, Krzysztof Kozlowski wrote:
> >> On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
> >> > The ARM Mali Utgard GPU family is embedded into a number of SoCs from
> >> > Allwinner, Amlogic, Mediatek or Rockchip.
> >> >
> >> > Add a binding for the GPU of that family.
> >> >
> >> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >> > ---
> >> > .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
> >> > 1 file changed, 76 insertions(+)
> >> > create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> >>
> >> Do you have a driver in kernel which will implement these bindings?
> >
> > No, but we have bindings for out-of-tree drivers already.
> >
> >> Defining them for out-of-tree driver does not bring any benefits
> >> (3rd party driver will not respect them anyway).
> >
> > You could see it the other way around too. The out-of-tree drivers
> > don't respect it at the moment because there's no binding to respect.
>
> Indeed, that's a point. However valid only when the out-of-tree driver
> will respect them, for example do not break them on next release.
If you're talking about the default platform provided by ARM, you also
have the option of creating your own. That's what we did, and it
worked like a charm.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/9fc96800/attachment.sig>
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Russell King - ARM Linux @ 2017-01-17 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117193414.GG27312@n2100.armlinux.org.uk>
On Tue, Jan 17, 2017 at 07:34:14PM +0000, Russell King - ARM Linux wrote:
> Uwe, can you try:
>
> setpci -s <whatever-the-id-of-the-root-is-it's-blanked-out-in-the-above> \
> 0x50.w=0x60
>
> and see whether it remains alive (you can check by reading the root
> register 0x52.w - bit 12 should be set once bit 11 clears again.
For reference, this I got wrong...
0xf1041a04 bit 0 indicates link status (0 = link up, 1 = link down).
> If that's successful, maybe setting the common clock bit on the PCIe
> device is what's causing the problem, in which case:
>
> setpci -s 02:00.0 0x80.w=0x40
> setpci -s <whatever-the-id-of-the-root-is-it's-blanked-out-in-the-above> \
> 0x50.w=0x60
Having worked with Uwe over IRC, it seems that any request to retrain
causes the link to go down, either with or without the common clock bit
set:
# setpci -s 2.0 0x50.w=0x60
# setpci -s 2.0 0x52.w
0011
# memtool md 0xf1041a04+4
f1041a04: 00010201
... reboot ...
# setpci -s 2.0 0x50.w=0x20
# memtool md 0xf1041a04+4
f1041a04: 00010201
which doesn't point towards ASPM itself, but the problem is caused by
a side effect of ASPM's setup code which always triggers a retrain.
Bit 5 in that register is documented (at least in the Armada 370 docs
and Armada XP docs I have) as:
5 RetrnLnk RW Retrain Link
0x0 This bit forces the device to initiate link retraining.
Always returns 0 when read.
NOTE: If configured as an Endpoint, this field is
reserved and has no effect.
Bjorn, are you aware of similar situations where a request for the PCIe
link to be retrained causes it to fail?
Here, on my Armada 388, I can request a link retrain with or without the
common clock bit set and everything's happy (this is with an ASM1062 SATA
mini-PCIe card):
root at clearfog21:~# setpci -s 2.0 0x50.w=0x60
root at clearfog21:~# setpci -s 2.0 0x52.w
0012
root at clearfog21:~# /shared/bin/devmem2 0xf1041a04
Value at address 0xf1041a04: 0x00010100
root at clearfog21:~# setpci -s 2.0 0x50.w=0x20
root at clearfog21:~# setpci -s 2.0 0x52.w
0012
root at clearfog21:~# /shared/bin/devmem2 0xf1041a04
Value at address 0xf1041a04: 0x00010100
One curious observation I have noticed on Armada 388 is this behaviour:
root at clearfog21:~# setpci -s 2.0 0x50.l=0xffff0040 0x50.l 0x50.l=0x0fff0040 0x50.l
10120040
00120040
bit 28 is writable, which goes against the 370/XP docs:
28 SltClkCfg RO Slot Clock Configuration
0x1 0 = Independent: The device uses an independent clock,
irrespective of the presence of a reference clock
on the connector.
1 = Reference: The device uses the reference clock that
the platform provides.
It seems that this bit is _not_ read-only.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Martin Blumenstingl @ 2017-01-17 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484680984.26620.29.camel@baylibre.com>
On Tue, Jan 17, 2017 at 8:23 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
>> This partially fixes the 1000Mbit/s ethernet TX throughput issues (on
>> networks which are not affected by the EEE problem, as reported here:
>> [1]).
>> The actual problem for the TX throughput issues was that the TX delay
>> was applied twice:
>> - once "accidentally" by the PHY (this was fixed with [2])
>> - once by the MAC because there was a hardcoded TX delay (of 2ns),
>> this will be configurable with the changes from [0]
>>
>> These are the dts changes which belong to my other series (in v2
>> these patches were part of the other series, upon request of the
>> net maintainers I have split the .dts changes into their own series
>> so
>> we are able to take both through different trees):
>> "[PATCH net-next v3 0/2] stmmac: dwmac-meson8b: configurable
>> RGMII TX delay": [0].
>> Thus this series depends on the ACK for the binding changes in the
>> other series!
>>
>> I based these changes on my other series "[PATCH v2 0/2] GXL and GXM
>> SCPI improvements": [3]
>>
>>
>> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-December/
>> 001834.html
>> [1] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/
>> 001607.html
>> [2] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/
>> 001707.html
>> [3] http://lists.infradead.org/pipermail/linux-amlogic/2016-December/
>> 001831.html
>>
>> Martin Blumenstingl (5):
>> ARM64: dts: meson-gx: move the MDIO node to meson-gx
>
> Sorry for the late reply, I've only been able to test this yesterday.
>
> With "snps,dwmac-mdio" provided in meson-gx.dtsi, the mdio_node is
> defined in stmmac_mdio_register and auto-detection of the PHY is
> disabled for all meson-gx boards.
>
> I wonder if this is desirable ? or maybe this something we could fix in
> stmmac ? (perform auto-detect the mdio bus is provided without a PHY)
actually it's only a "problem" when introducing support for new
devices. can you please forward this question to the stmmac
maintainers, as I think your idea of enabling auto-detection when
there are no children in the MDIO-bus makes sense
> Also, I think bisect is broken between patch 1 and patch 4: The PHY of
> some boards won't be detected between these patches. Should we squash
> them ?
what do you mean exactly? currently the TX-delay is hardcoded in
dwmac-meson8b. patch 4 moves the hardcoded value from the
dwmac-meson8b to the .dts-files.
unfortunately the corresponding dwmac-meson8b patch was not accepted
yet, so at the moment patch 4 should be a no-op.
>> ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY
>> ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
>> ARM64: dts: meson-gxbb-vega-s95: add reset for the ethernet PHY
>> ARM64: dts: amlogic: add the ethernet TX delay configuration
>>
>
> Last remark, about the use of ethernet-phy-idXXXX.XXXX in the odroid
> and the vega: Isn't it better to let phylib do the autodetection of the
> phy id ?
>
> If we want to specify the id in DT, we should probably add it for the
> Micrel PHY of the p200 as well, for consistency.
this seems to be a "best practice" when the PHY ID is known, see [0]
If you know the PHY ID of the Micrel PHY then please let me know, then
we can include this in the fix for the p20x boards
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 ++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 17
>> +++++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 17
>> +++++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 17
>> +++++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 2 ++
>> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 6 ------
>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 ++
>> arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 2 ++
>> 8 files changed, 63 insertions(+), 6 deletions(-)
>>
[0] http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/net/phy.txt#L22
^ permalink raw reply
* [PATCH v2 03/10] dt-bindings: sound: Add new reset compatible for sun4i-i2s
From: Thomas Petazzoni @ 2017-01-17 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117201016.A5fiHT0P@smtp2p.mail.yandex.net>
Hello,
On Wed, 18 Jan 2017 01:10:00 +0800, Icenowy Zheng wrote:
> > Add a new compatible for sun4i-i2s driver to handle some
> > SoCs that have a reset line that must be asserted/deasserted.
> >
> > This new compatible, "allwinner,sun6i-a31-i2s", requires two
> > properties:
> > - resets: phandle to the reset line
> > - reset-names: the name of the reset line ("rst").
> > Except these differences, the compatible is identical to previous one
> > which will not handle a reset line.
>
> But I think the IP block is identical, right?
>
> Should a new compatible be added only for reset-line?
Having a different compatible in this case allows to make some stricter
error checking: the driver can make sure that if the compatible string
is sun6i-a31-i2s there *IS* a reset line specified in the DT. Without a
separate compatible value, such a check is not possible, and the reset
line is just optional. This can lead to people being confused if they
forget to specify the reset line.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* usb: gadget: Kernel panic (NULL pointer dereference) when using fsl_udc2_core on i.MX31 PDK
From: Magnus Lilja @ 2017-01-17 21:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi
I tried the fsl_udc_core gadget driver on the i.MX31 PDK board and got a
kernel panic (NULL pointer dereference) when connecting the USB cable. I
had the g_serial module loaded as well.
The NULL pointer panic comes from gadget/udc/core.c
usb_gadget_giveback_request() which calls req->complete() and in some
cases req->complete is NULL.
Commit 304f7e5e1d08 ("usb: gadget: Refactor request completion") changed
fsl_udc2_core.c (and several other files) and in fsl_udc2_core.c a check
that req->complete is non-NULL was removed:
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -197,10 +197,8 @@ __acquires(ep->udc->lock)
ep->stopped = 1;
spin_unlock(&ep->udc->lock);
- /* complete() is from gadget layer,
- * eg fsg->bulk_in_complete() */
- if (req->req.complete)
- req->req.complete(&ep->ep, &req->req);
+
+ usb_gadget_giveback_request(&ep->ep, &req->req);
spin_lock(&ep->udc->lock);
ep->stopped = stopped;
If I re-introduce the check (either in fsl_udc_core.c or core.c) at
least USB gadget operation using g_serial seems to work just fine.
I don't know the logic in detail to understand whether this is a proper
fix or if there is some other more problem with the fls_udc_core driver.
Does anyone have input in this matter?
I can produce a proper patch that fixes this problem by re-introducing
the check (in either fsl_udc_core.c or core.c) if that is a proper
solution and I can also assist in testing other fixes to the problem.
Thanks, Magnus
^ permalink raw reply
* [PATCH 3/5] ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
From: Martin Blumenstingl @ 2017-01-17 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484680941.26620.28.camel@baylibre.com>
On Tue, Jan 17, 2017 at 8:22 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
>> This resets the ethernet PHY during boot to get the PHY into a
>> "clean"
>> state. While here also specify the phy-handle of the ethmac node to
>> make the PHY configuration similar to the one we have on GXL devices.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.co
>> m>
>> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15
>> +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> index 203be28..2abc553 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> @@ -134,10 +134,25 @@
>> pinctrl-names = "default";
>> };
>>
>> +&mdio0 {
>> + ethernet_phy0: ethernet-phy at 0 {
>> + compatible = "ethernet-phy-ieee802.3-c22";
>> + reg = <0>;
>
> Sorry for the late reply.
> I just tried on the p200 and this patch (serie) breaks the network on
> it. The PHY is not detected anymore.
>
> From the KSZ9031 Datasheet : "PHY Address 0h is supported as the unique
> PHY address only; it is not supported as the broadcast PHY address
> [...]"
>
> So we can't just use the broadcast address here:
> reg should be <3>.
OK, I'll fix that in a follow-up. as mentioned in the other thread:
can you confirm that the PHY ID is 0x00221620?
It seems that I also broke meson-gxbb-nexbox-a95x.dts with that series
(no idea why that slipped through): according to the photos from
Neil's wiki [0] this seems to use an IC+ 10/100 ethernet PHY (probably
an IP101A)
>> + };
>> +};
>> +
>> ðmac {
>> status = "okay";
>> pinctrl-0 = <ð_rgmii_pins>;
>> pinctrl-names = "default";
>> +
>> + phy-handle = <ðernet_phy0>;
>> +
>> + snps,reset-gpio = <&gpio GPIOZ_14 0>;
>> + snps,reset-delays-us = <0 10000 1000000>;
>> + snps,reset-active-low;
>> +
>> + phy-mode = "rgmii";
>
> We can't define this in p20x. actually the p201 uses an rmii.
> I have not idea about gpio reset, or the phy address for the p201.
>
> I suppose it would be better to move this to meson-gxbb_p200.dts
>
> I don't know if anybody has a p201, but until we can confirm a working
> Ethernet configuration, we should probably drop it for the p201
>
> Of course the problem was already there before this patch ...
indeed, that seems to be a problem.
the GXBB Nexbox A95x I mentioned above is based on the p201 board.
Amlogic's .dts also toggles GPIOZ_14 for it: [1]
chances are high that it also features an IP101A PHY (this is pure
speculation though).
I propose four patches to fix all this situation:
- add the GPIOZ_14 reset and an ethernet_phy0 (with reg = <0>) to
meson-gxbb-nexbox-a95x.dts
- add the ethernet_phy0 node with reg = <0> (and ideally I also want
to include the KSZ9031 PHY ID) to meson-gxbb-p200.dtsi along with
phy-mode = "rgmii"
- add the ethernet_phy0 node with reg = <0> (without any PHY ID as we
don't know which one is used) to meson-gxbb-p201.dtsi along with
phy-mode = "rgmii"
- remove "phy-mode" and ethernet_phy0 from meson-gxbb-p20x.dtsi and
add a comment that both, the RGMII and the RMII PHY have GPIOZ_14
connected to their reset line
does that make sense?
Regards,
Martin
[0] https://github.com/superna9999/linux/wiki/Boards#nexbox-a95x-s905
[1] https://github.com/khadas/linux/blob/Vim/arch/arm64/boot/dts/amlogic/gxbb_p201.dts#L186
^ permalink raw reply
* [PATCH] pci: mvebu: avoid changing the SCC bit in the link status register
From: Russell King @ 2017-01-17 21:40 UTC (permalink / raw)
To: linux-arm-kernel
It seems on later Armada 38x, the slot clock configuration bit is not
read-only, but can be written. This means that our RW1C protection
ends up clearing this bit when the link control register is written.
Adjust the mask so that we only avoid writing '1' bits to the RW1C
bits of this register (bits 15 and 14 of the link status) rather than
masking out all the status register bits.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/pci/host/pci-mvebu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 58f75c098b42..3ed4cb7501bd 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -827,10 +827,11 @@ static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
* If the mask is 0xffff0000, then we only want to write
* the link control register, rather than clearing the
* RW1C bits in the link status register. Mask out the
- * status register bits.
+ * RW1C bits.
*/
if (mask == 0xffff0000)
- value &= 0xffff;
+ value &= ~((PCI_EXP_LNKSTA_LABS |
+ PCI_EXP_LNKSTA_LBMS) << 16);
mvebu_writel(port, value, PCIE_CAP_PCIEXP + PCI_EXP_LNKCTL);
break;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 00/18] FSI device driver introduction
From: Christopher Bostic @ 2017-01-17 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117074243.GA20818@kroah.com>
On Tue, Jan 17, 2017 at 1:42 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Jan 16, 2017 at 03:22:48PM -0600, christopher.lee.bostic at gmail.com wrote:
>> From: Chris Bostic <cbostic@us.ibm.com>
>
> <snip>
>
> Only this, and patch 02/18 came through, did something get stuck on your
> end?
>
Hi Greg,
Yes had an issue with the server blocking send, investigating why.
> greg k-h
^ permalink raw reply
* [PATCH v3 00/18] FSI device driver introduction
From: christopher.lee.bostic at gmail.com @ 2017-01-17 22:02 UTC (permalink / raw)
To: linux-arm-kernel
From: Chris Bostic <cbostic@us.ibm.com>
Introduction of the IBM 'Flexible Support Interface' (FSI) bus device
driver. FSI is a high fan out serial bus consisting of a clock and a serial
data line capable of running at speeds up to 166 MHz.
This set provides the basic framework to add FSI extensions to the
Linux bus and device models. Master specific implementations are
defined to utilize the core FSI function.
In Linux, we have a core FSI "bus type", along with drivers for FSI
masters and engines.
The FSI master drivers expose a read/write interface to the bus address
space. The master drivers are under drivers/fsi/fsi-master-*.c.
The core handles probing and discovery of slaves and slave
engines, using those read/write interfaces. It is responsible for
creating the endpoint Linux devices corresponding to the discovered
engines on each slave.
Slave engines are identified by an 'engine' type, and an optional
version. Engine, a.k.a. client, drivers are matched and bound to these
engines during discovery.
This patch set does not include extended FSI function such as:
* Hub master support
* Cascaded master support
* Application layer hot plug notification
* Application layer FSI bus status interface
Common FSI terminology:
* Master
Controller of the FSI bus. Only the master is allowed to control the
clock line and is the initiator of all transactions on a bus.
* Slave
The receiver or target of a master initiated transaction. The slave
cannot initiate communications on a bus and must respond to any
master requests for data.
* CFAM
Stands for Common Field replaceable unit Access Macro. A CFAM is an
ASIC residing in any device requiring FSI communications. CFAMs
consist of an array of hardware 'engines' used for various purposes.
I2C masters, UARTs, General Purpose IO hardware are common types of
these engines.
* Configuration Space / Table
A table contained at the beginning of each CFAM address space.
This table lists information such as the CFAM's ID, which engine types
and versions it has available, as well as its addressing range.
* FSI Engine driver
A device driver that registers with the FSI core so that it can access
devices it owns on an FSI bus.
Chris Bostic (8):
drivers/fsi: Kick off master scan via sysfs
drivers/fsi: Set up links for slave communication
drivers/fsi: Set slave SMODE to init communication
drivers/fsi: Remove all scanned devices during master unregister
drivers/fsi: Add FSI bus documentation
drivers/fsi: Add documentation for GPIO based FSI master
drivers/fsi: Document FSI master sysfs files in ABI
drivers/fsi: Add GPIO based FSI master
Jeremy Kerr (10):
drivers/fsi: Add empty fsi bus definitions
drivers/fsi: Add device & driver definitions
drivers/fsi: add driver to device matches
drivers/fsi: Add fsi master definition
drivers/fsi: Add slave definition
drivers/fsi: Add empty master scan
drivers/fsi: Add FSI crc calculators to library
drivers/fsi: Implement slave initialisation
drivers/fsi: scan slaves & register devices
drivers/fsi: Add device read/write/peek functions
Changes for v3:
- Patch set contained an invalid 18/18 test patch not
meant for community review, corrected.
Changes for v2:
- Change from atomic global for master number to ida simple
interface.
- Add valid pointer checks on register and unregister utils.
- Move CRC calculation utilities out of driver to lib path.
- Clean up white space issues.
- Remove added list management of master devices and use
instead the device_for_each_child method available in the
bus.
- Add new patch to document FSI bus functionality.
- Add new patch documenting FSI gpio master.
- Rearrage patch set to have documentation earlier than code
implementing it.
- Document all comptible strings used in device tree bindings.
- Elaborate documentation definition of FSI GPIO master.
- Describe in more detail what each GPIO FSI master pin is for.
- Re-order compatible strings in example binding so that most
specific device comes first.
- Indicate proper activation order of all FSI GPIO master pins.
- Fix an unmatched '>' bracket in the example for binding.
- Bracket each element of the example bindings individually.
- Add new patch documenting sysfs-bus-fsi attributes.
- Merge FSI GPIO master init into probe function.
- Set pin initial values at time of pin request.
- Assign value of master->master.dev at probe time.
- Use get_optional interfac for all optional GPIO pins.
Documentation/ABI/testing/sysfs-bus-fsi | 6 +
.../devicetree/bindings/fsi/fsi-master-gpio.txt | 71 +++
Documentation/devicetree/bindings/fsi/fsi.txt | 54 +++
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/fsi/Kconfig | 23 +
drivers/fsi/Makefile | 3 +
drivers/fsi/fsi-core.c | 494 +++++++++++++++++++
drivers/fsi/fsi-master-gpio.c | 530 +++++++++++++++++++++
drivers/fsi/fsi-master.h | 39 ++
include/linux/crc-fsi.h | 29 ++
include/linux/fsi.h | 60 +++
lib/Makefile | 1 +
lib/crc-fsi.c | 39 ++
14 files changed, 1352 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-fsi
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt
create mode 100644 drivers/fsi/Kconfig
create mode 100644 drivers/fsi/Makefile
create mode 100644 drivers/fsi/fsi-core.c
create mode 100644 drivers/fsi/fsi-master-gpio.c
create mode 100644 drivers/fsi/fsi-master.h
create mode 100644 include/linux/crc-fsi.h
create mode 100644 include/linux/fsi.h
create mode 100644 lib/crc-fsi.c
--
1.8.2.2
^ permalink raw reply
* [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names
From: Shuah Khan @ 2017-01-17 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ziirmgz1.fsf@linux.intel.com>
On 01/16/2017 03:33 AM, Felipe Balbi wrote:
>
> Hi,
>
> Shuah Khan <shuahkh@osg.samsung.com> writes:
>> Change goto labels to meaningful names from a series of errNs.
>>
>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>
> doesn't apply to testing/next, please rebase.
>
Hi Felipe,
This patch is dependent on the
usb: dwc3: exynos fix axius clock error path to do cleanup
https://lkml.org/lkml/2017/1/10/1081
The above made it into usb-linus. It will apply to usb-next
or usb-testing after it gets merged. I can resend it after
the dependent patch makes it into the next rc release.
thanks,
-- Shuah
^ permalink raw reply
* [PATCH v3 2/3] arm64: dts: juno: fix CoreSight support for Juno r1/r2 variants
From: Olof Johansson @ 2017-01-17 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae9edbff-b315-7709-84e7-d72bc6394a4e@arm.com>
On Tue, Jan 17, 2017 at 3:37 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 17/01/17 06:58, Olof Johansson wrote:
>> Hi,
>>
>> On Thu, Jan 12, 2017 at 7:20 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> From: Mike Leach <mike.leach@linaro.org>
>>>
>>> The CoreSight support added for Juno is valid for only Juno r0.
>>> The Juno r1 and r2 variants have additional components and alternative
>>> connection routes between trace source and sinks.
>>>
>>> This patch builds on top of the existing r0 support and extends it to
>>> Juno r1/r2 variants.
>>>
>>> Signed-off-by: Mike Leach <mike.leach@linaro.org>
>>> [sudeep.holla at arm.com: minor changelog update and reorganising the common
>>> coresight components back into juno-base.dtsi to avoid duplication]
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 102 ++++++++++++++++++++++++++++++
>>> arch/arm64/boot/dts/arm/juno-r1.dts | 9 +++
>>> arch/arm64/boot/dts/arm/juno-r2.dts | 9 +++
>>> 3 files changed, 120 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>>> new file mode 100644
>>> index 000000000000..89fcef366ff9
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>>> @@ -0,0 +1,102 @@
>>> + csys1_funnel at 20130000 {
>>> + compatible = "arm,coresight-funnel", "arm,primecell";
>>> + reg = <0 0x20130000 0 0x1000>;
>>> +
>>> + clocks = <&soc_smc50mhz>;
>>> + clock-names = "apb_pclk";
>>> + power-domains = <&scpi_devpd 0>;
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + /* input port */
>>> + port at 0 {
>>> + reg = <0>;
>>> + csys1_funnel_out_port: endpoint {
>>> + remote-endpoint =
>>> + <&etf1_in_port>;
>>> + };
>>> + };
>>> +
>>> + /* output port */
>>> + port at 1 {
>>> + reg = <0>;
>>> + csys1_funnel_in_port0: endpoint {
>>> + slave-mode;
>>> + };
>>> + };
>>> +
>>> + };
>>> + };
>>> +
>>> + etf1 at 20140000 {
>>
>> The concept behind device-tree is that you name the nodes based on the
>> type of device they are. "i2c", "ethernet", etc. Not "eth0", "i2c3",
>> and so on.
>>
>> So, this should probably be something else than "etf1", and the
>> etf->etf0 rename you did somewhere else shouldn't be made either.
>>
>
> Agreed, will fix it. Sorry for not noticing that before. I somehow
> always confused them to be labels rather that node names and even missed
> to observe that when I changed for R0.
>
> [...]
>
>>> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
>>> index eec37feee8fc..d4b85d9d343e 100644
>>> --- a/arch/arm64/boot/dts/arm/juno-r1.dts
>>> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
>>> @@ -178,6 +178,7 @@
>>> };
>>>
>>> #include "juno-base.dtsi"
>>> + #include "juno-cs-r1r2.dtsi"
>>
>> Please don't nest dtsi inside a structure like this. We normally let
>> them stand by themselves at the top of the file instead.
>>
>> (yes, please fix for juno-base too).
>
> Agreed and fixed locally, will post it as part of v4.
Both look reasonable here on repost!
-Olof
^ permalink raw reply
* [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems
From: Stefano Stabellini @ 2017-01-17 22:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I would like to discuss with ARM64 and ACPI Linux maintainers the best
way to complete ACPI support in Linux for Dom0 on ARM64.
As a reminder, Xen can only parse static ACPI tables. It doesn't have a
bytecode interpreter. Xen maps all ACPI tables to Dom0, which parses
them as it does on native. Device memory is mapped in stage-2 by Xen
upon Dom0 request: a small driver under drivers/xen registers for
BUS_NOTIFY_ADD_DEVICE events, then calls xen_map_device_mmio, which
issues XENMEM_add_to_physmap_range hypercalls to Xen that creates the
appropriate stage-2 mappings.
This approach works well, but it breaks in few interesting cases.
Specifically, anything that requires a device memory mapping but it is
not a device, doesn't generate a BUS_NOTIFY_ADD_DEVICE event, thus, no
hypercalls to Xen are made. Examples are: ACPI OperationRegion (1), ECAM
(2), other memory regions described in static tables such as BERT (3).
What is the best way to map these regions in Dom0? I am going to
detail a few options that have been proposed and evaluated so far.
(2) and (3), being described by static tables, could be parsed by Xen
and mapped beforehand. However, this approach wouldn't work for (1).
Additionally, Xen and Linux versions can mix and match, so it is
possible, even likely, to run an old Xen and a new Dom0 on a new
platform. Xen might not know about a new ACPI table, while Linux might.
In this scenario, Xen wouldn't be able to map the region described in
the new table beforehand, but Linux would still try to access it. I
imagine that this problem could be work-arounded by blacklisting any
unknown static tables in Xen, but it seems suboptimal. (By blacklisting,
I mean removing them before starting Dom0.)
For this reason, and to use the same approach for (1), (2) and (3), it
looks like the best solution is for Dom0 to request the stage-2
mappings to Xen. If we go down this route, what is the best way to do
it?
a) One option is to provide a Xen specific implementation of
acpi_os_ioremap in Linux. I think this is the cleanest approach, but
unfortunately, it doesn't cover cases where ioremap is used directly. (2)
is one of such cases, see
arch/arm64/kernel/pci.c:pci_acpi_setup_ecam_mapping and
drivers/pci/ecam.c:pci_ecam_create. (3) is another one of these cases,
see drivers/acpi/apei/bert.c:bert_init.
b) Otherwise, we could write an alternative implementation of ioremap
on arm64. The Xen specific ioremap would request a stage-2 mapping
first, then create the stage-1 mapping as usual. However, this means
issuing an hypercall for every ioremap call.
c) Finally, a third option is to create the stage-2 mappings seamlessly
in Xen upon Dom0 memory faults. Keeping in mind that SMMU and guest
pagetables are shared in the Xen hypervisor, this approach does not work
if one of the pages that need a stage-2 mapping is used as DMA target
before Dom0 accesses it. No SMMU mappings would be available for the
page yet, so the DMA transaction would fail. After Dom0 touches the
page, the DMA transaction would succeed. I don't know how likely is this
scenario to happen, but it seems fragile to rely on it.
For these reasons, I think that the best option might be b).
Do you agree? Did I miss anything? Do you have other suggestions?
Many thanks,
Stefano
References:
https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg01693.html
https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg02425.html
https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg02531.html
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Bjorn Helgaas @ 2017-01-17 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117210258.GH27312@n2100.armlinux.org.uk>
[+cc David]
On Tue, Jan 17, 2017 at 09:02:58PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 17, 2017 at 07:34:14PM +0000, Russell King - ARM Linux wrote:
> > Uwe, can you try:
> >
> > setpci -s <whatever-the-id-of-the-root-is-it's-blanked-out-in-the-above> \
> > 0x50.w=0x60
> >
> > and see whether it remains alive (you can check by reading the root
> > register 0x52.w - bit 12 should be set once bit 11 clears again.
>
> For reference, this I got wrong...
>
> 0xf1041a04 bit 0 indicates link status (0 = link up, 1 = link down).
>
> > If that's successful, maybe setting the common clock bit on the PCIe
> > device is what's causing the problem, in which case:
> >
> > setpci -s 02:00.0 0x80.w=0x40
> > setpci -s <whatever-the-id-of-the-root-is-it's-blanked-out-in-the-above> \
> > 0x50.w=0x60
>
> Having worked with Uwe over IRC, it seems that any request to retrain
> causes the link to go down, either with or without the common clock bit
> set:
>
> # setpci -s 2.0 0x50.w=0x60
> # setpci -s 2.0 0x52.w
> 0011
> # memtool md 0xf1041a04+4
> f1041a04: 00010201
> ... reboot ...
> # setpci -s 2.0 0x50.w=0x20
> # memtool md 0xf1041a04+4
> f1041a04: 00010201
>
> which doesn't point towards ASPM itself, but the problem is caused by
> a side effect of ASPM's setup code which always triggers a retrain.
>
> Bit 5 in that register is documented (at least in the Armada 370 docs
> and Armada XP docs I have) as:
>
> 5 RetrnLnk RW Retrain Link
> 0x0 This bit forces the device to initiate link retraining.
> Always returns 0 when read.
> NOTE: If configured as an Endpoint, this field is
> reserved and has no effect.
>
> Bjorn, are you aware of similar situations where a request for the PCIe
> link to be retrained causes it to fail?
The only one that comes to mind is this patch from David (CC'd) that
avoids ASPM-related retrains when we know the link doesn't support ASPM:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e53f9a28bee3
Side note: it looks like we don't use the recommended retrain
algorithm in the implementation note about avoiding race conditions in
PCIe r3.0, sec 7.8.7.
^ permalink raw reply
* [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Jerome Brunet @ 2017-01-17 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCDvtufXUxe+cRCzOKFtbOqS-xEr0Vp=_0S4Pn+sTPHOmg@mail.gmail.com>
On Tue, 2017-01-17 at 22:09 +0100, Martin Blumenstingl wrote:
> On Tue, Jan 17, 2017 at 8:23 PM, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
> > >
> > > This partially fixes the 1000Mbit/s ethernet TX throughput issues
> > > (on
> > > networks which are not affected by the EEE problem, as reported
> > > here:
> > > [1]).
> > > The actual problem for the TX throughput issues was that the TX
> > > delay
> > > was applied twice:
> > > - once "accidentally" by the PHY (this was fixed with [2])
> > > - once by the MAC because there was a hardcoded TX delay (of
> > > 2ns),
> > > ? this will be configurable with the changes from [0]
> > >
> > > These are the dts changes which belong to my other series (in v2
> > > these patches were part of the other series, upon request of the
> > > net maintainers I have split the .dts changes into their own
> > > series
> > > so
> > > we are able to take both through different trees):
> > > "[PATCH net-next v3 0/2] stmmac: dwmac-meson8b: configurable
> > > RGMII TX delay": [0].
> > > Thus this series depends on the ACK for the binding changes in
> > > the
> > > other series!
> > >
> > > I based these changes on my other series "[PATCH v2 0/2] GXL and
> > > GXM
> > > SCPI improvements": [3]
> > >
> > >
> > > [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-Decem
> > > ber/
> > > 001834.html
> > > [1] http://lists.infradead.org/pipermail/linux-amlogic/2016-Novem
> > > ber/
> > > 001607.html
> > > [2] http://lists.infradead.org/pipermail/linux-amlogic/2016-Novem
> > > ber/
> > > 001707.html
> > > [3] http://lists.infradead.org/pipermail/linux-amlogic/2016-Decem
> > > ber/
> > > 001831.html
> > >
> > > Martin Blumenstingl (5):
> > > ? ARM64: dts: meson-gx: move the MDIO node to meson-gx
> >
> > Sorry for the late reply, I've only been able to test this
> > yesterday.
> >
> > With "snps,dwmac-mdio" provided in meson-gx.dtsi, the mdio_node is
> > defined in stmmac_mdio_register and auto-detection of the PHY is
> > disabled for all meson-gx boards.
> >
> > I wonder if this is desirable ? or maybe this something we could
> > fix in
> > stmmac ? (perform auto-detect the mdio bus is provided without a
> > PHY)
> actually it's only a "problem" when introducing support for new
> devices. can you please forward this question to the stmmac
> maintainers, as I think your idea of enabling auto-detection when
> there are no children in the MDIO-bus makes sense
That's one way to address the issue, sure. I just wonder if we should
keep the declaration of the mdio bus with "snps,dwmac-mdio" in the dts
using it, with the phy explicitly declared ...
Otherwise, we have to make clear that you must always explicitly
declare your PHY in amlogic's dts so there is no surprise.
As you mentioned, we missed the gxbb-nexbox-a95. No phy declared in
that dts, but it still get the mdio bus from meson-gx.dtsi. So as of
"ARM64: dts: meson-gx: move the MDIO node to meson-gx" the PHY is not
detected on this board.
>
> >
> > Also, I think bisect is broken between patch 1 and patch 4: The PHY
> > of
> > some boards won't be detected between these patches. Should we
> > squash
> > them ?
> what do you mean exactly? currently the TX-delay is hardcoded in
> dwmac-meson8b. patch 4 moves the hardcoded value from the
> dwmac-meson8b to the .dts-files.
> unfortunately the corresponding dwmac-meson8b patch was not accepted
> yet, so at the moment patch 4 should be a no-op.
Nothing related to the tx-delay ... I'm all for it ;) Thx for your work
by the way
What I meant is that as of "ARM64: dts: meson-gx: move the MDIO node to
meson-gx" all boards not declaring the PHY explicitly can't detect it
anymore. that's more or less all gxbb boards
With "ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY"
the odroid gets fixed ... but the p200 and vega-s95 are still broken?
With the next patch, the p200 is/should have been fixed, then the vega-
s95 is fixed?
In the end the gxbb-nexbox is still broken. To be honest I did not
verify if there any other board in that case.
My point is that I think the declaration of the mdio bus in meson-
gx.dtsi and the declaration of each PHY in the board dtss should be
done in single commit to avoid having a (very) short part of the
history with regressions
>
> >
> > >
> > > ? ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY
> > > ? ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
> > > ? ARM64: dts: meson-gxbb-vega-s95: add reset for the ethernet PHY
> > > ? ARM64: dts: amlogic: add the ethernet TX delay configuration
> > >
> >
> > Last remark, about the use of ethernet-phy-idXXXX.XXXX in the
> > odroid
> > and the vega: Isn't it better to let phylib do the autodetection of
> > the
> > phy id ?
> >
> > If we want to specify the id in DT, we should probably add it for
> > the
> > Micrel PHY of the p200 as well, for consistency.
> this seems to be a "best practice" when the PHY ID is known, see [0]
> If you know the PHY ID of the Micrel PHY then please let me know,
> then
> we can include this in the fix for the p20x boards
OK
>
> >
> > >
> > > ?arch/arm64/boot/dts/amlogic/meson-gx.dtsi????????????|??6 ++++++
> > > ?arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts??| 17
> > > +++++++++++++++++
> > > ?arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi?????| 17
> > > +++++++++++++++++
> > > ?arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 17
> > > +++++++++++++++++
> > > ?arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts |??2 ++
> > > ?arch/arm64/boot/dts/amlogic/meson-gxl.dtsi???????????|??6 ------
> > > ?arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts??|??2 ++
> > > ?arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts??|??2 ++
> > > ?8 files changed, 63 insertions(+), 6 deletions(-)
> > >
>
> [0] http://lxr.free-electrons.com/source/Documentation/devicetree/bin
> dings/net/phy.txt#L22
^ permalink raw reply
* [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Martin Blumenstingl @ 2017-01-17 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484691981.26620.55.camel@baylibre.com>
On Tue, Jan 17, 2017 at 11:26 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Tue, 2017-01-17 at 22:09 +0100, Martin Blumenstingl wrote:
>> On Tue, Jan 17, 2017 at 8:23 PM, Jerome Brunet <jbrunet@baylibre.com>
>> wrote:
>> >
>> > On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
>> > >
>> > > This partially fixes the 1000Mbit/s ethernet TX throughput issues
>> > > (on
>> > > networks which are not affected by the EEE problem, as reported
>> > > here:
>> > > [1]).
>> > > The actual problem for the TX throughput issues was that the TX
>> > > delay
>> > > was applied twice:
>> > > - once "accidentally" by the PHY (this was fixed with [2])
>> > > - once by the MAC because there was a hardcoded TX delay (of
>> > > 2ns),
>> > > this will be configurable with the changes from [0]
>> > >
>> > > These are the dts changes which belong to my other series (in v2
>> > > these patches were part of the other series, upon request of the
>> > > net maintainers I have split the .dts changes into their own
>> > > series
>> > > so
>> > > we are able to take both through different trees):
>> > > "[PATCH net-next v3 0/2] stmmac: dwmac-meson8b: configurable
>> > > RGMII TX delay": [0].
>> > > Thus this series depends on the ACK for the binding changes in
>> > > the
>> > > other series!
>> > >
>> > > I based these changes on my other series "[PATCH v2 0/2] GXL and
>> > > GXM
>> > > SCPI improvements": [3]
>> > >
>> > >
>> > > [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-Decem
>> > > ber/
>> > > 001834.html
>> > > [1] http://lists.infradead.org/pipermail/linux-amlogic/2016-Novem
>> > > ber/
>> > > 001607.html
>> > > [2] http://lists.infradead.org/pipermail/linux-amlogic/2016-Novem
>> > > ber/
>> > > 001707.html
>> > > [3] http://lists.infradead.org/pipermail/linux-amlogic/2016-Decem
>> > > ber/
>> > > 001831.html
>> > >
>> > > Martin Blumenstingl (5):
>> > > ARM64: dts: meson-gx: move the MDIO node to meson-gx
>> >
>> > Sorry for the late reply, I've only been able to test this
>> > yesterday.
>> >
>> > With "snps,dwmac-mdio" provided in meson-gx.dtsi, the mdio_node is
>> > defined in stmmac_mdio_register and auto-detection of the PHY is
>> > disabled for all meson-gx boards.
>> >
>> > I wonder if this is desirable ? or maybe this something we could
>> > fix in
>> > stmmac ? (perform auto-detect the mdio bus is provided without a
>> > PHY)
>> actually it's only a "problem" when introducing support for new
>> devices. can you please forward this question to the stmmac
>> maintainers, as I think your idea of enabling auto-detection when
>> there are no children in the MDIO-bus makes sense
>
> That's one way to address the issue, sure. I just wonder if we should
> keep the declaration of the mdio bus with "snps,dwmac-mdio" in the dts
> using it, with the phy explicitly declared ...
>
> Otherwise, we have to make clear that you must always explicitly
> declare your PHY in amlogic's dts so there is no surprise.
>
> As you mentioned, we missed the gxbb-nexbox-a95. No phy declared in
> that dts, but it still get the mdio bus from meson-gx.dtsi. So as of
> "ARM64: dts: meson-gx: move the MDIO node to meson-gx" the PHY is not
> detected on this board.
indeed, however I'd like to point out that this was already a
restriction for GXL and GXM based boards before.
I'm open to any solution though as breaking things is always bad
>>
>> >
>> > Also, I think bisect is broken between patch 1 and patch 4: The PHY
>> > of
>> > some boards won't be detected between these patches. Should we
>> > squash
>> > them ?
>> what do you mean exactly? currently the TX-delay is hardcoded in
>> dwmac-meson8b. patch 4 moves the hardcoded value from the
>> dwmac-meson8b to the .dts-files.
>> unfortunately the corresponding dwmac-meson8b patch was not accepted
>> yet, so at the moment patch 4 should be a no-op.
>
> Nothing related to the tx-delay ... I'm all for it ;) Thx for your work
> by the way
>
> What I meant is that as of "ARM64: dts: meson-gx: move the MDIO node to
> meson-gx" all boards not declaring the PHY explicitly can't detect it
> anymore. that's more or less all gxbb boards
>
> With "ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY"
> the odroid gets fixed ... but the p200 and vega-s95 are still broken
>
> With the next patch, the p200 is/should have been fixed, then the vega-
> s95 is fixed
>
> In the end the gxbb-nexbox is still broken. To be honest I did not
> verify if there any other board in that case.
>
> My point is that I think the declaration of the mdio bus in meson-
> gx.dtsi and the declaration of each PHY in the board dtss should be
> done in single commit to avoid having a (very) short part of the
> history with regressions
now I see the dependency, thanks for pointing this out!
Depending on the decision for above problem (MDIO-bus in meson-gx.dtsi
or not) I can provide a v2 with all issues addressed.
>>
>> >
>> > >
>> > > ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY
>> > > ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
>> > > ARM64: dts: meson-gxbb-vega-s95: add reset for the ethernet PHY
>> > > ARM64: dts: amlogic: add the ethernet TX delay configuration
>> > >
>> >
>> > Last remark, about the use of ethernet-phy-idXXXX.XXXX in the
>> > odroid
>> > and the vega: Isn't it better to let phylib do the autodetection of
>> > the
>> > phy id ?
>> >
>> > If we want to specify the id in DT, we should probably add it for
>> > the
>> > Micrel PHY of the p200 as well, for consistency.
>> this seems to be a "best practice" when the PHY ID is known, see [0]
>> If you know the PHY ID of the Micrel PHY then please let me know,
>> then
>> we can include this in the fix for the p20x boards
>
> OK
>
>>
>> >
>> > >
>> > > arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 ++++++
>> > > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 17
>> > > +++++++++++++++++
>> > > arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 17
>> > > +++++++++++++++++
>> > > arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 17
>> > > +++++++++++++++++
>> > > arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 2 ++
>> > > arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 6 ------
>> > > arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 ++
>> > > arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 2 ++
>> > > 8 files changed, 63 insertions(+), 6 deletions(-)
>> > >
>>
>> [0] http://lxr.free-electrons.com/source/Documentation/devicetree/bin
>> dings/net/phy.txt#L22
^ permalink raw reply
* [GIT PULL] ARM: aspeed: defconfig for 4.11
From: Joel Stanley @ 2017-01-17 22:46 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd and Olof,
Please pull the Aspeed defconfig tree for 4.11.
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
tags/aspeed-4.11-defconfig
for you to fetch changes up to 0e81eb77f5f81be9a3fd4a080eba9abfb6e54a3a:
ARM: configs: Update Aspeed with new drivers (2017-01-10 23:01:35 +1100)
----------------------------------------------------------------
Aspeed defconfig updates for 4.11
Just the one commit that updates our defconfigs with network (ftgmac100
and ncsi), bt ipmi, gpio and ncsi.
ARM: configs: Update Aspeed with new drivers
----------------------------------------------------------------
Joel Stanley (1):
ARM: configs: Update Aspeed with new drivers
arch/arm/configs/aspeed_g4_defconfig | 38 ++++++++++++++++++++++++++++++++----
arch/arm/configs/aspeed_g5_defconfig | 38 +++++++++++++++++++++++++++++++++++-
2 files changed, 71 insertions(+), 5 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: aspeed: soc for 4.11
From: Joel Stanley @ 2017-01-17 22:48 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd and Olof,
Please pull the Aspeed soc tree for 4.11.
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
tags/aspeed-4.11-soc
for you to fetch changes up to 43c08c1c1ae576a1517b31c9e3b615104c5ff131:
ARM: aspeed: Select pinctrl drivers (2017-01-10 22:36:06 +1100)
----------------------------------------------------------------
Apseed SoC updates for 4.11
One commit that selects the newly upstreamed pinctrl driver for all
SoCs.
ARM: aspeed: Select pinctrl drivers
----------------------------------------------------------------
Andrew Jeffery (1):
ARM: aspeed: Select pinctrl drivers
arch/arm/mach-aspeed/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2017-01-17 22:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/mach-ux500/platsmp.c
between commit:
6996cbb23721 ("ARM: 8641/1: treewide: Replace uses of virt_to_phys with __pa_symbol")
from the arm tree and commit:
9e634cae7256 ("ARM: ux500: simplify secondary boot")
from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/mach-ux500/platsmp.c
index 8c8f26389067,e0ee139fdebf..000000000000
--- a/arch/arm/mach-ux500/platsmp.c
+++ b/arch/arm/mach-ux500/platsmp.c
@@@ -92,7 -73,19 +73,19 @@@ static void __init ux500_smp_prepare_cp
static int ux500_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
- wakeup_secondary();
+ /*
+ * write the address of secondary startup into the backup ram register
+ * at offset 0x1FF4, then write the magic number 0xA1FEED01 to the
+ * backup ram register at offset 0x1FF0, which is what boot rom code
+ * is waiting for. This will wake up the secondary core from WFE.
+ */
- writel(virt_to_phys(secondary_startup),
++ writel(__pa_symbol(secondary_startup),
+ backupram + UX500_CPU1_JUMPADDR_OFFSET);
+ writel(0xA1FEED01,
+ backupram + UX500_CPU1_WAKEMAGIC_OFFSET);
+
+ /* make sure write buffer is drained */
+ mb();
arch_send_wakeup_ipi_mask(cpumask_of(cpu));
return 0;
}
^ permalink raw reply
* [GIT PULL] ARM: aspeed: devicetree for 4.11
From: Joel Stanley @ 2017-01-17 22:50 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd and Olof,
Please pull the Aspeed devicetree ...tree for 4.11.
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
tags/aspeed-4.11-devicetree
for you to fetch changes up to 8f9bafbb92c0308cf8d33536803c822e14bed4d7:
ARM: dts: aspeed: Add Romulus BMC platform (2017-01-10 21:55:46 +1100)
----------------------------------------------------------------
Aspeed devicetree updates for 4.11
This introduces the first OpenPower Power9 BMC system, Romulus. Romulus is
based on the ast2500 SoC from Aspeed.
These commits also add newly upstreamed drivers to the Palmetto BMC and ast2500
eval board. We now have working network, ipmi bt, gpio and pinmux on
all platforms.
ARM: dts: aspeed: Add Romulus BMC platform
ARM: dts: aspeed: Add ftgmac100 to g4 and g5 platforms
ARM: dts: aspeed: Correct palmetto device tree
ARM: dts: aspeed: Reserve framebuffer memory
ARM: dts: aspeed-g5: Add gpio controller to devicetree
ARM: dts: aspeed-g5: Add syscon and pin controller nodes
ARM: dts: aspeed-g5: Add LPC Controller node
ARM: dts: aspeed-g5: Add SoC Display Controller node
ARM: dts: aspeed-g4: Add gpio controller to devicetree
ARM: dts: aspeed-g4: Add syscon and pin controller nodes
----------------------------------------------------------------
Andrew Jeffery (6):
ARM: dts: aspeed-g4: Add syscon and pin controller nodes
ARM: dts: aspeed-g4: Add gpio controller to devicetree
ARM: dts: aspeed-g5: Add SoC Display Controller node
ARM: dts: aspeed-g5: Add LPC Controller node
ARM: dts: aspeed-g5: Add syscon and pin controller nodes
ARM: dts: aspeed-g5: Add gpio controller to devicetree
Cyril Bur (2):
ARM: dts: aspeed: Reserve framebuffer memory
ARM: dts: aspeed: Correct palmetto device tree
Joel Stanley (2):
ARM: dts: aspeed: Add ftgmac100 to g4 and g5 platforms
ARM: dts: aspeed: Add Romulus BMC platform
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/aspeed-ast2500-evb.dts | 14 +
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 24 +-
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 45 ++
arch/arm/boot/dts/aspeed-g4.dtsi | 776 +++++++++++++++++++++++
arch/arm/boot/dts/aspeed-g5.dtsi | 879 ++++++++++++++++++++++++++
6 files changed, 1737 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox