date:20170829

Re: dt-bindings: watchdog: renesas-wdt: Add support for the r8a77995 wdt

2017-08-29 Thread Guenter Roeck

On Thu, Aug 17, 2017 at 01:14:25PM +0200, Geert Uytterhoeven wrote:
> Document support for the Watchdog Timer (WDT) Controller in the Renesas
> R-Car D3 (r8a77995) SoC.
> 
> No driver update is needed.
> 
> Signed-off-by: Geert Uytterhoeven 
> Acked-by: Simon Horman 
> Acked-by: Rob Herring 

Reviewed-by: Guenter Roeck 

> ---
>  Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> index 9e306afbbd49e91b..bf6d1ca58af7d198 100644
> --- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> @@ -6,6 +6,7 @@ Required properties:
>  Examples with soctypes are:
>- "renesas,r8a7795-wdt" (R-Car H3)
>- "renesas,r8a7796-wdt" (R-Car M3-W)
> +  - "renesas,r8a77995-wdt" (R-Car D3)
>- "renesas,r7s72100-wdt" (RZ/A1)
>  
>When compatible with the generic version, nodes must list the SoC-specific

Re: [RFC, 2/3] watchdog: renesas_wdt: make 'clk' a variable local to probe()

2017-08-29 Thread Guenter Roeck

