* [PATCH] spi: davinci: Allow device tree devices to use DMA
From: David Lechner @ 2016-11-19 4:41 UTC (permalink / raw)
To: linux-arm-kernel
This makes SPI devices specified in a device tree use DMA when the master
controller has DMA configured.
Since device tree is supposed to only describe the hardware, adding a
configuration option to device tree to enable DMA per-device would not be
acceptable. So, this is the best we can do for now to get SPI devices
working with DMA when using device tree.
Unfortunately, this excludes the possibility of using one SPI device with
DMA and one without on the same master.
I have tested this on LEGO MINDSTORMS EV3 using the NOR flash. Reading the
flash memory would fail with -EIO when DMA is not enabled for the device.
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/spi/spi-davinci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index d36c11b..c6cf73a 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -388,6 +388,7 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
static int davinci_spi_of_setup(struct spi_device *spi)
{
struct davinci_spi_config *spicfg = spi->controller_data;
+ struct davinci_spi *dspi = spi_master_get_devdata(spi->master);
struct device_node *np = spi->dev.of_node;
u32 prop;
@@ -400,6 +401,9 @@ static int davinci_spi_of_setup(struct spi_device *spi)
if (!of_property_read_u32(np, "ti,spi-wdelay", &prop))
spicfg->wdelay = (u8)prop;
spi->controller_data = spicfg;
+ /* Use DMA for device if master supports it */
+ if (dspi->dma_rx)
+ spicfg->io_type = SPI_IO_TYPE_DMA;
}
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eduardo Valentin @ 2016-11-19 4:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7957B3CC-0E18-4B27-82EB-EF88B7695E28@martin.sperl.org>
Hello Martin,
Thanks for your patience to take the time to explain to me how the
firmware/linux split is done in your platform. Still, one thing is not
clear to me.
On Fri, Nov 18, 2016 at 09:32:47AM +0100, kernel at martin.sperl.org wrote:
>
> The way that firmware works on the RPI is quite different from most others I guess.
> in principle you got 2 different CPUs on the bcm2835:
> * ARM, which runs the linux instance
> * VideoCore 4, which runs the firmware (loading from SD initially) and
> then booting the ARM.
>
> So this Firmware on VC4 is the one that I am talking about.
> Without the working firmware linux can not boot on arm.
Given that "without the working firmware linux can not boot on arm",
(...)
> As far as I understand the conversion is continuous (as soon as the HW is
> configured). This case is there primarily to handle the situation where
> we initialize the HW ourselves (see line 226 and below), and we immediately
and around line 226 we have the comment:
+ /*
+ * right now the FW does set up the HW-block, so we are not
+ * touching the configuration registers.
+ * But if the HW is not enabled, then set it up
+ * using "sane" values used by the firmware right now.
+ */
> want to read the ADC value before the first conversion is finished.
>
then, does the firmware initializes the device or not?
What are the cases you would load this driver but still get an
uninitialized device? That looks like some bug workaround hidden
somewhere. Do system integrators/engineers need to be aware of this w/a?
Would the driver work right aways when the subsystem is loaded during
boot? How about module insertion?
Who has the ownership of this device?
> The above mentioned ?configuration if not running? reflect the values that
> the FW is currently setting. We should not change those values as long as the
> Firmware is also reading the temperature on its own.
hmm.. that looks like racy to me. Again, How do you synchronize accesses to
this device? What if you configure the device and right after the
firmware updates the configs? How do you make sure the configs you are
writing here are the same used by the firmware? What if the firmware
version changes? What versions of the firmware does this driver support?
Would it make sense to simply always initialize the device? Do you have
a way to tell the firmware that it should not use the device?
Or, if you want to keep the device driver simply being a dummy reader,
would it make sense to simply avoid writing configurations to the
device, and simply retry to check if the firmware gets the device
initialized?
>
> >
> >> So do you need another version of the patchset that uses that new API?
> >
> > I think the API usage is change that can be done together with
> > clarification for the above questions too: on hardware state,
> > firmware loading, maybe a master driver dependency, and the ADC
> > conversion sequence, which are not well clear to me on this driver. As long as
> > this is clarified and documented in the code (can be simple comments so
> > it is clear to whoever reads in the future), then I would be OK with
> > this driver.
>
> So how do you want this to get ?documented? in the driver?
> The setup and Firmware is a generic feature of the SOC, so if we would put
> some clarifications in this driver, then we would need to put it in every
> bcm283X driver (which seems unreasonable).
>
I think a simple comment explaining the firmware dependency and the
expected pre-conditions to get this driver working in a sane state would
do it.
A better device initialization would also be appreciated. Based on my
limited understanding of this platform, and your explanations, this
device seams to have a serious race condition with firmware while
accessing this device.
> Thanks,
> Martin
^ permalink raw reply
* [kvm-unit-tests PATCH v9 3/3] arm: pmu: Add CPI checking
From: Wei Huang @ 2016-11-19 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479528942-21866-1-git-send-email-wei@redhat.com>
From: Christopher Covington <cov@codeaurora.org>
Calculate the numbers of cycles per instruction (CPI) implied by ARM
PMU cycle counter values. The code includes a strict checking facility
intended for the -icount option in TCG mode in the configuration file.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Wei Huang <wei@redhat.com>
---
arm/pmu.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
arm/unittests.cfg | 14 +++++++
2 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/arm/pmu.c b/arm/pmu.c
index fa87de4..b36c4fb 100644
--- a/arm/pmu.c
+++ b/arm/pmu.c
@@ -104,6 +104,25 @@ static inline uint32_t id_dfr0_read(void)
asm volatile("mrc p15, 0, %0, c0, c1, 2" : "=r" (val));
return val;
}
+
+/*
+ * Extra instructions inserted by the compiler would be difficult to compensate
+ * for, so hand assemble everything between, and including, the PMCR accesses
+ * to start and stop counting.
+ */
+static inline void loop(int i, uint32_t pmcr)
+{
+ asm volatile(
+ " mcr p15, 0, %[pmcr], c9, c12, 0\n"
+ " isb\n"
+ "1: subs %[i], %[i], #1\n"
+ " bgt 1b\n"
+ " mcr p15, 0, %[z], c9, c12, 0\n"
+ " isb\n"
+ : [i] "+r" (i)
+ : [pmcr] "r" (pmcr), [z] "r" (0)
+ : "cc");
+}
#elif defined(__aarch64__)
static inline uint32_t pmcr_read(void)
{
@@ -150,6 +169,25 @@ static inline uint32_t id_dfr0_read(void)
asm volatile("mrs %0, id_dfr0_el1" : "=r" (id));
return id;
}
+
+/*
+ * Extra instructions inserted by the compiler would be difficult to compensate
+ * for, so hand assemble everything between, and including, the PMCR accesses
+ * to start and stop counting.
+ */
+static inline void loop(int i, uint32_t pmcr)
+{
+ asm volatile(
+ " msr pmcr_el0, %[pmcr]\n"
+ " isb\n"
+ "1: subs %[i], %[i], #1\n"
+ " b.gt 1b\n"
+ " msr pmcr_el0, xzr\n"
+ " isb\n"
+ : [i] "+r" (i)
+ : [pmcr] "r" (pmcr)
+ : "cc");
+}
#endif
/*
@@ -204,6 +242,71 @@ static bool check_cycles_increase(void)
return success;
}
+/*
+ * Execute a known number of guest instructions. Only odd instruction counts
+ * greater than or equal to 3 are supported by the in-line assembly code. The
+ * control register (PMCR_EL0) is initialized with the provided value (allowing
+ * for example for the cycle counter or event counters to be reset). At the end
+ * of the exact instruction loop, zero is written to PMCR_EL0 to disable
+ * counting, allowing the cycle counter or event counters to be read at the
+ * leisure of the calling code.
+ */
+static void measure_instrs(int num, uint32_t pmcr)
+{
+ int i = (num - 1) / 2;
+
+ assert(num >= 3 && ((num - 1) % 2 == 0));
+ loop(i, pmcr);
+}
+
+/*
+ * Measure cycle counts for various known instruction counts. Ensure that the
+ * cycle counter progresses (similar to check_cycles_increase() but with more
+ * instructions and using reset and stop controls). If supplied a positive,
+ * nonzero CPI parameter, also strictly check that every measurement matches
+ * it. Strict CPI checking is used to test -icount mode.
+ */
+static bool check_cpi(int cpi)
+{
+ uint32_t pmcr = pmcr_read() | PMU_PMCR_LC | PMU_PMCR_C | PMU_PMCR_E;
+
+ if (cpi > 0)
+ printf("Checking for CPI=%d.\n", cpi);
+ printf("instrs : cycles0 cycles1 ...\n");
+
+ for (unsigned int i = 3; i < 300; i += 32) {
+ uint64_t avg, sum = 0;
+
+ printf("%d :", i);
+ for (int j = 0; j < NR_SAMPLES; j++) {
+ uint64_t cycles;
+
+ pmccntr_write(0);
+ measure_instrs(i, pmcr);
+ cycles = pmccntr_read();
+ printf(" %"PRId64"", cycles);
+
+ /*
+ * The cycles taken by the loop above should fit in
+ * 32 bits easily. We check the upper 32 bits of the
+ * cycle counter to make sure there is no supprise.
+ */
+ if (!cycles || (cpi > 0 && cycles != i * cpi) ||
+ (cycles & 0xffffffff00000000)) {
+ printf("\n");
+ return false;
+ }
+
+ sum += cycles;
+ }
+ avg = sum / NR_SAMPLES;
+ printf(" sum=%"PRId64" avg=%"PRId64" avg_ipc=%"PRId64" "
+ "avg_cpi=%"PRId64"\n", sum, avg, i / avg, avg / i);
+ }
+
+ return true;
+}
+
void pmu_init(void)
{
uint32_t dfr0;
@@ -218,13 +321,19 @@ void pmu_init(void)
pmccfiltr_write(0); /* count cycles in EL0, EL1, but not EL2 */
}
-int main(void)
+int main(int argc, char *argv[])
{
+ int cpi = 0;
+
+ if (argc >= 1)
+ cpi = atol(argv[0]);
+
report_prefix_push("pmu");
pmu_init();
report("Control register", check_pmcr());
report("Monotonically increasing cycle count", check_cycles_increase());
+ report("Cycle/instruction ratio", check_cpi(cpi));
return report_summary();
}
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index 7645180..2050dc8 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -59,3 +59,17 @@ groups = selftest
[pmu]
file = pmu.flat
groups = pmu
+
+# Test PMU support (TCG) with -icount IPC=1
+[pmu-tcg-icount-1]
+file = pmu.flat
+extra_params = -icount 0 -append '1'
+groups = pmu
+accel = tcg
+
+# Test PMU support (TCG) with -icount IPC=256
+[pmu-tcg-icount-256]
+file = pmu.flat
+extra_params = -icount 8 -append '256'
+groups = pmu
+accel = tcg
--
1.8.3.1
^ permalink raw reply related
* [kvm-unit-tests PATCH v9 2/3] arm: pmu: Check cycle count increases
From: Wei Huang @ 2016-11-19 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479528942-21866-1-git-send-email-wei@redhat.com>
From: Christopher Covington <cov@codeaurora.org>
Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
even for the smallest delta of two subsequent reads.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Wei Huang <wei@redhat.com>
---
arm/pmu.c | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 156 insertions(+)
diff --git a/arm/pmu.c b/arm/pmu.c
index 9d9c53b..fa87de4 100644
--- a/arm/pmu.c
+++ b/arm/pmu.c
@@ -15,6 +15,9 @@
#include "libcflat.h"
#include "asm/barrier.h"
+#define PMU_PMCR_E (1 << 0)
+#define PMU_PMCR_C (1 << 2)
+#define PMU_PMCR_LC (1 << 6)
#define PMU_PMCR_N_SHIFT 11
#define PMU_PMCR_N_MASK 0x1f
#define PMU_PMCR_ID_SHIFT 16
@@ -22,6 +25,14 @@
#define PMU_PMCR_IMP_SHIFT 24
#define PMU_PMCR_IMP_MASK 0xff
+#define ID_DFR0_PERFMON_SHIFT 24
+#define ID_DFR0_PERFMON_MASK 0xf
+
+#define PMU_CYCLE_IDX 31
+
+#define NR_SAMPLES 10
+
+static unsigned int pmu_version;
#if defined(__arm__)
static inline uint32_t pmcr_read(void)
{
@@ -30,6 +41,69 @@ static inline uint32_t pmcr_read(void)
asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
return ret;
}
+
+static inline void pmcr_write(uint32_t value)
+{
+ asm volatile("mcr p15, 0, %0, c9, c12, 0" : : "r" (value));
+ isb();
+}
+
+static inline void pmselr_write(uint32_t value)
+{
+ asm volatile("mcr p15, 0, %0, c9, c12, 5" : : "r" (value));
+ isb();
+}
+
+static inline void pmxevtyper_write(uint32_t value)
+{
+ asm volatile("mcr p15, 0, %0, c9, c13, 1" : : "r" (value));
+}
+
+static inline uint64_t pmccntr_read(void)
+{
+ uint32_t lo, hi = 0;
+
+ if (pmu_version == 0x3)
+ asm volatile("mrrc p15, 0, %0, %1, c9" : "=r" (lo), "=r" (hi));
+ else
+ asm volatile("mrc p15, 0, %0, c9, c13, 0" : "=r" (lo));
+
+ return ((uint64_t)hi << 32) | lo;
+}
+
+static inline void pmccntr_write(uint64_t value)
+{
+ uint32_t lo, hi;
+
+ lo = value & 0xffffffff;
+ hi = (value >> 32) & 0xffffffff;
+
+ if (pmu_version == 0x3)
+ asm volatile("mcrr p15, 0, %0, %1, c9" : : "r" (lo), "r" (hi));
+ else
+ asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" (lo));
+}
+
+static inline void pmcntenset_write(uint32_t value)
+{
+ asm volatile("mcr p15, 0, %0, c9, c12, 1" : : "r" (value));
+}
+
+/* PMCCFILTR is an obsolete name for PMXEVTYPER31 in ARMv7 */
+static inline void pmccfiltr_write(uint32_t value)
+{
+ pmselr_write(PMU_CYCLE_IDX);
+ pmxevtyper_write(value);
+ isb();
+}
+
+static inline uint32_t id_dfr0_read(void)
+{
+ uint32_t val;
+
+ asm volatile("mrc p15, 0, %0, c0, c1, 2" : "=r" (val));
+ return val;
+}
#elif defined(__aarch64__)
static inline uint32_t pmcr_read(void)
{
@@ -38,6 +112,44 @@ static inline uint32_t pmcr_read(void)
asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
return ret;
}
+
+static inline void pmcr_write(uint32_t value)
+{
+ asm volatile("msr pmcr_el0, %0" : : "r" (value));
+ isb();
+}
+
+static inline uint64_t pmccntr_read(void)
+{
+ uint64_t cycles;
+
+ asm volatile("mrs %0, pmccntr_el0" : "=r" (cycles));
+ return cycles;
+}
+
+static inline void pmccntr_write(uint64_t value)
+{
+ asm volatile("msr pmccntr_el0, %0" : : "r" (value));
+}
+
+static inline void pmcntenset_write(uint32_t value)
+{
+ asm volatile("msr pmcntenset_el0, %0" : : "r" (value));
+}
+
+static inline void pmccfiltr_write(uint32_t value)
+{
+ asm volatile("msr pmccfiltr_el0, %0" : : "r" (value));
+ isb();
+}
+
+static inline uint32_t id_dfr0_read(void)
+{
+ uint32_t id;
+
+ asm volatile("mrs %0, id_dfr0_el1" : "=r" (id));
+ return id;
+}
#endif
/*
@@ -64,11 +176,55 @@ static bool check_pmcr(void)
return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
}
+/*
+ * Ensure that the cycle counter progresses between back-to-back reads.
+ */
+static bool check_cycles_increase(void)
+{
+ bool success = true;
+
+ pmccntr_write(0);
+ pmcr_write(pmcr_read() | PMU_PMCR_LC | PMU_PMCR_C | PMU_PMCR_E);
+
+ for (int i = 0; i < NR_SAMPLES; i++) {
+ uint64_t a, b;
+
+ a = pmccntr_read();
+ b = pmccntr_read();
+
+ if (a >= b) {
+ printf("Read %"PRId64" then %"PRId64".\n", a, b);
+ success = false;
+ break;
+ }
+ }
+
+ pmcr_write(pmcr_read() & ~PMU_PMCR_E);
+
+ return success;
+}
+
+void pmu_init(void)
+{
+ uint32_t dfr0;
+
+ /* probe pmu version */
+ dfr0 = id_dfr0_read();
+ pmu_version = (dfr0 >> ID_DFR0_PERFMON_SHIFT) & ID_DFR0_PERFMON_MASK;
+ printf("PMU version: %d\n", pmu_version);
+
+ /* init for PMU event access, right now only care about cycle count */
+ pmcntenset_write(1 << PMU_CYCLE_IDX);
+ pmccfiltr_write(0); /* count cycles in EL0, EL1, but not EL2 */
+}
+
int main(void)
{
report_prefix_push("pmu");
+ pmu_init();
report("Control register", check_pmcr());
+ report("Monotonically increasing cycle count", check_cycles_increase());
return report_summary();
}
--
1.8.3.1
^ permalink raw reply related
* [kvm-unit-tests PATCH v9 1/3] arm: Add PMU test
From: Wei Huang @ 2016-11-19 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479528942-21866-1-git-send-email-wei@redhat.com>
From: Christopher Covington <cov@codeaurora.org>
Beginning with a simple sanity check of the control register, add
a unit test for the ARM Performance Monitors Unit (PMU).
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Wei Huang <wei@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
---
arm/Makefile.common | 3 ++-
arm/pmu.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++
arm/unittests.cfg | 5 ++++
3 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 arm/pmu.c
diff --git a/arm/Makefile.common b/arm/Makefile.common
index ccb554d..f98f422 100644
--- a/arm/Makefile.common
+++ b/arm/Makefile.common
@@ -11,7 +11,8 @@ endif
tests-common = \
$(TEST_DIR)/selftest.flat \
- $(TEST_DIR)/spinlock-test.flat
+ $(TEST_DIR)/spinlock-test.flat \
+ $(TEST_DIR)/pmu.flat
all: test_cases
diff --git a/arm/pmu.c b/arm/pmu.c
new file mode 100644
index 0000000..9d9c53b
--- /dev/null
+++ b/arm/pmu.c
@@ -0,0 +1,74 @@
+/*
+ * Test the ARM Performance Monitors Unit (PMU).
+ *
+ * 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 Lesser General Public License version 2.1 and
+ * only version 2.1 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 Lesser General Public License
+ * for more details.
+ */
+#include "libcflat.h"
+#include "asm/barrier.h"
+
+#define PMU_PMCR_N_SHIFT 11
+#define PMU_PMCR_N_MASK 0x1f
+#define PMU_PMCR_ID_SHIFT 16
+#define PMU_PMCR_ID_MASK 0xff
+#define PMU_PMCR_IMP_SHIFT 24
+#define PMU_PMCR_IMP_MASK 0xff
+
+#if defined(__arm__)
+static inline uint32_t pmcr_read(void)
+{
+ uint32_t ret;
+
+ asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
+ return ret;
+}
+#elif defined(__aarch64__)
+static inline uint32_t pmcr_read(void)
+{
+ uint32_t ret;
+
+ asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
+ return ret;
+}
+#endif
+
+/*
+ * As a simple sanity check on the PMCR_EL0, ensure the implementer field isn't
+ * null. Also print out a couple other interesting fields for diagnostic
+ * purposes. For example, as of fall 2016, QEMU TCG mode doesn't implement
+ * event counters and therefore reports zero event counters, but hopefully
+ * support for at least the instructions event will be added in the future and
+ * the reported number of event counters will become nonzero.
+ */
+static bool check_pmcr(void)
+{
+ uint32_t pmcr;
+
+ pmcr = pmcr_read();
+
+ printf("PMU implementer: %c\n",
+ (pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK);
+ printf("Identification code: 0x%x\n",
+ (pmcr >> PMU_PMCR_ID_SHIFT) & PMU_PMCR_ID_MASK);
+ printf("Event counters: %d\n",
+ (pmcr >> PMU_PMCR_N_SHIFT) & PMU_PMCR_N_MASK);
+
+ return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
+}
+
+int main(void)
+{
+ report_prefix_push("pmu");
+
+ report("Control register", check_pmcr());
+
+ return report_summary();
+}
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index 3f6fa45..7645180 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -54,3 +54,8 @@ file = selftest.flat
smp = $MAX_SMP
extra_params = -append 'smp'
groups = selftest
+
+# Test PMU support
+[pmu]
+file = pmu.flat
+groups = pmu
--
1.8.3.1
^ permalink raw reply related
* [kvm-unit-tests PATCH v9 0/3] ARM PMU tests
From: Wei Huang @ 2016-11-19 4:15 UTC (permalink / raw)
To: linux-arm-kernel
Changes from v8:
* Probe PMU version based on ID_DFR0
* pmccntr_read() now returns 64bit and can handle both 32bit and 64bit
PMCCNTR based on PMU version.
* Add pmccntr_write() support
* Use a common printf format PRId64 to support 64bit variable smoothly in
test functions
* Add barriers to several PMU write functions
* Verfied on different execution modes
Note:
1) Current KVM code has bugs in handling PMCCFILTR write. A fix (see
below) is required for this unit testing code to work correctly under
KVM mode.
https://lists.cs.columbia.edu/pipermail/kvmarm/2016-November/022134.html.
Thanks,
-Wei
Wei Huang (3):
arm: Add PMU test
arm: pmu: Check cycle count increases
arm: pmu: Add CPI checking
arm/Makefile.common | 3 +-
arm/pmu.c | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++
arm/unittests.cfg | 19 +++
3 files changed, 360 insertions(+), 1 deletion(-)
create mode 100644 arm/pmu.c
--
1.8.3.1
^ permalink raw reply
* [GIT PULL 9/10] arm64: tegra: Device tree changes for v4.10-rc1
From: Olof Johansson @ 2016-11-19 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-9-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:18PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-arm64-dt
>
> for you to fetch changes up to cc13b4fa4ac780cec6c21b64a39ab2950e95e8f6:
>
> arm64: tegra: Add NVIDIA P2771 board support (2016-11-18 14:35:53 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> arm64: tegra: Device tree changes for v4.10-rc1
>
> This adds initial support for Tegra186, the P3310 processor module as
> well as the P2771 development board. Not much is functional, but there
> is enough to boot to an initial ramdisk with debug serial output.
>
> ----------------------------------------------------------------
> Dan Carpenter (1):
> mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
>
> Joseph Lo (6):
> soc/tegra: Add Tegra186 support
> dt-bindings: mailbox: Add Tegra HSP binding
> dt-bindings: firmware: Add bindings for Tegra BPMP
> arm64: tegra: Add Tegra186 support
> arm64: tegra: Add NVIDIA P3310 processor module support
> arm64: tegra: Add NVIDIA P2771 board support
>
> Stephen Warren (2):
> dt-bindings: Add power domains to Tegra BPMP firmware
> dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
>
> Thierry Reding (12):
> Merge branch 'for-4.10/soc' into for-4.10/mailbox
> mailbox: Add Tegra HSP driver
> Merge branch 'for-4.10/mailbox' into for-4.10/firmware
> firmware: tegra: Add IVC library
> firmware: tegra: Add BPMP support
> Merge branch 'for-4.10/firmware' into for-4.10/arm64/dt
> arm64: tegra: Add CPU nodes for Tegra186
> arm64: tegra: Add serial ports on Tegra186
> arm64: tegra: Add I2C controllers on Tegra186
> arm64: tegra: Add SDHCI controllers on Tegra186
> arm64: tegra: Add GPIO controllers on Tegra186
> arm64: tegra: Enable PSCI on P3310
The drivers->dt dependency here is annoying. Any chance you can respin without
it?
We've been encouraging people to consider using numerical clock/gpio/reset
numbers on initial submission to avoid these dependencies on dt-bindings
includes, and then follow up with a move to the symbolic names between -rc1 and
-rc2. Mind doing the same here?
Thanks!
-Olof
^ permalink raw reply
* [GIT PULL 8/10] ARM: tegra: Default configuration updates for v4.10-rc1
From: Olof Johansson @ 2016-11-19 2:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-8-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:17PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-arm-defconfig
>
> for you to fetch changes up to dafba3f6fb8614a114f939e5626447d71db864af:
>
> ARM: tegra: Enable GMI driver in default configuration (2016-11-08 11:49:41 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> ARM: tegra: Default configuration updates for v4.10-rc1
>
> Enable audio support for various Toradex devices as well as the GMI.
>
> ----------------------------------------------------------------
> Marcel Ziswiler (1):
> ARM: tegra: Enable SGTL5000 audio
>
> Thierry Reding (2):
> ARM: tegra: Update default configuration for v4.9-rc1
> ARM: tegra: Enable GMI driver in default configuration
>
> arch/arm/configs/tegra_defconfig | 27 +++++++++++++--------------
> 1 file changed, 13 insertions(+), 14 deletions(-)
> --
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 7/10] ARM: tegra: Device tree changes for v4.10-rc1
From: Olof Johansson @ 2016-11-19 2:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-7-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:16PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-arm-dt
>
> for you to fetch changes up to 5e8a724d143308f3195375951b0c8f01b2ca59fe:
>
> ARM: tegra: apalis-tk1: Drop leading 0 from unit-address (2016-11-08 11:14:02 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v4.10-rc1
>
> Adds support for GMI on Tegra20 and Tegra30 and enables the GPU on Nyan
> Chromebooks. It also enables sound support on various Toradex devices.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 6/10] dt-bindings: Cleanups and additions for v4.10-rc1
From: Olof Johansson @ 2016-11-19 2:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-6-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:15PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-dt-bindings
>
> for you to fetch changes up to 2e002bdedcdcbd6a708f5698a09eb32df568efb8:
>
> dt-bindings: Add documentation for Tegra186 Denver (2016-11-17 18:09:05 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> dt-bindings: Cleanups and additions for v4.10-rc1
>
> Contains two small patches, one fixing a typo and the other adding the
> compatible string for the Denver CPUs found on the new Tegra186 SoCs.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 5/10] soc: tegra: Core SoC changes for v4.10-rc1
From: Olof Johansson @ 2016-11-19 2:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-5-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:14PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-soc
>
> for you to fetch changes up to 4522112069a976908e32e5dd3231c9272d19794a:
>
> soc/tegra: pmc: Use consistent naming for PM domains (2016-11-15 15:51:56 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> soc: tegra: Core SoC changes for v4.10-rc1
>
> This contains mostly cleanup and new feature work on the power
> management controller as well as the addition of a Kconfig symbol for
> the new Tegra186 (Parker) SoC generation.
>
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 4/10] bus: Add Tegra GMI support
From: Olof Johansson @ 2016-11-19 2:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-4-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:13PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-bus
>
> for you to fetch changes up to 40eb47767852a9122ef99a48f8d208ec6327e07f:
>
> bus: Add support for Tegra Generic Memory Interface (2016-11-15 17:27:53 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> bus: Add Tegra GMI support
>
> This provides a driver to enable the use of the Generic Memory Interface
> found on Tegra SoCs that can host various types of high-speed devices.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 4/10] bus: Add Tegra GMI support
From: Olof Johansson @ 2016-11-19 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-4-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:13PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-bus
>
> for you to fetch changes up to 40eb47767852a9122ef99a48f8d208ec6327e07f:
>
> bus: Add support for Tegra Generic Memory Interface (2016-11-15 17:27:53 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> bus: Add Tegra GMI support
>
> This provides a driver to enable the use of the Generic Memory Interface
> found on Tegra SoCs that can host various types of high-speed devices.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 3/10] reset: Add Tegra BPMP reset driver
From: Olof Johansson @ 2016-11-19 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-3-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:12PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-reset
>
> for you to fetch changes up to dc606c5205536a828c17bd96f06559dafaf75fb7:
>
> reset: Add Tegra BPMP reset driver (2016-11-18 14:34:56 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> reset: Add Tegra BPMP reset driver
>
> This contains a patch which implements a reset driver using the services
> provided by the BPMP firmware (via the MRQ_RESET request).
>
> ----------------------------------------------------------------
> Dan Carpenter (1):
> mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
>
> Joseph Lo (3):
> soc/tegra: Add Tegra186 support
> dt-bindings: mailbox: Add Tegra HSP binding
> dt-bindings: firmware: Add bindings for Tegra BPMP
>
> Stephen Warren (2):
> dt-bindings: Add power domains to Tegra BPMP firmware
> dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
>
> Thierry Reding (7):
> Merge branch 'for-4.10/soc' into for-4.10/mailbox
> mailbox: Add Tegra HSP driver
> Merge branch 'for-4.10/mailbox' into for-4.10/firmware
> firmware: tegra: Add IVC library
> firmware: tegra: Add BPMP support
> Merge branch 'for-4.10/firmware' into for-4.10/reset
> reset: Add Tegra BPMP reset driver
Same comments apply here, since this branch only adds one more driver.
Merged into next/drivers with the other branches so far.
-Olof
^ permalink raw reply
* [GIT PULL 2/10] firmware: Add Tegra IVC and BPMP support
From: Olof Johansson @ 2016-11-19 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-2-thierry.reding@gmail.com>
On Fri, Nov 18, 2016 at 05:17:11PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-firmware
>
> for you to fetch changes up to b704ed8095ee91af5f3f7343bb3be23aae1cb26d:
>
> dt-bindings: firmware: Allow child nodes inside the Tegra BPMP (2016-11-18 14:33:44 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> firmware: Add Tegra IVC and BPMP support
>
> IVC is an inter-processor communication protocol that uses shared memory
> to exchange data between processors. The BPMP driver makes use of this
> to communicate with the Boot and Power Management Processor (BPMP) and
> uses an additional hardware synchronization primitive from the HSP block
> to signal availability of new data (doorbell).
>
> Firmware running on the BPMP implements a number of services such as the
> control of clocks and resets within the system, or the ability to ungate
> or gate power partitions.
>
> ----------------------------------------------------------------
> Dan Carpenter (1):
> mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
>
> Joseph Lo (3):
> soc/tegra: Add Tegra186 support
> dt-bindings: mailbox: Add Tegra HSP binding
> dt-bindings: firmware: Add bindings for Tegra BPMP
>
> Stephen Warren (2):
> dt-bindings: Add power domains to Tegra BPMP firmware
> dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
>
> Thierry Reding (5):
> Merge branch 'for-4.10/soc' into for-4.10/mailbox
> mailbox: Add Tegra HSP driver
> Merge branch 'for-4.10/mailbox' into for-4.10/firmware
> firmware: tegra: Add IVC library
> firmware: tegra: Add BPMP support
Hi,
Again the format of the pull request here is a little confusing, since it's
a cumulative shotlog and diffstat, while you already sent the bulk of this
as part of the driver branch (1/10). It'd have been better to use that branch
as the base when you generate the pull request since that's the delta we see
when we merge it in.
Also, I can't seem to find the key you use to sign these tags with, it isn't
uploaded on pgp.mit.edu. Can you remedy that please, and get it signed as
needed?
All that being said, I've merged this into next/drivers. Thanks!
-Olof
^ permalink raw reply
* [GIT PULL 1/10] mailbox: Add Tegra HSP driver
From: Olof Johansson @ 2016-11-19 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-1-thierry.reding@gmail.com>
Hi,
On Fri, Nov 18, 2016 at 05:17:10PM +0100, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-mailbox
>
> for you to fetch changes up to 68050eb6c611527232fe5574c7306e97e47499ef:
>
> mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells() (2016-11-18 14:32:13 +0100)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> mailbox: Add Tegra HSP driver
>
> This contains the device tree bindings and a driver for the Tegra HSP, a
> hardware block that provides hardware synchronization primitives and is
> the foundation for inter-processor communication between CPU and BPMP.
>
> ----------------------------------------------------------------
> Dan Carpenter (1):
> mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
>
> Joseph Lo (2):
> soc/tegra: Add Tegra186 support
I don't think you really needed to merge this in here, since all you need it
for is to fulfill the kconfig dependency and enable the driver, right? That'd
happen when the driver and soc branch is merged at the toplevel anyway.
Anyhow, no damage done, I've merged this in. I would say that it'd be a little
more logical to send the SoC branch before the driver branch given this
dependency though.
-Olof
^ permalink raw reply
* [GIT PULL 2/2] ARM: dts: exynos: Topic dts for v4.10
From: Olof Johansson @ 2016-11-19 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479473075-9787-2-git-send-email-krzk@kernel.org>
On Fri, Nov 18, 2016 at 02:44:35PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
>
> Topic branch with a GIC interrupt fixes and cleanup (human-friendly symbols).
>
> Possible rather trivial conflicts:
>
> diff --cc arch/arm/boot/dts/exynos4x12.dtsi
> index 0074f566cd3b,505f047e81c6..85a7122658f1
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@@ -147,9 -147,10 +147,10 @@@
> };
>
> fimc_is: fimc-is at 12000000 {
> - compatible = "samsung,exynos4212-fimc-is", "simple-bus";
> + compatible = "samsung,exynos4212-fimc-is";
> reg = <0x12000000 0x260000>;
> - interrupts = <0 90 0>, <0 95 0>;
> + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
> power-domains = <&pd_isp>;
> clocks = <&clock CLK_FIMC_LITE0>,
> <&clock CLK_FIMC_LITE1>, <&clock CLK_PPMUISPX>,
>
> diff --cc arch/arm/boot/dts/exynos5410.dtsi
> index 9a91685d8890,2501249d97aa..bb90bbdbe2d9
> --- a/arch/arm/boot/dts/exynos5410.dtsi
> +++ b/arch/arm/boot/dts/exynos5410.dtsi
> @@@ -190,58 -181,8 +190,58 @@@
> pinctrl_3: pinctrl at 03860000 {
> compatible = "samsung,exynos5410-pinctrl";
> reg = <0x03860000 0x1000>;
> - interrupts = <0 47 0>;
> + interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
> };
> +
> + amba {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + interrupt-parent = <&gic>;
> + ranges;
>
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-gic-flags-4.10
>
> for you to fetch changes up to 04a886727ca7e841afa2fbc5d87aff81ae256dbf:
>
> ARM: dts: exynos: Use human-friendly symbols for interrupt properties in exynos5440 (2016-11-03 22:44:56 +0200)
>
> ----------------------------------------------------------------
> Topic branch with DT changes for v4.10.
>
> Fix invalid GIC interrupt flags - type IRQ_TYPE_NONE is not allowed for GIC
> interrupts. Although this was working but with error messages like:
> genirq: Setting trigger mode 0 for irq 16 failed
>
> Use level high interrupt instead of type none. The choice of level high was
> rather an arbitrary decision hoping it will work on each platform. Tests shown
> no issues so far.
Merged, thanks. FYI, you could have based this on the previous DT branch
if you wanted to not expose the conflicts, but simple ones like these
(in particular that we can resolve in our own tree) are OK to expose too.
-Olof
^ permalink raw reply
* [GIT PULL 1/2] arm64: dts: exynos: Topic dts arm64 for v4.10
From: Olof Johansson @ 2016-11-19 2:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479473075-9787-1-git-send-email-krzk@kernel.org>
On Fri, Nov 18, 2016 at 02:44:34PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> Topic branch with a GIC interrupt fix and cleanup. No conflicts expected.
> No dependencies.
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-gic-flags-4.10
>
> for you to fetch changes up to 86bb573d0b2a8e876a12d1348bd0b6e377c1043e:
>
> arm64: dts: exynos: Use human-friendly symbols for interrupt properties in exynos7 (2016-11-03 22:40:39 +0200)
>
> ----------------------------------------------------------------
> Topic branch with DT arm64 changes for v4.10.
>
> Fix invalid GIC interrupt flags - type IRQ_TYPE_NONE is not allowed for GIC
> interrupts. Although this was working but with error messages like:
> genirq: Setting trigger mode 0 for irq 16 failed
>
> Use level high interrupt instead of type none. The choice of level high was
> rather an arbitrary decision hoping it will work on each platform. Tests shown
> no issues so far.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.10 (#1)
From: Olof Johansson @ 2016-11-19 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87oa1dbwrs.fsf@free-electrons.com>
On Thu, Nov 17, 2016 at 10:51:19PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for dt64 for mvebu for v4.10.
>
> Here again, I hope being able to send a second part very soon with the
> series removing all the remaining DT warning.
>
> Gregory
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.10-1
>
> for you to fetch changes up to e735aaf8fc4ac84dbdb3642a135da8dcdb84587b:
>
> arm64: dts: marvell: Add definition for the Globalscale Marvell ESPRESSOBin Board (2016-10-17 17:19:56 +0200)
>
> ----------------------------------------------------------------
> mvebu dt64 for 4.10 (part 1)
>
> Adding the new "community" board for Armada 3700
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v4.10 (#1)
From: Olof Johansson @ 2016-11-19 1:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87poltbwt2.fsf@free-electrons.com>
Hi,
On Thu, Nov 17, 2016 at 10:50:33PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for dt for mvebu for v4.10.
>
> I hope being able to send a second part very soon with the series
> removing all the DT warning.
>
> Gregory
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.10-1
>
> for you to fetch changes up to cf20c489de6fcef88405d4febef7a078d2053b9e:
>
> ARM: dt: orion5x: convert ls-chl to FDT (2016-11-07 17:23:34 +0100)
>
> ----------------------------------------------------------------
> mvebu fixes for 4.10 (part 1)
>
> Most of the commit are pinmux and i2c fix for netgear NASes
> Fix on a wrong comment about PLL frequency
> Bigger commit: conversion of on otion5x based board to the device tree
>
> ----------------------------------------------------------------
> Ashley Hughes (1):
> ARM: dt: orion5x: convert ls-chl to FDT
This is a great conversion, but I'd like to see the code handled a
little differently.
First of all, there's no longer a need to have a config option for
MACH_LINKSTATION_LSCHL, as long as ARCH_ORION5X_DT is enabled you'll
be fine. So you can remove that Kconfig entry alltogether.
Also, there's no need to make the DT addition and the legacy platform
removal in one commit. It's common that we build up the DT support to the point
that it's at parity, and then remove the legacy board. That way we also don't
entangle DT commits with non-DT commits, which can sometimes be a bit of a pain
(in particular for those who maintain a copy of the DT subdir in another git
repo).
So, mind respinning with this fixed? Thanks!
-Olof
^ permalink raw reply
* [PATCH] arm64: dts: qcom: msm8996: Fixup smp2p node
From: Sarangdhar Joshi @ 2016-11-19 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479499609-13336-1-git-send-email-bjorn.andersson@linaro.org>
On 11/18/2016 12:06 PM, Bjorn Andersson wrote:
> The SMEM state property name changes between the integration branch and
> mainline, update to use the correct one.
>
> Fixes: 2f45d9fcd531 ("arm64: dts: msm8996: Add SMP2P and APCS nodes")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Thanks for the change and sorry for missing it earlier.
Reviewed-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: drivers for v4.10 (#1)
From: Olof Johansson @ 2016-11-19 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r369bwvn.fsf@free-electrons.com>
Hi,
On Thu, Nov 17, 2016 at 10:49:00PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for drivers for mvebu for v4.10.
>
> Gregory
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-drivers-4.10-1
>
> for you to fetch changes up to d6ea689345ecc27b636a8bb62bf07080f21f110c:
>
> ARM/orion/gpio: Replace three seq_printf() calls by seq_puts() in orion_gpio_dbg_show() (2016-10-17 17:40:24 +0200)
>
> ----------------------------------------------------------------
> mvebu drivers for 4.10 (part 1)
>
> Clean-up on thegpio driver for old SoCs(non DT)
>
> ----------------------------------------------------------------
> Markus Elfring (1):
> ARM/orion/gpio: Replace three seq_printf() calls by seq_puts() in orion_gpio_dbg_show()
This is next/soc material, not driver. Merged there. Thanks.
(Also, please be mindful of patch prefixes. This is again a nonstandard
one).
-Olof
^ permalink raw reply
* [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.10
From: Olof Johansson @ 2016-11-19 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
On Thu, Nov 17, 2016 at 03:11:45PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these second round of Renesas ARM based SoC DT updates for v4.10.
>
> This pull request is based on a merge of:
>
> * The previous round of such requests, tagged as renesas-dt-for-v4.10,
> which I have already sent a pull-request for.
> * The rzg-clock-defs tag of Geert Uytterhoeven's renesas-driver's tree.
> This is to provide dependencies for adding the r8a7743 and r8a7745 SoCs.
> * The "Second Round of Renesas ARM Based SoC Drivers Updates for v4.10",
> tagged as renesas-drivers2-for-v4.10, which I have also sent a pull
> request for. This is included to provide dependencies for adding device
> nodes for PRR, and adding the r8a7743 and r8a7745 SoCs..
Again, nack. And again, I don't understand why you create dependencies that
aren't needed. Please fix.
-Olof
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC EtherAVB Updates for v4.10
From: Olof Johansson @ 2016-11-19 1:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479390880.git.horms+renesas@verge.net.au>
On Thu, Nov 17, 2016 at 03:05:08PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC EtherAVB updates for v4.10.
>
> This pull request is based on the "Second Round of Renesas ARM64 Based SoC
> DT Updates for v4.10", tagged as arm64-dt-for-v4.10, which I have also sent
> a pull-request for.
>
> The reason for this base is to provide dependencies. For the same reason
> an ack has been provided by David Miller to facilitate a merge of the patch
> via the Renesas tree.
And now we have cascading dependencies. Can't merge this either.
Why is the DT branch and this driver branch entangled?! Again, there is
absolutely no functional dependency between them.
-Olof
^ permalink raw reply
* [GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.10
From: Olof Johansson @ 2016-11-19 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479388193.git.horms+renesas@verge.net.au>
On Thu, Nov 17, 2016 at 03:04:55PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these second round of Renesas ARM64 based SoC DT updates
> for v4.10.
>
> This pull request is based on a merge of:
>
> * The previous round of such requests, tagged as renesas-arm64-dt-for-v4.10,
> which I have already sent a pull-request for.
> * The "Second Round of Renesas ARM Based SoC Drivers Updates for v4.10",
> tagged as renesas-drivers2-for-v4.10, which I have also sent a pull
> request for. This is included to provide dependencies for adding device
> nodes for PRR.
Please avoid entangling these pull requests, since now I can't merge DT since
I'm rejecting your drivers pull request.
I also don't understand why you need a driver branch as base. The PRR
nodes are literally just a compatible field and a reg entry. It should
depend on nothing.
So, I'm a little confused here. Please disentangle this and send a separate
pull request, I'll be happy to merge that.
-Olof
^ 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