Re: [PATCH] arm64: dts: renesas: Fix VSPD registers range
Hi Sergei,
(CC'ing Olof)
On Friday, 8 June 2018 19:41:01 EEST Sergei Shtylyov wrote:
> On 06/08/2018 03:21 PM, Laurent Pinchart wrote:
> > The VSPD and FCPVD nodes have overlapping register ranges, as the FCPVD
> > devices are mapped in the memory range usually used by the VSP LUT and
> > CLU, which are not present in the VSPD. Fix this by shortening the VSPD
> > registers range to 0x5000.
> >
> > Fixes: 9f8573e38a0b ("arm64: dts: renesas: r8a7795: Add VSP instances")
> > Fixes: 291e0c4994d0 ("arm64: dts: r8a7795: Add support for R-Car H3
> > ES2.0")
> > Fixes: f06ffdfbdd90 ("arm64: dts: r8a7796: Add VSP instances")
> > Fixes: b4f92030d5d3 ("arm64: dts: renesas: r8a77970: add VSPD support")
> > Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
> > Fixes: 85cb3229218a ("arm64: dts: renesas: r8a77965: Add VSP instances")
>
> That'd be a nightmare for the -stable maintainers -- all those commits
> were made in the different time, so constant rejects are warranted.
>
> > Reported-by: Simon Horman
> > Reported-by: Geert Uytterhoeven
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> > Changes since v1:
> >
> > - Fix H3, M3-W and M3-N in addition to V3H and D3
> > - Don't touch the VSPBS instance of D3 as there's no overlap
> > - Squash all patches together
>
> Don't think that was a good idea in this case. Other opinions?
We have been requested ([1]) to try and group the DT changes, hence this
change. No clear rule has been set, and this might be a case where a split is
better. Olof, what would you prefer ?
[1] https://www.spinics.net/lists/arm-kernel/msg657208.html
--
Regards,
Laurent Pinchart
Re: [PATCH] arm64: dts: renesas: Fix VSPD registers range
Hello!
On 06/08/2018 03:21 PM, Laurent Pinchart wrote:
> The VSPD and FCPVD nodes have overlapping register ranges, as the FCPVD
> devices are mapped in the memory range usually used by the VSP LUT and
> CLU, which are not present in the VSPD. Fix this by shortening the VSPD
> registers range to 0x5000.
>
> Fixes: 9f8573e38a0b ("arm64: dts: renesas: r8a7795: Add VSP instances")
> Fixes: 291e0c4994d0 ("arm64: dts: r8a7795: Add support for R-Car H3 ES2.0")
> Fixes: f06ffdfbdd90 ("arm64: dts: r8a7796: Add VSP instances")
> Fixes: b4f92030d5d3 ("arm64: dts: renesas: r8a77970: add VSPD support")
> Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
> Fixes: 85cb3229218a ("arm64: dts: renesas: r8a77965: Add VSP instances")
That'd be a nightmare for the -stable maintainers -- all those commits
were made in the different time, so constant rejects are warranted.
> Reported-by: Simon Horman
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Fix H3, M3-W and M3-N in addition to V3H and D3
> - Don't touch the VSPBS instance of D3 as there's no overlap
> - Squash all patches together
Don't think that was a good idea in this case. Other opinions?
[...]
MBR, Sergei
[PATCH] clocksource/drivers/sh_cmt: wait for CMCNT on init
As per section 57A.3.5/69A.3.5/79.A.3.5 of rz/g/r-car gen2/3 hardware
manual,it is mentioned that we need to provide 2 cycles in counter input
clock (RCLK) for reflecting written data to counter behaviour. Adding
sufficient wait to let the CMCNT register value settle before starting the
timer channel.
It fixes the error "sh_cmt ffca.timer: ch1: cannot clear CMCNT"
Signed-off-by: Biju Das
Reviewed-by: Chris Paterson
---
Hello,
During cmt testing, the tool
(tools/testing/selftests/timers/clocksource-switch.c)
is complaining about the error "sh_cmt ffca.timer: ch1: cannot clear CMCNT".
The above patch fixes this issue is by adding sufficient wait to let the
CMCNT register value settle before starting the timer channel.
This issue is reproduced on Koelsch/RZ/G1[ME] based iwave boards etc...,
as I assume the same issue should be present on lager etc. as well?
regards,
Biju
drivers/clocksource/sh_cmt.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
index 70b3cf8..48910df 100644
--- a/drivers/clocksource/sh_cmt.c
+++ b/drivers/clocksource/sh_cmt.c
@@ -328,7 +328,7 @@ static void sh_cmt_start_stop_ch(struct sh_cmt_channel *ch,
int start)
static int sh_cmt_enable(struct sh_cmt_channel *ch)
{
- int k, ret;
+ int j, k, ret;
pm_runtime_get_sync(>cmt->pdev->dev);
dev_pm_syscore_device(>cmt->pdev->dev, true);
@@ -368,11 +368,17 @@ static int sh_cmt_enable(struct sh_cmt_channel *ch)
* While at it, we're supposed to clear out the CMCNT as of this
* moment, so make sure it's processed properly here. This will
* take RCLKx2 at maximum.
+*
+* Similar register access usage for CMCNT is mentioned in R-Car
+* Gen[2/3]/RZ/G1 user's manual, RCLKx2 for cmt0 and RCLKx2 or
+* CPϕx2 (CPEXϕx2)) for cmt1.
*/
- for (k = 0; k < 100; k++) {
- if (!sh_cmt_read_cmcnt(ch))
- break;
- udelay(1);
+ for (j = 0; j < 2; j++) {
+ for (k = 0; k < 100; k++) {
+ if (!sh_cmt_read_cmcnt(ch))
+ break;
+ udelay(1);
+ }
}
if (sh_cmt_read_cmcnt(ch)) {
--
2.7.4
Re: [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
Hi Sergei, On Thursday, 7 June 2018 23:17:03 EEST Sergei Shtylyov wrote: > Hello! > > Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's > 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/ > DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder > connected to the LVDS output. These patches depend on the Thine THC63LVD1024 > driver and the R8A77980 LVDS support patch in order to work, and R8A77980 > GPIO DT patches in order to apply/compile... > > [1/5] arm64: dts: renesas: r8a77980: add FCPVD support > [2/5] arm64: dts: renesas: r8a77980: add VSPD support > [3/5] arm64: dts: renesas: r8a77980: add DU support > [4/5] arm64: dts: renesas: r8a77980: add LVDS support Based on the recent request of the ARM SoC maintainers to avoid a plethora of small patches, I think you can squash 1/5 to 4/5 all together. > [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support -- Regards, Laurent Pinchart
Re: [PATCH v2 4/5] arm64: dts: renesas: r8a77980: add LVDS support
Hi Sergei,
Thank you for the patch.
On Thursday, 7 June 2018 23:23:06 EEST Sergei Shtylyov wrote:
> Define the generic R8A77980 part of the LVDS device node.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 29 ++
> 1 file changed, 29 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -696,6 +696,35 @@
> port@1 {
> reg = <1>;
> du_out_lvds0: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + lvds0: lvds-encoder@feb9 {
> + compatible = "renesas,r8a77980-lvds";
> + reg = <0 0xfeb9 0 0x14>;
> + clocks = < CPG_MOD 727>;
> + power-domains = < R8A77980_PD_ALWAYS_ON>;
> + resets = < 727>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds0_in: endpoint {
> + remote-endpoint =
> + <_out_lvds0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + lvds0_out: endpoint {
> };
> };
> };
--
Regards,
Laurent Pinchart
Re: [PATCH v2 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
Hi Sergei,
Thank you for the patch.
On Thursday, 7 June 2018 23:19:31 EEST Sergei Shtylyov wrote:
> Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
> the next patch...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77980.dtsi |8
> 1 file changed, 8 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -653,6 +653,14 @@
> resets = < 408>;
> };
>
> + fcpvd0: fcp@fea27000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea27000 0 0x200>;
> + clocks = < CPG_MOD 603>;
> + power-domains = < R8A77980_PD_ALWAYS_ON>;
> + resets = < 603>;
> + };
> +
> prr: chipid@fff00044 {
> compatible = "renesas,prr";
> reg = <0 0xfff00044 0 4>;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 3/5] arm64: dts: renesas: r8a77980: add DU support
Hi Sergei,
Thank you for the patch.
On Thursday, 7 June 2018 23:21:38 EEST Sergei Shtylyov wrote:
> Define the generic R8A77980 part of the DU device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 30 ++
> 1 file changed, 30 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -671,6 +671,36 @@
> resets = < 603>;
> };
>
> + du: display@feb0 {
> + compatible = "renesas,du-r8a77980",
> + "renesas,du-r8a77970";
> + reg = <0 0xfeb0 0 0x8>;
> + interrupts = ;
> + clocks = < CPG_MOD 724>;
> + clock-names = "du.0";
> + power-domains = < R8A77980_PD_ALWAYS_ON>;
> + resets = < 724>;
> + vsps = <>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + du_out_rgb: endpoint {
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + du_out_lvds0: endpoint {
> + };
> + };
> + };
> + };
> +
> prr: chipid@fff00044 {
> compatible = "renesas,prr";
> reg = <0 0xfff00044 0 4>;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 2/5] arm64: dts: renesas: r8a77980: add VSPD support
Hello Simon,
On Friday, 8 June 2018 16:54:56 EEST Simon Horman wrote:
> [CC Laurent, Geert]
>
> On Thu, Jun 07, 2018 at 11:20:47PM +0300, Sergei Shtylyov wrote:
> > Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
> > the next patch...
> >
> > Based on the original (and large) patch by Vladimir Barinov.
> >
> > Signed-off-by: Vladimir Barinov
> > Signed-off-by: Sergei Shtylyov
> >
> > ---
> >
> > arch/arm64/boot/dts/renesas/r8a77980.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > ===
> > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > @@ -653,6 +653,16 @@
> > resets = < 408>;
> > };
> >
> > + vspd0: vsp@fea2 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea2 0 0x4000>;
>
> As per "[PATCH] arm64: dts: renesas: Fix VSPD registers range"
> I think the width of the range should be 0x5000.
I agree with that.
> > + interrupts = ;
> > + clocks = < CPG_MOD 623>;
> > + power-domains = < R8A77980_PD_ALWAYS_ON>;
> > + resets = < 623>;
> > + renesas,fcp = <>;
> > + };
> > +
> > fcpvd0: fcp@fea27000 {
> > compatible = "renesas,fcpv";
> > reg = <0 0xfea27000 0 0x200>;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 2/5] arm64: dts: renesas: r8a77980: add VSPD support
[CC Laurent, Geert]
On Thu, Jun 07, 2018 at 11:20:47PM +0300, Sergei Shtylyov wrote:
> Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
> the next patch...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
>
> ---
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -653,6 +653,16 @@
> resets = < 408>;
> };
>
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x4000>;
As per "[PATCH] arm64: dts: renesas: Fix VSPD registers range"
I think the width of the range should be 0x5000.
> + interrupts = ;
> + clocks = < CPG_MOD 623>;
> + power-domains = < R8A77980_PD_ALWAYS_ON>;
> + resets = < 623>;
> + renesas,fcp = <>;
> + };
> +
> fcpvd0: fcp@fea27000 {
> compatible = "renesas,fcpv";
> reg = <0 0xfea27000 0 0x200>;
>
Re: [PATCH 2/2] arm64: dts: renesas: r8a77995: Fix VSP registers range
Hi Geert,
On Friday, 8 June 2018 14:53:28 EEST Geert Uytterhoeven wrote:
> On Fri, Jun 8, 2018 at 1:18 PM Laurent Pinchart wrote:
> > The R8A77995 VSP and FCP nodes have overlapping register ranges, as the
> > SoC integrates the FCP devices in the memory range usually used by the
> > VSP LUT and CLUT, which are not present. Fix this by shortening the VSP
> > registers range to 0x5000.
>
> According to datasheet rev. 1.00, the CLUT is present on R-Car D3, the
> LUT is not.
That was a typo, the commit message should have mentioned CLU, not CLUT. I've
sent a v2 that fixes this and covers the H3 and M3* SoCs.
> > Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
> > Reported-by: Simon Horman
> > Reported-by: Geert Uytterhoeven
> > Signed-off-by: Laurent Pinchart
> >
>
> Apart from my comment above:
> Reviewed-by: Geert Uytterhoeven
--
Regards,
Laurent Pinchart
[PATCH] arm64: dts: renesas: Fix VSPD registers range
The VSPD and FCPVD nodes have overlapping register ranges, as the FCPVD
devices are mapped in the memory range usually used by the VSP LUT and
CLU, which are not present in the VSPD. Fix this by shortening the VSPD
registers range to 0x5000.
Fixes: 9f8573e38a0b ("arm64: dts: renesas: r8a7795: Add VSP instances")
Fixes: 291e0c4994d0 ("arm64: dts: r8a7795: Add support for R-Car H3 ES2.0")
Fixes: f06ffdfbdd90 ("arm64: dts: r8a7796: Add VSP instances")
Fixes: b4f92030d5d3 ("arm64: dts: renesas: r8a77970: add VSPD support")
Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
Fixes: 85cb3229218a ("arm64: dts: renesas: r8a77965: Add VSP instances")
Reported-by: Simon Horman
Reported-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Fix H3, M3-W and M3-N in addition to V3H and D3
- Don't touch the VSPBS instance of D3 as there's no overlap
- Squash all patches together
---
arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 +++---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 6 +++---
arch/arm64/boot/dts/renesas/r8a77965.dtsi| 4 ++--
arch/arm64/boot/dts/renesas/r8a77970.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a77995.dtsi| 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
index e19dcd6cb767..0a42b016f257 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
@@ -80,7 +80,7 @@
vspd3: vsp@fea38000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea38000 0 0x8000>;
+ reg = <0 0xfea38000 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 620>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 9b154ff33e67..6803c0075d51 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2539,7 +2539,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x8000>;
+ reg = <0 0xfea2 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -2550,7 +2550,7 @@
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea28000 0 0x8000>;
+ reg = <0 0xfea28000 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 622>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -2561,7 +2561,7 @@
vspd2: vsp@fea3 {
compatible = "renesas,vsp2";
- reg = <0 0xfea3 0 0x8000>;
+ reg = <0 0xfea3 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 621>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 3ca3f56110fe..636090ce3ee8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2256,7 +2256,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x8000>;
+ reg = <0 0xfea2 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
@@ -2267,7 +2267,7 @@
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea28000 0 0x8000>;
+ reg = <0 0xfea28000 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 622>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
@@ -2278,7 +2278,7 @@
vspd2: vsp@fea3 {
compatible = "renesas,vsp2";
- reg = <0 0xfea3 0 0x8000>;
+ reg = <0 0xfea3 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 621>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index d740c79752d5..a584dfc78339 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -1490,7 +1490,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0
Re: [PATCH 2/2] arm64: dts: renesas: r8a77995: Fix VSP registers range
Hi Laurent,
Thanks for your patch!
On Fri, Jun 8, 2018 at 1:18 PM Laurent Pinchart
wrote:
> The R8A77995 VSP and FCP nodes have overlapping register ranges, as the
> SoC integrates the FCP devices in the memory range usually used by the
> VSP LUT and CLUT, which are not present. Fix this by shortening the VSP
> registers range to 0x5000.
According to datasheet rev. 1.00, the CLUT is present on R-Car D3, the
LUT is not.
> Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
> Reported-by: Simon Horman
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Laurent Pinchart
Apart from my comment above:
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 1/2] arm64: dts: renesas: r8a77970: Fix VSP registers range
The R8A77970 VSP and FCP nodes have overlapping register ranges, as the
SoC integrates the FCP devices in the memory range usually used by the
VSP LUT and CLUT, which are not present. Fix this by shortening the VSP
registers range to 0x5000.
Fixes: b4f92030d5d3 ("arm64: dts: renesas: r8a77970: add VSPD support")
Reported-by: Simon Horman
Reported-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 98a2317a16c4..89dc4e343b7c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -776,7 +776,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x8000>;
+ reg = <0 0xfea2 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A77970_PD_ALWAYS_ON>;
--
Regards,
Laurent Pinchart
[PATCH 2/2] arm64: dts: renesas: r8a77995: Fix VSP registers range
The R8A77995 VSP and FCP nodes have overlapping register ranges, as the
SoC integrates the FCP devices in the memory range usually used by the
VSP LUT and CLUT, which are not present. Fix this by shortening the VSP
registers range to 0x5000.
Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
Reported-by: Simon Horman
Reported-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index eb23c85c561b..49ca64285092 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -704,7 +704,7 @@
vspbs: vsp@fe96 {
compatible = "renesas,vsp2";
- reg = <0 0xfe96 0 0x8000>;
+ reg = <0 0xfe96 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 627>;
power-domains = < R8A77995_PD_ALWAYS_ON>;
@@ -714,7 +714,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x8000>;
+ reg = <0 0xfea2 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A77995_PD_ALWAYS_ON>;
@@ -724,7 +724,7 @@
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea28000 0 0x8000>;
+ reg = <0 0xfea28000 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 622>;
power-domains = < R8A77995_PD_ALWAYS_ON>;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
On Thu, Jun 07, 2018 at 11:19:31PM +0300, Sergei Shtylyov wrote: > Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in > the next patch... > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov Hi, This looks fine to me but I will wait for the dependencies of this series to land and to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
On 6/8/2018 11:21 AM, Simon Horman wrote: Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/ DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder connected to the LVDS output. These patches depend on the Thine THC63LVD1024 driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO DT patches in order to apply/compile... [1/5] arm64: dts: renesas: r8a77980: add FCPVD support [2/5] arm64: dts: renesas: r8a77980: add VSPD support [3/5] arm64: dts: renesas: r8a77980: add DU support [4/5] arm64: dts: renesas: r8a77980: add LVDS support [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support Sergei, what are the changes in this series between v1 and v2? See patch #5. I've added the V3HSK DT update there... MBR, Sergei
Re: [PATCH 2/3] arm64: dts: renesas: condor: specify EtherAVB PHY IRQ
On Mon, Jun 04, 2018 at 05:22:52PM +0300, Sergei Shtylyov wrote:
> On 06/04/2018 01:33 PM, Simon Horman wrote:
>
> >> Specify EtherAVB PHY IRQ in the Condor board's device tree, now that
> >> we have the GPIO support (previously phylib had to resort to polling).
> >>
> >> Based on the original (and large) patch by Vladimir Barinov.
> >>
> >> Signed-off-by: Vladimir Barinov
> >> Signed-off-by: Sergei Shtylyov
> >>
> >> ---
> >> arch/arm64/boot/dts/renesas/r8a77980-condor.dts |2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> ===
> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> @@ -59,6 +59,8 @@
> >>phy0: ethernet-phy@0 {
> >>rxc-skew-ps = <1500>;
> >>reg = <0>;
> >> + interrupt-parent = <>;
> >> + interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
> >
> > I don't see this documented. Perhaps I'm missing something obvious.
>
>Have you looked into the V3H PFC section for where in the GPSRs AVB_PHY_INT
> is mapped?
Thanks, I see that now.
>The Condor schematics doesn't explicitly list the GPIO for AVB_PHY_INT
> because that signal is meant to be routed thru the MAC. Unfortunately, the
> sh_eth/ravb drivers don't support the PHY interrupt (the phylib function,
> phy_mac_interrupt() reporting the PHY interrupts routed thru MAC is clearly
> inadequate as it wants the link state as an argument), so we have to resort
> to the GPIO interrupts...
Understood.
> > Or you have some extra information or newer documentation?
>
>No.
>
> > Also, given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas
> > ARM64 Based SoC DT Updates for v4.18") please consider squashing this patch
> > and the following one.
>
>Hm... note that the different Ether cores are involved in these 2 PHY IRQ
> patches. If that's OK, I can merge the patches...
Tough call. Functionally these are both ethernet even though they are
different IP cores. So I think I prefer a squash.
I have applied 1/3 of this series and will push shortly.
Re: [PATCH 1/3] arm64: dts: renesas: r8a77980: add GPIO support
On Wed, Jun 06, 2018 at 11:07:27AM +0200, Geert Uytterhoeven wrote: > On Fri, Jun 1, 2018 at 10:44 PM, Sergei Shtylyov > wrote: > > Describe all 6 GPIO controllers in the R8A77980 device tree. > > > > Based on the original (and large) patch by Vladimir Barinov. > > > > Signed-off-by: Vladimir Barinov > > Signed-off-by: Sergei Shtylyov > > Reviewed-by: Geert Uytterhoeven Thanks Sergei, applied.
Re: [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
On Thu, Jun 07, 2018 at 11:17:03PM +0300, Sergei Shtylyov wrote: > Hello! > > Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's > 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/ > DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder > connected to the LVDS output. These patches depend on the Thine THC63LVD1024 > driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO > DT patches in order to apply/compile... > > [1/5] arm64: dts: renesas: r8a77980: add FCPVD support > [2/5] arm64: dts: renesas: r8a77980: add VSPD support > [3/5] arm64: dts: renesas: r8a77980: add DU support > [4/5] arm64: dts: renesas: r8a77980: add LVDS support > [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support Sergei, what are the changes in this series between v1 and v2?
Re: [PATCH v2] arm64: dts: renesas: r8a77990: Enable USB2.0 Host for Ebisu board
On Wed, Jun 06, 2018 at 06:52:06PM +0900, Yoshihiro Shimoda wrote:
> This patch adds USB2.0 PHY and Host(EHCI/OHCI) nodes and
> enables them for R-Car E3 Ebisu board.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> This patch set is based on renesas-drivers.git /
> renesas-drivers-2018-06-05-v4.17 tag.
>
> Changes from v1:
> - Squash 4 patches into a single patch.
Thanks Shimoda-san, I have applied this for v4.19.
I had to do so manually to resolve a trivial conflict in
r8a779980-ebisu.dts. The result is below. Please check to make
sure that I got it right.
From: Yoshihiro Shimoda
Subject: [PATCH] arm64: dts: renesas: r8a77990: Enable USB2.0 Host for Ebisu
board
This patch adds USB2.0 PHY and Host(EHCI/OHCI) nodes and
enables them for R-Car E3 Ebisu board.
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Simon Horman
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 20 ++
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 37 ++
2 files changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 28945a8b9800..5e28c1b94b77 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -47,10 +47,18 @@
};
};
+ {
+ status = "okay";
+};
+
_clk {
clock-frequency = <4800>;
};
+ {
+ status = "okay";
+};
+
{
avb_pins: avb {
mux {
@@ -58,6 +66,11 @@
function = "avb";
};
};
+
+ usb0_pins: usb {
+ groups = "usb0_b";
+ function = "usb0";
+ };
};
{
@@ -68,3 +81,10 @@
{
status = "okay";
};
+
+_phy0 {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 735881d4e57a..f8004608c595 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -267,6 +267,43 @@
status = "disabled";
};
+ ohci0: usb@ee08 {
+ compatible = "generic-ohci";
+ reg = <0 0xee08 0 0x100>;
+ interrupts = ;
+ clocks = < CPG_MOD 703>;
+ phys = <_phy0>;
+ phy-names = "usb";
+ power-domains = < 32>;
+ resets = < 703>;
+ status = "disabled";
+ };
+
+ ehci0: usb@ee080100 {
+ compatible = "generic-ehci";
+ reg = <0 0xee080100 0 0x100>;
+ interrupts = ;
+ clocks = < CPG_MOD 703>;
+ phys = <_phy0>;
+ phy-names = "usb";
+ companion = <>;
+ power-domains = < 32>;
+ resets = < 703>;
+ status = "disabled";
+ };
+
+ usb2_phy0: usb-phy@ee080200 {
+ compatible = "renesas,usb2-phy-r8a77990",
+"renesas,rcar-gen3-usb2-phy";
+ reg = <0 0xee080200 0 0x700>;
+ interrupts = ;
+ clocks = < CPG_MOD 703>;
+ power-domains = < 32>;
+ resets = < 703>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@f101 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.11.0
Re: [PATCH] soc: renesas: rcar-sysc: Make PM domain initialization more robust
On Thu, Jun 07, 2018 at 04:33:07AM +, Yoshihiro Shimoda wrote:
> Hi Geert-san,
>
> > From: Behalf Of Geert Uytterhoeven, Sent: Wednesday, June 6, 2018 5:58 PM
> >
> > Hi Simon,
> >
> > On Wed, Jun 6, 2018 at 10:52 AM, Simon Horman wrote:
> > > On Tue, Jun 05, 2018 at 05:05:15PM +0200, Geert Uytterhoeven wrote:
>
> > > This looks fine to me but I will wait to see if there are other reviews
> > > before applying.
> >
> > Let's wait for feedback from Shimoda-san. Perpaps the quirk did rely on
> > the buggy behavior.
>
> I checked /sys/kernel/debug/pm_genpd/pm_genpd_summary.
>
> < Before applies the patch >
> - "3dg-b's" status is "off-0".
> - "3dg-b" doesn't have any slaves.
>
> < After applied the patch >
> - "3dg-b's" status is "on".
> - "3dg-b" has "3dg-a" slave.
>
> So,
>
> Tested-by: Yoshihiro Shimoda
On Thu, Jun 07, 2018 at 02:47:29PM +0200, Ulf Hansson wrote:
> On 5 June 2018 at 17:05, Geert Uytterhoeven wrote:
> > The quirk for R-Car E3 ES1.0 added in commit 086b399965a7ee7e ("soc:
> > renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}") makes the 3DG-A
> > PM domain a subdomain of the 3DG-B PM domain. However, registering
> > 3DG-A with its parent fails silently, as the 3DG-B PM domain hasn't been
> > registered yet, and such failures are never reported.
> >
> > Fix this by:
> > 1. Splitting PM Domain initialization in two steps, so all PM domains
> > are registered before any child-parent links are established,
> > 2. Reporting any failures in establishing child-parent relations.
> >
> > Check for and report pm_genpd_init() failures, too, as that function
> > gained a return value in commit 7eb231c337e00735 ("PM / Domains: Convert
> > pm_genpd_init() to return an error code").
> >
> > Fixes: 086b399965a7ee7e ("soc: renesas: r8a77990-sysc: Add workaround for
> > 3DG-{A,B}")
> > Signed-off-by: Geert Uytterhoeven
>
> Reviewed-by: Ulf Hansson
Thanks everyone, applied as a fix for v4.18.
Re: [PATCH] arm64: dts: renesas: r8a77990: ebisu: Enable watchdog timer
On Wed, Jun 06, 2018 at 11:04:00AM +0200, Simon Horman wrote: > On Tue, Jun 05, 2018 at 07:20:34PM +0200, Geert Uytterhoeven wrote: > > From: Takeshi Kihara > > > > Add a device node for the Watchdog Timer (WDT) controller on the > > R8A77990 SoC, and enable the watchdog on the Ebisu board. > > > > Signed-off-by: Takeshi Kihara > > [geert: Squashed 2 commits] > > Signed-off-by: Geert Uytterhoeven > > Hi, > > This looks fine to me but I will wait to see if there are other reviews > before applying. > > Reviewed-by: Simon Horman Thanks Geert, applied
Re: [PATCH v2] ARM: Always build secure_cntvoff.S on ARM V7 to fix shmobile !SMP build
On Wed, Jun 06, 2018 at 11:25:16AM +0200, Geert Uytterhoeven wrote:
> If CONFIG_SMP=n, building a kernel for R-Car Gen2 fails with:
>
> arch/arm/mach-shmobile/setup-rcar-gen2.o: In function
> `rcar_gen2_timer_init':
> setup-rcar-gen2.c:(.init.text+0x30): undefined reference to
> `secure_cntvoff_init'
>
> Indeed, on R-Car Gen2 SoCs, secure_cntvoff_init() is not only needed for
> secondary CPUs, but also for the boot CPU. This is most visible on SoCs
> with Cortex A7 cores (e.g. R-Car E2, cfr. commit 9ce3fa6816c2fb59 ("ARM:
> shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794")),
> but Cortex A15 is affected, too.
>
> Fix this by always providing secure_cntvoff_init() when building for ARM
> V7.
>
> Reported-by: Arnd Bergmann
> Fixes: 7c607944bc657616 ("ARM: smp: Add initialization of CNTVOFF")
> Fixes: cad160ed0a94927e ("ARM: shmobile: Convert file to use cntvoff")
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Maxime Ripard
Reviewed-by: Simon Horman
> ---
> v2:
> - Add Reviewed-by,
> - Add a dependency on CPU_V7.
> ---
> arch/arm/common/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index 1e9f7af8f70ff6ba..3157be413297e5d2 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -10,7 +10,7 @@ obj-$(CONFIG_DMABOUNCE) += dmabounce.o
> obj-$(CONFIG_SHARP_LOCOMO) += locomo.o
> obj-$(CONFIG_SHARP_PARAM)+= sharpsl_param.o
> obj-$(CONFIG_SHARP_SCOOP)+= scoop.o
> -obj-$(CONFIG_SMP)+= secure_cntvoff.o
> +obj-$(CONFIG_CPU_V7) += secure_cntvoff.o
> obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
> obj-$(CONFIG_MCPM) += mcpm_head.o mcpm_entry.o mcpm_platsmp.o
> vlock.o
> CFLAGS_REMOVE_mcpm_entry.o = -pg
> --
> 2.7.4
>