On Wed, Jul 26, 2017 at 11:54:38PM +0200, Wolfram Sang wrote:
> It is not needed outside probe() anymore.
> 
> Signed-off-by: Wolfram Sang 
> Reviewed-by: Geert Uytterhoeven 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/renesas_wdt.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index a03997b418ba9c..2927b5086e156e 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -48,7 +48,6 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once 
> started (default="
>  struct rwdt_priv {
>   void __iomem *base;
>   struct watchdog_device wdev;
> - struct clk *clk;
>   unsigned long clk_rate;
>   u8 cks;
>  };
> @@ -125,6 +124,7 @@ static int rwdt_probe(struct platform_device *pdev)
>  {
>   struct rwdt_priv *priv;
>   struct resource *res;
> + struct clk *clk;
>   unsigned long clks_per_sec;
>   int ret, i;
>  
> @@ -137,14 +137,14 @@ static int rwdt_probe(struct platform_device *pdev)
>   if (IS_ERR(priv->base))
>   return PTR_ERR(priv->base);
>  
> - priv->clk = devm_clk_get(>dev, NULL);
> - if (IS_ERR(priv->clk))
> - return PTR_ERR(priv->clk);
> + clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
>  
>   pm_runtime_enable(>dev);
>  
>   pm_runtime_get_sync(>dev);
> - priv->clk_rate = clk_get_rate(priv->clk);
> + priv->clk_rate = clk_get_rate(clk);
>   pm_runtime_put(>dev);
>  
>   if (!priv->clk_rate) {

Re: [RFC,3/3] watchdog: renesas_wdt: update copyright dates

2017-08-29 Thread Guenter Roeck

On Wed, Jul 26, 2017 at 11:54:39PM +0200, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/renesas_wdt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index 2927b5086e156e..831ef83f6de15b 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -1,8 +1,8 @@
>  /*
>   * Watchdog driver for Renesas WDT watchdog
>   *
> - * Copyright (C) 2015-16 Wolfram Sang, Sang Engineering 
> 
> - * Copyright (C) 2015-16 Renesas Electronics Corporation
> + * Copyright (C) 2015-17 Wolfram Sang, Sang Engineering 
> 
> + * Copyright (C) 2015-17 Renesas Electronics Corporation
>   *
>   * 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

Re: [RFC, 1/3] watchdog: renesas_wdt: consistently use RuntimePM for clock management

2017-08-29 Thread Guenter Roeck

On Wed, Jul 26, 2017 at 11:54:37PM +0200, Wolfram Sang wrote:
> On Renesas R-Car archs, RuntimePM does all the clock handling. So, use
> it consistently to enable/disable the clocks. Also make sure that clocks
> are really enabled around clk_get_rate(). clk_summary looks proper now:
> 
>   clock   enable_cnt  prepare_cnt rate ...
> Before this commit:
> 
> At boot:  rwdt1   1   32768 0 0
> WDT running:  rwdt2   2   32768 0 0
> 
> After this commit:
> 
> At boot:  rwdt0   1   32768 0 0
> WDT running   rwdt1   1   32768 0 0
> 
> Signed-off-by: Wolfram Sang 
> Reviewed-by: Geert Uytterhoeven 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/renesas_wdt.c | 33 +++--
>  1 file changed, 19 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index e3f204bb8802aa..a03997b418ba9c 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -76,7 +76,7 @@ static int rwdt_start(struct watchdog_device *wdev)
>  {
>   struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
>  
> - clk_prepare_enable(priv->clk);
> + pm_runtime_get_sync(wdev->parent);
>  
>   rwdt_write(priv, 0, RWTCSRB);
>   rwdt_write(priv, priv->cks, RWTCSRA);
> @@ -95,7 +95,7 @@ static int rwdt_stop(struct watchdog_device *wdev)
>   struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
>  
>   rwdt_write(priv, priv->cks, RWTCSRA);
> - clk_disable_unprepare(priv->clk);
> + pm_runtime_put(wdev->parent);
>  
>   return 0;
>  }
> @@ -141,9 +141,16 @@ static int rwdt_probe(struct platform_device *pdev)
>   if (IS_ERR(priv->clk))
>   return PTR_ERR(priv->clk);
>  
> + pm_runtime_enable(>dev);
> +
> + pm_runtime_get_sync(>dev);
>   priv->clk_rate = clk_get_rate(priv->clk);
> - if (!priv->clk_rate)
> - return -ENOENT;
> + pm_runtime_put(>dev);
> +
> + if (!priv->clk_rate) {
> + ret = -ENOENT;
> + goto out_pm_disable;
> + }
>  
>   for (i = ARRAY_SIZE(clk_divs) - 1; i >= 0; i--) {
>   clks_per_sec = priv->clk_rate / clk_divs[i];
> @@ -155,12 +162,10 @@ static int rwdt_probe(struct platform_device *pdev)
>  
>   if (i < 0) {
>   dev_err(>dev, "Can't find suitable clock divider\n");
> - return -ERANGE;
> + ret = -ERANGE;
> + goto out_pm_disable;
>   }
>  
> - pm_runtime_enable(>dev);
> - pm_runtime_get_sync(>dev);
> -
>   priv->wdev.info = _ident,
>   priv->wdev.ops = _ops,
>   priv->wdev.parent = >dev;
> @@ -178,13 +183,14 @@ static int rwdt_probe(struct platform_device *pdev)
>   dev_warn(>dev, "Specified timeout value invalid, using 
> default\n");
>  
>   ret = watchdog_register_device(>wdev);
> - if (ret < 0) {
> - pm_runtime_put(>dev);
> - pm_runtime_disable(>dev);
> - return ret;
> - }
> + if (ret < 0)
> + goto out_pm_disable;
>  
>   return 0;
> +
> + out_pm_disable:
> + pm_runtime_disable(>dev);
> + return ret;
>  }
>  
>  static int rwdt_remove(struct platform_device *pdev)
> @@ -192,7 +198,6 @@ static int rwdt_remove(struct platform_device *pdev)
>   struct rwdt_priv *priv = platform_get_drvdata(pdev);
>  
>   watchdog_unregister_device(>wdev);
> - pm_runtime_put(>dev);
>   pm_runtime_disable(>dev);
>  
>   return 0;

[GIT PULL LTSI-4.9] Second Round of Renesas SoCs and Drivers to v4.12

2017-08-29 Thread Simon Horman

Hi,

This is a submission to LTSI-v4.9.

This series is comprised of a backport v4.9 of the rcar-gen3-thermal driver
to its as of v4.12. This was unintentionally omitted from earlier work
submitted for inclusion in LTSI-4.9.

There are 9 patches.

This is based on a merge of:
* Earlier work posted as
  "[GIT PULL LTSI-4.9] Renesas SoCs and Drivers to v4.12"
  and is tagged as tags/backport/v4.9.36/snapshot-to-v4.12-flattened
* v4.9.45

It appears to apply cleanly to an ltsi-4.9 tree generated using
scripts/generate_git


The following changes since commit 89dcb9ecf2d34cba6cba23376651476b0273db5d:

  Merge tag 'v4.9.45' into backport/v4.9.45/snapshot-flattened (2017-08-29 
20:34:36 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git 
tags/backport/v4.9.45/snapshot2-to-v4.12-flattened

for you to fetch changes up to 0d29576c55e2a72e64f36f66ab8dcd279c345942:

  thermal: rcar_gen3_thermal: add suspend and resume support (2017-08-29 
20:35:05 +0200)


Second Round of LTSI-v4.9 Preparation for Renesas SoCs to v4.12

Base:
* v4.9.45
* Backport of various components for Renesas SoCs to v4.12

Component backported in this snapshot:
* rcar-gen3-thermal driver


Niklas Söderlund (7):
  thermal: rcar_gen3_thermal: add delay in .thermal_init on r8a7796
  thermal: rcar_gen3_thermal: remove unneeded mutex
  thermal: rcar_gen3_thermal: check that TSC exists before memory allocation
  thermal: rcar_gen3_thermal: record and check number of TSCs found
  thermal: rcar_gen3_thermal: enable hardware interrupts for trip points
  thermal: rcar_gen3_thermal: store device match data in private structure
  thermal: rcar_gen3_thermal: add suspend and resume support

Wolfram Sang (2):
  thermal: rcar_gen3_thermal: Document the R-Car Gen3
  thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

 .../bindings/thermal/rcar-gen3-thermal.txt |  56 +++
 drivers/thermal/Kconfig|   9 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/rcar_gen3_thermal.c| 504 +
 4 files changed, 570 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
 create mode 100644 drivers/thermal/rcar_gen3_thermal.c

The RZ/A1 pin controller driver will be broken for 4.13

2017-08-29 Thread Chris Brandt

Just FYI,

After pulling Geert's new renesas-drivers-2017-08-29-v4.13-rc7, I tried 
testing RZ/A1 and it hangs during boot.

Basically...

[  110.329579] pinctrl-rza1 fcfe3000.pin-controller: Parsed gpiochip gpio-0-0 
with 6 pins
[  112.970056] pinctrl-rza1 fcfe3000.pin-controller: Parsed gpiochip gpio-1-1 
with 16 pins
(hangs here forever)


After some debug, I found that this commit broke the new 
drivers/pinctrl/pinctrl-rza1.c driver.

 108d23e322a2 ("gpiolib: request the gpio before querying its direction")

Looks like it was added for -rc5.

If I revert that one patch, RZ/A1 boots fine.

Since we're at -rc7, I probably won't have time to fix it before the 
release.

Poor RZ/A1 pinctrl driver...it took so long to get into mainline, and 
then it only worked for 1 release.

:(


Chris

[renesas-drivers:topic/r8a7794-smp-v2 2/3] arch/arm/mach-shmobile/headsmp-apmu.S:24: Error: selected processor does not support `isb' in ARM mode

2017-08-29 Thread kbuild test robot

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
topic/r8a7794-smp-v2
head:   28ff1a758639895fd5cea127ba16f92ff3f30628
commit: 0cc5e107f08f1835b8fcd6bddf91a7259a7298ae [2/3] ARM: shmobile: 
rcar-gen2: Make sure CNTVOFF is initialized on CA7/15
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0cc5e107f08f1835b8fcd6bddf91a7259a7298ae
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   arch/arm/mach-shmobile/headsmp-apmu.S: Assembler messages:
>> arch/arm/mach-shmobile/headsmp-apmu.S:24: Error: selected processor does not 
>> support `isb' in ARM mode
   arch/arm/mach-shmobile/headsmp-apmu.S:27: Error: selected processor does not 
support `isb' in ARM mode
   arch/arm/mach-shmobile/headsmp-apmu.S:29: Error: selected processor does not 
support `isb' in ARM mode

vim +24 arch/arm/mach-shmobile/headsmp-apmu.S

13  
14  ENTRY(shmobile_init_cntvoff)
15  /*
16   * CNTVOFF has to be initialized either from non-secure 
Hypervisor
17   * mode or secure Monitor mode with SCR.NS==1. If TrustZone is 
enabled
18   * then it should be handled by the secure code
19   */
20  cps #MON_MODE
21  mrc p15, 0, r1, c1, c1, 0   /* Get Secure Config */
22  orr r0, r1, #1
23  mcr p15, 0, r0, c1, c1, 0   /* Set Non Secure bit */
  > 24  isb
25  mov r0, #0
26  mcrrp15, 4, r0, r0, c14 /* CNTVOFF = 0 */
27  isb
28  mcr p15, 0, r1, c1, c1, 0   /* Set Secure bit */
29  isb
30  cps #SVC_MODE
31  ret lr
32  ENDPROC(shmobile_init_cntvoff)
33  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v3] pinctrl: sh-pfc: r8a7795: Add SDHI0-3 support

2017-08-29 Thread Wolfram Sang

From: Takeshi Kihara 

Add SDHI0-3 support for R-Car H3 ES2.0 based on a patch from the Renesas
BSP. SDHI pin config is identical to H3 ES1.*.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Dirk Behme 
Signed-off-by: Wolfram Sang 
---

Changes since V2 (from Dirk):
* re-added Takeshi's SoB and authorship
* rebased to sh-pfc-for-v4.14-tag1
* reworded commit message
* did more testing

 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 275 +++
 1 file changed, 275 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 8b35772cda9864..b225bc2f9bea9f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -2734,6 +2734,213 @@ static const unsigned int scif5_clk_b_mux[] = {
SCK5_B_MARK,
 };
 
+/* - SDHI0 -- 
*/
+static const unsigned int sdhi0_data1_pins[] = {
+   /* D0 */
+   RCAR_GP_PIN(3, 2),
+};
+static const unsigned int sdhi0_data1_mux[] = {
+   SD0_DAT0_MARK,
+};
+static const unsigned int sdhi0_data4_pins[] = {
+   /* D[0:3] */
+   RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
+   RCAR_GP_PIN(3, 4), RCAR_GP_PIN(3, 5),
+};
+static const unsigned int sdhi0_data4_mux[] = {
+   SD0_DAT0_MARK, SD0_DAT1_MARK,
+   SD0_DAT2_MARK, SD0_DAT3_MARK,
+};
+static const unsigned int sdhi0_ctrl_pins[] = {
+   /* CLK, CMD */
+   RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
+};
+static const unsigned int sdhi0_ctrl_mux[] = {
+   SD0_CLK_MARK, SD0_CMD_MARK,
+};
+static const unsigned int sdhi0_cd_pins[] = {
+   /* CD */
+   RCAR_GP_PIN(3, 12),
+};
+static const unsigned int sdhi0_cd_mux[] = {
+   SD0_CD_MARK,
+};
+static const unsigned int sdhi0_wp_pins[] = {
+   /* WP */
+   RCAR_GP_PIN(3, 13),
+};
+static const unsigned int sdhi0_wp_mux[] = {
+   SD0_WP_MARK,
+};
+/* - SDHI1 -- 
*/
+static const unsigned int sdhi1_data1_pins[] = {
+   /* D0 */
+   RCAR_GP_PIN(3, 8),
+};
+static const unsigned int sdhi1_data1_mux[] = {
+   SD1_DAT0_MARK,
+};
+static const unsigned int sdhi1_data4_pins[] = {
+   /* D[0:3] */
+   RCAR_GP_PIN(3, 8),  RCAR_GP_PIN(3, 9),
+   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 11),
+};
+static const unsigned int sdhi1_data4_mux[] = {
+   SD1_DAT0_MARK, SD1_DAT1_MARK,
+   SD1_DAT2_MARK, SD1_DAT3_MARK,
+};
+static const unsigned int sdhi1_ctrl_pins[] = {
+   /* CLK, CMD */
+   RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
+};
+static const unsigned int sdhi1_ctrl_mux[] = {
+   SD1_CLK_MARK, SD1_CMD_MARK,
+};
+static const unsigned int sdhi1_cd_pins[] = {
+   /* CD */
+   RCAR_GP_PIN(3, 14),
+};
+static const unsigned int sdhi1_cd_mux[] = {
+   SD1_CD_MARK,
+};
+static const unsigned int sdhi1_wp_pins[] = {
+   /* WP */
+   RCAR_GP_PIN(3, 15),
+};
+static const unsigned int sdhi1_wp_mux[] = {
+   SD1_WP_MARK,
+};
+/* - SDHI2 -- 
*/
+static const unsigned int sdhi2_data1_pins[] = {
+   /* D0 */
+   RCAR_GP_PIN(4, 2),
+};
+static const unsigned int sdhi2_data1_mux[] = {
+   SD2_DAT0_MARK,
+};
+static const unsigned int sdhi2_data4_pins[] = {
+   /* D[0:3] */
+   RCAR_GP_PIN(4, 2), RCAR_GP_PIN(4, 3),
+   RCAR_GP_PIN(4, 4), RCAR_GP_PIN(4, 5),
+};
+static const unsigned int sdhi2_data4_mux[] = {
+   SD2_DAT0_MARK, SD2_DAT1_MARK,
+   SD2_DAT2_MARK, SD2_DAT3_MARK,
+};
+static const unsigned int sdhi2_data8_pins[] = {
+   /* D[0:7] */
+   RCAR_GP_PIN(4, 2),  RCAR_GP_PIN(4, 3),
+   RCAR_GP_PIN(4, 4),  RCAR_GP_PIN(4, 5),
+   RCAR_GP_PIN(3, 8),  RCAR_GP_PIN(3, 9),
+   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 11),
+};
+static const unsigned int sdhi2_data8_mux[] = {
+   SD2_DAT0_MARK, SD2_DAT1_MARK,
+   SD2_DAT2_MARK, SD2_DAT3_MARK,
+   SD2_DAT4_MARK, SD2_DAT5_MARK,
+   SD2_DAT6_MARK, SD2_DAT7_MARK,
+};
+static const unsigned int sdhi2_ctrl_pins[] = {
+   /* CLK, CMD */
+   RCAR_GP_PIN(4, 0), RCAR_GP_PIN(4, 1),
+};
+static const unsigned int sdhi2_ctrl_mux[] = {
+   SD2_CLK_MARK, SD2_CMD_MARK,
+};
+static const unsigned int sdhi2_cd_a_pins[] = {
+   /* CD */
+   RCAR_GP_PIN(4, 13),
+};
+static const unsigned int sdhi2_cd_a_mux[] = {
+   SD2_CD_A_MARK,
+};
+static const unsigned int sdhi2_cd_b_pins[] = {
+   /* CD */
+   RCAR_GP_PIN(5, 10),
+};
+static const unsigned int sdhi2_cd_b_mux[] = {
+   SD2_CD_B_MARK,
+};
+static const unsigned int sdhi2_wp_a_pins[] = {
+   /* WP */
+   RCAR_GP_PIN(4, 14),
+};
+static const unsigned int sdhi2_wp_a_mux[] = {
+   SD2_WP_A_MARK,
+};
+static const unsigned int sdhi2_wp_b_pins[] = {
+   /* WP */
+

Re: [RFT] arm64: dts: renesas: salvator-common: enable SDR104 for SD cards

2017-08-29 Thread Wolfram Sang


> As discussed in a chat, I tried SDR104 with my SDIO WiFi cards:
> 
> H3:
> - one slot worked flawlessly
> - one slot could load FW but failed to read status
> (with SDR50: both slots work)
> 
> M3-W:
> - both slots could not load the firmware
> (with SDR50: one slot works, one fails to load FW)

Update for my H3-ES2.0:

 - both slots could not load the firmware with SDR104
 (with SDR50: both slots work)

> The cards, however, were correctly identified as SDR104 and there were
> no tuning errors and no other SDHI related warnings.

This still holds true.



signature.asc
Description: PGP signature

RE: [PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support

2017-08-29 Thread Chris Paterson



> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 29 August 2017 15:59
> 
> On Tue, Aug 29, 2017 at 02:52:06PM +0100, Biju Das wrote:
> > Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI is
> > identical to the R-Car Gen2 family.
> >
> > Signed-off-by: Biju Das 
> > ---
> > DT binding patch for r8a7743/5 SoC is applied for mmc next. But the
> > driver patch is still not applied for mmc next.So resending the driver 
> > patch.
> 
> Didn't Chris Paterson volunteer to write a new patch introducing Gen2 generic
> compatibles? Or did I misunderstand?

I did :)

But after some off-ML discussion with Geert/Simon I decided to leave it to 
Simon as he's been doing a lot of similar work for all of the R-Car related 
drivers.

This may not happen immediately, and we already have the bindings/DT patches 
accepted based on this patch, hence the repost.

Sorry for the confusion!

> 
> >
> > This patch is compiled and tested against mmc/next.
> >
> >  drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > index 160fbb2..df44654 100644
> > --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > @@ -98,6 +98,8 @@
> > { .compatible = "renesas,sdhi-r7s72100", .data = _rz_compatible, },
> > { .compatible = "renesas,sdhi-r8a7778", .data =
> _rcar_gen1_compatible, },
> > { .compatible = "renesas,sdhi-r8a7779", .data =
> > _rcar_gen1_compatible, },
> > +   { .compatible = "renesas,sdhi-r8a7743", .data =
> _rcar_gen2_compatible, },
> > +   { .compatible = "renesas,sdhi-r8a7745", .data =
> > +_rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7790", .data =
> _rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7791", .data =
> _rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7792", .data =
> > _rcar_gen2_compatible, },
> > --
> > 1.9.1
> >

Re: [PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support

2017-08-29 Thread Wolfram Sang

On Tue, Aug 29, 2017 at 02:52:06PM +0100, Biju Das wrote:
> Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI
> is identical to the R-Car Gen2 family.
> 
> Signed-off-by: Biju Das 
> ---
> DT binding patch for r8a7743/5 SoC is applied for mmc next. But the driver 
> patch 
> is still not applied for mmc next.So resending the driver patch.

Didn't Chris Paterson volunteer to write a new patch introducing Gen2
generic compatibles? Or did I misunderstand?

> 
> This patch is compiled and tested against mmc/next.
> 
>  drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index 160fbb2..df44654 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> @@ -98,6 +98,8 @@
>   { .compatible = "renesas,sdhi-r7s72100", .data = _rz_compatible, },
>   { .compatible = "renesas,sdhi-r8a7778", .data = 
> _rcar_gen1_compatible, },
>   { .compatible = "renesas,sdhi-r8a7779", .data = 
> _rcar_gen1_compatible, },
> + { .compatible = "renesas,sdhi-r8a7743", .data = 
> _rcar_gen2_compatible, },
> + { .compatible = "renesas,sdhi-r8a7745", .data = 
> _rcar_gen2_compatible, },
>   { .compatible = "renesas,sdhi-r8a7790", .data = 
> _rcar_gen2_compatible, },
>   { .compatible = "renesas,sdhi-r8a7791", .data = 
> _rcar_gen2_compatible, },
>   { .compatible = "renesas,sdhi-r8a7792", .data = 
> _rcar_gen2_compatible, },
> -- 
> 1.9.1
> 


signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: r8a7795: Add OPPs table for cpu devices

2017-08-29 Thread Niklas Söderlund

Hi Simon,

Thanks for your patches and sorry for getting to this a bit late.

On 2017-08-04 15:26:20 +0200, Simon Horman wrote:
> From: Dien Pham 
> 
> Current, OPP tables are defined temporary,
> they are being evaluated and adjust in future.
> 
> Based in part on work by Hien Dang.
> 
> Signed-off-by: Dien Pham 
> Signed-off-by: Takeshi Kihara 
> [simon: consolidated sseveral patches into one]
> Signed-off-by: Simon Horman 
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 309 
> +++
>  1 file changed, 309 insertions(+)
> 
> I am not aware of any build-time depdendencies of this patch.
> 
> This patch has run-time depdnencies on:
> * [PATCH] cpufreq: rcar: Add support for R8A7795 SoC
> * [PATCH 0/4] r8a7795: Add Z and Z2 clock support
> 
> I have provided an integration patch with this patch, those DTS changes,
> and Renesas clock updates also depended on by the DTS changes. The result
> is working CPUFreq for the r8a7795 (R-Car H3) ES1.0.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> topic/r8a7795-cpufreq
> 
> A description of steps taken to lightly exercise the above can be found here:
> 
> http://elinux.org/Tests:R-CAR-GEN3-CPUFreq

I tested this it's working, nice!

> 
> If this work is acceptable I plan to follow up with patches to
> enable CPUFreq on the r8a7796 (R-Car M3-W).
> 
> This patch is based on renesas-arm64-dt-for-v4.14
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index a87ae76880ab..f34da4c9ea52 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -46,6 +46,12 @@
>   power-domains = < R8A7795_PD_CA57_CPU0>;
>   next-level-cache = <_CA57>;
>   enable-method = "psci";
> + clocks =< CPG_CORE R8A7795_CLK_Z>;
> + operating-points-v2 = <_opp_tb0>,
> + <_opp_tb1>, <_opp_tb2>,
> + <_opp_tb3>, <_opp_tb4>,
> + <_opp_tb5>, <_opp_tb6>,
> + <_opp_tb7>;

This however leaves me a bit confused. If I understand the bindings 
documentation you should only specify one phandle here. IIUC only the 
first one will be used anyhow, from drivers/base/power/opp/of.c

253 static struct device_node *_opp_of_get_opp_desc_node(struct device_node *np)
254 {
255 /*
256  * There should be only ONE phandle present in "operating-points-v2"
257  * property.
258  */
259 
260 return of_parse_phandle(np, "operating-points-v2", 0);
261 }

I tried to look at other sources and bindings and I can't find anywhere 
where more then one phandle could be useful, but I can have missed 
something? My interest in this is that I wish to hook it up with the 
thermal zones to have it act as passive cooling and implement the part 
of the BSP emergency shutdown driver using already available code and 
having more then one phandle here confuses me how to describe that in DT 
:-)

>   };
>  
>   a57_1: cpu@1 {
> @@ -55,6 +61,11 @@
>   power-domains = < R8A7795_PD_CA57_CPU1>;
>   next-level-cache = <_CA57>;
>   enable-method = "psci";
> + operating-points-v2 = <_opp_tb0>,
> + <_opp_tb1>, <_opp_tb2>,
> + <_opp_tb3>, <_opp_tb4>,
> + <_opp_tb5>, <_opp_tb6>,
> + <_opp_tb7>;
>   };
>  
>   a57_2: cpu@2 {
> @@ -64,6 +75,11 @@
>   power-domains = < R8A7795_PD_CA57_CPU2>;
>   next-level-cache = <_CA57>;
>   enable-method = "psci";
> + operating-points-v2 = <_opp_tb0>,
> + <_opp_tb1>, <_opp_tb2>,
> + <_opp_tb3>, <_opp_tb4>,
> + <_opp_tb5>, <_opp_tb6>,
> + <_opp_tb7>;
>   };
>  
>   a57_3: cpu@3 {
> @@ -73,6 +89,11 @@
>   power-domains = < R8A7795_PD_CA57_CPU3>;
>   next-level-cache = <_CA57>;
>   enable-method = "psci";
> + operating-points-v2 = <_opp_tb0>,
> + <_opp_tb1>, <_opp_tb2>,
> + <_opp_tb3>, <_opp_tb4>,
> + <_opp_tb5>, <_opp_tb6>,
> + <_opp_tb7>;
>   };
>  
>   a53_0: cpu@100 {
> @@ -82,6 +103,8 @@
>   power-domains = < R8A7795_PD_CA53_CPU0>;
>   next-level-cache = <_CA53>;
>

Re: [PATCH 00/20] Add multiplexed media pads to support CSI-2 virtual channels

2017-08-29 Thread Maxime Ripard

Hi Niklas,

On Fri, Aug 11, 2017 at 11:56:43AM +0200, Niklas Söderlund wrote:
> This series is a RFC for how I think one could add CSI-2 virtual channel 
> support to the V4L2 framework. The problem is that there is no way to in 
> the media framework describe and control links between subdevices which 
> carry more then one video stream, for example a CSI-2 bus which can have 
> 4 virtual channels carrying different video streams.
> 
> This series adds a new pad flag which would indicate that a pad carries 
> multiplexed streams, adds a new s_stream() operation to the pad 
> operations structure which takes a new argument 'stream'. This new 
> s_stream() operation then is both pad and stream aware. It also extends 
> struct v4l2_mbus_frame_desc_entry with a new sub-struct to describe how 
> a CSI-2 link multiplexes virtual channels. I also include one 
> implementation based on Renesas R-Car which makes use of these patches 
> as I think they help with understanding but they have no impact on the 
> RFC feature itself.
> 
> The idea is that on both sides of the multiplexed media link there are 
> one multiplexer subdevice and one demultiplexer subdevice. These two 
> subdevices can't do any format conversions, there sole purpose is to 
> (de)multiplex the CSI-2 link. If there is hardware which can do both 
> CSI-2 multiplexing and format conversions they can be modeled as two 
> subdevices from the same device driver and using the still pending 
> incremental async mechanism to connect the external pads. The reason 
> there is no format conversion is important as the multiplexed pads can't 
> have a format in the current V4L2 model, get/set_fmt are not aware of 
> streams.
> 
> +--+  +--+
>  +---+  subdev 1   |  |  subdev 2   +---+
>   +--+ Pad 1 | |  | | Pad 3 +---+
>  +--++   +-+---+  +---+-+   ++--+
> || Muxed pad A +--+ Muxed pad B ||
>  +--++   +-+---+  +---+-+   ++--+
>   +--+ Pad 2 | |  | | Pad 4 +---+
>  +---+ |  | +---+
> +--+  +--+
> 
> In the simple example above Pad 1 is routed to Pad 3 and Pad 2 to Pad 4, 
> and the video data for both of them travels the link between pad A and 
> B. One shortcoming of this RFC is that there currently are no way to 
> express to user-space which pad is routed to which stream of the 
> multiplexed link. But inside the kernel this is known and format 
> validation is done by comparing the format of Pad 1 to Pad 3 and Pad 2 
> to Pad 4 by the V4L2 framework. But it would be nice for the user to 
> also be able to get this information while setting up the MC graph in 
> user-space.

Thanks for your patches.

I guess I already have a different use-case for this, one you might
not have envisionned (on top of the Cadence CSI2-RX driver I've been
posting and that would need it at some point).

I have a CSI2-TX controller that I'm currently writing a driver
for. That controller takes 4 video streams in input, and aggregates
them on a single CSI-2 link. Those video streams use some kind of
parallel interfaces. So far, so good.

However, those parallel interfaces come with additional signals that
set the virtual channel and data types of the associated video
signal. Those signals are under control of the upstream video output
device, and can change at runtime.

The virtual channel are direcly mapped to the CSI-2 Virtual Channels,
so that part is completely transparent to the transmitter. However,
the video input datatype is a 0-7 value. Each data type value has a
separate set of registers where you need to set up the width and
height of the video data, and the corresponding CSI-2 Data Type.

You can use this to do some interleaving of either the virtual
channels or the data types, or both.

To make things (slightly) more complicated, the FIFO registers are
per-video input. Which means that while most of the (input)
configuration will be done per-datatype, we still have to know which
input stream is generating it, for example to optimise the FIFO fill
levels to the resolution...

Since the stream is multiplexed both using the virtual channels and
the data-types, I'm not sure representing it using only muxed pads
like you did would work.

And I don't really know what a good stop gap measure would be either.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

signature.asc
Description: PGP signature

[PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support

2017-08-29 Thread Biju Das

Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI
is identical to the R-Car Gen2 family.

Signed-off-by: Biju Das 
---
DT binding patch for r8a7743/5 SoC is applied for mmc next. But the driver 
patch 
is still not applied for mmc next.So resending the driver patch.

This patch is compiled and tested against mmc/next.

 drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index 160fbb2..df44654 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -98,6 +98,8 @@
{ .compatible = "renesas,sdhi-r7s72100", .data = _rz_compatible, },
{ .compatible = "renesas,sdhi-r8a7778", .data = 
_rcar_gen1_compatible, },
{ .compatible = "renesas,sdhi-r8a7779", .data = 
_rcar_gen1_compatible, },
+   { .compatible = "renesas,sdhi-r8a7743", .data = 
_rcar_gen2_compatible, },
+   { .compatible = "renesas,sdhi-r8a7745", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7790", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7791", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7792", .data = 
_rcar_gen2_compatible, },
-- 
1.9.1

renesas-drivers-2017-08-29-v4.13-rc7

2017-08-29 Thread Geert Uytterhoeven

I have pushed renesas-drivers-2017-08-29-v4.13-rc7 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20170828-v4.13-rc7.

Included branches with driver code:
  - clk-renesas-for-v4.14
  - sh-pfc-for-v4.14
  - topic/suspend-to-idle-v1
  - topic/sh-sh7722-sh7757-sh7264-sh7269-fix-pinctrl-v2
  - topic/r8a77995-integration
  - topic/r8a77970-integration
  - topic/r8a7794-smp-v2
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/rcar-gen3-z-clk
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/cpufreq-automatic
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/rcar-gen3-cpufreq-dts
  - git://git.ragnatech.se/linux#for-renesas-drivers
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#renesas/topic/i2c-fault-injection
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/tlb-optimise-v2

Included fixes:
  - of_mdio: Fix broken PHY IRQ in case of probe deferral
  - rcar-vin: Fix section mismatch from rcar_vin_probe()
  - media: rcar-csi2: Fix section mismatch from rcar_csi2_probe()

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next

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: clk: renesas: rcar-gen3: Status of Z* clocks?

2017-08-29 Thread Dirk Behme


On 29.08.2017 11:44, Geert Uytterhoeven wrote:

Hi Dirk,

On Tue, Aug 29, 2017 at 11:15 AM, Dirk Behme  wrote:

But ZG and with this module clock #112 is still missing, no?

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8=aa7b99b06d280e4151e

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8=a03bfd8abc9572800fb5043


The ZG bits in the FRQCRB register are documented to exist on R-Car D3
only.



... what contradicts

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8=a03bfd8abc9572800fb5043

and the 3DGE module clock in e.g. MSTPSR1 which is documented for H3 and 
M3-W, too, and Table 8.1a List of Clocks [R-Car H3] ZG -> 3DGE etc.


Best regards

Dirk

[PATCH v2 2/2] ARM: dts: iwg20d-q7: Add RTC support

2017-08-29 Thread Biju Das

Define the iWave RainboW-G20D-Qseven board dependent part of the
RTC device node.

Signed-off-by: Biju Das 
Signed-off-by: Chris Paterson 
---
v1-->v2
   * Added ti to bq32000 compatible string - Thanks Geert
   * Repositioned i2c2_pins node.

 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts 
b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index e30c586..2b58b53 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -50,6 +50,11 @@
 };
 
  {
+   i2c2_pins: i2c2 {
+   groups = "i2c2";
+   function = "i2c2";
+   };
+
scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
@@ -107,3 +112,16 @@
sd-uhs-sdr50;
status = "okay";
 };
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+   clock-frequency = <40>;
+
+   rtc@68 {
+   compatible = "ti,bq32000";
+   reg = <0x68>;
+   };
+};
-- 
1.9.1

[PATCH v2 0/2] ARM: dts: iwg20d-q7: Add Chosen node and RTC support

2017-08-29 Thread Biju Das

Hello,

Resending this patches because of the previous merge issues. 

This series has been tested against renesas dev tag 
renesas-devel-20170828-v4.13-rc7.

Biju Das (2):
  ARM: dts: iwg20d-q7: Add chosen node
  ARM: dts: iwg20d-q7: Add RTC support

 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 23 +++
 1 file changed, 23 insertions(+)

-- 
1.9.1

[PATCH v2 1/2] ARM: dts: iwg20d-q7: Add chosen node

2017-08-29 Thread Biju Das

Signed-off-by: Biju Das 
---
v1-->v2
Position the chosen node similar to r8a7791(R-Car M2) SoC.

 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts 
b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index 4ff27d2..e30c586 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -20,6 +20,11 @@
ethernet0 = 
};
 
+   chosen {
+   bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
+   stdout-path = "serial0:115200n8";
+   };
+
vcc_sdhi1: regulator-vcc-sdhi1 {
compatible = "regulator-fixed";
 
-- 
1.9.1

Re: clk: renesas: rcar-gen3: Status of Z* clocks?

2017-08-29 Thread Geert Uytterhoeven

Hi Dirk,

On Tue, Aug 29, 2017 at 11:15 AM, Dirk Behme  wrote:
> But ZG and with this module clock #112 is still missing, no?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8=aa7b99b06d280e4151e
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8=a03bfd8abc9572800fb5043

The ZG bits in the FRQCRB register are documented to exist on R-Car D3
only.

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: clk: renesas: rcar-gen3: Status of Z* clocks?

2017-08-29 Thread Dirk Behme


On 29.08.2017 10:01, Geert Uytterhoeven wrote:

Hi Dirk,

On Tue, Aug 29, 2017 at 9:51 AM, Dirk Behme  wrote:

as mentioned previously since ages I'm back looking at the RCar3 status in
recent mainline (4.13-rc7). While doing so, it looks to me that some Z*
clock patches from recent BSP

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/log/?h=v4.9/rcar-3.5.8

are not in mainline clock configuration, yet. E.g.:

Takeshi Kihara | clk: renesas: r8a7795: Add ZG clock
Takeshi Kihara | clk: renesas: r8a7795: Add ZG clock
Takeshi Kihara | clk: renesas: r8a7795: Add Z2 clock
Takeshi Kihara | clk: renesas: r8a7795: Add Z clock
Takeshi Kihara | clk: renesas: rcar-gen3: Adjust output of PLL4 as 3DGE
clock divider input
Takeshi Kihara | clk: renesas: rcar-gen3: Add ZG clock divider support
Dien Pham | clk: renesas: rcar-gen3: Add PLL0 clock errata workaround in
PLL0 clk driver
Dien Pham | clk: renesas: rcar-gen3: Add PLL0 clk driver support
Dien Pham | clk: renesas: rcar-gen3: Adjust output of PLL0, PLL2 as
SYSC-CPUs input
Takeshi Kihara | clk: renesas: rcar-gen3: Add Z2 clock divider support
Takeshi Kihara | clk: renesas: rcar-gen3: Add Z clock divider support

Are there any plans to pick these, already? Or, if not, would it be fine to
pick them from the BSP and just submit them here? Or is some major rework
needed?


Yes, this is WIP, cfr. "[PATCH v2 0/6] clk: renesas: r8a779[56]: Add Z and Z2
clock support" (https://www.spinics.net/lists/arm-kernel/msg602197.html).



Ok, many thanks! :)

