Re: [PATCH] dmaengine: usb-dmac: Fix DMAOR AE bit definition

On Mon, May 15, 2017 at 05:49:52PM +0900, Yoshihiro Shimoda wrote: > From: Hiroyuki Yokoyama > > This patch fixes the register definition of AE (Address Error flag) bit. Applied, thanks -- ~Vinod

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Will, On 2017-05-15 19:52, Will Deacon wrote: Hi Sricharan, On Wed, May 03, 2017 at 03:54:59PM +0530, Sricharan R wrote: On 5/3/2017 3:24 PM, Robin Murphy wrote: > On 02/05/17 19:35, Geert Uytterhoeven wrote: >> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote:

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Laurent, On 2017-05-16 03:04, Laurent Pinchart wrote: Hi Sricharan, On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote: On Wednesday 03 May 2017 15:54:59 Sricharan R wrote: > On 5/3/2017 3:24 PM, Robin Murphy wrote: >> On 02/05/17 19:35, Geert Uytterhoeven wrote: >>> On Fri, Feb 3, 2017

[PATCH] ASoC: rsnd: don't use PDTA bit for 24bit on SSI

From: Kuninori Morimoto Current SSI uses PDTA bit which indicates data that Input/Output data are Right-Aligned. But, 24bit sound should be Left-Aligned in this HW. Because Linux is using Right-Aligned data, and HW uses Left-Aligned data, current 24bit data is

[PATCH] ASoC: rsnd: don't call free_irq() on Parent SSI

From: Kuninori Morimoto If SSI uses shared pin, some SSI will be used as parent SSI. Then, normal SSI's remove and Parent SSI's remove (these are same SSI) will be called when unbind or remove timing. In this case, free_irq() will be called twice. This patch

Re: [PATCH v2 02/10] pinctrl: sh-pfc: r8a7796: add Audio SSI pin support

Hi Geert > >> Does this affect H3 ES1.0, too? > >> My main worry there is that the name "ssi34_ctrl" is part of the DT ABI, > >> so we have to keep that as an alias for "ssi349_ctrl". > > > > I think this is from Gen3, not ESx. > > And no-one is using SSI34 on upstream code. > > Should we care

Re: [PATCH 3/3] dmaengine: rcar-dmac: wait for ISR to finish before freeing resources

Hi Vinod, On 2017-05-14 17:31:36 +0530, Vinod Koul wrote: > On Fri, May 12, 2017 at 02:49:38PM +0200, Niklas Söderlund wrote: > > On 2017-04-07 14:33:47 +0300, Laurent Pinchart wrote: > > > Hi Geert, > > > > > > On Wednesday 05 Apr 2017 12:40:11 Geert Uytterhoeven wrote: > > > > On Wed, Apr 5,

[PATCH v2 2/3] dmaengine: rcar-dmac: implement device_synchronize()

Implement the device_synchronize() callback which wait until a dma channel is stopped to provide a synchronization point. This protects the driver from multiple race conditions when terminating and freeing resources. E.g. the completion callback still running after device_terminate_all() has

[PATCH v2 3/3] dmaengine: rcar-dmac: wait for ISR to finish before freeing resources

This fixes a race condition where the channel resources could be freed before the ISR had finished running resulting in a NULL pointer reference from the ISR. [ 167.148934] Unable to handle kernel NULL pointer dereference at virtual address [ 167.157051] pgd = 80003c641000 [

[PATCH v2 1/3] dmaengine: rcar-dmac: store channel IRQ in struct rcar_dmac_chan

The IRQ number is needed after probe to be able to add synchronisation points in other places in the driver when freeing resources and to implement a device_synchronize() callback. Store the IRQ number in the struct rcar_dmac_chan so that it can be used later. Signed-off-by: Niklas Söderlund

[PATCH v2 0/3] dmaengine: rcar-dmac: fix resource freeing synchronization

Hi, This series fix resource freeing synchronization by: 1. Patch 1/3 Store the IRQ number in the global struct so it can be used later together with synchronize_irq(). 2. Patch 2/3 Adding support for the device_synchronize() callback in patch 2/3. 3. Patch 3/3 Waiting for any ISR

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Sricharan, On Monday 15 May 2017 23:37:16 Laurent Pinchart wrote: > On Wednesday 03 May 2017 15:54:59 Sricharan R wrote: > > On 5/3/2017 3:24 PM, Robin Murphy wrote: > >> On 02/05/17 19:35, Geert Uytterhoeven wrote: > >>> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote: > From: Laurent

Re: [PATCH v4] dt-bindings: pwm: Add R-Car M3-W device tree bindings

On Fri, May 12, 2017 at 10:09:42AM +0200, Simon Horman wrote: > From: Ulrich Hecht > > Add device tree bindings for the PWM controller found on R-Car M3-W SoCs. > > Signed-off-by: Ulrich Hecht > --- > v4 > * Broke out of lager

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Sricharan, On Wednesday 03 May 2017 15:54:59 Sricharan R wrote: > On 5/3/2017 3:24 PM, Robin Murphy wrote: > > On 02/05/17 19:35, Geert Uytterhoeven wrote: > >> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote: > >>> From: Laurent Pinchart > >>> >

Re: [PATCH v4 0/3] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0

Hi Simon, On Mon, May 15, 2017 at 8:40 PM, Simon Horman wrote: > On Mon, May 15, 2017 at 02:44:10PM +0200, Geert Uytterhoeven wrote: >> This patch series adds support for Renesas Salvator-X and H3ULCB >> development boards equipped with revision ES2.0 of the R-Car H3 SoC.

Re: [PATCH] arm64: dts: renesas: r8a7795: Use GIC_SPI for HDMI interrupts

On Mon, May 15, 2017 at 04:53:05PM +0200, Simon Horman wrote: > On Mon, May 15, 2017 at 12:52:41PM +0300, Laurent Pinchart wrote: > > Use the GIC_SPI macro instead of hardcoding its value in the HDMI > > interrupts specifiers. > > > > Signed-off-by: Laurent Pinchart

Re: [PATCH v4 0/3] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0

the DU node in r8a7795.dtsi, > in addition to the "vsps" property, > - Add support for ES2.0-based H3ULCB. > > For changes compared to v1 (which was not posted), please refer to the > individual patches. > > Dependencies: > - This patch series is against

Re: [PATCH] arm64: dts: renesas: r8a7795: Use GIC_SPI for HDMI interrupts

On Mon, May 15, 2017 at 12:52:41PM +0300, Laurent Pinchart wrote: > Use the GIC_SPI macro instead of hardcoding its value in the HDMI > interrupts specifiers. > > Signed-off-by: Laurent Pinchart > --- > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--

[ANN] R-Car H3 VIN and RDACM20 camera support prototype

recent VIN driver version. All patches are available from git://linuxtv.org/pinchartl/media.git vin-gmsl-20170515 Testing is pretty straightforward. On the hardware side, make sure to set SW29 to OFF-OFF on the Salvator-X board to select the external CSI-2 devices, to remove the J19

Re: [RFC v2 0/2] SH CEU camera driver

Hi Chris, On Thu, Apr 27, 2017 at 06:03:27PM +, Chris Brandt wrote: > Hi Jacopo, > > On Thursday, April 27, 2017, jmondi wrote: > > We planned to use the following setup to test the CEU driver with an > > actual HW platform > > > > GR-Peach + GR-Peach Audio Camera Shield + OV7670 evaluation

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Sricharan, On Wed, May 03, 2017 at 03:54:59PM +0530, Sricharan R wrote: > On 5/3/2017 3:24 PM, Robin Murphy wrote: > > On 02/05/17 19:35, Geert Uytterhoeven wrote: > >> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R > >> wrote: > >>> From: Laurent Pinchart

Re: [PATCH 2/2] arm64: dts: r8a7795: salvator-x: Move HDMI0 to common Salvator-X board support

Hi Laurent, On Mon, May 15, 2017 at 2:29 PM, Laurent Pinchart wrote: > On Monday 15 May 2017 14:22:44 Geert Uytterhoeven wrote: >> The extensions to the first HDMI device and connector nodes apply to >> Salvator-X boards equipped with either an R-Car H3 or M3-W

[PATCH v4 1/3] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0

Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: - The following devices no longer exist on ES2.0, and are thus removed: fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. - The DU <-> VSPD topology is different on ES2.0, hence remove the "compatible" and "vsps"

[PATCH v4 3/3] arm64: dts: r8a7795: h3ulcb: Add support for R-Car H3 ES2.0

Split off support for H3ULCB boards with the ES1.x revision of the R-Car H3 SoC into a separate file. The main r8a7795-h3ulcb.dts file now corresponds to H3ULCB with R-Car H3 ES2.0 or later. Signed-off-by: Geert Uytterhoeven --- v4: - No changes, v3: - New. ---

[PATCH v4 0/3] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0

move the "compatible" property from the DU node in r8a7795.dtsi, in addition to the "vsps" property, - Add support for ES2.0-based H3ULCB. For changes compared to v1 (which was not posted), please refer to the individual patches. Dependencies: - This patch series is

[PATCH v4 2/3] arm64: dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0

Split off support for Salvator-X boards with the ES1.x revision of the R-Car H3 SoC into a separate file. The main r8a7795-salvator-x.dts file now corresponds to Salvator-X with R-Car H3 ES2.0 or later. Signed-off-by: Geert Uytterhoeven --- v4: - Rebase on top of

Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver

Hi Sakari On 12/05/17 17:46, Sakari Ailus wrote: > Hi Kieran, > > Thanks for the patches! Thankyou for the review! > Would you have a media-ctl -p && media-ctl --print-dot (or the PS file) to > see how this looks like in practice? The file I linked to on Friday showed the immutable links

Re: [PATCH 2/2] arm64: dts: r8a7795: salvator-x: Move HDMI0 to common Salvator-X board support

Hi Geert, Thank you for the patch. On Monday 15 May 2017 14:22:44 Geert Uytterhoeven wrote: > The extensions to the first HDMI device and connector nodes apply to > Salvator-X boards equipped with either an R-Car H3 or M3-W SoC. > Hence move them from the R-Car H3 specific board file to the

[PATCH 1/2] arm64: dts: r8a7796: Add placeholder for HDMI device

Add an empty device node with ports boilerplate serving as a placeholder for the HDMI device. HDMI is not yet supported and/or tested on R-Car M3-W, but is supported and used on Salvator-X boards with an R-Car H3 SoC. Hence a placeholder will allow common board support to refer to it.

[PATCH 0/2] arm64: dts: salvator-x: Move HDMI0 to common Salvator-X board support

Hi Simon, Magnus, The extensions to the first HDMI device and connector nodes apply to Salvator-X boards equipped with either an R-Car H3 (ES1.0 or ES2.0) or M3-W SoC. Hence move them from the R-Car H3 specific board file to the common Salvator-X board file. This requires adding a

Re: [PATCH v2] ASoC: rsnd: tidyup Sampling rate convert example on Document

Hi Morimoto-san, On 2017-05-15 08:11:21 +, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > "renesas,rsrc-card" is exchanged to "simple-scu-audio-card". > Let's update Document > > Signed-off-by: Kuninori Morimoto >

[PATCH] arm64: dts: renesas: r8a7795: Use GIC_SPI for HDMI interrupts

Use the GIC_SPI macro instead of hardcoding its value in the HDMI interrupts specifiers. Signed-off-by: Laurent Pinchart --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Hi Simon, Sorry for having

Re: [PATCH v2 02/10] pinctrl: sh-pfc: r8a7796: add Audio SSI pin support

Hi Morimoto-san, On Mon, May 15, 2017 at 11:07 AM, Kuninori Morimoto wrote: >> > r8a7795 is still using old (= 34) naming now. >> >> Does this affect H3 ES1.0, too? >> My main worry there is that the name "ssi34_ctrl" is part of the DT ABI, >> so we have to keep

Re: [PATCH v2 02/10] pinctrl: sh-pfc: r8a7796: add Audio SSI pin support

Hi Geert > > r8a7795 is still using old (= 34) naming now. > > Does this affect H3 ES1.0, too? > My main worry there is that the name "ssi34_ctrl" is part of the DT ABI, > so we have to keep that as an alias for "ssi349_ctrl". I think this is from Gen3, not ESx. And no-one is using SSI34 on

Re: [PATCH] dmaengine: usb-dmac: Fix DMAOR AE bit definition

On Mon, May 15, 2017 at 10:49 AM, Yoshihiro Shimoda wrote: > From: Hiroyuki Yokoyama > > This patch fixes the register definition of AE (Address Error flag) bit. > > Fixes: 0c1c8ff32fa2 ("dmaengine: usb-dmac: Add Renesas USB DMA

Re: [PATCH v2 02/10] pinctrl: sh-pfc: r8a7796: add Audio SSI pin support

Hi Morimoto-san, On Mon, May 15, 2017 at 2:23 AM, Kuninori Morimoto wrote: >> > +static const unsigned int ssi34_ctrl_pins[] = { >> > + /* SCK, WS */ >> > + RCAR_GP_PIN(6, 5), RCAR_GP_PIN(6, 6), >> > +}; >> > +static const unsigned int

[PATCH] dmaengine: usb-dmac: Fix DMAOR AE bit definition

From: Hiroyuki Yokoyama This patch fixes the register definition of AE (Address Error flag) bit. Fixes: 0c1c8ff32fa2 ("dmaengine: usb-dmac: Add Renesas USB DMA Controller (USB-DMAC) driver") Cc: # v4.1+ Signed-off-by: Hiroyuki Yokoyama

[PATCH v2] ASoC: rsnd: tidyup Sampling rate convert example on Document

From: Kuninori Morimoto "renesas,rsrc-card" is exchanged to "simple-scu-audio-card". Let's update Document Signed-off-by: Kuninori Morimoto --- v1 -> v2 - simple-scu-card -> simple-scu-audio-card on git log

Applied "ASoC: ak4613: disable asymmetric audio interface format" to the asoc tree

The patch ASoC: ak4613: disable asymmetric audio interface format has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Re: [PATCH] ASoC: rsnd: tidyup Sampling rate convert example on Document

Hi Niklas > > "renesas,rsrc-card" is exchanged to "simple-scu-card". > > Let's update Document > > You state "simple-scu-audio-card" in the patch not "simple-scu-card", is > this intentional or a typo? Oops "simple-scu-card" is driver name, "simple-scu-audio-card" is compatible name I will

Re: [PATCH] ASoC: rsnd: tidyup Sampling rate convert example on Document

Hi Morimoto-san, On 2017-05-15 01:59:51 +, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > "renesas,rsrc-card" is exchanged to "simple-scu-card". > Let's update Document You state "simple-scu-audio-card" in the patch not "simple-scu-card", is this

Re: [PATCH v2 4/8] arm64: dts: r8a7796: salvator-x: Add panel backlight support

On Mon, May 15, 2017 at 09:50:39AM +0300, Laurent Pinchart wrote: > Hi Simon, > > On Monday 15 May 2017 07:48:11 Simon Horman wrote: > > On Sat, May 13, 2017 at 09:56:12PM +0300, Laurent Pinchart wrote: > > > Hi Simon, > > > > > > I'm afraid you added nodes in the wrong places when applying the

Re: [PATCH/RFT renesas-devel] arm64: dts: ulcb: Set drive-strength for ravb pins

On Fri, May 12, 2017 at 04:39:03PM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Tue, May 2, 2017 at 12:30 PM, Simon Horman > wrote: > > The EthernetAVB should not depend on the bootloader to setup correct > > drive-strength values. Values for drive-strength

Re: [PATCH v5 0/6] R-Car H3 HDMI output DT integration

On Mon, May 15, 2017 at 08:52:56AM +0200, Simon Horman wrote: > On Sun, May 14, 2017 at 02:16:12AM +0300, 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

Re: [PATCH v5 0/6] R-Car H3 HDMI output DT integration

On Sun, May 14, 2017 at 02:16:12AM +0300, 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 been rebased on top of a merge of Simon's latest devel branch > and v4.12-rc1,

Re: [PATCH v2 4/8] arm64: dts: r8a7796: salvator-x: Add panel backlight support

Hi Simon, On Monday 15 May 2017 07:48:11 Simon Horman wrote: > On Sat, May 13, 2017 at 09:56:12PM +0300, Laurent Pinchart wrote: > > Hi Simon, > > > > I'm afraid you added nodes in the wrong places when applying the patch to > > salvator-x.dtsi :-( Please see below. > > > > On Thursday 27 Apr