ARM: renesas: shmobile and multi_v7 defconfig updates

The manual bridge implementation was removed in favor of the generic one, so now we need to enable standard bridge drivers like DRM_DUMB_VGA_DAC and DRM_I2C_ADV7511.
Both were already enabled, but the (newer) ADV7511 audio part wasn't.

Fixes 5c602531feb3db39 ("drm: rcar-du: Replace manual bridge implementation

with DRM bridge")

Signed-off-by Geert Uytterhoeven <[email protected]>

---
multi_v7_defconfig is in desperate need of a refresh.

To reduce conflicts, I went for the simple option of adding CONFIG_DRM_I2C_ADV7511_AUDIO below CONFIG_DRM_I2C_ADV7511, instead of moving CONFIG_DRM_I2C_ADV7511 and CONFIG_DRM_DUMB_VGA_DAC around.

---
 arch/arm/configs/multi_v7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(quoted diff) +0 -0

b/arch/arm/configs/multi_v7_defconfig index
7fa1746970ecc531..ea2075d8e185f7aa 100644

arch/arm/configs/multi_v7_defconfig +1 -1

@@ -584,6 +584,7 @@ CONFIG_VIDEO_ADV7180=m
 CONFIG_VIDEO_ML86V7667=m
 CONFIG_DRM=y
 CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_I2C_ADV7511_AUDIO=y
 # CONFIG_DRM_I2C_CH7006 is not set
 # CONFIG_DRM_I2C_SIL164 is not set
 CONFIG_DRM_DUMB_VGA_DAC=m

@@ -603,7 +604,6 @@ CONFIG_ROCKCHIP_DW_MIPI_DSI=y
 CONFIG_ROCKCHIP_INNO_HDMI=y
 CONFIG_DRM_ATMEL_HLCDC=m
 CONFIG_DRM_RCAR_DU=m
-CONFIG_DRM_RCAR_HDMI=y
 CONFIG_DRM_RCAR_LVDS=y
 CONFIG_DRM_SUN4I=m
 CONFIG_DRM_TEGRA=y

Quoted 5 lines · On Monday 10 Jul 2017 15:28:21 Geert Uytterhoeven wrote:

The manual bridge implementation was removed in favor of the generic one, so now we need to enable standard bridge drivers like DRM_DUMB_VGA_DAC and DRM_I2C_ADV7511.
Both were already enabled, but the (newer) ADV7511 audio part wasn't.

Quoted 2 lines

Fixes 5c602531feb3db39 ("drm: rcar-du: Replace manual bridge implementation

with DRM bridge")

I wonder if this patch really needs a Fixes tag. All it does is removing a now deleted kernel option, and adding a new unrelated one. The former is related to 5c602531feb3db39, but I'm not sure it should be considered as a bug.

The content of this patch looks good to me though.

DMA for (H)SCIF(A|B) serial ports on Renesas R-Car Gen2 and RZ/G1 SoCs is considered stable, hence enable it by default.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm/configs/multi_v7_defconfig +0 -0

index ea2075d8e185f7aa..072a455008df9751 100644

Quoted 13 lines · Geert Uytterhoeven

DMA for (H)SCIF(A|B) serial ports on Renesas R-Car Gen2 and RZ/G1 SoCs is considered stable, hence enable it by default.

Signed-off-by Geert Uytterhoeven <[email protected]>

---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm/configs/multi_v7_defconfig +0 -0

index ea2075d8e185f7aa..072a455008df9751 100644

arch/arm/configs/multi_v7_defconfig CONFIG_SERIAL_IMX_CONSOLE=y · line 336

Quoted 7 lines

arch/arm/configs/multi_v7_defconfig +1 -0

@@ -330,6 +330,7 @@ CONFIG_SERIAL_IMX_CONSOLE=y
 CONFIG_SERIAL_SH_SCI=y
 CONFIG_SERIAL_SH_SCI_NR_UARTS=20
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
+CONFIG_SERIAL_SH_SCI_DMA=y
 CONFIG_SERIAL_MSM=y
 CONFIG_SERIAL_MSM_CONSOLE=y
 CONFIG_SERIAL_VT8500=y

Thanks, FWIW I'm very happy to see DMA enabled for the SCIF driver in mainline.

Since enabling DMA Engine still keeps PIO support around I wonder why we need this Kconfig at all - other drivers seem to get by without this kind of thing?
So in my opinion it would also be nice to get rid of SERIAL_SH_SCI_DMA completely and reducing the number of special per-driver Kconfig entries.

Whether we want to hide the option (and default to y if ARCH_RENESAS, i.e. ARM) is another question. Note that that wouldn't reduce code maintainability, as the #ifdefs would be kept, and it would prevent building and testing with/without DMA on ARM.

Quoted 4 lines · Geert Uytterhoeven

Whether we want to hide the option (and default to y if ARCH_RENESAS, i.e. ARM) is another question. Note that that wouldn't reduce code maintainability, as the #ifdefs would be kept, and it would prevent building and testing with/without DMA on ARM.

arch/sh/configs/sdk7786_defconfig enables it, too, so it should at least be a user-selectable option on SuperH if you do that.

Hi Magnus,

Quoted 8 lines · Magnus Damm

On Mon, Jul 10, 2017 at 10:28 PM, Geert Uytterhoeven

Since enabling DMA Engine still keeps PIO support around I wonder why we need this Kconfig at all - other drivers seem to get by without this kind of thing?
So in my opinion it would also be nice to get rid of SERIAL_SH_SCI_DMA completely and reducing the number of special per-driver Kconfig entries.

In general, I would agree, and remove the option at the blimp of an eye. However, this driver is shared with H8/300 and SuperH. While both could use DMA (but it's not supported by Linux yet), I don't know if they are willing to live with the increased static and dynamic memory footprint of SH_SCI DMA support.

Quoted 9 lines · Geert Uytterhoeven

Quoted 7 lines · Magnus Damm

On Mon, Jul 10, 2017 at 10:28 PM, Geert Uytterhoeven
Since enabling DMA Engine still keeps PIO support around I wonder why we need this Kconfig at all - other drivers seem to get by without this kind of thing?
So in my opinion it would also be nice to get rid of SERIAL_SH_SCI_DMA completely and reducing the number of special per-driver Kconfig entries.

Quoted 5 lines

In general, I would agree, and remove the option at the blimp of an eye. However, this driver is shared with H8/300 and SuperH. While both could use DMA (but it's not supported by Linux yet), I don't know if they are willing to live with the increased static and dynamic memory footprint of SH_SCI DMA support.

One more thing: enabling the DMA support in the console driver generally means you cannot use printk in the DMA driver anywhere that may be called during printk(). Not sure if that is a concern here.

Hi Arnd,

Quoted 17 lines · Arnd Bergmann

Quoted 14 lines · Geert Uytterhoeven

Quoted 7 lines · Magnus Damm

On Mon, Jul 10, 2017 at 10:28 PM, Geert Uytterhoeven
Since enabling DMA Engine still keeps PIO support around I wonder why we need this Kconfig at all - other drivers seem to get by without this kind of thing?
So in my opinion it would also be nice to get rid of SERIAL_SH_SCI_DMA completely and reducing the number of special per-driver Kconfig entries.

In general, I would agree, and remove the option at the blimp of an eye. However, this driver is shared with H8/300 and SuperH. While both could use DMA (but it's not supported by Linux yet), I don't know if they are willing to live with the increased static and dynamic memory footprint of SH_SCI DMA support.

Quoted 3 lines

One more thing: enabling the DMA support in the console driver generally means you cannot use printk in the DMA driver anywhere that may be called during printk(). Not sure if that is a concern here.

Not anymore, as all of these prints should have been removed/disabled already.

Quoted 18 lines · Geert Uytterhoeven

Quoted 17 lines · Arnd Bergmann

Quoted 14 lines · Geert Uytterhoeven

Quoted 7 lines · Magnus Damm

On Mon, Jul 10, 2017 at 10:28 PM, Geert Uytterhoeven
Since enabling DMA Engine still keeps PIO support around I wonder why we need this Kconfig at all - other drivers seem to get by without this kind of thing?
So in my opinion it would also be nice to get rid of SERIAL_SH_SCI_DMA completely and reducing the number of special per-driver Kconfig entries.

In general, I would agree, and remove the option at the blimp of an eye. However, this driver is shared with H8/300 and SuperH. While both could use DMA (but it's not supported by Linux yet), I don't know if they are willing to live with the increased static and dynamic memory footprint of SH_SCI DMA support.

Quoted 5 lines

Quoted 3 lines

One more thing: enabling the DMA support in the console driver generally means you cannot use printk in the DMA driver anywhere that may be called during printk(). Not sure if that is a concern here.

Not anymore, as all of these prints should have been removed/disabled already.

Last I checked qemu-system-sh4 still doesn't work with current linux serial driver unless you do:

drivers/tty/serial/sh-sci.c +1 -1

@@ -2193,7 +2193,7 @@ static void sci_reset(struct uart_port *port)
                        setup_timer(&s->rx_fifo_timer, rx_fifo_timer_fn,
                                    (unsigned long)s);
                } else {
-                       if (port->type == PORT_SCIFA ||
+                       if (1 || port->type == PORT_SCIFA ||
                            port->type == PORT_SCIFB)
                                scif_set_rtrg(port, 1);
                        else

Does this DMA stuff make that situation worse?

Hi Rob,

Quoted 40 lines · Rob Landley

Quoted 18 lines · Geert Uytterhoeven

Quoted 17 lines · Arnd Bergmann

Quoted 14 lines · Geert Uytterhoeven

Quoted 7 lines · Magnus Damm

On Mon, Jul 10, 2017 at 10:28 PM, Geert Uytterhoeven
Since enabling DMA Engine still keeps PIO support around I wonder why we need this Kconfig at all - other drivers seem to get by without this kind of thing?
So in my opinion it would also be nice to get rid of SERIAL_SH_SCI_DMA completely and reducing the number of special per-driver Kconfig entries.

In general, I would agree, and remove the option at the blimp of an eye. However, this driver is shared with H8/300 and SuperH. While both could use DMA (but it's not supported by Linux yet), I don't know if they are willing to live with the increased static and dynamic memory footprint of SH_SCI DMA support.

Quoted 5 lines

Quoted 3 lines

One more thing: enabling the DMA support in the console driver generally means you cannot use printk in the DMA driver anywhere that may be called during printk(). Not sure if that is a concern here.

Not anymore, as all of these prints should have been removed/disabled already.

Last I checked qemu-system-sh4 still doesn't work with current linux serial driver unless you do:

drivers/tty/serial/sh-sci.c +1 -1

@@ -2193,7 +2193,7 @@ static void sci_reset(struct uart_port *port)
                        setup_timer(&s->rx_fifo_timer, rx_fifo_timer_fn,
                                    (unsigned long)s);
                } else {
-                       if (port->type == PORT_SCIFA ||
+                       if (1 || port->type == PORT_SCIFA ||
                            port->type == PORT_SCIFB)
                                scif_set_rtrg(port, 1);
                        else

Quoted 1 line

Does this DMA stuff make that situation worse?

No, SH-SCI DMA is not used on your platform.

Gr{oetje,eeting}s,

Hi Arnd, Kevin, Magnus, Olof, Simon,

This patch series updates shmobile_defconfig and multi_v7_defconfig to (re-)enable some features:
- Re-enable R-Car PCIe (shmobile_defconfig),
- Re-enable R-Car XHCI (shmobile_defconfig),
- Re-enable R-Car sound (both),
- Update DRM bridge (both),
- Enable serial port DMA (both).

There also a patch included to refresh shmobile_defconfig.
To avoid conflicts, I didn't refresh multi_v7_defconfig (although it could definitely use a refresh), and only made "simple" changes to it.

Thanks!

Geert Uytterhoeven (9):
ARM: shmobile: defconfig: Enable missing PCIE_RCAR dependency
ARM: shmobile: defconfig: Replace USB_XHCI_RCAR by USB_XHCI_PLATFORM
ARM: shmobile: defconfig: Replace SND_SOC_RSRC_CARD by
SND_SIMPLE_SCU_CARD
ARM: shmobile: defconfig: Replace DRM_RCAR_HDMI by generic bridge
options
ARM: shmobile: defconfig: Enable DMA for serial ports
ARM: shmobile: defconfig: Refresh
ARM: multi_v7_defconfig: Replace SND_SOC_RSRC_CARD by
SND_SIMPLE_SCU_CARD
ARM: multi_v7_defconfig: Replace DRM_RCAR_HDMI by generic bridge
options
ARM: multi_v7_defconfig: Enable DMA for Renesas serial ports

 arch/arm/configs/multi_v7_defconfig |  5 +++--
 arch/arm/configs/shmobile_defconfig | 16 +++++++++-------
 2 files changed, 12 insertions(+), 9 deletions(-)

Signature · 12 lines

2.7.4

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds