* 答复: [PATCH v4 11/12] mm/memory-failure: increase queued recovery work's priority
From: gengdongjiu @ 2018-05-20 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516162829.14348-12-james.morse@arm.com>
>
> arm64 can take an NMI-like error notification when user-space steps in some corrupt memory. APEI's GHES code will call
> memory_failure_queue() to schedule the recovery work. We then return to user-space, possibly taking the fault again.
>
> Currently the arch code unconditionally signals user-space from this path, so we don't get stuck in this loop, but the affected process never
> benefits from memory_failure()s recovery work. To fix this we need to know the recovery work will run before we get back to user-space.
>
> Increase the priority of the recovery work by scheduling it on the system_highpri_wq, then try to bump the current task off this CPU so that
> the recover work starts immediately.
>
> Reported-by: Xie XiuQi <xiexiuqi@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
> Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
> CC: Xie XiuQi <xiexiuqi@huawei.com>
> CC: gengdongjiu <gengdongjiu@huawei.com>
Tested-by: gengdongjiu <gengdongjiu@huawei.com>
> ---
> mm/memory-failure.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 9d142b9b86dc..f0e69d7ac406 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -55,6 +55,7 @@
> #include <linux/hugetlb.h>
> #include <linux/memory_hotplug.h>
> #include <linux/mm_inline.h>
> +#include <linux/preempt.h>
> #include <linux/kfifo.h>
> #include <linux/ratelimit.h>
> #include "internal.h"
> @@ -1333,6 +1334,7 @@ static DEFINE_PER_CPU(struct memory_failure_cpu, memory_failure_cpu);
> */
> void memory_failure_queue(unsigned long pfn, int flags) {
> + int cpu = smp_processor_id();
> struct memory_failure_cpu *mf_cpu;
> unsigned long proc_flags;
> struct memory_failure_entry entry = {
> @@ -1342,11 +1344,14 @@ void memory_failure_queue(unsigned long pfn, int flags)
>
> mf_cpu = &get_cpu_var(memory_failure_cpu);
> spin_lock_irqsave(&mf_cpu->lock, proc_flags);
> - if (kfifo_put(&mf_cpu->fifo, entry))
> - schedule_work_on(smp_processor_id(), &mf_cpu->work);
> - else
> + if (kfifo_put(&mf_cpu->fifo, entry)) {
> + queue_work_on(cpu, system_highpri_wq, &mf_cpu->work);
> + set_tsk_need_resched(current);
> + preempt_set_need_resched();
> + } else {
> pr_err("Memory failure: buffer overflow when queuing memory failure at %#lx\n",
> pfn);
> + }
> spin_unlock_irqrestore(&mf_cpu->lock, proc_flags);
> put_cpu_var(memory_failure_cpu);
> }
> --
> 2.16.2
^ permalink raw reply
* [PATCH v3 1/2] soc: imx: gpcv2: Do not pass static memory as platform data
From: Shawn Guo @ 2018-05-20 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHQ1cqGCG0rwPcpoY+bnjcyupg18x1TvULJzvAjRxSkL6z1U_Q@mail.gmail.com>
On Sat, May 19, 2018 at 03:35:55PM -0700, Andrey Smirnov wrote:
> On Tue, Apr 10, 2018 at 11:32 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
> > Platform device core assumes the ownership of dev.platform_data as
> > well as that it is dynamically allocated and it will try to kfree it
> > as a part of platform_device_release(). Change the code to use
> > platform_device_add_data() n instead of a pointer to a static memory
> > to avoid causing a BUG() when calling platform_device_put().
> >
> > The problem can be reproduced by artificially enabling the error path
> > of platform_device_add() call (around line 357).
> >
> > Note that this change also allows us to constify imx7_pgc_domains,
> > since we no longer need to be able to modify it.
> >
>
> Shawn,
>
> What's the status of these two patches? Do I need to change anything
> or are they good to go?
The patches were queued on imx/drivers branch for a while. I forgot to
let you know. Sorry.
Shawn
^ permalink raw reply
* [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries
From: Manivannan Sadhasivam @ 2018-05-20 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180520051736.4842-1-manivannan.sadhasivam@linaro.org>
Add S900 pinctrl entries under ARCH_ACTIONS
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 640dabc4c311..9e1a17c9b4a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1125,10 +1125,12 @@ F: arch/arm/mach-actions/
F: arch/arm/boot/dts/owl-*
F: arch/arm64/boot/dts/actions/
F: drivers/clocksource/owl-*
+F: drivers/pinctrl/actions/*
F: drivers/soc/actions/
F: include/dt-bindings/power/owl-*
F: include/linux/soc/actions/
F: Documentation/devicetree/bindings/arm/actions.txt
+F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
F: Documentation/devicetree/bindings/power/actions,owl-sps.txt
F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
--
2.14.1
^ permalink raw reply related
* [PATCH v2 4/5] pinctrl: actions: Add gpio support for Actions S900 SoC
From: Manivannan Sadhasivam @ 2018-05-20 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180520051736.4842-1-manivannan.sadhasivam@linaro.org>
Add gpio support to pinctrl driver for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
drivers/pinctrl/actions/Kconfig | 1 +
drivers/pinctrl/actions/pinctrl-owl.c | 198 +++++++++++++++++++++++++++++++++
drivers/pinctrl/actions/pinctrl-owl.h | 20 ++++
drivers/pinctrl/actions/pinctrl-s900.c | 29 ++++-
4 files changed, 247 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/actions/Kconfig b/drivers/pinctrl/actions/Kconfig
index ede97cdbbc12..490927b4ea76 100644
--- a/drivers/pinctrl/actions/Kconfig
+++ b/drivers/pinctrl/actions/Kconfig
@@ -4,6 +4,7 @@ config PINCTRL_OWL
select PINMUX
select PINCONF
select GENERIC_PINCONF
+ select GPIOLIB
help
Say Y here to enable Actions Semi OWL pinctrl driver
diff --git a/drivers/pinctrl/actions/pinctrl-owl.c b/drivers/pinctrl/actions/pinctrl-owl.c
index ee090697b1e9..76243caa08c6 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.c
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -11,6 +11,7 @@
#include <linux/clk.h>
#include <linux/err.h>
+#include <linux/gpio/driver.h>
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
@@ -31,6 +32,7 @@
* struct owl_pinctrl - pinctrl state of the device
* @dev: device handle
* @pctrldev: pinctrl handle
+ * @chip: gpio chip
* @lock: spinlock to protect registers
* @soc: reference to soc_data
* @base: pinctrl register base address
@@ -38,6 +40,7 @@
struct owl_pinctrl {
struct device *dev;
struct pinctrl_dev *pctrldev;
+ struct gpio_chip chip;
raw_spinlock_t lock;
struct clk *clk;
const struct owl_pinctrl_soc_data *soc;
@@ -536,6 +539,190 @@ static struct pinctrl_desc owl_pinctrl_desc = {
.owner = THIS_MODULE,
};
+static const struct owl_gpio_port *
+owl_gpio_get_port(struct owl_pinctrl *pctrl, unsigned int *pin)
+{
+ unsigned int start = 0, i;
+
+ for (i = 0; i < pctrl->soc->nports; i++) {
+ const struct owl_gpio_port *port = &pctrl->soc->ports[i];
+
+ if (*pin >= start && *pin < start + port->pins) {
+ *pin -= start;
+ return port;
+ }
+
+ start += port->pins;
+ }
+
+ return NULL;
+}
+
+static void owl_gpio_update_reg(void __iomem *base, unsigned int pin, int flag)
+{
+ u32 val;
+
+ val = readl_relaxed(base);
+
+ if (flag)
+ val |= BIT(pin);
+ else
+ val &= ~BIT(pin);
+
+ writel_relaxed(val, base);
+}
+
+static int owl_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return -ENODEV;
+
+ gpio_base = pctrl->base + port->offset;
+
+ /*
+ * GPIOs have higher priority over other modules, so either setting
+ * them as OUT or IN is sufficient
+ */
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ owl_gpio_update_reg(gpio_base + port->outen, offset, true);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+
+ return 0;
+}
+
+static void owl_gpio_free(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ /* disable gpio output */
+ owl_gpio_update_reg(gpio_base + port->outen, offset, false);
+
+ /* disable gpio input */
+ owl_gpio_update_reg(gpio_base + port->inen, offset, false);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+}
+
+static int owl_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+ u32 val;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return -ENODEV;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ val = readl_relaxed(gpio_base + port->dat);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+
+ return !!(val & BIT(offset));
+}
+
+static void owl_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ owl_gpio_update_reg(gpio_base + port->dat, offset, value);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+}
+
+static int owl_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return -ENODEV;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ owl_gpio_update_reg(gpio_base + port->outen, offset, false);
+ owl_gpio_update_reg(gpio_base + port->inen, offset, true);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+
+ return 0;
+}
+
+static int owl_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int value)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return -ENODEV;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ owl_gpio_update_reg(gpio_base + port->inen, offset, false);
+ owl_gpio_update_reg(gpio_base + port->outen, offset, true);
+ owl_gpio_update_reg(gpio_base + port->dat, offset, value);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+
+ return 0;
+}
+
+static int owl_gpio_init(struct owl_pinctrl *pctrl)
+{
+ struct gpio_chip *chip;
+ int ret;
+
+ chip = &pctrl->chip;
+ chip->base = -1;
+ chip->ngpio = pctrl->soc->ngpios;
+ chip->label = dev_name(pctrl->dev);
+ chip->parent = pctrl->dev;
+ chip->owner = THIS_MODULE;
+ chip->of_node = pctrl->dev->of_node;
+
+ ret = gpiochip_add_data(&pctrl->chip, pctrl);
+ if (ret) {
+ dev_err(pctrl->dev, "failed to register gpiochip\n");
+ return ret;
+ }
+
+ return 0;
+}
+
int owl_pinctrl_probe(struct platform_device *pdev,
struct owl_pinctrl_soc_data *soc_data)
{
@@ -571,6 +758,13 @@ int owl_pinctrl_probe(struct platform_device *pdev,
owl_pinctrl_desc.pins = soc_data->pins;
owl_pinctrl_desc.npins = soc_data->npins;
+ pctrl->chip.direction_input = owl_gpio_direction_input;
+ pctrl->chip.direction_output = owl_gpio_direction_output;
+ pctrl->chip.get = owl_gpio_get;
+ pctrl->chip.set = owl_gpio_set;
+ pctrl->chip.request = owl_gpio_request;
+ pctrl->chip.free = owl_gpio_free;
+
pctrl->soc = soc_data;
pctrl->dev = &pdev->dev;
@@ -581,6 +775,10 @@ int owl_pinctrl_probe(struct platform_device *pdev,
return PTR_ERR(pctrl->pctrldev);
}
+ ret = owl_gpio_init(pctrl);
+ if (ret)
+ return ret;
+
platform_set_drvdata(pdev, pctrl);
return 0;
diff --git a/drivers/pinctrl/actions/pinctrl-owl.h b/drivers/pinctrl/actions/pinctrl-owl.h
index 448f81a6db3b..74342378937c 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.h
+++ b/drivers/pinctrl/actions/pinctrl-owl.h
@@ -114,6 +114,22 @@ struct owl_pinmux_func {
unsigned int ngroups;
};
+/**
+ * struct owl_gpio_port - Actions GPIO port info
+ * @offset: offset of the GPIO port.
+ * @pins: number of pins belongs to the GPIO port.
+ * @outen: offset of the output enable register.
+ * @inen: offset of the input enable register.
+ * @dat: offset of the data register.
+ */
+struct owl_gpio_port {
+ unsigned int offset;
+ unsigned int pins;
+ unsigned int outen;
+ unsigned int inen;
+ unsigned int dat;
+};
+
/**
* struct owl_pinctrl_soc_data - Actions pin controller driver configuration
* @pins: array describing all pins of the pin controller.
@@ -124,6 +140,8 @@ struct owl_pinmux_func {
* @ngroups: number of entries in @groups.
* @padinfo: array describing the pad info of this SoC.
* @ngpios: number of pingroups the driver should expose as GPIOs.
+ * @port: array describing all GPIO ports of this SoC.
+ * @nports: number of GPIO ports in this SoC.
*/
struct owl_pinctrl_soc_data {
const struct pinctrl_pin_desc *pins;
@@ -134,6 +152,8 @@ struct owl_pinctrl_soc_data {
unsigned int ngroups;
const struct owl_padinfo *padinfo;
unsigned int ngpios;
+ const struct owl_gpio_port *ports;
+ unsigned int nports;
};
int owl_pinctrl_probe(struct platform_device *pdev,
diff --git a/drivers/pinctrl/actions/pinctrl-s900.c b/drivers/pinctrl/actions/pinctrl-s900.c
index 08d93f8fc086..5503c7945764 100644
--- a/drivers/pinctrl/actions/pinctrl-s900.c
+++ b/drivers/pinctrl/actions/pinctrl-s900.c
@@ -33,6 +33,13 @@
#define PAD_SR1 (0x0274)
#define PAD_SR2 (0x0278)
+#define OWL_GPIO_PORT_A 0
+#define OWL_GPIO_PORT_B 1
+#define OWL_GPIO_PORT_C 2
+#define OWL_GPIO_PORT_D 3
+#define OWL_GPIO_PORT_E 4
+#define OWL_GPIO_PORT_F 5
+
#define _GPIOA(offset) (offset)
#define _GPIOB(offset) (32 + (offset))
#define _GPIOC(offset) (64 + (offset))
@@ -1814,6 +1821,24 @@ static struct owl_padinfo s900_padinfo[NUM_PADS] = {
[SGPIO3] = PAD_INFO_PULLCTL_ST(SGPIO3)
};
+#define OWL_GPIO_PORT(port, base, count, _outen, _inen, _dat) \
+ [OWL_GPIO_PORT_##port] = { \
+ .offset = base, \
+ .pins = count, \
+ .outen = _outen, \
+ .inen = _inen, \
+ .dat = _dat, \
+ }
+
+static const struct owl_gpio_port s900_gpio_ports[] = {
+ OWL_GPIO_PORT(A, 0x0000, 32, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(B, 0x000C, 32, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(C, 0x0018, 12, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(D, 0x0024, 30, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(E, 0x0030, 32, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(F, 0x00F0, 8, 0x0, 0x4, 0x8)
+};
+
static struct owl_pinctrl_soc_data s900_pinctrl_data = {
.padinfo = s900_padinfo,
.pins = (const struct pinctrl_pin_desc *)s900_pads,
@@ -1822,7 +1847,9 @@ static struct owl_pinctrl_soc_data s900_pinctrl_data = {
.nfunctions = ARRAY_SIZE(s900_functions),
.groups = s900_groups,
.ngroups = ARRAY_SIZE(s900_groups),
- .ngpios = NUM_GPIOS
+ .ngpios = NUM_GPIOS,
+ .ports = s900_gpio_ports,
+ .nports = ARRAY_SIZE(s900_gpio_ports)
};
static int s900_pinctrl_probe(struct platform_device *pdev)
--
2.14.1
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: actions: Add gpio line names to Bubblegum-96 board
From: Manivannan Sadhasivam @ 2018-05-20 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180520051736.4842-1-manivannan.sadhasivam@linaro.org>
Add gpio line names to Actions Semi S900 based Bubblegum-96 board.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 175 ++++++++++++++++++++++
1 file changed, 175 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
index ff043c961d75..d0ba35df9015 100644
--- a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
+++ b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
@@ -34,3 +34,178 @@
status = "okay";
clocks = <&cmu CLK_UART5>;
};
+
+/*
+ * GPIO name legend: proper name = the GPIO line is used as GPIO
+ * NC = not connected (pin out but not routed from the chip to
+ * anything the board)
+ * "[PER]" = pin is muxed for [peripheral] (not GPIO)
+ * LSEC = Low Speed External Connector
+ * HSEC = High Speed External Connector
+ *
+ * Line names are taken from the schematic "Schematics Bubblegum96"
+ * version v1.0
+ *
+ * For the lines routed to the external connectors the
+ * lines are named after the 96Boards CE Specification 1.0,
+ * Appendix "Expansion Connector Signal Description".
+ *
+ * When the 96Boards naming of a line and the schematic name of
+ * the same line are in conflict, the 96Boards specification
+ * takes precedence, which means that the external UART on the
+ * LSEC is named UART0 while the schematic and SoC names this
+ * UART2. Only exception is the I2C lines for which the schematic
+ * naming has been preferred. This is only for the informational
+ * lines i.e. "[FOO]", the GPIO named lines "GPIO-A" thru "GPIO-L"
+ * are the only ones actually used for GPIO.
+ */
+
+&pinctrl {
+ gpio-line-names =
+ "GPIO-A", /* GPIO_0, LSEC pin 23 */
+ "GPIO-B", /* GPIO_1, LSEC pin 24 */
+ "GPIO-C", /* GPIO_2, LSEC pin 25 */
+ "GPIO-D", /* GPIO_3, LSEC pin 26 */
+ "GPIO-E", /* GPIO_4, LSEC pin 27 */
+ "GPIO-F", /* GPIO_5, LSEC pin 28 */
+ "GPIO-G", /* GPIO_6, LSEC pin 29 */
+ "GPIO-H", /* GPIO_7, LSEC pin 30 */
+ "GPIO-I", /* GPIO_8, LSEC pin 31 */
+ "GPIO-J", /* GPIO_9, LSEC pin 32 */
+ "NC", /* GPIO_10 */
+ "NC", /* GPIO_11 */
+ "SIRQ2_1V8", /* GPIO_12 */
+ "PCM0_OUT", /* GPIO_13 */
+ "WIFI_LED", /* GPIO_14 */
+ "PCM0_SYNC", /* GPIO_15 */
+ "PCM0_CLK", /* GPIO_16 */
+ "PCM0_IN", /* GPIO_17 */
+ "BT_LED", /* GPIO_18 */
+ "LED0", /* GPIO_19 */
+ "LED1", /* GPIO_20 */
+ "JTAG_TCK", /* GPIO_21 */
+ "JTAG_TMS", /* GPIO_22 */
+ "JTAG_TDI", /* GPIO_23 */
+ "JTAG_TDO", /* GPIO_24 */
+ "[UART1_RxD]", /* GPIO_25, LSEC pin 13 */
+ "NC", /* GPIO_26 */
+ "[UART1_TxD]", /* GPIO_27, LSEC pin 11 */
+ "SD0_D0", /* GPIO_28 */
+ "SD0_D1", /* GPIO_29 */
+ "SD0_D2", /* GPIO_30 */
+ "SD0_D3", /* GPIO_31 */
+ "SD1_D0", /* GPIO_32 */
+ "SD1_D1", /* GPIO_33 */
+ "SD1_D2", /* GPIO_34 */
+ "SD1_D3", /* GPIO_35 */
+ "SD0_CMD", /* GPIO_36 */
+ "SD0_CLK", /* GPIO_37 */
+ "SD1_CMD", /* GPIO_38 */
+ "SD1_CLK", /* GPIO_39 */
+ "SPI0_SCLK", /* GPIO_40, LSEC pin 8 */
+ "SPI0_CS", /* GPIO_41, LSEC pin 12 */
+ "SPI0_DIN", /* GPIO_42, LSEC pin 10 */
+ "SPI0_DOUT", /* GPIO_43, LSEC pin 14 */
+ "I2C5_SDATA", /* GPIO_44, HSEC pin 36 */
+ "I2C5_SCLK", /* GPIO_45, HSEC pin 38 */
+ "UART0_RX", /* GPIO_46, LSEC pin 7 */
+ "UART0_TX", /* GPIO_47, LSEC pin 5 */
+ "UART0_RTSB", /* GPIO_48, LSEC pin 9 */
+ "UART0_CTSB", /* GPIO_49, LSEC pin 3 */
+ "I2C4_SCLK", /* GPIO_50, HSEC pin 32 */
+ "I2C4_SDATA", /* GPIO_51, HSEC pin 34 */
+ "I2C0_SCLK", /* GPIO_52 */
+ "I2C0_SDATA", /* GPIO_53 */
+ "I2C1_SCLK", /* GPIO_54, LSEC pin 15 */
+ "I2C1_SDATA", /* GPIO_55, LSEC pin 17 */
+ "I2C2_SCLK", /* GPIO_56, LSEC pin 19 */
+ "I2C2_SDATA", /* GPIO_57, LSEC pin 21 */
+ "CSI0_DN0", /* GPIO_58, HSEC pin 10 */
+ "CSI0_DP0", /* GPIO_59, HSEC pin 8 */
+ "CSI0_DN1", /* GPIO_60, HSEC pin 16 */
+ "CSI0_DP1", /* GPIO_61, HSEC pin 14 */
+ "CSI0_CN", /* GPIO_62, HSEC pin 4 */
+ "CSI0_CP", /* GPIO_63, HSEC pin 2 */
+ "CSI0_DN2", /* GPIO_64, HSEC pin 22 */
+ "CSI0_DP2", /* GPIO_65, HSEC pin 20 */
+ "CSI0_DN3", /* GPIO_66, HSEC pin 28 */
+ "CSI0_DP3", /* GPIO_67, HSEC pin 26 */
+ "[CLK0]", /* GPIO_68, HSEC pin 15 */
+ "CSI1_DN0", /* GPIO_69, HSEC pin 44 */
+ "CSI1_DP0", /* GPIO_70, HSEC pin 42 */
+ "CSI1_DN1", /* GPIO_71, HSEC pin 50 */
+ "CSI1_DP1", /* GPIO_72, HSEC pin 48 */
+ "CSI1_CN", /* GPIO_73, HSEC pin 56 */
+ "CSI1_CP", /* GPIO_74, HSEC pin 54 */
+ "[CLK1]", /* GPIO_75, HSEC pin 17 */
+ "[GPIOD0]", /* GPIO_76 */
+ "[GPIOD1]", /* GPIO_77 */
+ "BT_RST_N", /* GPIO_78 */
+ "EXT_DC_EN", /* GPIO_79 */
+ "[PCM_DI]", /* GPIO_80, LSEC pin 22 */
+ "[PCM_DO]", /* GPIO_81, LSEC pin 20 */
+ "[PCM_CLK]", /* GPIO_82, LSEC pin 18 */
+ "[PCM_FS]", /* GPIO_83, LSEC pin 16 */
+ "WAKE_BT", /* GPIO_84 */
+ "WL_REG_ON", /* GPIO_85 */
+ "NC", /* GPIO_86 */
+ "NC", /* GPIO_87 */
+ "NC", /* GPIO_88 */
+ "NC", /* GPIO_89 */
+ "NC", /* GPIO_90 */
+ "WIFI_WAKE", /* GPIO_91 */
+ "BT_WAKE", /* GPIO_92 */
+ "NC", /* GPIO_93 */
+ "OTG_EN2", /* GPIO_94 */
+ "OTG_EN", /* GPIO_95 */
+ "DSI_DP3", /* GPIO_96, HSEC pin 45 */
+ "DSI_DN3", /* GPIO_97, HSEC pin 47 */
+ "DSI_DP1", /* GPIO_98, HSEC pin 33 */
+ "DSI_DN1", /* GPIO_99, HSEC pin 35 */
+ "DSI_CP", /* GPIO_100, HSEC pin 21 */
+ "DSI_CN", /* GPIO_101, HSEC pin 23 */
+ "DSI_DP0", /* GPIO_102, HSEC pin 27 */
+ "DSI_DN0", /* GPIO_103, HSEC pin 29 */
+ "DSI_DP2", /* GPIO_104, HSEC pin 39 */
+ "DSI_DN2", /* GPIO_105, HSEC pin 41 */
+ "N0_D0", /* GPIO_106 */
+ "N0_D1", /* GPIO_107 */
+ "N0_D2", /* GPIO_108 */
+ "N0_D3", /* GPIO_109 */
+ "N0_D4", /* GPIO_110 */
+ "N0_D5", /* GPIO_111 */
+ "N0_D6", /* GPIO_112 */
+ "N0_D7", /* GPIO_113 */
+ "N0_DQS", /* GPIO_114 */
+ "N0_DQSN", /* GPIO_115 */
+ "NC", /* GPIO_116 */
+ "NC", /* GPIO_117 */
+ "NC", /* GPIO_118 */
+ "N0_CEB1", /* GPIO_119 */
+ "CARD_DT", /* GPIO_120 */
+ "N0_CEB3", /* GPIO_121 */
+ "SD_DAT0", /* GPIO_122, HSEC pin 1 */
+ "SD_DAT1", /* GPIO_123, HSEC pin 3 */
+ "SD_DAT2", /* GPIO_124, HSEC pin 5 */
+ "SD_DAT3", /* GPIO_125, HSEC pin 7 */
+ "NC", /* GPIO_126 */
+ "NC", /* GPIO_127 */
+ "[PWR_BTN_N]", /* GPIO_128, LSEC pin 4 */
+ "[RST_BTN_N]", /* GPIO_129, LSEC pin 6 */
+ "NC", /* GPIO_130 */
+ "SD_CMD", /* GPIO_131 */
+ "GPIO-L", /* GPIO_132, LSEC pin 34 */
+ "GPIO-K", /* GPIO_133, LSEC pin 33 */
+ "NC", /* GPIO_134 */
+ "SD_SCLK", /* GPIO_135 */
+ "NC", /* GPIO_136 */
+ "JTAG_TRST", /* GPIO_137 */
+ "I2C3_SCLK", /* GPIO_138 */
+ "LED2", /* GPIO_139 */
+ "LED3", /* GPIO_140 */
+ "I2C3_SDATA", /* GPIO_141 */
+ "UART3_RX", /* GPIO_142 */
+ "UART3_TX", /* GPIO_143 */
+ "UART3_RTSB", /* GPIO_144 */
+ "UART3_CTSB"; /* GPIO_145 */
+};
--
2.14.1
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: actions: Add gpio properties to pinctrl node for S900
From: Manivannan Sadhasivam @ 2018-05-20 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180520051736.4842-1-manivannan.sadhasivam@linaro.org>
Add gpio properties to pinctrl node for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
arch/arm64/boot/dts/actions/s900.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi b/arch/arm64/boot/dts/actions/s900.dtsi
index 0156483f0f4d..aa3a49b0d646 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -178,6 +178,9 @@
compatible = "actions,s900-pinctrl";
reg = <0x0 0xe01b0000 0x0 0x1000>;
clocks = <&cmu CLK_GPIO>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 0 146>;
+ #gpio-cells = <2>;
};
timer: timer at e0228000 {
--
2.14.1
^ permalink raw reply related
* [PATCH v2 1/5] dt-bindings: pinctrl: Add gpio bindings for Actions S900 SoC
From: Manivannan Sadhasivam @ 2018-05-20 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180520051736.4842-1-manivannan.sadhasivam@linaro.org>
Add gpio bindings for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
.../devicetree/bindings/pinctrl/actions,s900-pinctrl.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
index fb87c7d74f2e..8fb5a53775e8 100644
--- a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
@@ -8,6 +8,17 @@ Required Properties:
- reg: Should contain the register base address and size of
the pin controller.
- clocks: phandle of the clock feeding the pin controller
+- gpio-controller: Marks the device node as a GPIO controller.
+- gpio-ranges: Specifies the mapping between gpio controller and
+ pin-controller pins.
+- #gpio-cells: Should be two. The first cell is the gpio pin number
+ and the second cell is used for optional parameters.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Specifies the number of cells needed to encode an
+ interrupt. Shall be set to 2. The first cell
+ defines the interrupt number, the second encodes
+ the trigger flags described in
+ bindings/interrupt-controller/interrupts.txt
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
@@ -164,6 +175,11 @@ Example:
compatible = "actions,s900-pinctrl";
reg = <0x0 0xe01b0000 0x0 0x1000>;
clocks = <&cmu CLK_GPIO>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 0 146>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
uart2-default: uart2-default {
pinmux {
--
2.14.1
^ permalink raw reply related
* [PATCH v2 0/5] Add gpio support for Action Semi S900 SoC
From: Manivannan Sadhasivam @ 2018-05-20 5:17 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds gpio support for Actions Semi S900 SoC by extending
the pinctrl driver. There were previous patches submitted for adding a
standalone gpio driver based on gpiolib. But later on it has been realised
that the gpio functionality is closely tied with pinctrl subsystem for this
OWL family processors. So, having a separate gpio driver will make it hard
to add further functionalities in future. Hence, we decided to drop the
previous patches below adding a standalone gpio support:
dt-bindings: gpio: Add gpio nodes for Actions S900 SoC
arm64: dts: actions: Add S900 gpio nodes
arm64: dts: actions: Add gpio line names to Bubblegum-96 board
gpio: Add gpio driver for Actions OWL S900 SoC
MAINTAINERS: Add Actions Semi S900 pinctrl and gpio entries
This patchset consits of incremental patches which will apply with the
previous pinctrl series: Add Actions Semi S900 pinctrl and gpio support,
excluding the dropped patches mentioned above.
Thanks,
Mani
Changes in v2:
* Removed gpiochip_add_pin_range() function and added gpio-ranges property
in DT.
* Added Reviewed-by tag from Andy.
Manivannan Sadhasivam (5):
dt-bindings: pinctrl: Add gpio bindings for Actions S900 SoC
arm64: dts: actions: Add gpio properties to pinctrl node for S900
arm64: dts: actions: Add gpio line names to Bubblegum-96 board
pinctrl: actions: Add gpio support for Actions S900 SoC
MAINTAINERS: Add Actions Semi S900 pinctrl entries
.../bindings/pinctrl/actions,s900-pinctrl.txt | 16 ++
MAINTAINERS | 2 +
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 175 ++++++++++++++++++
arch/arm64/boot/dts/actions/s900.dtsi | 3 +
drivers/pinctrl/actions/Kconfig | 1 +
drivers/pinctrl/actions/pinctrl-owl.c | 198 +++++++++++++++++++++
drivers/pinctrl/actions/pinctrl-owl.h | 20 +++
drivers/pinctrl/actions/pinctrl-s900.c | 29 ++-
8 files changed, 443 insertions(+), 1 deletion(-)
--
2.14.1
^ permalink raw reply
* [GIT PULL] arm64: dts: uniphier: UniPhier DT updates for v4.18
From: Masahiro Yamada @ 2018-05-20 2:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Here are UniPhier DT (64bit) updates for the v4.18 merge window.
Please pull!
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt64-v4.18
for you to fetch changes up to b076ff8bddfba793d49bca14feb49a0e84f41843:
arm64: dts: uniphier: add syscon-phy-mode property to each ethernet
node (2018-04-25 00:21:14 +0900)
----------------------------------------------------------------
UniPhier ARM64 SoC DT updates for v4.18
- add more properties to ethernet nodes
----------------------------------------------------------------
Kunihiko Hayashi (2):
arm64: dts: uniphier: add clock-names and reset-names to ethernet node
arm64: dts: uniphier: add syscon-phy-mode property to each ethernet node
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 5 ++++-
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 3 +++
arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 8 +++++++-
3 files changed, 14 insertions(+), 2 deletions(-)
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.18
From: Masahiro Yamada @ 2018-05-20 2:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Here are UniPhier DT (32bit) updates for the v4.18 merge window.
Please pull!
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt-v4.18
for you to fetch changes up to 526f872b8492fbfb1a0f342e601bdc5ba322f16b:
ARM: dts: uniphier: add syscon-phy-mode property to each ethernet
node (2018-04-25 00:21:51 +0900)
----------------------------------------------------------------
UniPhier ARM SoC DT updates for v4.18
- add more properties to ethernet nodes
----------------------------------------------------------------
Kunihiko Hayashi (2):
ARM: dts: uniphier: add required clocks and resets to Pro4 ethernet node
ARM: dts: uniphier: add syscon-phy-mode property to each ethernet node
arch/arm/boot/dts/uniphier-pro4.dtsi | 10 +++++++---
arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +++
2 files changed, 10 insertions(+), 3 deletions(-)
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [linux-sunxi] [PATCH 10/15] drm/sun4i: Add support for R40 TV TCONs
From: Julian Calaby @ 2018-05-20 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGRGNgWumzhiiwJenOXRuRN0i-_2uY=YR5L+9m70HW2ibF=C7w@mail.gmail.com>
Hi Jernej,
On Sun, May 20, 2018 at 11:57 AM, Julian Calaby <julian.calaby@gmail.com> wrote:
> Hi Jernej,
>
> On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
>> R40 display pipeline has a lot of possible configurations. HDMI can be
>> connected to 2 different TCONs (out of 4) and mixers can be connected to
>> any TCON. All this must be configured in TCON TOP.
>>
>> Along with definition of TCON capabilities also add mux callback, which
>> can configure this complex pipeline.
>>
>> For now, only TCON TV is supported.
>>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> ---
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 39 ++++++++++++++++++++++++++++++
>> 1 file changed, 39 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index e0c562ce1c22..81b9551e4f78 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -1274,6 +1274,31 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
>> return 0;
>> }
>>
>> +static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
>> + const struct drm_encoder *encoder,
>> + int index)
>> +{
>> + if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
>> + sun8i_tcon_top_set_hdmi_src(tcon->tcon_top, index);
>> +
>> + sun8i_tcon_top_de_config(tcon->tcon_top, tcon->id,
>> + tcon_type_tv, index);
>> +
>> + return 0;
>> +}
>> +
>> +static int sun8i_r40_tcon_tv_set_mux_0(struct sun4i_tcon *tcon,
>> + const struct drm_encoder *encoder)
>> +{
>> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 0);
>> +}
>> +
>> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_tcon *tcon,
>> + const struct drm_encoder *encoder)
>> +{
>> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
>> +}
>
> Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
> If so, maybe we should add an index to the TCON quirks and have a
> common TCON-TOP set_mux function.
Actually, that only moves it up a level. Should it be a devicetree property?
Thanks,
--
Julian Calaby
Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [linux-sunxi] [PATCH 10/15] drm/sun4i: Add support for R40 TV TCONs
From: Julian Calaby @ 2018-05-20 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-11-jernej.skrabec@siol.net>
Hi Jernej,
On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> R40 display pipeline has a lot of possible configurations. HDMI can be
> connected to 2 different TCONs (out of 4) and mixers can be connected to
> any TCON. All this must be configured in TCON TOP.
>
> Along with definition of TCON capabilities also add mux callback, which
> can configure this complex pipeline.
>
> For now, only TCON TV is supported.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 39 ++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index e0c562ce1c22..81b9551e4f78 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1274,6 +1274,31 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
> return 0;
> }
>
> +static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder,
> + int index)
> +{
> + if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
> + sun8i_tcon_top_set_hdmi_src(tcon->tcon_top, index);
> +
> + sun8i_tcon_top_de_config(tcon->tcon_top, tcon->id,
> + tcon_type_tv, index);
> +
> + return 0;
> +}
> +
> +static int sun8i_r40_tcon_tv_set_mux_0(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 0);
> +}
> +
> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
> +}
Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
If so, maybe we should add an index to the TCON quirks and have a
common TCON-TOP set_mux function.
Thanks,
--
Julian Calaby
Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [linux-sunxi] [PATCH 07/15] dt-bindings: display: sun4i-drm: Add R40 HDMI pipeline
From: Julian Calaby @ 2018-05-20 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-8-jernej.skrabec@siol.net>
Hi Jernej,
On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> Missing compatibles and descriptions needed to implement R40 HDMI
> pipeline are added.
>
> For mixers only compatibles are added.
>
> TCON description is expanded with R40 TV TCON compatibles. If the SoC
> has TCON TOP unit, phandle to that unit has to be specified. Additional
> clock has to be specified if SoC has TCON TOP and TCON is TV TCON.
>
> New compatible is added for DWC HDMI PHY, which has additional clock
> specified.
There's a bunch of A64 related stuff mixed in here, is the R40
compatible with the A64's parts? If so, you should probably mention
that in the commit log.
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> .../bindings/display/sunxi/sun4i-drm.txt | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index a099957ab62a..634276f713e8 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -111,8 +112,9 @@ Required properties:
> - resets: phandle to the reset controller driving the PHY
> - reset-names: must be "phy"
>
> -H3 HDMI PHY requires additional clock:
> +H3 and A64 HDMI PHY requires additional clocks:
> - pll-0: parent of phy clock
> + - pll-1: second possible phy clock parent (A64 only)
Maybe split this into two:
H3 HDMI PHY ...
- pll-0: ...
A64 HDMI PHY ...
- pll-0: ...
- pll-1: ...
At the moment a quick reading implies that H3 needs pll-1.
Thanks,
--
Julian Calaby
Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [GIT PULL] ARM: SoC fixes
From: Olof Johansson @ 2018-05-20 1:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:
Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes
for you to fetch changes up to 709f490d5b594b9548577d2285ffeaad8a278b10:
Merge tag 'tegra-for-4.17-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into fixes (2018-05-19 17:58:32 -0700)
----------------------------------------------------------------
ARM: SoC fixes for 4.17-rc
A handful of fixes. I've been queuing them up a bit too long so the list
is longer than it otherwise would have been spread out across a few -rcs.
In general, it's a scattering of fixes across several platforms, nothing
truly serious enough to point out.
There's a slightly larger batch of them for the Davinci platforms due
to work to bring them back to life after some time, so there's a handful
of regressions, some of them going back very far, others more recent.
There's also a few patches fixing DT on Renesas platforms since they
changed some bindings without remaining backwards compatible, splitting
up describing LVDS as a proper bridge instead of having it as part of the
display unit. We could push for them to be backwards compatible with old
device trees, but it's likely to regress eventually if nobody's actually
using said compatibility.
----------------------------------------------------------------
Adam Ford (3):
ARM: dts: logicpd-som-lv: Fix WL127x Startup Issues
ARM: dts: logicpd-som-lv: Fix Audio Mute
ARM: dts: logicpd-som-lv: Fix pinmux controller references
Bhadram Varka (1):
arm64: tegra: Make BCM89610 PHY interrupt as active low
Cl?ment P?ron (1):
ARM: dts: cygnus: fix irq type for arm global timer
Dan Carpenter (1):
firmware: arm_scmi: Use after free in scmi_create_protocol_device()
Dmitry Osipenko (1):
ARM: dts: tegra20: Revert "Fix ULPI regression on Tegra20"
Etienne Carriere (1):
tee: check shm references are consistent in offset/size
Fabio Estevam (1):
ARM: dts: imx7s: Pass the 'fsl,sec-era' property
Graeme Smecher (1):
ARM: dts: correct missing "compatible" entry for ti81xx SoCs
Jann Horn (1):
tee: shm: fix use-after-free via temporarily dropped reference
Janusz Krzysztofik (1):
ARM: OMAP1: ams-delta: fix deferred_fiq handler
Laurent Pinchart (3):
ARM: dts: r8a7790: Convert to new LVDS DT bindings
ARM: dts: r8a7791: Convert to new LVDS DT bindings
ARM: dts: r8a7793: Convert to new LVDS DT bindings
Marek Szyprowski (1):
arm64: dts: exynos: Fix interrupt type for I2S1 device on Exynos5433
Masahiro Yamada (3):
arm64: dts: uniphier: fix input delay value for legacy mode of eMMC
reset: uniphier: fix USB clock line for LD20
arm64: dts: uniphier: stabilize ethernet of LD20 reference board
Maxime Chevallier (2):
ARM64: dts: marvell: armada-cp110: Add clocks for the xmdio node
ARM64: dts: marvell: armada-cp110: Add mg_core_clk for ethernet node
Nikita Yushchenko (1):
ARM: dts: imx51-zii-rdu1: fix touchscreen bindings
Olof Johansson (13):
Merge tag 'uniphier-fixes-v4.17' of git://git.kernel.org/.../masahiroy/linux-uniphier into fixes
Merge tag 'renesas-fixes-for-v4.17' of https://git.kernel.org/.../horms/renesas into fixes
Merge tag 'davinci-fixes-for-v4.17' of git://git.kernel.org/.../nsekhar/linux-davinci into fixes
Merge tag 'tegra-for-4.17-fixes' of git://git.kernel.org/.../tegra/linux into fixes
Merge tag 'tee-drv-fixes-for-4.17' of git://git.linaro.org/people/jens.wiklander/linux-tee into fixes
Merge tag 'arm-soc/for-4.17/devicetree-fixes' of https://github.com/Broadcom/stblinux into fixes
Merge tag 'omap-for-v17/fixes-rc4' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'scmi-fixes-4.17' of git://git.kernel.org/.../sudeep.holla/linux into fixes
Merge tag 'imx-fixes-4.17' of git://git.kernel.org/.../shawnguo/linux into fixes
Merge tag 'mvebu-fixes-4.17-1' of git://git.infradead.org/linux-mvebu into fixes
Merge tag 'reset-fixes-for-4.17' of git://git.pengutronix.de/pza/linux into fixes
Merge tag 'davinci-fixes-for-v4.17-part-2' of git://git.kernel.org/.../nsekhar/linux-davinci into fixes
Merge tag 'tegra-for-4.17-fixes-2' of git://git.kernel.org/.../tegra/linux into fixes
Russell King (1):
ARM: keystone: fix platform_domain_notifier array overrun
Sekhar Nori (11):
ARM: dts: da850: get rid of skeleton.dtsi
ARM: dts: da850-lcdk: add unit name for memory node
ARM: dts: da850: fix W=1 warnings with pinmux node
ARM: davinci: board-da830-evm: fix GPIO lookup for MMC/SD
ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD
ARM: davinci: board-omapl138-hawk: fix GPIO numbers for MMC/SD lookup
ARM: davinci: board-dm355-evm: fix broken networking
ARM: davinci: fix GPIO lookup for I2C
ARM: davinci: dm646x: fix timer interrupt generation
ARM: davinci: board-dm646x-evm: pass correct I2C adapter id for VPIF
ARM: davinci: board-dm646x-evm: set VPIF capture card name
Tero Kristo (1):
ARM: OMAP2+: powerdomain: use raw_smp_processor_id() for trace
Tony Lindgren (1):
Revert "ARM: dts: logicpd-som-lv: Fix pinmux controller references"
.../devicetree/bindings/net/marvell-pp2.txt | 9 +--
arch/arm/boot/dts/bcm-cygnus.dtsi | 2 +-
arch/arm/boot/dts/da850-lcdk.dts | 4 +-
arch/arm/boot/dts/da850.dtsi | 13 ++++-
arch/arm/boot/dts/dm8148-evm.dts | 2 +-
arch/arm/boot/dts/dm8148-t410.dts | 2 +-
arch/arm/boot/dts/dm8168-evm.dts | 2 +-
arch/arm/boot/dts/dra62x-j5eco-evm.dts | 2 +-
arch/arm/boot/dts/imx51-zii-rdu1.dts | 6 +-
arch/arm/boot/dts/imx7s.dtsi | 1 +
arch/arm/boot/dts/logicpd-som-lv.dtsi | 11 +++-
arch/arm/boot/dts/r8a7790-lager.dts | 22 ++++++--
arch/arm/boot/dts/r8a7790.dtsi | 65 +++++++++++++++++++---
arch/arm/boot/dts/r8a7791-koelsch.dts | 12 +++-
arch/arm/boot/dts/r8a7791-porter.dts | 16 +++++-
arch/arm/boot/dts/r8a7791.dtsi | 36 ++++++++++--
arch/arm/boot/dts/r8a7793-gose.dts | 10 +++-
arch/arm/boot/dts/r8a7793.dtsi | 37 ++++++++++--
arch/arm/boot/dts/tegra20.dtsi | 2 +-
arch/arm/mach-davinci/board-da830-evm.c | 9 ++-
arch/arm/mach-davinci/board-da850-evm.c | 9 ++-
arch/arm/mach-davinci/board-dm355-evm.c | 15 ++++-
arch/arm/mach-davinci/board-dm644x-evm.c | 10 +++-
arch/arm/mach-davinci/board-dm646x-evm.c | 5 +-
arch/arm/mach-davinci/board-omapl138-hawk.c | 10 +++-
arch/arm/mach-davinci/dm646x.c | 3 +-
arch/arm/mach-keystone/pm_domain.c | 1 +
arch/arm/mach-omap1/ams-delta-fiq.c | 28 +++++-----
arch/arm/mach-omap2/powerdomain.c | 4 +-
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 7 ++-
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 2 +-
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 2 +-
.../arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 8 +++
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 +-
arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 2 +-
drivers/firmware/arm_scmi/driver.c | 1 +
drivers/reset/reset-uniphier.c | 6 +-
drivers/tee/tee_core.c | 11 ++++
drivers/tee/tee_shm.c | 5 +-
40 files changed, 300 insertions(+), 96 deletions(-)
^ permalink raw reply
* [GIT PULL] arm64: tegra: Device tree fixes for v4.17
From: Olof Johansson @ 2018-05-20 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517160436.12180-1-thierry.reding@gmail.com>
On Thu, May 17, 2018 at 06:04:36PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.17-fixes-2
>
> for you to fetch changes up to 9df50ba76ac1485b844beffa1f3f5d9659d9cdaf:
>
> arm64: tegra: Make BCM89610 PHY interrupt as active low (2018-05-03 11:48:16 +0200)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> arm64: tegra: Device tree fixes for v4.17
>
> This contains a one-line update to the device tree of the Tegra186 P3310
> processor module, fixing the polarity of the PHY interrupt. Originally,
> this was queued to go into v4.18, but the PHY ID matching patch has now
> found its way into v4.17-rc5, which means that the PHY driver will know
> how to identify the PHY on this board and try to use the interrupt. This
> will unfortunately cause networking to break on P3310, hence why I think
> this should go into v4.17.
Merged, thanks.
-Olof
^ permalink raw reply
* [RHEL-8] arm64: add missing early clobber in atomic64_dec_if_positive()
From: Mark Salter @ 2018-05-20 0:17 UTC (permalink / raw)
To: linux-arm-kernel
When running a kernel compiled with gcc8 on a machine using LSE, I
get:
Unable to handle kernel paging request at virtual address 11111122222221
Mem abort info:
ESR = 0x96000021
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000021
CM = 0, WnR = 0
[0011111122222221] address between user and kernel address ranges
Internal error: Oops: 96000021 [#1] SMP
...
pstate: 20400009 (nzCv daif +PAN -UAO)
pc : test_atomic64+0x1360/0x155c
lr : 0x1111111122222222
sp : ffff00000bc6fd60
x29: ffff00000bc6fd60 x28: 0000000000000000
x27: 0000000000000000 x26: ffff000008f04460
x25: ffff000008de0584 x24: ffff000008e91060
x23: aaa31337c001d00e x22: 999202269ddfadeb
x21: aaa31337c001d00c x20: bbb42448e223f22f
x19: aaa31337c001d00d x18: 0000000000000010
x17: 0000000000000222 x16: 00000000000010e0
x15: ffffffffffffffff x14: ffff000009233c08
x13: ffff000089925a8f x12: ffff000009925a97
x11: ffff00000927f000 x10: ffff00000bc6fac0
x9 : 00000000ffffffd0 x8 : ffff00000853fdf8
x7 : 00000000deadbeef x6 : ffff00000bc6fda0
x5 : aaa31337c001d00d x4 : deadbeefdeafcafe
x3 : aaa31337c001d00d x2 : aaa31337c001d00e
x1 : 1111111122222222 x0 : 1111111122222221
Process swapper/0 (pid: 1, stack limit = 0x000000008209f908)
Call trace:
test_atomic64+0x1360/0x155c
test_atomics_init+0x10/0x28
do_one_initcall+0x134/0x160
kernel_init_freeable+0x18c/0x21c
kernel_init+0x18/0x108
ret_from_fork+0x10/0x1c
Code: f90023e1 f940001e f10007c0 540000ab (c8fefc00)
---[ end trace 29569e7320c6e926 ]---
The fault happens at the casal insn of inlined atomic64_dec_if_positive().
The inline asm code in that function has:
"1: ldr x30, %[v]\n"
" subs %[ret], x30, #1\n"
" b.lt 2f\n"
" casal x30, %[ret], %[v]\n"
" sub x30, x30, #1\n"
" sub x30, x30, %[ret]\n"
" cbnz x30, 1b\n"
"2:")
: [ret] "+r" (x0), [v] "+Q" (v->counter)
gcc8 used register x0 for both [ret] and [v] and the subs was
clobbering [v] before it was used for casal. Gcc is free to do
this because [ret] lacks an early clobber modifier. So add one
to tell gcc a separate register is needed for [v].
Signed-off-by: Mark Salter <msalter@redhat.com>
---
arch/arm64/include/asm/atomic_lse.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
index 9ef0797380cb..99fa69c9c3cf 100644
--- a/arch/arm64/include/asm/atomic_lse.h
+++ b/arch/arm64/include/asm/atomic_lse.h
@@ -435,7 +435,7 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
" sub x30, x30, %[ret]\n"
" cbnz x30, 1b\n"
"2:")
- : [ret] "+r" (x0), [v] "+Q" (v->counter)
+ : [ret] "+&r" (x0), [v] "+Q" (v->counter)
:
: __LL_SC_CLOBBERS, "cc", "memory");
--
2.17.0
^ permalink raw reply related
* [PATCH v3 1/2] soc: imx: gpcv2: Do not pass static memory as platform data
From: Andrey Smirnov @ 2018-05-19 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180410183210.28052-1-andrew.smirnov@gmail.com>
On Tue, Apr 10, 2018 at 11:32 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> Platform device core assumes the ownership of dev.platform_data as
> well as that it is dynamically allocated and it will try to kfree it
> as a part of platform_device_release(). Change the code to use
> platform_device_add_data() n instead of a pointer to a static memory
> to avoid causing a BUG() when calling platform_device_put().
>
> The problem can be reproduced by artificially enabling the error path
> of platform_device_add() call (around line 357).
>
> Note that this change also allows us to constify imx7_pgc_domains,
> since we no longer need to be able to modify it.
>
Shawn,
What's the status of these two patches? Do I need to change anything
or are they good to go?
Thanks,
Andrey Smirnov
^ permalink raw reply
* [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function
From: Dmitry Osipenko @ 2018-05-19 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507a66ab9ab530a6d71db7a74f11ddfb@agner.ch>
On 16.04.2018 21:21, Stefan Agner wrote:
> On 16.04.2018 18:08, Stephen Warren wrote:
>> On 04/16/2018 09:56 AM, Stefan Agner wrote:
>>> On 27.03.2018 14:16, Dmitry Osipenko wrote:
>>>> On 27.03.2018 14:54, Robin Murphy wrote:
>>>>> On 26/03/18 22:20, Dmitry Osipenko wrote:
>>>>>> On 25.03.2018 21:09, Stefan Agner wrote:
>>>>>>> As documented in GCC naked functions should only use Basic asm
>>>>>>> syntax. The Extended asm or mixture of Basic asm and "C" code is
>>>>>>> not guaranteed. Currently this works because it was hard coded
>>>>>>> to follow and check GCC behavior for arguments and register
>>>>>>> placement.
>>>>>>>
>>>>>>> Furthermore with clang using parameters in Extended asm in a
>>>>>>> naked function is not supported:
>>>>>>> ?? arch/arm/firmware/trusted_foundations.c:47:10: error: parameter
>>>>>>> ?????????? references not allowed in naked functions
>>>>>>> ???????????????? : "r" (type), "r" (arg1), "r" (arg2)
>>>>>>> ??????????????????????? ^
>>>>>>>
>>>>>>> Use a regular function to be more portable. This aligns also with
>>>>>>> the other smc call implementations e.g. in qcom_scm-32.c and
>>>>>>> bcm_kona_smc.c.
>>>>>>>
>>>>>>> Cc: Dmitry Osipenko <digetx@gmail.com>
>>>>>>> Cc: Stephen Warren <swarren@nvidia.com>
>>>>>>> Cc: Thierry Reding <treding@nvidia.com>
>>>>>>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>>>>>>> ---
>>>>>>> Changes in v2:
>>>>>>> - Keep stmfd/ldmfd to avoid potential ABI issues
>>>>>>>
>>>>>>> ? arch/arm/firmware/trusted_foundations.c | 14 +++++++++-----
>>>>>>> ? 1 file changed, 9 insertions(+), 5 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/firmware/trusted_foundations.c
>>>>>>> b/arch/arm/firmware/trusted_foundations.c
>>>>>>> index 3fb1b5a1dce9..689e6565abfc 100644
>>>>>>> --- a/arch/arm/firmware/trusted_foundations.c
>>>>>>> +++ b/arch/arm/firmware/trusted_foundations.c
>>>>>>> @@ -31,21 +31,25 @@
>>>>>>> ? ? static unsigned long cpu_boot_addr;
>>>>>>> ? -static void __naked tf_generic_smc(u32 type, u32 arg1, u32 arg2)
>>>>>>> +static void tf_generic_smc(u32 type, u32 arg1, u32 arg2)
>>>>>>> ? {
>>>>>>> +??? register u32 r0 asm("r0") = type;
>>>>>>> +??? register u32 r1 asm("r1") = arg1;
>>>>>>> +??? register u32 r2 asm("r2") = arg2;
>>>>>>> +
>>>>>>> ????? asm volatile(
>>>>>>> ????????? ".arch_extension??? sec\n\t"
>>>>>>> -??????? "stmfd??? sp!, {r4 - r11, lr}\n\t"
>>>>>>> +??????? "stmfd??? sp!, {r4 - r11}\n\t"
>>>>>>> ????????? __asmeq("%0", "r0")
>>>>>>> ????????? __asmeq("%1", "r1")
>>>>>>> ????????? __asmeq("%2", "r2")
>>>>>>> ????????? "mov??? r3, #0\n\t"
>>>>>>> ????????? "mov??? r4, #0\n\t"
>>>>>>> ????????? "smc??? #0\n\t"
>>>>>>> -??????? "ldmfd??? sp!, {r4 - r11, pc}"
>>>>>>> +??????? "ldmfd??? sp!, {r4 - r11}\n\t"
>>>>>>> ????????? :
>>>>>>> -??????? : "r" (type), "r" (arg1), "r" (arg2)
>>>>>>> -??????? : "memory");
>>>>>>> +??????? : "r" (r0), "r" (r1), "r" (r2)
>>>>>>> +??????? : "memory", "r3", "r12", "lr");
>>>>>>
>>>>>> Although seems "lr" won't be affected by SMC invocation because it should be
>>>>>> banked and hence could be omitted entirely from the code. Maybe somebody could
>>>>>> confirm this.
>>>>> Strictly per the letter of the architecture, the SMC could be trapped to Hyp
>>>>> mode, and a hypervisor might clobber LR_usr in the process of forwarding the
>>>>> call to the firmware secure monitor (since Hyp doesn't have a banked LR of its
>>>>> own). Admittedly there are probably no real systems with the appropriate
>>>>> hardware/software combination to hit that, but on the other hand if this gets
>>>>> inlined where the compiler has already created a stack frame then an LR clobber
>>>>> is essentially free, so I reckon we're better off keeping it for reassurance.
>>>>> This isn't exactly a critical fast path anyway.
>>>>
>>>> Okay, thank you for the clarification.
>>>
>>> So it seems this change is fine?
>>>
>>> Stephen, you picked up changes for this driver before, is this patch
>>> going through your tree?
>>
>> You had best ask Thierry; he's taken over Tegra maintenance upstream.
>> But that said, don't files in arch/arm go through Russell?
>
> I think the last patches applied to that file went through your tree.
>
> Thierry, Russel, any preferences?
I've been preparing patches for upstream to add initial support of L2 cache
maintance to TF / Tegra30 and noticed that without this patch I'm getting a hang
early in boot. That is because before this patch registers store / restore was
incorrect, probably the premature return (lr -> pc) causes stack corruption. Not
sure whether it's worth to backport this patch, but I want to see it at least in
-next.
Thierry, please take care of this patch. Thanks.
^ permalink raw reply
* [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table
From: Janusz Krzysztofik @ 2018-05-19 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VcUxjubx=zOGyCjmpjCk5RBLPCaHcaOieDie9LdTCa+5g@mail.gmail.com>
On Saturday, May 19, 2018 8:00:38 PM CEST Andy Shevchenko wrote:
> On Sat, May 19, 2018 at 2:15 AM, Janusz Krzysztofik <jmkrzyszt@gmail.com>
wrote:
> > On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote:
> >> On Sat, May 19, 2018 at 12:09 AM, Janusz Krzysztofik
> >>
> >> <jmkrzyszt@gmail.com> wrote:
> >> > + gpiod_rdy = devm_gpiod_get_optional(&pdev->dev, "rdy",
> >> > GPIOD_IN);
> >> > + if (!IS_ERR_OR_NULL(gpiod_rdy)) {
> >>
> >> So, is it optional or not at the end?
> >> If it is, why do we check for NULL?
> >
> > As far as I can understand, nand_chip->dev_ready() callback is optional.
> > That's why I decided to use the _optional variant of devm_gpiod_get(). In
> > case of ams-delta, the dev_ready() callback depends on availability of
> > the 'rdy' GPIO pin. As a consequence, I'm checking for both NULL and ERR
> > in order to decide if dev_ready() will be supported.
> >
> > I can pretty well replace it with the standard form and check for ERR only
> > if the purpose of the _optional form is different.
>
> NULL check in practice discards the _optional part of gpiod_get(). So,
> either you use non-optional variant and decide how to handle an
> errors, or user _optional w/o NULL check.
OK, I'm going to use something like the below while submitting v2:
- gpiod_rdy = devm_gpiod_get_optional(&pdev->dev, "rdy", GPIOD_IN);
- if (!IS_ERR_OR_NULL(gpiod_rdy)) {
- this->dev_ready = ams_delta_nand_ready;
- } else {
- this->dev_ready = NULL;
- pr_notice("Couldn't request gpio for Delta NAND ready.\n");
+ priv->gpiod_rdy = devm_gpiod_get_optional(&pdev->dev, "rdy",
+ GPIOD_IN);
+ if (IS_ERR(priv->gpiod_rdy)) {
+ err = PTR_ERR(priv->gpiod_nwp);
+ dev_warn(&pdev->dev, "RDY GPIO request failed (%d)\n", err);
+ goto err_gpiod;
}
+ if (priv->gpiod_rdy)
+ this->dev_ready = ams_delta_nand_ready;
>
> >> > +err_gpiod:
> >> > + if (err == -ENODEV || err == -ENOENT)
> >> > + err = -EPROBE_DEFER;
> >>
> >> Hmm...
> >
> > Amstrad Delta uses gpio-mmio driver. Unfortunatelty that driver is not
> > availble before device init phase, unlike other crucial GPIO drivers which
> > are initialized earlier, e.g. during the postcore or at latetst the
> > subsys phase. Hence, devices which depend on GPIO pins provided by
> > gpio-mmio must either be declared late or fail softly so they get another
> > chance of being probed succesfully.
> >
> > I thought of replacing the gpio-mmio platform driver with bgpio functions
> > it exports but for now I haven't implemented it, not even shared the
> > idea.
> >
> > Does it really hurt to return -EPROBE_DEFER if a GPIO pin can't be
> > obtained?
> I'm only concerned if it would be an infinite defer in the case when
> driver will never appear.
> But I don't remember the details.
Deferred probes are handled effectively during late_initcall, no risk of
infinite defer, see drivers/base/dd.c for details.
Thanks,
Janusz
^ permalink raw reply
* [arm:sa1100 80/87] ERROR: "ipaq_micro_tx_msg" [arch/arm/mach-sa1100/h3xxx-sleeve.ko] undefined!
From: kbuild test robot @ 2018-05-19 20:59 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git sa1100
head: 6713179ef01a294e21b4b2ff808a8d30155af2ad
commit: 6b9bc7e8128e38bc39eea71789c6e914f13b6d5a [80/87] ARM: sa1100/h3xxx: sleeve support
config: arm-neponset_defconfig (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
git checkout 6b9bc7e8128e38bc39eea71789c6e914f13b6d5a
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "ipaq_micro_tx_msg" [arch/arm/mach-sa1100/h3xxx-sleeve.ko] undefined!
---
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: 15702 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180520/f81d3c9c/attachment-0001.gz>
^ permalink raw reply
* [arm:zii 12/20] net/dsa/slave.c:1169:26: sparse: incorrect type in initializer (different argument counts)
From: kbuild test robot @ 2018-05-19 20:53 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git zii
head: 58e9ee3ee4dd4574170181ed8751766e234a33a8
commit: 94d9d1358684609c19eceb53aae76f40435b69dc [12/20] net: dsa: Plug in PHYLINK support
reproduce:
# apt-get install sparse
git checkout 94d9d1358684609c19eceb53aae76f40435b69dc
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
net/dsa/slave.c:434:13: sparse: incorrect type in initializer (different address spaces) @@ expected void const [noderef] <asn:3>*__vpp_verify @@ got const [noderef] <asn:3>*__vpp_verify @@
net/dsa/slave.c:434:13: expected void const [noderef] <asn:3>*__vpp_verify
net/dsa/slave.c:434:13: got struct pcpu_sw_netstats *<noident>
net/dsa/slave.c:550:16: sparse: undefined identifier 'phylink_ethtool_get_module_info'
net/dsa/slave.c:558:16: sparse: undefined identifier 'phylink_ethtool_get_module_eeprom'
net/dsa/slave.c:593:21: sparse: incorrect type in initializer (different address spaces) @@ expected void const [noderef] <asn:3>*__vpp_verify @@ got const [noderef] <asn:3>*__vpp_verify @@
net/dsa/slave.c:593:21: expected void const [noderef] <asn:3>*__vpp_verify
net/dsa/slave.c:593:21: got struct pcpu_sw_netstats *<noident>
net/dsa/slave.c:953:21: sparse: incorrect type in initializer (different address spaces) @@ expected void const [noderef] <asn:3>*__vpp_verify @@ got const [noderef] <asn:3>*__vpp_verify @@
net/dsa/slave.c:953:21: expected void const [noderef] <asn:3>*__vpp_verify
net/dsa/slave.c:953:21: got struct pcpu_sw_netstats *<noident>
>> net/dsa/slave.c:1169:26: sparse: incorrect type in initializer (different argument counts) @@ expected void ( *mac_link_down )( ... ) @@ got void ( *mac_link_down )( ... ) @@
net/dsa/slave.c:1169:26: expected void ( *mac_link_down )( ... )
net/dsa/slave.c:1169:26: got void ( *<noident> )( ... )
>> net/dsa/slave.c:1170:24: sparse: incorrect type in initializer (incompatible argument 3 (different base types)) @@ expected void ( *mac_link_up )( ... ) @@ got void ( *mac_link_up )( ... ) @@
net/dsa/slave.c:1170:24: expected void ( *mac_link_up )( ... )
net/dsa/slave.c:1170:24: got void ( *<noident> )( ... )
net/dsa/slave.c:1332:20: sparse: incorrect type in assignment (different address spaces) @@ expected struct pcpu_sw_netstats *stats64 @@ got struct pcpu_sw_nestruct pcpu_sw_netstats *stats64 @@
net/dsa/slave.c:1332:20: expected struct pcpu_sw_netstats *stats64
net/dsa/slave.c:1332:20: got struct pcpu_sw_netstats [noderef] <asn:3>*pcpu_stats
net/dsa/slave.c:1365:22: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:3>*__pdata @@ got stvoid [noderef] <asn:3>*__pdata @@
net/dsa/slave.c:1365:22: expected void [noderef] <asn:3>*__pdata
net/dsa/slave.c:1365:22: got struct pcpu_sw_netstats *stats64
net/dsa/slave.c:1382:22: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:3>*__pdata @@ got stvoid [noderef] <asn:3>*__pdata @@
net/dsa/slave.c:1382:22: expected void [noderef] <asn:3>*__pdata
net/dsa/slave.c:1382:22: got struct pcpu_sw_netstats *stats64
net/dsa/slave.c:550:47: sparse: call with no type!
net/dsa/slave.c:558:49: sparse: call with no type!
net/dsa/slave.c: In function 'dsa_slave_get_module_info':
net/dsa/slave.c:550:9: error: implicit declaration of function 'phylink_ethtool_get_module_info'; did you mean 'phylink_ethtool_get_pauseparam'? [-Werror=implicit-function-declaration]
return phylink_ethtool_get_module_info(dp->pl, modinfo);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
phylink_ethtool_get_pauseparam
net/dsa/slave.c: In function 'dsa_slave_get_module_eeprom':
net/dsa/slave.c:558:9: error: implicit declaration of function 'phylink_ethtool_get_module_eeprom'; did you mean 'phylink_ethtool_get_pauseparam'? [-Werror=implicit-function-declaration]
return phylink_ethtool_get_module_eeprom(dp->pl, ee, buf);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
phylink_ethtool_get_pauseparam
net/dsa/slave.c: At top level:
net/dsa/slave.c:1169:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.mac_link_down = dsa_slave_phylink_mac_link_down,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/dsa/slave.c:1169:19: note: (near initialization for 'dsa_slave_phylink_mac_ops.mac_link_down')
net/dsa/slave.c:1170:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.mac_link_up = dsa_slave_phylink_mac_link_up,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/dsa/slave.c:1170:17: note: (near initialization for 'dsa_slave_phylink_mac_ops.mac_link_up')
cc1: some warnings being treated as errors
vim +1169 net/dsa/slave.c
1163
1164 static const struct phylink_mac_ops dsa_slave_phylink_mac_ops = {
1165 .validate = dsa_slave_phylink_validate,
1166 .mac_link_state = dsa_slave_phylink_mac_link_state,
1167 .mac_config = dsa_slave_phylink_mac_config,
1168 .mac_an_restart = dsa_slave_phylink_mac_an_restart,
> 1169 .mac_link_down = dsa_slave_phylink_mac_link_down,
> 1170 .mac_link_up = dsa_slave_phylink_mac_link_up,
1171 };
1172
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [arm:zii 12/20] net//dsa/slave.c:1169:19: error: initialization from incompatible pointer type
From: kbuild test robot @ 2018-05-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git zii
head: 58e9ee3ee4dd4574170181ed8751766e234a33a8
commit: 94d9d1358684609c19eceb53aae76f40435b69dc [12/20] net: dsa: Plug in PHYLINK support
config: i386-randconfig-x012-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 94d9d1358684609c19eceb53aae76f40435b69dc
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net//dsa/slave.c: In function 'dsa_slave_get_module_info':
net//dsa/slave.c:550:9: error: implicit declaration of function 'phylink_ethtool_get_module_info'; did you mean 'phylink_ethtool_get_pauseparam'? [-Werror=implicit-function-declaration]
return phylink_ethtool_get_module_info(dp->pl, modinfo);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
phylink_ethtool_get_pauseparam
net//dsa/slave.c: In function 'dsa_slave_get_module_eeprom':
net//dsa/slave.c:558:9: error: implicit declaration of function 'phylink_ethtool_get_module_eeprom'; did you mean 'phylink_ethtool_get_pauseparam'? [-Werror=implicit-function-declaration]
return phylink_ethtool_get_module_eeprom(dp->pl, ee, buf);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
phylink_ethtool_get_pauseparam
net//dsa/slave.c: At top level:
>> net//dsa/slave.c:1169:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.mac_link_down = dsa_slave_phylink_mac_link_down,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net//dsa/slave.c:1169:19: note: (near initialization for 'dsa_slave_phylink_mac_ops.mac_link_down')
net//dsa/slave.c:1170:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.mac_link_up = dsa_slave_phylink_mac_link_up,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net//dsa/slave.c:1170:17: note: (near initialization for 'dsa_slave_phylink_mac_ops.mac_link_up')
cc1: some warnings being treated as errors
vim +1169 net//dsa/slave.c
1163
1164 static const struct phylink_mac_ops dsa_slave_phylink_mac_ops = {
1165 .validate = dsa_slave_phylink_validate,
1166 .mac_link_state = dsa_slave_phylink_mac_link_state,
1167 .mac_config = dsa_slave_phylink_mac_config,
1168 .mac_an_restart = dsa_slave_phylink_mac_an_restart,
> 1169 .mac_link_down = dsa_slave_phylink_mac_link_down,
1170 .mac_link_up = dsa_slave_phylink_mac_link_up,
1171 };
1172
---
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: 33520 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180520/1dd4f711/attachment-0001.gz>
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 730/935] drivers/crypto/zynqmp-sha.c:133:3: error: implicit declaration of function '__flush_cache_user_range'; did you mean 'clflush_cache_range'?
From: kbuild test robot @ 2018-05-19 18:31 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: 6b8ad2b85bb2279d13a436396238f0fd150138d1
commit: 5cccc03f86f27a3e9e76ba7a863eaf2f8506e9e2 [730/935] crypto: zynqmp: Use new firmware ops
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 5cccc03f86f27a3e9e76ba7a863eaf2f8506e9e2
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/crypto/zynqmp-sha.c: In function 'zynqmp_sha_update':
>> drivers/crypto/zynqmp-sha.c:133:3: error: implicit declaration of function '__flush_cache_user_range'; did you mean 'clflush_cache_range'? [-Werror=implicit-function-declaration]
__flush_cache_user_range((unsigned long)kbuf,
^~~~~~~~~~~~~~~~~~~~~~~~
clflush_cache_range
cc1: some warnings being treated as errors
vim +133 drivers/crypto/zynqmp-sha.c
3abec383 Nava kishore Manne 2017-09-19 111
3abec383 Nava kishore Manne 2017-09-19 112 static int zynqmp_sha_update(struct ahash_request *req)
3abec383 Nava kishore Manne 2017-09-19 113 {
3abec383 Nava kishore Manne 2017-09-19 114 struct zynqmp_sha_ctx *tctx = crypto_tfm_ctx(req->base.tfm);
3abec383 Nava kishore Manne 2017-09-19 115 struct zynqmp_sha_dev *dd = tctx->dd;
5cccc03f Rajan Vaja 2018-03-01 116 const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
3abec383 Nava kishore Manne 2017-09-19 117 char *kbuf;
3abec383 Nava kishore Manne 2017-09-19 118 size_t dma_size = req->nbytes;
3abec383 Nava kishore Manne 2017-09-19 119 dma_addr_t dma_addr;
3abec383 Nava kishore Manne 2017-09-19 120 int ret;
3abec383 Nava kishore Manne 2017-09-19 121
3abec383 Nava kishore Manne 2017-09-19 122 if (!req->nbytes)
3abec383 Nava kishore Manne 2017-09-19 123 return 0;
3abec383 Nava kishore Manne 2017-09-19 124
5cccc03f Rajan Vaja 2018-03-01 125 if (!eemi_ops || !eemi_ops->sha_hash)
5cccc03f Rajan Vaja 2018-03-01 126 return -ENOTSUPP;
5cccc03f Rajan Vaja 2018-03-01 127
3abec383 Nava kishore Manne 2017-09-19 128 kbuf = dma_alloc_coherent(dd->dev, dma_size, &dma_addr, GFP_KERNEL);
3abec383 Nava kishore Manne 2017-09-19 129 if (!kbuf)
3abec383 Nava kishore Manne 2017-09-19 130 return -ENOMEM;
3abec383 Nava kishore Manne 2017-09-19 131
3abec383 Nava kishore Manne 2017-09-19 132 scatterwalk_map_and_copy(kbuf, req->src, 0, req->nbytes, 0);
3abec383 Nava kishore Manne 2017-09-19 @133 __flush_cache_user_range((unsigned long)kbuf,
3abec383 Nava kishore Manne 2017-09-19 134 (unsigned long)kbuf + dma_size);
5cccc03f Rajan Vaja 2018-03-01 135 ret = eemi_ops->sha_hash(dma_addr, req->nbytes, ZYNQMP_SHA3_UPDATE);
3abec383 Nava kishore Manne 2017-09-19 136 dma_free_coherent(dd->dev, dma_size, kbuf, dma_addr);
3abec383 Nava kishore Manne 2017-09-19 137
3abec383 Nava kishore Manne 2017-09-19 138 return ret;
3abec383 Nava kishore Manne 2017-09-19 139 }
3abec383 Nava kishore Manne 2017-09-19 140
:::::: The code at line 133 was first introduced by commit
:::::: 3abec3839538ef5fe79c2873360d84cc92b4df25 crypto: zynqmp-sha: Adopted SHA3 support for ZynqMP Soc
:::::: TO: Nava kishore Manne <nava.manne@xilinx.com>
:::::: CC: Michal Simek <michal.simek@xilinx.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 61326 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180520/ad913ab3/attachment-0001.gz>
^ permalink raw reply
* [PATCH 15/15] ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
From: Jernej Skrabec @ 2018-05-19 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-1-jernej.skrabec@siol.net>
Since HDMI can be considered as main output, most capable mixer is
connected to it (mixer0).
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 50 +++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..66b492ad5847 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -93,6 +104,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -101,6 +116,22 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_tcon_tv0: endpoint {
+ remote-endpoint = <&tcon_tv0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c0 {
status = "okay";
@@ -161,6 +192,12 @@
regulator-name = "vcc-wifi";
};
+&mixer0_out {
+ mixer0_out_tcon_tv0: endpoint {
+ remote-endpoint = <&tcon_tv0_in_mixer0>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_dcdc1>;
bus-width = <4>;
@@ -195,6 +232,19 @@
status = "okay";
};
+&tcon_tv0_in {
+ tcon_tv0_in_mixer0: endpoint {
+ remote-endpoint = <&mixer0_out_tcon_tv0>;
+ };
+};
+
+&tcon_tv0_out {
+ tcon_tv0_out_hdmi: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&hdmi_in_tcon_tv0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.17.0
^ permalink raw reply related
* [PATCH 14/15] ARM: dts: sun8i: r40: Add HDMI pipeline
From: Jernej Skrabec @ 2018-05-19 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-1-jernej.skrabec@siol.net>
Add all entries needed for HDMI to function properly.
Since R40 has highly configurable pipeline, both mixers and both TCON
TVs are added. Board specific DT should then connect them together to
best fit the purpose of the board.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
arch/arm/boot/dts/sun8i-r40.dtsi | 166 +++++++++++++++++++++++++++++++
1 file changed, 166 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..6d5407964997 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -42,8 +42,11 @@
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun8i-de2.h>
#include <dt-bindings/clock/sun8i-r40-ccu.h>
+#include <dt-bindings/clock/sun8i-tcon-top.h>
#include <dt-bindings/reset/sun8i-r40-ccu.h>
+#include <dt-bindings/reset/sun8i-de2.h>
/ {
#address-cells = <1>;
@@ -99,12 +102,70 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-r40-display-engine",
+ "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ display_clocks: clock at 1000000 {
+ compatible = "allwinner,sun8i-r40-de2-clk",
+ "allwinner,sun8i-h3-de2-clk";
+ reg = <0x01000000 0x100000>;
+ clocks = <&ccu CLK_DE>,
+ <&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer at 1100000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-0";
+ reg = <0x01100000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+ <&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ mixer1: mixer at 1200000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-1";
+ reg = <0x01200000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+ <&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
nmi_intc: interrupt-controller at 1c00030 {
compatible = "allwinner,sun7i-a20-sc-nmi";
interrupt-controller;
@@ -451,6 +512,70 @@
#size-cells = <0>;
};
+ tcon_top: tcon-top at 1c70000 {
+ compatible = "allwinner,sun8i-r40-tcon-top";
+ reg = <0x01c70000 0x1000>;
+ clocks = <&ccu CLK_BUS_TCON_TOP>;
+ clock-names = "bus";
+ resets = <&ccu RST_BUS_TCON_TOP>;
+ reset-names = "rst";
+ #clock-cells = <1>;
+ };
+
+ tcon_tv0: lcd-controller at 1c73000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv-0";
+ reg = <0x01c73000 0x1000>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV0>, <&ccu CLK_TCON_TV0>,
+ <&tcon_top 1>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV0>;
+ reset-names = "lcd";
+ allwinner,tcon-top = <&tcon_top>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv0_in: port at 0 {
+ reg = <0>;
+ };
+
+ tcon_tv0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
+ tcon_tv1: lcd-controller at 1c74000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv-1";
+ reg = <0x01c74000 0x1000>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV1>, <&ccu CLK_TCON_TV1>,
+ <&tcon_top 2>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV1>;
+ reset-names = "lcd";
+ allwinner,tcon-top = <&tcon_top>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv1_in: port at 0 {
+ reg = <0>;
+ };
+
+ tcon_tv1_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
gic: interrupt-controller at 1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
@@ -461,6 +586,47 @@
#interrupt-cells = <3>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+
+ hdmi: hdmi at 1ee0000 {
+ compatible = "allwinner,sun8i-r40-dw-hdmi",
+ "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee0000 0x10000>;
+ reg-io-width = <1>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HDMI0>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu CLK_HDMI>;
+ clock-names = "iahb", "isfr", "tmds";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi-phy";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port at 0 {
+ reg = <0>;
+ };
+
+ hdmi_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ hdmi_phy: hdmi-phy at 1ef0000 {
+ compatible = "allwinner,sun8i-r40-hdmi-phy",
+ "allwinner,sun50i-a64-hdmi-phy";
+ reg = <0x01ef0000 0x10000>;
+ clocks = <&ccu CLK_BUS_HDMI1>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu 7>, <&ccu 16>;
+ clock-names = "bus", "mod", "pll-0", "pll-1";
+ resets = <&ccu RST_BUS_HDMI0>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
};
timer {
--
2.17.0
^ 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