Re: [PATCH 0/8] ARM: dts: renesas: Remove unit-addresses and regs from integrated caches

On Mon, Mar 06, 2017 at 05:40:35PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series removes the bogus unit-addresses and reg properties > from the device nodes representing Cortex-A15/A7 cache controllers. > > Note that the latter were added to remove warnings

Re: [PATCH 0/4] ARM/ARM64: renesas: Tidyup Audio-DMAC channel for DVC

On Tue, Mar 07, 2017 at 05:27:47AM +, Kuninori Morimoto wrote: > > Hi Simon > > These fixup DVC Audio-DMAC channel assignment > which was not same as SRC/SSI policy. > Because of this (is a little bit excessive), > current Playback/Capture on each platform > (= Lager/Koelsch/Gose/Salvator)

[PATCH 4/4] arm64: renesas: r8a7795: Tidyup Audio-DMAC channel for DVC

From: Kuninori Morimoto Current Audio-DMAC is assigned "rx" as Audio-DMAC0, "tx" as Audio-DMAC1. Thus, DVC "tx" should be assigned as Audio-DMAC1, instead of Audio-DMAC0. Because of this, current platform board (using SRC/DVC/SSI) Playback/Capture both will use

[PATCH 0/4] ARM/ARM64: renesas: Tidyup Audio-DMAC channel for DVC

Hi Simon These fixup DVC Audio-DMAC channel assignment which was not same as SRC/SSI policy. Because of this (is a little bit excessive), current Playback/Capture on each platform (= Lager/Koelsch/Gose/Salvator) are using same Audio-DMAC0. Playback/Capture uses different Audio-DMAC is more make

[PATCH v7 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V7

iommu/ipmmu-vmsa: IPMMU multi-arch update V7 [PATCH v7 01/07] iommu/ipmmu-vmsa: Remove platform data handling [PATCH v7 02/07] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context [PATCH v7 03/07] iommu/ipmmu-vmsa: Break out utlb parsing code [PATCH v7 04/07] iommu/ipmmu-vmsa:

[PATCH v7 07/07] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency

From: Magnus Damm Neither the ARM page table code enabled by IOMMU_IO_PGTABLE_LPAE nor the IPMMU_VMSA driver actually depends on ARM_LPAE, so get rid of the dependency. Tested with ipmmu-vmsa on r8a7794 ALT and a kernel config using: # CONFIG_ARM_LPAE is not set

[PATCH v7 01/07] iommu/ipmmu-vmsa: Remove platform data handling

From: Magnus Damm The IPMMU driver is using DT these days, and platform data is no longer used by the driver. Remove unused code. Signed-off-by: Magnus Damm Reviewed-by: Laurent Pinchart Reviewed-by:

[PATCH v7 06/07] iommu/ipmmu-vmsa: ARM and ARM64 archdata access

From: Magnus Damm Not all architectures have an iommu member in their archdata, so use #ifdefs support build with COMPILE_TEST on any architecture. Signed-off-by: Magnus Damm Reviewed-by: Joerg Roedel --- Changes since

[PATCH v7 04/07] iommu/ipmmu-vmsa: Break out domain allocation code

From: Magnus Damm Break out the domain allocation code into a separate function. This is preparation for future code sharing. Signed-off-by: Magnus Damm Reviewed-by: Joerg Roedel --- Changes since V6: - None

[PATCH v7 03/07] iommu/ipmmu-vmsa: Break out utlb parsing code

From: Magnus Damm Break out the utlb parsing code and dev_data allocation into a separate function. This is preparation for future code sharing. Signed-off-by: Magnus Damm Reviewed-by: Joerg Roedel --- Changes since V6:

[PATCH v7 02/07] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context

From: Magnus Damm Introduce a bitmap for context handing and convert the interrupt routine to handle all registered contexts. At this point the number of contexts are still limited. Also remove the use of the ARM specific mapping variable from ipmmu_irq() to allow

[PATCH v7 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

From: Magnus Damm Introduce an alternative set of iommu_ops suitable for 64-bit ARM as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the Kconfig to depend on ARM or IOMMU_DMA. Initialize the device from ->xlate() when CONFIG_IOMMU_DMA=y. Signed-off-by:

[PATCH v3] media: platform: Renesas IMR driver

From: Konstantin Kozhevnikov The image renderer, or the distortion correction engine, is a drawing processor with a simple instruction system capable of referencing video capture data or data in an external memory as the 2D texture data and performing

[PATCH] i2c: riic: fix restart condition

While modifying the driver to use the STOP interrupt, the completion of the intermediate transfers need to wake the driver back up in order to initiate the next transfer (restart condition). Otherwise you get never ending interrupts and only the first transfer sent. Fixes: 71ccea095ea1 ("i2c:

Re: [i2c-tools PATCH v2] i2ctransfer: add new tool

Hey Wolfram, On Mon, Mar 06, 2017 at 03:29:31PM +0100, Wolfram Sang wrote: > S, finally, finally, here is another version of my 'i2ctransfer' tool. > This > time, I'll keep at it until it is upstream. It was lying around long enough. > Thanks must go to Renesas for further funding this work!

[PATCH 2/7] thermal: rcar_gen3_thermal: fix probe error path

If the memory resource for a TSC is unviable probe should fail not try to go ahead with the remaining TSC. This fix is aligned with other checks in probe where probe fails if they are unavailable. Signed-off-by: Niklas Söderlund ---

[PATCH 6/7] thermal: rcar_gen3_thermal: store device match data in private structure

The device match data needs to be accessible outside the probe function, store it in the private data structure. Signed-off-by: Niklas Söderlund --- drivers/thermal/rcar_gen3_thermal.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff

[PATCH 7/7] thermal: rcar_gen3_thermal: add suspend and resume support

To restore operation it's easiest to reinitialise all TSC. In order to do this the current trip window needs to be stored in the TSC structure so that it can be restored upon resume. Signed-off-by: Niklas Söderlund --- drivers/thermal/rcar_gen3_thermal.c |

[PATCH 4/7] thermal: rcar_gen3_thermal: record more information about each TSC

The struct rcar_gen3_thermal_tsc benefits from knowing which TSC it represent. Record this at probe time before this information is lost. Signed-off-by: Niklas Söderlund --- drivers/thermal/rcar_gen3_thermal.c | 5 + 1 file changed, 5 insertions(+)

[PATCH 0/7] thermal: rcar_gen3_thermal: add support for interrupt triggerd trip points

Hi, This series adds support for hardware backed trip point windows. It is based on top of v4.11-rc1 and is tested on R-Car H3 and M3-W. The series starts out by fixing three issues (1/7, 2/7, 3/7) that should not have been fixed by me before the initial driver where submitted to upstream.

[PATCH 5/7] thermal: rcar_gen3_thermal: enable hardware interrupts for trip points

Enable hardware trip points by implementing the set_trips callback. The thermal core will take care of setting the initial trip point window and to update it once the driver reports a TSC have moved outside it. The interrupt structure for this device is a bit odd. There is not a dedicated IRQ for

[PATCH 3/7] thermal: rcar_gen3_thermal: remove unneeded mutex

There is no point in protecting a register read with a lock. This is most likely a leftover from when the driver was reworked before submitted for upstream. Signed-off-by: Niklas Söderlund --- drivers/thermal/rcar_gen3_thermal.c | 7 --- 1 file

Re: [i2c-tools PATCH v2] i2ctransfer: add new tool

Hi Geert, > > This tool allows to construct and concat multiple I2C messages into one > > single transfer. Its aim is to test I2C master controllers, and so there > > is no SMBus fallback. > > Thanks for the tool! Very welcome :) > > > I've been missing such a tool a number of times now, so I

Re: [PATCH] media: platform: Renesas IMR driver

On 03/05/2017 01:43 PM, Magnus Damm wrote: Thanks for your efforts with this driver. Nice to see that V2 is getting in better shape. In the future, would it be possible for you to include the patch version number in the [PATCH] tag somehow? Sorry, I'm still getting used to 'quilt mail'...

Re: [PATCH 1/4] v4l: vsp1: Implement partition algorithm restrictions

Hi Laurent, Morimoto-san, On 06/03/17 15:16, Laurent Pinchart wrote: > Hi Morimoto-san, > > On Monday 06 Mar 2017 06:17:47 Kuninori Morimoto wrote: >> Hi Laurent, Kieran >> I asked it to HW team. Please wait >> >> I'm still waiting from HW team's response, but can you check >>

[PATCH v2 2/6] ARM: dts: r8a7790: Add INTC-SYS clock to device tree

Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by: Geert Uytterhoeven

[PATCH v2 0/6] ARM: dts: renesas: Add INTC-SYS clock to device tree

Hi Simon, Magnus, This patch series improves the topology description in DT of the ARM GIC on Renesas SoCs using the legacy CPG/MSTP bindings (R-Mobile APE6 and R-Car Gen2). It describes the INTC-SYS clock, links the GIC to its module clock, and adds the GIC to the SYSC "always on" PM

[PATCH v2 6/6] ARM: dts: r8a7794: Add INTC-SYS clock to device tree

Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by: Geert Uytterhoeven

[PATCH v2 3/6] ARM: dts: r8a7791: Add INTC-SYS clock to device tree

Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by: Geert Uytterhoeven

[PATCH v2 5/6] ARM: dts: r8a7793: Add INTC-SYS clock to device tree

Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by: Geert Uytterhoeven

[PATCH v2 1/6] ARM: dts: r8a73a4: Add INTC-SYS clock to device tree

Link the ARM GIC to the INTC-SYS module clock and the C4 power domain, so it can be power managed using that clock in the future. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by: Geert Uytterhoeven

[PATCH v2 4/6] ARM: dts: r8a7792: Add INTC-SYS clock to device tree

Link the ARM GIC to the INTC-SYS module clock, and add it to the "always on" PM Domain, so it can be power managed using that clock. Note that currently the GIC-400 driver doesn't support module clocks nor Runtime PM, so this must be handled as a critical clock. Signed-off-by: Geert Uytterhoeven

Re: [PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties

Hi Geert, On Monday 06 Mar 2017 17:36:41 Geert Uytterhoeven wrote: > On Mon, Mar 6, 2017 at 5:32 PM, Laurent Pinchart wrote: > > On Monday 06 Mar 2017 17:25:56 Geert Uytterhoeven wrote: > >> Document the optional properties for describing module resets, to > >> support resetting display channels

Re: [PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties

Hi Laurent, On Mon, Mar 6, 2017 at 5:32 PM, Laurent Pinchart wrote: > On Monday 06 Mar 2017 17:25:56 Geert Uytterhoeven wrote: >> Document the optional properties for describing module resets, to >> support resetting display channels and LVDS encoders on R-Car

[PATCH 3/8] ARM: dts: r8a7745: Remove unit-address and reg from integrated cache

The Cortex-A7 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: c95360247bdd67d3 ("ARM: dts: r8a7745: initial SoC device tree") Signed-off-by: Geert Uytterhoeven ---

[PATCH 7/8] ARM: dts: r8a7793: Remove unit-address and reg from integrated cache

The Cortex-A15 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: ad53f5f00b095a0d ("ARM: dts: r8a7793: Fix W=1 dtc warnings") Signed-off-by: Geert Uytterhoeven ---

[PATCH 8/8] ARM: dts: r8a7794: Remove unit-address and reg from integrated cache

The Cortex-A7 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: 34ea4b4a827b4ee7 ("ARM: dts: r8a7794: Fix W=1 dtc warnings") Signed-off-by: Geert Uytterhoeven ---

[PATCH 4/8] ARM: dts: r8a7790: Remove unit-addresses and regs from integrated caches

The Cortex-A15/A7 cache controllers are integrated controllers, and thus the device nodes representing them should not have unit-addresses or reg properties. Fixes: 2c3de36700d4f3a5 ("ARM: dts: r8a7790: Fix W=1 dtc warnings") Signed-off-by: Geert Uytterhoeven ---

[PATCH 2/8] ARM: dts: r8a7743: Remove unit-address and reg from integrated cache

The Cortex-A15 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: 34e8d993a68ae459 ("ARM: dts: r8a7743: initial SoC device tree") Signed-off-by: Geert Uytterhoeven ---

[PATCH 6/8] ARM: dts: r8a7792: Remove unit-address and reg from integrated cache

The Cortex-A15 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: 7c4163aae3d8e5b9 ("ARM: dts: r8a7792: initial SoC device tree") Signed-off-by: Geert Uytterhoeven ---

[PATCH 0/8] ARM: dts: renesas: Remove unit-addresses and regs from integrated caches

Hi Simon, Magnus, This patch series removes the bogus unit-addresses and reg properties from the device nodes representing Cortex-A15/A7 cache controllers. Note that the latter were added to remove warnings from dtc when using W=1: Warning (unit_address_vs_reg): Node

[PATCH 5/8] ARM: dts: r8a7791: Remove unit-address and reg from integrated cache

The Cortex-A15 cache controller is an integrated controller, and thus the device node representing it should not have a unit-addresses or reg property. Fixes: 6f9314ce258c8504 ("ARM: dts: r8a7791: Fix W=1 dtc warnings") Signed-off-by: Geert Uytterhoeven ---

[PATCH 1/8] ARM: dts: r8a73a4: Remove unit-addresses and regs from integrated caches

The Cortex-A15/A7 cache controllers are integrated controllers, and thus the device nodes representing them should not have unit-addresses or reg properties. Fixes: b0da45c60d2f7b08 ("ARM: dts: r8a73a4: Fix W=1 dtc warnings") Signed-off-by: Geert Uytterhoeven ---

Re: [PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties

Hi Geert, Thank you for the patch. On Monday 06 Mar 2017 17:25:56 Geert Uytterhoeven wrote: > Document the optional properties for describing module resets, to > support resetting display channels and LVDS encoders on R-Car Gen2 and > Gen3. > > Signed-off-by: Geert Uytterhoeven

[PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties

Document the optional properties for describing module resets, to support resetting display channels and LVDS encoders on R-Car Gen2 and Gen3. Signed-off-by: Geert Uytterhoeven --- See "[v2,1/4] dt-bindings: clock: renesas: cpg-mssr: Document reset control support"

Re: [i2c-tools PATCH v2] i2ctransfer: add new tool

Hi Wolfram, On Mon, Mar 6, 2017 at 3:29 PM, Wolfram Sang wrote: > From: Wolfram Sang > > This tool allows to construct and concat multiple I2C messages into one > single transfer. Its aim is to test I2C master controllers, and so there > is

Re: [PATCH 1/4] v4l: vsp1: Implement partition algorithm restrictions

Hi Morimoto-san, On Monday 06 Mar 2017 06:17:47 Kuninori Morimoto wrote: > Hi Laurent, Kieran > > >>> Testing SRU-UDS scaling 768x576 - 768x576 - 640x480 in RGB24: fail > >>> Testing SRU-UDS scaling 768x576 - 768x576 - 768x576 in RGB24: pass > >>> Testing SRU-UDS scaling 768x576 - 768x576 -

Re: [PATCH v2] drm: rcar-du: Arm the page flip event after queuing the page flip

Hi Daniel, On Monday 06 Mar 2017 16:02:00 Daniel Vetter wrote: > On Sun, Mar 05, 2017 at 03:10:32AM +0200, Laurent Pinchart wrote: > > The page flip event is armed in the atomic begin handler, creating a > > race condition with the frame end interrupt that could send the event > > before the

Re: [PATCH v2] drm: rcar-du: Arm the page flip event after queuing the page flip

On Sun, Mar 05, 2017 at 03:10:32AM +0200, Laurent Pinchart wrote: > The page flip event is armed in the atomic begin handler, creating a > race condition with the frame end interrupt that could send the event > before the atomic operation actually completes. To avoid that, arm the > event in the

Re: [PATCH v2.2] v4l: Clearly document interactions between formats, controls and buffers

Hi Hans, On Monday 06 Mar 2017 11:46:28 Hans Verkuil wrote: > On 06/03/17 11:35, Laurent Pinchart wrote: > > On Monday 06 Mar 2017 11:04:50 Hans Verkuil wrote: > >> On 05/03/17 22:36, Laurent Pinchart wrote: > >>> V4L2 exposes parameters that influence buffers sizes through the format > >>>

[i2c-tools PATCH v2] i2ctransfer: add new tool

From: Wolfram Sang This tool allows to construct and concat multiple I2C messages into one single transfer. Its aim is to test I2C master controllers, and so there is no SMBus fallback. I've been missing such a tool a number of times now, so I finally got

Re: [PATCH v2.3] v4l: Clearly document interactions between formats, controls and buffers

On 06/03/17 15:14, Laurent Pinchart wrote: V4L2 exposes parameters that influence buffers sizes through the format ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly VIDIOC_G_SELECTION and VIDIOC_S_SELECTION). Other parameters not part of the format structure may also influence

[PATCH v2.3] v4l: Clearly document interactions between formats, controls and buffers

V4L2 exposes parameters that influence buffers sizes through the format ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly VIDIOC_G_SELECTION and VIDIOC_S_SELECTION). Other parameters not part of the format structure may also influence buffer sizes or buffer layout in general. One

RE: Possible Regression caused by "[PATCH] i2c: riic: correctly finish transfers"

Hi Simon, On Monday, March 06, 2017, Simon Horman wrote: > Hi, > > I have noticed a regression in v4.11-rc1 since v4.10 on r7s72100/Genmai. > > With some assistance from Geert I have isolated the problem as being > caused by 71ccea095ea1 ("i2c: riic: correctly finish transfers"). I just tried

Re: [PATCH v2.2] v4l: Clearly document interactions between formats, controls and buffers

On 06/03/17 11:35, Laurent Pinchart wrote: Hi Hans, On Monday 06 Mar 2017 11:04:50 Hans Verkuil wrote: On 05/03/17 22:36, Laurent Pinchart wrote: V4L2 exposes parameters that influence buffers sizes through the format ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly

Re: [PATCH v2.2] v4l: Clearly document interactions between formats, controls and buffers

Hi Hans, On Monday 06 Mar 2017 11:04:50 Hans Verkuil wrote: > On 05/03/17 22:36, Laurent Pinchart wrote: > > V4L2 exposes parameters that influence buffers sizes through the format > > ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly > > VIDIOC_G_SELECTION and VIDIOC_S_SELECTION).

Re: [PATCH v4 2/4] drm: bridge: Add LVDS encoder driver

Hi, On 3/2/2017 4:17 PM, Laurent Pinchart wrote: The LVDS encoder driver is a DRM bridge driver that supports the parallel to LVDS encoders that don't require any configuration. The driver thus doesn't interact with the device, but creates an LVDS connector for the panel and exposes its size

Re: [PATCH v2.2] v4l: Clearly document interactions between formats, controls and buffers

On 05/03/17 22:36, Laurent Pinchart wrote: V4L2 exposes parameters that influence buffers sizes through the format ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly VIDIOC_G_SELECTION and VIDIOC_S_SELECTION). Other parameters not part of the format structure may also influence

Re: [PATCH v2 2/3] v4l: Clearly document interactions between formats, controls and buffers

On 05/03/17 15:35, Laurent Pinchart wrote: Hi Hans, On Saturday 04 Mar 2017 11:53:45 Hans Verkuil wrote: On 28/02/17 16:03, Laurent Pinchart wrote: V4L2 exposes parameters that influence buffers sizes through the format ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT and VIDIO_S_FMT). Other parameters

Re: [PATCH/RFC v2 0/4] iommu/ipmmu-vmsa: IPMMU slave device whitelist V2

On Fri, Jan 27, 2017 at 3:14 PM, Magnus Damm wrote: > iommu/ipmmu-vmsa: IPMMU slave device whitelist V2 > > [PATCH/RFC v2 1/4] iommu/of: Skip IOMMU devices disabled in DT > [PATCH/RFC v2 2/4] iommu/ipmmu-vmsa: Get rid of disabled device check > [PATCH/RFC v2 3/4]

Re: [GIT PULL FOR renesas-drivers] R-Car Gen3 HDMI output support

Hi Geert, On Monday 06 Mar 2017 09:12:45 Geert Uytterhoeven wrote: > On Mon, Mar 6, 2017 at 1:32 AM, Laurent Pinchart wrote: > > Please find two pull requests below for renesas-drivers (in a single > > e-mail, lucky you :-)). > > > > The first tag contains driver changes only and is based on a

Re: [PATCH v2 2/3] v4l: Clearly document interactions between formats, controls and buffers

On 04/03/17 15:37, Sakari Ailus wrote: Hi Hans (and Laurent). On Sat, Mar 04, 2017 at 11:53:45AM +0100, Hans Verkuil wrote: Hi Laurent, Here is my review: On 28/02/17 16:03, Laurent Pinchart wrote: V4L2 exposes parameters that influence buffers sizes through the format ioctls (VIDIOC_G_FMT,

Re: [PATCH v3 0/5] R-Car H3 HDMI output DT integration

On Mon, Mar 06, 2017 at 02:20:21AM +0200, Laurent Pinchart wrote: > Hello, > > This patch series contains all the DT changes needed to integrate HDMI output > support for the H3 Salvator-X board. > > The patches have previously been posted as part of other patch series with > driver changes.

Re: [PATCHv2] arm64: dts: r8a7795: salvator-x: Set drive-strength for ravb pins

On Mon, Mar 06, 2017 at 12:28:18AM +0100, Niklas Söderlund wrote: > Hi Simon, > > On 2016-12-08 14:31:38 +0100, Simon Horman wrote: > > On Mon, Dec 05, 2016 at 06:43:10PM +0100, Niklas Söderlund wrote: > > > The EthernetAVB should not depend on the bootloader to setup correct > > > drive-strength

Re: [PATCH v2 3/3] arm64: renesas: r8a7796: Enable SCIF DMA

On Fri, Mar 03, 2017 at 10:54:01AM +0100, Geert Uytterhoeven wrote: > Hi Simon, > > On Thu, Mar 2, 2017 at 3:36 PM, Simon Horman wrote: > > On Tue, Feb 21, 2017 at 03:27:25PM +0100, Geert Uytterhoeven wrote: > >> On Wed, Dec 7, 2016 at 5:44 PM, Ulrich Hecht > >>

Re: [PATCH 0/2] arm64: dts: renesas: Remove unit-addresses and regs from integrated caches

On Fri, Mar 03, 2017 at 02:18:15PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series removes the bogus unit-addresses and reg properties > from the device nodes representing Cortex-A57/A53 cache controllers. > > Note that the latter were added to remove warnings

Re: [GIT PULL FOR renesas-drivers] R-Car Gen3 HDMI output support

Hi Laurent, On Mon, Mar 6, 2017 at 1:32 AM, Laurent Pinchart wrote: > Please find two pull requests below for renesas-drivers (in a single e-mail, > lucky you :-)). > > The first tag contains driver changes only and is based on a merge of drm-next > and

Re: [GIT PULL FOR renesas-drivers] VSP1 rotation and histogram

Hi Laurent, On Mon, Mar 6, 2017 at 1:47 AM, Laurent Pinchart wrote: > The following changes since commit 130f8756b9b83c0137ee0d587152a7ef3e10f74b: > > v4l: vsp1: Register pipe with output WPF (2017-03-05 01:53:46 +0200) > > are available in the git repository