But ZG and with this module clock #112 is still missing, no?

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8=aa7b99b06d280e4151e

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?h=v4.9/rcar-3.5.8=a03bfd8abc9572800fb5043

Best regards

Dirk

Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

2017-08-29 Thread Wolfram Sang


> I don't have a DT based system at hand now, but I'll test it again and
> let you know probably tomorrow.

I will try again today, too. Thanks!



signature.asc
Description: PGP signature

Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

2017-08-29 Thread Javier Martinez Canillas

Hello Wolfram,

On Mon, Aug 28, 2017 at 6:01 PM, Wolfram Sang  wrote:
>
>> > But there is a dependency, no? If I apply the driver patch,
>> > non-converted device trees will not find their eeproms anymore. So, I
>>
>> I don't think that's correct. If you apply this patch before the DTS
>> changes, the driver will still match using the I2C device ID table
>> like it has been doing it until today.
>
> My tests do not confirm this. If I add a node with a "renesas,24c01"
> compatible to my board, it works before your patch, but not after. If I
> change it to "atmel,24c01" it works even after your patch. I haven't
> looked into it, though, maybe i2c_of_match_device_sysfs() is stepping on
> our foots here?
>
> Did you test and did it work for you?
>

I would swear that I tested both combinations (driver patch without DT
changes and DTS changes without driver patch), but it was months ago
when I first posted the patches so I may misremembering.

