* [PATCH v6] soc: qcom: add l2 cache perf events driver
From: Neil Leeder @ 2016-09-21 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Adds perf events support for L2 cache PMU.
The L2 cache PMU driver is named 'l2cache_0' and can be used
with perf events to profile L2 events such as cache hits
and misses.
Signed-off-by: Neil Leeder <nleeder@codeaurora.org>
---
v6: restore accidentally dropped Kconfig dependencies
v5:
Fold the header and l2-accessors into .c file
Use multi-instance framework for hotplug
Change terminology from slice to cluster for clarity
Remove unnecessary rmw sequence for enable registers
Use prev_count in hwc rather than in slice
Enforce all events in same group on same CPU
Add comments, rename variables for clarity
v4:
Replace notifier with hotplug statemachine
Allocate PMU struct dynamically
v3:
Remove exports from l2-accessors
Change l2-accessors Kconfig to make it not user-selectable
Reorder and remove unnecessary includes
v2:
Add the l2-accessors patch to this patchset, previously posted separately.
Remove sampling and per-task functionality for this uncore PMU.
Use cpumask to replace code which filtered events to one cpu per slice.
Replace manual event filtering with filter_match callback.
Use a separate used_mask for event groups.
Add hotplug notifier for CPU and irq migration.
Remove extraneous synchronisation instructions.
Other miscellaneous cleanup.
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/perf_event_l2.c | 948 +++++++++++++++++++++++++++++++++++++++
include/linux/cpuhotplug.h | 1 +
4 files changed, 959 insertions(+)
create mode 100644 drivers/soc/qcom/perf_event_l2.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 461b387..3fa27a8 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -10,6 +10,15 @@ config QCOM_GSBI
functions for connecting the underlying serial UART, SPI, and I2C
devices to the output pins.
+config QCOM_PERF_EVENTS_L2
+ bool "Qualcomm Technologies L2-cache perf events"
+ depends on ARCH_QCOM && ARM64 && HW_PERF_EVENTS && ACPI
+ help
+ Provides support for the L2 cache performance monitor unit (PMU)
+ in Qualcomm Technologies processors.
+ Adds the L2 cache PMU into the perf events subsystem for
+ monitoring L2 cache events.
+
config QCOM_PM
bool "Qualcomm Power Management"
depends on ARCH_QCOM && !ARM64
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index fdd664e..4c9df3b 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
+obj-$(CONFIG_QCOM_PERF_EVENTS_L2) += perf_event_l2.o
obj-$(CONFIG_QCOM_PM) += spm.o
obj-$(CONFIG_QCOM_SMD) += smd.o
obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
diff --git a/drivers/soc/qcom/perf_event_l2.c b/drivers/soc/qcom/perf_event_l2.c
new file mode 100644
index 0000000..bbf47c9
--- /dev/null
+++ b/drivers/soc/qcom/perf_event_l2.c
@@ -0,0 +1,948 @@
+/* Copyright (c) 2015,2016 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/acpi.h>
+#include <linux/interrupt.h>
+#include <linux/perf_event.h>
+#include <linux/platform_device.h>
+
+#define MAX_L2_CTRS 9
+
+#define L2PMCR_NUM_EV_SHIFT 11
+#define L2PMCR_NUM_EV_MASK 0x1F
+
+#define L2PMCR 0x400
+#define L2PMCNTENCLR 0x403
+#define L2PMCNTENSET 0x404
+#define L2PMINTENCLR 0x405
+#define L2PMINTENSET 0x406
+#define L2PMOVSCLR 0x407
+#define L2PMOVSSET 0x408
+#define L2PMCCNTCR 0x409
+#define L2PMCCNTR 0x40A
+#define L2PMCCNTSR 0x40C
+#define L2PMRESR 0x410
+#define IA_L2PMXEVCNTCR_BASE 0x420
+#define IA_L2PMXEVCNTR_BASE 0x421
+#define IA_L2PMXEVFILTER_BASE 0x423
+#define IA_L2PMXEVTYPER_BASE 0x424
+
+#define IA_L2_REG_OFFSET 0x10
+
+#define L2PMXEVFILTER_SUFILTER_ALL 0x000E0000
+#define L2PMXEVFILTER_ORGFILTER_IDINDEP 0x00000004
+#define L2PMXEVFILTER_ORGFILTER_ALL 0x00000003
+
+#define L2PM_CC_ENABLE 0x80000000
+
+#define L2EVTYPER_REG_SHIFT 3
+
+#define L2PMRESR_GROUP_BITS 8
+#define L2PMRESR_GROUP_MASK GENMASK(7, 0)
+
+#define L2CYCLE_CTR_BIT 31
+#define L2CYCLE_CTR_RAW_CODE 0xFE
+
+#define L2PMCR_RESET_ALL 0x6
+#define L2PMCR_COUNTERS_ENABLE 0x1
+#define L2PMCR_COUNTERS_DISABLE 0x0
+
+#define L2PMRESR_EN ((u64)1 << 63)
+
+#define L2_EVT_MASK 0x00000FFF
+#define L2_EVT_CODE_MASK 0x00000FF0
+#define L2_EVT_GRP_MASK 0x0000000F
+#define L2_EVT_CODE_SHIFT 4
+#define L2_EVT_GRP_SHIFT 0
+
+#define L2_EVT_CODE(event) (((event) & L2_EVT_CODE_MASK) >> L2_EVT_CODE_SHIFT)
+#define L2_EVT_GROUP(event) (((event) & L2_EVT_GRP_MASK) >> L2_EVT_GRP_SHIFT)
+
+#define L2_EVT_GROUP_MAX 7
+
+#define L2_MAX_PERIOD U32_MAX
+#define L2_CNT_PERIOD (U32_MAX - GENMASK(26, 0))
+
+#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
+#define L2CPUSRDR_EL1 S3_3_c15_c0_7
+
+static DEFINE_RAW_SPINLOCK(l2_access_lock);
+
+/**
+ * set_l2_indirect_reg: write value to an L2 register
+ * @reg: Address of L2 register.
+ * @value: Value to be written to register.
+ *
+ * Use architecturally required barriers for ordering between system register
+ * accesses
+ */
+static void set_l2_indirect_reg(u64 reg, u64 val)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&l2_access_lock, flags);
+ write_sysreg(reg, L2CPUSRSELR_EL1);
+ isb();
+ write_sysreg(val, L2CPUSRDR_EL1);
+ isb();
+ raw_spin_unlock_irqrestore(&l2_access_lock, flags);
+}
+
+/**
+ * get_l2_indirect_reg: read an L2 register value
+ * @reg: Address of L2 register.
+ *
+ * Use architecturally required barriers for ordering between system register
+ * accesses
+ */
+static u64 get_l2_indirect_reg(u64 reg)
+{
+ u64 val;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&l2_access_lock, flags);
+ write_sysreg(reg, L2CPUSRSELR_EL1);
+ isb();
+ val = read_sysreg(L2CPUSRDR_EL1);
+ raw_spin_unlock_irqrestore(&l2_access_lock, flags);
+
+ return val;
+}
+
+/*
+ * Aggregate PMU. Implements the core pmu functions and manages
+ * the hardware PMUs.
+ */
+struct l2cache_pmu {
+ struct hlist_node node;
+ u32 num_pmus;
+ struct pmu pmu;
+ int num_counters;
+ cpumask_t cpumask;
+ struct platform_device *pdev;
+};
+
+/*
+ * The cache is made up of one or more clusters, each cluster has its own PMU.
+ * Each cluster is associated with one or more CPUs.
+ * This structure represents one of the hardware PMUs.
+ *
+ * Events can be envisioned as a 2-dimensional array. Each column represents
+ * a group of events. There are 8 groups. Only one entry from each
+ * group can be in use at a time. When an event is assigned a counter
+ * by *_event_add(), the counter index is assigned to group_to_counter[group].
+ * This allows *filter_match() to detect and reject conflicting events in
+ * the same group.
+ * Events are specified as 0xCCG, where CC is 2 hex digits specifying
+ * the code (array row) and G specifies the group (column).
+ *
+ * In addition there is a cycle counter event specified by L2CYCLE_CTR_RAW_CODE
+ * which is outside the above scheme.
+ */
+struct hml2_pmu {
+ struct perf_event *events[MAX_L2_CTRS];
+ struct l2cache_pmu *l2cache_pmu;
+ DECLARE_BITMAP(used_counters, MAX_L2_CTRS);
+ DECLARE_BITMAP(used_groups, L2_EVT_GROUP_MAX + 1);
+ int group_to_counter[L2_EVT_GROUP_MAX + 1];
+ int irq;
+ /* The CPU that is used for collecting events on this cluster */
+ int on_cpu;
+ /* All the CPUs associated with this cluster */
+ cpumask_t cluster_cpus;
+ spinlock_t pmu_lock;
+};
+
+#define to_l2cache_pmu(p) (container_of(p, struct l2cache_pmu, pmu))
+
+static DEFINE_PER_CPU(struct hml2_pmu *, pmu_cluster);
+static u32 l2_cycle_ctr_idx;
+static u32 l2_counter_present_mask;
+
+static inline u32 idx_to_reg_bit(u32 idx)
+{
+ if (idx == l2_cycle_ctr_idx)
+ return BIT(L2CYCLE_CTR_BIT);
+
+ return BIT(idx);
+}
+
+static inline struct hml2_pmu *get_hml2_pmu(int cpu)
+{
+ return per_cpu(pmu_cluster, cpu);
+}
+
+static void hml2_pmu__reset_on_cluster(void *x)
+{
+ /* Reset all ctrs */
+ set_l2_indirect_reg(L2PMCR, L2PMCR_RESET_ALL);
+ set_l2_indirect_reg(L2PMCNTENCLR, l2_counter_present_mask);
+ set_l2_indirect_reg(L2PMINTENCLR, l2_counter_present_mask);
+ set_l2_indirect_reg(L2PMOVSCLR, l2_counter_present_mask);
+}
+
+static inline void hml2_pmu__reset(struct hml2_pmu *cluster)
+{
+ cpumask_t *mask = &cluster->cluster_cpus;
+
+ if (smp_call_function_any(mask, hml2_pmu__reset_on_cluster, NULL, 1))
+ dev_err(&cluster->l2cache_pmu->pdev->dev,
+ "Failed to reset on cluster with cpu %d\n",
+ cpumask_first(&cluster->cluster_cpus));
+}
+
+static inline void hml2_pmu__enable(void)
+{
+ set_l2_indirect_reg(L2PMCR, L2PMCR_COUNTERS_ENABLE);
+}
+
+static inline void hml2_pmu__disable(void)
+{
+ set_l2_indirect_reg(L2PMCR, L2PMCR_COUNTERS_DISABLE);
+}
+
+static inline void hml2_pmu__counter_set_value(u32 idx, u64 value)
+{
+ u32 counter_reg;
+
+ if (idx == l2_cycle_ctr_idx) {
+ set_l2_indirect_reg(L2PMCCNTR, value);
+ } else {
+ counter_reg = (idx * IA_L2_REG_OFFSET) + IA_L2PMXEVCNTR_BASE;
+ set_l2_indirect_reg(counter_reg, value & GENMASK(31, 0));
+ }
+}
+
+static inline u64 hml2_pmu__counter_get_value(u32 idx)
+{
+ u64 value;
+ u32 counter_reg;
+
+ if (idx == l2_cycle_ctr_idx) {
+ value = get_l2_indirect_reg(L2PMCCNTR);
+ } else {
+ counter_reg = (idx * IA_L2_REG_OFFSET) + IA_L2PMXEVCNTR_BASE;
+ value = get_l2_indirect_reg(counter_reg);
+ }
+
+ return value;
+}
+
+static inline void hml2_pmu__counter_enable(u32 idx)
+{
+ set_l2_indirect_reg(L2PMCNTENSET, idx_to_reg_bit(idx));
+}
+
+static inline void hml2_pmu__counter_disable(u32 idx)
+{
+ set_l2_indirect_reg(L2PMCNTENCLR, idx_to_reg_bit(idx));
+}
+
+static inline void hml2_pmu__counter_enable_interrupt(u32 idx)
+{
+ set_l2_indirect_reg(L2PMINTENSET, idx_to_reg_bit(idx));
+}
+
+static inline void hml2_pmu__counter_disable_interrupt(u32 idx)
+{
+ set_l2_indirect_reg(L2PMINTENCLR, idx_to_reg_bit(idx));
+}
+
+static inline void hml2_pmu__set_evccntcr(u32 val)
+{
+ set_l2_indirect_reg(L2PMCCNTCR, val);
+}
+
+static inline void hml2_pmu__set_evcntcr(u32 ctr, u32 val)
+{
+ u32 evtcr_reg = (ctr * IA_L2_REG_OFFSET) + IA_L2PMXEVCNTCR_BASE;
+
+ set_l2_indirect_reg(evtcr_reg, val);
+}
+
+static inline void hml2_pmu__set_evtyper(u32 ctr, u32 val)
+{
+ u32 evtype_reg = (ctr * IA_L2_REG_OFFSET) + IA_L2PMXEVTYPER_BASE;
+
+ set_l2_indirect_reg(evtype_reg, val);
+}
+
+static void hml2_pmu__set_resr(struct hml2_pmu *cluster,
+ u32 event_group, u32 event_cc)
+{
+ u64 field;
+ u64 resr_val;
+ u32 shift;
+ unsigned long flags;
+
+ shift = L2PMRESR_GROUP_BITS * event_group;
+ field = ((u64)(event_cc & L2PMRESR_GROUP_MASK) << shift) | L2PMRESR_EN;
+
+ spin_lock_irqsave(&cluster->pmu_lock, flags);
+
+ resr_val = get_l2_indirect_reg(L2PMRESR);
+ resr_val &= ~(L2PMRESR_GROUP_MASK << shift);
+ resr_val |= field;
+ set_l2_indirect_reg(L2PMRESR, resr_val);
+
+ spin_unlock_irqrestore(&cluster->pmu_lock, flags);
+}
+
+/*
+ * Hardware allows filtering of events based on the originating
+ * CPU. Turn this off by setting filter bits to allow events from
+ * all CPUS, subunits and ID independent events in this cluster.
+ */
+static inline void hml2_pmu__set_evfilter_sys_mode(u32 ctr)
+{
+ u32 reg = (ctr * IA_L2_REG_OFFSET) + IA_L2PMXEVFILTER_BASE;
+ u32 val = L2PMXEVFILTER_SUFILTER_ALL |
+ L2PMXEVFILTER_ORGFILTER_IDINDEP |
+ L2PMXEVFILTER_ORGFILTER_ALL;
+
+ set_l2_indirect_reg(reg, val);
+}
+
+static inline u32 hml2_pmu__getreset_ovsr(void)
+{
+ u32 result = get_l2_indirect_reg(L2PMOVSSET);
+
+ set_l2_indirect_reg(L2PMOVSCLR, result);
+ return result;
+}
+
+static inline bool hml2_pmu__has_overflowed(u32 ovsr)
+{
+ return !!(ovsr & l2_counter_present_mask);
+}
+
+static inline bool hml2_pmu__counter_has_overflowed(u32 ovsr, u32 idx)
+{
+ return !!(ovsr & idx_to_reg_bit(idx));
+}
+
+static void l2_cache__event_update_from_cluster(struct perf_event *event,
+ struct hml2_pmu *cluster)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ u64 delta64, prev, now;
+ u32 delta;
+ u32 idx = hwc->idx;
+
+ do {
+ prev = local64_read(&hwc->prev_count);
+ now = hml2_pmu__counter_get_value(idx);
+ } while (local64_cmpxchg(&hwc->prev_count, prev, now) != prev);
+
+ if (idx == l2_cycle_ctr_idx) {
+ /*
+ * The cycle counter is 64-bit so needs separate handling
+ * of 64-bit delta.
+ */
+ delta64 = now - prev;
+ local64_add(delta64, &event->count);
+ } else {
+ /*
+ * 32-bit counters need the unsigned 32-bit math to handle
+ * overflow and now < prev
+ */
+ delta = now - prev;
+ local64_add(delta, &event->count);
+ }
+}
+
+static void l2_cache__cluster_set_period(struct hml2_pmu *cluster,
+ struct hw_perf_event *hwc)
+{
+ u64 base = L2_MAX_PERIOD - (L2_CNT_PERIOD - 1);
+ u32 idx = hwc->idx;
+ u64 prev = local64_read(&hwc->prev_count);
+ u64 value;
+
+ /*
+ * Limit the maximum period to prevent the counter value
+ * from overtaking the one we are about to program.
+ * Use a starting value which is high enough that after
+ * an overflow, interrupt latency will not cause the count
+ * to reach the base value. If the previous value
+ * is below the base, increase it to be above the base
+ * and update prev_count accordingly. Otherwise if
+ * the previous value is already above the base
+ * nothing needs to be done to prev_count.
+ */
+ if (prev < base) {
+ value = base + prev;
+ local64_set(&hwc->prev_count, value);
+ } else {
+ value = prev;
+ }
+
+ hml2_pmu__counter_set_value(idx, value);
+}
+
+static int l2_cache__get_event_idx(struct hml2_pmu *cluster,
+ struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ int idx;
+
+ if (hwc->config_base == L2CYCLE_CTR_RAW_CODE) {
+ if (test_and_set_bit(l2_cycle_ctr_idx, cluster->used_counters))
+ return -EAGAIN;
+
+ return l2_cycle_ctr_idx;
+ }
+
+ for (idx = 0; idx < cluster->l2cache_pmu->num_counters - 1; idx++) {
+ if (!test_and_set_bit(idx, cluster->used_counters)) {
+ set_bit(L2_EVT_GROUP(hwc->config_base),
+ cluster->used_groups);
+ return idx;
+ }
+ }
+
+ /* The counters are all in use. */
+ return -EAGAIN;
+}
+
+static void l2_cache__clear_event_idx(struct hml2_pmu *cluster,
+ struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ int idx = hwc->idx;
+
+ clear_bit(idx, cluster->used_counters);
+ if (hwc->config_base != L2CYCLE_CTR_RAW_CODE)
+ clear_bit(L2_EVT_GROUP(hwc->config_base), cluster->used_groups);
+}
+
+static irqreturn_t l2_cache__handle_irq(int irq_num, void *data)
+{
+ struct hml2_pmu *cluster = data;
+ int num_counters = cluster->l2cache_pmu->num_counters;
+ u32 ovsr;
+ int idx;
+
+ ovsr = hml2_pmu__getreset_ovsr();
+ if (!hml2_pmu__has_overflowed(ovsr))
+ return IRQ_NONE;
+
+ for_each_set_bit(idx, cluster->used_counters, num_counters) {
+ struct perf_event *event = cluster->events[idx];
+ struct hw_perf_event *hwc;
+
+ if (!hml2_pmu__counter_has_overflowed(ovsr, idx))
+ continue;
+
+ l2_cache__event_update_from_cluster(event, cluster);
+ hwc = &event->hw;
+
+ l2_cache__cluster_set_period(cluster, hwc);
+ }
+
+ return IRQ_HANDLED;
+}
+
+/*
+ * Implementation of abstract pmu functionality required by
+ * the core perf events code.
+ */
+
+static void l2_cache__pmu_enable(struct pmu *pmu)
+{
+ /*
+ * Although there is only one PMU (per socket) controlling multiple
+ * physical PMUs (per cluster), because we do not support per-task mode
+ * each event is associated with a CPU. Each event has pmu_enable
+ * called on its CPU, so here it is only necessary to enable the
+ * counters for the current CPU.
+ */
+
+ hml2_pmu__enable();
+}
+
+static void l2_cache__pmu_disable(struct pmu *pmu)
+{
+ hml2_pmu__disable();
+}
+
+static int l2_cache__event_init(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ struct hml2_pmu *cluster;
+ struct perf_event *sibling;
+ struct l2cache_pmu *l2cache_pmu;
+
+ if (event->attr.type != event->pmu->type)
+ return -ENOENT;
+
+ l2cache_pmu = to_l2cache_pmu(event->pmu);
+
+ if (hwc->sample_period) {
+ dev_warn(&l2cache_pmu->pdev->dev, "Sampling not supported\n");
+ return -EOPNOTSUPP;
+ }
+
+ if (event->cpu < 0) {
+ dev_warn(&l2cache_pmu->pdev->dev, "Per-task mode not supported\n");
+ return -EOPNOTSUPP;
+ }
+
+ /* We cannot filter accurately so we just don't allow it. */
+ if (event->attr.exclude_user || event->attr.exclude_kernel ||
+ event->attr.exclude_hv || event->attr.exclude_idle) {
+ dev_warn(&l2cache_pmu->pdev->dev, "Can't exclude execution levels\n");
+ return -EOPNOTSUPP;
+ }
+
+ if (((L2_EVT_GROUP(event->attr.config) > L2_EVT_GROUP_MAX) ||
+ ((event->attr.config & ~L2_EVT_MASK) != 0)) &&
+ (event->attr.config != L2CYCLE_CTR_RAW_CODE)) {
+ dev_warn(&l2cache_pmu->pdev->dev, "Invalid config %llx\n",
+ event->attr.config);
+ return -EINVAL;
+ }
+
+ /* Don't allow groups with mixed PMUs, except for s/w events */
+ if (event->group_leader->pmu != event->pmu &&
+ !is_software_event(event->group_leader)) {
+ dev_warn(&l2cache_pmu->pdev->dev,
+ "Can't create mixed PMU group\n");
+ return -EINVAL;
+ }
+
+ list_for_each_entry(sibling, &event->group_leader->sibling_list,
+ group_entry)
+ if (sibling->pmu != event->pmu &&
+ !is_software_event(sibling)) {
+ dev_warn(&l2cache_pmu->pdev->dev,
+ "Can't create mixed PMU group\n");
+ return -EINVAL;
+ }
+
+ /* Ensure all events in a group are on the same cpu */
+ cluster = get_hml2_pmu(event->cpu);
+ if ((event->group_leader != event) &&
+ (cluster->on_cpu != event->group_leader->cpu)) {
+ dev_warn(&l2cache_pmu->pdev->dev,
+ "Can't create group on CPUs %d and %d",
+ event->cpu, event->group_leader->cpu);
+ return -EINVAL;
+ }
+
+ hwc->idx = -1;
+ hwc->config_base = event->attr.config;
+
+ /*
+ * Ensure all events are on the same cpu so all events are in the
+ * same cpu context, to avoid races on pmu_enable etc.
+ */
+ event->cpu = cluster->on_cpu;
+
+ return 0;
+}
+
+static void l2_cache__event_start(struct perf_event *event, int flags)
+{
+ struct hml2_pmu *cluster;
+ struct hw_perf_event *hwc = &event->hw;
+ int idx = hwc->idx;
+ u32 config;
+ u32 event_cc, event_group;
+
+ hwc->state = 0;
+
+ cluster = get_hml2_pmu(event->cpu);
+ l2_cache__cluster_set_period(cluster, hwc);
+
+ if (hwc->config_base == L2CYCLE_CTR_RAW_CODE) {
+ hml2_pmu__set_evccntcr(0x0);
+ } else {
+ config = hwc->config_base;
+ event_cc = L2_EVT_CODE(config);
+ event_group = L2_EVT_GROUP(config);
+
+ hml2_pmu__set_evcntcr(idx, 0x0);
+ hml2_pmu__set_evtyper(idx, event_group);
+ hml2_pmu__set_resr(cluster, event_group, event_cc);
+ hml2_pmu__set_evfilter_sys_mode(idx);
+ }
+
+ hml2_pmu__counter_enable_interrupt(idx);
+ hml2_pmu__counter_enable(idx);
+}
+
+static void l2_cache__event_stop(struct perf_event *event, int flags)
+{
+ struct hml2_pmu *cluster;
+ struct hw_perf_event *hwc = &event->hw;
+ int idx = hwc->idx;
+
+ if (!(hwc->state & PERF_HES_STOPPED)) {
+ cluster = get_hml2_pmu(event->cpu);
+ hml2_pmu__counter_disable_interrupt(idx);
+ hml2_pmu__counter_disable(idx);
+
+ if (flags & PERF_EF_UPDATE)
+ l2_cache__event_update_from_cluster(event, cluster);
+ hwc->state |= PERF_HES_STOPPED | PERF_HES_UPTODATE;
+ }
+}
+
+static int l2_cache__event_add(struct perf_event *event, int flags)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ int idx;
+ int err = 0;
+ struct hml2_pmu *cluster;
+
+ cluster = get_hml2_pmu(event->cpu);
+
+ idx = l2_cache__get_event_idx(cluster, event);
+ if (idx < 0) {
+ err = idx;
+ return err;
+ }
+
+ hwc->idx = idx;
+ hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
+ cluster->events[idx] = event;
+ cluster->group_to_counter[L2_EVT_GROUP(hwc->config_base)] = idx;
+ local64_set(&hwc->prev_count, 0ULL);
+
+ if (flags & PERF_EF_START)
+ l2_cache__event_start(event, flags);
+
+ /* Propagate changes to the userspace mapping. */
+ perf_event_update_userpage(event);
+
+ return err;
+}
+
+static void l2_cache__event_del(struct perf_event *event, int flags)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ struct hml2_pmu *cluster;
+ int idx = hwc->idx;
+
+ cluster = get_hml2_pmu(event->cpu);
+ l2_cache__event_stop(event, flags | PERF_EF_UPDATE);
+ cluster->events[idx] = NULL;
+ l2_cache__clear_event_idx(cluster, event);
+
+ perf_event_update_userpage(event);
+}
+
+static void l2_cache__event_read(struct perf_event *event)
+{
+ l2_cache__event_update_from_cluster(event, get_hml2_pmu(event->cpu));
+}
+
+static int l2_cache_filter_match(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ struct hml2_pmu *cluster = get_hml2_pmu(event->cpu);
+ unsigned int group = L2_EVT_GROUP(hwc->config_base);
+
+ /* check for column exclusion: group already in use by another event */
+ if (test_bit(group, cluster->used_groups) &&
+ cluster->events[cluster->group_to_counter[group]] != event)
+ return 0;
+
+ return 1;
+}
+
+static ssize_t l2_cache_pmu_cpumask_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct l2cache_pmu *l2cache_pmu = to_l2cache_pmu(dev_get_drvdata(dev));
+
+ return cpumap_print_to_pagebuf(true, buf, &l2cache_pmu->cpumask);
+}
+
+static struct device_attribute l2_cache_pmu_cpumask_attr =
+ __ATTR(cpumask, S_IRUGO, l2_cache_pmu_cpumask_show, NULL);
+
+static struct attribute *l2_cache_pmu_cpumask_attrs[] = {
+ &l2_cache_pmu_cpumask_attr.attr,
+ NULL,
+};
+
+static struct attribute_group l2_cache_pmu_cpumask_group = {
+ .attrs = l2_cache_pmu_cpumask_attrs,
+};
+
+/* CCG format for perf RAW codes. */
+PMU_FORMAT_ATTR(l2_code, "config:4-11");
+PMU_FORMAT_ATTR(l2_group, "config:0-3");
+static struct attribute *l2_cache_pmu_formats[] = {
+ &format_attr_l2_code.attr,
+ &format_attr_l2_group.attr,
+ NULL,
+};
+
+static struct attribute_group l2_cache_pmu_format_group = {
+ .name = "format",
+ .attrs = l2_cache_pmu_formats,
+};
+
+static const struct attribute_group *l2_cache_pmu_attr_grps[] = {
+ &l2_cache_pmu_format_group,
+ &l2_cache_pmu_cpumask_group,
+ NULL,
+};
+
+/*
+ * Generic device handlers
+ */
+
+static const struct acpi_device_id l2_cache_pmu_acpi_match[] = {
+ { "QCOM8130", },
+ { }
+};
+
+static int get_num_counters(void)
+{
+ int val;
+
+ val = get_l2_indirect_reg(L2PMCR);
+
+ /*
+ * Read number of counters from L2PMCR and add 1
+ * for the cycle counter.
+ */
+ return ((val >> L2PMCR_NUM_EV_SHIFT) & L2PMCR_NUM_EV_MASK) + 1;
+}
+
+static int l2cache_pmu_online_cpu(unsigned int cpu, struct hlist_node *node)
+{
+ struct hml2_pmu *cluster;
+ cpumask_t cluster_online_cpus;
+ struct l2cache_pmu *l2cache_pmu;
+
+ l2cache_pmu = hlist_entry_safe(node, struct l2cache_pmu, node);
+ cluster = get_hml2_pmu(cpu);
+ cpumask_and(&cluster_online_cpus, &cluster->cluster_cpus,
+ cpu_online_mask);
+
+ if (cpumask_weight(&cluster_online_cpus) == 1) {
+ /* all CPUs on this cluster were down, use this one */
+ cluster->on_cpu = cpu;
+ cpumask_set_cpu(cpu, &l2cache_pmu->cpumask);
+ WARN_ON(irq_set_affinity(cluster->irq, cpumask_of(cpu)));
+ }
+
+ return 0;
+}
+
+static int l2cache_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
+{
+ struct hml2_pmu *cluster;
+ struct l2cache_pmu *l2cache_pmu;
+ cpumask_t cluster_online_cpus;
+ unsigned int target;
+
+ l2cache_pmu = hlist_entry_safe(node, struct l2cache_pmu, node);
+
+ if (!cpumask_test_and_clear_cpu(cpu, &l2cache_pmu->cpumask))
+ return 0;
+ cluster = get_hml2_pmu(cpu);
+ cpumask_and(&cluster_online_cpus, &cluster->cluster_cpus,
+ cpu_online_mask);
+
+ /* Any other CPU for this cluster which is still online */
+ target = cpumask_any_but(&cluster_online_cpus, cpu);
+ if (target >= nr_cpu_ids)
+ return 0;
+
+ perf_pmu_migrate_context(&l2cache_pmu->pmu, cpu, target);
+ cluster->on_cpu = target;
+ cpumask_set_cpu(target, &l2cache_pmu->cpumask);
+ WARN_ON(irq_set_affinity(cluster->irq, cpumask_of(target)));
+
+ return 0;
+}
+
+static int l2_cache_pmu_probe_cluster(struct device *dev, void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev->parent);
+ struct platform_device *sdev = to_platform_device(dev);
+ struct l2cache_pmu *l2cache_pmu = data;
+ struct hml2_pmu *cluster;
+ struct acpi_device *device;
+ unsigned long fw_cluster_id;
+ int cpu;
+ int err;
+ int irq;
+
+ if (acpi_bus_get_device(ACPI_HANDLE(dev), &device))
+ return -ENODEV;
+
+ if (kstrtol(device->pnp.unique_id, 10, &fw_cluster_id) < 0) {
+ dev_err(&pdev->dev, "unable to read ACPI uid\n");
+ return -ENODEV;
+ }
+
+ irq = platform_get_irq(sdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev,
+ "Failed to get valid irq for cluster %ld\n",
+ fw_cluster_id);
+ return irq;
+ }
+
+ cluster = devm_kzalloc(&pdev->dev, sizeof(*cluster), GFP_KERNEL);
+ if (!cluster)
+ return -ENOMEM;
+
+ cluster->l2cache_pmu = l2cache_pmu;
+ for_each_present_cpu(cpu) {
+ if (topology_physical_package_id(cpu) == fw_cluster_id) {
+ cpumask_set_cpu(cpu, &cluster->cluster_cpus);
+ per_cpu(pmu_cluster, cpu) = cluster;
+ }
+ }
+ cluster->irq = irq;
+
+ if (cpumask_empty(&cluster->cluster_cpus)) {
+ dev_err(&pdev->dev, "No CPUs found for L2 cache instance %ld\n",
+ fw_cluster_id);
+ return -ENODEV;
+ }
+
+ /* Pick one CPU to be the preferred one to use in the cluster */
+ cluster->on_cpu = cpumask_first(&cluster->cluster_cpus);
+
+ if (irq_set_affinity(irq, cpumask_of(cluster->on_cpu))) {
+ dev_err(&pdev->dev,
+ "Unable to set irq affinity (irq=%d, cpu=%d)\n",
+ irq, cluster->on_cpu);
+ return -ENODEV;
+ }
+
+ err = devm_request_irq(&pdev->dev, irq, l2_cache__handle_irq,
+ IRQF_NOBALANCING, "l2-cache-pmu", cluster);
+ if (err) {
+ dev_err(&pdev->dev,
+ "Unable to request IRQ%d for L2 PMU counters\n", irq);
+ return err;
+ }
+
+ dev_info(&pdev->dev,
+ "Registered L2 cache PMU instance %ld with %d CPUs\n",
+ fw_cluster_id, cpumask_weight(&cluster->cluster_cpus));
+
+ cluster->pmu_lock = __SPIN_LOCK_UNLOCKED(cluster->pmu_lock);
+ cpumask_set_cpu(cluster->on_cpu, &l2cache_pmu->cpumask);
+
+ hml2_pmu__reset(cluster);
+ l2cache_pmu->num_pmus++;
+
+ return 0;
+}
+
+static int l2_cache_pmu_probe(struct platform_device *pdev)
+{
+ int err;
+ struct l2cache_pmu *l2cache_pmu;
+
+ l2cache_pmu =
+ devm_kzalloc(&pdev->dev, sizeof(*l2cache_pmu), GFP_KERNEL);
+ if (!l2cache_pmu)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, l2cache_pmu);
+ l2cache_pmu->pmu = (struct pmu) {
+ /* suffix is instance id for future use with multiple sockets */
+ .name = "l2cache_0",
+ .task_ctx_nr = perf_invalid_context,
+ .pmu_enable = l2_cache__pmu_enable,
+ .pmu_disable = l2_cache__pmu_disable,
+ .event_init = l2_cache__event_init,
+ .add = l2_cache__event_add,
+ .del = l2_cache__event_del,
+ .start = l2_cache__event_start,
+ .stop = l2_cache__event_stop,
+ .read = l2_cache__event_read,
+ .attr_groups = l2_cache_pmu_attr_grps,
+ .filter_match = l2_cache_filter_match,
+ };
+
+ l2cache_pmu->num_counters = get_num_counters();
+ l2cache_pmu->pdev = pdev;
+ l2_cycle_ctr_idx = l2cache_pmu->num_counters - 1;
+ l2_counter_present_mask = GENMASK(l2cache_pmu->num_counters - 2, 0) |
+ L2PM_CC_ENABLE;
+
+ cpumask_clear(&l2cache_pmu->cpumask);
+
+ /* Read cluster info and initialize each cluster */
+ err = device_for_each_child(&pdev->dev, l2cache_pmu,
+ l2_cache_pmu_probe_cluster);
+ if (err < 0)
+ return err;
+
+ if (l2cache_pmu->num_pmus == 0) {
+ dev_err(&pdev->dev, "No hardware L2 cache PMUs found\n");
+ return -ENODEV;
+ }
+
+ err = perf_pmu_register(&l2cache_pmu->pmu, l2cache_pmu->pmu.name, -1);
+ if (err < 0) {
+ dev_err(&pdev->dev, "Error %d registering L2 cache PMU\n", err);
+ return err;
+ }
+
+ dev_info(&pdev->dev, "Registered L2 cache PMU using %d HW PMUs\n",
+ l2cache_pmu->num_pmus);
+
+ err = cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
+ &l2cache_pmu->node);
+
+ return err;
+}
+
+static int l2_cache_pmu_remove(struct platform_device *pdev)
+{
+ struct l2cache_pmu *l2cache_pmu =
+ to_l2cache_pmu(platform_get_drvdata(pdev));
+
+ cpuhp_state_remove_instance_nocalls(CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
+ &l2cache_pmu->node);
+ perf_pmu_unregister(&l2cache_pmu->pmu);
+ return 0;
+}
+
+static struct platform_driver l2_cache_pmu_driver = {
+ .driver = {
+ .name = "qcom-l2cache-pmu",
+ .owner = THIS_MODULE,
+ .acpi_match_table = ACPI_PTR(l2_cache_pmu_acpi_match),
+ },
+ .probe = l2_cache_pmu_probe,
+ .remove = l2_cache_pmu_remove,
+};
+
+static int __init register_l2_cache_pmu_driver(void)
+{
+ int err;
+
+ err = cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
+ "AP_PERF_ARM_QCOM_L2_ONLINE",
+ l2cache_pmu_online_cpu,
+ l2cache_pmu_offline_cpu);
+ if (err)
+ return err;
+
+ return platform_driver_register(&l2_cache_pmu_driver);
+}
+device_initcall(register_l2_cache_pmu_driver);
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 45a4287..f342842 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -113,6 +113,7 @@ enum cpuhp_state {
CPUHP_AP_PERF_ARM_CCI_ONLINE,
CPUHP_AP_PERF_ARM_CCN_ONLINE,
CPUHP_AP_PERF_ARM_L2X0_ONLINE,
+ CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
CPUHP_AP_WORKQUEUE_ONLINE,
CPUHP_AP_RCUTREE_ONLINE,
CPUHP_AP_NOTIFY_ONLINE,
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH] drm/sun4i: rgb: Enable panel after controller
From: Maxime Ripard @ 2016-09-21 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921130304.3486-1-net147@gmail.com>
Hi,
On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote:
> The panel should be enabled after the controller so that the panel
> prepare/enable delays are properly taken into account. Similarly, the
> panel should be disabled before the controller so that the panel
> unprepare/disable delays are properly taken into account.
>
> This is useful for avoiding visual glitches.
This is not really taking any delays into account, especially since
drm_panel_enable and prepare are suppose to block until their
operation is complete.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160922/2c9d582c/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] ARM: BCM5301X: Specify USB 3.0 PHY in DT
From: Rafał Miłecki @ 2016-09-21 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921205838.15627-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
Driver for Northstar USB 3.0 PHY has been recently added under the name
phy-bcm-ns-usb3. Add binding for it into the DT files.
The only slightly tricky part is BCM47094 which uses different PHY
version and requires different compatible value.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm47094.dtsi | 6 ++++++
arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
index f039765..4f09aa0 100644
--- a/arch/arm/boot/dts/bcm47094.dtsi
+++ b/arch/arm/boot/dts/bcm47094.dtsi
@@ -6,6 +6,12 @@
#include "bcm4708.dtsi"
+/ {
+ usb3_phy: usb3-phy {
+ compatible = "brcm,ns-bx-usb3-phy";
+ };
+};
+
&uart0 {
clock-frequency = <125000000>;
};
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index ae4b388..f09a2bb 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -149,6 +149,13 @@
clock-names = "phy-ref-clk";
};
+ usb3_phy: usb3-phy {
+ compatible = "brcm,ns-ax-usb3-phy";
+ reg = <0x18105000 0x1000>, <0x18003000 0x1000>;
+ reg-names = "dmp", "ccb-mii";
+ #phy-cells = <0>;
+ };
+
axi at 18000000 {
compatible = "brcm,bus-axi";
reg = <0x18000000 0x1000>;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: BCM5301X: Enable UART on Netgear R8000
From: Rafał Miłecki @ 2016-09-21 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921205838.15627-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
It was tested by LEDE users, all we need is to adjust clock frequency.
While we're at it create a separated DTS include file to share code with
other BCM4709 devices easier.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 2 +-
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 2 +-
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 2 +-
arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 6 +++++-
arch/arm/boot/dts/bcm4709.dtsi | 11 +++++++++++
5 files changed, 19 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm4709.dtsi
diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
index 8ade7de..eac0f52 100644
--- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
+++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
@@ -9,7 +9,7 @@
/dts-v1/;
-#include "bcm4708.dtsi"
+#include "bcm4709.dtsi"
#include "bcm5301x-nand-cs0-bch8.dtsi"
/ {
diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
index 0653e7e..aab39c9 100644
--- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
+++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
@@ -9,7 +9,7 @@
/dts-v1/;
-#include "bcm4708.dtsi"
+#include "bcm4709.dtsi"
#include "bcm5301x-nand-cs0-bch8.dtsi"
/ {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index a22ed14..fd38d2a 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -9,7 +9,7 @@
/dts-v1/;
-#include "bcm4708.dtsi"
+#include "bcm4709.dtsi"
#include "bcm5301x-nand-cs0-bch8.dtsi"
/ {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
index ca18151..92f8a72 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
@@ -9,7 +9,7 @@
/dts-v1/;
-#include "bcm4708.dtsi"
+#include "bcm4709.dtsi"
#include "bcm5301x-nand-cs0-bch8.dtsi"
/ {
@@ -107,6 +107,10 @@
};
};
+&uart0 {
+ status = "okay";
+};
+
&usb2 {
vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
new file mode 100644
index 0000000..f039765
--- /dev/null
+++ b/arch/arm/boot/dts/bcm4709.dtsi
@@ -0,0 +1,11 @@
+/*
+ * Copyright (C) 2016 Rafa? Mi?ecki <rafal@milecki.pl>
+ *
+ * Licensed under the ISC license.
+ */
+
+#include "bcm4708.dtsi"
+
+&uart0 {
+ clock-frequency = <125000000>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] ARM: BCM5301X: Add separated DTS include file for BCM47094
From: Rafał Miłecki @ 2016-09-21 20:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Rafa? Mi?ecki <rafal@milecki.pl>
Use it to store BCM47094 specific properties/values and avoid repeating
them in device DTS files.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 +--
arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 +--
arch/arm/boot/dts/bcm47094.dtsi | 11 +++++++++++
3 files changed, 13 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm47094.dtsi
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index c8c0b36..661348d 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -9,7 +9,7 @@
/dts-v1/;
-#include "bcm4708.dtsi"
+#include "bcm47094.dtsi"
#include "bcm5301x-nand-cs0-bch1.dtsi"
/ {
@@ -107,7 +107,6 @@
&uart0 {
status = "okay";
- clock-frequency = <125000000>;
};
&usb3 {
diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
index 10db4f8..521b415 100644
--- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
+++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
@@ -6,7 +6,7 @@
/dts-v1/;
-#include "bcm4708.dtsi"
+#include "bcm47094.dtsi"
#include "bcm5301x-nand-cs0-bch8.dtsi"
/ {
@@ -100,5 +100,4 @@
&uart0 {
status = "okay";
- clock-frequency = <125000000>;
};
diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
new file mode 100644
index 0000000..f039765
--- /dev/null
+++ b/arch/arm/boot/dts/bcm47094.dtsi
@@ -0,0 +1,11 @@
+/*
+ * Copyright (C) 2016 Rafa? Mi?ecki <rafal@milecki.pl>
+ *
+ * Licensed under the ISC license.
+ */
+
+#include "bcm4708.dtsi"
+
+&uart0 {
+ clock-frequency = <125000000>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2] musb: Export musb_root_disconnect for use in modules
From: Bin Liu @ 2016-09-21 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917100810.2406-1-hdegoede@redhat.com>
Hi,
On Sat, Sep 17, 2016 at 12:08:10PM +0200, Hans de Goede wrote:
> Export musb_root_disconnect for use in modules, so that musb glue
> code build as module can use it.
>
> This fixes the buildbot errors for -next in arm64-allmodconfig
> and arm-allmodconfig.
>
> Fixes: 7cba17ec9adc8cf ("musb: sunxi: Add support for platform_set_mode")
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied. Thanks.
Regards,
-Bin.
^ permalink raw reply
* [PATCH v4 0/2] ARM: cleanup PCI specific configs
From: Arnd Bergmann @ 2016-09-21 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473848346-17905-1-git-send-email-kishon@ti.com>
On Wednesday, September 14, 2016 3:49:04 PM CEST Kishon Vijay Abraham I wrote:
> This series was initially sent to add support for two PCIe
> ports in dra7. This included selecting PCI_DOMAINS config
> in SOC_DRA7XX.
>
> However from the review, PCI_DOMAINS can instead be selected
> from ARCH_MULTIPLATFORM. This is fixed in this series along
> with removing PCI_DOMAINS from other configs.
>
> Changes from v3:
> *) Added *Acked-by:*
> *) Fixed $subject to not have *Fix*
>
> Kishon Vijay Abraham I (2):
> ARM: stop *MIGHT_HAVE_PCI* config from being selected redundantly
> ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM
>
Applied both to next/cleanup now.
Arnd
^ permalink raw reply
* [PATCH] clk: mvebu: Add clk support for the orion5x SoC mv88f5181
From: Stephen Boyd @ 2016-09-21 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8760pp5zhp.fsf@free-electrons.com>
On 09/21, Gregory CLEMENT wrote:
> Hi Stephen,
>
> On mar., sept. 20 2016, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> > On 09/20, Gregory CLEMENT wrote:
> >> From: Jamie Lentin <jm@lentin.co.uk>
> >>
> >> Referring to the u-boot sources for the Netgear WNR854T, add support
> >> for the mv88f5181.
> >>
> >> [gregory.clement at free-electrons.com: fix commit title]
> >> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> >> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >> ---
> >>
> >> Hi Stephen and Mike,
> >>
> >> do you agree to give your acked-by on this patch. It is part of a
> >> convertion of old orion5x Socv to the device tree. If you acked-by
> >> this one, then I will be able to take it in my tree and avoiding
> >> breaking the git bisect.
> >
> > Is the problem that we're changing some dts files somewhere and
> > those platforms would stop booting if this change wasn't present?
> > Given that we're adding a new compatible it seems like we're
> > adding new SoC support, so having the clk patch and the dts patch
> > come together in -next via a merge instead of basing the dts
> > patch on top of the clk patch would be how things are normally
> > done.
>
> The problem appear if the dts for the board using the clock driver is
> merged in Linus tree before the support in the driver. At this point the
> board won't be able to boot.
>
> It introduces a hole in the git bisect between the merge of the clock
> subsystem and the arm-soc subsystem.
Ok so that sounds like the typical case where a new SoC/board is
supported and the dts files don't do anything useful until the
driver support lands. We don't usually care about bisection
problems here because the board doesn't transition from 'working'
to 'not working'. It only transitions from 'not working' to
'working' once the clk driver and the dts files are both present
in the tree.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL] Qualcomm EBI2 bindings and bus driver
From: Arnd Bergmann @ 2016-09-21 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZdoK4+YRrZC=Kd8TFzJXOQxh=Gi0BWLp4PzV6H5_wEtg@mail.gmail.com>
On Tuesday, September 20, 2016 11:50:14 PM CEST Linus Walleij wrote:
> On Tue, Sep 20, 2016 at 12:36 AM, Andy Gross <andy.gross@linaro.org> wrote:
> > On Tue, Sep 20, 2016 at 12:12:33AM +0200, Arnd Bergmann wrote:
> >> On Thursday, September 8, 2016 3:34:42 PM CEST Linus Walleij wrote:
> >> > please pull this new EBI2 bus driver and its bindings into an
> >> > apropriate branch in the ARM SoC tree. The binding now has
> >> > Rob Herrings ACK and we have hopefully finally figured out how
> >> > this should be done.
> >> >
> >>
> >> I just noticed that you sent the pull request directly to arm at kernel.org
> >> rather than the Qualcomm maintainers (which are only on Cc).
> >>
> >> Usually, I'd expect to see this forwarded from Andy, is there a
> >> reason to do it differently here? If so, can I have an Ack
> >> from him?
> >
> > When I looked at this last, I thought there were comments. Sorry I missed it.
> > If you want to pick it up Arnd, please do, otherwise I can send it along in the
> > next pull request.
> >
> > Acked-by: Andy Gross <andy.gross@linaro.org>
>
> Thanks, I hope Arnd can pull this as-is.
>
Pulled into next/drivers, with Andy's Ack added to the merge commit, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Allwinner late DT changes for 4.9
From: Arnd Bergmann @ 2016-09-21 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921085814.GA25513@lukather>
On Wednesday, September 21, 2016 11:58:14 AM CEST Maxime Ripard wrote:
> Allwinner DT changes for 4.9, late edition
>
> Here is a bunch of late changes for the 4.9 merge window, mostly:
> - Added a bunch of touchscreens nodes to tablets
> - Added support for the AXP806 PMIC found in the A80 boards
> - Enabled a few pinmux options for the H3
>
Pulled into next/late, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: drivers for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-21 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874m595zew.fsf@free-electrons.com>
On Wednesday, September 21, 2016 12:18:31 PM CEST Gregory CLEMENT wrote:
> Here is the second tentative of first pull request for drivers for
> mvebu for v4.9.
>
> This time both patches received their Acked-by.
>
Pulled into next/drivers, thanks for the quick updates!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-21 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737kt5zco.fsf@free-electrons.com>
On Wednesday, September 21, 2016 12:19:51 PM CEST Gregory CLEMENT wrote:
> mvebu soc for 4.9 (part 1)
>
> - irq cleanup for old mvebu SoC
>
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] i.MX legacy board changes for 4.9
From: Arnd Bergmann @ 2016-09-21 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921061613.GI3744@tiger>
On Wednesday, September 21, 2016 2:16:13 PM CEST Shawn Guo wrote:
> I know this is late for 4.9 merge window, but the patch series fixes a
> regression for i.MX legacy board support on linux-next [1]. So please
> pull it for 4.9 merge window. Otherwise, we will need to get them in
> during 4.9-rc cycles.
No worries, there is no "late" for regression fixes.
> ----------------------------------------------------------------
> i.MX legacy board file changes for 4.9:
>
> It includes a patch series that moves registrations and initializations
> of all peripherals which are GPIO line consumers for all legacy boards
> from .init_machine to .init_late init level. This is needed to
> proactively prevent boot time issues on the legacy boards due to the
> deprioritized init level of the GPIO controller driver (set lower than
> IOMUX controller driver init level), which is shared among all i.MX
> SoCs.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.8 (#3)
From: Arnd Bergmann @ 2016-09-21 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87intq5z0o.fsf@free-electrons.com>
On Tuesday, September 20, 2016 6:14:47 PM CEST Gregory CLEMENT wrote:
> mvebu fixes for 4.8 (part 3)
>
> - Select corediv clk for all mvebu v7 SoC
> - Fix clocksource for CP110 master SPI0 for Armada 7K/8K
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-09-21 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F87D223@lhreml507-mbx>
On Wednesday, September 21, 2016 4:20:55 PM CEST Gabriele Paoloni wrote:
> > -----Original Message-----
> > From: zhichang [mailto:zhichang.yuan02 at gmail.com]
> > On 2016?09?15? 20:24, Arnd Bergmann wrote:
> > > On Thursday, September 15, 2016 12:05:51 PM CEST Gabriele Paoloni
> > wrote:
> > >>> -----Original Message-----
> > >>> On Thursday, September 15, 2016 8:02:27 AM CEST Gabriele Paoloni
> > wrote:
> > >> I think that maybe having the 1:1 range mapping doesn't
> > >> reflect well the reality but it is the less painful
> > >> solution...
> > >>
> > >> What's your view?
> > >
> > > We can check the 'i' bit for I/O space in of_bus_isa_get_flags,
> > > and that should be enough to translate the I/O port number.
> > >
> > > The only part we need to change here is to not go through
> > > the crazy conversion all the way from PCI I/O space to a
> > > physical address and back to a (logical) port number
> > > that we do today with of_translate_address/pci_address_to_pio.
> > >
> > Sorry for the late response! Several days' leave....
> > Do you want to bypass of_translate_address and pci_address_to_pio for
> > the registered specific PIO?
> > I think the bypass for of_translate_address is ok, but worry some new
> > issues will emerge without the
> > conversion between physical address and logical/linux port number.
The same function that handles the non-translated region would
do that conversion.
> > When PCI host bridge which support IO operations is configured and
> > enabled, the pci_address_to_pio will
> > populate the logical IO range from ZERO for the first host bridge. Our
> > LPC will also use part of the IO range
> > started from ZERO. It will make in/out enter the wrong branch possibly.
> >
> > In V2, the 0 - 0x1000 logical IO range is reserved for LPC use only.
> > But it seems not so good. In this way,
> > PCI has no chance to use low 4K IO range(logical).
> >
> > So, in V3, applying the conversion from physical/cpu address to
> > logical/linux IO port for any IO ranges,
> > including the LPC, but recorded the logical IO range for LPC. When
> > calling in/out with a logical port address,
> > we can check this port fall into LPC logical IO range and get back the
> > real IO.
Right, and the same translation can be used in __of_address_to_resource()
going the opposite way.
> > Do you have further comments about this??
>
> I think there are two separate issues to be discussed:
>
> The first issue is about having of_translate_address failing due to
> "range" missing. About this Arnd suggested that it is not appropriate
> to have a range describing a bridge 1:1 mapping and this was discussed
> before in this thread. Arnd had a suggestion about this (see below)
> however (looking twice at the code) it seems to me that such solution
> would lead to quite some duplication from __of_translate_address()
> in order to retrieve the actual addr from dt...
I don't think we need to duplicate much, we can probably safely
assume that there are no nontrivial ranges in devices below the LPC
node, so we just walk up the bus to see if the node is a child
(or possibly grandchild etc) of the LPC bus, and treat any IO port
number under there as a physical port number, which has a known
offset from the Linux I/O port number.
> I think extending of_empty_ranges_quirk() may be a reasonable solution.
> What do you think Arnd?
I don't really like that idea, that quirk is meant to work around
broken DTs, but we can just make the DT valid and implement the
code properly.
> The second issue is a conflict between cpu addresses used by the LPC
> controller and i/o tokens from pci endpoints.
>
> About this what if we modify armn64_extio_ops to have a list of ranges
> rather than only one range (now we have just start/end); then in the
> LPC driver we can scan the LPC child devices and
> 1) populate such list of ranges
> 2) call pci_register_io_range for such ranges
Scanning the child devices sounds really wrong, please register just
one range that covers the bus to keep the workaround as simple
as possible.
> Then when calling __of_address_to_resource we retrieve I/O tokens
> for the devices on top of the LPC driver and in the I/O accessors
> we call pci_pio_to_address to figure out the cpu address and compare
> it to the list of ranges in armn64_extio_ops.
>
> What about this?
That seems really complex for something that can be quite simple.
The only thing we need to worry about is that the io_range_list
contains an entry for the LPC bus so we don't conflict with the
PCI buses.
Arnd
Arnd
^ permalink raw reply
* [PATCH v5] soc: qcom: add l2 cache perf events driver
From: kbuild test robot @ 2016-09-21 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474470350-25818-1-git-send-email-nleeder@codeaurora.org>
Hi Neil,
[auto build test ERROR on next-20160921]
[cannot apply to linus/master linux/master v4.8-rc7 v4.8-rc6 v4.8-rc5 v4.8-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Neil-Leeder/soc-qcom-add-l2-cache-perf-events-driver/20160922-000500
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
drivers/soc/qcom/perf_event_l2.c: In function 'set_l2_indirect_reg':
>> drivers/soc/qcom/perf_event_l2.c:92:2: error: implicit declaration of function 'write_sysreg' [-Werror=implicit-function-declaration]
write_sysreg(reg, L2CPUSRSELR_EL1);
^~~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:74:33: error: 'S3_3_c15_c0_6' undeclared (first use in this function)
#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
^
>> drivers/soc/qcom/perf_event_l2.c:92:20: note: in expansion of macro 'L2CPUSRSELR_EL1'
write_sysreg(reg, L2CPUSRSELR_EL1);
^~~~~~~~~~~~~~~
drivers/soc/qcom/perf_event_l2.c:74:33: note: each undeclared identifier is reported only once for each function it appears in
#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
^
>> drivers/soc/qcom/perf_event_l2.c:92:20: note: in expansion of macro 'L2CPUSRSELR_EL1'
write_sysreg(reg, L2CPUSRSELR_EL1);
^~~~~~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:75:33: error: 'S3_3_c15_c0_7' undeclared (first use in this function)
#define L2CPUSRDR_EL1 S3_3_c15_c0_7
^
>> drivers/soc/qcom/perf_event_l2.c:94:20: note: in expansion of macro 'L2CPUSRDR_EL1'
write_sysreg(val, L2CPUSRDR_EL1);
^~~~~~~~~~~~~
drivers/soc/qcom/perf_event_l2.c: In function 'get_l2_indirect_reg':
>> drivers/soc/qcom/perf_event_l2.c:74:33: error: 'S3_3_c15_c0_6' undeclared (first use in this function)
#define L2CPUSRSELR_EL1 S3_3_c15_c0_6
^
drivers/soc/qcom/perf_event_l2.c:112:20: note: in expansion of macro 'L2CPUSRSELR_EL1'
write_sysreg(reg, L2CPUSRSELR_EL1);
^~~~~~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:114:8: error: implicit declaration of function 'read_sysreg' [-Werror=implicit-function-declaration]
val = read_sysreg(L2CPUSRDR_EL1);
^~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:75:33: error: 'S3_3_c15_c0_7' undeclared (first use in this function)
#define L2CPUSRDR_EL1 S3_3_c15_c0_7
^
drivers/soc/qcom/perf_event_l2.c:114:20: note: in expansion of macro 'L2CPUSRDR_EL1'
val = read_sysreg(L2CPUSRDR_EL1);
^~~~~~~~~~~~~
drivers/soc/qcom/perf_event_l2.c: In function 'l2_cache_pmu_probe_cluster':
>> drivers/soc/qcom/perf_event_l2.c:787:6: error: implicit declaration of function 'acpi_bus_get_device' [-Werror=implicit-function-declaration]
if (acpi_bus_get_device(ACPI_HANDLE(dev), &device))
^~~~~~~~~~~~~~~~~~~
>> drivers/soc/qcom/perf_event_l2.c:790:20: error: dereferencing pointer to incomplete type 'struct acpi_device'
if (kstrtol(device->pnp.unique_id, 10, &fw_cluster_id) < 0) {
^~
cc1: some warnings being treated as errors
vim +/write_sysreg +92 drivers/soc/qcom/perf_event_l2.c
68
69 #define L2_EVT_GROUP_MAX 7
70
71 #define L2_MAX_PERIOD U32_MAX
72 #define L2_CNT_PERIOD (U32_MAX - GENMASK(26, 0))
73
> 74 #define L2CPUSRSELR_EL1 S3_3_c15_c0_6
> 75 #define L2CPUSRDR_EL1 S3_3_c15_c0_7
76
77 static DEFINE_RAW_SPINLOCK(l2_access_lock);
78
79 /**
80 * set_l2_indirect_reg: write value to an L2 register
81 * @reg: Address of L2 register.
82 * @value: Value to be written to register.
83 *
84 * Use architecturally required barriers for ordering between system register
85 * accesses
86 */
87 static void set_l2_indirect_reg(u64 reg, u64 val)
88 {
89 unsigned long flags;
90
91 raw_spin_lock_irqsave(&l2_access_lock, flags);
> 92 write_sysreg(reg, L2CPUSRSELR_EL1);
93 isb();
> 94 write_sysreg(val, L2CPUSRDR_EL1);
95 isb();
96 raw_spin_unlock_irqrestore(&l2_access_lock, flags);
97 }
98
99 /**
100 * get_l2_indirect_reg: read an L2 register value
101 * @reg: Address of L2 register.
102 *
103 * Use architecturally required barriers for ordering between system register
104 * accesses
105 */
106 static u64 get_l2_indirect_reg(u64 reg)
107 {
108 u64 val;
109 unsigned long flags;
110
111 raw_spin_lock_irqsave(&l2_access_lock, flags);
112 write_sysreg(reg, L2CPUSRSELR_EL1);
113 isb();
> 114 val = read_sysreg(L2CPUSRDR_EL1);
115 raw_spin_unlock_irqrestore(&l2_access_lock, flags);
116
117 return val;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 59315 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160922/bf497f00/attachment-0001.gz>
^ permalink raw reply
* [PATCH] arm64: Correctly bounds check virt_addr_valid
From: Mark Rutland @ 2016-09-21 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8f34fc7-76ac-5681-085a-8c007cd40e98@redhat.com>
On Wed, Sep 21, 2016 at 12:34:46PM -0700, Laura Abbott wrote:
> On 09/21/2016 10:58 AM, Mark Rutland wrote:
> >Are there other potentially-broken users of virt_addr_valid? It's not
> >clear to me what some drivers are doing with this, and therefore whether
> >we need to cc stable.
>
> The number of users is pretty limited. Some of them use it as a debugging
> check, others are using it more like hardened usercopy. The number of
> users that would actually affect arm64 seems so small I don't think it's
> worth trying to backport to stable.
Ok.
> Hardened usercopy was getting hit particularly hard because usercopy was
> happening on all types of memory whereas the drivers tend to be more limited
> in scope.
Sure.
> >Given the common sub-expression, perhaps it would be better to leave
> >these as-is, but prefix them with '_', and after the #endif, have
> >something like:
> >
> >#define _virt_addr_is_linear(kaddr) (((u64)(kaddr)) >= PAGE_OFFSET)
> >#define virt_addr_valid(kaddr) (_virt_addr_is_linear(kaddr) && _virt_addr_valid(kaddr))
> >
>
> Good suggestion.
FWIW, with that, feel free to add:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: Add BCM2835 (Raspberry Pi 3) support to the defconfig
From: Florian Fainelli @ 2016-09-21 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919133150.9371-1-eric@anholt.net>
On 09/19/2016 06:31 AM, Eric Anholt wrote:
> Most of the drivers are included as modules, except for serial (needed
> for early console), WDT (required for reboot), and the dependency
> chain of RASPBERRYPI_POWER (which is currently not buildable as a
> module, but should be changed).
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
LGTM, can you queue this for the next ARM/ARM64 SoC pull request in a
separate branch for me to pull from?
Thanks!
> ---
> arch/arm64/configs/defconfig | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index fb8d84516e92..9748c4735a60 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -34,6 +34,7 @@ CONFIG_MODULE_UNLOAD=y
> # CONFIG_IOSCHED_DEADLINE is not set
> CONFIG_ARCH_SUNXI=y
> CONFIG_ARCH_ALPINE=y
> +CONFIG_ARCH_BCM2835=y
> CONFIG_ARCH_BCM_IPROC=y
> CONFIG_ARCH_BERLIN=y
> CONFIG_ARCH_EXYNOS=y
> @@ -193,6 +194,7 @@ CONFIG_USB_NET_SMSC75XX=m
> CONFIG_USB_NET_SMSC95XX=m
> CONFIG_USB_NET_PLUSB=m
> CONFIG_USB_NET_MCS7830=m
> +CONFIG_BRCMFMAC=m
> CONFIG_WL18XX=m
> CONFIG_WLCORE_SDIO=m
> CONFIG_INPUT_EVDEV=y
> @@ -205,6 +207,9 @@ CONFIG_SERIO_AMBAKMI=y
> CONFIG_LEGACY_PTY_COUNT=16
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_EXTENDED=y
> +CONFIG_SERIAL_8250_SHARE_IRQ=y
> +CONFIG_SERIAL_8250_BCM2835AUX=y
> CONFIG_SERIAL_8250_DW=y
> CONFIG_SERIAL_8250_MT6577=y
> CONFIG_SERIAL_8250_UNIPHIER=y
> @@ -228,6 +233,7 @@ CONFIG_VIRTIO_CONSOLE=y
> CONFIG_I2C_CHARDEV=y
> CONFIG_I2C_MUX=y
> CONFIG_I2C_MUX_PCA954x=y
> +CONFIG_I2C_BCM2835=m
> CONFIG_I2C_DESIGNWARE_PLATFORM=y
> CONFIG_I2C_IMX=y
> CONFIG_I2C_MESON=y
> @@ -238,6 +244,8 @@ CONFIG_I2C_UNIPHIER_F=y
> CONFIG_I2C_RCAR=y
> CONFIG_I2C_CROS_EC_TUNNEL=y
> CONFIG_SPI=y
> +CONFIG_SPI_BCM2835=m
> +CONFIG_SPI_BCM2835AUX=m
> CONFIG_SPI_MESON_SPIFC=m
> CONFIG_SPI_ORION=y
> CONFIG_SPI_PL022=y
> @@ -272,6 +280,7 @@ CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
> CONFIG_CPU_THERMAL=y
> CONFIG_EXYNOS_THERMAL=y
> CONFIG_WATCHDOG=y
> +CONFIG_BCM2835_WDT=y
> CONFIG_RENESAS_WDT=y
> CONFIG_S3C2410_WATCHDOG=y
> CONFIG_MESON_GXBB_WATCHDOG=m
> @@ -294,6 +303,7 @@ CONFIG_REGULATOR_S2MPS11=y
> CONFIG_DRM=m
> CONFIG_DRM_NOUVEAU=m
> CONFIG_DRM_TEGRA=m
> +CONFIG_DRM_VC4=m
> CONFIG_DRM_PANEL_SIMPLE=m
> CONFIG_DRM_I2C_ADV7511=m
> CONFIG_DRM_HISI_KIRIN=m
> @@ -308,6 +318,7 @@ CONFIG_LOGO=y
> CONFIG_SOUND=y
> CONFIG_SND=y
> CONFIG_SND_SOC=y
> +CONFIG_SND_BCM2835_SOC_I2S=m
> CONFIG_SND_SOC_RCAR=y
> CONFIG_SND_SOC_SAMSUNG=y
> CONFIG_SND_SOC_AK4613=y
> @@ -372,6 +383,7 @@ CONFIG_RTC_DRV_XGENE=y
> CONFIG_RTC_DRV_S3C=y
> CONFIG_DMADEVICES=y
> CONFIG_PL330_DMA=y
> +CONFIG_DMA_BCM2835=m
> CONFIG_TEGRA20_APB_DMA=y
> CONFIG_QCOM_BAM_DMA=y
> CONFIG_QCOM_HIDMA_MGMT=y
> @@ -394,8 +406,10 @@ CONFIG_MSM_MMCC_8996=y
> CONFIG_HWSPINLOCK_QCOM=y
> CONFIG_MAILBOX=y
> CONFIG_ARM_MHU=y
> +CONFIG_BCM2835_MBOX=y
> CONFIG_HI6220_MBOX=y
> CONFIG_ARM_SMMU=y
> +CONFIG_RASPBERRYPI_POWER=y
> CONFIG_QCOM_SMEM=y
> CONFIG_QCOM_SMD=y
> CONFIG_QCOM_SMD_RPM=y
> @@ -403,6 +417,7 @@ CONFIG_ARCH_TEGRA_132_SOC=y
> CONFIG_ARCH_TEGRA_210_SOC=y
> CONFIG_EXTCON_USB_GPIO=y
> CONFIG_PWM=y
> +CONFIG_PWM_BCM2835=m
> CONFIG_PWM_TEGRA=m
> CONFIG_COMMON_RESET_HI6220=y
> CONFIG_PHY_RCAR_GEN3_USB2=y
> @@ -414,6 +429,7 @@ CONFIG_ACPI=y
> CONFIG_IIO=y
> CONFIG_EXYNOS_ADC=y
> CONFIG_PWM_SAMSUNG=y
> +CONFIG_RASPBERRYPI_FIRMWARE=y
> CONFIG_EXT2_FS=y
> CONFIG_EXT3_FS=y
> CONFIG_EXT4_FS_POSIX_ACL=y
>
--
Florian
^ permalink raw reply
* [PATCH] arm64: Correctly bounds check virt_addr_valid
From: Laura Abbott @ 2016-09-21 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921175855.GG18176@leverpostej>
On 09/21/2016 10:58 AM, Mark Rutland wrote:
> Hi,
>
> On Wed, Sep 21, 2016 at 10:28:48AM -0700, Laura Abbott wrote:
>> virt_addr_valid is supposed to return true if and only if virt_to_page
>> returns a valid page structure. The current macro does math on whatever
>> address is given and passes that to pfn_valid to verify. vmalloc and
>> module addresses can happen to generate a pfn that 'happens' to be
>> valid. Fix this by only performing the pfn_valid check on addresses that
>> have the potential to be valid.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> This caused a bug at least twice in hardened usercopy so it is an
>> actual problem.
>
> Are there other potentially-broken users of virt_addr_valid? It's not
> clear to me what some drivers are doing with this, and therefore whether
> we need to cc stable.
>
The number of users is pretty limited. Some of them use it as a debugging
check, others are using it more like hardened usercopy. The number of
users that would actually affect arm64 seems so small I don't think it's
worth trying to backport to stable. Hardened usercopy was getting hit
particularly hard because usercopy was happening on all types of memory
whereas the drivers tend to be more limited in scope.
>> A further TODO is full DEBUG_VIRTUAL support to
>> catch these types of mistakes.
>> ---
>> arch/arm64/include/asm/memory.h | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 31b7322..f741e19 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -214,7 +214,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>>
>> #ifndef CONFIG_SPARSEMEM_VMEMMAP
>> #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
>> -#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
>> +#define virt_addr_valid(kaddr) (((u64)kaddr) >= PAGE_OFFSET && pfn_valid(__pa(kaddr) >> PAGE_SHIFT))
>> #else
>> #define __virt_to_pgoff(kaddr) (((u64)(kaddr) & ~PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
>> #define __page_to_voff(kaddr) (((u64)(page) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
>> @@ -222,8 +222,8 @@ static inline void *phys_to_virt(phys_addr_t x)
>> #define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET))
>> #define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) | VMEMMAP_START))
>>
>> -#define virt_addr_valid(kaddr) pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
>> - + PHYS_OFFSET) >> PAGE_SHIFT)
>> +#define virt_addr_valid(kaddr) (((u64)kaddr) >= PAGE_OFFSET && pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
>> + + PHYS_OFFSET) >> PAGE_SHIFT))
>> #endif
>> #endif
>
> Given the common sub-expression, perhaps it would be better to leave
> these as-is, but prefix them with '_', and after the #endif, have
> something like:
>
> #define _virt_addr_is_linear(kaddr) (((u64)(kaddr)) >= PAGE_OFFSET)
> #define virt_addr_valid(kaddr) (_virt_addr_is_linear(kaddr) && _virt_addr_valid(kaddr))
>
Good suggestion.
> Otherwise, modulo the parenthesis issue you mentioned, this looks
> logically correct to me.
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* [PATCH v2 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Dave Gerlach @ 2016-09-21 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908033909.GR27345@vireshk-i7>
Viresh,
On 09/07/2016 10:39 PM, Viresh Kumar wrote:
> On 07-09-16, 10:04, Dave Gerlach wrote:
>>>> +static const struct of_device_id ti_cpufreq_of_match[] = {
>>>> + { .compatible = "operating-points-v2-ti-am3352-cpu",
>>>> + .data = &am3x_soc_data, },
>>>> + { .compatible = "operating-points-v2-ti-am4372-cpu",
>>>> + .data = &am4x_soc_data, },
>>>> + { .compatible = "operating-points-v2-ti-dra7-cpu",
>>>> + .data = &dra7_soc_data },
>>>
>>> You should be using your SoC compatible strings here. OPP compatible
>>> property isn't supposed to be (mis)used for this purpose.
>>>
>>
>> Referring to my comments in patch 1, what if we end up changing the bindings
>> based on DT maintainer comments? We will have these compatible strings, and
>> at that point is it acceptable to match against them? Or is it still better
>> to match to SoC compatibles? I think it makes sense to just probe against
>> these.
>
> But even then I think these are not correct. You should have added a
> single compatible string: operating-points-v2-ti-cpu.
>
> As the properties will stay the same across machines. And then you
> need to use SoC strings here.
>
Are you opposed to moving _of_get_opp_desc_node from
drivers/base/power/opp/opp.h to include/linux/pm_opp.h and renaming it
appropriately?
If I move the ti properties out of the cpu node, as discussed in patch 1
of this series, and into the operating-points-v2 table, I need a way to
get the operating-points-v2 device node and I think it makes sense to
reuse this as it is what the opp framework uses internally to parse the
phandle to the opp table.
Regards,
Dave
^ permalink raw reply
* [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count
From: Arnd Bergmann @ 2016-09-21 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <815bebc1-96c9-2131-930d-bccdd4bf1c55@gmail.com>
On Wednesday, September 21, 2016 6:12:28 PM CEST zhichang wrote:
> On 2016?09?15? 05:33, Arnd Bergmann wrote:
> > On Wednesday, September 14, 2016 11:04:33 PM CEST zhichang.yuan wrote:
> >> The 8250_hisi_lpc.c support both ACPI and dts similar to 8250_dw :
> >>
> >> +static struct platform_driver hs_lpc8250_driver = {
> >> + .driver = {
> >> + .name = "hisi-lpc-uart",
> >> + .of_match_table = hs8250_of_match,
> >> + .acpi_match_table = ACPI_PTR(hs8250_acpi_match),
> >>
> >> So, I am a little confused why we need to support dts in 8250_of.c and support ACPI in another
> >> driver file.
> >>
> >
> > After looking again, I'm pretty sure that drivers/tty/serial/8250/8250_pnp.c
> > will handle the ACPI case without modifications, you just need to adapt
> > the 8250_of driver to handle IORESOURCE_IO ports. This will be required
> > anyway with the next version once the LPC bridge is on the PCI bus.
> >
>
> Yes. You are right.
>
> When the indirectIO patch is accepted, no much changes needed in these two file to support LPC UART.
>
> BTW, what is your target to change these two files to support LPC uart?
> Do you think we don't need to add many new c files??
I think by modifying 8250_of.c, you should be able to make any UART on
some LPC bus work, regardless of what controller is used.
The ACPI version (8250_pnp.c) shouldn't need any changes at all if I
read that correctly.
Arnd
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-21 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDn4CeoB+sELQ5yQDQUS158raEu5QohPH2PsVtuGpfGKHg@mail.gmail.com>
On Wed, Sep 21, 2016 at 11:58:22AM -0700, Duc Dang wrote:
> On Wed, Sep 21, 2016 at 11:04 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
> > The existing x86 practice is to use PNP0C02 devices for this purpose,
> > and I think we should just follow that practice.
> >
> > ...
> >
> > My point is that the hard-coding should not be buried in a driver
> > where it's invisible to the rest of the kernel. If we hard-code it in
> > a quirk that adds _CRS entries, then the kernel will work just like it
> > would if the firmware had been correct in the first place. The
> > resource will appear in /sys/devices/pnp*/*/resources and /proc/iomem,
> > and if we ever used _SRS to assign or move ACPI devices, we would know
> > to avoid the bridge resource.
>
> Are you suggesting to add code similar to functions in
> linux/drivers/pnp/quirks.c to declare/attach the additional resource
> that the host need to have when the resource is not in MCFG table?
Yes, but what I'm suggesting is actually a little stronger. This has
nothing to do with whether a resource is in the MCFG table or not.
I'm suggesting ACPI firmware should always describe the resource. If the
firmware is defective and doesn't describe it, we should add a quirk in
pnp/quirks.c to add a resource for it.
Bjorn
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-21 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F87CF8F@lhreml507-mbx>
On Wed, Sep 21, 2016 at 02:10:55PM +0000, Gabriele Paoloni wrote:
> Hi Bjorn
>
> [...]
>
>
> >
> > If future hardware is completely ECAM-compliant and we don't need any
> > more MCFG quirks, that would be great.
> >
> > But we'll still need to describe that memory-mapped config space
> > somewhere. If that's done with PNP0C02 or similar devices (as is done
> > on my x86 laptop), we'd be all set.
> >
> > If we need to work around firmware in the field that doesn't do that,
> > one possibility is a PNP quirk along the lines of
> > quirk_amd_mmconfig_area().
>
> So, if my understanding is correct, for platforms that have not been
> shipped yet you propose to use PNP0C02 in the ACPI table in order to
> declare a motherboard reserved resource whereas for shipped platforms
> you propose to have a quirk along pnp_fixups in order to track the
> resource usage even if values are hardcoded...correct?
Yes. I'm open to alternate proposals, but x86 uses PNP0C02, and
following existing practice seems reasonable.
> Before Tomasz came up with this patchset we had a call between the vendors
> involved in this PCI quirks saga and other guys from Linaro and ARM.
>
> Lorenzo summarized the outcome as in the following link
> http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html
>
> Since this quirks mechanism has been discussed for quite a long time now
> IMHO it would be good to have a last call including also you (Bjorn) so
> that we can all agree on what to do and we avoid changing our drivers again
> and again...
I think we're converging pretty fast. As far as I'm concerned, the
v6 ECAM quirks implementation is perfect. The only remaining issue is
reporting the ECAM resources, and I haven't seen objections to using
PNP0C02 + PNP quirks for broken firmware.
There is the question of how or whether to associate a PNP0A03 PCI
bridge with resources from a different PNP0C02 device, but that's not
super important. If the hard-coded resources appear both in a quirk
and in the PCI bridge driver, it's ugly but not the end of the world.
We've still achieved the objective of avoiding landmines in the
address space.
Bjorn
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Duc Dang @ 2016-09-21 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921180457.GB20006@localhost>
On Wed, Sep 21, 2016 at 11:04 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
>> On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote:
>> > On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
>>
>> [...]
>>
>> > > None of these platforms can be fixed entirely in software, and given
>> > > that we will not be adding quirks for new broken hardware, we should
>> > > ask ourselves whether having two versions of a quirk, i.e., one for
>> > > broken hardware + currently shipping firmware, and one for the same
>> > > broken hardware with fixed firmware is really an improvement over what
>> > > has been proposed here.
>> >
>> > We're talking about two completely different types of quirks:
>> >
>> > 1) MCFG quirks to use memory-mapped config space that doesn't quite
>> > conform to the ECAM model in the PCIe spec, and
>> >
>> > 2) Some yet-to-be-determined method to describe address space
>> > consumed by a bridge.
>> >
>> > The first two patches of this series are a nice implementation for 1).
>> > The third patch (ThunderX-specific) is one possibility for 2), but I
>> > don't like it because there's no way for generic software like the
>> > ACPI core to discover these resources.
>>
>> Ok, so basically this means that to implement (2) we need to assign
>> some sort of _HID to these quirky PCI bridges (so that we know what
>> device they represent and we can retrieve their _CRS). I take from
>> this discussion that the goal is to make sure that all non-config
>> resources have to be declared through _CRS device objects, which is
>> fine but that requires a FW update (unless we can fabricate ACPI
>> devices and corresponding _CRS in the kernel whenever we match a
>> given MCFG table signature).
>
> All resources consumed by ACPI devices should be declared through
> _CRS. If you want to fabricate ACPI devices or _CRS via kernel
> quirks, that's fine with me. This could be triggered via MCFG
> signature, DMI info, host bridge _HID, etc.
>
>> We discussed this already and I think we should make a decision:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414722.html
>>
>> > > > I'd like to step back and come up with some understanding of how
>> > > > non-broken firmware *should* deal with this issue. Then, if we *do*
>> > > > work around this particular broken firmware in the kernel, it would be
>> > > > nice to do it in a way that fits in with that understanding.
>> > > >
>> > > > For example, if a companion ACPI device is the preferred solution, an
>> > > > ACPI quirk could fabricate a device with the required resources. That
>> > > > would address the problem closer to the source and make it more likely
>> > > > that the rest of the system will work correctly: /proc/iomem could
>> > > > make sense, things that look at _CRS generically would work (e.g,
>> > > > /sys/, an admittedly hypothetical "lsacpi", etc.)
>> > > >
>> > > > Hard-coding stuff in drivers is a point solution that doesn't provide
>> > > > any guidance for future platforms and makes it likely that the hack
>> > > > will get copied into even more drivers.
>> > > >
>> > >
>> > > OK, I see. But the guidance for future platforms should be 'do not
>> > > rely on quirks', and what I am arguing here is that the more we polish
>> > > up this code and make it clean and reusable, the more likely it is
>> > > that will end up getting abused by new broken hardware that we set out
>> > > to reject entirely in the first place.
>> > >
>> > > So of course, if the quirk involves claiming resources, let's make
>> > > sure that this occurs in the cleanest and most compliant way possible.
>> > > But any factoring/reuse concerns other than for the current crop of
>> > > broken hardware should be avoided imo.
>> >
>> > If future hardware is completely ECAM-compliant and we don't need any
>> > more MCFG quirks, that would be great.
>>
>> Yes.
>>
>> > But we'll still need to describe that memory-mapped config space
>> > somewhere. If that's done with PNP0C02 or similar devices (as is done
>> > on my x86 laptop), we'd be all set.
>>
>> I am not sure I understand what you mean here. Are you referring
>> to MCFG regions reported as PNP0c02 resources through its _CRS ?
>
> Yes. PCI Firmware Spec r3.0, Table 4-2, note 2 says address ranges
> reported via MCFG or _CBA should be reserved by _CRS of a PNP0C02
> device.
>
>> IIUC PNP0C02 is a reservation mechanism, but it does not help us
>> associate its _CRS to a specific PCI host bridge instance, right ?
>
> Gab proposed a hierarchy that *would* associate a PNP0C02 device with
> a PCI bridge:
>
> Device (PCI1) {
> Name (_HID, "HISI0080") // PCI Express Root Bridge
> Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
> Method (_CRS, 0, Serialized) { // Root complex resources (windows) }
> Device (RES0) {
> Name (_HID, "HISI0081") // HiSi PCIe RC config base address
> Name (_CID, "PNP0C02") // Motherboard reserved resource
> Name (_CRS, ResourceTemplate () { ... }
> }
> }
>
> That's a possibility. The PCI Firmware Spec suggests putting RES0 at
> the root (under \_SB), but I don't know why.
>
> Putting it at the root means we couldn't generically associate it with
> a bridge, although I could imagine something like this:
>
> Device (RES1) {
> Name (_HID, "HISI0081") // HiSi PCIe RC config base address
> Name (_CID, "PNP0C02") // Motherboard reserved resource
> Name (_CRS, ResourceTemplate () { ... }
> Method (BRDG) { "PCI1" } // hand-wavy ASL
> }
> Device (PCI1) {
> Name (_HID, "HISI0080") // PCI Express Root Bridge
> Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
> Method (_CRS, 0, Serialized) { // Root complex resources (windows) }
> }
>
> Where you could search PNP0C02 devices for a cookie that matched the
> host bridge.
>
>> > If we need to work around firmware in the field that doesn't do that,
>> > one possibility is a PNP quirk along the lines of
>> > quirk_amd_mmconfig_area().
>>
>> You mean matching PNP0C01/PNP0c02 and create a resource (that has to
>> hardcoded in a static array in the kernel anyway, there is no way to
>> retrieve it otherwise) in the corresponding PNP quirk handler ?
>
> Right. On some hardware we can read the resource out of a
> device-specific register, as we do in quirk_intel_mch(). But if
> that's not possible, it would have to be hard-coded.
>
>> And it is not a given we can match against PNP0c01/PNP0c02.
>>
>> So it looks like the only solution is allocating an _HID for each
>> host bridge that is not ECAM compliant to add resources to its _CRS
>> (unless the MCFG quirk does not need any additional data/resource,
>> eg "use different set of PCI accessorsi 32-bit vs byte-access").
>
> It doesn't matter whether it's ECAM-compliant or not. Any
> memory-mapped config space should be reported via some device's _CRS.
>
> The existing x86 practice is to use PNP0C02 devices for this purpose,
> and I think we should just follow that practice.
>
>> For FW that is immutable I really do not see what we can do apart
>> from hardcoding the non-config resources (consumed by a bridge),
>> somehow.
>
> Right. Well, I assume you mean we should hard-code "non-window
> resources consumed directly by a bridge". If firmware in the field is
> broken, we should work around it, and that may mean hard-coding some
> resources.
>
> My point is that the hard-coding should not be buried in a driver
> where it's invisible to the rest of the kernel. If we hard-code it in
> a quirk that adds _CRS entries, then the kernel will work just like it
> would if the firmware had been correct in the first place. The
> resource will appear in /sys/devices/pnp*/*/resources and /proc/iomem,
> and if we ever used _SRS to assign or move ACPI devices, we would know
> to avoid the bridge resource.
Hi Bjorn,
Are you suggesting to add code similar to functions in
linux/drivers/pnp/quirks.c to declare/attach the additional resource
that the host need to have when the resource is not in MCFG table?
>
> Bjorn
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH] clk: mediatek: clk-mt8173: Unmap region obtained by of_iomap
From: Stephen Boyd @ 2016-09-21 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474360242-15126-1-git-send-email-arvind.yadav.cs@gmail.com>
On 09/20, Arvind Yadav wrote:
> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
>
> Free memory mapping, if init is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox