* [PATCH v6 3/5] dt-bindings: timer: add i.MX EPIT timer binding
From: Clément Péron @ 2018-06-07 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607140544.22268-1-peron.clem@gmail.com>
From: Cl?ment Peron <clement.peron@devialet.com>
Add devicetree binding document for NXP's i.MX SoC specific
EPIT timer driver.
Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
---
.../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxepit.txt b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
new file mode 100644
index 000000000000..819d6458a860
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
@@ -0,0 +1,21 @@
+Binding for the i.MX Enhanced Periodic Interrupt Timer (EPIT)
+
+The Enhanced Periodic Interrupt Timer (EPIT) is a 32-bit set-and-forget timer
+that is capable of providing precise interrupts at regular intervals with
+minimal processor intervention.
+
+Required properties:
+- compatible: should be "fsl,<chip>-epit", "fsl,imx31-epit" where <chip> is
+ imx25, imx6qdl, imx6sl, imx6sul or imx6sx.
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: Should contain EPIT controller interrupt
+- clocks : The clock provided by the SoC to drive the timer.
+
+Example for i.MX6QDL:
+ epit1: timer at 20d0000 {
+ compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
+ reg = <0x020d0000 0x4000>;
+ interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_EPIT1>;
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v6 4/5] clocksource: add driver for i.MX EPIT timer
From: Clément Péron @ 2018-06-07 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607140544.22268-1-peron.clem@gmail.com>
From: Colin Didier <colin.didier@devialet.com>
Add driver for NXP's EPIT timer used in i.MX SoC.
Signed-off-by: Colin Didier <colin.didier@devialet.com>
Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
---
drivers/clocksource/Kconfig | 11 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-imx-epit.c | 265 +++++++++++++++++++++++++++
3 files changed, 277 insertions(+)
create mode 100644 drivers/clocksource/timer-imx-epit.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 8e8a09755d10..790478afd02c 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -576,6 +576,17 @@ config H8300_TPU
This enables the clocksource for the H8300 platform with the
H8S2678 cpu.
+config CLKSRC_IMX_EPIT
+ bool "Clocksource using i.MX EPIT"
+ depends on CLKDEV_LOOKUP && (ARCH_MXC || COMPILE_TEST)
+ select CLKSRC_MMIO
+ help
+ This enables EPIT support available on some i.MX platforms.
+ Normally you don't have a reason to do so as the EPIT has
+ the same features and uses the same clocks as the GPT.
+ Anyway, on some systems the GPT may be in use for other
+ purposes.
+
config CLKSRC_IMX_GPT
bool "Clocksource using i.MX GPT" if COMPILE_TEST
depends on ARM && CLKDEV_LOOKUP
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 00caf37e52f9..d9426f69ec69 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_INTEGRATOR_AP_TIMER) += timer-integrator-ap.o
obj-$(CONFIG_CLKSRC_VERSATILE) += versatile.o
obj-$(CONFIG_CLKSRC_MIPS_GIC) += mips-gic-timer.o
obj-$(CONFIG_CLKSRC_TANGO_XTAL) += tango_xtal.o
+obj-$(CONFIG_CLKSRC_IMX_EPIT) += timer-imx-epit.o
obj-$(CONFIG_CLKSRC_IMX_GPT) += timer-imx-gpt.o
obj-$(CONFIG_CLKSRC_IMX_TPM) += timer-imx-tpm.o
obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
diff --git a/drivers/clocksource/timer-imx-epit.c b/drivers/clocksource/timer-imx-epit.c
new file mode 100644
index 000000000000..15f70e210fad
--- /dev/null
+++ b/drivers/clocksource/timer-imx-epit.c
@@ -0,0 +1,265 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * i.MX EPIT Timer
+ *
+ * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
+ * Copyright (C) 2018 Colin Didier <colin.didier@devialet.com>
+ * Copyright (C) 2018 Cl?ment P?ron <clement.peron@devialet.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/sched_clock.h>
+#include <linux/slab.h>
+
+#define EPITCR 0x00
+#define EPITSR 0x04
+#define EPITLR 0x08
+#define EPITCMPR 0x0c
+#define EPITCNR 0x10
+
+#define EPITCR_EN BIT(0)
+#define EPITCR_ENMOD BIT(1)
+#define EPITCR_OCIEN BIT(2)
+#define EPITCR_RLD BIT(3)
+#define EPITCR_PRESC(x) (((x) & 0xfff) << 4)
+#define EPITCR_SWR BIT(16)
+#define EPITCR_IOVW BIT(17)
+#define EPITCR_DBGEN BIT(18)
+#define EPITCR_WAITEN BIT(19)
+#define EPITCR_RES BIT(20)
+#define EPITCR_STOPEN BIT(21)
+#define EPITCR_OM_DISCON (0 << 22)
+#define EPITCR_OM_TOGGLE (1 << 22)
+#define EPITCR_OM_CLEAR (2 << 22)
+#define EPITCR_OM_SET (3 << 22)
+#define EPITCR_CLKSRC_OFF (0 << 24)
+#define EPITCR_CLKSRC_PERIPHERAL (1 << 24)
+#define EPITCR_CLKSRC_REF_HIGH (2 << 24)
+#define EPITCR_CLKSRC_REF_LOW (3 << 24)
+
+#define EPITSR_OCIF BIT(0)
+
+struct epit_timer {
+ void __iomem *base;
+ int irq;
+ struct clk *clk;
+ struct clock_event_device ced;
+ struct irqaction act;
+};
+
+static void __iomem *sched_clock_reg;
+
+static inline struct epit_timer *to_epit_timer(struct clock_event_device *ced)
+{
+ return container_of(ced, struct epit_timer, ced);
+}
+
+static inline void epit_irq_disable(struct epit_timer *epittm)
+{
+ u32 val;
+
+ val = readl_relaxed(epittm->base + EPITCR);
+ writel_relaxed(val & ~EPITCR_OCIEN, epittm->base + EPITCR);
+}
+
+static inline void epit_irq_enable(struct epit_timer *epittm)
+{
+ u32 val;
+
+ val = readl_relaxed(epittm->base + EPITCR);
+ writel_relaxed(val | EPITCR_OCIEN, epittm->base + EPITCR);
+}
+
+static void epit_irq_acknowledge(struct epit_timer *epittm)
+{
+ writel_relaxed(EPITSR_OCIF, epittm->base + EPITSR);
+}
+
+static u64 notrace epit_read_sched_clock(void)
+{
+ return ~readl_relaxed(sched_clock_reg);
+}
+
+static int epit_set_next_event(unsigned long cycles,
+ struct clock_event_device *ced)
+{
+ struct epit_timer *epittm = to_epit_timer(ced);
+ unsigned long tcmp;
+
+ tcmp = readl_relaxed(epittm->base + EPITCNR) - cycles;
+ writel_relaxed(tcmp, epittm->base + EPITCMPR);
+
+ return 0;
+}
+
+/* Left event sources disabled, no more interrupts appear */
+static int epit_shutdown(struct clock_event_device *ced)
+{
+ struct epit_timer *epittm = to_epit_timer(ced);
+ unsigned long flags;
+
+ /*
+ * The timer interrupt generation is disabled at least
+ * for enough time to call epit_set_next_event()
+ */
+ local_irq_save(flags);
+
+ /* Disable interrupt in EPIT module */
+ epit_irq_disable(epittm);
+
+ /* Clear pending interrupt */
+ epit_irq_acknowledge(epittm);
+
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static int epit_set_oneshot(struct clock_event_device *ced)
+{
+ struct epit_timer *epittm = to_epit_timer(ced);
+ unsigned long flags;
+
+ /*
+ * The timer interrupt generation is disabled at least
+ * for enough time to call epit_set_next_event()
+ */
+ local_irq_save(flags);
+
+ /* Disable interrupt in EPIT module */
+ epit_irq_disable(epittm);
+
+ /* Clear pending interrupt, only while switching mode */
+ if (!clockevent_state_oneshot(ced))
+ epit_irq_acknowledge(epittm);
+
+ /*
+ * Do not put overhead of interrupt enable/disable into
+ * epit_set_next_event(), the core has about 4 minutes
+ * to call epit_set_next_event() or shutdown clock after
+ * mode switching
+ */
+ epit_irq_enable(epittm);
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static irqreturn_t epit_timer_interrupt(int irq, void *dev_id)
+{
+ struct clock_event_device *ced = dev_id;
+ struct epit_timer *epittm = to_epit_timer(ced);
+
+ epit_irq_acknowledge(epittm);
+
+ ced->event_handler(ced);
+
+ return IRQ_HANDLED;
+}
+
+static int __init epit_clocksource_init(struct epit_timer *epittm)
+{
+ unsigned int c = clk_get_rate(epittm->clk);
+
+ sched_clock_reg = epittm->base + EPITCNR;
+ sched_clock_register(epit_read_sched_clock, 32, c);
+
+ return clocksource_mmio_init(epittm->base + EPITCNR, "epit", c, 200, 32,
+ clocksource_mmio_readl_down);
+}
+
+static int __init epit_clockevent_init(struct epit_timer *epittm)
+{
+ struct clock_event_device *ced = &epittm->ced;
+ struct irqaction *act = &epittm->act;
+
+ ced->name = "epit";
+ ced->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_DYNIRQ;
+ ced->set_state_shutdown = epit_shutdown;
+ ced->tick_resume = epit_shutdown;
+ ced->set_state_oneshot = epit_set_oneshot;
+ ced->set_next_event = epit_set_next_event;
+ ced->rating = 200;
+ ced->cpumask = cpumask_of(0);
+ ced->irq = epittm->irq;
+ clockevents_config_and_register(ced, clk_get_rate(epittm->clk),
+ 0xff, 0xfffffffe);
+
+ act->name = "i.MX EPIT Timer Tick",
+ act->flags = IRQF_TIMER | IRQF_IRQPOLL;
+ act->handler = epit_timer_interrupt;
+ act->dev_id = ced;
+
+ /* Make irqs happen */
+ return setup_irq(epittm->irq, act);
+}
+
+static int __init epit_timer_init(struct device_node *np)
+{
+ struct epit_timer *epittm;
+ int ret;
+
+ epittm = kzalloc(sizeof(*epittm), GFP_KERNEL);
+ if (!epittm)
+ return -ENOMEM;
+
+ epittm->base = of_iomap(np, 0);
+ if (!epittm->base) {
+ ret = -ENXIO;
+ goto out_kfree;
+ }
+
+ epittm->irq = irq_of_parse_and_map(np, 0);
+ if (!epittm->irq) {
+ ret = -EINVAL;
+ goto out_iounmap;
+ }
+
+ /* Get EPIT clock */
+ epittm->clk = of_clk_get(np, 0);
+ if (IS_ERR(epittm->clk)) {
+ pr_err("i.MX EPIT: unable to get clk\n");
+ ret = PTR_ERR(epittm->clk);
+ goto out_iounmap;
+ }
+
+ ret = clk_prepare_enable(epittm->clk);
+ if (ret) {
+ pr_err("i.MX EPIT: unable to prepare+enable clk\n");
+ goto out_iounmap;
+ }
+
+ /* Initialise to a known state (all timers off, and timing reset) */
+ writel_relaxed(0x0, epittm->base + EPITCR);
+ writel_relaxed(0xffffffff, epittm->base + EPITLR);
+ writel_relaxed(EPITCR_EN | EPITCR_CLKSRC_REF_HIGH | EPITCR_WAITEN,
+ epittm->base + EPITCR);
+
+ ret = epit_clocksource_init(epittm);
+ if (ret) {
+ pr_err("i.MX EPIT: failed to init clocksource\n");
+ goto out_clk_disable;
+ }
+
+ ret = epit_clockevent_init(epittm);
+ if (ret) {
+ pr_err("i.MX EPIT: failed to init clockevent\n");
+ goto out_clk_disable;
+ }
+
+ return 0;
+
+out_clk_disable:
+ clk_disable_unprepare(epittm->clk);
+out_iounmap:
+ iounmap(epittm->base);
+out_kfree:
+ kfree(epittm);
+
+ return ret;
+}
+TIMER_OF_DECLARE(epit_timer, "fsl,imx31-epit", epit_timer_init);
--
2.17.1
^ permalink raw reply related
* [PATCH v6 5/5] ARM: dts: imx: add missing compatible and clock properties for EPIT
From: Clément Péron @ 2018-06-07 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607140544.22268-1-peron.clem@gmail.com>
From: Colin Didier <colin.didier@devialet.com>
Add missing compatible and clock properties for EPIT node.
Signed-off-by: Colin Didier <colin.didier@devialet.com>
Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
---
arch/arm/boot/dts/imx25.dtsi | 8 ++++++--
arch/arm/boot/dts/imx6qdl.dtsi | 10 ++++++++--
arch/arm/boot/dts/imx6sl.dtsi | 10 ++++++++--
arch/arm/boot/dts/imx6sx.dtsi | 10 ++++++++--
arch/arm/boot/dts/imx6ul.dtsi | 10 ++++++++--
5 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cf70df20b19c..15fd4308dad8 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -396,15 +396,19 @@
};
epit1: timer at 53f94000 {
- compatible = "fsl,imx25-epit";
+ compatible = "fsl,imx25-epit", "fsl,imx31-epit";
reg = <0x53f94000 0x4000>;
interrupts = <28>;
+ clocks = <&clks 83>;
+ status = "disabled";
};
epit2: timer at 53f98000 {
- compatible = "fsl,imx25-epit";
+ compatible = "fsl,imx25-epit", "fsl,imx31-epit";
reg = <0x53f98000 0x4000>;
interrupts = <27>;
+ clocks = <&clks 84>;
+ status = "disabled";
};
gpio4: gpio at 53f9c000 {
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index c003e62bf290..65c4ee07454c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -843,14 +843,20 @@
};
};
- epit1: epit at 20d0000 { /* EPIT1 */
+ epit1: timer at 20d0000 {
+ compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
reg = <0x020d0000 0x4000>;
interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_EPIT1>;
+ status = "disabled";
};
- epit2: epit at 20d4000 { /* EPIT2 */
+ epit2: timer at 20d4000 {
+ compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
reg = <0x020d4000 0x4000>;
interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_EPIT2>;
+ status = "disabled";
};
src: src at 20d8000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index ab6a7e2e7e8f..d63f8ebbc8a1 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -671,14 +671,20 @@
};
};
- epit1: epit at 20d0000 {
+ epit1: timer at 20d0000 {
+ compatible = "fsl,imx6sl-epit", "fsl,imx31-epit";
reg = <0x020d0000 0x4000>;
interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SL_CLK_EPIT1>;
+ status = "disabled";
};
- epit2: epit at 20d4000 {
+ epit2: timer at 20d4000 {
+ compatible = "fsl,imx6sl-epit", "fsl,imx31-epit";
reg = <0x020d4000 0x4000>;
interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SL_CLK_EPIT2>;
+ status = "disabled";
};
src: src at 20d8000 {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 49c7205b8db8..2b30559d3270 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -736,14 +736,20 @@
};
};
- epit1: epit at 20d0000 {
+ epit1: timer at 20d0000 {
+ compatible = "fsl,imx6sx-epit", "fsl,imx31-epit";
reg = <0x020d0000 0x4000>;
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SX_CLK_EPIT1>;
+ status = "disabled";
};
- epit2: epit at 20d4000 {
+ epit2: timer at 20d4000 {
+ compatible = "fsl,imx6sx-epit", "fsl,imx31-epit";
reg = <0x020d4000 0x4000>;
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SX_CLK_EPIT2>;
+ status = "disabled";
};
src: src at 20d8000 {
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 1241972b16ba..d5f765da1ee2 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -658,14 +658,20 @@
};
};
- epit1: epit at 20d0000 {
+ epit1: timer at 20d0000 {
+ compatible = "fsl,imx6ul-epit", "fsl,imx31-epit";
reg = <0x020d0000 0x4000>;
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6UL_CLK_EPIT1>;
+ status = "disabled";
};
- epit2: epit at 20d4000 {
+ epit2: timer at 20d4000 {
+ compatible = "fsl,imx6ul-epit", "fsl,imx31-epit";
reg = <0x020d4000 0x4000>;
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6UL_CLK_EPIT2>;
+ status = "disabled";
};
src: src at 20d8000 {
--
2.17.1
^ permalink raw reply related
* [xlnx:master 1122/1659] drivers/mtd/spi-nor/spi-nor.c:3334:14: error: implicit declaration of function 'of_get_next_parent'; did you mean 'of_get_parent'?
From: kbuild test robot @ 2018-06-07 14:12 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx master
head: c2ba891326bb472da59b6a2da29aca218d337687
commit: 818f168696f561c127f161379eb5b8d1835218a2 [1122/1659] Merge tag 'v4.14' into master
config: x86_64-randconfig-i0-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 818f168696f561c127f161379eb5b8d1835218a2
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/mtd/spi-nor/spi-nor.c: In function 'spi_nor_scan':
>> drivers/mtd/spi-nor/spi-nor.c:3334:14: error: implicit declaration of function 'of_get_next_parent'; did you mean 'of_get_parent'? [-Werror=implicit-function-declaration]
np_spi = of_get_next_parent(np);
^~~~~~~~~~~~~~~~~~
of_get_parent
drivers/mtd/spi-nor/spi-nor.c:3334:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
np_spi = of_get_next_parent(np);
^
drivers/mtd/spi-nor/spi-nor.c:3080:6: warning: unused variable 'is_dual' [-Wunused-variable]
u32 is_dual;
^~~~~~~
At top level:
drivers/mtd/spi-nor/spi-nor.c:323:12: warning: 'read_ear' defined but not used [-Wunused-function]
static int read_ear(struct spi_nor *nor, struct flash_info *info)
^~~~~~~~
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:ffs
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
Cyclomatic Complexity 1 include/linux/math64.h:div_u64_rem
Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
Cyclomatic Complexity 2 include/linux/device.h:dev_name
Cyclomatic Complexity 1 include/linux/device.h:dev_of_node
Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large
Cyclomatic Complexity 3 include/linux/slab.h:kmalloc
Cyclomatic Complexity 1 include/linux/of.h:of_find_property
Cyclomatic Complexity 1 include/linux/of.h:of_property_match_string
Cyclomatic Complexity 1 include/linux/of.h:of_property_read_bool
Cyclomatic Complexity 1 include/linux/mtd/mtd.h:mtd_get_of_node
Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_get_protocol_data_nbits
Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_get_protocol_width
Cyclomatic Complexity 1 include/linux/mtd/spi-nor.h:spi_nor_get_flash_node
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:write_sr
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:write_enable
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:write_disable
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:mtd_to_spi_nor
Cyclomatic Complexity 3 drivers/mtd/spi-nor/spi-nor.c:spi_nor_convert_opcode
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_convert_3to4_read
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_convert_3to4_program
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_convert_3to4_erase
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:spi_nor_set_4byte_opcodes
Cyclomatic Complexity 6 drivers/mtd/spi-nor/spi-nor.c:set_4byte
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:spi_nor_s3an_addr_convert
Cyclomatic Complexity 4 drivers/mtd/spi-nor/spi-nor.c:spi_nor_erase_sector
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:min_lockable_sectors
Cyclomatic Complexity 3 drivers/mtd/spi-nor/spi-nor.c:get_protected_area_start
Cyclomatic Complexity 4 drivers/mtd/spi-nor/spi-nor.c:min_protected_area_including_offset
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:bp_bits_from_sr
Cyclomatic Complexity 4 drivers/mtd/spi-nor/spi-nor.c:stm_get_locked_range
Cyclomatic Complexity 7 drivers/mtd/spi-nor/spi-nor.c:stm_check_lock_status_sr
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:stm_is_locked_sr
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:stm_is_unlocked_sr
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_set_read_settings
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_set_pp_settings
Cyclomatic Complexity 5 drivers/mtd/spi-nor/spi-nor.c:spi_nor_read_sfdp
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_set_read_settings_from_bfpt
Cyclomatic Complexity 3 drivers/mtd/spi-nor/spi-nor.c:spi_nor_hwcaps2cmd
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_hwcaps_read2cmd
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_hwcaps_pp2cmd
Cyclomatic Complexity 3 drivers/mtd/spi-nor/spi-nor.c:spi_nor_select_read
Cyclomatic Complexity 3 drivers/mtd/spi-nor/spi-nor.c:spi_nor_select_pp
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:spi_nor_select_erase
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:read_cr
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:s3an_sr_ready
Cyclomatic Complexity 10 drivers/mtd/spi-nor/spi-nor.c:spi_nor_setup
Cyclomatic Complexity 4 drivers/mtd/spi-nor/spi-nor.c:s3an_nor_scan
Cyclomatic Complexity 3 drivers/mtd/spi-nor/spi-nor.c:spi_nor_lock_and_prep
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:spi_nor_unlock_and_unprep
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:spi_nor_is_locked
Cyclomatic Complexity 3 include/linux/err.h:IS_ERR_OR_NULL
Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
Cyclomatic Complexity 4 drivers/mtd/spi-nor/spi-nor.c:read_sr
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:stm_is_locked
Cyclomatic Complexity 5 drivers/mtd/spi-nor/spi-nor.c:spi_nor_sr_ready
Cyclomatic Complexity 4 drivers/mtd/spi-nor/spi-nor.c:read_fsr
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:spi_nor_fsr_ready
Cyclomatic Complexity 5 drivers/mtd/spi-nor/spi-nor.c:spi_nor_ready
Cyclomatic Complexity 6 drivers/mtd/spi-nor/spi-nor.c:spi_nor_check
Cyclomatic Complexity 66 include/linux/log2.h:__order_base_2
Cyclomatic Complexity 7 drivers/mtd/spi-nor/spi-nor.c:spi_nor_wait_till_ready_with_timeout
Cyclomatic Complexity 1 drivers/mtd/spi-nor/spi-nor.c:spi_nor_wait_till_ready
Cyclomatic Complexity 10 drivers/mtd/spi-nor/spi-nor.c:write_ear
Cyclomatic Complexity 19 drivers/mtd/spi-nor/spi-nor.c:spi_nor_write
Cyclomatic Complexity 15 drivers/mtd/spi-nor/spi-nor.c:sst_write
Cyclomatic Complexity 3 drivers/mtd/spi-nor/spi-nor.c:write_sr_cr
Cyclomatic Complexity 6 drivers/mtd/spi-nor/spi-nor.c:write_sr_modify_protection
Cyclomatic Complexity 7 drivers/mtd/spi-nor/spi-nor.c:spi_nor_unlock
Cyclomatic Complexity 4 drivers/mtd/spi-nor/spi-nor.c:spansion_quad_enable
Cyclomatic Complexity 7 drivers/mtd/spi-nor/spi-nor.c:spansion_read_cr_quad_enable
Cyclomatic Complexity 2 drivers/mtd/spi-nor/spi-nor.c:spansion_no_read_cr_quad_enable
Cyclomatic Complexity 7 drivers/mtd/spi-nor/spi-nor.c:spi_nor_lock
Cyclomatic Complexity 144 drivers/mtd/spi-nor/spi-nor.c:stm_unlock
Cyclomatic Complexity 141 drivers/mtd/spi-nor/spi-nor.c:stm_lock
Cyclomatic Complexity 18 drivers/mtd/spi-nor/spi-nor.c:spi_nor_read
Cyclomatic Complexity 5 drivers/mtd/spi-nor/spi-nor.c:erase_chip
Cyclomatic Complexity 17 drivers/mtd/spi-nor/spi-nor.c:spi_nor_erase
Cyclomatic Complexity 6 drivers/mtd/spi-nor/spi-nor.c:macronix_quad_enable
Cyclomatic Complexity 7 drivers/mtd/spi-nor/spi-nor.c:sr2_bit7_quad_enable
Cyclomatic Complexity 3 drivers/mtd/spi-nor/spi-nor.c:spi_nor_match_id
vim +3334 drivers/mtd/spi-nor/spi-nor.c
b199489d3 Huang Shijie 2014-02-24 3270
b199489d3 Huang Shijie 2014-02-24 3271 if (info->flags & SPI_NOR_NO_ERASE)
b199489d3 Huang Shijie 2014-02-24 3272 mtd->flags |= MTD_NO_ERASE;
b199489d3 Huang Shijie 2014-02-24 3273
29e641775 Naga Sureshkumar Relli 2017-03-06 3274 nor->jedec_id = info->id[0];
b199489d3 Huang Shijie 2014-02-24 3275 mtd->dev.parent = dev;
cfc5604c4 Cyrille Pitchen 2017-04-25 3276 nor->page_size = params.page_size;
b199489d3 Huang Shijie 2014-02-24 3277 mtd->writebufsize = nor->page_size;
b199489d3 Huang Shijie 2014-02-24 3278
b199489d3 Huang Shijie 2014-02-24 3279 if (np) {
b199489d3 Huang Shijie 2014-02-24 3280 /* If we were instantiated by DT, use it */
b199489d3 Huang Shijie 2014-02-24 3281 if (of_property_read_bool(np, "m25p,fast-read"))
cfc5604c4 Cyrille Pitchen 2017-04-25 3282 params.hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
b199489d3 Huang Shijie 2014-02-24 3283 else
cfc5604c4 Cyrille Pitchen 2017-04-25 3284 params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
b199489d3 Huang Shijie 2014-02-24 3285 } else {
b199489d3 Huang Shijie 2014-02-24 3286 /* If we weren't instantiated by DT, default to fast-read */
cfc5604c4 Cyrille Pitchen 2017-04-25 3287 params.hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
b199489d3 Huang Shijie 2014-02-24 3288 }
b199489d3 Huang Shijie 2014-02-24 3289
b199489d3 Huang Shijie 2014-02-24 3290 /* Some devices cannot do fast-read, no matter what DT tells us */
b199489d3 Huang Shijie 2014-02-24 3291 if (info->flags & SPI_NOR_NO_FR)
cfc5604c4 Cyrille Pitchen 2017-04-25 3292 params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
b199489d3 Huang Shijie 2014-02-24 3293
cfc5604c4 Cyrille Pitchen 2017-04-25 3294 /*
cfc5604c4 Cyrille Pitchen 2017-04-25 3295 * Configure the SPI memory:
cfc5604c4 Cyrille Pitchen 2017-04-25 3296 * - select op codes for (Fast) Read, Page Program and Sector Erase.
cfc5604c4 Cyrille Pitchen 2017-04-25 3297 * - set the number of dummy cycles (mode cycles + wait states).
cfc5604c4 Cyrille Pitchen 2017-04-25 3298 * - set the SPI protocols for register and memory accesses.
cfc5604c4 Cyrille Pitchen 2017-04-25 3299 * - set the Quad Enable bit if needed (required by SPI x-y-4 protos).
cfc5604c4 Cyrille Pitchen 2017-04-25 3300 */
cfc5604c4 Cyrille Pitchen 2017-04-25 3301 ret = spi_nor_setup(nor, info, ¶ms, hwcaps);
cfc5604c4 Cyrille Pitchen 2017-04-25 3302 if (ret)
b199489d3 Huang Shijie 2014-02-24 3303 return ret;
b199489d3 Huang Shijie 2014-02-24 3304
f384b352c Cyrille Pitchen 2017-06-26 3305 if (nor->addr_width) {
f384b352c Cyrille Pitchen 2017-06-26 3306 /* already configured from SFDP */
f384b352c Cyrille Pitchen 2017-06-26 3307 } else if (info->addr_width) {
b199489d3 Huang Shijie 2014-02-24 3308 nor->addr_width = info->addr_width;
f384b352c Cyrille Pitchen 2017-06-26 3309 } else if (mtd->size > 0x1000000) {
1e7078305 Michal Simek 2017-01-24 3310 #ifdef CONFIG_OF
1e7078305 Michal Simek 2017-01-24 3311 np_spi = of_get_next_parent(np);
1e7078305 Michal Simek 2017-01-24 3312 if (of_property_match_string(np_spi, "compatible",
1e7078305 Michal Simek 2017-01-24 3313 "xlnx,zynq-qspi-1.0") >= 0) {
1e7078305 Michal Simek 2017-01-24 3314 int status;
1e7078305 Michal Simek 2017-01-24 3315
1e7078305 Michal Simek 2017-01-24 3316 nor->addr_width = 3;
1e7078305 Michal Simek 2017-01-24 3317 set_4byte(nor, info, 0);
1e7078305 Michal Simek 2017-01-24 3318 status = read_ear(nor, info);
1e7078305 Michal Simek 2017-01-24 3319 if (status < 0)
1e7078305 Michal Simek 2017-01-24 3320 dev_warn(dev, "failed to read ear reg\n");
1e7078305 Michal Simek 2017-01-24 3321 else
1e7078305 Michal Simek 2017-01-24 3322 nor->curbank = status & EAR_SEGMENT_MASK;
1e7078305 Michal Simek 2017-01-24 3323 } else {
1e7078305 Michal Simek 2017-01-24 3324 #endif
818f16869 Michal Simek 2018-01-11 3325 /*
818f16869 Michal Simek 2018-01-11 3326 * enable 4-byte addressing
818f16869 Michal Simek 2018-01-11 3327 * if the device exceeds 16MiB
818f16869 Michal Simek 2018-01-11 3328 */
b199489d3 Huang Shijie 2014-02-24 3329 nor->addr_width = 4;
ba3ae6a1d Cyrille Pitchen 2016-10-27 3330 if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
ba3ae6a1d Cyrille Pitchen 2016-10-27 3331 info->flags & SPI_NOR_4B_OPCODES)
ba3ae6a1d Cyrille Pitchen 2016-10-27 3332 spi_nor_set_4byte_opcodes(nor, info);
818f16869 Michal Simek 2018-01-11 3333 else {
d80f6153e Naga Sureshkumar Relli 2017-04-18 @3334 np_spi = of_get_next_parent(np);
818f16869 Michal Simek 2018-01-11 3335 if (of_property_match_string(np_spi,
818f16869 Michal Simek 2018-01-11 3336 "compatible",
d80f6153e Naga Sureshkumar Relli 2017-04-18 3337 "xlnx,xps-spi-2.00.a") >= 0) {
d80f6153e Naga Sureshkumar Relli 2017-04-18 3338 nor->addr_width = 3;
d80f6153e Naga Sureshkumar Relli 2017-04-18 3339 set_4byte(nor, info, 0);
d80f6153e Naga Sureshkumar Relli 2017-04-18 3340 } else {
d928a2593 Huang Shijie 2014-11-06 3341 set_4byte(nor, info, 1);
d859d3457 Anurag Kumar Vulisha 2015-05-13 3342 if (nor->isstacked) {
d80f6153e Naga Sureshkumar Relli 2017-04-18 3343 nor->spi->master->flags |=
d80f6153e Naga Sureshkumar Relli 2017-04-18 3344 SPI_MASTER_U_PAGE;
d859d3457 Anurag Kumar Vulisha 2015-05-13 3345 set_4byte(nor, info, 1);
d80f6153e Naga Sureshkumar Relli 2017-04-18 3346 nor->spi->master->flags &=
d80f6153e Naga Sureshkumar Relli 2017-04-18 3347 ~SPI_MASTER_U_PAGE;
d80f6153e Naga Sureshkumar Relli 2017-04-18 3348 }
d80f6153e Naga Sureshkumar Relli 2017-04-18 3349 }
d859d3457 Anurag Kumar Vulisha 2015-05-13 3350 }
1e7078305 Michal Simek 2017-01-24 3351 #ifdef CONFIG_OF
1e7078305 Michal Simek 2017-01-24 3352 }
1e7078305 Michal Simek 2017-01-24 3353 #endif
b199489d3 Huang Shijie 2014-02-24 3354 } else {
b199489d3 Huang Shijie 2014-02-24 3355 nor->addr_width = 3;
b199489d3 Huang Shijie 2014-02-24 3356 }
b199489d3 Huang Shijie 2014-02-24 3357
c67cbb839 Brian Norris 2015-11-10 3358 if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
c67cbb839 Brian Norris 2015-11-10 3359 dev_err(dev, "address width is too large: %u\n",
c67cbb839 Brian Norris 2015-11-10 3360 nor->addr_width);
c67cbb839 Brian Norris 2015-11-10 3361 return -EINVAL;
c67cbb839 Brian Norris 2015-11-10 3362 }
c67cbb839 Brian Norris 2015-11-10 3363
e99ca98f1 Ricardo Ribalda Delgado 2016-12-02 3364 if (info->flags & SPI_S3AN) {
e99ca98f1 Ricardo Ribalda Delgado 2016-12-02 3365 ret = s3an_nor_scan(info, nor);
e99ca98f1 Ricardo Ribalda Delgado 2016-12-02 3366 if (ret)
e99ca98f1 Ricardo Ribalda Delgado 2016-12-02 3367 return ret;
e99ca98f1 Ricardo Ribalda Delgado 2016-12-02 3368 }
b199489d3 Huang Shijie 2014-02-24 3369
7ae20097f Naga Sureshkumar Relli 2017-01-30 3370 dev_info(dev, "%s (%lld Kbytes)\n", info->name,
b199489d3 Huang Shijie 2014-02-24 3371 (long long)mtd->size >> 10);
b199489d3 Huang Shijie 2014-02-24 3372
7ae20097f Naga Sureshkumar Relli 2017-01-30 3373 dev_dbg(dev,
7ae20097f Naga Sureshkumar Relli 2017-01-30 3374 "mtd .name = %s, .size = 0x%llx (%lldMiB), "
b199489d3 Huang Shijie 2014-02-24 3375 ".erasesize = 0x%.8x (%uKiB) .numeraseregions = %d\n",
b199489d3 Huang Shijie 2014-02-24 3376 mtd->name, (long long)mtd->size, (long long)(mtd->size >> 20),
b199489d3 Huang Shijie 2014-02-24 3377 mtd->erasesize, mtd->erasesize / 1024, mtd->numeraseregions);
b199489d3 Huang Shijie 2014-02-24 3378
b199489d3 Huang Shijie 2014-02-24 3379 if (mtd->numeraseregions)
b199489d3 Huang Shijie 2014-02-24 3380 for (i = 0; i < mtd->numeraseregions; i++)
7ae20097f Naga Sureshkumar Relli 2017-01-30 3381 dev_dbg(dev,
7ae20097f Naga Sureshkumar Relli 2017-01-30 3382 "mtd.eraseregions[%d] = { .offset = 0x%llx, "
b199489d3 Huang Shijie 2014-02-24 3383 ".erasesize = 0x%.8x (%uKiB), "
b199489d3 Huang Shijie 2014-02-24 3384 ".numblocks = %d }\n",
b199489d3 Huang Shijie 2014-02-24 3385 i, (long long)mtd->eraseregions[i].offset,
b199489d3 Huang Shijie 2014-02-24 3386 mtd->eraseregions[i].erasesize,
b199489d3 Huang Shijie 2014-02-24 3387 mtd->eraseregions[i].erasesize / 1024,
b199489d3 Huang Shijie 2014-02-24 3388 mtd->eraseregions[i].numblocks);
b199489d3 Huang Shijie 2014-02-24 3389 return 0;
b199489d3 Huang Shijie 2014-02-24 3390 }
b61834b0d Brian Norris 2014-04-08 3391 EXPORT_SYMBOL_GPL(spi_nor_scan);
b199489d3 Huang Shijie 2014-02-24 3392
:::::: The code at line 3334 was first introduced by commit
:::::: d80f6153e7c446e0c7dc8400b06d199c50bfd509 mtd: spi-nor: Disable 4-Byte addressing for axi_quad_spi
:::::: TO: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>
:::::: CC: Michal Simek <michal.simek@xilinx.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 26841 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180607/6ee1dd7c/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2] ARM: multi_v7_defconfig: Add Marvell NAND controller support
From: Gregory CLEMENT @ 2018-06-07 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528151357.29203-1-gregory.clement@bootlin.com>
Hi,
On lun., mai 28 2018, Gregory CLEMENT <gregory.clement@bootlin.com> wrote:
> Add Marvell NAND controller support used by some Marvell Armada based
> boards.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
> Changelog v1 -> v2:
>
> - Rebased on v4.17-rc1 (Dropped "ARM: multi_v7_defconfig: Update with
> current configuration")
I would like to be sure that you don't miss it. I didn't sent a PR for
it but just a patch as you asked me however I still didn't see it in
arm-soc/for-next.
Thanks,
Gregory
>
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index e6b3c96d4c09..3fcb17b38f50 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -210,6 +210,7 @@ CONFIG_MTD_NAND_DENALI_DT=y
> CONFIG_MTD_NAND_OMAP2=y
> CONFIG_MTD_NAND_OMAP_BCH=y
> CONFIG_MTD_NAND_ATMEL=y
> +CONFIG_MTD_NAND_MARVELL=y
> CONFIG_MTD_NAND_GPMI_NAND=y
> CONFIG_MTD_NAND_BRCMNAND=y
> CONFIG_MTD_NAND_VF610_NFC=y
> --
> 2.17.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* [PATCH v2] arm64: topology: Avoid checking numa mask for scheduler MC selection
From: Geert Uytterhoeven @ 2018-06-07 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606163846.495725-1-jeremy.linton@arm.com>
Hi Jeremy,
On Wed, Jun 6, 2018 at 6:38 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> The numa mask subset check can often lead to system hang or crash during
> CPU hotplug and system suspend operation if NUMA is disabled. This is
Also during boot, if CONFIG_ARM_PSCI_CHECKER=y.
> mostly observed on HMP systems where the CPU compute capacities are
> different and ends up in different scheduler domains. Since
> cpumask_of_node is returned instead core_sibling, the scheduler is
> confused with incorrect cpumasks(e.g. one CPU in two different sched
> domains at the same time) on CPU hotplug.
>
> Lets disable the NUMA siblings checks for the time being, as NUMA in
> socket machines have LLC's that will assure that the scheduler topology
> isn't "borken".
>
> The NUMA check exists to assure that if a LLC within a socket crosses
> NUMA nodes/chiplets the scheduler domains remain consistent. This code will
> likely have to be re-enabled in the near future once the NUMA mask story
> is sorted. At the moment its not necessary because the NUMA in socket
> machines LLC's are contained within the NUMA domains.
>
> Further, as a defensive mechanism during hot-plug, lets assure that the
> LLC siblings are also masked.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Thanks!
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> arch/arm64/kernel/topology.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 7415c166281f..f845a8617812 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -215,13 +215,8 @@ EXPORT_SYMBOL_GPL(cpu_topology);
>
> const struct cpumask *cpu_coregroup_mask(int cpu)
> {
> - const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
> + const cpumask_t *core_mask = &cpu_topology[cpu].core_sibling;
>
> - /* Find the smaller of NUMA, core or LLC siblings */
> - if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
> - /* not numa in package, lets use the package siblings */
> - core_mask = &cpu_topology[cpu].core_sibling;
> - }
> if (cpu_topology[cpu].llc_id != -1) {
> if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
> core_mask = &cpu_topology[cpu].llc_siblings;
> @@ -239,8 +234,10 @@ static void update_siblings_masks(unsigned int cpuid)
> for_each_possible_cpu(cpu) {
> cpu_topo = &cpu_topology[cpu];
>
> - if (cpuid_topo->llc_id == cpu_topo->llc_id)
> + if (cpuid_topo->llc_id == cpu_topo->llc_id) {
> cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
> + cpumask_set_cpu(cpuid, &cpu_topo->llc_siblings);
> + }
>
> if (cpuid_topo->package_id != cpu_topo->package_id)
> continue;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* "media: ov5640: Add horizontal and vertical totals" regression issue on i.MX6QDL
From: Jagan Teki @ 2018-06-07 14:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
ov5640 camera is breaking with below commit on i.MXQDL platform.
commit 476dec012f4c6545b0b7599cd9adba2ed819ad3b
Author: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Mon Apr 16 08:36:55 2018 -0400
media: ov5640: Add horizontal and vertical totals
All the initialization arrays are changing the horizontal and vertical
totals for some value.
In order to clean up the driver, and since we're going to need that value
later on, let's introduce in the ov5640_mode_info structure the horizontal
and vertical total sizes, and move these out of the bytes array.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
We have reproduced as below [1] and along with ipu1_csi0 pipeline. I
haven't debug further please let us know how to move further.
media-ctl --links "'ov5640 2-003c':0->'imx6-mipi-csi2':0[1]"
media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
media-ctl --links "'ipu1_csi0_mux':2->'ipu1_csi0':0[1]"
media-ctl --links "'ipu1_csi0':2->'ipu1_csi0 capture':0[1]"
media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/640x480 field:none]"
media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/640x480 field:none]"
media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/640x480 field:none]"
media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:AYUV32/640x480 field:none]"
media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/640x480 field:none]"
[1] https://lkml.org/lkml/2018/5/31/543
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCH 1/3] rtc: ftrtc010: switch to devm_rtc_allocate_device
From: Hans Ulli Kroll @ 2018-06-07 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-1-alexandre.belloni@bootlin.com>
On Mon, 4 Jun 2018, Alexandre Belloni wrote:
> Switch to devm_rtc_allocate_device/rtc_register_device. This allow or
> further improvement and simplifies ftrtc010_rtc_remove().
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/rtc/rtc-ftrtc010.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ftrtc010.c b/drivers/rtc/rtc-ftrtc010.c
> index af8d6beae20c..165d0b62db00 100644
> --- a/drivers/rtc/rtc-ftrtc010.c
> +++ b/drivers/rtc/rtc-ftrtc010.c
> @@ -166,14 +166,18 @@ static int ftrtc010_rtc_probe(struct platform_device *pdev)
> if (!rtc->rtc_base)
> return -ENOMEM;
>
> + rtc->rtc_dev = devm_rtc_allocate_device(dev);
> + if (IS_ERR(rtc->rtc_dev))
> + return PTR_ERR(rtc->rtc_dev);
> +
> + rtc->rtc_dev->ops = &ftrtc010_rtc_ops;
> +
> ret = devm_request_irq(dev, rtc->rtc_irq, ftrtc010_rtc_interrupt,
> IRQF_SHARED, pdev->name, dev);
> if (unlikely(ret))
> return ret;
>
> - rtc->rtc_dev = rtc_device_register(pdev->name, dev,
> - &ftrtc010_rtc_ops, THIS_MODULE);
> - return PTR_ERR_OR_ZERO(rtc->rtc_dev);
> + return rtc_register_device(rtc->rtc_dev);
> }
>
> static int ftrtc010_rtc_remove(struct platform_device *pdev)
> @@ -184,7 +188,6 @@ static int ftrtc010_rtc_remove(struct platform_device *pdev)
> clk_disable_unprepare(rtc->extclk);
> if (!IS_ERR(rtc->pclk))
> clk_disable_unprepare(rtc->pclk);
> - rtc_device_unregister(rtc->rtc_dev);
>
> return 0;
> }
> --
> 2.17.1
>
>
Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
^ permalink raw reply
* [PATCH 2/3] rtc: ftrtc010: handle dates after 2106
From: Hans Ulli Kroll @ 2018-06-07 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-2-alexandre.belloni@bootlin.com>
On Mon, 4 Jun 2018, Alexandre Belloni wrote:
> Use correct types for offset and time and use
> rtc_time64_to_tm/rtc_tm_to_time64 to handle dates after 2106 properly.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/rtc/rtc-ftrtc010.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ftrtc010.c b/drivers/rtc/rtc-ftrtc010.c
> index 165d0b62db00..2cdc78ffeb17 100644
> --- a/drivers/rtc/rtc-ftrtc010.c
> +++ b/drivers/rtc/rtc-ftrtc010.c
> @@ -73,8 +73,8 @@ static int ftrtc010_rtc_read_time(struct device *dev, struct rtc_time *tm)
> {
> struct ftrtc010_rtc *rtc = dev_get_drvdata(dev);
>
> - unsigned int days, hour, min, sec;
> - unsigned long offset, time;
> + u32 days, hour, min, sec, offset;
> + timeu64_t time;
>
> sec = readl(rtc->rtc_base + FTRTC010_RTC_SECOND);
> min = readl(rtc->rtc_base + FTRTC010_RTC_MINUTE);
> @@ -84,7 +84,7 @@ static int ftrtc010_rtc_read_time(struct device *dev, struct rtc_time *tm)
>
> time = offset + days * 86400 + hour * 3600 + min * 60 + sec;
>
> - rtc_time_to_tm(time, tm);
> + rtc_time64_to_tm(time, tm);
>
> return 0;
> }
> @@ -92,13 +92,13 @@ static int ftrtc010_rtc_read_time(struct device *dev, struct rtc_time *tm)
> static int ftrtc010_rtc_set_time(struct device *dev, struct rtc_time *tm)
> {
> struct ftrtc010_rtc *rtc = dev_get_drvdata(dev);
> - unsigned int sec, min, hour, day;
> - unsigned long offset, time;
> + u32 sec, min, hour, day, offset;
> + timeu64_t time;
>
> if (tm->tm_year >= 2148) /* EPOCH Year + 179 */
> return -EINVAL;
>
> - rtc_tm_to_time(tm, &time);
> + time = rtc_tm_to_time64(tm);
>
> sec = readl(rtc->rtc_base + FTRTC010_RTC_SECOND);
> min = readl(rtc->rtc_base + FTRTC010_RTC_MINUTE);
> --
> 2.17.1
>
>
Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
^ permalink raw reply
* [PATCH 3/3] rtc: ftrtc010: let the core handle range
From: Hans Ulli Kroll @ 2018-06-07 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-3-alexandre.belloni@bootlin.com>
On Mon, 4 Jun 2018, Alexandre Belloni wrote:
> The current range handling is highly suspicious. Anyway, let the core
> handle it.
> The RTC has a 32 bit counter on top of days + hh:mm:ss registers.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/rtc/rtc-ftrtc010.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ftrtc010.c b/drivers/rtc/rtc-ftrtc010.c
> index 2cdc78ffeb17..61f798c6101f 100644
> --- a/drivers/rtc/rtc-ftrtc010.c
> +++ b/drivers/rtc/rtc-ftrtc010.c
> @@ -95,9 +95,6 @@ static int ftrtc010_rtc_set_time(struct device *dev, struct rtc_time *tm)
> u32 sec, min, hour, day, offset;
> timeu64_t time;
>
> - if (tm->tm_year >= 2148) /* EPOCH Year + 179 */
> - return -EINVAL;
> -
> time = rtc_tm_to_time64(tm);
>
> sec = readl(rtc->rtc_base + FTRTC010_RTC_SECOND);
> @@ -120,6 +117,7 @@ static const struct rtc_class_ops ftrtc010_rtc_ops = {
>
> static int ftrtc010_rtc_probe(struct platform_device *pdev)
> {
> + u32 days, hour, min, sec;
> struct ftrtc010_rtc *rtc;
> struct device *dev = &pdev->dev;
> struct resource *res;
> @@ -172,6 +170,15 @@ static int ftrtc010_rtc_probe(struct platform_device *pdev)
>
> rtc->rtc_dev->ops = &ftrtc010_rtc_ops;
>
> + sec = readl(rtc->rtc_base + FTRTC010_RTC_SECOND);
> + min = readl(rtc->rtc_base + FTRTC010_RTC_MINUTE);
> + hour = readl(rtc->rtc_base + FTRTC010_RTC_HOUR);
> + days = readl(rtc->rtc_base + FTRTC010_RTC_DAYS);
> +
> + rtc->rtc_dev->range_min = (u64)days * 86400 + hour * 3600 +
> + min * 60 + sec;
> + rtc->rtc_dev->range_max = U32_MAX + rtc->rtc_dev->range_min;
> +
> ret = devm_request_irq(dev, rtc->rtc_irq, ftrtc010_rtc_interrupt,
> IRQF_SHARED, pdev->name, dev);
> if (unlikely(ret))
> --
> 2.17.1
>
>
Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
^ permalink raw reply
* "media: ov5640: Add horizontal and vertical totals" regression issue on i.MX6QDL
From: Maxime Ripard @ 2018-06-07 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZCjNHUeHAJCDjoTHh_w1nNkUFTLjbp1=sYuF2DRiz-E-g@mail.gmail.com>
On Thu, Jun 07, 2018 at 08:02:28PM +0530, Jagan Teki wrote:
> Hi,
>
> ov5640 camera is breaking with below commit on i.MXQDL platform.
>
> commit 476dec012f4c6545b0b7599cd9adba2ed819ad3b
> Author: Maxime Ripard <maxime.ripard@bootlin.com>
> Date: Mon Apr 16 08:36:55 2018 -0400
>
> media: ov5640: Add horizontal and vertical totals
>
> All the initialization arrays are changing the horizontal and vertical
> totals for some value.
>
> In order to clean up the driver, and since we're going to need that value
> later on, let's introduce in the ov5640_mode_info structure the horizontal
> and vertical total sizes, and move these out of the bytes array.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>
> We have reproduced as below [1] and along with ipu1_csi0 pipeline. I
> haven't debug further please let us know how to move further.
>
> media-ctl --links "'ov5640 2-003c':0->'imx6-mipi-csi2':0[1]"
> media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
> media-ctl --links "'ipu1_csi0_mux':2->'ipu1_csi0':0[1]"
> media-ctl --links "'ipu1_csi0':2->'ipu1_csi0 capture':0[1]"
>
> media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/640x480 field:none]"
> media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/640x480 field:none]"
> media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/640x480 field:none]"
> media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:AYUV32/640x480 field:none]"
> media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/640x480 field:none]"
>
> [1] https://lkml.org/lkml/2018/5/31/543
Yeah, this has already been reported as part as this serie:
https://www.mail-archive.com/linux-media at vger.kernel.org/msg131655.html
and some suggestions have been done here:
https://www.mail-archive.com/linux-media at vger.kernel.org/msg132570.html
Feel free to help debug this.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Rob Herring @ 2018-06-07 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <OSBPR01MB205442B483C792125E6A6AF7D2640@OSBPR01MB2054.jpnprd01.prod.outlook.com>
On Thu, Jun 7, 2018 at 1:59 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> On 06 June 2018 22:53, Frank wrote:
>> On 06/06/18 14:48, Frank Rowand wrote:
>> > On 06/05/18 23:36, Michel Pollet wrote:
>> >> Hi Frank,
>> >>
>> >> On 05 June 2018 18:34, Frank wrote:
>> >>> On 06/05/18 04:28, Michel Pollet wrote:
>> >>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot
>> >>>> time, it requires a special enable method to get it started.
[...]
>> >>>> + * The second CPU is parked in ROM at boot time. It requires
>> >>>> +waking it after
>> >>>> + * writing an address into the BOOTADDR register of sysctrl.
>> >>>> + *
>> >>>> + * So the default value of the "cpu-release-addr" corresponds to
>> >>> BOOTADDR...
>> >>>> + *
>> >>>> + * *However* the BOOTADDR register is not available when the
>> >>>> +kernel
>> >>>> + * starts in NONSEC mode.
>> >>>> + *
>> >>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into
>> >>>> +a pen
>> >>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>> >>>> +SRAM address,
>> >>>> + * which is not restricted.
>> >>>
>> >>> The binding document for cpu-release-addr does not have a definition
>> >>> for 32 bit arm. The existing definition is only 64 bit arm. Please
>> >>> add the definition for 32 bit arm to patch 1.
>> >>
>> >> Hmmm I do find a definition in
>> >> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>> >> added my 'enable-method' -- And it is already used as 32 bits in at
>> >> least arch/arm/boot/dts/stih407-family.dtsi.
>> >
>> > If the correct answer is for cpu-release-addr to be 64 bits in certain
>> > cases (that discussion is ongoing further downthread) then one
>> > approach to maintain compatibility _and_ to fix the devicetree source
>> > files is to change the source code that currently gets
>> > cpu-release-addr as a
>> > 32 bit object to check the size of the property and get it as either a
>> > 32 bit or 64 bit object, based on the actual size of the property in
>> > the device tree and then change the value in the devicetree source
>> > files to be two cells. BUT this does not consider the bootloader
>> > complication. arch/arm/boot/dts/axm5516-cpus.dtsi has a note "//
>> > Fixed by the boot loader", so the boot loader also has to be modified
>> > to be able to handle the possibility that the property could be either
>> > 32 bits or 64 bits. I don't know how to maintain compatibility with
>> > the boot loader since we can't force it to change synchronously with
>> > changes in the kernel.
>> >
>> > You can consider this comment to be a drive-by observation. I think
>> > Rob and Geert and people like that are likely to be more helpful with
>> > what to actually do, and you can treat my comment more as pointing out
>> > the issue than as providing the perfect solution.
>>
>> Darn it, hit <send> too quickly.
>>
>> I meant to mention that there are several devicetree source files that have a
>> single cell value for cpu-release-addr, and thus potentially face the same
>> situation, depending on what the final decision is on the proper size for cpu-
>> release-addr. As of v4.17, a git grep shows one cell values in:
>>
>> arch/arm/boot/dts/axm5516-cpus.dtsi
>> arch/arm/boot/dts/stih407-family.dtsi
>> arch/arm/boot/dts/stih418.dtsi
>
> Yes, I had grepped before I used 32 bits on mine...
>
> Now, what is the decision here? Our bootloader is already modified to set it to 32 bits, so I propose that
And too late to fix the bootloader?
>
> + I change the driver to handle 32 and 64 bits properties
That's fine if you can't fix the bootloader.
> + I add this to the cpu.txt, as a separate patch:
> # On other systems, the property can be either
> 32 bits or 64 bits, it is the driver's responsibility
> to deal with either sizes.
That is definitely not what we want to say. Use of 32-bit should be
considered out of spec. Yes, we have a few platforms in that category,
but they already handle that themselves. Would be nice to fix them,
but at least the STi platforms don't seem too active.
IMO, we should delete whatever text we can here and at most just refer
to the spec.
Rob
^ permalink raw reply
* [PATCH] perf: xgene: Fix IOB SLOW PMU parser error
From: Will Deacon @ 2018-06-07 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528319214-19726-1-git-send-email-hoan.tran@amperecomputing.com>
On Wed, Jun 06, 2018 at 02:06:54PM -0700, Hoan Tran wrote:
> This patch fixes the below parser error of the IOB SLOW PMU.
>
> # perf stat -a -e iob-slow0/cycle-count/ sleep 1
> evenf syntax error: 'iob-slow0/cycle-count/'
> \___ parser error
>
> It replaces the "-" character by "_" character inside the PMU name.
>
> Signed-off-by: Hoan Tran <hoan.tran@amperecomputing.com>
Hmm, why did you only notice this now? :(
Anyway, whilst this could in theory break something, we did this for the CPU
PMUs in the past without issues so I'll pick this up.
Cheers,
Will
^ permalink raw reply
* [alsa-devel] [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Arnaud Pouliquen @ 2018-06-07 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <s5hpo14w8k6.wl-tiwai@suse.de>
On 06/06/2018 11:47 AM, Takashi Iwai wrote:
> On Wed, 06 Jun 2018 11:31:45 +0200,
> Arnaud Pouliquen wrote:
>>
>>
>>
>> On 06/05/2018 08:29 PM, Takashi Iwai wrote:
>> > On Tue, 05 Jun 2018 17:50:57 +0200,
>> > Arnaud Pouliquen wrote:
>> >>
>> >> Hi Takashi,
>> >>
>> >> On 04/17/2018 01:17 PM, Mark Brown wrote:
>> >> > On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
>> >> >
>> >> >> I guess the blocking patch in this patchset is the patch "add IEC958
>> >> >> channel status control helper". This patch has been reviewed several
>> >> >> times, but did not get a ack so far.
>> >> >> If you think these helpers will not be merged, I will reintegrate the
>> >> >> corresponding code in stm driver.
>> >> >> Please let me know, if I need to prepare a v2 without helpers, or if we
>> >> >> can go further in the review of iec helpers patch ?
>> >> >
>> >> > I don't mind either way but you're right here, I'm waiting for Takashi
>> >> > to review the first patch.? I'd probably be OK with it just integrated
>> >> > into the driver if we have to go that way though.
>> >>
>> >> Gentlemen reminder for this patch set. We would appreciate to have your
>> >> feedback on iec helper.
>> >> From our point of view it could be useful to have a generic management
>> >> of the iec controls based on helpers instead of redefining them in DAIs.
>> >> Having the same behavior for these controls could be useful to ensure
>> >> coherence of the control management used by application (for instance
>> >> Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
>> >
>> > Oh sorry for the late reply, I've totally overlooked the thread.
>> >
>> > And, another sorry: the patchset doesn't look convincing enough to
>> > me.
>> >
>> > First off, the provided API definition appears somewhat
>> > unconventional, the mixture of the ops, the static data and the
>> > dynamic data.
>> Sorry i can't figure out your point. I suppose that you speak about the
>> snd_pcm_iec958_params.
>> what would be a more conventional API?
>
> Imagine you'd want to put a const to the data passed to the API for
> hardening.? The current struct is a mixture of static and dynamic
> data.
>
>
>> > Moreover, this is only for your driver, ATM.?
>> It is also compatible with the sound/sti driver, even if we does not
>> propose patch yet. We also plan to propose an implementation, for the
>> HDMI_codec that would need to export a control to allow none-audio mode.
>>
>> >If it were an API that
>> > does clean up the already existing usages, I'd happily apply it. There
>> > are lots of drivers creating and controlling the IEC958 ctls even
>> > now.
>> >
>> > Also, the patchset requires more fine-tuning, in anyways.? The changes
>> > in create_iec958_consumre() are basically irrelevant, should be split
>> > off as an individual fix.? it is linked to the control, as not possible in existing implementation
>> (rate and width are get from hwparam or runtime). But no problem we can
>> split it in a separate patch.
>>
>> Also, the new function doesn't create the
>> > "XXX Mask" controls.? And the byte comparison should be replaced with
>> > memcmp(), etc, etc.
>> Yes mask are missing, can be added. For the rest could you comment
>> directly in code? i suppose that you want to replace the for loops by
>> memcmp, memcpy...
>
> Right.
>
>> > So, please proceed rather with the open codes for now.? If you can
>> > provide a patch that cleans up the *multiple* driver codes, again,
>> > I'll happily take it.? But it can be done anytime later, too.
>> Not simple to clean up the other drivers as this control is a PCM
>> control, that is mainly implemented as a mixer or card control.
>> This means that it should be registered on the pcm_new in CPU DAI or in
>> the DAI codec, to be able to bind it to the PCM device.
>> Inpact is not straigthforward as this could generate regression on driver.
>
> Yes, and that's my point.? The application of API is relatively
> limited -- although the API itself has nothing to do with ASoC at
> all.
>
>> For now We can add the clean up on the sti driver based on this helper,
>> and we are working on the HDMI_codec, we could also use this helper to
>> export the control....
>>
>> So if you estimate that it is interesting to purchase on this helper we
>> can try to come back with a patch set that implements the helper for
>> the 3 drivers.
>
> Right.? Basically there are two cases we add a new API:
>
> 1. It's absolutely new and nothing else can do it
> 2. API simplifies the whole tree, not only one you're trying to add.
>
> And in this case, let's prove 2 at first, that the API *is* actually
> useful in multiple situations we already have.? Then I'll happily ack
> for that.? More drivers cleanup, better.? At best, think of more
> range above ASoC, as you're proposing ALSA core API, not the ASoC
> one.
>
>> The other option, is that we drop the helpers, and implement the control
>> directly in our drivers.
>
> This is of course another, maybe easier option.
>
>> Please just tell us if we should continue to propose the helpers or not.
>
> I have no preference over two ways, but am only interested in the
> resulting patches :)
My tentative here was to start to introduce helpers at ALSA level (not
only ASoC) to have a generic implementation of the this generic control.
Today the snd_pcm_create_iec958_consumer_hw_params just allow to fill
AES based on runtime parameters, but not to offer a generic management
of iec control.
Now you are right i'm developing under ASoC and i have not the whole
knowledge of the ALSA drivers, an probably too limited view of the iec
controls usage.
Based on your feedback i think (at least in a first step) we will choose
the easiest option for the STM driver...
Thanks
Arnaud
>
>
> thanks,
>
> Takashi
^ permalink raw reply
* [PATCH v2 1/1] ARM: dts: cygnus: enable iproc-hwrng
From: Florian Fainelli @ 2018-06-07 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528309291-25579-1-git-send-email-scott.branden@broadcom.com>
On 06/06/2018 11:21 AM, Scott Branden wrote:
> From: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>
> Enable the HW rng driver "iproc-rng200" for all cygnus platforms.
>
> Signed-off-by: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Clement, do you want to test this and reported back?
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 9fe4f5a..b0e38fa 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -417,6 +417,11 @@
> status = "disabled";
> };
>
> + rng: rng at 18032000 {
> + compatible = "brcm,iproc-rng200";
> + reg = <0x18032000 0x28>;
> + };
> +
> sdhci0: sdhci at 18041000 {
> compatible = "brcm,sdhci-iproc-cygnus";
> reg = <0x18041000 0x100>;
>
--
Florian
^ permalink raw reply
* [PATCH v2 1/1] ARM: dts: cygnus: enable iproc-hwrng
From: Clément Péron @ 2018-06-07 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c0b4d69d-2826-320e-974e-c7cdbf341747@gmail.com>
Hi Florian,
On Thu, 7 Jun 2018 at 18:35, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 06/06/2018 11:21 AM, Scott Branden wrote:
> > From: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> >
> > Enable the HW rng driver "iproc-rng200" for all cygnus platforms.
> >
> > Signed-off-by: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> > Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> > Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>
> Clement, do you want to test this and reported back?
Tested v1 and works fine on bcm58305
Tested-by: Cl?ment P?ron <peron.clem@gmail.com>
>
> > ---
> > arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> > index 9fe4f5a..b0e38fa 100644
> > --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> > +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> > @@ -417,6 +417,11 @@
> > status = "disabled";
> > };
> >
> > + rng: rng at 18032000 {
> > + compatible = "brcm,iproc-rng200";
> > + reg = <0x18032000 0x28>;
> > + };
> > +
> > sdhci0: sdhci at 18041000 {
> > compatible = "brcm,sdhci-iproc-cygnus";
> > reg = <0x18041000 0x100>;
> >
>
>
> --
> Florian
^ permalink raw reply
* [PATCH v2 1/1] ARM: dts: cygnus: enable iproc-hwrng
From: Florian Fainelli @ 2018-06-07 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528309291-25579-1-git-send-email-scott.branden@broadcom.com>
On Wed, 6 Jun 2018 11:21:31 -0700, Scott Branden <scott.branden@broadcom.com> wrote:
> From: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>
> Enable the HW rng driver "iproc-rng200" for all cygnus platforms.
>
> Signed-off-by: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
Applied to devicetree/next, thanks!
--
Florian
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Leonard Crestez @ 2018-06-07 17:00 UTC (permalink / raw)
To: linux-arm-kernel
The following sensors are on I2C3 on the baseboard:
* isil,isl29023 light sensor
* fsl,mag3110 magnetometer
* fsl,mma8451 accelerometer
Added under i2cmux/i2c at 1 because they're not otherwise accessible.
These are all supported by iio with following configs:
* CONFIG_SENSORS_ISL29018
* CONFIG_MAG3110
* CONFIG_MMA8452
Tested with raw reads from iio sysfs.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 54b0139e978d..a6193240259d 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -160,10 +160,31 @@
compatible = "maxim,max7310";
reg = <0x34>;
gpio-controller;
#gpio-cells = <2>;
};
+
+ isl29023 at 44 {
+ compatible = "isil,isl29023";
+ reg = <0x44>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ mag3110 at 0e {
+ compatible = "fsl,mag3110";
+ reg = <0x0e>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ mma8451 at 1c {
+ compatible = "fsl,mma8451";
+ reg = <0x1c>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
};
&ipu1_csi0_from_ipu1_csi0_mux {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] imx_v6_v7_defconfig: Enable imx6qdl-sabreauto sensors
From: Leonard Crestez @ 2018-06-07 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b31ca3ff50566c193003614d0bbf5e0a0e95901c.1528390418.git.leonard.crestez@nxp.com>
CONFIG_SENSORS_ISL29018 supports isil,il29023 light sensor
CONFIG_MMA8452 supports fsl,mma8451 accelerometer
CONFIG_MAG3110 for fsl,mag3110 is already enabled
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 3a308437b088..7efcce8083d2 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -364,12 +364,14 @@ CONFIG_MXS_DMA=y
CONFIG_STAGING=y
CONFIG_STAGING_MEDIA=y
CONFIG_VIDEO_IMX_MEDIA=y
CONFIG_COMMON_CLK_PWM=y
CONFIG_IIO=y
+CONFIG_MMA8452=y
CONFIG_IMX7D_ADC=y
CONFIG_VF610_ADC=y
+CONFIG_SENSORS_ISL29018=y
CONFIG_MAG3110=y
CONFIG_MPL3115=y
CONFIG_PWM=y
CONFIG_PWM_FSL_FTM=y
CONFIG_PWM_IMX=y
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Fabio Estevam @ 2018-06-07 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b31ca3ff50566c193003614d0bbf5e0a0e95901c.1528390418.git.leonard.crestez@nxp.com>
Hi Leonard,
On Thu, Jun 7, 2018 at 2:00 PM, Leonard Crestez <leonard.crestez@nxp.com> wrote:
> +
> + isl29023 at 44 {
According to Devicetree Specification v0.2 document:
"The name of a node should be somewhat generic, reflecting the function
of the device and not its precise programming model."
So you could write:
light-sensor at 44
> + compatible = "isil,isl29023";
> + reg = <0x44>;
> + interrupt-parent = <&gpio5>;
> + interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
> + };
> +
> + mag3110 at 0e {
No leading zero in unit address, please.
Building with W=1 will give you warnings about it.
magnetometer at e
> + compatible = "fsl,mag3110";
> + reg = <0x0e>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <29 IRQ_TYPE_EDGE_RISING>;
> + };
> +
> + mma8451 at 1c {
accelerometer at 1c
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Kim Phillips @ 2018-06-07 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <adbabdb0-df2c-be74-3cde-cda4f6bce579@arm.com>
On Thu, 7 Jun 2018 11:07:15 +0100
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 06/07/2018 10:53 AM, Greg Kroah-Hartman wrote:
> > On Thu, Jun 07, 2018 at 10:32:21AM +0100, Suzuki K Poulose wrote:
> >> On 06/07/2018 10:13 AM, Greg Kroah-Hartman wrote:
> >>> On Thu, Jun 07, 2018 at 10:04:33AM +0100, Suzuki K Poulose wrote:
> >>>> Hi Greg,
> >>>>
> >>>> On 06/07/2018 09:34 AM, Greg Kroah-Hartman wrote:
> >>>>> On Wed, Jun 06, 2018 at 03:55:01PM -0500, Kim Phillips wrote:
> >>>>>> On Wed, 6 Jun 2018 10:46:36 +0100
> >>>>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >>>>>>
> >>>>>>> On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote:
> >>>>>>>> On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote:
> >>>>>>>>> Increment the refcnt for driver modules in current use by calling
> >>>>>>>>> module_get in coresight_build_path and module_put in release_path.
> >>>>>>>>>
> >>>>>>>>> This prevents driver modules from being unloaded when they are in use,
> >>>>>>>>> either in sysfs or perf mode.
> >>>>>>>>
> >>>>>>>> Why does it matter? Shouldn't you be allowed to remove any module at
> >>>>>>>> any point in time, much like a networking driver?
> >>>>
> >>>> The user doesn't have an explicit refcount on the individual components
> >>>> in a trace session. So, when a trace session is in progress, it is as
> >>>> good as having a "file" open on each component that is part of the
> >>>> active trace session. So, we don't want the driver to be removed when
> >>>> the component is being used in the trace collection.
> >>>
> >>> Why not? What's wrong with that happening and then the trace collection
> >>> starts failing with -ENODEV or something?
> >>
> >> May be I am missing something here. Can we allow the driver to be removed
> >> when one of its device is "turned ON" and we need the same
> >> driver to "turn it OFF" when the session ends ? To make a better
> >> comparison :
> >>
> >> Can we unload a usb_mass_storage module when a USB disk(which uses the
> >> module driver) is mounted and is being used ? I believe, the module
> >> will eventually get unloaded when we unmount the disk, if someone did
> >> a unload.
> >
> > No, mount causes the module count to be incrememted. Mount and
> > "open/close" are the old-school way of doing module reference counting.
> >
> > Look at how network drivers work today, you can unload any network
> > driver even if there is a valid network connection "up and running"
> > attached to it. It just gets torn down when that request happens.
>
> Ok, that makes more sense now. Thanks for the hints. However, it doesn't
> look that easy from the coresight point due to the way the devices are
> used in an interconnected manner which could be part of multiple trace
> sessions.
>
> e.g, a funnel could be part of two independent trace sessions with
> different sets of sources/sinks. Tearing down the trace sessions is
> going to be a difficult task unless we make drastic changes to the PMU
> framework itself. But will see, what best we can do to make it modern
> :-)
> >
> >> We have a similar situation here. The only difference is the driver is
> >> referenced only when one of its device is in a trace session.
> >
> > I understand, I'm saying that you have to be very careful when messing
> > around with module reference counts to get it correct and perhaps you
> > should just change your design to not care about module reference counts
> > at all, like networking did 15+ years ago.
> >
> > Let's learn from the good examples in our past (like networking), and
> > not like the older bad examples (like mount/files).
> >
> >>> Remember, removing a kernel module is something that only happens very
> >>> rarely, and is an explicit choice by someone with root permissions. If
> >>> you want to remove that module, it should be able to go, as you know
> >>> what you are doing at that point in time.
> >>
> >> Right, but when a device is "in use" can we do that ? I thought the user
> >> will get a module is in use or busy, error.
> >
> > Try it on networking today :)
> >
> >>> Don't try to "protect the user from themselves" here, they want to shoot
> >>> their foot, make it hurt if they are aiming it there :)
> >>>
> >>
> >> The module_get/put added here are only triggered when we start a trace
> >> session, where we build a path for the current session from the configured
> >> "source" to the configured "sink" and the path is destroyed
> >> at the end of the trace session. i.e, the path is not a permanent thing.
> >> It is constructed per session. So it is perfectly possible to remove a
> >> device in between trace sessions.
> >
> > That's fine, but again, just be careful to get this correct. The patch
> > I reviewed did not seem to do that.
>
> Thanks for the useful suggestions, we will explore this more.
I'm going to assume the series is still valid after this discussion,
since technically just this patch can get dropped, and the user is able
to shoot themselves in the foot. This series is for development
purposes, after all.
Let me know if I'm missing something.
Thanks,
Kim
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Scott Branden @ 2018-06-07 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d35afa1f-e0fd-84f1-7d42-60595e22cc77@gmail.com>
Hi Rob,
Could you please kindly comment on change below.
It allows board variants to be added easily via a simple define for
different number of SATA ports.
On 18-06-04 09:22 AM, Florian Fainelli wrote:
> On 05/18/2018 11:34 AM, Scott Branden wrote:
>> Move remaining sata configuration to stingray-sata.dtsi and enable
>> ports based on NUM_SATA defined.
>> Now, all that needs to be done is define NUM_SATA per board.
> Rob could you review this and let us know if this approach is okay or
> not? Thank you!
>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> ---
>> .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
>> .../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
>> .../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
>> .../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
>> 4 files changed, 72 insertions(+), 64 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> index 8862ec9..cacc25e 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>> @@ -72,70 +72,6 @@
>> <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
>> };
>>
>> -&sata0 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy0{
>> - status = "okay";
>> -};
>> -
>> -&sata1 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy1{
>> - status = "okay";
>> -};
>> -
>> -&sata2 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy2{
>> - status = "okay";
>> -};
>> -
>> -&sata3 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy3{
>> - status = "okay";
>> -};
>> -
>> -&sata4 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy4{
>> - status = "okay";
>> -};
>> -
>> -&sata5 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy5{
>> - status = "okay";
>> -};
>> -
>> -&sata6 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy6{
>> - status = "okay";
>> -};
>> -
>> -&sata7 {
>> - status = "okay";
>> -};
>> -
>> -&sata_phy7{
>> - status = "okay";
>> -};
>> -
>> &mdio_mux_iproc {
>> mdio at 10 {
>> gphy0: eth-phy at 10 {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> index 77efa28..a515346 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>> @@ -32,6 +32,8 @@
>>
>> /dts-v1/;
>>
>> +#define NUM_SATA 8
>> +
>> #include "bcm958742-base.dtsi"
>>
>> / {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> index 5084b03..6a4d19e 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>> @@ -32,6 +32,8 @@
>>
>> /dts-v1/;
>>
>> +#define NUM_SATA 8
>> +
>> #include "bcm958742-base.dtsi"
>>
>> / {
>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> index 8c68e0c..7f6d176 100644
>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>> @@ -43,7 +43,11 @@
>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 0)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata0_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -58,7 +62,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 0)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata0_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -73,7 +81,11 @@
>> interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 1)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata1_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -88,7 +100,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 1)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata1_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -103,7 +119,11 @@
>> interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 2)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata2_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -118,7 +138,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 2)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata2_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -133,7 +157,11 @@
>> interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 3)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata3_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -148,7 +176,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 3)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata3_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -163,7 +195,11 @@
>> interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 4)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata4_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -178,7 +214,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 4)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata4_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -193,7 +233,11 @@
>> interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 5)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata5_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -208,7 +252,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 5)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata5_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -223,7 +271,11 @@
>> interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 6)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata6_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -238,7 +290,11 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 6)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata6_phy0: sata-phy at 0 {
>> reg = <0>;
>> @@ -253,7 +309,11 @@
>> interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 7)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata7_port0: sata-port at 0 {
>> reg = <0>;
>> @@ -268,11 +328,19 @@
>> reg-names = "phy";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +#if (NUM_SATA > 7)
>> + status = "okay";
>> +#else
>> status = "disabled";
>> +#endif
>>
>> sata7_phy0: sata-phy at 0 {
>> reg = <0>;
>> #phy-cells = <0>;
>> };
>> };
>> +
>> +#if (NUM_SATA > 8)
>> +#error "NUM_SATA > 8"
>> +#endif
>> };
>>
>
^ permalink raw reply
* [PATCH] spi: clps711x: remove unused header
From: Corentin Labbe @ 2018-06-07 19:52 UTC (permalink / raw)
To: linux-arm-kernel
include/linux/platform_data/spi-clps711x.h is unused since 6acaadc852f1
("spi: clps711x: Driver refactor")
Let's remove it.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
include/linux/platform_data/spi-clps711x.h | 21 ---------------------
1 file changed, 21 deletions(-)
delete mode 100644 include/linux/platform_data/spi-clps711x.h
diff --git a/include/linux/platform_data/spi-clps711x.h b/include/linux/platform_data/spi-clps711x.h
deleted file mode 100644
index 301956e63143..000000000000
--- a/include/linux/platform_data/spi-clps711x.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * CLPS711X SPI bus driver definitions
- *
- * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef ____LINUX_PLATFORM_DATA_SPI_CLPS711X_H
-#define ____LINUX_PLATFORM_DATA_SPI_CLPS711X_H
-
-/* Board specific platform_data */
-struct spi_clps711x_pdata {
- int *chipselect; /* Array of GPIO-numbers */
- int num_chipselect; /* Total count of GPIOs */
-};
-
-#endif
--
2.16.4
^ permalink raw reply related
* [PATCH v4 0/2] support exception state migration and set VSESR_EL2 by user space
From: Dongjiu Geng @ 2018-06-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
This series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value
The user space patch is here: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06965.html
Dongjiu Geng (2):
arm64: KVM: export the capability to set guest SError syndrome
arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
Documentation/virtual/kvm/api.txt | 42 +++++++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/include/uapi/asm/kvm.h | 12 +++++++++++
arch/arm/kvm/guest.c | 12 +++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 ++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++
arch/arm64/kvm/guest.c | 36 +++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 6 +++---
arch/arm64/kvm/reset.c | 4 ++++
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 19 ++++++++++++++++
12 files changed, 157 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v4 1/2] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-06-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528401833-29963-1-git-send-email-gengdongjiu@huawei.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 758bf40..fdac969 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4603,3 +4603,14 @@ Architectures: s390
This capability indicates that kvm will implement the interfaces to handle
reset, migration and nested KVM for branch prediction blocking. The stfle
facility 82 should not be provided to the guest without this capability.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify the syndrome value reported
+to the guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, it can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+in ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b02c41e..e88f976 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -948,6 +948,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_BPB 152
#define KVM_CAP_GET_MSR_FEATURES 153
#define KVM_CAP_HYPERV_EVENTFD 154
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 155
#ifdef KVM_CAP_IRQ_ROUTING
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox