[PATCH 5/5] ASoC: audio-graph-card: use asoc_simple_card_clk_xxx()
From: Kuninori MorimotoCurrent 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()
From: Kuninori MorimotoCurrent 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()
From: Kuninori MorimotoCurrent 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()
From: Kuninori MorimotoCurrent 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
From: Kuninori MorimotoRenesas 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()
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
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 Binghamescreveu: > > > 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
Em Wed, 7 Jun 2017 10:52:07 +0100 Kieran Binghamescreveu: > 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()
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
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
> 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
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
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
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
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
From: Yoshihiro ShimodaTo 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
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 ShimodaSigned-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
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
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
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
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 ShimodaSigned-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
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
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 BehmeSigned-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
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
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 ShimodaSigned-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
From: Yoshihiro ShimodaTo 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
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
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
Em Mon, 29 May 2017 14:02:02 +0200 Wolfram Sangescreveu: > >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
> Em Thu, 8 Jun 2017 09:42:43 + > Ramesh Shanmugasundaramescreveu: > > > > 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
Em Thu, 8 Jun 2017 09:42:43 + Ramesh Shanmugasundaramescreveu: > > 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
> Subject: Re: [PATCH v6 3/7] media: i2c: max2175: Add MAX2175 support > > Em Wed, 31 May 2017 09:44:53 +0100 > Ramesh Shanmugasundaramescreveu: > > > +++ 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
Hi Chris, On Thu, Jun 8, 2017 at 10:50 AM, Chris Patersonwrote: >> > --- 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
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