Hello,
this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
could appear on different sets of pins, usually the 'a' and 'b' one.
With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
VIN_DATA_PIN_GROUP(vin4_data_a, 8)
which results in the group being named as "vin4_data_a_8" which is
un-consistent with the canonical group names (eg. "vin4_data8_a").
This series adds a macro that allows to specify the group 'version' along with
the pin and mux numbers in patch [1/1]. I haven't been able to find a better
term than 'version' as 'group' was already taken. Suggestions welcome.
As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
wired, I made sure the macro creates correct names and fields not only by
compile testing it, but with a small C program [1] that replicates the VIN data
layout defined in the PFC module and access fields (and has helped me testing
more easily the preprocessor stringification/concatenation process).
Final note: Simon, you took the E3 patches in your tree, and I expect them to
land on v4.20-rc1. They use the old macros, are follow up patches ok?)
Thanks
j
[1] https://paste.debian.net/1049603/
Jacopo Mondi (2):
pinctrl: sh-pfc: Introduce VIN_DATA_PIN_GROUP_VER
pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++++++++++++++++++++++++++++++++++
drivers/pinctrl/sh-pfc/sh_pfc.h | 20 ++-
2 files changed, 269 insertions(+), 5 deletions(-)
--
2.7.4
The VIN4 and VIN5 interfaces supports parallel video input.
Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N.
Signed-off-by: Jacopo Mondi <[email protected]>
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++++++++++++++++++++++++++++++++++
1 file changed, 254 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index dfdd982..1aca4b0 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),
+ },
+};
+
+static const union vin_data vin4_data_b_mux = {
+ .data24 = {
+ VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+ 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_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_sync_pins[] = {
+ /* VSYNC_N, HSYNC_N */
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+};
+
+static const unsigned int vin4_sync_mux[] = {
+ VI4_HSYNC_N_MARK, VI4_VSYNC_N_MARK,
+};
+
+static const unsigned int vin4_field_pins[] = {
+ RCAR_GP_PIN(1, 16),
+};
+
+static const unsigned int vin4_field_mux[] = {
+ VI4_FIELD_MARK,
+};
+
+static const unsigned int vin4_clkenb_pins[] = {
+ RCAR_GP_PIN(1, 19),
+};
+
+static const unsigned int vin4_clkenb_mux[] = {
+ VI4_CLKENB_MARK,
+};
+
+static const unsigned int vin4_clk_pins[] = {
+ RCAR_GP_PIN(1, 27),
+};
+
+static const unsigned int vin4_clk_mux[] = {
+ VI4_CLK_MARK,
+};
+
+/* - VIN5 ------------------------------------------------------------------- */
+static const union vin_data vin5_data_pins = {
+ .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 = {
+ .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,
+ },
+};
+
+static const unsigned int vin5_sync_pins[] = {
+ /* VSYNC_N, HSYNC_N */
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 10),
+};
+
+static const unsigned int vin5_sync_mux[] = {
+ VI5_HSYNC_N_MARK, VI5_VSYNC_N_MARK,
+};
+
+static const unsigned int vin5_field_pins[] = {
+ RCAR_GP_PIN(1, 11),
+};
+
+static const unsigned int vin5_field_mux[] = {
+ VI5_FIELD_MARK,
+};
+
+static const unsigned int vin5_clkenb_pins[] = {
+ RCAR_GP_PIN(1, 20),
+};
+
+static const unsigned int vin5_clkenb_mux[] = {
+ VI5_CLKENB_MARK,
+};
+
+static const unsigned int vin5_clk_pins[] = {
+ RCAR_GP_PIN(1, 21),
+};
+
+static const unsigned int vin5_clk_mux[] = {
+ VI5_CLK_MARK,
+};
+
static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(audio_clk_a_a),
SH_PFC_PIN_GROUP(audio_clk_a_b),
@@ -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_VER(vin4_data, a, 8),
+ VIN_DATA_PIN_GROUP_VER(vin4_data, a, 16),
+ SH_PFC_PIN_GROUP(vin4_data18_a),
+ VIN_DATA_PIN_GROUP_VER(vin4_data, a, 24),
+ VIN_DATA_PIN_GROUP_VER(vin4_data, b, 8),
+ VIN_DATA_PIN_GROUP_VER(vin4_data, b, 16),
+ SH_PFC_PIN_GROUP(vin4_data18_b),
+ VIN_DATA_PIN_GROUP_VER(vin4_data, b, 24),
+ 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),
+ 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",
+ "vin4_sync",
+ "vin4_field",
+ "vin4_clkenb",
+ "vin4_clk",
+};
+
+static const char * const vin5_groups[] = {
+ "vin5_data8",
+ "vin5_data16",
+ "vin5_sync",
+ "vin5_field",
+ "vin5_clkenb",
+ "vin5_clk",
+};
+
static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(audio_clk),
SH_PFC_FUNCTION(avb),
@@ -4432,6 +4684,8 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(usb0),
SH_PFC_FUNCTION(usb1),
SH_PFC_FUNCTION(usb30),
+ SH_PFC_FUNCTION(vin4),
+ SH_PFC_FUNCTION(vin5),
};
static const struct pinmux_cfg_reg pinmux_config_regs[] = {
--
2.7.4
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 names not consistent
with the ones defined using SH_PFC_PIN_GROUP() macro.
Fix this by adding a macro that supports appending suffixes when required.
Signed-off-by: Jacopo Mondi <[email protected]>
---
drivers/pinctrl/sh-pfc/sh_pfc.h | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 458ae0a..2930e9a 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -54,17 +54,27 @@ 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,
+ * while VIN_DATA_PIN_GROUP_VER() is used when the same pin group can appear
+ * on different sets of pins.
*/
-#define VIN_DATA_PIN_GROUP(n, s) \
- { \
- .name = #n#s, \
+#define __VIN_DATA_PIN_GROUP(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, \
+ __VIN_DATA_PIN_GROUP(n, s)
+
+#define VIN_DATA_PIN_GROUP_VER(n, v, s) \
+ { \
+ .name = #n#s"_"#v, \
+ __VIN_DATA_PIN_GROUP(n##_##v, s)
+
union vin_data {
unsigned int data24[24];
unsigned int data20[20];
--
2.7.4
> On October 29, 2018 at 7:13 PM Jacopo Mondi <[email protected]> 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 names not consistent
> with the ones defined using SH_PFC_PIN_GROUP() macro.
>
> Fix this by adding a macro that supports appending suffixes when required.
>
> Signed-off-by: Jacopo Mondi <[email protected]>
> ---
> drivers/pinctrl/sh-pfc/sh_pfc.h | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
> index 458ae0a..2930e9a 100644
> --- a/drivers/pinctrl/sh-pfc/sh_pfc.h
> +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
> @@ -54,17 +54,27 @@ 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,
Maybe fix the odd spacing, while you're at it?
> + * while VIN_DATA_PIN_GROUP_VER() is used when the same pin group can appear
> + * on different sets of pins.
> */
> -#define VIN_DATA_PIN_GROUP(n, s) \
> - { \
> - .name = #n#s, \
> +#define __VIN_DATA_PIN_GROUP(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, \
> + __VIN_DATA_PIN_GROUP(n, s)
> +
> +#define VIN_DATA_PIN_GROUP_VER(n, v, s) \
> + { \
> + .name = #n#s"_"#v, \
> + __VIN_DATA_PIN_GROUP(n##_##v, s)
> +
> union vin_data {
> unsigned int data24[24];
> unsigned int data20[20];
> --
> 2.7.4
>
With or without the whitespace fix:
Reviewed-by: Ulrich Hecht <[email protected]>
CU
Uli
Thank you for your patch.
> On October 29, 2018 at 7:13 PM Jacopo Mondi <[email protected]> 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.
>
> Signed-off-by: Jacopo Mondi <[email protected]>
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++++++++++++++++++++++++++++++++++
> 1 file changed, 254 insertions(+)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
> index dfdd982..1aca4b0 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),
> + },
> +};
> +
> +static const union vin_data vin4_data_b_mux = {
> + .data24 = {
> + VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
> + 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_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_sync_pins[] = {
> + /* VSYNC_N, HSYNC_N */
> + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> +};
> +
> +static const unsigned int vin4_sync_mux[] = {
> + VI4_HSYNC_N_MARK, VI4_VSYNC_N_MARK,
> +};
> +
> +static const unsigned int vin4_field_pins[] = {
> + RCAR_GP_PIN(1, 16),
> +};
> +
> +static const unsigned int vin4_field_mux[] = {
> + VI4_FIELD_MARK,
> +};
> +
> +static const unsigned int vin4_clkenb_pins[] = {
> + RCAR_GP_PIN(1, 19),
> +};
> +
> +static const unsigned int vin4_clkenb_mux[] = {
> + VI4_CLKENB_MARK,
> +};
> +
> +static const unsigned int vin4_clk_pins[] = {
> + RCAR_GP_PIN(1, 27),
> +};
> +
> +static const unsigned int vin4_clk_mux[] = {
> + VI4_CLK_MARK,
> +};
> +
> +/* - VIN5 ------------------------------------------------------------------- */
> +static const union vin_data vin5_data_pins = {
> + .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 = {
> + .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,
> + },
> +};
> +
> +static const unsigned int vin5_sync_pins[] = {
> + /* VSYNC_N, HSYNC_N */
> + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 10),
> +};
> +
> +static const unsigned int vin5_sync_mux[] = {
> + VI5_HSYNC_N_MARK, VI5_VSYNC_N_MARK,
> +};
> +
> +static const unsigned int vin5_field_pins[] = {
> + RCAR_GP_PIN(1, 11),
> +};
> +
> +static const unsigned int vin5_field_mux[] = {
> + VI5_FIELD_MARK,
> +};
> +
> +static const unsigned int vin5_clkenb_pins[] = {
> + RCAR_GP_PIN(1, 20),
> +};
> +
> +static const unsigned int vin5_clkenb_mux[] = {
> + VI5_CLKENB_MARK,
> +};
> +
> +static const unsigned int vin5_clk_pins[] = {
> + RCAR_GP_PIN(1, 21),
> +};
> +
> +static const unsigned int vin5_clk_mux[] = {
> + VI5_CLK_MARK,
> +};
> +
> static const struct sh_pfc_pin_group pinmux_groups[] = {
> SH_PFC_PIN_GROUP(audio_clk_a_a),
> SH_PFC_PIN_GROUP(audio_clk_a_b),
> @@ -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_VER(vin4_data, a, 8),
> + VIN_DATA_PIN_GROUP_VER(vin4_data, a, 16),
> + SH_PFC_PIN_GROUP(vin4_data18_a),
> + VIN_DATA_PIN_GROUP_VER(vin4_data, a, 24),
> + VIN_DATA_PIN_GROUP_VER(vin4_data, b, 8),
> + VIN_DATA_PIN_GROUP_VER(vin4_data, b, 16),
> + SH_PFC_PIN_GROUP(vin4_data18_b),
> + VIN_DATA_PIN_GROUP_VER(vin4_data, b, 24),
> + 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),
> + 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",
> + "vin4_sync",
> + "vin4_field",
> + "vin4_clkenb",
> + "vin4_clk",
> +};
> +
> +static const char * const vin5_groups[] = {
> + "vin5_data8",
> + "vin5_data16",
> + "vin5_sync",
> + "vin5_field",
> + "vin5_clkenb",
> + "vin5_clk",
> +};
> +
> static const struct sh_pfc_function pinmux_functions[] = {
> SH_PFC_FUNCTION(audio_clk),
> SH_PFC_FUNCTION(avb),
> @@ -4432,6 +4684,8 @@ static const struct sh_pfc_function pinmux_functions[] = {
> SH_PFC_FUNCTION(usb0),
> SH_PFC_FUNCTION(usb1),
> SH_PFC_FUNCTION(usb30),
> + SH_PFC_FUNCTION(vin4),
> + SH_PFC_FUNCTION(vin5),
> };
>
> static const struct pinmux_cfg_reg pinmux_config_regs[] = {
> --
> 2.7.4
>
Reviewed-by: Ulrich Hecht <[email protected]>
CU
Uli
Hi Uli,
On Tue, Oct 30, 2018 at 04:46:26AM +0100, Ulrich Hecht wrote:
>
> > On October 29, 2018 at 7:13 PM Jacopo Mondi <[email protected]> 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 names not consistent
> > with the ones defined using SH_PFC_PIN_GROUP() macro.
> >
> > Fix this by adding a macro that supports appending suffixes when required.
> >
> > Signed-off-by: Jacopo Mondi <[email protected]>
> > ---
> > drivers/pinctrl/sh-pfc/sh_pfc.h | 20 +++++++++++++++-----
> > 1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
> > index 458ae0a..2930e9a 100644
> > --- a/drivers/pinctrl/sh-pfc/sh_pfc.h
> > +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
> > @@ -54,17 +54,27 @@ 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,
>
> Maybe fix the odd spacing, while you're at it?
Ups, I have missed it.
Thanks, I'll wait for more feedbacks and add your tag to the next
version.
Thanks
j
>
> > + * while VIN_DATA_PIN_GROUP_VER() is used when the same pin group can appear
> > + * on different sets of pins.
> > */
> > -#define VIN_DATA_PIN_GROUP(n, s) \
> > - { \
> > - .name = #n#s, \
> > +#define __VIN_DATA_PIN_GROUP(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, \
> > + __VIN_DATA_PIN_GROUP(n, s)
> > +
> > +#define VIN_DATA_PIN_GROUP_VER(n, v, s) \
> > + { \
> > + .name = #n#s"_"#v, \
> > + __VIN_DATA_PIN_GROUP(n##_##v, s)
> > +
> > union vin_data {
> > unsigned int data24[24];
> > unsigned int data20[20];
> > --
> > 2.7.4
> >
>
> With or without the whitespace fix:
>
> Reviewed-by: Ulrich Hecht <[email protected]>
>
> CU
> Uli
Hi Jacopo,
On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <[email protected]> wrote:
> this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
>
> On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> could appear on different sets of pins, usually the 'a' and 'b' one.
>
> With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
>
> VIN_DATA_PIN_GROUP(vin4_data_a, 8)
>
> which results in the group being named as "vin4_data_a_8" which is
> un-consistent with the canonical group names (eg. "vin4_data8_a").
>
> This series adds a macro that allows to specify the group 'version' along with
> the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> term than 'version' as 'group' was already taken. Suggestions welcome.
Yeah, the datasheet also calls these groups :-(
A possible alternative is to use "variant"?
Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
macro varargs, and passing the "variant" as the (optional) third parameter?
That way existing users work as a before, while you can also write e.g.
VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
> As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> wired, I made sure the macro creates correct names and fields not only by
> compile testing it, but with a small C program [1] that replicates the VIN data
> layout defined in the PFC module and access fields (and has helped me testing
> more easily the preprocessor stringification/concatenation process).
>
> Final note: Simon, you took the E3 patches in your tree, and I expect them to
> land on v4.20-rc1. They use the old macros, are follow up patches ok?)
Which patches are using these macro names, and are in v4.20-rc1?
BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
have broken groups names on r8a7792, r8a7795, and r8a7796.
Fortunately we have no known users of them, so they can be fixed.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Geert,
On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <[email protected]> wrote:
> > this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> >
> > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > could appear on different sets of pins, usually the 'a' and 'b' one.
> >
> > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> >
> > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> >
> > which results in the group being named as "vin4_data_a_8" which is
> > un-consistent with the canonical group names (eg. "vin4_data8_a").
> >
> > This series adds a macro that allows to specify the group 'version' along with
> > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > term than 'version' as 'group' was already taken. Suggestions welcome.
>
> Yeah, the datasheet also calls these groups :-(
> A possible alternative is to use "variant"?
>
> Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> macro varargs, and passing the "variant" as the (optional) third parameter?
> That way existing users work as a before, while you can also write e.g.
>
> VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
Indeed.
Would something along the following lines fly for you?
#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), \
}
It can be used as:
VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
VIN_DATA_PIN_GROUP(vin5_data, 8),
With your ack on this, I'll send v2.
Thanks
j
>
> > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > wired, I made sure the macro creates correct names and fields not only by
> > compile testing it, but with a small C program [1] that replicates the VIN data
> > layout defined in the PFC module and access fields (and has helped me testing
> > more easily the preprocessor stringification/concatenation process).
> >
> > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
>
> Which patches are using these macro names, and are in v4.20-rc1?
>
> BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> have broken groups names on r8a7792, r8a7795, and r8a7796.
> Fortunately we have no known users of them, so they can be fixed.
>
On v4.20-rc1 the grep returns none for me :/
git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
Thanks
j
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> 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
Hi Jacopo,
On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi <[email protected]> wrote:
> On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <[email protected]> wrote:
> > > this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> > >
> > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > >
> > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> > >
> > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > >
> > > which results in the group being named as "vin4_data_a_8" which is
> > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > >
> > > This series adds a macro that allows to specify the group 'version' along with
> > > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > > term than 'version' as 'group' was already taken. Suggestions welcome.
> >
> > Yeah, the datasheet also calls these groups :-(
> > A possible alternative is to use "variant"?
> >
> > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > macro varargs, and passing the "variant" as the (optional) third parameter?
> > That way existing users work as a before, while you can also write e.g.
> >
> > VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
>
> Indeed.
>
> Would something along the following lines fly for you?
>
> #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), \
> }
>
> It can be used as:
> VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> VIN_DATA_PIN_GROUP(vin5_data, 8),
>
> With your ack on this, I'll send v2.
Thank you, that is exactly what I had in mind.
> > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > wired, I made sure the macro creates correct names and fields not only by
> > > compile testing it, but with a small C program [1] that replicates the VIN data
> > > layout defined in the PFC module and access fields (and has helped me testing
> > > more easily the preprocessor stringification/concatenation process).
> > >
> > > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> >
> > Which patches are using these macro names, and are in v4.20-rc1?
> >
> > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > Fortunately we have no known users of them, so they can be fixed.
> >
>
> On v4.20-rc1 the grep returns none for me :/
> git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
I grepped the .o files, to make sure it would see the final strings, which
obviously works in the build tree only ;-)
For the source tree, please try:
git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Geert,
On Tue, Nov 06, 2018 at 10:24:30AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi <[email protected]> wrote:
> > On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <[email protected]> wrote:
> > > > this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> > > >
> > > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > > >
> > > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> > > >
> > > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > > >
> > > > which results in the group being named as "vin4_data_a_8" which is
> > > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > > >
> > > > This series adds a macro that allows to specify the group 'version' along with
> > > > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > > > term than 'version' as 'group' was already taken. Suggestions welcome.
> > >
> > > Yeah, the datasheet also calls these groups :-(
> > > A possible alternative is to use "variant"?
> > >
> > > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > > macro varargs, and passing the "variant" as the (optional) third parameter?
> > > That way existing users work as a before, while you can also write e.g.
> > >
> > > VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
> >
> > Indeed.
> >
> > Would something along the following lines fly for you?
> >
> > #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), \
> > }
> >
> > It can be used as:
> > VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> > VIN_DATA_PIN_GROUP(vin5_data, 8),
> >
> > With your ack on this, I'll send v2.
>
> Thank you, that is exactly what I had in mind.
>
> > > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > > wired, I made sure the macro creates correct names and fields not only by
> > > > compile testing it, but with a small C program [1] that replicates the VIN data
> > > > layout defined in the PFC module and access fields (and has helped me testing
> > > > more easily the preprocessor stringification/concatenation process).
> > > >
> > > > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> > >
> > > Which patches are using these macro names, and are in v4.20-rc1?
> > >
> > > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> > > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > > Fortunately we have no known users of them, so they can be fixed.
> > >
> >
> > On v4.20-rc1 the grep returns none for me :/
> > git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
>
> I grepped the .o files, to make sure it would see the final strings, which
> obviously works in the build tree only ;-)
Ah yes, stupid me.
>
> For the source tree, please try:
>
> git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1
Argh, there are quite a few of them, but fortunately no users so far.
Is it ok fixing them in v2 of this series with follow-up patches, or
would you like a single patch that introduces the variadic macro and
replaces all the occurrences in the per-SoC PFC modules in one go?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> 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
Hi Jacopo,
(sorry, seems I prepared a reply, but forgot to press "Send")
On Tue, Nov 6, 2018 at 10:31 AM jacopo mondi <[email protected]> wrote:
> On Tue, Nov 06, 2018 at 10:24:30AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi <[email protected]> wrote:
> > > On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > > > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <[email protected]> wrote:
> > > > > this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> > > > >
> > > > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > > > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > > > >
> > > > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> > > > >
> > > > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > > > >
> > > > > which results in the group being named as "vin4_data_a_8" which is
> > > > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > > > >
> > > > > This series adds a macro that allows to specify the group 'version' along with
> > > > > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > > > > term than 'version' as 'group' was already taken. Suggestions welcome.
> > > >
> > > > Yeah, the datasheet also calls these groups :-(
> > > > A possible alternative is to use "variant"?
> > > >
> > > > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > > > macro varargs, and passing the "variant" as the (optional) third parameter?
> > > > That way existing users work as a before, while you can also write e.g.
> > > >
> > > > VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
> > >
> > > Indeed.
> > >
> > > Would something along the following lines fly for you?
> > >
> > > #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), \
> > > }
> > >
> > > It can be used as:
> > > VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> > > VIN_DATA_PIN_GROUP(vin5_data, 8),
> > >
> > > With your ack on this, I'll send v2.
> >
> > Thank you, that is exactly what I had in mind.
> >
> > > > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > > > wired, I made sure the macro creates correct names and fields not only by
> > > > > compile testing it, but with a small C program [1] that replicates the VIN data
> > > > > layout defined in the PFC module and access fields (and has helped me testing
> > > > > more easily the preprocessor stringification/concatenation process).
> > > > >
> > > > > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > > > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> > > >
> > > > Which patches are using these macro names, and are in v4.20-rc1?
> > > >
> > > > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> > > > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > > > Fortunately we have no known users of them, so they can be fixed.
> > > >
> > >
> > > On v4.20-rc1 the grep returns none for me :/
> > > git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
> >
> > I grepped the .o files, to make sure it would see the final strings, which
> > obviously works in the build tree only ;-)
>
> Ah yes, stupid me.
>
> >
> > For the source tree, please try:
> >
> > git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1
>
> Argh, there are quite a few of them, but fortunately no users so far.
>
> Is it ok fixing them in v2 of this series with follow-up patches, or
> would you like a single patch that introduces the variadic macro and
> replaces all the occurrences in the per-SoC PFC modules in one go?
Given the r8a7795 and r8a7796 issues were introduced in v4.17:
a5c2949ff7bd9e04 ("pinctrl: sh-pfc: r8a7796: Deduplicate VIN4 pin
definitions")
9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
definitions")
while the r8a7792 issue date back to v4.9:
7dd74bb1f058786e ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
I think separate patches are easier for backporting.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Geert,
On Wed, Nov 07, 2018 at 09:39:35AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> (sorry, seems I prepared a reply, but forgot to press "Send")
>
> On Tue, Nov 6, 2018 at 10:31 AM jacopo mondi <[email protected]> wrote:
> > On Tue, Nov 06, 2018 at 10:24:30AM +0100, Geert Uytterhoeven wrote:
> > > On Tue, Nov 6, 2018 at 10:08 AM jacopo mondi <[email protected]> wrote:
> > > > On Mon, Nov 05, 2018 at 06:19:22PM +0100, Geert Uytterhoeven wrote:
> > > > > On Mon, Oct 29, 2018 at 7:14 PM Jacopo Mondi <[email protected]> wrote:
> > > > > > this two patches add supports for VIN4 and VIN5 interfaces to R-Car M3-N.
> > > > > >
> > > > > > On this SoC (and in the forthcoming support for E3 R8A77990) the VIN groups
> > > > > > could appear on different sets of pins, usually the 'a' and 'b' one.
> > > > > >
> > > > > > With the existing VIN_DATA_PIN_GROUP macro we have to specify group names as:
> > > > > >
> > > > > > VIN_DATA_PIN_GROUP(vin4_data_a, 8)
> > > > > >
> > > > > > which results in the group being named as "vin4_data_a_8" which is
> > > > > > un-consistent with the canonical group names (eg. "vin4_data8_a").
> > > > > >
> > > > > > This series adds a macro that allows to specify the group 'version' along with
> > > > > > the pin and mux numbers in patch [1/1]. I haven't been able to find a better
> > > > > > term than 'version' as 'group' was already taken. Suggestions welcome.
> > > > >
> > > > > Yeah, the datasheet also calls these groups :-(
> > > > > A possible alternative is to use "variant"?
> > > > >
> > > > > Or, what about avoiding the name issue by making the VIN_DATA_PIN_GROUP()
> > > > > macro varargs, and passing the "variant" as the (optional) third parameter?
> > > > > That way existing users work as a before, while you can also write e.g.
> > > > >
> > > > > VIN_DATA_PIN_GROUP_VER(vin4_data, 8, _a),
> > > >
> > > > Indeed.
> > > >
> > > > Would something along the following lines fly for you?
> > > >
> > > > #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), \
> > > > }
> > > >
> > > > It can be used as:
> > > > VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
> > > > VIN_DATA_PIN_GROUP(vin5_data, 8),
> > > >
> > > > With your ack on this, I'll send v2.
> > >
> > > Thank you, that is exactly what I had in mind.
> > >
> > > > > > As I cannot test VIN4 nor VIN5 on Salvator-XS as the parallel pins are not
> > > > > > wired, I made sure the macro creates correct names and fields not only by
> > > > > > compile testing it, but with a small C program [1] that replicates the VIN data
> > > > > > layout defined in the PFC module and access fields (and has helped me testing
> > > > > > more easily the preprocessor stringification/concatenation process).
> > > > > >
> > > > > > Final note: Simon, you took the E3 patches in your tree, and I expect them to
> > > > > > land on v4.20-rc1. They use the old macros, are follow up patches ok?)
> > > > >
> > > > > Which patches are using these macro names, and are in v4.20-rc1?
> > > > >
> > > > > BTW, "grep vin._data_[a-z][0-9] drivers/pinctrl/sh-pfc/*o" tells me we already
> > > > > have broken groups names on r8a7792, r8a7795, and r8a7796.
> > > > > Fortunately we have no known users of them, so they can be fixed.
> > > > >
> > > >
> > > > On v4.20-rc1 the grep returns none for me :/
> > > > git grep v4.20-rc1 "vin._data_[a-z][0-9]" drivers/pinctrl/sh-pfc/
> > >
> > > I grepped the .o files, to make sure it would see the final strings, which
> > > obviously works in the build tree only ;-)
> >
> > Ah yes, stupid me.
> >
> > >
> > > For the source tree, please try:
> > >
> > > git grep -w VIN_DATA_PIN_GROUP.*_[a-z] v4.20-rc1
> >
> > Argh, there are quite a few of them, but fortunately no users so far.
> >
> > Is it ok fixing them in v2 of this series with follow-up patches, or
> > would you like a single patch that introduces the variadic macro and
> > replaces all the occurrences in the per-SoC PFC modules in one go?
>
> Given the r8a7795 and r8a7796 issues were introduced in v4.17:
>
> a5c2949ff7bd9e04 ("pinctrl: sh-pfc: r8a7796: Deduplicate VIN4 pin
> definitions")
> 9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
> definitions")
>
> while the r8a7792 issue date back to v4.9:
>
> 7dd74bb1f058786e ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
>
> I think separate patches are easier for backporting.
Fine, I've sent yesterday:
"[PATCH v4 0/4] sh-pfc: Variadic VIN_DATA_PIN_GROUP macro + updates"
which includes: "pinctrl: sh-pfc: Fix VIN versioned groups name" that
changes all users of VIN_DATA_PIN_GROUP in one go.
I'll split that and re-send.
Before resending, if there are comments on:
"pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions" and
"pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions"
which are included in that very same series, I'll like to address
them before sending v5 out.
Thanks
j
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> 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