Re: [PATCH] ARM: dts: silk: add DU pins

[Sergei Shtylyov]

Hello.

On 04/13/2016 10:36 PM, Sergei Shtylyov wrote:


Add the (previously omitted) DU pin data to the SILK board's device tree.

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'renesas-devel-20160411-v4.6-rc3' tag of Simon
Horman's 'renesas.git' repo. It depends on the R8A7794 DU PFC driver patch
just posted for the pins to be configured...


   Simon, this patch seems stuck while the PFC driver patch hit Linus' tree 
long ago. :-(


MBR, Sergei

Re: [PATCH/RFC] ARM: shmobile: rcar-gen2: Correct arch timer frequency on R-Car V2H

[Sergei Shtylyov]

On 06/16/2016 08:19 AM, Simon Horman wrote:


According to the datasheet, the frequency of the ARM architecture timer
on R-Car V2H depends on the frequency of the ZS clock, just like on
R-Car E2.

Signed-off-by: Geert Uytterhoeven 
---
Against renesas-devel-20160613-v4.7-rc3 with "ARM: shmobile: rcar-gen2:
Obtain extal frequency from DT" applied.

Untested due to lack of hardware.


Sergei, could you test this?


   Done, now 'sleep 5' takes 5 seconds indeed. :-)

Tested-by: Sergei Shtylyov 

MBR, Sergei

Re: [PATCH v4 03/13] soc: renesas: rcar-sysc: Make rcar_sysc_init() init the PM domains

[Geert Uytterhoeven]

Hi Ulrich,

On Fri, Jun 17, 2016 at 5:57 PM, Ulrich Hecht  wrote:
>> --- a/drivers/soc/renesas/rcar-sysc.c
>> +++ b/drivers/soc/renesas/rcar-sysc.c
>> @@ -164,15 +164,6 @@ static bool rcar_sysc_power_is_off(const struct 
>> rcar_sysc_ch *sysc_ch)
>> return false;
>>  }
>>
>> -void __iomem *rcar_sysc_init(phys_addr_t base)
>> -{
>> -   rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
>> -   if (!rcar_sysc_base)
>> -   panic("unable to ioremap R-Car SYSC hardware block\n");
>
> Is this check no longer necessary?

If this failed (out of memory) this early in the boot process, we're gonna die
anyway.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 06/13] ARM: shmobile: apmu: Move #ifdef CONFIG_SMP to cover more functions

[Ulrich Hecht]

On Thu, Jun 16, 2016 at 12:27 PM, Geert Uytterhoeven
 wrote:
> shmobile_smp_apmu_prepare_cpus() is used only if CONFIG_SMP=y.
>
> Hence move the #ifdef to cover shmobile_smp_apmu_prepare_cpus() and all
> functions only called by it (apmu_init_cpu() and apmu_parse_cfg()).
>
> Signed-off-by: Geert Uytterhoeven 
> ---
> v4:
>   - New.
> ---
>  arch/arm/mach-shmobile/platsmp-apmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c 
> b/arch/arm/mach-shmobile/platsmp-apmu.c
> index aba75c89f9c1c5eb..c1558ef0c590dd3e 100644
> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
> @@ -74,6 +74,7 @@ static int __maybe_unused apmu_wrap(int cpu, int (*fn)(void 
> __iomem *p, int cpu)
> return p ? fn(p, apmu_cpus[cpu].bit) : -EINVAL;
>  }
>
> +#ifdef CONFIG_SMP
>  static void apmu_init_cpu(struct resource *res, int cpu, int bit)
>  {
> if ((cpu >= ARRAY_SIZE(apmu_cpus)) || apmu_cpus[cpu].iomem)
> @@ -128,7 +129,6 @@ void __init shmobile_smp_apmu_prepare_cpus(unsigned int 
> max_cpus,
> apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
>  }
>
> -#ifdef CONFIG_SMP
>  int shmobile_smp_apmu_boot_secondary(unsigned int cpu, struct task_struct 
> *idle)
>  {
> /* For this particular CPU register boot vector */
> --
> 1.9.1
>

Reviewed-by: Ulrich Hecht 

CU
Uli

RE: [PATCH] pinctrl: sh-pfc: r8a7795: Add DRIF support

[Ramesh Shanmugasundaram]

Hi Geert,

Thanks for your time and review

> >  drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 121
> > +++
> >  1 file changed, 121 insertions(+)
> >
> > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> > b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> > index 33be5d56..6f246ec 100644
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> > @@ -1658,6 +1658,91 @@ static const unsigned int canfd1_data_mux[] = {
> > CANFD1_TX_MARK, CANFD1_RX_MARK,
> >  };
> >
> > +/* - DRIF
> > +--- */
> static const unsigned int drif0_data_a_pins[] = {
> > +   /* CLK, SYNC, D0, D1 */
> > +   RCAR_GP_PIN(6, 8), RCAR_GP_PIN(6, 9), RCAR_GP_PIN(6, 10),
> > +   RCAR_GP_PIN(6, 7),
> > +};
> > +static const unsigned int drif0_data_a_mux[] = {
> > +   RIF0_CLK_A_MARK, RIF0_SYNC_A_MARK, RIF0_D0_A_MARK,
> > +RIF0_D1_A_MARK, };
> 
> According to my information, each DRIF module consists of two sub-modules
> (that's why there are 8 module clocks for 4 DRIF modules), each handling a
> data pin, but sharing the CLK and SYNC signals.
> Hence it's possible to receive using only one data pin. Is that correct?

Yes, that is correct.

> 
> Shouldn't the pinctrl data reflect that? The second unused data pin could
> be used for something else.

Is that possible? For e.g. when MOD_SEL0(bit8 -> sel_drif2) is set to 0, all 
the 4 pins are owned by DRIF IP(RIF2_XXX_A set) even though one of the 
RIF2_D0_A or RIF2_D1_A may be unused depending on the master it interfaces 
with. Am I missing something?

> 
> One way to handle this is like SDHI and DU do: provide 2 sets of data, one
> for single-bit, and one for dual-bit configurations:
>   - "drif0_data1_a_pins" for CLK, SYNC, and D0,
>   - "drif0_data2_a_pins" for CLK. SYNC, D0, and D1.
> 
> Alternative, it could be split in 3 groups:
>   - "drif0_ctrl_a_pins" for CLK and SYNC,
>   - "drif0_data0_a_pins for D0,
>   - "drif0_data1_a_pins for D1.
> 
> I think the latter is preferable, as you can probably configure the DRIF
> to receive data through D1 only, and leave D0 unused?
> 
> > +static const unsigned int drif3_data_a_pins[] = {
> > +   /* CLK, SYNC, D0, D1 */
> > +   RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 18), RCAR_GP_PIN(6, 19),
> > +   RCAR_GP_PIN(6, 10),
> 
> According to my datasheet, the above line should be
> 
> RCAR_GP_PIN(6, 20),

You are right. Thanks again. I'll fix that typo :-(

Thanks,
Ramesh

Re: [PATCH] pinctrl: sh-pfc: r8a7795: Add DRIF support

[Geert Uytterhoeven]

Hi Ramesh,

On Fri, Jun 17, 2016 at 2:19 PM, Ramesh Shanmugasundaram
 wrote:
> This patch adds DRIF[0-3] pinmux support for r8a7795 SoC.
>
> Signed-off-by: Ramesh Shanmugasundaram 
> 

Thanks for your patch!

> ---
>  drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 121 
> +++
>  1 file changed, 121 insertions(+)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
> b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> index 33be5d56..6f246ec 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> @@ -1658,6 +1658,91 @@ static const unsigned int canfd1_data_mux[] = {
> CANFD1_TX_MARK, CANFD1_RX_MARK,
>  };
>
> +/* - DRIF --- */
> +static const unsigned int drif0_data_a_pins[] = {
> +   /* CLK, SYNC, D0, D1 */
> +   RCAR_GP_PIN(6, 8), RCAR_GP_PIN(6, 9), RCAR_GP_PIN(6, 10),
> +   RCAR_GP_PIN(6, 7),
> +};
> +static const unsigned int drif0_data_a_mux[] = {
> +   RIF0_CLK_A_MARK, RIF0_SYNC_A_MARK, RIF0_D0_A_MARK, RIF0_D1_A_MARK,
> +};

According to my information, each DRIF module consists of two sub-modules
(that's why there are 8 module clocks for 4 DRIF modules), each handling a data
pin, but sharing the CLK and SYNC signals.
Hence it's possible to receive using only one data pin. Is that correct?

Shouldn't the pinctrl data reflect that? The second unused data pin could be
used for something else.

One way to handle this is like SDHI and DU do: provide 2 sets of data, one for
single-bit, and one for dual-bit configurations:
  - "drif0_data1_a_pins" for CLK, SYNC, and D0,
  - "drif0_data2_a_pins" for CLK. SYNC, D0, and D1.

Alternative, it could be split in 3 groups:
  - "drif0_ctrl_a_pins" for CLK and SYNC,
  - "drif0_data0_a_pins for D0,
  - "drif0_data1_a_pins for D1.

I think the latter is preferable, as you can probably configure the DRIF to
receive data through D1 only, and leave D0 unused?

> +static const unsigned int drif3_data_a_pins[] = {
> +   /* CLK, SYNC, D0, D1 */
> +   RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 18), RCAR_GP_PIN(6, 19),
> +   RCAR_GP_PIN(6, 10),

According to my datasheet, the above line should be

RCAR_GP_PIN(6, 20),

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] clk: renesas: r8a7795: Add DRIF clock

[Geert Uytterhoeven]

Hi Ramesh,

On Fri, Jun 17, 2016 at 2:25 PM, Ramesh Shanmugasundaram
 wrote:
> This patch adds DRIF module clocks for r8a7795 SoC.
>
> Signed-off-by: Ramesh Shanmugasundaram 
> 

Thanks!

Reviewed-by: Geert Uytterhoeven 

(i.e. will queue in clk-renesas-for-v4.8)

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 v3] arm64: dts: r8a7795: Add CAN FD support

[Ramesh Shanmugasundaram]

Adds CAN FD controller node for r8a7795.

Note: CAN FD controller register base address specified in R-Car Gen3
Hardware User Manual v0.5E is incorrect. The correct address is:

CAN FD - 0xe66c

Signed-off-by: Ramesh Shanmugasundaram 
---

Note:
Bindings already Acked-by: Rob H on driver patch set
(https://www.mail-archive.com/netdev@vger.kernel.org/msg102789.html)

Changes since v2:
Rebased to Simon's latest tag:renesas-devel-20160616-v4.7-rc3

Changes since v1:
As suggested by Sergei, Simon - changed node name from canfd@ to can@

---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index fad6dd8..b902356 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -583,6 +583,30 @@
status = "disabled";
};
 
+   canfd: can@e66c {
+   compatible = "renesas,r8a7795-canfd",
+"renesas,rcar-gen3-canfd";
+   reg = <0 0xe66c 0 0x8000>;
+   interrupts = ,
+  ;
+   clocks = < CPG_MOD 914>,
+  < CPG_CORE R8A7795_CLK_CANFD>,
+  <_clk>;
+   clock-names = "fck", "canfd", "can_clk";
+   assigned-clocks = < CPG_CORE R8A7795_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   status = "disabled";
+
+   channel0 {
+   status = "disabled";
+   };
+
+   channel1 {
+   status = "disabled";
+   };
+   };
+
hscif0: serial@e654 {
compatible = "renesas,hscif-r8a7795",
 "renesas,rcar-gen3-hscif",
-- 
1.9.1

[PATCH] pinctrl: sh-pfc: r8a7795: Add DRIF support

[Ramesh Shanmugasundaram]

This patch adds DRIF[0-3] pinmux support for r8a7795 SoC.

Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 121 +++
 1 file changed, 121 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 33be5d56..6f246ec 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -1658,6 +1658,91 @@ static const unsigned int canfd1_data_mux[] = {
CANFD1_TX_MARK, CANFD1_RX_MARK,
 };
 
+/* - DRIF --- */
+static const unsigned int drif0_data_a_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(6, 8), RCAR_GP_PIN(6, 9), RCAR_GP_PIN(6, 10),
+   RCAR_GP_PIN(6, 7),
+};
+static const unsigned int drif0_data_a_mux[] = {
+   RIF0_CLK_A_MARK, RIF0_SYNC_A_MARK, RIF0_D0_A_MARK, RIF0_D1_A_MARK,
+};
+static const unsigned int drif0_data_b_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(5, 0), RCAR_GP_PIN(5, 4), RCAR_GP_PIN(5, 1),
+   RCAR_GP_PIN(5, 2),
+};
+static const unsigned int drif0_data_b_mux[] = {
+   RIF0_CLK_B_MARK, RIF0_SYNC_B_MARK, RIF0_D0_B_MARK, RIF0_D1_B_MARK,
+};
+static const unsigned int drif0_data_c_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(5, 12), RCAR_GP_PIN(5, 15), RCAR_GP_PIN(5, 13),
+   RCAR_GP_PIN(5, 14),
+};
+static const unsigned int drif0_data_c_mux[] = {
+   RIF0_CLK_C_MARK, RIF0_SYNC_C_MARK, RIF0_D0_C_MARK, RIF0_D1_C_MARK,
+};
+
+static const unsigned int drif1_data_a_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 18), RCAR_GP_PIN(6, 19),
+   RCAR_GP_PIN(6, 20),
+};
+static const unsigned int drif1_data_a_mux[] = {
+   RIF1_CLK_A_MARK, RIF1_SYNC_A_MARK, RIF1_D0_A_MARK, RIF1_D1_A_MARK,
+};
+static const unsigned int drif1_data_b_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(5, 9), RCAR_GP_PIN(5, 3), RCAR_GP_PIN(5, 7),
+   RCAR_GP_PIN(5, 8),
+};
+static const unsigned int drif1_data_b_mux[] = {
+   RIF1_CLK_B_MARK, RIF1_SYNC_B_MARK, RIF1_D0_B_MARK, RIF1_D1_B_MARK,
+};
+static const unsigned int drif1_data_c_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(5, 5), RCAR_GP_PIN(5, 11), RCAR_GP_PIN(5, 6),
+   RCAR_GP_PIN(5, 10),
+};
+static const unsigned int drif1_data_c_mux[] = {
+   RIF1_CLK_C_MARK, RIF1_SYNC_C_MARK, RIF1_D0_C_MARK, RIF1_D1_C_MARK,
+};
+
+static const unsigned int drif2_data_a_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(6, 8), RCAR_GP_PIN(6, 9), RCAR_GP_PIN(6, 7),
+   RCAR_GP_PIN(6, 10),
+};
+static const unsigned int drif2_data_a_mux[] = {
+   RIF2_CLK_A_MARK, RIF2_SYNC_A_MARK, RIF2_D0_A_MARK, RIF2_D1_A_MARK,
+};
+static const unsigned int drif2_data_b_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(6, 26), RCAR_GP_PIN(6, 27), RCAR_GP_PIN(6, 30),
+   RCAR_GP_PIN(6, 31),
+};
+static const unsigned int drif2_data_b_mux[] = {
+   RIF2_CLK_B_MARK, RIF2_SYNC_B_MARK, RIF2_D0_B_MARK, RIF2_D1_B_MARK,
+};
+
+static const unsigned int drif3_data_a_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 18), RCAR_GP_PIN(6, 19),
+   RCAR_GP_PIN(6, 10),
+};
+static const unsigned int drif3_data_a_mux[] = {
+   RIF3_CLK_A_MARK, RIF3_SYNC_A_MARK, RIF3_D0_A_MARK, RIF3_D1_A_MARK,
+};
+static const unsigned int drif3_data_b_pins[] = {
+   /* CLK, SYNC, D0, D1 */
+   RCAR_GP_PIN(6, 24), RCAR_GP_PIN(6, 25), RCAR_GP_PIN(6, 28),
+   RCAR_GP_PIN(6, 29),
+};
+static const unsigned int drif3_data_b_mux[] = {
+   RIF3_CLK_B_MARK, RIF3_SYNC_B_MARK, RIF3_D0_B_MARK, RIF3_D1_B_MARK,
+};
+
 /* - HSCIF0 - 
*/
 static const unsigned int hscif0_data_pins[] = {
/* RX, TX */
@@ -3350,6 +3435,16 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(canfd0_data_a),
SH_PFC_PIN_GROUP(canfd0_data_b),
SH_PFC_PIN_GROUP(canfd1_data),
+   SH_PFC_PIN_GROUP(drif0_data_a),
+   SH_PFC_PIN_GROUP(drif0_data_b),
+   SH_PFC_PIN_GROUP(drif0_data_c),
+   SH_PFC_PIN_GROUP(drif1_data_a),
+   SH_PFC_PIN_GROUP(drif1_data_b),
+   SH_PFC_PIN_GROUP(drif1_data_c),
+   SH_PFC_PIN_GROUP(drif2_data_a),
+   SH_PFC_PIN_GROUP(drif2_data_b),
+   SH_PFC_PIN_GROUP(drif3_data_a),
+   SH_PFC_PIN_GROUP(drif3_data_b),
SH_PFC_PIN_GROUP(hscif0_data),
SH_PFC_PIN_GROUP(hscif0_clk),
SH_PFC_PIN_GROUP(hscif0_ctrl),
@@ -3633,6 +3728,28 @@ static const char * const canfd1_groups[] = {
"canfd1_data",
 };
 
+static const char * const drif0_groups[] = {
+   "drif0_data_a",
+   "drif0_data_b",
+   "drif0_data_c",
+};
+
+static const char * const drif1_groups[] = {
+   "drif1_data_a",
+   "drif1_data_b",
+   "drif1_data_c",
+};
+

Applied "ASoC: ak4613: Enable cache usage to fix crashes on resume" to the asoc tree

[Mark Brown]

The patch

   ASoC: ak4613: Enable cache usage to fix crashes on resume

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

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

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

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

Thanks,
Mark

>From dcd2d1f78664fdc75eadaaf65257834e24383d01 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven 
Date: Thu, 16 Jun 2016 14:34:30 +0200
Subject: [PATCH] ASoC: ak4613: Enable cache usage to fix crashes on resume

During system resume:

kernel BUG at drivers/base/regmap/regcache.c:347!
...
PC is at regcache_sync+0x1c/0x128
LR is at ak4613_resume+0x28/0x34

The ak4613 driver is using a regmap cache sync to restore the
configuration of the chip on resume but does not actually define a
register cache which means that the resume is never going to work and we
trigger asserts in regmap.  Fix this by enabling caching.

Based on commit d3030d11961a8c10 ("ASoC: ak4642: Enable cache usage to
fix crashes on resume") by Mark Brown .

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/ak4613.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/ak4613.c b/sound/soc/codecs/ak4613.c
index 33d2f2e10e24..5013d2ba0c10 100644
--- a/sound/soc/codecs/ak4613.c
+++ b/sound/soc/codecs/ak4613.c
@@ -146,6 +146,7 @@ static const struct regmap_config ak4613_regmap_cfg = {
.max_register   = 0x16,
.reg_defaults   = ak4613_reg,
.num_reg_defaults   = ARRAY_SIZE(ak4613_reg),
+   .cache_type = REGCACHE_RBTREE,
 };
 
 static const struct of_device_id ak4613_of_match[] = {
-- 
2.8.1

Re: [PATCH v2 05/13] v4l: vsp1: Add FCP support

[Mauro Carvalho Chehab]

Em Tue, 26 Apr 2016 00:36:30 +0300
Laurent Pinchart  escreveu:

> On some platforms the VSP performs memory accesses through an FCP. When
> that's the case get a reference to the FCP from the VSP DT node and
> enable/disable it at runtime as needed.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../devicetree/bindings/media/renesas,vsp1.txt  |  5 +
>  drivers/media/platform/Kconfig  |  1 +
>  drivers/media/platform/vsp1/vsp1.h  |  2 ++
>  drivers/media/platform/vsp1/vsp1_drv.c  | 21 
> -
>  4 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt 
> b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> index 627405abd144..9b695bcbf219 100644
> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
> @@ -14,6 +14,11 @@ Required properties:
>- interrupts: VSP interrupt specifier.
>- clocks: A phandle + clock-specifier pair for the VSP functional clock.
>  
> +Optional properties:
> +
> +  - renesas,fcp: A phandle referencing the FCP that handles memory accesses
> + for the VSP. Not needed on Gen2, mandatory on Gen3.
> +
>  
>  Example: R8A7790 (R-Car H2) VSP1-S node
>  
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index f453910050be..a3304466e628 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -264,6 +264,7 @@ config VIDEO_RENESAS_VSP1
>   tristate "Renesas VSP1 Video Processing Engine"
>   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
>   depends on (ARCH_RENESAS && OF) || COMPILE_TEST
> + depends on !ARM64 || VIDEO_RENESAS_FCP

It sounds that this will break compile-test on ARM64 for no good reason.

Thanks,
Mauro

Re: [[RESEND]PATCH v7 0/2] Add CAN FD driver support to r8a7795 SoC

[Marc Kleine-Budde]

On 06/17/2016 10:20 AM, Ramesh Shanmugasundaram wrote:
>Would it be possible for you to consider this patch please?
> 
>This patch set has undergone multiple reviews as in the change history
>below. We would be grateful if you could consider accepting this patch as
>Marc K appears to be inactive and we haven't heard from him since March.

I'll take the patch.

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

[[RESEND]PATCH v7 2/2] can: rcar_can: Move Renesas CAN driver to rcar dir

[Ramesh Shanmugasundaram]

This patch clubs the Renesas controller drivers in one rcar dir.

Signed-off-by: Ramesh Shanmugasundaram 
---
 drivers/net/can/Kconfig   | 10 --
 drivers/net/can/Makefile  |  1 -
 drivers/net/can/rcar/Kconfig  | 10 ++
 drivers/net/can/rcar/Makefile |  3 ++-
 drivers/net/can/{ => rcar}/rcar_can.c |  0
 5 files changed, 12 insertions(+), 12 deletions(-)
 rename drivers/net/can/{ => rcar}/rcar_can.c (100%)

diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 13003a9..22570ea 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -104,16 +104,6 @@ config CAN_JANZ_ICAN3
  This driver can also be built as a module. If so, the module will be
  called janz-ican3.ko.
 
-config CAN_RCAR
-   tristate "Renesas R-Car CAN controller"
-   depends on ARCH_RENESAS || ARM
-   ---help---
- Say Y here if you want to use CAN controller found on Renesas R-Car
- SoCs.
-
- To compile this driver as a module, choose M here: the module will
- be called rcar_can.
-
 config CAN_SUN4I
tristate "Allwinner A10 CAN controller"
depends on MACH_SUN4I || MACH_SUN7I || COMPILE_TEST
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index 226d5b5..26ba4b7 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -25,7 +25,6 @@ obj-$(CONFIG_CAN_IFI_CANFD)   += ifi_canfd/
 obj-$(CONFIG_CAN_JANZ_ICAN3)   += janz-ican3.o
 obj-$(CONFIG_CAN_MSCAN)+= mscan/
 obj-$(CONFIG_CAN_M_CAN)+= m_can/
-obj-$(CONFIG_CAN_RCAR) += rcar_can.o
 obj-$(CONFIG_CAN_SJA1000)  += sja1000/
 obj-$(CONFIG_CAN_SUN4I)+= sun4i_can.o
 obj-$(CONFIG_CAN_TI_HECC)  += ti_hecc.o
diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
index 6ea64d1..7b03a3a 100644
--- a/drivers/net/can/rcar/Kconfig
+++ b/drivers/net/can/rcar/Kconfig
@@ -1,3 +1,13 @@
+config CAN_RCAR
+   tristate "Renesas R-Car CAN controller"
+   depends on ARCH_RENESAS || ARM
+   ---help---
+ Say Y here if you want to use CAN controller found on Renesas R-Car
+ SoCs.
+
+ To compile this driver as a module, choose M here: the module will
+ be called rcar_can.
+
 config CAN_RCAR_CANFD
tristate "Renesas R-Car CAN FD controller"
depends on ARCH_RENESAS || ARM
diff --git a/drivers/net/can/rcar/Makefile b/drivers/net/can/rcar/Makefile
index cbaf498e..08de36a 100644
--- a/drivers/net/can/rcar/Makefile
+++ b/drivers/net/can/rcar/Makefile
@@ -1,5 +1,6 @@
 #
-#  Makefile for the Renesas R-Car CAN FD controller driver
+#  Makefile for the Renesas R-Car CAN & CAN FD controller drivers
 #
 
+obj-$(CONFIG_CAN_RCAR) += rcar_can.o
 obj-$(CONFIG_CAN_RCAR_CANFD)   += rcar_canfd.o
diff --git a/drivers/net/can/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
similarity index 100%
rename from drivers/net/can/rcar_can.c
rename to drivers/net/can/rcar/rcar_can.c
-- 
1.9.1

[[RESEND]PATCH v7 1/2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

[Ramesh Shanmugasundaram]

This patch adds support for the CAN FD controller found in Renesas R-Car
SoCs. The controller operates in CAN FD only mode by default.

CAN FD mode supports both Classical CAN & CAN FD frame formats. The
controller supports ISO 11898-1:2015 CAN FD format only.

This controller supports two channels and the driver can enable either
or both of the channels.

Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs (one
per channel) for transmission. Rx filter rules are configured to the
minimum (one per channel) and it accepts Standard, Extended, Data &
Remote Frame combinations.

Note: There are few documentation errors in R-Car Gen3 Hardware User
Manual v0.5E with respect to CAN FD controller. They are listed below:

1. CAN FD interrupt numbers 29 & 30 are listed as per channel
interrupts. However, they are common to both channels (i.e.) they are
global and channel interrupts respectively.

2. CANFD clock is derived from PLL1. This is not documented.

3. CANFD clock is further divided by (1/2) within the CAN FD controller.
This is not documented.

4. The minimum value of NTSEG1 in RSCFDnCFDCmNCFG register is 2 Tq. It
is specified 4 Tq in the manual.

5. The maximum number of message RAM area the controller can use is 3584
bytes. It is specified 10752 bytes in the manual.

Signed-off-by: Ramesh Shanmugasundaram 
Acked-by: Rob Herring 
Reviewed-by: Ulrich Hecht 
---
 .../devicetree/bindings/net/can/rcar_canfd.txt |   89 +
 drivers/net/can/Kconfig|1 +
 drivers/net/can/Makefile   |1 +
 drivers/net/can/rcar/Kconfig   |   11 +
 drivers/net/can/rcar/Makefile  |5 +
 drivers/net/can/rcar/rcar_canfd.c  | 1695 
 6 files changed, 1802 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/can/rcar_canfd.txt
 create mode 100644 drivers/net/can/rcar/Kconfig
 create mode 100644 drivers/net/can/rcar/Makefile
 create mode 100644 drivers/net/can/rcar/rcar_canfd.c

diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt 
b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
new file mode 100644
index 000..d45182b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -0,0 +1,89 @@
+Renesas R-Car CAN FD controller Device Tree Bindings
+
+
+Required properties:
+- compatible: Must contain one or more of the following:
+  - "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
+  - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
+
+  When compatible with the generic version, nodes must list the
+  SoC-specific version corresponding to the platform first, followed by the
+  family-specific and/or generic versions.
+
+- reg: physical base address and size of the R-Car CAN FD register map.
+- interrupts: interrupt specifier for the Global & Channel interrupts
+- clocks: phandles and clock specifiers for 3 clock inputs.
+- clock-names: 3 clock input name strings: "fck", "canfd", "can_clk".
+- pinctrl-0: pin control group to be used for this controller.
+- pinctrl-names: must be "default".
+
+Required child nodes:
+The controller supports two channels and each is represented as a child node.
+The name of the child nodes are "channel0" and "channel1" respectively. Each
+child node supports the "status" property only, which is used to
+enable/disable the respective channel.
+
+Required properties for "renesas,r8a7795-canfd" compatible:
+In R8A7795 SoC, canfd clock is a div6 clock and can be used by both CAN
+and CAN FD controller at the same time. It needs to be scaled to maximum
+frequency if any of these controllers use it. This is done using the
+below properties.
+
+- assigned-clocks: phandle of canfd clock.
+- assigned-clock-rates: maximum frequency of this clock.
+
+Example
+---
+
+SoC common .dtsi file:
+
+   canfd: can@e66c {
+   compatible = "renesas,r8a7795-canfd",
+"renesas,rcar-gen3-canfd";
+   reg = <0 0xe66c 0 0x8000>;
+   interrupts = ,
+  ;
+   clocks = < CPG_MOD 914>,
+  < CPG_CORE R8A7795_CLK_CANFD>,
+  <_clk>;
+   clock-names = "fck", "canfd", "can_clk";
+   assigned-clocks = < CPG_CORE R8A7795_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = <>;
+   status = "disabled";
+
+   channel0 {
+   status = "disabled";
+   };
+
+   channel1 {
+   status = "disabled";
+

[PATCH 7/7] drm/rcar-du: Remove redundant calls to drm_connector_register_all()

[Chris Wilson]

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 48ec4b6e8b26..36d390093c92 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -278,7 +278,6 @@ static int rcar_du_remove(struct platform_device *pdev)
struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
struct drm_device *ddev = rcdu->ddev;
 
-   drm_connector_unregister_all(ddev);
drm_dev_unregister(ddev);
 
if (rcdu->fbdev)
@@ -360,10 +359,6 @@ static int rcar_du_probe(struct platform_device *pdev)
if (ret)
goto error;
 
-   ret = drm_connector_register_all(ddev);
-   if (ret < 0)
-   goto error;
-
DRM_INFO("Device %s probed\n", dev_name(>dev));
 
return 0;
-- 
2.8.1

Re: [PATCH 2/2] ARM: dts: r8a7792: add JPU support

[Geert Uytterhoeven]

On Fri, Jun 17, 2016 at 12:03 AM, Sergei Shtylyov
 wrote:
> Describe JPEG Processing Unit (JPU) in the R8A7792 device tree.
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds