* [RFC PATCH 1/2] spi: Add QuadSPI driver for Atmel SAMA5D2
From: Piotr Bugalski @ 2018-06-18 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618162124.21749-1-bugalski.piotr@gmail.com>
Kernel contains QSPI driver strongly tied to MTD and nor-flash memory.
New spi-mem interface allows usage also other memory types, especially
much larger NAND with SPI interface. This driver works as SPI controller
and is not related to MTD, however can work with NAND-flash or other
peripherals using spi-mem interface.
Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Piotr Bugalski <pbu@cryptera.com>
---
drivers/spi/Kconfig | 9 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-atmel-qspi.c | 480 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 490 insertions(+)
create mode 100644 drivers/spi/spi-atmel-qspi.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 4a77cfa3213d..4f70a7005997 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -84,6 +84,15 @@ config SPI_ATMEL
This selects a driver for the Atmel SPI Controller, present on
many AT91 ARM chips.
+config SPI_ATMEL_QSPI
+ tristate "Atmel QuadSPI Controller"
+ depends on ARCH_AT91 || (ARM && COMPILE_TEST)
+ depends on OF && HAS_IOMEM
+ help
+ This selects a driver for the Atmel QSPI Controller on SAMA5D2.
+ This controller does not support generic SPI, it supports only
+ spi-mem interface.
+
config SPI_AU1550
tristate "Au1550/Au1200/Au1300 SPI Controller"
depends on MIPS_ALCHEMY
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index fe54d787cf4d..6245a5693b16 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST) += spi-loopback-test.o
obj-$(CONFIG_SPI_ALTERA) += spi-altera.o
obj-$(CONFIG_SPI_ARMADA_3700) += spi-armada-3700.o
obj-$(CONFIG_SPI_ATMEL) += spi-atmel.o
+obj-$(CONFIG_SPI_ATMEL_QSPI) += spi-atmel-qspi.o
obj-$(CONFIG_SPI_ATH79) += spi-ath79.o
obj-$(CONFIG_SPI_AU1550) += spi-au1550.o
obj-$(CONFIG_SPI_AXI_SPI_ENGINE) += spi-axi-spi-engine.o
diff --git a/drivers/spi/spi-atmel-qspi.c b/drivers/spi/spi-atmel-qspi.c
new file mode 100644
index 000000000000..1ee626201b0d
--- /dev/null
+++ b/drivers/spi/spi-atmel-qspi.c
@@ -0,0 +1,480 @@
+/*
+ * Atmel SAMA5D2 QuadSPI driver.
+ *
+ * Copyright (C) 2018 Cryptera A/S
+ * All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 (GPL v2)
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/spi/spi-mem.h>
+#include <linux/delay.h>
+
+#define QSPI_CR 0x0000
+#define QSPI_MR 0x0004
+#define QSPI_RDR 0x0008
+#define QSPI_TDR 0x000c
+#define QSPI_SR 0x0010
+#define QSPI_IER 0x0014
+#define QSPI_IDR 0x0018
+#define QSPI_IMR 0x001c
+#define QSPI_SCR 0x0020
+
+#define QSPI_IAR 0x0030
+#define QSPI_ICR 0x0034
+#define QSPI_IFR 0x0038
+
+#define QSPI_WPMR 0x00e4
+#define QSPI_WPSR 0x00e8
+
+/* Bitfields in QSPI_CR (Control Register) */
+#define QSPI_CR_QSPIEN BIT(0)
+#define QSPI_CR_QSPIDIS BIT(1)
+#define QSPI_CR_SWRST BIT(7)
+#define QSPI_CR_LASTXFER BIT(24)
+
+/* Bitfields in QSPI_ICR (Instruction Code Register) */
+#define QSPI_ICR_INST_MASK GENMASK(7, 0)
+#define QSPI_ICR_INST(inst) (((inst) << 0) & QSPI_ICR_INST_MASK)
+#define QSPI_ICR_OPT_MASK GENMASK(23, 16)
+#define QSPI_ICR_OPT(opt) (((opt) << 16) & QSPI_ICR_OPT_MASK)
+
+/* Bitfields in QSPI_MR (Mode Register) */
+#define QSPI_MR_SMM BIT(0)
+#define QSPI_MR_LLB BIT(1)
+#define QSPI_MR_WDRBT BIT(2)
+#define QSPI_MR_SMRM BIT(3)
+#define QSPI_MR_CSMODE_MASK GENMASK(5, 4)
+#define QSPI_MR_CSMODE_NOT_RELOADED (0 << 4)
+#define QSPI_MR_CSMODE_LASTXFER (1 << 4)
+#define QSPI_MR_CSMODE_SYSTEMATICALLY (2 << 4)
+#define QSPI_MR_NBBITS_MASK GENMASK(11, 8)
+#define QSPI_MR_NBBITS(n) ((((n) - 8) << 8) & QSPI_MR_NBBITS_MASK)
+#define QSPI_MR_DLYBCT_MASK GENMASK(23, 16)
+#define QSPI_MR_DLYBCT(n) (((n) << 16) & QSPI_MR_DLYBCT_MASK)
+#define QSPI_MR_DLYCS_MASK GENMASK(31, 24)
+#define QSPI_MR_DLYCS(n) (((n) << 24) & QSPI_MR_DLYCS_MASK)
+
+/* Bitfields in QSPI_IFR (Instruction Frame Register) */
+#define QSPI_IFR_WIDTH_MASK GENMASK(2, 0)
+#define QSPI_IFR_WIDTH_SINGLE_BIT_SPI (0 << 0)
+#define QSPI_IFR_WIDTH_DUAL_OUTPUT (1 << 0)
+#define QSPI_IFR_WIDTH_QUAD_OUTPUT (2 << 0)
+#define QSPI_IFR_WIDTH_DUAL_IO (3 << 0)
+#define QSPI_IFR_WIDTH_QUAD_IO (4 << 0)
+#define QSPI_IFR_WIDTH_DUAL_CMD (5 << 0)
+#define QSPI_IFR_WIDTH_QUAD_CMD (6 << 0)
+#define QSPI_IFR_INSTEN BIT(4)
+#define QSPI_IFR_ADDREN BIT(5)
+#define QSPI_IFR_OPTEN BIT(6)
+#define QSPI_IFR_DATAEN BIT(7)
+#define QSPI_IFR_OPTL_MASK GENMASK(9, 8)
+#define QSPI_IFR_OPTL_1BIT (0 << 8)
+#define QSPI_IFR_OPTL_2BIT (1 << 8)
+#define QSPI_IFR_OPTL_4BIT (2 << 8)
+#define QSPI_IFR_OPTL_8BIT (3 << 8)
+#define QSPI_IFR_ADDRL BIT(10)
+#define QSPI_IFR_TFRTYP_MASK GENMASK(13, 12)
+#define QSPI_IFR_TFRTYP_TRSFR_READ (0 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_READ_MEM (1 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_WRITE (2 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_WRITE_MEM (3 << 13)
+#define QSPI_IFR_CRM BIT(14)
+#define QSPI_IFR_NBDUM_MASK GENMASK(20, 16)
+#define QSPI_IFR_NBDUM(n) (((n) << 16) & QSPI_IFR_NBDUM_MASK)
+
+/* Bitfields in QSPI_SR/QSPI_IER/QSPI_IDR/QSPI_IMR */
+#define QSPI_SR_RDRF BIT(0)
+#define QSPI_SR_TDRE BIT(1)
+#define QSPI_SR_TXEMPTY BIT(2)
+#define QSPI_SR_OVRES BIT(3)
+#define QSPI_SR_CSR BIT(8)
+#define QSPI_SR_CSS BIT(9)
+#define QSPI_SR_INSTRE BIT(10)
+#define QSPI_SR_QSPIENS BIT(24)
+
+#define QSPI_SR_CMD_COMPLETED (QSPI_SR_INSTRE | QSPI_SR_CSR)
+
+
+/* Bitfields in QSPI_SCR (Serial Clock Register) */
+#define QSPI_SCR_CPOL BIT(0)
+#define QSPI_SCR_CPHA BIT(1)
+#define QSPI_SCR_SCBR_MASK GENMASK(15, 8)
+#define QSPI_SCR_SCBR(n) (((n) << 8) & QSPI_SCR_SCBR_MASK)
+#define QSPI_SCR_DLYBS_MASK GENMASK(23, 16)
+#define QSPI_SCR_DLYBS(n) (((n) << 16) & QSPI_SCR_DLYBS_MASK)
+
+#define QSPI_WPMR_WPKEY_PASSWD (0x515350u << 8)
+
+struct atmel_qspi {
+ struct platform_device *pdev;
+ void __iomem *iobase;
+ void __iomem *ahb_addr;
+ int irq;
+ struct clk *clk;
+ u32 clk_rate;
+ struct completion cmd_done;
+ u32 pending;
+};
+
+struct qspi_mode {
+ u8 cmd_buswidth;
+ u8 addr_buswidth;
+ u8 data_buswidth;
+ u32 config;
+};
+
+static const struct qspi_mode sama5d2_qspi_modes[] = {
+ { 1, 1, 1, QSPI_IFR_WIDTH_SINGLE_BIT_SPI },
+ { 1, 1, 2, QSPI_IFR_WIDTH_DUAL_OUTPUT },
+ { 1, 1, 4, QSPI_IFR_WIDTH_QUAD_OUTPUT },
+ { 1, 2, 2, QSPI_IFR_WIDTH_DUAL_IO },
+ { 1, 4, 4, QSPI_IFR_WIDTH_QUAD_IO },
+ { 2, 2, 2, QSPI_IFR_WIDTH_DUAL_CMD },
+ { 4, 4, 4, QSPI_IFR_WIDTH_QUAD_CMD },
+};
+
+static inline u32 qspi_readl(struct atmel_qspi *aq, u32 reg)
+{
+ return readl_relaxed(aq->iobase + reg);
+}
+
+static inline void qspi_writel(struct atmel_qspi *aq, u32 reg, u32 value)
+{
+ writel_relaxed(value, aq->iobase + reg);
+}
+
+static int atmel_qspi_init(struct atmel_qspi *aq)
+{
+ unsigned long rate;
+ u32 scbr;
+
+ qspi_writel(aq, QSPI_WPMR, QSPI_WPMR_WPKEY_PASSWD);
+
+ /* software reset */
+ qspi_writel(aq, QSPI_CR, QSPI_CR_SWRST);
+
+ /* set QSPI mode */
+ qspi_writel(aq, QSPI_MR, QSPI_MR_SMM);
+
+ rate = clk_get_rate(aq->clk);
+ if (!rate)
+ return -EINVAL;
+
+ /* set baudrate */
+ scbr = DIV_ROUND_UP(rate, aq->clk_rate);
+ if (scbr > 0)
+ scbr--;
+ qspi_writel(aq, QSPI_SCR, QSPI_SCR_SCBR(scbr));
+
+ /* enable qspi controller */
+ qspi_writel(aq, QSPI_CR, QSPI_CR_QSPIEN);
+
+ return 0;
+}
+
+static int atmel_qspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
+{
+ return 0;
+}
+
+static inline bool is_compatible(const struct spi_mem_op *op,
+ const struct qspi_mode *mode)
+{
+ if (op->cmd.buswidth != mode->cmd_buswidth)
+ return false;
+ if (op->addr.nbytes && op->addr.buswidth != mode->addr_buswidth)
+ return false;
+ if (op->data.nbytes && op->data.buswidth != mode->data_buswidth)
+ return false;
+ return true;
+}
+
+static int find_mode(const struct spi_mem_op *op)
+{
+ u32 i;
+
+ for (i = 0; i < ARRAY_SIZE(sama5d2_qspi_modes); i++)
+ if (is_compatible(op, &sama5d2_qspi_modes[i]))
+ return i;
+ return -1;
+}
+
+static bool atmel_qspi_supports_op(struct spi_mem *mem,
+ const struct spi_mem_op *op)
+{
+ if (find_mode(op) < 0)
+ return false;
+
+ // special case not supported by hardware
+ if ((op->addr.nbytes == 2) && (op->cmd.buswidth != op->addr.buswidth) &&
+ (op->dummy.nbytes == 0))
+ return false;
+
+ return true;
+}
+
+static irqreturn_t atmel_qspi_interrupt(int irq, void *dev_id)
+{
+ struct spi_controller *ctrl = dev_id;
+ struct atmel_qspi *aq = spi_controller_get_devdata(ctrl);
+ u32 status, mask, pending;
+
+ status = qspi_readl(aq, QSPI_SR);
+ mask = qspi_readl(aq, QSPI_IMR);
+ pending = status & mask;
+
+ if (!pending)
+ return IRQ_NONE;
+
+ aq->pending |= pending;
+ if ((aq->pending & QSPI_SR_CMD_COMPLETED) == QSPI_SR_CMD_COMPLETED)
+ complete(&aq->cmd_done);
+
+ return IRQ_HANDLED;
+}
+
+static int atmel_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ struct atmel_qspi *aq = spi_controller_get_devdata(mem->spi->master);
+ int mode;
+ u32 addr = 0;
+ u32 dummy_cycles = 0;
+ u32 ifr = QSPI_IFR_INSTEN;
+ u32 icr = QSPI_ICR_INST(op->cmd.opcode);
+
+ qspi_writel(aq, QSPI_MR, QSPI_MR_SMM);
+
+ mode = find_mode(op);
+ if (mode < 0)
+ return -1;
+ ifr |= sama5d2_qspi_modes[mode].config;
+
+ if (op->dummy.buswidth && op->dummy.nbytes)
+ dummy_cycles = op->dummy.nbytes * 8 / op->dummy.buswidth;
+
+ if (op->addr.buswidth) {
+ switch (op->addr.nbytes) {
+ case 0:
+ break;
+ case 1:
+ ifr |= QSPI_IFR_OPTEN | QSPI_IFR_OPTL_8BIT;
+ icr |= QSPI_ICR_OPT(op->addr.val & 0xff);
+ break;
+ case 2:
+ if (dummy_cycles < 8 / op->addr.buswidth) {
+ ifr &= ~QSPI_IFR_INSTEN;
+ addr = (op->cmd.opcode << 16) |
+ (op->addr.val & 0xffff);
+ ifr |= QSPI_IFR_ADDREN;
+ } else {
+ addr = (op->addr.val << 8) & 0xffffff;
+ dummy_cycles -= 8 / op->addr.buswidth;
+ ifr |= QSPI_IFR_ADDREN;
+ }
+ break;
+ case 3:
+ addr = op->addr.val & 0xffffff;
+ ifr |= QSPI_IFR_ADDREN;
+ break;
+ case 4:
+ addr = op->addr.val;
+ ifr |= QSPI_IFR_ADDREN | QSPI_IFR_ADDRL;
+ break;
+ default:
+ return -1;
+ }
+ }
+ ifr |= QSPI_IFR_NBDUM(dummy_cycles);
+ if (op->data.nbytes == 0)
+ qspi_writel(aq, QSPI_IAR, addr);
+ else
+ ifr |= QSPI_IFR_DATAEN;
+
+ if ((op->data.dir == SPI_MEM_DATA_IN) && (op->data.nbytes > 0))
+ ifr |= QSPI_IFR_TFRTYP_TRSFR_READ;
+ else
+ ifr |= QSPI_IFR_TFRTYP_TRSFR_WRITE;
+
+ qspi_writel(aq, QSPI_IAR, addr);
+ qspi_writel(aq, QSPI_ICR, icr);
+ qspi_writel(aq, QSPI_IFR, ifr);
+ qspi_readl(aq, QSPI_IFR);
+
+ if (op->data.nbytes > 0) {
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ _memcpy_fromio(op->data.buf.in,
+ aq->ahb_addr + addr, op->data.nbytes);
+ else
+ _memcpy_toio(aq->ahb_addr + addr,
+ op->data.buf.out, op->data.nbytes);
+
+ qspi_writel(aq, QSPI_CR, QSPI_CR_LASTXFER);
+ }
+
+ aq->pending = qspi_readl(aq, QSPI_SR) & QSPI_SR_CMD_COMPLETED;
+ if (aq->pending == QSPI_SR_CMD_COMPLETED)
+ return 0;
+ reinit_completion(&aq->cmd_done);
+ qspi_writel(aq, QSPI_IER, QSPI_SR_CMD_COMPLETED);
+ wait_for_completion(&aq->cmd_done);
+ qspi_writel(aq, QSPI_IDR, QSPI_SR_CMD_COMPLETED);
+
+ return 0;
+}
+
+static const struct spi_controller_mem_ops atmel_qspi_mem_ops = {
+ .adjust_op_size = atmel_qspi_adjust_op_size,
+ .supports_op = atmel_qspi_supports_op,
+ .exec_op = atmel_qspi_exec_op
+};
+
+static int atmel_qspi_probe(struct platform_device *pdev)
+{
+ struct spi_controller *ctrl;
+ struct atmel_qspi *aq;
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *child;
+ struct resource *res;
+ int irq, err = 0;
+
+ ctrl = spi_alloc_master(&pdev->dev, sizeof(*aq));
+ if (!ctrl)
+ return -ENOMEM;
+
+ ctrl->mode_bits = SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
+ ctrl->bus_num = -1;
+ ctrl->mem_ops = &atmel_qspi_mem_ops;
+ ctrl->num_chipselect = 1;
+ ctrl->dev.of_node = pdev->dev.of_node;
+ platform_set_drvdata(pdev, ctrl);
+
+ aq = spi_controller_get_devdata(ctrl);
+
+ if (of_get_child_count(np) != 1)
+ return -ENODEV;
+ child = of_get_next_child(np, NULL);
+
+ aq->pdev = pdev;
+
+ /* map registers */
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "qspi_base");
+ aq->iobase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(aq->iobase)) {
+ dev_err(&pdev->dev, "missing registers\n");
+ err = PTR_ERR(aq->iobase);
+ goto err_put_ctrl;
+ }
+
+ /* map AHB memory */
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "qspi_mmap");
+ aq->ahb_addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(aq->ahb_addr)) {
+ dev_err(&pdev->dev, "missing AHB memory\n");
+ err = PTR_ERR(aq->ahb_addr);
+ goto err_put_ctrl;
+ }
+
+ /* get peripheral clock */
+ aq->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(aq->clk)) {
+ dev_err(&pdev->dev, "missing peripheral clock\n");
+ err = PTR_ERR(aq->clk);
+ goto err_put_ctrl;
+ }
+
+ err = clk_prepare_enable(aq->clk);
+ if (err) {
+ dev_err(&pdev->dev, "failed to enable peripheral clock\n");
+ goto err_put_ctrl;
+ }
+
+ /* request IRQ */
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "missing IRQ\n");
+ err = irq;
+ goto disable_clk;
+ }
+ err = devm_request_irq(&pdev->dev, irq, atmel_qspi_interrupt, 0,
+ dev_name(&pdev->dev), ctrl);
+ if (err)
+ goto disable_clk;
+
+ err = of_property_read_u32(child, "spi-max-frequency", &aq->clk_rate);
+ if (err < 0)
+ goto disable_clk;
+
+ init_completion(&aq->cmd_done);
+
+ err = atmel_qspi_init(aq);
+ if (err)
+ goto disable_clk;
+
+ of_node_put(child);
+
+ err = spi_register_controller(ctrl);
+ if (err)
+ goto disable_clk;
+
+ return 0;
+
+disable_clk:
+ clk_disable_unprepare(aq->clk);
+err_put_ctrl:
+ spi_controller_put(ctrl);
+ of_node_put(child);
+ return err;
+}
+
+static int atmel_qspi_remove(struct platform_device *pdev)
+{
+ struct spi_controller *ctrl = platform_get_drvdata(pdev);
+ struct atmel_qspi *aq = spi_controller_get_devdata(ctrl);
+
+ qspi_writel(aq, QSPI_CR, QSPI_CR_QSPIDIS);
+ clk_disable_unprepare(aq->clk);
+
+ spi_unregister_controller(ctrl);
+
+ return 0;
+}
+
+static const struct of_device_id atmel_qspi_dt_ids[] = {
+ {
+ .compatible = "atmel,sama5d2-spi-qspi"
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, atmel_qspi_dt_ids);
+
+static struct platform_driver atmel_qspi_driver = {
+ .driver = {
+ .name = "atmel_spi_qspi",
+ .of_match_table = atmel_qspi_dt_ids
+ },
+ .probe = atmel_qspi_probe,
+ .remove = atmel_qspi_remove
+};
+
+module_platform_driver(atmel_qspi_driver);
+
+
+MODULE_DESCRIPTION("Atmel SAMA5D2 QuadSPI Driver");
+MODULE_AUTHOR("Piotr Bugalski <pbu@cryptera.com");
+MODULE_LICENSE("GPL v2");
+
--
2.11.0
^ permalink raw reply related
* [RFC PATCH 2/2] dt-bindings: spi: QuadSPI driver for Atmel SAMA5D2 documentation
From: Piotr Bugalski @ 2018-06-18 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618162124.21749-1-bugalski.piotr@gmail.com>
Documentation for DT-binding change.
Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Piotr Bugalski <pbu@cryptera.com>
---
.../devicetree/bindings/spi/spi_atmel-qspi.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
diff --git a/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt b/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
new file mode 100644
index 000000000000..d52b534c9c2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
@@ -0,0 +1,41 @@
+* Atmel Quad Serial Peripheral Interface (QSPI)
+
+Required properties:
+- compatible: Should be "atmel,sama5d2-spi-qspi".
+- reg: Should contain the locations and lengths of the base registers
+ and the mapped memory.
+- reg-names: Should contain the resource reg names:
+ - qspi_base: configuration register address space
+ - qspi_mmap: memory mapped address space
+- interrupts: Should contain the interrupt for the device.
+- clocks: The phandle of the clock needed by the QSPI controller.
+- #address-cells: Should be <1>.
+- #size-cells: Should be <0>.
+
+Example:
+
+qspi1: spi at f0024000 {
+ compatible = "atmel,sama5d2-spi-qspi";
+ reg = <0xf0024000 0x100>, <0xd8000000 0x08000000>;
+ reg-names = "qspi_base", "qspi_mmap";
+ interrupts = <53 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <&qspi1_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi1_default>;
+ status = "okay";
+
+ flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "winbond,w25m02gv", "spi-nand";
+ reg = <0>;
+ spi-max-frequency = <83000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+
+ ...
+ };
+};
+
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: dts: imx6: RIoTboard Add chosen stdout-path property
From: Emmanuel Vadot @ 2018-06-18 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529337797.7211.4.camel@pengutronix.de>
On Mon, 18 Jun 2018 18:03:17 +0200
Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Montag, den 18.06.2018, 17:42 +0200 schrieb Emmanuel Vadot:
> > The RIoTboard debug uart is connected to serial1.
> > Add a chosen property in the DTS so OS knows what serial port to use for
> > the console.
> >
> > > Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
> > ---
> > ?arch/arm/boot/dts/imx6dl-riotboard.dts | 4 ++++
> > ?1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts
> > index 2e98c92adff7..315d2ae6fa45 100644
> > --- a/arch/arm/boot/dts/imx6dl-riotboard.dts
> > +++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
> > @@ -19,6 +19,10 @@
> > > ? reg = <0x10000000 0x40000000>;
> > > ? };
> > ?
> > > + chosen {
> > + stdout-path = "serial1:115200n8";
>
> If there a reason to deviate from the "stdout-path = &uart1;" notation
> used by other i.MX boards?
>
> Regards,
> Lucas
This is, AFAIK, the proper way to specify the stdout-path.
See
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/chosen.txt#L31
Cheers,
> > + };
> > +
> > > ? regulators {
> > > ? compatible = "simple-bus";
> > > ? #address-cells = <1>;
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH] ARM: dts: imx7d-sdb: Remove duplicate regulator-can2-3v3
From: Fabio Estevam @ 2018-06-18 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <abacbb7485b0c9b908eae8ae87be9d8e0eab87b3.1529327283.git.leonard.crestez@nxp.com>
On Mon, Jun 18, 2018 at 10:11 AM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> Two different regulators are defined with the same name and label but
> distinct properties.
>
> The first definition was added with the first board dts and the second
> was added when upstream added flexcan support.
>
> Looking at schematics it is indeed gpio2 14 connected to the STB pin of
> the CAN transceiver so remove the first definition.
>
> The second definition entirely overrides the first so this already
> worked and this patch results in no DTB change, just a cleanup.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: NSP: Fix i2c controller interrupt type
From: Florian Fainelli @ 2018-06-18 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611224714.7007-2-f.fainelli@gmail.com>
On Mon, 11 Jun 2018 15:47:12 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> The i2c controller should use IRQ_TYPE_LEVEL_HIGH instead of
> IRQ_TYPE_NONE.
>
> Fixes: 0f9f27a36d09 ("ARM: dts: NSP: Add I2C support to the DT")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
Applied to devicetree/fixes, thanks!
--
Florian
^ permalink raw reply
* [PATCH 2/3] ARM: dts: NSP: Fix PCIe controllers interrupt types
From: Florian Fainelli @ 2018-06-18 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611224714.7007-3-f.fainelli@gmail.com>
On Mon, 11 Jun 2018 15:47:13 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> The interrupts for the PCIe controllers should all be of type
> IRQ_TYPE_LEVEL_HIGH instead of IRQ_TYPE_NONE.
>
> Fixes: d71eb9412088 ("ARM: dts: NSP: Add MSI support on PCI")
> Fixes: 522199029fdc ("ARM: dts: NSP: Fix PCIE DT issue")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
Applied to devicetree/fixes, thanks!
--
Florian
^ permalink raw reply
* [PATCH 3/3] ARM: dts: HR2: Fix interrupt types for i2c and PCIe
From: Florian Fainelli @ 2018-06-18 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611224714.7007-4-f.fainelli@gmail.com>
On Mon, 11 Jun 2018 15:47:14 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> The i2c and PCIe controllers had an incorrect type which should have
> been set to IRQ_TYPE_LEVEL_HIGH, fix that.
>
> Fixes: b9099ec754b5 ("ARM: dts: Add Broadcom Hurricane 2 DTS include file")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
Applied to devicetree/fixes, thanks!
--
Florian
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301x: Fix i2c controller interrupt type
From: Florian Fainelli @ 2018-06-18 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611225340.12733-1-f.fainelli@gmail.com>
On Mon, 11 Jun 2018 15:53:40 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> The i2c controller should be using IRQ_TYPE_LEVEL_HIGH, fix that.
>
> Fixes: bb097e3e0045 ("ARM: dts: BCM5301X: Add I2C support to the DT")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
Applied to devicetree/fixes, thanks!
--
Florian
^ permalink raw reply
* [PATCH 0/5] Fix Cygnus, NS2, Stingray interrupt type
From: Florian Fainelli @ 2018-06-18 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
On 06/12/2018 01:21 PM, Ray Jui wrote:
> This patch series fixes incorrect interrupt types for I2C and PCIe in DT
> for Broadcom Cygnus, NS2, and Stingray SoCs
>
> This patch series is based off v4.17 and is available on GIHUB:
> repo: https://github.com/Broadcom/arm64-linux.git
> branch: cygnus-ns2-dt-irq-type-fix-v1
Series applied to:
- 1&2: devicetree/fixes
- 3-5: devicetree-arm64/fixes
Thanks Ray.
--
Florian
^ permalink raw reply
* [PATCH] arm64: make secondary_start_kernel() notrace
From: Catalin Marinas @ 2018-06-18 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528794457-14129-1-git-send-email-zhizhouzhang@asrmicro.com>
On Tue, Jun 12, 2018 at 05:07:37PM +0800, Zhizhou Zhang wrote:
> We can't call function trace hook before setup percpu offset.
> When entering secondary_start_kernel(), percpu offset has not
> been initialized. So this lead hotplug malfunction.
> Here is the flow to reproduce this bug:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo function > /sys/kernel/debug/tracing/current_tracer
> echo 1 > /sys/kernel/debug/tracing/tracing_on
> echo 1 > /sys/devices/system/cpu/cpu1/online
>
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v3] ARM: dts: BCM5301X: Add support for Linksys EA9500
From: Vivek Unune @ 2018-06-18 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180222223844.98527-1-npcomplete13@gmail.com>
Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external BCM53125
DDR3 RAM - 256 MB
Flash - 128 MB (Toshiba TC58BVG0S3HTA00)
2.4GHz - BCM4366 4?4 2.4/5G single chip 802.11ac SoC
Power Amp - Skyworks SE2623L 2.4 GHz power amp (x4)
5GHz x 2 - BCM4366 4?4 2.4/5G single chip 802.11ac SoC
Power Amp - PLX Technology PEX8603 3-lane, 3-port PCIe switch
Ports - 8 Ports, 1 WAN Ports
Antennas - 8 Antennas
Serial Port - @J6 [GND,TX,RX] (VCC NC) 115200 8n1
Tested with OpenWrt built with DSA driver and Kernel v4.14
Signed-off-by: Vivek Unune <npcomplete13@gmail.com>
---
Changes in v3:
- Remove unnecessary change to BCH settings
- Remove ports 5 & 7 from internal switch for now
Changes in v2:
- Properly define mdio mux, internal mdio, external mdio, mii bus
- Now we define usb3 phy as a mdio node connected to internal mdio,
thanks to work done by Rafa? Mi?ecki on the bcm usb3 phy mdio driver
- Define external SW as a mdio-mii node connected to external mdio
---
arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 225 ++++++++++++++++++++++++
1 file changed, 225 insertions(+)
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index 1b26f0be2382..f4f40fd7fbe5 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -31,6 +31,231 @@
linux,code = <KEY_WPS_BUTTON>;
gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
};
+
+ rfkill {
+ label = "WiFi";
+ linux,code = <KEY_RFKILL>;
+ gpios = <&chipcommon 16 GPIO_ACTIVE_LOW>;
+ };
+
+ reset {
+ label = "Reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&chipcommon 17 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ wps {
+ label = "bcm53xx:white:wps";
+ gpios = <&chipcommon 22 GPIO_ACTIVE_LOW>;
+ };
+
+ usb2 {
+ label = "bcm53xx:green:usb2";
+ gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&ohci_port2>, <&ehci_port2>;
+ linux,default-trigger = "usbport";
+ };
+
+ usb3 {
+ label = "bcm53xx:green:usb3";
+ gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&ohci_port1>, <&ehci_port1>,
+ <&xhci_port1>;
+ linux,default-trigger = "usbport";
+ };
+
+ power {
+ label = "bcm53xx:white:power";
+ gpios = <&chipcommon 4 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi-disabled {
+ label = "bcm53xx:amber:wifi-disabled";
+ gpios = <&chipcommon 0 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi-enabled {
+ label = "bcm53xx:white:wifi-enabled";
+ gpios = <&chipcommon 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar1 {
+ label = "bcm53xx:white:bluebar1";
+ gpios = <&chipcommon 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar2 {
+ label = "bcm53xx:white:bluebar2";
+ gpios = <&chipcommon 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar3 {
+ label = "bcm53xx:white:bluebar3";
+ gpios = <&chipcommon 15 GPIO_ACTIVE_LOW>;
+ };
+
+ bluebar4 {
+ label = "bcm53xx:white:bluebar4";
+ gpios = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar5 {
+ label = "bcm53xx:white:bluebar5";
+ gpios = <&chipcommon 19 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar6 {
+ label = "bcm53xx:white:bluebar6";
+ gpios = <&chipcommon 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar7 {
+ label = "bcm53xx:white:bluebar7";
+ gpios = <&chipcommon 21 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar8 {
+ label = "bcm53xx:white:bluebar8";
+ gpios = <&chipcommon 8 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ mdio-bus-mux {
+ mdio_ext: mdio at 200 { /* BIT(9) = 1 => external mdio */
+ reg = <0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ mdio-mii-mux {
+ compatible = "mdio-mux-mmioreg";
+ mdio-parent-bus = <&mdio_ext>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1800c1c0 0x4>;
+ mux-mask = <0xc0>; /* BIT(6) = mdc, BIT(7) = mdio */
+
+ mdio-mii at 0 {
+ reg = <0x0>; /* Enable mii function */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch at 0 {
+ compatible = "brcm,bcm53125";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
+ reset-names = "robo_reset";
+ reg = <0>;
+ dsa,member = <1 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port at 1 {
+ reg = <1>;
+ label = "lan5";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan6";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "lan3";
+ };
+
+ sw1_p8: port at 8 {
+ reg = <8>;
+ ethernet = <&sw0_p0>;
+ label = "cpu";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ };
+ };
+};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 14 GPIO_ACTIVE_HIGH>;
+};
+
+&srab {
+ compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
+ status = "okay";
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 1 {
+ reg = <1>;
+ label = "lan7";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan4";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan8";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port at 8 {
+ reg = <8>;
+ ethernet = <&gmac2>;
+ label = "cpu";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ sw0_p0: port at 0 {
+ reg = <0>;
+ label = "extsw";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: exynos: Remove leading 0x from unit addresses in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 17:42 UTC (permalink / raw)
To: linux-arm-kernel
Remove leading 0x from recently introduced unit addresses to fix DTC
warnings:
Warning (unit_address_format): /soc/sysmmu at 0x15040000: unit name should not have leading "0x"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 038c99792ccb..3a9b4c4b9c63 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1171,7 +1171,7 @@
power-domains = <&pd_gscl>;
};
- sysmmu_scaler_0: sysmmu at 0x15040000 {
+ sysmmu_scaler_0: sysmmu at 15040000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x15040000 0x1000>;
interrupts = <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>;
@@ -1182,7 +1182,7 @@
power-domains = <&pd_mscl>;
};
- sysmmu_scaler_1: sysmmu at 0x15050000 {
+ sysmmu_scaler_1: sysmmu at 15050000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x15050000 0x1000>;
interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
--
2.14.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-1-krzk@kernel.org>
The decon, decon_tv and dsi nodes have only one child port so
address/size mappings are not necessary. This fixes DTC warnings like:
Warning (graph_child_address): /soc/decon at 13800000/ports:
graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 +-----
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 ++----------
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e3194b7483..0a15ee513f5c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -321,11 +321,7 @@
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
tv_to_hdmi: endpoint {
remote-endpoint = <&hdmi_to_tv>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 3a9b4c4b9c63..e4367fd39120 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -850,11 +850,7 @@
iommu-names = "m0", "m1";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
decon_to_mic: endpoint {
remote-endpoint =
<&mic_to_decon>;
@@ -914,11 +910,7 @@
#size-cells = <0>;
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
dsi_to_mic: endpoint {
remote-endpoint = <&mic_to_dsi>;
};
--
2.14.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: exynos: Remove leading 0x from unit addresses in Exynos5433
From: Joe Perches @ 2018-06-18 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-1-krzk@kernel.org>
On Mon, 2018-06-18 at 19:42 +0200, Krzysztof Kozlowski wrote:
> Remove leading 0x from recently introduced unit addresses to fix DTC
> warnings:
>
> Warning (unit_address_format): /soc/sysmmu at 0x15040000: unit name should not have leading "0x"
[]
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
[]
> @@ -1171,7 +1171,7 @@
> power-domains = <&pd_gscl>;
> };
>
> - sysmmu_scaler_0: sysmmu at 0x15040000 {
> + sysmmu_scaler_0: sysmmu at 15040000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x15040000 0x1000>;
> interrupts = <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1182,7 +1182,7 @@
> power-domains = <&pd_mscl>;
> };
>
> - sysmmu_scaler_1: sysmmu at 0x15050000 {
> + sysmmu_scaler_1: sysmmu at 15050000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x15050000 0x1000>;
> interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
Presumably these 3 other entries too?
$ git grep -P "\b\w+:\s+\w+ at 0x" -- "*.dt*"
arch/arc/boot/dts/abilis_tb10x.dtsi: spi0: spi at 0xFE010000 {
arch/arc/boot/dts/abilis_tb10x.dtsi: spi1: spi at 0xFE011000 {
arch/arc/boot/dts/vdk_axs10x_mb.dtsi: uio_ev: uio at 0xD0000000 {
arch/arm64/boot/dts/exynos/exynos5433.dtsi: sysmmu_scaler_0: sysmmu at 0x15040000 {
arch/arm64/boot/dts/exynos/exynos5433.dtsi: sysmmu_scaler_1: sysmmu at 0x15050000 {
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Geoff Levand @ 2018-06-18 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5b03f754-3a98-c01d-3e2a-615a8b1ea537@arm.com>
Hi James,
Thanks for all the comments, but my lack of access to an m400 platform, and
my lack of knowledge about the m400 limits what I can comment on and what I
can do.
My motivation for submitting this fix was to enable CONFIG_ACPI_APEI in the
Debian 10 kernel (for the new Cavium ThunderX2 based systems). The Debian
maintainers wanted to either have an upstream kernel fix for this m400 APEI
problem or to disable CONFIG_ACPI_APEI. The later would be unfortunate. It
means users would need to have custom kernels to get APEI support or go
without.
Comments follow.
On 06/18/2018 09:18 AM, James Morse wrote:
> On 15/06/18 18:17, Geoff Levand wrote:
>
> From:
> https://bugzilla.redhat.com/show_bug.cgi?id=1574718
>
> This is tripped by the ghes_probe() call, it finds an error has already occurred
> before ghes code is initialized.
>
> Does this still happen if you compile without CONFIG_PCI? (that is easily half
> the dmesg that has happened before this point).
> Disabling CONFIG_EFIVAR_FS would be interesting too, as that is firmware-code we
> can't fix bugs in.
Sorry, no m400 to test these on, but looking at the code, I would say it doesn't
occur if CONFIG_PCI=n.
> Your argument here is the that the firmware-vendor only build-tested their code,
> and never noticed it notifies a fatal exception on startup. I find this hard to
> believe, especially as these systems don't have EL3.
>
> It's much more likely a driver is causing this, possibly because of bad data in
> the firmware tables. I'd like to quirk the driver, so we can fix the next error
> like this, as opposed to blindly continuing.
That sounds OK, but which driver?
> If it really is firmware, what is it doing that causes this error, and where
> does it run? Disabling APEI is just reacting after the error has occurred, when
> we could prevent it happening.
>
> I can't reproduce this on a Mustang. I assume its the different ACPI tables, not
> the kernel-config.
>From what I understand this is only on the m400, not the Mustang.
>> I just put together this patch to unify things and have a
>> common 'upstream' fix.
>
> Wouldn't passing 'hest_disable' on the cmdline do the same for all kernel versions?
Yes, the current patch essentially just sets hest_disable when an m400 is
detected. The cmdline work-around is what some have been using, but is
not an acceptable solution for the Debian maintainers. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900581
>> On 06/15/2018 04:14 AM, James Morse wrote:
>>> On 13/06/18 19:22, Geoff Levand wrote:
>>>> Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
>>>> a work-around for HPE ProLiant m400 APEI firmware problems.
>>>>
>>>> The work-around disables APEI when CONFIG_ACPI_APEI is set and
>>>> m400 firmware is detected. Without this fixup m400 systems
>>>> experience errors like these on startup:
>>>>
>>>> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
>>>> [Hardware Error]: event severity: fatal
>>>> [Hardware Error]: Error 0, type: fatal
>>>> [Hardware Error]: section_type: memory error
>>>> [Hardware Error]: error_status: 0x0000000000001300
>>>
>>> "Access to a memory address which is not mapped to any component"
>>>
>>>
>>>> [Hardware Error]: error_type: 10, invalid address
>>>> Kernel panic - not syncing: Fatal hardware error!
>>>
>>> Why is this a problem?
>>>
>>> Surely this is a valid description of an error.
>>
>> The firmware bug causes this failure, not bad hardware.
>
> I'm not talking about bad hardware here. What I think is happening is a software
> bug is causing the CPU to make a bad access, which the RAS mechanism is
> reporting like this because software would never be stupid enough to access an
> address which is not mapped to any component! The RAS stuff believes this must
> be address corruption.
>
> I think this is a linux-driver bug, or a typo in the firmware tables, that cause
> $non_existent_address to be mapped and probed.
>From what I know about it the problem is in the access of the firmware tables,
and that corrupted data is retrieved. But I am not sure, as there are so many
reported m400 firmware problems it is hard to tell what exactly is what.
>>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>>> index 7b09487ff8fb..3c315c2c7476 100644
>>>> --- a/arch/arm64/kernel/acpi.c
>>>> +++ b/arch/arm64/kernel/acpi.c
>
>>>> +
>>>> + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
>>>> + return;
>>>> +
>>>> + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
>>>> +
>>>> + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
>>>> + !strncmp(header->oem_table_id, "ProLiant", 8) &&
>
>>> You should match the affected range of OEM table revisions too, that way a
>>> firmware upgrade should start working, instead of being permanently disabled
>>> because we think its unlikely.
>>
>> The m400 has reached end of life. No one really expects to see any firmware
>> update. I don't know what the effected OEM table revisions are, and I don't
>> think there is an active platform maintainer who could give that info either.
>>
>> If someone can provide the info. I'll update the fix.
>
> We can start with the version you have. You mention distro's have their own
> fixes, hopefully they can supply the missing range of values.
It seems you are living in a dream world...
>>>> + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
>>>
>>> How is the CPU implementer relevant?
>>
>> That was just a copy of what other fixes had. Should I remove it?
>
> The conclusion in the rest of this thread was HPE also produces ProLiant boxes
> with a (presumably) identical HEST, but a totally different architecture.
>
> Matching the DMI platform name as well would work round this. (or somewhere only
> arm64 builds, with an appropriate comment in case we move it).
>
>
>>> Nothing arch-specific here. You're adding this to arch/arm64 because
>>> drivers/acpi/apei doesn't have an existing quirks table?
>>
>> There was a fix submitted that had it in drivers/acpi/scan.c, but the
>> ACPI maintainer said he didn't want the fix in the main ACPI code.
>
> Specifically about a HID-hack in the core device enumeration code, as opposed to
> in the driver that claims it.
>
>
>> See:
>>
>> https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression related to X-Gene UARTs)
>
> | 'some X-Gene based platforms (Mustang and M400) with invalid DSDT.'
>
> ... sounds familiar ...
>
> And:
> https://bugzilla.redhat.com/attachment.cgi?id=1144903&action=diff
>
> Fixes a typo in firmware description of the GIC.
>
> Why do we think this is a new kind of firmware bug, and not a repeat of the last
> two? The only difference is this is being caught by the RAS code.
It could very well be.
>> The m400 is an arm64 platform, so it seems most appropriate to
>> have it in arch/arm64/kernel/acpi.c.
>
> We don't keep all drivers under arch/arm64, I'd really like to find the driver
> that is causing this, and quirk it there.
>
> If we have to bolt the hest-stable-door, drivers/acpi/apei/hest.c looks better,
> it at least doesn't have to bodge around hest_disabled not being exposed in a
> compatible way. If the maintainer objects, (as x86 hasn't had to do this yet),
> then we can try drivers/acpi/arm64/hest_quirks.c.
We need to call acpi_fixup_m400_quirks early enough to get hest_disable set
before it is used. To do that from drivers/acpi/ code we would need have
it as arch_initcall, or still call it from acpi_boot_table_init. I think
having it as a static routine and the call in arch/arm64/kernel/acpi.c is
cleaner.
> When only once architecture had to quirk stuff based on the ACPI tables, the
> arch-code was a suitable dumping ground. Now there is more than one, we should
> do things in a way they are useful to both architectures.
As I mentioned in the opening, I don't have access to m400 equipment. There is
little I can do. I could move acpi_fixup_m400_quirks into
drivers/acpi/apei/hest.c and submit that to the ACPI maintainer, but based on
https://lkml.org/lkml/2018/4/19/1020, I don't think it would be accepted.
-Geoff
^ permalink raw reply
* [PATCH] arm64: dts: hikey960: Remove deprecated MMC properties
From: Ryan Grachek @ 2018-06-18 18:08 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Ryan Grachek <ryan@edited.us>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 -
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 --------
2 files changed, 9 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index c706f70ce9f2..abc991619c75 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -611,7 +611,6 @@
broken-cd;
/* WL_EN */
vmmc-supply = <&wlan_en>;
- ti,non-removable;
non-removable;
cap-power-off-card;
keep-power-in-suspend;
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 484b837757f3..74c0509f99e9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -1121,7 +1121,6 @@
bus-width = <0x4>;
disable-wp;
cap-sd-highspeed;
- supports-highspeed;
card-detect-delay = <200>;
reg = <0x0 0xff37f000 0x0 0x1000>;
interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
@@ -1142,12 +1141,6 @@
sd-uhs-sdr50;
sd-uhs-sdr104;
status = "disabled";
-
- slot at 0 {
- reg = <0x0>;
- bus-width = <4>;
- disable-wp;
- };
};
/* SDIO */
@@ -1162,7 +1155,6 @@
reset-names = "reset";
card-detect-delay = <200>;
cap-sd-highspeed;
- supports-highspeed;
keep-power-in-suspend;
pinctrl-names = "default";
pinctrl-0 = <&sdio_pmx_func
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: dts: hikey960: Clean up MMC properties and move to proper file
From: Ryan Grachek @ 2018-06-18 18:10 UTC (permalink / raw)
To: linux-arm-kernel
Certain properties should be moved to the board file to reflect
the specific properties of the board, and not the SoC. Move these
properties to proper location and organize properties in both files.
Signed-off-by: Ryan Grachek <ryan@edited.us>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 27 ++++++++++++++++++-----
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 27 +++++------------------
2 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index abc991619c75..1c2a9a5d0477 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -602,20 +602,37 @@
};
&dwmmc1 {
+ bus-width = <0x4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ disable-wp;
+ cd-inverted;
+ cd-gpios = <&gpio25 3 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd_pmx_func
+ &sd_clk_cfg_func
+ &sd_cfg_func>;
vmmc-supply = <&ldo16>;
vqmmc-supply = <&ldo9>;
status = "okay";
};
&dwmmc2 { /* WIFI */
- broken-cd;
- /* WL_EN */
- vmmc-supply = <&wlan_en>;
+ bus-width = <0x4>;
non-removable;
+ broken-cd;
+ cap-sd-highspeed;
cap-power-off-card;
keep-power-in-suspend;
- #address-cells = <0x1>;
- #size-cells = <0x0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio_pmx_func
+ &sdio_clk_cfg_func
+ &sdio_cfg_func>;
+ /* WL_EN */
+ vmmc-supply = <&wlan_en>;
status = "ok";
wlcore: wlcore at 2 {
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 74c0509f99e9..fe4c9f321b70 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -1114,15 +1114,10 @@
/* SD */
dwmmc1: dwmmc1 at ff37f000 {
- #address-cells = <1>;
- #size-cells = <0>;
- cd-inverted;
compatible = "hisilicon,hi3660-dw-mshc";
- bus-width = <0x4>;
- disable-wp;
- cap-sd-highspeed;
- card-detect-delay = <200>;
reg = <0x0 0xff37f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&crg_ctrl HI3660_CLK_GATE_SD>,
<&crg_ctrl HI3660_HCLK_GATE_SD>;
@@ -1130,16 +1125,8 @@
clock-frequency = <3200000>;
resets = <&crg_rst 0x94 18>;
reset-names = "reset";
- cd-gpios = <&gpio25 3 0>;
hisilicon,peripheral-syscon = <&sctrl>;
- pinctrl-names = "default";
- pinctrl-0 = <&sd_pmx_func
- &sd_clk_cfg_func
- &sd_cfg_func>;
- sd-uhs-sdr12;
- sd-uhs-sdr25;
- sd-uhs-sdr50;
- sd-uhs-sdr104;
+ card-detect-delay = <200>;
status = "disabled";
};
@@ -1147,6 +1134,8 @@
dwmmc2: dwmmc2 at ff3ff000 {
compatible = "hisilicon,hi3660-dw-mshc";
reg = <0x0 0xff3ff000 0x0 0x1000>;
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&crg_ctrl HI3660_CLK_GATE_SDIO0>,
<&crg_ctrl HI3660_HCLK_GATE_SDIO0>;
@@ -1154,12 +1143,6 @@
resets = <&crg_rst 0x94 20>;
reset-names = "reset";
card-detect-delay = <200>;
- cap-sd-highspeed;
- keep-power-in-suspend;
- pinctrl-names = "default";
- pinctrl-0 = <&sdio_pmx_func
- &sdio_clk_cfg_func
- &sdio_cfg_func>;
status = "disabled";
};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-2-krzk@kernel.org>
On Mon, Jun 18, 2018 at 07:42:16PM +0200, Krzysztof Kozlowski wrote:
> The decon, decon_tv and dsi nodes have only one child port so
> address/size mappings are not necessary. This fixes DTC warnings like:
>
> Warning (graph_child_address): /soc/decon at 13800000/ports:
> graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 +-----
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 ++----------
> 2 files changed, 3 insertions(+), 15 deletions(-)
The patch 1/2 should not have any impact but this one could have and I forgot
to mention that it was not tested. If someone could provide testing, it
would be highly appreciated.
Best regards,
Krzysztof
^ permalink raw reply
* [U-Boot] [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
From: Tom Rini @ 2018-06-18 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
On Tue, Jun 12, 2018 at 03:24:07PM -0500, Nishanth Menon wrote:
> Hi,
>
> This is a follow on from https://marc.info/?l=u-boot&m=151691688828176&w=2 (RFC)
>
> NOTE:
> * As per ARM recommendations[2], and discussions in list[1] ARM
> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> OS level workarounds.
> * This itself is'nt a complete solution and is based on recommendation
> This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on
> linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag).
> * I think it is necessary on older SoCs without firmware support
> (such as older OMAPs and AM*) to have kernel support mirroring what we do in
> u-boot to support additional cores AND/OR low power states where contexts are
> lost (assuming ACR states are'nt saved). just my 2 cents.
>
> Few of the tests (with linux next-20180612):
> AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15)
> OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15)
> OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8)
> AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8)
>
> Nishanth Menon (4):
> ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
> CVE-2017-5715
> ARM: Introduce ability to enable invalidate of BTB with ICIALLU on
> Cortex-A15 for CVE-2017-5715
> ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of
> BTB) to facilitate CVE_2017-5715 WA in OS
> ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for
> CVE-2017-5715
>
> arch/arm/Kconfig | 9 +++++++++
> arch/arm/cpu/armv7/start.S | 15 +++++++++++++--
> arch/arm/mach-omap2/Kconfig | 3 +++
> 3 files changed, 25 insertions(+), 2 deletions(-)
>
> [1] https://marc.info/?t=151639906500002&r=1&w=2
> [2] https://developer.arm.com/support/security-update
> [3] https://marc.info/?t=151543790400007&r=1&w=2 and the latest in:
> https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2
> [4]
> https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6
> https://www.op-tee.org/security-advisories/
> https://www.linaro.org/blog/meltdown-spectre/
This series of changes for U-Boot, if I can briefly summarize the
feedback as I understand it, is that yes, this is correct and is a part
of what is required to work around the issues, but only covers as much
of the system as U-Boot can cover leaving other parts of the software
stack (still) in need of fixes. Yes? If so, is there anything else
that should be done before in U-Boot we grab these changes? Would any
of the knowledgeable but not usually U-Boot folks on CC feel comfortable
adding an ack/reviewed-by to the series? Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/fbdc1526/attachment.sig>
^ permalink raw reply
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
From: Icenowy Zheng @ 2018-06-18 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15787507.kzqBcLUy0z@jernej-laptop>
? 2018-06-18?? 16:43 +0200?Jernej ?krabec???
> Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki
> napisal(a):
> > On Thu, Jun 14, 2018 at 10:59 PM, Jernej ?krabec
> >
> > <jernej.skrabec@siol.net> wrote:
> > > Dne ?etrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki
> > > napisal(a):
> > > > On Thu, Jun 14, 2018 at 8:04 PM, Jernej ?krabec <jernej.skrabec
> > > > @siol.net>
> > >
> > > wrote:
> > > > > Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki
> > > > > napisal(a):
> > > > > > On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> > > > > > <jernej.skrabec@siol.net>
> > > > >
> > > > > wrote:
> > > > > > > This series adds support for R40 HDMI pipeline. It is a
> > > > > > > bit special
> > > > > > > than other already supported pipelines because it has
> > > > > > > additional
> > > > > > > unit
> > > > > > > called TCON TOP responsible for relationship
> > > > > > > configuration between
> > > > > > > mixers, TCONs and HDMI. Additionally, it has additional
> > > > > > > gates for
> > > > > > > DSI
> > > > > > > and TV TCONs, TV encoder clock settings and pin muxing
> > > > > > > between LCD
> > > > > > > and TV encoders.
> > > > > > >
> > > > > > > However, it seems that TCON TOP will become a norm, since
> > > > > > > newer
> > > > > > > Allwinner SoCs like H6 also have this unit.
> > > > > > >
> > > > > > > I tested different possible configurations:
> > > > > > > - mixer0 <> TCON-TV0 <> HDMI
> > > > > > > - mixer0 <> TCON-TV1 <> HDMI
> > > > > > > - mixer1 <> TCON-TV0 <> HDMI
> > > > > > > - mixer1 <> TCON-TV1 <> HDMI
> > > > > > >
> > > > > > > Please review.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jernej
> > > > > > >
> > > > > > > Changes from v1:
> > > > > > > - Split DT bindings patch and updated description
> > > > > > > - Split HDMI PHY patch
> > > > > > > - Move header file from TCON TOP patch to dt bindings
> > > > > > > patch
> > > > > > > - Added Rob reviewed-by tag
> > > > > > > - Used clk_hw_register_gate() instead of custom gate
> > > > > > > registration
> > > > > > > code
> > > > > > > - Reworked TCON TOP to be part of of-graph. Because of
> > > > > > > that, a lot
> > > > > > > of
> > > > > > >
> > > > > > > new patches were added.
> > > > > > >
> > > > > > > - Droped mixer index quirk patch
> > > > > > > - Reworked TCON support for TCON TOP
> > > > > > > - Updated commit messages
> > > > > > >
> > > > > > > Jernej Skrabec (27):
> > > > > > > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> > > > > > > clk: sunxi-ng: r40: Allow setting parent rate to
> > > > > > > display related
> > > > > > >
> > > > > > > clocks
> > > > > > >
> > > > > > > clk: sunxi-ng: r40: Export video PLLs
> > > > > > > dt-bindings: display: sunxi-drm: Add TCON TOP
> > > > > > > description
> > > > > > > drm/sun4i: Add TCON TOP driver
> > > > > > > drm/sun4i: Fix releasing node when enumerating enpoints
> > > > > > > drm/sun4i: Split out code for enumerating endpoints in
> > > > > > > output port
> > > > > > > drm/sun4i: Add support for traversing graph with TCON
> > > > > > > TOP
> > > > > > > drm/sun4i: Don't skip TCONs if they don't have channel
> > > > > > > 0
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 TV TCON
> > > > > > > description
> > > > > > > drm/sun4i: tcon: Add support for tcon-top gate
> > > > > > > drm/sun4i: tcon: Generalize engine search algorithm
> > > > > > > drm/sun4i: Don't check for LVDS and RGB when TCON has
> > > > > > > only ch1
> > > > > > > drm/sun4i: Don't check for panel or bridge on TV TCONs
> > > > > > > drm/sun4i: Add support for R40 TV TCON
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 mixer
> > > > > > > compatibles
> > > > > > > drm/sun4i: Add support for R40 mixers
> > > > > > > dt-bindings: display: sun4i-drm: Add description of A64
> > > > > > > HDMI PHY
> > > > > > > drm/sun4i: Enable DW HDMI PHY clock
> > > > > > > drm/sun4i: Don't change clock bits in DW HDMI PHY
> > > > > > > driver
> > > > > > > drm/sun4i: DW HDMI PHY: Add support for second PLL
> > > > > > > drm/sun4i: Add support for second clock parent to DW
> > > > > > > HDMI PHY clk
> > > > > > >
> > > > > > > driver
> > > > > > >
> > > > > > > drm/sun4i: Add support for A64 HDMI PHY
> > > > > > > drm: of: Export drm_crtc_port_mask()
> > > > > > > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> > > > > > > ARM: dts: sun8i: r40: Add HDMI pipeline
> > > > > > > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2
> > > > > > > Ultra
> > > > > >
> > > > > > Tested whole series on top of linux-next.
> > > > > >
> > > > > > Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > >
> > > > > Thanks!
> > > >
> > > > I've V40 board, which is same as R40. I'm able to detect the
> > > > HDMI but
> > > > seems edid not detecting properly.
> > > >
> > > > [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer
> > > > (ops
> > > > 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound
> > > > 1200000.mixer
> > > > (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> > > > 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> > > > display-engine:
> > > > bound 1c73000.lcd-controller (ops 0xc0747a28)
> > > > [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX
> > > > controller
> > > > v1.32a with HDCP (sun8i_dw_hdmi_phy)
> > > > [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered
> > > > DesignWare HDMI
> > > > I2C bus driver
> > > > [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi
> > > > (ops
> > > > 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp
> > > > caching Rev 2
> > > > (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> > > > timestamp query. [ 1.091055] [drm] Cannot find any crtc or
> > > > sizes
> > > > [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> > > > display-engine on minor 0
> > >
> > > This seems like DT issue. Can you post somewhere your V40 DTSI
> > > (if it is
> > > different to R40) and board DTS?
> >
> > same dtsi shared between r40 and v40, here is board dts support for
> > HDMI[1]
> >
> > [1] https://paste.ubuntu.com/p/wqVz38BHrM/
>
> This patch looks like exactly the same as mine for BananaPi M2U, so
> there
> should be no issues.
As I know, M2B is designed to be compatible with M2U, so most things
should be the same. The stock firmware even use the same images for
both M2U and M2B.
>
> What about VCC-HDMI? Is powered? Can you measure it to check?
>
> Best regards,
> Jernej
>
>
>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: exynos: Remove leading 0x from unit addresses in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6755acb72649a712bd16cee4cab92f1aa63b70b9.camel@perches.com>
On 18 June 2018 at 19:57, Joe Perches <joe@perches.com> wrote:
> On Mon, 2018-06-18 at 19:42 +0200, Krzysztof Kozlowski wrote:
>> Remove leading 0x from recently introduced unit addresses to fix DTC
>> warnings:
>>
>> Warning (unit_address_format): /soc/sysmmu at 0x15040000: unit name should not have leading "0x"
> []
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> []
>> @@ -1171,7 +1171,7 @@
>> power-domains = <&pd_gscl>;
>> };
>>
>> - sysmmu_scaler_0: sysmmu at 0x15040000 {
>> + sysmmu_scaler_0: sysmmu at 15040000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x15040000 0x1000>;
>> interrupts = <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>;
>> @@ -1182,7 +1182,7 @@
>> power-domains = <&pd_mscl>;
>> };
>>
>> - sysmmu_scaler_1: sysmmu at 0x15050000 {
>> + sysmmu_scaler_1: sysmmu at 15050000 {
>> compatible = "samsung,exynos-sysmmu";
>> reg = <0x15050000 0x1000>;
>> interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
>
> Presumably these 3 other entries too?
>
> $ git grep -P "\b\w+:\s+\w+ at 0x" -- "*.dt*"
> arch/arc/boot/dts/abilis_tb10x.dtsi: spi0: spi at 0xFE010000 {
> arch/arc/boot/dts/abilis_tb10x.dtsi: spi1: spi at 0xFE011000 {
> arch/arc/boot/dts/vdk_axs10x_mb.dtsi: uio_ev: uio at 0xD0000000 {
True. That's an "arc" but I can fix it as well with your reported-by.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 06/14] mtd: rawnand: marvell: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-06-18 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3a2a8951-f380-af99-bf97-6ff722404410@zonque.org>
Daniel Mack <daniel@zonque.org> writes:
> On Sunday, June 17, 2018 07:02 PM, Robert Jarzmik wrote:
>> As the pxa architecture switched towards the dmaengine slave map, the
>> old compatibility mechanism to acquire the dma requestor line number and
>> priority are not needed anymore.
>>
>> This patch simplifies the dma resource acquisition, using the more
>> generic function dma_request_slave_channel().
>>
>> Signed-off-by: Signed-off-by: Daniel Mack <daniel@zonque.org>
>
> Something went wrong here, but you can simply fix that when applying the series
> :)
Indeed, fixed before applying to the pxa/for-next tree.
--
Robert
^ permalink raw reply
* [PATCH v4 16/19] media: platform: Add Sunxi-Cedrus VPU decoder driver
From: kbuild test robot @ 2018-06-18 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-17-paul.kocialkowski@bootlin.com>
Hi Paul,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.18-rc1 next-20180618]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Paul-Kocialkowski/Sunxi-Cedrus-driver-for-the-Allwinner-Video-Engine-using-media-requests/20180619-020757
base: git://linuxtv.org/media_tree.git master
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
drivers/media/platform/sunxi/cedrus/cedrus_video.c: In function 'cedrus_stop_streaming':
>> drivers/media/platform/sunxi/cedrus/cedrus_video.c:434:3: error: implicit declaration of function 'v4l2_ctrl_request_complete'; did you mean 'v4l2_ctrl_replace'? [-Werror=implicit-function-declaration]
v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
^~~~~~~~~~~~~~~~~~~~~~~~~~
v4l2_ctrl_replace
>> drivers/media/platform/sunxi/cedrus/cedrus_video.c:434:43: error: 'struct vb2_buffer' has no member named 'req_obj'
v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
^
drivers/media/platform/sunxi/cedrus/cedrus_video.c: In function 'cedrus_buf_request_complete':
drivers/media/platform/sunxi/cedrus/cedrus_video.c:452:31: error: 'struct vb2_buffer' has no member named 'req_obj'
v4l2_ctrl_request_complete(vb->req_obj.req, &ctx->hdl);
^~
drivers/media/platform/sunxi/cedrus/cedrus_video.c: At top level:
>> drivers/media/platform/sunxi/cedrus/cedrus_video.c:461:3: error: 'struct vb2_ops' has no member named 'buf_request_complete'
.buf_request_complete = cedrus_buf_request_complete,
^~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/sunxi/cedrus/cedrus_video.c:461:26: warning: excess elements in struct initializer
.buf_request_complete = cedrus_buf_request_complete,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/platform/sunxi/cedrus/cedrus_video.c:461:26: note: (near initialization for 'cedrus_qops')
cc1: some warnings being treated as errors
--
drivers/media/platform/sunxi/cedrus/cedrus_dec.c: In function 'cedrus_device_run':
>> drivers/media/platform/sunxi/cedrus/cedrus_dec.c:91:28: error: 'struct vb2_buffer' has no member named 'req_obj'
src_req = run.src->vb2_buf.req_obj.req;
^
>> drivers/media/platform/sunxi/cedrus/cedrus_dec.c:94:3: error: implicit declaration of function 'v4l2_ctrl_request_setup'; did you mean 'v4l2_ctrl_handler_setup'? [-Werror=implicit-function-declaration]
v4l2_ctrl_request_setup(src_req, &ctx->hdl);
^~~~~~~~~~~~~~~~~~~~~~~
v4l2_ctrl_handler_setup
>> drivers/media/platform/sunxi/cedrus/cedrus_dec.c:123:3: error: implicit declaration of function 'v4l2_ctrl_request_complete'; did you mean 'v4l2_ctrl_replace'? [-Werror=implicit-function-declaration]
v4l2_ctrl_request_complete(src_req, &ctx->hdl);
^~~~~~~~~~~~~~~~~~~~~~~~~~
v4l2_ctrl_replace
cc1: some warnings being treated as errors
vim +434 drivers/media/platform/sunxi/cedrus/cedrus_video.c
413
414 static void cedrus_stop_streaming(struct vb2_queue *q)
415 {
416 struct cedrus_ctx *ctx = vb2_get_drv_priv(q);
417 struct vb2_v4l2_buffer *vbuf;
418 unsigned long flags;
419
420 flush_scheduled_work();
421 for (;;) {
422 spin_lock_irqsave(&ctx->dev->irq_lock, flags);
423
424 if (V4L2_TYPE_IS_OUTPUT(q->type))
425 vbuf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
426 else
427 vbuf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
428
429 spin_unlock_irqrestore(&ctx->dev->irq_lock, flags);
430
431 if (vbuf == NULL)
432 return;
433
> 434 v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
435 &ctx->hdl);
436 v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
437 }
438 }
439
440 static void cedrus_buf_queue(struct vb2_buffer *vb)
441 {
442 struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
443 struct cedrus_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
444
445 v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
446 }
447
448 static void cedrus_buf_request_complete(struct vb2_buffer *vb)
449 {
450 struct cedrus_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
451
> 452 v4l2_ctrl_request_complete(vb->req_obj.req, &ctx->hdl);
453 }
454
455 static struct vb2_ops cedrus_qops = {
456 .queue_setup = cedrus_queue_setup,
457 .buf_prepare = cedrus_buf_prepare,
458 .buf_init = cedrus_buf_init,
459 .buf_cleanup = cedrus_buf_cleanup,
460 .buf_queue = cedrus_buf_queue,
> 461 .buf_request_complete = cedrus_buf_request_complete,
462 .stop_streaming = cedrus_stop_streaming,
463 .wait_prepare = vb2_ops_wait_prepare,
464 .wait_finish = vb2_ops_wait_finish,
465 };
466
---
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: 65280 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/c08b77c7/attachment-0001.gz>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: sdm845: Add rpmh-rsc node
From: Douglas Anderson @ 2018-06-18 20:56 UTC (permalink / raw)
To: linux-arm-kernel
This adds the rpmh-rsc node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cd308b84bed7..19b006293d3b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/qcom,rpmh-rsc.h>
/ {
interrupt-parent = <&intc>;
@@ -984,6 +985,24 @@
#mbox-cells = <1>;
};
+ apps_rsc: rsc at 179c0000 {
+ label = "apps_rsc";
+ compatible = "qcom,rpmh-rsc";
+ reg = <0x179c0000 0x10000>,
+ <0x179d0000 0x10000>,
+ <0x179e0000 0x10000>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = <SLEEP_TCS 3>,
+ <WAKE_TCS 3>,
+ <ACTIVE_TCS 2>,
+ <CONTROL_TCS 1>;
+ };
+
intc: interrupt-controller at 17a00000 {
compatible = "arm,gic-v3";
#address-cells = <1>;
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: sdm845: Add rpmh-clk node
From: Douglas Anderson @ 2018-06-18 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618205616.102750-1-dianders@chromium.org>
This adds the rpmh-clk node to sdm845 based on the examples in the
bindings.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
NOTE: to apply this patch cleanly, apply it atop:
arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
https://patchwork.kernel.org/patch/10462691/
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 19b006293d3b..c61ae815a697 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -6,6 +6,7 @@
*/
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
+#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
@@ -1001,6 +1002,11 @@
<WAKE_TCS 3>,
<ACTIVE_TCS 2>,
<CONTROL_TCS 1>;
+
+ rpmhcc: clock-controller {
+ compatible = "qcom,sdm845-rpmh-clk";
+ #clock-cells = <1>;
+ };
};
intc: interrupt-controller at 17a00000 {
--
2.18.0.rc1.244.gcf134e6275-goog
^ 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