Re: [PATCH v2 3/3] usb: gadget: udc: renesas_usb3: add support for R-Car M3-W

[Rob Herring]

On Fri, Aug 04, 2017 at 11:16:58AM +0900, Yoshihiro Shimoda wrote:
> This patch adds support for R-Car M3-W. This patch also adds R-Car
> Gen3 generic version's compatible and changes ".compatible" in
> the usb3_of_match from "renesas,r8a7796-usb3-peri" to
> "renesas,rcar-gen3-usb3-peri".
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/usb/renesas_usb3.txt | 16 +---
>  drivers/usb/gadget/udc/renesas_usb3.c  |  2 +-
>  2 files changed, 14 insertions(+), 4 deletions(-)

Binding looks fine, but...

> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index aa2b185..b1e166c 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -2503,7 +2503,7 @@ static void renesas_usb3_init_ram(struct renesas_usb3 
> *usb3, struct device *dev,
>  
>  static const struct of_device_id usb3_of_match[] = {
>   {
> - .compatible = "renesas,r8a7795-usb3-peri",
> + .compatible = "renesas,rcar-gen3-usb3-peri",

You need to keep the existing string for compatibility with existing 
dtbs.

>   .data = _usb3_priv_gen3,
>   },
>   { },
> -- 
> 1.9.1
> 

Re: [PATCH] dmaengine: usb-dmac: Add soctype for R-Car M3-W

[Rob Herring]

On Wed, Aug 02, 2017 at 08:33:34PM +0900, Yoshihiro Shimoda wrote:
> This patch adds R-Car M3-W device tree bindings for usb-dmac driver.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Applied "ASoC: rsnd: add rsnd_ssi_flags_has/add() macro" to the asoc tree

[Mark Brown]

The patch

   ASoC: rsnd: add rsnd_ssi_flags_has/add() macro

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 bf9b29c784b393d1e506945f1e24e871d2587eb3 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Thu, 10 Aug 2017 00:07:20 +
Subject: [PATCH] ASoC: rsnd: add rsnd_ssi_flags_has/add() macro

Current rsnd_ssi_mode_flags() is not useful. This patch adds
new rsnd_ssi_flags_has/add() macro for it.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/sh/rcar/ssi.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 281ed0da6ba1..ca9355b86bd9 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -101,7 +101,8 @@ struct rsnd_ssi {
 #define rsnd_ssi_to_dma(mod) ((ssi)->dma)
 #define rsnd_ssi_nr(priv) ((priv)->ssi_nr)
 #define rsnd_mod_to_ssi(_mod) container_of((_mod), struct rsnd_ssi, mod)
-#define rsnd_ssi_mode_flags(p) ((p)->flags)
+#define rsnd_ssi_flags_has(p, f) ((p)->flags & f)
+#define rsnd_ssi_flags_set(p, f) ((p)->flags |= f)
 #define rsnd_ssi_is_parent(ssi, io) ((ssi) == rsnd_io_to_mod_ssip(io))
 #define rsnd_ssi_is_multi_slave(mod, io) \
(rsnd_ssi_multi_slaves(io) & (1 << rsnd_mod_id(mod)))
@@ -114,10 +115,10 @@ int rsnd_ssi_hdmi_port(struct rsnd_dai_stream *io)
struct rsnd_mod *mod = rsnd_io_to_mod_ssi(io);
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
 
-   if (rsnd_ssi_mode_flags(ssi) & RSND_SSI_HDMI0)
+   if (rsnd_ssi_flags_has(ssi, RSND_SSI_HDMI0))
return RSND_SSI_HDMI_PORT0;
 
-   if (rsnd_ssi_mode_flags(ssi) & RSND_SSI_HDMI1)
+   if (rsnd_ssi_flags_has(ssi, RSND_SSI_HDMI1))
return RSND_SSI_HDMI_PORT1;
 
return 0;
@@ -132,7 +133,7 @@ int rsnd_ssi_use_busif(struct rsnd_dai_stream *io)
if (!rsnd_ssi_is_dma_mode(mod))
return 0;
 
-   if (!(rsnd_ssi_mode_flags(ssi) & RSND_SSI_NO_BUSIF))
+   if (!(rsnd_ssi_flags_has(ssi, RSND_SSI_NO_BUSIF)))
use_busif = 1;
if (rsnd_io_to_mod_src(io))
use_busif = 1;
@@ -986,13 +987,13 @@ static void __rsnd_ssi_parse_hdmi_connection(struct 
rsnd_priv *priv,
ssi  = rsnd_mod_to_ssi(mod);
 
if (strstr(remote_ep->full_name, "hdmi0")) {
-   ssi->flags |= RSND_SSI_HDMI0;
+   rsnd_ssi_flags_set(ssi, RSND_SSI_HDMI0);
dev_dbg(dev, "%s[%d] connected to HDMI0\n",
 rsnd_mod_name(mod), rsnd_mod_id(mod));
}
 
if (strstr(remote_ep->full_name, "hdmi1")) {
-   ssi->flags |= RSND_SSI_HDMI1;
+   rsnd_ssi_flags_set(ssi, RSND_SSI_HDMI1);
dev_dbg(dev, "%s[%d] connected to HDMI1\n",
rsnd_mod_name(mod), rsnd_mod_id(mod));
}
@@ -1025,7 +1026,7 @@ int __rsnd_ssi_is_pin_sharing(struct rsnd_mod *mod)
 {
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
 
-   return !!(rsnd_ssi_mode_flags(ssi) & RSND_SSI_CLK_PIN_SHARE);
+   return !!(rsnd_ssi_flags_has(ssi, RSND_SSI_CLK_PIN_SHARE));
 }
 
 static u32 *rsnd_ssi_get_status(struct rsnd_dai_stream *io,
@@ -1108,10 +1109,10 @@ int rsnd_ssi_probe(struct rsnd_priv *priv)
}
 
if (of_get_property(np, "shared-pin", NULL))
-   ssi->flags |= RSND_SSI_CLK_PIN_SHARE;
+   rsnd_ssi_flags_set(ssi, RSND_SSI_CLK_PIN_SHARE);
 
if (of_get_property(np, "no-busif", NULL))
-   ssi->flags |= RSND_SSI_NO_BUSIF;
+   rsnd_ssi_flags_set(ssi, RSND_SSI_NO_BUSIF);
 
ssi->irq = irq_of_parse_and_map(np, 0);
if (!ssi->irq) {
-- 
2.13.2

Applied "ASoC: rsnd: call request_irq/free_irq once in MIX case" to the asoc tree

[Mark Brown]

The patch

   ASoC: rsnd: call request_irq/free_irq once in MIX case

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 b6e58fcacb3edc6245ecf700207ba675cba18018 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Thu, 10 Aug 2017 00:07:38 +
Subject: [PATCH] ASoC: rsnd: call request_irq/free_irq once in MIX case

Each module's dai callback function availability is controlled
by mod->status. For example "always called", "call once".
In .probe/.remove case, it needs to be called always, because
.probe will call xxx_attach() function on .probe, especially
if platform is using MIXer.
For example, below case, MIX0/DVC0/SSI0 needs to be called twice.

playback = <>;
playback = <>;

But in this case, SSI0 will call request_irq() twice.
This patch add new RSND_SSI_PROBED flag and control it

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/sh/rcar/ssi.c | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index ca9355b86bd9..8bb47144660b 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -90,6 +90,7 @@ struct rsnd_ssi {
 #define RSND_SSI_NO_BUSIF  (1 << 1) /* SSI+DMA without BUSIF */
 #define RSND_SSI_HDMI0 (1 << 2) /* for HDMI0 */
 #define RSND_SSI_HDMI1 (1 << 3) /* for HDMI1 */
+#define RSND_SSI_PROBED(1 << 4)
 
 #define for_each_rsnd_ssi(pos, priv, i)
\
for (i = 0; \
@@ -103,6 +104,7 @@ struct rsnd_ssi {
 #define rsnd_mod_to_ssi(_mod) container_of((_mod), struct rsnd_ssi, mod)
 #define rsnd_ssi_flags_has(p, f) ((p)->flags & f)
 #define rsnd_ssi_flags_set(p, f) ((p)->flags |= f)
+#define rsnd_ssi_flags_del(p, f) ((p)->flags = ((p)->flags & ~f))
 #define rsnd_ssi_is_parent(ssi, io) ((ssi) == rsnd_io_to_mod_ssip(io))
 #define rsnd_ssi_is_multi_slave(mod, io) \
(rsnd_ssi_multi_slaves(io) & (1 << rsnd_mod_id(mod)))
@@ -784,11 +786,22 @@ static int rsnd_ssi_common_probe(struct rsnd_mod *mod,
/*
 * SSI might be called again as PIO fallback
 * It is easy to manual handling for IRQ request/free
+*
+* OTOH, this function might be called many times if platform is
+* using MIX. It needs xxx_attach() many times on xxx_probe().
+* Because of it, we can't control .probe/.remove calling count by
+* mod->status.
+* But it don't need to call request_irq() many times.
+* Let's control it by RSND_SSI_PROBED flag.
 */
-   ret = request_irq(ssi->irq,
- rsnd_ssi_interrupt,
- IRQF_SHARED,
- dev_name(dev), mod);
+   if (!rsnd_ssi_flags_has(ssi, RSND_SSI_PROBED)) {
+   ret = request_irq(ssi->irq,
+ rsnd_ssi_interrupt,
+ IRQF_SHARED,
+ dev_name(dev), mod);
+
+   rsnd_ssi_flags_set(ssi, RSND_SSI_PROBED);
+   }
 
return ret;
 }
@@ -805,7 +818,11 @@ static int rsnd_ssi_common_remove(struct rsnd_mod *mod,
return 0;
 
/* PIO will request IRQ again */
-   free_irq(ssi->irq, mod);
+   if (rsnd_ssi_flags_has(ssi, RSND_SSI_PROBED)) {
+   free_irq(ssi->irq, mod);
+
+   rsnd_ssi_flags_del(ssi, RSND_SSI_PROBED);
+   }
 
return 0;
 }
-- 
2.13.2

Applied "ASoC: rsnd: call free_irq() both DMA/PIO mode" to the asoc tree

[Mark Brown]

The patch

   ASoC: rsnd: call free_irq() both DMA/PIO mode

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 213691c7e873206742b39751895d15b41a02b3d1 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Thu, 10 Aug 2017 00:07:00 +
Subject: [PATCH] ASoC: rsnd: call free_irq() both DMA/PIO mode

commit 701172dca15b ("ASoC: rsnd: don't use devm_request_irq() for SSI")
exchanged devm_request_irq() to request_irq() for SSI, because SSI will
fallback into PIO mode if DMA doesn't work.
But, because of it, PIO mode needed to call free_irq() when removing,
not only DMA mode.
This patch call free_irq() both PIO/DMA. Otherwise, rsnd IRQ handler
will be increased if user tried many unbind/bind.

Fixes: 701172dca15b ("ASoC: rsnd: don't use devm_request_irq() for SSI")
Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/sh/rcar/ssi.c | 37 +++--
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 0309de58bf18..281ed0da6ba1 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -792,6 +792,23 @@ static int rsnd_ssi_common_probe(struct rsnd_mod *mod,
return ret;
 }
 
+static int rsnd_ssi_common_remove(struct rsnd_mod *mod,
+ struct rsnd_dai_stream *io,
+ struct rsnd_priv *priv)
+{
+   struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
+   struct rsnd_mod *pure_ssi_mod = rsnd_io_to_mod_ssi(io);
+
+   /* Do nothing if non SSI (= SSI parent, multi SSI) mod */
+   if (pure_ssi_mod != mod)
+   return 0;
+
+   /* PIO will request IRQ again */
+   free_irq(ssi->irq, mod);
+
+   return 0;
+}
+
 static int rsnd_ssi_pointer(struct rsnd_mod *mod,
struct rsnd_dai_stream *io,
snd_pcm_uframes_t *pointer)
@@ -807,6 +824,7 @@ static int rsnd_ssi_pointer(struct rsnd_mod *mod,
 static struct rsnd_mod_ops rsnd_ssi_pio_ops = {
.name   = SSI_NAME,
.probe  = rsnd_ssi_common_probe,
+   .remove = rsnd_ssi_common_remove,
.init   = rsnd_ssi_init,
.quit   = rsnd_ssi_quit,
.start  = rsnd_ssi_start,
@@ -841,23 +859,6 @@ static int rsnd_ssi_dma_probe(struct rsnd_mod *mod,
return ret;
 }
 
-static int rsnd_ssi_dma_remove(struct rsnd_mod *mod,
-  struct rsnd_dai_stream *io,
-  struct rsnd_priv *priv)
-{
-   struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
-   struct rsnd_mod *pure_ssi_mod = rsnd_io_to_mod_ssi(io);
-
-   /* Do nothing if non SSI (= SSI parent, multi SSI) mod */
-   if (pure_ssi_mod != mod)
-   return 0;
-
-   /* PIO will request IRQ again */
-   free_irq(ssi->irq, mod);
-
-   return 0;
-}
-
 static int rsnd_ssi_fallback(struct rsnd_mod *mod,
 struct rsnd_dai_stream *io,
 struct rsnd_priv *priv)
@@ -899,7 +900,7 @@ static struct rsnd_mod_ops rsnd_ssi_dma_ops = {
.name   = SSI_NAME,
.dma_req = rsnd_ssi_dma_req,
.probe  = rsnd_ssi_dma_probe,
-   .remove = rsnd_ssi_dma_remove,
+   .remove = rsnd_ssi_common_remove,
.init   = rsnd_ssi_init,
.quit   = rsnd_ssi_quit,
.start  = rsnd_ssi_start,
-- 
2.13.2

Re: Possible null pointer dereference in rcar-dmac.ko

[Laurent Pinchart]

Hi Morimoto-san,

Thank you for the patch.

On Thursday 10 Aug 2017 02:09:21 Kuninori Morimoto wrote:
> Anton Volkov noticed that engine->dev is NULL before
> of_dma_controller_register() in probe.
> Thus there might be a NULL pointer dereference in
> rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which
> is equal to (>engine)->dev.
> To be more safety code, this patch initialize dmac->engine before it.
> 
> Reported-by: Anton Volkov 
> Signed-off-by: Kuninori Morimoto 
> ---
> 
> > Anton, Laurent
> 
> I created this patch because noone posted it yesterday.
> Anton, you can use this patch and replace Author to you if you want.
> Thus, I used [RFC] on this patch

I don't think you have, the subject line is still "Re: Possible null pointer 
dereference in rcar-dmac.ko" :-)

>  drivers/dma/sh/rcar-dmac.c | 51 ---
>  1 file changed, 26 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index ffcadca..6d60628 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1818,8 +1818,32 @@ static int rcar_dmac_probe(struct platform_device
> *pdev) goto error;
>   }
> 
> - /* Initialize the channels. */
> - INIT_LIST_HEAD(>engine.channels);
> + /* Initialize engine */
> + engine = >engine;
> +
> + dma_cap_set(DMA_MEMCPY, engine->cap_mask);
> + dma_cap_set(DMA_SLAVE, engine->cap_mask);
> +
> + engine->dev = >dev;
> + engine->copy_align  = ilog2(RCAR_DMAC_MEMCPY_XFER_SIZE);
> +
> + engine->src_addr_widths = widths;
> + engine->dst_addr_widths = widths;
> + engine->directions  = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
> + engine->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> +
> + engine->device_alloc_chan_resources = 
rcar_dmac_alloc_chan_resources;
> + engine->device_free_chan_resources  = 
rcar_dmac_free_chan_resources;
> + engine->device_prep_dma_memcpy  = rcar_dmac_prep_dma_memcpy;
> + engine->device_prep_slave_sg= rcar_dmac_prep_slave_sg;
> + engine->device_prep_dma_cyclic  = rcar_dmac_prep_dma_cyclic;
> + engine->device_config   = rcar_dmac_device_config;
> + 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;
> +
> + INIT_LIST_HEAD(>channels);

I don't think this fully fixes the problem, as the rcar_dmac_isr_error() IRQ 
handler is still registered before all this. Furthermore, at least some of the 
initialization at the end of rcar_dmac_chan_probe() has to be moved before the 
rcar_dmac_isr_channel() IRQ handler registration.

Let's not commit a quick hack but fix the problem correctly, we should ensure 
that all the initialization needed by IRQ handlers is performed before they 
get registered.

>   for (i = 0; i < dmac->n_channels; ++i) {
>   ret = rcar_dmac_chan_probe(dmac, >channels[i],
> @@ -1839,29 +1863,6 @@ static int rcar_dmac_probe(struct platform_device
> *pdev) *
>* Default transfer size of 32 bytes requires 32-byte alignment.
>*/
> - engine = >engine;
> - dma_cap_set(DMA_MEMCPY, engine->cap_mask);
> - dma_cap_set(DMA_SLAVE, engine->cap_mask);
> -
> - engine->dev = >dev;
> - engine->copy_align = ilog2(RCAR_DMAC_MEMCPY_XFER_SIZE);
> -
> - engine->src_addr_widths = widths;
> - engine->dst_addr_widths = widths;
> - engine->directions = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
> - engine->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> -
> - engine->device_alloc_chan_resources = rcar_dmac_alloc_chan_resources;
> - engine->device_free_chan_resources = rcar_dmac_free_chan_resources;
> - engine->device_prep_dma_memcpy = rcar_dmac_prep_dma_memcpy;
> - engine->device_prep_slave_sg = rcar_dmac_prep_slave_sg;
> - engine->device_prep_dma_cyclic = rcar_dmac_prep_dma_cyclic;
> - engine->device_config = rcar_dmac_device_config;
> - 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)
>   goto error;

-- 
Regards,

Laurent Pinchart

Re: [PATCH 12/15] arm-soc: omap: replace open coded VA->PA calculations

[Tony Lindgren]

* Ard Biesheuvel  [170810 02:23]:
> On 9 August 2017 at 22:05, Tony Lindgren  wrote:
> > * Ard Biesheuvel  [170809 12:24]:
> >> On 9 August 2017 at 20:05, Tony Lindgren  wrote:
> >> > * Ard Biesheuvel  [170805 13:54]:
> >> >> This replaces a couple of open coded calculations to obtain the
> >> >> physical address of a far symbol with calls to the new adr_l etc
> >> >> macros.
> >> >
> >> > I gave this series a quick test and omap3 no longer boots it seems.
> >> >
> >>
> >> Thanks Tony. I will investigate
> >
> > Thanks. Looks like omap4 still boots with all your patches, but
> > omap3 won't boot even with patch 12 left out.
> >
> 
> Are you using the same image on both? Which .config?

Yes it's the same image compiled with omap2plus_defconfig.

Regards,

Tony

RE: [PATCH 2/2] ARM: dts: r8a7743: Add IIC cores to dtsi

[Chris Paterson]

Hello,

> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 10 August 2017 12:24
> 
> 
> > > >+i2c6: i2c@e60b {
> > >
> > >I'd use iic0 as the label.
> >
> > I have no preference here other than that we try to be consistent in
> > DT for different R-Car SoCs. Wolfram, do you have an opinion on this?
> 
> Back then, for M2-W, I decided to go with the schematics/datasheets.
> And those mentioned i2c6 rather than iic0. For that reason, the comment

The M2 schematics still use i2c6, and for consistency I'd vote to use the same 
with RZ/G1M.

> 
> "/* The memory map in the User's Manual maps the cores to bus numbers */"
> 
> exists in r8a7791.dtsi. Dunno the manual of this SoC here.

The manual for r8a7743 uses the same terminology as the r8a7791 manuals.

Kind regards, Chris

RE: [RFT 0/2] mmc: renesas_sdhi: small patches for RZ/A1

[Chris Brandt]

Hello Wolfram,


On Wednesday, August 09, 2017, Wolfram Sang wrote:
> Here is a small series to improve RZ support for SDHI. I don't have that
> platform currently, so I hope Chris has some time to check these simple
> patches. It is based on top of the patch just sent out:
> "[PATCH] mmc: renesas_sdhi: use extra flag for CBSY usage"


I applied the 3 patches and tested with an SD Card. No issues.

Thank you for considering RZ!


Chris

RE: [PATCH 0/3] Add SMP support

[Biju Das]

> -Original Message-
> From: Biju Das
> Sent: 10 August 2017 10:17
> To: 'Simon Horman' 
> Cc: Rob Herring ; Mark Rutland
> ; Magnus Damm ;
> Russell King ; Chris Paterson
> ; devicet...@vger.kernel.org; linux-renesas-
> s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH 0/3] Add SMP support
>
>
> > -Original Message-
> > From: Simon Horman [mailto:ho...@verge.net.au]
> > Sent: 09 August 2017 09:36
> > To: Biju Das 
> > Cc: Rob Herring ; Mark Rutland
> > ; Magnus Damm ;
> Russell
> > King ; Chris Paterson
> > ; devicet...@vger.kernel.org;
> > linux-renesas- s...@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org
> > Subject: Re: [PATCH 0/3] Add SMP support
> >
> > On Tue, Aug 08, 2017 at 11:56:30AM +0100, Biju Das wrote:
> > > This series aims to add SMP support for r8a7743 SoC.
> > >
> > > This series has been tested against Linux-next tag 20170727 and
> > > renesas-dev branch.
> >
> > It seems that these patches are targeted at the renesas tree.
> > The best practice in that case is to base patches on the latest devel 
> > branch.
> > Please consider doing so in future.
> >
> > The patches themselves seem good to me, however, I would like to
> > enquire about testing. In particular, have you tested CPU hotplug and
> > suspend to RAM with these patches (and without in the case of the latter)?
>
> I have tested CPU hotplug with this patch and it works ok.
>
> Currently iWave platform doesn't support STR I guess. But we should check the
> changes on other M2 platforms to prove that things don't break.

I have tested STR on RZ-G1M SK(r8a7743) platform using gpio-key as wake up 
source.
It works fine with and without the patch . It is tested against 
renesas-developer branch.

Also I have tested STR on R-Car M2 board.it works fine with gpio-key as wake up 
source.

> [>]
> > I am cautious about any regressions that may creep in when going from
> > UP to SMP.
>
> > >
> > > Biju Das (3):
> > >   dt-bindings: apmu: Document r8a7743 support
> > >   ARM: dts: r8a7743: Add APMU node and second CPU core
> > >   ARM: dts: r8a7743: Add OPP table for frequency scaling
> > >
> > >  .../devicetree/bindings/power/renesas,apmu.txt |  3 ++-
> > >  arch/arm/boot/dts/r8a7743.dtsi | 25
> ++
> > >  2 files changed, 27 insertions(+), 1 deletion(-)
> > >
> > > --
> > > 1.9.1
> > >



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH 0/3] usb: host: xhci: {plat,rcar}: add support for R-Car H3 ES2.0

[Mathias Nyman]

On 24.07.2017 15:30, Yoshihiro Shimoda wrote:

This patch set is based on the latest Greg's usb.git / usb-next branch
(the commit id = 141769851cb73e8f986e9ed83129cde3b645288d)

Yoshihiro Shimoda (3):
   usb: host: xhci: rcar: Add firmware_name selection by
 soc_device_match()
   usb: host: xhci: plat: re-fact xhci_plat_priv for R-Car Gen3
   usb: host: xhci: rcar: Add support for R-Car H3 ES2.0

  drivers/usb/host/xhci-plat.c | 10 +-
  drivers/usb/host/xhci-rcar.c | 40 ++--
  2 files changed, 39 insertions(+), 11 deletions(-)



Thanks, adding

-Mathias

Re: [PATCH v4 00/06] clocksource: sh_cmt: DT binding rework V4

[Daniel Lezcano]

On 10/08/2017 11:01, Geert Uytterhoeven wrote:
> On Tue, Jul 11, 2017 at 1:56 PM, Simon Horman  wrote:
>> On Thu, Nov 24, 2016 at 11:58:43AM +0100, Simon Horman wrote:
>>> On Mon, Mar 14, 2016 at 11:23:42PM +0900, Magnus Damm wrote:
 clocksource: sh_cmt: DT binding rework V4

 [PATCH v4 01/06] devicetree: bindings: Remove sh7372 CMT binding
 [PATCH v4 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
 [PATCH v4 03/06] devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings
 [PATCH v4 04/06] devicetree: bindings: Deprecate property, update example
 [PATCH v4 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings
 [PATCH v4 06/06] devicetree: bindings: Remove deprecated properties

 Here is the latest and hopefully final take on updating the CMT DT
 bindings for R-Car Gen2. In total there are 6 patches that have acks
 and are ready to be picked up and merged. Other earlier posted changes
 such as driver modification and SoC DTS bits depend on this series.
>>>
>>> I am wondering what the state of this work is.
>>> I see only one minor review comment for this series.
>>> It would be great to see it merged.
>>
>> Ping
> 
> Recently, at +1800m, I realized that if we want to continue this work, we
> better do it soon, so it can be included in the big R-Car Gen2 flag day
> requiring APMU, CPG/MSSR, ICRAM, RST, and SYSC being described in DT.

Applied.

Thanks.

  -- Daniel



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Hans Verkuil]

On 10/08/17 11:08, Archit Taneja wrote:
> 
> 
> On 08/10/2017 02:26 PM, Hans Verkuil wrote:
>> On 10/08/17 10:49, Archit Taneja wrote:
>>> Hi Hans,
>>>
>>> On 07/30/2017 06:37 PM, Hans Verkuil wrote:
 From: Hans Verkuil 

 This patch series adds CEC support to the drm adv7511/adv7533 drivers.

 I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
 and the Renesas R-Car Koelsch board (adv7511 based).

 Note: the Dragonboard needs this patch:

 https://patchwork.kernel.org/patch/9824773/

 Archit, can you confirm that this patch will go to kernel 4.14?

 And the Koelsch board needs this 4.13 fix:

 https://patchwork.kernel.org/patch/9836865/

 I only have the Koelsch board to test with, but it looks like other
 R-Car boards use the same adv7511. It would be nice if someone can
 add CEC support to the other R-Car boards as well. The main thing
 to check is if they all use the same 12 MHz fixed CEC clock source.

 Anyone who wants to test this will need the CEC utilities that
 are part of the v4l-utils git repository:

 git clone git://linuxtv.org/v4l-utils.git
 cd v4l-utils
 ./bootstrap.sh
 ./configure
 make
 sudo make install

 Now configure the CEC adapter as a Playback device:

 cec-ctl --playback

 Discover other CEC devices:

 cec-ctl -S
>>>
>>> I tried the instructions, and I get the following output. I don't think I 
>>> have
>>> any CEC device connected, though. Is this the expected behaviour?
>>>
>>> #cec-ctl -S
>>> Driver Info:
>>>  Driver Name: adv7511
>>>  Adapter Name   : 3-0039
>>>  Capabilities   : 0x000e
>>>  Logical Addresses
>>>  Transmit
>>>  Passthrough
>>>  Driver version : 4.13.0
>>>  Available Logical Addresses: 3
>>>  Physical Address   : 1.0.0.0
>>>  Logical Address Mask   : 0x
>>>  CEC Version: 2.0
>>>  Logical Addresses  : 0
>>>
>>> #cec-ctl --playback
>>> [ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!
>>
>> This isn't right. You shouldn't see this. It never receives an interrupt
>> when the transmit has finished, which causes these time outs.
>>
>> What are you testing this on? The Dragonboard c410?
> 
> Yes.

On top of which kernel tree are these patches applied? I can try and reproduce
it.

Regards,

Hans

RE: [PATCH 0/3] Add SMP support

[Biju Das]

> -Original Message-
> From: Simon Horman [mailto:ho...@verge.net.au]
> Sent: 09 August 2017 09:36
> To: Biju Das 
> Cc: Rob Herring ; Mark Rutland
> ; Magnus Damm ;
> Russell King ; Chris Paterson
> ; devicet...@vger.kernel.org; linux-renesas-
> s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 0/3] Add SMP support
>
> On Tue, Aug 08, 2017 at 11:56:30AM +0100, Biju Das wrote:
> > This series aims to add SMP support for r8a7743 SoC.
> >
> > This series has been tested against Linux-next tag 20170727 and
> > renesas-dev branch.
>
> It seems that these patches are targeted at the renesas tree.
> The best practice in that case is to base patches on the latest devel branch.
> Please consider doing so in future.
>
> The patches themselves seem good to me, however, I would like to enquire
> about testing. In particular, have you tested CPU hotplug and suspend to RAM
> with these patches (and without in the case of the latter)?

I have tested CPU hotplug with this patch and it works ok.

Currently iWave platform doesn't support STR I guess. But we should check the 
changes on other M2 platforms to prove that
things don't break.

[>]
> I am cautious about any regressions that may creep in when going from UP to
> SMP.

> >
> > Biju Das (3):
> >   dt-bindings: apmu: Document r8a7743 support
> >   ARM: dts: r8a7743: Add APMU node and second CPU core
> >   ARM: dts: r8a7743: Add OPP table for frequency scaling
> >
> >  .../devicetree/bindings/power/renesas,apmu.txt |  3 ++-
> >  arch/arm/boot/dts/r8a7743.dtsi | 25 
> > ++
> >  2 files changed, 27 insertions(+), 1 deletion(-)
> >
> > --
> > 1.9.1
> >



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH 12/15] arm-soc: omap: replace open coded VA->PA calculations

[Ard Biesheuvel]

On 9 August 2017 at 22:05, Tony Lindgren  wrote:
> * Ard Biesheuvel  [170809 12:24]:
>> On 9 August 2017 at 20:05, Tony Lindgren  wrote:
>> > * Ard Biesheuvel  [170805 13:54]:
>> >> This replaces a couple of open coded calculations to obtain the
>> >> physical address of a far symbol with calls to the new adr_l etc
>> >> macros.
>> >
>> > I gave this series a quick test and omap3 no longer boots it seems.
>> >
>>
>> Thanks Tony. I will investigate
>
> Thanks. Looks like omap4 still boots with all your patches, but
> omap3 won't boot even with patch 12 left out.
>

Are you using the same image on both? Which .config?

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Archit Taneja]

On 08/10/2017 02:26 PM, Hans Verkuil wrote:

On 10/08/17 10:49, Archit Taneja wrote:

Hi Hans,

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

Note: the Dragonboard needs this patch:

https://patchwork.kernel.org/patch/9824773/

Archit, can you confirm that this patch will go to kernel 4.14?

And the Koelsch board needs this 4.13 fix:

https://patchwork.kernel.org/patch/9836865/

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.

Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S


I tried the instructions, and I get the following output. I don't think I have
any CEC device connected, though. Is this the expected behaviour?

#cec-ctl -S
Driver Info:
 Driver Name: adv7511
 Adapter Name   : 3-0039
 Capabilities   : 0x000e
 Logical Addresses
 Transmit
 Passthrough
 Driver version : 4.13.0
 Available Logical Addresses: 3
 Physical Address   : 1.0.0.0
 Logical Address Mask   : 0x
 CEC Version: 2.0
 Logical Addresses  : 0

#cec-ctl --playback
[ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!


This isn't right. You shouldn't see this. It never receives an interrupt
when the transmit has finished, which causes these time outs.

What are you testing this on? The Dragonboard c410?


Yes.



Can you check the cec clock frequency? It should be 19.2 MHz.
Remember to apply this patch: https://patchwork.kernel.org/patch/9824773/
You probably did, but just in case...


clk_summary does show bb_clk2 to be set to 19.2 Mhz.

I applied a newer version of this patch, which got merged in clk-next:

https://patchwork.kernel.org/patch/9845493/

I will try to apply the patch you use and check again.

Thanks,
Archit



Regards,

Hans


Driver Info:
 Driver Name: adv7511
 Adapter Name   : 3-0039
 Capabilities   : 0x000e
 Logical Addresses
 Transmit
 Passthrough
 Driver version : 4.13.0
 Available Logical Addresses: 3
 Physical Address   : 1.0.0.0
 Logical Address Mask   : 0x0010
 CEC Version: 2.0
 Vendor ID  : 0x000c03
 Logical Addresses  : 1 (Allow RC Passthrough)

   Logical Address  : 4
 Primary Device Type: Playback
 Logical Address Type   : Playback
 All Device Types   : Playback
 RC TV Profile  : None
 Device Features:
 None


[ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed out!
[ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!

Thanks,
Archit



Regards,

 Hans

Hans Verkuil (4):
dt-bindings: adi,adv7511.txt: document cec clock
arm: dts: qcom: add cec clock for apq8016 board
arm: dts: renesas: add cec clock for Koelsch board
drm: adv7511/33: add HDMI CEC support

   .../bindings/display/bridge/adi,adv7511.txt|   4 +
   arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
   arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
   drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
   drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
   drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 
+
   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
   drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
   9 files changed, 514 insertions(+), 50 deletions(-)
   create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c





--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/06] clocksource: sh_cmt: DT binding rework V4

[Geert Uytterhoeven]

On Tue, Jul 11, 2017 at 1:56 PM, Simon Horman  wrote:
> On Thu, Nov 24, 2016 at 11:58:43AM +0100, Simon Horman wrote:
>> On Mon, Mar 14, 2016 at 11:23:42PM +0900, Magnus Damm wrote:
>> > clocksource: sh_cmt: DT binding rework V4
>> >
>> > [PATCH v4 01/06] devicetree: bindings: Remove sh7372 CMT binding
>> > [PATCH v4 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
>> > [PATCH v4 03/06] devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings
>> > [PATCH v4 04/06] devicetree: bindings: Deprecate property, update example
>> > [PATCH v4 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings
>> > [PATCH v4 06/06] devicetree: bindings: Remove deprecated properties
>> >
>> > Here is the latest and hopefully final take on updating the CMT DT
>> > bindings for R-Car Gen2. In total there are 6 patches that have acks
>> > and are ready to be picked up and merged. Other earlier posted changes
>> > such as driver modification and SoC DTS bits depend on this series.
>>
>> I am wondering what the state of this work is.
>> I see only one minor review comment for this series.
>> It would be great to see it merged.
>
> Ping

Recently, at +1800m, I realized that if we want to continue this work, we
better do it soon, so it can be included in the big R-Car Gen2 flag day
requiring APMU, CPG/MSSR, ICRAM, RST, and SYSC being described in DT.

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 0/4] drm/bridge/adv7511: add CEC support

[Hans Verkuil]

On 10/08/17 10:49, Archit Taneja wrote:
> Hi Hans,
> 
> On 07/30/2017 06:37 PM, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This patch series adds CEC support to the drm adv7511/adv7533 drivers.
>>
>> I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
>> and the Renesas R-Car Koelsch board (adv7511 based).
>>
>> Note: the Dragonboard needs this patch:
>>
>> https://patchwork.kernel.org/patch/9824773/
>>
>> Archit, can you confirm that this patch will go to kernel 4.14?
>>
>> And the Koelsch board needs this 4.13 fix:
>>
>> https://patchwork.kernel.org/patch/9836865/
>>
>> I only have the Koelsch board to test with, but it looks like other
>> R-Car boards use the same adv7511. It would be nice if someone can
>> add CEC support to the other R-Car boards as well. The main thing
>> to check is if they all use the same 12 MHz fixed CEC clock source.
>>
>> Anyone who wants to test this will need the CEC utilities that
>> are part of the v4l-utils git repository:
>>
>> git clone git://linuxtv.org/v4l-utils.git
>> cd v4l-utils
>> ./bootstrap.sh
>> ./configure
>> make
>> sudo make install
>>
>> Now configure the CEC adapter as a Playback device:
>>
>> cec-ctl --playback
>>
>> Discover other CEC devices:
>>
>> cec-ctl -S
> 
> I tried the instructions, and I get the following output. I don't think I have
> any CEC device connected, though. Is this the expected behaviour?
> 
> #cec-ctl -S
> Driver Info:
> Driver Name: adv7511
> Adapter Name   : 3-0039
> Capabilities   : 0x000e
> Logical Addresses
> Transmit
> Passthrough
> Driver version : 4.13.0
> Available Logical Addresses: 3
> Physical Address   : 1.0.0.0
> Logical Address Mask   : 0x
> CEC Version: 2.0
> Logical Addresses  : 0
> 
> #cec-ctl --playback
> [ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!

This isn't right. You shouldn't see this. It never receives an interrupt
when the transmit has finished, which causes these time outs.

What are you testing this on? The Dragonboard c410?

Can you check the cec clock frequency? It should be 19.2 MHz.
Remember to apply this patch: https://patchwork.kernel.org/patch/9824773/
You probably did, but just in case...

Regards,

Hans

> Driver Info:
> Driver Name: adv7511
> Adapter Name   : 3-0039
> Capabilities   : 0x000e
> Logical Addresses
> Transmit
> Passthrough
> Driver version : 4.13.0
> Available Logical Addresses: 3
> Physical Address   : 1.0.0.0
> Logical Address Mask   : 0x0010
> CEC Version: 2.0
> Vendor ID  : 0x000c03
> Logical Addresses  : 1 (Allow RC Passthrough)
> 
>   Logical Address  : 4
> Primary Device Type: Playback
> Logical Address Type   : Playback
> All Device Types   : Playback
> RC TV Profile  : None
> Device Features:
> None
> 
> 
> [ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed 
> out!
> [ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!
> 
> Thanks,
> Archit
> 
>>
>> Regards,
>>
>> Hans
>>
>> Hans Verkuil (4):
>>dt-bindings: adi,adv7511.txt: document cec clock
>>arm: dts: qcom: add cec clock for apq8016 board
>>arm: dts: renesas: add cec clock for Koelsch board
>>drm: adv7511/33: add HDMI CEC support
>>
>>   .../bindings/display/bridge/adi,adv7511.txt|   4 +
>>   arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
>>   arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
>>   drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
>>   drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
>>   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
>>   drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 
>> +
>>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
>>   drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
>>   9 files changed, 514 insertions(+), 50 deletions(-)
>>   create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>>
> 

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Archit Taneja]

Hi Hans,

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

Note: the Dragonboard needs this patch:

https://patchwork.kernel.org/patch/9824773/

Archit, can you confirm that this patch will go to kernel 4.14?

And the Koelsch board needs this 4.13 fix:

https://patchwork.kernel.org/patch/9836865/

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.

Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S


I tried the instructions, and I get the following output. I don't think I have
any CEC device connected, though. Is this the expected behaviour?

#cec-ctl -S
Driver Info:
Driver Name: adv7511
Adapter Name   : 3-0039
Capabilities   : 0x000e
Logical Addresses
Transmit
Passthrough
Driver version : 4.13.0
Available Logical Addresses: 3
Physical Address   : 1.0.0.0
Logical Address Mask   : 0x
CEC Version: 2.0
Logical Addresses  : 0

#cec-ctl --playback
[ 1038.761545] cec-3-0039: cec_thread_func: message 44 timed out!
Driver Info:
Driver Name: adv7511
Adapter Name   : 3-0039
Capabilities   : 0x000e
Logical Addresses
Transmit
Passthrough
Driver version : 4.13.0
Available Logical Addresses: 3
Physical Address   : 1.0.0.0
Logical Address Mask   : 0x0010
CEC Version: 2.0
Vendor ID  : 0x000c03
Logical Addresses  : 1 (Allow RC Passthrough)

  Logical Address  : 4
Primary Device Type: Playback
Logical Address Type   : Playback
All Device Types   : Playback
RC TV Profile  : None
Device Features:
None


[ 1041.063605] cec-3-0039: cec_thread_func: message 4f a6 06 10 00 00 timed out!
[ 1043.367482] cec-3-0039: cec_thread_func: message 4f 84 10 00 04 timed out!

Thanks,
Archit



Regards,

Hans

Hans Verkuil (4):
   dt-bindings: adi,adv7511.txt: document cec clock
   arm: dts: qcom: add cec clock for apq8016 board
   arm: dts: renesas: add cec clock for Koelsch board
   drm: adv7511/33: add HDMI CEC support

  .../bindings/display/bridge/adi,adv7511.txt|   4 +
  arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
  drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 +
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
  9 files changed, 514 insertions(+), 50 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 4/4] drm: adv7511/33: add HDMI CEC support

[Archit Taneja]

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

Add support for HDMI CEC to the drm adv7511/adv7533 drivers.

The CEC registers that we need to use are identical for both drivers,
but they appear at different offsets in the register map.


Thanks for the patch. Some minor comments below.



Signed-off-by: Hans Verkuil 
---
  drivers/gpu/drm/bridge/adv7511/Kconfig   |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile  |   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h |  45 +++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 314 +++
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 152 +++--
  drivers/gpu/drm/bridge/adv7511/adv7533.c |  30 +--
  6 files changed, 500 insertions(+), 50 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index 2fed567f9943..592b9d2ec034 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -21,3 +21,11 @@ config DRM_I2C_ADV7533
default y
help
  Support for the Analog Devices ADV7533 DSI to HDMI encoder.
+
+config DRM_I2C_ADV7511_CEC
+   bool "ADV7511/33 HDMI CEC driver"
+   depends on DRM_I2C_ADV7511
+   select CEC_CORE
+   default y
+   help
+ When selected the HDMI transmitter will support the CEC feature.
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 5ba675534f6e..5bb384938a71 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,4 +1,5 @@
  adv7511-y := adv7511_drv.o
  adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
  adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index fe18a5d2d84b..4fd7b14f619b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -195,6 +195,25 @@
  #define ADV7511_PACKET_GM(x)  ADV7511_PACKET(5, x)
  #define ADV7511_PACKET_SPARE(x)   ADV7511_PACKET(6, x)
  
+#define ADV7511_REG_CEC_TX_FRAME_HDR	0x00

+#define ADV7511_REG_CEC_TX_FRAME_DATA0 0x01
+#define ADV7511_REG_CEC_TX_FRAME_LEN   0x10
+#define ADV7511_REG_CEC_TX_ENABLE  0x11
+#define ADV7511_REG_CEC_TX_RETRY   0x12
+#define ADV7511_REG_CEC_TX_LOW_DRV_CNT 0x14
+#define ADV7511_REG_CEC_RX_FRAME_HDR   0x15
+#define ADV7511_REG_CEC_RX_FRAME_DATA0 0x16
+#define ADV7511_REG_CEC_RX_FRAME_LEN   0x25
+#define ADV7511_REG_CEC_RX_ENABLE  0x26
+#define ADV7511_REG_CEC_RX_BUFFERS 0x4a
+#define ADV7511_REG_CEC_LOG_ADDR_MASK  0x4b
+#define ADV7511_REG_CEC_LOG_ADDR_0_1   0x4c
+#define ADV7511_REG_CEC_LOG_ADDR_2 0x4d
+#define ADV7511_REG_CEC_CLK_DIV0x4e
+#define ADV7511_REG_CEC_SOFT_RESET 0x50
+
+#define ADV7533_REG_CEC_OFFSET 0x70
+
  enum adv7511_input_clock {
ADV7511_INPUT_CLOCK_1X,
ADV7511_INPUT_CLOCK_2X,
@@ -297,6 +316,8 @@ enum adv7511_type {
ADV7533,
  };
  
+#define ADV7511_MAX_ADDRS 3

+
  struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
@@ -343,15 +364,29 @@ struct adv7511 {
  
  	enum adv7511_type type;

struct platform_device *audio_pdev;
+
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV7511_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+   struct clk *cec_clk;
+   u32 cec_clk_freq;
  };
  
+#ifdef CONFIG_DRM_I2C_ADV7511_CEC

+extern const struct cec_adap_ops adv7511_cec_adap_ops;
+
+void adv7511_cec_init(struct adv7511 *adv7511, unsigned int offset);
+int adv7511_cec_parse_dt(struct device *dev, struct adv7511 *adv7511);
+void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#endif
+
  #ifdef CONFIG_DRM_I2C_ADV7533
  void adv7533_dsi_power_on(struct adv7511 *adv);
  void adv7533_dsi_power_off(struct adv7511 *adv);
  void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode *mode);
  int adv7533_patch_registers(struct adv7511 *adv);
-void adv7533_uninit_cec(struct adv7511 *adv);
-int adv7533_init_cec(struct adv7511 *adv);
+int adv7533_patch_cec_registers(struct adv7511 *adv);
  int adv7533_attach_dsi(struct adv7511 *adv);
  void adv7533_detach_dsi(struct adv7511 *adv);
  int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
@@ -374,11 +409,7 @@ static inline int adv7533_patch_registers(struct adv7511 
*adv)
return -ENODEV;
  }
  
-static inline void adv7533_uninit_cec(struct adv7511 *adv)

-{
-}
-
-static inline int adv7533_init_cec(struct adv7511 *adv)
+static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
  {
return -ENODEV;
  }
diff --git 

Re: [PATCH] mmc: renesas_sdhi: use extra flag for CBSY usage

[Wolfram Sang]

On Thu, Aug 10, 2017 at 09:58:50AM +0200, Simon Horman wrote:
> On Wed, Aug 09, 2017 at 09:00:41PM +0200, Wolfram Sang wrote:
> > There is one SDHI instance on Gen2 which does not have the CBSY bit.
> > So, turn CBSY usage into an extra flag and set it accordingly. This has
> > the additional advantage that we can also set it for other incarnations
> > later.
> 
> What is the run-time effect, if any, of this change?

The run-time effect is that a few cycles are saved because CBSY signals
ready a bit earlier than SCLKDIVEN. Though, the more important aspect is
that docs explicitly say to wait for CBSY. That's why this change was
requested although I don't think it will matter much in practice.

> > Chris: according to the specs I have, we can enable it for RZ as well. I'll
> > send a patch for that in a minute. If you could test this on top of this 
> > one,
> > that would be much appreciated! Thanks.
> 
> I take it from the above you did a pass of the available documentation to
> see which SoCs support this feature. If so, thanks!

I don't have docs for R-Car Gen1 SDHI. But given that even Gen2 has one
SDHI instance without CBSY and Gen1 is older, my educated guess is that
it does not have CBSY.



signature.asc
Description: PGP signature

Re: [PATCH v2] mmc: sdhi: use maximum width for the sdbuf register

[Wolfram Sang]

On Thu, Aug 10, 2017 at 09:53:10AM +0200, Simon Horman wrote:
> On Wed, Aug 09, 2017 at 08:29:26PM +0200, Wolfram Sang wrote:
> > Make use of the 64 bit sdbuf width on Renesas R-Car Gen3. If the
> > registers are 8 byte apart, the width is also 64 bit. For all others,
> > the width is 32 bit, even if the registers are only 16 bit apart.
> > 
> > Signed-off-by: Wolfram Sang 
> 
> Reviewed-by: Simon Horman 

Thanks!

> > Tested on a M3-W Salvator-X and H2 Lager (with both SDHI instances). On
> > the Lager, I could reproduce the problem with the old patch. It is gone now!
> 
> Do you think there is any value in widening the test-coverage of this
> change, f.e. to older SoCs?

Current mmc/next with this patch and the CBSY patch might be worth it,
I'd think. Mounting, copying and checksumming a file should do IMO.



signature.asc
Description: PGP signature

Re: [PATCH] ARM:dts:armadillo800eva: Add console parametters

[Kuninori Morimoto]

Hi Simon

> >   chosen {
> > - bootargs = "earlyprintk ignore_loglevel root=/dev/nfs 
> ip=dhcp rw";
> > + bootargs = "console=tty0 console=ttySC0,115200 earlyprintk
> > + ignore_loglevel root=/dev/nfs ip=dhcp rw";
> >   stdout-path = "serial0:115200n8";
> >   };
>
> Hi,
>
> this feels wrong. My understanding is that stdout-path should be enough
> to get the console.
(snip)
> Thank you for your comment.
> Before creating this patch, I have a patch reference of you and Geert.
> https://patchwork.kernel.org/patch/5184001/

I think he want to say here is that it needs "console=" which
is indicated by Geert on https://patchwork.kernel.org/patch/5184001/

"Note that we have to keep the "console=ttySC1" parameter in
chosen/bootargs, ..."

I don't have armadillo800eva anymore, so I can't test this patch.
But according to Phuc-san, there is not command prompt after boot
without this patch.

Best regards
---
Kuninori Morimoto

Re: [PATCH 00/10] ARM, arm64: dts: renesas: Use R-Car GPIO Gen[123] fallback compat strings

[Simon Horman]

On Wed, Aug 09, 2017 at 08:11:24PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Aug 9, 2017 at 5:22 PM, Simon Horman  wrote:
> > On Wed, Aug 09, 2017 at 09:55:26AM +0200, Simon Horman wrote:
> >> On Tue, Aug 08, 2017 at 07:29:28PM +0900, Magnus Damm wrote:
> >> > Hi Simon,
> >> >
> >> > On Tue, Aug 8, 2017 at 5:39 PM, Simon Horman 
> >> >  wrote:
> >> > > Use newly added R-Car GPIO Gen 1, 2 and 3 fallback compat strings in 
> >> > > place
> >> > > of now deprecated non-generation specific R-Car GPIO fallback compat 
> >> > > string
> >> > > in the DT of Renesas ARM and arm64 based SoCs.
> >> > >
> >> > > This should have no run-time effect as the driver matches against the
> >> > > per-SoC compat string before considering the fallback compat string.
> >> >
> >> > Thanks for your efforts.I have no issue with your series (apart from
> >> > the GPIO and SATA mistake), but at the same time I believe the GPIO
> >> > hardware itself is backwards compatible between various generations.
> >> >
> >> > In the nitpick department I would like to point out that the level of
> >> > hardware difference between say R-Car Gen1 GPIO and R-Car Gen2 GPIO is
> >> > similar to say good old uarts like 8250 and 16450 hardware. Basically
> >> > a couple of registers were added to the hardware in a
> >> > backwards-compatible way if I recall correctly.
> >> >
> >> > So if we are going to use "compatible" to point out if hardware is
> >> > compatible or not then I would do this instead:
> >>
> >> Thanks for your feedback.
> >>
> >> When the generation specific compat strings were recently
> >> added the renesas,gpio-rcar compat string was marked as deprecated
> >> as I was under the understanding that it was only compatibile with gen 1 
> >> SoCs.
> >>
> >> It now seems that was not the best thing to do and renesas,gpio-rcar should
> >> be re-instated as being a generic fallback for all R-Car versions supported
> >> in upstream.
> >>
> >> Do you concur?
> >
> > I posted a patch to un-deprecate the renesas,gpio-rcar compat string
> > in the bindings documentation.
> >
> > [PATCH] gpio: rcar: reinstate generic compat string
> 
> Thanks, this looks good to me. I would like to hear what Geert thinks as well!

Thanks, good plan.

Re: [PATCH] gpio: rcar: reinstate generic compat string

[Simon Horman]

On Wed, Aug 09, 2017 at 10:21:06AM +0200, Simon Horman wrote:
> commit d10bbd156926 ("gpio: rcar: add gen[123] fallback compatibility
> strings") deprecated the generic compat string, renesas,gpio-rcar. After
> further discussion this appears not to have been desirable as that compat
> string is compatible with all R-Car SoCs supported in upstream.
> 
> This commit partially reverts that commit, and updates related
> documentation and examples.
> 
> Fixes: d10bbd156926 ("gpio: rcar: add gen[123] fallback compatibility 
> strings")
> Signed-off-by: Simon Horman 

Hi Linus,

I believe Geert is on holidays at the moment (maybe you are to‽).
I'd like to wait for feedback from him on this as I feel that
its not at all urgent and it would be best to try to avoid further
churn in this area.

> ---
>  .../devicetree/bindings/gpio/renesas,gpio-rcar.txt | 18 
> --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt 
> b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> index 48634b01f1bf..347d8ede2982 100644
> --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> @@ -16,11 +16,13 @@ Required Properties:
>  - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller.
>  - "renesas,rcar-gen2-gpio": for a generic R-Car Gen2 or RZ/G1 GPIO 
> controller.
>  - "renesas,rcar-gen3-gpio": for a generic R-Car Gen3 GPIO controller.
> -- "renesas,gpio-rcar": deprecated.
> +- "renesas,gpio-rcar": for generic R-Car GPIO controller.
>  
> -When compatible with the generic version nodes must list the
> -SoC-specific version corresponding to the platform first followed by
> -the generic version.
> +Nodes should list all of the following that are compatible
> +in this order:
> +- A SoC-specific version
> +- A generic R-Car generation version
> +- The generic R-Car version
>  
>- reg: Base address and length of each memory resource used by the GPIO
>  controller hardware module.
> @@ -50,7 +52,9 @@ interrupt-controller/interrupts.txt.
>  Example: R8A7779 (R-Car H1) GPIO controller nodes
>  
>   gpio0: gpio@ffc4 {
> - compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
> + compatible = "renesas,gpio-r8a7779",
> +  "renesas,rcar-gen1-gpio",
> +  "renesas,gpio-rcar";
>   reg = <0xffc4 0x2c>;
>   interrupt-parent = <>;
>   interrupts = <0 141 0x4>;
> @@ -62,7 +66,9 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes
>   };
>   ...
>   gpio6: gpio@ffc46000 {
> - compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
> + compatible = "renesas,gpio-r8a7779",
> +  "renesas,rcar-gen1-gpio",
> +  "renesas,gpio-rcar";
>   reg = <0xffc46000 0x2c>;
>   interrupt-parent = <>;
>   interrupts = <0 147 0x4>;
> -- 
> 2.1.4
> 

Re: [PATCH 2/2] ARM: dts: r8a7743: Add IIC cores to dtsi

[Simon Horman]

On Wed, Aug 09, 2017 at 12:17:06PM +0300, Sergei Shtylyov wrote:
> On 8/8/2017 3:46 PM, Biju Das wrote:
> 
> >Signed-off-by: Biju Das 
> >---
> >This patch has been tested against Linux-next tag 20170727 and renesas-dev 
> >branch.
> >This patch depends on https://www.spinics.net/lists/arm-kernel/msg599220.html
> >
> >  arch/arm/boot/dts/r8a7743.dtsi | 55 
> > ++
> >  1 file changed, 55 insertions(+)
> >
> >diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
> >index 14222c72..5c2b140 100644
> >--- a/arch/arm/boot/dts/r8a7743.dtsi
> >+++ b/arch/arm/boot/dts/r8a7743.dtsi
> [...]
> >@@ -436,6 +439,58 @@
> > status = "disabled";
> > };
> >+i2c6: i2c@e60b {
> 
>I'd use iic0 as the label.

I have no preference here other than that we try to be consistent
in DT for different R-Car SoCs. Wolfram, do you have an opinion on this?

> 
> >+/* doesn't need pinmux */
> >+#address-cells = <1>;
> >+#size-cells = <0>;
> >+compatible = "renesas,iic-r8a7743",
> >+ "renesas,rcar-gen2-iic",
> >+ "renesas,rmobile-iic";
> >+reg = <0 0xe60b 0 0x425>;
> >+interrupts = ;
> >+clocks = < CPG_MOD 926>;
> >+dmas = < 0x77>, < 0x78>,
> >+   < 0x77>, < 0x78>;
> >+dma-names = "tx", "rx", "tx", "rx";
> >+power-domains = < R8A7743_PD_ALWAYS_ON>;
> >+resets = < CPG_MOD 926>;
> 
>CPG_MOD not needed here, it's not a "clocks" prop.
> 
> [...]
> 
> MBR, Sergei
> 

Re: [PATCH] mmc: renesas_sdhi: use extra flag for CBSY usage

[Simon Horman]

On Wed, Aug 09, 2017 at 09:00:41PM +0200, Wolfram Sang wrote:
> There is one SDHI instance on Gen2 which does not have the CBSY bit.
> So, turn CBSY usage into an extra flag and set it accordingly. This has
> the additional advantage that we can also set it for other incarnations
> later.

What is the run-time effect, if any, of this change?

> Signed-off-by: Wolfram Sang 

Code looks good:

Reviewed-by: Simon Horman 

> ---
> 
> Tested on a M3-W Salvator-X and H2 Lager (with both SDHI instances). I could
> move large files around without problems. Note that on the special incarnation
> without the CBSY bit, the old code still worked, so there might be a CBSY bit.
> But it is not documented, so we better play safe.
> 
> Chris: according to the specs I have, we can enable it for RZ as well. I'll
> send a patch for that in a minute. If you could test this on top of this one,
> that would be much appreciated! Thanks.

I take it from the above you did a pass of the available documentation to
see which SoCs support this feature. If so, thanks!

>  drivers/mmc/host/renesas_sdhi_core.c  | 6 +-
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c | 3 ++-
>  drivers/mmc/host/renesas_sdhi_sys_dmac.c  | 6 --
>  include/linux/mfd/tmio.h  | 3 +++
>  4 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
> b/drivers/mmc/host/renesas_sdhi_core.c
> index a252145097d6a5..e46504edc9fcb4 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -429,7 +429,7 @@ static int renesas_sdhi_write16_hook(struct tmio_mmc_host 
> *host, int addr)
>   case CTL_TRANSACTION_CTL:
>   case CTL_DMA_ENABLE:
>   case EXT_ACC:
> - if (host->pdata->flags & TMIO_MMC_MIN_RCAR2)
> + if (host->pdata->flags & TMIO_MMC_HAVE_CBSY)
>   bit = TMIO_STAT_CMD_BUSY;
>   /* fallthrough */
>   case CTL_SD_CARD_CLK_CTL:
> @@ -589,6 +589,10 @@ int renesas_sdhi_probe(struct platform_device *pdev,
>   if (ret < 0)
>   goto efree;
>  
> + /* One Gen2 SDHI incarnation does NOT have a CBSY bit */
> + if (sd_ctrl_read16(host, CTL_VERSION) == SDHI_VER_GEN2_SDR50)
> + mmc_data->flags &= ~TMIO_MMC_HAVE_CBSY;
> +
>   /* Enable tuning iff we have an SCC and a supported mode */
>   if (of_data && of_data->scc_offset &&
>   (host->mmc->caps & MMC_CAP_UHS_SDR104 ||
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index 6717003888e292..fa4e71d3b47d47 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -72,7 +72,8 @@ static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
>  
>  static const struct renesas_sdhi_of_data of_rcar_gen3_compatible = {
>   .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
> -   TMIO_MMC_CLK_ACTUAL | TMIO_MMC_MIN_RCAR2,
> +   TMIO_MMC_CLK_ACTUAL | TMIO_MMC_HAVE_CBSY |
> +   TMIO_MMC_MIN_RCAR2,
>   .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> MMC_CAP_CMD23,
>   .bus_shift  = 2,

Keeping the above of_rcar_gen3_compatible structure in sync with the one
below may get painful at some point. Perhaps we should consider a common
location for it? (Yes, I know this is my handiwork)

> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index 718cb8a9d2ce8d..9b77f521cd2c2f 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> @@ -58,7 +58,8 @@ static struct renesas_sdhi_scc rcar_gen2_scc_taps[] = {
>  
>  static const struct renesas_sdhi_of_data of_rcar_gen2_compatible = {
>   .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
> -   TMIO_MMC_CLK_ACTUAL | TMIO_MMC_MIN_RCAR2,
> +   TMIO_MMC_CLK_ACTUAL | TMIO_MMC_HAVE_CBSY |
> +   TMIO_MMC_MIN_RCAR2,
>   .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> MMC_CAP_CMD23,
>   .dma_buswidth   = DMA_SLAVE_BUSWIDTH_4_BYTES,
> @@ -78,7 +79,8 @@ static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
>  
>  static const struct renesas_sdhi_of_data of_rcar_gen3_compatible = {
>   .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
> -   TMIO_MMC_CLK_ACTUAL | TMIO_MMC_MIN_RCAR2,
> +   TMIO_MMC_CLK_ACTUAL | TMIO_MMC_HAVE_CBSY |
> +   TMIO_MMC_MIN_RCAR2,
>   .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> MMC_CAP_CMD23,
>   .bus_shift  = 2,
> diff --git a/include/linux/mfd/tmio.h 

Re: [PATCH v2] mmc: sdhi: use maximum width for the sdbuf register

[Simon Horman]

On Wed, Aug 09, 2017 at 08:29:26PM +0200, Wolfram Sang wrote:
> Make use of the 64 bit sdbuf width on Renesas R-Car Gen3. If the
> registers are 8 byte apart, the width is also 64 bit. For all others,
> the width is 32 bit, even if the registers are only 16 bit apart.
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

> ---
> 
> Change since v1:
> * width calculation is now fully backwards compatible. If it is not 8 byte
>   apart (which is only on Gen3), we will always default to 32 as before.
>   Thanks to Biju Das and Simon Horman for the error reports!
> 
> Tested on a M3-W Salvator-X and H2 Lager (with both SDHI instances). On
> the Lager, I could reproduce the problem with the old patch. It is gone now!

Do you think there is any value in widening the test-coverage of this
change, f.e. to older SoCs?

>  drivers/mmc/host/renesas_sdhi_core.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
> b/drivers/mmc/host/renesas_sdhi_core.c
> index dd215723fa4312..a252145097d6a5 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -459,10 +459,11 @@ static int renesas_sdhi_multi_io_quirk(struct mmc_card 
> *card,
>  
>  static void renesas_sdhi_enable_dma(struct tmio_mmc_host *host, bool enable)
>  {
> - sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
> + /* Iff regs are 8 byte apart, sdbuf is 64 bit. Otherwise always 32. */
> + int width = (host->bus_shift == 2) ? 64 : 32;
>  
> - /* enable 32bit access if DMA mode if possibile */
> - renesas_sdhi_sdbuf_width(host, enable ? 32 : 16);
> + sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
> + renesas_sdhi_sdbuf_width(host, enable ? width : 16);
>  }
>  
>  int renesas_sdhi_probe(struct platform_device *pdev,
> -- 
> 2.11.0
>