* Re: [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support
2013-08-07 4:06 [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support Kuninori Morimoto
@ 2013-08-21 8:47 ` Simon Horman
2013-08-21 20:50 ` Linus Walleij
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Simon Horman @ 2013-08-21 8:47 UTC (permalink / raw)
To: linux-sh
[ CC Laurent and Linux ]
On Tue, Aug 06, 2013 at 09:06:19PM -0700, Kuninori Morimoto wrote:
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 163 ++++++++++++++++++++++++++++++++++
> 1 file changed, 163 insertions(+)
Laurent, this looks like it should be reviewed by you and
then taken through Linus's tree.
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
> index 428d2a6..a1bc846 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
> @@ -1304,6 +1304,22 @@ SH_PFC_MUX1(ether_link, ETH_LINK);
> SH_PFC_PINS(ether_magic, RCAR_GP_PIN(4, 20));
> SH_PFC_MUX1(ether_magic, ETH_MAGIC);
>
> +/* - AUDIO macro -------------------------------------------------------------*/
> +#define AUDIO_PFC_PIN(name, pin) SH_PFC_PINS(name, pin)
> +#define AUDIO_PFC_DAT(name, pin) SH_PFC_MUX1(name, pin)
> +
> +/* - AUDIO clock -------------------------------------------------------------*/
> +AUDIO_PFC_PIN(audio_clk_a, RCAR_GP_PIN(2, 22));
> +AUDIO_PFC_DAT(audio_clk_a, AUDIO_CLKA);
> +AUDIO_PFC_PIN(audio_clk_b, RCAR_GP_PIN(2, 23));
> +AUDIO_PFC_DAT(audio_clk_b, AUDIO_CLKB);
> +AUDIO_PFC_PIN(audio_clk_c, RCAR_GP_PIN(2, 7));
> +AUDIO_PFC_DAT(audio_clk_c, AUDIO_CLKC);
> +AUDIO_PFC_PIN(audio_clkout_a, RCAR_GP_PIN(2, 16));
> +AUDIO_PFC_DAT(audio_clkout_a, AUDIO_CLKOUT_A);
> +AUDIO_PFC_PIN(audio_clkout_b, RCAR_GP_PIN(1, 16));
> +AUDIO_PFC_DAT(audio_clkout_b, AUDIO_CLKOUT_B);
> +
> /* - SCIF macro ------------------------------------------------------------- */
> #define SCIF_PFC_PIN(name, args...) SH_PFC_PINS(name, args)
> #define SCIF_PFC_DAT(name, tx, rx) SH_PFC_MUX2(name, tx, rx)
> @@ -1577,6 +1593,105 @@ SDHI_PFC_WPPN(sdhi2_wp_a, SD2_WP_A);
> SDHI_PFC_PINS(sdhi2_wp_b, RCAR_GP_PIN(3, 28));
> SDHI_PFC_WPPN(sdhi2_wp_b, SD2_WP_B);
>
> +/* - SSI macro -------------------------------------------------------------- */
> +#define SSI_PFC_PINS(name, args...) SH_PFC_PINS(name, args)
> +#define SSI_PFC_SETS(name, sck, ws, d) SH_PFC_MUX3(name, sck, ws, d)
> +#define SSI_PFC_MULT(name, sck, ws, d1, d2) SH_PFC_MUX4(name, sck, ws,\
> + d1, d2)
> +/* - SSI0 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi0, RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> + RCAR_GP_PIN(3, 10));
> +SSI_PFC_SETS(ssi0, SSI_SCK012, SSI_WS012,
> + SSI_SDATA0);
> +
> +/* - SSI01 -------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi01, RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> + RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 9));
> +SSI_PFC_MULT(ssi01, SSI_SCK012, SSI_WS012,
> + SSI_SDATA0, SSI_SDATA1);
> +
> +/* - SSI012 -------------------------------------------------------------------*/
> +static const unsigned ssi012_pins[] = {
> + RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> + RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 9),
> + RCAR_GP_PIN(3, 8),
> +};
> +
> +static const unsigned int ssi012_mux[] = {
> + SSI_SCK012_MARK, SSI_WS012_MARK,
> + SSI_SDATA0_MARK, SSI_SDATA1_MARK,
> + SSI_SDATA2_MARK,
> +};
> +
> +/* - SSI02 -------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi02, RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> + RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 8));
> +SSI_PFC_MULT(ssi02, SSI_SCK012, SSI_WS012,
> + SSI_SDATA0, SSI_SDATA2);
> +
> +/* - SSI1 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi1_a, RCAR_GP_PIN(2, 20), RCAR_GP_PIN(2, 21),
> + RCAR_GP_PIN(3, 9));
> +SSI_PFC_SETS(ssi1_a, SSI_SCK1_A, SSI_WS1_A,
> + SSI_SDATA1);
> +SSI_PFC_PINS(ssi1_b, PIN_NUMBER(3, 20), RCAR_GP_PIN(1, 3),
> + RCAR_GP_PIN(3, 9));
> +SSI_PFC_SETS(ssi1_b, SSI_SCK1_B, SSI_WS1_B,
> + SSI_SDATA1);
> +
> +/* - SSI2 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi2_a, RCAR_GP_PIN(2, 26), RCAR_GP_PIN(3, 4),
> + RCAR_GP_PIN(3, 8));
> +SSI_PFC_SETS(ssi2_a, SSI_SCK2_A, SSI_WS2_A,
> + SSI_SDATA2);
> +
> +SSI_PFC_PINS(ssi2_b, RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 17),
> + RCAR_GP_PIN(3, 8));
> +SSI_PFC_SETS(ssi2_b, SSI_SCK2_B, SSI_WS2_B,
> + SSI_SDATA2);
> +
> +/* - SSI3 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi3, RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
> + RCAR_GP_PIN(3, 5));
> +SSI_PFC_SETS(ssi3, SSI_SCK34, SSI_WS34,
> + SSI_SDATA3);
> +
> +/* - SSI34 -------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi34, RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
> + RCAR_GP_PIN(3, 5), RCAR_GP_PIN(3, 4));
> +SSI_PFC_MULT(ssi34, SSI_SCK34, SSI_WS34,
> + SSI_SDATA3, SSI_SDATA4);
> +
> +/* - SSI4 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi4, RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 23),
> + RCAR_GP_PIN(3, 4));
> +SSI_PFC_SETS(ssi4, SSI_SCK4, SSI_WS4,
> + SSI_SDATA4);
> +
> +/* - SSI5 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi5, RCAR_GP_PIN(2, 31), RCAR_GP_PIN(3, 0),
> + RCAR_GP_PIN(3, 1));
> +SSI_PFC_SETS(ssi5, SSI_SCK5, SSI_WS5,
> + SSI_SDATA5);
> +
> +/* - SSI6 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi6, RCAR_GP_PIN(2, 28), RCAR_GP_PIN(2, 29),
> + RCAR_GP_PIN(2, 30));
> +SSI_PFC_SETS(ssi6, SSI_SCK6, SSI_WS6,
> + SSI_SDATA6);
> +
> +/* - SSI7 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi7, RCAR_GP_PIN(2, 24), RCAR_GP_PIN(2, 25),
> + RCAR_GP_PIN(2, 27));
> +SSI_PFC_SETS(ssi7, SSI_SCK78, SSI_WS78,
> + SSI_SDATA7);
> +
> +/* - SSI78 --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi78, RCAR_GP_PIN(2, 24), RCAR_GP_PIN(2, 25),
> + RCAR_GP_PIN(2, 27), RCAR_GP_PIN(2, 26));
> +SSI_PFC_MULT(ssi78, SSI_SCK78, SSI_WS78,
> + SSI_SDATA7, SSI_SDATA8);
> +
> /* - USB0 ------------------------------------------------------------------- */
> SH_PFC_PINS(usb0, RCAR_GP_PIN(0, 1));
> SH_PFC_MUX1(usb0, PENC0);
> @@ -1624,6 +1739,11 @@ VIN_PFC_PINS(vin1_sync, RCAR_GP_PIN(3, 21), RCAR_GP_PIN(3, 22));
> VIN_PFC_SYNC(vin1_sync, VI1_HSYNC, VI1_VSYNC);
>
> static const struct sh_pfc_pin_group pinmux_groups[] = {
> + SH_PFC_PIN_GROUP(audio_clk_a),
> + SH_PFC_PIN_GROUP(audio_clk_b),
> + SH_PFC_PIN_GROUP(audio_clk_c),
> + SH_PFC_PIN_GROUP(audio_clkout_a),
> + SH_PFC_PIN_GROUP(audio_clkout_b),
> SH_PFC_PIN_GROUP(ether_rmii),
> SH_PFC_PIN_GROUP(ether_link),
> SH_PFC_PIN_GROUP(ether_magic),
> @@ -1713,6 +1833,21 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
> SH_PFC_PIN_GROUP(sdhi2_data4_b),
> SH_PFC_PIN_GROUP(sdhi2_wp_a),
> SH_PFC_PIN_GROUP(sdhi2_wp_b),
> + SH_PFC_PIN_GROUP(ssi0),
> + SH_PFC_PIN_GROUP(ssi01),
> + SH_PFC_PIN_GROUP(ssi012),
> + SH_PFC_PIN_GROUP(ssi02),
> + SH_PFC_PIN_GROUP(ssi1_a),
> + SH_PFC_PIN_GROUP(ssi1_b),
> + SH_PFC_PIN_GROUP(ssi2_a),
> + SH_PFC_PIN_GROUP(ssi2_b),
> + SH_PFC_PIN_GROUP(ssi3),
> + SH_PFC_PIN_GROUP(ssi34),
> + SH_PFC_PIN_GROUP(ssi4),
> + SH_PFC_PIN_GROUP(ssi5),
> + SH_PFC_PIN_GROUP(ssi6),
> + SH_PFC_PIN_GROUP(ssi7),
> + SH_PFC_PIN_GROUP(ssi78),
> SH_PFC_PIN_GROUP(usb0),
> SH_PFC_PIN_GROUP(usb0_ovc),
> SH_PFC_PIN_GROUP(usb1),
> @@ -1725,6 +1860,14 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
> SH_PFC_PIN_GROUP(vin1_sync),
> };
>
> +static const char * const audio_clk_groups[] = {
> + "audio_clk_a",
> + "audio_clk_b",
> + "audio_clk_c",
> + "audio_clkout_a",
> + "audio_clkout_b",
> +};
> +
> static const char * const ether_groups[] = {
> "ether_rmii",
> "ether_link",
> @@ -1875,6 +2018,24 @@ static const char * const sdhi2_groups[] = {
> "sdhi2_wp_b",
> };
>
> +static const char * const ssi_groups[] = {
> + "ssi0",
> + "ssi01",
> + "ssi012",
> + "ssi02",
> + "ssi1_a",
> + "ssi1_b",
> + "ssi2_a",
> + "ssi2_b",
> + "ssi3",
> + "ssi34",
> + "ssi4",
> + "ssi5",
> + "ssi6",
> + "ssi7",
> + "ssi78",
> +};
> +
> static const char * const usb0_groups[] = {
> "usb0",
> "usb0_ovc",
> @@ -1898,6 +2059,7 @@ static const char * const vin1_groups[] = {
> };
>
> static const struct sh_pfc_function pinmux_functions[] = {
> + SH_PFC_FUNCTION(audio_clk),
> SH_PFC_FUNCTION(ether),
> SH_PFC_FUNCTION(hscif0),
> SH_PFC_FUNCTION(hscif1),
> @@ -1918,6 +2080,7 @@ static const struct sh_pfc_function pinmux_functions[] = {
> SH_PFC_FUNCTION(sdhi0),
> SH_PFC_FUNCTION(sdhi1),
> SH_PFC_FUNCTION(sdhi2),
> + SH_PFC_FUNCTION(ssi),
> SH_PFC_FUNCTION(usb0),
> SH_PFC_FUNCTION(usb1),
> SH_PFC_FUNCTION(vin0),
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support
2013-08-07 4:06 [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support Kuninori Morimoto
2013-08-21 8:47 ` Simon Horman
@ 2013-08-21 20:50 ` Linus Walleij
2013-08-22 0:19 ` Simon Horman
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Linus Walleij @ 2013-08-21 20:50 UTC (permalink / raw)
To: linux-sh
On Wed, Aug 21, 2013 at 10:47 AM, Simon Horman <horms@verge.net.au> wrote:
> [ CC Laurent and Linux ]
That misspelling again :-)
> On Tue, Aug 06, 2013 at 09:06:19PM -0700, Kuninori Morimoto wrote:
>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> ---
>> drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 163 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 163 insertions(+)
>
> Laurent, this looks like it should be reviewed by you and
> then taken through Linus's tree.
Fine with me, but can we atleast have it resent with me on the To-line
or atleast Cc? I don't know if I'm even on the list where it was sent.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support
2013-08-07 4:06 [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support Kuninori Morimoto
2013-08-21 8:47 ` Simon Horman
2013-08-21 20:50 ` Linus Walleij
@ 2013-08-22 0:19 ` Simon Horman
2013-08-22 1:28 ` Laurent Pinchart
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Simon Horman @ 2013-08-22 0:19 UTC (permalink / raw)
To: linux-sh
On Wed, Aug 21, 2013 at 10:50:48PM +0200, Linus Walleij wrote:
> On Wed, Aug 21, 2013 at 10:47 AM, Simon Horman <horms@verge.net.au> wrote:
>
> > [ CC Laurent and Linux ]
>
> That misspelling again :-)
Sorry.
> > On Tue, Aug 06, 2013 at 09:06:19PM -0700, Kuninori Morimoto wrote:
> >> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >> ---
> >> drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 163 ++++++++++++++++++++++++++++++++++
> >> 1 file changed, 163 insertions(+)
> >
> > Laurent, this looks like it should be reviewed by you and
> > then taken through Linus's tree.
>
> Fine with me, but can we atleast have it resent with me on the To-line
> or atleast Cc? I don't know if I'm even on the list where it was sent.
Sure.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support
2013-08-07 4:06 [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support Kuninori Morimoto
` (2 preceding siblings ...)
2013-08-22 0:19 ` Simon Horman
@ 2013-08-22 1:28 ` Laurent Pinchart
2013-08-22 4:46 ` Kuninori Morimoto
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Laurent Pinchart @ 2013-08-22 1:28 UTC (permalink / raw)
To: linux-sh
Hi Morimoto-san,
Thank you for the patch.
On Tuesday 06 August 2013 21:06:19 Kuninori Morimoto wrote:
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 163 +++++++++++++++++++++++++++++++
> 1 file changed, 163 insertions(+)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
> b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c index 428d2a6..a1bc846 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
> @@ -1304,6 +1304,22 @@ SH_PFC_MUX1(ether_link, ETH_LINK);
> SH_PFC_PINS(ether_magic, RCAR_GP_PIN(4, 20));
> SH_PFC_MUX1(ether_magic, ETH_MAGIC);
>
> +/* - AUDIO macro ------------------------------------------------------- */
> +#define AUDIO_PFC_PIN(name, pin) SH_PFC_PINS(name, pin)
> +#define AUDIO_PFC_DAT(name, pin) SH_PFC_MUX1(name, pin)
> +
> +/* - AUDIO clock --------------------------------------------------------*/
> +AUDIO_PFC_PIN(audio_clk_a, RCAR_GP_PIN(2, 22));
> +AUDIO_PFC_DAT(audio_clk_a, AUDIO_CLKA);
> +AUDIO_PFC_PIN(audio_clk_b, RCAR_GP_PIN(2, 23));
> +AUDIO_PFC_DAT(audio_clk_b, AUDIO_CLKB);
> +AUDIO_PFC_PIN(audio_clk_c, RCAR_GP_PIN(2, 7));
> +AUDIO_PFC_DAT(audio_clk_c, AUDIO_CLKC);
> +AUDIO_PFC_PIN(audio_clkout_a, RCAR_GP_PIN(2, 16));
> +AUDIO_PFC_DAT(audio_clkout_a, AUDIO_CLKOUT_A);
> +AUDIO_PFC_PIN(audio_clkout_b, RCAR_GP_PIN(1, 16));
> +AUDIO_PFC_DAT(audio_clkout_b, AUDIO_CLKOUT_B);
> +
Could you please move this block up to keep the blocks alphabetically sorted ?
> /* - SCIF macro -------------------------------------------------------- */
> #define SCIF_PFC_PIN(name, args...) SH_PFC_PINS(name, args)
> #define SCIF_PFC_DAT(name, tx, rx) SH_PFC_MUX2(name, tx, rx)
> @@ -1577,6 +1593,105 @@ SDHI_PFC_WPPN(sdhi2_wp_a, SD2_WP_A);
> SDHI_PFC_PINS(sdhi2_wp_b, RCAR_GP_PIN(3, 28));
> SDHI_PFC_WPPN(sdhi2_wp_b, SD2_WP_B);
>
> +/* - SSI macro --------------------------------------------------------- */
> +#define SSI_PFC_PINS(name, args...) SH_PFC_PINS(name, args)
> +#define SSI_PFC_SETS(name, sck, ws, d) SH_PFC_MUX3(name, sck, ws, d)
> +#define SSI_PFC_MULT(name, sck, ws, d1, d2) SH_PFC_MUX4(name, sck, ws,\
> + d1, d2)
> +/* - SSI0
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi0, RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> + RCAR_GP_PIN(3, 10));
> +SSI_PFC_SETS(ssi0, SSI_SCK012, SSI_WS012,
> + SSI_SDATA0);
> +
> +/* - SSI01 --------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi01, RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> + RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 9));
> +SSI_PFC_MULT(ssi01, SSI_SCK012, SSI_WS012,
> + SSI_SDATA0, SSI_SDATA1);
> +
> +/* - SSI012 -------------------------------------------------------------*/
> +static const unsigned ssi012_pins[] = {
> + RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> + RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 9),
> + RCAR_GP_PIN(3, 8),
> +};
> +
> +static const unsigned int ssi012_mux[] = {
> + SSI_SCK012_MARK, SSI_WS012_MARK,
> + SSI_SDATA0_MARK, SSI_SDATA1_MARK,
> + SSI_SDATA2_MARK,
> +};
> +
> +/* - SSI02
> -------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi02, RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> + RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 8));
> +SSI_PFC_MULT(ssi02, SSI_SCK012, SSI_WS012,
> + SSI_SDATA0, SSI_SDATA2);
This looks a bit complex to me. Could you please explain how the various pins
are used ? I see that the SSI_DATA1 and SSI_DATA2 signals are used here and
below. What are the possible combinations ? For instance, if I select ssi02,
will SDATA0 and SDATA2 be driven by the SSI0 instance, or by the SSI0 and SSI2
instances respectively ?
> +
> +/* - SSI1
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi1_a, RCAR_GP_PIN(2, 20), RCAR_GP_PIN(2, 21),
> + RCAR_GP_PIN(3, 9));
> +SSI_PFC_SETS(ssi1_a, SSI_SCK1_A, SSI_WS1_A,
> + SSI_SDATA1);
> +SSI_PFC_PINS(ssi1_b, PIN_NUMBER(3, 20), RCAR_GP_PIN(1, 3),
> + RCAR_GP_PIN(3, 9));
> +SSI_PFC_SETS(ssi1_b, SSI_SCK1_B, SSI_WS1_B,
> + SSI_SDATA1);
> +
> +/* - SSI2
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi2_a, RCAR_GP_PIN(2, 26), RCAR_GP_PIN(3, 4),
> + RCAR_GP_PIN(3, 8));
> +SSI_PFC_SETS(ssi2_a, SSI_SCK2_A, SSI_WS2_A,
> + SSI_SDATA2);
> +
> +SSI_PFC_PINS(ssi2_b, RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 17),
> + RCAR_GP_PIN(3, 8));
> +SSI_PFC_SETS(ssi2_b, SSI_SCK2_B, SSI_WS2_B,
> + SSI_SDATA2);
> +
> +/* - SSI3
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi3, RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
> + RCAR_GP_PIN(3, 5));
> +SSI_PFC_SETS(ssi3, SSI_SCK34, SSI_WS34,
> + SSI_SDATA3);
> +
> +/* - SSI34
> -------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi34, RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
> + RCAR_GP_PIN(3, 5), RCAR_GP_PIN(3, 4));
> +SSI_PFC_MULT(ssi34, SSI_SCK34, SSI_WS34,
> + SSI_SDATA3, SSI_SDATA4);
Can SSI_SDATA4 be used without SSI_SDATA3 ? Same question for SSI_DATA7 and
SSI_DATA8 below.
> +/* - SSI4
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi4, RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 23),
> + RCAR_GP_PIN(3, 4));
> +SSI_PFC_SETS(ssi4, SSI_SCK4, SSI_WS4,
> + SSI_SDATA4);
> +
> +/* - SSI5
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi5, RCAR_GP_PIN(2, 31), RCAR_GP_PIN(3, 0),
> + RCAR_GP_PIN(3, 1));
> +SSI_PFC_SETS(ssi5, SSI_SCK5, SSI_WS5,
> + SSI_SDATA5);
> +
> +/* - SSI6
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi6, RCAR_GP_PIN(2, 28), RCAR_GP_PIN(2, 29),
> + RCAR_GP_PIN(2, 30));
> +SSI_PFC_SETS(ssi6, SSI_SCK6, SSI_WS6,
> + SSI_SDATA6);
> +
> +/* - SSI7
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi7, RCAR_GP_PIN(2, 24), RCAR_GP_PIN(2, 25),
> + RCAR_GP_PIN(2, 27));
> +SSI_PFC_SETS(ssi7, SSI_SCK78, SSI_WS78,
> + SSI_SDATA7);
> +
> +/* - SSI78
> --------------------------------------------------------------------*/
> +SSI_PFC_PINS(ssi78, RCAR_GP_PIN(2, 24), RCAR_GP_PIN(2, 25),
> + RCAR_GP_PIN(2, 27), RCAR_GP_PIN(2, 26));
> +SSI_PFC_MULT(ssi78, SSI_SCK78, SSI_WS78,
> + SSI_SDATA7, SSI_SDATA8);
> +
> /* - USB0
> ------------------------------------------------------------------- */
> SH_PFC_PINS(usb0, RCAR_GP_PIN(0, 1));
> SH_PFC_MUX1(usb0, PENC0);
> @@ -1624,6 +1739,11 @@ VIN_PFC_PINS(vin1_sync, RCAR_GP_PIN(3,
> 21), RCAR_GP_PIN(3, 22)); VIN_PFC_SYNC(vin1_sync, VI1_HSYNC,
VI1_VSYNC);
>
> static const struct sh_pfc_pin_group pinmux_groups[] = {
> + SH_PFC_PIN_GROUP(audio_clk_a),
> + SH_PFC_PIN_GROUP(audio_clk_b),
> + SH_PFC_PIN_GROUP(audio_clk_c),
> + SH_PFC_PIN_GROUP(audio_clkout_a),
> + SH_PFC_PIN_GROUP(audio_clkout_b),
> SH_PFC_PIN_GROUP(ether_rmii),
> SH_PFC_PIN_GROUP(ether_link),
> SH_PFC_PIN_GROUP(ether_magic),
> @@ -1713,6 +1833,21 @@ static const struct sh_pfc_pin_group pinmux_groups[]
> = { SH_PFC_PIN_GROUP(sdhi2_data4_b),
> SH_PFC_PIN_GROUP(sdhi2_wp_a),
> SH_PFC_PIN_GROUP(sdhi2_wp_b),
> + SH_PFC_PIN_GROUP(ssi0),
> + SH_PFC_PIN_GROUP(ssi01),
> + SH_PFC_PIN_GROUP(ssi012),
> + SH_PFC_PIN_GROUP(ssi02),
> + SH_PFC_PIN_GROUP(ssi1_a),
> + SH_PFC_PIN_GROUP(ssi1_b),
> + SH_PFC_PIN_GROUP(ssi2_a),
> + SH_PFC_PIN_GROUP(ssi2_b),
> + SH_PFC_PIN_GROUP(ssi3),
> + SH_PFC_PIN_GROUP(ssi34),
> + SH_PFC_PIN_GROUP(ssi4),
> + SH_PFC_PIN_GROUP(ssi5),
> + SH_PFC_PIN_GROUP(ssi6),
> + SH_PFC_PIN_GROUP(ssi7),
> + SH_PFC_PIN_GROUP(ssi78),
> SH_PFC_PIN_GROUP(usb0),
> SH_PFC_PIN_GROUP(usb0_ovc),
> SH_PFC_PIN_GROUP(usb1),
> @@ -1725,6 +1860,14 @@ static const struct sh_pfc_pin_group pinmux_groups[]
> = { SH_PFC_PIN_GROUP(vin1_sync),
> };
>
> +static const char * const audio_clk_groups[] = {
> + "audio_clk_a",
> + "audio_clk_b",
> + "audio_clk_c",
> + "audio_clkout_a",
> + "audio_clkout_b",
> +};
> +
> static const char * const ether_groups[] = {
> "ether_rmii",
> "ether_link",
> @@ -1875,6 +2018,24 @@ static const char * const sdhi2_groups[] = {
> "sdhi2_wp_b",
> };
>
> +static const char * const ssi_groups[] = {
> + "ssi0",
> + "ssi01",
> + "ssi012",
> + "ssi02",
> + "ssi1_a",
> + "ssi1_b",
> + "ssi2_a",
> + "ssi2_b",
> + "ssi3",
> + "ssi34",
> + "ssi4",
> + "ssi5",
> + "ssi6",
> + "ssi7",
> + "ssi78",
> +};
I'm not familiar with SSI so I could be wrong, but shouldn't we have one group
per SSI instance ?
> +
> static const char * const usb0_groups[] = {
> "usb0",
> "usb0_ovc",
> @@ -1898,6 +2059,7 @@ static const char * const vin1_groups[] = {
> };
>
> static const struct sh_pfc_function pinmux_functions[] = {
> + SH_PFC_FUNCTION(audio_clk),
> SH_PFC_FUNCTION(ether),
> SH_PFC_FUNCTION(hscif0),
> SH_PFC_FUNCTION(hscif1),
> @@ -1918,6 +2080,7 @@ static const struct sh_pfc_function pinmux_functions[]
> = { SH_PFC_FUNCTION(sdhi0),
> SH_PFC_FUNCTION(sdhi1),
> SH_PFC_FUNCTION(sdhi2),
> + SH_PFC_FUNCTION(ssi),
> SH_PFC_FUNCTION(usb0),
> SH_PFC_FUNCTION(usb1),
> SH_PFC_FUNCTION(vin0),
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support
2013-08-07 4:06 [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support Kuninori Morimoto
` (3 preceding siblings ...)
2013-08-22 1:28 ` Laurent Pinchart
@ 2013-08-22 4:46 ` Kuninori Morimoto
2013-08-22 11:02 ` Laurent Pinchart
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Kuninori Morimoto @ 2013-08-22 4:46 UTC (permalink / raw)
To: linux-sh
Hi Laurent
Thank you for your review
> > +/* - AUDIO clock --------------------------------------------------------*/
> > +AUDIO_PFC_PIN(audio_clk_a, RCAR_GP_PIN(2, 22));
> > +AUDIO_PFC_DAT(audio_clk_a, AUDIO_CLKA);
> > +AUDIO_PFC_PIN(audio_clk_b, RCAR_GP_PIN(2, 23));
> > +AUDIO_PFC_DAT(audio_clk_b, AUDIO_CLKB);
> > +AUDIO_PFC_PIN(audio_clk_c, RCAR_GP_PIN(2, 7));
> > +AUDIO_PFC_DAT(audio_clk_c, AUDIO_CLKC);
> > +AUDIO_PFC_PIN(audio_clkout_a, RCAR_GP_PIN(2, 16));
> > +AUDIO_PFC_DAT(audio_clkout_a, AUDIO_CLKOUT_A);
> > +AUDIO_PFC_PIN(audio_clkout_b, RCAR_GP_PIN(1, 16));
> > +AUDIO_PFC_DAT(audio_clkout_b, AUDIO_CLKOUT_B);
> > +
>
> Could you please move this block up to keep the blocks alphabetically sorted ?
Oops indeed.
Thank you. I will fix it in v2
> > +/* - SSI02
> > -------------------------------------------------------------------*/
> > +SSI_PFC_PINS(ssi02, RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> > + RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 8));
> > +SSI_PFC_MULT(ssi02, SSI_SCK012, SSI_WS012,
> > + SSI_SDATA0, SSI_SDATA2);
>
> This looks a bit complex to me. Could you please explain how the various pins
> are used ? I see that the SSI_DATA1 and SSI_DATA2 signals are used here and
> below. What are the possible combinations ? For instance, if I select ssi02,
> will SDATA0 and SDATA2 be driven by the SSI0 instance, or by the SSI0 and SSI2
> instances respectively ?
Can you check datasheet ?
[Sound Routing Unit] has SSI image
SSI1, SSI2 can use (share) SSI0's pin (= SSI012)
Yes, SSI is very confusable device/pins
> > +/* - SSI34
> > -------------------------------------------------------------------*/
> > +SSI_PFC_PINS(ssi34, RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
> > + RCAR_GP_PIN(3, 5), RCAR_GP_PIN(3, 4));
> > +SSI_PFC_MULT(ssi34, SSI_SCK34, SSI_WS34,
> > + SSI_SDATA3, SSI_SDATA4);
>
> Can SSI_SDATA4 be used without SSI_SDATA3 ? Same question for SSI_DATA7 and
> SSI_DATA8 below.
Yes, you can use SSI4 without SSI3.
You can select SSI4 only in that case.
SSI34 is sharing pins case for SSI3/SSI4
> > +static const char * const ssi_groups[] = {
> > + "ssi0",
> > + "ssi01",
> > + "ssi012",
> > + "ssi02",
> > + "ssi1_a",
> > + "ssi1_b",
> > + "ssi2_a",
> > + "ssi2_b",
> > + "ssi3",
> > + "ssi34",
> > + "ssi4",
> > + "ssi5",
> > + "ssi6",
> > + "ssi7",
> > + "ssi78",
> > +};
>
> I'm not familiar with SSI so I could be wrong, but shouldn't we have one group
> per SSI instance ?
Current pinctrl map is like below
PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
"ssi01", "ssi"),
Do you want like this ?
PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
"sck", "ssi01"),
But hmm...
this style can solve above complex SSIxyz settings ?
- separate data / ctrl pin
- select these each
PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
"ssi01_ctrl", "ssi"),
PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
"ssi0_data", "ssi"),
PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
"ssi1_data", "ssi"),
Best regards
---
Kuninori Morimoto
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support
2013-08-07 4:06 [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support Kuninori Morimoto
` (4 preceding siblings ...)
2013-08-22 4:46 ` Kuninori Morimoto
@ 2013-08-22 11:02 ` Laurent Pinchart
2013-08-23 0:51 ` Kuninori Morimoto
2013-08-23 11:16 ` Laurent Pinchart
7 siblings, 0 replies; 9+ messages in thread
From: Laurent Pinchart @ 2013-08-22 11:02 UTC (permalink / raw)
To: linux-sh
Hi Morimoto-san,
On Wednesday 21 August 2013 21:46:04 Kuninori Morimoto wrote:
[snip]
> > > +/* - SSI02
> > > -------------------------------------------------------------------*/
> > > +SSI_PFC_PINS(ssi02, RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
> > > + RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 8));
> > > +SSI_PFC_MULT(ssi02, SSI_SCK012, SSI_WS012,
> > > + SSI_SDATA0, SSI_SDATA2);
> >
> > This looks a bit complex to me. Could you please explain how the various
> > pins are used ? I see that the SSI_DATA1 and SSI_DATA2 signals are used
> > here and below. What are the possible combinations ? For instance, if I
> > select ssi02, will SDATA0 and SDATA2 be driven by the SSI0 instance, or
> > by the SSI0 and SSI2 instances respectively ?
>
> Can you check datasheet ?
> [Sound Routing Unit] has SSI image
> SSI1, SSI2 can use (share) SSI0's pin (= SSI012)
>
> Yes, SSI is very confusable device/pins
The only copy of the datasheet I have access to is in Japanese, so it's a bit
hard to understand for me :-)
We seem to have three pin sharing groups: SSI0/1/2, SSI3/4 and SSI7/8.
SSI7 and SSI8 have a single set of SCK and WS pins called SCK78 and WS78. What
are the possible combinations here ? I can think of
- SSI7 alone with (SCK78, WS78, SDATA7)
- SSI8 alone with (SCK78, WS78, SDATA8)
- SSI7 and SSI8 together with (SCK78, WS78, SDATA7, SDATA8) using a single set
of shared SCK and WS signals, driven by either SSI7 or SSI8
For SSI3 and SSI4, I can think of more combinations:
- SSI3 alone with (SCK34, WS34, SDATA3)
- SSI4 alone with (SCK4, WS4, SDATA4)
- SSI4 alone with (SCK34, WS34, SDATA4)
- SSI3 and SSI4 together with (SCK34, WS34, SDATA3) for SSI3 and (SCK4, WS4,
SDATA4) for SSI4
- SSI3 and SSI4 together with (SCK34, WS34, SDATA3, SDATA4) using a single set
of shared SCK and WS signals, driven by either SSI3 or SSI4
- SSI3 and SSI4 together with (SCK4, WS4, SDATA3, SDATA4) using a single set
of shared SCK and WS signals, driven by either SSI3 or SSI4
SSI0/1/2 is even more complex.
Could you please tell me which of the above combinations is supported ? Based
on that we can divide the pins into proper groups.
[snip]
> > > +static const char * const ssi_groups[] = {
> > > + "ssi0",
> > > + "ssi01",
> > > + "ssi012",
> > > + "ssi02",
> > > + "ssi1_a",
> > > + "ssi1_b",
> > > + "ssi2_a",
> > > + "ssi2_b",
> > > + "ssi3",
> > > + "ssi34",
> > > + "ssi4",
> > > + "ssi5",
> > > + "ssi6",
> > > + "ssi7",
> > > + "ssi78",
> > > +};
> >
> > I'm not familiar with SSI so I could be wrong, but shouldn't we have one
> > group per SSI instance ?
>
> Current pinctrl map is like below
>
> PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> "ssi01", "ssi"),
>
> Do you want like this ?
>
> PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> "sck", "ssi01"),
>
> But hmm...
> this style can solve above complex SSIxyz settings ?
> - separate data / ctrl pin
> - select these each
>
> PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> "ssi01_ctrl", "ssi"),
> PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> "ssi0_data", "ssi"),
> PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> "ssi1_data", "ssi"),
The answer to this depends on what combinations are supported by the hardware.
Let's first discuss that, and then decide how to divide pins in pin groups.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support
2013-08-07 4:06 [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support Kuninori Morimoto
` (5 preceding siblings ...)
2013-08-22 11:02 ` Laurent Pinchart
@ 2013-08-23 0:51 ` Kuninori Morimoto
2013-08-23 11:16 ` Laurent Pinchart
7 siblings, 0 replies; 9+ messages in thread
From: Kuninori Morimoto @ 2013-08-23 0:51 UTC (permalink / raw)
To: linux-sh
Hi Laurent
> The only copy of the datasheet I have access to is in Japanese, so it's a bit
> hard to understand for me :-)
Oops
> We seem to have three pin sharing groups: SSI0/1/2, SSI3/4 and SSI7/8.
>
> SSI7 and SSI8 have a single set of SCK and WS pins called SCK78 and WS78. What
> are the possible combinations here ? I can think of
>
> - SSI7 alone with (SCK78, WS78, SDATA7)
> - SSI8 alone with (SCK78, WS78, SDATA8)
> - SSI7 and SSI8 together with (SCK78, WS78, SDATA7, SDATA8) using a single set
> of shared SCK and WS signals, driven by either SSI7 or SSI8
>
> For SSI3 and SSI4, I can think of more combinations:
>
> - SSI3 alone with (SCK34, WS34, SDATA3)
> - SSI4 alone with (SCK4, WS4, SDATA4)
> - SSI4 alone with (SCK34, WS34, SDATA4)
> - SSI3 and SSI4 together with (SCK34, WS34, SDATA3) for SSI3 and (SCK4, WS4,
> SDATA4) for SSI4
> - SSI3 and SSI4 together with (SCK34, WS34, SDATA3, SDATA4) using a single set
> of shared SCK and WS signals, driven by either SSI3 or SSI4
> - SSI3 and SSI4 together with (SCK4, WS4, SDATA3, SDATA4) using a single set
> of shared SCK and WS signals, driven by either SSI3 or SSI4
>
> SSI0/1/2 is even more complex.
>
> Could you please tell me which of the above combinations is supported ? Based
> on that we can divide the pins into proper groups.
Sorry for my confusable explain.
I can try to explain about this.
The image is like this
* can be shared pin
* SSI0
SSI1 (can use SSI0 SCK/WS pin)
SSI2 (can use SSI0 SCK/WS pin)
* SSI3
SSI4 (can use SSI3 SCK/WS pin)
SSI5
SSI6
* SSI7
SSI8 (can use SSI7 SCK/WS pin)
For example, in SSI3/SSI4 case, there are 2 patterns
1) alone pattern
SSI3 with SCK34, WS34, SDATA3
SSI4 with SCK4, WS4, SDATA4
2) share pattern
SSI3 with SCK34, WS34, SDATA3
SSI4 with SCK34, WS34, SDATA4
SSI4 can use (share) SSI3's SCK/WS pin,
and share SCK or WS only doesn't happen.
And, SSI8 is very special. it always uses shared pin.
(can't be alone)
The pattern for SSI7/SSI8 are...
1) alone pattern
SSI7 with SCK78, WS78, SDATA7
2) share pattern
SSI7 with SCK78, WS78, SDATA7
SSI8 with SCK78, WS78, SDATA8
> > But hmm...
> > this style can solve above complex SSIxyz settings ?
> > - separate data / ctrl pin
> > - select these each
> >
> > PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> > "ssi01_ctrl", "ssi"),
> > PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> > "ssi0_data", "ssi"),
> > PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> > "ssi1_data", "ssi"),
>
> The answer to this depends on what combinations are supported by the hardware.
> Let's first discuss that, and then decide how to divide pins in pin groups.
OK
From SSI4 point of view, the DATA4 is fixed,
and it can select SCK / WS pin from SSI4 (= alone) or SSI3 (= share)
Best regards
---
Kuninori Morimoto
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support
2013-08-07 4:06 [PATCH 1/5] sh-pfc: r8a7778: add SRU/SSI pin support Kuninori Morimoto
` (6 preceding siblings ...)
2013-08-23 0:51 ` Kuninori Morimoto
@ 2013-08-23 11:16 ` Laurent Pinchart
7 siblings, 0 replies; 9+ messages in thread
From: Laurent Pinchart @ 2013-08-23 11:16 UTC (permalink / raw)
To: linux-sh
Hi Morimoto-san,
On Thursday 22 August 2013 17:51:20 Kuninori Morimoto wrote:
> Hi Laurent
>
> > The only copy of the datasheet I have access to is in Japanese, so it's a
> > bit hard to understand for me :-)
>
> Oops
>
> > We seem to have three pin sharing groups: SSI0/1/2, SSI3/4 and SSI7/8.
> >
> > SSI7 and SSI8 have a single set of SCK and WS pins called SCK78 and WS78.
> > What are the possible combinations here ? I can think of
> >
> > - SSI7 alone with (SCK78, WS78, SDATA7)
> > - SSI8 alone with (SCK78, WS78, SDATA8)
> > - SSI7 and SSI8 together with (SCK78, WS78, SDATA7, SDATA8) using a single
> > set of shared SCK and WS signals, driven by either SSI7 or SSI8
> >
> > For SSI3 and SSI4, I can think of more combinations:
> >
> > - SSI3 alone with (SCK34, WS34, SDATA3)
> > - SSI4 alone with (SCK4, WS4, SDATA4)
> > - SSI4 alone with (SCK34, WS34, SDATA4)
> > - SSI3 and SSI4 together with (SCK34, WS34, SDATA3) for SSI3 and (SCK4,
> > WS4, SDATA4) for SSI4
> > - SSI3 and SSI4 together with (SCK34, WS34, SDATA3, SDATA4) using a single
> > set of shared SCK and WS signals, driven by either SSI3 or SSI4
> > - SSI3 and SSI4 together with (SCK4, WS4, SDATA3, SDATA4) using a single
> > set of shared SCK and WS signals, driven by either SSI3 or SSI4
> >
> > SSI0/1/2 is even more complex.
> >
> > Could you please tell me which of the above combinations is supported ?
> > Based on that we can divide the pins into proper groups.
>
> Sorry for my confusable explain.
> I can try to explain about this.
>
> The image is like this
> * can be shared pin
>
> * SSI0
> SSI1 (can use SSI0 SCK/WS pin)
> SSI2 (can use SSI0 SCK/WS pin)
>
> * SSI3
> SSI4 (can use SSI3 SCK/WS pin)
>
> SSI5
> SSI6
>
> * SSI7
> SSI8 (can use SSI7 SCK/WS pin)
I can pretty much understand the image from the datasheet, it's just the
Japanese text that I have trouble understanding :-)
> For example, in SSI3/SSI4 case, there are 2 patterns
>
> 1) alone pattern
> SSI3 with SCK34, WS34, SDATA3
> SSI4 with SCK4, WS4, SDATA4
>
> 2) share pattern
> SSI3 with SCK34, WS34, SDATA3
> SSI4 with SCK34, WS34, SDATA4
>
> SSI4 can use (share) SSI3's SCK/WS pin,
> and share SCK or WS only doesn't happen.
Can you also use SSI4 alone (without SSI3) with SCK34, WS34 and SDATA4 ?
> And, SSI8 is very special. it always uses shared pin.
> (can't be alone)
> The pattern for SSI7/SSI8 are...
>
> 1) alone pattern
> SSI7 with SCK78, WS78, SDATA7
>
> 2) share pattern
> SSI7 with SCK78, WS78, SDATA7
> SSI8 with SCK78, WS78, SDATA8
Same question, can you use SSI8 alone with SCK78, WS78 and SDATA8 ?
> > > But hmm...
> > > this style can solve above complex SSIxyz settings ?
> > >
> > > - separate data / ctrl pin
> > > - select these each
> > >
> > > PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> > > "ssi01_ctrl", "ssi"),
> > > PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> > > "ssi0_data", "ssi"),
> > > PIN_MAP_MUX_GROUP_DEFAULT("rcar_sound", "pfc-r8a7778",
> > > "ssi1_data", "ssi"),
> >
> > The answer to this depends on what combinations are supported by the
> > hardware. Let's first discuss that, and then decide how to divide pins in
> > pin groups.
>
> OK
>
> From SSI4 point of view, the DATA4 is fixed,
> and it can select SCK / WS pin from SSI4 (= alone) or SSI3 (= share)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread