Date   

[PATCH 04/15] serial: sh-sci: Add support for GPIO-controlled modem lines

Fabrizio Castro <fabrizio.castro@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

Enhance the Renesas SCI UART driver to add support for GPIO-controlled
modem lines (CTS, DSR, DCD, RNG, RTS, DTR), using the serial_mctrl_gpio
helpers.

GPIO-controlled modem lines can be used when dedicated modem lines are
not available. Invalid configurations specifying both GPIO RTS/CTS and
dedicated RTS/CTS are rejected.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Reviewed-by: Peter Hurley <peter@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
(cherry picked from commit f907c9ea88355ac9fe065ffbd6acc914408b4232)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/sh-sci.c | 46 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index f38beb2..05a2b2c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -731,6 +731,7 @@ config SERIAL_SH_SCI
tristate "SuperH SCI(F) serial port support"
depends on SUPERH || ARCH_SHMOBILE || H8300 || COMPILE_TEST
select SERIAL_CORE
+ select SERIAL_MCTRL_GPIO if GPIOLIB

config SERIAL_SH_SCI_NR_UARTS
int "Maximum number of SCI(F) serial ports"
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 5f148f3..cf91172 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -56,6 +56,7 @@
#include <asm/sh_bios.h>
#endif

+#include "serial_mctrl_gpio.h"
#include "sh-sci.h"

/* Offsets into the sci_port->irqs array */
@@ -86,6 +87,7 @@ struct sci_port {
unsigned int error_clear;
unsigned int sampling_rate;
resource_size_t reg_size;
+ struct mctrl_gpios *gpios;

/* Break timer */
struct timer_list break_timer;
@@ -1738,6 +1740,8 @@ static unsigned int sci_tx_empty(struct uart_port *port)
*/
static void sci_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
+ struct sci_port *s = to_sci_port(port);
+
if (mctrl & TIOCM_LOOP) {
const struct plat_sci_reg *reg;

@@ -1750,15 +1754,35 @@ static void sci_set_mctrl(struct uart_port *port, unsigned int mctrl)
serial_port_in(port, SCFCR) |
SCFCR_LOOP);
}
+
+ mctrl_gpio_set(s->gpios, mctrl);
}

static unsigned int sci_get_mctrl(struct uart_port *port)
{
+ struct sci_port *s = to_sci_port(port);
+ struct mctrl_gpios *gpios = s->gpios;
+ unsigned int mctrl = 0;
+
+ mctrl_gpio_get(gpios, &mctrl);
+
/*
* CTS/RTS is handled in hardware when supported, while nothing
* else is wired up. Keep it simple and simply assert CTS/DSR/CAR.
*/
- return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+ if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS)))
+ mctrl |= TIOCM_CTS;
+ if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR)))
+ mctrl |= TIOCM_DSR;
+ if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD)))
+ mctrl |= TIOCM_CAR;
+
+ return mctrl;
+}
+
+static void sci_enable_ms(struct uart_port *port)
+{
+ mctrl_gpio_enable_ms(to_sci_port(port)->gpios);
}

static void sci_break_ctl(struct uart_port *port, int break_state)
@@ -1822,6 +1846,8 @@ static void sci_shutdown(struct uart_port *port)

dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);

+ mctrl_gpio_disable_ms(to_sci_port(port)->gpios);
+
spin_lock_irqsave(&port->lock, flags);
sci_stop_rx(port);
sci_stop_tx(port);
@@ -2075,6 +2101,9 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
sci_start_rx(port);

sci_port_disable(s);
+
+ if (UART_ENABLE_MS(port, termios->c_cflag))
+ sci_enable_ms(port);
}

static void sci_pm(struct uart_port *port, unsigned int state,
@@ -2200,6 +2229,7 @@ static struct uart_ops sci_uart_ops = {
.start_tx = sci_start_tx,
.stop_tx = sci_stop_tx,
.stop_rx = sci_stop_rx,
+ .enable_ms = sci_enable_ms,
.break_ctl = sci_break_ctl,
.startup = sci_startup,
.shutdown = sci_shutdown,
@@ -2641,6 +2671,20 @@ static int sci_probe_single(struct platform_device *dev,
if (ret)
return ret;

+ sciport->gpios = mctrl_gpio_init(&sciport->port, 0);
+ if (IS_ERR(sciport->gpios) && PTR_ERR(sciport->gpios) != -ENOSYS)
+ return PTR_ERR(sciport->gpios);
+
+ if (p->capabilities & SCIx_HAVE_RTSCTS) {
+ if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
+ UART_GPIO_CTS)) ||
+ !IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
+ UART_GPIO_RTS))) {
+ dev_err(&dev->dev, "Conflicting RTS/CTS config\n");
+ return -EINVAL;
+ }
+ }
+
ret = uart_add_one_port(&sci_uart_driver, &sciport->port);
if (ret) {
sci_cleanup_single(sciport);
--
2.7.4


[PATCH 03/15] serial: sh-sci: Always set TIOCM_CTS in .get_mctrl() callback

Fabrizio Castro <fabrizio.castro@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

Documentation/serial/driver clearly states:

If the port does not support CTS, DCD or DSR, the driver should
indicate that the signal is permanently active.

Hence always set TIOCM_CTS, as we currently don't look at the CTS
hardware line state at all.

FWIW, this fixes the transmit path when hardware-assisted flow control
is enabled, and userspace enables CRTSCTS.
The receive path is still broken, as RTS is never asserted.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Reviewed-by: Peter Hurley <peter@...>
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
(cherry picked from commit 71e98e0e2aede08d6e0a0f3d94ea28b591ef4306)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 80d0ffe..5f148f3 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1756,9 +1756,9 @@ static unsigned int sci_get_mctrl(struct uart_port *port)
{
/*
* CTS/RTS is handled in hardware when supported, while nothing
- * else is wired up. Keep it simple and simply assert DSR/CAR.
+ * else is wired up. Keep it simple and simply assert CTS/DSR/CAR.
*/
- return TIOCM_DSR | TIOCM_CAR;
+ return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
}

static void sci_break_ctl(struct uart_port *port, int break_state)
--
2.7.4


[PATCH 02/15] serial: sh-sci: Update DT binding documentation for dedicated RTS/CTS

Fabrizio Castro <fabrizio.castro@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

Some Renesas SCIF UARTs have dedicated lines for RTS/CTS hardware flow
control. Whether these lines exist depends on SoC and UART instance
inside the SoC. Whether these lines can be used for hardware flow
control depends on board wiring.

Amend the DT bindings with an optional property to indicate that RTS/CTS
hardware flow control lines exist, and can be used as such, according to
the Generic Serial DT Bindings.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Acked-by: Rob Herring <robh@...>
Cc: devicetree@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
(cherry picked from commit b0405dc998e425bbb1f64488b6fda781b627056b)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index e0fd7ee..211f193 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -61,6 +61,8 @@ Optional properties:
- dma-names: Must contain a list of two DMA names, "tx" and "rx".
- {cts,dsr,dcd,rng,rts,dtr}-gpios: Specify GPIOs for modem lines, cfr. the
generic serial DT bindings in serial.txt.
+ - uart-has-rtscts: Indicates dedicated lines for RTS/CTS hardware flow
+ control, cfr. the generic serial DT bindings in serial.txt.

Example:
aliases {
--
2.7.4


[PATCH 01/15] serial: sh-sci: Update DT binding documentation for GPIO modem lines

Fabrizio Castro <fabrizio.castro@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

Amend the DT bindings for the Renesas SCI driver to allow describing
optional GPIO-controlled modem lines, which can be used where dedicated
modem lines are not available.

The property naming is dictated by the Generic Serial DT Bindings.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Acked-by: Rob Herring <robh@...>
Cc: devicetree@...
Signed-off-by: Greg Kroah-Hartman <gregkh@...>
(cherry picked from commit 0c529b3fc6c66e618088aa3a998d760d1ad05272)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index cbcfdc0..e0fd7ee 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -59,6 +59,8 @@ Optional properties:
- dmas: Must contain a list of two references to DMA specifiers, one for
transmission, and one for reception.
- dma-names: Must contain a list of two DMA names, "tx" and "rx".
+ - {cts,dsr,dcd,rng,rts,dtr}-gpios: Specify GPIOs for modem lines, cfr. the
+ generic serial DT bindings in serial.txt.

Example:
aliases {
--
2.7.4


[PATCH 00/15] Add UART support to r8a7743

Fabrizio Castro <fabrizio.castro@...>
 

This series aims at adding UART support to r8a7743 by backporting
the relevant patches from upstream.
As per upstream, since two of the serial interfaces live on the
camera daughter board, we rework the DT architecture to better
accomodate all the possible HW variants.

Finally, in order to get CTS/RTS to work this series backports
fixes made by Geert some time ago.

Thanks,
Fabrizio

Biju Das (1):
ARM: dts: iwg20d-q7: Add chosen node

Fabrizio Castro (3):
ARM: dts: iwg20d-q7: Rework DT architecture
ARM: dts: iwg20d-q7-dbcm-ca: Add device trees for camera DB
ARM: dts: iwg20d-q7: Add support for ttySC3

Geert Uytterhoeven (11):
serial: sh-sci: Update DT binding documentation for GPIO modem lines
serial: sh-sci: Update DT binding documentation for dedicated RTS/CTS
serial: sh-sci: Always set TIOCM_CTS in .get_mctrl() callback
serial: sh-sci: Add support for GPIO-controlled modem lines
serial: sh-sci: Do not open-code sci_getreg()
serial: sh-sci: Add more Serial Port Register documentation
serial: sh-sci: Add more Serial Port Control/Data Register
documentation
serial: sh-sci: Correct pin initialization on (H)SCIF
serial: sh-sci: Add pin initialization for SCIFA/SCIFB
serial: sh-sci: Fix support for hardware-assisted RTS/CTS
serial: sh-sci: Add DT support for dedicated RTS/CTS

.../bindings/serial/renesas,sci-serial.txt | 4 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 127 +++++++++++++++
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 43 +++++
arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts | 19 +++
arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 100 +-----------
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/sh-sci.c | 177 ++++++++++++++++++---
drivers/tty/serial/sh-sci.h | 24 ++-
9 files changed, 365 insertions(+), 131 deletions(-)
create mode 100644 arch/arm/boot/dts/iwg20d-q7-common.dtsi
create mode 100644 arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
create mode 100644 arch/arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dts

--
2.7.4


Re: Meltdown and Spectre in CIP

Jan Kiszka
 

On 2018-02-15 12:44, Ben Hutchings wrote:
[...]
Will you be keeping an eye on Spectre patches on behalf of CIP as
part of your maintainer role? I guess you may be in the loop a bit
more than the rest of us?
I will look at the mitigations as they land upstream, but I still think
these are low priority security issues for CIP.
The priority starts to rise here because new system are coming out that
need to start system testing and other processes on a CIP kernel with
Spectre mitigations (x86 so far). Can you estimate the time needed for a
cip19 release?

Thanks,
Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


[PATCH 6/6] ARM: dts: iwg20d-q7: Add SDHI1 support

Fabrizio Castro <fabrizio.castro@...>
 

From: Biju Das <biju.das@...>

Define the iWave RainboW-G20D-Qseven board dependent part of the
SDHI1 device node.

Signed-off-by: Biju Das <biju.das@...>
Acked-by: Wolfram Sang <wsa+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 029efb3a03c5039902a6f1cfe266ed664cb97f20)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 40 +++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index f3b4890..0bd9754 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -19,6 +19,29 @@
serial0 = &scif0;
ethernet0 = &avb;
};
+
+ vcc_sdhi1: regulator-vcc-sdhi1 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI1 Vcc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ };
+
+ vccq_sdhi1: regulator-vccq-sdhi1 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI1 VccQ";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpios = <&gpio2 30 GPIO_ACTIVE_LOW>;
+ gpios-states = <1>;
+ states = <3300000 1
+ 1800000 0>;
+ };
};

&pfc {
@@ -36,6 +59,12 @@
groups = "avb_mdio", "avb_gmii";
function = "avb";
};
+
+ sdhi1_pins: sd1 {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <3300>;
+ };
};

&scif0 {
@@ -60,6 +89,17 @@
};
};

+&sdhi1 {
+ pinctrl-0 = <&sdhi1_pins>;
+ pinctrl-names = "default";
+
+ vmmc-supply = <&vcc_sdhi1>;
+ vqmmc-supply = <&vccq_sdhi1>;
+ cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio6 15 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
&i2c2 {
pinctrl-0 = <&i2c2_pins>;
pinctrl-names = "default";
--
2.7.4


[PATCH 5/6] ARM: dts: iwg20m: Enable SDHI0 controller

Fabrizio Castro <fabrizio.castro@...>
 

From: Biju Das <biju.das@...>

Enable the SDHI0 controller on iWave RZG1M Qseven SOM.

Signed-off-by: Biju Das <biju.das@...>
Acked-by: Wolfram Sang <wsa+renesas@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit e75e71e7bcee2e04be8bbca6fb67af1a45fa128b)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index ff79938..4119737 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -9,6 +9,7 @@
*/

#include "r8a7743.dtsi"
+#include <dt-bindings/gpio/gpio.h>

/ {
compatible = "iwave,g20m", "renesas,r8a7743";
@@ -42,6 +43,12 @@
groups = "mmc_data8_b", "mmc_ctrl";
function = "mmc";
};
+
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
};

&mmcif0 {
@@ -53,3 +60,13 @@
non-removable;
status = "okay";
};
+
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-names = "default";
+
+ vmmc-supply = <&reg_3p3v>;
+ vqmmc-supply = <&reg_3p3v>;
+ cd-gpios = <&gpio7 11 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
--
2.7.4


[PATCH 4/6] ARM: dts: r8a7743: Add SDHI controllers

Fabrizio Castro <fabrizio.castro@...>
 

From: Biju Das <biju.das@...>

Add the SDHI controllers to the r8a7743 device tree.

Signed-off-by: Biju Das <biju.das@...>
Signed-off-by: Simon Horman <horms+renesas@...>
(cherry picked from commit 63ce8a617b5129f7cb20ed0d6d822a31ecca4696)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
arch/arm/boot/dts/r8a7743.dtsi | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index b1534a0..8515abf 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -716,6 +716,45 @@
status = "disabled";
};

+ sdhi0: sd@ee100000 {
+ compatible = "renesas,sdhi-r8a7743";
+ reg = <0 0xee100000 0 0x328>;
+ interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp3_clks R8A7743_CLK_SDHI0>;
+ dmas = <&dmac0 0xcd>, <&dmac0 0xce>,
+ <&dmac1 0xcd>, <&dmac1 0xce>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <195000000>;
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
+ sdhi1: sd@ee140000 {
+ compatible = "renesas,sdhi-r8a7743";
+ reg = <0 0xee140000 0 0x100>;
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp3_clks R8A7743_CLK_SDHI1>;
+ dmas = <&dmac0 0xc1>, <&dmac0 0xc2>,
+ <&dmac1 0xc1>, <&dmac1 0xc2>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <97500000>;
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
+ sdhi2: sd@ee160000 {
+ compatible = "renesas,sdhi-r8a7743";
+ reg = <0 0xee160000 0 0x100>;
+ interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp3_clks R8A7743_CLK_SDHI2>;
+ dmas = <&dmac0 0xd3>, <&dmac0 0xd4>,
+ <&dmac1 0xd3>, <&dmac1 0xd4>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <97500000>;
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
--
2.7.4


[PATCH 3/6] mmc: renesas_sdhi: Add r8a7743/5 support

Fabrizio Castro <fabrizio.castro@...>
 

From: Biju Das <biju.das@...>

Add support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5) SDHI
is identical to the R-Car Gen2 family.

Signed-off-by: Biju Das <biju.das@...>
Reviewed-by: Wolfram Sang <wsa+renesas@...>
Acked-by: Simon Horman <horms+renesas@...>
Signed-off-by: Ulf Hansson <ulf.hansson@...>
(cherry picked from commit 34292311f0195b2113a5f30e5bea33e4c2668315)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 400b640..cbf9135 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -15,6 +15,8 @@ Required properties:
"renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC
"renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
"renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
+ "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
+ "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
"renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
"renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
"renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
--
2.7.4


[PATCH 2/6] mmc: renesas_sdhi: Add r8a7743/5 support

Fabrizio Castro <fabrizio.castro@...>
 

From: Biju Das <biju.das@...>

Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI
is identical to the R-Car Gen2 family.

Signed-off-by: Biju Das <biju.das@...>
Acked-by: Simon Horman <horms+renesas@...>
Signed-off-by: Ulf Hansson <ulf.hansson@...>
(cherry picked from commit c16a854e4463078aedad601fac76341760a66dd1)
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
drivers/mmc/host/sh_mobile_sdhi.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 354f4f3..e43aff4 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -73,6 +73,8 @@ static const struct of_device_id sh_mobile_sdhi_of_match[] = {
{ .compatible = "renesas,sdhi-r8a7740", .data = &sh_mobile_sdhi_of_cfg[0], },
{ .compatible = "renesas,sdhi-r8a7778", .data = &of_rcar_gen1_compatible, },
{ .compatible = "renesas,sdhi-r8a7779", .data = &of_rcar_gen1_compatible, },
+ { .compatible = "renesas,sdhi-r8a7743", .data = &of_rcar_gen2_compatible, },
+ { .compatible = "renesas,sdhi-r8a7745", .data = &of_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7790", .data = &of_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7791", .data = &of_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7792", .data = &of_rcar_gen2_compatible, },
--
2.7.4


[PATCH 1/6] ARM: shmobile: r8a7743: Rename SDHI clocks

Fabrizio Castro <fabrizio.castro@...>
 

This commit renames R8A7743_CLK_SDHI2 to R8A7743_CLK_SDHI1 and
R8A7743_CLK_SDHI3 to R8A7743_CLK_SDHI2. This is to make the SDHI
clock names of the r8a7743 more similar to upstream definitions.

Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
arch/arm/boot/dts/r8a7743.dtsi | 4 ++--
include/dt-bindings/clock/r8a7743-clock.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 9255582..b1534a0 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -958,8 +958,8 @@
<&hp_clk>, <&hp_clk>;
#clock-cells = <1>;
clock-indices = <
- R8A7743_CLK_TPU0 R8A7743_CLK_SDHI3
- R8A7743_CLK_SDHI2 R8A7743_CLK_SDHI0
+ R8A7743_CLK_TPU0 R8A7743_CLK_SDHI2
+ R8A7743_CLK_SDHI1 R8A7743_CLK_SDHI0
R8A7743_CLK_MMCIF0 R8A7743_CLK_IIC0
R8A7743_CLK_PCIEC R8A7743_CLK_IIC1
R8A7743_CLK_SSUSB R8A7743_CLK_CMT1
diff --git a/include/dt-bindings/clock/r8a7743-clock.h b/include/dt-bindings/clock/r8a7743-clock.h
index 53f54df..8e4b843 100644
--- a/include/dt-bindings/clock/r8a7743-clock.h
+++ b/include/dt-bindings/clock/r8a7743-clock.h
@@ -58,8 +58,8 @@

/* MSTP3 */
#define R8A7743_CLK_TPU0 4
-#define R8A7743_CLK_SDHI3 11
-#define R8A7743_CLK_SDHI2 12
+#define R8A7743_CLK_SDHI2 11
+#define R8A7743_CLK_SDHI1 12
#define R8A7743_CLK_SDHI0 14
#define R8A7743_CLK_MMCIF0 15
#define R8A7743_CLK_IIC0 18
--
2.7.4


[PATCH 0/6] Add SDHI support to r8a7743

Fabrizio Castro <fabrizio.castro@...>
 

Dear All,

this patch series adds SDHI support to the r8a7743 SoC.

The only patch that hasn't been backported in this series is:
"ARM: shmobile: r8a7743: Rename SDHI clocks"

This work has been based on top of this series:
https://lists.cip-project.org/pipermail/cip-dev/2018-February/000863.html

Thanks,
Fabrizio

Biju Das (5):
mmc: renesas_sdhi: Add r8a7743/5 support
mmc: renesas_sdhi: Add r8a7743/5 support
ARM: dts: r8a7743: Add SDHI controllers
ARM: dts: iwg20m: Enable SDHI0 controller
ARM: dts: iwg20d-q7: Add SDHI1 support

Fabrizio Castro (1):
ARM: shmobile: r8a7743: Rename SDHI clocks

Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 2 +
arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 40 ++++++++++++++++++++
arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 17 +++++++++
arch/arm/boot/dts/r8a7743.dtsi | 43 +++++++++++++++++++++-
drivers/mmc/host/sh_mobile_sdhi.c | 2 +
include/dt-bindings/clock/r8a7743-clock.h | 4 +-
6 files changed, 104 insertions(+), 4 deletions(-)

--
2.7.4


Re: Increase of visibility of the work done in Gitlab: proposal

Jan Kiszka
 

On 2018-02-28 01:57, Jeff ErnstFriedman wrote:
Agustin,

Following up on this thread, I would like to raise the option of the
project moving from a Mailman mailing list (currently use) to Group.io.
We would see about a 50% savings over the course of the year and lower
the effort to create and maintain lists.
Maybe we should discuss the numbers at board level.


I leverage Groups.io with other LF projects and find it a better
experience. It is my understanding we can migrate all the existing
content to Groups.io for a one-time fee.
Seems like a an interesting project, but it's a one-man show, and I
would be careful with relying on it at that point.

Jan


Please let me know if there is any interest in me exploring further.



/Jeff ErnstFriedman/
/jernstfriedman@...
<mailto:jernstfriedman@...> /
/2201 Broadway #604, Oakland, CA 94612//
/
/mobile: 510.593.1367 <tel:(510)%20593-1367>/
/skype: jeffrey.ernstfriedman/
/twitter: @namdeirf/

On Thu, Feb 8, 2018 at 8:25 AM, Agustín Benito Bethencourt
<agustin.benito@... <mailto:agustin.benito@...>>
wrote:

__

Hi,

 

in order to increase the visibility of the work done in Gitlab I
suggest one of these two actions:

* Create a mailing list for development notifications where we can
send the notifications of the commits made in gitlab, including the
diffs.

* Send the notifications to this mailing list and let users filter them.

 

I do not expect heavy traffic as long as we do not include Ben's repo.

 

In the same line, I suggest to do the same with IRC, expecting
limited traffic.

 

Best Regards

 

--

Agustín Benito Bethencourt

Principal Consultant

Codethink Ltd


_______________________________________________
cip-dev mailing list
cip-dev@... <mailto:cip-dev@...>
https://lists.cip-project.org/mailman/listinfo/cip-dev
<https://lists.cip-project.org/mailman/listinfo/cip-dev>




_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Increase of visibility of the work done in Gitlab: proposal

Daniel Wagner <wagi@...>
 

On 01.03.2018 18:05, Jeff ErnstFriedman wrote:
I would need to see if there are any caveats, but in the FAQ here are
the instructions to get an archive
extract: https://groups.io/static/help#how-can-i-download-my-member-list-and-message-archive,
so it seems a straight forward process to me.
Ah, though this seems only available for the admin of the list.


Re: Increase of visibility of the work done in Gitlab: proposal

Jeff ErnstFriedman <jernstfriedman@...>
 

Daniel,

I would need to see if there are any caveats, but in the FAQ here are the instructions to get an archive extract: https://groups.io/static/help#how-can-i-download-my-member-list-and-message-archive, so it seems a straight forward process to me.

Jeff ErnstFriedman
2201 Broadway #604, Oakland, CA 94612
mobile: 510.593.1367
skype: jeffrey.ernstfriedman
twitter: @namdeirf

On Thu, Mar 1, 2018 at 8:08 AM, Daniel Wagner <wagi@...> wrote:
Hi Jeff,

> Following up on this thread, I would like to raise the option of the
> project moving from a Mailman mailing list (currently use) to Group.io.
> We would see about a 50% savings over the course of the year and lower
> the effort to create and maintain lists.

Is there a way to get an archive extracted from the groups.io platform?

Daniel


Re: Increase of visibility of the work done in Gitlab: proposal

Daniel Wagner <wagi@...>
 

Hi Jeff,

Following up on this thread, I would like to raise the option of the
project moving from a Mailman mailing list (currently use) to Group.io.
We would see about a 50% savings over the course of the year and lower
the effort to create and maintain lists.
Is there a way to get an archive extracted from the groups.io platform?

Daniel


Re: Increase of visibility of the work done in Gitlab: proposal

Jeff ErnstFriedman <jernstfriedman@...>
 

Agustin,

Following up on this thread, I would like to raise the option of the project moving from a Mailman mailing list (currently use) to Group.io. We would see about a 50% savings over the course of the year and lower the effort to create and maintain lists. 

I leverage Groups.io with other LF projects and find it a better experience. It is my understanding we can migrate all the existing content to Groups.io for a one-time fee. 

Please let me know if there is any interest in me exploring further.



Jeff ErnstFriedman
2201 Broadway #604, Oakland, CA 94612
mobile: 510.593.1367
skype: jeffrey.ernstfriedman
twitter: @namdeirf

On Thu, Feb 8, 2018 at 8:25 AM, Agustín Benito Bethencourt <agustin.benito@....uk> wrote:

Hi,

 

in order to increase the visibility of the work done in Gitlab I suggest one of these two actions:

* Create a mailing list for development notifications where we can send the notifications of the commits made in gitlab, including the diffs.

* Send the notifications to this mailing list and let users filter them.

 

I do not expect heavy traffic as long as we do not include Ben's repo.

 

In the same line, I suggest to do the same with IRC, expecting limited traffic.

 

Best Regards

 

--

Agustín Benito Bethencourt

Principal Consultant

Codethink Ltd


_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev



Re: How to develop on the RT version

Chris Brandt <Chris.Brandt@...>
 

Hi Daniel,

On Thursday, February 22, 2018, Daniel Wagner wrote:
In short: linux-4.4.y-cip-rt wont be rebased. linux-4.4.y-cip-rt-rebase
tree contains the extracted patches from linux-4.4.y.cip-rt. Some people
like to get a patchset which they can apply on top of some tree. But it
looks no one here around is particular interested in this.

The linux-4.4.y-cip-patches is just a variation from the rebase branch.
Probably not really useful to anyone. I just archived all the a patches
in that branch. It was useful for me when I started with the scripting
to have a backup but I don't think I need it anymore. So if no one needs
I can drop it completely to avoid further confusion.

Thank you for this information.

I admit, I had 2 purposes for the question:

1. To be able to guild RZ/G customers on how to develop on the RT branch.

2. To get an idea of how to maintain the public repos for the RZ/A BSP with an RT branch. The 'rebase' branch thing didn't seem to make sense to me that anyone would want to follow that.

The current official RZ/A1 BSPs are 3.14, 4.9 and 4.14, although most of the drivers are mainlined at this point. So, maybe on the next CIP cycle, we'll support CIP for RZ/A as well.

Thanks,
Chris


Re: How to develop on the RT version

Daniel Wagner <daniel.wagner@...>
 

Hi Chris,

On 22.02.2018 03:36, Chris Brandt wrote:
On Wednesday, February 21, 2018, Daniel Sangorrin wrote:
The rebase branch is something complimentary, the maintainer may decide
not to prepare it (the same with the patches).
# The rebase branch might useful to see clearly which patches come from
the cip kernel and which ones are from PREEMPT RT.
OK, that was the info that I needed.
Sorry for the late response.

In short: linux-4.4.y-cip-rt wont be rebased. linux-4.4.y-cip-rt-rebase
tree contains the extracted patches from linux-4.4.y.cip-rt. Some people
like to get a patchset which they can apply on top of some tree. But it
looks no one here around is particular interested in this.

The linux-4.4.y-cip-patches is just a variation from the rebase branch.
Probably not really useful to anyone. I just archived all the a patches
in that branch. It was useful for me when I started with the scripting
to have a backup but I don't think I need it anymore. So if no one needs
I can drop it completely to avoid further confusion.

Thanks,
Daniel

8741 - 8760 of 9641