I don't have a DT based system at hand now, but I'll test it again and
let you know probably tomorrow.

Best regards,
Javier

Re: clk: renesas: rcar-gen3: Status of Z* clocks?

2017-08-29 Thread Geert Uytterhoeven

Hi Dirk,

On Tue, Aug 29, 2017 at 9:51 AM, Dirk Behme  wrote:
> as mentioned previously since ages I'm back looking at the RCar3 status in
> recent mainline (4.13-rc7). While doing so, it looks to me that some Z*
> clock patches from recent BSP
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/log/?h=v4.9/rcar-3.5.8
>
> are not in mainline clock configuration, yet. E.g.:
>
> Takeshi Kihara | clk: renesas: r8a7795: Add ZG clock
> Takeshi Kihara | clk: renesas: r8a7795: Add ZG clock
> Takeshi Kihara | clk: renesas: r8a7795: Add Z2 clock
> Takeshi Kihara | clk: renesas: r8a7795: Add Z clock
> Takeshi Kihara | clk: renesas: rcar-gen3: Adjust output of PLL4 as 3DGE
> clock divider input
> Takeshi Kihara | clk: renesas: rcar-gen3: Add ZG clock divider support
> Dien Pham | clk: renesas: rcar-gen3: Add PLL0 clock errata workaround in
> PLL0 clk driver
> Dien Pham | clk: renesas: rcar-gen3: Add PLL0 clk driver support
> Dien Pham | clk: renesas: rcar-gen3: Adjust output of PLL0, PLL2 as
> SYSC-CPUs input
> Takeshi Kihara | clk: renesas: rcar-gen3: Add Z2 clock divider support
> Takeshi Kihara | clk: renesas: rcar-gen3: Add Z clock divider support
>
> Are there any plans to pick these, already? Or, if not, would it be fine to
> pick them from the BSP and just submit them here? Or is some major rework
> needed?

Yes, this is WIP, cfr. "[PATCH v2 0/6] clk: renesas: r8a779[56]: Add Z and Z2
clock support" (https://www.spinics.net/lists/arm-kernel/msg602197.html).

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

spi: sh-msiof: Status of fixes from BSP?

2017-08-29 Thread Dirk Behme


Hi,

as mentioned previously since ages I'm back looking at the RCar3 status 
in recent mainline (4.13-rc7). While doing so, it looks to me that some 
msiof fixes from recent BSP


https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/log/?h=v4.9/rcar-3.5.8

are not in mainline, yet. E.g.:

Hiromitsu Yamasaki | spi: sh-msiof: Add registers reset
Hiromitsu Yamasaki | spi: sh-msiof: Fix gpio function
Hiromitsu Yamasaki | spi: sh-msiof: Add MSIOF parent clock changing 
function for R-Car Gen3

Hiromitsu Yamasaki | spi: sh-msiof: Wait for Tx FIFO empty after DMA
Ryo Kataoka | spi: sh-msiof: Fix DMA completion
Ryo Kataoka | spi: sh-msiof: Fix MSIOF address for DMAC
Hiromitsu Yamasaki | spi: sh-msiof: Fix DMA transfer size check
Hiromitsu Yamasaki | spi: sh-msiof: Add sleep before master transfer for 
test


seem to be needed to make msiof in mainline work reliably on larger files.

Are there any plans to pick these, already? Or, if not, would it be fine 
to pick them from the BSP and just submit them here? Or is some major 
rework needed?


Best regards

Dirk

clk: renesas: rcar-gen3: Status of Z* clocks?

2017-08-29 Thread Dirk Behme


Hi,

as mentioned previously since ages I'm back looking at the RCar3 status 
in recent mainline (4.13-rc7). While doing so, it looks to me that some 
Z* clock patches from recent BSP


https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/log/?h=v4.9/rcar-3.5.8

are not in mainline clock configuration, yet. E.g.:

Takeshi Kihara | clk: renesas: r8a7795: Add ZG clock
Takeshi Kihara | clk: renesas: r8a7795: Add ZG clock
Takeshi Kihara | clk: renesas: r8a7795: Add Z2 clock
Takeshi Kihara | clk: renesas: r8a7795: Add Z clock
Takeshi Kihara | clk: renesas: rcar-gen3: Adjust output of PLL4 as 3DGE 
clock divider input

Takeshi Kihara | clk: renesas: rcar-gen3: Add ZG clock divider support
Dien Pham | clk: renesas: rcar-gen3: Add PLL0 clock errata workaround in 
PLL0 clk driver

Dien Pham | clk: renesas: rcar-gen3: Add PLL0 clk driver support
Dien Pham | clk: renesas: rcar-gen3: Adjust output of PLL0, PLL2 as 
SYSC-CPUs input

