* [PATCH v6 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-12-12 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-1-git-send-email-cedric.madianga@gmail.com>
This patch adds support for the STM32F4 I2C controller.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-stm32f4.c | 849 +++++++++++++++++++++++++++++++++++++++
3 files changed, 860 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-stm32f4.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 0cdc844..2719208 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -886,6 +886,16 @@ config I2C_ST
This driver can also be built as module. If so, the module
will be called i2c-st.
+config I2C_STM32F4
+ tristate "STMicroelectronics STM32F4 I2C support"
+ depends on ARCH_STM32 || COMPILE_TEST
+ help
+ Enable this option to add support for STM32 I2C controller embedded
+ in STM32F4 SoCs.
+
+ This driver can also be built as module. If so, the module
+ will be called i2c-stm32f4.
+
config I2C_STU300
tristate "ST Microelectronics DDC I2C interface"
depends on MACH_U300
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 1c1bac8..a2c6ff5 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o
obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o
obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o
obj-$(CONFIG_I2C_ST) += i2c-st.o
+obj-$(CONFIG_I2C_STM32F4) += i2c-stm32f4.o
obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o
obj-$(CONFIG_I2C_TEGRA) += i2c-tegra.o
diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
new file mode 100644
index 0000000..89ad579
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -0,0 +1,849 @@
+/*
+ * Driver for STMicroelectronics STM32 I2C controller
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2015
+ * Author: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR1 0x00
+#define STM32F4_I2C_CR2 0x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR1 0x14
+#define STM32F4_I2C_SR2 0x18
+#define STM32F4_I2C_CCR 0x1C
+#define STM32F4_I2C_TRISE 0x20
+#define STM32F4_I2C_FLTR 0x24
+
+/* STM32F4 I2C control 1*/
+#define STM32F4_I2C_CR1_SWRST BIT(15)
+#define STM32F4_I2C_CR1_POS BIT(11)
+#define STM32F4_I2C_CR1_ACK BIT(10)
+#define STM32F4_I2C_CR1_STOP BIT(9)
+#define STM32F4_I2C_CR1_START BIT(8)
+#define STM32F4_I2C_CR1_PE BIT(0)
+
+/* STM32F4 I2C control 2 */
+#define STM32F4_I2C_CR2_FREQ_MASK GENMASK(5, 0)
+#define STM32F4_I2C_CR2_FREQ(n) ((n & STM32F4_I2C_CR2_FREQ_MASK))
+#define STM32F4_I2C_CR2_ITBUFEN BIT(10)
+#define STM32F4_I2C_CR2_ITEVTEN BIT(9)
+#define STM32F4_I2C_CR2_ITERREN BIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK (STM32F4_I2C_CR2_ITBUFEN \
+ | STM32F4_I2C_CR2_ITEVTEN \
+ | STM32F4_I2C_CR2_ITERREN)
+
+/* STM32F4 I2C Status 1 */
+#define STM32F4_I2C_SR1_AF BIT(10)
+#define STM32F4_I2C_SR1_ARLO BIT(9)
+#define STM32F4_I2C_SR1_BERR BIT(8)
+#define STM32F4_I2C_SR1_TXE BIT(7)
+#define STM32F4_I2C_SR1_RXNE BIT(6)
+#define STM32F4_I2C_SR1_BTF BIT(2)
+#define STM32F4_I2C_SR1_ADDR BIT(1)
+#define STM32F4_I2C_SR1_SB BIT(0)
+#define STM32F4_I2C_SR1_ITEVTEN_MASK (STM32F4_I2C_SR1_BTF \
+ | STM32F4_I2C_SR1_ADDR \
+ | STM32F4_I2C_SR1_SB)
+#define STM32F4_I2C_SR1_ITBUFEN_MASK (STM32F4_I2C_SR1_TXE \
+ | STM32F4_I2C_SR1_RXNE)
+#define STM32F4_I2C_SR1_ITERREN_MASK (STM32F4_I2C_SR1_AF \
+ | STM32F4_I2C_SR1_ARLO \
+ | STM32F4_I2C_SR1_BERR)
+
+/* STM32F4 I2C Status 2 */
+#define STM32F4_I2C_SR2_BUSY BIT(1)
+
+/* STM32F4 I2C Control Clock */
+#define STM32F4_I2C_CCR_CCR_MASK GENMASK(11, 0)
+#define STM32F4_I2C_CCR_CCR(n) ((n & STM32F4_I2C_CCR_CCR_MASK))
+#define STM32F4_I2C_CCR_FS BIT(15)
+#define STM32F4_I2C_CCR_DUTY BIT(14)
+
+/* STM32F4 I2C Trise */
+#define STM32F4_I2C_TRISE_VALUE_MASK GENMASK(5, 0)
+#define STM32F4_I2C_TRISE_VALUE(n) ((n & STM32F4_I2C_TRISE_VALUE_MASK))
+
+/* STM32F4 I2C Filter */
+#define STM32F4_I2C_FLTR_DNF_MASK GENMASK(3, 0)
+#define STM32F4_I2C_FLTR_DNF(n) ((n & STM32F4_I2C_FLTR_DNF_MASK))
+#define STM32F4_I2C_FLTR_ANOFF BIT(4)
+
+#define STM32F4_I2C_MIN_FREQ 2U
+#define STM32F4_I2C_MAX_FREQ 42U
+#define FAST_MODE_MAX_RISE_TIME 1000
+#define STD_MODE_MAX_RISE_TIME 300
+#define MHZ_TO_HZ 1000000
+
+enum stm32f4_i2c_speed {
+ STM32F4_I2C_SPEED_STANDARD, /* 100 kHz */
+ STM32F4_I2C_SPEED_FAST, /* 400 kHz */
+ STM32F4_I2C_SPEED_END,
+};
+
+/**
+ * struct stm32f4_i2c_timings - per-Mode tuning parameters
+ * @duty: Fast mode duty cycle
+ * @mul_ccr: Value to be multiplied to CCR to reach 100Khz/400Khz SCL frequency
+ * @min_ccr: Minimum clock ctrl reg value to reach 100Khz/400Khz SCL frequency
+ */
+struct stm32f4_i2c_timings {
+ u32 rate;
+ u32 duty;
+ u32 mul_ccr;
+ u32 min_ccr;
+};
+
+/**
+ * struct stm32f4_i2c_msg - client specific data
+ * @addr: 8-bit slave addr, including r/w bit
+ * @count: number of bytes to be transferred
+ * @buf: data buffer
+ * @result: result of the transfer
+ * @stop: last I2C msg to be sent, i.e. STOP to be generated
+ */
+struct stm32f4_i2c_msg {
+ u8 addr;
+ u32 count;
+ u8 *buf;
+ int result;
+ bool stop;
+};
+
+/**
+ * struct stm32f4_i2c_dev - private data of the controller
+ * @adap: I2C adapter for this controller
+ * @dev: device for this controller
+ * @base: virtual memory area
+ * @complete: completion of I2C message
+ * @irq_event: interrupt event line for the controller
+ * @irq_error: interrupt error line for the controller
+ * @clk: hw i2c clock
+ * speed: I2C clock frequency of the controller. Standard or Fast only supported
+ * @msg: I2C transfer information
+ */
+struct stm32f4_i2c_dev {
+ struct i2c_adapter adap;
+ struct device *dev;
+ void __iomem *base;
+ struct completion complete;
+ int irq_event;
+ int irq_error;
+ struct clk *clk;
+ int speed;
+ struct stm32f4_i2c_msg msg;
+};
+
+static struct stm32f4_i2c_timings i2c_timings[] = {
+ [STM32F4_I2C_SPEED_STANDARD] = {
+ .mul_ccr = 1,
+ .min_ccr = 4,
+ .duty = 0,
+ },
+ [STM32F4_I2C_SPEED_FAST] = {
+ .mul_ccr = 16,
+ .min_ccr = 1,
+ .duty = 1,
+ },
+};
+
+static inline void stm32f4_i2c_set_bits(void __iomem *reg, u32 mask)
+{
+ writel_relaxed(readl_relaxed(reg) | mask, reg);
+}
+
+static inline void stm32f4_i2c_clr_bits(void __iomem *reg, u32 mask)
+{
+ writel_relaxed(readl_relaxed(reg) & ~mask, reg);
+}
+
+static void stm32f4_i2c_soft_reset(struct stm32f4_i2c_dev *i2c_dev)
+{
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
+
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_SWRST);
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_SWRST);
+}
+
+static void stm32f4_i2c_disable_it(struct stm32f4_i2c_dev *i2c_dev)
+{
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_IRQ_MASK);
+}
+
+static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
+{
+ u32 clk_rate, cr2, freq;
+
+ cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
+ cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
+ clk_rate = clk_get_rate(i2c_dev->clk);
+ freq = clk_rate / MHZ_TO_HZ;
+ freq = clamp(freq, STM32F4_I2C_MIN_FREQ, STM32F4_I2C_MAX_FREQ);
+ cr2 |= STM32F4_I2C_CR2_FREQ(freq);
+ writel_relaxed(cr2, i2c_dev->base + STM32F4_I2C_CR2);
+}
+
+static void stm32f4_i2c_set_rise_time(struct stm32f4_i2c_dev *i2c_dev)
+{
+ u32 trise, freq, cr2, val;
+
+ cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
+ freq = cr2 & STM32F4_I2C_CR2_FREQ_MASK;
+
+ trise = readl_relaxed(i2c_dev->base + STM32F4_I2C_TRISE);
+ trise &= ~STM32F4_I2C_TRISE_VALUE_MASK;
+
+ /* Maximum rise time computation */
+ if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
+ trise |= STM32F4_I2C_TRISE_VALUE((freq + 1));
+ } else {
+ val = freq * FAST_MODE_MAX_RISE_TIME / STD_MODE_MAX_RISE_TIME;
+ trise |= STM32F4_I2C_TRISE_VALUE((val + 1));
+ }
+
+ writel_relaxed(trise, i2c_dev->base + STM32F4_I2C_TRISE);
+}
+
+static void stm32f4_i2c_set_speed_mode(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_timings *t = &i2c_timings[i2c_dev->speed];
+ u32 ccr, clk_rate;
+ int val;
+
+ ccr = readl_relaxed(i2c_dev->base + STM32F4_I2C_CCR);
+ ccr &= ~(STM32F4_I2C_CCR_FS | STM32F4_I2C_CCR_DUTY |
+ STM32F4_I2C_CCR_CCR_MASK);
+
+ clk_rate = clk_get_rate(i2c_dev->clk);
+ val = clk_rate / MHZ_TO_HZ * t->mul_ccr;
+ if (val < t->min_ccr)
+ val = t->min_ccr;
+ ccr |= STM32F4_I2C_CCR_CCR(val);
+
+ if (t->duty)
+ ccr |= STM32F4_I2C_CCR_FS | STM32F4_I2C_CCR_DUTY;
+
+ writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR);
+}
+
+static void stm32f4_i2c_set_filter(struct stm32f4_i2c_dev *i2c_dev)
+{
+ u32 filter;
+
+ /* Enable analog noise filter and disable digital noise filter */
+ filter = readl_relaxed(i2c_dev->base + STM32F4_I2C_FLTR);
+ filter &= ~(STM32F4_I2C_FLTR_ANOFF | STM32F4_I2C_FLTR_DNF_MASK);
+ writel_relaxed(filter, i2c_dev->base + STM32F4_I2C_FLTR);
+}
+
+/**
+ * stm32f4_i2c_hw_config() - Prepare I2C block
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_hw_config(struct stm32f4_i2c_dev *i2c_dev)
+{
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
+
+ /* Disable I2C */
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_PE);
+
+ stm32f4_i2c_set_periph_clk_freq(i2c_dev);
+
+ stm32f4_i2c_set_rise_time(i2c_dev);
+
+ stm32f4_i2c_set_speed_mode(i2c_dev);
+
+ stm32f4_i2c_set_filter(i2c_dev);
+
+ /* Enable I2C */
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_PE);
+}
+
+static int stm32f4_i2c_wait_free_bus(struct stm32f4_i2c_dev *i2c_dev)
+{
+ u32 status;
+ int ret;
+
+ ret = readl_relaxed_poll_timeout(i2c_dev->base + STM32F4_I2C_SR2,
+ status,
+ !(status & STM32F4_I2C_SR2_BUSY),
+ 10, 1000);
+ if (ret) {
+ dev_err(i2c_dev->dev, "bus not free\n");
+ ret = -EBUSY;
+ }
+
+ return ret;
+}
+
+/**
+ * stm32f4_i2c_write_ byte() - Write a byte in the data register
+ * @i2c_dev: Controller's private data
+ * @byte: Data to write in the register
+ */
+static void stm32f4_i2c_write_byte(struct stm32f4_i2c_dev *i2c_dev, u8 byte)
+{
+ writel_relaxed(byte, i2c_dev->base + STM32F4_I2C_DR);
+}
+
+/**
+ * stm32f4_i2c_write_msg() - Fill the data register in write mode
+ * @i2c_dev: Controller's private data
+ *
+ * This function fills the data register with I2C transfer buffer
+ */
+static void stm32f4_i2c_write_msg(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+
+ stm32f4_i2c_write_byte(i2c_dev, *msg->buf++);
+ msg->count--;
+}
+
+static void stm32f4_i2c_read_msg(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ u32 rbuf;
+
+ rbuf = readl_relaxed(i2c_dev->base + STM32F4_I2C_DR);
+ *msg->buf++ = (u8)rbuf & 0xff;
+ msg->count--;
+}
+
+static void stm32f4_i2c_terminate_xfer(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+
+ stm32f4_i2c_disable_it(i2c_dev);
+
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ if (msg->stop)
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
+ else
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
+
+ complete(&i2c_dev->complete);
+}
+
+/**
+ * stm32f4_i2c_handle_write() - Handle FIFO empty interrupt in case of write
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_handle_write(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+
+ if (msg->count) {
+ stm32f4_i2c_write_msg(i2c_dev);
+ if (!msg->count) {
+ /* Disable BUF interrupt */
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
+ }
+ } else {
+ stm32f4_i2c_terminate_xfer(i2c_dev);
+ }
+}
+
+/**
+ * stm32f4_i2c_handle_read() - Handle FIFO empty interrupt in case of read
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_handle_read(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+
+ switch (msg->count) {
+ case 1:
+ stm32f4_i2c_disable_it(i2c_dev);
+ stm32f4_i2c_read_msg(i2c_dev);
+ complete(&i2c_dev->complete);
+ break;
+ case 2:
+ case 3:
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
+ break;
+ default:
+ stm32f4_i2c_read_msg(i2c_dev);
+ }
+}
+
+/**
+ * stm32f4_i2c_handle_rx_btf() - Handle byte transfer finished interrupt
+ * in case of read
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_handle_rx_btf(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg;
+ u32 mask;
+ int i;
+
+ switch (msg->count) {
+ case 2:
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ /* Generate STOP or REPSTART */
+ if (msg->stop)
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
+ else
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
+
+ /* Read two last data bytes */
+ for (i = 2; i > 0; i--)
+ stm32f4_i2c_read_msg(i2c_dev);
+
+ /* Disable EVT and ERR interrupt */
+ reg = i2c_dev->base + STM32F4_I2C_CR2;
+ mask = STM32F4_I2C_CR2_ITEVTEN | STM32F4_I2C_CR2_ITERREN;
+ stm32f4_i2c_clr_bits(reg, mask);
+
+ complete(&i2c_dev->complete);
+ break;
+ case 3:
+ /* Enable ACK and read data */
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
+ stm32f4_i2c_read_msg(i2c_dev);
+ break;
+ default:
+ stm32f4_i2c_read_msg(i2c_dev);
+ }
+}
+
+/**
+ * stm32f4_i2c_handle_rx_addr() - Handle address matched interrupt in case of
+ * master receiver
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_handle_rx_addr(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg;
+
+ switch (msg->count) {
+ case 0:
+ stm32f4_i2c_terminate_xfer(i2c_dev);
+ /* Clear ADDR flag */
+ readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+ break;
+ case 1:
+ /*
+ * Single byte reception:
+ * Enable NACK, clear ADDR flag and generate STOP or RepSTART
+ */
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
+ if (msg->stop)
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
+ else
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
+ break;
+ case 2:
+ /*
+ * 2-byte reception:
+ * Enable NACK and PEC Position Ack and clear ADDR flag
+ */
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_POS);
+ readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+ break;
+
+ default:
+ /* N-byte reception: Enable ACK and clear ADDR flag */
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_ACK);
+ readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+ break;
+ }
+}
+
+/**
+ * stm32f4_i2c_isr_event() - Interrupt routine for I2C bus event
+ * @irq: interrupt number
+ * @data: Controller's private data
+ */
+static irqreturn_t stm32f4_i2c_isr_event(int irq, void *data)
+{
+ struct stm32f4_i2c_dev *i2c_dev = data;
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg;
+ u32 real_status, possible_status, ien;
+ int flag;
+
+ ien = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
+ ien &= STM32F4_I2C_CR2_IRQ_MASK;
+ possible_status = 0;
+
+ /* Check possible status combinations */
+ if (ien & STM32F4_I2C_CR2_ITEVTEN) {
+ possible_status = STM32F4_I2C_SR1_ITEVTEN_MASK;
+ if (ien & STM32F4_I2C_CR2_ITBUFEN)
+ possible_status |= STM32F4_I2C_SR1_ITBUFEN_MASK;
+ }
+
+ real_status = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR1);
+
+ if (!(real_status & possible_status)) {
+ dev_dbg(i2c_dev->dev,
+ "spurious evt it (status=0x%08x, ien=0x%08x)\n",
+ real_status, ien);
+ return IRQ_NONE;
+ }
+
+ /* Use __fls() to check error bits first */
+ flag = __fls(real_status & possible_status);
+
+ switch (1 << flag) {
+ case STM32F4_I2C_SR1_SB:
+ stm32f4_i2c_write_byte(i2c_dev, msg->addr);
+ break;
+
+ case STM32F4_I2C_SR1_ADDR:
+ if (msg->addr & I2C_M_RD)
+ stm32f4_i2c_handle_rx_addr(i2c_dev);
+ else
+ readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+
+ /* Enable ITBUF interrupts */
+ reg = i2c_dev->base + STM32F4_I2C_CR2;
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
+ break;
+
+ case STM32F4_I2C_SR1_BTF:
+ if (msg->addr & I2C_M_RD)
+ stm32f4_i2c_handle_rx_btf(i2c_dev);
+ else
+ stm32f4_i2c_handle_write(i2c_dev);
+ break;
+
+ case STM32F4_I2C_SR1_TXE:
+ stm32f4_i2c_handle_write(i2c_dev);
+ break;
+
+ case STM32F4_I2C_SR1_RXNE:
+ stm32f4_i2c_handle_read(i2c_dev);
+ break;
+
+ default:
+ dev_err(i2c_dev->dev,
+ "evt it unhandled: status=0x%08x)\n", real_status);
+ return IRQ_NONE;
+ }
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * stm32f4_i2c_isr_error() - Interrupt routine for I2C bus error
+ * @irq: interrupt number
+ * @data: Controller's private data
+ */
+static irqreturn_t stm32f4_i2c_isr_error(int irq, void *data)
+{
+ struct stm32f4_i2c_dev *i2c_dev = data;
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg;
+ u32 real_status, possible_status, ien;
+ int flag;
+
+ ien = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
+ ien &= STM32F4_I2C_CR2_IRQ_MASK;
+ possible_status = 0;
+
+ /* Check possible status combinations */
+ if (ien & STM32F4_I2C_CR2_ITERREN)
+ possible_status = STM32F4_I2C_SR1_ITERREN_MASK;
+
+ real_status = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR1);
+
+ if (!(real_status & possible_status)) {
+ dev_dbg(i2c_dev->dev,
+ "spurious err it (status=0x%08x, ien=0x%08x)\n",
+ real_status, ien);
+ return IRQ_NONE;
+ }
+
+ /* Use __fls() to check error bits first */
+ flag = __fls(real_status & possible_status);
+
+ switch (1 << flag) {
+ case STM32F4_I2C_SR1_BERR:
+ reg = i2c_dev->base + STM32F4_I2C_SR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_SR1_BERR);
+ msg->result = -EIO;
+ break;
+
+ case STM32F4_I2C_SR1_ARLO:
+ reg = i2c_dev->base + STM32F4_I2C_SR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_SR1_ARLO);
+ msg->result = -EAGAIN;
+ break;
+
+ case STM32F4_I2C_SR1_AF:
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
+ msg->result = -EIO;
+ break;
+
+ default:
+ dev_err(i2c_dev->dev,
+ "err it unhandled: status=0x%08x)\n", real_status);
+ return IRQ_NONE;
+ }
+
+ stm32f4_i2c_soft_reset(i2c_dev);
+ stm32f4_i2c_disable_it(i2c_dev);
+ complete(&i2c_dev->complete);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * stm32f4_i2c_xfer_msg() - Transfer a single I2C message
+ * @i2c_dev: Controller's private data
+ * @msg: I2C message to transfer
+ * @is_first: first message of the sequence
+ * @is_last: last message of the sequence
+ */
+static int stm32f4_i2c_xfer_msg(struct stm32f4_i2c_dev *i2c_dev,
+ struct i2c_msg *msg, bool is_first,
+ bool is_last)
+{
+ struct stm32f4_i2c_msg *f4_msg = &i2c_dev->msg;
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
+ unsigned long timeout;
+ u32 mask;
+ int ret;
+
+ f4_msg->addr = i2c_8bit_addr_from_msg(msg);
+ f4_msg->buf = msg->buf;
+ f4_msg->count = msg->len;
+ f4_msg->result = 0;
+ f4_msg->stop = is_last;
+
+ reinit_completion(&i2c_dev->complete);
+
+ /* Enable ITEVT and ITERR interrupts */
+ mask = STM32F4_I2C_CR2_ITEVTEN | STM32F4_I2C_CR2_ITERREN;
+ stm32f4_i2c_set_bits(i2c_dev->base + STM32F4_I2C_CR2, mask);
+
+ if (is_first) {
+ ret = stm32f4_i2c_wait_free_bus(i2c_dev);
+ if (ret)
+ return ret;
+
+ /* START generation */
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
+ }
+
+ timeout = wait_for_completion_timeout(&i2c_dev->complete,
+ i2c_dev->adap.timeout);
+ ret = f4_msg->result;
+
+ /* Disable PEC position Ack */
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_POS);
+
+ if (!timeout)
+ ret = -ETIMEDOUT;
+
+ return ret;
+}
+
+/**
+ * stm32f4_i2c_xfer() - Transfer combined I2C message
+ * @i2c_adap: Adapter pointer to the controller
+ * @msgs: Pointer to data to be written.
+ * @num: Number of messages to be executed
+ */
+static int stm32f4_i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[],
+ int num)
+{
+ struct stm32f4_i2c_dev *i2c_dev = i2c_get_adapdata(i2c_adap);
+ int ret, i;
+
+ ret = clk_enable(i2c_dev->clk);
+ if (ret) {
+ dev_err(i2c_dev->dev, "Failed to enable clock\n");
+ return ret;
+ }
+
+ stm32f4_i2c_hw_config(i2c_dev);
+
+ for (i = 0; i < num && !ret; i++)
+ ret = stm32f4_i2c_xfer_msg(i2c_dev, &msgs[i], i == 0,
+ i == num - 1);
+
+ clk_disable(i2c_dev->clk);
+
+ return (ret < 0) ? ret : i;
+}
+
+static u32 stm32f4_i2c_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static struct i2c_algorithm stm32f4_i2c_algo = {
+ .master_xfer = stm32f4_i2c_xfer,
+ .functionality = stm32f4_i2c_func,
+};
+
+static int stm32f4_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct stm32f4_i2c_dev *i2c_dev;
+ struct resource *res;
+ u32 clk_rate;
+ struct i2c_adapter *adap;
+ struct reset_control *rst;
+ int ret;
+
+ i2c_dev = devm_kzalloc(&pdev->dev, sizeof(*i2c_dev), GFP_KERNEL);
+ if (!i2c_dev)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ i2c_dev->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(i2c_dev->base))
+ return PTR_ERR(i2c_dev->base);
+
+ i2c_dev->irq_event = irq_of_parse_and_map(np, 0);
+ if (!i2c_dev->irq_event) {
+ dev_err(&pdev->dev, "IRQ missing or invalid\n");
+ return -EINVAL;
+ }
+
+ i2c_dev->irq_error = irq_of_parse_and_map(np, 1);
+ if (!i2c_dev->irq_error) {
+ dev_err(&pdev->dev, "IRQ missing or invalid\n");
+ return -EINVAL;
+ }
+
+ i2c_dev->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(i2c_dev->clk)) {
+ dev_err(&pdev->dev, "Error: Missing controller clock\n");
+ return PTR_ERR(i2c_dev->clk);
+ }
+ ret = clk_prepare(i2c_dev->clk);
+ if (ret) {
+ dev_err(i2c_dev->dev, "Failed to prepare clock\n");
+ return ret;
+ }
+
+ rst = devm_reset_control_get(&pdev->dev, NULL);
+ if (IS_ERR(rst)) {
+ dev_err(&pdev->dev, "Error: Missing controller reset\n");
+ ret = PTR_ERR(rst);
+ goto clk_free;
+ }
+ reset_control_assert(rst);
+ udelay(2);
+ reset_control_deassert(rst);
+
+ i2c_dev->speed = STM32F4_I2C_SPEED_STANDARD;
+ ret = of_property_read_u32(np, "clock-frequency", &clk_rate);
+ if ((!ret) && (clk_rate == 400000))
+ i2c_dev->speed = STM32F4_I2C_SPEED_FAST;
+
+ i2c_dev->dev = &pdev->dev;
+
+ ret = devm_request_threaded_irq(&pdev->dev, i2c_dev->irq_event,
+ NULL, stm32f4_i2c_isr_event,
+ IRQF_ONESHOT, pdev->name, i2c_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request irq %i\n",
+ i2c_dev->irq_error);
+ goto clk_free;
+ }
+
+ ret = devm_request_threaded_irq(&pdev->dev, i2c_dev->irq_error,
+ NULL, stm32f4_i2c_isr_error,
+ IRQF_ONESHOT, pdev->name, i2c_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request irq %i\n",
+ i2c_dev->irq_error);
+ goto clk_free;
+ }
+
+ adap = &i2c_dev->adap;
+ i2c_set_adapdata(adap, i2c_dev);
+ snprintf(adap->name, sizeof(adap->name), "STM32 I2C(%pa)", &res->start);
+ adap->owner = THIS_MODULE;
+ adap->timeout = 2 * HZ;
+ adap->retries = 0;
+ adap->algo = &stm32f4_i2c_algo;
+ adap->dev.parent = &pdev->dev;
+ adap->dev.of_node = pdev->dev.of_node;
+
+ init_completion(&i2c_dev->complete);
+
+ ret = i2c_add_adapter(adap);
+ if (ret)
+ goto clk_free;
+
+ platform_set_drvdata(pdev, i2c_dev);
+
+ dev_info(i2c_dev->dev, "STM32F4 I2C driver initialized\n");
+
+ return 0;
+
+clk_free:
+ clk_unprepare(i2c_dev->clk);
+ return ret;
+}
+
+static int stm32f4_i2c_remove(struct platform_device *pdev)
+{
+ struct stm32f4_i2c_dev *i2c_dev = platform_get_drvdata(pdev);
+
+ i2c_del_adapter(&i2c_dev->adap);
+
+ clk_unprepare(i2c_dev->clk);
+
+ return 0;
+}
+
+static const struct of_device_id stm32f4_i2c_match[] = {
+ { .compatible = "st,stm32f4-i2c", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, stm32f4_i2c_match);
+
+static struct platform_driver stm32f4_i2c_driver = {
+ .driver = {
+ .name = "stm32f4-i2c",
+ .of_match_table = stm32f4_i2c_match,
+ },
+ .probe = stm32f4_i2c_probe,
+ .remove = stm32f4_i2c_remove,
+};
+
+module_platform_driver(stm32f4_i2c_driver);
+
+MODULE_AUTHOR("M'boumba Cedric Madianga <cedric.madianga@gmail.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32F4 I2C driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v6 1/5] dt-bindings: Document the STM32 I2C bindings
From: M'boumba Cedric Madianga @ 2016-12-12 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-1-git-send-email-cedric.madianga@gmail.com>
This patch adds documentation of device tree bindings for the STM32 I2C
controller.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/i2c/i2c-stm32.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 0000000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+ interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+ operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 100000 and 400000.
+
+Example :
+
+ i2c at 40005400 {
+ compatible = "st,stm32f4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x40005400 0x400>;
+ interrupts = <31>,
+ <32>;
+ resets = <&rcc 277>;
+ clocks = <&rcc 0 149>;
+ pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+ pinctrl-names = "default";
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v6 0/5] Add support for the STM32F4 I2C
From: M'boumba Cedric Madianga @ 2016-12-12 16:15 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.
Changes since v5:
- Change commit header from "ARM: dts:" to "ARM: dts: stm32:" (Alex)
- Change commit header from "ARM: configs:" to "ARM: configs: stm32:" (Alex)
- Fix warnings due to variable set but unused (Wolfram)
- Remove double space in Kconfig (Wolfram)
- Fix warning due to bad type parameter when using clamp() function
(build-bot)
M'boumba Cedric Madianga (5):
dt-bindings: Document the STM32 I2C bindings
i2c: Add STM32F4 I2C driver
ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
ARM: dts: stm32: Add I2C1 support for STM32429 eval board
ARM: configs: stm32: Add I2C support for STM32 defconfig
.../devicetree/bindings/i2c/i2c-stm32.txt | 33 +
arch/arm/boot/dts/stm32429i-eval.dts | 6 +
arch/arm/boot/dts/stm32f429.dtsi | 23 +
arch/arm/configs/stm32_defconfig | 3 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-stm32f4.c | 849 +++++++++++++++++++++
7 files changed, 925 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
create mode 100644 drivers/i2c/busses/i2c-stm32f4.c
--
1.9.1
^ permalink raw reply
* [PATCH 2/2] FPGA: Add TS-7300 FPGA manager
From: Alan Tull @ 2016-12-12 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211221750.27743-3-f.fainelli@gmail.com>
On Sun, 11 Dec 2016, Florian Fainelli wrote:
> Add support for loading bitstreams on the Altera Cyclone II FPGA
> populated on the TS-7300 board. This is done through the configuration
> and data registers offered through a memory interface between the EP93xx
> SoC and the FPGA.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Hi Florain,
Thanks for submitting!
How specific is this to the tx7300 board?
I'm unclear about the programming method here. Are these registers
exposed by the EP93xx? Is it possible that another cpu could access
these two registers to configure the cyclone ii? Is this passive
serial?
Please cc linux-fpga at vger.kernel.org for the next version.
Other comments below...
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/ts73xx-fpga.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 173 insertions(+)
> create mode 100644 drivers/fpga/ts73xx-fpga.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index cd84934774cc..109625707ef0 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ZYNQ_FPGA
> help
> FPGA manager driver support for Xilinx Zynq FPGAs.
>
> +config FPGA_MGR_TS73XX
> + tristate "Technologic Systems TS-73xx SBC FPGA Manager"
> + depends on ARCH_EP93XX && MACH_TS72XX
> + help
> + FPGA manager driver support for the Altera Cyclone II FPGA
> + present on the TS-73xx SBC boards.
> +
> endif # FPGA
>
> endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6b1613..5d51265cc1b4 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
> # FPGA Manager Drivers
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> +obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
> diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c
> new file mode 100644
> index 000000000000..2b3d5d668dfc
> --- /dev/null
> +++ b/drivers/fpga/ts73xx-fpga.c
> @@ -0,0 +1,165 @@
> +/*
> + * Technologic Systems TS-73xx SBC FPGA loader
> + *
> + * Copyright (C) 2016 Florian Fainelli <f.fainelli@gmail.com>
> + *
> + * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on
> + * TS-7300, heavily based on load_fpga.c in their vendor tree.
> + *
> + * 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; version 2 of the License.
> + *
> + * 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/delay.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/string.h>
> +#include <linux/bitrev.h>
> +#include <linux/fpga/fpga-mgr.h>
> +
> +#define TS73XX_FPGA_DATA_REG 0
> +#define TS73XX_FPGA_CONFIG_REG 1
> +
> +struct ts73xx_fpga_priv {
> + void __iomem *io_base;
> + struct device *dev;
> +};
> +
> +static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr)
> +{
> + return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int ts73xx_fpga_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> +
> + /* Reset the FPGA */
> + writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + udelay(30);
> + writeb(0x2, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + udelay(80);
Could these udelay values be macros?
> +
> + return 0;
> +}
> +
> +static inline int ts73xx_fpga_can_write(struct ts73xx_fpga_priv *priv)
> +{
> + unsigned int timeout = 1000;
Another macro?
> + u8 reg;
> +
> + while (timeout--) {
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + if (!(reg & 0x1))
Macro to tell us what the bit name of this bit.
> + return 0;
> + cpu_relax();
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> +static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> + size_t i = 0;
> + int ret;
> + u8 reg;
> +
> + while (count--) {
> + ret = ts73xx_fpga_can_write(priv);
> + if (ret < 0)
> + return ret;
> +
> + writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG);
> + i++;
> + }
> +
> + usleep_range(1000, 2000);
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + reg |= 0x8;
A macro for this bit.
> + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + usleep_range(1000, 2000);
> +
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + reg &= ~0x8;
> + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> +
> + return 0;
> +}
> +
> +static int ts73xx_fpga_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> + u8 reg;
> +
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + if ((reg & 0x4) != 0x4)
Another macro...
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> +static const struct fpga_manager_ops ts73xx_fpga_ops = {
> + .state = ts73xx_fpga_state,
> + .write_init = ts73xx_fpga_write_init,
> + .write = ts73xx_fpga_write,
> + .write_complete = ts73xx_fpga_write_complete,
> +};
> +
> +static int ts73xx_fpga_probe(struct platform_device *pdev)
> +{
> + struct device *kdev = &pdev->dev;
> + struct ts73xx_fpga_priv *priv;
> + struct fpga_manager *mgr;
> + struct resource *res;
> + int err;
> +
> + priv = devm_kzalloc(kdev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = kdev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->io_base = devm_ioremap_resource(kdev, res);
> + if (IS_ERR(priv->io_base))
> + return PTR_ERR(priv->io_base);
> +
> + err = fpga_mgr_register(kdev, "TS-73xx FPGA Manager",
> + &ts73xx_fpga_ops, priv);
> + if (err) {
> + dev_err(kdev, "failed to register FPGA manager\n");
> + return err;
> + }
> +
> + return err;
> +}
> +
> +static int ts73xx_fpga_remove(struct platform_device *pdev)
> +{
> + fpga_mgr_unregister(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static struct platform_driver ts73xx_fpga_driver = {
> + .driver = {
> + .name = "ts73xx-fpga-mgr",
> + },
> + .probe = ts73xx_fpga_probe,
> + .remove = ts73xx_fpga_remove,
> +};
> +module_platform_driver(ts73xx_fpga_driver);
> +
> +MODULE_AUTHOR("Florian Fainelli <f.fainelli@gmail.com>");
> +MODULE_DESCRIPTION("TS-73xx FPGA Manager driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.9.3
>
>
^ permalink raw reply
* [PATCH v2 06/11] mfd: axp20x: add separate MFD cell for AXP223
From: Maxime Ripard @ 2016-12-12 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-7-quentin.schulz@free-electrons.com>
On Fri, Dec 09, 2016 at 12:04:14PM +0100, Quentin Schulz wrote:
> The AXP223 shares most of its logic with the AXP221 but has some
> differences for the VBUS power supply driver. Thus, to probe the driver
> with the correct compatible, the AXP221 and the AXP223 now have separate
> MFD cells.
>
> AXP221 MFD cells are renamed from axp22x_cells to axp221_cells to avoid
> confusion.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/6c2ec2c4/attachment.sig>
^ permalink raw reply
* [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Maxime Ripard @ 2016-12-12 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-5-quentin.schulz@free-electrons.com>
On Fri, Dec 09, 2016 at 12:04:12PM +0100, Quentin Schulz wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/27391208/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: Support DTB build for NanoPi M1
From: Maxime Ripard @ 2016-12-12 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209014758.27368-1-woogyom.kim@gmail.com>
Hi,
On Fri, Dec 09, 2016 at 10:47:58AM +0900, Milo Kim wrote:
> The commit 10efbf5f1633 introduced NanoPi M1 board but it's missing in
> Allwinner H3 DTB build.
>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
checkpatch reports an error on this one (commit format), please fix
and resend.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/3adae531/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Rob Herring @ 2016-12-12 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206025321.1792-7-andrew@aj.id.au>
On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> The use of syscons is growing, lets collate them in their own part of
> the bindings tree.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt | 0
> Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt | 0
> Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt | 0
> Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt | 0
> Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt | 0
> Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt | 0
> .../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt | 0
> 7 files changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
> rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
> rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
> rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
> rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
> rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
> rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)
I'm not so sure this is the right direction. syscon usage is pretty much
spread throughout the tree.
Rob
^ permalink raw reply
* [PATCH v3 4/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Rob Herring @ 2016-12-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206025321.1792-5-andrew@aj.id.au>
On Tue, Dec 06, 2016 at 01:53:19PM +1100, Andrew Jeffery wrote:
> The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> on bits in both the System Control Unit and the LPC Host Controller.
>
> The Aspeed LPC Host Controller is described as a child node of the
> LPC host-range syscon device for arbitration of access by the host
> controller and pinmux drivers.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index a97131aba446..9de318ef72da 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -109,3 +109,25 @@ lpc: lpc at 1e789000 {
> };
> };
>
> +Host Node Children
> +==================
> +
> +LPC Host Controller
> +-------------------
> +
> +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
> +between the host and the baseboard management controller. The registers exist
> +in the "host" portion of the Aspeed LPC controller, which must be the parent of
> +the LPC host controller node.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-lhc";
> +- reg: contains offset/length value of the LHC memory
> + region.
How many regions? Looks like 2.
> +
> +Example:
> +
> +lhc: lhc at 20 {
> + compatible = "aspeed,ast2500-lhc";
> + reg = <0x20 0x24 0x48 0x8>;
> +};
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v3 3/6] mfd: dt: Add Aspeed Low Pin Count Controller bindings
From: Rob Herring @ 2016-12-12 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206025321.1792-4-andrew@aj.id.au>
On Tue, Dec 06, 2016 at 01:53:18PM +1100, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 111 +++++++++++++++++++++
> 1 file changed, 111 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Nicolas Pitre @ 2016-12-12 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212112230epcms5p6af05aef34f72eab15061a166d18cff00@epcms5p6>
On Mon, 12 Dec 2016, Vaneet Narang wrote:
> Hi,
>
> >A PC24 relocation has a range of +/-32MB. This means that where-ever
> >the module is placed, it must be capable of reaching any function
> >within the kernel text, which may itself be quite large (eg, 8MB, or
> >possibly larger). The module area exists to allow modules to be
> >located in an area where PC24 relocations are able to reach all of the
> >kernel text on sensibly configured kernels, thereby allowing for
> >optimal performance.
> >
> >If you wish to load large modules, then enable ARM_MODULE_PLTS, which
> >will use the less efficient PLT method (which is basically an indirect
> >function call) for relocations that PC24 can't handle, and will allow
> >the module to be loaded into the vmalloc area.
> >
> >Growing the module area so that smaller modules also get penalised by
> >the PLT indirection is not sane.
>
> This is exactly what i am saying. These changes are useful to accomdate
> 22MB modules without enabling ARM_MODULE_PLTS.
I think you need to figure out why you need such a huge module in the
first place. That is very uncommon indeed.
Nicolas
^ permalink raw reply
* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Marc Zyngier @ 2016-12-12 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212151432.GB3203@e104818-lin.cambridge.arm.com>
On 12/12/16 15:14, Catalin Marinas wrote:
> On Mon, Dec 12, 2016 at 04:06:36PM +0100, Christoffer Dall wrote:
>> On Mon, Dec 12, 2016 at 01:50:26PM +0000, Marc Zyngier wrote:
>>> Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
>>> functionality based on TTBR0_EL1") added conditional PAN
>>> enable/disable. Unfortunately, a typo prevents PAN from being
>>> re-enabled once it has been disabled.
>>>
>>> Restore the PAN functionnality by adding the missing '!'.
>>>
>>> Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
>>> Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>> ---
>>> Christoffer, any chance you could give this a go and let me know
>>> if that fixes your issues?
>>
>> Yep, fixes the issue. Thanks!
>
> Thanks for confirming. I merged this with a slightly updated commit log:
>
> ------8<-----------------
> Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
> functionality based on TTBR0_EL1") added conditional user access
> enable/disable. Unfortunately, a typo prevents the PAN bit from being
> cleared for user access functions.
That looks indeed much better. Thanks!
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Catalin Marinas @ 2016-12-12 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212150636.GA7070@cbox>
On Mon, Dec 12, 2016 at 04:06:36PM +0100, Christoffer Dall wrote:
> On Mon, Dec 12, 2016 at 01:50:26PM +0000, Marc Zyngier wrote:
> > Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
> > functionality based on TTBR0_EL1") added conditional PAN
> > enable/disable. Unfortunately, a typo prevents PAN from being
> > re-enabled once it has been disabled.
> >
> > Restore the PAN functionnality by adding the missing '!'.
> >
> > Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
> > Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> > ---
> > Christoffer, any chance you could give this a go and let me know
> > if that fixes your issues?
>
> Yep, fixes the issue. Thanks!
Thanks for confirming. I merged this with a slightly updated commit log:
------8<-----------------
Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
functionality based on TTBR0_EL1") added conditional user access
enable/disable. Unfortunately, a typo prevents the PAN bit from being
cleared for user access functions.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Christoffer Dall @ 2016-12-12 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481550626-30956-1-git-send-email-marc.zyngier@arm.com>
On Mon, Dec 12, 2016 at 01:50:26PM +0000, Marc Zyngier wrote:
> Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
> functionality based on TTBR0_EL1") added conditional PAN
> enable/disable. Unfortunately, a typo prevents PAN from being
> re-enabled once it has been disabled.
>
> Restore the PAN functionnality by adding the missing '!'.
>
> Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
> Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> Christoffer, any chance you could give this a go and let me know
> if that fixes your issues?
Yep, fixes the issue. Thanks!
-Christoffer
>
> arch/arm64/include/asm/uaccess.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 6986f56..d26750c 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -188,7 +188,7 @@ do { \
>
> #define __uaccess_enable(alt) \
> do { \
> - if (uaccess_ttbr0_enable()) \
> + if (!uaccess_ttbr0_enable()) \
> asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
> CONFIG_ARM64_PAN)); \
> } while (0)
> --
> 2.1.4
>
^ permalink raw reply
* [Xen-devel] [PATCH v2 4/4] Explicitly clean linux-system.axf and xen-system.axf
From: Andre Przywara @ 2016-12-12 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212144729.GD1686@char.us.oracle.com>
Hi Konrad,
On 12/12/16 14:47, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 22, 2016 at 03:09:17PM +0000, Andre Przywara wrote:
>> From: Christoffer Dall <christoffer.dall@linaro.org>
>>
>> When doing a make clean, only the output image currently configured to
>> build is being removed. However, one would expect all build artifacts
>> to be removed when doing a 'make clean' and when switching between Xen
>> and Linux builds, it is easy to accidentally run an older build than
>> intended. Simply hardcode the axf image file names.
>>
>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Reviewed-by: Julien Grall <julien.grall@arm.com>
>
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thanks a lot!
I will try to poke Mark to see if we can get this merged eventually.
Cheers,
Andre.
>> ---
>> Makefile.am | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index db97f9c..506a1d9 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -130,7 +130,7 @@ OFILES += $(addprefix $(ARCH_SRC),boot.o stack.o $(BOOTMETHOD) utils.o)
>>
>> all: $(IMAGE)
>>
>> -CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
>> +CLEANFILES = $(IMAGE) linux-system.axf xen-system.axf $(OFILES) model.lds fdt.dtb
>>
>> $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
>> $(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
>> --
>> 2.9.0
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel at lists.xen.org
>> https://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] [PATCH v2 4/4] Explicitly clean linux-system.axf and xen-system.axf
From: Konrad Rzeszutek Wilk @ 2016-12-12 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-5-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:09:17PM +0000, Andre Przywara wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> When doing a make clean, only the output image currently configured to
> build is being removed. However, one would expect all build artifacts
> to be removed when doing a 'make clean' and when switching between Xen
> and Linux builds, it is easy to accidentally run an older build than
> intended. Simply hardcode the axf image file names.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Julien Grall <julien.grall@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Makefile.am | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index db97f9c..506a1d9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -130,7 +130,7 @@ OFILES += $(addprefix $(ARCH_SRC),boot.o stack.o $(BOOTMETHOD) utils.o)
>
> all: $(IMAGE)
>
> -CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
> +CLEANFILES = $(IMAGE) linux-system.axf xen-system.axf $(OFILES) model.lds fdt.dtb
>
> $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
> $(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
> --
> 2.9.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] [PATCH v2 3/4] Xen: Select correct dom0 console
From: Konrad Rzeszutek Wilk @ 2016-12-12 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-4-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:09:16PM +0000, Andre Przywara wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
>
> If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
> the usual ttyAMA0 otherwise.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Julien Grall <julien.grall@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> configure.ac | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index aff4aad..c959ab8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -92,7 +92,8 @@ AC_ARG_WITH([initrd],
> AC_SUBST([FILESYSTEM], [$USE_INITRD])
> AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
>
> -C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c090000"
> +AS_IF([test "x$X_IMAGE" = "x"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
> +C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c090000"
> AC_ARG_WITH([cmdline],
> AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
> [C_CMDLINE=$withval])
> --
> 2.9.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] [PATCH v2 2/4] Xen: Support adding DT nodes
From: Konrad Rzeszutek Wilk @ 2016-12-12 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-3-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:09:15PM +0000, Andre Przywara wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Support adding xen,xen-bootargs node via --with-xen-bootargs to the
> configure script and automatically add the Dom0 node to the DT as well.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Makefile.am | 23 +++++++++++++++--------
> configure.ac | 9 +++++++++
> 2 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index f8b9ec9..db97f9c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -96,21 +96,28 @@ FDT_OFFSET := 0x08000000
> if XEN
> XEN := -DXEN=$(XEN_IMAGE)
> XEN_OFFSET := 0x08200000
> +KERNEL_SIZE := $(shell stat -Lc %s $(KERNEL_IMAGE) 2>/dev/null || echo 0)
> +DOM0_OFFSET := $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
> +XEN_BOOTARGS := xen,xen-bootargs = \"$(XEN_CMDLINE)\"; \
> + \#address-cells = <2>; \
> + \#size-cells = <2>; \
> + module at 1 { \
> + compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
> + reg = <0x0 $(DOM0_OFFSET) 0x0 $(KERNEL_SIZE)>; \
> + };
> endif
>
> if INITRD
> INITRD_FLAGS := -DUSE_INITRD
> +INITRD_CHOSEN := linux,initrd-start = <$(FILESYSTEM_START)>; \
> + linux,initrd-end = <$(FILESYSTEM_END)>;
> +endif
> +
> CHOSEN_NODE := chosen { \
> bootargs = \"$(CMDLINE)\"; \
> - linux,initrd-start = <$(FILESYSTEM_START)>; \
> - linux,initrd-end = <$(FILESYSTEM_END)>; \
> - };
> -else
> -INITRD_FLAGS :=
> -CHOSEN_NODE := chosen { \
> - bootargs = \"$(CMDLINE)\"; \
> + $(INITRD_CHOSEN) \
> + $(XEN_BOOTARGS) \
> };
> -endif
>
> CPPFLAGS += $(INITRD_FLAGS)
> CFLAGS += -Iinclude/ -I$(ARCH_SRC)/include/
> diff --git a/configure.ac b/configure.ac
> index f7e24c7..aff4aad 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -98,6 +98,12 @@ AC_ARG_WITH([cmdline],
> [C_CMDLINE=$withval])
> AC_SUBST([CMDLINE], [$C_CMDLINE])
>
> +X_CMDLINE="console=dtuart dtuart=serial0 no-bootscrub"
> +AC_ARG_WITH([xen-cmdline],
> + AS_HELP_STRING([--with-xen-cmdline], [set Xen command line]),
> + [X_CMDLINE=$withval])
> +AC_SUBST([XEN_CMDLINE], [$X_CMDLINE])
> +
> # Allow a user to pass --enable-gicv3
> AC_ARG_ENABLE([gicv3],
> AS_HELP_STRING([--enable-gicv3], [enable GICv3 instead of GICv2]),
> @@ -136,4 +142,7 @@ echo " Use GICv3? ${USE_GICV3}"
> echo " Boot-wrapper execution state: AArch${BOOTWRAPPER_ES}"
> echo " Kernel execution state: AArch${KERNEL_ES}"
> echo " Xen image ${XEN_IMAGE:-NONE}"
> +if test "x${XEN_IMAGE}" != "x"; then
> +echo " Xen command line: ${XEN_CMDLINE}"
> +fi
> echo ""
> --
> 2.9.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] [PATCH v2 1/4] Support for building in a Xen binary
From: Konrad Rzeszutek Wilk @ 2016-12-12 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-2-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:09:14PM +0000, Andre Przywara wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Add support for building a Xen binary which includes a Dom0 image and
> the Dom0 command-line.
>
> If the user specifies --with-xen=<Xen>, where Xen is an appropriate
> AArch64 Xen binary, the build system will generate a xen-system.axf
> instead of a linux-system.axf.
>
> Original patch from Ian Campbell, but I modified most of it so all bugs
> are probably mine.
> [Andre: adapt to newest boot-wrapper branch, increase load address,
> fixup Xen image file test]
>
> Cc: Ian Campbell <ijc@hellion.org.uk>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
And also
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> .gitignore | 1 +
> Makefile.am | 10 +++++++---
> boot_common.c | 4 ++--
> configure.ac | 17 +++++++++++++++++
> model.lds.S | 14 ++++++++++++++
> 5 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 8653852..80770c0 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -14,6 +14,7 @@ configure
> dtc
> fdt.dtb
> Image
> +Xen
> install-sh
> Makefile
> Makefile.in
> diff --git a/Makefile.am b/Makefile.am
> index 692d2cc..f8b9ec9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -85,7 +85,6 @@ TEXT_LIMIT := 0x80080000
> endif
>
> LD_SCRIPT := model.lds.S
> -IMAGE := linux-system.axf
>
> FS_OFFSET := 0x10000000
> FILESYSTEM_START:= $(shell echo $$(($(PHYS_OFFSET) + $(FS_OFFSET))))
> @@ -94,6 +93,11 @@ FILESYSTEM_END := $(shell echo $$(($(FILESYSTEM_START) + $(FILESYSTEM_SIZE))))
>
> FDT_OFFSET := 0x08000000
>
> +if XEN
> +XEN := -DXEN=$(XEN_IMAGE)
> +XEN_OFFSET := 0x08200000
> +endif
> +
> if INITRD
> INITRD_FLAGS := -DUSE_INITRD
> CHOSEN_NODE := chosen { \
> @@ -121,7 +125,7 @@ all: $(IMAGE)
>
> CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
>
> -$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
> +$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
> $(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
>
> %.o: %.S Makefile
> @@ -131,7 +135,7 @@ $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
> $(CC) $(CPPFLAGS) $(CFLAGS) $(DEFINES) -c -o $@ $<
>
> model.lds: $(LD_SCRIPT) Makefile
> - $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
> + $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) $(XEN) -DXEN_OFFSET=$(XEN_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
>
> fdt.dtb: $(KERNEL_DTB) Makefile gen-cpu-nodes.sh
> ( $(DTC) -O dts -I dtb $(KERNEL_DTB) ; echo "/ { $(CHOSEN_NODE) $(PSCI_NODE) $(CPUS_NODE) };" ) | $(DTC) -O dtb -o $@ -
> diff --git a/boot_common.c b/boot_common.c
> index 4947fe3..e7b8e1d 100644
> --- a/boot_common.c
> +++ b/boot_common.c
> @@ -9,7 +9,7 @@
> #include <cpu.h>
> #include <spin.h>
>
> -extern unsigned long kernel;
> +extern unsigned long entrypoint;
> extern unsigned long dtb;
>
> void init_platform(void);
> @@ -67,7 +67,7 @@ void __noreturn first_spin(unsigned int cpu, unsigned long *mbox,
> if (cpu == 0) {
> init_platform();
>
> - *mbox = (unsigned long)&kernel;
> + *mbox = (unsigned long)&entrypoint;
> sevl();
> spin(mbox, invalid, 1);
> } else {
> diff --git a/configure.ac b/configure.ac
> index ab8f5b3..f7e24c7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -40,6 +40,18 @@ AC_ARG_WITH([dtb],
> AS_HELP_STRING([--with-dtb], [Specify a particular DTB to use]),
> [KERN_DTB="$withval"])
>
> +AC_ARG_WITH([xen],
> + AS_HELP_STRING([--with-xen], [Compile for Xen, and Specify a particular Xen to use]),
> + X_IMAGE=$withval)
> +
> +AS_IF([test "x$X_IMAGE" == "x"], [],
> + [AS_IF([test ! -f "$X_IMAGE"],
> + [AC_MSG_ERROR([Could not find Xen hypervisor binary: $X_IMAGE])]
> + )]
> +)
> +AC_SUBST([XEN_IMAGE], [$X_IMAGE])
> +AM_CONDITIONAL([XEN], [test "x$X_IMAGE" != "x"])
> +
> # Ensure that the user has provided us with a sane kernel dir.
> m4_define([CHECKFILES], [KERN_DIR,
> KERN_DTB,
> @@ -50,6 +62,10 @@ m4_foreach([checkfile], [CHECKFILES],
>
> AC_SUBST([KERNEL_IMAGE], [$KERN_IMAGE])
> AC_SUBST([KERNEL_DTB], [$KERN_DTB])
> +AS_IF([test "x$X_IMAGE" != "x"],
> + [AC_SUBST([IMAGE], ["xen-system.axf"])],
> + [AC_SUBST([IMAGE], ["linux-system.axf"])]
> +)
>
> # Allow a user to pass --enable-psci
> AC_ARG_ENABLE([psci],
> @@ -119,4 +135,5 @@ echo " CPU IDs: ${CPU_IDS}"
> echo " Use GICv3? ${USE_GICV3}"
> echo " Boot-wrapper execution state: AArch${BOOTWRAPPER_ES}"
> echo " Kernel execution state: AArch${KERNEL_ES}"
> +echo " Xen image ${XEN_IMAGE:-NONE}"
> echo ""
> diff --git a/model.lds.S b/model.lds.S
> index 51c5684..511f552 100644
> --- a/model.lds.S
> +++ b/model.lds.S
> @@ -16,6 +16,9 @@ OUTPUT_ARCH(aarch64)
> #endif
> TARGET(binary)
>
> +#ifdef XEN
> +INPUT(XEN)
> +#endif
> INPUT(KERNEL)
> INPUT(./fdt.dtb)
>
> @@ -36,6 +39,17 @@ SECTIONS
> KERNEL
> }
>
> +#ifdef XEN
> + .xen (PHYS_OFFSET + XEN_OFFSET): {
> + xen = .;
> + XEN
> + }
> +
> + entrypoint = xen;
> +#else
> + entrypoint = kernel;
> +#endif
> +
> .dtb (PHYS_OFFSET + FDT_OFFSET): {
> dtb = .;
> ./fdt.dtb
> --
> 2.9.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH] watchdog: bcm2835_wdt: set WDOG_HW_RUNNING bit when appropriate
From: Guenter Roeck @ 2016-12-12 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481536123-9279-1-git-send-email-rasmus.villemoes@prevas.dk>
On 12/12/2016 01:48 AM, Rasmus Villemoes wrote:
> A bootloader may start the watchdog device before handing control to
> the kernel - in that case, we should tell the kernel about it so the
> watchdog framework can keep it alive until userspace opens
> /dev/watchdog0.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/watchdog/bcm2835_wdt.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
> index 4dddd82..c32c45b 100644
> --- a/drivers/watchdog/bcm2835_wdt.c
> +++ b/drivers/watchdog/bcm2835_wdt.c
> @@ -55,6 +55,15 @@ struct bcm2835_wdt {
> static unsigned int heartbeat;
> static bool nowayout = WATCHDOG_NOWAYOUT;
>
> +static bool bcm2835_wdt_is_running(struct bcm2835_wdt *wdt)
> +{
> + uint32_t cur;
> +
> + cur = readl(wdt->base + PM_RSTC);
> +
> + return !!(cur & PM_RSTC_WRCFG_FULL_RESET);
> +}
> +
> static int bcm2835_wdt_start(struct watchdog_device *wdog)
> {
> struct bcm2835_wdt *wdt = watchdog_get_drvdata(wdog);
> @@ -181,6 +190,17 @@ static int bcm2835_wdt_probe(struct platform_device *pdev)
> watchdog_init_timeout(&bcm2835_wdt_wdd, heartbeat, dev);
> watchdog_set_nowayout(&bcm2835_wdt_wdd, nowayout);
> bcm2835_wdt_wdd.parent = &pdev->dev;
> + if (bcm2835_wdt_is_running(wdt)) {
> + /*
> + * The currently active timeout value (set by the
> + * bootloader) may be different from the module
> + * heartbeat parameter or the value in device
> + * tree. But we just need to set WDOG_HW_RUNNING,
> + * because then the framework will "immediately" ping
> + * the device, updating the timeout.
> + */
> + set_bit(WDOG_HW_RUNNING, &bcm2835_wdt_wdd.status);
> + }
> err = watchdog_register_device(&bcm2835_wdt_wdd);
> if (err) {
> dev_err(dev, "Failed to register watchdog device");
>
^ permalink raw reply
* [PATCH renesas/devel 10/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
From: Simon Horman @ 2016-12-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0db5b88e-41fb-03db-fa61-48e754356901@cogentembedded.com>
On Mon, Dec 12, 2016 at 01:28:30PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 12/12/2016 12:11 PM, Simon Horman wrote:
>
> >Use recently added R-Car Gen 2 fallback binding for iii nodes in
>
> s/iii/iic/?
Yes, thanks for noticing that.
> >DT for r8a7790 SoC.
> >
> >This has no run-time effect for the current driver as the initialisation
> >sequence is the same for the SoC-specific binding for r8a7790 and the
> >fallback binding for R-Car Gen 2.
> >
> >Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> [...]
>
> MBR, Sergei
>
On Mon, Dec 12, 2016 at 02:42:29PM +0100, Geert Uytterhoeven wrote:
> Hi SImon,
>
> On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Use recently added R-Car Gen 2 fallback binding for iii nodes in
>
> As Sergei already pointed out: s/iii/iic/.
>
> You may also want to s/i2c/iic/ in the one-line summary, to avoid having
> multiple different patches with the same one-line summary (initially I was a
> bit confused by this, as Gmail grouped them together).
Yes, I meant to differentiate the subjects as you suggest.
I'll fix things up.
> These two comments apply to all iic DT patches in this series.
Got it.
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Sekhar Nori @ 2016-12-12 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5370936.ZbqF1HU8Jz@amdc3058>
Hi Bartlomiej,
On Monday 12 December 2016 06:15 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote:
>> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote:
>>> Arnd Bergmann <arnd@arndb.de> writes:
>>>
>>>> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
>>>>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
>>>>>>> This patch disables deprecated IDE subsystem in assabet_defconfig
>>>>>>> (no IDE host drivers are selected in this config so there is no
>>>>>>> valid reason to enable IDE subsystem itself).
>>>>>>>
>>>>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>>>
>>>>>> I think the series makes a lot of sense. I have checked your assertions
>>>>>> in the changelogs and found no flaws in your logic, so I think we should
>>>>>> take them all through arm-soc unless there are other concerns.
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Should I resend everything or just patches that were not reposted yet
>>>>> (the ones that were marked as RFT initially and got no feedback)?
>>>>
>>>> I'd be fine with just getting a pull request with all the patches that
>>>> had no negative feedback and that were not already applied (if any).
>>>>
>>>>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and
>>>>>> how you determined that they need it?
>>>>>
>>>>> The only such defconfig is davinci_all_defconfig which uses
>>>>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710).
>>>>>
>>>>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that
>>>>>> have no libata replacement, are there any others like that, or are
>>>>>> they all platforms that should in theory work with libata but need
>>>>>> testing?
>>>>>
>>>>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work
>>>>> with libata.
>>>>
>>>> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks
>>>> fairly straightforward (meaning someone has to do a few day's work)
>>>> to convert into a libata driver.
>>>>
>>>> As this is on on-chip controller that is part of a dm644x and dm646x,
>>>> it should also not be hard to test (as long as someone can find
>>>> a hard drive to plug in).
>>>
>>> I have a hard drive, but don't have any dm64xx hardware anymore to test
>>> this. My last working dm644x board died last year.
>>
>> I have a working DM6446 EVM. I was able to connect a hard drive to it
>> and do some basic tests with v4.6 kernel.
>>
>> I will look into converting the driver to libata. Might take some time
>> because this is unfamiliar territory for me.
>
> Do you need some help with it?
>
> I can provide you with draft driver patch if you want.
A draft driver patch will really help. I can test/debug. Otherwise, not
sure when I will really be able to get to this.
Regards,
Sekhar
^ permalink raw reply
* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Marc Zyngier @ 2016-12-12 13:50 UTC (permalink / raw)
To: linux-arm-kernel
Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
functionality based on TTBR0_EL1") added conditional PAN
enable/disable. Unfortunately, a typo prevents PAN from being
re-enabled once it has been disabled.
Restore the PAN functionnality by adding the missing '!'.
Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
Christoffer, any chance you could give this a go and let me know
if that fixes your issues?
arch/arm64/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 6986f56..d26750c 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -188,7 +188,7 @@ do { \
#define __uaccess_enable(alt) \
do { \
- if (uaccess_ttbr0_enable()) \
+ if (!uaccess_ttbr0_enable()) \
asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
CONFIG_ARM64_PAN)); \
} while (0)
--
2.1.4
^ permalink raw reply related
* EXT: imx-sdma UART series failed for i.MX51
From: Han, Nandor (GE Healthcare) @ 2016-12-12 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481538186.727700380@f399.i.mail.ru>
Hi Alexander,
Thanks for info. I have already posted a patch that probably will
fix this issue.
https://lkml.org/lkml/2016/10/11/319
It was already tested on imx6 and imx53. Let me know how it works.
Reference:
http://lists-archives.com/linux-kernel/28679793-ext-pre-4-9-rc-dma-regression-imx6-sound-etc.html
On 12/12/2016 12:23, Alexander Shiyan wrote:
> Hello all.
>
> Upgrading the kernel from version 4.7 (to latest) has resulted in inoperable for i.MX51 DMA.
> It appears on sound playback (fsl_ssi with DMA). The sound is intermittent and a feeling that
> the each sound channel eats a part of buffer from another channel.
> Git-bisect found a first bad commit "first bad commit: [5881826ded79cf3c3314ee2d84c3bfa94e111b42]
> dmaengine: imx-sdma - update the residue calculation for cyclic channels" and after revert this commit,
> the problem has gone.
>
> Additionally, I had to disable DMA for the UART, because the revert the patch above led to the
> inoperability of the UART receiving part, although even before the series of all UART-SDMA
> patches still functioned normally (with imx6q check commented out).
>
> Any ideas?
>
> Thanks.
>
> shc at shc /home/ARM/linux $ git bisect log
> git bisect start
> # good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
> git bisect good c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
> # bad: [2e972325da7a2984b9045844d4185f4406e7a4b0] Revert "USB debug"
> git bisect bad 2e972325da7a2984b9045844d4185f4406e7a4b0
> # bad: [41844e36206be90cd4d962ea49b0abc3612a99d0] Merge tag 'staging-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
<snip>
--
Regards,
Nandi
^ permalink raw reply
* [PATCH renesas/devel 13/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-14-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7794 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
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