All of lore.kernel.org
 help / color / mirror / Atom feed
From: jacopo mondi <jacopo@jmondi.org>
To: Simon Horman <horms@verge.net.au>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>,
	laurent.pinchart@ideasonboard.com, geert@linux-m68k.org,
	kieran.bingham+renesas@ideasonboard.com,
	niklas.soderlund+renesas@ragnatech.se,
	damm+renesas@opensource.se, ulrich.hecht+renesas@gmail.com,
	linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Date: Tue, 11 Sep 2018 11:44:30 +0200	[thread overview]
Message-ID: <20180911094430.GS28160@w540> (raw)
In-Reply-To: <20180911074448.GQ28160@w540>

[-- Attachment #1: Type: text/plain, Size: 12733 bytes --]

Hi again,
   I actually noticed I'm handling VIN4 and VIN5 un-consistently
here...

On Tue, Sep 11, 2018 at 09:44:48AM +0200, jacopo mondi wrote:
> Hi Simon,
>    thanks for looking into this patch
>
> On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> > On Wed, Sep 05, 2018 at 05:29:42PM +0200, Jacopo Mondi wrote:
> > > This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > > ---
> > >  drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 250 ++++++++++++++++++++++++++++++++++
> > >  1 file changed, 250 insertions(+)
> > >
> > > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > index b81c807..0797940 100644
> > > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > @@ -1831,6 +1831,194 @@ static const unsigned int usb30_id_mux[] = {
> > >  	USB3HS0_ID_MARK,
> > >  };
> > >
> > > +/* - VIN4 ------------------------------------------------------------------- */
> > > +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 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),
> >
> > I am curious to know why the data B pins below (8 - 23)
> > are duplicates of the corresponding data A pins in vin4_data_a_pins.
> >
>
> On R-Car E3 only pins [0-7] of VIN4 interface have an '_a' and '_b'
> options. Pins from [8-23] are "shared".
>
> We can discuss how we want this to be handled, but according to Table
> 6D.5 (pag. 383 of R-Car chip manual revision 1.00) this table is
> correct.
>
> Currently there are two open questions on this PFC patch:
> 1) This one here you reported

It does not end here, I'm sorry.

VIN4 and VIN5 are described differently, it seems to me that we have

vin4_data[0-7]_[a|b]
vin4_data[8-23]
vin4_sync

vin5_data[0-7]_[a|b]
vin5_data[8-15]_a
vin5_sync_a

So I handled it differently, as I've registered the following data groups
for VIN4

> > > +	"vin4_data8_a",
> > > +	"vin4_data10_a",
> > > +	"vin4_data12_a",
> > > +	"vin4_data16_a",
> > > +	"vin4_data20_a",
> > > +	"vin4_data24_a",
> > > +	"vin4_data8_b",
> > > +	"vin4_data10_b",
> > > +	"vin4_data12_b",
> > > +	"vin4_data16_b",
> > > +	"vin4_data20_b",
> > > +	"vin4_data24_b",

And the following ones for VIN5


> > > +	"vin5_data8_a",
> > > +	"vin5_data10_a",
> > > +	"vin5_data12_a",
> > > +	"vin5_data16_a",
> > > +	"vin5_data8_b",

If I would have been doing the same as I did for VIN4, I should have
had "vin5_data10_b", "vin5_data12_b" and so on, with only the first 8
pin being different between all _a and _b groups.

I didn't do that because the VIN5 pins in the [8-15] range have a clear _a
indications, but the more I think about this, the more I think that's
a typographical mistake in the chip manual, and the VIN5 groups should
not have any _a suffix, except for the first 8 pins, where a
corresponding _b group actually exists. Or there is maybe an
explanation why VIN4 and VIN5 are different, but I don't see it right
now...

Thanks
   j


> ... (see below)
>
> > > +		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, 15),
> > > +		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_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[] = {
> > > +	/* HSYNC, VSYNC */
> > > +	RCAR_GP_PIN(2, 25), RCAR_GP_PIN(2, 24),
> > > +};
> > > +
> > > +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(2, 23),
> > > +};
> > > +
> > > +static const unsigned int vin4_field_mux[] = {
> > > +	VI4_FIELD_MARK,
> > > +};
> > > +
> > > +static const unsigned int vin4_clkenb_pins[] = {
> > > +	RCAR_GP_PIN(1, 2),
> > > +};
> > > +
> > > +static const unsigned int vin4_clkenb_mux[] = {
> > > +	VI4_CLKENB_MARK,
> > > +};
> > > +
> > > +static const unsigned int vin4_clk_pins[] = {
> > > +	RCAR_GP_PIN(2, 22),
> > > +};
> > > +
> > > +static const unsigned int vin4_clk_mux[] = {
> > > +	VI4_CLK_MARK,
> > > +};
> > > +
> > > +/* - VIN5 ------------------------------------------------------------------- */
> > > +static const union vin_data vin5_data_a_pins = {
> > > +	.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 = {
> > > +	.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,
> > > +	},
> > > +};
> > > +
> > > +static const union vin_data vin5_data_b_pins = {
> > > +	.data8 = {
> > > +		RCAR_GP_PIN(2, 23), RCAR_GP_PIN(0, 4),
> > > +		RCAR_GP_PIN(0, 7),  RCAR_GP_PIN(0, 12),
> > > +		RCAR_GP_PIN(0, 13), RCAR_GP_PIN(0, 14),
> > > +		RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
> > > +	},
> > > +};
> > > +
> > > +static const union vin_data vin5_data_b_mux = {
> > > +	.data8 = {
> > > +		VI5_DATA0_B_MARK,  VI5_DATA1_B_MARK,
> > > +		VI5_DATA2_B_MARK,  VI5_DATA3_B_MARK,
> > > +		VI5_DATA4_B_MARK,  VI5_DATA5_B_MARK,
> > > +		VI5_DATA6_B_MARK,  VI5_DATA7_B_MARK,
> > > +	},
> > > +};
> > > +
> > > +static const unsigned int vin5_sync_a_pins[] = {
> > > +	/* HSYNC_N, VSYNC_N */
> > > +	RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 9),
> > > +};
> > > +
> > > +static const unsigned int vin5_sync_a_mux[] = {
> > > +	VI5_HSYNC_N_A_MARK, VI5_VSYNC_N_A_MARK,
> > > +};
> > > +
> > > +static const unsigned int vin5_field_a_pins[] = {
> > > +	RCAR_GP_PIN(1, 10),
> > > +};
> > > +
> > > +static const unsigned int vin5_field_a_mux[] = {
> > > +	VI5_FIELD_A_MARK,
> > > +};
> > > +
> > > +static const unsigned int vin5_clkenb_a_pins[] = {
> > > +	RCAR_GP_PIN(0, 1),
> > > +};
> > > +
> > > +static const unsigned int vin5_clkenb_a_mux[] = {
> > > +	VI5_CLKENB_A_MARK,
> > > +};
>
> 2) VIN5 synchronism signals (V/HSYNC, CLKENB, FIELD) are marked as
>    "_A" only, while VIN4 ones have not _A or _B extensions and are
>    shared between _A and _B group. The VIN5_#_A extension is an
>    indication that synchronism signals for group _B are not
>    multiplexed but active be default according to Morimoto-san, that
>    is about to confirm this with HW team. In that case, we need to
>    decide if to provide an 'vin5_sync_b' group anyway to let user
>    select it from DTS. Otherwise it won't be possible to select
>    synchronism pins for VIN5_B group (which is maybe fine if they're
>    not multiplexed at all).
>
> Thanks
>    j
>
> > > +
> > > +static const unsigned int vin5_clk_a_pins[] = {
> > > +	RCAR_GP_PIN(1, 0),
> > > +};
> > > +
> > > +static const unsigned int vin5_clk_a_mux[] = {
> > > +	VI5_CLK_A_MARK,
> > > +};
> > > +
> > > +static const unsigned int vin5_clk_b_pins[] = {
> > > +	RCAR_GP_PIN(2, 22),
> > > +};
> > > +
> > > +static const unsigned int vin5_clk_b_mux[] = {
> > > +	VI5_CLK_B_MARK,
> > > +};
> > > +
> > >  static const struct sh_pfc_pin_group pinmux_groups[] = {
> > >  	SH_PFC_PIN_GROUP(avb_link),
> > >  	SH_PFC_PIN_GROUP(avb_magic),
> > > @@ -1889,6 +2077,32 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
> > >  	SH_PFC_PIN_GROUP(usb0_id),
> > >  	SH_PFC_PIN_GROUP(usb30),
> > >  	SH_PFC_PIN_GROUP(usb30_id),
> > > +	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_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_b, 20),
> > > +	VIN_DATA_PIN_GROUP(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_a, 8),
> > > +	VIN_DATA_PIN_GROUP(vin5_data_a, 10),
> > > +	VIN_DATA_PIN_GROUP(vin5_data_a, 12),
> > > +	VIN_DATA_PIN_GROUP(vin5_data_a, 16),
> > > +	VIN_DATA_PIN_GROUP(vin5_data_b, 8),
> > > +	SH_PFC_PIN_GROUP(vin5_sync_a),
> > > +	SH_PFC_PIN_GROUP(vin5_field_a),
> > > +	SH_PFC_PIN_GROUP(vin5_clkenb_a),
> > > +	SH_PFC_PIN_GROUP(vin5_clk_a),
> > > +	SH_PFC_PIN_GROUP(vin5_clk_b),
> > >  };
> > >
> > >  static const char * const avb_groups[] = {
> > > @@ -1996,6 +2210,40 @@ static const char * const usb30_groups[] = {
> > >  	"usb30_id",
> > >  };
> > >
> > > +static const char * const vin4_groups[] = {
> > > +	"vin4_data8_a",
> > > +	"vin4_data10_a",
> > > +	"vin4_data12_a",
> > > +	"vin4_data16_a",
> > > +	"vin4_data20_a",
> > > +	"vin4_data24_a",
> > > +	"vin4_data8_b",
> > > +	"vin4_data10_b",
> > > +	"vin4_data12_b",
> > > +	"vin4_data16_b",
> > > +	"vin4_data20_b",
> > > +	"vin4_data24_b",
> > > +	"vin4_data8_sft8",
> > > +	"vin4_sync",
> > > +	"vin4_field",
> > > +	"vin4_clkenb",
> > > +	"vin4_clk",
> > > +};
> > > +
> > > +static const char * const vin5_groups[] = {
> > > +	"vin5_data8_a",
> > > +	"vin5_data8_sft8_a",
> > > +	"vin5_data10_a",
> > > +	"vin5_data12_a",
> > > +	"vin5_data16_a",
> > > +	"vin5_data8_b",
> > > +	"vin5_sync_a",
> > > +	"vin5_field_a",
> > > +	"vin5_clkenb_a",
> > > +	"vin5_clk_a",
> > > +	"vin5_clk_b",
> > > +};
> > > +
> > >  static const struct sh_pfc_function pinmux_functions[] = {
> > >  	SH_PFC_FUNCTION(avb),
> > >  	SH_PFC_FUNCTION(i2c1),
> > > @@ -2013,6 +2261,8 @@ static const struct sh_pfc_function pinmux_functions[] = {
> > >  	SH_PFC_FUNCTION(scif_clk),
> > >  	SH_PFC_FUNCTION(usb0),
> > >  	SH_PFC_FUNCTION(usb30),
> > > +	SH_PFC_FUNCTION(vin4),
> > > +	SH_PFC_FUNCTION(vin5),
> > >  };
> > >
> > >  static const struct pinmux_cfg_reg pinmux_config_regs[] = {
> > > --
> > > 2.7.4
> > >



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2018-09-11 14:43 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 15:29 [PATCH/RFT v2 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input Jacopo Mondi
2018-09-05 15:29 ` [PATCH v2 1/8] media: dt-bindings: rcar-vin: Add R8A77990 support Jacopo Mondi
2018-09-10 12:42   ` Simon Horman
2018-09-10 13:58   ` Laurent Pinchart
2018-09-10 18:15   ` Niklas Söderlund
2018-09-05 15:29 ` [PATCH v2 2/8] media: rcar-vin: Add support for R-Car R8A77990 Jacopo Mondi
2018-09-10 14:02   ` Laurent Pinchart
2018-09-10 18:18   ` Niklas Söderlund
2018-09-05 15:29 ` [PATCH v2 3/8] media: dt-bindings: rcar-csi2: Add R8A77990 Jacopo Mondi
2018-09-10 12:45   ` Simon Horman
2018-09-10 14:04   ` Laurent Pinchart
2018-09-10 18:19   ` Niklas Söderlund
2018-09-05 15:29 ` [PATCH v2 4/8] media: rcar-csi2: Add R8A77990 support Jacopo Mondi
2018-09-10 14:05   ` Laurent Pinchart
2018-09-10 18:20   ` Niklas Söderlund
2018-09-05 15:29 ` [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions Jacopo Mondi
2018-09-10 13:01   ` Simon Horman
2018-09-11  7:44     ` jacopo mondi
2018-09-11  8:15       ` Geert Uytterhoeven
2018-09-11  8:54         ` jacopo mondi
2018-09-11  9:44       ` jacopo mondi [this message]
2018-09-28  7:46         ` jacopo mondi
2018-10-02  9:25   ` Geert Uytterhoeven
2018-10-19 16:55     ` jacopo mondi
2018-10-20 19:04       ` Geert Uytterhoeven
2018-09-05 15:29 ` [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes Jacopo Mondi
2018-09-06  9:10   ` Simon Horman
2018-09-06  9:16     ` Simon Horman
2018-09-10 14:12   ` Laurent Pinchart
2018-09-17 14:37     ` Laurent Pinchart
2018-10-30 10:14     ` jacopo mondi
2018-10-30 12:57       ` Laurent Pinchart
2018-10-31 12:48         ` Simon Horman
2018-10-31 13:18           ` jacopo mondi
2018-10-31 14:37             ` Simon Horman
2018-11-05 10:32               ` jacopo mondi
2018-11-06 14:02                 ` Simon Horman
2018-09-05 15:29 ` [PATCH v2 7/8] arm64: dts: r8a77990: Add I2C " Jacopo Mondi
2018-09-05 16:12   ` Laurent Pinchart
2018-09-06  9:12   ` Simon Horman
2018-09-05 15:29 ` [PATCH v2 8/8] arm64: dts: renesas: ebisu: Add HDMI and CVBS input Jacopo Mondi
2018-09-10 14:21   ` Laurent Pinchart
2018-09-12  9:29     ` Simon Horman
2018-09-12 11:08       ` jacopo mondi
2018-09-17  7:09         ` Simon Horman
2018-09-17 15:22 ` [PATCH/RFT v2 0/8] arm64: dts: renesas: Ebisu: " Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180911094430.GS28160@w540 \
    --to=jacopo@jmondi.org \
    --cc=damm+renesas@opensource.se \
    --cc=geert@linux-m68k.org \
    --cc=horms@verge.net.au \
    --cc=jacopo+renesas@jmondi.org \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=ulrich.hecht+renesas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.