Takeshi Kihara | clk: renesas: rcar-gen3: Add Z2 clock divider support
Takeshi Kihara | clk: renesas: rcar-gen3: Add Z clock divider support

Are there any plans to pick these, already? Or, if not, would it be fine 
to pick them from the BSP and just submit them here? Or is some major 
rework needed?


Best regards

Dirk

Re: [PATCH] arm64: dts: r8a77995: update PFC node name to pin-controller

2017-08-29 Thread Geert Uytterhoeven

On Tue, Aug 29, 2017 at 9:35 AM, Yoshihiro Shimoda
 wrote:
> This patch changes the name from from e606.pfc and pfc@e606 to
> e606.pin-controller and pin-controller@e606 like other Renesas
> SoCs.
>
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Yoshihiro Shimoda 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH] arm64: dts: renesas: r8a77995: add pfc device node

2017-08-29 Thread Yoshihiro Shimoda

Hi Simon-san,

> -Original Message-
> From: Simon Horman
> Sent: Monday, August 28, 2017 11:05 PM
> 
> On Mon, Aug 28, 2017 at 10:39:47AM +0200, Geert Uytterhoeven wrote:
> > Hi Shimoda-san, Simon,
> >
> > On Wed, Aug 9, 2017 at 2:20 PM, Yoshihiro Shimoda
> >  wrote:
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >
> > >  This patch set is based on the renesas-drivers.git /
> > > topic/r8a77995-integration branch and depends on the following patch
> > >  "pinctrl: sh-pfc: r8a77995: Initial R8A77995 PFC support"
> > >
> > >  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
> > > b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > index 7419688..240b0f8 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > @@ -123,6 +123,11 @@
> > > reg = <0 0xe616 0 0x0200>;
> > > };
> > >
> > > +   pfc: pfc@e606 {
> >
> > Upon second look, this should use the generic "pin-controller@..." node 
> > name.
> > I will fix the example in the bindings.
> >
> > > +   compatible = "renesas,pfc-r8a77995";
> > > +   reg = <0 0xe606 0 0x508>;
> > > +   };
> 
> Shimoda-san, as this patch has been accepted for v4.14 could
> you please send a follow-up patch (for v4.15)?

Sure. I submitted a patch now.

Best regards,
Yoshihiro Shimoda

[PATCH] arm64: dts: r8a77995: update PFC node name to pin-controller

2017-08-29 Thread Yoshihiro Shimoda

This patch changes the name from from e606.pfc and pfc@e606 to
e606.pin-controller and pin-controller@e606 like other Renesas
SoCs.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index d0f95b7..72c3033 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -122,7 +122,7 @@
reg = <0 0xe616 0 0x0200>;
};
 
-   pfc: pfc@e606 {
+   pfc: pin-controller@e606 {
compatible = "renesas,pfc-r8a77995";
reg = <0 0xe606 0 0x508>;
};
-- 
1.9.1

Re: dt-bindings: watchdog: renesas-wdt: Add support for the r8a77995 wdt

Re: [RFC, 2/3] watchdog: renesas_wdt: make 'clk' a variable local to probe()

Re: [RFC,3/3] watchdog: renesas_wdt: update copyright dates

Re: [RFC, 1/3] watchdog: renesas_wdt: consistently use RuntimePM for clock management

[GIT PULL LTSI-4.9] Second Round of Renesas SoCs and Drivers to v4.12

The RZ/A1 pin controller driver will be broken for 4.13

[renesas-drivers:topic/r8a7794-smp-v2 2/3] arch/arm/mach-shmobile/headsmp-apmu.S:24: Error: selected processor does not support `isb' in ARM mode

[PATCH v3] pinctrl: sh-pfc: r8a7795: Add SDHI0-3 support

Re: [RFT] arm64: dts: renesas: salvator-common: enable SDR104 for SD cards

RE: [PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support

Re: [PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support

Re: [PATCH] arm64: dts: r8a7795: Add OPPs table for cpu devices

Re: [PATCH 00/20] Add multiplexed media pads to support CSI-2 virtual channels

[PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support

renesas-drivers-2017-08-29-v4.13-rc7

Re: clk: renesas: rcar-gen3: Status of Z* clocks?

[PATCH v2 2/2] ARM: dts: iwg20d-q7: Add RTC support

[PATCH v2 0/2] ARM: dts: iwg20d-q7: Add Chosen node and RTC support

[PATCH v2 1/2] ARM: dts: iwg20d-q7: Add chosen node

Re: clk: renesas: rcar-gen3: Status of Z* clocks?

Re: clk: renesas: rcar-gen3: Status of Z* clocks?

Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

Re: clk: renesas: rcar-gen3: Status of Z* clocks?

spi: sh-msiof: Status of fixes from BSP?

clk: renesas: rcar-gen3: Status of Z* clocks?

Re: [PATCH] arm64: dts: r8a77995: update PFC node name to pin-controller

RE: [PATCH] arm64: dts: renesas: r8a77995: add pfc device node

[PATCH] arm64: dts: r8a77995: update PFC node name to pin-controller

29 matches

Site Navigation

Mail list logo

Footer information