Re: HDMI doesn't work on ULCB board
Hi Laurent > > > I tried to reproduce the problem, starting with drm-next which seems to > > > work > > > fine, moving to renesas-drivers-2018-10-09-v4.19-rc7 which also didn't > > > exhibit any issue. I then used your kernel configuration, and got a > > > WARN_ON > > > \o/ > > > > Investigations revealed that you're missing the CONFIG_COMMON_CLK_VC5=y > > option > > in your kernel configuration. It also revealed a bug in the error handling > > code of the DU driver, for which I have just sent "[PATCH] drm: rcar-du: > > Fix > > external clock error checks". > > Thanks !! > I tried your posted patch, and it solved Oops issue, > and CONFIG_COMMON_CLK_VC5 solved HDMI outputs !! Hmm... I noticed Salvator can't boot if .config has CONFIG_COMMON_CLK_VC5. This means, Salvator and ULCB can't use same binary so far for me (= all modules are =y on .config). I'm using previous attached .config + your patch + CONFIG_COMMON_CLK_VC5 Kernel will stop here on Salvator - rcar-fcp fe9af000.fcp: ignoring dependency for device, assuming no driver rcar-fcp fe9bf000.fcp: ignoring dependency for device, assuming no driver rcar-fcp fea27000.fcp: ignoring dependency for device, assuming no driver rcar-fcp fea2f000.fcp: ignoring dependency for device, assuming no driver rcar-fcp fea37000.fcp: ignoring dependency for device, assuming no driver [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. ** stop here ** Best regards --- Kuninori Morimoto
Re: [PATCH] arm64: renesas: r8a7795: add SSIU support for sound
Hi Simon > > rsnd sound driver will handle SSIU from v4.21 via DT. > > Of course it is keeping compatibility, thus, no SSIU settings > > is no problem. > > > > SSIU handles BUSIFn, but rsnd driver had been assumed only BUSIF0 was used. > > Thus, SSIU / BUSIF0 was attached via SSI automatically, > > but it was not enough for TDM Split mode. > > > > To enable TDM Split mode, we need to select BUSIFn via SSIU. > > This patch adds SSIU DT settings to r8a7795. > > > > If we had SSIU DT settings, existing BUSIF0 settings via SSI > > is no longer needed. We want to remove it. > > To avoid git merge timing issue / git bisect issue, > > I will re-post "remove" patch later (= for v4.22). > > Please consider 1st patch and ignore 2nd patch so far. > > Thanks. I have applied the 1st patch for v4.21. And marked the 2nd patch as > deferred. Please repost or ping me once v4.22-rc1 has been released. Thanks. Yes, will do.
Re: [PATCH 0/4] arm64: renesas: enable ULCB HDMI / ULCB-KF sound
Hi Simon
> > These patches adds sound support for KingFisher.
> > We can enable it on top of v4.20-rc1, but, it is not stable.
> > We need this patch (= from ASoC for-v4.21 branch) to be stable it.
> >
> > 223bc10b84970fd772c105b550beeef3ac3502be
> > ("ASoC: pcm3168a: remove read-only status register from
> > snd_kcontrol_new")
>
> Perhaps it is best to wait for that patch to hit an rc release.
> Do you know when that will happen?
It will be v4.21, not for v4.20.
Best regards
---
Kuninori Morimoto
Re: [PATCH 0/2] pinctrl: sh-pfc: gen2: initialize TDSEL register
Hi Wolfram,
CC Chris Paterson
On Sun, Oct 28, 2018 at 10:25 PM Wolfram Sang
wrote:
> During our SDHI hackathon, we found that Lager was the only Gen2 board
> having issues with a stubborn SD card. The issue went away when setting
> TDSEL to the expected value mentioned in the H2 documentation which is
> sadly not the default value. M2-W, M2-N, and V2H have an expected value
> of 0 for TDSEL, so this is why they likely work out of the box (V2H has
> non-zero drive strength bit, though). I can't verify those SoCs here, no
But the default non-zero drive strength bit does match the required value
on V2H.
> boards. E2 has a non-zero expected value as well, so we fix it in this
> patch series as well (although on my board the bootloader prepares TDSEL
> correctly, but let's not rely on that).
Probably we should program TDSEL regardless, to avoid any dependency on
reset state or boot loader.
Note that all RZ/G1 SoCs requires zero TDSEL values, except for RZ/G1C
(which doesn't document required values, just the initial values).
So we need some soc_device_match() handling to obtain the required value.
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: r8a7794: initialize TDSEL register
On Sun, Oct 28, 2018 at 10:25 PM Wolfram Sang
wrote:
> Documentation says that some bits in TDSEL must be set (ch 5.3.35 in
> R-Car E2 v0.5). However, the reset value of the register is 0, so
> software has to do it. Add this to the kernel driver to ensure this is
> really done independent of firmware versions. This is needed for some SD
> cards supporting SDR104 transfer mode.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] pinctrl: sh-pfc: r8a7790: initialize TDSEL register
On Sun, Oct 28, 2018 at 10:25 PM Wolfram Sang
wrote:
> Documentation says that some bits in TDSEL must be set (ch 5.3.39 in R-Car H2
> v0.91). However, the reset value of the register is 0, so software has to do
> it. Add this to the kernel driver to ensure this is really done independent of
> firmware versions.
>
> This is needed for some SD cards supporting SDR104 transfer mode. For
> me, TDSEL was not initialized by the firmware and I had problems with
> the card when re-inserting it.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 0/3] Add QSPI flash support to iwg23s
Dear All, this series includes all that is necessary to add QSPI flash support to the iwg23s board powered by the RZ/G1C SoC (a.k.a. r8a77470). The second version of this series is to address a comment made by both Simon and Geert on one of the patches. This series applies on top of renesas-devel-20181108v3-v4.20-rc1 Thanks, Fab Fabrizio Castro (3): mtd: spi-nor: Add support for is25lp016d ARM: dts: r8a77470: Add QSPI support ARM: dts: iwg23s-sbc: Add QSPI flash support arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 26 + arch/arm/boot/dts/r8a77470.dtsi | 32 +++ drivers/mtd/spi-nor/spi-nor.c | 2 ++ 3 files changed, 60 insertions(+) -- 2.7.4
[PATCH v2 3/3] ARM: dts: iwg23s-sbc: Add QSPI flash support
This commit adds QSPI flash support to the iwg23s board specific
device tree.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* No Change
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 52f23b8..40b7f98 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -96,6 +96,11 @@
power-source = <1800>;
};
+ qspi0_pins: qspi0 {
+ groups = "qspi0_ctrl", "qspi0_data2";
+ function = "qspi0";
+ };
+
scif1_pins: scif1 {
groups = "scif1_data_b";
function = "scif1";
@@ -114,6 +119,27 @@
};
};
+&qspi0 {
+ pinctrl-0 = <&qspi0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* WARNING - This device contains the bootloader. Handle with care. */
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "issi,is25lp016d", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <13300>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ m25p,fast-read;
+ spi-cpol;
+ spi-cpha;
+ };
+};
+
&rwdt {
timeout-sec = <60>;
status = "okay";
--
2.7.4
[PATCH v2 1/3] mtd: spi-nor: Add support for is25lp016d
The is25lp016d is found on the iwg23s from iWave, therefore
add driver support for it so that we can upstream board support.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* No change
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5..85d869b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1352,6 +1352,8 @@ static const struct flash_info spi_nor_ids[] = {
{ "is25cd512", INFO(0x7f9d20, 0, 32 * 1024, 2, SECT_4K) },
{ "is25lq040b", INFO(0x9d4013, 0, 64 * 1024, 8,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "is25lp016d", INFO(0x9d6015, 0, 64 * 1024, 32,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "is25lp080d", INFO(0x9d6014, 0, 64 * 1024, 16,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "is25lp128", INFO(0x9d6018, 0, 64 * 1024, 256,
--
2.7.4
[PATCH v2 2/3] ARM: dts: r8a77470: Add QSPI support
Add QSPI[01] support to the RZ/G1C SoC specific device tree.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* Removed aliases
arch/arm/boot/dts/r8a77470.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 5c0e48d..f4e232b 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -460,6 +460,38 @@
status = "disabled";
};
+ qspi0: spi@e6b1 {
+ compatible = "renesas,qspi-r8a77470", "renesas,qspi";
+ reg = <0 0xe6b1 0 0x2c>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 918>;
+ dmas = <&dmac0 0x17>, <&dmac0 0x18>,
+ <&dmac1 0x17>, <&dmac1 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = <&cpg 918>;
+ status = "disabled";
+ };
+
+ qspi1: spi@ee20 {
+ compatible = "renesas,qspi-r8a77470", "renesas,qspi";
+ reg = <0 0xee20 0 0x2c>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 917>;
+ dmas = <&dmac0 0xd1>, <&dmac0 0xd2>,
+ <&dmac1 0xd1>, <&dmac1 0xd2>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = <&cpg 917>;
+ status = "disabled";
+ };
+
scif0: serial@e6e6 {
compatible = "renesas,scif-r8a77470",
"renesas,rcar-gen2-scif", "renesas,scif";
--
2.7.4
[PATCH v5 3/6] pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions
Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car E3.
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Use new variadic macro: this time for real as reported by Simon
- s/union vin_data/union vin_data16/ for VIN5 pins and mux as suggested by Geert
- add vin4_data18_[a|b] pins
- fix VIN4_DATA19 pin number in vin4_data_b group
v3 -> v4:
- Use new variadic version of VIN_DATA_PIN_GROUP macro
v2 -> v3:
- Rebased on v4.20-rc1
- Use the newly introduced VIN_DATA_PIN_GROUP_VER macro
Incorporate Geert's comments:
- vin5_data8_b is only used with 8 pins: use regular SH_PFC_PIN_GROUP()
- remove stf groups for vin4/vin5
- confirmed that pins [23-8] of vin4's groups 'a' and 'b' are shared
- confirmed with HW team the synchronism pins in vin5 are only for group 'a'
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 300 +-
1 file changed, 298 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 923261687a75..1a2cf73a84ad 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -2786,8 +2786,240 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const unsigned int vin4_data18_a_pins[] = {
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+};
+
+static const unsigned int vin4_data18_a_mux[] = {
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_data18_b_pins[] = {
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+};
+
+static const unsigned int vin4_data18_b_mux[] = {
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+
[PATCH v5 4/6] pinctrl: sh-pfc: r8a7792: Fix VIN versioned groups
Versioned VIN groups can appear on different sets of pins. Use of the
VIN_DATA_PIN_GROUP macro fix naming of said groups through an optional
'version' argument.
Use the 'version' argument for said macro to fix naming of versioned
groups for R-Car V2H R8A7792 SoC.
Fixes: 7dd74bb1f058 ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
Reviewed-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Broke out r8a7792 from single patch
---
drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
index e977121b433b..a623459b234e 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
@@ -1744,10 +1744,10 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
VIN_DATA_PIN_GROUP(vin1_data, 12),
VIN_DATA_PIN_GROUP(vin1_data, 10),
VIN_DATA_PIN_GROUP(vin1_data, 8),
- VIN_DATA_PIN_GROUP(vin1_data_b, 24),
- VIN_DATA_PIN_GROUP(vin1_data_b, 20),
+ VIN_DATA_PIN_GROUP(vin1_data, 24, _b),
+ VIN_DATA_PIN_GROUP(vin1_data, 20, _b),
SH_PFC_PIN_GROUP(vin1_data18_b),
- VIN_DATA_PIN_GROUP(vin1_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin1_data, 16, _b),
SH_PFC_PIN_GROUP(vin1_sync),
SH_PFC_PIN_GROUP(vin1_field),
SH_PFC_PIN_GROUP(vin1_clkenb),
--
2.7.4
[PATCH v5 5/6] pinctrl: sh-pfc: r8a7795: Fix VIN versioned groups
Versioned VIN groups can appear on different sets of pins. Use of the
VIN_DATA_PIN_GROUP macro fix naming of said groups through an optional
'version' argument.
Use the 'version' argument for said macro to fix naming of versioned
groups for R-Car H3 R8A7795 SoC.
Fixes: 9942a5b52990 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
definitions")
Reviewed-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Broke out r8a7795 from single patch
---
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 0af737d11403..20fac0fde91a 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -4474,20 +4474,20 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(usb2),
SH_PFC_PIN_GROUP(usb2_ch3),
SH_PFC_PIN_GROUP(usb30),
- VIN_DATA_PIN_GROUP(vin4_data_a, 8),
- VIN_DATA_PIN_GROUP(vin4_data_a, 10),
- VIN_DATA_PIN_GROUP(vin4_data_a, 12),
- VIN_DATA_PIN_GROUP(vin4_data_a, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
SH_PFC_PIN_GROUP(vin4_data18_a),
- VIN_DATA_PIN_GROUP(vin4_data_a, 20),
- VIN_DATA_PIN_GROUP(vin4_data_a, 24),
- VIN_DATA_PIN_GROUP(vin4_data_b, 8),
- VIN_DATA_PIN_GROUP(vin4_data_b, 10),
- VIN_DATA_PIN_GROUP(vin4_data_b, 12),
- VIN_DATA_PIN_GROUP(vin4_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
SH_PFC_PIN_GROUP(vin4_data18_b),
- VIN_DATA_PIN_GROUP(vin4_data_b, 20),
- VIN_DATA_PIN_GROUP(vin4_data_b, 24),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
SH_PFC_PIN_GROUP(vin4_sync),
SH_PFC_PIN_GROUP(vin4_field),
SH_PFC_PIN_GROUP(vin4_clkenb),
--
2.7.4
[PATCH v5 0/6] sh-pfc: Variadic VIN_DATA_PIN_GROUP macro + VIN updates
Hi Geert, Simon, this version uses the new variadic macro VIN_DATA_PIN_GROUP as v4 (this for real in [3/6]. Refactoring of users of the macro old version have broken out to single patches, comments on M3-N and E3 VIN PFC groups have been incorporated. Quite a few changes in M3-N and E3 VIN support in PFC, so the single patches changelog is in commit messages. Thanks j Jacopo Mondi (6): pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions pinctrl: sh-pfc: r8a7792: Fix VIN versioned groups pinctrl: sh-pfc: r8a7795: Fix VIN versioned groups pinctrl: sh-pfc: r8a7796: Fix VIN versioned groups drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24 +-- drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 24 +-- drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 270 ++ drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244 ++ drivers/pinctrl/sh-pfc/sh_pfc.h | 15 +- 6 files changed, 549 insertions(+), 34 deletions(-) -- 2.7.4
[PATCH v5 6/6] pinctrl: sh-pfc: r8a7796: Fix VIN versioned groups
Versioned VIN groups can appear on different sets of pins. Using the
VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through
an optional 'version' argument.
Use the 'version' argument for said macro to fix naming of versioned
groups for R-Car M3-W R8A7796 SoC.
Fixes: a5c2949ff7bd ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
definitions")
Reviewed-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Broke out r8a7796 from single patch
---
drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
index 3a6d21d87107..b003abdd1a74 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
@@ -4409,20 +4409,20 @@ static const struct {
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb1),
SH_PFC_PIN_GROUP(usb30),
- VIN_DATA_PIN_GROUP(vin4_data_a, 8),
- VIN_DATA_PIN_GROUP(vin4_data_a, 10),
- VIN_DATA_PIN_GROUP(vin4_data_a, 12),
- VIN_DATA_PIN_GROUP(vin4_data_a, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
SH_PFC_PIN_GROUP(vin4_data18_a),
- VIN_DATA_PIN_GROUP(vin4_data_a, 20),
- VIN_DATA_PIN_GROUP(vin4_data_a, 24),
- VIN_DATA_PIN_GROUP(vin4_data_b, 8),
- VIN_DATA_PIN_GROUP(vin4_data_b, 10),
- VIN_DATA_PIN_GROUP(vin4_data_b, 12),
- VIN_DATA_PIN_GROUP(vin4_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
SH_PFC_PIN_GROUP(vin4_data18_b),
- VIN_DATA_PIN_GROUP(vin4_data_b, 20),
- VIN_DATA_PIN_GROUP(vin4_data_b, 24),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
SH_PFC_PIN_GROUP(vin4_sync),
SH_PFC_PIN_GROUP(vin4_field),
SH_PFC_PIN_GROUP(vin4_clkenb),
--
2.7.4
[PATCH v5 1/6] pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP
VIN data groups may appear on different sets of pins, usually named
"vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support
appending the '_a' or '_b' suffix, leading to the definition of group
names not consistent with the ones defined using the SH_PFC_PIN_GROUP()
macro.
Fix this by making the VIN_DATA_PIN_GROUP macro a variadic one,
which accepts an optional 'version' argument.
Fixes: 423caa52534f ("pinctrl: sh-pfc: r8a779[01]: Move 'union vin_data' to
shared header file")
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Rebased on sh-pfc-for-v4.21
- Add fixes tag
---
drivers/pinctrl/sh-pfc/sh_pfc.h | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 1fc13366869a..4ef485cfe08d 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -55,14 +55,15 @@ struct sh_pfc_pin_group {
/*
* Using union vin_data{,12,16} saves memory occupied by the VIN data pins.
* VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups
- * in this case.
+ * in this case. It accepts an optional 'version' argument used when the
+ * same group can appear on a different set of pins.
*/
-#define VIN_DATA_PIN_GROUP(n, s) \
- { \
- .name = #n#s, \
- .pins = n##_pins.data##s, \
- .mux = n##_mux.data##s, \
- .nr_pins = ARRAY_SIZE(n##_pins.data##s),\
+#define VIN_DATA_PIN_GROUP(n, s, ...) \
+ { \
+ .name = #n#s#__VA_ARGS__, \
+ .pins = n##__VA_ARGS__##_pins.data##s, \
+ .mux = n##__VA_ARGS__##_mux.data##s,\
+ .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s), \
}
union vin_data12 {
--
2.7.4
[PATCH v5 2/6] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
The VIN4 and VIN5 interfaces supports parallel video input.
Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N.
Reviewed-by: Ulrich Hecht
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Add definitions for 10, 12 and 20 pin groups for VIN4 as suggested by Geert
- Add definitions for 10 and 12 pin groups for VIN5 as suggested by Geert
- s/union vin_data/union vin_data16/ for VIN5 pins and mux as suggested by Geert
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 270 ++
1 file changed, 270 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index dfdd982984d4..0159e80d29c3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -3725,6 +3725,216 @@ static const unsigned int usb30_mux[] = {
USB30_PWEN_MARK, USB30_OVC_MARK,
};
+/* - VIN4 ---
*/
+static const unsigned int vin4_data18_a_pins[] = {
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+ RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+};
+
+static const unsigned int vin4_data18_a_mux[] = {
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9),
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+ RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+ RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_data18_b_pins[] = {
+ RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+ RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+};
+
+static const unsigned int vin4_data18_b_mux[] = {
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+ RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+ RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+
RE: [PATCH v2 2/2] irqchip: Add support for Renesas RZ/N1 GPIO interrupt multiplexer
Hello Marc, On 06 November 2018 13:16 Phil Edworthy wrote: > On 31 October 2018 15:39, Phil Edworthy wrote > > On 31 October 2018 15:31, Marc Zyngier wrote: > > > On 31/10/18 15:09, Phil Edworthy wrote: > > > > On 31 October 2018 08:02, Marc Zyngier wote: > > > >> On Tue, 30 Oct 2018 10:44:38 +, Phil Edworthy wrote: > > > >>> > > > >>> On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks > > > >>> each configured to have 32 interrupt outputs, so we have a total > > > >>> of 96 GPIO interrupts. All of these are passed to the GPIO IRQ > > > >>> Muxer, which selects > > > >>> 8 of the GPIO interrupts to pass onto the GIC. The interrupt > > > >>> signals aren't latched, so there is nothing to do in this driver > > > >>> when an interrupt is received, other than tell the corresponding > > > >>> GPIO > > block. > > > > > There are two cases: > > > 1) there is 1:1 mapping between a used input and an output, leaving > > > some input unused > > > 2) there is an n:1 mapping between input and output, and all the > > > input can be used at any given time > > > > > > If what you have is (1), you need to implement an hierarchy. > > > If what you have is (2), you need to implement a chained controller. > > > > > > (1) requires you to revisit this driver, making it a lot more like > > > ti's irq-crossbar > > > (2) requires you to actually do some decoding in the chained handler > > > > > > I believe you're in configuration (1). Am I right? > > Right, it's a 1:1 mapping. The information about which input to be > > used needs to be specified in dt. > > I didn’t think I could implement a hierarchy that didn’t mask the > > interrupts, so I need to go back over that and look again... > > Ok, I have changed the driver to implement a hierarchy, i.e. > call irq_domain_create_hierarchy() in probe, call > irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent() in > the irq_domain_ops.alloc function. I suspect that I went in the wrong direction yet again... After looking at Rob H's email again, I am now of the opinion that this hardware, and the way to handle it, is very similar to PCIe MSI. A cutdown DT looks like this: interrupts = , ; #interrupt-cells = <1>; #address-cells = <0>; interrupt-map-mask = <127>; interrupt-map = /* gpio2a 24, pin 146: ETH Port 1 IRQ */ <88 &gic GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, /* gpio2a 26, pin 148: Touchscreen_IRQ */ <90 &gic GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>; The only issue is that I can't see how to get the first element of each interrupt-map entry in the driver. The driver needs to know that input interrupt hwirq 88 corresponds to GIC_SPI 103, and 90 to GIC_SPI 104. Thanks for your time & patience, Phil
RE: [PATCH 3/5] media: dt-bindings: media: rcar_vin: Add r8a774a1 support
Thank you Simon for getting back to me. Cheers, Fab > Subject: Re: [PATCH 3/5] media: dt-bindings: media: rcar_vin: Add r8a774a1 > support > > On Thu, Nov 08, 2018 at 12:52:30PM +, Fabrizio Castro wrote: > > Dear All, > > > > Who is the best person to take this patch? > > I believe this is for Mauro. Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH 4/5] media: rcar-vin: Enable support for r8a774a1
On Mon, Sep 10, 2018 at 03:31:17PM +0100, Biju Das wrote: > Add the SoC specific information for RZ/G2M(r8a774a1) SoC. > The VIN module of RZ/G2M is similar to R-Car M3-W. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Reviewed-by: Simon Horman
Re: [PATCH 3/5] media: dt-bindings: media: rcar_vin: Add r8a774a1 support
On Mon, Sep 10, 2018 at 03:31:16PM +0100, Biju Das wrote: > Document RZ/G2M (R8A774A1) SoC bindings. > > The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Reviewed-by: Simon Horman
Re: [PATCH 2/5] media: rcar-csi2: Enable support for r8a774a1
On Mon, Sep 10, 2018 at 03:31:15PM +0100, Biju Das wrote: > Add the MIPI CSI-2 driver support for RZ/G2M(r8a774a1) SoC. > The CSI-2 module of RZ/G2M is similar to R-Car M3-W. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Reviewed-by: Simon Horman
RE: [PATCH 3/5] media: dt-bindings: media: rcar_vin: Add r8a774a1 support
Hello Mauro, Does this patch look ok to you? Thanks, Fab > From: linux-renesas-soc-ow...@vger.kernel.org > On Behalf Of Biju Das > Sent: 10 September 2018 15:31 > Subject: [PATCH 3/5] media: dt-bindings: media: rcar_vin: Add r8a774a1 support > > Document RZ/G2M (R8A774A1) SoC bindings. > > The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > b/Documentation/devicetree/bindings/media/rcar_vin.txt > index 2f42005..8c81689 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -12,6 +12,7 @@ on Gen3 platforms to a CSI-2 receiver. > - compatible: Must be one or more of the following > - "renesas,vin-r8a7743" for the R8A7743 device > - "renesas,vin-r8a7745" for the R8A7745 device > + - "renesas,vin-r8a774a1" for the R8A774A1 device > - "renesas,vin-r8a7778" for the R8A7778 device > - "renesas,vin-r8a7779" for the R8A7779 device > - "renesas,vin-r8a7790" for the R8A7790 device > @@ -58,9 +59,9 @@ The per-board settings Gen2 platforms: > - data-enable-active: polarity of CLKENB signal, see [1] for >description. Default is active high. > > -The per-board settings Gen3 platforms: > +The per-board settings Gen3 and RZ/G2 platforms: > > -Gen3 platforms can support both a single connected parallel input source > +Gen3 and RZ/G2 platforms can support both a single connected parallel input > source > from external SoC pins (port@0) and/or multiple parallel input sources > from local SoC CSI-2 receivers (port@1) depending on SoC. > > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 2/5] media: rcar-csi2: Enable support for r8a774a1
Thank you Simon for getting back to me. Cheers, Fab > Subject: Re: [PATCH 2/5] media: rcar-csi2: Enable support for r8a774a1 > > On Thu, Nov 08, 2018 at 12:51:29PM +, Fabrizio Castro wrote: > > Dear All, > > > > Who is the best person to take this patch? > > I believe this is for Mauro. Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 2/5] media: rcar-csi2: Enable support for r8a774a1
Hello Mauro,
Does this patch look ok to you?
Thanks,
Fab
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Biju Das
> Sent: 10 September 2018 15:31
> Subject: [PATCH 2/5] media: rcar-csi2: Enable support for r8a774a1
>
> Add the MIPI CSI-2 driver support for RZ/G2M(r8a774a1) SoC.
> The CSI-2 module of RZ/G2M is similar to R-Car M3-W.
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index daef72d..65c7efb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -953,6 +953,10 @@ static const struct rcar_csi2_info
> rcar_csi2_info_r8a77970 = {
>
> static const struct of_device_id rcar_csi2_of_table[] = {
> {
> +.compatible = "renesas,r8a774a1-csi2",
> +.data = &rcar_csi2_info_r8a7796,
> +},
> +{
> .compatible = "renesas,r8a7795-csi2",
> .data = &rcar_csi2_info_r8a7795,
> },
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH 3/5] media: dt-bindings: media: rcar_vin: Add r8a774a1 support
On Thu, Nov 08, 2018 at 12:52:30PM +, Fabrizio Castro wrote: > Dear All, > > Who is the best person to take this patch? I believe this is for Mauro.
RE: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
Thank you Simon for getting back to me. Cheers, Fab > Subject: Re: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 > support > > On Thu, Nov 08, 2018 at 12:50:22PM +, Fabrizio Castro wrote: > > Dear All, > > > > Who is the best person to take this patch? > > I believe this patch is for Mauro. Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
Hello Mauro, Does this patch look ok to you? Thanks, Fab > From: Biju Das > Sent: 10 September 2018 15:31 > Subject: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 > support > > Document RZ/G2M (R8A774A1) SoC bindings. > > The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > --- > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > index 2d385b6..12fe685 100644 > --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > @@ -2,12 +2,13 @@ Renesas R-Car MIPI CSI-2 > > > The R-Car CSI-2 receiver device provides MIPI CSI-2 capabilities for the > -Renesas R-Car family of devices. It is used in conjunction with the > -R-Car VIN module, which provides the video capture capabilities. > +Renesas R-Car Gen3 and RZ/G2 family of devices. It is used in conjunction > +with the R-Car VIN module, which provides the video capture capabilities. > > Mandatory properties > > - compatible: Must be one or more of the following > + - "renesas,r8a774a1-csi2" for the R8A774A1 device. > - "renesas,r8a7795-csi2" for the R8A7795 device. > - "renesas,r8a7796-csi2" for the R8A7796 device. > - "renesas,r8a77965-csi2" for the R8A77965 device. > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
Thank you Simon for getting back to me. > From: Simon Horman > Sent: 08 November 2018 13:21 > Subject: Re: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for > r8a774a1 > > On Thu, Nov 08, 2018 at 12:48:46PM +, Fabrizio Castro wrote: > > Dear All, > > > > Who is the best person to take this patch? > > I believe this one is for Vinod. Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
Hello Vinod, Do you think you can take this patch? Thanks, Fab > From: Fabrizio Castro > Sent: 24 August 2018 08:56 > Subject: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for > r8a774a1 > > From: Biju Das > > This patch adds binding for r8a774a1 (RZ/G2M). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > --- > Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > index 482e543..417ca90 100644 > --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > @@ -5,6 +5,7 @@ Required Properties: > Examples with soctypes are: >- "renesas,r8a7743-usb-dmac" (RZ/G1M) >- "renesas,r8a7745-usb-dmac" (RZ/G1E) > + - "renesas,r8a774a1-usb-dmac" (RZ/G2M) >- "renesas,r8a7790-usb-dmac" (R-Car H2) >- "renesas,r8a7791-usb-dmac" (R-Car M2-W) >- "renesas,r8a7793-usb-dmac" (R-Car M2-N) > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH 2/5] media: rcar-csi2: Enable support for r8a774a1
On Thu, Nov 08, 2018 at 12:51:29PM +, Fabrizio Castro wrote: > Dear All, > > Who is the best person to take this patch? I believe this is for Mauro.
Re: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
On Thu, Nov 08, 2018 at 02:03:33PM +, Fabrizio Castro wrote: > Joerg, does this patch look ok to you? Applied both patches, thanks Fabrizio.
Re: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
On Mon, Sep 10, 2018 at 03:31:14PM +0100, Biju Das wrote: > Document RZ/G2M (R8A774A1) SoC bindings. > > The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Reviewed-by: Simon Horman
Re: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
On Thu, Nov 08, 2018 at 12:50:22PM +, Fabrizio Castro wrote: > Dear All, > > Who is the best person to take this patch? I believe this patch is for Mauro.
RE: [PATCH v2 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support
Thank you Simon for getting back to me. Marc, does this patch look ok to you? Thanks, Fab > Subject: Re: [PATCH v2 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support > > On Thu, Nov 08, 2018 at 11:25:23AM +, Fabrizio Castro wrote: > > Dear All, > > > > Who is the best person to take this patch? > > I believe this one is for Marc. > > > Thanks, > > Fab > > > > > From: Fabrizio Castro > > > Sent: 10 September 2018 11:43 > > > Subject: [PATCH v2 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support > > > > > > Document RZ/G2M (r8a774a1) SoC specific bindings. > > > > > > Signed-off-by: Fabrizio Castro > > > Signed-off-by: Chris Paterson > > > Reviewed-by: Biju Das > > > --- > > > v1->v2: > > > * dropped "renesas,rzg-gen2-can" and fixed "clocks" property description > > > as per Geert's comments. > > > > > > This patch applies on top of next-20180910. > > > > > > Documentation/devicetree/bindings/net/can/rcar_can.txt | 18 > > > +- > > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt > b/Documentation/devicetree/bindings/net/can/rcar_can.txt > > > index 94a7f33..f3b160c 100644 > > > --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt > > > +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt > > > @@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings > > > Required properties: > > > - compatible: "renesas,can-r8a7743" if CAN controller is a part of > > > R8A7743 SoC. > > >"renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. > > > + "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC. > > >"renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. > > >"renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. > > >"renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. > > > @@ -16,15 +17,21 @@ Required properties: > > >"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. > > >"renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 > > >compatible device. > > > - "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device. > > > + "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2 > > > + compatible device. > > >When compatible with the generic version, nodes must list the > > >SoC-specific version corresponding to the platform first > > >followed by the generic version. > > > > > > - reg: physical base address and size of the R-Car CAN register map. > > > - interrupts: interrupt specifier for the sole interrupt. > > > -- clocks: phandles and clock specifiers for 3 CAN clock inputs. > > > -- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk". > > > +- clocks: phandles and clock specifiers for 2 CAN clock inputs for RZ/G2 > > > + devices. > > > + phandles and clock specifiers for 3 CAN clock inputs for every other > > > + SoC. > > > +- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk". > > > + 3 clock input name strings for every other SoC: "clkp1", "clkp2", > > > + "can_clk". > > > - pinctrl-0: pin control group to be used for this controller. > > > - pinctrl-names: must be "default". > > > > > > @@ -41,8 +48,9 @@ using the below properties: > > > Optional properties: > > > - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values > > > are: > > > <0x0> (default) : Peripheral clock (clkp1) > > > -<0x1> : Peripheral clock (clkp2) > > > -<0x3> : Externally input clock > > > +<0x1> : Peripheral clock (clkp2) (not supported by > > > +RZ/G2 devices) > > > +<0x3> : External input clock > > > > > > Example > > > --- > > > -- > > > 2.7.4 > > > > > > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > > Buckinghamshire, SL8 5FH, UK. Registered in England > & Wales under Registered No. 04586709. > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
Thank you Simon for getting back to me. Joerg, does this patch look ok to you? Thanks, Fab > Subject: Re: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support > > On Thu, Nov 08, 2018 at 11:23:58AM +, Fabrizio Castro wrote: > > Dear All, > > > > Who is the best person to take this patch? > > I believe this one is also for Joerg. > > > Thanks, > > Fab > > > > > From: Fabrizio Castro > > > Sent: 17 August 2018 15:31 > > > Subject: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support > > > > > > Document RZ/G2M (R8A774A1) SoC bindings. > > > > > > Signed-off-by: Fabrizio Castro > > > Reviewed-by: Biju Das > > > --- > > > This patch applies on top of next-20180817 > > > > > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > > b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > > index ffadb7c..68446dd 100644 > > > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > > @@ -13,6 +13,7 @@ Required Properties: > > > - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU. > > > - "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU. > > > - "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU. > > > +- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU. > > > - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU. > > > - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU. > > > - "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU. > > > -- > > > 2.7.4 > > > > > > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > > Buckinghamshire, SL8 5FH, UK. Registered in England > & Wales under Registered No. 04586709. > > 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 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
Thank you Simon for getting back to me.
Joerg, does this patch look ok to you?
Thanks,
Fab
> Subject: Re: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
>
> Hi Fabrizio,
>
> I believe this one is for Joerg.
>
> On Thu, Nov 08, 2018 at 11:22:55AM +, Fabrizio Castro wrote:
> > Dear All,
> >
> > Who is the best person to take this patch?
> >
> > Thanks,
> > Fab
> >
> > > From: Fabrizio Castro
> > > Sent: 23 August 2018 16:33
> > > Subject: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
> > >
> > > Add support for RZ/G2M (R8A774A1) SoC IPMMUs.
> > >
> > > Signed-off-by: Fabrizio Castro
> > > Reviewed-by: Biju Das
> > > ---
> > > v1-v2:
> > > * taken out IOMMU_OF_DECLARE
> > >
> > > drivers/iommu/ipmmu-vmsa.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> > > index 51af2c5..331562f 100644
> > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > > @@ -761,6 +761,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> > > }
> > >
> > > static const struct soc_device_attribute soc_rcar_gen3[] = {
> > > +{ .soc_id = "r8a774a1", },
> > > { .soc_id = "r8a7795", },
> > > { .soc_id = "r8a7796", },
> > > { .soc_id = "r8a77965", },
> > > @@ -942,6 +943,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> > > .compatible = "renesas,ipmmu-vmsa",
> > > .data = &ipmmu_features_default,
> > > }, {
> > > +.compatible = "renesas,ipmmu-r8a774a1",
> > > +.data = &ipmmu_features_rcar_gen3,
> > > +}, {
> > > .compatible = "renesas,ipmmu-r8a7795",
> > > .data = &ipmmu_features_rcar_gen3,
> > > }, {
> > > --
> > > 2.7.4
> >
> >
> >
> >
> > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
> > Buckinghamshire, SL8 5FH, UK. Registered in England
> & Wales under Registered No. 04586709.
> >
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings
Thank you Simon for getting back to me. Vinod, does this patch look ok to you? Thanks, Fab > Subject: Re: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings > > Hi Fabrizio, > > I believe this one is for Vinod. > > On Thu, Nov 08, 2018 at 11:03:53AM +, Fabrizio Castro wrote: > > Dear All, > > > > Who is the best person to take this patch? > > > > Thanks, > > Fab > > > > > From: Fabrizio Castro > > > Sent: 14 August 2018 13:32 > > > Subject: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings > > > > > > Renesas' RZ/G2M (R8A774A1) SoC has DMA controllers compatible > > > with this driver, therefore document RZ/G2M specific bindings. > > > > > > Signed-off-by: Fabrizio Castro > > > Reviewed-by: Biju Das > > > --- > > > Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > > > b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > > > index 946229c..2de2eed 100644 > > > --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > > > @@ -1,6 +1,6 @@ > > > * Renesas R-Car (RZ/G) DMA Controller Device Tree bindings > > > > > > -Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA > > > +Renesas R-Car (Gen 2/3) and RZ/G SoCs have multiple multi-channel DMA > > > controller instances named DMAC capable of serving multiple clients. > > > Channels > > > can be dedicated to specific clients or shared between a large number of > > > clients. > > > @@ -19,6 +19,7 @@ Required Properties: > > > - "renesas,dmac-r8a7743" (RZ/G1M) > > > - "renesas,dmac-r8a7745" (RZ/G1E) > > > - "renesas,dmac-r8a77470" (RZ/G1C) > > > +- "renesas,dmac-r8a774a1" (RZ/G2M) > > > - "renesas,dmac-r8a7790" (R-Car H2) > > > - "renesas,dmac-r8a7791" (R-Car M2-W) > > > - "renesas,dmac-r8a7792" (R-Car V2H) > > > -- > > > 2.7.4 > > > > > > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > > Buckinghamshire, SL8 5FH, UK. Registered in England > & Wales under Registered No. 04586709. > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH 3/4] arm64: renesas: ulcb-kf: add pcm3168 sound codec
Hi Morimoto-san
with the TDM Split patch-set you sent earlier in community,
together with this DTS change set,
I am able to test TDM Split mode,
just some minor findings.
On 2018/11/08 10:59, Kuninori Morimoto wrote:
From: Kuninori Morimoto
KingFisher has pcm3168 sound codec. This patch enables it.
Because pcm3168 can't handle symmetric channel on playback/
capture, we need to handle it as different DAI.
Signed-off-by: Kuninori Morimoto
---
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 151 +++
1 file changed, 151 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
index 1b316d79..fdd625d 100644
--- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
@@ -6,11 +6,50 @@
* Copyright (C) 2017 Cogent Embedded, Inc.
*/
+/*
+ * SSI-PCM3168A
+ * aplay -D plughw:0,2 xxx.wav
+ * arecord -D plughw:0,3 xxx.wav
+ */
+
/ {
aliases {
serial1 = &hscif0;
serial2 = &scif1;
};
+
+ clk8snd: clk8snd {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
This is the same clock as cs2000, why not directly refer to &cs2000 from
clksndsel,
otherwise, if snd_soc_rcar is loaded after snd_soc_pcm3168a_i2c,
load of snd_soc_pcm3168a_i2c fails with
"[ 8.412356] pcm3168a 15-0044: Failed to reset device: -6"
and sound cards can not be created
Thanks,
Jiada
+
+ clksnd: clksnd {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <22579200>;
+ };
+
+ clksndsel: clksndsel {
+ #clock-cells = <0>;
+ compatible = "gpio-mux-clock";
+ clocks = <&clk8snd>, <&clksnd>;
+ select-gpios = <&gpio_exp_75 13 GPIO_ACTIVE_HIGH>;
+ };
+
+ snd_3p3v: regulator-snd_3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "snd-3.3v";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ snd_vcc5v: regulator-snd_vcc5v {
+ compatible = "regulator-fixed";
+ regulator-name = "snd-vcc5v";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
};
&can0 {
@@ -44,6 +83,7 @@
};
&i2c2 {
+ /* U11 */
gpio_exp_74: gpio@74 {
compatible = "ti,tca9539";
reg = <0x74>;
@@ -53,6 +93,13 @@
interrupt-parent = <&gpio6>;
interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
+ audio_out_off {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_HIGH>; /* P00 */
+ output-high;
+ line-name = "Audio_Out_OFF";
+ };
+
hub_pwen {
gpio-hog;
gpios = <6 GPIO_ACTIVE_HIGH>;
@@ -80,8 +127,16 @@
output-high;
line-name = "OTG EXTLPn";
};
+
+ snd_rst {
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_HIGH>; /* P17 */
+ output-high;
+ line-name = "SND_RST";
+ };
};
+ /* U5 */
gpio_exp_75: gpio@75 {
compatible = "ti,tca9539";
reg = <0x75>;
@@ -98,6 +153,49 @@
#size-cells = <0>;
reg = <0x71>;
reset-gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
+
+ /* Audio_SDA, Audio_SCL */
+ i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ pcm3168a: audio-codec@44 {
+ #sound-dai-cells = <0>;
+ compatible = "ti,pcm3168a";
+ reg = <0x44>;
+ clocks = <&clksndsel>;
+ clock-names = "scki";
+
+ VDD1-supply = <&snd_3p3v>;
+ VDD2-supply = <&snd_3p3v>;
+ VCCAD1-supply = <&snd_vcc5v>;
+ VCCAD2-supply = <&snd_vcc5v>;
+ VCCDA1-supply = <&snd_vcc5v>;
+ VCCDA2-supply = <&snd_vcc5v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ pcm3168a_endpoint_p: endpoint {
+
Re: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
On Fri, Aug 24, 2018 at 08:56:13AM +0100, Fabrizio Castro wrote: > From: Biju Das > > This patch adds binding for r8a774a1 (RZ/G2M). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Reviewed-by: Simon Horman
Re: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
On Thu, Nov 08, 2018 at 12:48:46PM +, Fabrizio Castro wrote: > Dear All, > > Who is the best person to take this patch? I believe this one is for Vinod.
Re: [PATCH v2 1/3][can-next] can: rcar_can: Fix erroneous registration
On Thu, Nov 08, 2018 at 12:39:00PM +, Fabrizio Castro wrote: > Dear All, > > Is this patch ok? It looks ok to me. Reviewed-by: Simon Horman
Re: [PATCH/RFT] arm64: dts: renesas: r8a77990: Add I2C-DVFS device node
On Thu, Nov 08, 2018 at 01:25:45PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, Nov 8, 2018 at 12:52 PM Simon Horman wrote:
> > On Thu, Nov 08, 2018 at 11:27:31AM +0100, Geert Uytterhoeven wrote:
> > > On Thu, Nov 8, 2018 at 11:22 AM Simon Horman wrote:
> > > > On Wed, Nov 07, 2018 at 01:30:10PM +0100, Simon Horman wrote:
> > > > > On Mon, Nov 05, 2018 at 09:52:48AM +0100, Geert Uytterhoeven wrote:
> > > > > > On Sat, Oct 20, 2018 at 11:35 PM Yoshihiro Kaneko
> > > > > > wrote:
> > > > > > > From: Takeshi Kihara
> > > > > > >
> > > > > > > This patch adds I2C-DVFS device node for the R8A77990 SoC.
> > > > > > >
> > > > > > > Signed-off-by: Takeshi Kihara
> > > > > > > Signed-off-by: Yoshihiro Kaneko
> > > > > >
> > > > > > Thanks for your patch!
> > > > > >
> > > > > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > >
> > > > > > > };
> > > > > > >
> > > > > > > cpus {
> > > > > > > @@ -337,6 +338,22 @@
> > > > > > > reg = <0 0xe606 0 0x508>;
> > > > > > > };
> > > > > > >
> > > > > > > + i2c_dvfs: i2c@e60b {
> > > > > > > + #address-cells = <1>;
> > > > > > > + #size-cells = <0>;
> > > > > > > + compatible = "renesas,iic-r8a77990",
> > > > > >
> > > > > > "renesas,iic-r8a77990" is not yet documented.
> > > > >
> > > > > Thanks, as per my comment below I wonder if as well as documenting
> > > > > "renesas,iic-r8a77990" we also to teach the driver about it.
> > > > >
> > > > > >
> > > > > > > +"renesas,rcar-gen3-iic",
> > > > > > > +"renesas,rmobile-iic";
> > > > > >
> > > > > > Also, IIC on R-Car E3 does not have the automatic transmission
> > > > > > registers.
> > > > > > Does this affect claiming compatibility with the family-specific or
> > > > > > generic
> > > > > > compatible values?
> > > > >
> > > > > My cursory reading of the driver indicates that only register that is
> > > > > used by it but documented as not existing on E3 is ICSTART (offset
> > > > > 0x70).
> > > > >
> > > > > It seems to me that we should confirm with Renesas that the register
> > > > > does
> > > > > indeed not exist - as this patch comes from the BSP which implies it
> > > > > is
> > > > > being used there. And if it does not exist we should try teaching the
> > > > > driver not to use ICSTART via the "renesas,iic-r8a77990" compat
> > > > > string.
> > > > > What do you think?
> > > >
> > > > Further examination by Wolfram Sang has shown that the code in question
> > > > is
> > > > only used on the r8a7740. I don't think there is any compatibility issue
> > > > for r8a77990 when using the current driver.
> > >
> > > "When using the current driver".
> > > Do we want to claim compatibility with "renesas,rcar-gen3-iic" and/or
> > > "renesas,rmobile-iic"?
> >
> > Thinking a bit more since I wrote my previous email.
> >
> > It seems that the r8a77990 has a different feature set to other R-Car Gen3
> > SoCs but that the current driver implementation "renesas,rcar-gen3-iic"
> > and "renesas,rmobile-iic" do not exceed that feature set.
> >
> > In future we could expand the features supported by the driver for other
> > Gen3 SoCs beyond what is supported for r8a77990. If we chose to describe
> > r8a77990 as compatible with renesas,rcar-gen3-iic then that implies those
> > new features would not be activated by matching on "renesas,rcar-gen3-iic",
> > though we could choose to control that using soc_match. Conversely if we
> > decide that r8a77990 is not compatible with renesas,rcar-gen3-iic then we
> > have more freedom to move with regards to adding features not supported by
> > r8a77990 to renesas,rcar-gen3-iic in future.
> >
> > So perhaps it would be wise to be conservative and, for now,
> > not document r8a77990 as being compatible with renesas,iic-r8a77990.
> >
> > I'm tempted to say that renesas,rmobile-iic is a lowest common denominator
> > and r8a77990 can be documented as being compatible with it. But we could
> > say the same of renesas,rcar-gen3-iic.
> >
> > What do you think?
>
> That matches my thoughts.
>
> Given R-Mobile A1 does have the register, I think r8a77990 should not claim
> compatibility with it.
Right, but the ICSTART register is only used on R-Mobile A1
(r8a7740) via the "renesas,iic-r8a7740" compat string. Never, in my reading
of the driver, via more generic compat strings.
Also, fwiw, the function the ICSTART register is called
sh_mobile_i2c_r8a7740_workaround. Note the use of workaround.
> Of course all this assumes there's no bug in the datasheet w.r.t. r8a77990...
The safest approach would be not to declare r8a77990 as being compatible
with the more generic compat strings. We can reverse that decision in
future. The converse is not, strictly speaking, true.
Re: [PATCH] pinctrl: sh-pfc: r8a77970: add QSPI pins, groups, and functions
On Tue, Nov 6, 2018 at 7:53 PM Sergei Shtylyov
wrote:
> From: Dmitry Shifrin
>
> Add the QSPI{0|1} pins/groups/functions to the R8A77970 PFC driver.
>
> [Sergei: ported to the upstream driver, fixed up the swapped QSPI0 SPCLK/
> SSL pins, fixed up the comments, moved the QSPI pins/groups/functions to
> be in the alphanumeric order, removed unneeded empty lines, renamed the
> patch.]
>
> Signed-off-by: Dmitry Shifrin
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.21.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins
On Thu, Nov 08, 2018 at 01:01:08PM +0100, Geert Uytterhoeven wrote: > On Mon, Nov 5, 2018 at 10:39 PM Marek Vasut wrote: > > Subject: [PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins > > arm64: dts: renesas: r8a77990: ebisu: Add serial console pins Thanks, fixed.
Re: [PATCH] [trivial] mfd: tmio: Typo s/use use/use/
On Wed, 07 Nov 2018, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > include/linux/mfd/tmio.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes
On Thu, Nov 08, 2018 at 01:00:11PM +0100, Geert Uytterhoeven wrote: > On Tue, Nov 6, 2018 at 9:46 PM Marek Vasut wrote: > > Subject: [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device > > nodes > > arm64: dts: renesas: r8a77990: ebisu: Add and enable SDHI device nodes Thanks, fixed.
Re: [PATCH 2/2] pinctrl: sh-pfc: r8a77990: Add voltage switch operations for SDHI
On Mon, Nov 5, 2018 at 10:40 PM Marek Vasut wrote:
> From: Takeshi Kihara
>
> This patch supports the {get,set}_io_voltage operations of SDHI.
>
> This operates the IOCTRL30 register on the R8A77990 SoC and makes
> 1.8V/3.3V signal voltage switch possible.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.21.
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] pinctrl: sh-pfc: r8a77990: Add SDHI pins, groups and functions
On Mon, Nov 5, 2018 at 10:40 PM Marek Vasut wrote:
> From: Takeshi Kihara
>
> This patch adds SDHI{0,1,3} pins, groups and functions to the R8A77990
> SoC.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Marek Vasut
Reviewed-by: Geert Uytterhoeven
i.e. will queue in sh-pfc-for-v4.21.
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 4/5] media: rcar-vin: Enable support for r8a774a1
Dear All,
Who is the best person to take this patch?
Cheers,
Fab
> From: Biju Das
> Sent: 10 September 2018 15:31
> Subject: [PATCH 4/5] media: rcar-vin: Enable support for r8a774a1
>
> Add the SoC specific information for RZ/G2M(r8a774a1) SoC.
> The VIN module of RZ/G2M is similar to R-Car M3-W.
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index d3072e1..c0c84d1 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -995,6 +995,10 @@ static const struct rvin_info rcar_info_r8a77970 = {
>
> static const struct of_device_id rvin_of_id_table[] = {
> {
> +.compatible = "renesas,vin-r8a774a1",
> +.data = &rcar_info_r8a7796,
> +},
> +{
> .compatible = "renesas,vin-r8a7778",
> .data = &rcar_info_m1,
> },
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 3/5] media: dt-bindings: media: rcar_vin: Add r8a774a1 support
Dear All, Who is the best person to take this patch? Thanks, Fab > From: linux-renesas-soc-ow...@vger.kernel.org > On Behalf Of Biju Das > Sent: 10 September 2018 15:31 > Subject: [PATCH 3/5] media: dt-bindings: media: rcar_vin: Add r8a774a1 support > > Document RZ/G2M (R8A774A1) SoC bindings. > > The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > b/Documentation/devicetree/bindings/media/rcar_vin.txt > index 2f42005..8c81689 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -12,6 +12,7 @@ on Gen3 platforms to a CSI-2 receiver. > - compatible: Must be one or more of the following > - "renesas,vin-r8a7743" for the R8A7743 device > - "renesas,vin-r8a7745" for the R8A7745 device > + - "renesas,vin-r8a774a1" for the R8A774A1 device > - "renesas,vin-r8a7778" for the R8A7778 device > - "renesas,vin-r8a7779" for the R8A7779 device > - "renesas,vin-r8a7790" for the R8A7790 device > @@ -58,9 +59,9 @@ The per-board settings Gen2 platforms: > - data-enable-active: polarity of CLKENB signal, see [1] for >description. Default is active high. > > -The per-board settings Gen3 platforms: > +The per-board settings Gen3 and RZ/G2 platforms: > > -Gen3 platforms can support both a single connected parallel input source > +Gen3 and RZ/G2 platforms can support both a single connected parallel input > source > from external SoC pins (port@0) and/or multiple parallel input sources > from local SoC CSI-2 receivers (port@1) depending on SoC. > > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 2/5] media: rcar-csi2: Enable support for r8a774a1
Dear All,
Who is the best person to take this patch?
Thanks,
Fab
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Biju Das
> Sent: 10 September 2018 15:31
> Subject: [PATCH 2/5] media: rcar-csi2: Enable support for r8a774a1
>
> Add the MIPI CSI-2 driver support for RZ/G2M(r8a774a1) SoC.
> The CSI-2 module of RZ/G2M is similar to R-Car M3-W.
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index daef72d..65c7efb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -953,6 +953,10 @@ static const struct rcar_csi2_info
> rcar_csi2_info_r8a77970 = {
>
> static const struct of_device_id rcar_csi2_of_table[] = {
> {
> +.compatible = "renesas,r8a774a1-csi2",
> +.data = &rcar_csi2_info_r8a7796,
> +},
> +{
> .compatible = "renesas,r8a7795-csi2",
> .data = &rcar_csi2_info_r8a7795,
> },
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 support
Dear All, Who is the best person to take this patch? Thanks, Fab > From: Biju Das > Sent: 10 September 2018 15:31 > Subject: [PATCH 1/5] media: dt-bindings: media: rcar-csi2: Add r8a774a1 > support > > Document RZ/G2M (R8A774A1) SoC bindings. > > The RZ/G2M SoC is similar to R-Car M3-W (R8A7796). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > --- > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > index 2d385b6..12fe685 100644 > --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > @@ -2,12 +2,13 @@ Renesas R-Car MIPI CSI-2 > > > The R-Car CSI-2 receiver device provides MIPI CSI-2 capabilities for the > -Renesas R-Car family of devices. It is used in conjunction with the > -R-Car VIN module, which provides the video capture capabilities. > +Renesas R-Car Gen3 and RZ/G2 family of devices. It is used in conjunction > +with the R-Car VIN module, which provides the video capture capabilities. > > Mandatory properties > > - compatible: Must be one or more of the following > + - "renesas,r8a774a1-csi2" for the R8A774A1 device. > - "renesas,r8a7795-csi2" for the R8A7795 device. > - "renesas,r8a7796-csi2" for the R8A7796 device. > - "renesas,r8a77965-csi2" for the R8A77965 device. > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
Dear All, Who is the best person to take this patch? Thanks, Fab > From: Fabrizio Castro > Sent: 24 August 2018 08:56 > Subject: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for > r8a774a1 > > From: Biju Das > > This patch adds binding for r8a774a1 (RZ/G2M). > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > --- > Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > index 482e543..417ca90 100644 > --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > @@ -5,6 +5,7 @@ Required Properties: > Examples with soctypes are: >- "renesas,r8a7743-usb-dmac" (RZ/G1M) >- "renesas,r8a7745-usb-dmac" (RZ/G1E) > + - "renesas,r8a774a1-usb-dmac" (RZ/G2M) >- "renesas,r8a7790-usb-dmac" (R-Car H2) >- "renesas,r8a7791-usb-dmac" (R-Car M2-W) >- "renesas,r8a7793-usb-dmac" (R-Car M2-N) > -- > 2.7.4 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 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support
On Thu, Nov 08, 2018 at 11:25:23AM +, Fabrizio Castro wrote: > Dear All, > > Who is the best person to take this patch? I believe this one is for Marc. > Thanks, > Fab > > > From: Fabrizio Castro > > Sent: 10 September 2018 11:43 > > Subject: [PATCH v2 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support > > > > Document RZ/G2M (r8a774a1) SoC specific bindings. > > > > Signed-off-by: Fabrizio Castro > > Signed-off-by: Chris Paterson > > Reviewed-by: Biju Das > > --- > > v1->v2: > > * dropped "renesas,rzg-gen2-can" and fixed "clocks" property description > > as per Geert's comments. > > > > This patch applies on top of next-20180910. > > > > Documentation/devicetree/bindings/net/can/rcar_can.txt | 18 > > +- > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt > > b/Documentation/devicetree/bindings/net/can/rcar_can.txt > > index 94a7f33..f3b160c 100644 > > --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt > > +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt > > @@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings > > Required properties: > > - compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 > > SoC. > >"renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. > > + "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC. > >"renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. > >"renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. > >"renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. > > @@ -16,15 +17,21 @@ Required properties: > >"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. > >"renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 > >compatible device. > > - "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device. > > + "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2 > > + compatible device. > >When compatible with the generic version, nodes must list the > >SoC-specific version corresponding to the platform first > >followed by the generic version. > > > > - reg: physical base address and size of the R-Car CAN register map. > > - interrupts: interrupt specifier for the sole interrupt. > > -- clocks: phandles and clock specifiers for 3 CAN clock inputs. > > -- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk". > > +- clocks: phandles and clock specifiers for 2 CAN clock inputs for RZ/G2 > > + devices. > > + phandles and clock specifiers for 3 CAN clock inputs for every other > > + SoC. > > +- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk". > > + 3 clock input name strings for every other SoC: "clkp1", "clkp2", > > + "can_clk". > > - pinctrl-0: pin control group to be used for this controller. > > - pinctrl-names: must be "default". > > > > @@ -41,8 +48,9 @@ using the below properties: > > Optional properties: > > - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values > > are: > > <0x0> (default) : Peripheral clock (clkp1) > > -<0x1> : Peripheral clock (clkp2) > > -<0x3> : Externally input clock > > +<0x1> : Peripheral clock (clkp2) (not supported by > > +RZ/G2 devices) > > +<0x3> : External input clock > > > > Example > > --- > > -- > > 2.7.4 > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered > No. 04586709. >
Re: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
On Thu, Nov 08, 2018 at 11:23:58AM +, Fabrizio Castro wrote: > Dear All, > > Who is the best person to take this patch? I believe this one is also for Joerg. > Thanks, > Fab > > > From: Fabrizio Castro > > Sent: 17 August 2018 15:31 > > Subject: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support > > > > Document RZ/G2M (R8A774A1) SoC bindings. > > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Biju Das > > --- > > This patch applies on top of next-20180817 > > > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > index ffadb7c..68446dd 100644 > > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > > @@ -13,6 +13,7 @@ Required Properties: > > - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU. > > - "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU. > > - "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU. > > +- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU. > > - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU. > > - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU. > > - "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU. > > -- > > 2.7.4 > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered > No. 04586709. >
Re: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
On Fri, Aug 17, 2018 at 03:31:05PM +0100, Fabrizio Castro wrote: > Document RZ/G2M (R8A774A1) SoC bindings. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das > --- > This patch applies on top of next-20180817 Reviewed-by: Simon Horman
RE: [PATCH v2 1/3][can-next] can: rcar_can: Fix erroneous registration
Dear All,
Is this patch ok?
Thanks,
Fab
> From: Fabrizio Castro
> Sent: 10 September 2018 11:43
> Subject: [PATCH v2 1/3][can-next] can: rcar_can: Fix erroneous registration
>
> Assigning 2 to "renesas,can-clock-select" tricks the driver into
> registering the CAN interface, even though we don't want that.
> This patch improves one of the checks to prevent that from happening.
>
> Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks")
> Signed-off-by: Fabrizio Castro
> Signed-off-by: Chris Paterson
> ---
>
> v1->v2:
> * dropped id specific data as per Geert's comments
>
> This patch applies on top of linux-can-next-for-4.19-20180727.
>
> drivers/net/can/rcar/rcar_can.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
> index 11662f4..771a460 100644
> --- a/drivers/net/can/rcar/rcar_can.c
> +++ b/drivers/net/can/rcar/rcar_can.c
> @@ -24,6 +24,9 @@
>
> #define RCAR_CAN_DRV_NAME"rcar_can"
>
> +#define RCAR_SUPPORTED_CLOCKS(BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
> + BIT(CLKR_CLKEXT))
> +
> /* Mailbox configuration:
> * mailbox 60 - 63 - Rx FIFO mailboxes
> * mailbox 56 - 59 - Tx FIFO mailboxes
> @@ -789,7 +792,7 @@ static int rcar_can_probe(struct platform_device *pdev)
> goto fail_clk;
> }
>
> -if (clock_select >= ARRAY_SIZE(clock_names)) {
> +if (!(BIT(clock_select) & RCAR_SUPPORTED_CLOCKS)) {
> err = -EINVAL;
> dev_err(&pdev->dev, "invalid CAN clock selected\n");
> goto fail_clk;
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH v4 4/4] pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions
Hi Jacopo,
On Wed, Nov 7, 2018 at 11:56 AM jacopo mondi wrote:
> On Wed, Nov 07, 2018 at 11:34:50AM +0100, Simon Horman wrote:
> > On Tue, Nov 06, 2018 at 11:35:33AM +0100, Jacopo Mondi wrote:
> > > Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car E3.
> > >
> > > Signed-off-by: Jacopo Mondi
> > >
> > > ---
> > > v3 -> v4:
> > > - Use new variadic version of VIN_DATA_PIN_GROUP macro
> >
> > I may be missing something but this patch seems to be the same as v3,
> > using the VIN_DATA_PIN_GROUP_VER macro.
> >
> Oooops, I forgot to add the changes and lost them while rebasing.
>
> Sorry about this, I'll resend.
Two quick comments below...
> > > v2 -> v3:
> > > - Rebased on v4.20-rc1
> > > - Use the newly introduced VIN_DATA_PIN_GROUP_VER macro
> > >
> > > Incorporate Geert's comments:
> > > - vin5_data8_b is only used with 8 pins: use regular SH_PFC_PIN_GROUP()
> > > - remove stf groups for vin4/vin5
> > > - confirmed that pins [23-8] of vin4's groups 'a' and 'b' are shared
> > > - confirmed with HW team the synchronism pins in vin5 are only for group
> > > 'a'
> > > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > +/* - VIN5
> > > --- */
> > > +static const union vin_data vin5_data_a_pins = {
union vin_data16
> > > + .data16 = {
> > > + RCAR_GP_PIN(1, 1), RCAR_GP_PIN(1, 2),
> > > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 12),
> > > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
> > > + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> > > + RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
> > > + RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 11),
> > > + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 10),
> > > + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
> > > + },
> > > +};
> > > +
> > > +static const union vin_data vin5_data_a_mux = {
union vin_data16
> > > + .data16 = {
> > > + VI5_DATA0_A_MARK, VI5_DATA1_A_MARK,
> > > + VI5_DATA2_A_MARK, VI5_DATA3_A_MARK,
> > > + VI5_DATA4_A_MARK, VI5_DATA5_A_MARK,
> > > + VI5_DATA6_A_MARK, VI5_DATA7_A_MARK,
> > > + VI5_DATA8_A_MARK, VI5_DATA9_A_MARK,
> > > + VI5_DATA10_A_MARK, VI5_DATA11_A_MARK,
> > > + VI5_DATA12_A_MARK, VI5_DATA13_A_MARK,
> > > + VI5_DATA14_A_MARK, VI5_DATA15_A_MARK,
> > > + },
> > > +};
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 v4 3/4] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
On Tue, Nov 6, 2018 at 11:35 AM Jacopo Mondi wrote:
> The VIN4 and VIN5 interfaces supports parallel video input.
> Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N.
>
> Reviewed-by: Ulrich Hecht
> Signed-off-by: Jacopo Mondi
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
Oops, found two more...
> +/* - VIN5
> --- */
> +static const union vin_data vin5_data_pins = {
union vin_data16
> + .data16 = {
> + RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
> + RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
> + RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
> + RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
> + RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 13),
> + RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 15),
> + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> + },
> +};
> +
> +static const union vin_data vin5_data_mux = {
union vin_data16
> + .data16 = {
> + VI5_DATA0_MARK, VI5_DATA1_MARK,
> + VI5_DATA2_MARK, VI5_DATA3_MARK,
> + VI5_DATA4_MARK, VI5_DATA5_MARK,
> + VI5_DATA6_MARK, VI5_DATA7_MARK,
> + VI5_DATA8_MARK, VI5_DATA9_MARK,
> + VI5_DATA10_MARK, VI5_DATA11_MARK,
> + VI5_DATA12_MARK, VI5_DATA13_MARK,
> + VI5_DATA14_MARK, VI5_DATA15_MARK,
> + },
> +};
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 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
On Thu, Aug 23, 2018 at 04:33:04PM +0100, Fabrizio Castro wrote:
> Add support for RZ/G2M (R8A774A1) SoC IPMMUs.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
Reviewed-by: Simon Horman
> ---
> v1-v2:
> * taken out IOMMU_OF_DECLARE
>
> drivers/iommu/ipmmu-vmsa.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 51af2c5..331562f 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -761,6 +761,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> }
>
> static const struct soc_device_attribute soc_rcar_gen3[] = {
> + { .soc_id = "r8a774a1", },
> { .soc_id = "r8a7795", },
> { .soc_id = "r8a7796", },
> { .soc_id = "r8a77965", },
> @@ -942,6 +943,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> .compatible = "renesas,ipmmu-vmsa",
> .data = &ipmmu_features_default,
> }, {
> + .compatible = "renesas,ipmmu-r8a774a1",
> + .data = &ipmmu_features_rcar_gen3,
> + }, {
> .compatible = "renesas,ipmmu-r8a7795",
> .data = &ipmmu_features_rcar_gen3,
> }, {
> --
> 2.7.4
>
Re: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
Hi Fabrizio,
I believe this one is for Joerg.
On Thu, Nov 08, 2018 at 11:22:55AM +, Fabrizio Castro wrote:
> Dear All,
>
> Who is the best person to take this patch?
>
> Thanks,
> Fab
>
> > From: Fabrizio Castro
> > Sent: 23 August 2018 16:33
> > Subject: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
> >
> > Add support for RZ/G2M (R8A774A1) SoC IPMMUs.
> >
> > Signed-off-by: Fabrizio Castro
> > Reviewed-by: Biju Das
> > ---
> > v1-v2:
> > * taken out IOMMU_OF_DECLARE
> >
> > drivers/iommu/ipmmu-vmsa.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> > index 51af2c5..331562f 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -761,6 +761,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> > }
> >
> > static const struct soc_device_attribute soc_rcar_gen3[] = {
> > +{ .soc_id = "r8a774a1", },
> > { .soc_id = "r8a7795", },
> > { .soc_id = "r8a7796", },
> > { .soc_id = "r8a77965", },
> > @@ -942,6 +943,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> > .compatible = "renesas,ipmmu-vmsa",
> > .data = &ipmmu_features_default,
> > }, {
> > +.compatible = "renesas,ipmmu-r8a774a1",
> > +.data = &ipmmu_features_rcar_gen3,
> > +}, {
> > .compatible = "renesas,ipmmu-r8a7795",
> > .data = &ipmmu_features_rcar_gen3,
> > }, {
> > --
> > 2.7.4
>
>
>
>
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
> Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
> No. 04586709.
>
Re: [PATCH/RFT] arm64: dts: renesas: r8a77990: Add I2C-DVFS device node
Hi Simon,
On Thu, Nov 8, 2018 at 12:52 PM Simon Horman wrote:
> On Thu, Nov 08, 2018 at 11:27:31AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Nov 8, 2018 at 11:22 AM Simon Horman wrote:
> > > On Wed, Nov 07, 2018 at 01:30:10PM +0100, Simon Horman wrote:
> > > > On Mon, Nov 05, 2018 at 09:52:48AM +0100, Geert Uytterhoeven wrote:
> > > > > On Sat, Oct 20, 2018 at 11:35 PM Yoshihiro Kaneko
> > > > > wrote:
> > > > > > From: Takeshi Kihara
> > > > > >
> > > > > > This patch adds I2C-DVFS device node for the R8A77990 SoC.
> > > > > >
> > > > > > Signed-off-by: Takeshi Kihara
> > > > > > Signed-off-by: Yoshihiro Kaneko
> > > > >
> > > > > Thanks for your patch!
> > > > >
> > > > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >
> > > > > > };
> > > > > >
> > > > > > cpus {
> > > > > > @@ -337,6 +338,22 @@
> > > > > > reg = <0 0xe606 0 0x508>;
> > > > > > };
> > > > > >
> > > > > > + i2c_dvfs: i2c@e60b {
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + compatible = "renesas,iic-r8a77990",
> > > > >
> > > > > "renesas,iic-r8a77990" is not yet documented.
> > > >
> > > > Thanks, as per my comment below I wonder if as well as documenting
> > > > "renesas,iic-r8a77990" we also to teach the driver about it.
> > > >
> > > > >
> > > > > > +"renesas,rcar-gen3-iic",
> > > > > > +"renesas,rmobile-iic";
> > > > >
> > > > > Also, IIC on R-Car E3 does not have the automatic transmission
> > > > > registers.
> > > > > Does this affect claiming compatibility with the family-specific or
> > > > > generic
> > > > > compatible values?
> > > >
> > > > My cursory reading of the driver indicates that only register that is
> > > > used by it but documented as not existing on E3 is ICSTART (offset
> > > > 0x70).
> > > >
> > > > It seems to me that we should confirm with Renesas that the register
> > > > does
> > > > indeed not exist - as this patch comes from the BSP which implies it is
> > > > being used there. And if it does not exist we should try teaching the
> > > > driver not to use ICSTART via the "renesas,iic-r8a77990" compat string.
> > > > What do you think?
> > >
> > > Further examination by Wolfram Sang has shown that the code in question is
> > > only used on the r8a7740. I don't think there is any compatibility issue
> > > for r8a77990 when using the current driver.
> >
> > "When using the current driver".
> > Do we want to claim compatibility with "renesas,rcar-gen3-iic" and/or
> > "renesas,rmobile-iic"?
>
> Thinking a bit more since I wrote my previous email.
>
> It seems that the r8a77990 has a different feature set to other R-Car Gen3
> SoCs but that the current driver implementation "renesas,rcar-gen3-iic"
> and "renesas,rmobile-iic" do not exceed that feature set.
>
> In future we could expand the features supported by the driver for other
> Gen3 SoCs beyond what is supported for r8a77990. If we chose to describe
> r8a77990 as compatible with renesas,rcar-gen3-iic then that implies those
> new features would not be activated by matching on "renesas,rcar-gen3-iic",
> though we could choose to control that using soc_match. Conversely if we
> decide that r8a77990 is not compatible with renesas,rcar-gen3-iic then we
> have more freedom to move with regards to adding features not supported by
> r8a77990 to renesas,rcar-gen3-iic in future.
>
> So perhaps it would be wise to be conservative and, for now,
> not document r8a77990 as being compatible with renesas,iic-r8a77990.
>
> I'm tempted to say that renesas,rmobile-iic is a lowest common denominator
> and r8a77990 can be documented as being compatible with it. But we could
> say the same of renesas,rcar-gen3-iic.
>
> What do you think?
That matches my thoughts.
Given R-Mobile A1 does have the register, I think r8a77990 should not claim
compatibility with it.
Of course all this assumes there's no bug in the datasheet w.r.t. r8a77990...
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] serial: sh-sci: Document r8a774a1 bindings
On Tue, Aug 14, 2018 at 01:34:02PM +0100, Fabrizio Castro wrote: > RZ/G2M (R8A774A1) SoC also has the R-Car Gen3 compatible SCIF and > HSCIF ports, so document the SoC specific bindings. While at it, > update the RZ/G1 and RZ/G2 family specific strings description as > outdated. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das Reviewed-by: Simon Horman
Re: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings
Hi Fabrizio, I believe this one is for Vinod. On Thu, Nov 08, 2018 at 11:03:53AM +, Fabrizio Castro wrote: > Dear All, > > Who is the best person to take this patch? > > Thanks, > Fab > > > From: Fabrizio Castro > > Sent: 14 August 2018 13:32 > > Subject: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings > > > > Renesas' RZ/G2M (R8A774A1) SoC has DMA controllers compatible > > with this driver, therefore document RZ/G2M specific bindings. > > > > Signed-off-by: Fabrizio Castro > > Reviewed-by: Biju Das > > --- > > Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > > b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > > index 946229c..2de2eed 100644 > > --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > > +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > > @@ -1,6 +1,6 @@ > > * Renesas R-Car (RZ/G) DMA Controller Device Tree bindings > > > > -Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA > > +Renesas R-Car (Gen 2/3) and RZ/G SoCs have multiple multi-channel DMA > > controller instances named DMAC capable of serving multiple clients. > > Channels > > can be dedicated to specific clients or shared between a large number of > > clients. > > @@ -19,6 +19,7 @@ Required Properties: > > - "renesas,dmac-r8a7743" (RZ/G1M) > > - "renesas,dmac-r8a7745" (RZ/G1E) > > - "renesas,dmac-r8a77470" (RZ/G1C) > > +- "renesas,dmac-r8a774a1" (RZ/G2M) > > - "renesas,dmac-r8a7790" (R-Car H2) > > - "renesas,dmac-r8a7791" (R-Car M2-W) > > - "renesas,dmac-r8a7792" (R-Car V2H) > > -- > > 2.7.4 > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered > No. 04586709. >
Re: [PATCH v4 3/4] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
Hi Jacopo,
On Tue, Nov 6, 2018 at 11:35 AM Jacopo Mondi wrote:
> The VIN4 and VIN5 interfaces supports parallel video input.
> Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N.
>
> Reviewed-by: Ulrich Hecht
> Signed-off-by: Jacopo Mondi
Thanks for your patch!
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
> @@ -4000,6 +4210,24 @@ static const struct sh_pfc_pin_group pinmux_groups[] =
> {
> SH_PFC_PIN_GROUP(usb0),
> SH_PFC_PIN_GROUP(usb1),
> SH_PFC_PIN_GROUP(usb30),
> + VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> + VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
> + SH_PFC_PIN_GROUP(vin4_data18_a),
> + VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
> + VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
> + VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
> + SH_PFC_PIN_GROUP(vin4_data18_b),
> + VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
Missing support for 10/12/20?
> + SH_PFC_PIN_GROUP(vin4_sync),
> + SH_PFC_PIN_GROUP(vin4_field),
> + SH_PFC_PIN_GROUP(vin4_clkenb),
> + SH_PFC_PIN_GROUP(vin4_clk),
> + VIN_DATA_PIN_GROUP(vin5_data, 8),
> + VIN_DATA_PIN_GROUP(vin5_data, 16),
Missing support for 10/12?
> + SH_PFC_PIN_GROUP(vin5_sync),
> + SH_PFC_PIN_GROUP(vin5_field),
> + SH_PFC_PIN_GROUP(vin5_clkenb),
> + SH_PFC_PIN_GROUP(vin5_clk),
> };
>
> static const char * const audio_clk_groups[] = {
> @@ -4392,6 +4620,30 @@ static const char * const usb30_groups[] = {
> "usb30",
> };
>
> +static const char * const vin4_groups[] = {
> + "vin4_data8_a",
> + "vin4_data16_a",
> + "vin4_data18_a",
> + "vin4_data24_a",
> + "vin4_data8_b",
> + "vin4_data16_b",
> + "vin4_data18_b",
> + "vin4_data24_b",
Missing support for 10/12/20?
> + "vin4_sync",
> + "vin4_field",
> + "vin4_clkenb",
> + "vin4_clk",
> +};
> +
> +static const char * const vin5_groups[] = {
> + "vin5_data8",
> + "vin5_data16",
Missing support for 10/12?
> + "vin5_sync",
> + "vin5_field",
> + "vin5_clkenb",
> + "vin5_clk",
> +};
With the above fixed:
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: [renesas:arm64-dt-for-v4.21 25/25] Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or path sdhi0 not found
On Thu, Nov 08, 2018 at 11:54:32AM +0100, Marek Vasut wrote: > On 11/08/2018 11:33 AM, Simon Horman wrote: > > On Wed, Nov 07, 2018 at 03:04:51PM +0100, Marek Vasut wrote: > >> On 11/07/2018 02:57 PM, kbuild test robot wrote: > >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > >>> arm64-dt-for-v4.21 > >>> head: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c > >>> commit: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c [25/25] arm64: dts: > >>> r8a77990: ebisu: Add and enable SDHI device nodes > >>> config: arm64-defconfig (attached as .config) > >>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > >>> reproduce: > >>> wget > >>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross > >>> -O ~/bin/make.cross > >>> chmod +x ~/bin/make.cross > >>> git checkout 3e8f76c61511f3c4f0c25c36172605d6aeaec37c > >>> # save the attached .config to linux build tree > >>> GCC_VERSION=7.2.0 make.cross ARCH=arm64 > >>> > >>> All errors (new ones prefixed by >>): > >>> > >>>>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or > >>>>> path sdhi0 not found > >>>>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:637.1-7 Label or > >>>>> path sdhi1 not found > >>>>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:651.1-7 Label or > >>>>> path sdhi3 not found > >>>>> FATAL ERROR: Syntax error parsing input tree > >> > >> Commit 3e8f76c61511f3c4f0c25c36172605d6aeaec37c seems to be missing the > >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 + > >> part from > >> [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes > >> thus the error. > > > > Sorry about that, will fix ASAP. > > No problem, thanks! Should be fixed in renesas-next-20181108-v4.20-rc1.
Re: [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes
On Tue, Nov 6, 2018 at 9:46 PM Marek Vasut wrote:
> Subject: [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device
> nodes
arm64: dts: renesas: r8a77990: ebisu: Add and enable SDHI device nodes
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins
On Mon, Nov 5, 2018 at 10:39 PM Marek Vasut wrote:
> Subject: [PATCH] arm64: dts: r8a77990: ebisu: Add serial console pins
arm64: dts: renesas: r8a77990: ebisu: Add serial console pins
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] arm64: dts: renesas: r8a77990: Add I2C-DVFS device node
On Thu, Nov 08, 2018 at 11:27:31AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, Nov 8, 2018 at 11:22 AM Simon Horman wrote:
> > On Wed, Nov 07, 2018 at 01:30:10PM +0100, Simon Horman wrote:
> > > On Mon, Nov 05, 2018 at 09:52:48AM +0100, Geert Uytterhoeven wrote:
> > > > On Sat, Oct 20, 2018 at 11:35 PM Yoshihiro Kaneko
> > > > wrote:
> > > > > From: Takeshi Kihara
> > > > >
> > > > > This patch adds I2C-DVFS device node for the R8A77990 SoC.
> > > > >
> > > > > Signed-off-by: Takeshi Kihara
> > > > > Signed-off-by: Yoshihiro Kaneko
> > > >
> > > > Thanks for your patch!
> > > >
> > > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
>
> > > > > };
> > > > >
> > > > > cpus {
> > > > > @@ -337,6 +338,22 @@
> > > > > reg = <0 0xe606 0 0x508>;
> > > > > };
> > > > >
> > > > > + i2c_dvfs: i2c@e60b {
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > + compatible = "renesas,iic-r8a77990",
> > > >
> > > > "renesas,iic-r8a77990" is not yet documented.
> > >
> > > Thanks, as per my comment below I wonder if as well as documenting
> > > "renesas,iic-r8a77990" we also to teach the driver about it.
> > >
> > > >
> > > > > +"renesas,rcar-gen3-iic",
> > > > > +"renesas,rmobile-iic";
> > > >
> > > > Also, IIC on R-Car E3 does not have the automatic transmission
> > > > registers.
> > > > Does this affect claiming compatibility with the family-specific or
> > > > generic
> > > > compatible values?
> > >
> > > My cursory reading of the driver indicates that only register that is
> > > used by it but documented as not existing on E3 is ICSTART (offset 0x70).
> > >
> > > It seems to me that we should confirm with Renesas that the register does
> > > indeed not exist - as this patch comes from the BSP which implies it is
> > > being used there. And if it does not exist we should try teaching the
> > > driver not to use ICSTART via the "renesas,iic-r8a77990" compat string.
> > > What do you think?
> >
> > Further examination by Wolfram Sang has shown that the code in question is
> > only used on the r8a7740. I don't think there is any compatibility issue
> > for r8a77990 when using the current driver.
>
> "When using the current driver".
> Do we want to claim compatibility with "renesas,rcar-gen3-iic" and/or
> "renesas,rmobile-iic"?
Thinking a bit more since I wrote my previous email.
It seems that the r8a77990 has a different feature set to other R-Car Gen3
SoCs but that the current driver implementation "renesas,rcar-gen3-iic"
and "renesas,rmobile-iic" do not exceed that feature set.
In future we could expand the features supported by the driver for other
Gen3 SoCs beyond what is supported for r8a77990. If we chose to describe
r8a77990 as compatible with renesas,rcar-gen3-iic then that implies those
new features would not be activated by matching on "renesas,rcar-gen3-iic",
though we could choose to control that using soc_match. Conversely if we
decide that r8a77990 is not compatible with renesas,rcar-gen3-iic then we
have more freedom to move with regards to adding features not supported by
r8a77990 to renesas,rcar-gen3-iic in future.
So perhaps it would be wise to be conservative and, for now,
not document r8a77990 as being compatible with renesas,iic-r8a77990.
I'm tempted to say that renesas,rmobile-iic is a lowest common denominator
and r8a77990 can be documented as being compatible with it. But we could
say the same of renesas,rcar-gen3-iic.
What do you think?
Re: [PATCH] serial: sh-sci: Improve type-safety calling sci_receive_chars()
On Wed, Nov 07, 2018 at 02:37:31PM +0100, Geert Uytterhoeven wrote: > While ptr and port both point to the uart_port structure, the former is > the untyped pointer cookie passed to interrupt handlers. > Use the correctly typed port variable instead, to improve type-safety. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman
Re: [PATCH v4 1/4] pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP
Hi Jacopo,
On Thu, Nov 8, 2018 at 11:58 AM Geert Uytterhoeven wrote:
> On Tue, Nov 6, 2018 at 11:35 AM Jacopo Mondi
> wrote:
> > VIN data groups may appear on different sets of pins, usually named
> > "vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support
> > appending the '_a' or '_b' suffix, leading to the definition of groups
>
> group
>
> > names not consistent with the ones defined using SH_PFC_PIN_GROUP() macro.
>
> the SH_PFC_PIN_GROUP() macro.
>
> >
> > Fix this by adding making the VIN_DATA_PIN_GROUP macro a variadic one,
>
> Please drop "adding".
> VIN_DATA_PIN_GROUP()
>
> > which accepts an optional 'version' argument.
> >
> > Signed-off-by: Jacopo Mondi
>
> Reviewed-by: Geert Uytterhoeven
Perhaps it makes sense to add
Fixes: 423caa52534ff15a ("pinctrl: sh-pfc: r8a779[01]: Move 'union
vin_data' to shared header file")
to make sure it gets backported with the SoC-specific fixes that depend on it?
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 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support
Dear All, Who is the best person to take this patch? Thanks, Fab > From: Fabrizio Castro > Sent: 10 September 2018 11:43 > Subject: [PATCH v2 2/3] dt-bindings: can: rcar_can: Add r8a774a1 support > > Document RZ/G2M (r8a774a1) SoC specific bindings. > > Signed-off-by: Fabrizio Castro > Signed-off-by: Chris Paterson > Reviewed-by: Biju Das > --- > v1->v2: > * dropped "renesas,rzg-gen2-can" and fixed "clocks" property description > as per Geert's comments. > > This patch applies on top of next-20180910. > > Documentation/devicetree/bindings/net/can/rcar_can.txt | 18 > +- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt > b/Documentation/devicetree/bindings/net/can/rcar_can.txt > index 94a7f33..f3b160c 100644 > --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt > +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt > @@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings > Required properties: > - compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 > SoC. >"renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. > + "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC. >"renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. >"renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. >"renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. > @@ -16,15 +17,21 @@ Required properties: >"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. >"renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 >compatible device. > - "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device. > + "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2 > + compatible device. >When compatible with the generic version, nodes must list the >SoC-specific version corresponding to the platform first >followed by the generic version. > > - reg: physical base address and size of the R-Car CAN register map. > - interrupts: interrupt specifier for the sole interrupt. > -- clocks: phandles and clock specifiers for 3 CAN clock inputs. > -- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk". > +- clocks: phandles and clock specifiers for 2 CAN clock inputs for RZ/G2 > + devices. > + phandles and clock specifiers for 3 CAN clock inputs for every other > + SoC. > +- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk". > + 3 clock input name strings for every other SoC: "clkp1", "clkp2", > + "can_clk". > - pinctrl-0: pin control group to be used for this controller. > - pinctrl-names: must be "default". > > @@ -41,8 +48,9 @@ using the below properties: > Optional properties: > - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are: > <0x0> (default) : Peripheral clock (clkp1) > -<0x1> : Peripheral clock (clkp2) > -<0x3> : Externally input clock > +<0x1> : Peripheral clock (clkp2) (not supported by > +RZ/G2 devices) > +<0x3> : External input clock > > Example > --- > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH v4 3/4] media: i2c: Add MAX9286 driver
Hi Jacopo, On 08/11/18 11:11, jacopo mondi wrote: > Hi Luca, Kieran, > sorry to jump up, but I feel this should be clarified. > > On Wed, Nov 07, 2018 at 06:24:18PM +0100, Luca Ceresoli wrote: >> Hi Kieran, >> >> thanks for the clarification. One additional note below. >> >> On 07/11/18 16:06, Kieran Bingham wrote: >>> Hi Luca >>> >>> >>> kbingham: hi, I'm looking at your GMSL v4 patches kbingham: jmondi helped me in understanding parts of it, but I still have a question kbingham: are the drivers waiting for the established link before the remote chips are accessed? where? >>> >>> I'm replying here rather than spam the IRC channel with a big paste. >>> It's also a useful description to the probe sequence, so I've kept it >>> with the driver posting. >>> >>> I hope the following helps illustrate the sequences which are involved: >>> >>> max9286_probe() >>> - max9286_i2c_mux_close() # Disable all links >>> - max9286_configure_i2c # Configure early communication settings >>> - max9286_init(): >>>- regulator_enable() # Power up all cameras >>>- max9286_setup() # Most link setup is done here. >>>... Set up v4l2/async/media-controller endpoints >>>- max9286_i2c_mux_init() # Start configuring cameras: >>> - i2c_mux_alloc() # Create our mux device >>> - for_each_source(dev, source) >>>i2c_mux_add_adapter() # This is where sensors get probed. >>> >>> So yes sensors are only communicated with once the link is brought up as >>> much as possible. >> >> For the records, an additional bit of explanation I got from Kieran via IRC. >> >> The fact that link is already up when the sensors are probed is due to >> the fact that the power regulator has a delay of *8 seconds*. This is >> intended, because there's an MCU on the camera modules that talks on the >> I2C bus during that time, and thus the drivers need to wait after it's done. > > The 8sec delay is due to the fact an integrated MCU on the remote > camera module programs the local sensor and the serializer intgrated > in the module in to some default configuration state. At power up, we > just want to let it finish, with all reverse channels closed > (camera module -> SoC direction) not to have the MCU transmitted > messages repeated to the local side (our remote serializer does repeat > messages not directed to it on it's remote side, as our local > deserialier does). > > The "link up" thing is fairly more complicated for GMSL than just > having a binary "on" or "off" mode. This technology defines two different > "channels", a 'configuration-channel' for transmitting control messages > on the serial link (i2c messages for the deserializer/serializer pair > this patches support) and a 'video-channel' for transmission of > high-speed data, such as, no surprise, video and images :) > > GMSL also defines two "link modes": a clock-less "configuration link" > and an high-speed "video link". The "configuration link" is available a > few msec after power up (roughly), while the "video link" needs a pixel > clock to be supplied to the serializer for it to enter this mode and > be able to lock the status between itself and the deserializer. Then it can > begin serializing video data. > > The 'control channel' is available both when the link is in > 'configuration' and 'video' mode, while the 'video' channel is > available only when the link is in 'video' mode (or, to put it more > simply: you can send i2c configuration messages while the link is > serializing video). > > Our implementation uses the link in 'configuration mode' during the > remote side programming phase, at 'max9286_i2c_mux_init()' time, with > the 'max9286_i2c_mux_select()' function enabling selectively the > 'configuration link' of each single remote end. It probes the remote device > by instantiating a new i2c_adapter connected to the mux, one for each > remote end, and performs the device configuration by initially using its > default power up i2c address (it is safe to do so, all other links are > closed), then changes the remote devices address to an unique one > (as our devices allows us to do so, otherwise you should use the > deserializer address translation feature to mask and translate the > remote addresses). > > Now all remote devices have an unique i2c address, and we can operate > with all 'configuration links' open with no risk of i2c addresses > collisions. > > At this point when we want to start the video stream, we send a > control message to the remote device, which enables the pixel clock > output from the image sensor, and activate the 'video channel' on the > remote serializer. The local deserializer makes sure all 'video links' > are locked (see 'max9286_check_video_links()') and at this point we > can begin serializing/deserializing video data. > > As you can see, the initial delay only plays a role in avoiding > collision before we properly configure the channels and the i2c > addresses. The link setu
RE: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support
Dear All, Who is the best person to take this patch? Thanks, Fab > From: Fabrizio Castro > Sent: 17 August 2018 15:31 > Subject: [PATCH 2/2] dt-bindings: iommu: ipmmu-vmsa: Add r8a774a1 support > > Document RZ/G2M (R8A774A1) SoC bindings. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das > --- > This patch applies on top of next-20180817 > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > index ffadb7c..68446dd 100644 > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt > @@ -13,6 +13,7 @@ Required Properties: > - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU. > - "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU. > - "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU. > +- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU. > - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU. > - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU. > - "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU. > -- > 2.7.4 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 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
Dear All,
Who is the best person to take this patch?
Thanks,
Fab
> From: Fabrizio Castro
> Sent: 23 August 2018 16:33
> Subject: [PATCH v2 1/2] iommu/ipmmu-vmsa: Hook up R8A774A1 DT maching code
>
> Add support for RZ/G2M (R8A774A1) SoC IPMMUs.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Biju Das
> ---
> v1-v2:
> * taken out IOMMU_OF_DECLARE
>
> drivers/iommu/ipmmu-vmsa.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 51af2c5..331562f 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -761,6 +761,7 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> }
>
> static const struct soc_device_attribute soc_rcar_gen3[] = {
> +{ .soc_id = "r8a774a1", },
> { .soc_id = "r8a7795", },
> { .soc_id = "r8a7796", },
> { .soc_id = "r8a77965", },
> @@ -942,6 +943,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
> .compatible = "renesas,ipmmu-vmsa",
> .data = &ipmmu_features_default,
> }, {
> +.compatible = "renesas,ipmmu-r8a774a1",
> +.data = &ipmmu_features_rcar_gen3,
> +}, {
> .compatible = "renesas,ipmmu-r8a7795",
> .data = &ipmmu_features_rcar_gen3,
> }, {
> --
> 2.7.4
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
RE: [PATCH] serial: sh-sci: Document r8a774a1 bindings
Dear All, This is just a gentle reminder. Thanks, Fab > From: Fabrizio Castro > Sent: 14 August 2018 13:34 > Subject: [PATCH] serial: sh-sci: Document r8a774a1 bindings > > RZ/G2M (R8A774A1) SoC also has the R-Car Gen3 compatible SCIF and > HSCIF ports, so document the SoC specific bindings. While at it, > update the RZ/G1 and RZ/G2 family specific strings description as > outdated. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das > --- > .../devicetree/bindings/serial/renesas,sci-serial.txt | 14 > -- > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > b/Documentation/devicetree/bindings/serial/renesas,sci- > serial.txt > index eaca9da..1994ab8 100644 > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > @@ -20,6 +20,8 @@ Required properties: > - "renesas,hscif-r8a7745" for R8A7745 (RZ/G1E) HSCIF compatible UART. > - "renesas,scif-r8a77470" for R8A77470 (RZ/G1C) SCIF compatible UART. > - "renesas,hscif-r8a77470" for R8A77470 (RZ/G1C) HSCIF compatible UART. > +- "renesas,scif-r8a774a1" for R8A774A1 (RZ/G2M) SCIF compatible UART. > +- "renesas,hscif-r8a774a1" for R8A774A1 (RZ/G2M) HSCIF compatible UART. > - "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART. > - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART. > - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART. > @@ -55,13 +57,13 @@ Required properties: > - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible > UART. > - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible > UART. > - "renesas,rcar-gen1-scif" for R-Car Gen1 SCIF compatible UART, > -- "renesas,rcar-gen2-scif" for R-Car Gen2 SCIF compatible UART, > -- "renesas,rcar-gen3-scif" for R-Car Gen3 SCIF compatible UART, > -- "renesas,rcar-gen2-scifa" for R-Car Gen2 SCIFA compatible UART, > -- "renesas,rcar-gen2-scifb" for R-Car Gen2 SCIFB compatible UART, > +- "renesas,rcar-gen2-scif" for R-Car Gen2 and RZ/G1 SCIF compatible UART, > +- "renesas,rcar-gen3-scif" for R-Car Gen3 and RZ/G2 SCIF compatible UART, > +- "renesas,rcar-gen2-scifa" for R-Car Gen2 and RZ/G1 SCIFA compatible > UART, > +- "renesas,rcar-gen2-scifb" for R-Car Gen2 and RZ/G1 SCIFB compatible > UART, > - "renesas,rcar-gen1-hscif" for R-Car Gen1 HSCIF compatible UART, > -- "renesas,rcar-gen2-hscif" for R-Car Gen2 HSCIF compatible UART, > -- "renesas,rcar-gen3-hscif" for R-Car Gen3 HSCIF compatible UART, > +- "renesas,rcar-gen2-hscif" for R-Car Gen2 and RZ/G1 HSCIF compatible > UART, > +- "renesas,rcar-gen3-hscif" for R-Car Gen3 and RZ/G2 HSCIF compatible > UART, > - "renesas,scif" for generic SCIF compatible UART. > - "renesas,scifa" for generic SCIFA compatible UART. > - "renesas,scifb" for generic SCIFB compatible UART. > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH] [trivial] mfd: tmio: Typo s/use use/use/
On Wed, Nov 07, 2018 at 02:50:01PM +0100, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang We will remove that flag somewhen in the future anyhow, but for now it is good, me thinks. signature.asc Description: PGP signature
Re: [PATCH v4 2/4] pinctrl: sh-pfc: Fix VIN versioned groups name
Hi Geert
On Thu, Nov 08, 2018 at 11:59:08AM +0100, Geert Uytterhoeven wrote:
> On Tue, Nov 6, 2018 at 11:35 AM Jacopo Mondi
> wrote:
> > Versioned VIN groups can appear on different sets of pins. Using the
> > VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through
> > an optional 'version' argument.
> >
> > Use the 'version' argument for said macro to fix naming of versioned
> > groups for R-Car SoCs that defines them.
> >
> > Signed-off-by: Jacopo Mondi
>
> Fixes: 7dd74bb1f058786e ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
> Fixes: a5c2949ff7bd9e04 ("pinctrl: sh-pfc: r8a7796: Deduplicate VIN4 pin
> Fixes: 9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
> Reviewed-by: Geert Uytterhoeven
I added the Fixes tag to the single patches I've broke out and will
send in v5.
Thanks
j
>
> 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
signature.asc
Description: PGP signature
RE: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings
Dear All, Who is the best person to take this patch? Thanks, Fab > From: Fabrizio Castro > Sent: 14 August 2018 13:32 > Subject: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings > > Renesas' RZ/G2M (R8A774A1) SoC has DMA controllers compatible > with this driver, therefore document RZ/G2M specific bindings. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Biju Das > --- > Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > index 946229c..2de2eed 100644 > --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt > @@ -1,6 +1,6 @@ > * Renesas R-Car (RZ/G) DMA Controller Device Tree bindings > > -Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA > +Renesas R-Car (Gen 2/3) and RZ/G SoCs have multiple multi-channel DMA > controller instances named DMAC capable of serving multiple clients. Channels > can be dedicated to specific clients or shared between a large number of > clients. > @@ -19,6 +19,7 @@ Required Properties: > - "renesas,dmac-r8a7743" (RZ/G1M) > - "renesas,dmac-r8a7745" (RZ/G1E) > - "renesas,dmac-r8a77470" (RZ/G1C) > +- "renesas,dmac-r8a774a1" (RZ/G2M) > - "renesas,dmac-r8a7790" (R-Car H2) > - "renesas,dmac-r8a7791" (R-Car M2-W) > - "renesas,dmac-r8a7792" (R-Car V2H) > -- > 2.7.4 Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH v4 2/4] pinctrl: sh-pfc: Fix VIN versioned groups name
On Tue, Nov 6, 2018 at 11:35 AM Jacopo Mondi wrote:
> Versioned VIN groups can appear on different sets of pins. Using the
> VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through
> an optional 'version' argument.
>
> Use the 'version' argument for said macro to fix naming of versioned
> groups for R-Car SoCs that defines them.
>
> Signed-off-by: Jacopo Mondi
Fixes: 7dd74bb1f058786e ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
Fixes: a5c2949ff7bd9e04 ("pinctrl: sh-pfc: r8a7796: Deduplicate VIN4 pin
Fixes: 9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
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 v4 1/4] pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP
Hi Jacopo,
Thanks for your patch!
On Tue, Nov 6, 2018 at 11:35 AM Jacopo Mondi wrote:
> VIN data groups may appear on different sets of pins, usually named
> "vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support
> appending the '_a' or '_b' suffix, leading to the definition of groups
group
> names not consistent with the ones defined using SH_PFC_PIN_GROUP() macro.
the SH_PFC_PIN_GROUP() macro.
>
> Fix this by adding making the VIN_DATA_PIN_GROUP macro a variadic one,
Please drop "adding".
VIN_DATA_PIN_GROUP()
> which accepts an optional 'version' argument.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
> --- a/drivers/pinctrl/sh-pfc/sh_pfc.h
> +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
> @@ -54,15 +54,16 @@ struct sh_pfc_pin_group {
>
> /*
> * Using union vin_data saves memory occupied by the VIN data pins.
> - * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups
> - * in this case.
> + * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups
> + * in this case. It accepts an optional 'version' argument used when the
> + * same group can appear on a different set of pins.
Please rebase against sh-pfc-for-v4.21.
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: [renesas:arm64-dt-for-v4.21 25/25] Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or path sdhi0 not found
On 11/08/2018 11:33 AM, Simon Horman wrote: > On Wed, Nov 07, 2018 at 03:04:51PM +0100, Marek Vasut wrote: >> On 11/07/2018 02:57 PM, kbuild test robot wrote: >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git >>> arm64-dt-for-v4.21 >>> head: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c >>> commit: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c [25/25] arm64: dts: >>> r8a77990: ebisu: Add and enable SDHI device nodes >>> config: arm64-defconfig (attached as .config) >>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 >>> reproduce: >>> wget >>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O >>> ~/bin/make.cross >>> chmod +x ~/bin/make.cross >>> git checkout 3e8f76c61511f3c4f0c25c36172605d6aeaec37c >>> # save the attached .config to linux build tree >>> GCC_VERSION=7.2.0 make.cross ARCH=arm64 >>> >>> All errors (new ones prefixed by >>): >>> > Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or > path sdhi0 not found > Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:637.1-7 Label or > path sdhi1 not found > Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:651.1-7 Label or > path sdhi3 not found > FATAL ERROR: Syntax error parsing input tree >> >> Commit 3e8f76c61511f3c4f0c25c36172605d6aeaec37c seems to be missing the >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 + >> part from >> [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes >> thus the error. > > Sorry about that, will fix ASAP. No problem, thanks! -- Best regards, Marek Vasut
Re: [PATCH] arm64: renesas: r8a7795: add SSIU support for sound
On Thu, Nov 08, 2018 at 02:12:14AM +, Kuninori Morimoto wrote: > > Hi Simon > > rsnd sound driver will handle SSIU from v4.21 via DT. > Of course it is keeping compatibility, thus, no SSIU settings > is no problem. > > SSIU handles BUSIFn, but rsnd driver had been assumed only BUSIF0 was used. > Thus, SSIU / BUSIF0 was attached via SSI automatically, > but it was not enough for TDM Split mode. > > To enable TDM Split mode, we need to select BUSIFn via SSIU. > This patch adds SSIU DT settings to r8a7795. > > If we had SSIU DT settings, existing BUSIF0 settings via SSI > is no longer needed. We want to remove it. > To avoid git merge timing issue / git bisect issue, > I will re-post "remove" patch later (= for v4.22). > Please consider 1st patch and ignore 2nd patch so far. Thanks. I have applied the 1st patch for v4.21. And marked the 2nd patch as deferred. Please repost or ping me once v4.22-rc1 has been released.
Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.20
Hi Olof,
On Wed, Nov 7, 2018 at 5:03 PM Olof Johansson wrote:
> On Wed, Nov 7, 2018 at 3:25 AM Simon Horman
> wrote:
> > * R-Car V3H (r8a77980) based Condor board
> > - Switch from EtherAVB to GEther to match offical boards
> >
> > * RZ/G2E (ra8774c0) SoC: correct documentation of part number
>
> I have to admit, Renesas part numbers have got to be _really_ hard to
> deal with for anyone who has even the slightest hint of dyslexia. :-)
Yeah, for some on them, you can trick people into believing Renesas did
switch to "r" + a truncated commit ID in the HDL source repository ;-)
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 0/4] arm64: renesas: enable ULCB HDMI / ULCB-KF sound
On Thu, Nov 08, 2018 at 01:57:41AM +, Kuninori Morimoto wrote:
>
> Hi Simon
>
> These patches adds sound support for KingFisher.
> We can enable it on top of v4.20-rc1, but, it is not stable.
> We need this patch (= from ASoC for-v4.21 branch) to be stable it.
>
> 223bc10b84970fd772c105b550beeef3ac3502be
> ("ASoC: pcm3168a: remove read-only status register from
> snd_kcontrol_new")
Perhaps it is best to wait for that patch to hit an rc release.
Do you know when that will happen?
>
> Kuninori Morimoto (4):
> arm64: renesas: ulcb: use audio-graph-card
> arm64: renesas: ulcb: add HDMI sound support
> arm64: renesas: ulcb-kf: add pcm3168 sound codec
> arm64: renesas_defconfig: select Kingfisher Sound related configs
>
> arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 151
> +++
> arch/arm64/boot/dts/renesas/ulcb.dtsi| 70 ++
> arch/arm64/configs/renesas_defconfig | 2 +
> 3 files changed, 206 insertions(+), 17 deletions(-)
>
> --
> 2.7.4
>
>
>
> Best regards
> ---
> Kuninori Morimoto
>
RE: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
Hi Geert,
Thank you for your feedback!
> Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
>
> Hi Fabrizio,
>
> On Thu, Nov 8, 2018 at 11:31 AM Fabrizio Castro
> wrote:
> > > On Thu, Nov 8, 2018 at 11:22 AM Fabrizio Castro
> > > wrote:
> > > > > From: Simon Horman
> > > > > Sent: 02 November 2018 11:50
> > > > > Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
> > > > >
> > > > > On Thu, Nov 01, 2018 at 12:35:04PM +, Fabrizio Castro wrote:
> > > > > > Add QSPI[01] support to the RZ/G1C SoC specific device tree.
> > > > > >
> > > > > > Signed-off-by: Fabrizio Castro
> > > > > > ---
> > > > > > arch/arm/boot/dts/r8a77470.dtsi | 34
> > > > > > ++
> > > > > > 1 file changed, 34 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/arm/boot/dts/r8a77470.dtsi
> > > > > > b/arch/arm/boot/dts/r8a77470.dtsi
> > > > > > index e6407e5..04a8877 100644
> > > > > > --- a/arch/arm/boot/dts/r8a77470.dtsi
> > > > > > +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > > > > > @@ -20,6 +20,8 @@
> > > > > > i2c2 = &i2c2;
> > > > > > i2c3 = &i2c3;
> > > > > > i2c4 = &i2c4;
> > > > > > +spi0 = &qspi0;
> > > > > > +spi1 = &qspi1;
> > > > > > };
> > > > >
> > > > > Geert can comment but I believe we are moving away from using aliases
> > > > > in this way and that it would be best if the above hunk was dropped
> > > > > from this patch.
> > > > >
> > > > > https://patchwork.kernel.org/patch/10644159/
> > > >
> > > > Geert, what do you want me to do here?
> > >
> > > Please drop the aliases. Thanks!
> >
> > Will do, will send a new version without the additional aliases.
>
> Thanks!
>
> > My understanding is that your personal preference is to only leave debug
> > console and ethernet,
>
> Labeled serial ports and primary Ethernet, so U-Boot knows which MAC address
> property to update.
>
> > shall I also get rid of what was already upstreamed for RZ/G related
> > boards that is not in line
> > with the new policy?
>
> I believe these are all serial ports, using aliases that match the documented
> and/or labeled port names? So they don't have to be removed.
We have also been using aliases for i2c, spi (like in this case), vin, etc.,
for all of the RZ/G boards,
shall I get rid of those?
Cheers,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH v3 resend] ARM: dts: iwg23s-sbc: Add pinctl support for EtherAVB
On Wed, Nov 07, 2018 at 12:06:43PM +, Fabrizio Castro wrote: > From: Biju Das > > Adding pinctrl support for EtherAVB interface. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > Reviewed-by: Geert Uytterhoeven > Signed-off-by: Fabrizio Castro > --- > v4.20 RC1 is out, this update rebases the patch on top of > renesas-devel-20181107-v4.20-rc1 Thanks, applied for v4.21.
Re: [PATCH] [trivial] mfd: tmio: Typo s/use use/use/
On Wed, Nov 07, 2018 at 02:50:01PM +0100, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman > --- > include/linux/mfd/tmio.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h > index 1e70060c92ce0a11..aa696bcb1d12e750 100644 > --- a/include/linux/mfd/tmio.h > +++ b/include/linux/mfd/tmio.h > @@ -83,7 +83,7 @@ > /* Some controllers have a CBSY bit */ > #define TMIO_MMC_HAVE_CBSY BIT(11) > > -/* Some controllers that support HS400 use use 4 taps while others use 8. */ > +/* Some controllers that support HS400 use 4 taps while others use 8. */ > #define TMIO_MMC_HAVE_4TAP_HS400 BIT(13) > > int tmio_core_mmc_enable(void __iomem *cnf, int shift, unsigned long base); > -- > 2.17.1 >
Re: [PATCH LOCAL 1/2] arm64: renesas_defconfig: Drop CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
On Wed, Nov 07, 2018 at 11:17:17AM +0100, Geert Uytterhoeven wrote:
> CONFIG_ARM_BIG_LITTLE_CPUFREQ was removed on arm64 in commit
> a7314405d83c8f95 ("cpufreq: drop ARM_BIG_LITTLE_CPUFREQ support for
> ARM64").
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Not intended for upstream merge.
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 LOCAL 2/2] arm64: renesas_defconfig: Enable CONFIG_PHY_RCAR_GEN3_PCIE
On Wed, Nov 07, 2018 at 11:17:18AM +0100, Geert Uytterhoeven wrote: > Enable R-Car Gen3 PCIe PHY support, which is needed for PCIe to function > on the Renesas Condor board. > > Signed-off-by: Geert Uytterhoeven > --- > Not intended for upstream merge. 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 v2] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
On Wed, Nov 07, 2018 at 06:30:13PM +0200, Laurent Pinchart wrote:
> Hi Simon,
>
> On Tuesday, 6 November 2018 16:00:35 EET Simon Horman wrote:
> > On Mon, Nov 05, 2018 at 02:12:43PM +0100, Jacopo Mondi wrote:
> > > The VIN driver bindings dictates fixed numbering for VIN endpoints
> > > connected to CSI-2 endpoints, even when a single endpoint exists.
> > >
> > > Without proper endpoint numbering the VIN driver fails to probe.
> > >
> > > Based on a patch in BSP from Koji Matsuoka
> > >
> > > Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> > > device nodes") Signed-off-by: Koji Matsuoka
> > >
> > > Signed-off-by: Takeshi Kihara
> > > Signed-off-by: Jacopo Mondi
> > > Reviewed-by: Laurent Pinchart
> >
> > Thanks,
> >
> > This looks fine to me but I will wait to see if there are other reviews
> > before applying.
> >
> > Reviewed-by: Simon Horman
>
> I think you can go ahead and apply it.
Thanks, applied for v4.21.
Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.20
On Wed, Nov 07, 2018 at 08:02:17AM -0800, Olof Johansson wrote: > On Wed, Nov 7, 2018 at 3:25 AM Simon Horman > wrote: > > > > Hi Olof, Hi Kevin, Hi Arnd, > > > > Please consider these Renesas ARM based SoC fixes for v4.20. > > > > > > The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: > > > > Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) > > > > are available in the git repository at: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > > tags/renesas-fixes-for-v4.20 > > > > for you to fetch changes up to eab53fdfd60a84b0cc514d4f1f5d79226c76df01: > > > > arm64: dts: renesas: condor: switch from EtherAVB to GEther (2018-11-05 > > 15:08:44 +0100) > > > > > > Renesas ARM Based SoC Fixes for v4.20 > > > > * R-Car V3H (r8a77980) based Condor board > > - Switch from EtherAVB to GEther to match offical boards > > > > * RZ/G2E (ra8774c0) SoC: correct documentation of part number > > I have to admit, Renesas part numbers have got to be _really_ hard to > deal with for anyone who has even the slightest hint of dyslexia. :-) I have my own problems in this area :) > > > * R-Car H3 (r8a7795) SoC: reinstate all DMA channels on HSCIF2 > > Thanks Simon! I've merged this branch now. Thanks!
Re: [PATCH 2/2] arm64: dts: renesas: r8a774a1: Replace clock magic numbers
On Wed, Nov 07, 2018 at 03:24:27PM +, Fabrizio Castro wrote: > Now that include/dt-bindings/clock/r8a774a1-cpg-mssr.h is in Linus' > master branch we can replace clock related magic numbers with the > corresponding labels. > > Signed-off-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/2] arm64: dts: renesas: r8a774a1: Replace power magic numbers
On Wed, Nov 07, 2018 at 03:24:26PM +, Fabrizio Castro wrote: > Now that include/dt-bindings/power/r8a774a1-sysc.h is in Linus' > master branch we can replace power related magic numbers with > the corresponding labels. > > Signed-off-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 3/4] ARM: dts: r8a77470: Add QSPI support
Hi Fabrizio,
On Thu, Nov 8, 2018 at 11:31 AM Fabrizio Castro
wrote:
> > On Thu, Nov 8, 2018 at 11:22 AM Fabrizio Castro
> > wrote:
> > > > From: Simon Horman
> > > > Sent: 02 November 2018 11:50
> > > > Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
> > > >
> > > > On Thu, Nov 01, 2018 at 12:35:04PM +, Fabrizio Castro wrote:
> > > > > Add QSPI[01] support to the RZ/G1C SoC specific device tree.
> > > > >
> > > > > Signed-off-by: Fabrizio Castro
> > > > > ---
> > > > > arch/arm/boot/dts/r8a77470.dtsi | 34
> > > > > ++
> > > > > 1 file changed, 34 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/r8a77470.dtsi
> > > > > b/arch/arm/boot/dts/r8a77470.dtsi
> > > > > index e6407e5..04a8877 100644
> > > > > --- a/arch/arm/boot/dts/r8a77470.dtsi
> > > > > +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > > > > @@ -20,6 +20,8 @@
> > > > > i2c2 = &i2c2;
> > > > > i2c3 = &i2c3;
> > > > > i2c4 = &i2c4;
> > > > > +spi0 = &qspi0;
> > > > > +spi1 = &qspi1;
> > > > > };
> > > >
> > > > Geert can comment but I believe we are moving away from using aliases
> > > > in this way and that it would be best if the above hunk was dropped
> > > > from this patch.
> > > >
> > > > https://patchwork.kernel.org/patch/10644159/
> > >
> > > Geert, what do you want me to do here?
> >
> > Please drop the aliases. Thanks!
>
> Will do, will send a new version without the additional aliases.
Thanks!
> My understanding is that your personal preference is to only leave debug
> console and ethernet,
Labeled serial ports and primary Ethernet, so U-Boot knows which MAC address
property to update.
> shall I also get rid of what was already upstreamed for RZ/G related boards
> that is not in line
> with the new policy?
I believe these are all serial ports, using aliases that match the documented
and/or labeled port names? So they don't have to be 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
Re: [PATCH] dt-bindings: thermal: rcar-gen3-thermal: All variants use 3 interrupts
On Wed, Nov 07, 2018 at 02:35:00PM +0100, Geert Uytterhoeven wrote:
> RZ/G2M also has 3 interrupts routed to the TSC, but the list was not
> updated to reflect this.
>
> Just drop the list, as this is the case for this TSC variant in all
> R-Car Gen3 and RZ/G2 SoCs.
>
> Fixes: be6af481f3b2d508 ("dt-bindings: thermal: rcar-gen3-thermal: Add
> r8a774a1 support")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
Re: [renesas:arm64-dt-for-v4.21 25/25] Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or path sdhi0 not found
On Wed, Nov 07, 2018 at 03:04:51PM +0100, Marek Vasut wrote: > On 11/07/2018 02:57 PM, kbuild test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > > arm64-dt-for-v4.21 > > head: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c > > commit: 3e8f76c61511f3c4f0c25c36172605d6aeaec37c [25/25] arm64: dts: > > r8a77990: ebisu: Add and enable SDHI device nodes > > config: arm64-defconfig (attached as .config) > > compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > > reproduce: > > wget > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > > ~/bin/make.cross > > chmod +x ~/bin/make.cross > > git checkout 3e8f76c61511f3c4f0c25c36172605d6aeaec37c > > # save the attached .config to linux build tree > > GCC_VERSION=7.2.0 make.cross ARCH=arm64 > > > > All errors (new ones prefixed by >>): > > > >>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:622.1-7 Label or > >>> path sdhi0 not found > >>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:637.1-7 Label or > >>> path sdhi1 not found > >>> Error: arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts:651.1-7 Label or > >>> path sdhi3 not found > >>> FATAL ERROR: Syntax error parsing input tree > > Commit 3e8f76c61511f3c4f0c25c36172605d6aeaec37c seems to be missing the > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 36 + > part from > [PATCH V3] arm64: dts: r8a77990: ebisu: Add and enable SDHI device nodes > thus the error. Sorry about that, will fix ASAP.
RE: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
Hello Geert,
Thank you for your feedback!
> Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
>
> Hi Fabrizio,
>
> On Thu, Nov 8, 2018 at 11:22 AM Fabrizio Castro
> wrote:
> > > From: Simon Horman
> > > Sent: 02 November 2018 11:50
> > > Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
> > >
> > > On Thu, Nov 01, 2018 at 12:35:04PM +, Fabrizio Castro wrote:
> > > > Add QSPI[01] support to the RZ/G1C SoC specific device tree.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > > ---
> > > > arch/arm/boot/dts/r8a77470.dtsi | 34 ++
> > > > 1 file changed, 34 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/r8a77470.dtsi
> > > > b/arch/arm/boot/dts/r8a77470.dtsi
> > > > index e6407e5..04a8877 100644
> > > > --- a/arch/arm/boot/dts/r8a77470.dtsi
> > > > +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > > > @@ -20,6 +20,8 @@
> > > > i2c2 = &i2c2;
> > > > i2c3 = &i2c3;
> > > > i2c4 = &i2c4;
> > > > +spi0 = &qspi0;
> > > > +spi1 = &qspi1;
> > > > };
> > >
> > > Geert can comment but I believe we are moving away from using aliases
> > > in this way and that it would be best if the above hunk was dropped
> > > from this patch.
> > >
> > > https://patchwork.kernel.org/patch/10644159/
> >
> > Geert, what do you want me to do here?
>
> Please drop the aliases. Thanks!
Will do, will send a new version without the additional aliases.
My understanding is that your personal preference is to only leave debug
console and ethernet,
shall I also get rid of what was already upstreamed for RZ/G related boards
that is not in line
with the new policy?
Thanks,
Fab
>
> 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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH/RFT] arm64: dts: renesas: r8a77990: Add I2C-DVFS device node
Hi Simon,
On Thu, Nov 8, 2018 at 11:22 AM Simon Horman wrote:
> On Wed, Nov 07, 2018 at 01:30:10PM +0100, Simon Horman wrote:
> > On Mon, Nov 05, 2018 at 09:52:48AM +0100, Geert Uytterhoeven wrote:
> > > On Sat, Oct 20, 2018 at 11:35 PM Yoshihiro Kaneko
> > > wrote:
> > > > From: Takeshi Kihara
> > > >
> > > > This patch adds I2C-DVFS device node for the R8A77990 SoC.
> > > >
> > > > Signed-off-by: Takeshi Kihara
> > > > Signed-off-by: Yoshihiro Kaneko
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > };
> > > >
> > > > cpus {
> > > > @@ -337,6 +338,22 @@
> > > > reg = <0 0xe606 0 0x508>;
> > > > };
> > > >
> > > > + i2c_dvfs: i2c@e60b {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + compatible = "renesas,iic-r8a77990",
> > >
> > > "renesas,iic-r8a77990" is not yet documented.
> >
> > Thanks, as per my comment below I wonder if as well as documenting
> > "renesas,iic-r8a77990" we also to teach the driver about it.
> >
> > >
> > > > +"renesas,rcar-gen3-iic",
> > > > +"renesas,rmobile-iic";
> > >
> > > Also, IIC on R-Car E3 does not have the automatic transmission registers.
> > > Does this affect claiming compatibility with the family-specific or
> > > generic
> > > compatible values?
> >
> > My cursory reading of the driver indicates that only register that is
> > used by it but documented as not existing on E3 is ICSTART (offset 0x70).
> >
> > It seems to me that we should confirm with Renesas that the register does
> > indeed not exist - as this patch comes from the BSP which implies it is
> > being used there. And if it does not exist we should try teaching the
> > driver not to use ICSTART via the "renesas,iic-r8a77990" compat string.
> > What do you think?
>
> Further examination by Wolfram Sang has shown that the code in question is
> only used on the r8a7740. I don't think there is any compatibility issue
> for r8a77990 when using the current driver.
"When using the current driver".
Do we want to claim compatibility with "renesas,rcar-gen3-iic" and/or
"renesas,rmobile-iic"?
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
