[PATCH 10/10] arm64: dts: renesas: r8a7796-salvator-x: enable HDMI sound

From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 28 ++ 1 file changed, 28 insertions(+)

[PATCH 09/10] arm64: dts: renesas: r8a7795-salvator-x: enable HDMI sound

From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 46 ++ 1 file changed, 46 insertions(+)

[PATCH 08/10] arm64: dts: renesas: r8a7796-salvator-xs: enable HDMI sound

From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- .../arm64/boot/dts/renesas/r8a7796-salvator-xs.dts | 28 ++ 1 file changed, 28 insertions(+)

[PATCH 07/10] arm64: dts: renesas: r8a7795-salvator-xs: enable HDMI sound

From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 46 ++ 1 file changed, 46 insertions(+)

[PATCH 06/10] arm64: dts: renesas: r8a7795-es1-salvator-x: enable HDMI sound

From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- .../boot/dts/renesas/r8a7795-es1-salvator-x.dts| 46 ++ 1 file changed, 46 insertions(+)

[PATCH 05/10] arm64: dts: renesas: salvator-common: use audio-graph-card for Sound

From: Kuninori Morimoto Current Sound is using simple-audio-card which can't support HDMI. To use HDMI sound, we need to use audio-graph-card. But, one note is that r8a7795 has 2 HDMI ports, but r8a7796 has 1. Because of this mismatch, supporting HDMI on

[PATCH 02/10] arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

From: Kuninori Morimoto CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- arch/arm64/configs/defconfig | 1 + 1 file

[PATCH 04/10] arm64: dts: renesas: r8a7796: add HDMI sound support

From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 03/10] arm64: dts: renesas: r8a7795: add HDMI sound support

From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 1 file changed, 8 insertions(+) diff --git

[PATCH 01/10] arm64: renesas_defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

From: Kuninori Morimoto CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video Signed-off-by: Kuninori Morimoto Tested-by: Nguyen Viet Dung --- arch/arm64/configs/renesas_defconfig | 1 + 1

[PATCH 00/10] arm64: renesas: enable HDMI sound on Salvator

Hi Simon These patches enable HDMI sound on R-Car Salvator boards on H3/M3. Basically, HDMI sound support on "driver side" was already supported, but I didn't posted "DT side" patches, because it needed to confirm business relationship. Now it be cleared. But, unfortunately, DT "full_name"

[PATCH v2 2/8] v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code

The implementation of the set_fmt pad operation is identical in the three modules. Move it to a generic helper function. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_clu.c| 65 +--

[PATCH v2 6/8] v4l: vsp1: Add support for the DISCOM entity

The DISCOM calculates a CRC on a configurable window of the frame. It interfaces to the VSP through the UIF glue, hence the name used in the code. The module supports configuration of the CRC window through the crop rectangle on the ink pad of the corresponding entity. However, unlike the

[PATCH v2 8/8] drm: rcar-du: Add support for CRC computation

Implement CRC computation configuration and reporting through the DRM debugfs-based CRC API. The CRC source can be configured to any input plane or the pipeline output. Signed-off-by: Laurent Pinchart --- Changes since v1: - Format the source names

[PATCH v2 5/8] v4l: vsp1: Extend the DU API to support CRC computation

Add a parameter (in the form of a structure to ease future API extensions) to the VSP atomic flush handler to pass CRC source configuration, and pass the CRC value to the completion callback. Signed-off-by: Laurent Pinchart ---

[PATCH v2 4/8] v4l: vsp1: Document the vsp1_du_atomic_config structure

The structure is used in the API that the VSP1 driver exposes to the DU driver. Documenting it is thus important. Signed-off-by: Laurent Pinchart --- Changes since v1: - Fixed typo --- include/media/vsp1.h | 10 ++ 1 file changed, 10

[PATCH v2 7/8] v4l: vsp1: Integrate DISCOM in display pipeline

The DISCOM is used to compute CRCs on display frames. Integrate it in the display pipeline at the output of the blending unit to process output frames. Computing CRCs on input frames is possible by positioning the DISCOM at a different point in the pipeline. This use case isn't supported at the

[PATCH v2 1/8] v4l: vsp1: Use SPDX license headers

Adopt the SPDX license identifier headers to ease license compliance management. All files in the driver are licensed under the GPLv2+ except for the vsp1_regs.h file which is licensed under the GPLv2. This is likely an oversight, but fixing this requires contacting the copyright owners and is out

[PATCH v2 3/8] v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper

To make vsp1_subdev_set_pad_format() usable by entities that support selection rectangles, we need to reset the crop and compose rectangles when setting the format on the sink pad. Do so and replace the custom set_fmt implementation of the histogram code by a call to vsp1_subdev_set_pad_format().

[PATCH v2 0/8] R-Car DU: Support CRC calculation

Hello, This patch series adds support for CRC calculation to the rcar-du-drm driver. CRC calculation is supported starting at the Renesas R-Car Gen3 SoCs, as earlier versions don't have the necessary hardware. On Gen3 SoCs, the CRC is computed by the DISCOM module part of the VSP-D and VSP-DL.

Re: [PATCH 6/8] drm: rcar-du: rcar-lvds: Add bridge format support

On 2018-04-19 11:31, Jacopo Mondi wrote: > With the introduction of static input image format enumeration in DRM > bridges, add support to retrieve the format in rcar-lvds LVDS encoder > from both panel or bridge, to set the desired LVDS mode. > > Do not rely on 'DRM_BUS_FLAG_DATA_LSB_TO_MSB'

Re: [PATCH 3/8] drm: bridge: thc63lvd1024: Add support for LVDS mode map

On 2018-04-19 11:31, Jacopo Mondi wrote: > The THC63LVD1024 LVDS to RGB bridge supports two different LVDS mapping > modes, selectable by means of an external pin. > > Add support for configurable LVDS input mapping modes, using the newly > introduced support for bridge input image formats. > >

Re: [PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property

On 2018-04-19 11:31, Jacopo Mondi wrote: > The THC63LVD1024 LVDS to RGB bridge supports two different input mapping > modes, selectable by means of an external pin. > > Describe the LVDS mode map through a newly defined mandatory property in > device tree bindings. > > Signed-off-by: Jacopo

Re: [PATCH 1/8] drm: bridge: Add support for static image formats

On 2018-04-19 11:31, Jacopo Mondi wrote: > Add support for storing image format information in DRM bridges with > associated helper function. > > This patch replicates for bridges what 'drm_display_info_set_bus_formats()' > is for connectors. > > Signed-off-by: Jacopo Mondi

Re: [PATCH 30/61] mtd: nand: onenand: simplify getting .drvdata

On Thu, 19 Apr 2018 16:06:00 +0200 Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Applied to nand/next.

Re: [PATCH 29/61] mtd: devices: simplify getting .drvdata

On Thu, 19 Apr 2018 16:05:59 +0200 Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Applied to mtd/next.

Re: [PATCH/RFC net-next 5/5] ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car Gen3

Hello! On 4/17/2018 11:50 AM, Simon Horman wrote: From: Kazuya Mizuguchi This patch sets from two descriptor to one descriptor because R-Car Gen3 does not have the 4 bytes alignment restriction of the transmission buffer. Signed-off-by: Kazuya Mizuguchi

[PATCH 0/4] ARM: dts: renesas: Enable FDP1 devices

Hello, This patch series adds the FDP1 devices for all applicable Gen2 platforms (H2, M2W, M2N and E2). There's no rocket science involved, the devices have no I/O pin and need no resource other than a memory range, a functional clock and an interrupt. Laurent Pinchart (4): ARM: dts: renesas:

[PATCH 2/4] ARM: dts: renesas: r8a7791: Add FDP1 instances

The r8a7791 has two FDP1 instances. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/r8a7791.dtsi | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi index

[PATCH 3/4] ARM: dts: renesas: r8a7793: Add FDP1 instances

The r8a7793 has two FDP1 instances. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/r8a7793.dtsi | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi index

[PATCH 4/4] ARM: dts: renesas: r8a7794: Add FDP1 instances

The r8a7794 has one FDP1 instance. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/r8a7794.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi index

[PATCH 1/4] ARM: dts: renesas: r8a7790: Add FDP1 instances

The r8a7790 has three FDP1 instances. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/r8a7790.dtsi | 27 +++ 1 file changed, 27 insertions(+) diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi

[PATCH 2/3] v4l: rcar_fdp1: Enable compilation on Gen2 platforms

Commit 1d3897143815 ("[media] v4l: rcar_fdp1: add FCP dependency") fixed a compilation breakage when the optional VIDEO_RENESAS_FCP dependency is compiled as a module while the rcar_fdp1 driver is built in. As a side effect it disabled compilation on Gen2 by disallowing the valid combination

[PATCH 3/3] v4l: rcar_fdp1: Fix indentation oddities

Indentation is odd in several places, especially when printing messages to the kernel log. Fix it to match the usual coding style. Signed-off-by: Laurent Pinchart --- drivers/media/platform/rcar_fdp1.c | 28 ++-- 1 file changed,

[PATCH 0/3] R-Car Gen2 support for FDP1

Hello, This small patch series improves support of the FDP1 on R-Car Gen2 platforms by enabling compilation without requiring the Gen3-only FCP dependency. As the Kconfig change (2/3) conflicts with a patch recently posted by Geert I have included it in the series as 1/3. Patch 3/3 fixes

[PATCH 1/3] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

From: Geert Uytterhoeven The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency than the legacy ARCH_SHMOBILE, hence use

[PATCH 04/04] arm64: dts: renesas: r8a77995: Enable IPMMU devices

From: Magnus Damm Remove 'status = "disabled"' to make sure all IPMMU devices are enabled in DT on the r8a77995 SoC. Signed-off-by: Magnus Damm --- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 10 -- 1 file changed, 10

[PATCH 02/04] arm64: dts: renesas: r8a7796: Enable IPMMU devices

From: Magnus Damm Remove 'status = "disabled"' to make sure all IPMMU devices are enabled in DT on the r8a7796 SoC. Signed-off-by: Magnus Damm --- arch/arm64/boot/dts/renesas/r8a7796.dtsi |5 - 1 file changed, 5 deletions(-)

[PATCH 03/04] arm64: dts: renesas: r8a77970: Enable IPMMU devices

From: Magnus Damm Remove 'status = "disabled"' to make sure all IPMMU devices are enabled in DT on the r8a77970 SoC. Signed-off-by: Magnus Damm --- arch/arm64/boot/dts/renesas/r8a77970.dtsi |2 -- 1 file changed, 2 deletions(-) ---

[PATCH 01/04] arm64: dts: renesas: r8a7795: Enable IPMMU devices

From: Magnus Damm Remove 'status = "disabled"' to make sure all IPMMU devices are enabled in DT on the r8a7795 SoC. Signed-off-by: Magnus Damm --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 12 1 file changed, 12

[PATCH 00/04] arm64: dts: renesas: Enable IPMMU devices

arm64: dts: renesas: Enable IPMMU devices [PATCH 01/04] arm64: dts: renesas: r8a7795: Enable IPMMU devices [PATCH 02/04] arm64: dts: renesas: r8a7796: Enable IPMMU devices [PATCH 03/04] arm64: dts: renesas: r8a77970: Enable IPMMU devices [PATCH 04/04] arm64: dts: renesas: r8a77995: Enable IPMMU

Re: [PATCH 07/61] dma: simplify getting .drvdata

On Sun, Apr 22, 2018 at 11:47:33AM +0530, Vinod Koul wrote: > On Thu, Apr 19, 2018 at 04:05:37PM +0200, Wolfram Sang wrote: > > We should get drvdata from struct device directly. Going via > > platform_device is an unneeded step back and forth. > > Do you mind splitting this per driver please,

Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

Hi Geert, On Saturday, 21 April 2018 11:07:11 EEST Laurent Pinchart wrote: > On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote: > > The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs > > only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce > >

Re: [PATCH 09/61] dmaengine: qcom: simplify getting .drvdata

On Thu, Apr 19, 2018 at 04:05:39PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. Applied, thanks -- ~Vinod

Re: [PATCH 08/61] dmaengine: dw: simplify getting .drvdata

On Thu, Apr 19, 2018 at 04:05:38PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. Applied, thanks -- ~Vinod

Re: [PATCH 07/61] dma: simplify getting .drvdata

On Thu, Apr 19, 2018 at 04:05:37PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. Do you mind splitting this per driver please, that makes it easy to manage for me :) -- ~Vinod