[PATCH 5/5] ASoC: audio-graph-card: use asoc_simple_card_clk_xxx()

2017-06-08 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Current simple-card-utils sets asoc_simple_dai::clk via
asoc_simple_card_parse_clk().
Current simple card drivers are using it directly for
clk_enable/disable.
Encapsulation is one of simple card util's purpose.
Let's use asoc_simple_card_clk_enable/disable.

Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

 - no change

 sound/soc/generic/audio-graph-card.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/generic/audio-graph-card.c 
b/sound/soc/generic/audio-graph-card.c
index 0180b28..b5bb791 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -44,13 +44,13 @@ static int asoc_graph_card_startup(struct snd_pcm_substream 
*substream)
struct graph_dai_props *dai_props = graph_priv_to_props(priv, rtd->num);
int ret;
 
-   ret = clk_prepare_enable(dai_props->cpu_dai.clk);
+   ret = asoc_simple_card_clk_enable(_props->cpu_dai);
if (ret)
return ret;
 
-   ret = clk_prepare_enable(dai_props->codec_dai.clk);
+   ret = asoc_simple_card_clk_enable(_props->codec_dai);
if (ret)
-   clk_disable_unprepare(dai_props->cpu_dai.clk);
+   asoc_simple_card_clk_disable(_props->cpu_dai);
 
return ret;
 }
@@ -61,9 +61,9 @@ static void asoc_graph_card_shutdown(struct snd_pcm_substream 
*substream)
struct graph_card_data *priv = snd_soc_card_get_drvdata(rtd->card);
struct graph_dai_props *dai_props = graph_priv_to_props(priv, rtd->num);
 
-   clk_disable_unprepare(dai_props->cpu_dai.clk);
+   asoc_simple_card_clk_disable(_props->cpu_dai);
 
-   clk_disable_unprepare(dai_props->codec_dai.clk);
+   asoc_simple_card_clk_disable(_props->codec_dai);
 }
 
 static struct snd_soc_ops asoc_graph_card_ops = {
-- 
1.9.1



[PATCH 4/5] ASoC: audio-graph-scu-card: use asoc_simple_card_clk_xxx()

2017-06-08 Thread Kuninori Morimoto
From: Kuninori Morimoto 

Current simple-card-utils sets asoc_simple_dai::clk via
asoc_simple_card_parse_clk().
Current simple card drivers are using it directly for
clk_enable/disable.
Encapsulation is one of simple card util's purpose.
Let's use asoc_simple_card_clk_enable/disable.

Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

 - no change

 sound/soc/generic/audio-graph-scu-card.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/generic/audio-graph-scu-card.c 
b/sound/soc/generic/audio-graph-scu-card.c
index 0066102..27a261e 100644
--- a/sound/soc/generic/audio-graph-scu-card.c
+++ b/sound/soc/generic/audio-graph-scu-card.c
@@ -45,7 +45,7 @@ static int asoc_graph_card_startup(struct snd_pcm_substream 
*substream)
struct graph_card_data *priv = snd_soc_card_get_drvdata(rtd->card);
struct asoc_simple_dai *dai_props = graph_priv_to_props(priv, rtd->num);
 
-   return clk_prepare_enable(dai_props->clk);
+   return asoc_simple_card_clk_enable(dai_props);
 }
 
 static void asoc_graph_card_shutdown(struct snd_pcm_substream *substream)
@@ -54,7 +54,7 @@ static void asoc_graph_card_shutdown(struct snd_pcm_substream 
*substream)
struct graph_card_data *priv = snd_soc_card_get_drvdata(rtd->card);
struct asoc_simple_dai *dai_props = graph_priv_to_props(priv, rtd->num);
 
-   clk_disable_unprepare(dai_props->clk);
+   asoc_simple_card_clk_disable(dai_props);
 }
 
 static struct snd_soc_ops asoc_graph_card_ops = {
-- 
1.9.1



[PATCH 2/5 v2] ASoC: simple-card: use asoc_simple_card_clk_xxx()

2017-06-08 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Current simple-card-utils sets asoc_simple_dai::clk via
asoc_simple_card_parse_clk().
Current simple card drivers are using it directly for
clk_enable/disable.
Encapsulation is one of simple card util's purpose.
Let's use asoc_simple_card_clk_enable/disable.

Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

 - no change

 sound/soc/generic/simple-card.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 1039202..276607d 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -118,13 +118,13 @@ static int asoc_simple_card_startup(struct 
snd_pcm_substream *substream)
simple_priv_to_props(priv, rtd->num);
int ret;
 
-   ret = clk_prepare_enable(dai_props->cpu_dai.clk);
+   ret = asoc_simple_card_clk_enable(_props->cpu_dai);
if (ret)
return ret;
 
-   ret = clk_prepare_enable(dai_props->codec_dai.clk);
+   ret = asoc_simple_card_clk_enable(_props->codec_dai);
if (ret)
-   clk_disable_unprepare(dai_props->cpu_dai.clk);
+   asoc_simple_card_clk_disable(_props->cpu_dai);
 
return ret;
 }
@@ -136,9 +136,9 @@ static void asoc_simple_card_shutdown(struct 
snd_pcm_substream *substream)
struct simple_dai_props *dai_props =
simple_priv_to_props(priv, rtd->num);
 
-   clk_disable_unprepare(dai_props->cpu_dai.clk);
+   asoc_simple_card_clk_disable(_props->cpu_dai);
 
-   clk_disable_unprepare(dai_props->codec_dai.clk);
+   asoc_simple_card_clk_disable(_props->codec_dai);
 }
 
 static int asoc_simple_card_hw_params(struct snd_pcm_substream *substream,
-- 
1.9.1



[PATCH 1/5 v2] ASoC: simple_card_utils: add asoc_simple_card_clk_xxx()

2017-06-08 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Current simple-card-utils sets asoc_simple_dai::clk via
asoc_simple_card_parse_clk().
Current simple card drivers are using it directly for
clk_enable/disable.
Encapsulation is one of simple card util's purpose.
Let's encapsulate it.

Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

 - asoc_simple_card_clk_xxx #define -> function
 - add new asoc_simple_card_clk_register

 include/sound/simple_card_utils.h |  2 ++
 sound/soc/generic/simple-card-utils.c | 19 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/include/sound/simple_card_utils.h 
b/include/sound/simple_card_utils.h
index 108cae4..840d624 100644
--- a/include/sound/simple_card_utils.h
+++ b/include/sound/simple_card_utils.h
@@ -45,6 +45,8 @@ int asoc_simple_card_parse_clk(struct device *dev,
   struct device_node *dai_of_node,
   struct asoc_simple_dai *simple_dai,
   const char *name);
+int asoc_simple_card_clk_enable(struct asoc_simple_dai *dai);
+void asoc_simple_card_clk_disable(struct asoc_simple_dai *dai);
 
 #define asoc_simple_card_parse_cpu(node, dai_link, 
\
   list_name, cells_name, is_single_link)   
\
diff --git a/sound/soc/generic/simple-card-utils.c 
b/sound/soc/generic/simple-card-utils.c
index d9d8b8a..beb4e38 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -110,6 +110,22 @@ int asoc_simple_card_parse_card_name(struct snd_soc_card 
*card,
 }
 EXPORT_SYMBOL_GPL(asoc_simple_card_parse_card_name);
 
+static void asoc_simple_card_clk_register(struct asoc_simple_dai *dai,
+ struct clk *clk)
+{
+   dai->clk = clk;
+}
+
+int asoc_simple_card_clk_enable(struct asoc_simple_dai *dai)
+{
+   return clk_prepare_enable(dai->clk);
+}
+
+void asoc_simple_card_clk_disable(struct asoc_simple_dai *dai)
+{
+   clk_disable_unprepare(dai->clk);
+}
+
 int asoc_simple_card_parse_clk(struct device *dev,
   struct device_node *node,
   struct device_node *dai_of_node,
@@ -128,7 +144,8 @@ int asoc_simple_card_parse_clk(struct device *dev,
clk = devm_get_clk_from_child(dev, node, NULL);
if (!IS_ERR(clk)) {
simple_dai->sysclk = clk_get_rate(clk);
-   simple_dai->clk = clk;
+
+   asoc_simple_card_clk_register(simple_dai, clk);
} else if (!of_property_read_u32(node, "system-clock-frequency", )) 
{
simple_dai->sysclk = val;
} else {
-- 
1.9.1



[PATCH] ASoC: rsnd: add detail explanation of L/R conversion timing

2017-06-08 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Renesas Sound device *Hardware* L/R and Linux *Software* L/R are
inverted. Because of this background, it needs to convert L/R.
Then, DVC needs *Hardware* L/R, and Linux needs *Software* L/R.
Because Playback/Capture needs different timing, and there is no
explanation about it on source code / git log, this patch adds it.

Signed-off-by: Kuninori Morimoto 
---
 sound/soc/sh/rcar/core.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 7c68f9d..1bf261d 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -310,6 +310,24 @@ u32 rsnd_get_dalign(struct rsnd_mod *mod, struct 
rsnd_dai_stream *io)
u32 val = 0x76543210;
u32 mask = ~0;
 
+   /*
+* *Hardware* L/R and *Software* L/R are inverted.
+* We need to care about inversion timing to control
+* Playback/Capture correctly.
+* The point is [DVC] needs *Hardware* L/R, [MEM] needs *Software* L/R
+*
+* sL/R : software L/R
+* hL/R : hardware L/R
+* (*)  : conversion timing
+*
+* Playback
+*   sL/R (*) hL/R hL/R hL/R  hL/R hL/R
+*  [MEM] -> [SRC] -> [DVC] -> [CMD] -> [SSIU] -> [SSI] -> codec
+*
+* Capture
+*   hL/R hL/R  hL/R hL/R hL/R (*) sL/R
+*  codec -> [SSI] -> [SSIU] -> [SRC] -> [DVC] -> [CMD] -> [MEM]
+*/
if (rsnd_io_is_play(io)) {
struct rsnd_mod *src = rsnd_io_to_mod_src(io);
 
-- 
1.9.1



Re: [PATCH 1/5] ASoC: simple_card_utils: add asoc_simple_card_clk_enable/disable()

2017-06-08 Thread Kuninori Morimoto

Hi Mark

> > +#define asoc_simple_card_clk_enable(dai) clk_prepare_enable((dai)->clk)
> > +#define asoc_simple_card_clk_disable(dai) clk_disable_unprepare((dai)->clk)
> 
> Could we make these static inline functions instead please?  It
> shouldn't make any difference to the generated code but it's a bit more
> type safe.

OK, will do in v2

Best regards
---
Kuninori Morimoto


Re: [PATCH v4] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

2017-06-08 Thread Sakari Ailus
Hi Mauro,

On Thu, Jun 08, 2017 at 03:00:22PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed,  7 Jun 2017 10:52:07 +0100
> Kieran Bingham  escreveu:
> 
> > From: Kieran Bingham 
> > 
> > Return NULL, if a null entity is parsed for it's v4l2_subdev
> > 
> > Signed-off-by: Kieran Bingham 
> 
> Could you please improve this patch description?
> 
> I'm unsure if this is a bug fix, or some sort of feature...
> 
> On what situations would a null entity be passed to this function?

I actually proposed this patch. This change is simply for convenience ---
the caller doesn't need to make sure the subdev is non-NULL, possibly
obtained from e.g. media_entity_remote_pad() which returns NULL all links to
the pad are disabled. This is a recurring pattern, and making this change
avoids an additional check.

Having something along these lines in the patch description wouldn't hurt.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk


Re: [PATCH v4] v4l: subdev: tolerate null in media_entity_to_v4l2_subdev

2017-06-08 Thread Mauro Carvalho Chehab
Em Wed,  7 Jun 2017 10:52:07 +0100
Kieran Bingham  escreveu:

> From: Kieran Bingham 
> 
> Return NULL, if a null entity is parsed for it's v4l2_subdev
> 
> Signed-off-by: Kieran Bingham 

Could you please improve this patch description?

I'm unsure if this is a bug fix, or some sort of feature...

On what situations would a null entity be passed to this function?

Regards,
Mauro

> 
> ---
> Not sure if this patch ever made it out of my mailbox:
> 
> Here's the respin with the parameter evaluated only once.
> 
> v4:
>  - Improve macro usage to evaluate ent only once
> 
>  include/media/v4l2-subdev.h | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index a40760174797..0f92ebd2d710 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -826,8 +826,15 @@ struct v4l2_subdev {
>   struct v4l2_subdev_platform_data *pdata;
>  };
>  
> -#define media_entity_to_v4l2_subdev(ent) \
> - container_of(ent, struct v4l2_subdev, entity)
> +#define media_entity_to_v4l2_subdev(ent) \
> +({   \
> + typeof(ent) __me_sd_ent = (ent);\
> + \
> + __me_sd_ent ?   \
> + container_of(__me_sd_ent, struct v4l2_subdev, entity) : \
> + NULL;   \
> +})
> +
>  #define vdev_to_v4l2_subdev(vdev) \
>   ((struct v4l2_subdev *)video_get_drvdata(vdev))
>  



Thanks,
Mauro


Re: [PATCH 1/5] ASoC: simple_card_utils: add asoc_simple_card_clk_enable/disable()

2017-06-08 Thread Mark Brown
On Wed, Jun 07, 2017 at 12:29:05AM +, Kuninori Morimoto wrote:

> +#define asoc_simple_card_clk_enable(dai) clk_prepare_enable((dai)->clk)
> +#define asoc_simple_card_clk_disable(dai) clk_disable_unprepare((dai)->clk)

Could we make these static inline functions instead please?  It
shouldn't make any difference to the generated code but it's a bit more
type safe.


signature.asc
Description: PGP signature


Re: [PATCH] ARM: shmobile: Update R-Car Gen3 ULCB board part numbers

2017-06-08 Thread Simon Horman
On Wed, Jun 07, 2017 at 05:12:03PM -0500, Rob Herring wrote:
> On Thu, Jun 01, 2017 at 12:34:29PM +0200, Geert Uytterhoeven wrote:
> > The board part numbers for the R-Car H3 and M3 ULCB boards corresponded
> > to versions predating mass production.  Update them for mass production.
> > 
> > Note that the H3 ULCB board can be equipped with either revision ES1.1
> > or ES2.0 of the R-Car H3 SoC.  While these have different board part
> > numbers, no new compatible values are needed, as the revision can be
> > detected at runtime using the PRR register.
> > 
> > Signed-off-by: Geert Uytterhoeven 
> > ---
> > See also http://elinux.org/index.php?title=R-Car/Boards/H3SK
> > 
> >  Documentation/devicetree/bindings/arm/shmobile.txt | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Acked-by: Rob Herring 

Thanks, I have queued this up for v4.13.


Re: [PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

2017-06-08 Thread Wolfram Sang

> Btw, I'm seeing only patches 6 and 7 here at media ML (and patchwork).
> As those are trivial changes, I'll just apply what I have.

Perfect, thanks!



signature.asc
Description: PGP signature


[PATCH] arm64: dts: salvator-x: Add missing index to PWM pinctrl subnode name

2017-06-08 Thread Geert Uytterhoeven
R-Car Gen3 SoCs contain multiple PWM modules.  Hence to avoid conflicts,
pinctrl subnodes for PWM should include indices referring to their
instances.

Fixes: b33be33670217533 ("arm64: dts: salvator-x: Add panel backlight support")
Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/salvator-x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/salvator-x.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
index 937bdf8842f2e684..2f5386252aed55e8 100644
--- a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
@@ -417,7 +417,7 @@
function = "i2c2";
};
 
-   pwm1_pins: pwm {
+   pwm1_pins: pwm1 {
groups = "pwm1_a";
function = "pwm1";
};
-- 
2.7.4



Re: [PATCH v2] ARM: dts: armadillo800eva: Split LCD mux and gpio

2017-06-08 Thread Simon Horman
On Fri, Jun 02, 2017 at 08:53:26AM +0300, Laurent Pinchart wrote:
> Hi Geert,
> 
> Thank you for the patch.
> 
> On Thursday 01 Jun 2017 12:27:00 Geert Uytterhoeven wrote:
> > Configuration of the lcd0 pinmux group and GPIO hog for the external
> > GPIO mux are done using a single device node, causing the "output-high"
> > property to be applied to both.  This will fail for the pinmux group,
> > but doesn't cause any harm, as the failure is ignored silently.
> > 
> > However, after "pinctrl: sh-pfc: propagate errors on group config", the
> > failure will become fatal, leading to a broken display:
> > 
> > sh-pfc e605.pin-controller: pin_config_group_set op failed for group
> > 102 sh-pfc e605.pin-controller: Error applying setting, reverse things
> > back sh-pfc e605.pin-controller: failed to select default state
> > 
> > Move the GPIO hog to its own node to fix this.
> > 
> > Fixes: ffd2f9a5afb730b9 ("ARM: shmobile: armadillo800eva dts: Add pinctrl
> > and gpio-hog for lcdc0") Signed-off-by: Geert Uytterhoeven
> > 
> > ---
> > This is a hard dependency for "pinctrl: sh-pfc: propagate errors on
> > group config" (https://patchwork.kernel.org/patch/9186713/).
> > 
> > v2:
> >   - Keep the GPIO hog, but move it to its own node, instead of using
> > another level of subnodes.  As the GPIO hog node is not referenced from
> > a pinctrl-0 property, pinconf doesn't fail with "No pin or group
> > provided in DT node".
> 
> I like this approach better, it allows us to drive the output instead of 
> pulling it up, without requiring a full implementation of output drive 
> control 
> in the pfc driver.
> 
> Acked-by: Laurent Pinchart 

Thanks, I have queued this up as a fix for v4.12.


Re: [PATCH] arm64: defconfig: enable Simple Sound Card support

2017-06-08 Thread Simon Horman
On Tue, Jun 06, 2017 at 02:33:47AM +, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> commit 7fa72cca39a0 ("ASoC: rsnd: add HDMI output support")
> exchanged Renesas Sound driver's Kconfig selection
> from SND_SIMPLE_CARD to SND_SIMPLE_CARD_UTILS, because of this,
> defconfig doesn't select SND_SIMPLE_CARD today.
> All Renesas platform needs SND_SIMPLE_CARD, Let's select it.
> 
> Signed-off-by: Kuninori Morimoto 

Thanks Morimoto-san, applied.


[PATCH/RFC 5/5] mmc: renesas-sdhi: remove gen3 support from sysc dmac driver

2017-06-08 Thread Simon Horman
Gen3 SoCs are now supported by the internal dmac variant of the SDHI driver.
Remove them from the sys dmac variant where only PIO mode is supported.

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi_sys_dmac.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index cc3e0f94b276..1f8863e725aa 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -63,25 +63,6 @@ static const struct renesas_sdhi_of_data 
of_rcar_gen2_compatible = {
.taps_num   = ARRAY_SIZE(rcar_gen2_scc_taps),
 };
 
-/* Definitions for sampling clocks */
-static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
-   {
-   .clk_rate = 0,
-   .tap = 0x0300,
-   },
-};
-
-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,
-   .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
- MMC_CAP_CMD23,
-   .bus_shift  = 2,
-   .scc_offset = 0x1000,
-   .taps   = rcar_gen3_scc_taps,
-   .taps_num   = ARRAY_SIZE(rcar_gen3_scc_taps),
-};
-
 static const struct of_device_id renesas_sdhi_sys_dmac_of_match[] = {
{ .compatible = "renesas,sdhi-shmobile" },
{ .compatible = "renesas,sdhi-sh73a0", .data = _default_cfg, },
@@ -95,8 +76,6 @@ static const struct of_device_id 
renesas_sdhi_sys_dmac_of_match[] = {
{ .compatible = "renesas,sdhi-r8a7792", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7793", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7794", .data = 
_rcar_gen2_compatible, },
-   { .compatible = "renesas,sdhi-r8a7795", .data = 
_rcar_gen3_compatible, },
-   { .compatible = "renesas,sdhi-r8a7796", .data = 
_rcar_gen3_compatible, },
{},
 };
 MODULE_DEVICE_TABLE(of, renesas_sdhi_sys_dmac_of_match);
-- 
2.1.4



[PATCH/RFC 1/5] mmc: tmio: add max_segs and max_blk_count in tmio_mmc_data

2017-06-08 Thread Simon Horman
From: Yoshihiro Shimoda 

To change each value from related driver (e.g. sh_mobile_sdhi driver),
this patch adds these member in the struct tmio_mmc_data.

Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
 drivers/mmc/host/tmio_mmc_core.c | 6 +++---
 include/linux/mfd/tmio.h | 2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index ed4068125349..0e76e099dc7f 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1247,10 +1247,10 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 
mmc->caps |= MMC_CAP_4_BIT_DATA | pdata->capabilities;
mmc->caps2 |= pdata->capabilities2;
-   mmc->max_segs = 32;
+   mmc->max_segs = pdata->max_segs ? : 32;
mmc->max_blk_size = 512;
-   mmc->max_blk_count = (PAGE_SIZE / mmc->max_blk_size) *
-   mmc->max_segs;
+   mmc->max_blk_count = pdata->max_blk_count ? :
+   (PAGE_SIZE / mmc->max_blk_size) * mmc->max_segs;
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
mmc->max_seg_size = mmc->max_req_size;
 
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index c83c16b931a8..4e261ea94d6a 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -128,6 +128,8 @@ struct tmio_mmc_data {
unsigned intcd_gpio;
int alignment_shift;
dma_addr_t  dma_rx_offset;
+   unsigned intmax_blk_count;
+   unsigned short  max_segs;
void (*set_pwr)(struct platform_device *host, int state);
void (*set_clk_div)(struct platform_device *host, int state);
 };
-- 
2.1.4



[PATCH/RFC 2/5] mmc: sh_mobile_sdhi: set max_segs and max_blk_count values R-Car Gen3

2017-06-08 Thread Simon Horman
To avoid complicate code in own dma code for gen3, this patch
adds set max_segs to 1. Then, the tmio driver will get requests
as sg_len = 1 only.

In the performance point of view, the CONFIG_MMC_BLOCK_BOUNCE should
be set. Otherwise, mmc block layer will set 4-kbyte each as a request.

Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi.h  | 2 ++
 drivers/mmc/host/renesas_sdhi_core.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi.h b/drivers/mmc/host/renesas_sdhi.h
index eb3ea15ff92d..6f7233fe32a2 100644
--- a/drivers/mmc/host/renesas_sdhi.h
+++ b/drivers/mmc/host/renesas_sdhi.h
@@ -31,6 +31,8 @@ struct renesas_sdhi_of_data {
int scc_offset;
struct renesas_sdhi_scc *taps;
int taps_num;
+   unsigned int max_blk_count;
+   unsigned short max_segs;
 };
 
 int renesas_sdhi_probe(struct platform_device *pdev,
diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index 82150a966391..294bc9705c5f 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -522,6 +522,8 @@ int renesas_sdhi_probe(struct platform_device *pdev,
mmc_data->capabilities |= of_data->capabilities;
mmc_data->capabilities2 |= of_data->capabilities2;
mmc_data->dma_rx_offset = of_data->dma_rx_offset;
+   mmc_data->max_blk_count = of_data->max_blk_count;
+   mmc_data->max_segs = of_data->max_segs;
dma_priv->dma_buswidth = of_data->dma_buswidth;
host->bus_shift = of_data->bus_shift;
}
-- 
2.1.4



[PATCH/RFC 0/5 repost] mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC

2017-06-08 Thread Simon Horman
Hi,

this series adds support for the internal DMAC used by r8a779[56] SoCs.
This is achieved by adding a new variant of the SDHI driver for this
DMA controller with compat strings for the r8a779[56] SoCs.
Compat strings for these SoCs are also removed from the existing SYS DMAC
variant of the SDHI driver.

Based on mmc/next

Headline performance boost: 9.5MB/s -> 39.7MB/s
More run-time information below.

Simon Horman (4):
  mmc: sh_mobile_sdhi: set max_segs and max_blk_count values R-Car Gen3
  mmc: tmio: add complete to DMA ops
  mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC
  mmc: renesas-sdhi: remove gen3 support from sysc dmac driver

Yoshihiro Shimoda (1):
  mmc: tmio: add max_segs and max_blk_count in tmio_mmc_data

 drivers/mmc/host/Kconfig  |  17 ++
 drivers/mmc/host/Makefile |   8 +-
 drivers/mmc/host/renesas_sdhi.h   |   2 +
 drivers/mmc/host/renesas_sdhi_core.c  |   2 +
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 275 ++
 drivers/mmc/host/renesas_sdhi_sys_dmac.c  |  23 +--
 drivers/mmc/host/tmio_mmc.h   |   2 +
 drivers/mmc/host/tmio_mmc_core.c  |  16 +-
 include/linux/mfd/tmio.h  |   2 +
 9 files changed, 319 insertions(+), 28 deletions(-)
 create mode 100644 drivers/mmc/host/renesas_sdhi_internal_dmac.c

-- 
2.1.4

M3-W ES1.0

fd9437fc8884 (topic/sdhi-gen3-dma-2017) mmc: renesas-sdhi: remove gen3 support 
from sysc dmac driver

# dmesg | egrep '(sd|mmc)'
[1.412911] sdhci: Secure Digital Host Controller Interface driver
[1.419120] sdhci: Copyright(c) Pierre Ossman
[1.423990] renesas_sdhi_internal_dmac ee10.sd: Got CD GPIO
[1.429951] renesas_sdhi_internal_dmac ee10.sd: Got WP GPIO
[1.560503] renesas_sdhi_internal_dmac ee14.sd: mmc0 base at 0xee14 
max clock rate 200 MHz
[1.569871] renesas_sdhi_internal_dmac ee16.sd: Got CD GPIO
[1.575846] renesas_sdhi_internal_dmac ee16.sd: Got WP GPIO
[1.590584] sdhci-pltfm: SDHCI platform and OF driver helper
[1.638687] renesas_sdhi_internal_dmac ee10.sd: Got CD GPIO
[1.644661] renesas_sdhi_internal_dmac ee10.sd: Got WP GPIO
[1.772556] renesas_sdhi_internal_dmac ee10.sd: mmc1 base at 0xee10 
max clock rate 200 MHz
[1.782613] renesas_sdhi_internal_dmac ee16.sd: Got CD GPIO
[1.788580] renesas_sdhi_internal_dmac ee16.sd: Got WP GPIO
[1.842940] mmc0: new high speed MMC card at address 0001
[1.852857] mmcblk0: mmc0:0001 eMMC   28.8 GiB
[1.857624] mmcblk0boot0: mmc0:0001 eMMC   partition 1 4.00 MiB
[1.867734] mmcblk0boot1: mmc0:0001 eMMC   partition 2 4.00 MiB
[1.877858] mmcblk0rpmb: mmc0:0001 eMMC   partition 3 4.00 MiB
[1.887028]  mmcblk0: p1
[1.916589] renesas_sdhi_internal_dmac ee16.sd: mmc2 base at 0xee16 
max clock rate 200 MHz
[2.060534] mmc1: new ultra high speed SDR50 SDHC card at address e624
[2.071600] mmcblk1: mmc1:e624 SU08G 7.40 GiB
[2.086875]  mmcblk1: p1
[2.260532] mmc2: new ultra high speed SDR50 SDHC card at address 0001
[2.267407] mmcblk2: mmc2:0001 0 29.8 GiB
[2.281572]  mmcblk2: p1

# grep sd /proc/interrupts
100:  24972  0 GIC-0 197 Level ee10.sd
101:604  0 GIC-0 199 Level ee14.sd
102:  24980  0 GIC-0 200 Level ee16.sd
178:  0  0  e6053000.gpio  12 Edge  ee10.sd cd
197:  0  0  e6054000.gpio  15 Edge  ee16.sd cd

# cat /sys/devices/platform/soc/ee10.sd/mmc_host/mmc1/mmc1:e624
035344535530384780b1b8a11200d300
# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=512 iflag=direct
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 13.5376 s, 39.7 MB/s

# cat /sys/devices/platform/soc/ee16.sd/mmc_host/mmc2/mmc2:0001
1b534d3030303030103916141700f600
# dd if=/dev/mmcblk2 of=/dev/null bs=1M count=512 iflag=direct
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 17.5562 s, 30.6 MB/s

# grep sd /proc/interrupts
100:  49548  0 GIC-0 197 Level ee10.sd
101:604  0 GIC-0 199 Level ee14.sd
102:  49556  0 GIC-0 200 Level ee16.sd
178:  0  0  e6053000.gpio  12 Edge  ee10.sd cd
197:  0  0  e6054000.gpio  15 Edge  ee16.sd cd

---

6e75316c15df (mmc/next) mmc: tmio: make sure SDIO gets reinitialized after 
resume

# dmesg | egrep '(sd|mmc)'
[1.428112] sdhci: Secure Digital Host Controller Interface driver
[1.434620] sdhci: Copyright(c) Pierre Ossman
[1.439831] sh_mobile_sdhi ee10.sd: Got CD GPIO
[1.444764] sh_mobile_sdhi ee10.sd: Got WP GPIO
[1.571160] sh_mobile_sdhi ee14.sd: mmc0 base at 0xee14 max clock 
rate 200 MHz
[1.579496] sh_mobile_sdhi ee16.sd: Got CD GPIO
[1.584434] sh_mobile_sdhi ee16.sd: Got WP 

Re: [PATCH/RFC 0/5] mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC

2017-06-08 Thread Simon Horman
On Thu, Jun 08, 2017 at 03:09:21PM +0200, Simon Horman wrote:
> Hi,
> 
> this series adds support for the internal DMAC used by r8a779[56] SoCs.
> This is achieved by adding a new variant of the SDHI driver for this
> DMA controller with compat strings for the r8a779[56] SoCs.
> Compat strings for these SoCs are also removed from the existing SYS DMAC
> variant of the SDHI driver.

Sorry, I managed to post duplicate patches in this series.
I will repost.


[PATCH/RFC 5/5] mmc: renesas-sdhi: remove gen3 support from sysc dmac driver

2017-06-08 Thread Simon Horman
Gen3 SoCs are now supported by the internal dmac variant of the SDHI driver.
Remove them from the sys dmac variant where only PIO mode is supported.

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi_sys_dmac.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index cc3e0f94b276..1f8863e725aa 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -63,25 +63,6 @@ static const struct renesas_sdhi_of_data 
of_rcar_gen2_compatible = {
.taps_num   = ARRAY_SIZE(rcar_gen2_scc_taps),
 };
 
-/* Definitions for sampling clocks */
-static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
-   {
-   .clk_rate = 0,
-   .tap = 0x0300,
-   },
-};
-
-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,
-   .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
- MMC_CAP_CMD23,
-   .bus_shift  = 2,
-   .scc_offset = 0x1000,
-   .taps   = rcar_gen3_scc_taps,
-   .taps_num   = ARRAY_SIZE(rcar_gen3_scc_taps),
-};
-
 static const struct of_device_id renesas_sdhi_sys_dmac_of_match[] = {
{ .compatible = "renesas,sdhi-shmobile" },
{ .compatible = "renesas,sdhi-sh73a0", .data = _default_cfg, },
@@ -95,8 +76,6 @@ static const struct of_device_id 
renesas_sdhi_sys_dmac_of_match[] = {
{ .compatible = "renesas,sdhi-r8a7792", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7793", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7794", .data = 
_rcar_gen2_compatible, },
-   { .compatible = "renesas,sdhi-r8a7795", .data = 
_rcar_gen3_compatible, },
-   { .compatible = "renesas,sdhi-r8a7796", .data = 
_rcar_gen3_compatible, },
{},
 };
 MODULE_DEVICE_TABLE(of, renesas_sdhi_sys_dmac_of_match);
-- 
2.1.4



[PATCH/RFC 3/5] mmc: sh_mobile_sdhi: add some SoC specific data for R-Car Gen3

2017-06-08 Thread Simon Horman
To avoid complicate code in own dma code for gen3, this patch
adds set max_segs to 1. Then, the tmio driver will get requests
as sg_len = 1 only.

In the performance point of view, the CONFIG_MMC_BLOCK_BOUNCE should
be set. Otherwise, mmc block layer will set 4-kbyte each as a request.

Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi.h  | 2 ++
 drivers/mmc/host/renesas_sdhi_core.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi.h b/drivers/mmc/host/renesas_sdhi.h
index eb3ea15ff92d..6f7233fe32a2 100644
--- a/drivers/mmc/host/renesas_sdhi.h
+++ b/drivers/mmc/host/renesas_sdhi.h
@@ -31,6 +31,8 @@ struct renesas_sdhi_of_data {
int scc_offset;
struct renesas_sdhi_scc *taps;
int taps_num;
+   unsigned int max_blk_count;
+   unsigned short max_segs;
 };
 
 int renesas_sdhi_probe(struct platform_device *pdev,
diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index 82150a966391..294bc9705c5f 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -522,6 +522,8 @@ int renesas_sdhi_probe(struct platform_device *pdev,
mmc_data->capabilities |= of_data->capabilities;
mmc_data->capabilities2 |= of_data->capabilities2;
mmc_data->dma_rx_offset = of_data->dma_rx_offset;
+   mmc_data->max_blk_count = of_data->max_blk_count;
+   mmc_data->max_segs = of_data->max_segs;
dma_priv->dma_buswidth = of_data->dma_buswidth;
host->bus_shift = of_data->bus_shift;
}
-- 
2.1.4



[PATCH/RFC 3/5] mmc: tmio: add complete to DMA ops

2017-06-08 Thread Simon Horman
Add complete to DMA ops to allow DMAC implementation dependent
handling of DMA completion.

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/tmio_mmc.h  |  1 +
 drivers/mmc/host/tmio_mmc_core.c | 10 --
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 9c94b6eb9b49..82725f9de359 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -121,6 +121,7 @@ struct tmio_mmc_dma_ops {
struct tmio_mmc_data *pdata);
void (*release)(struct tmio_mmc_host *host);
void (*abort)(struct tmio_mmc_host *host);
+   void (*complete)(struct tmio_mmc_host *host);
 };
 
 struct tmio_mmc_host {
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 0e76e099dc7f..26fe9bb64849 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -86,6 +86,12 @@ static inline void tmio_mmc_abort_dma(struct tmio_mmc_host 
*host)
host->dma_ops->abort(host);
 }
 
+static inline void tmio_mmc_complete_dma(struct tmio_mmc_host *host)
+{
+   if (host->dma_ops)
+   host->dma_ops->complete(host);
+}
+
 void tmio_mmc_enable_mmc_irqs(struct tmio_mmc_host *host, u32 i)
 {
host->sdcard_irq_mask &= ~(i & TMIO_MASK_IRQ);
@@ -604,11 +610,11 @@ static void tmio_mmc_data_irq(struct tmio_mmc_host *host, 
unsigned int stat)
 
if (done) {
tmio_mmc_disable_mmc_irqs(host, TMIO_STAT_DATAEND);
-   complete(>dma_dataend);
+   tmio_mmc_complete_dma(host);
}
} else if (host->chan_rx && (data->flags & MMC_DATA_READ) && 
!host->force_pio) {
tmio_mmc_disable_mmc_irqs(host, TMIO_STAT_DATAEND);
-   complete(>dma_dataend);
+   tmio_mmc_complete_dma(host);
} else {
tmio_mmc_do_data_irq(host);
tmio_mmc_disable_mmc_irqs(host, TMIO_MASK_READOP | 
TMIO_MASK_WRITEOP);
-- 
2.1.4



[PATCH/RFC 4/5] mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC

2017-06-08 Thread Simon Horman
R-Car Gen3 has a dedicated DMA controller for SDHI module. Since
the DMAC is in a part of SDHI module and is not suitable as dmaengine,
this patch adds a different code as tmio_mmc_dma_gen3.c.

Clearing of DM_CM_INFO1 after DMA thanks to Dirk Behme

Cc: Dirk Behme 
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Ai Kyuse 
---
 drivers/mmc/host/Kconfig  |  17 ++
 drivers/mmc/host/Makefile |   8 +-
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 275 ++
 drivers/mmc/host/renesas_sdhi_sys_dmac.c  |   2 +-
 drivers/mmc/host/tmio_mmc.h   |   1 +
 5 files changed, 301 insertions(+), 2 deletions(-)
 create mode 100644 drivers/mmc/host/renesas_sdhi_internal_dmac.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 5755b69f2f72..e813d420d7b3 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -575,10 +575,27 @@ config MMC_SDHI
depends on SUPERH || ARM || ARM64
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
select MMC_TMIO_CORE
+   select MMC_SDHI_SYS_DMAC if (SUPERH || ARM)
+   select MMC_SDHI_INTERNAL_DMAC if ARM64
help
  This provides support for the SDHI SD/SDIO controller found in
  Renesas SuperH, ARM and ARM64 based SoCs
 
+config MMC_SDHI_SYS_DMAC
+   tristate "DMA support use of SYS DMAC with SDHI SD/SDIO controller"
+   depends on MMC_SDHI
+   help
+ This provides DMA support for the SDHI SD/SDIO controller
+ found in SuperH and Renesas ARM based SoCs.
+
+config MMC_SDHI_INTERNAL_DMAC
+   tristate "DMA support for Internal DMAC with SDHI SD/SDIO controller"
+   depends on ARM64 || COMPILE_TEST
+   depends on MMC_SDHI
+   help
+ This provides DMA support for the SDHI SD/SDIO controller
+ found in Renesas arm64 based SoCs.
+
 config MMC_CB710
tristate "ENE CB710 MMC/SD Interface support"
depends on PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 4d4547116311..8c46766c000c 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -36,7 +36,13 @@ obj-$(CONFIG_MMC_S3C)+= s3cmci.o
 obj-$(CONFIG_MMC_SDRICOH_CS)   += sdricoh_cs.o
 obj-$(CONFIG_MMC_TMIO) += tmio_mmc.o
 obj-$(CONFIG_MMC_TMIO_CORE)+= tmio_mmc_core.o
-obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_core.o renesas_sdhi_sys_dmac.o
+obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_core.o
+ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_SYS_DMAC)),y)
+obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_sys_dmac.o
+endif
+ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_INTERNAL_DMAC)),y)
+obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_internal_dmac.o
+endif
 obj-$(CONFIG_MMC_CB710)+= cb710-mmc.o
 obj-$(CONFIG_MMC_VIA_SDMMC)+= via-sdmmc.o
 obj-$(CONFIG_SDH_BFIN) += bfin_sdh.o
diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
new file mode 100644
index ..a16b616a2c96
--- /dev/null
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -0,0 +1,275 @@
+/*
+ * DMA support for Internal DMAC with SDHI SD/SDIO controller
+ *
+ * Copyright (C) 2016-17 Renesas Electronics Corporation
+ * Copyright (C) 2016-17 Horms Solutions, Simon Horman
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "renesas_sdhi.h"
+#include "tmio_mmc.h"
+
+#define DM_CM_DTRAN_MODE   0x820
+#define DM_CM_DTRAN_CTRL   0x828
+#define DM_CM_RST  0x830
+#define DM_CM_INFO10x840
+#define DM_CM_INFO1_MASK   0x848
+#define DM_CM_INFO20x850
+#define DM_CM_INFO2_MASK   0x858
+#define DM_DTRAN_ADDR  0x880
+
+/* DM_CM_DTRAN_MODE */
+#define DTRAN_MODE_CH_NUM_CH0  0   /* "downstream" = for write commands */
+#define DTRAN_MODE_CH_NUM_CH1  BIT(16) /* "uptream" = for read commands */
+#define DTRAN_MODE_BUS_WID_TH  (BIT(5) | BIT(4))
+#define DTRAN_MODE_ADDR_MODE   BIT(0)  /* 1 = Increment address */
+
+/* DM_CM_DTRAN_CTRL */
+#define DTRAN_CTRL_DM_STARTBIT(0)
+
+/* DM_CM_RST */
+#define RST_DTRANRST1  BIT(9)
+#define RST_DTRANRST0  BIT(8)
+#define RST_RESERVED_BITS  GENMASK_ULL(32, 0)
+
+/* DM_CM_INFO1 and DM_CM_INFO1_MASK */
+#define INFO1_CLEAR0
+#define INFO1_DTRANEND1BIT(17)
+#define INFO1_DTRANEND0BIT(16)
+
+/* DM_CM_INFO2 and DM_CM_INFO2_MASK */
+#define INFO2_DTRANERR1BIT(17)
+#define INFO2_DTRANERR0BIT(16)
+
+/*
+ * Specification of this driver:
+ * - host->chan_{rx,tx} will be used as a flag of enabling/disabling the dma
+ 

[PATCH/RFC 0/5] mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC

2017-06-08 Thread Simon Horman
Hi,

this series adds support for the internal DMAC used by r8a779[56] SoCs.
This is achieved by adding a new variant of the SDHI driver for this
DMA controller with compat strings for the r8a779[56] SoCs.
Compat strings for these SoCs are also removed from the existing SYS DMAC
variant of the SDHI driver.

Based on mmc/next

Headline performance boost: 9.5MB/s -> 39.7MB/s
More run-time information below.

Simon Horman (4):
  mmc: sh_mobile_sdhi: set max_segs and max_blk_count values R-Car Gen3
  mmc: tmio: add complete to DMA ops
  mmc: renesas_sdhi: add support for R-Car Gen3 SDHI DMAC
  mmc: renesas-sdhi: remove gen3 support from sysc dmac driver

Yoshihiro Shimoda (1):
  mmc: tmio: add max_segs and max_blk_count in tmio_mmc_data

 drivers/mmc/host/Kconfig  |  17 ++
 drivers/mmc/host/Makefile |   8 +-
 drivers/mmc/host/renesas_sdhi.h   |   2 +
 drivers/mmc/host/renesas_sdhi_core.c  |   2 +
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 275 ++
 drivers/mmc/host/renesas_sdhi_sys_dmac.c  |  23 +--
 drivers/mmc/host/tmio_mmc.h   |   2 +
 drivers/mmc/host/tmio_mmc_core.c  |  16 +-
 include/linux/mfd/tmio.h  |   2 +
 9 files changed, 319 insertions(+), 28 deletions(-)
 create mode 100644 drivers/mmc/host/renesas_sdhi_internal_dmac.c

-- 
2.1.4

M3-W ES1.0

fd9437fc8884 (topic/sdhi-gen3-dma-2017) mmc: renesas-sdhi: remove gen3 support 
from sysc dmac driver

# dmesg | egrep '(sd|mmc)'
[1.412911] sdhci: Secure Digital Host Controller Interface driver
[1.419120] sdhci: Copyright(c) Pierre Ossman
[1.423990] renesas_sdhi_internal_dmac ee10.sd: Got CD GPIO
[1.429951] renesas_sdhi_internal_dmac ee10.sd: Got WP GPIO
[1.560503] renesas_sdhi_internal_dmac ee14.sd: mmc0 base at 0xee14 
max clock rate 200 MHz
[1.569871] renesas_sdhi_internal_dmac ee16.sd: Got CD GPIO
[1.575846] renesas_sdhi_internal_dmac ee16.sd: Got WP GPIO
[1.590584] sdhci-pltfm: SDHCI platform and OF driver helper
[1.638687] renesas_sdhi_internal_dmac ee10.sd: Got CD GPIO
[1.644661] renesas_sdhi_internal_dmac ee10.sd: Got WP GPIO
[1.772556] renesas_sdhi_internal_dmac ee10.sd: mmc1 base at 0xee10 
max clock rate 200 MHz
[1.782613] renesas_sdhi_internal_dmac ee16.sd: Got CD GPIO
[1.788580] renesas_sdhi_internal_dmac ee16.sd: Got WP GPIO
[1.842940] mmc0: new high speed MMC card at address 0001
[1.852857] mmcblk0: mmc0:0001 eMMC   28.8 GiB
[1.857624] mmcblk0boot0: mmc0:0001 eMMC   partition 1 4.00 MiB
[1.867734] mmcblk0boot1: mmc0:0001 eMMC   partition 2 4.00 MiB
[1.877858] mmcblk0rpmb: mmc0:0001 eMMC   partition 3 4.00 MiB
[1.887028]  mmcblk0: p1
[1.916589] renesas_sdhi_internal_dmac ee16.sd: mmc2 base at 0xee16 
max clock rate 200 MHz
[2.060534] mmc1: new ultra high speed SDR50 SDHC card at address e624
[2.071600] mmcblk1: mmc1:e624 SU08G 7.40 GiB
[2.086875]  mmcblk1: p1
[2.260532] mmc2: new ultra high speed SDR50 SDHC card at address 0001
[2.267407] mmcblk2: mmc2:0001 0 29.8 GiB
[2.281572]  mmcblk2: p1

# grep sd /proc/interrupts
100:  24972  0 GIC-0 197 Level ee10.sd
101:604  0 GIC-0 199 Level ee14.sd
102:  24980  0 GIC-0 200 Level ee16.sd
178:  0  0  e6053000.gpio  12 Edge  ee10.sd cd
197:  0  0  e6054000.gpio  15 Edge  ee16.sd cd

# cat /sys/devices/platform/soc/ee10.sd/mmc_host/mmc1/mmc1:e624
035344535530384780b1b8a11200d300
# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=512 iflag=direct
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 13.5376 s, 39.7 MB/s

# cat /sys/devices/platform/soc/ee16.sd/mmc_host/mmc2/mmc2:0001
1b534d3030303030103916141700f600
# dd if=/dev/mmcblk2 of=/dev/null bs=1M count=512 iflag=direct
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 17.5562 s, 30.6 MB/s

# grep sd /proc/interrupts
100:  49548  0 GIC-0 197 Level ee10.sd
101:604  0 GIC-0 199 Level ee14.sd
102:  49556  0 GIC-0 200 Level ee16.sd
178:  0  0  e6053000.gpio  12 Edge  ee10.sd cd
197:  0  0  e6054000.gpio  15 Edge  ee16.sd cd

---

6e75316c15df (mmc/next) mmc: tmio: make sure SDIO gets reinitialized after 
resume

# dmesg | egrep '(sd|mmc)'
[1.428112] sdhci: Secure Digital Host Controller Interface driver
[1.434620] sdhci: Copyright(c) Pierre Ossman
[1.439831] sh_mobile_sdhi ee10.sd: Got CD GPIO
[1.444764] sh_mobile_sdhi ee10.sd: Got WP GPIO
[1.571160] sh_mobile_sdhi ee14.sd: mmc0 base at 0xee14 max clock 
rate 200 MHz
[1.579496] sh_mobile_sdhi ee16.sd: Got CD GPIO
[1.584434] sh_mobile_sdhi ee16.sd: Got WP 

[PATCH/RFC 2/5] mmc: sh_mobile_sdhi: set max_segs and max_blk_count values R-Car Gen3

2017-06-08 Thread Simon Horman
To avoid complicate code in own dma code for gen3, this patch
adds set max_segs to 1. Then, the tmio driver will get requests
as sg_len = 1 only.

In the performance point of view, the CONFIG_MMC_BLOCK_BOUNCE should
be set. Otherwise, mmc block layer will set 4-kbyte each as a request.

Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
 drivers/mmc/host/renesas_sdhi.h  | 2 ++
 drivers/mmc/host/renesas_sdhi_core.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi.h b/drivers/mmc/host/renesas_sdhi.h
index eb3ea15ff92d..6f7233fe32a2 100644
--- a/drivers/mmc/host/renesas_sdhi.h
+++ b/drivers/mmc/host/renesas_sdhi.h
@@ -31,6 +31,8 @@ struct renesas_sdhi_of_data {
int scc_offset;
struct renesas_sdhi_scc *taps;
int taps_num;
+   unsigned int max_blk_count;
+   unsigned short max_segs;
 };
 
 int renesas_sdhi_probe(struct platform_device *pdev,
diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index 82150a966391..294bc9705c5f 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -522,6 +522,8 @@ int renesas_sdhi_probe(struct platform_device *pdev,
mmc_data->capabilities |= of_data->capabilities;
mmc_data->capabilities2 |= of_data->capabilities2;
mmc_data->dma_rx_offset = of_data->dma_rx_offset;
+   mmc_data->max_blk_count = of_data->max_blk_count;
+   mmc_data->max_segs = of_data->max_segs;
dma_priv->dma_buswidth = of_data->dma_buswidth;
host->bus_shift = of_data->bus_shift;
}
-- 
2.1.4



[PATCH/RFC 1/5] mmc: tmio: add max_segs and max_blk_count in tmio_mmc_data

2017-06-08 Thread Simon Horman
From: Yoshihiro Shimoda 

To change each value from related driver (e.g. sh_mobile_sdhi driver),
this patch adds these member in the struct tmio_mmc_data.

Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
 drivers/mmc/host/tmio_mmc_core.c | 6 +++---
 include/linux/mfd/tmio.h | 2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index ed4068125349..0e76e099dc7f 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1247,10 +1247,10 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 
mmc->caps |= MMC_CAP_4_BIT_DATA | pdata->capabilities;
mmc->caps2 |= pdata->capabilities2;
-   mmc->max_segs = 32;
+   mmc->max_segs = pdata->max_segs ? : 32;
mmc->max_blk_size = 512;
-   mmc->max_blk_count = (PAGE_SIZE / mmc->max_blk_size) *
-   mmc->max_segs;
+   mmc->max_blk_count = pdata->max_blk_count ? :
+   (PAGE_SIZE / mmc->max_blk_size) * mmc->max_segs;
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
mmc->max_seg_size = mmc->max_req_size;
 
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index c83c16b931a8..4e261ea94d6a 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -128,6 +128,8 @@ struct tmio_mmc_data {
unsigned intcd_gpio;
int alignment_shift;
dma_addr_t  dma_rx_offset;
+   unsigned intmax_blk_count;
+   unsigned short  max_segs;
void (*set_pwr)(struct platform_device *host, int state);
void (*set_clk_div)(struct platform_device *host, int state);
 };
-- 
2.1.4



[PATCH/RFC 2/5] mmc: tmio: add complete to DMA ops

2017-06-08 Thread Simon Horman
Add complete to DMA ops to allow DMAC implementation dependent
handling of DMA completion.

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/tmio_mmc.h  |  1 +
 drivers/mmc/host/tmio_mmc_core.c | 10 --
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 9c94b6eb9b49..82725f9de359 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -121,6 +121,7 @@ struct tmio_mmc_dma_ops {
struct tmio_mmc_data *pdata);
void (*release)(struct tmio_mmc_host *host);
void (*abort)(struct tmio_mmc_host *host);
+   void (*complete)(struct tmio_mmc_host *host);
 };
 
 struct tmio_mmc_host {
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 0e76e099dc7f..26fe9bb64849 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -86,6 +86,12 @@ static inline void tmio_mmc_abort_dma(struct tmio_mmc_host 
*host)
host->dma_ops->abort(host);
 }
 
+static inline void tmio_mmc_complete_dma(struct tmio_mmc_host *host)
+{
+   if (host->dma_ops)
+   host->dma_ops->complete(host);
+}
+
 void tmio_mmc_enable_mmc_irqs(struct tmio_mmc_host *host, u32 i)
 {
host->sdcard_irq_mask &= ~(i & TMIO_MASK_IRQ);
@@ -604,11 +610,11 @@ static void tmio_mmc_data_irq(struct tmio_mmc_host *host, 
unsigned int stat)
 
if (done) {
tmio_mmc_disable_mmc_irqs(host, TMIO_STAT_DATAEND);
-   complete(>dma_dataend);
+   tmio_mmc_complete_dma(host);
}
} else if (host->chan_rx && (data->flags & MMC_DATA_READ) && 
!host->force_pio) {
tmio_mmc_disable_mmc_irqs(host, TMIO_STAT_DATAEND);
-   complete(>dma_dataend);
+   tmio_mmc_complete_dma(host);
} else {
tmio_mmc_do_data_irq(host);
tmio_mmc_disable_mmc_irqs(host, TMIO_MASK_READOP | 
TMIO_MASK_WRITEOP);
-- 
2.1.4



Re: [PATCH v2 0/3] Add R8A7743/SK-RZG1M PFC support

2017-06-08 Thread Sergei Shtylyov

Hello!

On 06/07/2017 08:52 PM, Geert Uytterhoeven wrote:


   Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20170420-v4.11-rc7' tag.  We're adding the R8A7743 PFC
node
and then describing the pins for SCIF0 and Ether devices declared
earlier.
These patches depend on the R8A7743 PFC suport in order to work properly.



Thanks. I have marked these as deferred pending acceptance of the PFC
driver changes. Please repost or otherwise let me know when dependency
is satisfied.


   FYI, Linus W. has pulled the R8A774x PFC patches for 4.13:

https://www.spinics.net/lists/linux-renesas-soc/msg14824.html


But Simon has to wait for v4.13-rc1 to apply the DTS parts, to avoid
regressions in renesas/devel.


   Indeed, now that pinctrl_bind_pins() causes really_probe() to fail!
The 1st patch in the series should be safe to apply still...


Gr{oetje,eeting}s,

Geert


MBR, Sergei



Re: [PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

2017-06-08 Thread Mauro Carvalho Chehab
Em Mon, 29 May 2017 14:02:02 +0200
Wolfram Sang  escreveu:

> >Why "soc_camera:" in the subject?  
> 
> I used 'git log $file' and copied the most recent entry. Do I need to
> resend?
> 

No need to resend. I'll fix it when applying the patch.

Btw, I'm seeing only patches 6 and 7 here at media ML (and patchwork).
As those are trivial changes, I'll just apply what I have.

Thanks,
Mauro


RE: [PATCH v6 3/7] media: i2c: max2175: Add MAX2175 support

2017-06-08 Thread Ramesh Shanmugasundaram

> Em Thu, 8 Jun 2017 09:42:43 +
> Ramesh Shanmugasundaram  escreveu:
> 
> > > Subject: Re: [PATCH v6 3/7] media: i2c: max2175: Add MAX2175 support
> > >
> > > Em Wed, 31 May 2017 09:44:53 +0100
> > > Ramesh Shanmugasundaram 
> escreveu:
> > >
> > > > +++ b/Documentation/media/v4l-drivers/max2175.rst
> > > > @@ -0,0 +1,60 @@
> > > > +Maxim Integrated MAX2175 RF to bits tuner driver
> > > > +
> > > > +
> > > > +The MAX2175 driver implements the following driver-specific
> controls:
> > > > +
> > > > +``V4L2_CID_MAX2175_I2S_ENABLE``
> > > > +---
> > > > +Enable/Disable I2S output of the tuner.
> > > > +
> > > > +.. flat-table::
> > > > +:header-rows:  0
> > > > +:stub-columns: 0
> > > > +:widths:   1 4
> > > > +
> > > > +* - ``(0)``
> > > > +  - I2S output is disabled.
> > > > +* - ``(1)``
> > > > +  - I2S output is enabled.
> > >
> > > Hmm... There are other drivers at the subsystem that use I2S (for
> > > audio - not for SDR - but I guess the issue is similar).
> > >
> > > On such drivers, the bridge driver controls it directly, being sure
> > > that I2S is enabled when it is expecting some data coming from the I2S
> bus.
> > >
> > > On some drivers, there are both I2S and A/D inputs at the bridge
> chipset.
> > > On such drivers, enabling/disabling I2S is done via VIDIOC_S_INPUT
> > > (and optionally via ALSA mixer), being transparent to the user if
> > > the stream comes from a tuner via I2S or from a directly connected A/D
> input.
> > >
> > > I don't think it is a good idea to enable it via a control, as, if
> > > the bridge driver is expecting data via I2S, disabling it will cause
> > > timeouts at the videobuf handling.
> >
> > The MAX2175 device is exposed as a v4l2 subdev with tuner ops and can
> interface with an SDR device. When the tuner is configured, the I2S output
> is enabled by default. From an independent tuner device perspective, this
> default behaviour is enough and this control may not be needed/used.
> >
> > However, for the use case here, the R-Car DRIF device acts as the main
> SDR device and the Maxim MAX2175 provides a sub-dev interface with tuner
> ops.
> >
> > +-++-+
> > | |-SCK--->|CLK  |
> > |   Master|-SS>|SYNC  DRIFn (slave)  |
> > |  (MAX2175)  |-SD0--->|D0   |
> > | |-SD1--->|D1   |
> > +-++-+
> >
> > The DRIF device design is such that it involves separate register writes
> to enable Rx on each of the data line. To keep both the data lines in sync
> it expects the master device to enable output after both the data line Rx
> are enabled.
> >
> > This level of control is exposed as a feature in the MAX2175 using this
> control. When interfaced with DRIF this control is used to achieve the
> desired functionality. When not interfaced with DRIF, the MAX2175 default
> behaviour does not have to change because of DRIF and hence this I2S
> control may be unused. Like MAX2175, DRIF is also an independent device
> and can interface with a different third party tuner.
> >
> > Hence, this I2S enable/disable is exposed as a user control. The end
> user application (knowing both these devices) is expected to use these
> controls appropriately. Please let me know if I need to explain anything
> in further detail.
> 
> 
> The usecase is clear. That's exactly what other drivers with I2S do,
> except that, on those other drivers, they pass I2S control info via
> platform_data (they're not platform drivers).
> 
> With those drivers, generic applications work as-is via the standard
> video, radio or sdr devnodes, without knowing about I2S.
> 
> The main difference here is that you're requiring an specialized
> application for this device to work, 

Specialized application may be needed for this specific combination of devices 
(DRIF + MAX2175) only. For MAX2175 alone, a generic application itself would be 
enough. The MAX2175 will have I2S output enabled by default and the SDR device 
have to just enable/disable its own RX during .start_streaming/.stop_streaming.

as a generic one won't be aware of
> this device-specific control, and may end by exposing this "internal"
> control to the end user. That is OK for embedded usage, but, as soon as
> this is used on some non-embedded usecase (with is likely, as there are
> several PC consumer products using other chips from Maxim), we'll have
> problems.
> 
> I guess the solution here is to make such control visible only via the
> subdev interface.
> 

Did you mean using v4l2_subdev_tuner_ops? It does not have a method as of today 
to support this. The video, audio subdev ops supports s_stream method. 

Re: [PATCH v6 3/7] media: i2c: max2175: Add MAX2175 support

2017-06-08 Thread Mauro Carvalho Chehab
Em Thu, 8 Jun 2017 09:42:43 +
Ramesh Shanmugasundaram  escreveu:

> > Subject: Re: [PATCH v6 3/7] media: i2c: max2175: Add MAX2175 support
> > 
> > Em Wed, 31 May 2017 09:44:53 +0100
> > Ramesh Shanmugasundaram  escreveu:
> >   
> > > +++ b/Documentation/media/v4l-drivers/max2175.rst
> > > @@ -0,0 +1,60 @@
> > > +Maxim Integrated MAX2175 RF to bits tuner driver
> > > +
> > > +
> > > +The MAX2175 driver implements the following driver-specific controls:
> > > +
> > > +``V4L2_CID_MAX2175_I2S_ENABLE``
> > > +---
> > > +Enable/Disable I2S output of the tuner.
> > > +
> > > +.. flat-table::
> > > +:header-rows:  0
> > > +:stub-columns: 0
> > > +:widths:   1 4
> > > +
> > > +* - ``(0)``
> > > +  - I2S output is disabled.
> > > +* - ``(1)``
> > > +  - I2S output is enabled.  
> > 
> > Hmm... There are other drivers at the subsystem that use I2S (for audio -
> > not for SDR - but I guess the issue is similar).
> > 
> > On such drivers, the bridge driver controls it directly, being sure that
> > I2S is enabled when it is expecting some data coming from the I2S bus.
> > 
> > On some drivers, there are both I2S and A/D inputs at the bridge chipset.
> > On such drivers, enabling/disabling I2S is done via VIDIOC_S_INPUT (and
> > optionally via ALSA mixer), being transparent to the user if the stream
> > comes from a tuner via I2S or from a directly connected A/D input.
> > 
> > I don't think it is a good idea to enable it via a control, as, if the
> > bridge driver is expecting data via I2S, disabling it will cause timeouts
> > at the videobuf handling.  
> 
> The MAX2175 device is exposed as a v4l2 subdev with tuner ops and can 
> interface with an SDR device. When the tuner is configured, the I2S output is 
> enabled by default. From an independent tuner device perspective, this 
> default behaviour is enough and this control may not be needed/used.
> 
> However, for the use case here, the R-Car DRIF device acts as the main SDR 
> device and the Maxim MAX2175 provides a sub-dev interface with tuner ops.
> 
> +-++-+
> | |-SCK--->|CLK  |   
> |   Master|-SS>|SYNC  DRIFn (slave)  |
> |  (MAX2175)  |-SD0--->|D0   |   
> | |-SD1--->|D1   |   
> +-++-+
> 
> The DRIF device design is such that it involves separate register writes to 
> enable Rx on each of the data line. To keep both the data lines in sync it 
> expects the master device to enable output after both the data line Rx are 
> enabled.
> 
> This level of control is exposed as a feature in the MAX2175 using this 
> control. When interfaced with DRIF this control is used to achieve the 
> desired functionality. When not interfaced with DRIF, the MAX2175 default 
> behaviour does not have to change because of DRIF and hence this I2S control 
> may be unused. Like MAX2175, DRIF is also an independent device and can 
> interface with a different third party tuner. 
> 
> Hence, this I2S enable/disable is exposed as a user control. The end user 
> application (knowing both these devices) is expected to use these controls 
> appropriately. Please let me know if I need to explain anything in further 
> detail.


The usecase is clear. That's exactly what other drivers with I2S do,
except that, on those other drivers, they pass I2S control info via
platform_data (they're not platform drivers).

With those drivers, generic applications work as-is via the standard
video, radio or sdr devnodes, without knowing about I2S.

The main difference here is that you're requiring an specialized
application for this device to work, as a generic one won't be
aware of this device-specific control, and may end by exposing this
"internal" control to the end user. That is OK for embedded usage,
but, as soon as this is used on some non-embedded usecase (with
is likely, as there are several PC consumer products using other
chips from Maxim), we'll have problems.

I guess the solution here is to make such control visible only via the
subdev interface.

Thanks,
Mauro


RE: [PATCH v6 3/7] media: i2c: max2175: Add MAX2175 support

2017-06-08 Thread Ramesh Shanmugasundaram
> Subject: Re: [PATCH v6 3/7] media: i2c: max2175: Add MAX2175 support
> 
> Em Wed, 31 May 2017 09:44:53 +0100
> Ramesh Shanmugasundaram  escreveu:
> 
> > +++ b/Documentation/media/v4l-drivers/max2175.rst
> > @@ -0,0 +1,60 @@
> > +Maxim Integrated MAX2175 RF to bits tuner driver
> > +
> > +
> > +The MAX2175 driver implements the following driver-specific controls:
> > +
> > +``V4L2_CID_MAX2175_I2S_ENABLE``
> > +---
> > +Enable/Disable I2S output of the tuner.
> > +
> > +.. flat-table::
> > +:header-rows:  0
> > +:stub-columns: 0
> > +:widths:   1 4
> > +
> > +* - ``(0)``
> > +  - I2S output is disabled.
> > +* - ``(1)``
> > +  - I2S output is enabled.
> 
> Hmm... There are other drivers at the subsystem that use I2S (for audio -
> not for SDR - but I guess the issue is similar).
> 
> On such drivers, the bridge driver controls it directly, being sure that
> I2S is enabled when it is expecting some data coming from the I2S bus.
> 
> On some drivers, there are both I2S and A/D inputs at the bridge chipset.
> On such drivers, enabling/disabling I2S is done via VIDIOC_S_INPUT (and
> optionally via ALSA mixer), being transparent to the user if the stream
> comes from a tuner via I2S or from a directly connected A/D input.
> 
> I don't think it is a good idea to enable it via a control, as, if the
> bridge driver is expecting data via I2S, disabling it will cause timeouts
> at the videobuf handling.

The MAX2175 device is exposed as a v4l2 subdev with tuner ops and can interface 
with an SDR device. When the tuner is configured, the I2S output is enabled by 
default. From an independent tuner device perspective, this default behaviour 
is enough and this control may not be needed/used.

However, for the use case here, the R-Car DRIF device acts as the main SDR 
device and the Maxim MAX2175 provides a sub-dev interface with tuner ops.

+-++-+
| |-SCK--->|CLK  |   
|   Master|-SS>|SYNC  DRIFn (slave)  |
|  (MAX2175)  |-SD0--->|D0   |   
| |-SD1--->|D1   |   
+-++-+

The DRIF device design is such that it involves separate register writes to 
enable Rx on each of the data line. To keep both the data lines in sync it 
expects the master device to enable output after both the data line Rx are 
enabled.

This level of control is exposed as a feature in the MAX2175 using this 
control. When interfaced with DRIF this control is used to achieve the desired 
functionality. When not interfaced with DRIF, the MAX2175 default behaviour 
does not have to change because of DRIF and hence this I2S control may be 
unused. Like MAX2175, DRIF is also an independent device and can interface with 
a different third party tuner. 

Hence, this I2S enable/disable is exposed as a user control. The end user 
application (knowing both these devices) is expected to use these controls 
appropriately. Please let me know if I need to explain anything in further 
detail.

Thanks,
Ramesh


Re: [PATCH] ARM: debug-ll: Add support for r8a7743

2017-06-08 Thread Geert Uytterhoeven
Hi Chris,

On Thu, Jun 8, 2017 at 10:50 AM, Chris Paterson
 wrote:
>> > --- a/arch/arm/Kconfig.debug
>> > +++ b/arch/arm/Kconfig.debug
>> > @@ -895,12 +895,13 @@ choice
>> >   via SCIF2 on Renesas R-Car H1 (R8A7779).
>> >
>> > config DEBUG_RCAR_GEN2_SCIF0
>> > -   bool "Kernel low-level debugging messages via SCIF0 on
>> R8A7790/R8A7791/R8A7792/R8A7793"
>> > -   depends on ARCH_R8A7790 || ARCH_R8A7791 || ARCH_R8A7792
>> || ARCH_R8A7793
>> > +   bool "Kernel low-level debugging messages via SCIF0 on
>> R8A7743/R8A7790/R8A7791/R8A7792/R8A7793"
>>
>> This line is becoming a bit long, and it'll only become worse in the future.
>> What about "Kernel low-level debugging messages via SCIF0 on R-Car Gen2"?
>
> What about "Kernel low-level debugging messages via SCIF0 on R-Car Gen2 and 
> RZ/G1"?

Oops, of course. That's what I intended to type ;-)

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] ARM: debug-ll: Add support for r8a7743

2017-06-08 Thread Chris Paterson
Enable low-level debugging support for RZ/G1M (r8a7743). RZ/G1M uses
SCIF0 for the debug console, like most of the R-Car Gen2 SoCs.

Signed-off-by: Chris Paterson 
---
 arch/arm/Kconfig.debug | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index ba2cb63..fd5164c 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -895,12 +895,13 @@ choice
  via SCIF2 on Renesas R-Car H1 (R8A7779).
 
config DEBUG_RCAR_GEN2_SCIF0
-   bool "Kernel low-level debugging messages via SCIF0 on 
R8A7790/R8A7791/R8A7792/R8A7793"
-   depends on ARCH_R8A7790 || ARCH_R8A7791 || ARCH_R8A7792 || 
ARCH_R8A7793
+   bool "Kernel low-level debugging messages via SCIF0 on 
R8A7743/R8A7790/R8A7791/R8A7792/R8A7793"
+   depends on ARCH_R8A7743 || ARCH_R8A7790 || ARCH_R8A7791 || \
+   ARCH_R8A7792 || ARCH_R8A7793
help
  Say Y here if you want kernel low-level debugging support
- via SCIF0 on Renesas R-Car H2 (R8A7790), M2-W (R8A7791), V2H
- (R8A7792), or M2-N (R8A7793).
+ via SCIF0 on Renesas RZ/G1M (R8A7743), R-Car H2 (R8A7790),
+ M2-W (R8A7791), V2H (R8A7792), or M2-N (R8A7793).
 
config DEBUG_RCAR_GEN2_SCIF2
bool "Kernel low-level debugging messages via SCIF2 on R8A7794"
-- 
1.9.1