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

[Vinod Koul]

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

[sricharan]

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:
>>> From: Laurent Pinchart 
>>>
>>> Failures to look up an IOMMU when parsing the DT iommus property need to
>>> be handled separately from the .of_xlate() failures to support deferred
>>> probing.
>>>
>>> The lack of a registered IOMMU can be caused by the lack of a driver for
>>> the IOMMU, the IOMMU device probe not having been performed yet, having
>>> been deferred, or having failed.
>>>
>>> The first case occurs when the device tree describes the bus master and
>>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>>> or the device driver has not been compiled in. Return NULL, the caller
>>> will configure the device without an IOMMU.
>>>
>>> The second and third cases are handled by deferring the probe of the bus
>>> master device which will eventually get reprobed after the IOMMU.
>>>
>>> The last case is currently handled by deferring the probe of the bus
>>> master device as well. A mechanism to either configure the bus master
>>> device without an IOMMU or to fail the bus master device probe depending
>>> on whether the IOMMU is optional or mandatory would be a good
>>> enhancement.
>>>
>>> Tested-by: Marek Szyprowski 
>>> Signed-off-by: Laurent Pichart 
>>> Signed-off-by: Sricharan R 
>>
>> This patch broke Renesas R-Car Gen3 platforms in renesas-drivers.
>> As the IOMMU nodes in DT are not yet enabled, all devices having iommus
>> properties in DT now fail to probe.
>
> How exactly do they fail to probe? Per d7b0558230e4, if there are no ops
> registered then they should merely defer until we reach the point of
> giving up and ignoring the IOMMU. Is it just that you have no other
> late-probing drivers or post-init module loads to kick the deferred
> queue after that point? I did try to find a way to explicitly kick it
> from a suitably late initcall, but there didn't seem to be any obvious
> public interface - anyone have any suggestions?
>
> I think that's more of a general problem with the probe deferral
> mechanism itself (I've seen the same thing happen with some of the
> CoreSight stuff on Juno due to the number of inter-component
> dependencies) rather than any specific fault of this series.
>

I was thinking of an additional check like below to avoid the
situation ?

From 499b6e662f60f23740b8880882b0a16f16434501 Mon Sep 17 00:00:00 2001
From: Sricharan R 
Date: Wed, 3 May 2017 13:16:59 +0530
Subject: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER

While returning EPROBE_DEFER for iommu masters
take in to account of iommu nodes that could be
marked in DT as 'status=disabled', in which case
simply return NULL and let the master's probe
continue rather than deferring.

Signed-off-by: Sricharan R 
---
 drivers/iommu/of_iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 9f44ee8..e6e9bec 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct 
device_node *np)


ops = iommu_ops_from_fwnode(fwnode);
if ((ops && !ops->of_xlate) ||
+   !of_device_is_available(iommu_spec->np) ||
(!ops && !of_iommu_driver_present(iommu_spec->np)))
return NULL;


Without this patch, v4.12-rc1 hangs on my Juno waiting to mount the 
root
filesystem. The problem is that the USB controller is behind an SMMU 
which
is marked as 'status = "disabled"' in the devicetree. Whilst there was 
a
separate thread with Ard about exactly what this means in terms of the 
DMA

ops used by upstream devices, your patch above fixes the regression and
I think should go in regardless. The DMA ops issue will likely require
an additional DT binding anyway, to advertise the behaviour of the
IOMMU when it is disabled.

Tested-by: Will Deacon 
Acked-by: Will Deacon 

Could you resend it as a proper patch, please?


Sure, will send this as a separate patch.

Regards,
 Sricharan

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

[sricharan]

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 at 4:48 PM, Sricharan R wrote:
 From: Laurent Pinchart 

 Failures to look up an IOMMU when parsing the DT iommus property need
 to be handled separately from the .of_xlate() failures to support
 deferred probing.

 The lack of a registered IOMMU can be caused by the lack of a driver
 for the IOMMU, the IOMMU device probe not having been performed yet,
 having been deferred, or having failed.

 The first case occurs when the device tree describes the bus master
 and IOMMU topology correctly but no device driver exists for the IOMMU
 yet or the device driver has not been compiled in. Return NULL, the
 caller will configure the device without an IOMMU.

 The second and third cases are handled by deferring the probe of the
 bus master device which will eventually get reprobed after the IOMMU.

 The last case is currently handled by deferring the probe of the bus
 master device as well. A mechanism to either configure the bus master
 device without an IOMMU or to fail the bus master device probe
 depending on whether the IOMMU is optional or mandatory would be a good
 enhancement.

 Tested-by: Marek Szyprowski 
 Signed-off-by: Laurent Pichart
 
 Signed-off-by: Sricharan R 
>>>
>>> This patch broke Renesas R-Car Gen3 platforms in renesas-drivers.
>>> As the IOMMU nodes in DT are not yet enabled, all devices having iommus
>>> properties in DT now fail to probe.
>>
>> How exactly do they fail to probe? Per d7b0558230e4, if there are no ops
>> registered then they should merely defer until we reach the point of
>> giving up and ignoring the IOMMU. Is it just that you have no other
>> late-probing drivers or post-init module loads to kick the deferred
>> queue after that point? I did try to find a way to explicitly kick it
>> from a suitably late initcall, but there didn't seem to be any obvious
>> public interface - anyone have any suggestions?
>>
>> I think that's more of a general problem with the probe deferral
>> mechanism itself (I've seen the same thing happen with some of the
>> CoreSight stuff on Juno due to the number of inter-component
>> dependencies) rather than any specific fault of this series.
>
> I was thinking of an additional check like below to avoid the
> situation ?
>
> From 499b6e662f60f23740b8880882b0a16f16434501 Mon Sep 17 00:00:00 2001
> From: Sricharan R 
> Date: Wed, 3 May 2017 13:16:59 +0530
> Subject: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER
>
> While returning EPROBE_DEFER for iommu masters
> take in to account of iommu nodes that could be
> marked in DT as 'status=disabled', in which case
> simply return NULL and let the master's probe
> continue rather than deferring.
>
> Signed-off-by: Sricharan R 
> ---
>
>  drivers/iommu/of_iommu.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 9f44ee8..e6e9bec 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct device_node
> *np)
>
> ops = iommu_ops_from_fwnode(fwnode);
> if ((ops && !ops->of_xlate) ||
> +   !of_device_is_available(iommu_spec->np) ||
> (!ops && !of_iommu_driver_present(iommu_spec->np)))
> return NULL;

This looks good to me, but won't be enough. The ipmmu-vmsa driver in
v4.12-rc1 doesn't call iommu_device_register() and thus won't be found 
by
iommu_ops_from_fwnode(). Furthermore, it doesn't IOMMU_OF_DECLARE(), 
and

thus will always be considered as absent.

I agree that the ipmmu-vmsa driver needs to be fixed, but it would 
have been
nice to check existing IOMMU drivers before merging this patch 
series...


Please pardon the question, but has this patch series been tested on 
ARM32 ?


When the device is probed the arch_setup_dma_ops() function is called. 
It sets
the device's dma_ops and the mapping (in __arm_iommu_attach_device()). 
If
probe is deferred, arch_teardown_dma_ops() is called which in turn 
calls

arch_teardown_dma_ops(). This removes the mapping but doesn't touch the
dma_ops. The next time the device is probed, arch_setup_dma_ops() bails 
out
immediately as the dma_ops are already set, leaving us with a device 
bound to
IOMMU operations but with no mapping. This oopses later as soon as the 
kernel

tries to map memory for the device through the IOMMU.


Resetting the dma_ops for arm32 was added in this 

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

[Kuninori Morimoto]

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 missing lower 8bit.
To fix this issue, this patch removes PDTA bit, and shift 8bit
in necessary module

Reported-by: Hiroyuki Yokoyama 
Signed-off-by: Kuninori Morimoto 
Tested-by: Hiroyuki Yokoyama 
---
 sound/soc/sh/rcar/cmd.c  |  1 +
 sound/soc/sh/rcar/core.c | 51 
 sound/soc/sh/rcar/gen.c  |  1 +
 sound/soc/sh/rcar/rsnd.h |  2 ++
 sound/soc/sh/rcar/src.c  | 12 ++--
 sound/soc/sh/rcar/ssi.c  |  2 +-
 sound/soc/sh/rcar/ssiu.c |  3 ++-
 7 files changed, 68 insertions(+), 4 deletions(-)

diff --git a/sound/soc/sh/rcar/cmd.c b/sound/soc/sh/rcar/cmd.c
index 7d92a24..d879c01 100644
--- a/sound/soc/sh/rcar/cmd.c
+++ b/sound/soc/sh/rcar/cmd.c
@@ -89,6 +89,7 @@ static int rsnd_cmd_init(struct rsnd_mod *mod,
dev_dbg(dev, "ctu/mix path = 0x%08x", data);
 
rsnd_mod_write(mod, CMD_ROUTE_SLCT, data);
+   rsnd_mod_write(mod, CMD_BUSIF_MODE, rsnd_get_busif_shift(io, mod) | 1);
rsnd_mod_write(mod, CMD_BUSIF_DALIGN, rsnd_get_dalign(mod, io));
 
rsnd_adg_set_cmd_timsel_gen2(mod, io);
diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index e36a6b5..6264b39 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -343,6 +343,57 @@ u32 rsnd_get_dalign(struct rsnd_mod *mod, struct 
rsnd_dai_stream *io)
return 0x76543210;
 }
 
+u32 rsnd_get_busif_shift(struct rsnd_dai_stream *io, struct rsnd_mod *mod)
+{
+   enum rsnd_mod_type playback_mods[] = {
+   RSND_MOD_SRC,
+   RSND_MOD_CMD,
+   RSND_MOD_SSIU,
+   };
+   enum rsnd_mod_type capture_mods[] = {
+   RSND_MOD_CMD,
+   RSND_MOD_SRC,
+   RSND_MOD_SSIU,
+   };
+   struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
+   struct rsnd_mod *tmod = NULL;
+   enum rsnd_mod_type *mods =
+   rsnd_io_is_play(io) ?
+   playback_mods : capture_mods;
+   int i;
+
+   /*
+* This is needed for 24bit data
+* We need to shift 8bit
+*
+* Linux 24bit data is located as 0x00**
+* HW24bit data is located as 0x**00
+*
+*/
+   switch (runtime->sample_bits) {
+   case 16:
+   return 0;
+   case 32:
+   break;
+   }
+
+   for (i = 0; i < ARRAY_SIZE(playback_mods); i++) {
+   tmod = rsnd_io_to_mod(io, mods[i]);
+   if (tmod)
+   break;
+   }
+
+   if (tmod != mod)
+   return 0;
+
+   if (rsnd_io_is_play(io))
+   return  (0 << 20) | /* shift to Left */
+   (8 << 16);  /* 8bit */
+   else
+   return  (1 << 20) | /* shift to Right */
+   (8 << 16);  /* 8bit */
+}
+
 /*
  * rsnd_dai functions
  */
diff --git a/sound/soc/sh/rcar/gen.c b/sound/soc/sh/rcar/gen.c
index 99f93a17..ee00e35 100644
--- a/sound/soc/sh/rcar/gen.c
+++ b/sound/soc/sh/rcar/gen.c
@@ -238,6 +238,7 @@ static int rsnd_gen2_probe(struct rsnd_priv *priv)
RSND_GEN_M_REG(SRC_ROUTE_MODE0, 0xc,0x20),
RSND_GEN_M_REG(SRC_CTRL,0x10,   0x20),
RSND_GEN_M_REG(SRC_INT_ENABLE0, 0x18,   0x20),
+   RSND_GEN_M_REG(CMD_BUSIF_MODE,  0x184,  0x20),
RSND_GEN_M_REG(CMD_BUSIF_DALIGN,0x188,  0x20),
RSND_GEN_M_REG(CMD_ROUTE_SLCT,  0x18c,  0x20),
RSND_GEN_M_REG(CMD_CTRL,0x190,  0x20),
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index af6d57b..cc929fc 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -74,6 +74,7 @@ enum rsnd_reg {
RSND_REG_SCU_SYS_INT_EN0,
RSND_REG_SCU_SYS_INT_EN1,
RSND_REG_CMD_CTRL,
+   RSND_REG_CMD_BUSIF_MODE,
RSND_REG_CMD_BUSIF_DALIGN,
RSND_REG_CMD_ROUTE_SLCT,
RSND_REG_CMDOUT_TIMSEL,
@@ -207,6 +208,7 @@ void rsnd_bset(struct rsnd_priv *priv, struct rsnd_mod 
*mod, enum rsnd_reg reg,
u32 mask, u32 data);
 u32 rsnd_get_adinr_bit(struct rsnd_mod *mod, struct rsnd_dai_stream *io);
 u32 rsnd_get_dalign(struct rsnd_mod *mod, struct rsnd_dai_stream *io);
+u32 rsnd_get_busif_shift(struct rsnd_dai_stream *io, struct rsnd_mod *mod);
 
 /*
  * R-Car DMA
diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
index e395fcb..7aa239e 100644
--- a/sound/soc/sh/rcar/src.c
+++ b/sound/soc/sh/rcar/src.c
@@ -172,11 +172,13 @@ static void rsnd_src_set_convert_rate(struct 
rsnd_dai_stream *io,
struct 

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

[Kuninori Morimoto]

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 solve this issue.

Signed-off-by: Kuninori Morimoto 
Tested-by: Hiroyuki Yokoyama 
---
 sound/soc/sh/rcar/ssi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 5960042..e23fcab 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -726,6 +726,11 @@ static int rsnd_ssi_dma_remove(struct rsnd_mod *mod,
   struct rsnd_priv *priv)
 {
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
+   struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
+
+   /* Do nothing for SSI parent mod */
+   if (ssi_parent_mod == mod)
+   return 0;
 
/* PIO will request IRQ again */
free_irq(ssi->irq, mod);
-- 
1.9.1

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

[Kuninori Morimoto]

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 about out-of-tree user ?
> 
> Probably not, especially for H3 ES1.x.

Sorry, I didn't explain.
This is from Gen3, and ES1.x version datasheet has typo.
But datasheet team no more update for it.

For example on v0.5 datasheet (= for ES1.x)

6. Pin Function Controller (PFC)
6.2.2  GPIO/Peripheral Function Select Register (GPSR0-7)

This has SSI_xxx_0129 (= this is typo), but

41. Serial Sound Interface Unit (SSIU)
41.1.3 External Pins

This has SSI_xxx_01239

Can you agree about SSI_xxx_01239 / SSI_349 are from Gen3, not ES1.x ?

> > OK. will do in v3
> 
> OK, thanks!

Oops, sorry, not v3, but incremental patch.
I will post this patch (= fixup SSI_349) if I could find my posted patches
on your sh-pfc-for-v4.13.

Best regards
---
Kuninori Morimoto

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

[Niklas Söderlund]

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, 2017 at 11:14 AM, Niklas Söderlund wrote:
> > > > > On 2017-04-05 08:55:31 +0530, Vinod Koul wrote:
> > > > >> On Thu, Mar 30, 2017 at 09:38:39AM +0200, Niklas Söderlund wrote:
> > > > >>> On 2017-03-29 15:30:42 +0200, Niklas Söderlund wrote:
> > > >  On 2017-03-29 14:31:33 +0200, Geert Uytterhoeven wrote:
> > > > > On Wed, Mar 29, 2017 at 12:40 AM, Niklas Söderlund wrote:
> > > > >> 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
> > > > >> [  167.160449] [] *pgd=7c507003,
> > > > >> *pud=7c4ff003, *pmd=
> > > > >> [  167.168719] Internal error: Oops: 9646 [#1] PREEMPT SMP
> > > > >> [  167.174289] Modules linked in:
> > > > >> [  167.177348] CPU: 3 PID: 10547 Comm: dma_ioctl Not tainted
> > > > >> 4.11.0-rc1-1-g8d92afddc2f6633a #73
> > > > >> [  167.186131] Hardware name: Renesas Salvator-X board based on
> > > > >> r8a7795 (DT)
> > > > >> [  167.192917] task: 80003a411a00 task.stack: 
> > > > >> 80003bcd4000
> > > > >> [  167.198850] PC is at rcar_dmac_chan_prep_sg+0xe0/0x400
> > > > >> [  167.203985] LR is at rcar_dmac_chan_prep_sg+0x48/0x400
> > > > > 
> > > > > Do you have a test case to trigger this?
> > > >  
> > > >  Yes I have a testcase, it's rather complex and involves both a 
> > > >  kernel
> > > >  module and a userspaces application to stress the rcar-dmac. I'm
> > > >  checking if I can share this publicly or not, please hold :-)
> > > > >>> 
> > > > >>> I have now received feedback that I'm unfortunately not allowed to
> > > > >>> share the test case :-(
> > > > >>> 
> > > > >>> The big picture in how to trigger this problem is that you start a 
> > > > >>> DMA
> > > > >>> transfer like this:
> > > > >>> 
> > > > >>> struct dma_async_tx_descriptor *tx = ...;
> > > > >>> 
> > > > >>> ...
> > > > >>> 
> > > > >>> tx->tx_submit(tx);
> > > > >>> 
> > > > >>> And then you directly call dma_release_channel() on this channel
> > > > >>> without making sure the completion callback ran or anything. Now if 
> > > > >>> you
> > > > >>> are unlucky the ISR have not finished running for the DMA when
> > > > >>> dma_release_channel() starts to clean up resources. The 
> > > > >>> synchronisation
> > > > >>> point in the dma_release_channel() call path fixes this.
> > > > >> 
> > > > >> Well the API expectation would be you abort the txn before calling
> > > > >> release. So the expected order should be:
> > > > >> 
> > > > >> dmaengine_terminate_all();
> > > > >> dma_release_channel();
> > > > > 
> > > > > Agree this is the correct way and in this case patch 3/3 in this 
> > > > > series
> > > > > could be dropped. Then device_synchronize() would added to rcar-dmac,
> > > > > dmaengine_terminate_all() would turn of the IRQ and
> > > > > dma_release_channel() would ensure that device_synchronize() is called
> > > > > prior to calling rcar-dmac device_free_chan_resources().
> > > > > 
> > > > >> Terminate should then stop the channel, ie abort the pending
> > > > >> descriptors..
> > > > > 
> > > > > However for reasons unknown to me the rcar-dmac
> > > > > device_free_chan_resources() implementation implements logic to turn 
> > > > > of
> > > > > IRQs before it frees the resources. And it's because of this patch 3/3
> > > > > is needed so that it can be sure no ISR is running before it frees
> > > > > resources.
> > > > > 
> > > > > I don't know how to best proceed here. I agree it feels a bit odd that
> > > > > device_free_chan_resources() is dealing with the IRQs as such things
> > > > > should be done before it's called. But on the other hand that code has
> > > > > been part of the driver since it was added upstream. I feel a bit
> > > > > uncomfortable just removing that part from the
> > > > > device_free_chan_resources() since the driver have been in use with it
> > > > > for such a long time.
> > > > > 
> > > > > How would you prefer I try and resolve this?
> > > > 
> > > > Perhaps Laurent knows why it was implemented this way?
> > > 
> > > That was nearly 3 years ago, and I can hardly remember reasons related to 
> > > code 
> > > I wrote 3 months ago :-)
> > > 
> > > I might just have been overcautious, guarding against conditions that 
> > > should 
> > > not happen if the caller behaves correctly. The situation might have 
> > > 

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

[Niklas Söderlund]

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 completed.

Signed-off-by: Niklas Söderlund 
---
 drivers/dma/sh/rcar-dmac.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index c68c3336bdad44df..fb07cd5fe77b3c43 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1365,6 +1365,13 @@ static void rcar_dmac_issue_pending(struct dma_chan 
*chan)
spin_unlock_irqrestore(>lock, flags);
 }
 
+static void rcar_dmac_device_synchronize(struct dma_chan *chan)
+{
+   struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+
+   synchronize_irq(rchan->irq);
+}
+
 /* 
-
  * IRQ handling
  */
@@ -1846,6 +1853,7 @@ static int rcar_dmac_probe(struct platform_device *pdev)
engine->device_terminate_all = rcar_dmac_chan_terminate_all;
engine->device_tx_status = rcar_dmac_tx_status;
engine->device_issue_pending = rcar_dmac_issue_pending;
+   engine->device_synchronize = rcar_dmac_device_synchronize;
 
ret = dma_async_device_register(engine);
if (ret < 0)
-- 
2.13.0

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

[Niklas Söderlund]

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
[  167.160449] [] *pgd=7c507003, *pud=7c4ff003, 
*pmd=
[  167.168719] Internal error: Oops: 9646 [#1] PREEMPT SMP
[  167.174289] Modules linked in:
[  167.177348] CPU: 3 PID: 10547 Comm: dma_ioctl Not tainted 
4.11.0-rc1-1-g8d92afddc2f6633a #73
[  167.186131] Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
[  167.192917] task: 80003a411a00 task.stack: 80003bcd4000
[  167.198850] PC is at rcar_dmac_chan_prep_sg+0xe0/0x400
[  167.203985] LR is at rcar_dmac_chan_prep_sg+0x48/0x400

Based of previous work by:
Hiroyuki Yokoyama .

Signed-off-by: Niklas Söderlund 
---
 drivers/dma/sh/rcar-dmac.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index fb07cd5fe77b3c43..d2cb4a0916e62e62 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1010,7 +1010,11 @@ static void rcar_dmac_free_chan_resources(struct 
dma_chan *chan)
rcar_dmac_chan_halt(rchan);
spin_unlock_irq(>lock);
 
-   /* Now no new interrupts will occur */
+   /*
+* Now no new interrupts will occur, but one might already be
+* running. Wait for it to finish before freeing resources.
+*/
+   synchronize_irq(rchan->irq);
 
if (rchan->mid_rid >= 0) {
/* The caller is holding dma_list_mutex */
-- 
2.13.0

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

[Niklas Söderlund]

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 
---
 drivers/dma/sh/rcar-dmac.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index db41795fe42ae6ed..c68c3336bdad44df 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -144,6 +144,7 @@ struct rcar_dmac_chan_map {
  * @chan: base DMA channel object
  * @iomem: channel I/O memory base
  * @index: index of this channel in the controller
+ * @irq: channel IRQ
  * @src: slave memory address and size on the source side
  * @dst: slave memory address and size on the destination side
  * @mid_rid: hardware MID/RID for the DMA client using this channel
@@ -161,6 +162,7 @@ struct rcar_dmac_chan {
struct dma_chan chan;
void __iomem *iomem;
unsigned int index;
+   int irq;
 
struct rcar_dmac_chan_slave src;
struct rcar_dmac_chan_slave dst;
@@ -1647,7 +1649,6 @@ static int rcar_dmac_chan_probe(struct rcar_dmac *dmac,
struct dma_chan *chan = >chan;
char pdev_irqname[5];
char *irqname;
-   int irq;
int ret;
 
rchan->index = index;
@@ -1664,8 +1665,8 @@ static int rcar_dmac_chan_probe(struct rcar_dmac *dmac,
 
/* Request the channel interrupt. */
sprintf(pdev_irqname, "ch%u", index);
-   irq = platform_get_irq_byname(pdev, pdev_irqname);
-   if (irq < 0) {
+   rchan->irq = platform_get_irq_byname(pdev, pdev_irqname);
+   if (rchan->irq < 0) {
dev_err(dmac->dev, "no IRQ specified for channel %u\n", index);
return -ENODEV;
}
@@ -1675,11 +1676,13 @@ static int rcar_dmac_chan_probe(struct rcar_dmac *dmac,
if (!irqname)
return -ENOMEM;
 
-   ret = devm_request_threaded_irq(dmac->dev, irq, rcar_dmac_isr_channel,
+   ret = devm_request_threaded_irq(dmac->dev, rchan->irq,
+   rcar_dmac_isr_channel,
rcar_dmac_isr_channel_thread, 0,
irqname, rchan);
if (ret) {
-   dev_err(dmac->dev, "failed to request IRQ %u (%d)\n", irq, ret);
+   dev_err(dmac->dev, "failed to request IRQ %u (%d)\n",
+   rchan->irq, ret);
return ret;
}
 
-- 
2.13.0

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

[Niklas Söderlund]

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 that might still be running after the channel is
   halted prior to freeing its resources. This was patch previously part
   of a patch sent out by Yoshihiro Shimoda and authored by Hiroyuki
   Yokoyama, see [1].

   In that thread it was suggested by Lars-Peter Clausen to instead
   implement the device_synchronize() callback. Unfortunately this is not
   enough to solve the issue. In rcar_dmac_free_chan_resources() the
   channel is halted by a call to rcar_dmac_chan_halt() and then directly
   moves on to freeing resources, here it is still needed to add a wait
   for any ISR to finish before freeing the resources, despite that a
   device_synchronize() have been added.  This is because call chain:

   dma_release_channel()
 dma_chan_put()
   dmaengine_synchronize()
   rcar_dmac_free_chan_resources()
 rcar_dmac_chan_halt()

   Here dmaengine_synchronize() is called prior to rcar_dmac_chan_halt()
   so an extra synchronisation to wait for any running ISR is still
   needed.

By both adding a device_synchronize() which can be used in conjunction
with device_terminate_all() and fiends and by adding an explicit
synchronize_irq() when freeing channel resources I feel the
synchronisation for freeing channel resources are in a much better
shape. It also solves the issue in the original mail thread.

The series is based on v4.12-rc1 and is tested on r8a7795 Salvator-X.

1. https://patchwork.kernel.org/patch/9557691/

* Changes since v1
- Rebased to v4.12-rc1

Niklas Söderlund (3):
  dmaengine: rcar-dmac: store channel IRQ in struct rcar_dmac_chan
  dmaengine: rcar-dmac: implement device_synchronize()
  dmaengine: rcar-dmac: wait for ISR to finish before freeing resources

 drivers/dma/sh/rcar-dmac.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

-- 
2.13.0

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

[Laurent Pinchart]

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 Pinchart 
>  
>  Failures to look up an IOMMU when parsing the DT iommus property need
>  to be handled separately from the .of_xlate() failures to support
>  deferred probing.
>  
>  The lack of a registered IOMMU can be caused by the lack of a driver
>  for the IOMMU, the IOMMU device probe not having been performed yet,
>  having been deferred, or having failed.
>  
>  The first case occurs when the device tree describes the bus master
>  and IOMMU topology correctly but no device driver exists for the IOMMU
>  yet or the device driver has not been compiled in. Return NULL, the
>  caller will configure the device without an IOMMU.
>  
>  The second and third cases are handled by deferring the probe of the
>  bus master device which will eventually get reprobed after the IOMMU.
>  
>  The last case is currently handled by deferring the probe of the bus
>  master device as well. A mechanism to either configure the bus master
>  device without an IOMMU or to fail the bus master device probe
>  depending on whether the IOMMU is optional or mandatory would be a good
>  enhancement.
>  
>  Tested-by: Marek Szyprowski 
>  Signed-off-by: Laurent Pichart
>  
>  Signed-off-by: Sricharan R 
> >>> 
> >>> This patch broke Renesas R-Car Gen3 platforms in renesas-drivers.
> >>> As the IOMMU nodes in DT are not yet enabled, all devices having iommus
> >>> properties in DT now fail to probe.
> >> 
> >> How exactly do they fail to probe? Per d7b0558230e4, if there are no ops
> >> registered then they should merely defer until we reach the point of
> >> giving up and ignoring the IOMMU. Is it just that you have no other
> >> late-probing drivers or post-init module loads to kick the deferred
> >> queue after that point? I did try to find a way to explicitly kick it
> >> from a suitably late initcall, but there didn't seem to be any obvious
> >> public interface - anyone have any suggestions?
> >> 
> >> I think that's more of a general problem with the probe deferral
> >> mechanism itself (I've seen the same thing happen with some of the
> >> CoreSight stuff on Juno due to the number of inter-component
> >> dependencies) rather than any specific fault of this series.
> > 
> > I was thinking of an additional check like below to avoid the
> > situation ?
> > 
> > From 499b6e662f60f23740b8880882b0a16f16434501 Mon Sep 17 00:00:00 2001
> > From: Sricharan R 
> > Date: Wed, 3 May 2017 13:16:59 +0530
> > Subject: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER
> > 
> > While returning EPROBE_DEFER for iommu masters
> > take in to account of iommu nodes that could be
> > marked in DT as 'status=disabled', in which case
> > simply return NULL and let the master's probe
> > continue rather than deferring.
> > 
> > Signed-off-by: Sricharan R 
> > ---
> > 
> >  drivers/iommu/of_iommu.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > index 9f44ee8..e6e9bec 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct device_node
> > *np)
> > 
> > ops = iommu_ops_from_fwnode(fwnode);
> > if ((ops && !ops->of_xlate) ||
> > +   !of_device_is_available(iommu_spec->np) ||
> > (!ops && !of_iommu_driver_present(iommu_spec->np)))
> > return NULL;
> 
> This looks good to me, but won't be enough. The ipmmu-vmsa driver in
> v4.12-rc1 doesn't call iommu_device_register() and thus won't be found by
> iommu_ops_from_fwnode(). Furthermore, it doesn't IOMMU_OF_DECLARE(), and
> thus will always be considered as absent.
> 
> I agree that the ipmmu-vmsa driver needs to be fixed, but it would have been
> nice to check existing IOMMU drivers before merging this patch series...

Please pardon the question, but has this patch series been tested on ARM32 ?

When the device is probed the arch_setup_dma_ops() function is called. It sets 
the device's dma_ops and the mapping (in __arm_iommu_attach_device()). If 
probe is deferred, arch_teardown_dma_ops() is called which in turn calls 
arch_teardown_dma_ops(). This removes the mapping but doesn't touch the 
dma_ops. The next time the device is probed, arch_setup_dma_ops() bails out 
immediately as the dma_ops are already set, leaving us with a device bound to 
IOMMU operations but with no mapping. This oopses later as 

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

[Rob Herring]

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 patchset on which it appears to have no dependencies
> * Added Reviewed by tags 
> ---
>  Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring  

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

[Laurent Pinchart]

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 
> >>> 
> >>> Failures to look up an IOMMU when parsing the DT iommus property need to
> >>> be handled separately from the .of_xlate() failures to support deferred
> >>> probing.
> >>> 
> >>> The lack of a registered IOMMU can be caused by the lack of a driver for
> >>> the IOMMU, the IOMMU device probe not having been performed yet, having
> >>> been deferred, or having failed.
> >>> 
> >>> The first case occurs when the device tree describes the bus master and
> >>> IOMMU topology correctly but no device driver exists for the IOMMU yet
> >>> or the device driver has not been compiled in. Return NULL, the caller
> >>> will configure the device without an IOMMU.
> >>> 
> >>> The second and third cases are handled by deferring the probe of the bus
> >>> master device which will eventually get reprobed after the IOMMU.
> >>> 
> >>> The last case is currently handled by deferring the probe of the bus
> >>> master device as well. A mechanism to either configure the bus master
> >>> device without an IOMMU or to fail the bus master device probe depending
> >>> on whether the IOMMU is optional or mandatory would be a good
> >>> enhancement.
> >>> 
> >>> Tested-by: Marek Szyprowski 
> >>> Signed-off-by: Laurent Pichart
> >>> 
> >>> Signed-off-by: Sricharan R 
> >> 
> >> This patch broke Renesas R-Car Gen3 platforms in renesas-drivers.
> >> As the IOMMU nodes in DT are not yet enabled, all devices having iommus
> >> properties in DT now fail to probe.
> > 
> > How exactly do they fail to probe? Per d7b0558230e4, if there are no ops
> > registered then they should merely defer until we reach the point of
> > giving up and ignoring the IOMMU. Is it just that you have no other
> > late-probing drivers or post-init module loads to kick the deferred
> > queue after that point? I did try to find a way to explicitly kick it
> > from a suitably late initcall, but there didn't seem to be any obvious
> > public interface - anyone have any suggestions?
> > 
> > I think that's more of a general problem with the probe deferral
> > mechanism itself (I've seen the same thing happen with some of the
> > CoreSight stuff on Juno due to the number of inter-component
> > dependencies) rather than any specific fault of this series.
> 
> I was thinking of an additional check like below to avoid the
> situation ?
> 
> From 499b6e662f60f23740b8880882b0a16f16434501 Mon Sep 17 00:00:00 2001
> From: Sricharan R 
> Date: Wed, 3 May 2017 13:16:59 +0530
> Subject: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER
> 
> While returning EPROBE_DEFER for iommu masters
> take in to account of iommu nodes that could be
> marked in DT as 'status=disabled', in which case
> simply return NULL and let the master's probe
> continue rather than deferring.
> 
> Signed-off-by: Sricharan R 
> ---
>  drivers/iommu/of_iommu.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 9f44ee8..e6e9bec 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct device_node
> *np)
> 
> ops = iommu_ops_from_fwnode(fwnode);
> if ((ops && !ops->of_xlate) ||
> +   !of_device_is_available(iommu_spec->np) ||
> (!ops && !of_iommu_driver_present(iommu_spec->np)))
> return NULL;

This looks good to me, but won't be enough. The ipmmu-vmsa driver in v4.12-rc1 
doesn't call iommu_device_register() and thus won't be found by 
iommu_ops_from_fwnode(). Furthermore, it doesn't IOMMU_OF_DECLARE(), and thus 
will always be considered as absent.

I agree that the ipmmu-vmsa driver needs to be fixed, but it would have been 
nice to check existing IOMMU drivers before merging this patch series...

> >> This can be fixed by either:
> >>   - Disabling CONFIG_IPMMU_VMSA, or
> >>   - Reverting commit 7b07cbefb68d486f (but keeping "int ret = 0;").
> >> 
> >> Note that this was a bit hard to investigate, as R-Car Gen3 support
> >> wasn't upstreamed yet, so bisection pointed to a merge commit.

-- 
Regards,

Laurent Pinchart

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

[Geert Uytterhoeven]

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.

[...]

>> This has been tested on Salvator-X (H3 ES1.0 and ES2.0), and H3ULCB with
>> H3 ES1.1.
>>
>> This has not been tested on H3ULCB with H3 ES2.0 due to lack of
>> hardware, so perhaps you want to defer patch 3. However, adding ES2.0
>> support to both boards at the same time has its advantages (e.g. to answer
>> the question "in which kernel version do I need a DTB with 'es1' in its
>> name?").
>>
>> Thanks for applying (at least) the first two patches!
>
> Thanks, patches 1 and 2 queued up.

Thank you!

> I'd rather not take 3 until it can be tested somehow.

No problem.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

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

[Simon Horman]

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 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > Hi Simon,
> > 
> > Sorry for having messed that up in the original patch :-/ Feel free to 
> > squash
> > this fix in "arm64: dts: renesas: r8a7795: Add HDMI encoder support" if you
> > want to rebase, or just apply it on top.
> 
> No problem, I've also made a few DT errors of late :)
> 
> I have squashed this change as you suggest.
> I plan to push it a bit later today and if not tomorrow.

For the record, updated patch is as follows:


From: Ulrich Hecht 

arm64: dts: renesas: r8a7795: Add HDMI encoder support

Add DT nodes for the two HDMI encoders in disabled state.

Based on work by Koji Matsuoka.

Signed-off-by: Ulrich Hecht 
Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 

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 | 52 
 1 file changed, 52 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 7d87dff70ac8..ee0129634cdf 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1758,6 +1758,56 @@
renesas,fcp = <>;
};
 
+   hdmi0: hdmi0@fead {
+   compatible = "renesas,r8a7795-hdmi", 
"renesas,rcar-gen3-hdmi";
+   reg = <0 0xfead 0 0x1>;
+   interrupts = ;
+   clocks = < CPG_MOD 729>, < CPG_CORE 
R8A7795_CLK_HDMI>;
+   clock-names = "iahb", "isfr";
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 729>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   dw_hdmi0_in: endpoint {
+   remote-endpoint = 
<_out_hdmi0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   };
+   };
+   };
+
+   hdmi1: hdmi1@feae {
+   compatible = "renesas,r8a7795-hdmi", 
"renesas,rcar-gen3-hdmi";
+   reg = <0 0xfeae 0 0x1>;
+   interrupts = ;
+   clocks = < CPG_MOD 728>, < CPG_CORE 
R8A7795_CLK_HDMI>;
+   clock-names = "iahb", "isfr";
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 728>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   dw_hdmi1_in: endpoint {
+   remote-endpoint = 
<_out_hdmi1>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   };
+   };
+   };
+
du: display@feb0 {
compatible = "renesas,du-r8a7795";
reg = <0 0xfeb0 0 0x8>,
@@ -1789,11 +1839,13 @@
port@1 {
reg = <1>;
du_out_hdmi0: endpoint {
+   remote-endpoint = 
<_hdmi0_in>;
};
};
port@2 {
reg = <2>;
du_out_hdmi1: endpoint {
+   remote-endpoint = 

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

[Simon Horman]

On Mon, May 15, 2017 at 02:44:10PM +0200, Geert Uytterhoeven wrote:
>   Hi all,
> 
> This patch series adds support for Renesas Salvator-X and H3ULCB
> development boards equipped with revision ES2.0 of the R-Car H3 SoC.
> 
> Our goal is to have a single kernel image supporting both ES1. and ES2.0
> revisions of the R-Car H3 SoC, and let r8a7795-salvator-x.dtb and
> r8a7795-h3ulcb.dtb represent the latest production hardware.
> As R-Car H3 ES1.x SoCs are pre-production revisions, the DTB files for
> these revisions are renamed to r8a7795-es1-salvator-x.dtb resp.
> r8a7795-es1-h3ulcb.dtb.
> 
> While this will cause a slight inconvenience for developers using
> pre-production hardware, it will make it easier to deploy production
> hardware, and phase out support for pre-production hardware later.
> Note that unless you need access to new features not yet described in
> DT, you can keep on using the existing DTBs on pre-production hardware.
> 
>   - Patch 1 adds support for the R-Car H3 ES2.0 Soc, by providing 2
> .dtsi files: r8a7795.dtsi (ES2.0), and r8a7795-es1.dtsi (ES1.x).
>   - Patch 2 adds support for Salvator-X with R-Car H3 ES2.0 by providing
> 2 .dts files: r8a7795-salvator-x.dts (ES2.0), and
> r8a7795-es1-salvator-x.dts(ES1.x),
>   - Patch 3 adds support for ator-X with R-Car H3 ES2.0 by providing 2
> .dts files: r8a7795-salvator-x.dts (ES2.0), and
> r8a7795-es1-salvator-x.dts(ES1.x).
> 
> While patch 1 has no user-visible impact, patches 2 and 3 do.
> 
> Changes compared to v3:
>   - Remove "/remove/overrides", as r8a7795-es1.dtsi does additions only,
>   - Move node and property deletion guidelines above the scissors,
>   - Rebase on top of r8a7795 HDMI support (but most of that is "hidden"
> thanks to git's smart copy from/to patch format),
> 
> Changes compared to v2:
>   - Rebase on top of common Salvator-X board support extraction,
>   - Remove 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 against renesas-devel-20170515-v4.12-rc1,
>   - Thanks to git's smart copy from/to patch format, it should be
> applicable with and without "[PATCH 0/2] arm64: dts: salvator-x: Move
> HDMI0 to common Salvator-X board support".
> 
> This series is available in the topic/r8a7795es2-dt-v4 branch of my
> renesas-drivers git repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
> An integration branch (incl. all dependencies) for testing is provided
> as topic/r8a7795es2-integration.  I plan to update this branch when any
> of the dependencies are updated.
> 
> This has been tested on Salvator-X (H3 ES1.0 and ES2.0), and H3ULCB with
> H3 ES1.1.
> 
> This has not been tested on H3ULCB with H3 ES2.0 due to lack of
> hardware, so perhaps you want to defer patch 3. However, adding ES2.0
> support to both boards at the same time has its advantages (e.g. to answer
> the question "in which kernel version do I need a DTB with 'es1' in its
> name?").
> 
> Thanks for applying (at least) the first two patches!

Thanks, patches 1 and 2 queued up.
I'd rather not take 3 until it can be tested somehow.

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

[Simon Horman]

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 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Hi Simon,
> 
> Sorry for having messed that up in the original patch :-/ Feel free to squash
> this fix in "arm64: dts: renesas: r8a7795: Add HDMI encoder support" if you
> want to rebase, or just apply it on top.

No problem, I've also made a few DT errors of late :)

I have squashed this change as you suggest.
I plan to push it a bit later today and if not tomorrow.

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

[Laurent Pinchart]

Hello,

[ANN] stands for announcement: I have managed to capture images from the 
RDACM20 camera on R-Car H3 using the Gen3 VIN driver developed by Niklas.

The RDACM20 camera is a GMSL (Gigabit Multimedia Serial Link) camera module 
based on an Omnivision 10635 camera sensor and a Maxim MAX9271 GMSL 
serializer. The GMSL link carries power, control (I2C) and video data over a 
single coax cable.

The R-Car H3 Salvator-X is plugged to an extension board based on a Maxim 
MAX9286 quad-channel GMSL deserializer. Up to four cameras can be connected to 
the deserializer, which outputs the four video streams on separate virtual 
channels over one CSI-2 connections.

Based on this hardware setup, I have ported the BSP core developed against the 
old soc-camera VIN driver to the mainline kernel, on top of Niklas R-Car Gen3 
VIN support series (available from his git tree under the tag rcar-vin-elinux-
v7). After more cleanups than my sleep schedule was comfortable with, but not 
enough to let me post the patches to public mailing lists without shame, I 
ended up with the following five patches.

- v4l: Add MAX9286 driver
- v4l: Add RDACM20 driver
- arm64: dts: renesas: salvator-x: Add MAX9286 expansion board
- arm64: dts: renesas: salvator-x-max9286: Add RDACM20 cameras
- arm64: dts: renesas: salvator-x: Connect GMSL cameras to VIN

Those patches are all hacks to some extent.

Patches 1/5 and 2/5 add drivers for the MAX9286 GMSL deserializer and for the 
RDACM20 camera respectively. They are currently interdependent as they both 
touch registers of the other one (don't blame me, the original version was 
worse). This needs to be fixed.

Patches 3/5 to 5/5 add the corresponding devices to DT. The DT bindings 
haven't been documented yet and need to be reworked anyway. How to describe 
the I2C connections between the devices is under discussion. Additionally, due 
to restrictions of the VIN driver that the code is based on, the RDACM20 
cameras' endpoints are connected directly to the CSI-2 receivers' endpoints. 
This will be fixed when rebasing the code on top of a more 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 jumper from the 
MAX9286 expansion board to disable the second MAX9286, and to connect RDACM20 
cameras to the first four GMSL ports (J1 to J4).

On the software side, you need recent versions of the media-ctl and yavta 
tools on your system. The kernel must be compiled with the following options.

CONFIG_VIDEO_MAX9286=y
CONFIG_VIDEO_RDACM20=y
CONFIG_VIDEO_RCAR_CSI2=y
CONFIG_VIDEO_RCAR_VIN=y
# CONFIG_VIDEO_RENESAS_FDP1 is not set
# CONFIG_VIDEO_RENESAS_JPU is not set
# CONFIG_VIDEO_RENESAS_VSP1 is not set

Disabling FDP1, JPU and VSP1 ensure that the media controller and video device 
nodes will have known names. You can enable those drivers if you update the 
device names accordingly in the commands below.

After booting the system, simply run

$ media-ctl -V "'rcar_csi2 feaa.csi2':0 [fmt:UYVY8_2X8/1280x800 
field:none]"
$ yavta -f YUYV -s 1280x800 -c10 --skip 7 -F /dev/video0

This will capture three images from the first camera to files 
frame-07.bin, frame-08.bin and frame-09.bin. You can convert them 
to pnm with the raw2rgbpnm tool (which doesn't have to be run on the target 
system, you can use it in your development environment).

$ raw2rgbpnm -f YUYV -s 1280x800 frame-07.bin frame-07.pnm

All these information are available from the elinux.org wiki at 
http://elinux.org/R-Car/Tests:rcar-vin.

Notwithstanding the ability to capture images, the to-do list is still long. A 
first non-exhaustive list of items will contain

- Defining the software architecture to handle I2C devices (including address 
translation)
- Defining the corresponding DT bindings for the I2C devices
- Moving the MAX9271 and OV10635 code out of the MAX9286 driver
- Moving the MAX9286 code out of the RDACM20 driver
- Connecting the DT video endpoints to describe the hardware correctly 
(RDACM20 -> MAX9286 -> CSI-2 receivers)
- Splitting, if at all possible, the RDACM20 driver into a MAX9271 driver and 
an OV10365 driver
- Implementing support for multi-channel capture

-- 
Regards,

Laurent Pinchart

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

[jmondi]

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 module
> > https://www.digikey.com/product-detail/en/renesas-electronics-
> > america/YGRPEACHAUDIOCAMERASHIELD/YGRPEACHAUDIOCAMERASHIELD-ND/5800301
> > www.elecfreaks.com/estore/ov7670-camera-module.html
>
> Oh ya, I forgot about that thing.
>
>
> > This implies running mainline on Peach or backporting CEU driver to your
> > BSP if we're not able to do so. A desirable collateral benefit in both
> > cases, I guess...
>
> You should probably be able to run mainline on it.
>

I'm now trying to boot v4.11 (non-XIP) on GR-Peach.
I've been able to write u-boot from your BSP directly on the SPI
flash, and I'm now trying to use it to boot a kernel image from
on-chip SRAM.

I've spent quite some time on it without any appreciable result, so I
am now considering trying to make a XIP kernel out of mainline and
boot from QSPI.
I've seen you have applied  lot of patches for XIP support on top of
your v3.14 BSP, can you summarize what I need to apply on v4.11 to
have the same?

Also FYI, I am now trying to boot a uImage with device tree appended,
loaded on the on-chip RAM with J-Link to address 0x2050, and
compiled with 20008000 [1] as load address (32Kb below on-chip RAM
address start)
This way I -should- be able to load my 3MB kernel image in RAM and
execute it from there.
I always get back a mute console unfortunately, so I'm starting to
wonder if I shouldn't go for a XIP kernel as well...


=> bootm 0x2050
## Booting kernel from Legacy Image at 2050 ...
   Image Name:   Linux
   Created:  2017-05-15  14:29:05 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3009736 Bytes = 2.9 MiB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...



Thanks
  j

[1] I tried to use 0x20208000 as well, to avoid writing to memory
pages for data retention.

[2] I am using r7s72100-grpeach.dts from your BSP, with the following applied:

memory {
device_type = "memory";
-   reg = <0x0800 0x0200>;  /* 32MB @ 0x0x0800 */
+   reg = <0x2000 0x00A0>;  /* 10Mb @ 0x0x2000 */
};

[3] I have used uImage with appended DTB and uImage with separate dtb as well. 
No luck.

PS I have removed renesas list not to spam to everyone. If relevant, I will 
re-send and add them back.

> Go here for u-boot build instructions: http://elinux.org/RZ-A/Boards/GR-PEACH
>
> Remember, that board only has 8MB of SPI flash, so you should download uImage 
> and DTB to RAM using Jlink, the use the SPI flash for a rootfs. I so have USB 
> host working for mainline, but it requires an out-of-tree patch from me (I'm 
> not sure on what upstream path I should take for RZ/A1 USB yet).
>
>
>
> Of course if you change your mind, this board:
>
> https://www.digikey.com/product-detail/en/renesas-electronics-america/YLCDRZA1H/YLCDRZA1H-ND/6173788
> has a camera, 1280x800 LCD, 64MB of SDRAM and a Segger JLINK built into the 
> board. But...no serial port. You have to plug in a USB-to-UART PMOD adapter 
> (something like this 
> http://store.digilentinc.com/pmod-usbuart-usb-to-uart-interface/).
> Once I get everything working, I'll be pushing to our github repos and 
> posting instructions on eLinux.org.
> I might test your new driver using this board (will require an out-of-tree 
> fbdev driver)
>
> I'm going to start phasing out the 3.14 BSP for a 4.9 BSP here in a couple 
> months, so I'll probably backport this new driver to 4.9, but that's about it.
>
>
> Chris
>

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

[Will Deacon]

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 
> >>>
> >>> Failures to look up an IOMMU when parsing the DT iommus property need to
> >>> be handled separately from the .of_xlate() failures to support deferred
> >>> probing.
> >>>
> >>> The lack of a registered IOMMU can be caused by the lack of a driver for
> >>> the IOMMU, the IOMMU device probe not having been performed yet, having
> >>> been deferred, or having failed.
> >>>
> >>> The first case occurs when the device tree describes the bus master and
> >>> IOMMU topology correctly but no device driver exists for the IOMMU yet
> >>> or the device driver has not been compiled in. Return NULL, the caller
> >>> will configure the device without an IOMMU.
> >>>
> >>> The second and third cases are handled by deferring the probe of the bus
> >>> master device which will eventually get reprobed after the IOMMU.
> >>>
> >>> The last case is currently handled by deferring the probe of the bus
> >>> master device as well. A mechanism to either configure the bus master
> >>> device without an IOMMU or to fail the bus master device probe depending
> >>> on whether the IOMMU is optional or mandatory would be a good
> >>> enhancement.
> >>>
> >>> Tested-by: Marek Szyprowski 
> >>> Signed-off-by: Laurent Pichart 
> >>> Signed-off-by: Sricharan R 
> >>
> >> This patch broke Renesas R-Car Gen3 platforms in renesas-drivers.
> >> As the IOMMU nodes in DT are not yet enabled, all devices having iommus
> >> properties in DT now fail to probe.
> > 
> > How exactly do they fail to probe? Per d7b0558230e4, if there are no ops
> > registered then they should merely defer until we reach the point of
> > giving up and ignoring the IOMMU. Is it just that you have no other
> > late-probing drivers or post-init module loads to kick the deferred
> > queue after that point? I did try to find a way to explicitly kick it
> > from a suitably late initcall, but there didn't seem to be any obvious
> > public interface - anyone have any suggestions?
> > 
> > I think that's more of a general problem with the probe deferral
> > mechanism itself (I've seen the same thing happen with some of the
> > CoreSight stuff on Juno due to the number of inter-component
> > dependencies) rather than any specific fault of this series.
> > 
> 
> I was thinking of an additional check like below to avoid the
> situation ?
> 
> From 499b6e662f60f23740b8880882b0a16f16434501 Mon Sep 17 00:00:00 2001
> From: Sricharan R 
> Date: Wed, 3 May 2017 13:16:59 +0530
> Subject: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER
> 
> While returning EPROBE_DEFER for iommu masters
> take in to account of iommu nodes that could be
> marked in DT as 'status=disabled', in which case
> simply return NULL and let the master's probe
> continue rather than deferring.
> 
> Signed-off-by: Sricharan R 
> ---
>  drivers/iommu/of_iommu.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 9f44ee8..e6e9bec 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct device_node 
> *np)
> 
> ops = iommu_ops_from_fwnode(fwnode);
> if ((ops && !ops->of_xlate) ||
> +   !of_device_is_available(iommu_spec->np) ||
> (!ops && !of_iommu_driver_present(iommu_spec->np)))
> return NULL;

Without this patch, v4.12-rc1 hangs on my Juno waiting to mount the root
filesystem. The problem is that the USB controller is behind an SMMU which
is marked as 'status = "disabled"' in the devicetree. Whilst there was a
separate thread with Ard about exactly what this means in terms of the DMA
ops used by upstream devices, your patch above fixes the regression and
I think should go in regardless. The DMA ops issue will likely require
an additional DT binding anyway, to advertise the behaviour of the
IOMMU when it is disabled.

Tested-by: Will Deacon 
Acked-by: Will Deacon 

Could you resend it as a proper patch, please?

Will

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

[Geert Uytterhoeven]

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 SoC.
>> Hence move them from the R-Car H3 specific board file to the common
>> Salvator-X board file.
>>
>> The second HDMI device and connector nodes are left as-is, as R-Car M3-W
>> has only one HDMI output.
>>
>> Signed-off-by: Geert Uytterhoeven 
>
> I wonder whether this is really worth it, given that the number of HDMI ports
> is different between the two boards. I actually had similar patches in my tree
> and then decided to drop them, as I found that splitting the H3 Salvator-X
> HDMI ports salvator-x.dtsi and r8a7795-salvator-x.dts was getting pretty
> confusing.

I moved them because ES2.0 support required adding one other copy.
When M3-W gets DU/HDMI support, we would need a third copy.

I suppose H3ULCB and M3ULCB will receive DU/HDMI support, too.
H3ULCB is available with H3 ES1.1 and ES2.0, so that means 3 more
copies (instead of 1 in ulcb.dtsi).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

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

[Geert Uytterhoeven]

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" properties from the DU node until the driver
can handle this.

Move support for the ES1.x revision of the R-Car H3 SoC into a
separate file.  To avoid duplication, r8a7795-es1.dtsi includes
r8a7795.dtsi, and adds device nodes and properties where needed.
Note that while currently r8a7795-es1.dtsi only adds device nodes,
removal of devices nodes and properties can be implemented using the
/delete-node/ and /delete-property/ keywords, as shown below:

 {
/delete-node/ @;
};

& {
/delete-property/ ;
};

Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi
to r8a7795-es1.dtsi to preserve compatibility.

Signed-off-by: Geert Uytterhoeven 
---
v4:
  - Remove "/remove/overrides", as r8a7795-es1.dtsi does additions only,
  - Move node and property deletion guidelines above the scissors,
  - Rebase on top of r8a7795 HDMI support,

v3:
  - Rebase on top of common Salvator-X board support extraction,
  - Remove the "compatible" property from the DU node in r8a7795.dtsi,
in addition to the "vsps" property,

v2:
  - Use a separate file for ES1.x instead of for ES2.0, so r8a7795.dtsi
always corresponds to the latest SoC revision,
  - Add a dash between SoC part number and revision, for compatibility
with the BSP,
  - Enhance the hardware description from basic support to everything
already supported on ES1.x (except for DU due VSP),
  - Let r8a7795-es1.dtsi include r8a7795.dtsi.
---
 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi   | 84 ++
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts |  4 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  4 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 71 +-
 4 files changed, 89 insertions(+), 74 deletions(-)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
new file mode 100644
index ..a0ba7bd21ea3aa18
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
@@ -0,0 +1,84 @@
+/*
+ * Device Tree Source for the r8a7795 ES1.x SoC
+ *
+ * Copyright (C) 2015 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include "r8a7795.dtsi"
+
+ {
+   xhci1: usb@ee040 {
+   compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci";
+   reg = <0 0xee04 0 0xc00>;
+   interrupts = ;
+   clocks = < CPG_MOD 327>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 327>;
+   status = "disabled";
+   };
+
+   fcpf2: fcp@fe952000 {
+   compatible = "renesas,fcpf";
+   reg = <0 0xfe952000 0 0x200>;
+   clocks = < CPG_MOD 613>;
+   power-domains = < R8A7795_PD_A3VP>;
+   resets = < 613>;
+   };
+
+   vspi2: vsp@fe9c {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfe9c 0 0x8000>;
+   interrupts = ;
+   clocks = < CPG_MOD 629>;
+   power-domains = < R8A7795_PD_A3VP>;
+   resets = < 629>;
+
+   renesas,fcp = <>;
+   };
+
+   fcpvi2: fcp@fe9cf000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfe9cf000 0 0x200>;
+   clocks = < CPG_MOD 609>;
+   power-domains = < R8A7795_PD_A3VP>;
+   resets = < 609>;
+   };
+
+   vspd3: vsp@fea38000 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfea38000 0 0x4000>;
+   interrupts = ;
+   clocks = < CPG_MOD 620>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 620>;
+
+   renesas,fcp = <>;
+   };
+
+   fcpvd3: fcp@fea3f000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfea3f000 0 0x200>;
+   clocks = < CPG_MOD 600>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 600>;
+   };
+
+   fdp1@fe948000 {
+   compatible = "renesas,fdp1";
+   reg = <0 0xfe948000 0 0x2400>;
+   interrupts = ;
+   clocks = < CPG_MOD 117>;
+   power-domains = < R8A7795_PD_A3VP>;
+   resets = < 117>;
+   renesas,fcp = <>;
+   };
+};
+
+ {
+   compatible = "renesas,du-r8a7795";
+   vsps 

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

[Geert Uytterhoeven]

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.
---
 arch/arm64/boot/dts/renesas/Makefile  | 2 +-
 .../boot/dts/renesas/{r8a7795-h3ulcb.dts => r8a7795-es1-h3ulcb.dts}   | 0
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts| 4 ++--
 3 files changed, 3 insertions(+), 3 deletions(-)
 copy arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb.dts => 
r8a7795-es1-h3ulcb.dts} (100%)

diff --git a/arch/arm64/boot/dts/renesas/Makefile 
b/arch/arm64/boot/dts/renesas/Makefile
index b6c723d8f6875f2d..d5451015950e3dfc 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,5 +1,5 @@
 dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
-dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb
+dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb r8a7795-es1-h3ulcb.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
similarity index 100%
copy from arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
copy to arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 95fe207cb6a3fd2f..0426f41765f0bc68 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -12,11 +12,11 @@
 #define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
 
 /dts-v1/;
-#include "r8a7795-es1.dtsi"
+#include "r8a7795.dtsi"
 #include "ulcb.dtsi"
 
 / {
-   model = "Renesas H3ULCB board based on r8a7795 ES1.x";
+   model = "Renesas H3ULCB board based on r8a7795 ES2.0+";
compatible = "renesas,h3ulcb", "renesas,r8a7795";
 
memory@4800 {
-- 
2.7.4

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

[Geert Uytterhoeven]

Hi all,

This patch series adds support for Renesas Salvator-X and H3ULCB
development boards equipped with revision ES2.0 of the R-Car H3 SoC.

Our goal is to have a single kernel image supporting both ES1. and ES2.0
revisions of the R-Car H3 SoC, and let r8a7795-salvator-x.dtb and
r8a7795-h3ulcb.dtb represent the latest production hardware.
As R-Car H3 ES1.x SoCs are pre-production revisions, the DTB files for
these revisions are renamed to r8a7795-es1-salvator-x.dtb resp.
r8a7795-es1-h3ulcb.dtb.

While this will cause a slight inconvenience for developers using
pre-production hardware, it will make it easier to deploy production
hardware, and phase out support for pre-production hardware later.
Note that unless you need access to new features not yet described in
DT, you can keep on using the existing DTBs on pre-production hardware.

  - Patch 1 adds support for the R-Car H3 ES2.0 Soc, by providing 2
.dtsi files: r8a7795.dtsi (ES2.0), and r8a7795-es1.dtsi (ES1.x).
  - Patch 2 adds support for Salvator-X with R-Car H3 ES2.0 by providing
2 .dts files: r8a7795-salvator-x.dts (ES2.0), and
r8a7795-es1-salvator-x.dts(ES1.x),
  - Patch 3 adds support for ator-X with R-Car H3 ES2.0 by providing 2
.dts files: r8a7795-salvator-x.dts (ES2.0), and
r8a7795-es1-salvator-x.dts(ES1.x).

While patch 1 has no user-visible impact, patches 2 and 3 do.

Changes compared to v3:
  - Remove "/remove/overrides", as r8a7795-es1.dtsi does additions only,
  - Move node and property deletion guidelines above the scissors,
  - Rebase on top of r8a7795 HDMI support (but most of that is "hidden"
thanks to git's smart copy from/to patch format),

Changes compared to v2:
  - Rebase on top of common Salvator-X board support extraction,
  - Remove 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 against renesas-devel-20170515-v4.12-rc1,
  - Thanks to git's smart copy from/to patch format, it should be
applicable with and without "[PATCH 0/2] arm64: dts: salvator-x: Move
HDMI0 to common Salvator-X board support".

This series is available in the topic/r8a7795es2-dt-v4 branch of my
renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
An integration branch (incl. all dependencies) for testing is provided
as topic/r8a7795es2-integration.  I plan to update this branch when any
of the dependencies are updated.

This has been tested on Salvator-X (H3 ES1.0 and ES2.0), and H3ULCB with
H3 ES1.1.

This has not been tested on H3ULCB with H3 ES2.0 due to lack of
hardware, so perhaps you want to defer patch 3. However, adding ES2.0
support to both boards at the same time has its advantages (e.g. to answer
the question "in which kernel version do I need a DTB with 'es1' in its
name?").

Thanks for applying (at least) the first two patches!

Geert Uytterhoeven (3):
  arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
  arm64: dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0
  arm64: dts: r8a7795: h3ulcb: Add support for R-Car H3 ES2.0

 arch/arm64/boot/dts/renesas/Makefile   |  1 +
 .../{r8a7795-h3ulcb.dts => r8a7795-es1-h3ulcb.dts} |  4 +-
 ...5-salvator-x.dts => r8a7795-es1-salvator-x.dts} |  4 +-
 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi   | 84 ++
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts |  2 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  2 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 71 +-
 7 files changed, 92 insertions(+), 76 deletions(-)
 copy arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb.dts => 
r8a7795-es1-h3ulcb.dts} (91%)
 copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => 
r8a7795-es1-salvator-x.dts} (94%)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

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

[Geert Uytterhoeven]

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 r8a7795 HDMI support,

v3:
  - Rebase on top of common Salvator-X board support extraction,

v2:
  - Use a separate file for ES1.x instead of for ES2.0, so
r8a7795-salvator-x.dts always corresponds to the board with the
latest SoC revision,
  - Add a dash between SoC part number and revision, for compatibility
with the BSP,
  - Enhance the hardware description from basic support to everything
already supported on ES1.x.
---
 arch/arm64/boot/dts/renesas/Makefile  | 1 +
 .../renesas/{r8a7795-salvator-x.dts => r8a7795-es1-salvator-x.dts}| 0
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts| 4 ++--
 3 files changed, 3 insertions(+), 2 deletions(-)
 copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => 
r8a7795-es1-salvator-x.dts} (100%)

diff --git a/arch/arm64/boot/dts/renesas/Makefile 
b/arch/arm64/boot/dts/renesas/Makefile
index 1618e0a3c81d48bd..b6c723d8f6875f2d 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
+dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-salvator-x.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
similarity index 100%
copy from arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
copy to arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 1bb1dd61ba1ca442..8bcf4c0d6c4a65fa 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -11,11 +11,11 @@
 #define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
 
 /dts-v1/;
-#include "r8a7795-es1.dtsi"
+#include "r8a7795.dtsi"
 #include "salvator-x.dtsi"
 
 / {
-   model = "Renesas Salvator-X board based on r8a7795 ES1.x";
+   model = "Renesas Salvator-X board based on r8a7795 ES2.0+";
compatible = "renesas,salvator-x", "renesas,r8a7795";
 
memory@4800 {
-- 
2.7.4

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

[Kieran Bingham]

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 version (I have that
in as a temporary workaround until the links are correctly ignored by rvin /
handled by core correctly)

So again, here is the posted 'immutable' version, which represents this patch
version:

http://janet.linuxembedded.co.uk/adv748x-immutable.png

But the end goal of this patchset will be the following configuration:

http://janet.linuxembedded.co.uk/adv748x-non-immutable.png


> Please see my comments below.
> 
> On Thu, May 11, 2017 at 06:21:20PM +0100, Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> Provide basic support for the ADV7481 and ADV7482.
>>
>> The driver is modelled with 2 subdevices to allow simultaneous streaming
>> from the AFE (Analog front end) and HDMI inputs.
>>
>> Presently the HDMI is hardcoded to link to the TXA CSI bus, whilst the
>> AFE is linked to the TXB CSI bus.
>>
>> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
>> and an earlier rework by Niklas Söderlund.
>>
>> Signed-off-by: Kieran Bingham 
>>
>> ---
>>
>> v2:
>>  - Implement DT parsing
>>  - adv748x: Add CSI2 entity
>>  - adv748x: Rework pad allocations and fmts
>>  - Give AFE 8 input pads and move pad defines
>>  - Use the enums to ensure pads are referenced correctly.
>>  - adv748x: Rename AFE/HDMI entities
>>Now they are 'just afe' and 'just hdmi'
>>  - Reorder the entity enum and structures
>>  - Added pad-format for the CSI2 entities
>>  - CSI2 s_stream pass through
>>  - CSI2 control pass through (with link following)
>> ---
>>  Documentation/devicetree/bindings/media/i2c/adv748x.txt |  63 +-
>>  MAINTAINERS |   6 +-
>>  drivers/media/i2c/Kconfig   |  10 +-
>>  drivers/media/i2c/Makefile  |   1 +-
>>  drivers/media/i2c/adv748x/Makefile  |   7 +-
>>  drivers/media/i2c/adv748x/adv748x-afe.c | 599 -
>>  drivers/media/i2c/adv748x/adv748x-core.c| 698 +-
>>  drivers/media/i2c/adv748x/adv748x-csi2.c| 373 +-
>>  drivers/media/i2c/adv748x/adv748x-hdmi.c| 671 +-
>>  drivers/media/i2c/adv748x/adv748x.h | 201 +++-
>>  10 files changed, 2629 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt
>>  create mode 100644 drivers/media/i2c/adv748x/Makefile
>>  create mode 100644 drivers/media/i2c/adv748x/adv748x-afe.c
>>  create mode 100644 drivers/media/i2c/adv748x/adv748x-core.c
>>  create mode 100644 drivers/media/i2c/adv748x/adv748x-csi2.c
>>  create mode 100644 drivers/media/i2c/adv748x/adv748x-hdmi.c
>>  create mode 100644 drivers/media/i2c/adv748x/adv748x.h
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.txt 
>> b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
>> new file mode 100644
>> index ..04d9ebc674a6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
>> @@ -0,0 +1,63 @@
>> +* Analog Devices ADV748X video decoder with HDMI receiver
>> +
>> +The ADV7481, and ADV7482 are multi format video decoders with an integrated
>> +HDMI receiver. It can output CSI-2 on two independent outputs TXA and TXB 
>> from
>> +three input sources HDMI, analog and TTL.
>> +
>> +Required Properties:
>> +
>> +  - compatible: Must contain one of the following
>> +- "adi,adv7481" for the ADV7481
>> +- "adi,adv7482" for the ADV7482
>> +
>> +  - reg: I2C slave address
>> +
>> +The device node must contain one 'port' child node per device input and 
>> output
>> +port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
>> +are numbered as follows.
>> +
>> +  Name  TypePort
>> +
>> +  HDMI  sink0
>> +  AIN1  sink1
>> +  AIN2  sink2
>> +  AIN3  sink3
>> +  AIN4  sink4
>> +  AIN5  sink5
>> +  AIN6  sink6
>> +  AIN7  sink7
>> +  AIN8  sink8
>> +  TTL   sink9
>> +  TXA   source  10
>> +  TXB   source  11
>> +
>> +The digital output port node must contain at least one source endpoint.
>> +
>> +Example:
>> +
>> +video_receiver@70 {
>> +compatible = "adi,adv7482";
>> 

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

[Laurent Pinchart]

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 common
> Salvator-X board file.
> 
> The second HDMI device and connector nodes are left as-is, as R-Car M3-W
> has only one HDMI output.
> 
> Signed-off-by: Geert Uytterhoeven 

I wonder whether this is really worth it, given that the number of HDMI ports 
is different between the two boards. I actually had similar patches in my tree 
and then decided to drop them, as I found that splitting the H3 Salvator-X 
HDMI ports salvator-x.dtsi and r8a7795-salvator-x.dts was getting pretty 
confusing.

> ---
>  arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 17 -
>  arch/arm64/boot/dts/renesas/salvator-x.dtsi| 17 +
>  2 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index
> fcd9ca73f2c76768..22e5324e7ada0eea 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> @@ -58,23 +58,6 @@
>   status = "okay";
>  };
> 
> - {
> - status = "okay";
> -
> - ports {
> - port@1 {
> - reg = <1>;
> - rcar_dw_hdmi0_out: endpoint {
> - remote-endpoint = <_con>;
> - };
> - };
> - };
> -};
> -
> -_con {
> - remote-endpoint = <_dw_hdmi0_out>;
> -};
> -
>   {
>   status = "okay";
> 
> diff --git a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> b/arch/arm64/boot/dts/renesas/salvator-x.dtsi index
> 5f0d4bdcd3b44aae..1f6b9fbb13af1ebf 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> @@ -294,6 +294,23 @@
>   clock-frequency = <32768>;
>  };
> 
> + {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + reg = <1>;
> + rcar_dw_hdmi0_out: endpoint {
> + remote-endpoint = <_con>;
> + };
> + };
> + };
> +};
> +
> +_con {
> + remote-endpoint = <_dw_hdmi0_out>;
> +};
> +
>   {
>   status = "okay";
>  };

-- 
Regards,

Laurent Pinchart

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

[Geert Uytterhoeven]

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.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index b418a66f4ceccb90..892d956d1b1b565c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1428,6 +1428,15 @@
/* placeholder */
};
 
+   hdmi0: hdmi0@fead {
+   /* placeholder */
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+
du: display@feb0 {
/* placeholder */
 
-- 
2.7.4

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

[Geert Uytterhoeven]

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 placeholder for hdmi0 to r8a7796.dtsi first.

Thanks!

Geert Uytterhoeven (2):
  arm64: dts: r8a7796: Add placeholder for HDMI device
  arm64: dts: r8a7795: salvator-x: Move HDMI0 to common Salvator-X board
support

 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 17 -
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  9 +
 arch/arm64/boot/dts/renesas/salvator-x.dtsi| 17 +
 3 files changed, 26 insertions(+), 17 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

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

[Niklas Söderlund]

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 
> ---
> v1 -> v2
> 
>  - simple-scu-card -> simple-scu-audio-card on git log

Reviewed-by: Niklas Söderlund 

> 
>  .../devicetree/bindings/sound/renesas,rsnd.txt | 30 
> +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt 
> b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> index 15a7316..3332910 100644
> --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> @@ -83,11 +83,11 @@ SRC can convert [xx]Hz to [yy]Hz. Then, it has below 2 
> modes
>  ** Asynchronous mode
>  --
>  
> -You need to use "renesas,rsrc-card" sound card for it.
> +You need to use "simple-scu-audio-card" sound card for it.
>  example)
>  
>   sound {
> - compatible = "renesas,rsrc-card";
> + compatible = "simple-scu-audio-card";
>   ...
>   /*
>* SRC Asynchronous mode setting
> @@ -97,12 +97,12 @@ example)
>* Inputed 48kHz data will be converted to
>* system specified Hz
>*/
> - convert-rate = <48000>;
> + simple-audio-card,convert-rate = <48000>;
>   ...
> - cpu {
> + simple-audio-card,cpu {
>   sound-dai = <_sound>;
>   };
> - codec {
> + simple-audio-card,codec {
>   ...
>   };
>   };
> @@ -141,23 +141,23 @@ For more detail information, see below
>   ${LINUX}/sound/soc/sh/rcar/ctu.c
>- comment of header
>  
> -You need to use "renesas,rsrc-card" sound card for it.
> +You need to use "simple-scu-audio-card" sound card for it.
>  example)
>  
>   sound {
> - compatible = "renesas,rsrc-card";
> + compatible = "simple-scu-audio-card";
>   ...
>   /*
>* CTU setting
>* All input data will be converted to 2ch
>* as output data
>*/
> - convert-channels = <2>;
> + simple-audio-card,convert-channels = <2>;
>   ...
> - cpu {
> + simple-audio-card,cpu {
>   sound-dai = <_sound>;
>   };
> - codec {
> + simple-audio-card,codec {
>   ...
>   };
>   };
> @@ -190,22 +190,22 @@ and these sounds will be merged by MIX.
>   aplay -D plughw:0,0 .wav &
>   aplay -D plughw:0,1 .wav
>  
> -You need to use "renesas,rsrc-card" sound card for it.
> +You need to use "simple-scu-audio-card" sound card for it.
>  Ex)
>   [MEM] -> [SRC1] -> [CTU02] -+-> [MIX0] -> [DVC0] -> [SSI0]
>   |
>   [MEM] -> [SRC2] -> [CTU03] -+
>  
>   sound {
> - compatible = "renesas,rsrc-card";
> + compatible = "simple-scu-audio-card";
>   ...
> - cpu@0 {
> + simple-audio-card,cpu@0 {
>   sound-dai = <_sound 0>;
>   };
> - cpu@1 {
> + simple-audio-card,cpu@1 {
>   sound-dai = <_sound 1>;
>   };
> - codec {
> + simple-audio-card,codec {
>   ...
>   };
>   };
> -- 
> 1.9.1
> 

-- 
Regards,
Niklas Söderlund

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

[Laurent Pinchart]

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 messed that up in the original patch :-/ Feel free to squash
this fix in "arm64: dts: renesas: r8a7795: Add HDMI encoder support" if you
want to rebase, or just apply it on top.

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1aad7433b460..ee0129634cdf 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1761,7 +1761,7 @@
hdmi0: hdmi0@fead {
compatible = "renesas,r8a7795-hdmi", 
"renesas,rcar-gen3-hdmi";
reg = <0 0xfead 0 0x1>;
-   interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
+   interrupts = ;
clocks = < CPG_MOD 729>, < CPG_CORE 
R8A7795_CLK_HDMI>;
clock-names = "iahb", "isfr";
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -1786,7 +1786,7 @@
hdmi1: hdmi1@feae {
compatible = "renesas,r8a7795-hdmi", 
"renesas,rcar-gen3-hdmi";
reg = <0 0xfeae 0 0x1>;
-   interrupts = <0 436 IRQ_TYPE_LEVEL_HIGH>;
+   interrupts = ;
clocks = < CPG_MOD 728>, < CPG_CORE 
R8A7795_CLK_HDMI>;
clock-names = "iahb", "isfr";
power-domains = < R8A7795_PD_ALWAYS_ON>;
-- 
Regards,

Laurent Pinchart

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

[Geert Uytterhoeven]

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 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 about out-of-tree user ?

Probably not, especially for H3 ES1.x.

>> > I can adjust it both r8a7795/6.
>> > Do you want to v3 patch for r8a7796 ?
>> > or incremental patch is OK with r8a7795 ?
>>
>> As long as I haven't sent a pull request for sh-pfc-for-v4.13, it can still 
>> be
>> fixed incrementally.
>
> OK. will do in v3

OK, thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

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

[Kuninori Morimoto]

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 upstream code.
Should we care about out-of-tree user ?

> > I can adjust it both r8a7795/6.
> > Do you want to v3 patch for r8a7796 ?
> > or incremental patch is OK with r8a7795 ?
> 
> As long as I haven't sent a pull request for sh-pfc-for-v4.13, it can still be
> fixed incrementally.

OK. will do in v3

Best regards
---
Kuninori Morimoto

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

[Geert Uytterhoeven]

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 Controller 
> (USB-DMAC) driver")
> Cc:  # v4.1+
> Signed-off-by: Hiroyuki Yokoyama 
> [Shimoda: add Fixes and Cc tags in the commit log]
> Signed-off-by: Yoshihiro Shimoda 

This matches my documentation, where the AE bit in the DMAOR register
is indeed different for USB-DMAC, compared to SYS-DMAC and AUDIO-DMAC.

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

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

[Geert Uytterhoeven]

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 ssi34_ctrl_mux[] = {
>> > +   SSI_SCK34_MARK, SSI_WS34_MARK,
>> > +};
>>
>> I'm a bit confused by this group: in the R-Car M3 Pin Function Rev. 0.54
>> sheet, these are named SCK349 resp. WS349. According to the history, the
>> change from {SCK,WS}34 to {SCK,WS}349 was made at the same time as the
>> change from {SCK,WS}0129 to {SCK,WS}01239.
>> However, the former change is not reflected in the PFC section of the
>> Hardware User's Manual.
>>
>> So which is correct: {SCK,WS}34 or {SCK,WS}349?
>>
>> Can you please enlighten me?
>
> It seems
> SSI_SCK 0129 -> 01239 was happen on v0.51 timing,
> SSI_SCK 34   -> 349   was happen on v0.54 timing.

In the pin function spreadsheets, the changes were made together, in June 2016.

> 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 can adjust it both r8a7795/6.
> Do you want to v3 patch for r8a7796 ?
> or incremental patch is OK with r8a7795 ?

As long as I haven't sent a pull request for sh-pfc-for-v4.13, it can still be
fixed incrementally.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

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

[Yoshihiro Shimoda]

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 
[Shimoda: add Fixes and Cc tags in the commit log]
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/dma/sh/usb-dmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
index 72c6497..31a1451 100644
--- a/drivers/dma/sh/usb-dmac.c
+++ b/drivers/dma/sh/usb-dmac.c
@@ -117,7 +117,7 @@ struct usb_dmac {
 #define USB_DMASWR 0x0008
 #define USB_DMASWR_SWR (1 << 0)
 #define USB_DMAOR  0x0060
-#define USB_DMAOR_AE   (1 << 2)
+#define USB_DMAOR_AE   (1 << 1)
 #define USB_DMAOR_DME  (1 << 0)
 
 #define USB_DMASAR 0x
-- 
1.9.1

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

[Kuninori Morimoto]

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

 .../devicetree/bindings/sound/renesas,rsnd.txt | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt 
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 15a7316..3332910 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -83,11 +83,11 @@ SRC can convert [xx]Hz to [yy]Hz. Then, it has below 2 modes
 ** Asynchronous mode
 --
 
-You need to use "renesas,rsrc-card" sound card for it.
+You need to use "simple-scu-audio-card" sound card for it.
 example)
 
sound {
-   compatible = "renesas,rsrc-card";
+   compatible = "simple-scu-audio-card";
...
/*
 * SRC Asynchronous mode setting
@@ -97,12 +97,12 @@ example)
 * Inputed 48kHz data will be converted to
 * system specified Hz
 */
-   convert-rate = <48000>;
+   simple-audio-card,convert-rate = <48000>;
...
-   cpu {
+   simple-audio-card,cpu {
sound-dai = <_sound>;
};
-   codec {
+   simple-audio-card,codec {
...
};
};
@@ -141,23 +141,23 @@ For more detail information, see below
${LINUX}/sound/soc/sh/rcar/ctu.c
 - comment of header
 
-You need to use "renesas,rsrc-card" sound card for it.
+You need to use "simple-scu-audio-card" sound card for it.
 example)
 
sound {
-   compatible = "renesas,rsrc-card";
+   compatible = "simple-scu-audio-card";
...
/*
 * CTU setting
 * All input data will be converted to 2ch
 * as output data
 */
-   convert-channels = <2>;
+   simple-audio-card,convert-channels = <2>;
...
-   cpu {
+   simple-audio-card,cpu {
sound-dai = <_sound>;
};
-   codec {
+   simple-audio-card,codec {
...
};
};
@@ -190,22 +190,22 @@ and these sounds will be merged by MIX.
aplay -D plughw:0,0 .wav &
aplay -D plughw:0,1 .wav
 
-You need to use "renesas,rsrc-card" sound card for it.
+You need to use "simple-scu-audio-card" sound card for it.
 Ex)
[MEM] -> [SRC1] -> [CTU02] -+-> [MIX0] -> [DVC0] -> [SSI0]
|
[MEM] -> [SRC2] -> [CTU03] -+
 
sound {
-   compatible = "renesas,rsrc-card";
+   compatible = "simple-scu-audio-card";
...
-   cpu@0 {
+   simple-audio-card,cpu@0 {
sound-dai = <_sound 0>;
};
-   cpu@1 {
+   simple-audio-card,cpu@1 {
sound-dai = <_sound 1>;
};
-   codec {
+   simple-audio-card,codec {
...
};
};
-- 
1.9.1

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

[Mark Brown]

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) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From ec185f95401e36f398b39706705f10d7fe7ff058 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Mon, 8 May 2017 02:28:13 +
Subject: [PATCH] ASoC: ak4613: disable asymmetric audio interface format

Asymmetric audio interface formats exist in ak4613 by same
register settings.

Capture Playback
24bit LEFT_J16bit RIGHT_J
24bit LEFT_J20bit RIGHT_J
24bit LEFT_J24bit RIGHT_J
24bit LEFT_J24bit LEFT_J
24bit I2S   24bit I2S

These asymmetric formats makes driver / behavior difficult.
It is not HW limitation, but SW limitation. To makes code reading
easy, this patch removes asymmetric format support.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/ak4613.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/sound/soc/codecs/ak4613.c b/sound/soc/codecs/ak4613.c
index b2dfddead227..557ac16d43e2 100644
--- a/sound/soc/codecs/ak4613.c
+++ b/sound/soc/codecs/ak4613.c
@@ -139,9 +139,7 @@ static const struct reg_default ak4613_reg[] = {
 #define AUDIO_IFACE(b, fmt) { b, SND_SOC_DAIFMT_##fmt }
 static const struct ak4613_interface ak4613_iface[] = {
/* capture */   /* playback */
-   [0] = { AUDIO_IFACE(24, LEFT_J),AUDIO_IFACE(16, RIGHT_J) },
-   [1] = { AUDIO_IFACE(24, LEFT_J),AUDIO_IFACE(20, RIGHT_J) },
-   [2] = { AUDIO_IFACE(24, LEFT_J),AUDIO_IFACE(24, RIGHT_J) },
+   /* [0] - [2] are not supported */
[3] = { AUDIO_IFACE(24, LEFT_J),AUDIO_IFACE(24, LEFT_J) },
[4] = { AUDIO_IFACE(24, I2S),   AUDIO_IFACE(24, I2S) },
 };
@@ -262,11 +260,9 @@ static int ak4613_dai_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
fmt &= SND_SOC_DAIFMT_FORMAT_MASK;
 
switch (fmt) {
-   case SND_SOC_DAIFMT_RIGHT_J:
case SND_SOC_DAIFMT_LEFT_J:
case SND_SOC_DAIFMT_I2S:
priv->fmt = fmt;
-
break;
default:
return -EINVAL;
@@ -286,13 +282,8 @@ static bool ak4613_dai_fmt_matching(const struct 
ak4613_interface *iface,
if (fmts->fmt != fmt)
return false;
 
-   if (fmt == SND_SOC_DAIFMT_RIGHT_J) {
-   if (fmts->width != width)
-   return false;
-   } else {
-   if (fmts->width < width)
-   return false;
-   }
+   if (fmts->width != width)
+   return false;
 
return true;
 }
@@ -420,8 +411,7 @@ static const struct snd_soc_dai_ops ak4613_dai_ops = {
 SNDRV_PCM_RATE_96000  |\
 SNDRV_PCM_RATE_176400 |\
 SNDRV_PCM_RATE_192000)
-#define AK4613_PCM_FMTBIT  (SNDRV_PCM_FMTBIT_S16_LE |\
-SNDRV_PCM_FMTBIT_S24_LE)
+#define AK4613_PCM_FMTBIT  (SNDRV_PCM_FMTBIT_S24_LE)
 
 static struct snd_soc_dai_driver ak4613_dai = {
.name = "ak4613-hifi",
-- 
2.11.0

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

[Kuninori Morimoto]

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 fix git log in v2

Best regards
---
Kuninori Morimoto

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

[Niklas Söderlund]

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 intentional or a typo?

> 
> Signed-off-by: Kuninori Morimoto 
> ---
>  .../devicetree/bindings/sound/renesas,rsnd.txt | 30 
> +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt 
> b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> index 15a7316..3332910 100644
> --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> @@ -83,11 +83,11 @@ SRC can convert [xx]Hz to [yy]Hz. Then, it has below 2 
> modes
>  ** Asynchronous mode
>  --
>  
> -You need to use "renesas,rsrc-card" sound card for it.
> +You need to use "simple-scu-audio-card" sound card for it.
>  example)
>  
>   sound {
> - compatible = "renesas,rsrc-card";
> + compatible = "simple-scu-audio-card";
>   ...
>   /*
>* SRC Asynchronous mode setting
> @@ -97,12 +97,12 @@ example)
>* Inputed 48kHz data will be converted to
>* system specified Hz
>*/
> - convert-rate = <48000>;
> + simple-audio-card,convert-rate = <48000>;
>   ...
> - cpu {
> + simple-audio-card,cpu {
>   sound-dai = <_sound>;
>   };
> - codec {
> + simple-audio-card,codec {
>   ...
>   };
>   };
> @@ -141,23 +141,23 @@ For more detail information, see below
>   ${LINUX}/sound/soc/sh/rcar/ctu.c
>- comment of header
>  
> -You need to use "renesas,rsrc-card" sound card for it.
> +You need to use "simple-scu-audio-card" sound card for it.
>  example)
>  
>   sound {
> - compatible = "renesas,rsrc-card";
> + compatible = "simple-scu-audio-card";
>   ...
>   /*
>* CTU setting
>* All input data will be converted to 2ch
>* as output data
>*/
> - convert-channels = <2>;
> + simple-audio-card,convert-channels = <2>;
>   ...
> - cpu {
> + simple-audio-card,cpu {
>   sound-dai = <_sound>;
>   };
> - codec {
> + simple-audio-card,codec {
>   ...
>   };
>   };
> @@ -190,22 +190,22 @@ and these sounds will be merged by MIX.
>   aplay -D plughw:0,0 .wav &
>   aplay -D plughw:0,1 .wav
>  
> -You need to use "renesas,rsrc-card" sound card for it.
> +You need to use "simple-scu-audio-card" sound card for it.
>  Ex)
>   [MEM] -> [SRC1] -> [CTU02] -+-> [MIX0] -> [DVC0] -> [SSI0]
>   |
>   [MEM] -> [SRC2] -> [CTU03] -+
>  
>   sound {
> - compatible = "renesas,rsrc-card";
> + compatible = "simple-scu-audio-card";
>   ...
> - cpu@0 {
> + simple-audio-card,cpu@0 {
>   sound-dai = <_sound 0>;
>   };
> - cpu@1 {
> + simple-audio-card,cpu@1 {
>   sound-dai = <_sound 1>;
>   };
> - codec {
> + simple-audio-card,codec {
>   ...
>   };
>   };
> -- 
> 1.9.1
> 

-- 
Regards,
Niklas Söderlund

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

[Simon Horman]

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 patch to
> > > salvator-x.dtsi :-( Please see below.
> > > 
> > > On Thursday 27 Apr 2017 17:43:56 Laurent Pinchart wrote:
> > >> Hi Ulrich,
> > >> 
> > >> Thank you for the patch.
> > >> 
> > >> On Thursday 27 Apr 2017 16:37:39 Ulrich Hecht wrote:
> > >>> The panel backlight is controlled through a GPIO and a PWM channel.
> > >>> 
> > >>> Signed-off-by: Ulrich Hecht 
> > >> 
> > >> Reviewed-by: Laurent Pinchart 
> > >> 
> > >>> ---
> > >>> 
> > >>>  arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 22 +
> > >>>  1 file changed, 22 insertions(+)
> > >>> 
> > >>> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > >>> b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts index
> > >>> 14d9e51..abda84c
> > >>> 100644
> > >>> --- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > >>> +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > >>> @@ -133,6 +133,11 @@
> > >>> function = "i2c2";
> > >>> };
> > >>> 
> > >>> +   pwm1_pins: pwm {
> > >>> +   groups = "pwm1_a";
> > >>> +   function = "pwm1";
> > >>> +   };
> > >>> +
> > > 
> > > This is alphabetically ordered here and isn't anymore in your devel
> > > branch.
> > 
> > Thanks, I  will move it from between scif_clk_pins and sdhi0_pins to
> > between i2c2_pins and scif1_pins.
> > 
> > >>> sdhi0_pins: sd0 {
> > >>> groups = "sdhi0_data4", "sdhi0_ctrl";
> > >>> function = "sdhi0";
> > >>> @@ -183,6 +188,16 @@
> > >>> interrupt-parent = <>;
> > >>> interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> > >>> };
> > >>> +
> > >>> +   backlight: backlight {
> > >>> +   compatible = "pwm-backlight";
> > >>> +   pwms = < 0 5>;
> > >>> +
> > >>> +   brightness-levels = <256 128 64 16 8 4 0>;
> > >>> +   default-brightness-level = <6>;
> > >>> +
> > >>> +   enable-gpios = < 7 GPIO_ACTIVE_HIGH>;
> > >>> +   };
> > > 
> > > The backlight node needs to be added as a child of the root node, while
> > > you've added it to the DU node in your devel branch.
> > 
> > Thanks. I have moved it to between audio_clkout and reg_1p8v in
> > the root node.
> > 
> > >>>  };
> > >>>  
> > >>>  _clk {
> > >>> @@ -235,6 +250,13 @@
> > >>> status = "okay";
> > >>>  };
> > >>> 
> > >>> + {
> > >>> +   pinctrl-0 = <_pins>;
> > >>> +   pinctrl-names = "default";
> > >>> +
> > >>> +   status = "okay";
> > >>> +};
> > >>> +
> > > 
> > > This is alphabetically ordered here and isn't anymore in your devel
> > > branch.
> > 
> > Thanks, I have moved it from between rcar_sound and scif1 to
> > between pfc and rcar_sound.
> > 
> > > Can you rebase your devel branch to fix this ?
> > 
> > Sure. I have the following in my local tree which I plan to push
> > a later today.
> 
> That looks good to me, thank you !

Thanks for checking.

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

[Simon Horman]

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 where found by
> > examining the registers after the bootloader has configured the
> > registers and successfully used the EthernetAVB.
> >
> > Based on:
> > * commit 7d73a4da2681 ("arm64: dts: r8a7795: salvator-x: Set drive-strength
> >   for ravb pins")
> > * commit 4903987033be ("arm64: dts: r8a7796: salvator-x: Set drive-strength
> >   for ravb pins")
> >
> > Cc: Geert Uytterhoeven 
> > Cc: Niklas Söderlund 
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> > * Compile tested only due to lack of hardware access
> 
> So how did you examine the registers? ;-)

You got me there: copy-paste gone wrong.

> Hence I examined the registers myself:
>   - H3ULCB has the same register settings as Salvator-X with H3 ES1.0
>   - M3ULCB has the same register settings as Salvator-X with M3-W ES1.0
> or H3 ES2.0.

That was my assumption, which is what I should have written.
But as you have checked - thanks for that - I will leave the changelog
as-is and queue up the patch.

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

[Simon Horman]

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 have been rebased on top of a merge of Simon's latest devel 
> > branch
> > and v4.12-rc1, and have taken Geert's comments into account. For 
> > convenience,
> > they are available from
> > 
> > git://linuxtv.org/pinchartl/media.git drm-next-dt-v5-20170513
> > 
> > Simon, this still depends on driver changes that were merged by Linus for
> > v4.12-rc1 (the checkpatch warnings related to unknown compatible strings 
> > will
> > then be gone). Again, please only apply these patches after you merge
> > v4.12-rc1 in your tree.
> 
> Thanks. Now that v4.12-rc1 has been released I have rebased by
> arm64-dt-for-v4.13 branch on top of it. I plan to merge that into both
> renesas-next and renesas-devel, and push later today.

I somehow forgot to say that I have queued up these patches in
the arm64-dt-for-v4.13 branch.

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

[Simon Horman]

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, and have taken Geert's comments into account. For convenience,
> they are available from
> 
> git://linuxtv.org/pinchartl/media.git drm-next-dt-v5-20170513
> 
> Simon, this still depends on driver changes that were merged by Linus for
> v4.12-rc1 (the checkpatch warnings related to unknown compatible strings will
> then be gone). Again, please only apply these patches after you merge
> v4.12-rc1 in your tree.

Thanks. Now that v4.12-rc1 has been released I have rebased by
arm64-dt-for-v4.13 branch on top of it. I plan to merge that into both
renesas-next and renesas-devel, and push later today.

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

[Laurent Pinchart]

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 2017 17:43:56 Laurent Pinchart wrote:
> >> Hi Ulrich,
> >> 
> >> Thank you for the patch.
> >> 
> >> On Thursday 27 Apr 2017 16:37:39 Ulrich Hecht wrote:
> >>> The panel backlight is controlled through a GPIO and a PWM channel.
> >>> 
> >>> Signed-off-by: Ulrich Hecht 
> >> 
> >> Reviewed-by: Laurent Pinchart 
> >> 
> >>> ---
> >>> 
> >>>  arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 22 +
> >>>  1 file changed, 22 insertions(+)
> >>> 
> >>> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> >>> b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts index
> >>> 14d9e51..abda84c
> >>> 100644
> >>> --- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> >>> +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> >>> @@ -133,6 +133,11 @@
> >>>   function = "i2c2";
> >>>   };
> >>> 
> >>> + pwm1_pins: pwm {
> >>> + groups = "pwm1_a";
> >>> + function = "pwm1";
> >>> + };
> >>> +
> > 
> > This is alphabetically ordered here and isn't anymore in your devel
> > branch.
> 
> Thanks, I  will move it from between scif_clk_pins and sdhi0_pins to
> between i2c2_pins and scif1_pins.
> 
> >>>   sdhi0_pins: sd0 {
> >>>   groups = "sdhi0_data4", "sdhi0_ctrl";
> >>>   function = "sdhi0";
> >>> @@ -183,6 +188,16 @@
> >>>   interrupt-parent = <>;
> >>>   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> >>>   };
> >>> +
> >>> + backlight: backlight {
> >>> + compatible = "pwm-backlight";
> >>> + pwms = < 0 5>;
> >>> +
> >>> + brightness-levels = <256 128 64 16 8 4 0>;
> >>> + default-brightness-level = <6>;
> >>> +
> >>> + enable-gpios = < 7 GPIO_ACTIVE_HIGH>;
> >>> + };
> > 
> > The backlight node needs to be added as a child of the root node, while
> > you've added it to the DU node in your devel branch.
> 
> Thanks. I have moved it to between audio_clkout and reg_1p8v in
> the root node.
> 
> >>>  };
> >>>  
> >>>  _clk {
> >>> @@ -235,6 +250,13 @@
> >>>   status = "okay";
> >>>  };
> >>> 
> >>> + {
> >>> + pinctrl-0 = <_pins>;
> >>> + pinctrl-names = "default";
> >>> +
> >>> + status = "okay";
> >>> +};
> >>> +
> > 
> > This is alphabetically ordered here and isn't anymore in your devel
> > branch.
> 
> Thanks, I have moved it from between rcar_sound and scif1 to
> between pfc and rcar_sound.
> 
> > Can you rebase your devel branch to fix this ?
> 
> Sure. I have the following in my local tree which I plan to push
> a later today.

That looks good to me, thank you !

> From: Laurent Pinchart 
> 
> [PATCH] arm64: dts: salvator-x: Add panel backlight support
> 
> The panel backlight is controlled through a GPIO and a PWM channel.
> 
> Signed-off-by: Laurent Pinchart 
> [simon: apply to salvator-x.dtsi instead of r8a7795-salvator-x.dts]
> Signed-off-by: Simon Horman 
> ---
>  arch/arm64/boot/dts/renesas/salvator-x.dtsi | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> b/arch/arm64/boot/dts/renesas/salvator-x.dtsi index
> d5eb022d247c..7240bcd75918 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> @@ -58,6 +58,16 @@
>   clock-frequency = <11289600>;
>   };
> 
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 5>;
> +
> + brightness-levels = <256 128 64 16 8 4 0>;
> + default-brightness-level = <6>;
> +
> + enable-gpios = < 7 GPIO_ACTIVE_HIGH>;
> + };
> +
>   reg_1p8v: regulator0 {
>   compatible = "regulator-fixed";
>   regulator-name = "fixed-1.8V";
> @@ -358,6 +368,11 @@
>   function = "i2c2";
>   };
> 
> + pwm1_pins: pwm {
> + groups = "pwm1_a";
> + function = "pwm1";
> + };
> +
>   scif1_pins: scif1 {
>   groups = "scif1_data_a", "scif1_ctrl";
>   function = "scif1";
> @@ -443,6 +458,13 @@
>   };
>  };
> 
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
> +
>  _sound {
>   pinctrl-0 = <_pins _clk_pins>;
>   pinctrl-names = "default";

-- 
Regards,

Laurent Pinchart