Re: [PATCH] media: i2c: adv748x: Fix pixel rate values

[Niklas Söderlund]

Hi Laurent,

On 2018-04-25 01:36:42 +0200, Niklas Söderlund wrote:
> Hi Laurent,
> 
> Thanks for your patch.
> 
> On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote:
> > The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> > include both horizontal and vertical blanking. Both the AFE and HDMI
> > receiver program it incorrectly:
> > 
> > - The HDMI receiver goes to the trouble of removing blanking to compute
> > the rate of active pixels. This is easy to fix by removing the
> > computation and returning the incoming pixel clock rate directly.
> > 
> > - The AFE performs similar calculation, while it should simply return
> > the fixed pixel rate for analog sources, mandated by the ADV748x to be
> > 28.63636 MHz.
> > 
> > Signed-off-by: Laurent Pinchart 
> 
> Reviewed-by: Niklas Söderlund 

I'm afraid I would like to revoke this review tag, please see bellow.

> 
> This patch uncovered a calculation error in rcar-csi2 which compensated 
> for the removing of the blanking in the adv748x, thanks for that! Good 
> thing that it's not merged yet, will include the fix in the next version 
> of the CSI-2 driver.
> 
> > ---
> >  drivers/media/i2c/adv748x/adv748x-afe.c  | 11 +--
> >  drivers/media/i2c/adv748x/adv748x-hdmi.c |  8 +---
> >  2 files changed, 6 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
> > b/drivers/media/i2c/adv748x/adv748x-afe.c
> > index 61514bae7e5c..3e18d5ae813b 100644
> > --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> > +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> > @@ -321,17 +321,16 @@ static const struct v4l2_subdev_video_ops 
> > adv748x_afe_video_ops = {
> >  static int adv748x_afe_propagate_pixelrate(struct adv748x_afe *afe)
> >  {
> > struct v4l2_subdev *tx;
> > -   unsigned int width, height, fps;
> >  
> > tx = adv748x_get_remote_sd(>pads[ADV748X_AFE_SOURCE]);
> > if (!tx)
> > return -ENOLINK;
> >  
> > -   width = 720;
> > -   height = afe->curr_norm & V4L2_STD_525_60 ? 480 : 576;
> > -   fps = afe->curr_norm & V4L2_STD_525_60 ? 30 : 25;
> > -
> > -   return adv748x_csi2_set_pixelrate(tx, width * height * fps);
> > +   /*
> > +* The ADV748x samples analog video signals using an externally supplied
> > +* clock whose frequency is required to be 28.63636 MHz.
> > +*/
> > +   return adv748x_csi2_set_pixelrate(tx, 28636360);

I believe this is wrong. The sampling rate of the AFE is 28.63636 MHz 
but the pixelrate output on the CSI-TXB might not be right? The adv7482 
is a complex and badly documented thing. But it's internal plumbing 
shows that the CVBS signal sampled by the AFE is passed to the SD core 
and then to the TXB CSI-2 transmitter.  

Reading the documentation we have such registers as LTA[1:0] which 
controls the delay between the chroma and luma samples. I do believe the 
adv748x is running with the default of AUTO_PDC_EN which indicates that 
the timings are automatically controlled by the adv748x hardware. And 
there are other registers in the SD core which to me looks like it can 
be configured to make use of the samples so that it won't correlate 1:1 
with the pixel rate.

Looking at the CSI-TXA and CSI-TXB cores which are particularly badly 
documented and the driver contains a lot of undocumented register 
writes. One that is documented and I find interesting in this context is 
EN_AUTOCALC_DPHY_PARAMS which is set 'yes' for the adv748x driver. This 
leads me to believe that the pixel rate output on the CSI-2 bus is not 
correlated with the AFE sampling clock. There are lots of holes in the 
documentation here but some stand out, the undocumented hole around 0xda 
which contains the few documented bits in that area, MIPI_PLL_LOCK_FLAG, 
MIPI_PLL_CLK_DET and MIPI_PLL_EN. Maybe the true link_freq or pixel_rate 
could be read from a undocumented register in that darkness :-)

The real reason I started to dig into this is that after you corrected 
my assumption about how to setup the R-Car CSI-2 receiver link freq this 
change breaks capture of CVBS for me. Looking at how I on your 
suggestion calculate link speed.

link_freq = (pixel_rate * bits_per_sample) / (2 * nr_of_lanes)

pixel_rate = 28636360 (from the adv748x V4L2_CID_PIXEL_RATE)
bits_per_sample = 16 (adv748x reports MEDIA_BUS_FMT_UYVY8_2X8)
nr_of_lanes = 1 (Using TXB of the adv748x)

Gives a link_freq of 229Mhz or as the R-Car CSI-2 deals with in Mbps 
~460Mbps as CSI-2 is DDR. If I try to capture CVBS using such a high 
link speed capture fail. I tried using the lowest link speed R-Car CSI-2 
receiver supports of 80Mbps and then capture works perfectly. But 
settings as high as 235Mps still manage to capture.

I'm not sure how to proceed here and have the adv748x and rcar-csi2 to 
agree on the link speed. But I do think this is wrong.

The change for the adv748x HDMI pixel rate is tested and works for both 

[PATCH v9 01/12] ARM: Allow this header to be included by assembly files

[Mylène Josserand]

From: Doug Berger 

The constants defined in this file are equally useful in assembly and C
source files. The arm64 architecture version of this file allows
inclusion in both assembly and C source files, so this this commit adds
that capability to the arm architecture version so that the constants
don't need to be defined in multiple places.

Signed-off-by: Doug Berger 
Signed-off-by: Florian Fainelli 
Signed-off-by: Mylène Josserand 
---
 arch/arm/include/asm/cputype.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index cb546425da8a..e7632f536633 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -2,9 +2,6 @@
 #ifndef __ASM_ARM_CPUTYPE_H
 #define __ASM_ARM_CPUTYPE_H
 
-#include 
-#include 
-
 #define CPUID_ID   0
 #define CPUID_CACHETYPE1
 #define CPUID_TCM  2
@@ -98,6 +95,11 @@
 /* Qualcomm implemented cores */
 #define ARM_CPU_PART_SCORPION  0x510002d0
 
+#ifndef __ASSEMBLY__
+
+#include 
+#include 
+
 extern unsigned int processor_id;
 
 #ifdef CONFIG_CPU_CP15
@@ -326,4 +328,6 @@ static inline int __attribute_const__ 
cpuid_feature_extract_field(u32 features,
 #define cpuid_feature_extract(reg, field) \
cpuid_feature_extract_field(read_cpuid_ext(reg), field)
 
+#endif /* __ASSEMBLY__ */
+
 #endif
-- 
2.11.0

[PATCH v9 03/12] ARM: dts: sun8i: Add CPUCFG device node for A83T dtsi

[Mylène Josserand]

As we found in sun9i-a80, CPUCFG is a collection of registers that are
mapped to the SoC's signals from each individual processor core and
associated peripherals.

These registers are used for SMP bringup and CPU hotplugging.

Signed-off-by: Mylène Josserand 
Reviewed-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 379981389eea..a50ccb475de8 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -349,6 +349,11 @@
};
};
 
+   cpucfg@170 {
+   compatible = "allwinner,sun8i-a83t-cpucfg";
+   reg = <0x0170 0x400>;
+   };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
-- 
2.11.0

[PATCH v9 02/12] ARM: sunxi: smp: Move assembly code into a file

[Mylène Josserand]

Move the assembly code for cluster cache enabling and resuming
into an assembly file instead of having it directly in C code.

Remove the CFLAGS because we are using the ARM directive "arch"
instead.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
---
 arch/arm/mach-sunxi/Makefile  |  2 +-
 arch/arm/mach-sunxi/headsmp.S | 80 +
 arch/arm/mach-sunxi/mc_smp.c  | 82 +++
 3 files changed, 85 insertions(+), 79 deletions(-)
 create mode 100644 arch/arm/mach-sunxi/headsmp.S

diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 7de9cc286d53..71429aa85143 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -1,5 +1,5 @@
 CFLAGS_mc_smp.o+= -march=armv7-a
 
 obj-$(CONFIG_ARCH_SUNXI) += sunxi.o
-obj-$(CONFIG_ARCH_SUNXI_MC_SMP) += mc_smp.o
+obj-$(CONFIG_ARCH_SUNXI_MC_SMP) += mc_smp.o headsmp.o
 obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
new file mode 100644
index ..37dc772701f3
--- /dev/null
+++ b/arch/arm/mach-sunxi/headsmp.S
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2018 Chen-Yu Tsai
+ * Copyright (c) 2018 Bootlin
+ *
+ * Chen-Yu Tsai 
+ * Mylène Josserand 
+ *
+ * SMP support for sunxi based systems with Cortex A7/A15
+ *
+ */
+
+#include 
+#include 
+#include 
+
+ENTRY(sunxi_mc_smp_cluster_cache_enable)
+   .arch   armv7-a
+   /*
+* Enable cluster-level coherency, in preparation for turning on the 
MMU.
+*
+* Also enable regional clock gating and L2 data latency settings for
+* Cortex-A15. These settings are from the vendor kernel.
+*/
+   mrc p15, 0, r1, c0, c0, 0
+   movwr2, #(ARM_CPU_PART_MASK & 0x)
+   movtr2, #(ARM_CPU_PART_MASK >> 16)
+   and r1, r1, r2
+   movwr2, #(ARM_CPU_PART_CORTEX_A15 & 0x)
+   movtr2, #(ARM_CPU_PART_CORTEX_A15 >> 16)
+   cmp r1, r2
+   bne not_a15
+
+   /* The following is Cortex-A15 specific */
+
+   /* ACTLR2: Enable CPU regional clock gates */
+   mrc p15, 1, r1, c15, c0, 4
+   orr r1, r1, #(0x1 << 31)
+   mcr p15, 1, r1, c15, c0, 4
+
+   /* L2ACTLR */
+   mrc p15, 1, r1, c15, c0, 0
+   /* Enable L2, GIC, and Timer regional clock gates */
+   orr r1, r1, #(0x1 << 26)
+   /* Disable clean/evict from being pushed to external */
+   orr r1, r1, #(0x1<<3)
+   mcr p15, 1, r1, c15, c0, 0
+
+   /* L2CTRL: L2 data RAM latency */
+   mrc p15, 1, r1, c9, c0, 2
+   bic r1, r1, #(0x7 << 0)
+   orr r1, r1, #(0x3 << 0)
+   mcr p15, 1, r1, c9, c0, 2
+
+   /* End of Cortex-A15 specific setup */
+   not_a15:
+
+   /* Get value of sunxi_mc_smp_first_comer */
+   adr r1, first
+   ldr r0, [r1]
+   ldr r0, [r1, r0]
+
+   /* Skip cci_enable_port_for_self if not first comer */
+   cmp r0, #0
+   bxeqlr
+   b   cci_enable_port_for_self
+
+   .align 2
+   first: .word sunxi_mc_smp_first_comer - .
+ENDPROC(sunxi_mc_smp_cluster_cache_enable)
+
+ENTRY(sunxi_mc_smp_secondary_startup)
+   bl  sunxi_mc_smp_cluster_cache_enable
+   b   secondary_startup
+ENDPROC(sunxi_mc_smp_secondary_startup)
+
+ENTRY(sunxi_mc_smp_resume)
+   bl  sunxi_mc_smp_cluster_cache_enable
+   b   cpu_resume
+ENDPROC(sunxi_mc_smp_resume)
diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index c0246ec54a0a..727968d6a3e5 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -72,6 +72,9 @@ static void __iomem *cpucfg_base;
 static void __iomem *prcm_base;
 static void __iomem *sram_b_smp_base;
 
+extern void sunxi_mc_smp_secondary_startup(void);
+extern void sunxi_mc_smp_resume(void);
+
 static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
 {
struct device_node *node;
@@ -300,74 +303,7 @@ static void sunxi_cluster_cache_disable_without_axi(void)
 }
 
 static int sunxi_mc_smp_cpu_table[SUNXI_NR_CLUSTERS][SUNXI_CPUS_PER_CLUSTER];
-static int sunxi_mc_smp_first_comer;
-
-/*
- * Enable cluster-level coherency, in preparation for turning on the MMU.
- *
- * Also enable regional clock gating and L2 data latency settings for
- * Cortex-A15. These settings are from the vendor kernel.
- */
-static void __naked sunxi_mc_smp_cluster_cache_enable(void)
-{
-   asm volatile (
-   "mrcp15, 0, r1, c0, c0, 0\n"
-   "movw   r2, #" __stringify(ARM_CPU_PART_MASK & 0x) "\n"
-   "movt   r2, #" __stringify(ARM_CPU_PART_MASK >> 16) "\n"
-   "andr1, r1, r2\n"
-   "movw   r2, #" __stringify(ARM_CPU_PART_CORTEX_A15 & 0x) 
"\n"
-   "movt   r2, #" 

[PATCH v9 05/12] ARM: dts: sun8i: a83t: Add CCI-400 node

[Mylène Josserand]

Add CCI-400 node and control-port on CPUs needed by SMP bringup.

Signed-off-by: Mylène Josserand 
Reviewed-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 53ace066b7dc..0669b8dc499d 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -66,6 +66,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
operating-points-v2 = <_opp_table>;
+   cci-control-port = <_control0>;
reg = <0>;
};
 
@@ -73,6 +74,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
operating-points-v2 = <_opp_table>;
+   cci-control-port = <_control0>;
reg = <1>;
};
 
@@ -80,6 +82,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
operating-points-v2 = <_opp_table>;
+   cci-control-port = <_control0>;
reg = <2>;
};
 
@@ -87,6 +90,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
operating-points-v2 = <_opp_table>;
+   cci-control-port = <_control0>;
reg = <3>;
};
 
@@ -96,6 +100,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
operating-points-v2 = <_opp_table>;
+   cci-control-port = <_control1>;
reg = <0x100>;
};
 
@@ -103,6 +108,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
operating-points-v2 = <_opp_table>;
+   cci-control-port = <_control1>;
reg = <0x101>;
};
 
@@ -110,6 +116,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
operating-points-v2 = <_opp_table>;
+   cci-control-port = <_control1>;
reg = <0x102>;
};
 
@@ -117,6 +124,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
operating-points-v2 = <_opp_table>;
+   cci-control-port = <_control1>;
reg = <0x103>;
};
};
@@ -354,6 +362,39 @@
reg = <0x0170 0x400>;
};
 
+   cci@179 {
+   compatible = "arm,cci-400";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x0179 0x1>;
+   ranges = <0x0 0x0179 0x1>;
+
+   cci_control0: slave-if@4000 {
+   compatible = "arm,cci-400-ctrl-if";
+   interface-type = "ace";
+   reg = <0x4000 0x1000>;
+   };
+
+   cci_control1: slave-if@5000 {
+   compatible = "arm,cci-400-ctrl-if";
+   interface-type = "ace";
+   reg = <0x5000 0x1000>;
+   };
+
+   pmu@9000 {
+   compatible = "arm,cci-400-pmu,r1";
+   reg = <0x9000 0x5000>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+;
+   };
+   };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
-- 
2.11.0

[PATCH v9 04/12] ARM: dts: sun8i: Add R_CPUCFG device node for the A83T dtsi

[Mylène Josserand]

The R_CPUCFG is a collection of registers needed for SMP bringup
on clusters and cluster's reset.
For the moment, documentation about this register is found in
Allwinner's code only.

Signed-off-by: Mylène Josserand 
Reviewed-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index a50ccb475de8..53ace066b7dc 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -938,6 +938,11 @@
#reset-cells = <1>;
};
 
+   r_cpucfg@1f01c00 {
+   compatible = "allwinner,sun8i-a83t-r-cpucfg";
+   reg = <0x1f01c00 0x400>;
+   };
+
r_pio: pinctrl@1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
-- 
2.11.0

[PATCH v9 07/12] ARM: sunxi: Add initialization of CNTVOFF

[Mylène Josserand]

Add the initialization of CNTVOFF for sun8i-a83t.

For boot CPU, create a new machine that handles this
function's call in an "init_early" callback. We need to initialize
CNTVOFF before the arch timer's initialization otherwise, it will
not be taken into account and fails to boot correctly.
Because of that, this function can't be called in SMP's early_initcall
function which is called after timer's init.

For secondary CPUs, add this function into secondary_startup
assembly entry.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
---
 arch/arm/mach-sunxi/headsmp.S |  1 +
 arch/arm/mach-sunxi/sunxi.c   | 20 +++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
index 37dc772701f3..32d76be98541 100644
--- a/arch/arm/mach-sunxi/headsmp.S
+++ b/arch/arm/mach-sunxi/headsmp.S
@@ -71,6 +71,7 @@ ENDPROC(sunxi_mc_smp_cluster_cache_enable)
 
 ENTRY(sunxi_mc_smp_secondary_startup)
bl  sunxi_mc_smp_cluster_cache_enable
+   bl  secure_cntvoff_init
b   secondary_startup
 ENDPROC(sunxi_mc_smp_secondary_startup)
 
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 5e9602ce1573..752e0748b0c8 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -16,6 +16,7 @@
 #include 
 
 #include 
+#include 
 
 static const char * const sunxi_board_dt_compat[] = {
"allwinner,sun4i-a10",
@@ -62,7 +63,6 @@ MACHINE_END
 static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a23",
"allwinner,sun8i-a33",
-   "allwinner,sun8i-a83t",
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
"allwinner,sun8i-r40",
@@ -75,6 +75,24 @@ DT_MACHINE_START(SUN8I_DT, "Allwinner sun8i Family")
.dt_compat  = sun8i_board_dt_compat,
 MACHINE_END
 
+void __init sun8i_a83t_cntvoff_init(void)
+{
+#ifdef CONFIG_SMP
+   secure_cntvoff_init();
+#endif
+}
+
+static const char * const sun8i_a83t_cntvoff_board_dt_compat[] = {
+   "allwinner,sun8i-a83t",
+   NULL,
+};
+
+DT_MACHINE_START(SUN8I_A83T_CNTVOFF_DT, "Allwinner sun8i-a83t board")
+   .init_early = sun8i_a83t_cntvoff_init,
+   .init_time  = sun6i_timer_init,
+   .dt_compat  = sun8i_a83t_cntvoff_board_dt_compat,
+MACHINE_END
+
 static const char * const sun9i_board_dt_compat[] = {
"allwinner,sun9i-a80",
NULL,
-- 
2.11.0

[PATCH v9 06/12] ARM: smp: Add initialization of CNTVOFF

[Mylène Josserand]

The CNTVOFF register from arch timer is uninitialized.
It should be done by the bootloader but it is currently not the case,
even for boot CPU because this SoC is booting in secure mode.
It leads to an random offset value meaning that each CPU will have a
different time, which isn't working very well.

Add assembly code used for boot CPU and secondary CPU cores to make
sure that the CNTVOFF register is initialized. Because this code can
be used by different platforms, add this assembly file in ARM's common
folder.

Signed-off-by: Mylène Josserand 
Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 
---
 arch/arm/common/Makefile  |  1 +
 arch/arm/common/secure_cntvoff.S  | 31 +++
 arch/arm/include/asm/secure_cntvoff.h |  8 
 3 files changed, 40 insertions(+)
 create mode 100644 arch/arm/common/secure_cntvoff.S
 create mode 100644 arch/arm/include/asm/secure_cntvoff.h

diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 70b4a14ed993..1e9f7af8f70f 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -10,6 +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_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
diff --git a/arch/arm/common/secure_cntvoff.S b/arch/arm/common/secure_cntvoff.S
new file mode 100644
index ..68a4a8344319
--- /dev/null
+++ b/arch/arm/common/secure_cntvoff.S
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2014 Renesas Electronics Corporation
+ *
+ * Initialization of CNTVOFF register from secure mode
+ *
+ */
+
+#include 
+#include 
+
+ENTRY(secure_cntvoff_init)
+   .arch   armv7-a
+   /*
+* CNTVOFF has to be initialized either from non-secure Hypervisor
+* mode or secure Monitor mode with SCR.NS==1. If TrustZone is enabled
+* then it should be handled by the secure code
+*/
+   cps #MON_MODE
+   mrc p15, 0, r1, c1, c1, 0   /* Get Secure Config */
+   orr r0, r1, #1
+   mcr p15, 0, r0, c1, c1, 0   /* Set Non Secure bit */
+   isb
+   mov r0, #0
+   mcrrp15, 4, r0, r0, c14 /* CNTVOFF = 0 */
+   isb
+   mcr p15, 0, r1, c1, c1, 0   /* Set Secure bit */
+   isb
+   cps #SVC_MODE
+   ret lr
+ENDPROC(secure_cntvoff_init)
diff --git a/arch/arm/include/asm/secure_cntvoff.h 
b/arch/arm/include/asm/secure_cntvoff.h
new file mode 100644
index ..1f93aee1f630
--- /dev/null
+++ b/arch/arm/include/asm/secure_cntvoff.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASMARM_ARCH_CNTVOFF_H
+#define __ASMARM_ARCH_CNTVOFF_H
+
+extern void secure_cntvoff_init(void);
+
+#endif
-- 
2.11.0

[PATCH v9 09/12] ARM: sun9i: smp: Add is_a83t field

[Mylène Josserand]

To prepare the support of sun8i-a83t, add a field in the smp_data
structure to know if we are on sun9i-a80 or sun8i-a83t.

Add also a global variable to retrieve which architecture we are
having.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
---
 arch/arm/mach-sunxi/mc_smp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index 03f021d0c73e..fc10e3a3268f 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -74,6 +74,7 @@ static void __iomem *sram_b_smp_base;
 
 extern void sunxi_mc_smp_secondary_startup(void);
 extern void sunxi_mc_smp_resume(void);
+static bool is_a83t;
 
 static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
 {
@@ -624,6 +625,7 @@ struct sunxi_mc_smp_nodes {
 struct sunxi_mc_smp_data {
const char *enable_method;
int (*get_smp_nodes)(struct sunxi_mc_smp_nodes *nodes);
+   bool is_a83t;
 };
 
 static void __init sunxi_mc_smp_put_nodes(struct sunxi_mc_smp_nodes *nodes)
@@ -697,6 +699,8 @@ static int __init sunxi_mc_smp_init(void)
break;
}
 
+   is_a83t = sunxi_mc_smp_data[i].is_a83t;
+
of_node_put(node);
if (ret)
return -ENODEV;
-- 
2.11.0

[PATCH v9 11/12] ARM: dts: sun8i: Add enable-method for SMP support for the A83T SoC

[Mylène Josserand]

Add the use of enable-method property for SMP support which allows
to handle the SMP support for this specific SoC.

This commit adds enable-method properties to all CPU nodes.

Signed-off-by: Mylène Josserand 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 0669b8dc499d..2be23d600957 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -67,6 +67,7 @@
device_type = "cpu";
operating-points-v2 = <_opp_table>;
cci-control-port = <_control0>;
+   enable-method = "allwinner,sun8i-a83t-smp";
reg = <0>;
};
 
@@ -75,6 +76,7 @@
device_type = "cpu";
operating-points-v2 = <_opp_table>;
cci-control-port = <_control0>;
+   enable-method = "allwinner,sun8i-a83t-smp";
reg = <1>;
};
 
@@ -83,6 +85,7 @@
device_type = "cpu";
operating-points-v2 = <_opp_table>;
cci-control-port = <_control0>;
+   enable-method = "allwinner,sun8i-a83t-smp";
reg = <2>;
};
 
@@ -91,6 +94,7 @@
device_type = "cpu";
operating-points-v2 = <_opp_table>;
cci-control-port = <_control0>;
+   enable-method = "allwinner,sun8i-a83t-smp";
reg = <3>;
};
 
@@ -101,6 +105,7 @@
device_type = "cpu";
operating-points-v2 = <_opp_table>;
cci-control-port = <_control1>;
+   enable-method = "allwinner,sun8i-a83t-smp";
reg = <0x100>;
};
 
@@ -109,6 +114,7 @@
device_type = "cpu";
operating-points-v2 = <_opp_table>;
cci-control-port = <_control1>;
+   enable-method = "allwinner,sun8i-a83t-smp";
reg = <0x101>;
};
 
@@ -117,6 +123,7 @@
device_type = "cpu";
operating-points-v2 = <_opp_table>;
cci-control-port = <_control1>;
+   enable-method = "allwinner,sun8i-a83t-smp";
reg = <0x102>;
};
 
@@ -125,6 +132,7 @@
device_type = "cpu";
operating-points-v2 = <_opp_table>;
cci-control-port = <_control1>;
+   enable-method = "allwinner,sun8i-a83t-smp";
reg = <0x103>;
};
};
-- 
2.11.0

[PATCH v9 08/12] ARM: sun9i: smp: Rename clusters's power-off

[Mylène Josserand]

To prepare the support for sun8i-a83t, rename the macro that handles
the power-off of clusters because it is different from sun9i-a80 to
sun8i-a83t.

The power off register for clusters are different from a80 and a83t.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
Reviewed-by: Chen-Yu Tsai 
---
 arch/arm/mach-sunxi/mc_smp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index 727968d6a3e5..03f021d0c73e 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -60,7 +60,7 @@
 #define PRCM_CPU_PO_RST_CTRL_CORE(n)   BIT(n)
 #define PRCM_CPU_PO_RST_CTRL_CORE_ALL  0xf
 #define PRCM_PWROFF_GATING_REG(c)  (0x100 + 0x4 * (c))
-#define PRCM_PWROFF_GATING_REG_CLUSTER BIT(4)
+#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I   BIT(4)
 #define PRCM_PWROFF_GATING_REG_CORE(n) BIT(n)
 #define PRCM_PWR_SWITCH_REG(c, cpu)(0x140 + 0x10 * (c) + 0x4 * (cpu))
 #define PRCM_CPU_SOFT_ENTRY_REG0x164
@@ -255,7 +255,7 @@ static int sunxi_cluster_powerup(unsigned int cluster)
 
/* clear cluster power gate */
reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
-   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER;
+   reg &= ~PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
udelay(20);
 
@@ -452,7 +452,7 @@ static int sunxi_cluster_powerdown(unsigned int cluster)
/* gate cluster power */
pr_debug("%s: gate cluster power\n", __func__);
reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
-   reg |= PRCM_PWROFF_GATING_REG_CLUSTER;
+   reg |= PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I;
writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
udelay(20);
 
-- 
2.11.0

[PATCH v9 10/12] ARM: sun8i: smp: Add support for A83T

[Mylène Josserand]

Add the support for A83T.

A83T SoC has an additional register than A80 to handle CPU configurations:
R_CPUS_CFG. Information about the register comes from Allwinner's BSP
driver.
An important difference is the Power Off Gating register for clusters
which is BIT(4) in case of SUN9I-A80 and BIT(0) in case of SUN8I-A83T.
There is also a bit swap between sun8i-a83t and sun9i-a80 that must be
handled.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
---
 arch/arm/mach-sunxi/Kconfig  |   2 +-
 arch/arm/mach-sunxi/mc_smp.c | 151 ++-
 2 files changed, 137 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index ce53ceaf4cc5..d9c8ecf88ec6 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -51,7 +51,7 @@ config MACH_SUN9I
 config ARCH_SUNXI_MC_SMP
bool
depends on SMP
-   default MACH_SUN9I
+   default MACH_SUN9I || MACH_SUN8I
select ARM_CCI400_PORT_CTRL
select ARM_CPU_SUSPEND
 
diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index fc10e3a3268f..b4037b603897 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -55,22 +55,31 @@
 #define CPUCFG_CX_RST_CTRL_L2_RST  BIT(8)
 #define CPUCFG_CX_RST_CTRL_CX_RST(n)   BIT(4 + (n))
 #define CPUCFG_CX_RST_CTRL_CORE_RST(n) BIT(n)
+#define CPUCFG_CX_RST_CTRL_CORE_RST_ALL(0xf << 0)
 
 #define PRCM_CPU_PO_RST_CTRL(c)(0x4 + 0x4 * (c))
 #define PRCM_CPU_PO_RST_CTRL_CORE(n)   BIT(n)
 #define PRCM_CPU_PO_RST_CTRL_CORE_ALL  0xf
 #define PRCM_PWROFF_GATING_REG(c)  (0x100 + 0x4 * (c))
+/* The power off register for clusters are different from a80 and a83t */
+#define PRCM_PWROFF_GATING_REG_CLUSTER_SUN8I   BIT(0)
 #define PRCM_PWROFF_GATING_REG_CLUSTER_SUN9I   BIT(4)
 #define PRCM_PWROFF_GATING_REG_CORE(n) BIT(n)
 #define PRCM_PWR_SWITCH_REG(c, cpu)(0x140 + 0x10 * (c) + 0x4 * (cpu))
 #define PRCM_CPU_SOFT_ENTRY_REG0x164
 
+/* R_CPUCFG registers, specific to sun8i-a83t */
+#define R_CPUCFG_CLUSTER_PO_RST_CTRL(c)(0x30 + (c) * 0x4)
+#define R_CPUCFG_CLUSTER_PO_RST_CTRL_CORE(n)   BIT(n)
+#define R_CPUCFG_CPU_SOFT_ENTRY_REG0x01a4
+
 #define CPU0_SUPPORT_HOTPLUG_MAGIC00xFA50392F
 #define CPU0_SUPPORT_HOTPLUG_MAGIC10x790DCA3A
 
 static void __iomem *cpucfg_base;
 static void __iomem *prcm_base;
 static void __iomem *sram_b_smp_base;
+static void __iomem *r_cpucfg_base;
 
 extern void sunxi_mc_smp_secondary_startup(void);
 extern void sunxi_mc_smp_resume(void);
@@ -161,6 +170,16 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned 
int cluster)
reg &= ~PRCM_CPU_PO_RST_CTRL_CORE(cpu);
writel(reg, prcm_base + PRCM_CPU_PO_RST_CTRL(cluster));
 
+   if (is_a83t) {
+   /* assert cpu power-on reset */
+   reg  = readl(r_cpucfg_base +
+R_CPUCFG_CLUSTER_PO_RST_CTRL(cluster));
+   reg &= ~(R_CPUCFG_CLUSTER_PO_RST_CTRL_CORE(cpu));
+   writel(reg, r_cpucfg_base +
+  R_CPUCFG_CLUSTER_PO_RST_CTRL(cluster));
+   udelay(10);
+   }
+
/* Cortex-A7: hold L1 reset disable signal low */
if (!sunxi_core_is_cortex_a15(cpu, cluster)) {
reg = readl(cpucfg_base + CPUCFG_CX_CTRL_REG0(cluster));
@@ -184,17 +203,38 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned 
int cluster)
/* open power switch */
sunxi_cpu_power_switch_set(cpu, cluster, true);
 
+   /* Handle A83T bit swap */
+   if (is_a83t) {
+   if (cpu == 0)
+   cpu = 4;
+   }
+
/* clear processor power gate */
reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
reg &= ~PRCM_PWROFF_GATING_REG_CORE(cpu);
writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
udelay(20);
 
+   /* Handle A83T bit swap */
+   if (is_a83t) {
+   if (cpu == 4)
+   cpu = 0;
+   }
+
/* de-assert processor power-on reset */
reg = readl(prcm_base + PRCM_CPU_PO_RST_CTRL(cluster));
reg |= PRCM_CPU_PO_RST_CTRL_CORE(cpu);
writel(reg, prcm_base + PRCM_CPU_PO_RST_CTRL(cluster));
 
+   if (is_a83t) {
+   reg  = readl(r_cpucfg_base +
+R_CPUCFG_CLUSTER_PO_RST_CTRL(cluster));
+   reg |= R_CPUCFG_CLUSTER_PO_RST_CTRL_CORE(cpu);
+   writel(reg, r_cpucfg_base +
+  R_CPUCFG_CLUSTER_PO_RST_CTRL(cluster));
+   udelay(10);
+   }
+
/* de-assert all processor resets */
reg = readl(cpucfg_base + CPUCFG_CX_RST_CTRL(cluster));
reg |= CPUCFG_CX_RST_CTRL_DBG_RST(cpu);
@@ -216,6 +256,14 @@ static int sunxi_cluster_powerup(unsigned int cluster)
if (cluster >= SUNXI_NR_CLUSTERS)

[PATCH v9 12/12] ARM: shmobile: Convert file to use cntvoff

[Mylène Josserand]

Now that a common function is available for CNTVOFF's
initialization, let's convert shmobile-apmu code to use
this function.

Signed-off-by: Mylène Josserand 
Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 
Acked-by: Simon Horman 
---
 arch/arm/mach-shmobile/common.h  |  1 -
 arch/arm/mach-shmobile/headsmp-apmu.S| 22 +-
 arch/arm/mach-shmobile/setup-rcar-gen2.c |  3 ++-
 3 files changed, 3 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index 43c1ac696274..2109f123bdfb 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -2,7 +2,6 @@
 #ifndef __ARCH_MACH_COMMON_H
 #define __ARCH_MACH_COMMON_H
 
-extern void shmobile_init_cntvoff(void);
 extern void shmobile_init_delay(void);
 extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
diff --git a/arch/arm/mach-shmobile/headsmp-apmu.S 
b/arch/arm/mach-shmobile/headsmp-apmu.S
index 5672b5849401..d49ab194766a 100644
--- a/arch/arm/mach-shmobile/headsmp-apmu.S
+++ b/arch/arm/mach-shmobile/headsmp-apmu.S
@@ -11,29 +11,9 @@
 #include 
 #include 
 
-ENTRY(shmobile_init_cntvoff)
-   /*
-* CNTVOFF has to be initialized either from non-secure Hypervisor
-* mode or secure Monitor mode with SCR.NS==1. If TrustZone is enabled
-* then it should be handled by the secure code
-*/
-   cps #MON_MODE
-   mrc p15, 0, r1, c1, c1, 0   /* Get Secure Config */
-   orr r0, r1, #1
-   mcr p15, 0, r0, c1, c1, 0   /* Set Non Secure bit */
-   instr_sync
-   mov r0, #0
-   mcrrp15, 4, r0, r0, c14 /* CNTVOFF = 0 */
-   instr_sync
-   mcr p15, 0, r1, c1, c1, 0   /* Set Secure bit */
-   instr_sync
-   cps #SVC_MODE
-   ret lr
-ENDPROC(shmobile_init_cntvoff)
-
 #ifdef CONFIG_SMP
 ENTRY(shmobile_boot_apmu)
-   bl  shmobile_init_cntvoff
+   bl  secure_cntvoff_init
b   secondary_startup
 ENDPROC(shmobile_boot_apmu)
 #endif
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c 
b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index 5561dbed7a33..4a881026d740 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "common.h"
 #include "rcar-gen2.h"
 
@@ -70,7 +71,7 @@ void __init rcar_gen2_timer_init(void)
void __iomem *base;
u32 freq;
 
-   shmobile_init_cntvoff();
+   secure_cntvoff_init();
 
if (of_machine_is_compatible("renesas,r8a7745") ||
of_machine_is_compatible("renesas,r8a7792") ||
-- 
2.11.0

[PATCH v9 00/12] Sunxi: Add SMP support on A83T

[Mylène Josserand]

Hello everyone,

This is a V9 of my series that adds SMP support for Allwinner sun8i-a83t.
Based on sunxi's tree, sunxi/for-next branch.
Depends on a patch from Doug Berger that allows to include the "cpu-type"
header on assembly files that I included in my series (patch 01).

The difference with the v8 is just that the machine is renamed in sun8i-a83t
(see patch 07), according to Maxime's review.

Thank you in advance,
Best regards,
Mylène

Changes from v8:
- Rename machine into "sun8i-a83t"

Changes from v7:
- Add the patch of Doug Berger in my series.
- Rename the machine name to start secure_cntvoff into "sun8i-a83t",
according to Maxime's review.
- Change the type of is_a83t field from integer into boolean.

Changes from v6:
- Correct the commit log on patch 07 according to Sergei Shtylyov's
review.
- Rename the field "is_sun8i" into "is_a83t".
- Add all Tested-by and Reviewed-by from previous version.

Changes from v5:
- Remove my patch 01 and use the patch of Doug Berger to be able to
include the cpu-type header on assembly files.
- Rename smp_init_cntvoff function into secure_cntvoff_init according
to Marc Zyngier's review.
- According to Chen-Yu and Maxime's reviews, remove the patch that was
moving structures. Instead of using an index to retrieve which
architecture we are having, use a global variable.
- Merge the 2 patches that move assembly code from C to assembly file.
- Use a sun8i field instead of sun9i to know on which architecture we
are using because many modifications/additions of the code are for
sun8i-a83t.
- Rework the patch "add is_sun8i field" to add only this field in this
patch. The part of the patch that was starting to handle the differences
between sun8i-a83t and sun9i-a80 is merged in the patch that adds the
support of sun8i-a83t.
- Add a new patch that refactor the shmobile code to use the new function
secure_cntvoff_init introduced in this series.

Changes from v4:
- Rebased my series according to new Chen-Yu series:
   "ARM: sunxi: Clean and improvements for multi-cluster SMP"
   https://lkml.org/lkml/2018/3/8/886
- Updated my series according to Marc Zyngier's reviews to add CNTVOFF
initialization's function into ARM's common part. Thanks to that, other
platforms such as Renesa can use this function.
- For boot CPU, create a new machine to handle the CNTVOFF initialization
using "init_early" callback.

Changes from v3:
- Take into account Maxime's reviews:
- split the first patch into 4 new patches: add sun9i device tree
parsing, rename some variables, add a83t support and finally,
add hotplug support.
- Move the code of previous patch 07 (to disable CPU0 disabling)
into hotplug support patch (see patch 04)
- Remove the patch that added PRCM register because it is already
available. Because of that, update the device tree parsing to use
"sun8i-a83t-r-ccu".
- Use a variable to know which SoC we currently have
- Take into account Chen-Yu's reviews: create two iounmap functions
to release the resources of the device tree parsing.
- Take into account Marc's review: Update the code to initialize CNTVOFF
register. As there is already assembly code in the driver, I decided
to create an assembly file not to mix assembly and C code.
For that, I create 3 new patches: move the current assembly code that
handles the cluster cache enabling into a file, move the cpu_resume entry
in this file and finally, add a new assembly entry to initialize the timer
offset for boot CPU and secondary CPUs.

Changes from v2:
- Rebased my modifications according to new Chen Yu's patch series
that adds SMP support for sun9i-a80 (without MCPM).
- Split the device-tree patches into 3 patches for CPUCFG, R_CPUCFG
and PRCM registers for more visibility.
- The hotplug of CPU0 is currently not working (even after trying what
Allwinner's code is doing) so remove the possibility of disabling
this CPU. Created a new patch for it.

Changes from v1:
- Add Chen Yu's patch in my series (see path 01)
- Add new compatibles for prcm and cpucfg registers for sun8i-a83t.
Create two functions to separate the DT parsing of sun9i-a80 and
sun8i-a83t.
- Thanks to Maxime's review: order device tree's nodes according
to physical addresses, remove unused label and fix registers' sizes.
Update the commit log and commit title of my last patch (see
patch 05).

Doug Berger (1):
  ARM: Allow this header to be included by assembly files

Mylène Josserand (11):
  ARM: sunxi: smp: Move assembly code into a file
  ARM: dts: sun8i: Add CPUCFG device node for A83T dtsi
  ARM: dts: sun8i: Add R_CPUCFG device node for the A83T dtsi
  ARM: dts: sun8i: a83t: Add CCI-400 node
  ARM: smp: Add initialization of CNTVOFF
  ARM: sunxi: Add 

Re: [PATCH] media: vsp1: cleanup a false positive warning

[Mauro Carvalho Chehab]

Em Fri, 4 May 2018 16:37:23 +0200
Geert Uytterhoeven  escreveu:

> Hi Mauro,
> 
> On Fri, May 4, 2018 at 2:13 PM, Mauro Carvalho Chehab
>  wrote:
> > With the new vsp1 code changes introduced by changeset
> > f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines 
> > dynamically"),
> > smatch complains with:
> > drivers/media/platform/vsp1/vsp1_drm.c:262 
> > vsp1_du_pipeline_setup_bru() error: we previously assumed 'pipe->bru' could 
> > be null (see line 180)
> >
> > This is a false positive, as, if pipe->bru is NULL, the brx
> > var will be different, with ends by calling a code that will
> > set pipe->bru to another value.
> >
> > Yet, cleaning this false positive is as easy as adding an explicit
> > check if pipe->bru is NULL.
> >
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> Thanks for your patch!
> 
> s/bru/brx/

Hah, yeah... there was a rename from bru->brx... 
I guess that confused me, as I saw this error before the renaming patch
(even though I wrote it to be applied after them) :-)

> 
> > --- a/drivers/media/platform/vsp1/vsp1_drm.c
> > +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> > @@ -185,7 +185,7 @@ static int vsp1_du_pipeline_setup_brx(struct 
> > vsp1_device *vsp1,
> > brx = >brs->entity;
> >
> > /* Switch BRx if needed. */
> > -   if (brx != pipe->brx) {
> > +   if (brx != pipe->brx || !pipe->brx) {
> > struct vsp1_entity *released_brx = NULL;
> >
> > /* Release our BRx if we have one. */  
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 



Thanks,
Mauro

Re: [PATCH/RFT 0/3] mmc: renesas_sdhi: add support for r8a77965

[Wolfram Sang]

On Tue, May 01, 2018 at 05:27:07PM +0200, Simon Horman wrote:
> On Mon, Apr 30, 2018 at 04:48:13AM +0900, Yoshihiro Kaneko wrote:
> > This series adds SDHI device support for r8a77965.
> > 
> > This series is based on the next branch of Ulf Hansson's mmc tree.
> > 
> > Masaharu Hayakawa (1):
> >   mmc: renesas_sdhi: Add r8a77965 support
> > 
> > Takeshi Kihara (2):
> >   pinctrl: sh-pfc: r8a77965: Add SDHI pins, groups and functions
> 
> Thanks,
> 
> I did some testing of these patches applied on top of a merge of:
> * renesas-devel-20180430-v4.17-rc3
> * mmc/next (5bec8e5878e2)
> 
> And things seem to work :)
> 
> Tested-by: Simon Horman 

Same here. Checked with the internal eMMC (the MMC core needs to do some
retries for tuning with HS200 on cold-boot, but then it works. Always
immediately works after warm-boot), and both SDHI slots. Checksumming
files with SDR50 works fine.

Tested-by: Wolfram Sang 

> # time dd if=/dev/mmcblk0 of=/dev/null bs=1M count=2048

It may be a little bit more typing but I think it is worth the effort to
catch more bugs: dd'ing a file from /dev/urandom to /tmp, checksum it
and write it to the SD cards, re-read and compare the md5sums?

Thanks all!



signature.asc
Description: PGP signature

Re: [PATCH] media: vsp1: cleanup a false positive warning

[Geert Uytterhoeven]

Hi Mauro,

On Fri, May 4, 2018 at 2:13 PM, Mauro Carvalho Chehab
 wrote:
> With the new vsp1 code changes introduced by changeset
> f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines 
> dynamically"),
> smatch complains with:
> drivers/media/platform/vsp1/vsp1_drm.c:262 
> vsp1_du_pipeline_setup_bru() error: we previously assumed 'pipe->bru' could 
> be null (see line 180)
>
> This is a false positive, as, if pipe->bru is NULL, the brx
> var will be different, with ends by calling a code that will
> set pipe->bru to another value.
>
> Yet, cleaning this false positive is as easy as adding an explicit
> check if pipe->bru is NULL.
>
> Signed-off-by: Mauro Carvalho Chehab 

Thanks for your patch!

s/bru/brx/

> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -185,7 +185,7 @@ static int vsp1_du_pipeline_setup_brx(struct vsp1_device 
> *vsp1,
> brx = >brs->entity;
>
> /* Switch BRx if needed. */
> -   if (brx != pipe->brx) {
> +   if (brx != pipe->brx || !pipe->brx) {
> struct vsp1_entity *released_brx = NULL;
>
> /* Release our BRx if we have one. */

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 v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

[Peter Rosin]

Bridge drivers can now (temporarily, in a transition phase) select if
they want to provide a full owner device or keep just providing an
of_node.

By providing a full owner device, the bridge drivers no longer need
to provide an of_node since that node is available via the owner
device.

When all bridge drivers provide an owner device, that will become
mandatory and the .of_node member will be removed.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
 include/drm/drm_bridge.h | 2 ++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..3872f5379998 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
*np)
mutex_lock(_lock);
 
list_for_each_entry(bridge, _list, list) {
-   if (bridge->of_node == np) {
+   if ((bridge->odev && bridge->odev->of_node == np) ||
+   bridge->of_node == np) {
mutex_unlock(_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 4bd94b167d2c..557e0079c98d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct 
device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
-   else
+   else if (lvds->bridge->of_node)
remote = lvds->bridge->of_node;
+   else
+   remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", ))
/* default set it as output rgb */
lvds->output = DISPLAY_OUTPUT_RGB;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7c17977c3537 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -254,6 +254,7 @@ struct drm_bridge_timings {
 
 /**
  * struct drm_bridge - central DRM bridge control structure
+ * @odev: device that owns the bridge
  * @dev: DRM device this bridge belongs to
  * @encoder: encoder to which this bridge is connected
  * @next: the next bridge in the encoder chain
@@ -265,6 +266,7 @@ struct drm_bridge_timings {
  * @driver_private: pointer to the bridge driver's internal context
  */
 struct drm_bridge {
+   struct device *odev;
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
-- 
2.11.0

[PATCH v2 22/26] drm/rcar-du: lvds: provide an owner .odev device for the bridge

[Peter Rosin]

The .of_node member is going away.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3d2d3bbd1342..efda02f55c95 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -463,9 +463,9 @@ static int rcar_lvds_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
+   lvds->bridge.odev = >dev;
lvds->bridge.driver_private = lvds;
lvds->bridge.funcs = _lvds_bridge_ops;
-   lvds->bridge.of_node = pdev->dev.of_node;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
lvds->mmio = devm_ioremap_resource(>dev, mem);
-- 
2.11.0

[PATCH v2 24/26] drm/bridge: remove the .of_node member

[Peter Rosin]

It is unused.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 3 +--
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
 include/drm/drm_bridge.h | 4 
 3 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 3872f5379998..df084db33494 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,8 +365,7 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
*np)
mutex_lock(_lock);
 
list_for_each_entry(bridge, _list, list) {
-   if ((bridge->odev && bridge->odev->of_node == np) ||
-   bridge->of_node == np) {
+   if (bridge->odev->of_node == np) {
mutex_unlock(_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 557e0079c98d..e77d4c909582 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct 
device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
-   else if (lvds->bridge->of_node)
-   remote = lvds->bridge->of_node;
else
remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", ))
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 7c17977c3537..b656e505d11e 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -258,7 +258,6 @@ struct drm_bridge_timings {
  * @dev: DRM device this bridge belongs to
  * @encoder: encoder to which this bridge is connected
  * @next: the next bridge in the encoder chain
- * @of_node: device node pointer to the bridge
  * @list: to keep track of all added bridges
  * @timings: the timing specification for the bridge, if any (may
  * be NULL)
@@ -270,9 +269,6 @@ struct drm_bridge {
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
-#ifdef CONFIG_OF
-   struct device_node *of_node;
-#endif
struct list_head list;
const struct drm_bridge_timings *timings;
 
-- 
2.11.0

[PATCH v2 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach

[Peter Rosin]

The .odev owner device will be handy to have around.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index df084db33494..78d186b6831b 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -70,6 +70,9 @@ static LIST_HEAD(bridge_list);
  */
 void drm_bridge_add(struct drm_bridge *bridge)
 {
+   if (WARN_ON(!bridge->odev))
+   return;
+
mutex_lock(_lock);
list_add_tail(>list, _list);
mutex_unlock(_lock);
@@ -115,6 +118,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
if (!encoder || !bridge)
return -EINVAL;
 
+   if (WARN_ON(!bridge->odev))
+   return -EINVAL;
+
if (previous && (!previous->dev || previous->encoder != encoder))
return -EINVAL;
 
-- 
2.11.0

[PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Peter Rosin]

If the bridge supplier is unbound, this will bring the bridge consumer
down along with the bridge. Thus, there will no longer linger any
dangling pointers from the bridge consumer (the drm_device) to some
non-existent bridge supplier.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 18 ++
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 78d186b6831b..0259f0a3ff27 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -26,6 +26,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_internal.h"
@@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
if (bridge->dev)
return -EBUSY;
 
+   if (encoder->dev->dev != bridge->odev) {
+   bridge->link = device_link_add(encoder->dev->dev,
+  bridge->odev, 0);
+   if (!bridge->link) {
+   dev_err(bridge->odev, "failed to link bridge to %s\n",
+   dev_name(encoder->dev->dev));
+   return -EINVAL;
+   }
+   }
+
bridge->dev = encoder->dev;
bridge->encoder = encoder;
 
if (bridge->funcs->attach) {
ret = bridge->funcs->attach(bridge);
if (ret < 0) {
+   if (bridge->link)
+   device_link_del(bridge->link);
+   bridge->link = NULL;
bridge->dev = NULL;
bridge->encoder = NULL;
return ret;
@@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
if (bridge->funcs->detach)
bridge->funcs->detach(bridge);
 
+   if (bridge->link)
+   device_link_del(bridge->link);
+   bridge->link = NULL;
+
bridge->dev = NULL;
 }
 
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index b656e505d11e..804189c63a4c 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -261,6 +261,7 @@ struct drm_bridge_timings {
  * @list: to keep track of all added bridges
  * @timings: the timing specification for the bridge, if any (may
  * be NULL)
+ * @link: drm consumer <-> bridge supplier
  * @funcs: control functions
  * @driver_private: pointer to the bridge driver's internal context
  */
@@ -271,6 +272,7 @@ struct drm_bridge {
struct drm_bridge *next;
struct list_head list;
const struct drm_bridge_timings *timings;
+   struct device_link *link;
 
const struct drm_bridge_funcs *funcs;
void *driver_private;
-- 
2.11.0

[PATCH v2 00/26] device link, bridge supplier <-> drm device

[Peter Rosin]

Hi!

It was noted by Russel King [1] that bridges (not using components)
might disappear unexpectedly if the owner of the bridge was unbound.
Jyri Sarha had previously noted the same thing with panels [2]. Jyri
came up with using device links to resolve the panel issue, which
was also my (independent) reaction to the note from Russel.

This series builds up to the addition of that link in the last
patch, but in my opinion the other 25 patches do have merit on their
own.

The last patch needs testing, while the others look trivial. Jyri, are
you able to test? That said, I might have missed some subtlety.

Oh and the reason I'm pushing this is of course so that the issue
noted by Russel in [1] is addressed which in turn means that the
tda998x bridge driver can be patched according to that series without
objection (hopefully) and then used from the atmel-hlcdc driver (and
other drivers that are not componentized).

Changes since v1https://lkml.org/lkml/2018/4/26/1018

- rename .owner to .odev to not get mixed up with the module owner.
- added patches for new recent drivers thc63lvd1024 and cdns-dsi
- fix for problem in the rockchip_lvds driver reported by 0day
- added a WARN in drm_bridge_add if there is no .odev owner device

I did *not*:
- add any ack from Daniel since he suggested "pdev", and I ended up
  with "odev" in the rename since I disliked "pdev" about as much
  as "owner".
- add any port id. The current .of_node (that this series removes)
  does not identify the port, so that problem seems orthogonal
  to me.

Cheers,
Peter

[1] https://lkml.org/lkml/2018/4/23/769
[2] https://www.spinics.net/lists/dri-devel/msg174275.html

Peter Rosin (26):
  drm/bridge: allow optionally specifying an owner .odev device
  drm/bridge: adv7511: provide an owner .odev device
  drm/bridge/analogix: core: specify the owner .odev of the bridge
  drm/bridge: analogix-anx78xx: provide an owner .odev device
  drm/bridge: cdns-dsi: provide an owner .odev device
  drm/bridge: vga-dac: provide an owner .odev device
  drm/bridge: lvds-encoder: provide an owner .odev device
  drm/bridge: megachips-stdp-ge-b850v3-fw: provide an owner .odev
device
  drm/bridge: nxp-ptn3460: provide an owner .odev device
  drm/bridge: panel: provide an owner .odev device
  drm/bridge: ps8622: provide an owner .odev device
  drm/bridge: sii902x: provide an owner .odev device
  drm/bridge: sii9234: provide an owner .odev device
  drm/bridge: sii8620: provide an owner .odev device
  drm/bridge: synopsys: provide an owner .odev device for the bridges
  drm/bridge: tc358767: provide an owner .odev device
  drm/bridge: thc63lvd1024: provide an owner .odev device
  drm/bridge: ti-tfp410: provide an owner .odev device
  drm/exynos: mic: provide an owner .odev device for the bridge
  drm/mediatek: hdmi: provide an owner .odev device for the bridge
  drm/msm: specify the owner .odev of the bridges
  drm/rcar-du: lvds: provide an owner .odev device for the bridge
  drm/sti: provide an owner .odev device for the bridges
  drm/bridge: remove the .of_node member
  drm/bridge: require the owner .odev to be filled in on
drm_bridge_add/attach
  drm/bridge: establish a link between the bridge supplier and consumer

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c  |  5 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  1 +
 drivers/gpu/drm/bridge/cdns-dsi.c  |  2 +-
 drivers/gpu/drm/bridge/dumb-vga-dac.c  |  2 +-
 drivers/gpu/drm/bridge/lvds-encoder.c  |  2 +-
 .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  2 +-
 drivers/gpu/drm/bridge/nxp-ptn3460.c   |  2 +-
 drivers/gpu/drm/bridge/panel.c |  4 +---
 drivers/gpu/drm/bridge/parade-ps8622.c |  2 +-
 drivers/gpu/drm/bridge/sii902x.c   |  2 +-
 drivers/gpu/drm/bridge/sii9234.c   |  2 +-
 drivers/gpu/drm/bridge/sil-sii8620.c   |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  4 +---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  |  4 +---
 drivers/gpu/drm/bridge/tc358767.c  |  2 +-
 drivers/gpu/drm/bridge/thc63lvd1024.c  |  2 +-
 drivers/gpu/drm/bridge/ti-tfp410.c |  2 +-
 drivers/gpu/drm/drm_bridge.c   | 26 +-
 drivers/gpu/drm/exynos/exynos_drm_mic.c|  2 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c|  2 +-
 drivers/gpu/drm/msm/dsi/dsi_manager.c  |  1 +
 drivers/gpu/drm/msm/edp/edp_bridge.c   |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  1 +
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  2 +-
 drivers/gpu/drm/rockchip/rockchip_lvds.c   |  2 +-
 drivers/gpu/drm/sti/sti_dvo.c  |  2 +-
 drivers/gpu/drm/sti/sti_hda.c  |  1 +
 drivers/gpu/drm/sti/sti_hdmi.c |  1 +
 

Re: [PATCH v3 0/5] Add R8A77980 PCIe support & some driver cleanups

[Simon Horman]

On Fri, May 04, 2018 at 02:22:59PM +0100, Lorenzo Pieralisi wrote:
> On Thu, May 03, 2018 at 10:32:41PM +0300, Sergei Shtylyov wrote:
> > Hello!
> > 
> > Here's a set of 5 patches against the 'pci/rcar' branch of Lorenzo 
> > Pieralisi's
> > 'pci.git' repo. These are the changes needed for better R-Car gen3 support
> > (namely for R8A77980 support) plus some PCIe driver re-factoring done in
> > the process...
> > 
> > [1/5] pcie-rcar: poll PHYRDY in rcar_pcie_hw_init()
> > [2/5] pcie-rcar: remove PHYRDY polling from rcar_pcie_hw_init_h1()
> > [3/5] pcie-rcar: add R-Car gen3 PHY support
> > [4/5] pcie-rcar: factor out rcar_pcie_hw_init() call
> > [5/5] DT: pci: rcar-pci: document R8A77980 bindings
> 
> I applied the series, with some commit log changes, I can comment
> on those please have a look at my updated pci/rcar branch.
> 
> Thanks,
> Lorenzo

Thanks, much appreciated.

Re: [PATCH v3 0/3] arm64: dts: renesas: salvator-x(s)/ulcb: Add PMIC DDR Backup Power config

[Simon Horman]

On Thu, May 03, 2018 at 02:30:48PM +0200, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
> development boards supports DDR Backup Power, which means that the DDR
> power rails can be kept powered while the main SoC is powered down.
> 
> For this to function correctly, the DDR Backup Power configuration
> must be described in DT, which is the topic of this series:
>   - The first patch adds the missing device node for the BD9571 PMIC on
> the ULCB boards,
>   - The last two patches add DDR Backup Mode configuration for
> Salvator-X(S) and ULCB.
> 
> Changes compared to v3:
>   - Use a hex value for the bit mask.
> 
> Changes compared to v2:
>   - Add support for ULCB,
>   - Add "rohm,rstbmode-level" for Salvator-X(S).
> 
> The relevant DT binding updates have been accepted in
> regulator/for-next, as well as driver support for DDR Backup Mode on
> systems with momentary power switches ("rohm,rstbmode-pulse"), like
> ULCB.  Combined with this series, the PMIC on ULCB will be configured
> automatically during system suspend.
> 
> Note that driver support for systems with toggle power swiches
> ("rohm,rstbmode-level"), like Salvator-X(S), is still under review
> (https://lkml.org/lkml/2018/3/14/324).  But as DT describes hardware,
> not software limitations, this series is safe to apply.
> 
> This has been tested on M3ULCB (thanks Jacopo!), and on Salvator-X(S).
> All support has been part of renesas-drivers since a few releases.
> 
> Thanks for applying!

Thanks, applied.

Re: [PATCH v2 0/3] arm64: dts: renesas: Correct whitespace

[Simon Horman]

On Thu, May 03, 2018 at 02:38:27PM +0200, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> This patch series fixes a few whitespace issues in DTS files.

Thanks, applied.

Re: [PATCH v3 0/5] Add R8A77980 PCIe support & some driver cleanups

[Lorenzo Pieralisi]

On Thu, May 03, 2018 at 10:32:41PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> Here's a set of 5 patches against the 'pci/rcar' branch of Lorenzo Pieralisi's
> 'pci.git' repo. These are the changes needed for better R-Car gen3 support
> (namely for R8A77980 support) plus some PCIe driver re-factoring done in
> the process...
> 
> [1/5] pcie-rcar: poll PHYRDY in rcar_pcie_hw_init()
> [2/5] pcie-rcar: remove PHYRDY polling from rcar_pcie_hw_init_h1()
> [3/5] pcie-rcar: add R-Car gen3 PHY support
> [4/5] pcie-rcar: factor out rcar_pcie_hw_init() call
> [5/5] DT: pci: rcar-pci: document R8A77980 bindings

I applied the series, with some commit log changes, I can comment
on those please have a look at my updated pci/rcar branch.

Thanks,
Lorenzo

Re: [PATCH] dt-bindings: can: rcar_can: Fix R8A7796 SoC name

[Simon Horman]

On Thu, May 03, 2018 at 03:02:33PM +0200, Geert Uytterhoeven wrote:
> R8A7796 is R-Car M3-W.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

Re: [PATCH 0/3] arm64: dts: renesas: r8a7795: salvator-xs: enable USB2.0 channel 3

[Simon Horman]

On Fri, Apr 27, 2018 at 03:34:29PM +0900, Yoshihiro Shimoda wrote:
> This patch set is based on the renesas-devel-20180426-v4.17-rc2 tag
> of renesas.git.
> 
> Yoshihiro Shimoda (3):
>   arm64: dts: renesas: r8a7795: salvator-xs: enable usb2_phy3 node
>   arm64: dts: renesas: r8a7795: salvator-xs: enable hsusb channel 3 node
>   arm64: dts: renesas: r8a7795: salvator-xs: enable USB2.0 host channel
> 3

Thanks, series applied.

Re: [PATCH] arm64: dts: renesas: salvator-common: add eeprom

[Simon Horman]

On Sun, Apr 29, 2018 at 08:26:39PM +0200, Wolfram Sang wrote:
> Add the EEPROM found on Salvator-X and -XS boards for H3, M3-W, and M3-N
> on the IIC_DVFS bus.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Always nice for I2C debugging to have en EEPROM around...

Thanks, applied.

[PATCH] media: vsp1: cleanup a false positive warning

[Mauro Carvalho Chehab]

With the new vsp1 code changes introduced by changeset
f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines dynamically"),
smatch complains with:
drivers/media/platform/vsp1/vsp1_drm.c:262 vsp1_du_pipeline_setup_bru() 
error: we previously assumed 'pipe->bru' could be null (see line 180)

This is a false positive, as, if pipe->bru is NULL, the brx
var will be different, with ends by calling a code that will
set pipe->bru to another value.

Yet, cleaning this false positive is as easy as adding an explicit
check if pipe->bru is NULL.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 095dc48aa25a..cb6b60843400 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -185,7 +185,7 @@ static int vsp1_du_pipeline_setup_brx(struct vsp1_device 
*vsp1,
brx = >brs->entity;
 
/* Switch BRx if needed. */
-   if (brx != pipe->brx) {
+   if (brx != pipe->brx || !pipe->brx) {
struct vsp1_entity *released_brx = NULL;
 
/* Release our BRx if we have one. */
-- 
2.17.0

RE: [PATCH v2] pinctrl: sh-pfc: Add r8a77470 PFC support

[Biju Das]

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v2] pinctrl: sh-pfc: Add r8a77470 PFC support
>
> Hi Biju,
>
> On Tue, Apr 24, 2018 at 1:03 PM, Biju Das  wrote:
> > Add PFC support for the R8A77470 SoC including pin groups for some
> > on-chip devices such as SCIF, AVB and MMC.
> >
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
>
> Thanks for your patch!
>
> > ---
> > V1-->V2
> > * Incoroporated the following review comments
> > * Fixed MOD_SEL to MOD_SEL0
> > * Created seperate pin group for AVB_COL and AVB_CRS
> > * Added the pin group AVB_CAPTURE and AVB_MATCH
> > * Added missing SCIF pin groups
>
> I believe this is v3, not v2?

Yes it is v3,  I have realised this after sending the patch.

> Reviewed-by: Geert Uytterhoeven 
>
> Given the (unfinished) discussion about the AVB pins, I'll apply and queue
> your patch in sh-pfc-for-v4.18 with the AVB pin groups removed.

It is ok for me.

Regards,
Biju



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH v2] pinctrl: sh-pfc: Add r8a77470 PFC support

[Geert Uytterhoeven]

Hi Biju,

On Tue, Apr 24, 2018 at 1:03 PM, Biju Das  wrote:
> Add PFC support for the R8A77470 SoC including pin groups for
> some on-chip devices such as SCIF, AVB and MMC.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Thanks for your patch!

> ---
> V1-->V2
> * Incoroporated the following review comments
> * Fixed MOD_SEL to MOD_SEL0
> * Created seperate pin group for AVB_COL and AVB_CRS
> * Added the pin group AVB_CAPTURE and AVB_MATCH
> * Added missing SCIF pin groups

I believe this is v3, not v2?

Reviewed-by: Geert Uytterhoeven 

Given the (unfinished) discussion about the AVB pins, I'll apply and queue
your patch in sh-pfc-for-v4.18 with the AVB pin groups removed.

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] media: renesas-ceu: Set mbus_fmt on subdev operations

[Jacopo Mondi]

The renesas-ceu driver intializes the desired mbus_format at 'complete'
time, inspecting the supported subdevice ones, and tuning some
parameters to produce the requested memory format from what the sensor
can produce. Although, the initially selected mbus_format was not
provided to the subdevice during set_fmt and try_fmt operations,
providing instead a '0' mbus format code.

As long as the sensor defaults to a compatible mbus_format when an
invalid code as '0' is provided, capture operations work correctly. If
the subdevice defaults to an unsupported format (eg. some RGB
permutations) capture does not work properly due to a mismatch on the
expected and received image format on the wire.

Fix that by re-using the initially selected mbus_format code during
set_fmt and try_fmt subdevice operation calls.

Tested by printing out the format selection procedure with ov7670
sensor.

Before this patch:
[0.866001] ov7670_try_fmt_internal -- Looking for mbus_code 0x
[0.870882] ov7670_try_fmt_internal -- Try mbus_code 0x2008
[0.876336] ov7670_try_fmt_internal -- Try mbus_code 0x1002
[0.881387] ov7670_try_fmt_internal -- Try mbus_code 0x1008
[0.886537] ov7670_try_fmt_internal -- Try mbus_code 0x3001
[0.891584] ov7670_try_fmt_internal -- mbus_code defaulted to 0x2008

With this patch applied:
[0.867015] ov7670_try_fmt_internal -- Looking for mbus_code 0x2008
[0.873205] ov7670_try_fmt_internal -- Try mbus_code 0x2008: match

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/renesas-ceu.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
index 6599dba..dec1b35 100644
--- a/drivers/media/platform/renesas-ceu.c
+++ b/drivers/media/platform/renesas-ceu.c
@@ -777,8 +777,15 @@ static int ceu_try_fmt(struct ceu_device *ceudev, struct 
v4l2_format *v4l2_fmt)
const struct ceu_fmt *ceu_fmt;
int ret;

+   /*
+* Set format on sensor sub device: bus format used to produce memory
+* format is selected at initialization time.
+*/
struct v4l2_subdev_format sd_format = {
-   .which = V4L2_SUBDEV_FORMAT_TRY,
+   .which  = V4L2_SUBDEV_FORMAT_TRY,
+   .format = {
+   .code = ceu_sd->mbus_fmt.mbus_code,
+   },
};

switch (pix->pixelformat) {
@@ -800,10 +807,6 @@ static int ceu_try_fmt(struct ceu_device *ceudev, struct 
v4l2_format *v4l2_fmt)
v4l_bound_align_image(>width, 2, CEU_MAX_WIDTH, 4,
  >height, 4, CEU_MAX_HEIGHT, 4, 0);

-   /*
-* Set format on sensor sub device: bus format used to produce memory
-* format is selected at initialization time.
-*/
v4l2_fill_mbus_format_mplane(_format.format, pix);
ret = v4l2_subdev_call(v4l2_sd, pad, set_fmt, _cfg, _format);
if (ret)
@@ -827,8 +830,15 @@ static int ceu_set_fmt(struct ceu_device *ceudev, struct 
v4l2_format *v4l2_fmt)
struct v4l2_subdev *v4l2_sd = ceu_sd->v4l2_sd;
int ret;

+   /*
+* Set format on sensor sub device: bus format used to produce memory
+* format is selected at initialization time.
+*/
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   .format = {
+   .code = ceu_sd->mbus_fmt.mbus_code,
+   },
};

ret = ceu_try_fmt(ceudev, v4l2_fmt);
--
2.7.4

Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support

[Geert Uytterhoeven]

Hi Sergei,

On Sat, Apr 28, 2018 at 8:30 PM, Sergei Shtylyov
 wrote:
> On 04/28/2018 08:40 PM, Sergei Shtylyov wrote:
> Subject: Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support
> On Wed, Apr 4, 2018 at 5:22 PM, Biju Das  wrote:
>> Add PFC support for the R8A77470 SoC including pin groups for some
>> on-chip devices such as SCIF, AVB and MMC.
>>
>> Signed-off-by: Biju Das 
>> Reviewed-by: Fabrizio Castro 
>>>
>> --- /dev/null
>> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
>>>
>> +/* - AVB
>> + */ 
>> static const
> unsigned int avb_link_pins[] = {
>> +   RCAR_GP_PIN(5, 14),
>> +};
>> +static const unsigned int avb_link_mux[] = {
>> +   AVB_LINK_MARK,
>> +};
>> +static const unsigned int avb_magic_pins[] = {
>> +   RCAR_GP_PIN(5, 15),
>> +};
>> +static const unsigned int avb_magic_mux[] = {
>> +   AVB_MAGIC_MARK,
>> +};
>> +static const unsigned int avb_phy_int_pins[] = {
>> +   RCAR_GP_PIN(5, 16),
>> +};
>> +static const unsigned int avb_phy_int_mux[] = {
>> +   AVB_PHY_INT_MARK,
>> +};
>> +static const unsigned int avb_mdio_pins[] = {
>> +   RCAR_GP_PIN(5, 12), RCAR_GP_PIN(5, 13), }; static const
>> +unsigned int avb_mdio_mux[] = {
>> +   AVB_MDC_MARK, AVB_MDIO_MARK,
>> +};
>> +static const unsigned int avb_mii_pins[] = {
>> +   RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 15), RCAR_GP_PIN(3, 16),
>> +   RCAR_GP_PIN(3, 27),
>> +
>> +   RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3), RCAR_GP_PIN(3, 4),
>> +   RCAR_GP_PIN(3, 5),
>> +
>> +   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
>> +   RCAR_GP_PIN(5, 17), RCAR_GP_PIN(3, 13), RCAR_GP_PIN(5, 23),
>> +   RCAR_GP_PIN(3, 12),
>> +};
>> +static const unsigned int avb_mii_mux[] = {
>> +   AVB_TXD0_MARK, AVB_TXD1_MARK, AVB_TXD2_MARK,
>> +   AVB_TXD3_MARK,
>> +
>> +   AVB_RXD0_MARK, AVB_RXD1_MARK, AVB_RXD2_MARK,
>> +   AVB_RXD3_MARK,
>> +
>> +   AVB_RX_ER_MARK, AVB_RX_CLK_MARK, AVB_RX_DV_MARK,
>> +   AVB_CRS_MARK, AVB_TX_EN_MARK, AVB_TX_ER_MARK,
>> +   AVB_TX_CLK_MARK,
>
> You forgot AVB_COL, which is GP5_18?

 GP5_18 is shred between the signals AVB_COL and VI0_CLK. As per the RZ/G1C 
 board schematic /hardware user guide
 Ethernet Phy collision pin(AVB_COL) pin  is not populated on this board by 
 default. It is populated only for
 Video Input Channel0 pixel clock.

 Since it is initial submission, I thought of adding only board specific 
 pins first and later
 add this collision pin alone as a separate pin entry  in the avb group. 
 That way we can support existing board
 as well as any future RZ/G1C board which populates this pin. Are you ok 
 for this approach?
>>
>>> Oops. That means our grouping is suboptimal. Perhaps we should revisit
>>> (for all SoCs, while keeping backwards compatibility)?
>>
>>
>>> After reading some wikipedia, I came up with:
>>>
>>> mii_tx
>>> mii_tx_er (optional)
>>> mii_rx
>>
>>I don't see why we should have the separate TX/RX subgroups just because 
>> they're
>> described separately in the Wikipedia. Or did you have some special reason 
>> to do it?

OK, so for MII:

mii_tx_rx
mii_tx_er

and for GMII:

gmii_tx_rx

>>> mii_col_crs (optional, half duplex)
>>>
>>> However, given your board uses AVB_CRS without AVB_COL, that would still
>>> not be sufficient, so the last group should be split to cover your use case?
>>
>>> BTW, how does it work with AVB_COL not wired to anything by default, and 
>>> thus
>>> floating? Do you enable pull-up/down for that pin in the PFC, or is the pin
>>> just ignored in full-duplex mode?
>>
>>Well, I'm seeing the strong possibility the half-duplex mode just doesn't 
>> work as
>> the collision indication isn't available.
>
>And indeed, the manuals tell me that RZ/G (and R-Car gen2) EtherAVB only 
> supports
> the full-duplex mode.

Indeed. Also on R-Car Gen3.

Then, what's the purpose of the CRS and COL signals in full-duplex mode?
Apart from being shown in the timing diagrams (Figures 33A.72 and later in
the RZ/G1C Hardware User Manual Rev. 1.00), there's no further information
about them.

Gigabit Ethernet has carrier extension, perhaps the CRS signal is needed
to detect invalid carrier extension? That means it could be used without COL,
and thus we may need separate pin groups for CRS and COL?

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. 

Re: [PATCH/RFT 3/3] arm64: dts: r8a77965: Add SDHI device nodes

[Yoshihiro Kaneko]

Hi Simon-san,

2018-05-02 0:30 GMT+09:00 Simon Horman :
> On Mon, Apr 30, 2018 at 04:48:16AM +0900, Yoshihiro Kaneko wrote:
>> From: Takeshi Kihara 
>>
>> Add SDHI nodes to the DT of the r8a77965 SoC.
>>
>> Based on several similar patches of the R8A7796 device tree
>> by Simon Horman .
>>
>> Signed-off-by: Takeshi Kihara 
>> Signed-off-by: Yoshihiro Kaneko 
>
> This patch needs to be rebased on top of the devel branch of the renesas
> tree. Otherwise it looks good to me.

Thanks for your review.
I will rebase this patch.

>
>> ---
>>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 68 
>> ++-
>>  1 file changed, 48 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
>> b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> index f0871fc..6860704 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> @@ -834,26 +834,6 @@
>>   };
>>   };
>>
>> - sdhi0: sd@ee10 {
>> - reg = <0 0xee10 0 0x2000>;
>> - /* placeholder */
>> - };
>> -
>> - sdhi1: sd@ee12 {
>> - reg = <0 0xee12 0 0x2000>;
>> - /* placeholder */
>> - };
>> -
>> - sdhi2: sd@ee14 {
>> - reg = <0 0xee14 0 0x2000>;
>> - /* placeholder */
>> - };
>> -
>> - sdhi3: sd@ee16 {
>> - reg = <0 0xee16 0 0x2000>;
>> - /* placeholder */
>> - };
>> -
>>   usb3_phy0: usb-phy@e65ee000 {
>>   reg = <0 0xe65ee000 0 0x90>;
>>   #phy-cells = <0>;
>> @@ -874,5 +854,53 @@
>>   reg = <0 0xe602 0 0x0c>;
>>   /* placeholder */
>>   };
>> +
>> + sdhi0: sd@ee10 {
>> + compatible = "renesas,sdhi-r8a77965",
>> +  "renesas,rcar-gen3-sdhi";
>> + reg = <0 0xee10 0 0x2000>;
>> + interrupts = ;
>> + clocks = < CPG_MOD 314>;
>> + max-frequency = <2>;
>> + power-domains = < 32>;
>> + resets = < 314>;
>> + status = "disabled";
>> + };
>> +
>> + sdhi1: sd@ee12 {
>> + compatible = "renesas,sdhi-r8a77965",
>> +  "renesas,rcar-gen3-sdhi";
>> + reg = <0 0xee12 0 0x2000>;
>> + interrupts = ;
>> + clocks = < CPG_MOD 313>;
>> + max-frequency = <2>;
>> + power-domains = < 32>;
>> + resets = < 313>;
>> + status = "disabled";
>> + };
>> +
>> + sdhi2: sd@ee14 {
>> + compatible = "renesas,sdhi-r8a77965",
>> +  "renesas,rcar-gen3-sdhi";
>> + reg = <0 0xee14 0 0x2000>;
>> + interrupts = ;
>> + clocks = < CPG_MOD 312>;
>> + max-frequency = <2>;
>> + power-domains = < 32>;
>> + resets = < 312>;
>> + status = "disabled";
>> + };
>> +
>> + sdhi3: sd@ee16 {
>> + compatible = "renesas,sdhi-r8a77965",
>> +  "renesas,rcar-gen3-sdhi";
>> + reg = <0 0xee16 0 0x2000>;
>> + interrupts = ;
>> + clocks = < CPG_MOD 311>;
>> + max-frequency = <2>;
>> + power-domains = < 32>;
>> + resets = < 311>;
>> + status = "disabled";
>> + };
>>   };
>>  };
>> --
>> 1.9.1
>>

Best regards,
Kaneko

Re: [PATCH/RFT 1/3] pinctrl: sh-pfc: r8a77965: Add SDHI pins, groups and functions

[Yoshihiro Kaneko]

Hi Geert-san,

2018-05-04 17:30 GMT+09:00 Geert Uytterhoeven :
> Hi Kaneko-san,
>
> On Fri, May 4, 2018 at 10:28 AM, Yoshihiro Kaneko  
> wrote:
>> 2018-05-02 18:16 GMT+09:00 Geert Uytterhoeven :
>>> On Sun, Apr 29, 2018 at 9:48 PM, Yoshihiro Kaneko  
>>> wrote:
 From: Takeshi Kihara 

 This patch adds SDHI{0,1,2,3} pins, groups and functions to the R8A77965
 SoC.

 Signed-off-by: Takeshi Kihara 
 Signed-off-by: Yoshihiro Kaneko 
>>>
>>> Thanks for your patch!
>>>
>>> The pins, groups, and functions are correct, so
>>> Reviewed-by: Geert Uytterhoeven .
>>> i.e. queuing in sh-pfc-for-v4.18, after fixing up the below.
>>
>> Thanks for your review!
>> I will fix up the below in V2.
>
> There's no need to send a v2, as I have already fixed and applied your patch.

Okay, 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: [PATCH/RFT 2/3] mmc: renesas_sdhi: Add r8a77965 support

[Yoshihiro Kaneko]

Hello,

2018-05-02 17:14 GMT+09:00 Wolfram Sang :
>
>> With the current state of the driver this patch should be fine,
>> modulo the changes suggested above. But once HS400 support is merged
>> some logic will be required to disable that feature for the r8a77965
>> until HS400 support for that SoC is explicitly added.
>>
>> Or conversely, perhaps when HS400 is added it should only be enabled
>> in the driver for SoCs that are known to work: r8a7796 and r8a7795. In the
>> case of the latter perhaps only ES2.0.
>>
>> Wolfram, what do you think?
>
> M3-N (and future SoCs as it seems) has 8 taps while the others have 4.
> Maybe we should have something already in place to distinguish 8 taps
> and 4 taps and leave the 8 taps part for "to be added later"?
>

Thanks for your review.
I will drop .revision = "ES1.0" and renesas,sdhi-r8a77965 in V2.

Best regards,
Kaneko

Re: [PATCH/RFT 1/3] pinctrl: sh-pfc: r8a77965: Add SDHI pins, groups and functions

[Geert Uytterhoeven]

Hi Kaneko-san,

On Fri, May 4, 2018 at 10:28 AM, Yoshihiro Kaneko  wrote:
> 2018-05-02 18:16 GMT+09:00 Geert Uytterhoeven :
>> On Sun, Apr 29, 2018 at 9:48 PM, Yoshihiro Kaneko  
>> wrote:
>>> From: Takeshi Kihara 
>>>
>>> This patch adds SDHI{0,1,2,3} pins, groups and functions to the R8A77965
>>> SoC.
>>>
>>> Signed-off-by: Takeshi Kihara 
>>> Signed-off-by: Yoshihiro Kaneko 
>>
>> Thanks for your patch!
>>
>> The pins, groups, and functions are correct, so
>> Reviewed-by: Geert Uytterhoeven .
>> i.e. queuing in sh-pfc-for-v4.18, after fixing up the below.
>
> Thanks for your review!
> I will fix up the below in V2.

There's no need to send a v2, as I have already fixed and applied your patch.

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/RFT 1/3] pinctrl: sh-pfc: r8a77965: Add SDHI pins, groups and functions

[Yoshihiro Kaneko]

Hi Geert-san,

2018-05-02 18:16 GMT+09:00 Geert Uytterhoeven :
> Hi Kaneko-san,
>
> On Sun, Apr 29, 2018 at 9:48 PM, Yoshihiro Kaneko  
> wrote:
>> From: Takeshi Kihara 
>>
>> This patch adds SDHI{0,1,2,3} pins, groups and functions to the R8A77965
>> SoC.
>>
>> Signed-off-by: Takeshi Kihara 
>> Signed-off-by: Yoshihiro Kaneko 
>
> Thanks for your patch!
>
> The pins, groups, and functions are correct, so
> Reviewed-by: Geert Uytterhoeven .
> i.e. queuing in sh-pfc-for-v4.18, after fixing up the below.

Thanks for your review!
I will fix up the below in V2.

>
>> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
>> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
>> @@ -1923,6 +1923,264 @@ enum {
>> RCAR_GP_PIN(6, 24), RCAR_GP_PIN(6, 25),
>>  };
>>
>> +/* - SDHI0 
>> -- */
>> +static const unsigned int sdhi0_data1_pins[] = {
>
> [...]
>
>> +};
>
> This doesn't belong in the middle of the usb0 section ;-)
>
>> +
>>  static const unsigned int usb0_mux[] = {
>> USB0_PWEN_MARK, USB0_OVC_MARK,
>>  };
>> @@ -1997,6 +2255,32 @@ enum {
>> SH_PFC_PIN_GROUP(usb0),
>> SH_PFC_PIN_GROUP(usb1),
>> SH_PFC_PIN_GROUP(usb30),
>> +   SH_PFC_PIN_GROUP(sdhi0_data1),
>
> Alphabetical order, please.
>
>> @@ -2083,6 +2367,44 @@ enum {
>> "usb30",
>>  };
>>
>> +static const char * const sdhi0_groups[] = {
>
> Alphabetical order, please.
>
>> @@ -2096,6 +2418,10 @@ enum {
>> SH_PFC_FUNCTION(usb0),
>> SH_PFC_FUNCTION(usb1),
>> SH_PFC_FUNCTION(usb30),
>> +   SH_PFC_FUNCTION(sdhi0),
>> +   SH_PFC_FUNCTION(sdhi1),
>> +   SH_PFC_FUNCTION(sdhi2),
>> +   SH_PFC_FUNCTION(sdhi3),
>>  };
>
> Alphabetical order, please.
>
> 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

Best regards,
Kaneko

Re: [PATCH 1/2] arm64: dts: renesas: r8a77980: add CAN-FD support

[Geert Uytterhoeven]

Hi Sergei,

On Fri, Apr 27, 2018 at 9:12 PM, Sergei Shtylyov
 wrote:
> Define the generic R8A77980 part of the CAN-FD device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 

Thanks for your patch!

> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
=
> @@ -170,6 +177,30 @@
> status = "disabled";
> };
>
> +   canfd: can@e66c {
> +   compatible = "renesas,r8a77980-canfd",
> +"renesas,rcar-gen3-canfd";
> +   reg = <0 0xe66c 0 0x8000>;
> +   interrupts = ,
> +;
> +   clocks = < CPG_MOD 914>,
> +< CPG_CORE R8A77980_CLK_CANFD>,
> +<_clk>;
> +   clock-names = "fck", "canfd", "can_clk";
> +   assigned-clocks = < CPG_CORE R8A77980_CLK_CANFD>;
> +   assigned-clock-rates = <4000>;
> +   power-domains = < R8A77980_PD_ALWAYS_ON>;

You forgot the resets property.

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 3/3] video: fbdev: remove unused sh_mobile_meram driver

[Geert Uytterhoeven]

On Fri, Apr 27, 2018 at 1:21 PM, Bartlomiej Zolnierkiewicz
 wrote:
> Since commit a521422ea4ae  ("ARM: shmobile: mackerel: Remove Legacy C
> board code") MERAM functionality is unused. Remove it.
>
> Cc: Simon Horman 
> Cc: Laurent Pinchart 
> Cc: Geert Uytterhoeven 
> Signed-off-by: Bartlomiej Zolnierkiewicz 

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

Re: [PATCH 1/3] video: fbdev: sh_mobile_lcdcfb: remove unused MERAM support

[Geert Uytterhoeven]

On Fri, Apr 27, 2018 at 1:21 PM, Bartlomiej Zolnierkiewicz
 wrote:
> Since commit a521422ea4ae  ("ARM: shmobile: mackerel: Remove Legacy C
> board code") MERAM functionality is unused. Remove it.
>
> Cc: Simon Horman 
> Cc: Laurent Pinchart 
> Cc: Geert Uytterhoeven 
> Signed-off-by: Bartlomiej Zolnierkiewicz 

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

Re: [PATCH 3/5] tty: serial: sh-sci: Hide earlycon config question

[Geert Uytterhoeven]

Hi Rob,

On Wed, May 2, 2018 at 4:32 AM, Rob Herring  wrote:
> On Sun, Apr 15, 2018 at 2:09 PM, Rich Felker  wrote:
>> On Sun, Apr 15, 2018 at 08:58:42PM +0200, Geert Uytterhoeven wrote:
>>> On Sun, Apr 15, 2018 at 2:34 AM, Rich Felker  wrote:
>>> > On Thu, Nov 30, 2017 at 02:12:00PM +0100, Geert Uytterhoeven wrote:
>>> >> Renesas H8/300 and ARM platforms use DT and support earlycon, so most
>>> >> users want earlycon support to be enabled.
>>> >>
>>> >> On SuperH platforms, earlycon is not yet supported.
>>> >>
>>> >> Hence follow the above rationale to configure the default, unless
>>> >> CONFIG_EXPERT is enabled.
>>> >>
>>> >> Signed-off-by: Geert Uytterhoeven 
>>> >> ---
>>> >>  drivers/tty/serial/Kconfig | 3 ++-
>>> >>  1 file changed, 2 insertions(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>>> >> index 0c75562d620feb82..952a2c6a9da08fdd 100644
>>> >> --- a/drivers/tty/serial/Kconfig
>>> >> +++ b/drivers/tty/serial/Kconfig
>>> >> @@ -774,10 +774,11 @@ config SERIAL_SH_SCI_CONSOLE
>>> >>   default y
>>> >>
>>> >>  config SERIAL_SH_SCI_EARLYCON
>>> >> - bool "Support for early console on SuperH SCI(F)"
>>> >> + bool "Support for early console on SuperH SCI(F)" if EXPERT
>>> >>   depends on SERIAL_SH_SCI=y
>>> >>   select SERIAL_CORE_CONSOLE
>>> >>   select SERIAL_EARLYCON
>>> >> + default ARCH_RENESAS || H8300
>>> >>
>>> >>  config SERIAL_SH_SCI_DMA
>>> >>   bool "DMA support"
>>> >> --
>>> >
>>> > Can you clarify what the claim that SuperH does not support earlycon
>>> > is based on? My understanding is that users were successfully using
>>> > this option on Renesas SH systems, and I'm using it on J2 with the
>>> > uartlite earlycon support which I added in 7cdcc29e49. I think if you
>>> > want to omit the question it should always default to enabled.
>>>
>>> This is a patch for a Kconfig option for the Renesas sh-sci driver, which
>>> supports the SCI, SCIF, SCIFA, SCIFB, and HSCIF uarts found on various
>>> Renesas SoCs.
>>>
>>> Earlycon is used with DT only. While you are using earlycon on J2, you do
>>> use it with a different uart (uartlite). Currently there's no upstream 
>>> support
>>> for using DT on Renesas SuperH SoCs. If this changes, the default for
>>> SERIAL_SH_SCI_EARLYCON has to be changed.
>>>
>>> So none of my patch applies to the current state of SuperH Linux support.
>>
>> OK, I was under the impression (from users) that it worked on Renesas
>> SH devices without DT. If it really doesn't then it doesn't matter
>> until DT support for them is added. I've got some hardware to
>> experiment with now so I'll see what can be done.
>
> Yes, it works without DT (but maybe that is UART specific). It was
> originally an x86 8250 thing.
>
> The main thing you need is either fixmap support or ioremap has to
> work before paging_init when early_params are processed.

Without DT and its chosen/stdout-path, you need a way to specify which
UART to use. That's typically done through a UART-specific earlycon=
extension.

The sh-sci.c driver uses:

OF_EARLYCON_DECLARE(scif, "renesas,scif", scif_early_console_setup);
(+ for sci, scifa, scifb, hscif)

So it may actually work with earlycon=scif,0x?

Anyone who can try on a non-DT SH system?

if it works, the default should be changed to

default ARCH_RENESAS || H8300 || SUPERH

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