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 @@
};
};
+ {
+ pinctrl-0 = <_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;
+ };
+};
+
{
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_MOD 918>;
+ dmas = < 0x17>, < 0x18>,
+ < 0x17>, < 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 918>;
+ status = "disabled";
+ };
+
+ qspi1: spi@ee20 {
+ compatible = "renesas,qspi-r8a77470", "renesas,qspi";
+ reg = <0 0xee20 0 0x2c>;
+ interrupts = ;
+ clocks = < CPG_MOD 917>;
+ dmas = < 0xd1>, < 0xd2>,
+ < 0xd1>, < 0xd2>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A77470_PD_ALWAYS_ON>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ resets = < 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 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 =
serial2 =
};
+
+ clk8snd: clk8snd {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
This is the same clock as cs2000, why not directly refer to 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 = <>, <>;
+ select-gpios = <_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>;
+ };
};
{
@@ -44,6 +83,7 @@
};
{
+ /* U11 */
gpio_exp_74: gpio@74 {
compatible = "ti,tca9539";
reg = <0x74>;
@@ -53,6 +93,13 @@
interrupt-parent = <>;
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 = < 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 = <>;
+ clock-names = "scki";
+
+ VDD1-supply = <_3p3v>;
+ VDD2-supply = <_3p3v>;
+ VCCAD1-supply = <_vcc5v>;
+ VCCAD2-supply = <_vcc5v>;
+ VCCDA1-supply = <_vcc5v>;
+ VCCDA2-supply = <_vcc5v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ pcm3168a_endpoint_p: endpoint {
+ remote-endpoint =
<_endpoint2>;
+
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 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/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 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] [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 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 =
> > > > > > i2c3 =
> > > > > > i2c4 =
> > > > > > +spi0 =
> > > > > > +spi1 =
> > > > > > };
> > > > >
> > > > > 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 =
> > > > > i2c3 =
> > > > > i2c4 =
> > > > > +spi0 =
> > > > > +spi1 =
> > > > > };
> > > >
> > > > 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 =
> > > > i2c3 =
> > > > i2c4 =
> > > > +spi0 =
> > > > +spi1 =
> > > > };
> > >
> > > 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
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 =
> > > i2c3 =
> > > i2c4 =
> > > +spi0 =
> > > +spi1 =
> > > };
> >
> > 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!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH 3/4] ARM: dts: r8a77470: Add QSPI support
Hello Simon,
Thank you for your feedback!
> 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 =
> > i2c3 =
> > i2c4 =
> > +spi0 =
> > +spi1 =
> > };
>
> 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?
Thanks,
Fab
>
> The rest of the patch looks fine to me.
>
> >
> > cpus {
> > @@ -460,6 +462,38 @@
> > status = "disabled";
> > };
> >
> > +qspi0: spi@e6b1 {
> > +compatible = "renesas,qspi-r8a77470", "renesas,qspi";
> > +reg = <0 0xe6b1 0 0x2c>;
> > +interrupts = ;
> > +clocks = < CPG_MOD 918>;
> > +dmas = < 0x17>, < 0x18>,
> > + < 0x17>, < 0x18>;
> > +dma-names = "tx", "rx", "tx", "rx";
> > +power-domains = < R8A77470_PD_ALWAYS_ON>;
> > +num-cs = <1>;
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +resets = < 918>;
> > +status = "disabled";
> > +};
> > +
> > +qspi1: spi@ee20 {
> > +compatible = "renesas,qspi-r8a77470", "renesas,qspi";
> > +reg = <0 0xee20 0 0x2c>;
> > +interrupts = ;
> > +clocks = < CPG_MOD 917>;
> > +dmas = < 0xd1>, < 0xd2>,
> > + < 0xd1>, < 0xd2>;
> > +dma-names = "tx", "rx", "tx", "rx";
> > +power-domains = < R8A77470_PD_ALWAYS_ON>;
> > +num-cs = <1>;
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +resets = < 917>;
> > +status = "disabled";
> > +};
> > +
> > scif0: serial@e6e6 {
> > compatible = "renesas,scif-r8a77470",
> > "renesas,rcar-gen2-scif", "renesas,scif";
> > --
> > 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
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:
> > Hi Kaneko-san,
> >
> > 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
> > > @@ -22,7 +22,8 @@
> > > i2c4 =
> > > i2c5 =
> > > i2c6 =
> > > - i2c7 =
> > > + i2c7 = _dvfs;
> > > + i2c8 =
> >
> > Please don't change existing aliases.
> > While this makes the use of i2c7 for PMIC access uniform across the
> > range of R-Car Gen3 SoCs that have it, I think this is a bad idea, and that
> > it is better not to rely on I2C aliases at all.
> >
> > I guess the BSP did this to configure the BD9571 PMIC for DDR backup
> > mode using i2cset? Upstream has another method, avoiding the need for
> > i2cset, cfr. Documentation/ABI/testing/sysfs-driver-bd9571mwv-regulator.
>
> Dropping the above hung makes sense to me.
>
> Out of interest, what would be the implication of removing
> existing aliases?
>
> >
> > > };
> > >
> > > 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.
>
>
> > > + reg = <0 0xe60b 0 0x34>;
> >
> > Why 0x34? Last (byte-sized) register documented is at 0x14 => 0x15?
>
> I can't explain 0x34 but I agree 0x15 would match the documentation.
>
> >
> > > + interrupts = ;
> > > + clocks = < CPG_MOD 926>;
> > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > + resets = < 926>;
> > > + dmas = < 0x11>, < 0x10>;
> > > + dma-names = "tx", "rx";
> > > + status = "disabled";
> > > + };
> > > +
>
