Re: Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks)

[Dirk Behme]

On 30.06.2017 22:24, Uwe Kleine-König wrote:

Hello,

On Fri, Jun 30, 2017 at 10:58:26AM -0500, Rob Herring wrote:

TL;DR: Clocks may be in use by another CPU not running Linux, while Linux
disables them as being unused.


not long ago I thought with a few colleagues about this. The scenario is
to start a Linux kernel on a Cortex-M companion to a Cortex-A.


On Mon, Jun 26, 2017 at 1:30 PM, Dirk Behme  wrote:

With commit 72f5df2c2bbb6 ("clk: renesas: cpg-mssr: Migrate to
CLK_IS_CRITICAL") we are able to handle critical module clocks.
Introduce the same logic for critical core clocks.

Signed-off-by: Dirk Behme 
---
Commit

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/renesas?id=72f5df2c2bbb66d4a555cb51eb9f412abf1af77f

is quite nice to avoid *module* clocks being disabled. Unfortunately,
there are *core* clocks, too. E.g. using an other OS on the Cortex R7
core of the r8a7795, the 'canfd' is a quite popular core clock which
shouldn't be disabled by Linux.

Therefore, this patch is a proposal to use the same 'mark clocks as
critical' logic implemented for the module clocks for the core
clocks, too.

Opinions?


On r8a7795, there are several Cortex A cores running Linux, and a Cortex R7
core which may run another OS.
This is an interesting issue, and relevant to other SoCs, too.

In this particular case, the "canfd" clock is a core clock used as an
auxiliary clock for the CAN0, CAN1, and CANFD interfaces.  This can lead
to three scenarios:
   1. Linux controls all CAN interfaces
  => no issue,
   2. The OS on the RT CPU controls all CAN interfaces
  => issue, Linux disables the clock
   3. Mix of 1 and 2
  => More issues.
Of course this is not limited to clocks, but also to e.g. PM domains.

How can this be handled?
I believe just marking the "canfd" clock critical is not the right solution,
as about any clock could be used by the RT CPU.

Still, Linux needs to be made aware that devices (clocks and PM domains) are
controlled by another CPU/OS.

Should this be described in DT? It feels like software policy to me.


No, it shouldn't. It is Linux policy to disable all unused clocks, so
Linux gets to deal with the consequences.


The ideal solution I imagine is to make the other CPU's OS a consumer of
the Linux clock driver. This would require a generic device driver on the
companion CPU that forwards clk requests via inter-cpu communication to
the Linux clk driver. It could be feed with the necessary information by
the rproc glue. So when the companion cpu is supposed to care for the
can0 device, the steps that should happen are:

  - make sure can0 isn't occupied by the Linux Host
  - reroute the can irq to the companion cpu (if necessary)
  - create a dtb containing something like this for the companion CPU:

clks: virtclk {
compatible = ???
#clock-cells = <1>;
...
};

can@$address {
compatible = ...
regs = ...
clocks = < 3>;
clock-names = ...
...
};

where the driver binding to the virtclk device just forwards clk
requests to the Linux host side which then knows that clk 3 is the
can clock and does the necessary stuff.

This way the can clock doesn't need special handling in the host's dtb
and no clock necessary for the companion is disabled as unused because
it is requested and enabled.

The only problem I see is that implementing such a driver/protocol
probably is time consuming.



The other problem is security related. If, at all, you have to do it 
the other way around, then:


Make Linux a consumer of the other CPU's (trusted/trustzone/whatever 
secured) OS clock driver.


Best regards

Dirk

Re: Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks)

[Uwe Kleine-König]

Hello,

On Fri, Jun 30, 2017 at 10:58:26AM -0500, Rob Herring wrote:
> > TL;DR: Clocks may be in use by another CPU not running Linux, while Linux
> > disables them as being unused.

not long ago I thought with a few colleagues about this. The scenario is
to start a Linux kernel on a Cortex-M companion to a Cortex-A.

> > On Mon, Jun 26, 2017 at 1:30 PM, Dirk Behme  wrote:
> >> With commit 72f5df2c2bbb6 ("clk: renesas: cpg-mssr: Migrate to
> >> CLK_IS_CRITICAL") we are able to handle critical module clocks.
> >> Introduce the same logic for critical core clocks.
> >>
> >> Signed-off-by: Dirk Behme 
> >> ---
> >> Commit
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/renesas?id=72f5df2c2bbb66d4a555cb51eb9f412abf1af77f
> >>
> >> is quite nice to avoid *module* clocks being disabled. Unfortunately,
> >> there are *core* clocks, too. E.g. using an other OS on the Cortex R7
> >> core of the r8a7795, the 'canfd' is a quite popular core clock which
> >> shouldn't be disabled by Linux.
> >>
> >> Therefore, this patch is a proposal to use the same 'mark clocks as
> >> critical' logic implemented for the module clocks for the core
> >> clocks, too.
> >>
> >> Opinions?
> >
> > On r8a7795, there are several Cortex A cores running Linux, and a Cortex R7
> > core which may run another OS.
> > This is an interesting issue, and relevant to other SoCs, too.
> >
> > In this particular case, the "canfd" clock is a core clock used as an
> > auxiliary clock for the CAN0, CAN1, and CANFD interfaces.  This can lead
> > to three scenarios:
> >   1. Linux controls all CAN interfaces
> >  => no issue,
> >   2. The OS on the RT CPU controls all CAN interfaces
> >  => issue, Linux disables the clock
> >   3. Mix of 1 and 2
> >  => More issues.
> > Of course this is not limited to clocks, but also to e.g. PM domains.
> >
> > How can this be handled?
> > I believe just marking the "canfd" clock critical is not the right solution,
> > as about any clock could be used by the RT CPU.
> >
> > Still, Linux needs to be made aware that devices (clocks and PM domains) are
> > controlled by another CPU/OS.
> >
> > Should this be described in DT? It feels like software policy to me.
> 
> No, it shouldn't. It is Linux policy to disable all unused clocks, so
> Linux gets to deal with the consequences.

The ideal solution I imagine is to make the other CPU's OS a consumer of
the Linux clock driver. This would require a generic device driver on the
companion CPU that forwards clk requests via inter-cpu communication to
the Linux clk driver. It could be feed with the necessary information by
the rproc glue. So when the companion cpu is supposed to care for the
can0 device, the steps that should happen are:

 - make sure can0 isn't occupied by the Linux Host
 - reroute the can irq to the companion cpu (if necessary)
 - create a dtb containing something like this for the companion CPU:

clks: virtclk {
compatible = ???
#clock-cells = <1>;
...
};

can@$address {
compatible = ...
regs = ...
clocks = < 3>;
clock-names = ...
...
};

   where the driver binding to the virtclk device just forwards clk
   requests to the Linux host side which then knows that clk 3 is the
   can clock and does the necessary stuff.

This way the can clock doesn't need special handling in the host's dtb
and no clock necessary for the companion is disabled as unused because
it is requested and enabled.

The only problem I see is that implementing such a driver/protocol
probably is time consuming.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH 3/8] clk: vc5: Do not warn about disabled output buffer input muxes

[Stephen Boyd]

On 06/29, Marek Vasut wrote:
> @@ -549,6 +552,7 @@ static unsigned char vc5_clk_out_get_parent(struct clk_hw 
> *hw)
>  
>   dev_warn(>client->dev,
>"Invalid clock output configuration (%02x)\n", src);
> +
>   return 0;
>  }
>  

Please drop this hunk as it isn't relevant to the patch.

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

Re: Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks)

[Rob Herring]

On Thu, Jun 29, 2017 at 4:27 AM, Geert Uytterhoeven
 wrote:
> Hi Dirk,
>
> CC clock, ARM, DT, PM people
>
> TL;DR: Clocks may be in use by another CPU not running Linux, while Linux
> disables them as being unused.
>
> On Mon, Jun 26, 2017 at 1:30 PM, Dirk Behme  wrote:
>> With commit 72f5df2c2bbb6 ("clk: renesas: cpg-mssr: Migrate to
>> CLK_IS_CRITICAL") we are able to handle critical module clocks.
>> Introduce the same logic for critical core clocks.
>>
>> Signed-off-by: Dirk Behme 
>> ---
>> Commit
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/renesas?id=72f5df2c2bbb66d4a555cb51eb9f412abf1af77f
>>
>> is quite nice to avoid *module* clocks being disabled. Unfortunately,
>> there are *core* clocks, too. E.g. using an other OS on the Cortex R7
>> core of the r8a7795, the 'canfd' is a quite popular core clock which
>> shouldn't be disabled by Linux.
>>
>> Therefore, this patch is a proposal to use the same 'mark clocks as
>> critical' logic implemented for the module clocks for the core
>> clocks, too.
>>
>> Opinions?
>
> On r8a7795, there are several Cortex A cores running Linux, and a Cortex R7
> core which may run another OS.
> This is an interesting issue, and relevant to other SoCs, too.
>
> In this particular case, the "canfd" clock is a core clock used as an
> auxiliary clock for the CAN0, CAN1, and CANFD interfaces.  This can lead
> to three scenarios:
>   1. Linux controls all CAN interfaces
>  => no issue,
>   2. The OS on the RT CPU controls all CAN interfaces
>  => issue, Linux disables the clock
>   3. Mix of 1 and 2
>  => More issues.
> Of course this is not limited to clocks, but also to e.g. PM domains.
>
> How can this be handled?
> I believe just marking the "canfd" clock critical is not the right solution,
> as about any clock could be used by the RT CPU.
>
> Still, Linux needs to be made aware that devices (clocks and PM domains) are
> controlled by another CPU/OS.
>
> Should this be described in DT? It feels like software policy to me.

No, it shouldn't. It is Linux policy to disable all unused clocks, so
Linux gets to deal with the consequences.

Rob

Re: [PATCH] pinctrl: rza1: Remove unneeded wrong check for wrong variable

[Linus Walleij]

On Fri, Jun 30, 2017 at 8:57 AM, Geert Uytterhoeven
 wrote:

> Depending on compiler version:
>
> drivers/pinctrl/pinctrl-rza1.c: In function ‘rza1_pinctrl_probe’:
> drivers/pinctrl/pinctrl-rza1.c:1260:5: warning: ‘ret’ may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>   if (ret)
>  ^
>
> Indeed, the result returned by platform_get_resource() was stored in
> "res", not "ret".  In addition, the correct error check would be
> "if (!res)", as platform_get_resource() does not return an error code,
> but returns NULL on failure.
>
> However, as devm_ioremap_resource() verifies the validity of the passed
> resource pointer anyway, the check can just be removed.
>
> Reported-by: Stephen Rothwell 
> Fixes: 5a49b644b3075f88 ("pinctrl: Renesas RZ/A1 pin and gpio controller")
> Signed-off-by: Geert Uytterhoeven 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v3] media: platform: rcar_imr: add IMR-LSX3 support

[Sergei Shtylyov]

On 06/30/2017 12:42 AM, Rob Herring wrote:


Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
only in the R-Car V2H (R8A7792) SoC.  It differs  from IMR-LX4 in that it
supports only planar video formats but can use the video capture data for
the textures.

Signed-off-by: Sergei Shtylyov 

---
This patch  is against the 'media_tree.git' repo's 'master' branch plus the
latest version of the Renesas IMR driver...

Changes in version 3:
- fixed compilation errors, resolved rejects, refreshed the patch atop of the
  IMR driver patch (version 6).

Changes in version 2:
- renamed *enum* 'imr_gen' to 'imr_type' and the *struct* field of this type
  from 'gen' to 'type';
- rename *struct* 'imr_type' to 'imr_info' and the fields/variables of this type
  from 'type' to 'info';
- added comments to IMR-LX4 only CMRCR2 bits;
- added IMR type check to the WTS instruction writing to CMRCCR2.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   11 +-


You missed my ack on v2.


   Sorry again, realized that just after posting v3.


 drivers/media/platform/rcar_imr.c|  101 +++
 2 files changed, 92 insertions(+), 20 deletions(-)


MBR, Sergei

Re: [PATCH] arm64: dts: r8a7796: Add DRIF support

[Simon Horman]

On Fri, Jun 30, 2017 at 10:28:09AM +, Ramesh Shanmugasundaram wrote:
> Hi Simon,
> 
> > Subject: Re: [PATCH] arm64: dts: r8a7796: Add DRIF support
> > 
> > On Tue, Jun 27, 2017 at 01:54:38PM +0100, Ramesh Shanmugasundaram wrote:
> > > Adds the DRIF controller nodes for r8a7796.
> > >
> > > Signed-off-by: Ramesh Shanmugasundaram
> > > 
> > > ---
> > > Hi Simon,
> > >
> > >This patch is based on renesas-devel-20170626-v4.12-rc7 tag.
> > >It is verified on M3 ES1.0. I also verified there are no regression
> > issues
> > >with this addition.
> > >
> > >The driver[1] is pushed into the media_tree. The bindings[2] are
> > ACK'ed
> > >by Geert & Rob and in the media_tree queue.
> > >
> > >[1]
> > https://git.linuxtv.org/media_tree.git/commit/?id=7625ee981af166ddb569e2e6
> > c0006e2af471326f
> > >[2]
> > > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg1560
> > > 2.html
> > >
> > > Thanks,
> > > Ramesh.
> > >
> > >  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 120
> > > +++
> > >  1 file changed, 120 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > > b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > > index 1f6710912045..df04d132a127 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > > @@ -639,6 +639,126 @@
> > >   };
> > >   };
> > >
> > > + drif00: rif@e6f4 {
> > > + compatible = "renesas,r8a7796-drif",
> > > +  "renesas,rcar-gen3-drif";
> > > + reg = <0 0xe6f4 0 0x64>;
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 515>;
> > > + clock-names = "fck";
> > > + dmas = < 0x20>, < 0x20>;
> > 
> > The dmas property seems a little strange. I would have expected to allow
> > ether dmac1 or dmac2 to be used for both tx and rx:
> > 
> > dmas = < 0x20>, < 0x20>,
> >< 0x20>, < 0x20>;
> > 
> 
> It is an rx-only interface that can use either dmac1 or 2.

Thanks, I see that clearly now.
I have applied this for v4.14.

> 
> > 
> > > + dma-names = "rx", "rx";
> > > + power-domains = < R8A7796_PD_ALWAYS_ON>;
> > > + resets = < 515>;
> > > + renesas,bonding = <>;
> > > + status = "disabled";
> > > + };
> > 
> 
> Thanks,
> Ramesh
> 

Re: [PATCH] arm64: dts: renesas: Move CPG_AUDIO_CLK_I from board to soc files

[Simon Horman]

On Fri, Jun 30, 2017 at 12:10:52PM +0300, Laurent Pinchart wrote:
> Hi Geert,
> 
> Thank you for the patch.
> 
> On Friday 30 Jun 2017 10:22:28 Geert Uytterhoeven wrote:
> > The definition of CPG_AUDIO_CLK_I is SoC-specific, not board-specific.
> > Hence move it from the board-specific .dts files to the SoC-specific
> > .dtsi files.
> > 
> > Signed-off-by: Geert Uytterhoeven 
> 
> Reviewed-by: Laurent Pinchart 
> 
> > ---
> > I don't think it's worth adding Fixes tags.
> > 
> > If you disagree, feel free to add:
> > 
> > Fixes: 79e3b5cf035e4734 ("arm64: dts: renesas: Add support for Salvator-XS
> > with R-Car H3 ES2.0") Fixes: fb5202dbebfd8fbf ("arm64: dts: r8a7795:
> > h3ulcb: Add support for R-Car H3 ES2.0") Fixes: 0b03c32db03d63de ("arm64:
> > dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0") Fixes:
> > 253ed045a34d16d9 ("arm64: dts: renesas: Extract common ULCB board support")
> > Fixes: d25e8ff0d5aaf8b1 ("arm64: dts: renesas: Extract common Salvator-X
> > board support") ---

I agree. I've applied this for v4.14 without the fixes tags.

Re: [renesas-drivers:topic/sdhi-gen3-dma-2017-v2-rebased1 3/4] drivers/mmc//host/renesas_sdhi_internal_dmac.c:96:2: error: implicit declaration of function 'writeq'

[Simon Horman]

On Wed, Jun 28, 2017 at 09:08:39PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Wed, Jun 28, 2017 at 9:04 PM, Simon Horman  wrote:
> > On Wed, Jun 28, 2017 at 11:37:02AM +0800, kbuild test robot wrote:
> >> tree:   
> >> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> >> topic/sdhi-gen3-dma-2017-v2-rebased1
> >> head:   bcf4bf9f75e02e84971693bce04e5c3775b0f97e
> >> commit: 6e76773921ebc2c58d7878a8cb3cb26e57f5ed06 [3/4] mmc: renesas-sdhi: 
> >> add support for R-Car Gen3 SDHI DMAC
> >> 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 6e76773921ebc2c58d7878a8cb3cb26e57f5ed06
> >> # save the attached .config to linux build tree
> >> make.cross ARCH=arm
> >>
> >> All errors (new ones prefixed by >>):
> >
> > This should be resolved in topic/sdhi-gen3-dma-2017-v3
> 
> IC. I guess I should use that branch (or a newer one) for next 
> renesas-drivers?

Yes, I guess so. v3 should be the latest. Let me know if you'd like me to
rebase it.

Re: [PATCH 1/2] ARM: dts: r8a7792: add IMR-L[S]X3 clocks

[Simon Horman]

On Thu, Jan 01, 1970 at 03:00:01AM +0300, Sergei Shtylyov wrote:
> Add the IMR-L[S]X3 clocks to the R8A7792 device tree.
> 
> Based on the original patch by Roman Meshkevich
> .
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  arch/arm/boot/dts/r8a7792.dtsi|   15 ---
>  include/dt-bindings/clock/r8a7792-clock.h |7 +++
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===
> --- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -927,16 +927,25 @@
>"renesas,cpg-mstp-clocks";
>   reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
>   clocks = <_clk>, <_clk>, <_clk>, <_clk>,
> -  <_clk>, <_clk>, <_clk>;
> +  <_clk>, <_clk>, <_clk>, <_clk>,
> +  <_clk>, <_clk>, <_clk>, <_clk>,
> +  <_clk>, <_clk>;
>   #clock-cells = <1>;
>   clock-indices = <
>   R8A7792_CLK_VIN5 R8A7792_CLK_VIN4
>   R8A7792_CLK_VIN3 R8A7792_CLK_VIN2
>   R8A7792_CLK_VIN1 R8A7792_CLK_VIN0
> - R8A7792_CLK_ETHERAVB
> + R8A7792_CLK_ETHERAVB R8A7792_CLK_IMR_LX3
> + R8A7792_CLK_IMR_LSX3_1 R8A7792_CLK_IMR_LSX3_0
> + R8A7792_CLK_IMR_LSX3_5 R8A7792_CLK_IMR_LSX3_4
> + R8A7792_CLK_IMR_LSX3_3 R8A7792_CLK_IMR_LSX3_2
>   >;
>   clock-output-names = "vin5", "vin4", "vin3", "vin2",
> -  "vin1", "vin0", "etheravb";
> +  "vin1", "vin0",
> +  "etheravb", "imr-lx3",
> +  "imr-lsx3-1", "imr-lsx3-0",
> +  "imr-lsx3-5", "imr-lsx3-4",
> +  "imr-lsx3-3", "imr-lsx3-2";
>   };
>   mstp9_clks: mstp9_clks@e6150994 {
>   compatible = "renesas,r8a7792-mstp-clocks",
> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
> ===
> --- renesas.orig/include/dt-bindings/clock/r8a7792-clock.h
> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
> @@ -70,6 +70,13 @@
>  #define R8A7792_CLK_VIN1 10
>  #define R8A7792_CLK_VIN0 11
>  #define R8A7792_CLK_ETHERAVB 12
> +#define R8A7792_CLK_IMR_LX3  21
> +#define R8A7792_CLK_IMR_LSX3_1   22
> +#define R8A7792_CLK_IMR_LSX3_0   23
> +#define R8A7792_CLK_IMR_LSX3_5   25
> +#define R8A7792_CLK_IMR_LSX3_4   26
> +#define R8A7792_CLK_IMR_LSX3_3   27
> +#define R8A7792_CLK_IMR_LSX3_2   28
>  
>  /* MSTP9 */
>  #define R8A7792_CLK_GPIO74
> 

I think this patch needs to be split in two, one for each file,
to allow queuing bindings and DT changes in different branches.

Re: [PATCH 1/4] mmc: tmio: remove obsolete TMIO_BBS

[Geert Uytterhoeven]

On Fri, Jun 30, 2017 at 12:56 PM, Wolfram Sang
 wrote:
> Since commit 10c7fcbd0f00a0 ("ARM: shmobile: sh7372: Remove ZBOOT
> MMC/SDHI support"), this define is not needed anymore.
>
> Signed-off-by: Wolfram Sang 

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

[PATCH 3/4] mmc: tmio: no magic values when enabling DMA

[Wolfram Sang]

Use a proper define.

Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/renesas_sdhi_core.c | 2 +-
 drivers/mmc/host/tmio_mmc.h  | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index be806d3e9afeec..dd215723fa4312 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -459,7 +459,7 @@ static int renesas_sdhi_multi_io_quirk(struct mmc_card 
*card,
 
 static void renesas_sdhi_enable_dma(struct tmio_mmc_host *host, bool enable)
 {
-   sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? 2 : 0);
+   sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
 
/* enable 32bit access if DMA mode if possibile */
renesas_sdhi_sdbuf_width(host, enable ? 32 : 16);
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index e3e96178acaab4..3e6ff892144034 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -97,6 +97,9 @@
 
 #define TMIO_SDIO_SETBITS_MASK 0x0006
 
+/* Definitions for values the CTL_DMA_ENABLE register can take */
+#define DMA_ENABLE_DMASDRW BIT(1)
+
 /* Define some IRQ masks */
 /* This is the mask used at reset by the chip */
 #define TMIO_MASK_ALL   0x837f031d
-- 
2.11.0

[PATCH 1/4] mmc: tmio: remove obsolete TMIO_BBS

[Wolfram Sang]

Since commit 10c7fcbd0f00a0 ("ARM: shmobile: sh7372: Remove ZBOOT
MMC/SDHI support"), this define is not needed anymore.

Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/tmio_mmc.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 2479f8e12faf5e..b161dfadfec25d 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -87,8 +87,6 @@
 #define CARD_OPT_WIDTH8BIT(13)
 #define CARD_OPT_WIDTH BIT(15)
 
-#define TMIO_BBS   512 /* Boot block size */
-
 /* Definitions for values the CTL_SDIO_STATUS register can take */
 #define TMIO_SDIO_STAT_IOIRQ   0x0001
 #define TMIO_SDIO_STAT_EXPUB52 0x4000
-- 
2.11.0

[PATCH 2/4] mmc: tmio: add references to bit defines in the header

[Wolfram Sang]

When defining bits, make sure we always have a reference to the register
they belong to. For now, renaming all bits properly seems too intrusive,
so at least make sure we have proper documentation.

Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/tmio_mmc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index b161dfadfec25d..e3e96178acaab4 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -81,9 +81,11 @@
 #define TMIO_STAT_CMD_BUSY  BIT(30)
 #define TMIO_STAT_ILL_ACCESSBIT(31)
 
+/* Definitions for values the CTL_SD_CARD_CLK_CTL register can take */
 #defineCLK_CTL_DIV_MASK0xff
 #defineCLK_CTL_SCLKEN  BIT(8)
 
+/* Definitions for values the CTL_SD_MEM_CARD_OPT register can take */
 #define CARD_OPT_WIDTH8BIT(13)
 #define CARD_OPT_WIDTH BIT(15)
 
-- 
2.11.0

[PATCH 0/4] tmio/sdhi: use max sd_buf size & clean header file before

[Wolfram Sang]

From: Wolfram Sang 

The main patch is patch 4 which uses the maximum sd_buf size, i.e. 32 bit on
Gen2 and 64 bit on Gen3. Instead of a new flag, we use the bus_shift
information we already have. See the patch description for details.

Before fixing this, I wanted to remove a magic value in that function which is
done in patch 3.

When adding the new define, I noticed that some description is missing in the
header which is fixed with patch 2.

When adding the description, I noticed this meanwhile obsolete define which
gets removed in patch 1.

That's the way it went :)

Tested on Salvator-X/M3-W and Lager/H2.

Regards,

   Wolfram

Wolfram Sang (4):
  mmc: tmio: remove obsolete TMIO_BBS
  mmc: tmio: add references to bit defines in the header
  mmc: tmio: no magic values when enabling DMA
  mmc: sdhi: use maximum width for the sdbuf register

 drivers/mmc/host/renesas_sdhi_core.c | 5 ++---
 drivers/mmc/host/tmio_mmc.h  | 7 +--
 2 files changed, 7 insertions(+), 5 deletions(-)

-- 
2.11.0

[PATCH 4/4] mmc: sdhi: use maximum width for the sdbuf register

[Wolfram Sang]

We can derive the sd_buf width from the bus_shift parameter which tells
us how far registers are apart. Remove the obvious comment, too.

Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/renesas_sdhi_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index dd215723fa4312..48da28dfef6465 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -461,8 +461,7 @@ static void renesas_sdhi_enable_dma(struct tmio_mmc_host 
*host, bool enable)
 {
sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
 
-   /* enable 32bit access if DMA mode if possibile */
-   renesas_sdhi_sdbuf_width(host, enable ? 32 : 16);
+   renesas_sdhi_sdbuf_width(host, enable ? (16 << host->bus_shift) : 16);
 }
 
 int renesas_sdhi_probe(struct platform_device *pdev,
-- 
2.11.0

Re: [PATCH 1/2] ARM: dts: r8a7792: add IMR-L[S]X3 clocks

[Geert Uytterhoeven]

On Fri, Jun 30, 2017 at 12:01 PM, Simon Horman  wrote:
> On Thu, Jan 01, 1970 at 03:00:01AM +0300, Sergei Shtylyov wrote:
>> Add the IMR-L[S]X3 clocks to the R8A7792 device tree.
>>
>> Based on the original patch by Roman Meshkevich
>> .
>>
>> Signed-off-by: Sergei Shtylyov 
>>
>> ---
>>  arch/arm/boot/dts/r8a7792.dtsi|   15 ---
>>  include/dt-bindings/clock/r8a7792-clock.h |7 +++
>>  2 files changed, 19 insertions(+), 3 deletions(-)
>>
>> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
>> ===
>> --- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
>> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
>> @@ -927,16 +927,25 @@
>>"renesas,cpg-mstp-clocks";
>>   reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
>>   clocks = <_clk>, <_clk>, <_clk>, <_clk>,
>> -  <_clk>, <_clk>, <_clk>;
>> +  <_clk>, <_clk>, <_clk>, <_clk>,
>> +  <_clk>, <_clk>, <_clk>, <_clk>,
>> +  <_clk>, <_clk>;
>>   #clock-cells = <1>;
>>   clock-indices = <
>>   R8A7792_CLK_VIN5 R8A7792_CLK_VIN4
>>   R8A7792_CLK_VIN3 R8A7792_CLK_VIN2
>>   R8A7792_CLK_VIN1 R8A7792_CLK_VIN0
>> - R8A7792_CLK_ETHERAVB
>> + R8A7792_CLK_ETHERAVB R8A7792_CLK_IMR_LX3
>> + R8A7792_CLK_IMR_LSX3_1 R8A7792_CLK_IMR_LSX3_0
>> + R8A7792_CLK_IMR_LSX3_5 R8A7792_CLK_IMR_LSX3_4
>> + R8A7792_CLK_IMR_LSX3_3 R8A7792_CLK_IMR_LSX3_2
>>   >;
>>   clock-output-names = "vin5", "vin4", "vin3", "vin2",
>> -  "vin1", "vin0", "etheravb";
>> +  "vin1", "vin0",
>> +  "etheravb", "imr-lx3",
>> +  "imr-lsx3-1", "imr-lsx3-0",
>> +  "imr-lsx3-5", "imr-lsx3-4",
>> +  "imr-lsx3-3", "imr-lsx3-2";
>>   };
>>   mstp9_clks: mstp9_clks@e6150994 {
>>   compatible = "renesas,r8a7792-mstp-clocks",
>> Index: renesas/include/dt-bindings/clock/r8a7792-clock.h
>> ===
>> --- renesas.orig/include/dt-bindings/clock/r8a7792-clock.h
>> +++ renesas/include/dt-bindings/clock/r8a7792-clock.h
>> @@ -70,6 +70,13 @@
>>  #define R8A7792_CLK_VIN1 10
>>  #define R8A7792_CLK_VIN0 11
>>  #define R8A7792_CLK_ETHERAVB 12
>> +#define R8A7792_CLK_IMR_LX3  21
>> +#define R8A7792_CLK_IMR_LSX3_1   22
>> +#define R8A7792_CLK_IMR_LSX3_0   23
>> +#define R8A7792_CLK_IMR_LSX3_5   25
>> +#define R8A7792_CLK_IMR_LSX3_4   26
>> +#define R8A7792_CLK_IMR_LSX3_3   27
>> +#define R8A7792_CLK_IMR_LSX3_2   28
>>
>>  /* MSTP9 */
>>  #define R8A7792_CLK_GPIO74
>>
>
> I think this patch needs to be split in two, one for each file,
> to allow queuing bindings and DT changes in different branches.

I don't know if it's worth still adding this.
About 47 years after the original patch date, my plan is to convert r8a7792.dtsi
to the new CPG/MSSR bindings, cfr. latest renesas-drivers.

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: r8a7796: Add DRIF support

[Ramesh Shanmugasundaram]

Hi Simon,

> Subject: Re: [PATCH] arm64: dts: r8a7796: Add DRIF support
> 
> On Tue, Jun 27, 2017 at 01:54:38PM +0100, Ramesh Shanmugasundaram wrote:
> > Adds the DRIF controller nodes for r8a7796.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> > ---
> > Hi Simon,
> >
> >This patch is based on renesas-devel-20170626-v4.12-rc7 tag.
> >It is verified on M3 ES1.0. I also verified there are no regression
> issues
> >with this addition.
> >
> >The driver[1] is pushed into the media_tree. The bindings[2] are
> ACK'ed
> >by Geert & Rob and in the media_tree queue.
> >
> >[1]
> https://git.linuxtv.org/media_tree.git/commit/?id=7625ee981af166ddb569e2e6
> c0006e2af471326f
> >[2]
> > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg1560
> > 2.html
> >
> > Thanks,
> > Ramesh.
> >
> >  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 120
> > +++
> >  1 file changed, 120 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > index 1f6710912045..df04d132a127 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > @@ -639,6 +639,126 @@
> > };
> > };
> >
> > +   drif00: rif@e6f4 {
> > +   compatible = "renesas,r8a7796-drif",
> > +"renesas,rcar-gen3-drif";
> > +   reg = <0 0xe6f4 0 0x64>;
> > +   interrupts = ;
> > +   clocks = < CPG_MOD 515>;
> > +   clock-names = "fck";
> > +   dmas = < 0x20>, < 0x20>;
> 
> The dmas property seems a little strange. I would have expected to allow
> ether dmac1 or dmac2 to be used for both tx and rx:
> 
>   dmas = < 0x20>, < 0x20>,
>  < 0x20>, < 0x20>;
> 

It is an rx-only interface that can use either dmac1 or 2.

> 
> > +   dma-names = "rx", "rx";
> > +   power-domains = < R8A7796_PD_ALWAYS_ON>;
> > +   resets = < 515>;
> > +   renesas,bonding = <>;
> > +   status = "disabled";
> > +   };
> 

Thanks,
Ramesh

Re: [PATCH] arm64: dts: r8a7796: Add DRIF support

[Simon Horman]

On Tue, Jun 27, 2017 at 01:54:38PM +0100, Ramesh Shanmugasundaram wrote:
> Adds the DRIF controller nodes for r8a7796.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
> Hi Simon,
> 
>This patch is based on renesas-devel-20170626-v4.12-rc7 tag.
>It is verified on M3 ES1.0. I also verified there are no regression issues
>with this addition.
> 
>The driver[1] is pushed into the media_tree. The bindings[2] are ACK'ed
>by Geert & Rob and in the media_tree queue.
> 
>[1] 
> https://git.linuxtv.org/media_tree.git/commit/?id=7625ee981af166ddb569e2e6c0006e2af471326f
>[2] 
> https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg15602.html
> 
> Thanks,
> Ramesh.
> 
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 120 
> +++
>  1 file changed, 120 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> index 1f6710912045..df04d132a127 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -639,6 +639,126 @@
>   };
>   };
>  
> + drif00: rif@e6f4 {
> + compatible = "renesas,r8a7796-drif",
> +  "renesas,rcar-gen3-drif";
> + reg = <0 0xe6f4 0 0x64>;
> + interrupts = ;
> + clocks = < CPG_MOD 515>;
> + clock-names = "fck";
> + dmas = < 0x20>, < 0x20>;

The dmas property seems a little strange. I would have expected to allow
ether dmac1 or dmac2 to be used for both tx and rx:

dmas = < 0x20>, < 0x20>,
   < 0x20>, < 0x20>;


> + dma-names = "rx", "rx";
> + power-domains = < R8A7796_PD_ALWAYS_ON>;
> + resets = < 515>;
> + renesas,bonding = <>;
> + status = "disabled";
> + };

...

Re: [PATCH v2] arm64: dts: r8a7795: add IMR-LX4 support

[Simon Horman]

On Tue, Jun 27, 2017 at 08:30:53PM +0300, Sergei Shtylyov wrote:
> Describe the IMR-LX4 devices in the R8A7795 device tree.
> 
> Based on the original (and large) patch by Konstantin Kozhevnikov
> .
> 
> Signed-off-by: Konstantin Kozhevnikov 
> 
> Signed-off-by: Sergei Shtylyov 
> Reviewed-by: Geert Uytterhoeven 
> 
> ---
> This patch is against the 'renesas-devel-20170626-v4.12-rc7' tag of Simon
> Horman's 'renesas.git' repo.
> 
> The IMR-LX4 bindings were documented in the IMR driver patch and ACK'ed by Rob
> Herring, so I don't expect them to change...

Thanks Sergei,

applied for v4.14.

Re: [PATCH 1/2] ARM: dts: r8a7792: add IMR-L[S]X3 clocks

[Simon Horman]

On Wed, Jun 28, 2017 at 11:49:01PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 03/29/2017 11:04 AM, Simon Horman wrote:
> 
> >>>Still not cover letter but I think it's better now, so I won't retry...
> >>>The patches are against Simon Horman's 'renesas.git' repo,
> >>>'renesas-devel-20170321-v4.11-rc3' tag.
> >>
> >>   The patches depend on the IMR driver patches adding the IMR-L[S]X3
> >>support for the "compatible" values.
> >
> >I have marked these patches as deferred accordingly.
> 
>Actually, the 1st patch in htis series doesn't depend on anything and
> should still apply (with offsets).

I'd prefer to take both patches at the same time unless there is a strong
motivation to just take the first one.

Re: [PATCH v3 2/4] media: adv7180: add adv7180cp, adv7180st compatible strings

[Geert Uytterhoeven]

Hi Ulrich,

On Fri, May 19, 2017 at 3:07 PM, Ulrich Hecht
 wrote:
> Used to differentiate between models with 3 and 6 inputs.
>
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/media/i2c/adv7180.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index bdbbf8c..78de7dd 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -1452,6 +1452,8 @@ static SIMPLE_DEV_PM_OPS(adv7180_pm_ops, 
> adv7180_suspend, adv7180_resume);
>  #ifdef CONFIG_OF
>  static const struct of_device_id adv7180_of_id[] = {
> { .compatible = "adi,adv7180", },
> +   { .compatible = "adi,adv7180cp", },
> +   { .compatible = "adi,adv7180st", },
> { .compatible = "adi,adv7182", },
> { .compatible = "adi,adv7280", },
> { .compatible = "adi,adv7280-m", },

Adding compatible entries here is not sufficient, and causes a crash on
r8a7793/gose with renesas-drivers-2017-06-27-v4.12-rc7:

adv7180 2-0020: chip found @ 0x20 (e653.i2c)
Unable to handle kernel NULL pointer dereference at virtual address 0014
pgd = c0003000
[0014] *pgd=8040004003, *pmd=
Internal error: Oops: 207 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc7-rcar2-initrd #37
Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
task: df427040 task.stack: df436000
PC is at adv7180_probe+0x84/0x3cc

In the absence of an entry in adv7180_id[], the passed i2c_device_id
pointer is NULL, and thus dereferencing it crashes the system.

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] arm64: renesas: salvator-common: sound clock-frequency needs descending order

[Simon Horman]

From: Kuninori Morimoto 

It will be used ADG clock initial settings, and will be
sound codec's initial system clock which needs maximum clock frequency.
Thus, descending order is required

Fixes: d37d2b3c0ec2708a ("arm64: dts: salvator-x: add 12288000 for sound ADG")
Fixes: 0b03c32db03d63de ("arm64: dts: r8a7795: salvator-x: Add support for 
R-Car H3 ES2.0")
Signed-off-by: Kuninori Morimoto 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index aef35e0b685a..a451996f590a 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -508,7 +508,7 @@
 
/* audio_clkout0/1/2/3 */
#clock-cells = <1>;
-   clock-frequency = <11289600 12288000>;
+   clock-frequency = <12288000 11289600>;
 
status = "okay";
 
-- 
2.1.4

[GIT PULL] Renesas ARM Based SoC Fixes for v4.13

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider this Renesas ARM based SoC fix for v4.13.

This pull request is based on
"[GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.13",
tagged as renesas-arm64-dt2-for-v4.13, which you have already pulled.

It is my understanding that the problem fixed was introduced
earlier in the v4.13 development cycle. So I don't think consideration
needs to be given to merging for to v4.12 or back-porting to -stable.


The following changes since commit 4d1255ebefb6838eab4f652107433438bea0051f:

  arm64: dts: r8a7796: Add reset control properties for audio (2017-06-14 
11:00:29 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-fixes-for-v4.13

for you to fetch changes up to 5e2feac330953fe75197aecb20c781400e2bf606:

  arm64: renesas: salvator-common: sound clock-frequency needs descending order 
(2017-06-19 11:18:33 +0200)


Renesas ARM Based SoC Fixes for v4.13

Correct order of sound clock frequencies for Salvator boards
used by r8a7795 and r8a7796 SoCs.

These sounds clock frequencies are used as the ADG clock (output clocks
for audio module) initial setting and sound codec's initial system clock
which needs the maximum clock frequency. Thus, descending order is
required.


Kuninori Morimoto (1):
  arm64: renesas: salvator-common: sound clock-frequency needs descending 
order

 arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH] drm: rcar-du: remove an unneeded NULL check

[Laurent Pinchart]

Hi Dan,

Thank you for the patch.

On Friday 30 Jun 2017 11:00:12 Dan Carpenter wrote:
> "params" can't be NULL here.  The next lines assume that we either
> hit the break statement of "params->mpixelclock == ~0UL".  The
> inconsistent NULL checking makes static checkers complain.  I've just
> removed the test.
> 
> Signed-off-by: Dan Carpenter 

Reviewed-by: Laurent Pinchart 

and taken in my tree for v4.14.

> diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c index 7539626b8ebd..dc85b53d58ef
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -45,7 +45,7 @@ static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
>  {
>   const struct rcar_hdmi_phy_params *params = rcar_hdmi_phy_params;
> 
> - for (; params && params->mpixelclock != ~0UL; ++params) {
> + for (; params->mpixelclock != ~0UL; ++params) {
>   if (mpixelclock <= params->mpixelclock)
>   break;
>   }

-- 
Regards,

Laurent Pinchart

Re: [PATCH] arm64: dts: renesas: Move CPG_AUDIO_CLK_I from board to soc files

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Friday 30 Jun 2017 10:22:28 Geert Uytterhoeven wrote:
> The definition of CPG_AUDIO_CLK_I is SoC-specific, not board-specific.
> Hence move it from the board-specific .dts files to the SoC-specific
> .dtsi files.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Laurent Pinchart 

> ---
> I don't think it's worth adding Fixes tags.
> 
> If you disagree, feel free to add:
> 
> Fixes: 79e3b5cf035e4734 ("arm64: dts: renesas: Add support for Salvator-XS
> with R-Car H3 ES2.0") Fixes: fb5202dbebfd8fbf ("arm64: dts: r8a7795:
> h3ulcb: Add support for R-Car H3 ES2.0") Fixes: 0b03c32db03d63de ("arm64:
> dts: r8a7795: salvator-x: Add support for R-Car H3 ES2.0") Fixes:
> 253ed045a34d16d9 ("arm64: dts: renesas: Extract common ULCB board support")
> Fixes: d25e8ff0d5aaf8b1 ("arm64: dts: renesas: Extract common Salvator-X
> board support") ---
>  arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts | 2 --
>  arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts | 2 --
>  arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 --
>  arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 --
>  arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts| 2 --
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 2 ++
>  arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 2 --
>  arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 2 --
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi   | 2 ++
>  9 files changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts index
> 95fe207cb6a3fd2f..dd4f9b6a42546def 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
> @@ -9,8 +9,6 @@
>   * kind, whether express or implied.
>   */
> 
> -#define CPG_AUDIO_CLK_I  R8A7795_CLK_S0D4
> -
>  /dts-v1/;
>  #include "r8a7795-es1.dtsi"
>  #include "ulcb.dtsi"
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts index
> b84c156ed6969947..3f7d5f51e42878cb 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
> @@ -8,8 +8,6 @@
>   * kind, whether express or implied.
>   */
> 
> -#define CPG_AUDIO_CLK_I  R8A7795_CLK_S0D4
> -
>  /dts-v1/;
>  #include "r8a7795-es1.dtsi"
>  #include "salvator-x.dtsi"
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts index
> 0426f41765f0bc68..27d4b1a4c4754732 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> @@ -9,8 +9,6 @@
>   * kind, whether express or implied.
>   */
> 
> -#define CPG_AUDIO_CLK_I  R8A7795_CLK_S0D4
> -
>  /dts-v1/;
>  #include "r8a7795.dtsi"
>  #include "ulcb.dtsi"
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index
> 684fb3b9d154559e..17953070f38dff8d 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> @@ -8,8 +8,6 @@
>   * kind, whether express or implied.
>   */
> 
> -#define CPG_AUDIO_CLK_I  R8A7795_CLK_S0D4
> -
>  /dts-v1/;
>  #include "r8a7795.dtsi"
>  #include "salvator-x.dtsi"
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts index
> de354957144b4822..6a7d1b22d0fecc9c 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
> @@ -8,8 +8,6 @@
>   * kind, whether express or implied.
>   */
> 
> -#define CPG_AUDIO_CLK_I  R8A7795_CLK_S0D4
> -
>  /dts-v1/;
>  #include "r8a7795.dtsi"
>  #include "salvator-xs.dtsi"
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index
> 5ec03641d9873f22..6b75d4b9ce7efa49 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -12,6 +12,8 @@
>  #include 
>  #include 
> 
> +#define CPG_AUDIO_CLK_I  R8A7795_CLK_S0D4
> +
>  / {
>   compatible = "renesas,r8a7795";
>   #address-cells = <2>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts index
> 38b58b7fca4bf0e9..1ff9dffae4618a5a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> @@ -9,8 +9,6 @@
>   * kind, whether express or implied.
>   */
> 
> -#define CPG_AUDIO_CLK_I  R8A7796_CLK_S0D4
> -
>  /dts-v1/;
>  #include "r8a7796.dtsi"
>  #include "ulcb.dtsi"
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts

Re: timeout waiting for hardware interrupt CMD19

[Geert Uytterhoeven]

Hi Wolfram,

On Mon, Mar 13, 2017 at 12:12 PM, Wolfram Sang  wrote:
>> +sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
>> +sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
>> +sh_mobile_sdhi ee10.sd: Tuning procedure failed
>> +mmc1: tuning execution failed: -110
>> +mmc1: error -110 whilst initialising SD card
>
> Thanks! We have some tuning fixes in the queue. Let's see if they help
> here...

With renesas-drivers-2017-06-27-v4.12-rc7 on ALT:

sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: Tuning procedure failed
mmc1: tuning execution failed: -110
mmc1: error -110 whilst initialising SD card
random: fast init done
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: Tuning procedure failed
mmc1: tuning execution failed: -110
mmc1: error -110 whilst initialising SD card
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: Tuning procedure failed
mmc1: tuning execution failed: -110
mmc1: error -110 whilst initialising SD card
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: Tuning procedure failed
mmc1: tuning execution failed: -110
mmc1: error -110 whilst initialising SD card
[ cut here ]
WARNING: CPU: 0 PID: 19 at lib/dma-debug.c:519 add_dma_entry+0xfc/0x148
DMA-API: exceeded 7 overlapping mappings of cacheline 0x01b97cca
Modules linked in:
CPU: 0 PID: 19 Comm: kworker/0:1 Not tainted 4.12.0-rc7-rcar2-initrd #37
Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
Workqueue: events_freezable mmc_rescan
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x7c/0x9c)
[] (dump_stack) from [] (__warn+0xcc/0xfc)
[] (__warn) from [] (warn_slowpath_fmt+0x34/0x44)
[] (warn_slowpath_fmt) from [] (add_dma_entry+0xfc/0x148)
[] (add_dma_entry) from [] (debug_dma_map_sg+0x140/0x168)
[] (debug_dma_map_sg) from []
(renesas_sdhi_sys_dmac_start_dma+0x194/0x550)
[] (renesas_sdhi_sys_dmac_start_dma) from []
(tmio_process_mrq+0x15c/0x3b8)
[] (tmio_process_mrq) from []
(mmc_start_request+0x11c/0x128)
[] (mmc_start_request) from [] (mmc_wait_for_req+0x78/0xdc)
[] (mmc_wait_for_req) from [] (mmc_send_tuning+0xe0/0x148)
[] (mmc_send_tuning) from []
(tmio_mmc_execute_tuning+0xcc/0x160)
[] (tmio_mmc_execute_tuning) from []
(mmc_execute_tuning+0x30/0x68)
[] (mmc_execute_tuning) from []
(mmc_sd_init_card+0x5c4/0x62c)
[] (mmc_sd_init_card) from [] (mmc_attach_sd+0xa4/0x130)
[] (mmc_attach_sd) from [] (mmc_rescan+0x2fc/0x340)
[] (mmc_rescan) from [] (process_one_work+0x1cc/0x30c)
[] (process_one_work) from []
(process_scheduled_works+0x28/0x30)
[] (process_scheduled_works) from []
(worker_thread+0x2e0/0x3e0)
[] (worker_thread) from [] (kthread+0x134/0x150)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
---[ end trace e899ede79c440525 ]---

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 v1.1 2/2] drm: rcar-du: Repair vblank for DRM page flips using the VSP1

[Kuninori Morimoto]

Hi Kieran

> -static void rcar_du_vsp_complete(void *private)
> +static void rcar_du_vsp_complete(void *private, bool completed)
>  {
>   struct rcar_du_crtc *crtc = private;
>  
> - rcar_du_crtc_finish_page_flip(crtc);
> + if (crtc->vblank_enable)
> + drm_crtc_handle_vblank(>crtc);
> +
> + if (completed)
> + rcar_du_crtc_finish_page_flip(crtc);
>  }

Here, this "vblank_enable" flag, timestamp will be update on 
drm_crtc_handle_vblank().

For example modetest Flip test, if we stop it by Ctrl+C, then, vblank_enable 
will be false,
Then, vblank timestamp isn't updated on waiting method on 
drm_atomic_helper_wait_for_vblanks().
Thus we will have timeout error.

And, print complete is now indicated on VSP Frame End,
in interlace input case, print complete will be indicated to user
on each ODD, EVEN timing.

Before this patch, for example 1080i@60Hz, print complete indication
happen in 30Hz.
After this patch, in interlace case, indication coming 60Hz

Best regards
---
Kuninori Morimoto

[PATCH] arm64: dts: renesas: Move CPG_AUDIO_CLK_I from board to soc files

[Geert Uytterhoeven]

The definition of CPG_AUDIO_CLK_I is SoC-specific, not board-specific.
Hence move it from the board-specific .dts files to the SoC-specific
.dtsi files.

Signed-off-by: Geert Uytterhoeven 
---
I don't think it's worth adding Fixes tags.

If you disagree, feel free to add:

Fixes: 79e3b5cf035e4734 ("arm64: dts: renesas: Add support for Salvator-XS with 
R-Car H3 ES2.0")
Fixes: fb5202dbebfd8fbf ("arm64: dts: r8a7795: h3ulcb: Add support for R-Car H3 
ES2.0")
Fixes: 0b03c32db03d63de ("arm64: dts: r8a7795: salvator-x: Add support for 
R-Car H3 ES2.0")
Fixes: 253ed045a34d16d9 ("arm64: dts: renesas: Extract common ULCB board 
support")
Fixes: d25e8ff0d5aaf8b1 ("arm64: dts: renesas: Extract common Salvator-X board 
support")
---
 arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts | 2 --
 arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts | 2 --
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 --
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 --
 arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts| 2 --
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 2 ++
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 2 --
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 2 --
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   | 2 ++
 9 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
index 95fe207cb6a3fd2f..dd4f9b6a42546def 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
@@ -9,8 +9,6 @@
  * kind, whether express or implied.
  */
 
-#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
-
 /dts-v1/;
 #include "r8a7795-es1.dtsi"
 #include "ulcb.dtsi"
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
index b84c156ed6969947..3f7d5f51e42878cb 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
@@ -8,8 +8,6 @@
  * kind, whether express or implied.
  */
 
-#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
-
 /dts-v1/;
 #include "r8a7795-es1.dtsi"
 #include "salvator-x.dtsi"
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 0426f41765f0bc68..27d4b1a4c4754732 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -9,8 +9,6 @@
  * kind, whether express or implied.
  */
 
-#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
-
 /dts-v1/;
 #include "r8a7795.dtsi"
 #include "ulcb.dtsi"
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 684fb3b9d154559e..17953070f38dff8d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -8,8 +8,6 @@
  * kind, whether express or implied.
  */
 
-#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
-
 /dts-v1/;
 #include "r8a7795.dtsi"
 #include "salvator-x.dtsi"
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index de354957144b4822..6a7d1b22d0fecc9c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -8,8 +8,6 @@
  * kind, whether express or implied.
  */
 
-#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
-
 /dts-v1/;
 #include "r8a7795.dtsi"
 #include "salvator-xs.dtsi"
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 5ec03641d9873f22..6b75d4b9ce7efa49 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -12,6 +12,8 @@
 #include 
 #include 
 
+#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
+
 / {
compatible = "renesas,r8a7795";
#address-cells = <2>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 38b58b7fca4bf0e9..1ff9dffae4618a5a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -9,8 +9,6 @@
  * kind, whether express or implied.
  */
 
-#define CPG_AUDIO_CLK_IR8A7796_CLK_S0D4
-
 /dts-v1/;
 #include "r8a7796.dtsi"
 #include "ulcb.dtsi"
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index db4f162d6bdd2c42..b35b15914771af86 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -8,8 +8,6 @@
  * kind, whether express or implied.
  */
 
-#define CPG_AUDIO_CLK_IR8A7796_CLK_S0D4
-
 /dts-v1/;
 #include "r8a7796.dtsi"
 

Re: [PATCH v2 0/4] sh: sh7722/sh7757i/sh7264/sh7269: Fix pinctrl registration

[Geert Uytterhoeven]

Hi Rich, Sato-san,

On Thu, May 11, 2017 at 10:03 AM, Geert Uytterhoeven
 wrote:
> Magnus reported that on sh7722/Migo-R, pinctrl registration fails with:
>
> sh-pfc pfc-sh7722: pin 0 already registered
> sh-pfc pfc-sh7722: error during pin registration
> sh-pfc pfc-sh7722: could not register: -22
> sh-pfc: probe of pfc-sh7722 failed with error -22
>
> pinmux_pins[] is initialized through PINMUX_GPIO(), using designated
> array initializers, where the GPIO_* enums serve as indices.
> Apparently GPIO_PTQ7 was defined in the enum, but never used.
> If enum values are defined, but never used, pinmux_pins[] contains
> (zero-filled) holes.  Hence such entries are treated as pin zero, which
> was registered before, and pinctrl registration fails.
>
> I can't see how this ever worked, as at the time of commit f5e25ae52feff2dc
> ("sh-pfc: Add sh7722 pinmux support"), pinmux_gpios[] in
> drivers/pinctrl/sh-pfc/pfc-sh7722.c already had the hole, and
> drivers/pinctrl/core.c already had the check.
>
> Some scripting revealed a few more broken drivers:
>   - sh7757 has four holes, due to nonexistent GPIO_PT[JLNQ]7_RESV.
>   - sh7264 and sh7269 define GPIO_PH[0-7], but don't use it with
> PINMUX_GPIO().
>
> Patch 1 fixes the issue on sh7722, and was tested.
> Patches 3-4 should fix the issue on the other 3 SoCs, but was untested due
> to lack of hardware.
>
> Changes compared to v1:
>   - Replace fake error messages by references to sh7722,
>   - Add Reviewed-by, Tested-by.
>
> Thanks for applying!
>
> Geert Uytterhoeven (4):
>   sh: sh7722: Remove nonexistent GPIO_PTQ7 to fix pinctrl registration
>   sh: sh7757: Remove nonexistent GPIO_PT[JLNQ]7_RESV to fix pinctrl
> registration
>   sh: sh7264: Remove nonexistent GPIO_PH[0-7] to fix pinctrl
> registration
>   sh: sh7269: Remove nonexistent GPIO_PH[0-7] to fix pinctrl
> registration
>
>  arch/sh/include/cpu-sh2a/cpu/sh7264.h | 4 +---
>  arch/sh/include/cpu-sh2a/cpu/sh7269.h | 4 +---
>  arch/sh/include/cpu-sh4/cpu/sh7722.h  | 2 +-
>  arch/sh/include/cpu-sh4/cpu/sh7757.h  | 8 
>  4 files changed, 7 insertions(+), 11 deletions(-)

Are these patches planned for inclusion in v4.13?
I don't see them in next-2016.

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

Re: Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks)

[Peter De Schrijver]

On Thu, Jun 29, 2017 at 11:27:28AM +0200, Geert Uytterhoeven wrote:
> Hi Dirk,
> 
> CC clock, ARM, DT, PM people
> 
> TL;DR: Clocks may be in use by another CPU not running Linux, while Linux
> disables them as being unused.
> 

There is that but also Linux should not be allowed to change the rate and
parent. Otherwise your R7 sw will likely fail as well. I think it makes sense
to have some DT property which informs linux which clocks it should not touch.
At least assuming clock control isn't moved to a separate coprocessor. In that
case any policy can ofcourse be implemented in the coprocessor.

Peter.


> On Mon, Jun 26, 2017 at 1:30 PM, Dirk Behme  wrote:
> > With commit 72f5df2c2bbb6 ("clk: renesas: cpg-mssr: Migrate to
> > CLK_IS_CRITICAL") we are able to handle critical module clocks.
> > Introduce the same logic for critical core clocks.
> >
> > Signed-off-by: Dirk Behme 
> > ---
> > Commit
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/renesas?id=72f5df2c2bbb66d4a555cb51eb9f412abf1af77f
> >
> > is quite nice to avoid *module* clocks being disabled. Unfortunately,
> > there are *core* clocks, too. E.g. using an other OS on the Cortex R7
> > core of the r8a7795, the 'canfd' is a quite popular core clock which
> > shouldn't be disabled by Linux.
> >
> > Therefore, this patch is a proposal to use the same 'mark clocks as
> > critical' logic implemented for the module clocks for the core
> > clocks, too.
> >
> > Opinions?
> 
> On r8a7795, there are several Cortex A cores running Linux, and a Cortex R7
> core which may run another OS.
> This is an interesting issue, and relevant to other SoCs, too.
> 
> In this particular case, the "canfd" clock is a core clock used as an
> auxiliary clock for the CAN0, CAN1, and CANFD interfaces.  This can lead
> to three scenarios:
>   1. Linux controls all CAN interfaces
>  => no issue,
>   2. The OS on the RT CPU controls all CAN interfaces
>  => issue, Linux disables the clock
>   3. Mix of 1 and 2
>  => More issues.
> Of course this is not limited to clocks, but also to e.g. PM domains.
> 
> How can this be handled?
> I believe just marking the "canfd" clock critical is not the right solution,
> as about any clock could be used by the RT CPU.
> 
> Still, Linux needs to be made aware that devices (clocks and PM domains) are
> controlled by another CPU/OS.
> 
> Should this be described in DT? It feels like software policy to me.
> 
> Note that we (mainline) currently don't describe the Cortex R7 core in DT.
> Dirk: do you describe it?
> 
> Summary:
>   1. Core/module clocks are described in the clock driver (not in DT),
>   2. Unused clocks are disabled by CCF,
>   3. Clocks may be in use by the Real-Time CPU core, running another OS,
>   4. How to communicate to Linux which clocks are under control of the RT CPU?
> 
> Thanks for your comments!
> 
> >  drivers/clk/renesas/clk-div6.c | 17 +++--
> >  drivers/clk/renesas/clk-div6.h |  4 +++-
> >  drivers/clk/renesas/r8a7795-cpg-mssr.c |  7 +++
> >  drivers/clk/renesas/renesas-cpg-mssr.c |  3 ++-
> >  drivers/clk/renesas/renesas-cpg-mssr.h |  8 
> >  5 files changed, 35 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/clk/renesas/clk-div6.c b/drivers/clk/renesas/clk-div6.c
> > index 0627860..5917e05 100644
> > --- a/drivers/clk/renesas/clk-div6.c
> > +++ b/drivers/clk/renesas/clk-div6.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >
> > +#include "renesas-cpg-mssr.h"
> >  #include "clk-div6.h"
> >
> >  #define CPG_DIV6_CKSTP BIT(8)
> > @@ -184,7 +185,9 @@ static const struct clk_ops cpg_div6_clock_ops = {
> >  struct clk * __init cpg_div6_register(const char *name,
> >   unsigned int num_parents,
> >   const char **parent_names,
> > - void __iomem *reg)
> > + void __iomem *reg,
> > + const struct cpg_mssr_info *info,
> > + unsigned int id)
> >  {
> > unsigned int valid_parents;
> > struct clk_init_data init;
> > @@ -246,6 +249,15 @@ struct clk * __init cpg_div6_register(const char *name,
> > init.name = name;
> > init.ops = _div6_clock_ops;
> > init.flags = CLK_IS_BASIC;
> > +   if (info) {
> > +   for (i = 0; i < info->num_crit_core_clks; i++)
> > +   if (id == info->crit_core_clks[i]) {
> > +   pr_devel("DIV6 %s setting 
> > CLK_IS_CRITICAL\n",
> > +name);
> > +   init.flags |= CLK_IS_CRITICAL;
> > +   break;
> > +   }
> > +   }
> > init.parent_names = parent_names;
> > init.num_parents = 

[PATCH] drm: rcar-du: remove an unneeded NULL check

[Dan Carpenter]

"params" can't be NULL here.  The next lines assume that we either
hit the break statement of "params->mpixelclock == ~0UL".  The
inconsistent NULL checking makes static checkers complain.  I've just
removed the test.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c 
b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
index 7539626b8ebd..dc85b53d58ef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -45,7 +45,7 @@ static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
 {
const struct rcar_hdmi_phy_params *params = rcar_hdmi_phy_params;
 
-   for (; params && params->mpixelclock != ~0UL; ++params) {
+   for (; params->mpixelclock != ~0UL; ++params) {
if (mpixelclock <= params->mpixelclock)
break;
}

[PATCH] pinctrl: rza1: Remove unneeded wrong check for wrong variable

[Geert Uytterhoeven]

Depending on compiler version:

drivers/pinctrl/pinctrl-rza1.c: In function ‘rza1_pinctrl_probe’:
drivers/pinctrl/pinctrl-rza1.c:1260:5: warning: ‘ret’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  if (ret)
 ^

Indeed, the result returned by platform_get_resource() was stored in
"res", not "ret".  In addition, the correct error check would be
"if (!res)", as platform_get_resource() does not return an error code,
but returns NULL on failure.

However, as devm_ioremap_resource() verifies the validity of the passed
resource pointer anyway, the check can just be removed.

Reported-by: Stephen Rothwell 
Fixes: 5a49b644b3075f88 ("pinctrl: Renesas RZ/A1 pin and gpio controller")
Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.
---
 drivers/pinctrl/pinctrl-rza1.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rza1.c b/drivers/pinctrl/pinctrl-rza1.c
index 614a043f3038d5d3..1188e6881e52ba7a 100644
--- a/drivers/pinctrl/pinctrl-rza1.c
+++ b/drivers/pinctrl/pinctrl-rza1.c
@@ -1257,9 +1257,6 @@ static int rza1_pinctrl_probe(struct platform_device 
*pdev)
rza1_pctl->dev = >dev;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (ret)
-   return -ENODEV;
-
rza1_pctl->base = devm_ioremap_resource(>dev, res);
if (IS_ERR(rza1_pctl->base))
return PTR_ERR(rza1_pctl->base);
-- 
2.7.4

Re: [PATCH/RFC v2 0/5] clk: renesas: rcar-gen3: Restore clocks during resume

[Niklas Söderlund]

Hi Geert,

On 2017-06-29 18:26:38 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Thu, Jun 29, 2017 at 5:18 PM, Niklas Söderlund
>  wrote:
> > On 2017-06-29 15:25:15 +0200, Geert Uytterhoeven wrote:
> >> During PSCI system suspend, R-Car Gen3 SoCs are powered down, and their
> >> clock register state is lost.  Note that as the boot loader skips most
> >> initialization after resume, clock register state differs from the state
> >> encountered during normal system boot, too.
> >>
> >> Hence after s2ram, some operations may fail because module clocks are
> >> disabled, while drivers expect them to be still enabled.  E.g. EtherAVB
> >> fails when Wake-on-LAN has been enabled using "ethtool -s eth0 wol g":
> >>
> >> ravb e680.ethernet eth0: failed to switch device to config mode
> >> ravb e680.ethernet eth0: device will be stopped after h/w 
> >> processes are done.
> >> ravb e680.ethernet eth0: failed to switch device to config
> >> PM: Device e680.ethernet failed to resume: error -110
> >>
> >> In addition, some clocks that were disabled by clk_disable_unused() may
> >> have been re-enabled, wasting power.
> >>
> >> This RFC is a second attempt to fix this issue by restoring clock registers
> >> during system resume.
> 
> >> This has been tested on Salvator-X with R-Car H3 ES1.0 and M3-W ES1.0.
> >> On Salvator-XS with R-Car H3 ES2.0, EtherAVB restarts after system resume,
> >> but NFS fails with "server not responding", probably not due to a clock
> >> issue.
> >
> > I tested this series using this setup:
> >
> > - Base latest renesas-drivers, 710def1a48c7bc9d ("of_mdio: Fix broken
> >   PHY IRQ in case of probe deferral"). This branch also includes the
> >   RAVB WoL patches.
> >
> > - Salvator-X H3 ES1.0
> >
> > - The arm64 defconfig.
> >
> > The test procedure I used:
> >
> > arm64 ~/shared/deep-sleep # cat sleep.sh
> > #!/bin/bash
> >
> > ethtool -s eth0 wol g
> >
> > echo disabled > /sys/devices/platform/soc/e680.ethernet/power/wakeup
> >
> > echo 0 > /sys/module/printk/parameters/console_suspend
> >
> > i2cset -f -y 7 0x30 0x20 0x0F
> >
> > echo "Flip Switch"
> > read -n 1
> >
> > echo mem > /sys/power/state
> 
> Looks good.
> 
> > And for me the NFS root came up OK after flipping switch back. I wonder
> > what is different in our test procedures. I would like to provide my
> > tested-by tag but I first want to figure out why NFS (or maybe the whole
> > net interface?) don't work for you after resume.
> 
> Sorry for the confusion: NFS fails only on Salvator-XS H3 ES2.0.
> It works fine on Salvator-X H3 ES1.0 and M3-W ES1.0.

Dooh, I should read the error descriptions more carefully before directly 
jumping to the conclusion that WoL is broken :-) For the entire series:

Tested-by: Niklas Söderlund 

Lets hope I soon can get my hands on a Salvator-XS to try and figure out 
the RAVB issue!

> 
> > I also know you reported an IRQ storm when resuming using WoL which I in
> > over 1000 suspend/resume cycles never have been able to reproduce. Maybe
> > my test environment or procedure is to kind and/or something is falling
> > thru the cracks :-( Do you notice any difference in test procedure or
> > console printouts?
> 
> I saw the IRQ storm only once.
> 
> Thanks for testing!
> 
> 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

-- 
Regards,
Niklas Söderlund