[PATCH 2/2] pinctrl: sh-pfc: r8a77965: add Audio SSI pin support
From: Hoan Nguyen An
Add Audio SSI pin support for r8a77965
Signed-off-by: Hoan Nguyen An
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 232 ++
1 file changed, 232 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index 46241c0..dfdd982 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -3517,6 +3517,184 @@ static const unsigned int sdhi3_ds_mux[] = {
SD3_DS_MARK,
};
+/* - SSI
*/
+static const unsigned int ssi0_data_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 2),
+};
+static const unsigned int ssi0_data_mux[] = {
+ SSI_SDATA0_MARK,
+};
+static const unsigned int ssi01239_ctrl_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 0), RCAR_GP_PIN(6, 1),
+};
+static const unsigned int ssi01239_ctrl_mux[] = {
+ SSI_SCK01239_MARK, SSI_WS01239_MARK,
+};
+static const unsigned int ssi1_data_a_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 3),
+};
+static const unsigned int ssi1_data_a_mux[] = {
+ SSI_SDATA1_A_MARK,
+};
+static const unsigned int ssi1_data_b_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(5, 12),
+};
+static const unsigned int ssi1_data_b_mux[] = {
+ SSI_SDATA1_B_MARK,
+};
+static const unsigned int ssi1_ctrl_a_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 26), RCAR_GP_PIN(6, 27),
+};
+static const unsigned int ssi1_ctrl_a_mux[] = {
+ SSI_SCK1_A_MARK, SSI_WS1_A_MARK,
+};
+static const unsigned int ssi1_ctrl_b_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 4), RCAR_GP_PIN(6, 21),
+};
+static const unsigned int ssi1_ctrl_b_mux[] = {
+ SSI_SCK1_B_MARK, SSI_WS1_B_MARK,
+};
+static const unsigned int ssi2_data_a_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 4),
+};
+static const unsigned int ssi2_data_a_mux[] = {
+ SSI_SDATA2_A_MARK,
+};
+static const unsigned int ssi2_data_b_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(5, 13),
+};
+static const unsigned int ssi2_data_b_mux[] = {
+ SSI_SDATA2_B_MARK,
+};
+static const unsigned int ssi2_ctrl_a_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(5, 19), RCAR_GP_PIN(5, 21),
+};
+static const unsigned int ssi2_ctrl_a_mux[] = {
+ SSI_SCK2_A_MARK, SSI_WS2_A_MARK,
+};
+static const unsigned int ssi2_ctrl_b_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 28), RCAR_GP_PIN(6, 29),
+};
+static const unsigned int ssi2_ctrl_b_mux[] = {
+ SSI_SCK2_B_MARK, SSI_WS2_B_MARK,
+};
+static const unsigned int ssi3_data_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 7),
+};
+static const unsigned int ssi3_data_mux[] = {
+ SSI_SDATA3_MARK,
+};
+static const unsigned int ssi349_ctrl_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 5), RCAR_GP_PIN(6, 6),
+};
+static const unsigned int ssi349_ctrl_mux[] = {
+ SSI_SCK349_MARK, SSI_WS349_MARK,
+};
+static const unsigned int ssi4_data_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 10),
+};
+static const unsigned int ssi4_data_mux[] = {
+ SSI_SDATA4_MARK,
+};
+static const unsigned int ssi4_ctrl_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 8), RCAR_GP_PIN(6, 9),
+};
+static const unsigned int ssi4_ctrl_mux[] = {
+ SSI_SCK4_MARK, SSI_WS4_MARK,
+};
+static const unsigned int ssi5_data_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 13),
+};
+static const unsigned int ssi5_data_mux[] = {
+ SSI_SDATA5_MARK,
+};
+static const unsigned int ssi5_ctrl_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 11), RCAR_GP_PIN(6, 12),
+};
+static const unsigned int ssi5_ctrl_mux[] = {
+ SSI_SCK5_MARK, SSI_WS5_MARK,
+};
+static const unsigned int ssi6_data_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 16),
+};
+static const unsigned int ssi6_data_mux[] = {
+ SSI_SDATA6_MARK,
+};
+static const unsigned int ssi6_ctrl_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 14), RCAR_GP_PIN(6, 15),
+};
+static const unsigned int ssi6_ctrl_mux[] = {
+ SSI_SCK6_MARK, SSI_WS6_MARK,
+};
+static const unsigned int ssi7_data_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 19),
+};
+static const unsigned int ssi7_data_mux[] = {
+ SSI_SDATA7_MARK,
+};
+static const unsigned int ssi78_ctrl_pins[] = {
+ /* SCK, WS */
+ RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 18),
+};
+static const unsigned int ssi78_ctrl_mux[] = {
+ SSI_SCK78_MARK, SSI_WS78_MARK,
+};
+static const unsigned int ssi8_data_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 20),
+};
+static const unsigned int ssi8_data_mux[] = {
+ SSI_SDATA8_MARK,
+};
+static const unsigned int ssi9_data_a_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(6, 21),
+};
+static const unsigned int ssi9_data_a_mux[] = {
+ SSI_SDATA9_A_MARK,
+};
+static const unsigned int ssi9_data_b_pins[] = {
+ /* SDATA */
+ RCAR_GP_PIN(5, 14),
+};
+st
[RESEND PATCH 0/2] Add support Audio's pins for r8a77965.
From: Hoan Nguyen An Morimoto-san, Geert-san: Thank you for your comments. These are the patches that I added Signed-off-by. These patches based on the file drivers/pinctrl/sh-pfc/pfc-r8a7796.c. Although the current renesas-drives tree r8a77965.dtsi has not yet configured for the Sound-driver, but I have manually configured and tested for this. Patches were be tested. Hoan Nguyen An (2): pinctrl: sh-pfc: r8a77965: add Audio clock pin support pinctrl: sh-pfc: r8a77965: add Audio SSI pin support drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 392 ++ 1 file changed, 392 insertions(+) -- 2.7.4
[PATCH 1/2] pinctrl: sh-pfc: r8a77965: add Audio clock pin support
From: Hoan Nguyen An
Add Audio clock pin support for r8a77965
Signed-off-by: Hoan Nguyen An
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 160 ++
1 file changed, 160 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index 72ccd1a..46241c0 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -1575,6 +1575,128 @@ static const struct sh_pfc_pin pinmux_pins[] = {
SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('T'), 30, ASEBRK, CFG_FLAGS),
};
+/* - AUDIO CLOCK
*/
+static const unsigned int audio_clk_a_a_pins[] = {
+ /* CLK A */
+ RCAR_GP_PIN(6, 22),
+};
+static const unsigned int audio_clk_a_a_mux[] = {
+ AUDIO_CLKA_A_MARK,
+};
+static const unsigned int audio_clk_a_b_pins[] = {
+ /* CLK A */
+ RCAR_GP_PIN(5, 4),
+};
+static const unsigned int audio_clk_a_b_mux[] = {
+ AUDIO_CLKA_B_MARK,
+};
+static const unsigned int audio_clk_a_c_pins[] = {
+ /* CLK A */
+ RCAR_GP_PIN(5, 19),
+};
+static const unsigned int audio_clk_a_c_mux[] = {
+ AUDIO_CLKA_C_MARK,
+};
+static const unsigned int audio_clk_b_a_pins[] = {
+ /* CLK B */
+ RCAR_GP_PIN(5, 12),
+};
+static const unsigned int audio_clk_b_a_mux[] = {
+ AUDIO_CLKB_A_MARK,
+};
+static const unsigned int audio_clk_b_b_pins[] = {
+ /* CLK B */
+ RCAR_GP_PIN(6, 23),
+};
+static const unsigned int audio_clk_b_b_mux[] = {
+ AUDIO_CLKB_B_MARK,
+};
+static const unsigned int audio_clk_c_a_pins[] = {
+ /* CLK C */
+ RCAR_GP_PIN(5, 21),
+};
+static const unsigned int audio_clk_c_a_mux[] = {
+ AUDIO_CLKC_A_MARK,
+};
+static const unsigned int audio_clk_c_b_pins[] = {
+ /* CLK C */
+ RCAR_GP_PIN(5, 0),
+};
+static const unsigned int audio_clk_c_b_mux[] = {
+ AUDIO_CLKC_B_MARK,
+};
+static const unsigned int audio_clkout_a_pins[] = {
+ /* CLKOUT */
+ RCAR_GP_PIN(5, 18),
+};
+static const unsigned int audio_clkout_a_mux[] = {
+ AUDIO_CLKOUT_A_MARK,
+};
+static const unsigned int audio_clkout_b_pins[] = {
+ /* CLKOUT */
+ RCAR_GP_PIN(6, 28),
+};
+static const unsigned int audio_clkout_b_mux[] = {
+ AUDIO_CLKOUT_B_MARK,
+};
+static const unsigned int audio_clkout_c_pins[] = {
+ /* CLKOUT */
+ RCAR_GP_PIN(5, 3),
+};
+static const unsigned int audio_clkout_c_mux[] = {
+ AUDIO_CLKOUT_C_MARK,
+};
+static const unsigned int audio_clkout_d_pins[] = {
+ /* CLKOUT */
+ RCAR_GP_PIN(5, 21),
+};
+static const unsigned int audio_clkout_d_mux[] = {
+ AUDIO_CLKOUT_D_MARK,
+};
+static const unsigned int audio_clkout1_a_pins[] = {
+ /* CLKOUT1 */
+ RCAR_GP_PIN(5, 15),
+};
+static const unsigned int audio_clkout1_a_mux[] = {
+ AUDIO_CLKOUT1_A_MARK,
+};
+static const unsigned int audio_clkout1_b_pins[] = {
+ /* CLKOUT1 */
+ RCAR_GP_PIN(6, 29),
+};
+static const unsigned int audio_clkout1_b_mux[] = {
+ AUDIO_CLKOUT1_B_MARK,
+};
+static const unsigned int audio_clkout2_a_pins[] = {
+ /* CLKOUT2 */
+ RCAR_GP_PIN(5, 16),
+};
+static const unsigned int audio_clkout2_a_mux[] = {
+ AUDIO_CLKOUT2_A_MARK,
+};
+static const unsigned int audio_clkout2_b_pins[] = {
+ /* CLKOUT2 */
+ RCAR_GP_PIN(6, 30),
+};
+static const unsigned int audio_clkout2_b_mux[] = {
+ AUDIO_CLKOUT2_B_MARK,
+};
+
+static const unsigned int audio_clkout3_a_pins[] = {
+ /* CLKOUT3 */
+ RCAR_GP_PIN(5, 19),
+};
+static const unsigned int audio_clkout3_a_mux[] = {
+ AUDIO_CLKOUT3_A_MARK,
+};
+static const unsigned int audio_clkout3_b_pins[] = {
+ /* CLKOUT3 */
+ RCAR_GP_PIN(6, 31),
+};
+static const unsigned int audio_clkout3_b_mux[] = {
+ AUDIO_CLKOUT3_B_MARK,
+};
+
/* - EtherAVB ---
*/
static const unsigned int avb_link_pins[] = {
/* AVB_LINK */
@@ -3426,6 +3548,23 @@ static const unsigned int usb30_mux[] = {
};
static const struct sh_pfc_pin_group pinmux_groups[] = {
+ SH_PFC_PIN_GROUP(audio_clk_a_a),
+ SH_PFC_PIN_GROUP(audio_clk_a_b),
+ SH_PFC_PIN_GROUP(audio_clk_a_c),
+ SH_PFC_PIN_GROUP(audio_clk_b_a),
+ SH_PFC_PIN_GROUP(audio_clk_b_b),
+ SH_PFC_PIN_GROUP(audio_clk_c_a),
+ SH_PFC_PIN_GROUP(audio_clk_c_b),
+ SH_PFC_PIN_GROUP(audio_clkout_a),
+ SH_PFC_PIN_GROUP(audio_clkout_b),
+ SH_PFC_PIN_GROUP(audio_clkout_c),
+ SH_PFC_PIN_GROUP(audio_clkout_d),
+ SH_PFC_PIN_GROUP(audio_clkout1_a),
+ SH_PFC_PIN_GROUP(audio_clkout1_b),
+ SH_PFC_PIN_GROUP(audio_clkout2_a),
+ SH_PFC_PIN_GROUP(audio_clkout2_b),
+ SH_PFC_PIN_GROUP(audio_clkout3_a),
+ SH_PFC_PIN_GROUP(audio_clkout3_b),
SH_PFC_PIN_GROUP(avb_link),
SH_PFC_PIN_GROUP(avb_magic),
SH_PFC_PIN_GROUP(avb_phy_in
RE: [PATCH] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Geert, On Monday, August 27, 2018 1, Geert Uytterhoeven wrote: > Given the differences, and the limited amount of RAM on RZ/A2, I think you > would be better off with a separate renesas-cpg-stbcr driver, and an > r7s9210-cpg-stbcr counterpart. I went and measured the amount of RAM being used by the driver (allocated during boot when the driver is loaded and probed), and it's only 8KB. That's not really much compared to other drivers and subsystems being loaded in the system. Of course RZ/A tries to be RAM sensitive...but 8KB for a clock driver is not my biggest concern. So with that said, I could add in a driver option to not register the reset controller. And, also make a macro so users can specify "36" instead of "306" in the DT. And then, I no longer have to worry about duplicate code (2 drivers do almost the same thing). What do you think? Were you expecting the driver to allocate more than 8K of RAM on boot? Thanks, Chris
Re: [PATCH v2 6/7] arm64: dts: renesas: r8a77965: Add HSCIF0 device node
Hi Simon,
On Wed, Aug 22, 2018 at 01:12:47PM +0200, Simon Horman wrote:
> On Sun, Aug 12, 2018 at 03:31:48PM +0200, Eugeniu Rosca wrote:
> > Fix below DTC error:
> > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:36.1-8 Label or path hscif0
> > not found
> >
> > The DTC error occurs *after* the addition of r8a77965-m3nulcb-kf.dts.
> > Fix it beforehand.
> >
> > Inspired from v4.12-rc1 commits:
> > - commit 68cd16107260 ("arm64: dts: r8a7796 dtsi: Add all HSCIF nodes")
> > - commit 6d50bb893504 ("arm64: dts: r8a7796: Enable HSCIF DMA")
> > - commit bec0948e810f ("arm64: dts: r8a7796: Add reset control properties")
> >
> > Signed-off-by: Eugeniu Rosca
> > ---
> > Changes in v2:
> > - Slightly improved the commit description.
> > - Note that this commit could be replaced by
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/commit/?h=b8e3c8e17611
>
> That commit has been accepted for upstream so it should be used.
Thanks for the explanation. No further questions/concerns.
Best regards,
Eugeniu.
Re: [PATCH v2 3/7] pinctrl: sh-pfc: r8a77965: Add HSCIF0 pins, groups, and functions
Hi Geert,
On Mon, Aug 27, 2018 at 05:07:39PM +0200, Geert Uytterhoeven wrote:
> Hi Eugeniu,
>
> On Sun, Aug 12, 2018 at 3:33 PM Eugeniu Rosca wrote:
> > According to R-Car Gen3 HW manual Rev.1.00 Apr 2018, M3-N SoC implements
> > five (0..4) HSCIF channels, similar to H3, M3-W and E3.
> >
> > The story behind this patch is tackling below dmesg warnings, which pop
> > up when booting M3NULCB Kingfisher board:
> >
> > $ dmesg | grep sh-pfc
> > sh-pfc e606.pin-controller: r8a77965_pfc support registered
> > sh-pfc e606.pin-controller: function 'hscif0' not supported
> > sh-pfc e606.pin-controller: invalid function hscif0 in map table
> > sh-pfc e606.pin-controller: function 'hscif0' not supported
> > sh-pfc e606.pin-controller: invalid function hscif0 in map table
> >
> > To fix them, extract the HSCIF0 part from below v4.15-rc1 commits:
> > - commit 7a362e3488cb ("pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups,
> > and functions")
> > - commit 0e4e4999aac1 ("pinctrl: sh-pfc: r8a7796: Add HSCIF pins, groups,
> > and functions")
> >
> > Note that `checkpatch --strict` throws several "CHECK: Please use a
> > blank line after function/struct/union/enum declarations", which are
> > ignored for the sake of staying in sync with the aforementioned commits.
> >
> > Signed-off-by: Eugeniu Rosca
>
> Thanks for your patch, but please see commit 7628fa811b8af571 ("pinctrl:
> sh-pfc: r8a77965: Add HSCIF pins, groups, and functions") in v4.19-rc1.
Thanks for pointing out. Please, feel free to drop the patch. Its
purpose was to build a self-contained (no new compiler/dmesg
warnings/errors) patch series assuming v4.18.
> 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,
Eugeniu.
Re: [PATCH v2 5/7] arm64: dts: renesas: r8a77965: Add CAN{0,1} placeholder nodes
Hi Simon, hi Geert,
On Mon, Aug 27, 2018 at 02:44:47PM +0200, Simon Horman wrote:
> On Thu, Aug 23, 2018 at 10:52:09AM +0200, Geert Uytterhoeven wrote:
> > On Fri, Aug 17, 2018 at 3:53 PM Kieran Bingham
> > wrote:
> > > On 12/08/18 14:31, Eugeniu Rosca wrote:
> > > > According to R-Car Gen3 HW manual rev1.00, R-Car M3-N has two CAN
> > > > interfaces, similar to H3, M3-W and other SoCs from the same family.
> > > >
> > > > Add CAN placeholder nodes to avoid below DTC errors:
> > > > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path
> > > > can0 not found
> > > > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path
> > > > can1 not found
> > > >
> > > > These errors occur *after* the addition of r8a77965-m3nulcb-kf.dts.
> > > > Fix them beforehand.
> > > >
> > > > CAN support is inspired from below commits:
> > > > - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
> > > > - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
> > > > - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control
> > > > properties")
> > > >
> > > > Signed-off-by: Eugeniu Rosca
> > >
> > > Reviewed-by: Kieran Bingham
> > >
> > >
> > > > ---
> > > > Changes in v2:
> > > > - [Kieran Bingham] Improved commit description:
> > > >- Referenced the newer HW manual rev1.00 instead of rev0.55E.
> > > >- Kept the "true story" behind the patch. Just made it more clear.
> > > > - [Geert Uytterhoeven] Replaced CAN0 and CAN1 nodes with placeholders
> > > >(no CAN testing was done to validate the DTS configuration).
> > > > ---
> > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi | 16
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > > b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > > index 486aecacb22a..4da479d3c226 100644
> > > > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > > @@ -656,6 +656,22 @@
> > > > status = "disabled";
> > > > };
> > > >
> > > > + can0: can@e6c3 {
> > > > + compatible = "renesas,can-r8a77965",
> > > > + "renesas,rcar-gen3-can";
> > > > + reg = <0 0xe6c3 0 0x1000>;
> > > > + /* placeholder */
> > > > + status = "disabled";
> > > > + };
> > >
> > > This is probably more detail than is needed for a placeholder, but it
> > > looks correct so I think this is fine.
> >
> > Indeed. Adding the "compatible" properties means they're no longer
> > placeholders, and will be probed by the driver, possibly leading to
> > undefined behavior.
> >
> > Hence please limit the placeholders to the absolute required minimum,
> > and thus drop the "compatible" and "status" properties.
>
> Agreed, I will update the patch accordingly.
My understanding is that Simon will drop the compatible strings and no
action is needed from my end. Let me know otherwise.
Thanks,
Eugeniu.
Re: [PATCH v2 5/7] arm64: dts: renesas: r8a77965: Add CAN{0,1} placeholder nodes
Hi Kieran, I appreciate the detailed reply zooming in into many aspects (both technical and related to process/workflow) of contributing/reviewing patches. I take it as is. I could elaborate on specific parts of it, like applying the "undefined behavior" term (which comes from the world of compilers) to the software we write. This doesn't sound right to me, since our software is guided by our own requirements and one of this requirements is (should be) predictable and safe behavior given some junky/incomplete DTS configuration. If any bugs exist dealing with nonsense configuration, IMHO they should be fixed in the driver. Since my purpose is simply seeing the patches in upstream the way maintainers like them best, I will put little to no time discussing this and will mainly focus on submitting any changes requested by the reviewers. Thanks, Eugeniu.
[PATCH v3 2/2] arm64: dts: renesas: condor: add PCIe support
Enable PCIe PHY and PCIEC and specify the PCIe bus clock for the Condor
board.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
---
Changes in version 2:
- mentioned Vladimir's original work and added his signoff;
- refreshed the patch.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 12
1 file changed, 12 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
@@ -223,6 +223,18 @@
status = "okay";
};
+&pciec {
+ status = "okay";
+};
+
+&pcie_bus_clk {
+ clock-frequency = <1>;
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
&pfc {
avb_pins: avb {
groups = "avb_mdio", "avb_rgmii";
[PATCH v3 1/2] arm64: dts: renesas: r8a77980: add PCIe support
Describe the PCIe PHY, PCIEC, and PCIe bus clock 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: Simon Horman
---
Changes in version 3:
- refreshed against the recent tree (moving the PCIe clock node);
- added Simon's tag.
Changes in version 2:
- merged in the PCIEC patch, renamed the patch, updated the description
accordingly;
- used R8A77980_PD_ALWAYS_ON in the "power-domains" props;
- mentioned Vladimir's original work and added his signoff.
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 49 ++
1 file changed, 49 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
@@ -98,6 +98,13 @@
clock-frequency = <0>;
};
+ /* External PCIe clock - can be overridden by the board */
+ pcie_bus_clk: pcie_bus {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
pmu_a53 {
compatible = "arm,cortex-a53-pmu";
interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
@@ -437,6 +444,16 @@
status = "disabled";
};
+ pcie_phy: pcie-phy@e65d {
+ compatible = "renesas,r8a77980-pcie-phy";
+ reg = <0 0xe65d 0 0x8000>;
+ #phy-cells = <0>;
+ clocks = <&cpg CPG_MOD 319>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 319>;
+ status = "disabled";
+ };
+
canfd: can@e66c {
compatible = "renesas,r8a77980-canfd",
"renesas,rcar-gen3-canfd";
@@ -1047,6 +1064,38 @@
resets = <&cpg 408>;
};
+ pciec: pcie@fe00 {
+ compatible = "renesas,pcie-r8a77980",
+"renesas,pcie-rcar-gen3";
+ reg = <0 0xfe00 0 0x8>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <
+ 0x0100 0 0x 0 0xfe10 0 0x010
+ 0x0200 0 0xfe20 0 0xfe20 0 0x020
+ 0x0200 0 0x3000 0 0x3000 0 0x800
+ 0x4200 0 0x3800 0 0x3800 0 0x800
+ >;
+ dma-ranges = <0x4200 0 0x4000 0 0x4000
+ 0 0x8000>;
+ interrupts = ,
+,
+;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 148
+IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 319>, <&pcie_bus_clk>;
+ clock-names = "pcie", "pcie_bus";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 319>;
+ phys = <&pcie_phy>;
+ phy-names = "pcie";
+ status = "disabled";
+ };
+
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
reg = <0 0xfea2 0 0x5000>;
Re: [PATCH v2 0/2] Add R8A77980/Condor PCIe support
v3, I meant to type... :-/
[PATCH v2 0/2] Add R8A77980/Condor PCIe support
Hello! Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20180827-v4.19-rc1' tag. We're adding the R8A77980 PCIe related device nodes and then enable PCIe on the Condor board. [1/2] arm64: dts: renesas: r8a77980: add PCIe support [2/2] arm64: dts: renesas: condor: add PCIe support WBR, Sergei
Re: [PATCH] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Chris,
On Mon, Aug 27, 2018 at 6:59 PM Chris Brandt wrote:
> On Monday, August 27, 2018 1, Geert Uytterhoeven wrote:
> > Given the differences, and the limited amount of RAM on RZ/A2, I think you
> > would be better off with a separate renesas-cpg-stbcr driver, and an
> > r7s9210-cpg-stbcr counterpart.
>
> If you really think there will be a lot of wasted RAM, then I will look
> into it.
>
> So are you saying I should first copy/rename renesas-cpg-mssr.c to
> renesas-cpg-stbr.c and then start hacking away at it?
Exactly.
It's debatable: from one side, it's good to reuse code. From the other other,
to much conditional logic complicates everything.
The reset controller part will be different anyway.
But the clock domain part and most of the core/module logic is the same.
Perhaps some common code can be spun off?
> > 4. Your module clocks can use e.g. "36" instead of "306" (also in the DTS),
> >matching the datasheet.
>
> Yes, that would be much nicer!
At least in DTS and the module clock table, you can get that with cpg-mssr, too,
if you use a different macro.
> Just FYI,
> I like this new driver method, but the one downfall is that I have to go
> back and change my timer driver (renesas-ostm.c). The current OSTM
> driver uses TIMER_OF_DECLARE(). But when you use TIMER_OF_DECLARE, your
> timer driver gets probed VERY early in boot, before subsys_initcall, so none
> of your clocks are registered yet and the probe fails.
IC. When CPG/MSSR was introduced, we had ordering issues on R-Car, too.
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] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Geert,
Thank you for having a look at this.
On Monday, August 27, 2018 1, Geert Uytterhoeven wrote:
> Given the differences, and the limited amount of RAM on RZ/A2, I think you
> would be better off with a separate renesas-cpg-stbcr driver, and an
> r7s9210-cpg-stbcr counterpart.
If you really think there will be a lot of wasted RAM, then I will look
into it.
So are you saying I should first copy/rename renesas-cpg-mssr.c to
renesas-cpg-stbr.c and then start hacking away at it?
> 4. Your module clocks can use e.g. "36" instead of "306" (also in the DTS),
>matching the datasheet.
Yes, that would be much nicer!
Just FYI,
I like this new driver method, but the one downfall is that I have to go
back and change my timer driver (renesas-ostm.c). The current OSTM
driver uses TIMER_OF_DECLARE(). But when you use TIMER_OF_DECLARE, your
timer driver gets probed VERY early in boot, before subsys_initcall, so none
of your clocks are registered yet and the probe fails.
Chris
>
> That means:
>
> > .../devicetree/bindings/clock/renesas,cpg-mssr.txt | 3 +-
>
> 1. A separate binding document.
>
> > drivers/clk/renesas/Kconfig| 5 +
> > drivers/clk/renesas/Makefile | 1 +
> > drivers/clk/renesas/r7s9210-cpg-mssr.c | 189
> +
> > drivers/clk/renesas/renesas-cpg-mssr.c | 66 +--
> > drivers/clk/renesas/renesas-cpg-mssr.h | 6 +
> > include/dt-bindings/clock/r7s9210-cpg-mssr.h | 21 +++
> > 7 files changed, 280 insertions(+), 11 deletions(-)
> > create mode 100644 drivers/clk/renesas/r7s9210-cpg-mssr.c
> > create mode 100644 include/dt-bindings/clock/r7s9210-cpg-mssr.h
> >
> > diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-
> mssr.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> > index db542abadb75..66ca973edd77 100644
> > --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> > +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> > @@ -13,6 +13,7 @@ They provide the following functionalities:
> >
> > Required Properties:
> >- compatible: Must be one of:
> > + - "renesas,r7s9210-cpg-mssr" for the r7s9210 SoC (RZ/A2)
> >- "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M)
> >- "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E)
> >- "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C)
> > @@ -37,7 +38,7 @@ Required Properties:
> >- clock-names: List of external parent clock names. Valid names are:
> >- "extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7792,
> > r8a7793, r8a7794, r8a7795, r8a7796, r8a77965, r8a77970,
> > -r8a77980, r8a77990, r8a77995)
> > +r8a77980, r8a77990, r8a77995, r7s9210)
> >- "extalr" (r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
> >- "usb_extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791,
> r8a7793,
> > r8a7794)
> > diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
> > index 9022bbe1297e..d8ccdaba5103 100644
> > --- a/drivers/clk/renesas/Kconfig
> > +++ b/drivers/clk/renesas/Kconfig
>
> > @@ -45,6 +46,10 @@ config CLK_RZA1
> > bool "RZ/A1H clock support" if COMPILE_TEST
> > select CLK_RENESAS_CPG_MSTP
> >
> > +config CLK_R7S9210
> > + bool "RZ/A2 clock support" if COMPILE_TEST
> > + select CLK_RENESAS_CPG_MSSR
>
> 2. a separate CLK_RENESAS_CPG_STBCR symbol.
>
> > --- /dev/null
> > +++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
>
> 3. Almost all of this can stay the same, modulo some renames.
>
> > +static const struct mssr_mod_clk r7s9210_mod_clks[] __initconst = {
> > + DEF_MOD("ostm0", 306, R7S9210_CLK_P1C),
>
> 4. Your module clocks can use e.g. "36" instead of "306" (also in the DTS),
>matching the datasheet.
>
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/r7s9210-cpg-mssr.h
>
> 5. Almost all of this can stay the same, modulo some renames.
>
> What do you think?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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] clk: renesas: cpg-mssr: Add R7S9210 support
Hi Chris,
On Tue, Aug 21, 2018 at 5:20 AM Chris Brandt wrote:
> Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
> Standby.
Thanks for your patch, looks mostly OK to me!
> The Module Standby HW in the RZ/A series is very close to R-Car HW, except
> for how the registers are laid out.
> The MSTP registers are only 8-bits wide, there is no status registers
> (MSTPST), and the register offsets are a little different. Since the RZ/A
> hardware manuals refer to these registers as the Standby Control Registers,
> we'll use that name to distinguish the RZ/A type for the R-Car type.
And it doesn't have the reset control registers, so you should not register
the reset controller (or register a different one, when you add the support).
> Signed-off-by: Chris Brandt
Given the differences, and the limited amount of RAM on RZ/A2, I think you
would be better off with a separate renesas-cpg-stbcr driver, and an
r7s9210-cpg-stbcr counterpart.
That means:
> .../devicetree/bindings/clock/renesas,cpg-mssr.txt | 3 +-
1. A separate binding document.
> drivers/clk/renesas/Kconfig| 5 +
> drivers/clk/renesas/Makefile | 1 +
> drivers/clk/renesas/r7s9210-cpg-mssr.c | 189
> +
> drivers/clk/renesas/renesas-cpg-mssr.c | 66 +--
> drivers/clk/renesas/renesas-cpg-mssr.h | 6 +
> include/dt-bindings/clock/r7s9210-cpg-mssr.h | 21 +++
> 7 files changed, 280 insertions(+), 11 deletions(-)
> create mode 100644 drivers/clk/renesas/r7s9210-cpg-mssr.c
> create mode 100644 include/dt-bindings/clock/r7s9210-cpg-mssr.h
>
> diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> index db542abadb75..66ca973edd77 100644
> --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> @@ -13,6 +13,7 @@ They provide the following functionalities:
>
> Required Properties:
>- compatible: Must be one of:
> + - "renesas,r7s9210-cpg-mssr" for the r7s9210 SoC (RZ/A2)
>- "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M)
>- "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E)
>- "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C)
> @@ -37,7 +38,7 @@ Required Properties:
>- clock-names: List of external parent clock names. Valid names are:
>- "extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7792,
> r8a7793, r8a7794, r8a7795, r8a7796, r8a77965, r8a77970,
> -r8a77980, r8a77990, r8a77995)
> +r8a77980, r8a77990, r8a77995, r7s9210)
>- "extalr" (r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
>- "usb_extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7793,
> r8a7794)
> diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
> index 9022bbe1297e..d8ccdaba5103 100644
> --- a/drivers/clk/renesas/Kconfig
> +++ b/drivers/clk/renesas/Kconfig
> @@ -45,6 +46,10 @@ config CLK_RZA1
> bool "RZ/A1H clock support" if COMPILE_TEST
> select CLK_RENESAS_CPG_MSTP
>
> +config CLK_R7S9210
> + bool "RZ/A2 clock support" if COMPILE_TEST
> + select CLK_RENESAS_CPG_MSSR
2. a separate CLK_RENESAS_CPG_STBCR symbol.
> --- /dev/null
> +++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
3. Almost all of this can stay the same, modulo some renames.
> +static const struct mssr_mod_clk r7s9210_mod_clks[] __initconst = {
> + DEF_MOD("ostm0", 306, R7S9210_CLK_P1C),
4. Your module clocks can use e.g. "36" instead of "306" (also in the DTS),
matching the datasheet.
> --- /dev/null
> +++ b/include/dt-bindings/clock/r7s9210-cpg-mssr.h
5. Almost all of this can stay the same, modulo some renames.
What do you think?
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 2/2] pinctrl: sh-pfc: r8a77965: add Audio SSI pin support
Hi Hoan,
On Fri, Aug 17, 2018 at 5:03 AM Nguyen An Hoan wrote:
> From: Hoan Nguyen An
Thanks for your patch!
Reviewed-by: Geert Uytterhoeven
But I cannot apply it without your Signed-off-by.
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] clk: renesas: cpg-mssr: Add R7S9210 support
Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
Standby.
The Module Standby HW in the RZ/A series is very close to R-Car HW, except
for how the registers are laid out.
The MSTP registers are only 8-bits wide, there is no status registers
(MSTPST), and the register offsets are a little different. Since the RZ/A
hardware manuals refer to these registers as the Standby Control Registers,
we'll use that name to distinguish the RZ/A type for the R-Car type.
Signed-off-by: Chris Brandt
---
v2:
* num_hw_mod_clks was wrong
* added ethernet clocks
---
.../devicetree/bindings/clock/renesas,cpg-mssr.txt | 3 +-
drivers/clk/renesas/Kconfig| 5 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r7s9210-cpg-mssr.c | 192 +
drivers/clk/renesas/renesas-cpg-mssr.c | 66 +--
drivers/clk/renesas/renesas-cpg-mssr.h | 6 +
include/dt-bindings/clock/r7s9210-cpg-mssr.h | 21 +++
7 files changed, 283 insertions(+), 11 deletions(-)
create mode 100644 drivers/clk/renesas/r7s9210-cpg-mssr.c
create mode 100644 include/dt-bindings/clock/r7s9210-cpg-mssr.h
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
index 42d0f83d812b..012416b33d2d 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
@@ -13,6 +13,7 @@ They provide the following functionalities:
Required Properties:
- compatible: Must be one of:
+ - "renesas,r7s9210-cpg-mssr" for the r7s9210 SoC (RZ/A2)
- "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M)
- "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E)
- "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C)
@@ -38,7 +39,7 @@ Required Properties:
- clock-names: List of external parent clock names. Valid names are:
- "extal" (r8a7743, r8a7745, r8a77470, r8a774a1, r8a7790, r8a7791,
r8a7792, r8a7793, r8a7794, r8a7795, r8a7796, r8a77965,
-r8a77970, r8a77980, r8a77990, r8a77995)
+r8a77970, r8a77980, r8a77990, r8a77995, r7s9210)
- "extalr" (r8a774a1, r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
- "usb_extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7793,
r8a7794)
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index f998a7333acb..2edcb1bdb487 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -3,6 +3,7 @@ config CLK_RENESAS
default y if ARCH_RENESAS
select CLK_EMEV2 if ARCH_EMEV2
select CLK_RZA1 if ARCH_R7S72100
+ select CLK_R7S9210 if ARCH_R7S9210
select CLK_R8A73A4 if ARCH_R8A73A4
select CLK_R8A7740 if ARCH_R8A7740
select CLK_R8A7743 if ARCH_R8A7743
@@ -46,6 +47,10 @@ config CLK_RZA1
bool "RZ/A1H clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
+config CLK_R7S9210
+ bool "RZ/A2 clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSSR
+
config CLK_R8A73A4
bool "R-Mobile APE6 clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index 71d4cafe15c0..dbbfd0b0742b 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -2,6 +2,7 @@
# SoC
obj-$(CONFIG_CLK_EMEV2)+= clk-emev2.o
obj-$(CONFIG_CLK_RZA1) += clk-rz.o
+obj-$(CONFIG_CLK_R7S9210) += r7s9210-cpg-mssr.o
obj-$(CONFIG_CLK_R8A73A4) += clk-r8a73a4.o
obj-$(CONFIG_CLK_R8A7740) += clk-r8a7740.o
obj-$(CONFIG_CLK_R8A7743) += r8a7743-cpg-mssr.o
diff --git a/drivers/clk/renesas/r7s9210-cpg-mssr.c
b/drivers/clk/renesas/r7s9210-cpg-mssr.c
new file mode 100644
index ..e63bc634d252
--- /dev/null
+++ b/drivers/clk/renesas/r7s9210-cpg-mssr.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * r7s9210 Clock Pulse Generator / Module Standby and Software Reset
+ *
+ * Based on r8a7795-cpg-mssr.c
+ *
+ * Copyright (C) 2018 Chris Brandt
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ *
+ */
+
+#include
+#include
+#include
+#include "renesas-cpg-mssr.h"
+
+#define CPG_FRQCR 0x00
+#define CPG_CKIOSEL0xF0
+#define CPG_SCLKSEL0xF4
+
+#define PORTL_PIDR 0xFCFFE074
+static u8 cpg_mode;
+
+/* Internal Clock ratio table */
+static const unsigned int ratio_tab[5][5] = {
+ /* I, G, B, P1, P0 */
+ { 2, 4, 8, 16, 32 }, /* FRQCR = 0x012 */
+ { 4, 4, 8, 16, 32 }, /* FRQCR = 0x112 */
+ { 8, 4, 8, 16, 32 }, /* FRQCR = 0x212 */
+ { 16, 8, 16, 16, 32 }, /* FRQCR = 0x322 */
+ { 16, 16, 32, 32, 32 }
Re: [PATCH 1/2] pinctrl: sh-pfc: r8a77965: add Audio clock pin support
Hi Hoan,
On Fri, Aug 17, 2018 at 5:03 AM Nguyen An Hoan wrote:
> From: Hoan Nguyen An
Reviewed-by: Geert Uytterhoeven
But I cannot apply it without your Signed-off-by.
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 2/2] pinctrl: sh-pfc: r8a7796: Add R8A774A1 PFC support
Hi Biju,
On Tue, Aug 14, 2018 at 10:18 AM Biju Das wrote:
> > Subject: RE: [PATCH 2/2] pinctrl: sh-pfc: r8a7796: Add R8A774A1 PFC support
> > > From: Biju Das
> > > Sent: 13 August 2018 14:53
> > >
> > > Renesas RZ/G2M (r8a774a1) is pin compatible with R-Car M3-W (r8a7796),
> > > however it doesn't have several automotive specific peripherals. Add a
> > > r8a7796 specific pin groups/functions along with common pin
> > > groups/functions for supporting both r8a7796 and r8a7794a1 SoC.
> > s|r8a7794a1|r8a774a1
>
> Will fix this and send v2.
No need for that, I can fix it up while applying.
> > > Signed-off-by: Biju Das
> > > Reviewed-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.2.0.
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/2] mmc: renesas_sdhi: handle 4tap hs400 mode quirk based on SoC revision
Hi Geert,
Thanks for your feedback.
On 2018-08-06 21:55:17 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, Aug 6, 2018 at 9:43 PM Niklas Söderlund
> wrote:
> > Latest datasheet makes it clear that not all ES revisions of the H3 and
> > M3-W have the 4-tap HS400 mode quirk, currently the quirk is set
> > unconditionally for these two SoCs. Prepare to handle the quirk based on
> > SoC revision instead of compatibility value by using soc_device_match()
> > and set the TMIO_MMC_HAVE_4TAP_HS400 flag explicitly.
>
> Thanks for your patch!
>
> > The reason for adding a new quirks struct instead of just a flag is that
> > looking ahead it seems more quirks needs to be handled in a SoC revision
> > basis.
>
> Do you expect to add a lot? If yes...
Looking at the BSP it looks like there will be just one more quirk
needed.
>
> > --- a/drivers/mmc/host/renesas_sdhi_core.c
> > +++ b/drivers/mmc/host/renesas_sdhi_core.c
>
> > @@ -569,6 +588,10 @@ int renesas_sdhi_probe(struct platform_device *pdev,
> >
> > of_data = of_device_get_match_data(&pdev->dev);
> >
> > + attr = soc_device_match(sdhi_quirks_match);
> > + if (attr)
> > + quirks = attr->data;
>
> ... you may consider just storing a plain struct renesas_sdhi_of_data in
> the sdhi_quirks_match[] table.
I think this design is less messy as the quirks gets added in
renesas_sdhi_core.c instead of needing to keep
renesas_sdhi_internal_dmac.c and renesas_sdhi_sys_dmac.c in sync with
the quirks.
Wolfram what do you think about this design?
>
> > +
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > if (!res)
> > return -EINVAL;
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Regards,
Niklas Söderlund
Re: [PATCH 1/2] dt-bindings: pinctrl: sh-pfc: Document r8a774a1 PFC support
On Mon, Aug 13, 2018 at 3:58 PM Biju Das wrote:
> Document PFC support for the R8A774A1 SoC.
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.2.0.
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 v3 1/2] mmc: renesas_sdhi: skip SCC error check when retuning
From: Masaharu Hayakawa
Checking for SCC error during retuning is unnecessary.
Signed-off-by: Masaharu Hayakawa
[Niklas: fix small style issue]
Signed-off-by: Niklas Söderlund
---
* Changes since v2
- Add comment to describe why checking SCC errors when using 4 taps is
not needed.
* Changes since v1
- Use intermediate variable use_4tap to simplify check.
---
drivers/mmc/host/renesas_sdhi_core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/mmc/host/renesas_sdhi_core.c
b/drivers/mmc/host/renesas_sdhi_core.c
index 777e32b0e410e850..4427f0e7058f3ee5 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -443,6 +443,19 @@ static int renesas_sdhi_select_tuning(struct tmio_mmc_host
*host)
static bool renesas_sdhi_check_scc_error(struct tmio_mmc_host *host)
{
struct renesas_sdhi *priv = host_to_priv(host);
+ bool use_4tap = host->pdata->flags & TMIO_MMC_HAVE_4TAP_HS400;
+
+ /*
+* Skip checking SCC errors when running on 4 taps in HS400 mode as
+* any retuning would still result in the same 4 taps being used.
+*/
+ if (!(host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) &&
+ !(host->mmc->ios.timing == MMC_TIMING_MMC_HS200) &&
+ !(host->mmc->ios.timing == MMC_TIMING_MMC_HS400 && !use_4tap))
+ return false;
+
+ if (host->mmc->doing_retune)
+ return false;
/* Check SCC error */
if (sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL) &
--
2.18.0
[PATCH v3 0/2] mmc: {tmio,renesas_sdhi}: retune if SCC error detected
Hi, These patches triggers a retune if a SCC error is detected. They where ported from the renesas BSP. Masaharu-san did all the real work I just ported them to upstream and did small fixups. These patches where broken out of my retuning series as more work where needed to adapt them to the recent HS400 series picked-up. It's tested on M3-N using both HS200 and HS400 and on H3 ES2.0 using HS200. Masaharu Hayakawa (2): mmc: renesas_sdhi: skip SCC error check when retuning mmc: tmio: Fix SCC error detection drivers/mmc/host/renesas_sdhi_core.c | 13 + drivers/mmc/host/tmio_mmc_core.c | 4 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) -- 2.18.0
[PATCH v3 2/2] mmc: tmio: Fix SCC error detection
From: Masaharu Hayakawa
SDR104 and HS200 need to check for SCC error. If SCC error is detected,
retuning is necessary.
Signed-off-by: Masaharu Hayakawa
[Niklas: update commit message]
Signed-off-by: Niklas Söderlund
---
drivers/mmc/host/tmio_mmc_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 261b4d62d2b1061f..268c4a3b728c775f 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -919,8 +919,8 @@ static void tmio_mmc_finish_request(struct tmio_mmc_host
*host)
if (mrq->cmd->error || (mrq->data && mrq->data->error))
tmio_mmc_abort_dma(host);
- if (host->check_scc_error)
- host->check_scc_error(host);
+ if (host->check_scc_error && host->check_scc_error(host))
+ mrq->cmd->error = -EILSEQ;
/* If SET_BLOCK_COUNT, continue with main command */
if (host->mrq && !mrq->cmd->error) {
--
2.18.0
Re: [PATCH 0/3] I2C0/3/5 pin control for H3 and M3-W
Hi Uli,
On Fri, Aug 17, 2018 at 3:19 PM Ulrich Hecht wrote:
> This is an up-port from the BSP. Unfortunately I could not test these
> because none of those pins seem to be accessible on Salvator boards (not on
> ULCB either, AFAICT), so the best thing I can say is that they don't seem to
> break anything.
For Salvator-X(S):
1. If you set SW5 and SW6 to their center positions, you can access I2C3 on
EXIO Connector D.
2. I2C5 is available on test points CP45/46.
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 v2 3/7] pinctrl: sh-pfc: r8a77965: Add HSCIF0 pins, groups, and functions
Hi Eugeniu,
On Sun, Aug 12, 2018 at 3:33 PM Eugeniu Rosca wrote:
> According to R-Car Gen3 HW manual Rev.1.00 Apr 2018, M3-N SoC implements
> five (0..4) HSCIF channels, similar to H3, M3-W and E3.
>
> The story behind this patch is tackling below dmesg warnings, which pop
> up when booting M3NULCB Kingfisher board:
>
> $ dmesg | grep sh-pfc
> sh-pfc e606.pin-controller: r8a77965_pfc support registered
> sh-pfc e606.pin-controller: function 'hscif0' not supported
> sh-pfc e606.pin-controller: invalid function hscif0 in map table
> sh-pfc e606.pin-controller: function 'hscif0' not supported
> sh-pfc e606.pin-controller: invalid function hscif0 in map table
>
> To fix them, extract the HSCIF0 part from below v4.15-rc1 commits:
> - commit 7a362e3488cb ("pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups,
> and functions")
> - commit 0e4e4999aac1 ("pinctrl: sh-pfc: r8a7796: Add HSCIF pins, groups,
> and functions")
>
> Note that `checkpatch --strict` throws several "CHECK: Please use a
> blank line after function/struct/union/enum declarations", which are
> ignored for the sake of staying in sync with the aforementioned commits.
>
> Signed-off-by: Eugeniu Rosca
Thanks for your patch, but please see commit 7628fa811b8af571 ("pinctrl:
sh-pfc: r8a77965: Add HSCIF pins, groups, and functions") in v4.19-rc1.
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: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Niklas, On Mon, Aug 27, 2018 at 03:23:45PM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > On 2018-08-27 11:49:56 +0200, Jacopo Mondi wrote: > > Hi Niklas, > > A few more talk on the adv748x link handling, please bear with me... > > > > On Sat, Aug 25, 2018 at 03:18:06PM +0200, jacopo mondi wrote: > > > Hi Laurent, Niklas, > > > > > > On Sat, Aug 25, 2018 at 08:37:15AM +0200, Niklas Söderlund wrote: > > > > Hi Laurent and Jacopo, > > > > > > > > On 2018-08-25 02:54:44 +0300, Laurent Pinchart wrote: > > > > > Hi Jacopo, > > > > > > > > > > On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > > > > > > Hello renesas list, > > > > > >this series add supports for the HDMI and CVBS input to R-Car E3 > > > > > > R8A77990 > > > > > > Ebisu board. > > > > > > > > > > > > It's an RFT, as I don't have an Ebisu to test with :( > > > > > > > > > > > > The series adds supports for the following items: > > > > > > > > > > > > - PFC: add VIN groups and functions > > > > > > - R-Car VIN and R-Car CSI-2: add support for R8A77990 > > > > > > - R8A77990: Add I2C, VIN and CSI-2 nodes > > > > > > - Ebisu: describe HDMI and CVBS inputs > > > > > > > > > > > > Each patch, when relevant reports difference between the upported > > > > > > BSP patch > > > > > > and the proposed one. > > > > > > > > > > > > I know Laurent should receive an Ebisu sooner or later, maybe we > > > > > > can sync > > > > > > for testing :) > > > > > > > > > > I've given the series a first test, and I think a bit more work is > > > > > needed :-) > > > > > > > > > > [1.455533] adv748x 0-0070: Endpoint > > > > > /soc/i2c@e650/video-receiver@70/ > > > > > port@7/endpoint on port 7 > > > > > [1.464683] adv748x 0-0070: Endpoint > > > > > /soc/i2c@e650/video-receiver@70/ > > > > > port@8/endpoint on port 8 > > > > > [1.473728] adv748x 0-0070: Endpoint > > > > > /soc/i2c@e650/video-receiver@70/ > > > > > port@a/endpoint on port 10 > > > > > [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 > > > > > [1.639470] adv748x 0-0070: No endpoint found for txb > > > > > [1.644653] adv748x 0-0070: Failed to probe TXB > > > > > > > > I fear this is a design choice in the adv748x driver. Currently the > > > > driver requires both of its two CSI-2 transmitters to be connected/used > > > > else probe fails. Furthermore the HDMI capture is always routed to TXA > > > > while the analog capture is always routed to TXB. > > > > > > > > Now that we have a board where only TXA is connected but both HDMI and > > > > analog captures are used maybe it's time to do some more work on v4l2 > > > > and the adv748x driver ;-P What's missing: > > > > > > > > - Probe should be OK with either TXA or TXB connected and not bail if > > > > not both are used. > > > > > > I have three patches for this I hope to share as soon as I'll be able > > > to do some more testing > > > > > > > - The media_device_ops or at least the .link_notify() callback of that > > > > struct must be changed so not one driver in the media graph is > > > > responsible for all links. In this case rcar-vin provides the callback > > > > and rcar-vin should not judge which links between the adv748x > > > > subdevices are OK to enable/disable. Currently the links between the > > > > adv748x subdevices are immutably enabled to avoid this particular > > > > problem. > > > > > > Uh, I didn't get this :/ Care to elaborate more? > > > > > > > I'm thinking if it is not enough to just provide a .link_setup() > > callback to the (enabled) csi-2 sink pads of the adv748x and handle > > routing between the afe/hdmi sources and that sink, without the vin's > > registered link_notify playing any role in that. > > That is my point, the v4l2 framework needs work to allow all drivers to > provide a .link_setup() callback. And this as you describe will conflict > with the current solution where there is only one possible such > callback. So in addition to being able to have multiple such callbacks > the current drivers implementing one would need to be updated to ignore > links which it do not care about. > > In our case the .link_setup() in rcar-vin should not care about the > links between the adv748x internal subdevice. Of course the other way > around is also true, the .link_setup() in adv748x should not care about > the links handled by rcar-vin :-) > > As you discovers this is not possible today and might require some work > or maybe even a different design then the one outlined above. > Myabe I'm missing some piece for sure, but why do you think it is not possible? I've applied, for testing, the following patch: https://paste.debian.net/1039515/ And that's the output I get * At system boot, no link is enabled between the HDMI backend and the TXA output: [root@alarm ~]# media-ctl -p -d /dev/media2 - entity 7: adv748x 4-0070 txa (2 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-su
Re: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Jacopo, On 2018-08-27 11:49:56 +0200, Jacopo Mondi wrote: > Hi Niklas, > A few more talk on the adv748x link handling, please bear with me... > > On Sat, Aug 25, 2018 at 03:18:06PM +0200, jacopo mondi wrote: > > Hi Laurent, Niklas, > > > > On Sat, Aug 25, 2018 at 08:37:15AM +0200, Niklas Söderlund wrote: > > > Hi Laurent and Jacopo, > > > > > > On 2018-08-25 02:54:44 +0300, Laurent Pinchart wrote: > > > > Hi Jacopo, > > > > > > > > On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > > > > > Hello renesas list, > > > > >this series add supports for the HDMI and CVBS input to R-Car E3 > > > > > R8A77990 > > > > > Ebisu board. > > > > > > > > > > It's an RFT, as I don't have an Ebisu to test with :( > > > > > > > > > > The series adds supports for the following items: > > > > > > > > > > - PFC: add VIN groups and functions > > > > > - R-Car VIN and R-Car CSI-2: add support for R8A77990 > > > > > - R8A77990: Add I2C, VIN and CSI-2 nodes > > > > > - Ebisu: describe HDMI and CVBS inputs > > > > > > > > > > Each patch, when relevant reports difference between the upported BSP > > > > > patch > > > > > and the proposed one. > > > > > > > > > > I know Laurent should receive an Ebisu sooner or later, maybe we can > > > > > sync > > > > > for testing :) > > > > > > > > I've given the series a first test, and I think a bit more work is > > > > needed :-) > > > > > > > > [1.455533] adv748x 0-0070: Endpoint > > > > /soc/i2c@e650/video-receiver@70/ > > > > port@7/endpoint on port 7 > > > > [1.464683] adv748x 0-0070: Endpoint > > > > /soc/i2c@e650/video-receiver@70/ > > > > port@8/endpoint on port 8 > > > > [1.473728] adv748x 0-0070: Endpoint > > > > /soc/i2c@e650/video-receiver@70/ > > > > port@a/endpoint on port 10 > > > > [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 > > > > [1.639470] adv748x 0-0070: No endpoint found for txb > > > > [1.644653] adv748x 0-0070: Failed to probe TXB > > > > > > I fear this is a design choice in the adv748x driver. Currently the > > > driver requires both of its two CSI-2 transmitters to be connected/used > > > else probe fails. Furthermore the HDMI capture is always routed to TXA > > > while the analog capture is always routed to TXB. > > > > > > Now that we have a board where only TXA is connected but both HDMI and > > > analog captures are used maybe it's time to do some more work on v4l2 > > > and the adv748x driver ;-P What's missing: > > > > > > - Probe should be OK with either TXA or TXB connected and not bail if > > > not both are used. > > > > I have three patches for this I hope to share as soon as I'll be able > > to do some more testing > > > > > - The media_device_ops or at least the .link_notify() callback of that > > > struct must be changed so not one driver in the media graph is > > > responsible for all links. In this case rcar-vin provides the callback > > > and rcar-vin should not judge which links between the adv748x > > > subdevices are OK to enable/disable. Currently the links between the > > > adv748x subdevices are immutably enabled to avoid this particular > > > problem. > > > > Uh, I didn't get this :/ Care to elaborate more? > > > > I'm thinking if it is not enough to just provide a .link_setup() > callback to the (enabled) csi-2 sink pads of the adv748x and handle > routing between the afe/hdmi sources and that sink, without the vin's > registered link_notify playing any role in that. That is my point, the v4l2 framework needs work to allow all drivers to provide a .link_setup() callback. And this as you describe will conflict with the current solution where there is only one possible such callback. So in addition to being able to have multiple such callbacks the current drivers implementing one would need to be updated to ignore links which it do not care about. In our case the .link_setup() in rcar-vin should not care about the links between the adv748x internal subdevice. Of course the other way around is also true, the .link_setup() in adv748x should not care about the links handled by rcar-vin :-) As you discovers this is not possible today and might require some work or maybe even a different design then the one outlined above. > > > What I was about to do, instead, given the fixed HDMI->TXA and AFE->TXB > > routing in the adv748x driver was to insert a .link_validate() callback for > > both the HDMI and AFE backends, that checks for the availability of > > the corresponding output endpoint. This seems to me that this makes > > easy when dynamic routing will be added to do the same on the > > dynamically configured sink pad. > > What do you think? > > On a second thought if a CSI-2 sink it's not enabled it is not part of > the media graph neither, so it should not be possible to link it in any > pipeline, so no link validation is required. The link simply can't > exist. > > It seems to me that to support Ebisu-like designs is then enough to >
Re: [PATCH 1/2] arm64: dts: r8a77965: add FDP1 device nodes
On Fri, Aug 24, 2018 at 11:45:52AM +0300, Laurent Pinchart wrote:
> Hello Nguyen An,
>
> Thank you for the patch.
>
> On Friday, 24 August 2018 07:52:28 EEST Nguyen An Hoan wrote:
> > From: Hoan Nguyen An
>
> You're missing a commit message. I agree that for simple patches like this
> one
> the subject line often contains enough information, but adding a commit
> message is still a good practice that we try to enforce through the kernel.
> For instance, looking at git history for r8a7796, you could use
>
> "The r8a77965 has a single FDP1 instance."
>
> > Signed-off-by: Hoan Nguyen An
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart
>
> Simon, could you update the commit message when taking this patch in your
> tree, to avoid the need for a v2 ?
Yes, can do.
Can I confirm that it is safe, from a regression point of view,
to apply this patch without patch 2/2?
> > ---
> > arch/arm64/boot/dts/renesas/r8a77965.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77965.dtsi index 9c4f405..bef519f 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > @@ -1578,6 +1578,16 @@
> > status = "disabled";
> > };
> >
> > + fdp1@fe94 {
> > + compatible = "renesas,fdp1";
> > + reg = <0 0xfe94 0 0x2400>;
> > + interrupts = ;
> > + clocks = <&cpg CPG_MOD 119>;
> > + power-domains = <&sysc R8A77965_PD_A3VP>;
> > + resets = <&cpg 119>;
> > + renesas,fcp = <&fcpf0>;
> > + };
> > +
> > fcpf0: fcp@fe95 {
> > compatible = "renesas,fcpf";
> > reg = <0 0xfe95 0 0x200>;
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
Re: [PATCH/RFT] arm64: dts: renesas: r8a77965: Add OPPs table for cpu devices
On Fri, Aug 24, 2018 at 10:23:28AM +0200, Simon Horman wrote:
> On Wed, Aug 22, 2018 at 04:41:18PM +0200, Simon Horman wrote:
> > On Tue, Aug 14, 2018 at 11:12:41PM +0900, Yoshihiro Kaneko wrote:
> > > From: Dien Pham
> > >
> > > This patch adds OPPs table for CA57{0,1} cpu devices
> > >
> > > Signed-off-by: Dien Pham
> > > Signed-off-by: Takeshi Kihara
> > > Signed-off-by: Yoshihiro Kaneko
> >
> > Tested on r8a77965/Salvator-XS
> >
> > I see that CPUFreq is activated, that sysfs reports 3 possible
> > CPU speeds; 1.5, 1.0 and 0.50GHz. That current CPU frequency can be
> > manipulated
> > by setting the maximum CPU frequency in sysfs. And that the frequency
> > of Z clock changes accordingly.
> >
> > Tested-by: Simon Horman
>
> I have applied this for v4.20.
I noticed that this patch included unit numbers for the opps nodes.
This is not correct as there is no bus that the nodes live on.
I fixed this using s/@/-/.
The result is below:
>From cd889b86ce3fba300ce82b0ec22bf310cd2f361d Mon Sep 17 00:00:00 2001
From: Dien Pham
Date: Tue, 14 Aug 2018 23:12:41 +0900
Subject: [PATCH] arm64: dts: renesas: r8a77965: Add OPPs table for cpu devices
This patch adds OPPs table for CA57{0,1} cpu devices
Signed-off-by: Dien Pham
Signed-off-by: Takeshi Kihara
Signed-off-by: Yoshihiro Kaneko
Tested-by: Simon Horman
[simon: do not give nodes unit names as they have no bus addresses]
Signed-off-by: Simon Horman
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 44 +++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index e7128fb65e33..5ce978502ee9 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -60,6 +60,46 @@
clock-frequency = <0>;
};
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-5 {
+ opp-hz = /bits/ 64 <5>;
+ opp-microvolt = <83>;
+ clock-latency-ns = <30>;
+ };
+ opp-10 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = <83>;
+ clock-latency-ns = <30>;
+ };
+ opp-15 {
+ opp-hz = /bits/ 64 <15>;
+ opp-microvolt = <83>;
+ clock-latency-ns = <30>;
+ opp-suspend;
+ };
+ opp-16 {
+ opp-hz = /bits/ 64 <16>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+ opp-17 {
+ opp-hz = /bits/ 64 <17>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+ opp-18 {
+ opp-hz = /bits/ 64 <18>;
+ opp-microvolt = <96>;
+ clock-latency-ns = <30>;
+ turbo-mode;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -71,6 +111,8 @@
power-domains = <&sysc R8A77965_PD_CA57_CPU0>;
next-level-cache = <&L2_CA57>;
enable-method = "psci";
+ clocks =<&cpg CPG_CORE R8A77965_CLK_Z>;
+ operating-points-v2 = <&cluster0_opp>;
};
a57_1: cpu@1 {
@@ -80,6 +122,8 @@
power-domains = <&sysc R8A77965_PD_CA57_CPU1>;
next-level-cache = <&L2_CA57>;
enable-method = "psci";
+ clocks =<&cpg CPG_CORE R8A77965_CLK_Z>;
+ operating-points-v2 = <&cluster0_opp>;
};
L2_CA57: cache-controller-0 {
--
2.11.0
Re: [PATCH v2 5/7] arm64: dts: renesas: r8a77965: Add CAN{0,1} placeholder nodes
On Thu, Aug 23, 2018 at 10:52:09AM +0200, Geert Uytterhoeven wrote:
> On Fri, Aug 17, 2018 at 3:53 PM Kieran Bingham
> wrote:
> > On 12/08/18 14:31, Eugeniu Rosca wrote:
> > > According to R-Car Gen3 HW manual rev1.00, R-Car M3-N has two CAN
> > > interfaces, similar to H3, M3-W and other SoCs from the same family.
> > >
> > > Add CAN placeholder nodes to avoid below DTC errors:
> > > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:19.1-6 Label or path can0
> > > not found
> > > Error: arch/arm64/boot/dts/renesas/ulcb-kf.dtsi:25.1-6 Label or path can1
> > > not found
> > >
> > > These errors occur *after* the addition of r8a77965-m3nulcb-kf.dts.
> > > Fix them beforehand.
> > >
> > > CAN support is inspired from below commits:
> > > - v4.7 commit 308b7e4ba62e ("arm64: dts: r8a7795: Add CAN support")
> > > - v4.11 commit 909c16252415 ("arm64: dts: r8a7796: Add CAN support")
> > > - v4.12 commit bec0948e810f ("arm64: dts: r8a7796: Add reset control
> > > properties")
> > >
> > > Signed-off-by: Eugeniu Rosca
> >
> > Reviewed-by: Kieran Bingham
> >
> >
> > > ---
> > > Changes in v2:
> > > - [Kieran Bingham] Improved commit description:
> > >- Referenced the newer HW manual rev1.00 instead of rev0.55E.
> > >- Kept the "true story" behind the patch. Just made it more clear.
> > > - [Geert Uytterhoeven] Replaced CAN0 and CAN1 nodes with placeholders
> > >(no CAN testing was done to validate the DTS configuration).
> > > ---
> > > arch/arm64/boot/dts/renesas/r8a77965.dtsi | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > index 486aecacb22a..4da479d3c226 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > @@ -656,6 +656,22 @@
> > > status = "disabled";
> > > };
> > >
> > > + can0: can@e6c3 {
> > > + compatible = "renesas,can-r8a77965",
> > > + "renesas,rcar-gen3-can";
> > > + reg = <0 0xe6c3 0 0x1000>;
> > > + /* placeholder */
> > > + status = "disabled";
> > > + };
> >
> > This is probably more detail than is needed for a placeholder, but it
> > looks correct so I think this is fine.
>
> Indeed. Adding the "compatible" properties means they're no longer
> placeholders, and will be probed by the driver, possibly leading to
> undefined behavior.
>
> Hence please limit the placeholders to the absolute required minimum,
> and thus drop the "compatible" and "status" properties.
Agreed, I will update the patch accordingly.
Re: [PATCH v2 1/7] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board
On Fri, Aug 17, 2018 at 12:08:24PM +0200, Simon Horman wrote: > On Sun, Aug 12, 2018 at 03:31:43PM +0200, Eugeniu Rosca wrote: > > In harmony with ATF and U-Boot outputs [1] and [2], the new board is > > based on M3-N revision ES1.1 and the amount of memory present on SiP > > is 2GiB, contiguously addressed. > > > > The amount of RAM is mentioned based on the assumption that it is > > encoded in the board id/string. There is some evidence supporting this > > in form of last-digit-mismatch between two R-Car H3 ES2.0 ULCB board > > ids, one with 4GiB and one with 8GiB of RAM (see [3]). > > > > [1] BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.21 > > BL2: PRR is R-Car M3N Ver.1.1 > > > > [2] U-Boot 2015.04-00295-* > > CPU: Renesas Electronics R8A77965 rev 1.1 > > ---8< > > DRAM: 1.9 GiB > > Bank #0: 0x04800 - 0x0bfff, 1.9 GiB > > ---8< > > > > [3] https://patchwork.kernel.org/patch/10555957/#22169325 > > > > Signed-off-by: Eugeniu Rosca > > Thanks, > > This looks fine to me but I will wait to see if there are other reviews > before applying. > > Reviewed-by: Simon Horman Thanks again, applied for v4.20.
Re: [PATCH v4] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
On Thu, Aug 23, 2018 at 07:59:20PM +0300, Sergei Shtylyov wrote: > Define the Condor/V3HSK board dependent parts of the DU and LVDS device > nodes. Also add the device nodes for Thine THC63LVD1024 LVDS decoder and > Analog Devices ADV7511W HDMI transmitter... > > Based on the original (and large) patch by Vladimir Barinov. > > Signed-off-by: Vladimir Barinov > Signed-off-by: Sergei Shtylyov > Reviewed-by: Ulrich Hecht > Reviewed-by: Laurent Pinchart > > --- > The patch is against the 'renesas-devel-20180822-v4.18' tag of Simon Horman's > 'renesas.git' repo. The only driver support still unmerged seems to be the > R8A77980 LVDS support patches... Thanks, applied for v4.20.
Re: [PATCH] arm64: dts: renesas: r8a774a1: Add CAN nodes
On Thu, Aug 23, 2018 at 03:22:46PM +0100, Fabrizio Castro wrote: > From: Chris Paterson > > Add the device nodes for both RZ/G2M CAN channels. > > Signed-off-by: Chris Paterson > Reviewed-by: Biju Das Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Niklas, A few more talk on the adv748x link handling, please bear with me... On Sat, Aug 25, 2018 at 03:18:06PM +0200, jacopo mondi wrote: > Hi Laurent, Niklas, > > On Sat, Aug 25, 2018 at 08:37:15AM +0200, Niklas Söderlund wrote: > > Hi Laurent and Jacopo, > > > > On 2018-08-25 02:54:44 +0300, Laurent Pinchart wrote: > > > Hi Jacopo, > > > > > > On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > > > > Hello renesas list, > > > >this series add supports for the HDMI and CVBS input to R-Car E3 > > > > R8A77990 > > > > Ebisu board. > > > > > > > > It's an RFT, as I don't have an Ebisu to test with :( > > > > > > > > The series adds supports for the following items: > > > > > > > > - PFC: add VIN groups and functions > > > > - R-Car VIN and R-Car CSI-2: add support for R8A77990 > > > > - R8A77990: Add I2C, VIN and CSI-2 nodes > > > > - Ebisu: describe HDMI and CVBS inputs > > > > > > > > Each patch, when relevant reports difference between the upported BSP > > > > patch > > > > and the proposed one. > > > > > > > > I know Laurent should receive an Ebisu sooner or later, maybe we can > > > > sync > > > > for testing :) > > > > > > I've given the series a first test, and I think a bit more work is needed > > > :-) > > > > > > [1.455533] adv748x 0-0070: Endpoint > > > /soc/i2c@e650/video-receiver@70/ > > > port@7/endpoint on port 7 > > > [1.464683] adv748x 0-0070: Endpoint > > > /soc/i2c@e650/video-receiver@70/ > > > port@8/endpoint on port 8 > > > [1.473728] adv748x 0-0070: Endpoint > > > /soc/i2c@e650/video-receiver@70/ > > > port@a/endpoint on port 10 > > > [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 > > > [1.639470] adv748x 0-0070: No endpoint found for txb > > > [1.644653] adv748x 0-0070: Failed to probe TXB > > > > I fear this is a design choice in the adv748x driver. Currently the > > driver requires both of its two CSI-2 transmitters to be connected/used > > else probe fails. Furthermore the HDMI capture is always routed to TXA > > while the analog capture is always routed to TXB. > > > > Now that we have a board where only TXA is connected but both HDMI and > > analog captures are used maybe it's time to do some more work on v4l2 > > and the adv748x driver ;-P What's missing: > > > > - Probe should be OK with either TXA or TXB connected and not bail if > > not both are used. > > I have three patches for this I hope to share as soon as I'll be able > to do some more testing > > > - The media_device_ops or at least the .link_notify() callback of that > > struct must be changed so not one driver in the media graph is > > responsible for all links. In this case rcar-vin provides the callback > > and rcar-vin should not judge which links between the adv748x > > subdevices are OK to enable/disable. Currently the links between the > > adv748x subdevices are immutably enabled to avoid this particular > > problem. > > Uh, I didn't get this :/ Care to elaborate more? > I'm thinking if it is not enough to just provide a .link_setup() callback to the (enabled) csi-2 sink pads of the adv748x and handle routing between the afe/hdmi sources and that sink, without the vin's registered link_notify playing any role in that. > What I was about to do, instead, given the fixed HDMI->TXA and AFE->TXB > routing in the adv748x driver was to insert a .link_validate() callback for > both the HDMI and AFE backends, that checks for the availability of > the corresponding output endpoint. This seems to me that this makes > easy when dynamic routing will be added to do the same on the > dynamically configured sink pad. > What do you think? On a second thought if a CSI-2 sink it's not enabled it is not part of the media graph neither, so it should not be possible to link it in any pipeline, so no link validation is required. The link simply can't exist. It seems to me that to support Ebisu-like designs is then enough to make the adv748x driver probe with a single csi-2 output enabled and handle power management accordingly. I will share patches for this briefly. > > Thanks > j > > > > > > > > > > PS: the list of upported patches will be sent separately. > > > > > > > > Jacopo Mondi (5): > > > > media: dt-bindings: media: rcar-vin: Add R8A77990 support > > > > media: rcar-vin: Add support for R-Car R8A77990 > > > > dt-bindings: media: rcar-csi2: Add R8A77990 > > > > media: rcar-csi2: Add R8A77990 support > > > > arm64: dts: renesas: ebisu: Add HDMI and CVBS input > > > > > > > > Koji Matsuoka (1): > > > > arm64: dts: r8a77990: Add VIN and CSI-2 device nodes > > > > > > > > Takeshi Kihara (2): > > > > pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions > > > > arm64: dts: r8a77990: Add I2C device nodes > > > > > > > > .../devicetree/bindings/media/rcar_vin.txt | 1 + > > > > .../bindings/media/renesas,rcar-csi2.txt | 1 + > > > > arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts |
Re: [PATCH v3 9/9] arm64: dts: renesas: r8a774a1: Add FCPF and FCPV instances
On Fri, Aug 24, 2018 at 11:21:14AM +0100, Fabrizio Castro wrote:
> Add FCPF and FCPV instances to the r8a774a1 dtsi, similarly
> to what was done for the r8a7796 with commit 41dbbf0c5b4e
> ("arm64: dts: r8a7796: Add FCPF and FCPV instances"),
> commit 69490bc9665d ("arm64: dts: renesas: r8a7796: Point
> FDP1 via FCPF to IPMMU-VI0"), and commit cef942d0bd89 ("arm64:
> dts: renesas: r8a7796: Point VSPI via FCPVI to IPMMU-VC0").
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman
Re: [PATCH 8/9] arm64: dts: renesas: r8a774a1: Add audio support
On Thu, Aug 23, 2018 at 02:43:07PM +0100, Fabrizio Castro wrote: > From: Biju Das > > Add sound support for the RZ/G2M SoC (a.k.a. R8A774A1). > > This work is based on similar work done on the R8A7796 SoC > by Kuninori Morimoto . > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 7/9] arm64: dts: renesas: r8a774a1: Add PWM device nodes
On Thu, Aug 23, 2018 at 02:43:06PM +0100, Fabrizio Castro wrote: > This patch adds PWM[0123456] device nodes to the RZ/G2M (a.k.a R8A774A1) > device tree. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 6/9] arm64: dts: renesas: r8a774a1: Add Cortex-A53 CPU cores
On Thu, Aug 23, 2018 at 02:43:05PM +0100, Fabrizio Castro wrote: > From: Biju Das > > This patch adds definitions for L2 cache for the Cortex-A53 CPU > cores (512 KiB in size, organized as 32 KiB x 16 ways), adds > Cortex-A53 CPU cores (setting a total of 6 cores, 2 x Cortex-A57 > + 4 x Cortex-A53), and finally enables the performance monitor > unit for the Cortex-A53 cores on the R8A774A1 SoC. > > Based on work done for r8a7796 SoC. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 5/9] arm64: dts: renesas: r8a774a1: Add all MSIOF nodes
On Thu, Aug 23, 2018 at 02:43:04PM +0100, Fabrizio Castro wrote: > From: Biju Das > > Add the device nodes for all MSIOF SPI controllers on RZ/G2M SoC. > > Based on several similar patches of the R8A7796 device tree > by Geert Uytterhoeven > and Simon Horman . > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 4/9] arm64: dts: renesas: r8a774a1: Add IPMMU device nodes
On Thu, Aug 23, 2018 at 02:43:03PM +0100, Fabrizio Castro wrote: > Add r8a774a1 IPMMU nodes. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 3/9] arm64: dts: renesas: r8a774a1: Add RZ/G2M thermal support
On Thu, Aug 23, 2018 at 02:43:02PM +0100, Fabrizio Castro wrote: > From: Biju Das > > Add thermal support for R8A774A1 (RZ/G2M) SoC. > > Based on the work done for r8a7796 SoC. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 2/9] arm64: dts: renesas: r8a774a1: Add I2C and IIC-DVFS support
On Thu, Aug 23, 2018 at 02:43:01PM +0100, Fabrizio Castro wrote: > From: Biju Das > > Add the I2C[0-6] and IIC Bus Interface for DVFS (IIC for DVFS) > devices nodes to the r8a774a1 device tree. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add SDHI nodes
On Thu, Aug 23, 2018 at 02:43:00PM +0100, Fabrizio Castro wrote: > Add SDHI nodes to the DT of the r8a774a1 SoC. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH] arm64: dts: renesas: r8a774a1: Add GPIO device nodes
On Thu, Aug 23, 2018 at 03:18:18PM +0100, Fabrizio Castro wrote: > Add GPIO device nodes to the DT of the r8a774a1 SoC. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das > --- > > This patch depends on: > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg30549.html Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
Re: [PATCH] arm64: dts: renesas: r8a774a1: Add pinctrl device node
On Thu, Aug 23, 2018 at 03:13:16PM +0100, Fabrizio Castro wrote: > This patch adds pinctrl device node for R8A774A1 SoC. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das > --- > > This patch depends on: > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg30339.html > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg30539.html Thanks, This looks fine to me but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman
