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

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC DT fixes for v4.8.

This fixes some problems with clock descriptions in DT for the r8a7792 SoC
which is new in v4.8.

This pull request is based on "Second Round of Renesas ARM Based SoC DT
Updates for v4.8", tagged as renesas-dt2-for-v4.8, which you have already
pulled.


The following changes since commit 8fd763c75c3ab8e72e5d7f0d4c53531e6ff76197:

  ARM: dts: r8a7792: add SMP support (2016-06-30 14:26:14 +0200)

are available in the git repository at:

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

for you to fetch changes up to e0c3f92a08f3e0a95024d0d032564fdc1ee96f54:

  ARM: dts: r8a7792: remove ADSP clock (2016-07-15 13:22:45 +0900)

----------------------------------------------------------------
Renesas ARM Based SoC DT Fixes for v4.8

* Corrections to r8a7792

----------------------------------------------------------------
Sergei Shtylyov (2):
      ARM: dts: r8a7792: add PLL1 divided by 2 clock
      ARM: dts: r8a7792: remove ADSP clock

 arch/arm/boot/dts/r8a7792.dtsi            | 9 ++++++++-
 include/dt-bindings/clock/r8a7792-clock.h | 1 -
 2 files changed, 8 insertions(+), 2 deletions(-)

From: Sergei Shtylyov <redacted>

Despite the fact that QSPI clock has PLL1/VCOx1/4 clock as a parent, the
latter hasn't been added to the R8A7792 device tree. This patch corrects
that oversight.

Signed-off-by: Sergei Shtylyov <redacted>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <redacted>
---
 arch/arm/boot/dts/r8a7792.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 75256ef4a04d..d5fd0762e2d6 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi

@@ -284,6 +284,13 @@
 		};
 
 		/* Fixed factor clocks */
+		pll1_div2_clk: pll1_div2 {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <2>;
+			clock-mult = <1>;
+		};
 		zs_clk: zs {
 			compatible = "fixed-factor-clock";
 			clocks = <&cpg_clocks R8A7792_CLK_PLL1>;

-- 
2.7.0.rc3.207.g0ac5344

From: Sergei Shtylyov <redacted>

Simon Horman told me that R8A7792 has ADSP clock based on an incorrect
table in the most recent R-Car gen2 manual. But when I received that manual
I discovered that this is false: R8A7792 is the only Gen 2 SoC that doesn't
have ADSP at all.  Accordingly remove the ADSP clock from DT for the
r8a7792.

Signed-off-by: Sergei Shtylyov <redacted>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <redacted>
---
 arch/arm/boot/dts/r8a7792.dtsi            | 2 +-
 include/dt-bindings/clock/r8a7792-clock.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index d5fd0762e2d6..3fd61d7ab906 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi

@@ -279,7 +279,7 @@
 			clocks = <&extal_clk>;
 			#clock-cells = <1>;
 			clock-output-names = "main", "pll0", "pll1", "pll3",
-					     "lb", "qspi", "z", "adsp";
+					     "lb", "qspi", "z";
 			#power-domain-cells = <0>;
 		};
 

diff --git a/include/dt-bindings/clock/r8a7792-clock.h b/include/dt-bindings/clock/r8a7792-clock.h
index 89a5155913f6..9a8b392ceb00 100644
--- a/include/dt-bindings/clock/r8a7792-clock.h
+++ b/include/dt-bindings/clock/r8a7792-clock.h

@@ -18,7 +18,6 @@
 #define R8A7792_CLK_LB			4
 #define R8A7792_CLK_QSPI		5
 #define R8A7792_CLK_Z			6
-#define R8A7792_CLK_ADSP		7
 
 /* MSTP0 */
 #define R8A7792_CLK_MSIOF0		0

-- 
2.7.0.rc3.207.g0ac5344

On Monday, July 18, 2016 11:39:35 AM CEST Simon Horman wrote:

Renesas ARM Based SoC DT Fixes for v4.8

* Corrections to r8a7792

Merged into next/dt, thanks!

	Arnd

On Thu, Jul 21, 2016 at 02:41:52PM +0200, Arnd Bergmann wrote:

On Monday, July 18, 2016 11:39:35 AM CEST Simon Horman wrote:

quoted

Renesas ARM Based SoC DT Fixes for v4.8

* Corrections to r8a7792

Merged into next/dt, thanks!

Thanks!

I have queued up another fix for v4.8 since sending the above to you.
This time it is an SoC (C-code) rather than a DT fix. I am wondering
if you could offer guidance on:

* If you would prefer me to split fixes out into separate (DT, SoC, ...)
  branches? If so is that until around rc1 when everything has been
  merged into the forthcoming release and thereafter you would prefer
  a single fixes branch?

* What pace you would like me to send fixes. I guess it depends on
  where we are in the cycle. Currently I put the changes in next and
  send what I have about once a week (or not if there are none :).

Typically there are very few fixes. But as I already have 3 for v4.8,
including those in this pull request, I get the feeling a few more could
emerge before v4.8 is released.

On Friday, July 22, 2016 10:59:24 AM CEST Simon Horman wrote:

On Thu, Jul 21, 2016 at 02:41:52PM +0200, Arnd Bergmann wrote:

quoted

On Monday, July 18, 2016 11:39:35 AM CEST Simon Horman wrote:

quoted

Renesas ARM Based SoC DT Fixes for v4.8

* Corrections to r8a7792

Merged into next/dt, thanks!

Thanks!

I have queued up another fix for v4.8 since sending the above to you.
This time it is an SoC (C-code) rather than a DT fix. I am wondering
if you could offer guidance on:

* If you would prefer me to split fixes out into separate (DT, SoC, ...)
  branches? If so is that until around rc1 when everything has been
  merged into the forthcoming release and thereafter you would prefer
  a single fixes branch?

I prefer a separate fixes branch. It's fine for all other branches
to be based on top of this branch so you have a working baseline
for testing.

* What pace you would like me to send fixes. I guess it depends on
  where we are in the cycle. Currently I put the changes in next and
  send what I have about once a week (or not if there are none :).

Typically there are very few fixes. But as I already have 3 for v4.8,
including those in this pull request, I get the feeling a few more could
emerge before v4.8 is released.

I'd say don't wait longer than a week before forwarding bugfixes.
If you find something urgent, just send that right away along with
whatever less urgent patches you have accumulated.

It's possible we won't merge it right away as we might all be busy
for a couple of days, but in the worst case that means you send
another fixes pull request that is a superset before we have merged
the first one.

	Arnd

On Fri, Jul 22, 2016 at 09:30:58PM +0200, Arnd Bergmann wrote:

On Friday, July 22, 2016 10:59:24 AM CEST Simon Horman wrote:

quoted

On Thu, Jul 21, 2016 at 02:41:52PM +0200, Arnd Bergmann wrote:

quoted

On Monday, July 18, 2016 11:39:35 AM CEST Simon Horman wrote:

quoted

Renesas ARM Based SoC DT Fixes for v4.8

* Corrections to r8a7792

Merged into next/dt, thanks!

Thanks!

I have queued up another fix for v4.8 since sending the above to you.
This time it is an SoC (C-code) rather than a DT fix. I am wondering
if you could offer guidance on:

* If you would prefer me to split fixes out into separate (DT, SoC, ...)
  branches? If so is that until around rc1 when everything has been
  merged into the forthcoming release and thereafter you would prefer
  a single fixes branch?

I prefer a separate fixes branch. It's fine for all other branches
to be based on top of this branch so you have a working baseline
for testing.

Is some sort of minimal base for the fixes branch desired?
If should the base be a merge of all the tags you have pulled for v4.8?

Currently I have DT fixes and SoC fixes which depend on
respective tags that have been accepted for v4.8.

quoted

* What pace you would like me to send fixes. I guess it depends on
  where we are in the cycle. Currently I put the changes in next and
  send what I have about once a week (or not if there are none :).

Typically there are very few fixes. But as I already have 3 for v4.8,
including those in this pull request, I get the feeling a few more could
emerge before v4.8 is released.

I'd say don't wait longer than a week before forwarding bugfixes.
If you find something urgent, just send that right away along with
whatever less urgent patches you have accumulated.

It's possible we won't merge it right away as we might all be busy
for a couple of days, but in the worst case that means you send
another fixes pull request that is a superset before we have merged
the first one.

	Arnd

[resending as non-HTML]

On Sun, Jul 24, 2016 at 7:15 PM, Simon Horman [off-list ref] wrote:

On Fri, Jul 22, 2016 at 09:30:58PM +0200, Arnd Bergmann wrote:

quoted

On Friday, July 22, 2016 10:59:24 AM CEST Simon Horman wrote:

quoted

On Thu, Jul 21, 2016 at 02:41:52PM +0200, Arnd Bergmann wrote:

quoted

On Monday, July 18, 2016 11:39:35 AM CEST Simon Horman wrote:

quoted

Renesas ARM Based SoC DT Fixes for v4.8

* Corrections to r8a7792

Merged into next/dt, thanks!

Thanks!

I have queued up another fix for v4.8 since sending the above to you.
This time it is an SoC (C-code) rather than a DT fix. I am wondering
if you could offer guidance on:

* If you would prefer me to split fixes out into separate (DT, SoC, ...)
  branches? If so is that until around rc1 when everything has been
  merged into the forthcoming release and thereafter you would prefer
  a single fixes branch?

I prefer a separate fixes branch. It's fine for all other branches
to be based on top of this branch so you have a working baseline
for testing.

Is some sort of minimal base for the fixes branch desired?
If should the base be a merge of all the tags you have pulled for v4.8?

Currently I have DT fixes and SoC fixes which depend on
respective tags that have been accepted for v4.8.

It's hard to make those one branch without doing your own merge. You
can't take a merge out of our for-next branch as a base, since those
aren't stable.

Wait for our merges to go into Linus' tree, then use his last merge
commit as the base (before -rc1 is out).


-Olof