* [PATCH v2 5/7] ARM: perf_event: Fully support Krait CPU PMU events
From: Stephen Boyd @ 2014-01-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389808535-23852-1-git-send-email-sboyd@codeaurora.org>
Krait supports a set of performance monitor region event
selection registers (PMRESR) sitting behind a cp15 based
interface that extend the architected PMU events to include Krait
CPU and Venum VFP specific events. To use these events the user
is expected to program the region register (PMRESRn) with the
event code shifted into the group they care about and then point
the PMNx event at that region+group combo by writing a
PMRESRn_GROUPx event. Add support for this hardware.
Note: the raw event number is a pure software construct that
allows us to map the multi-dimensional number space of regions,
groups, and event codes into a flat event number space suitable
for use by the perf framework.
This is based on code originally written by Ashwin Chaugule and
Neil Leeder [1].
[1] https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/kernel/perf_event_msm_krait.c?h=msm-3.4
Cc: Neil Leeder <nleeder@codeaurora.org>
Cc: Ashwin Chaugule <ashwinc@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/kernel/perf_event_v7.c | 398 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 392 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 16386b1d27a8..daa675529c12 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -18,6 +18,10 @@
#ifdef CONFIG_CPU_V7
+#include <asm/cp15.h>
+#include <asm/vfp.h>
+#include "../vfp/vfpinstr.h"
+
/*
* Common ARMv7 event types
*
@@ -109,6 +113,20 @@ enum armv7_a15_perf_types {
ARMV7_A15_PERFCTR_PC_WRITE_SPEC = 0x76,
};
+/* ARMv7 Krait specific event types */
+enum krait_perf_types {
+ KRAIT_PMRESR0_GROUP0 = 0xcc,
+ KRAIT_PMRESR1_GROUP0 = 0xd0,
+ KRAIT_PMRESR2_GROUP0 = 0xd4,
+ KRAIT_VPMRESR0_GROUP0 = 0xd8,
+
+ KRAIT_PERFCTR_L1_ICACHE_ACCESS = 0x10011,
+ KRAIT_PERFCTR_L1_ICACHE_MISS = 0x10010,
+
+ KRAIT_PERFCTR_L1_ITLB_ACCESS = 0x12222,
+ KRAIT_PERFCTR_L1_DTLB_ACCESS = 0x12210,
+};
+
/*
* Cortex-A8 HW events mapping
*
@@ -779,8 +797,8 @@ static const unsigned krait_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
},
[C(L1I)] = {
[C(OP_READ)] = {
- [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
- [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_ACCESS)] = KRAIT_PERFCTR_L1_ICACHE_ACCESS,
+ [C(RESULT_MISS)] = KRAIT_PERFCTR_L1_ICACHE_MISS,
},
[C(OP_WRITE)] = {
[C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
@@ -807,11 +825,11 @@ static const unsigned krait_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
},
[C(DTLB)] = {
[C(OP_READ)] = {
- [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_ACCESS)] = KRAIT_PERFCTR_L1_DTLB_ACCESS,
[C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
},
[C(OP_WRITE)] = {
- [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_ACCESS)] = KRAIT_PERFCTR_L1_DTLB_ACCESS,
[C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
},
[C(OP_PREFETCH)] = {
@@ -821,11 +839,11 @@ static const unsigned krait_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
},
[C(ITLB)] = {
[C(OP_READ)] = {
- [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_ACCESS)] = KRAIT_PERFCTR_L1_ITLB_ACCESS,
[C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
},
[C(OP_WRITE)] = {
- [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_ACCESS)] = KRAIT_PERFCTR_L1_ITLB_ACCESS,
[C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
},
[C(OP_PREFETCH)] = {
@@ -1428,6 +1446,369 @@ static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
return 0;
}
+/*
+ * Krait Performance Monitor Region Event Selection Register (PMRESRn)
+ *
+ * 31 30 24 16 8 0
+ * +--------------------------------+
+ * PMRESR0 | EN | CC | CC | CC | CC | N = 1, R = 0
+ * +--------------------------------+
+ * PMRESR1 | EN | CC | CC | CC | CC | N = 1, R = 1
+ * +--------------------------------+
+ * PMRESR2 | EN | CC | CC | CC | CC | N = 1, R = 2
+ * +--------------------------------+
+ * VPMRESR0 | EN | CC | CC | CC | CC | N = 2, R = ?
+ * +--------------------------------+
+ * EN | G=3 | G=2 | G=1 | G=0
+ *
+ * Event Encoding:
+ *
+ * hwc->config_base = 0xNRCCG
+ *
+ * N = prefix, 1 for Krait CPU (PMRESRn), 2 for Venum VFP (VPMRESR)
+ * R = region register
+ * CC = class of events the group G is choosing from
+ * G = group or particular event
+ *
+ * Example: 0x12021 is a Krait CPU event in PMRESR2's group 1 with code 2
+ *
+ * A region (R) corresponds to a piece of the CPU (execution unit, instruction
+ * unit, etc.) while the event code (CC) corresponds to a particular class of
+ * events (interrupts for example). An event code is broken down into
+ * groups (G) that can be mapped into the PMU (irq, fiqs, and irq+fiqs for
+ * example).
+ */
+
+#define KRAIT_EVENT (1 << 16)
+#define VENUM_EVENT (2 << 16)
+#define KRAIT_EVENT_MASK (KRAIT_EVENT | VENUM_EVENT)
+#define PMRESRn_EN BIT(31)
+#define NUM_PMRESR (KRAIT_VPMRESR0_GROUP0 + 4 - KRAIT_PMRESR0_GROUP0)
+
+static DEFINE_PER_CPU(unsigned long [BITS_TO_LONGS(NUM_PMRESR)], pmresrn_used);
+
+static u32 krait_read_pmresrn(int n)
+{
+ u32 val;
+
+ switch (n) {
+ case 0:
+ asm volatile("mrc p15, 1, %0, c9, c15, 0" : "=r" (val));
+ break;
+ case 1:
+ asm volatile("mrc p15, 1, %0, c9, c15, 1" : "=r" (val));
+ break;
+ case 2:
+ asm volatile("mrc p15, 1, %0, c9, c15, 2" : "=r" (val));
+ break;
+ default:
+ BUG(); /* Should be validated in krait_pmu_get_event_idx() */
+ }
+
+ return val;
+}
+
+static void krait_write_pmresrn(int n, u32 val)
+{
+ switch (n) {
+ case 0:
+ asm volatile("mcr p15, 1, %0, c9, c15, 0" : : "r" (val));
+ break;
+ case 1:
+ asm volatile("mcr p15, 1, %0, c9, c15, 1" : : "r" (val));
+ break;
+ case 2:
+ asm volatile("mcr p15, 1, %0, c9, c15, 2" : : "r" (val));
+ break;
+ default:
+ BUG(); /* Should be validated in krait_pmu_get_event_idx() */
+ }
+}
+
+static u32 krait_read_vpmresr0(void)
+{
+ u32 val;
+ asm volatile("mrc p10, 7, %0, c11, c0, 0" : "=r" (val));
+ return val;
+}
+
+static void krait_write_vpmresr0(u32 val)
+{
+ asm volatile("mcr p10, 7, %0, c11, c0, 0" : : "r" (val));
+}
+
+static void krait_pre_vpmresr0(u32 *venum_orig_val, u32 *fp_orig_val)
+{
+ u32 venum_new_val;
+ u32 fp_new_val;
+
+ /* CPACR Enable CP10 and CP11 access */
+ *venum_orig_val = get_copro_access();
+ venum_new_val = *venum_orig_val | CPACC_SVC(10) | CPACC_SVC(11);
+ set_copro_access(venum_new_val);
+
+ /* Enable FPEXC */
+ *fp_orig_val = fmrx(FPEXC);
+ fp_new_val = *fp_orig_val | FPEXC_EN;
+ fmxr(FPEXC, fp_new_val);
+}
+
+static void krait_post_vpmresr0(u32 venum_orig_val, u32 fp_orig_val)
+{
+ /* Restore FPEXC */
+ fmxr(FPEXC, fp_orig_val);
+ isb();
+ /* Restore CPACR */
+ set_copro_access(venum_orig_val);
+}
+
+static u32 krait_get_pmresrn_event(int region)
+{
+ static const u32 pmresrn_table[] = { KRAIT_PMRESR0_GROUP0,
+ KRAIT_PMRESR1_GROUP0,
+ KRAIT_PMRESR2_GROUP0 };
+ return pmresrn_table[region];
+}
+
+static void krait_evt_setup(int idx, u32 config_base)
+{
+ u32 val;
+ u32 mask;
+ u32 vval, fval;
+ unsigned int region;
+ unsigned int group;
+ unsigned int code;
+ unsigned int group_shift;
+ bool venum_event;
+
+ venum_event = !!(config_base & VENUM_EVENT);
+ region = (config_base >> 12) & 0xf;
+ code = (config_base >> 4) & 0xff;
+ group = (config_base >> 0) & 0xf;
+
+ group_shift = group * 8;
+ mask = 0xff << group_shift;
+
+ /* Configure evtsel for the region and group */
+ if (venum_event)
+ val = KRAIT_VPMRESR0_GROUP0;
+ else
+ val = krait_get_pmresrn_event(region);
+ val += group;
+ /* Mix in mode-exclusion bits */
+ val |= config_base & (ARMV7_EXCLUDE_USER | ARMV7_EXCLUDE_PL1);
+ armv7_pmnc_write_evtsel(idx, val);
+
+ asm volatile("mcr p15, 0, %0, c9, c15, 0" : : "r" (0));
+
+ if (venum_event) {
+ krait_pre_vpmresr0(&vval, &fval);
+ val = krait_read_vpmresr0();
+ val &= ~mask;
+ val |= code << group_shift;
+ val |= PMRESRn_EN;
+ krait_write_vpmresr0(val);
+ krait_post_vpmresr0(vval, fval);
+ } else {
+ val = krait_read_pmresrn(region);
+ val &= ~mask;
+ val |= code << group_shift;
+ val |= PMRESRn_EN;
+ krait_write_pmresrn(region, val);
+ }
+}
+
+static u32 krait_clear_pmresrn_group(u32 val, int group)
+{
+ u32 mask;
+ int group_shift;
+
+ group_shift = group * 8;
+ mask = 0xff << group_shift;
+ val &= ~mask;
+
+ /* Don't clear enable bit if entire region isn't disabled */
+ if (val & ~PMRESRn_EN)
+ return val |= PMRESRn_EN;
+
+ return 0;
+}
+
+static void krait_clearpmu(u32 config_base)
+{
+ u32 val;
+ u32 vval, fval;
+ unsigned int region;
+ unsigned int group;
+ bool venum_event;
+
+ venum_event = !!(config_base & VENUM_EVENT);
+ region = (config_base >> 12) & 0xf;
+ group = (config_base >> 0) & 0xf;
+
+ if (venum_event) {
+ krait_pre_vpmresr0(&vval, &fval);
+ val = krait_read_vpmresr0();
+ val = krait_clear_pmresrn_group(val, group);
+ krait_write_vpmresr0(val);
+ krait_post_vpmresr0(vval, fval);
+ } else {
+ val = krait_read_pmresrn(region);
+ val = krait_clear_pmresrn_group(val, group);
+ krait_write_pmresrn(region, val);
+ }
+}
+
+static void krait_pmu_disable_event(struct perf_event *event)
+{
+ unsigned long flags;
+ struct hw_perf_event *hwc = &event->hw;
+ int idx = hwc->idx;
+ struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+
+ /* Disable counter and interrupt */
+ raw_spin_lock_irqsave(&events->pmu_lock, flags);
+
+ /* Disable counter */
+ armv7_pmnc_disable_counter(idx);
+
+ /*
+ * Clear pmresr code (if destined for PMNx counters)
+ */
+ if (hwc->config_base & KRAIT_EVENT_MASK)
+ krait_clearpmu(hwc->config_base);
+
+ /* Disable interrupt for this counter */
+ armv7_pmnc_disable_intens(idx);
+
+ raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
+}
+
+static void krait_pmu_enable_event(struct perf_event *event)
+{
+ unsigned long flags;
+ struct hw_perf_event *hwc = &event->hw;
+ int idx = hwc->idx;
+ struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+
+ /*
+ * Enable counter and interrupt, and set the counter to count
+ * the event that we're interested in.
+ */
+ raw_spin_lock_irqsave(&events->pmu_lock, flags);
+
+ /* Disable counter */
+ armv7_pmnc_disable_counter(idx);
+
+ /*
+ * Set event (if destined for PMNx counters)
+ * We set the event for the cycle counter because we
+ * have the ability to perform event filtering.
+ */
+ if (hwc->config_base & KRAIT_EVENT_MASK)
+ krait_evt_setup(idx, hwc->config_base);
+ else
+ armv7_pmnc_write_evtsel(idx, hwc->config_base);
+
+ /* Enable interrupt for this counter */
+ armv7_pmnc_enable_intens(idx);
+
+ /* Enable counter */
+ armv7_pmnc_enable_counter(idx);
+
+ raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
+}
+
+static void krait_pmu_reset(void *info)
+{
+ u32 vval, fval;
+
+ armv7pmu_reset(info);
+
+ /* Clear all pmresrs */
+ krait_write_pmresrn(0, 0);
+ krait_write_pmresrn(1, 0);
+ krait_write_pmresrn(2, 0);
+
+ krait_pre_vpmresr0(&vval, &fval);
+ krait_write_vpmresr0(0);
+ krait_post_vpmresr0(vval, fval);
+}
+
+/*
+ * We check for column exclusion constraints here.
+ * Two events cant use the same group within a pmresr register.
+ */
+static int krait_pmu_get_event_idx(struct pmu_hw_events *cpuc,
+ struct perf_event *event)
+{
+ int idx;
+ int bit;
+ unsigned int prefix;
+ unsigned int region;
+ unsigned int code;
+ unsigned int group;
+ bool krait_event;
+ struct hw_perf_event *hwc = &event->hw;
+ unsigned long *bitmap = this_cpu_ptr(pmresrn_used);
+
+ region = (hwc->config_base >> 12) & 0xf;
+ code = (hwc->config_base >> 4) & 0xff;
+ group = (hwc->config_base >> 0) & 0xf;
+ krait_event = !!(hwc->config_base & KRAIT_EVENT_MASK);
+
+ if (krait_event) {
+ /* Ignore invalid events */
+ if (group > 3 || region > 2)
+ return -EINVAL;
+ prefix = hwc->config_base & KRAIT_EVENT_MASK;
+ if (prefix != KRAIT_EVENT && prefix != VENUM_EVENT)
+ return -EINVAL;
+ if (prefix == VENUM_EVENT && (code & 0xe0))
+ return -EINVAL;
+
+ if (prefix == VENUM_EVENT)
+ bit = KRAIT_VPMRESR0_GROUP0;
+ else
+ bit = krait_get_pmresrn_event(region);
+ bit -= krait_get_pmresrn_event(0);
+ bit += group;
+
+ if (test_and_set_bit(bit, bitmap))
+ return -EAGAIN;
+ }
+
+ idx = armv7pmu_get_event_idx(cpuc, event);
+ if (idx < 0 && krait_event)
+ clear_bit(bit, bitmap);
+
+ return idx;
+}
+
+static void krait_pmu_clear_event_idx(struct perf_event *event)
+{
+ int bit;
+ struct hw_perf_event *hwc = &event->hw;
+ unsigned int region;
+ unsigned int group;
+ bool krait_event;
+ unsigned long *bitmap = this_cpu_ptr(pmresrn_used);
+
+ region = (hwc->config_base >> 12) & 0xf;
+ group = (hwc->config_base >> 0) & 0xf;
+ krait_event = !!(hwc->config_base & KRAIT_EVENT_MASK);
+
+ if (krait_event) {
+ if (hwc->config_base & VENUM_EVENT)
+ bit = KRAIT_VPMRESR0_GROUP0;
+ else
+ bit = krait_get_pmresrn_event(region);
+ bit -= krait_get_pmresrn_event(0);
+ bit += group;
+ clear_bit(bit, bitmap);
+ }
+}
+
static int krait_pmu_init(struct arm_pmu *cpu_pmu)
{
armv7pmu_init(cpu_pmu);
@@ -1440,6 +1821,11 @@ static int krait_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->map_event = krait_map_event;
cpu_pmu->num_events = armv7_read_num_pmnc_events();
cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ cpu_pmu->reset = krait_pmu_reset;
+ cpu_pmu->enable = krait_pmu_enable_event;
+ cpu_pmu->disable = krait_pmu_disable_event;
+ cpu_pmu->get_event_idx = krait_pmu_get_event_idx;
+ cpu_pmu->clear_event_idx = krait_pmu_clear_event_idx;
return 0;
}
#else
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [RFC 2/2] arm: Get rid of meminfo
From: Laura Abbott @ 2014-01-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115112516.GA17371@arm.com>
On 1/15/2014 3:25 AM, Catalin Marinas wrote:
> On Wed, Jan 15, 2014 at 10:53:47AM +0000, Russell King - ARM Linux wrote:
>> On Wed, Jan 15, 2014 at 10:22:02AM +0000, Catalin Marinas wrote:
>>> On 15 January 2014 09:49, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>>> On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
>>>>> memblock is now fully integrated into the kernel and is the prefered
>>>>> method for tracking memory. Rather than reinvent the wheel with
>>>>> meminfo, migrate to using memblock directly instead of meminfo as
>>>>> an intermediate.
>>>>
>>>> The reason I never killed meminfo was that for some of the functions here
>>>> is that meminfo has a slightly different property to memblock.
>>>>
>>>> With meminfo, each sparsemem section mapping or discontigmem node must be
>>>> specified as a separate bank of memory, even if it is contiguous with the
>>>> previous block. This is so that the functions which walk the page arrays
>>>> can do so efficiently (without having to convert from a PFN to a struct
>>>> page for every page in the system, which is very inefficient.)
>>>
>>> pfn_to_page() conversion is indeed expensive with sparsemem (on
>>> 32-bit) but does meminfo actually add a noticeable improvement to the
>>> boot time? I don't think so but it's worth testing (something a
>>> thousand cycles maximum would be lost in the noise).
>>
>> Why do you ask about boot time?
>
> Is meminfo used on a critical path at run-time?
>
As far as I can tell, the only place meminfo is used after
initialization is in show_mem which isn't a critical path. Are there
other paths I missed?
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 4/7] ARM: perf_event: Add hook for event index clearing
From: Stephen Boyd @ 2014-01-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389808535-23852-1-git-send-email-sboyd@codeaurora.org>
On Krait processors we have a many-to-one relationship between
raw CPU events and the event programmed into the PMNx counter.
Two raw CPU events could map to the same value programmed in the
PMNx counter. To avoid this problem, we check for collisions
during the get_event_idx() callback by setting a bit in a bitmap
whenever a certain event is used in a PMNx counter (see the next
patch). Unfortunately, we don't have a hook to clear this bit in
the bitmap when the event is deleted so let's add an optional
clear_event_idx() callback for this purpose.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/include/asm/pmu.h | 1 +
arch/arm/kernel/perf_event.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index f24edad26c70..994ac445e792 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -71,6 +71,7 @@ struct arm_pmu {
void (*disable)(struct perf_event *event);
int (*get_event_idx)(struct pmu_hw_events *hw_events,
struct perf_event *event);
+ void (*clear_event_idx)(struct perf_event *event);
int (*set_event_filter)(struct hw_perf_event *evt,
struct perf_event_attr *attr);
u32 (*read_counter)(struct perf_event *event);
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index e76750980b38..06c6b191c8db 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -207,6 +207,8 @@ armpmu_del(struct perf_event *event, int flags)
armpmu_stop(event, PERF_EF_UPDATE);
hw_events->events[idx] = NULL;
clear_bit(idx, hw_events->used_mask);
+ if (armpmu->clear_event_idx)
+ armpmu->clear_event_idx(event);
perf_event_update_userpage(event);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2 3/7] ARM: perf_event: Add basic support for Krait CPU PMUs
From: Stephen Boyd @ 2014-01-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389808535-23852-1-git-send-email-sboyd@codeaurora.org>
Add basic support for the Krait CPU PMU. This allows us to use
the architected functionality of the PMU.
This is based on code originally written by Ashwin Chaugule and
Neil Leeder [1].
[1] https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/kernel/perf_event_msm_krait.c?h=msm-3.4
Cc: Neil Leeder <nleeder@codeaurora.org>
Cc: Ashwin Chaugule <ashwinc@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/kernel/perf_event_cpu.c | 1 +
arch/arm/kernel/perf_event_v7.c | 164 +++++++++++++++++++++++++++++++++++++++
2 files changed, 165 insertions(+)
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 68d02ca0ca1b..ed571d386c0b 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -229,6 +229,7 @@ static struct of_device_id cpu_pmu_of_device_ids[] = {
{.compatible = "arm,arm11mpcore-pmu", .data = armv6mpcore_pmu_init},
{.compatible = "arm,arm1176-pmu", .data = armv6pmu_init},
{.compatible = "arm,arm1136-pmu", .data = armv6pmu_init},
+ {.compatible = "qcom,krait-pmu", .data = krait_pmu_init},
{},
};
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 039cffb053a7..16386b1d27a8 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -732,6 +732,138 @@ static const unsigned armv7_a7_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
};
/*
+ * Krait HW events mapping
+ */
+static const unsigned krait_perf_map[PERF_COUNT_HW_MAX] = {
+ [PERF_COUNT_HW_CPU_CYCLES] = ARMV7_PERFCTR_CPU_CYCLES,
+ [PERF_COUNT_HW_INSTRUCTIONS] = ARMV7_PERFCTR_INSTR_EXECUTED,
+ [PERF_COUNT_HW_CACHE_REFERENCES] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_CACHE_MISSES] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = ARMV7_PERFCTR_PC_WRITE,
+ [PERF_COUNT_HW_BRANCH_MISSES] = ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
+ [PERF_COUNT_HW_BUS_CYCLES] = ARMV7_PERFCTR_CLOCK_CYCLES,
+};
+
+static const unsigned krait_perf_map_no_branch[PERF_COUNT_HW_MAX] = {
+ [PERF_COUNT_HW_CPU_CYCLES] = ARMV7_PERFCTR_CPU_CYCLES,
+ [PERF_COUNT_HW_INSTRUCTIONS] = ARMV7_PERFCTR_INSTR_EXECUTED,
+ [PERF_COUNT_HW_CACHE_REFERENCES] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_CACHE_MISSES] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = HW_OP_UNSUPPORTED,
+ [PERF_COUNT_HW_BRANCH_MISSES] = ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
+ [PERF_COUNT_HW_BUS_CYCLES] = ARMV7_PERFCTR_CLOCK_CYCLES,
+};
+
+static const unsigned krait_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+ [C(L1D)] = {
+ /*
+ * The performance counters don't differentiate between read
+ * and write accesses/misses so this isn't strictly correct,
+ * but it's the best we can do. Writes and reads get
+ * combined.
+ */
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = ARMV7_PERFCTR_L1_DCACHE_ACCESS,
+ [C(RESULT_MISS)] = ARMV7_PERFCTR_L1_DCACHE_REFILL,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = ARMV7_PERFCTR_L1_DCACHE_ACCESS,
+ [C(RESULT_MISS)] = ARMV7_PERFCTR_L1_DCACHE_REFILL,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ },
+ [C(L1I)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ },
+ [C(LL)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ },
+ [C(DTLB)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ },
+ [C(ITLB)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ },
+ [C(BPU)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = ARMV7_PERFCTR_PC_BRANCH_PRED,
+ [C(RESULT_MISS)] = ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = ARMV7_PERFCTR_PC_BRANCH_PRED,
+ [C(RESULT_MISS)] = ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ },
+ [C(NODE)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)] = CACHE_OP_UNSUPPORTED,
+ },
+ },
+};
+
+/*
* Perf Events' indices
*/
#define ARMV7_IDX_CYCLE_COUNTER 0
@@ -1212,6 +1344,18 @@ static int armv7_a7_map_event(struct perf_event *event)
&armv7_a7_perf_cache_map, 0xFF);
}
+static int krait_map_event(struct perf_event *event)
+{
+ return armpmu_map_event(event, &krait_perf_map,
+ &krait_perf_cache_map, 0xFFFFF);
+}
+
+static int krait_map_event_no_branch(struct perf_event *event)
+{
+ return armpmu_map_event(event, &krait_perf_map_no_branch,
+ &krait_perf_cache_map, 0xFFFFF);
+}
+
static void armv7pmu_init(struct arm_pmu *cpu_pmu)
{
cpu_pmu->handle_irq = armv7pmu_handle_irq;
@@ -1283,6 +1427,21 @@ static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
return 0;
}
+
+static int krait_pmu_init(struct arm_pmu *cpu_pmu)
+{
+ armv7pmu_init(cpu_pmu);
+ cpu_pmu->name = "ARMv7 Krait";
+ /* Some early versions of Krait don't support PC write events */
+ if (of_property_read_bool(cpu_pmu->plat_device->dev.of_node,
+ "qcom,no-pc-write"))
+ cpu_pmu->map_event = krait_map_event_no_branch;
+ else
+ cpu_pmu->map_event = krait_map_event;
+ cpu_pmu->num_events = armv7_read_num_pmnc_events();
+ cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ return 0;
+}
#else
static inline int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
{
@@ -1308,4 +1467,9 @@ static inline int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
{
return -ENODEV;
}
+
+static inline int krait_pmu_init(struct arm_pmu *cpu_pmu)
+{
+ return -ENODEV;
+}
#endif /* CONFIG_CPU_V7 */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2 2/7] ARM: perf_event: Assign pdev pointer earlier for CPU PMUs
From: Stephen Boyd @ 2014-01-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389808535-23852-1-git-send-email-sboyd@codeaurora.org>
We want to inspect the of_node that the pdev is pointing to in
the Krait CPU specific PMU initialization function. Assign it
earlier so that we don't crash with a NULL pointer dereference.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/kernel/perf_event_cpu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 6efd8aab15df..68d02ca0ca1b 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -311,6 +311,9 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ cpu_pmu = pmu;
+ cpu_pmu->plat_device = pdev;
+
if (node && (of_id = of_match_node(cpu_pmu_of_device_ids, pdev->dev.of_node))) {
init_fn = of_id->data;
ret = init_fn(pmu);
@@ -323,8 +326,6 @@ static int cpu_pmu_device_probe(struct platform_device *pdev)
goto out_free;
}
- cpu_pmu = pmu;
- cpu_pmu->plat_device = pdev;
cpu_pmu_init(cpu_pmu);
ret = armpmu_register(cpu_pmu, PERF_TYPE_RAW);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2 1/7] ARM: perf_event: Support percpu irqs for the CPU PMU
From: Stephen Boyd @ 2014-01-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389808535-23852-1-git-send-email-sboyd@codeaurora.org>
Some CPU PMUs are wired up with one PPI for all the CPUs instead
of with a different SPI for each CPU. Add support for these
devices.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/kernel/perf_event.c | 14 ++++--
arch/arm/kernel/perf_event_cpu.c | 97 ++++++++++++++++++++++++++++------------
2 files changed, 80 insertions(+), 31 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 789d846a9184..e76750980b38 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -16,6 +16,8 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/uaccess.h>
+#include <linux/irq.h>
+#include <linux/irqdesc.h>
#include <asm/irq_regs.h>
#include <asm/pmu.h>
@@ -295,9 +297,15 @@ validate_group(struct perf_event *event)
static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
- struct arm_pmu *armpmu = (struct arm_pmu *) dev;
- struct platform_device *plat_device = armpmu->plat_device;
- struct arm_pmu_platdata *plat = dev_get_platdata(&plat_device->dev);
+ struct arm_pmu *armpmu;
+ struct platform_device *plat_device;
+ struct arm_pmu_platdata *plat;
+
+ if (irq_is_percpu(irq))
+ dev = *(struct arm_pmu_cpu **)dev;
+ armpmu = dev;
+ plat_device = armpmu->plat_device;
+ plat = dev_get_platdata(&plat_device->dev);
if (plat && plat->handle_irq)
return plat->handle_irq(irq, dev, armpmu->handle_irq);
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 20d553c9f5e2..6efd8aab15df 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -25,6 +25,8 @@
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/irq.h>
+#include <linux/irqdesc.h>
#include <asm/cputype.h>
#include <asm/irq_regs.h>
@@ -33,6 +35,7 @@
/* Set at runtime when we know what CPU type we are. */
static struct arm_pmu *cpu_pmu;
+static DEFINE_PER_CPU(struct arm_pmu *, percpu_pmu);
static DEFINE_PER_CPU(struct perf_event * [ARMPMU_MAX_HWEVENTS], hw_events);
static DEFINE_PER_CPU(unsigned long [BITS_TO_LONGS(ARMPMU_MAX_HWEVENTS)], used_mask);
static DEFINE_PER_CPU(struct pmu_hw_events, cpu_hw_events);
@@ -71,6 +74,26 @@ static struct pmu_hw_events *cpu_pmu_get_cpu_events(void)
return this_cpu_ptr(&cpu_hw_events);
}
+static void cpu_pmu_enable_percpu_irq(void *data)
+{
+ struct arm_pmu *cpu_pmu = data;
+ struct platform_device *pmu_device = cpu_pmu->plat_device;
+ int irq = platform_get_irq(pmu_device, 0);
+
+ enable_percpu_irq(irq, IRQ_TYPE_NONE);
+ cpumask_set_cpu(smp_processor_id(), &cpu_pmu->active_irqs);
+}
+
+static void cpu_pmu_disable_percpu_irq(void *data)
+{
+ struct arm_pmu *cpu_pmu = data;
+ struct platform_device *pmu_device = cpu_pmu->plat_device;
+ int irq = platform_get_irq(pmu_device, 0);
+
+ cpumask_clear_cpu(smp_processor_id(), &cpu_pmu->active_irqs);
+ disable_percpu_irq(irq);
+}
+
static void cpu_pmu_free_irq(struct arm_pmu *cpu_pmu)
{
int i, irq, irqs;
@@ -78,12 +101,18 @@ static void cpu_pmu_free_irq(struct arm_pmu *cpu_pmu)
irqs = min(pmu_device->num_resources, num_possible_cpus());
- for (i = 0; i < irqs; ++i) {
- if (!cpumask_test_and_clear_cpu(i, &cpu_pmu->active_irqs))
- continue;
- irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
- free_irq(irq, cpu_pmu);
+ irq = platform_get_irq(pmu_device, 0);
+ if (irq >= 0 && irq_is_percpu(irq)) {
+ on_each_cpu(cpu_pmu_disable_percpu_irq, cpu_pmu, 1);
+ free_percpu_irq(irq, &percpu_pmu);
+ } else {
+ for (i = 0; i < irqs; ++i) {
+ if (!cpumask_test_and_clear_cpu(i, &cpu_pmu->active_irqs))
+ continue;
+ irq = platform_get_irq(pmu_device, i);
+ if (irq >= 0)
+ free_irq(irq, cpu_pmu);
+ }
}
}
@@ -101,33 +130,44 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
return -ENODEV;
}
- for (i = 0; i < irqs; ++i) {
- err = 0;
- irq = platform_get_irq(pmu_device, i);
- if (irq < 0)
- continue;
-
- /*
- * If we have a single PMU interrupt that we can't shift,
- * assume that we're running on a uniprocessor machine and
- * continue. Otherwise, continue without this interrupt.
- */
- if (irq_set_affinity(irq, cpumask_of(i)) && irqs > 1) {
- pr_warning("unable to set irq affinity (irq=%d, cpu=%u)\n",
- irq, i);
- continue;
- }
-
- err = request_irq(irq, handler,
- IRQF_NOBALANCING | IRQF_NO_THREAD, "arm-pmu",
- cpu_pmu);
+ irq = platform_get_irq(pmu_device, 0);
+ if (irq >= 0 && irq_is_percpu(irq)) {
+ err = request_percpu_irq(irq, handler, "arm-pmu", &percpu_pmu);
if (err) {
pr_err("unable to request IRQ%d for ARM PMU counters\n",
irq);
return err;
}
-
- cpumask_set_cpu(i, &cpu_pmu->active_irqs);
+ on_each_cpu(cpu_pmu_enable_percpu_irq, cpu_pmu, 1);
+ } else {
+ for (i = 0; i < irqs; ++i) {
+ err = 0;
+ irq = platform_get_irq(pmu_device, i);
+ if (irq < 0)
+ continue;
+
+ /*
+ * If we have a single PMU interrupt that we can't shift,
+ * assume that we're running on a uniprocessor machine and
+ * continue. Otherwise, continue without this interrupt.
+ */
+ if (irq_set_affinity(irq, cpumask_of(i)) && irqs > 1) {
+ pr_warning("unable to set irq affinity (irq=%d, cpu=%u)\n",
+ irq, i);
+ continue;
+ }
+
+ err = request_irq(irq, handler,
+ IRQF_NOBALANCING | IRQF_NO_THREAD, "arm-pmu",
+ cpu_pmu);
+ if (err) {
+ pr_err("unable to request IRQ%d for ARM PMU counters\n",
+ irq);
+ return err;
+ }
+
+ cpumask_set_cpu(i, &cpu_pmu->active_irqs);
+ }
}
return 0;
@@ -141,6 +181,7 @@ static void cpu_pmu_init(struct arm_pmu *cpu_pmu)
events->events = per_cpu(hw_events, cpu);
events->used_mask = per_cpu(used_mask, cpu);
raw_spin_lock_init(&events->pmu_lock);
+ per_cpu(percpu_pmu, cpu) = cpu_pmu;
}
cpu_pmu->get_hw_events = cpu_pmu_get_cpu_events;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2 0/7] Support Krait CPU PMUs
From: Stephen Boyd @ 2014-01-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for the Krait CPU PMUs. I split the main patch
up into two parts: first the basic support that gets us just the architected
events and second the full support patch that tackles the PMRESR interface.
Please note, this patchset relies on the per-cpu irq patch from Vinayak Kale,
7f4a8e7b1943 (genirq: Add an accessor for IRQ_PER_CPU flag, 2013-12-04),
that's sitting in linux-next. Patches are based on commit 21dea6695134
(ARM: msm_defconfig: Enable restart driver, 2013-12-20) in linux-next.
Changes since v1:
* Dropped sparse warning patch
* Reworked percpu irq support patch to hide double pointers in dispatch func
* Expanded on comments explaining Krait raw event syntax
* Expanded on DT binding
* Added qcom,no-pc-write property instead of using cpuid scheme
Stephen Boyd (7):
ARM: perf_event: Support percpu irqs for the CPU PMU
ARM: perf_event: Assign pdev pointer earlier for CPU PMUs
ARM: perf_event: Add basic support for Krait CPU PMUs
ARM: perf_event: Add hook for event index clearing
ARM: perf_event: Fully support Krait CPU PMU events
devicetree: bindings: Document Krait performance monitor units (PMU)
ARM: dts: msm: Add krait-pmu to platforms with Krait CPUs
Documentation/devicetree/bindings/arm/pmu.txt | 9 +-
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 6 +
arch/arm/boot/dts/qcom-msm8974.dtsi | 5 +
arch/arm/include/asm/pmu.h | 1 +
arch/arm/kernel/perf_event.c | 16 +-
arch/arm/kernel/perf_event_cpu.c | 103 +++--
arch/arm/kernel/perf_event_v7.c | 550 ++++++++++++++++++++++++++
7 files changed, 656 insertions(+), 34 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v3 5/7] ARM: brcmstb: add misc. DT bindings for brcm, brcmstb-*
From: Florian Fainelli @ 2014-01-15 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115171155.GK25824@e106331-lin.cambridge.arm.com>
2014/1/15 Mark Rutland <mark.rutland@arm.com>:
> On Tue, Jan 14, 2014 at 11:48:51PM +0000, Marc Carino wrote:
>> Document the bindings that the Broadcom STB platform needs
>> for proper bootup.
>>
>> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
>> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> .../devicetree/bindings/arm/brcm-brcmstb.txt | 43 ++++++++++++++++++++
>> 1 files changed, 43 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
>> new file mode 100644
>> index 0000000..5f1aba7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
>> @@ -0,0 +1,43 @@
>> +Broadcom STB platforms Device Tree Bindings
>> +-------------------------------------------
>> +Boards with Broadcom Brahma15 ARM-based BCM7xxx SoC shall have the following
>> +properties.
>> +
>> +Required root node properties:
>> +
>> + - compatible = "brcm,brcmstb-<chip_id>";
>
> I'd prefer it if variants were listed explicitly (as it makes it far
> easier to grep for). Something like:
>
> - compatible: should contain one of:
> * "brcm,brcmsrb-7445"
> * "brcm,brcmsrb-7446"
For consistency with other Broadcom SoCs in mainline, as well as
making it easier to grep for products, I would be inclined to use:
compatible = "brcm,bcm7445", with the fallback compatible string "brcm,brcmstb".
--
Florian
^ permalink raw reply
* [3.8.y.z extended stable] Patch "clk: clk-divider: fix divisor > 255 bug" has been added to staging queue
From: Kamal Mostafa @ 2014-01-15 17:45 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I have just added a patch titled
clk: clk-divider: fix divisor > 255 bug
to the linux-3.8.y-queue branch of the 3.8.y.z extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.8.y-queue
This patch is scheduled to be released in version 3.8.13.16.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.8.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
------
>From 3af84c1bd5418bf66ab5879718b66806d0fe8e41 Mon Sep 17 00:00:00 2001
From: James Hogan <james.hogan@imgtec.com>
Date: Mon, 16 Dec 2013 10:41:38 +0000
Subject: clk: clk-divider: fix divisor > 255 bug
commit 778037e1ccb75609846deca9e419449c1dc137fa upstream.
Commit 6d9252bd9a4bb (clk: Add support for power of two type dividers)
merged in v3.6 added the _get_val function to convert a divisor value to
a register field value depending on the flags. However it used the type
u8 for the div field, causing divisors larger than 255 to be masked
and the resultant clock rate to be too high.
E.g. in my case an 11bit divider was supposed to divide 24.576 MHz down
to 32.768KHz. The divisor was correctly calculated as 750 (0x2ee). This
was masked to 238 (0xee) resulting in a frequency of 103.26KHz.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
---
drivers/clk/clk-divider.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index a9204c6..f253ce1 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -87,7 +87,7 @@ static unsigned int _get_table_val(const struct clk_div_table *table,
return 0;
}
-static unsigned int _get_val(struct clk_divider *divider, u8 div)
+static unsigned int _get_val(struct clk_divider *divider, unsigned int div)
{
if (divider->flags & CLK_DIVIDER_ONE_BASED)
return div;
--
1.8.3.2
^ permalink raw reply related
* [PATCH] ARM: Kirkwood: Add DT description of QNAP 419
From: Andrew Lunn @ 2014-01-15 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401151736.46280.arnd@arndb.de>
> > But i'm also a little bit concerned by the "unique number" and this
> > ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this
> > path supposed to be stable? This unique number is not stable. An
> > unwitting change to the DT could cause its value to change. Do we need
> > to make it stable?
> >
>
> One possibility would be to create an artificial bus in DT for all
> gpio-keys devices, use #address-cells=<1> and #size-cells=<0>
> for it, and give each device a unique reg property. Not sure if that
> would be considered an elegant solution though.
Hi Arnd
Can i imply from your answer that you think
/dev/input/by-path/platform-gpio_keys.3-event
should be stable?
A quick look at udev rules seems to suggestion this is an issue for
input/gpio-keys and maybe audio and video if there is a top level DT
property collecting the different sub devices together for ASOC and
V4L.
Thanks
Andrew
^ permalink raw reply
* [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Mark Rutland @ 2014-01-15 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389743333-16741-8-git-send-email-marc.ceeeee@gmail.com>
On Tue, Jan 14, 2014 at 11:48:53PM +0000, Marc Carino wrote:
> Add a sample DTS which will allow bootup of a board populated
> with the BCM7445 chip.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/boot/dts/brcmstb-7445.dts | 104 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 104 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/brcmstb-7445.dts
>
> diff --git a/arch/arm/boot/dts/brcmstb-7445.dts b/arch/arm/boot/dts/brcmstb-7445.dts
> new file mode 100644
> index 0000000..cbe73b4
> --- /dev/null
> +++ b/arch/arm/boot/dts/brcmstb-7445.dts
> @@ -0,0 +1,104 @@
> +/dts-v1/;
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
I see that there are some Xen patches floating around for the B15, so
presumably you have LPAE (and therefore can have physical addresses
wider than 32-bits).
Are all peripherals and memory in the bottom 4GB of the physical address
space? If not, I'd recommend you bump #address-cells (and #size-cells)
to <2> now, or you'll need to rewrite half the DT to add currently
missing peripherals...
Also, unless you're writing an address or mask it's usually nicer to
have the value in decimal rather than hex. Please could you get rid of
the 0x prefix on the #address-cells, #size-cells, #clock-cells values?
It's a minor issue, but it's nicer for humans to read...
> + model = "Broadcom STB (7445)";
> + compatible = "brcm,brcmstb-7445";
> + interrupt-parent = <&gic>;
> +
> + chosen {};
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x40000000 0x40000000 0x40000000 0x80000000 0x40000000>;
> + };
As a general note, where you have list properties, please bracket
elements individually (here and elsewhere) so it's possible to read,
e.g:
reg = <0x00000000 0x40000000>,
<0x40000000 0x40000000>,
<0x80000000 0x40000000>;
In this case, the memory is contiguous, so you can describe it with one
reg entry:
reg = <0x0 0xc0000000>;
> +
> + cpupll: cpupll at 0 {
> + #clock-cells = <0x0>;
> + compatible = "fixed-clock";
> + clock-frequency = <1500000000>;
> + };
The unit-address (the "@0") should go, as this doesn't have a reg entry.
same for the cpu-clk-div at 0 node below:
> +
> + cpuclk: cpu-clk-div at 0 {
> + #clock-cells = <0x0>;
> + compatible = "brcm,brcmstb-cpu-clk-div";
> + reg = <0xf03e257c 0x4>;
> + clocks = <&cpupll>;
> + div-table = <0x0 0x1 0x11 0x2 0x12 0x4 0x13 0x8 0x14 0x10>;
> + };
The unit-address here should be f03e257c (or 0,f03e257c if you move to
#address-cells = <2>).
Is this binding documented anywhere? It doesn't seem to be added in this
series, and grep on mainline gave me nothing...
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + compatible = "brcm,brahma15";
I think this string should change, as mentioned in my cpu binding
patch comments.
> + operating-points = <0x16e360 0x0
> + 0x0b71b0 0x0
> + 0x05b8d8 0x0
> + 0x02dc6c 0x0
> + 0x016e36 0x0>;
These might be easier to read in decimal...
> + clocks = <&cpuclk>;
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <1500000000>;
> + };
> +
> + cpu at 1 {
> + compatible = "brcm,brahma15";
> + device_type = "cpu";
> + reg = <1>;
> + clock-frequency = <1500000000>;
> + };
> +
> + cpu at 2 {
> + compatible = "brcm,brahma15";
> + device_type = "cpu";
> + reg = <2>;
> + clock-frequency = <1500000000>;
> + };
> +
> + cpu at 3 {
> + compatible = "brcm,brahma15";
> + device_type = "cpu";
> + reg = <3>;
> + clock-frequency = <1500000000>;
> + };
> + };
> +
> + gic: interrupt-controller at ffd00000 {
> + compatible = "brcm,brahma15-gic", "arm,cortex-a15-gic";
> + reg = <0xffd01000 0x1000
> + 0xffd02000 0x2000>;
I see you have Xen patches, and therefore presumably have a GIC with
virtualization features. Could you add the missing reg entries for the
virtual control and virtual cpu interface registers please?
Cheers,
Mark.
^ permalink raw reply
* [PATCH V2 0/6] Enable X-Gene platform reboot driver.
From: Feng Kan @ 2014-01-15 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114160755.GC4307@srcf.ucam.org>
On Tue, Jan 14, 2014 at 8:07 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Jan 07, 2014 at 02:50:35PM -0800, Feng Kan wrote:
>> Enable X-Gene platform driver for the X-Gene platform. Remove the
>> use of the mask attribute from the reboot dts node. Add support
>> for using the ACPI and DTS resource for the reboot driver.
>
> Why can't you just use the standard ACPI reboot register values in the
> FADT?
>
FKAN: I am removing the acpi patch in the next round. Mainly, I don't see a
way for the arm64 kernel to use those values. EFI in x86 have some runtime
services that can be triggered to call reset_system, but that code is not
available yet in arm64.
> --
> Matthew Garrett | mjg59 at srcf.ucam.org
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Nicolas Ferre @ 2014-01-15 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D3C166.5050908@overkiz.com>
On 13/01/2014 11:35, boris brezillon :
> On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
>> Hello Nicolas, Jean-Christophe,
>>
>> As I was trying to enable the touchscreen on the at91sam9261ek with
>> device-tree support, I ran into an issue. The touchscreen driver needs
>> to know the state of the pendown gpio and also needs it as an
>> interrupt source.
>>
>> The problem is that when a gpio is used as an interrupt, it's
>> requested by the pinctrl driver during the xlate stage, marking it
>> unavaliable for the other driver.
>> It looks like the at91 pinctrl driver is the only one to use
>> gpio_request() in the xlate stage. Maybe we should remove this:
>
> You should only request it as a GPIO and then use gpio_to_irq to get the
> related IRQ.
> Because what is done here, is to solve the case where only the irq
> is request, and in this specific case we need to request the pin as a
> GPIO.
Yes, this is what we do.
It seems simple and obvious to me, but some may say that "you shall not
do that, it is horrible!". Well... I always tend to choose a solution
that works. It is one of my weaknesses, I admit ;-)
Linus W. any advice on this, before we hit again one of those infinite
threads that leads no progress at all?
>> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
>> index a7549c4..cf91a35 100644
>> --- a/drivers/pinctrl/pinctrl-at91.c
>> +++ b/drivers/pinctrl/pinctrl-at91.c
>> @@ -1463,14 +1463,6 @@ static int at91_gpio_irq_domain_xlate(struct
>> irq_domain *d,
>> *out_hwirq = intspec[0];
>> *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
>>
>> - ret = gpio_request(pin, ctrlr->full_name);
>> - if (ret)
>> - return ret;
>> -
>> - ret = gpio_direction_input(pin);
>> - if (ret)
>> - return ret;
>> -
>> return 0;
>> }
>>
>> Jean-Jacques
>
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCHv9][ 2/2] ARM: dts: mbimxsd35: Add sound support.
From: Denis Carikli @ 2014-01-15 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389806606-21521-1-git-send-email-denis@eukrea.com>
Cc: Eric B?nard <eric@eukrea.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v8->v9:
- Better Cc list.
ChangeLog v7->v8:
- Ajusted to match the driver changes.
---
.../boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts b/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts
index 23f6fe1..3e207df 100644
--- a/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts
+++ b/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts
@@ -46,6 +46,14 @@
linux,default-trigger = "heartbeat";
};
};
+
+ sound {
+ compatible = "eukrea,asoc-tlv320";
+ eukrea,model = "imx35-eukrea-tlv320aic23";
+ ssi-controller = <&ssi1>;
+ fsl,mux-int-port = <1>;
+ fsl,mux-ext-port = <4>;
+ };
};
&audmux {
@@ -118,6 +126,7 @@
};
&ssi1 {
+ codec-handle = <&tlv320aic23>;
fsl,mode = "i2s-slave";
status = "okay";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 6/7] ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
From: Mark Rutland @ 2014-01-15 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389743333-16741-7-git-send-email-marc.ceeeee@gmail.com>
On Tue, Jan 14, 2014 at 11:48:52PM +0000, Marc Carino wrote:
> Document the Broadcom Brahma B15 GIC implementation as compatible
> with the ARM GIC standard.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> index 3dfb0c0..b7d7970 100644
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -15,6 +15,7 @@ Main node required properties:
> "arm,cortex-a9-gic"
> "arm,cortex-a7-gic"
> "arm,arm11mp-gic"
> + "brcm,brahma15-gic"
Similarly to the cpu binding patch, I think this should be
"brcm,brahma-b15-gic".
It doesn't have to be done here, but it might make sense to add
"arm,gic-v2" for arbitrary GICv2 implementations to use as a fallback
compatible string.
Cheers,
Mark.
^ permalink raw reply
* [PATCH v3 3/7] ARM: do CPU-specific init for Broadcom Brahma15 cores
From: Will Deacon @ 2014-01-15 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389743333-16741-4-git-send-email-marc.ceeeee@gmail.com>
On Tue, Jan 14, 2014 at 11:48:49PM +0000, Marc Carino wrote:
> Perform any CPU-specific initialization required on the
> Broadcom Brahma-15 core.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/mm/proc-v7.S | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index bd17819..98ea423 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -193,6 +193,7 @@ __v7_cr7mp_setup:
> b 1f
> __v7_ca7mp_setup:
> __v7_ca15mp_setup:
> +__v7_b15mp_setup:
> mov r10, #0
> 1:
> #ifdef CONFIG_SMP
> @@ -494,6 +495,16 @@ __v7_ca15mp_proc_info:
> .size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
>
> /*
> + * Broadcom Corporation Brahma-B15 processor.
> + */
> + .type __v7_b15mp_proc_info, #object
> +__v7_b15mp_proc_info:
> + .long 0x420f00f0
> + .long 0xff0ffff0
> + __v7_proc __v7_b15mp_setup, hwcaps = HWCAP_IDIV
You only need to specify HWCAP_IDIV if you screwed up your idregs (namely
CPUID_EXT_ISAR0). Do you actually need this for your core?
Will
^ permalink raw reply
* [PATCH 3/3] Binding: atmel-wm8904: add option to choose clock
From: Nicolas Ferre @ 2014-01-15 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389669956-2304-4-git-send-email-voice.shen@atmel.com>
On 14/01/2014 04:25, Bo Shen :
> Add the option to choose clock output on which pin connect to SSC.
> Default is on TK pin to SSC, add clk_from_rk_pin option, the clock
Please do not use "_" in DT properties. It is a common pattern to use
"-" instead.
> is on RK pin to SSC.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
>
> Documentation/devicetree/bindings/sound/atmel-wm8904.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> index 8bbe50c..68a5c1a 100644
> --- a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> +++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> @@ -33,6 +33,8 @@ Required properties:
>
> Optional properties:
> - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
> + - clk_from_rk_pin: according to hardware design, clk privide on rk pin
typo + more description is needed:
Please tell that it is a boolean property, that by default it is using
the TK pin (like in the commit message in fact).
Bye,
> + to ssc device
>
> Example:
> sound {
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 3/7] iommu/omap: Convert to devicetree
From: Florian Vaussard @ 2014-01-15 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140102010150.GA9933@earth.universe>
Hi
On 01/02/2014 02:01 AM, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Jan 02, 2014 at 01:13:42AM +0100, Laurent Pinchart wrote:
>>> + .of_match_table = omap_iommu_of_match,
>>
>> If CONFIG_OF isn't defined (pretty unlikely I agree, but a possibility you
>> seem to be prepared for nonetheless given the above #if), this will fail to
>> compile.
>
> FYI: This is avoided in other drivers by using
> of_match_ptr(omap_iommu_of_match), which is replaced with NULL by
> the preprocessor if CONFIG_OF is not defined.
>
Thank you for the hint.
Florian
^ permalink raw reply
* [PATCH 2/3] ASoC: atmel_wm8904: make it available to choose clock
From: Nicolas Ferre @ 2014-01-15 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389669956-2304-3-git-send-email-voice.shen@atmel.com>
On 14/01/2014 04:25, Bo Shen :
> Make it available to choose the clock from TK pin or RK pin. This
> is hardware design decided.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
>
> sound/soc/atmel/atmel_wm8904.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/sound/soc/atmel/atmel_wm8904.c b/sound/soc/atmel/atmel_wm8904.c
> index b4e3690..b85088d 100644
> --- a/sound/soc/atmel/atmel_wm8904.c
> +++ b/sound/soc/atmel/atmel_wm8904.c
> @@ -108,6 +108,7 @@ static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
> struct device_node *codec_np, *cpu_np;
> struct snd_soc_card *card = &atmel_asoc_wm8904_card;
> struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
> + struct atmel_ssc_info *ssc_info;
> int ret;
>
> if (!np) {
> @@ -115,6 +116,15 @@ static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
> return -EINVAL;
> }
>
> + ssc_info = devm_kzalloc(&pdev->dev, sizeof(*ssc_info), GFP_KERNEL);
Isn't an atmel_ssc_info structure table already instantiated in
sound/soc/atmel/atmel_ssc_dai.c ...
I see, you copy the information contained in this field in the proper
ssc_info of the DAI in the previous patch... Well, isn't it a better way
to pass parameters to the DAI than this one?
> + if (!ssc_info)
> + return -ENOMEM;
> +
> + ssc_info->clk_from_rk_pin =
> + of_property_read_bool(np, "clk_from_rk_pin");
> +
> + card->drvdata = (void *)ssc_info;
> +
> ret = snd_soc_of_parse_card_name(card, "atmel,model");
> if (ret) {
> dev_err(&pdev->dev, "failed to parse card name\n");
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v5 1/3] ARM: Introduce atomic MMIO modify
From: Jason Cooper @ 2014-01-15 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140113140215.GZ15937@n2100.arm.linux.org.uk>
Hey Russell,
On Mon, Jan 13, 2014 at 02:02:15PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 13, 2014 at 01:58:58PM +0000, Catalin Marinas wrote:
> > On Sun, Jan 12, 2014 at 02:52:07PM +0000, Ezequiel Garcia wrote:
> > > Catalin, Will: Can you ack as well, so Russell can take this?
> >
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> >
> > (with the condition that Will promises to sort out the generic relaxed
> > IO accessors and move this to generic code ;))
>
> I think that's an impossibility, as there's no such thing as a "generic
> relaxed IO accessor" and agreement on what that should be is very hard
> to come by.
This has been Acked by myself and Catalin. Do think it will make it in
to v3.14?
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7930/1
thx,
Jason.
^ permalink raw reply
* [PATCH v3 5/7] ARM: brcmstb: add misc. DT bindings for brcm, brcmstb-*
From: Arnd Bergmann @ 2014-01-15 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115171155.GK25824@e106331-lin.cambridge.arm.com>
On Wednesday 15 January 2014 17:11:55 Mark Rutland wrote:
> > +
> > +Further, a node with the following compatible string shall be defined:
> > +
> > + - compatible: "brcm,brcmstb-gen-ctrl-v1"
>
> It's probably better to say a brcmstb-gen-ctrl node (described below)
> should be present, or you'll have two places to update the compatible
> strings for each new variant...
See my other reply on this node. The previous patch version had a different
approach to these registers, and I suggested doing yet another one and
using syscon.
Arnd
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Tony Lindgren @ 2014-01-15 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115035011.4167.96678@quantum>
* Mike Turquette <mturquette@linaro.org> [140114 19:52]:
> >
> > These 40 patches apply very cleanly on top of clk-next with 2
> > exceptions:
> >
> > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
> > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
> > on 3.13-rc1).
> >
> > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
> > resolved correctly but would like verification.
> >
> > I'd prefer to simply merge these patches into clk-next, which is the
> > most straightforward route. Any ideas on how to handle the missing
> > AM35xx dtsi data? It can always go as a separate fix after this stuff
> > gets merged which, ironically, is how that file was created in the first
> > place.
You could do something like this to take advantage of fast forward and
not have to do a merge back from mainline:
$ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi
$ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc
$ git am am3517-clk-patch
$ git checkout clk-next
$ git merge clk-next-omap # this fast forwards clk-next to the desired -rc
Regards,
Tony
^ permalink raw reply
* [PATCH 1/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds
From: Florian Vaussard @ 2014-01-15 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52B8C8C1.8080101@ti.com>
Hi Suman,
So back to this...
On 12/24/2013 12:35 AM, Anna, Suman wrote:
> Hi Florian,
>
[...]
>>
>> If omap_iommu_probe() fails, the init will have called bus_set_iommu()
>> anyways. Thus, when a driver request the iommu by calling
>> iommu_domain_alloc(), it will succeed (but iommu_attach_device() will
>> fail if I remember).
>
> Yeah, thats the behavior I expected anyway.
>
>> Leaving a driver with a dangling reference to
>> a phantom iommu is not good IMHO. It will lead to strange behaviours
>> one day or another.
>>
>> As for the multiple iommu case, as I do not think it is currently
>> possible, as bus_type (in this case &platform_bus_type) has only
>> one struct iommu_ops. bus_set_iommu() will return EBUSY on the
>> second call. Am I missing something?
>
> What I meant was the problem you cited will still exist, say if ISP MMU
> probe failed, but the IVA MMU probe succeeded. The bus_set_iommu() can
> only be called once anyway, so moving it from init to probe would not
> help much.
>
Ok I see your point. Similar IPs share the same ops, but with different
omap_iommu_arch_data, even if currently we only have one registered
IOMMU for OMAP3.
So I will drop this patch.
Regards,
Florian
^ permalink raw reply
* [PATCH v3 5/7] ARM: brcmstb: add misc. DT bindings for brcm,brcmstb-*
From: Mark Rutland @ 2014-01-15 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389743333-16741-6-git-send-email-marc.ceeeee@gmail.com>
On Tue, Jan 14, 2014 at 11:48:51PM +0000, Marc Carino wrote:
> Document the bindings that the Broadcom STB platform needs
> for proper bootup.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../devicetree/bindings/arm/brcm-brcmstb.txt | 43 ++++++++++++++++++++
> 1 files changed, 43 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
> new file mode 100644
> index 0000000..5f1aba7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
> @@ -0,0 +1,43 @@
> +Broadcom STB platforms Device Tree Bindings
> +-------------------------------------------
> +Boards with Broadcom Brahma15 ARM-based BCM7xxx SoC shall have the following
> +properties.
> +
> +Required root node properties:
> +
> + - compatible = "brcm,brcmstb-<chip_id>";
I'd prefer it if variants were listed explicitly (as it makes it far
easier to grep for). Something like:
- compatible: should contain one of:
* "brcm,brcmsrb-7445"
* "brcm,brcmsrb-7446"
> +
> +Further, a node with the following compatible string shall be defined:
> +
> + - compatible: "brcm,brcmstb-gen-ctrl-v1"
It's probably better to say a brcmstb-gen-ctrl node (described below)
should be present, or you'll have two places to update the compatible
strings for each new variant...
> +
> +brcmstb-gen-ctrl
> +----------------
> +This node describes the registers needed for reset and CPU power control.
> +
> + - compatible: "brcm,brcmstb-gen-ctrl-v1"
> + - properties:
This looks odd, compatible is itself a property.
> + o reg = <rst-src-en-reg-base len
> + sw-mstr-rst-reg-base len
> + cpu-rst-cfg-reg-base len
> + cpu-pwr-zone-ctrl-reg-base len
> + stb-boot-hi-addr0-reg len>;
This would be nicer as something like follows, but with less
abberviation (unless these names are from a datasheet for the hardware).
- reg: a list of base-address size pairs:
* The first entry should cover the sw-mstr-rst registers
* The second entry should cover the cpu-rst-cfg registers
* The third entry should cover the cpu-pwr-zone registers
* The fourth entry should cover the stb-boot-hi-addr0 registers
It may make sense to use reg-names, future revisions might change
things.
> +
> +example:
> +/ {
> + model = "Broadcom STB";
> + compatible = "brcm,brcmstb-7445";
> +
> + /* snip */
> +
> + gen-ctrl {
> + compatible = "brcm,brcmstb-gen-ctrl-v1";
> + reg = <0xf0404304 0x4
> + 0xf0404308 0x4
> + 0xf03e2578 0x4
> + 0xf03e2488 0x10
> + 0xf0452000 0x20>;
Nit: please bracket each entry individually:
reg = <0xf0404304 0x4>,
<0xf0404308 0x4>,
<0xf03e2578 0x4>,
<0xf03e2488 0x10>,
<0xf0452000 0x20>;
Also, these look to be single registers in a larger register bank. Is
there any reason you can't describe the bank(s) they are in? That'll
give you more flexibility in the driver...
Thanks,
Mark
^ permalink raw reply
* [PATCH v4 4/6] spmi: pmic_arb: add support for interrupt handling
From: Josh Cartwright @ 2014-01-15 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114234402.GD23276@sonymobile.com>
On Tue, Jan 14, 2014 at 03:44:03PM -0800, Courtney Cavin wrote:
> On Tue, Jan 14, 2014 at 07:41:38PM +0100, Josh Cartwright wrote:
> > The Qualcomm PMIC Arbiter, in addition to being a basic SPMI controller,
> > also implements interrupt handling for slave devices. Note, this is
> > outside the scope of SPMI, as SPMI leaves interrupt handling completely
> > unspecified.
> >
> > Extend the driver to provide a irq_chip implementation and chained irq
> > handling which allows for these interrupts to be used.
> >
> > Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> > ---
> > drivers/spmi/spmi-pmic-arb.c | 393 ++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 391 insertions(+), 2 deletions(-)
[..]
> > +struct spmi_pmic_arb_qpnpint_type {
> > + u8 type; /* 1 -> edge */
> > + u8 polarity_high;
> > + u8 polarity_low;
> > +} __packed;
> > +
>
> While the rest of this driver uses 'pmic' or 'spmi_pmic', this patch
> adds 'qpnpint'. Can we please just leave the software fabricated name
> 'qpnp' out of any changes, as it isn't in any hardware spec? Perhaps
> 'pmic_int' or something along those lines?
QPNP is not a software-created concept. It is a hardware concept, where
it places requirements on the layout of a peripherals' register space,
and how interrupts are expected to behave, among other things.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ 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