* [PATCH] arm64: tlb: Fix TLBI RANGE operand
From: Gavin Shan @ 2024-04-03 6:49 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, catalin.marinas, will, akpm, maz, apopple,
mark.rutland, ryan.roberts, rananta, yangyicong, v-songbaohua,
yezhenyu2, yihyu, shan.gavin
KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty
bitmap is collected by VMM and the corresponding PTEs need to be
write-protected again. Unfortunately, the operand passed to the TLBI
RANGE instruction isn't correctly sorted out by commit d1d3aa98b1d4
("arm64: tlb: Use the TLBI RANGE feature in arm64"). It leads to
crash on the destination VM after live migration because some of the
dirty pages are missed.
For example, I have a VM where 8GB memory is assigned, starting from
0x40000000 (1GB). Note that the host has 4KB as the base page size.
All TLBs for VM can be covered by one TLBI RANGE operation. However,
I receives 0xffff708000040000 as the operand, which is wrong and the
correct one should be 0x00007f8000040000. From the wrong operand, we
have 3 and 1 for SCALE (bits[45:44) and NUM (bits943:39], only 1GB
instead of 8GB memory is covered.
Fix the macro __TLBI_RANGE_NUM() so that the correct NUM and TLBI
RANGE operand are provided.
Fixes: d1d3aa98b1d4 ("arm64: tlb: Use the TLBI RANGE feature in arm64")
Cc: stable@kernel.org # v5.10+
Reported-by: Yihuang Yu <yihyu@redhat.com>
Signed-off-by: Gavin Shan <gshan@redhat.com>
---
arch/arm64/include/asm/tlbflush.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 3b0e8248e1a4..07c4fb4b82b4 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -166,7 +166,7 @@ static inline unsigned long get_trans_granule(void)
*/
#define TLBI_RANGE_MASK GENMASK_ULL(4, 0)
#define __TLBI_RANGE_NUM(pages, scale) \
- ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1)
+ ((((pages) >> (5 * (scale) + 1)) - 1) & TLBI_RANGE_MASK)
/*
* TLB Invalidation
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4] perf/marvell: Marvell PEM performance monitor support
From: Gowthami Thiagarajan @ 2024-04-03 5:41 UTC (permalink / raw)
To: will, mark.rutland, linux-arm-kernel, linux-kernel
Cc: sgoutham, gcherian, lcherian, Gowthami Thiagarajan
PCI Express Interface PMU includes various performance counters
to monitor the data that is transmitted over the PCIe link. The
counters track various inbound and outbound transactions which
includes separate counters for posted/non-posted/completion TLPs.
Also, inbound and outbound memory read requests along with their
latencies can also be monitored. Address Translation Services(ATS)events
such as ATS Translation, ATS Page Request, ATS Invalidation along with
their corresponding latencies are also supported.
The performance counters are 64 bits wide.
For instance,
perf stat -e ib_tlp_pr <workload>
tracks the inbound posted TLPs for the workload.
Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com>
---
MAINTAINERS | 6 +
drivers/perf/Kconfig | 7 +
drivers/perf/Makefile | 1 +
drivers/perf/marvell_pem_pmu.c | 425 +++++++++++++++++++++++++++++++++
include/linux/cpuhotplug.h | 1 +
5 files changed, 440 insertions(+)
create mode 100644 drivers/perf/marvell_pem_pmu.c
diff --git a/MAINTAINERS b/MAINTAINERS
index dd5de540ec0b..50c11e128a98 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12759,6 +12759,12 @@ S: Supported
F: Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
F: drivers/net/ethernet/marvell/octeontx2/af/
+MARVELL PEM PMU DRIVER
+M: Linu Cherian <lcherian@marvell.com>
+M: Gowthami Thiagarajan <gthiagarajan@marvell.com>
+S: Supported
+F: drivers/perf/marvell_pem_pmu.c
+
MARVELL PRESTERA ETHERNET SWITCH DRIVER
M: Taras Chornyi <taras.chornyi@plvision.eu>
S: Supported
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 273d67ecf6d2..12ac8409263a 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -234,4 +234,11 @@ config CXL_PMU
If unsure say 'm'.
+config MARVELL_PEM_PMU
+ tristate "MARVELL PEM PMU Support"
+ depends on ARCH_THUNDER || (COMPILE_TEST && 64BIT)
+ help
+ Enable support for PCIe Interface performance monitoring
+ on Marvell platform.
+
endmenu
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 16b3ec4db916..db3c473cc5c7 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
obj-$(CONFIG_MARVELL_CN10K_TAD_PMU) += marvell_cn10k_tad_pmu.o
obj-$(CONFIG_MARVELL_CN10K_DDR_PMU) += marvell_cn10k_ddr_pmu.o
+obj-$(CONFIG_MARVELL_PEM_PMU) += marvell_pem_pmu.o
obj-$(CONFIG_APPLE_M1_CPU_PMU) += apple_m1_cpu_pmu.o
obj-$(CONFIG_ALIBABA_UNCORE_DRW_PMU) += alibaba_uncore_drw_pmu.o
obj-$(CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU) += arm_cspmu/
diff --git a/drivers/perf/marvell_pem_pmu.c b/drivers/perf/marvell_pem_pmu.c
new file mode 100644
index 000000000000..913175954a9c
--- /dev/null
+++ b/drivers/perf/marvell_pem_pmu.c
@@ -0,0 +1,425 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Marvell PEM(PCIe RC) Performance Monitor Driver
+ *
+ * Copyright (C) 2024 Marvell.
+ */
+
+#include <linux/acpi.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/perf_event.h>
+#include <linux/platform_device.h>
+
+/*
+ * Each of these events maps to a free running 64 bit counter
+ * with no event control, but can be reset.
+ *
+ */
+enum pem_events {
+ IB_TLP_NPR,
+ IB_TLP_PR,
+ IB_TLP_CPL,
+ IB_TLP_DWORDS_NPR,
+ IB_TLP_DWORDS_PR,
+ IB_TLP_DWORDS_CPL,
+ IB_INFLIGHT,
+ IB_READS,
+ IB_REQ_NO_RO_NCB,
+ IB_REQ_NO_RO_EBUS,
+ OB_TLP_NPR,
+ OB_TLP_PR,
+ OB_TLP_CPL,
+ OB_TLP_DWORDS_NPR,
+ OB_TLP_DWORDS_PR,
+ OB_TLP_DWORDS_CPL,
+ OB_INFLIGHT,
+ OB_READS,
+ OB_MERGES_NPR,
+ OB_MERGES_PR,
+ OB_MERGES_CPL,
+ ATS_TRANS,
+ ATS_TRANS_LATENCY,
+ ATS_PRI,
+ ATS_PRI_LATENCY,
+ ATS_INV,
+ ATS_INV_LATENCY,
+ PEM_EVENTIDS_MAX,
+};
+
+static u64 eventid_to_offset_table[] = {
+ [IB_TLP_NPR] = 0x0,
+ [IB_TLP_PR] = 0x8,
+ [IB_TLP_CPL] = 0x10,
+ [IB_TLP_DWORDS_NPR] = 0x100,
+ [IB_TLP_DWORDS_PR] = 0x108,
+ [IB_TLP_DWORDS_CPL] = 0x110,
+ [IB_INFLIGHT] = 0x200,
+ [IB_READS] = 0x300,
+ [IB_REQ_NO_RO_NCB] = 0x400,
+ [IB_REQ_NO_RO_EBUS] = 0x408,
+ [OB_TLP_NPR] = 0x500,
+ [OB_TLP_PR] = 0x508,
+ [OB_TLP_CPL] = 0x510,
+ [OB_TLP_DWORDS_NPR] = 0x600,
+ [OB_TLP_DWORDS_PR] = 0x608,
+ [OB_TLP_DWORDS_CPL] = 0x610,
+ [OB_INFLIGHT] = 0x700,
+ [OB_READS] = 0x800,
+ [OB_MERGES_NPR] = 0x900,
+ [OB_MERGES_PR] = 0x908,
+ [OB_MERGES_CPL] = 0x910,
+ [ATS_TRANS] = 0x2D18,
+ [ATS_TRANS_LATENCY] = 0x2D20,
+ [ATS_PRI] = 0x2D28,
+ [ATS_PRI_LATENCY] = 0x2D30,
+ [ATS_INV] = 0x2D38,
+ [ATS_INV_LATENCY] = 0x2D40,
+};
+
+struct pem_pmu {
+ struct pmu pmu;
+ void __iomem *base;
+ unsigned int cpu;
+ struct device *dev;
+ struct hlist_node node;
+};
+
+#define to_pem_pmu(p) container_of(p, struct pem_pmu, pmu)
+
+static int eventid_to_offset(int eventid)
+{
+ return eventid_to_offset_table[eventid];
+}
+
+/* Events */
+static ssize_t pem_pmu_event_show(struct device *dev,
+ struct device_attribute *attr,
+ char *page)
+{
+ struct perf_pmu_events_attr *pmu_attr;
+
+ pmu_attr = container_of(attr, struct perf_pmu_events_attr, attr);
+ return sysfs_emit(page, "event=0x%02llx\n", pmu_attr->id);
+}
+
+#define PEM_EVENT_ATTR(_name, _id) \
+ (&((struct perf_pmu_events_attr[]) { \
+ { .attr = __ATTR(_name, 0444, pem_pmu_event_show, NULL), \
+ .id = _id, } \
+ })[0].attr.attr)
+
+static struct attribute *pem_perf_events_attrs[] = {
+ PEM_EVENT_ATTR(ib_tlp_npr, IB_TLP_NPR),
+ PEM_EVENT_ATTR(ib_tlp_pr, IB_TLP_PR),
+ PEM_EVENT_ATTR(ib_tlp_cpl_partid, IB_TLP_CPL),
+ PEM_EVENT_ATTR(ib_tlp_dwords_npr, IB_TLP_DWORDS_NPR),
+ PEM_EVENT_ATTR(ib_tlp_dwords_pr, IB_TLP_DWORDS_PR),
+ PEM_EVENT_ATTR(ib_tlp_dwords_cpl_partid, IB_TLP_DWORDS_CPL),
+ PEM_EVENT_ATTR(ib_inflight, IB_INFLIGHT),
+ PEM_EVENT_ATTR(ib_reads, IB_READS),
+ PEM_EVENT_ATTR(ib_req_no_ro_ncb, IB_REQ_NO_RO_NCB),
+ PEM_EVENT_ATTR(ib_req_no_ro_ebus, IB_REQ_NO_RO_EBUS),
+ PEM_EVENT_ATTR(ob_tlp_npr_partid, OB_TLP_NPR),
+ PEM_EVENT_ATTR(ob_tlp_pr_partid, OB_TLP_PR),
+ PEM_EVENT_ATTR(ob_tlp_cpl_partid, OB_TLP_CPL),
+ PEM_EVENT_ATTR(ob_tlp_dwords_npr_partid, OB_TLP_DWORDS_NPR),
+ PEM_EVENT_ATTR(ob_tlp_dwords_pr_partid, OB_TLP_DWORDS_PR),
+ PEM_EVENT_ATTR(ob_tlp_dwords_cpl_partid, OB_TLP_DWORDS_CPL),
+ PEM_EVENT_ATTR(ob_inflight_partid, OB_INFLIGHT),
+ PEM_EVENT_ATTR(ob_reads_partid, OB_READS),
+ PEM_EVENT_ATTR(ob_merges_npr_partid, OB_MERGES_NPR),
+ PEM_EVENT_ATTR(ob_merges_pr_partid, OB_MERGES_PR),
+ PEM_EVENT_ATTR(ob_merges_cpl_partid, OB_MERGES_CPL),
+ PEM_EVENT_ATTR(ats_trans, ATS_TRANS),
+ PEM_EVENT_ATTR(ats_trans_latency, ATS_TRANS_LATENCY),
+ PEM_EVENT_ATTR(ats_pri, ATS_PRI),
+ PEM_EVENT_ATTR(ats_pri_latency, ATS_PRI_LATENCY),
+ PEM_EVENT_ATTR(ats_inv, ATS_INV),
+ PEM_EVENT_ATTR(ats_inv_latency, ATS_INV_LATENCY),
+ NULL
+};
+
+static struct attribute_group pem_perf_events_attr_group = {
+ .name = "events",
+ .attrs = pem_perf_events_attrs,
+};
+
+PMU_FORMAT_ATTR(event, "config:0-5");
+
+static struct attribute *pem_perf_format_attrs[] = {
+ &format_attr_event.attr,
+ NULL
+};
+
+static struct attribute_group pem_perf_format_attr_group = {
+ .name = "format",
+ .attrs = pem_perf_format_attrs,
+};
+
+/* cpumask */
+static ssize_t pem_perf_cpumask_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct pem_pmu *pmu = dev_get_drvdata(dev);
+
+ return cpumap_print_to_pagebuf(true, buf, cpumask_of(pmu->cpu));
+}
+
+static struct device_attribute pem_perf_cpumask_attr =
+ __ATTR(cpumask, 0444, pem_perf_cpumask_show, NULL);
+
+static struct attribute *pem_perf_cpumask_attrs[] = {
+ &pem_perf_cpumask_attr.attr,
+ NULL
+};
+
+static struct attribute_group pem_perf_cpumask_attr_group = {
+ .attrs = pem_perf_cpumask_attrs,
+};
+
+static const struct attribute_group *pem_perf_attr_groups[] = {
+ &pem_perf_events_attr_group,
+ &pem_perf_cpumask_attr_group,
+ &pem_perf_format_attr_group,
+ NULL
+};
+
+static int pem_perf_event_init(struct perf_event *event)
+{
+ struct pem_pmu *pmu = to_pem_pmu(event->pmu);
+ struct hw_perf_event *hwc = &event->hw;
+
+ if (event->attr.type != event->pmu->type)
+ return -ENOENT;
+
+ if (is_sampling_event(event) ||
+ event->attach_state & PERF_ATTACH_TASK) {
+ return -EOPNOTSUPP;
+ }
+
+ if (event->cpu < 0)
+ return -EOPNOTSUPP;
+
+ /* We must NOT create groups containing mixed PMUs */
+ if (event->group_leader->pmu != event->pmu &&
+ !is_software_event(event->group_leader))
+ return -EINVAL;
+
+ /*
+ * Set ownership of event to one CPU, same event can not be observed
+ * on multiple cpus at same time.
+ */
+ event->cpu = pmu->cpu;
+ hwc->idx = -1;
+ return 0;
+}
+
+static void pem_perf_counter_reset(struct pem_pmu *pmu,
+ struct perf_event *event, int eventid)
+{
+ writeq_relaxed(0x0, pmu->base + eventid_to_offset(eventid));
+}
+
+static u64 pem_perf_read_counter(struct pem_pmu *pmu,
+ struct perf_event *event, int eventid)
+{
+ return readq_relaxed(pmu->base + eventid_to_offset(eventid));
+}
+
+static void pem_perf_event_update(struct perf_event *event)
+{
+ struct pem_pmu *pmu = to_pem_pmu(event->pmu);
+ struct hw_perf_event *hwc = &event->hw;
+ u64 prev_count, new_count;
+
+ do {
+ prev_count = local64_read(&hwc->prev_count);
+ new_count = pem_perf_read_counter(pmu, event, hwc->idx);
+ } while (local64_xchg(&hwc->prev_count, new_count) != prev_count);
+
+ local64_add((new_count - prev_count), &event->count);
+}
+
+static void pem_perf_event_start(struct perf_event *event, int flags)
+{
+ struct pem_pmu *pmu = to_pem_pmu(event->pmu);
+ struct hw_perf_event *hwc = &event->hw;
+ int eventid = hwc->idx;
+
+ local64_set(&hwc->prev_count, 0);
+
+ pem_perf_counter_reset(pmu, event, eventid);
+
+ hwc->state = 0;
+}
+
+static int pem_perf_event_add(struct perf_event *event, int flags)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ hwc->idx = event->attr.config;
+ if (hwc->idx >= PEM_EVENTIDS_MAX)
+ return -EINVAL;
+ hwc->state |= PERF_HES_STOPPED;
+
+ if (flags & PERF_EF_START)
+ pem_perf_event_start(event, flags);
+
+ return 0;
+}
+
+static void pem_perf_event_stop(struct perf_event *event, int flags)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ if (flags & PERF_EF_UPDATE)
+ pem_perf_event_update(event);
+
+ hwc->state |= PERF_HES_STOPPED;
+}
+
+static void pem_perf_event_del(struct perf_event *event, int flags)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ pem_perf_event_stop(event, PERF_EF_UPDATE);
+ hwc->idx = -1;
+}
+
+static int pem_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
+{
+ struct pem_pmu *pmu = hlist_entry_safe(node, struct pem_pmu,
+ node);
+ unsigned int target;
+
+ if (cpu != pmu->cpu)
+ return 0;
+
+ target = cpumask_any_but(cpu_online_mask, cpu);
+ if (target >= nr_cpu_ids)
+ return 0;
+
+ perf_pmu_migrate_context(&pmu->pmu, cpu, target);
+ pmu->cpu = target;
+ return 0;
+}
+
+static int pem_perf_probe(struct platform_device *pdev)
+{
+ struct pem_pmu *pem_pmu;
+ struct resource *res;
+ void __iomem *base;
+ char *name;
+ int ret;
+
+ pem_pmu = devm_kzalloc(&pdev->dev, sizeof(*pem_pmu), GFP_KERNEL);
+ if (!pem_pmu)
+ return -ENOMEM;
+
+ pem_pmu->dev = &pdev->dev;
+ platform_set_drvdata(pdev, pem_pmu);
+
+ base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pem_pmu->base = base;
+
+ pem_pmu->pmu = (struct pmu) {
+ .module = THIS_MODULE,
+ .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
+ .task_ctx_nr = perf_invalid_context,
+ .attr_groups = pem_perf_attr_groups,
+ .event_init = pem_perf_event_init,
+ .add = pem_perf_event_add,
+ .del = pem_perf_event_del,
+ .start = pem_perf_event_start,
+ .stop = pem_perf_event_stop,
+ .read = pem_perf_event_update,
+ };
+
+ /* Choose this cpu to collect perf data */
+ pem_pmu->cpu = raw_smp_processor_id();
+
+ name = devm_kasprintf(pem_pmu->dev, GFP_KERNEL, "mrvl_pcie_rc_pmu_%llx",
+ res->start);
+ if (!name)
+ return -ENOMEM;
+
+ cpuhp_state_add_instance_nocalls
+ (CPUHP_AP_PERF_ARM_MARVELL_PEM_ONLINE,
+ &pem_pmu->node);
+
+ ret = perf_pmu_register(&pem_pmu->pmu, name, -1);
+ if (ret)
+ goto error;
+
+ return 0;
+error:
+ cpuhp_state_remove_instance_nocalls
+ (CPUHP_AP_PERF_ARM_MARVELL_PEM_ONLINE,
+ &pem_pmu->node);
+ return ret;
+}
+
+static int pem_perf_remove(struct platform_device *pdev)
+{
+ struct pem_pmu *pem_pmu = platform_get_drvdata(pdev);
+
+ cpuhp_state_remove_instance_nocalls
+ (CPUHP_AP_PERF_ARM_MARVELL_PEM_ONLINE,
+ &pem_pmu->node);
+
+ perf_pmu_unregister(&pem_pmu->pmu);
+ return 0;
+}
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id pem_pmu_acpi_match[] = {
+ {"MRVL000E", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(acpi, pem_pmu_acpi_match);
+#endif
+
+static struct platform_driver pem_pmu_driver = {
+ .driver = {
+ .name = "pem-pmu",
+ .acpi_match_table = ACPI_PTR(pem_pmu_acpi_match),
+ .suppress_bind_attrs = true,
+ },
+ .probe = pem_perf_probe,
+ .remove = pem_perf_remove,
+};
+
+static int __init pem_pmu_init(void)
+{
+ int ret;
+
+ ret = cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_MARVELL_PEM_ONLINE,
+ "perf/marvell/pem:online", NULL,
+ pem_pmu_offline_cpu);
+ if (ret)
+ return ret;
+
+ ret = platform_driver_register(&pem_pmu_driver);
+ if (ret)
+ cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_MARVELL_PEM_ONLINE);
+ return ret;
+}
+
+static void __exit pem_pmu_exit(void)
+{
+ platform_driver_unregister(&pem_pmu_driver);
+ cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_MARVELL_PEM_ONLINE);
+}
+
+module_init(pem_pmu_init);
+module_exit(pem_pmu_exit);
+
+MODULE_DESCRIPTION("Marvell PEM Perf driver");
+MODULE_AUTHOR("Linu Cherian <lcherian@marvell.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 624d4a38c358..9bf34f66e5f5 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -238,6 +238,7 @@ enum cpuhp_state {
CPUHP_AP_PERF_ARM_APM_XGENE_ONLINE,
CPUHP_AP_PERF_ARM_CAVIUM_TX2_UNCORE_ONLINE,
CPUHP_AP_PERF_ARM_MARVELL_CN10K_DDR_ONLINE,
+ CPUHP_AP_PERF_ARM_MARVELL_PEM_ONLINE,
CPUHP_AP_PERF_POWERPC_NEST_IMC_ONLINE,
CPUHP_AP_PERF_POWERPC_CORE_IMC_ONLINE,
CPUHP_AP_PERF_POWERPC_THREAD_IMC_ONLINE,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-03 6:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <083e50de-1c99-4a58-8b55-4dec26d97c1b@kernel.org>
On Wed, Apr 03, 2024 at 08:40:19AM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2024 08:32, Siddharth Vadapalli wrote:
> > On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
> >> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> >>> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> >>>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> >>>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> >>>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> >>>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
> >>>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> >>>>>>> registers within the System Controller device-tree node. The default MAC
> >>>>>>> Address for the interface corresponding to the first MAC port will be set
> >>>>>>> to the value programmed in the eFuse.
> >>>>>>>
> >>>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> This patch is based on linux-next tagged next-20240402.
> >>>>>>
> >>>>>> Where is the DTS using it?
> >>>>>
> >>>>> The current implementation in the device-tree for older TI K3 SoCs is as
> >>>>> follows:
> >>>>>
> >>>>> cpsw_port1: port@1 {
> >>>>> reg = <1>;
> >>>>> ti,mac-only;
> >>>>> label = "port1";
> >>>>> phys = <&phy_gmii_sel 1>;
> >>>>> mac-address = [00 00 00 00 00 00];
> >>>>> ti,syscon-efuse = <&wkup_conf 0x200>;
> >>>>> };
> >>>>>
> >>>>> The "ti,syscon-efuse" property passes the reference to the System
> >>>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> >>>>> within the CTRL_MMR space.
> >>>>
> >>>> Please reference upstream DTS or lore link to patch under review.
> >>>
> >>> An example of the existing implementation in the device-tree for AM64x
> >>> is:
> >>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> >>> It uses:
> >>> ti,syscon-efuse = <&main_conf 0x200>;
> >>>
> >>> and "main_conf" node is defined at:
> >>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
> >>
> >> It is quite different than your bindings, so your bindings are incorrect.
> >
> > Sorry I didn't understand what you mean. The references I have provided
> > are for existing DTS where "main_conf"/"wkup_conf" (System Controller
> > nodes) have the compatible "syscon", unlike in AM62p at:
> > https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
> > which has the "simple-bus" compatible for the "wkup_conf" node.
> >
> > Also, shouldn't the device-tree bindings patches be posted first and get
> > merged before I post the device-tree patches that utilize the
> > compatible/properties that have been added in the bindings? That is the
> > reason why I had shared the "DIFF" for the DTS changes that I will be
> > posting once this patch for the new compatible is accepted.
> >
>
> That's not the process. I will be NAKing bindings which do not have any
> users, because I do not trust you test them.
>
> The process is almost always:
> 1. Send bindings,
> 2. Send driver changes (if applicable) in the same patchset.
> 3. Send DTS, usually in separate patches and provide lore link to the
> bindings in the changelog or cover letter.
Thank you for clarifying. I will post the DTS patches corresponding to
this patch and reference this patch in the DTS patch series.
Regards,
Siddharth.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/18] PCI: endpoint: Introduce pci_epc_function_is_valid()
From: Manivannan Sadhasivam @ 2024-04-03 6:46 UTC (permalink / raw)
To: Damien Le Moal
Cc: Lorenzo Pieralisi, Kishon Vijay Abraham I, Shawn Lin,
Krzysztof Wilczyński, Bjorn Helgaas, Heiko Stuebner,
linux-pci, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <20240330041928.1555578-2-dlemoal@kernel.org>
On Sat, Mar 30, 2024 at 01:19:11PM +0900, Damien Le Moal wrote:
> Introduce the epc core helper function pci_epc_function_is_valid() to
> verify that an epc pointer, a physical function number and a virtual
> function number are all valid. This avoids repeating the code pattern:
>
> if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> return err;
>
> if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> return err;
>
> in many functions of the endpoint controller core code.
>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
One nit below. With that fixed,
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> drivers/pci/endpoint/pci-epc-core.c | 79 +++++++++++------------------
> 1 file changed, 31 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index da3fc0795b0b..754afd115bbd 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -126,6 +126,18 @@ enum pci_barno pci_epc_get_next_free_bar(const struct pci_epc_features
> }
> EXPORT_SYMBOL_GPL(pci_epc_get_next_free_bar);
>
> +static inline bool pci_epc_function_is_valid(struct pci_epc *epc,
> + u8 func_no, u8 vfunc_no)
No need to add 'inline' keyword to function definitions in a .c file. Compiler
will handle that.
- Mani
> +{
> + if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> + return false;
> +
> + if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + return false;
> +
> + return true;
> +}
> +
> /**
> * pci_epc_get_features() - get the features supported by EPC
> * @epc: the features supported by *this* EPC device will be returned
> @@ -143,10 +155,7 @@ const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
> {
> const struct pci_epc_features *epc_features;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return NULL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return NULL;
>
> if (!epc->ops->get_features)
> @@ -216,10 +225,7 @@ int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return -EINVAL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> if (!epc->ops->raise_irq)
> @@ -260,10 +266,7 @@ int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc))
> - return -EINVAL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> if (!epc->ops->map_msi_irq)
> @@ -291,10 +294,7 @@ int pci_epc_get_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
> {
> int interrupt;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return 0;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return 0;
>
> if (!epc->ops->get_msi)
> @@ -327,11 +327,10 @@ int pci_epc_set_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no, u8 interrupts)
> int ret;
> u8 encode_int;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
> - interrupts < 1 || interrupts > 32)
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (interrupts < 1 || interrupts > 32)
> return -EINVAL;
>
> if (!epc->ops->set_msi)
> @@ -359,10 +358,7 @@ int pci_epc_get_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
> {
> int interrupt;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return 0;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return 0;
>
> if (!epc->ops->get_msix)
> @@ -395,11 +391,10 @@ int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
> - interrupts < 1 || interrupts > 2048)
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (interrupts < 1 || interrupts > 2048)
> return -EINVAL;
>
> if (!epc->ops->set_msix)
> @@ -426,10 +421,7 @@ EXPORT_SYMBOL_GPL(pci_epc_set_msix);
> void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> phys_addr_t phys_addr)
> {
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return;
>
> if (!epc->ops->unmap_addr)
> @@ -457,10 +449,7 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return -EINVAL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> if (!epc->ops->map_addr)
> @@ -487,12 +476,11 @@ EXPORT_SYMBOL_GPL(pci_epc_map_addr);
> void pci_epc_clear_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> struct pci_epf_bar *epf_bar)
> {
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
> - (epf_bar->barno == BAR_5 &&
> - epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return;
>
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (epf_bar->barno == BAR_5 &&
> + epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64)
> return;
>
> if (!epc->ops->clear_bar)
> @@ -519,18 +507,16 @@ int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> int ret;
> int flags = epf_bar->flags;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
> - (epf_bar->barno == BAR_5 &&
> - flags & PCI_BASE_ADDRESS_MEM_TYPE_64) ||
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> + return -EINVAL;
> +
> + if ((epf_bar->barno == BAR_5 && flags & PCI_BASE_ADDRESS_MEM_TYPE_64) ||
> (flags & PCI_BASE_ADDRESS_SPACE_IO &&
> flags & PCI_BASE_ADDRESS_IO_MASK) ||
> (upper_32_bits(epf_bar->size) &&
> !(flags & PCI_BASE_ADDRESS_MEM_TYPE_64)))
> return -EINVAL;
>
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> - return -EINVAL;
> -
> if (!epc->ops->set_bar)
> return 0;
>
> @@ -559,10 +545,7 @@ int pci_epc_write_header(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return -EINVAL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> /* Only Virtual Function #1 has deviceID */
> --
> 2.44.0
>
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC][PATCH 0/2] Amlogic T7 (A113D2) Clock Driver
From: Xianwei Zhao @ 2024-04-03 6:44 UTC (permalink / raw)
To: Lucas Tanure, Yu Tu, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stephen Boyd, Michael Turquette
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20240318114346.112935-1-tanure@linux.com>
Hi Lucas,
As we are preparing the T7 clock patchset, we would like to your
purpose and plan of this RFC patches. Are you going to submit these
patches at last?
On 2024/3/18 19:43, Lucas Tanure wrote:
> [ EXTERNAL EMAIL ]
>
> I am trying to port the T7 clock driver from Khadas 5.4 kernel for Vim4
> to mainline, but I am encountering some issues in the path.
>
> The kernel panics at clk_mux_val_to_index, but I believe that all the
> needed clocks are registered.
>
> If anyone from Amlogic or the community could help me understand what
> my driver is missing, that would be great.
> I will continue to try to figure out, but it has been some weeks
> without progress =/.
>
> Lucas Tanure (2):
> clk: meson: T7: add support for Amlogic T7 SoC PLL clock driver
> arm64: dts: amlogic: t7: SDCard, Ethernet and Clocking
>
> .../amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 66 +
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 189 +
> drivers/clk/meson/Kconfig | 25 +
> drivers/clk/meson/Makefile | 2 +
> drivers/clk/meson/t7-peripherals.c | 6368 +++++++++++++++++
> drivers/clk/meson/t7-peripherals.h | 131 +
> drivers/clk/meson/t7-pll.c | 1543 ++++
> drivers/clk/meson/t7-pll.h | 83 +
> .../clock/amlogic,t7-peripherals-clkc.h | 410 ++
> .../dt-bindings/clock/amlogic,t7-pll-clkc.h | 69 +
> 10 files changed, 8886 insertions(+)
> create mode 100644 drivers/clk/meson/t7-peripherals.c
> create mode 100644 drivers/clk/meson/t7-peripherals.h
> create mode 100644 drivers/clk/meson/t7-pll.c
> create mode 100644 drivers/clk/meson/t7-pll.h
> create mode 100644 include/dt-bindings/clock/amlogic,t7-peripherals-clkc.h
> create mode 100644 include/dt-bindings/clock/amlogic,t7-pll-clkc.h
>
> Starting kernel ...
>
> uboot time: 14277917 us
> boot 64bit kernel
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd092]
> [ 0.000000] Linux version 6.8.0-09793-gda876e5b54b3-dirty (tanureal@ryzen) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621, GNU ld (GNU Toolchain for the A-pr4
> [ 0.000000] KASLR disabled due to lack of seed
> [ 0.000000] Machine model: Khadas vim4
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] OF: reserved mem: 0x0000000005000000..0x00000000052fffff (3072 KiB) nomap non-reusable secmon@5000000
> [ 0.000000] OF: reserved mem: 0x0000000005300000..0x00000000072fffff (32768 KiB) nomap non-reusable secmon@5300000
> [ 0.000000] NUMA: No NUMA configuration found
> [ 0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000000df7fffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0xdf10c9c0-0xdf10efff]
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000000000000-0x00000000df7fffff]
> [ 0.000000] DMA32 empty
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000004ffffff]
> [ 0.000000] node 0: [mem 0x0000000005000000-0x00000000072fffff]
> [ 0.000000] node 0: [mem 0x0000000007300000-0x00000000df7fffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000df7fffff]
> [ 0.000000] On node 0, zone DMA: 2048 pages in unavailable ranges
> [ 0.000000] cma: Reserved 32 MiB at 0x00000000d9800000 on node -1
> [ 0.000000] psci: probing for conduit method from DT.
> [ 0.000000] psci: PSCIv1.0 detected in firmware.
> [ 0.000000] psci: Using standard PSCI v0.2 function IDs
> [ 0.000000] psci: Trusted OS migration not required
> [ 0.000000] psci: SMC Calling Convention v1.1
> [ 0.000000] percpu: Embedded 24 pages/cpu s58152 r8192 d31960 u98304
> [ 0.000000] Detected VIPT I-cache on CPU0
> [ 0.000000] CPU features: detected: Spectre-v2
> [ 0.000000] CPU features: detected: Spectre-v4
> [ 0.000000] CPU features: detected: Spectre-BHB
> [ 0.000000] CPU features: detected: ARM erratum 858921
> [ 0.000000] alternatives: applying boot alternatives
> [ 0.000000] Kernel command line: root=UUID=a91e7bfe-4263-4e53-867d-7824e7c6a992 rw rootfstype=ext4 console=ttyS0,921600 no_console_suspend earlycon=ttyS0,0xfe078000 khadas_board=VIM4 androidboot.selinux=permissive androidboot.0
> [ 0.000000] Unknown kernel command line parameters "khadas_board=VIM4", will be passed to user space.
> [ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
> [ 0.000000] Fallback order for Node 0: 0
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 901152
> [ 0.000000] Policy zone: DMA
> [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [ 0.000000] software IO TLB: SWIOTLB bounce buffer size adjusted to 3MB
> [ 0.000000] software IO TLB: area num 8.
> [ 0.000000] software IO TLB: SWIOTLB bounce buffer size roundup to 4MB
> [ 0.000000] software IO TLB: mapped [mem 0x00000000d8e00000-0x00000000d9200000] (4MB)
> [ 0.000000] Memory: 3445944K/3661824K available (16896K kernel code, 4426K rwdata, 9184K rodata, 9728K init, 611K bss, 183112K reserved, 32768K cma-reserved)
> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
> [ 0.000000] rcu: Preemptible hierarchical RCU implementation.
> [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8.
> [ 0.000000] Trampoline variant of Tasks RCU enabled.
> [ 0.000000] Tracing variant of Tasks RCU enabled.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
> [ 0.000000] RCU Tasks: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
> [ 0.000000] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
> [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> [ 0.000000] GIC: GICv2 detected, but range too small and irqchip.gicv2_force_probe not set
> [ 0.000000] Root IRQ handler: gic_handle_irq
> [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
> [ 0.000000] arch_timer: Enabling local workaround for ARM erratum 858921
> [ 0.000000] arch_timer: CPU0: Trapping CNTVCT access
> [ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
> [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
> [ 0.000000] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
> [ 0.000210] Console: colour dummy device 80x25
> [ 0.000253] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
> [ 0.000261] pid_max: default: 32768 minimum: 301
> [ 0.000300] LSM: initializing lsm=capability
> [ 0.000358] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
> [ 0.000371] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
> [ 0.000920] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [ 0.001389] rcu: Hierarchical SRCU implementation.
> [ 0.001391] rcu: Max phase no-delay instances is 1000.
> [ 0.001834] EFI services will not be available.
> [ 0.001999] smp: Bringing up secondary CPUs ...
> [ 0.002408] CPU features: detected: ARM erratum 845719
> [ 0.002426] Detected VIPT I-cache on CPU1
> [ 0.002516] CPU1: Booted secondary processor 0x0000000100 [0x410fd034]
> [ 0.003007] Detected VIPT I-cache on CPU2
> [ 0.003054] CPU2: Booted secondary processor 0x0000000101 [0x410fd034]
> [ 0.003497] Detected VIPT I-cache on CPU3
> [ 0.003546] CPU3: Booted secondary processor 0x0000000102 [0x410fd034]
> [ 0.003988] Detected VIPT I-cache on CPU4
> [ 0.004038] CPU4: Booted secondary processor 0x0000000103 [0x410fd034]
> [ 0.004472] Detected VIPT I-cache on CPU5
> [ 0.004509] arch_timer: Enabling local workaround for ARM erratum 858921
> [ 0.004519] arch_timer: CPU5: Trapping CNTVCT access
> [ 0.004527] CPU5: Booted secondary processor 0x0000000001 [0x410fd092]
> [ 0.004915] Detected VIPT I-cache on CPU6
> [ 0.004940] arch_timer: Enabling local workaround for ARM erratum 858921
> [ 0.004946] arch_timer: CPU6: Trapping CNTVCT access
> [ 0.004951] CPU6: Booted secondary processor 0x0000000002 [0x410fd092]
> [ 0.005333] Detected VIPT I-cache on CPU7
> [ 0.005358] arch_timer: Enabling local workaround for ARM erratum 858921
> [ 0.005364] arch_timer: CPU7: Trapping CNTVCT access
> [ 0.005369] CPU7: Booted secondary processor 0x0000000003 [0x410fd092]
> [ 0.005414] smp: Brought up 1 node, 8 CPUs
> [ 0.005419] SMP: Total of 8 processors activated.
> [ 0.005421] CPU: All CPU(s) started at EL2
> [ 0.005434] CPU features: detected: 32-bit EL0 Support
> [ 0.005437] CPU features: detected: 32-bit EL1 Support
> [ 0.005440] CPU features: detected: CRC32 instructions
> [ 0.005485] alternatives: applying system-wide alternatives
> [ 0.006730] devtmpfs: initialized
> [ 0.008534] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [ 0.008545] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
> [ 0.008989] pinctrl core: initialized pinctrl subsystem
> [ 0.009581] DMI not present or invalid.
> [ 0.011290] NET: Registered PF_NETLINK/PF_ROUTE protocol family
> [ 0.011944] DMA: preallocated 512 KiB GFP_KERNEL pool for atomic allocations
> [ 0.012293] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> [ 0.012711] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
> [ 0.012832] audit: initializing netlink subsys (disabled)
> [ 0.013075] audit: type=2000 audit(0.012:1): state=initialized audit_enabled=0 res=1
> [ 0.013508] thermal_sys: Registered thermal governor 'step_wise'
> [ 0.013512] thermal_sys: Registered thermal governor 'power_allocator'
> [ 0.013557] cpuidle: using governor menu
> [ 0.013675] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> [ 0.013784] ASID allocator initialised with 65536 entries
> [ 0.014630] Serial: AMBA PL011 UART driver
> [ 0.017553] Modules: 22496 pages in range for non-PLT usage
> [ 0.017556] Modules: 514016 pages in range for PLT usage
> [ 0.017980] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
> [ 0.017984] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
> [ 0.017988] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages
> [ 0.017990] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page
> [ 0.017993] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
> [ 0.017995] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
> [ 0.017997] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages
> [ 0.018000] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page
> [ 0.018247] Demotion targets for Node 0: null
> [ 0.018884] ACPI: Interpreter disabled.
> [ 0.019584] iommu: Default domain type: Translated
> [ 0.019587] iommu: DMA domain TLB invalidation policy: strict mode
> [ 0.019979] SCSI subsystem initialized
> [ 0.020174] usbcore: registered new interface driver usbfs
> [ 0.020187] usbcore: registered new interface driver hub
> [ 0.020200] usbcore: registered new device driver usb
> [ 0.020434] pps_core: LinuxPPS API ver. 1 registered
> [ 0.020437] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
> [ 0.020443] PTP clock support registered
> [ 0.020487] EDAC MC: Ver: 3.0.0
> [ 0.020717] scmi_core: SCMI protocol bus registered
> [ 0.021039] FPGA manager framework
> [ 0.021076] Advanced Linux Sound Architecture Driver Initialized.
> [ 0.021612] vgaarb: loaded
> [ 0.021857] clocksource: Switched to clocksource arch_sys_counter
> [ 0.021967] VFS: Disk quotas dquot_6.6.0
> [ 0.021984] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [ 0.022062] pnp: PnP ACPI: disabled
> [ 0.026651] NET: Registered PF_INET protocol family
> [ 0.026781] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear)
> [ 0.028598] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
> [ 0.028615] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
> [ 0.028622] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
> [ 0.028750] TCP bind hash table entries: 32768 (order: 8, 1048576 bytes, linear)
> [ 0.029019] TCP: Hash tables configured (established 32768 bind 32768)
> [ 0.029096] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
> [ 0.029124] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
> [ 0.029225] NET: Registered PF_UNIX/PF_LOCAL protocol family
> [ 0.029506] RPC: Registered named UNIX socket transport module.
> [ 0.029510] RPC: Registered udp transport module.
> [ 0.029512] RPC: Registered tcp transport module.
> [ 0.029513] RPC: Registered tcp-with-tls transport module.
> [ 0.029515] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [ 0.029524] PCI: CLS 0 bytes, default 64
> [ 0.029649] Unpacking initramfs...
> [ 0.033933] kvm [1]: IPA Size Limit: 40 bits
> [ 0.034713] kvm [1]: Hyp mode initialized successfully
> [ 0.035476] Initialise system trusted keyrings
> [ 0.035582] workingset: timestamp_bits=42 max_order=20 bucket_order=0
> [ 0.035747] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> [ 0.035906] NFS: Registering the id_resolver key type
> [ 0.035919] Key type id_resolver registered
> [ 0.035922] Key type id_legacy registered
> [ 0.035933] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
> [ 0.035935] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
> [ 0.036031] 9p: Installing v9fs 9p2000 file system support
> [ 0.062587] Key type asymmetric registered
> [ 0.062596] Asymmetric key parser 'x509' registered
> [ 0.062657] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
> [ 0.062661] io scheduler mq-deadline registered
> [ 0.062664] io scheduler kyber registered
> [ 0.062688] io scheduler bfq registered
> [ 0.063318] irq_meson_gpio: 157 to 12 gpio interrupt mux initialized
> [ 0.068061] EINJ: ACPI disabled.
> [ 0.072570] amlogic_t7_pll_probe
> [ 0.072855] amlogic_t7_pll_probe ret 0
> [ 0.072943] amlogic_a1_periphs_probe
> [ 0.078155] amlogic_a1_periphs_probe ret 0
> [ 0.084876] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [ 0.086691] fe078000.serial: ttyS0 at MMIO 0xfe078000 (irq = 14, base_baud = 1500000) is a meson_uart
> [ 0.086710] printk: legacy console [ttyS0] enabled
> [ 0.229167] sysfs: cannot create duplicate filename '/class/tty/ttyS0'
> [ 0.229669] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> [ 0.230684] Hardware name: Khadas vim4 (DT)
> [ 0.231205] Call trace:
> [ 0.231509] dump_backtrace+0x94/0xec
> [ 0.231963] show_stack+0x18/0x24
> [ 0.232374] dump_stack_lvl+0x78/0x90
> [ 0.232829] dump_stack+0x18/0x24
> [ 0.233241] sysfs_warn_dup+0x64/0x80
> [ 0.233696] sysfs_do_create_link_sd+0xf0/0xf8
> [ 0.234248] sysfs_create_link+0x20/0x40
> [ 0.234736] device_add+0x27c/0x77c
> [ 0.235169] device_register+0x20/0x30
> [ 0.235635] tty_register_device_attr+0xfc/0x240
> [ 0.236209] tty_port_register_device_attr_serdev+0x8c/0xac
> [ 0.236902] serial_core_register_port+0x318/0x658
> [ 0.237498] serial_ctrl_register_port+0x10/0x1c
> [ 0.238072] uart_add_one_port+0x10/0x1c
> [ 0.238560] meson_uart_probe+0x2c0/0x3b4
> [ 0.239058] platform_probe+0x68/0xd8
> [ 0.239513] really_probe+0x148/0x2b4
> [ 0.239968] __driver_probe_device+0x78/0x12c
> [ 0.240510] driver_probe_device+0xdc/0x160
> [ 0.241030] __driver_attach+0x94/0x19c
> [ 0.241507] bus_for_each_dev+0x74/0xd4
> [ 0.241983] driver_attach+0x24/0x30
> [ 0.242428] bus_add_driver+0xe4/0x1e8
> [ 0.242893] driver_register+0x60/0x128
> [ 0.243370] __platform_driver_register+0x28/0x34
> [ 0.243955] meson_uart_platform_driver_init+0x1c/0x28
> [ 0.244594] do_one_initcall+0x6c/0x1b0
> [ 0.245071] kernel_init_freeable+0x1cc/0x294
> [ 0.245613] kernel_init+0x20/0x1dc
> [ 0.246046] ret_from_fork+0x10/0x20
> [ 0.246555] meson_uart fe078000.serial: Cannot register tty device on line 0
> [ 0.247729] msm_serial: driver initialized
> [ 0.248150] SuperH (H)SCI(F) driver initialized
> [ 0.248544] STM32 USART driver initialized
> [ 0.263927] loop: module loaded
> [ 0.264952] megasas: 07.727.03.00-rc1
> [ 0.271065] tun: Universal TUN/TAP device driver, 1.6
> [ 0.271824] thunder_xcv, ver 1.0
> [ 0.271878] thunder_bgx, ver 1.0
> [ 0.271956] nicpf, ver 1.0
> [ 0.273230] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
> [ 0.273437] hns3: Copyright (c) 2017 Huawei Corporation.
> [ 0.274148] hclge is initializing
> [ 0.274541] e1000: Intel(R) PRO/1000 Network Driver
> [ 0.275116] e1000: Copyright (c) 1999-2006 Intel Corporation.
> [ 0.275860] e1000e: Intel(R) PRO/1000 Network Driver
> [ 0.276449] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> [ 0.277209] igb: Intel(R) Gigabit Ethernet Network Driver
> [ 0.277867] igb: Copyright (c) 2007-2014 Intel Corporation.
> [ 0.278576] igbvf: Intel(R) Gigabit Virtual Function Network Driver
> [ 0.279330] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
> [ 0.280319] sky2: driver version 1.30
> [ 0.281597] VFIO - User Level meta-driver version: 0.3
> [ 0.283859] usbcore: registered new interface driver usb-storage
> [ 0.286328] i2c_dev: i2c /dev entries driver
> [ 0.292404] sdhci: Secure Digital Host Controller Interface driver
> [ 0.292481] sdhci: Copyright(c) Pierre Ossman
> [ 0.293577] Synopsys Designware Multimedia Card Interface Driver
> [ 0.294572] sdhci-pltfm: SDHCI platform and OF driver helper
> [ 0.296259] ledtrig-cpu: registered to indicate activity on CPUs
> [ 0.298966] meson-sm: secure-monitor enabled
> [ 0.299963] usbcore: registered new interface driver usbhid
> [ 0.299997] usbhid: USB HID core driver
> [ 0.306803] NET: Registered PF_PACKET protocol family
> [ 0.306919] 9pnet: Installing 9P2000 support
> [ 0.307331] Key type dns_resolver registered
> [ 0.318926] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
> [ 0.319462] registered taskstats version 1
> [ 0.319968] Loading compiled-in X.509 certificates
> [ 0.362771] clk: Disabling unused clocks
> [ 0.363100] PM: genpd: Disabling unused power domains
> [ 0.363383] ALSA device list:
> [ 0.363580] No soundcards found.
> [ 0.368194] meson-gx-mmc fe08a000.sd: Got CD GPIO
> [ 0.368524] SError Interrupt on CPU6, code 0x00000000bf000002 -- SError
> [ 0.368531] CPU: 6 PID: 87 Comm: kworker/u32:3 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> [ 0.368537] Hardware name: Khadas vim4 (DT)
> [ 0.368540] Workqueue: async async_run_entry_fn
> [ 0.368552] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.368556] pc : clk_mux_val_to_index+0x0/0xc0
> [ 0.368565] lr : clk_mux_get_parent+0x4c/0x84
> [ 0.368571] sp : ffff800082efba10
> [ 0.368572] x29: ffff800082efba10 x28: ffff8000823279c0 x27: ffff800082327000
> [ 0.368578] x26: ffff000004c361c0 x25: 0000000000000000 x24: 0000000000000002
> [ 0.368584] x23: ffff000003f1d300 x22: ffff000003f1d2a0 x21: ffff000004c37280
> [ 0.368589] x20: ffff000004c36ec0 x19: ffff000004bba800 x18: 0000000000000020
> [ 0.368594] x17: ffff000000022000 x16: 0000000000000003 x15: ffffffffffffffff
> [ 0.368599] x14: ffffffffffffffff x13: 0078756d2364732e x12: 3030306138306566
> [ 0.368604] x11: 7f7f7f7f7f7f7f7f x10: ffff7fff83438910 x9 : 0000000000000005
> [ 0.368609] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 05114367045e5359
> [ 0.368613] x5 : 0000000000000006 x4 : 0000000000000000 x3 : 0000000000000000
> [ 0.368618] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000004c36ec0
> [ 0.368624] Kernel panic - not syncing: Asynchronous SError Interrupt
> [ 0.368626] CPU: 6 PID: 87 Comm: kworker/u32:3 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> [ 0.368630] Hardware name: Khadas vim4 (DT)
> [ 0.368631] Workqueue: async async_run_entry_fn
> [ 0.368635] Call trace:
> [ 0.368637] dump_backtrace+0x94/0xec
> [ 0.368644] show_stack+0x18/0x24
> [ 0.368649] dump_stack_lvl+0x38/0x90
> [ 0.368656] dump_stack+0x18/0x24
> [ 0.368661] panic+0x388/0x3c8
> [ 0.368666] nmi_panic+0x48/0x94
> [ 0.368670] arm64_serror_panic+0x6c/0x78
> [ 0.368674] do_serror+0x3c/0x78
> [ 0.368677] el1h_64_error_handler+0x30/0x48
> [ 0.368681] el1h_64_error+0x64/0x68
> [ 0.368684] clk_mux_val_to_index+0x0/0xc0
> [ 0.368689] __clk_register+0x440/0x82c
> [ 0.368693] devm_clk_register+0x5c/0xbc
> [ 0.368697] meson_mmc_clk_init+0x11c/0x2a8
> [ 0.368702] meson_mmc_probe+0x18c/0x3c0
> [ 0.368705] platform_probe+0x68/0xd8
> [ 0.368711] really_probe+0x148/0x2b4
> [ 0.368714] __driver_probe_device+0x78/0x12c
> [ 0.368718] driver_probe_device+0xdc/0x160
> [ 0.368721] __device_attach_driver+0xb8/0x134
> [ 0.368724] bus_for_each_drv+0x84/0xe0
> [ 0.368727] __device_attach_async_helper+0xac/0xd0
> [ 0.368730] async_run_entry_fn+0x34/0xe0
> [ 0.368734] process_one_work+0x150/0x294
> [ 0.368740] worker_thread+0x304/0x408
> [ 0.368744] kthread+0x118/0x11c
> [ 0.368748] ret_from_fork+0x10/0x20
> [ 0.368753] SMP: stopping secondary CPUs
> [ 0.368760] Kernel Offset: disabled
> [ 0.368761] CPU features: 0x0,00000060,d0080000,0200421b
> [ 0.368765] Memory Limit: none
> [ 0.400328] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
>
>
> --
> 2.44.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/1] drm/mediatek/dp: The register is written with the parsed DTS SSC value.
From: Krzysztof Kozlowski @ 2024-04-03 6:41 UTC (permalink / raw)
To: Liankun Yang, chunkuang.hu, p.zabel, chunfeng.yun, vkoul, kishon,
matthias.bgg, angelogioacchino.delregno, jitao.shi, mac.shen
Cc: dri-devel, linux-mediatek, linux-arm-kernel, linux-phy,
linux-kernel
In-Reply-To: <20240403040517.3279-1-liankun.yang@mediatek.com>
On 03/04/2024 06:05, Liankun Yang wrote:
> [Description]
> Severe screen flickering has been observed on the external display
> when the DP projection function is used with the market expansion dock.
>
> + if (!strcmp(mode_name, RG_XTP_GLB_TXPLL_SSC_DELTA_RBR)) {
> + regmap_update_bits(dp_phy->regs, ssc_reg_offset,
> + XTP_GLB_TXPLL_SSC_DELTA_RBR_DEFAULT, read_value);
> + } else if (!strcmp(mode_name, RG_XTP_GLB_TXPLL_SSC_DELTA_HBR)) {
> + read_value = read_value << 16 | 0x0000;
> + regmap_update_bits(dp_phy->regs, ssc_reg_offset,
> + XTP_GLB_TXPLL_SSC_DELTA_HBR_DEFAULT, read_value);
> + }
> +
> + return 0;
> +}
> +
> +static struct device_node *mtk_dp_get_ssc_node(struct phy *phy, struct mtk_dp_phy *dp_phy)
> +{
> + struct device_node *mode_node = NULL;
> +
> + mode_node = of_find_node_by_name(dp_phy->dev->of_node, SSC_SETTING);
?!?!
You have the node, why do you try to find it?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Krzysztof Kozlowski @ 2024-04-03 6:40 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <af61424e-7006-49f5-b614-3caa3674685a@ti.com>
On 03/04/2024 08:32, Siddharth Vadapalli wrote:
> On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
>> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
>>> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
>>>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
>>>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
>>>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
>>>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
>>>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
>>>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
>>>>>>> registers within the System Controller device-tree node. The default MAC
>>>>>>> Address for the interface corresponding to the first MAC port will be set
>>>>>>> to the value programmed in the eFuse.
>>>>>>>
>>>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>>>>>> ---
>>>>>>>
>>>>>>> This patch is based on linux-next tagged next-20240402.
>>>>>>
>>>>>> Where is the DTS using it?
>>>>>
>>>>> The current implementation in the device-tree for older TI K3 SoCs is as
>>>>> follows:
>>>>>
>>>>> cpsw_port1: port@1 {
>>>>> reg = <1>;
>>>>> ti,mac-only;
>>>>> label = "port1";
>>>>> phys = <&phy_gmii_sel 1>;
>>>>> mac-address = [00 00 00 00 00 00];
>>>>> ti,syscon-efuse = <&wkup_conf 0x200>;
>>>>> };
>>>>>
>>>>> The "ti,syscon-efuse" property passes the reference to the System
>>>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
>>>>> within the CTRL_MMR space.
>>>>
>>>> Please reference upstream DTS or lore link to patch under review.
>>>
>>> An example of the existing implementation in the device-tree for AM64x
>>> is:
>>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
>>> It uses:
>>> ti,syscon-efuse = <&main_conf 0x200>;
>>>
>>> and "main_conf" node is defined at:
>>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
>>
>> It is quite different than your bindings, so your bindings are incorrect.
>
> Sorry I didn't understand what you mean. The references I have provided
> are for existing DTS where "main_conf"/"wkup_conf" (System Controller
> nodes) have the compatible "syscon", unlike in AM62p at:
> https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
> which has the "simple-bus" compatible for the "wkup_conf" node.
>
> Also, shouldn't the device-tree bindings patches be posted first and get
> merged before I post the device-tree patches that utilize the
> compatible/properties that have been added in the bindings? That is the
> reason why I had shared the "DIFF" for the DTS changes that I will be
> posting once this patch for the new compatible is accepted.
>
That's not the process. I will be NAKing bindings which do not have any
users, because I do not trust you test them.
The process is almost always:
1. Send bindings,
2. Send driver changes (if applicable) in the same patchset.
3. Send DTS, usually in separate patches and provide lore link to the
bindings in the changelog or cover letter.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-03 6:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <eb7a0d5c-c197-44b9-baea-e9b54792b447@kernel.org>
On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> > On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> >> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> >>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> >>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> >>>>> contain the MAC Address programmed in the eFuse. Add compatible for
> >>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> >>>>> registers within the System Controller device-tree node. The default MAC
> >>>>> Address for the interface corresponding to the first MAC port will be set
> >>>>> to the value programmed in the eFuse.
> >>>>>
> >>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >>>>> ---
> >>>>>
> >>>>> This patch is based on linux-next tagged next-20240402.
> >>>>
> >>>> Where is the DTS using it?
> >>>
> >>> The current implementation in the device-tree for older TI K3 SoCs is as
> >>> follows:
> >>>
> >>> cpsw_port1: port@1 {
> >>> reg = <1>;
> >>> ti,mac-only;
> >>> label = "port1";
> >>> phys = <&phy_gmii_sel 1>;
> >>> mac-address = [00 00 00 00 00 00];
> >>> ti,syscon-efuse = <&wkup_conf 0x200>;
> >>> };
> >>>
> >>> The "ti,syscon-efuse" property passes the reference to the System
> >>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> >>> within the CTRL_MMR space.
> >>
> >> Please reference upstream DTS or lore link to patch under review.
> >
> > An example of the existing implementation in the device-tree for AM64x
> > is:
> > https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> > It uses:
> > ti,syscon-efuse = <&main_conf 0x200>;
> >
> > and "main_conf" node is defined at:
> > https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
>
> It is quite different than your bindings, so your bindings are incorrect.
Sorry I didn't understand what you mean. The references I have provided
are for existing DTS where "main_conf"/"wkup_conf" (System Controller
nodes) have the compatible "syscon", unlike in AM62p at:
https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
which has the "simple-bus" compatible for the "wkup_conf" node.
Also, shouldn't the device-tree bindings patches be posted first and get
merged before I post the device-tree patches that utilize the
compatible/properties that have been added in the bindings? That is the
reason why I had shared the "DIFF" for the DTS changes that I will be
posting once this patch for the new compatible is accepted.
Regards,
Siddharth.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Krzysztof Kozlowski @ 2024-04-03 6:27 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <aabea385-16e0-4116-a12b-3ce1e06574e3@ti.com>
On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
>>>>> registers within the System Controller device-tree node. The default MAC
>>>>> Address for the interface corresponding to the first MAC port will be set
>>>>> to the value programmed in the eFuse.
>>>>>
>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>>>> ---
>>>>>
>>>>> This patch is based on linux-next tagged next-20240402.
>>>>
>>>> Where is the DTS using it?
>>>
>>> The current implementation in the device-tree for older TI K3 SoCs is as
>>> follows:
>>>
>>> cpsw_port1: port@1 {
>>> reg = <1>;
>>> ti,mac-only;
>>> label = "port1";
>>> phys = <&phy_gmii_sel 1>;
>>> mac-address = [00 00 00 00 00 00];
>>> ti,syscon-efuse = <&wkup_conf 0x200>;
>>> };
>>>
>>> The "ti,syscon-efuse" property passes the reference to the System
>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
>>> within the CTRL_MMR space.
>>
>> Please reference upstream DTS or lore link to patch under review.
>
> An example of the existing implementation in the device-tree for AM64x
> is:
> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> It uses:
> ti,syscon-efuse = <&main_conf 0x200>;
>
> and "main_conf" node is defined at:
> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
It is quite different than your bindings, so your bindings are incorrect.
Please fix them and send when your DTS is ready.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: About upstreaming ArmChina NPU driver
From: Oded Gabbay @ 2024-04-03 6:25 UTC (permalink / raw)
To: Dejia Shang
Cc: ogabbay@kernel.org, airlied@redhat.com, daniel@ffwll.ch,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <SH0PR01MB063461EBC046437C88A6AE84983BA@SH0PR01MB0634.CHNPR01.prod.partner.outlook.cn>
On Thu, Mar 28, 2024 at 10:01 AM Dejia Shang <Dejia.Shang@armchina.com> wrote:
>
> Dear Kernel Maintainers,
>
> I am a driver developer and would like to upstream the ArmChina Zhouyi NPU driver ("Zhouyi" is the brand) to accel subsystem.
>
> The driver is already open sourced (both UMD and KMD) and anyone can find the code from https://github.com/Arm-China/Compass_NPU_Driver.git.
>
> This driver is responsible for scheduling AI inference tasks to the NPU cores (V1/V2/V3). Specifically, a simplified end-to-end flow is:
>
> 1. A TFLite/ONNX model is transformed to an executable binary file in ELF format by the NN graph compiler (designed by ArmChina)
> 2. An application loads the executable binary file to UMD and provides the input data.
> 3. UMD parses the binary and sends ioctls to KMD (open device, do memory allocation/mmap/free, submit the job descriptor).
> 4. KMD dispatches the job to NPU h/w, handles interrupts and updates the execution status.
> 5. UMD polls the status of the pre-scheduled job.
> 6. The application gets the output results.
>
> So...for the upstreaming,
>
> Q1: do you think our NPU driver is suitable for accel? If the answer is yes, which tree & branch should the patches be based on?
Hi Dejia,
Yes, it definitely sounds as a good fit to the accel subsystem.
Please base your patches on "drm-misc-next" branch in drm-misc repo:
https://anongit.freedesktop.org/git/drm/drm-misc.git
>
> Q2: in thread https://lore.kernel.org/lkml/ec547d33-214f-4952-aa33-c271e9edad63@kernel.org/ showing a similar case, Oded mentioned that:
>
> "If we would have upstreamed a new driver, the expectation would have been that we would use some drm mechanisms.", and
> "the minimal requirement is to use GEM/BOs for memory management operations".
>
> I guess those requirements are also applicable for the Zhouyi NPU KMD? Currently, the memory management (MM) in KMD is based on dma-mapping APIs, which handles both reserved CMA region(s) and SMMU mapped buffers, and supports the dma-buf framework. Maybe I should replace the implementations with DRM APIs.
Yes, those requirements definitely apply here.
>
> Q3: if you have looked at the KMD code, do you think I should make any other major change before submitting the first patch series? Thank you!
I took a quick glance. In general, it seems to be ok, but I noticed
two things related to the integration with drm/accel:
1. You us a scheduler for the job submission, which provides the
ability to defer jobs. In that case, I suggest to check if you can use
drm_sched instead of your own implementation. No point in re-inventing
the wheel.
2. You provide several memory zones for allocation of memory. I would
suggest here to look at using ttm as the memory manager instead of
re-implementing your own.
And please remove the IMPORTANT NOTICE at the end of your emails. I
would have to refrain from answering to further emails if that notice
remains.
Thanks,
Oded
>
> Thanks for your time and look forward to your reply~ 😊
>
> Best Regards,
> Dejia
> IMPORTANT NOTICE: The contents of this email and any attachments may be privileged and confidential. If you are not the intended recipient, please delete the email immediately. It is strictly prohibited to disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ©Arm Technology (China) Co., Ltd copyright and reserve all rights. 重要提示：本邮件（包括任何附件）可能含有专供明确的个人或目的使用的机密信息，并受法律保护。如果您并非该收件人，请立即删除此邮件。严禁通过任何渠道，以任何目的，向任何人披露、储存或复制邮件信息或者据此采取任何行动。感谢您的配合。 ©安谋科技（中国）有限公司 版权所有并保留一切权利。
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/7] arm64: mm: accelerate pagefault when VM_FAULT_BADACCESS
From: Kefeng Wang @ 2024-04-03 6:13 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <CAJuCfpHkrwPp0X65BuYS2SKAkWPJDMNWYPDO+Jr4SmuxoCEsZg@mail.gmail.com>
On 2024/4/3 13:30, Suren Baghdasaryan wrote:
> On Tue, Apr 2, 2024 at 10:19 PM Suren Baghdasaryan <surenb@google.com> wrote:
>>
>> On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>>
>>> The vm_flags of vma already checked under per-VMA lock, if it is a
>>> bad access, directly set fault to VM_FAULT_BADACCESS and handle error,
>>> no need to lock_mm_and_find_vma() and check vm_flags again, the latency
>>> time reduce 34% in lmbench 'lat_sig -P 1 prot lat_sig'.
>>
>> The change makes sense to me. Per-VMA lock is enough to keep
>> vma->vm_flags stable, so no need to retry with mmap_lock.
>>
>>>
>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>>
>> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
>>
>>> ---
>>> arch/arm64/mm/fault.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>>> index 9bb9f395351a..405f9aa831bd 100644
>>> --- a/arch/arm64/mm/fault.c
>>> +++ b/arch/arm64/mm/fault.c
>>> @@ -572,7 +572,9 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
>>>
>>> if (!(vma->vm_flags & vm_flags)) {
>>> vma_end_read(vma);
>>> - goto lock_mmap;
>>> + fault = VM_FAULT_BADACCESS;
>>> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
>>
>> nit: VMA_LOCK_SUCCESS accounting here seems correct to me but
>> unrelated to the main change. Either splitting into a separate patch
>> or mentioning this additional fixup in the changelog would be helpful.
>
> The above nit applies to all the patches after this one, so I won't
> comment on each one separately. If you decide to split or adjust the
> changelog please do that for each patch.
I will update the change log for each patch, thank for your review and
suggestion.
>
>>
>>> + goto done;
>>> }
>>> fault = handle_mm_fault(vma, addr, mm_flags | FAULT_FLAG_VMA_LOCK, regs);
>>> if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
>>> --
>>> 2.27.0
>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] irqchip/gic-v3-its: Don't need VSYNC if VMAPP with {V, Alloc}=={0, x}
From: Marc Zyngier @ 2024-04-03 6:00 UTC (permalink / raw)
To: Tangnianyao; +Cc: tglx, linux-arm-kernel, linux-kernel, guoyang2, wangwudi
In-Reply-To: <cc7a6d40-7fdc-196e-56bc-fe8a15ea29bb@huawei.com>
On Wed, 03 Apr 2024 03:18:51 +0100,
Tangnianyao <tangnianyao@huawei.com> wrote:
>
>
>
> On 4/2/2024 21:43, Marc Zyngier wrote:
> > On Tue, 02 Apr 2024 14:32:40 +0100,
> > Tangnianyao <tangnianyao@huawei.com> wrote:
> >>
> >>
> >> Thank you for quick fix, it would be great to remove this VSYNC. ITS handling VSYNC unmap
> >> vpeid may waste some time, trigger exception and needed to be
> >> handled.
> > Do you actually see an exception being delivered from this?
> >
> > In any case, feel free to respin the patch after having tested this
> > diff, with the commit message fixed and a Fixes: tag attached to it.
>
> In our developing implemenation, ITS would report RAS when doing vsync
> and reaching an invalid vpe table entry. It is reasonable to report RAS, right?
If a RAS error is the only reporting method you have, then I suspect
you don't have much of a choice (the pseudocode indicates an IMPDEF
SError for VSYNC). Shame this wasn't caught earlier.
> It just reports, and kernel can still run normally regardless of
> this RAS message.
That really depends on the policy behind RAS errors.
Looking forward to your respinning of this patch.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/7] x86: mm: accelerate pagefault when badaccess
From: Suren Baghdasaryan @ 2024-04-03 5:59 UTC (permalink / raw)
To: Kefeng Wang
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20240402075142.196265-8-wangkefeng.wang@huawei.com>
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly handle error and return, there is no need to
> lock_mm_and_find_vma() and check vm_flags again.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Looks safe to me.
Using (mm != NULL) to indicate that we are holding mmap_lock is not
ideal but I guess that works.
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> ---
> arch/x86/mm/fault.c | 23 ++++++++++++++---------
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index a4cc20d0036d..67b18adc75dd 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -866,14 +866,17 @@ bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
>
> static void
> __bad_area(struct pt_regs *regs, unsigned long error_code,
> - unsigned long address, u32 pkey, int si_code)
> + unsigned long address, struct mm_struct *mm,
> + struct vm_area_struct *vma, u32 pkey, int si_code)
> {
> - struct mm_struct *mm = current->mm;
> /*
> * Something tried to access memory that isn't in our memory map..
> * Fix it, but check if it's kernel or user first..
> */
> - mmap_read_unlock(mm);
> + if (mm)
> + mmap_read_unlock(mm);
> + else
> + vma_end_read(vma);
>
> __bad_area_nosemaphore(regs, error_code, address, pkey, si_code);
> }
> @@ -897,7 +900,8 @@ static inline bool bad_area_access_from_pkeys(unsigned long error_code,
>
> static noinline void
> bad_area_access_error(struct pt_regs *regs, unsigned long error_code,
> - unsigned long address, struct vm_area_struct *vma)
> + unsigned long address, struct mm_struct *mm,
> + struct vm_area_struct *vma)
> {
> /*
> * This OSPKE check is not strictly necessary at runtime.
> @@ -927,9 +931,9 @@ bad_area_access_error(struct pt_regs *regs, unsigned long error_code,
> */
> u32 pkey = vma_pkey(vma);
>
> - __bad_area(regs, error_code, address, pkey, SEGV_PKUERR);
> + __bad_area(regs, error_code, address, mm, vma, pkey, SEGV_PKUERR);
> } else {
> - __bad_area(regs, error_code, address, 0, SEGV_ACCERR);
> + __bad_area(regs, error_code, address, mm, vma, 0, SEGV_ACCERR);
> }
> }
>
> @@ -1357,8 +1361,9 @@ void do_user_addr_fault(struct pt_regs *regs,
> goto lock_mmap;
>
> if (unlikely(access_error(error_code, vma))) {
> - vma_end_read(vma);
> - goto lock_mmap;
> + bad_area_access_error(regs, error_code, address, NULL, vma);
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + return;
> }
> fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);
> if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
> @@ -1394,7 +1399,7 @@ void do_user_addr_fault(struct pt_regs *regs,
> * we can handle it..
> */
> if (unlikely(access_error(error_code, vma))) {
> - bad_area_access_error(regs, error_code, address, vma);
> + bad_area_access_error(regs, error_code, address, mm, vma);
> return;
> }
>
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7603: add debugfs attr for disabling frames buffering
From: Rafał Miłecki @ 2024-04-03 4:40 UTC (permalink / raw)
To: Shengyu Qu, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang
Cc: Kalle Valo, Matthias Brugger, AngeloGioacchino Del Regno,
linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
openwrt-devel, Rafał Miłecki
In-Reply-To: <TY3P286MB261180E5A3A3A11351441DEC983E2@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM>
On 2.04.2024 18:54, Shengyu Qu wrote:
> Maybe we could disable frames buffering by default until it is fixed?
Please check commit description:
"If this solution yields a success we can make this feature disabled by default."
> Also, maybe we could do more tests on newer models such as mt7986/81 to
> make this patch benefit more models?
Can you point me to the mt7915 driver buffering code? I clearly missed that.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu-v3: Free MSIs in case of ENOMEM
From: Aleksandr Aprelkov @ 2024-04-03 5:37 UTC (permalink / raw)
To: Will Deacon
Cc: Aleksandr Aprelkov, Robin Murphy, Joerg Roedel, Jason Gunthorpe,
Nicolin Chen, Michael Shavit, Lu Baolu, Marc Zyngier,
linux-arm-kernel, iommu, linux-kernel
If devm_add_action() returns ENOMEM, then MSIs allocated but
not freed on teardown.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 166bdbd23161 ("iommu/arm-smmu: Add support for MSI on SMMUv3")
Signed-off-by: Aleksandr Aprelkov <aaprelkov@usergate.com>
---
v2: Use appropriate function for registration failure as
Jonathan Cameron <Jonathan.Cameron@Huawei.com> suggested.
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 41f93c3ab160..8800af041e5f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3402,7 +3402,9 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu)
smmu->priq.q.irq = msi_get_virq(dev, PRIQ_MSI_INDEX);
/* Add callback to free MSIs on teardown */
- devm_add_action(dev, arm_smmu_free_msis, dev);
+ ret = devm_add_action_or_reset(dev, arm_smmu_free_msis, dev);
+ if (ret)
+ dev_warn(dev, "failed to add free MSIs callback - falling back to wired irqs\n");
}
static void arm_smmu_setup_unique_irqs(struct arm_smmu_device *smmu)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 5/7] riscv: mm: accelerate pagefault when badaccess
From: Suren Baghdasaryan @ 2024-04-03 5:37 UTC (permalink / raw)
To: Kefeng Wang
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20240402075142.196265-6-wangkefeng.wang@huawei.com>
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly handle error and return, there is no need to
> lock_mm_and_find_vma() and check vm_flags again.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> ---
> arch/riscv/mm/fault.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index 3ba1d4dde5dd..b3fcf7d67efb 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -292,7 +292,10 @@ void handle_page_fault(struct pt_regs *regs)
>
> if (unlikely(access_error(cause, vma))) {
> vma_end_read(vma);
> - goto lock_mmap;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + tsk->thread.bad_cause = SEGV_ACCERR;
> + bad_area_nosemaphore(regs, code, addr);
> + return;
> }
>
> fault = handle_mm_fault(vma, addr, flags | FAULT_FLAG_VMA_LOCK, regs);
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-03 5:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <4b1380a8-0136-4395-ba42-9bcff2e1bdb0@kernel.org>
On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> > On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> >> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> >>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> >>> contain the MAC Address programmed in the eFuse. Add compatible for
> >>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> >>> registers within the System Controller device-tree node. The default MAC
> >>> Address for the interface corresponding to the first MAC port will be set
> >>> to the value programmed in the eFuse.
> >>>
> >>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >>> ---
> >>>
> >>> This patch is based on linux-next tagged next-20240402.
> >>
> >> Where is the DTS using it?
> >
> > The current implementation in the device-tree for older TI K3 SoCs is as
> > follows:
> >
> > cpsw_port1: port@1 {
> > reg = <1>;
> > ti,mac-only;
> > label = "port1";
> > phys = <&phy_gmii_sel 1>;
> > mac-address = [00 00 00 00 00 00];
> > ti,syscon-efuse = <&wkup_conf 0x200>;
> > };
> >
> > The "ti,syscon-efuse" property passes the reference to the System
> > Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> > within the CTRL_MMR space.
>
> Please reference upstream DTS or lore link to patch under review.
An example of the existing implementation in the device-tree for AM64x
is:
https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
It uses:
ti,syscon-efuse = <&main_conf 0x200>;
and "main_conf" node is defined at:
https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
Regards,
Siddharth.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/7] powerpc: mm: accelerate pagefault when badaccess
From: Suren Baghdasaryan @ 2024-04-03 5:34 UTC (permalink / raw)
To: Kefeng Wang
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20240402075142.196265-5-wangkefeng.wang@huawei.com>
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly handle error and return, there is no need to
> lock_mm_and_find_vma() and check vm_flags again.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Code-wise looks correct to me and almost identical to x86 change but
someone with more experience with this architecture should review.
> ---
> arch/powerpc/mm/fault.c | 33 ++++++++++++++++++++-------------
> 1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 53335ae21a40..215690452495 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -71,23 +71,26 @@ static noinline int bad_area_nosemaphore(struct pt_regs *regs, unsigned long add
> return __bad_area_nosemaphore(regs, address, SEGV_MAPERR);
> }
>
> -static int __bad_area(struct pt_regs *regs, unsigned long address, int si_code)
> +static int __bad_area(struct pt_regs *regs, unsigned long address, int si_code,
> + struct mm_struct *mm, struct vm_area_struct *vma)
> {
> - struct mm_struct *mm = current->mm;
>
> /*
> * Something tried to access memory that isn't in our memory map..
> * Fix it, but check if it's kernel or user first..
> */
> - mmap_read_unlock(mm);
> + if (mm)
> + mmap_read_unlock(mm);
> + else
> + vma_end_read(vma);
>
> return __bad_area_nosemaphore(regs, address, si_code);
> }
>
> static noinline int bad_access_pkey(struct pt_regs *regs, unsigned long address,
> + struct mm_struct *mm,
> struct vm_area_struct *vma)
> {
> - struct mm_struct *mm = current->mm;
> int pkey;
>
> /*
> @@ -109,7 +112,10 @@ static noinline int bad_access_pkey(struct pt_regs *regs, unsigned long address,
> */
> pkey = vma_pkey(vma);
>
> - mmap_read_unlock(mm);
> + if (mm)
> + mmap_read_unlock(mm);
> + else
> + vma_end_read(vma);
>
> /*
> * If we are in kernel mode, bail out with a SEGV, this will
> @@ -124,9 +130,10 @@ static noinline int bad_access_pkey(struct pt_regs *regs, unsigned long address,
> return 0;
> }
>
> -static noinline int bad_access(struct pt_regs *regs, unsigned long address)
> +static noinline int bad_access(struct pt_regs *regs, unsigned long address,
> + struct mm_struct *mm, struct vm_area_struct *vma)
> {
> - return __bad_area(regs, address, SEGV_ACCERR);
> + return __bad_area(regs, address, SEGV_ACCERR, mm, vma);
> }
>
> static int do_sigbus(struct pt_regs *regs, unsigned long address,
> @@ -479,13 +486,13 @@ static int ___do_page_fault(struct pt_regs *regs, unsigned long address,
>
> if (unlikely(access_pkey_error(is_write, is_exec,
> (error_code & DSISR_KEYFAULT), vma))) {
> - vma_end_read(vma);
> - goto lock_mmap;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + return bad_access_pkey(regs, address, NULL, vma);
> }
>
> if (unlikely(access_error(is_write, is_exec, vma))) {
> - vma_end_read(vma);
> - goto lock_mmap;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + return bad_access(regs, address, NULL, vma);
> }
>
> fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);
> @@ -521,10 +528,10 @@ static int ___do_page_fault(struct pt_regs *regs, unsigned long address,
>
> if (unlikely(access_pkey_error(is_write, is_exec,
> (error_code & DSISR_KEYFAULT), vma)))
> - return bad_access_pkey(regs, address, vma);
> + return bad_access_pkey(regs, address, mm, vma);
>
> if (unlikely(access_error(is_write, is_exec, vma)))
> - return bad_access(regs, address);
> + return bad_access(regs, address, mm, vma);
>
> /*
> * If for any reason at all we couldn't handle the fault,
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/7] arm: mm: accelerate pagefault when VM_FAULT_BADACCESS
From: Suren Baghdasaryan @ 2024-04-03 5:30 UTC (permalink / raw)
To: Kefeng Wang
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20240402075142.196265-4-wangkefeng.wang@huawei.com>
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly set fault to VM_FAULT_BADACCESS and handle error,
> so no need to lock_mm_and_find_vma() and check vm_flags again.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> ---
> arch/arm/mm/fault.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 439dc6a26bb9..5c4b417e24f9 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -294,7 +294,9 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
>
> if (!(vma->vm_flags & vm_flags)) {
> vma_end_read(vma);
> - goto lock_mmap;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + fault = VM_FAULT_BADACCESS;
> + goto bad_area;
> }
> fault = handle_mm_fault(vma, addr, flags | FAULT_FLAG_VMA_LOCK, regs);
> if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/7] arm64: mm: accelerate pagefault when VM_FAULT_BADACCESS
From: Suren Baghdasaryan @ 2024-04-03 5:30 UTC (permalink / raw)
To: Kefeng Wang
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <CAJuCfpGpKup6AOPY08p35S2S+D4ch5XjEB=FM-n9-kU8dZXS5Q@mail.gmail.com>
On Tue, Apr 2, 2024 at 10:19 PM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> >
> > The vm_flags of vma already checked under per-VMA lock, if it is a
> > bad access, directly set fault to VM_FAULT_BADACCESS and handle error,
> > no need to lock_mm_and_find_vma() and check vm_flags again, the latency
> > time reduce 34% in lmbench 'lat_sig -P 1 prot lat_sig'.
>
> The change makes sense to me. Per-VMA lock is enough to keep
> vma->vm_flags stable, so no need to retry with mmap_lock.
>
> >
> > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
>
> > ---
> > arch/arm64/mm/fault.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index 9bb9f395351a..405f9aa831bd 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -572,7 +572,9 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> >
> > if (!(vma->vm_flags & vm_flags)) {
> > vma_end_read(vma);
> > - goto lock_mmap;
> > + fault = VM_FAULT_BADACCESS;
> > + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
>
> nit: VMA_LOCK_SUCCESS accounting here seems correct to me but
> unrelated to the main change. Either splitting into a separate patch
> or mentioning this additional fixup in the changelog would be helpful.
The above nit applies to all the patches after this one, so I won't
comment on each one separately. If you decide to split or adjust the
changelog please do that for each patch.
>
> > + goto done;
> > }
> > fault = handle_mm_fault(vma, addr, mm_flags | FAULT_FLAG_VMA_LOCK, regs);
> > if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
> > --
> > 2.27.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [RESEND PATCH v3] perf/marvell: Marvell PEM performance monitor support
From: Gowthami Thiagarajan @ 2024-04-03 5:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: will@kernel.org, mark.rutland@arm.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sunil Kovvuri Goutham,
George Cherian, Linu Cherian
In-Reply-To: <695199ba-c71d-43ec-8305-8f52488b8c5d@lunn.ch>
Hi Andrew,
Please find the responses inline.
Thanks,
Gowthami
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Wednesday, March 27, 2024 6:41 PM
> To: Gowthami Thiagarajan <gthiagarajan@marvell.com>
> Cc: will@kernel.org; mark.rutland@arm.com; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Sunil Kovvuri Goutham <sgoutham@marvell.com>; George Cherian
> <gcherian@marvell.com>; Linu Cherian <lcherian@marvell.com>
> Subject: [EXTERNAL] Re: [RESEND PATCH v3] perf/marvell: Marvell PEM performance monitor support
>
> On Wed, Mar 27, 2024 at 12:51:17PM +0530, Gowthami Thiagarajan wrote:
> > PCI Express Interface PMU includes various performance counters
> > to monitor the data that is transmitted over the PCIe link. The
> > counters track various inbound and outbound transactions which
> > includes separate counters for posted/non-posted/completion TLPs.
> > Also, inbound and outbound memory read requests along with their
> > latencies can also be monitored. Address Translation Services(ATS)events
> > such as ATS Translation, ATS Page Request, ATS Invalidation along with
> > their corresponding latencies are also supported.
> >
> > The performance counters are 64 bits wide.
> >
> > For instance,
> > perf stat -e ib_tlp_pr <workload>
> > tracks the inbound posted TLPs for the workload.
> >
> > Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com>
> > ---
> > v2->v3 changes:
> > - Dropped device tree support as the acpi table based probing is used.
>
> So people using DT cannot use this driver? Can they use the PCIe
> interface?
>
> There does not appear to be any ACPI binding, it is not reading any
> properties from ACPI tables etc. So the DT binding should be
> trivial...
The ACPI bindings are present in the driver. Have the ACPI ID MRVL000E tied here
and the resources are fetched from the ACPI table.
static const struct acpi_device_id pem_pmu_acpi_match[] = {
{"MRVL000E", 0},
{},
};
MODULE_DEVICE_TABLE(acpi, pem_pmu_acpi_match);
base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
>
> > index 000000000000..d4175483b982
> > --- /dev/null
> > +++ b/drivers/perf/marvell_pem_pmu.c
> > @@ -0,0 +1,428 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Marvell PEM(PCIe RC) Performance Monitor Driver
> > + *
> > + * Copyright (C) 2024 Marvell.
> > + */
> > +
> > +#include <linux/acpi.h>
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_device.h>
>
> Why do you need these header files? I don't see any calls to of_
> functions.
>
These header files are not needed. I will remove them in the next version.
> > +static int pem_perf_probe(struct platform_device *pdev)
> > +{
> > + struct pem_pmu *pem_pmu;
> > + struct resource *res;
> > + void __iomem *base;
> > + char *name;
> > + int ret;
> > +
> > + pem_pmu = devm_kzalloc(&pdev->dev, sizeof(*pem_pmu), GFP_KERNEL);
> > + if (!pem_pmu)
> > + return -ENOMEM;
> > +
> > + pem_pmu->dev = &pdev->dev;
> > + platform_set_drvdata(pdev, pem_pmu);
> > +
> > + base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> > + if (IS_ERR(base))
> > + return PTR_ERR(base);
> > +
> > + pem_pmu->base = base;
> > +
> > + pem_pmu->pmu = (struct pmu) {
> > + .module = THIS_MODULE,
> > + .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
> > + .task_ctx_nr = perf_invalid_context,
> > + .attr_groups = pem_perf_attr_groups,
> > + .event_init = pem_perf_event_init,
> > + .add = pem_perf_event_add,
> > + .del = pem_perf_event_del,
> > + .start = pem_perf_event_start,
> > + .stop = pem_perf_event_stop,
> > + .read = pem_perf_event_update,
> > + };
> > +
> > + /* Choose this cpu to collect perf data */
> > + pem_pmu->cpu = raw_smp_processor_id();
> > +
> > + name = devm_kasprintf(pem_pmu->dev, GFP_KERNEL, "mrvl_pcie_rc_pmu_%llx",
> > + res->start);
> > + if (!name)
> > + return -ENOMEM;
> > +
> > + cpuhp_state_add_instance_nocalls
> > + (CPUHP_AP_PERF_ARM_MARVELL_PEM_ONLINE,
> > + &pem_pmu->node);
> > +
> > + ret = perf_pmu_register(&pem_pmu->pmu, name, -1);
> > + if (ret)
> > + goto error;
> > +
> > + pr_info("Marvell PEM(PCIe RC) PMU Driver for pem@%llx\n", res->start);
>
> Please don't spam the kernel log like this.
Will get this message removed.
>
> Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/7] arm64: mm: accelerate pagefault when VM_FAULT_BADACCESS
From: Suren Baghdasaryan @ 2024-04-03 5:19 UTC (permalink / raw)
To: Kefeng Wang
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20240402075142.196265-3-wangkefeng.wang@huawei.com>
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly set fault to VM_FAULT_BADACCESS and handle error,
> no need to lock_mm_and_find_vma() and check vm_flags again, the latency
> time reduce 34% in lmbench 'lat_sig -P 1 prot lat_sig'.
The change makes sense to me. Per-VMA lock is enough to keep
vma->vm_flags stable, so no need to retry with mmap_lock.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> ---
> arch/arm64/mm/fault.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 9bb9f395351a..405f9aa831bd 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -572,7 +572,9 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
>
> if (!(vma->vm_flags & vm_flags)) {
> vma_end_read(vma);
> - goto lock_mmap;
> + fault = VM_FAULT_BADACCESS;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
nit: VMA_LOCK_SUCCESS accounting here seems correct to me but
unrelated to the main change. Either splitting into a separate patch
or mentioning this additional fixup in the changelog would be helpful.
> + goto done;
> }
> fault = handle_mm_fault(vma, addr, mm_flags | FAULT_FLAG_VMA_LOCK, regs);
> if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 2/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY binding
From: Hongxing Zhu @ 2024-04-03 5:16 UTC (permalink / raw)
To: Conor Dooley, Frank Li
Cc: vkoul@kernel.org, kishon@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de,
imx@lists.linux.dev
In-Reply-To: <20240402-anemic-aerospace-bc428fff280c@spud>
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: 2024年4月3日 2:17
> To: Frank Li <frank.li@nxp.com>
> Cc: Hongxing Zhu <hongxing.zhu@nxp.com>; vkoul@kernel.org;
> kishon@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> conor+dt@kernel.org; linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; imx@lists.linux.dev
> Subject: Re: [PATCH v2 2/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY
> binding
>
> On Tue, Apr 02, 2024 at 10:23:45AM -0400, Frank Li wrote:
> > On Tue, Apr 02, 2024 at 01:45:03PM +0800, Richard Zhu wrote:
> > > Add i.MX8QM and i.MX8QXP HSIO SerDes PHY binding.
> > > - Use the controller ID to specify which controller is binded to the
> > > PHY.
> > > - Introduce one HSIO configuration, mandatory required to set
> > > "PCIE_AB_SELECT" and "PHY_X1_EPCS_SEL" during the initialization.
> > >
> > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> >
> > You missed all conor's comments.
> > Please double check v1's comments.
>
Hi Frank:
Thanks a lot for your reminder.
It's my fault that I missed this email.
> > > + fsl,refclk-pad-mode:
> > > + description: |
> > > + Specifies the mode of the refclk pad used. It can be UNUSED(PHY
> > > + refclock is derived from SoC internal source), INPUT(PHY refclock
> > > + is provided externally via the refclk pad) or OUTPUT(PHY refclock
> > > + is derived from SoC internal source and provided on the refclk pad).
> > > + Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants
> > > + to be used.
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + enum: [ 0, 1, 2 ]
> >
> > I remember needn't enum because there are header file.
>
> Yah, specifically my comments about this property were missed and were
> probably the most meaningful comments I left.
Hi Conor:
I'm so sorry about it.
I made the mistake missing your last review email.
Would follow your comments in next review cycle.
Best Regards
Richard Zhu
>
> Thanks for the reminder Frank.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/7] arm64: mm: cleanup __do_page_fault()
From: Suren Baghdasaryan @ 2024-04-03 5:11 UTC (permalink / raw)
To: Kefeng Wang
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20240402075142.196265-2-wangkefeng.wang@huawei.com>
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> The __do_page_fault() only check vma->flags and call handle_mm_fault(),
> and only called by do_page_fault(), let's squash it into do_page_fault()
> to cleanup code.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> ---
> arch/arm64/mm/fault.c | 27 +++++++--------------------
> 1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 8251e2fea9c7..9bb9f395351a 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -486,25 +486,6 @@ static void do_bad_area(unsigned long far, unsigned long esr,
> }
> }
>
> -#define VM_FAULT_BADMAP ((__force vm_fault_t)0x010000)
> -#define VM_FAULT_BADACCESS ((__force vm_fault_t)0x020000)
> -
> -static vm_fault_t __do_page_fault(struct mm_struct *mm,
> - struct vm_area_struct *vma, unsigned long addr,
> - unsigned int mm_flags, unsigned long vm_flags,
> - struct pt_regs *regs)
> -{
> - /*
> - * Ok, we have a good vm_area for this memory access, so we can handle
> - * it.
> - * Check that the permissions on the VMA allow for the fault which
> - * occurred.
> - */
> - if (!(vma->vm_flags & vm_flags))
> - return VM_FAULT_BADACCESS;
> - return handle_mm_fault(vma, addr, mm_flags, regs);
> -}
> -
> static bool is_el0_instruction_abort(unsigned long esr)
> {
> return ESR_ELx_EC(esr) == ESR_ELx_EC_IABT_LOW;
> @@ -519,6 +500,9 @@ static bool is_write_abort(unsigned long esr)
> return (esr & ESR_ELx_WNR) && !(esr & ESR_ELx_CM);
> }
>
> +#define VM_FAULT_BADMAP ((__force vm_fault_t)0x010000)
> +#define VM_FAULT_BADACCESS ((__force vm_fault_t)0x020000)
> +
> static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> struct pt_regs *regs)
> {
> @@ -617,7 +601,10 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> goto done;
> }
>
> - fault = __do_page_fault(mm, vma, addr, mm_flags, vm_flags, regs);
> + if (!(vma->vm_flags & vm_flags))
> + fault = VM_FAULT_BADACCESS;
> + else
> + fault = handle_mm_fault(vma, addr, mm_flags, regs);
>
> /* Quick path to respond to signals */
> if (fault_signal_pending(fault, regs)) {
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] ASoC: sunxi: sun4i-i2s: Support 32-bit audio formats
From: John Watts @ 2024-04-03 3:47 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland
Cc: linux-sound, linux-arm-kernel, linux-sunxi, linux-kernel,
John Watts
The I2S cores used in the H3 onwards support 32-bit sample rates.
Support these by adding a per-variant PCM format list.
Signed-off-by: John Watts <contact@jookia.org>
---
This patch enables support for 32-bit audio in the sunxi I2S driver.
I have only tested this on the Allwinner T113 but I'm fairly
certain it will work on older boards.
---
Changes in v2:
- Specify PCM formats for each variant instead of failing in hw_params
- Link to v1: https://lore.kernel.org/r/20240326-sunxi_s32-v1-1-899f71dcb1e6@jookia.org
---
sound/soc/sunxi/sun4i-i2s.c | 33 ++++++++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index a736f632bf0b..59830f2a0d30 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -156,6 +156,7 @@ struct sun4i_i2s;
/**
* struct sun4i_i2s_quirks - Differences between SoC variants.
* @has_reset: SoC needs reset deasserted.
+ * @pcm_formats: available PCM formats
* @reg_offset_txdata: offset of the tx fifo.
* @sun4i_i2s_regmap: regmap config to use.
* @field_clkdiv_mclk_en: regmap field to enable mclk output.
@@ -175,6 +176,7 @@ struct sun4i_i2s;
*/
struct sun4i_i2s_quirks {
bool has_reset;
+ snd_pcm_format_t pcm_formats;
unsigned int reg_offset_txdata; /* TX FIFO */
const struct regmap_config *sun4i_i2s_regmap;
@@ -1092,8 +1094,18 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
return 0;
}
+static int sun4i_i2s_dai_startup(struct snd_pcm_substream *sub, struct snd_soc_dai *dai)
+{
+ struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+ struct snd_pcm_runtime *runtime = sub->runtime;
+
+ return snd_pcm_hw_constraint_mask64(runtime, SNDRV_PCM_HW_PARAM_FORMAT,
+ i2s->variant->pcm_formats);
+}
+
static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
.probe = sun4i_i2s_dai_probe,
+ .startup = sun4i_i2s_dai_startup,
.hw_params = sun4i_i2s_hw_params,
.set_fmt = sun4i_i2s_set_fmt,
.set_sysclk = sun4i_i2s_set_sysclk,
@@ -1101,9 +1113,10 @@ static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
.trigger = sun4i_i2s_trigger,
};
-#define SUN4I_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
- SNDRV_PCM_FMTBIT_S20_LE | \
- SNDRV_PCM_FMTBIT_S24_LE)
+#define SUN4I_FORMATS_ALL (SNDRV_PCM_FMTBIT_S16_LE | \
+ SNDRV_PCM_FMTBIT_S20_LE | \
+ SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE)
static struct snd_soc_dai_driver sun4i_i2s_dai = {
.capture = {
@@ -1111,14 +1124,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
.channels_min = 1,
.channels_max = 8,
.rates = SNDRV_PCM_RATE_8000_192000,
- .formats = SUN4I_FORMATS,
+ .formats = SUN4I_FORMATS_ALL,
},
.playback = {
.stream_name = "Playback",
.channels_min = 1,
.channels_max = 8,
.rates = SNDRV_PCM_RATE_8000_192000,
- .formats = SUN4I_FORMATS,
+ .formats = SUN4I_FORMATS_ALL,
},
.ops = &sun4i_i2s_dai_ops,
.symmetric_rate = 1,
@@ -1340,8 +1353,12 @@ static int sun4i_i2s_runtime_suspend(struct device *dev)
return 0;
}
+#define SUN4I_FORMATS_A10 (SUN4I_FORMATS_ALL & ~SNDRV_PCM_FMTBIT_S32_LE)
+#define SUN4I_FORMATS_H3 SUN4I_FORMATS_ALL
+
static const struct sun4i_i2s_quirks sun4i_a10_i2s_quirks = {
.has_reset = false,
+ .pcm_formats = SUN4I_FORMATS_A10,
.reg_offset_txdata = SUN4I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
@@ -1360,6 +1377,7 @@ static const struct sun4i_i2s_quirks sun4i_a10_i2s_quirks = {
static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
.has_reset = true,
+ .pcm_formats = SUN4I_FORMATS_A10,
.reg_offset_txdata = SUN4I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
@@ -1383,6 +1401,7 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
*/
static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
+ .pcm_formats = SUN4I_FORMATS_A10,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
@@ -1401,6 +1420,7 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
.has_reset = true,
+ .pcm_formats = SUN4I_FORMATS_H3,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun8i_i2s_regmap_config,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
@@ -1419,6 +1439,7 @@ static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
static const struct sun4i_i2s_quirks sun50i_a64_codec_i2s_quirks = {
.has_reset = true,
+ .pcm_formats = SUN4I_FORMATS_H3,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
@@ -1437,6 +1458,7 @@ static const struct sun4i_i2s_quirks sun50i_a64_codec_i2s_quirks = {
static const struct sun4i_i2s_quirks sun50i_h6_i2s_quirks = {
.has_reset = true,
+ .pcm_formats = SUN4I_FORMATS_H3,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun50i_h6_i2s_regmap_config,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
@@ -1455,6 +1477,7 @@ static const struct sun4i_i2s_quirks sun50i_h6_i2s_quirks = {
static const struct sun4i_i2s_quirks sun50i_r329_i2s_quirks = {
.has_reset = true,
+ .pcm_formats = SUN4I_FORMATS_H3,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun50i_h6_i2s_regmap_config,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
---
base-commit: 13227c2baa6b345451128828c9c2b0ec3868bd0d
change-id: 20240326-sunxi_s32-f2ab25b8e688
Best regards,
--
John Watts <contact@jookia.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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