[PATCH 00/11] ARM: shmobile: koelsch: MSIOF support

[PATCH 00/11] ARM: shmobile: koelsch: MSIOF support

[Takashi YOSHII]

Koelsch board has SPI connected on-board PMIC(r2a11302).
These patches enable spidev interface for it using MSIOF
(Clock-Synchronized Serial Interface with FIFO) module on SoC(r8a7791).
This adds platform device support to Koelsh single-platform.
(dt, -reference, multi-platform support are not included)

Summary of patches:

These are bug fix.
 [PATCH 01/11] pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP
 [PATCH 02/11] spi: spi-sh-msiof: round up div to fix freq calculation

To use CS output function which the HW module has.
 [PATCH 03/11] spi: spi-sh-msiof: let it run even without GPIO
 [PATCH 04/11] spi: spi-sh-msiof: set hi/low Active for HW CS

To support MSIOF variant that TX and RX are not separately controllable.
 [PATCH 05/11] spi: spi-sh-msiof: rx_need_dummy_tx variant
 [PATCH 06/11] spi: spi-sh-msiof: RMDIR1[15:0] may should be zero
 [PATCH 07/11] spi: spi-sh-msiof: RSCR register may absent

r8a7791 part
 [PATCH 08/11] ARM: shmobile: r8a7791: Add MSIOF clocks
 [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

Koelsh part
 [PATCH 10/11] ARM: shmobile: koelsch: pinctrl map for MSIOF0
 [PATCH 11/11] ARM: shmobile: koelsch: spidev for r2a11302

---

Takashi Yoshii (11):
  pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP
  spi: spi-sh-msiof: round up div to fix freq calculation
  spi: spi-sh-msiof: let it run even without GPIO
  spi: spi-sh-msiof: set hi/low Active for HW CS
  spi: spi-sh-msiof: rx_need_dummy_tx variant
  spi: spi-sh-msiof: RMDIR1[15:0] may should be zero
  spi: spi-sh-msiof: RSCR register may absent
  ARM: shmobile: r8a7791: Add MSIOF clocks
  ARM: shmobile: r8a7791: MSIOF platform device
  ARM: shmobile: koelsch: pinctrl map for MSIOF0
  ARM: shmobile: koelsch: spidev for r2a11302

 arch/arm/mach-shmobile/board-koelsch.c |   20 ++++++++++++++++++++
 arch/arm/mach-shmobile/clock-r8a7791.c |    9 ++++++++-
 arch/arm/mach-shmobile/setup-r8a7791.c |   30 ++++++++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-r8a7791.c   |   21 +++++++++++++++------
 drivers/spi/spi-sh-msiof.c             |   30 +++++++++++++++++++++---------
 include/linux/spi/sh_msiof.h           |    1 +
 6 files changed, 95 insertions(+), 16 deletions(-)

-- 
1.7.9.5

[PATCH 00/11] ARM: shmobile: koelsch: MSIOF support

[Takashi YOSHII]

Koelsch board has SPI connected on-board PMIC(r2a11302).
These patches enable spidev interface for it using MSIOF
(Clock-Synchronized Serial Interface with FIFO) module on SoC(r8a7791).
This adds platform device support to Koelsh single-platform.
(dt, -reference, multi-platform support are not included)

Summary of patches:

These are bug fix.
 [PATCH 01/11] pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP
 [PATCH 02/11] spi: spi-sh-msiof: round up div to fix freq calculation

To use CS output function which the HW module has.
 [PATCH 03/11] spi: spi-sh-msiof: let it run even without GPIO
 [PATCH 04/11] spi: spi-sh-msiof: set hi/low Active for HW CS

To support MSIOF variant that TX and RX are not separately controllable.
 [PATCH 05/11] spi: spi-sh-msiof: rx_need_dummy_tx variant
 [PATCH 06/11] spi: spi-sh-msiof: RMDIR1[15:0] may should be zero
 [PATCH 07/11] spi: spi-sh-msiof: RSCR register may absent

r8a7791 part
 [PATCH 08/11] ARM: shmobile: r8a7791: Add MSIOF clocks
 [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

Koelsh part
 [PATCH 10/11] ARM: shmobile: koelsch: pinctrl map for MSIOF0
 [PATCH 11/11] ARM: shmobile: koelsch: spidev for r2a11302

---

Takashi Yoshii (11):
  pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP
  spi: spi-sh-msiof: round up div to fix freq calculation
  spi: spi-sh-msiof: let it run even without GPIO
  spi: spi-sh-msiof: set hi/low Active for HW CS
  spi: spi-sh-msiof: rx_need_dummy_tx variant
  spi: spi-sh-msiof: RMDIR1[15:0] may should be zero
  spi: spi-sh-msiof: RSCR register may absent
  ARM: shmobile: r8a7791: Add MSIOF clocks
  ARM: shmobile: r8a7791: MSIOF platform device
  ARM: shmobile: koelsch: pinctrl map for MSIOF0
  ARM: shmobile: koelsch: spidev for r2a11302

 arch/arm/mach-shmobile/board-koelsch.c |   20 ++++++++++++++++++++
 arch/arm/mach-shmobile/clock-r8a7791.c |    9 ++++++++-
 arch/arm/mach-shmobile/setup-r8a7791.c |   30 ++++++++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-r8a7791.c   |   21 +++++++++++++++------
 drivers/spi/spi-sh-msiof.c             |   30 +++++++++++++++++++++---------
 include/linux/spi/sh_msiof.h           |    1 +
 6 files changed, 95 insertions(+), 16 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/11] pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

SH_PFC_PIN_GROUP(), pins[], mux[], defines
 clk, sync, ss1, ss2, rx, tx
But, msiof?_groups[] defines
 clk, ctrl, data

Fix msiof[012]_groups members to be consistent to PIN_GROUP.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7791.c |   21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
index bf76a65..e0be506 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
@@ -2840,20 +2840,29 @@ static const char * const mmc_groups[] = {
 
 static const char * const msiof0_groups[] = {
 	"msiof0_clk",
-	"msiof0_ctrl",
-	"msiof0_data",
+	"msiof0_sync",
+	"msiof0_ss1",
+	"msiof0_ss2",
+	"msiof0_rx",
+	"msiof0_tx",
 };
 
 static const char * const msiof1_groups[] = {
 	"msiof1_clk",
-	"msiof1_ctrl",
-	"msiof1_data",
+	"msiof1_sync",
+	"msiof1_ss1",
+	"msiof1_ss2",
+	"msiof1_rx",
+	"msiof1_tx",
 };
 
 static const char * const msiof2_groups[] = {
 	"msiof2_clk",
-	"msiof2_ctrl",
-	"msiof2_data",
+	"msiof2_sync",
+	"msiof2_ss1",
+	"msiof2_ss2",
+	"msiof2_rx",
+	"msiof2_tx",
 };
 
 static const char * const scif0_groups[] = {
-- 
1.7.9.5

[PATCH 01/11] pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

SH_PFC_PIN_GROUP(), pins[], mux[], defines
 clk, sync, ss1, ss2, rx, tx
But, msiof?_groups[] defines
 clk, ctrl, data

Fix msiof[012]_groups members to be consistent to PIN_GROUP.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7791.c |   21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
index bf76a65..e0be506 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
@@ -2840,20 +2840,29 @@ static const char * const mmc_groups[] = {
 
 static const char * const msiof0_groups[] = {
 	"msiof0_clk",
-	"msiof0_ctrl",
-	"msiof0_data",
+	"msiof0_sync",
+	"msiof0_ss1",
+	"msiof0_ss2",
+	"msiof0_rx",
+	"msiof0_tx",
 };
 
 static const char * const msiof1_groups[] = {
 	"msiof1_clk",
-	"msiof1_ctrl",
-	"msiof1_data",
+	"msiof1_sync",
+	"msiof1_ss1",
+	"msiof1_ss2",
+	"msiof1_rx",
+	"msiof1_tx",
 };
 
 static const char * const msiof2_groups[] = {
 	"msiof2_clk",
-	"msiof2_ctrl",
-	"msiof2_data",
+	"msiof2_sync",
+	"msiof2_ss1",
+	"msiof2_ss2",
+	"msiof2_rx",
+	"msiof2_tx",
 };
 
 static const char * const scif0_groups[] = {
-- 
1.7.9.5

[PATCH 02/11] spi: spi-sh-msiof: round up div to fix freq calculation

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Truncation on integer division in sh_msiof_spi_set_clk_regs()
results in insufficient transfer frequency (> max_speed_freq).

For example, source 52MHz, required max 6MHz
 52/6 = 8.6 --> 8, then 1/8 table selected,
and result in 52/8 = 6.5 MHz (>6MHz)

Rounding it up is a simple solution.
 52/6 = 8.6 --> 9, then 1/16 table selected,
and result in 52/16 = 3.25 MHz

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index c74298c..ac8795f 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -152,7 +152,7 @@ static void sh_msiof_spi_set_clk_regs(struct sh_msiof_spi_priv *p,
 	size_t k;
 
 	if (!WARN_ON(!spi_hz || !parent_rate))
-		div = parent_rate / spi_hz;
+		div = DIV_ROUND_UP(parent_rate, spi_hz);
 
 	/* TODO: make more fine grained */
 
-- 
1.7.9.5

[PATCH 02/11] spi: spi-sh-msiof: round up div to fix freq calculation

[takasi-y-nDL5PR/MsHhHfZP73Gtkiw]

From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>

Truncation on integer division in sh_msiof_spi_set_clk_regs()
results in insufficient transfer frequency (> max_speed_freq).

For example, source 52MHz, required max 6MHz
 52/6 = 8.6 --> 8, then 1/8 table selected,
and result in 52/8 = 6.5 MHz (>6MHz)

Rounding it up is a simple solution.
 52/6 = 8.6 --> 9, then 1/16 table selected,
and result in 52/16 = 3.25 MHz

Signed-off-by: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
---
 drivers/spi/spi-sh-msiof.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index c74298c..ac8795f 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -152,7 +152,7 @@ static void sh_msiof_spi_set_clk_regs(struct sh_msiof_spi_priv *p,
 	size_t k;
 
 	if (!WARN_ON(!spi_hz || !parent_rate))
-		div = parent_rate / spi_hz;
+		div = DIV_ROUND_UP(parent_rate, spi_hz);
 
 	/* TODO: make more fine grained */
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/11] spi: spi-sh-msiof: round up div to fix freq calculation

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:13AM +0900, takasi-y@ops.dti.ne.jp wrote:
> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> 
> Truncation on integer division in sh_msiof_spi_set_clk_regs()
> results in insufficient transfer frequency (> max_speed_freq).

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 02/11] spi: spi-sh-msiof: round up div to fix freq calculation

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:13AM +0900, takasi-y@ops.dti.ne.jp wrote:
> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> 
> Truncation on integer division in sh_msiof_spi_set_clk_regs()
> results in insufficient transfer frequency (> max_speed_freq).

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 06/11] spi: spi-sh-msiof: RMDIR1[15:0] may should be zero

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

On Ape6, Rcar-H2, and Rcar-M2,
RMDR1(Receive Mode Register 1) has no FLD, CONT, RXSTP bits.
HW manual says "The write value should always be 0" for RMDR1[15:0].
I guess this is a part of .rx_need_dummy_tx case, and use same flag.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 936d8ab..b0334b6 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -183,11 +183,13 @@ static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
 	 */
 	sh_msiof_write(p, FCTR, 0);
 
-	tmp = 0;
+	tmp = 0x00000005;
 	tmp |= !cs_high << 25;
 	tmp |= lsb_first << 24;
-	sh_msiof_write(p, TMDR1, 0xe0000005 | tmp);
-	sh_msiof_write(p, RMDR1, 0x20000005 | tmp);
+	sh_msiof_write(p, TMDR1, 0xe0000000 | tmp);
+	if (p->info->rx_need_dummy_tx)
+		tmp &= ~0x0000ffff;
+	sh_msiof_write(p, RMDR1, 0x20000000 | tmp);
 
 	tmp = 0xa0000000;
 	tmp |= cpol << 30; /* TSCKIZ */
-- 
1.7.9.5

[PATCH 06/11] spi: spi-sh-msiof: RMDIR1[15:0] may should be zero

[takasi-y-nDL5PR/MsHhHfZP73Gtkiw]

From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>

On Ape6, Rcar-H2, and Rcar-M2,
RMDR1(Receive Mode Register 1) has no FLD, CONT, RXSTP bits.
HW manual says "The write value should always be 0" for RMDR1[15:0].
I guess this is a part of .rx_need_dummy_tx case, and use same flag.

Signed-off-by: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
---
 drivers/spi/spi-sh-msiof.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 936d8ab..b0334b6 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -183,11 +183,13 @@ static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
 	 */
 	sh_msiof_write(p, FCTR, 0);
 
-	tmp = 0;
+	tmp = 0x00000005;
 	tmp |= !cs_high << 25;
 	tmp |= lsb_first << 24;
-	sh_msiof_write(p, TMDR1, 0xe0000005 | tmp);
-	sh_msiof_write(p, RMDR1, 0x20000005 | tmp);
+	sh_msiof_write(p, TMDR1, 0xe0000000 | tmp);
+	if (p->info->rx_need_dummy_tx)
+		tmp &= ~0x0000ffff;
+	sh_msiof_write(p, RMDR1, 0x20000000 | tmp);
 
 	tmp = 0xa0000000;
 	tmp |= cpol << 30; /* TSCKIZ */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/11] spi: spi-sh-msiof: RSCR register may absent

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

On Ape6, Rcar-H2, and Rcar-M2,
MSIOF lacks RSCR(Receive Clock Select Register).
I guess this is a part of .rx_need_dummy_tx case, and use same flag.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index b0334b6..bbd989f 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -164,7 +164,8 @@ static void sh_msiof_spi_set_clk_regs(struct sh_msiof_spi_priv *p,
 	k = min_t(int, k, ARRAY_SIZE(sh_msiof_spi_clk_table) - 1);
 
 	sh_msiof_write(p, TSCR, sh_msiof_spi_clk_table[k].scr);
-	sh_msiof_write(p, RSCR, sh_msiof_spi_clk_table[k].scr);
+	if (!p->info->rx_need_dummy_tx)
+		sh_msiof_write(p, RSCR, sh_msiof_spi_clk_table[k].scr);
 }
 
 static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
-- 
1.7.9.5

[PATCH 07/11] spi: spi-sh-msiof: RSCR register may absent

[takasi-y-nDL5PR/MsHhHfZP73Gtkiw]

From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>

On Ape6, Rcar-H2, and Rcar-M2,
MSIOF lacks RSCR(Receive Clock Select Register).
I guess this is a part of .rx_need_dummy_tx case, and use same flag.

Signed-off-by: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
---
 drivers/spi/spi-sh-msiof.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index b0334b6..bbd989f 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -164,7 +164,8 @@ static void sh_msiof_spi_set_clk_regs(struct sh_msiof_spi_priv *p,
 	k = min_t(int, k, ARRAY_SIZE(sh_msiof_spi_clk_table) - 1);
 
 	sh_msiof_write(p, TSCR, sh_msiof_spi_clk_table[k].scr);
-	sh_msiof_write(p, RSCR, sh_msiof_spi_clk_table[k].scr);
+	if (!p->info->rx_need_dummy_tx)
+		sh_msiof_write(p, RSCR, sh_msiof_spi_clk_table[k].scr);
 }
 
 static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/11] spi: spi-sh-msiof: RSCR register may absent

[Geert Uytterhoeven]

Hi Yoshii-san,

On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> On Ape6, Rcar-H2, and Rcar-M2,
> MSIOF lacks RSCR(Receive Clock Select Register).
> I guess this is a part of .rx_need_dummy_tx case, and use same flag.

Are you sure? I'm under the impression MSIOF on APE6 does have RSCR,
just like on A1, and SH (e.g. 7724).

Given also that:
  - dummy TX is needed during reception for  APE6, R-Car H2/M2, and
     (perhaps --- this is not 100% clear to me) A1,
  - RMDR1[15:0] must be zero on APE6, and R-Car H2/M2.

there are (at least) 4 different variants of MSIOF:
  - SH
  - A1
  - APE6
  - R-Car H2 and M2

And I don't know about SH7372 and SH73A0...

But we indeed may not need to distinguish between all variants.
You just use the value of rx_need_dummy_tx as test condition.
If this works for APE6 and A1, we can add a new platform device name
"spi_sh_mobile_msiof" instead of adding the rx_need_dummy_tx flag
to platform data (struct sh_msiof_spi_info).
This would be in line with the currently defined (but so far unused) DT
compatible values "renesas,sh-msiof" and "renesas,sh-mobile-msiof".

What do you think?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 07/11] spi: spi-sh-msiof: RSCR register may absent

[Geert Uytterhoeven]

Hi Yoshii-san,

On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org> wrote:
> On Ape6, Rcar-H2, and Rcar-M2,
> MSIOF lacks RSCR(Receive Clock Select Register).
> I guess this is a part of .rx_need_dummy_tx case, and use same flag.

Are you sure? I'm under the impression MSIOF on APE6 does have RSCR,
just like on A1, and SH (e.g. 7724).

Given also that:
  - dummy TX is needed during reception for  APE6, R-Car H2/M2, and
     (perhaps --- this is not 100% clear to me) A1,
  - RMDR1[15:0] must be zero on APE6, and R-Car H2/M2.

there are (at least) 4 different variants of MSIOF:
  - SH
  - A1
  - APE6
  - R-Car H2 and M2

And I don't know about SH7372 and SH73A0...

But we indeed may not need to distinguish between all variants.
You just use the value of rx_need_dummy_tx as test condition.
If this works for APE6 and A1, we can add a new platform device name
"spi_sh_mobile_msiof" instead of adding the rx_need_dummy_tx flag
to platform data (struct sh_msiof_spi_info).
This would be in line with the currently defined (but so far unused) DT
compatible values "renesas,sh-msiof" and "renesas,sh-mobile-msiof".

What do you think?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/11] spi: spi-sh-msiof: RSCR register may absent

[Simon Horman]

On Wed, Feb 12, 2014 at 05:06:41PM +0100, Geert Uytterhoeven wrote:
> Hi Yoshii-san,
> 
> On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> > On Ape6, Rcar-H2, and Rcar-M2,
> > MSIOF lacks RSCR(Receive Clock Select Register).
> > I guess this is a part of .rx_need_dummy_tx case, and use same flag.
> 
> Are you sure? I'm under the impression MSIOF on APE6 does have RSCR,
> just like on A1, and SH (e.g. 7724).

FWIW, the version of the APE6 documentation that I have access to
indicates that it does have RSCR.

> Given also that:
>   - dummy TX is needed during reception for  APE6, R-Car H2/M2, and
>      (perhaps --- this is not 100% clear to me) A1,
>   - RMDR1[15:0] must be zero on APE6, and R-Car H2/M2.
> 
> there are (at least) 4 different variants of MSIOF:
>   - SH
>   - A1
>   - APE6
>   - R-Car H2 and M2
> 
> And I don't know about SH7372 and SH73A0...
> 
> But we indeed may not need to distinguish between all variants.
> You just use the value of rx_need_dummy_tx as test condition.
> If this works for APE6 and A1, we can add a new platform device name
> "spi_sh_mobile_msiof" instead of adding the rx_need_dummy_tx flag
> to platform data (struct sh_msiof_spi_info).
> This would be in line with the currently defined (but so far unused) DT
> compatible values "renesas,sh-msiof" and "renesas,sh-mobile-msiof".
> 
> What do you think?
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

Re: [PATCH 07/11] spi: spi-sh-msiof: RSCR register may absent

[Simon Horman]

On Wed, Feb 12, 2014 at 05:06:41PM +0100, Geert Uytterhoeven wrote:
> Hi Yoshii-san,
> 
> On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org> wrote:
> > On Ape6, Rcar-H2, and Rcar-M2,
> > MSIOF lacks RSCR(Receive Clock Select Register).
> > I guess this is a part of .rx_need_dummy_tx case, and use same flag.
> 
> Are you sure? I'm under the impression MSIOF on APE6 does have RSCR,
> just like on A1, and SH (e.g. 7724).

FWIW, the version of the APE6 documentation that I have access to
indicates that it does have RSCR.

> Given also that:
>   - dummy TX is needed during reception for  APE6, R-Car H2/M2, and
>      (perhaps --- this is not 100% clear to me) A1,
>   - RMDR1[15:0] must be zero on APE6, and R-Car H2/M2.
> 
> there are (at least) 4 different variants of MSIOF:
>   - SH
>   - A1
>   - APE6
>   - R-Car H2 and M2
> 
> And I don't know about SH7372 and SH73A0...
> 
> But we indeed may not need to distinguish between all variants.
> You just use the value of rx_need_dummy_tx as test condition.
> If this works for APE6 and A1, we can add a new platform device name
> "spi_sh_mobile_msiof" instead of adding the rx_need_dummy_tx flag
> to platform data (struct sh_msiof_spi_info).
> This would be in line with the currently defined (but so far unused) DT
> compatible values "renesas,sh-msiof" and "renesas,sh-mobile-msiof".
> 
> What do you think?
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/11] ARM: shmobile: r8a7791: Add MSIOF clocks

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Add clocks for MSIOF0,1,2,
and DEV_ID spi_sh_msiof.1,2,3 for platform devices.
(numberd 1-based for the compatibility with BSP)

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 arch/arm/mach-shmobile/clock-r8a7791.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7791.c b/arch/arm/mach-shmobile/clock-r8a7791.c
index ff2d60d..0530f3a 100644
--- a/arch/arm/mach-shmobile/clock-r8a7791.c
+++ b/arch/arm/mach-shmobile/clock-r8a7791.c
@@ -125,9 +125,10 @@ enum {
 	MSTP726, MSTP724, MSTP723, MSTP721, MSTP720,
 	MSTP719, MSTP718, MSTP715, MSTP714,
 	MSTP522,
-	MSTP216, MSTP207, MSTP206,
+	MSTP216, MSTP208, MSTP207, MSTP206, MSTP205,
 	MSTP204, MSTP203, MSTP202, MSTP1105, MSTP1106, MSTP1107,
 	MSTP124,
+	MSTP000,
 	MSTP_NR
 };
 
@@ -143,8 +144,10 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP714] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 14, 0), /* SCIF5 */
 	[MSTP522] = SH_CLK_MSTP32(&extal_clk, SMSTPCR5, 22, 0), /* Thermal */
 	[MSTP216] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 16, 0), /* SCIFB2 */
+	[MSTP208] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 8, 0), /* MSIOF1 */
 	[MSTP207] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 7, 0), /* SCIFB1 */
 	[MSTP206] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 6, 0), /* SCIFB0 */
+	[MSTP205] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 5, 0), /* MSIOF2 */
 	[MSTP204] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
 	[MSTP203] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
 	[MSTP202] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 2, 0), /* SCIFA2 */
@@ -152,6 +155,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP1106] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 6, 0), /* SCIFA4 */
 	[MSTP1107] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 7, 0), /* SCIFA5 */
 	[MSTP124] = SH_CLK_MSTP32(&rclk_clk, SMSTPCR1, 24, 0), /* CMT0 */
+	[MSTP000] = SH_CLK_MSTP32(&mp_clk, SMSTPCR0, 0, 0), /* MSIOF0 */
 };
 
 static struct clk_lookup lookups[] = {
@@ -192,6 +196,9 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_cmt.0", &mstp_clks[MSTP124]),
 	CLKDEV_DEV_ID("e61f0000.thermal", &mstp_clks[MSTP522]),
 	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
+	CLKDEV_DEV_ID("spi_sh_msiof.1", &mstp_clks[MSTP000]),
+	CLKDEV_DEV_ID("spi_sh_msiof.2", &mstp_clks[MSTP208]),
+	CLKDEV_DEV_ID("spi_sh_msiof.3", &mstp_clks[MSTP205]),
 };
 
 #define R8A7791_CLOCK_ROOT(e, m, p0, p1, p30, p31)		\
-- 
1.7.9.5

[PATCH 08/11] ARM: shmobile: r8a7791: Add MSIOF clocks

[takasi-y-nDL5PR/MsHhHfZP73Gtkiw]

From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>

Add clocks for MSIOF0,1,2,
and DEV_ID spi_sh_msiof.1,2,3 for platform devices.
(numberd 1-based for the compatibility with BSP)

Signed-off-by: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
---
 arch/arm/mach-shmobile/clock-r8a7791.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7791.c b/arch/arm/mach-shmobile/clock-r8a7791.c
index ff2d60d..0530f3a 100644
--- a/arch/arm/mach-shmobile/clock-r8a7791.c
+++ b/arch/arm/mach-shmobile/clock-r8a7791.c
@@ -125,9 +125,10 @@ enum {
 	MSTP726, MSTP724, MSTP723, MSTP721, MSTP720,
 	MSTP719, MSTP718, MSTP715, MSTP714,
 	MSTP522,
-	MSTP216, MSTP207, MSTP206,
+	MSTP216, MSTP208, MSTP207, MSTP206, MSTP205,
 	MSTP204, MSTP203, MSTP202, MSTP1105, MSTP1106, MSTP1107,
 	MSTP124,
+	MSTP000,
 	MSTP_NR
 };
 
@@ -143,8 +144,10 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP714] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 14, 0), /* SCIF5 */
 	[MSTP522] = SH_CLK_MSTP32(&extal_clk, SMSTPCR5, 22, 0), /* Thermal */
 	[MSTP216] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 16, 0), /* SCIFB2 */
+	[MSTP208] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 8, 0), /* MSIOF1 */
 	[MSTP207] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 7, 0), /* SCIFB1 */
 	[MSTP206] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 6, 0), /* SCIFB0 */
+	[MSTP205] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 5, 0), /* MSIOF2 */
 	[MSTP204] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
 	[MSTP203] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
 	[MSTP202] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 2, 0), /* SCIFA2 */
@@ -152,6 +155,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP1106] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 6, 0), /* SCIFA4 */
 	[MSTP1107] = SH_CLK_MSTP32(&mp_clk, SMSTPCR11, 7, 0), /* SCIFA5 */
 	[MSTP124] = SH_CLK_MSTP32(&rclk_clk, SMSTPCR1, 24, 0), /* CMT0 */
+	[MSTP000] = SH_CLK_MSTP32(&mp_clk, SMSTPCR0, 0, 0), /* MSIOF0 */
 };
 
 static struct clk_lookup lookups[] = {
@@ -192,6 +196,9 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_cmt.0", &mstp_clks[MSTP124]),
 	CLKDEV_DEV_ID("e61f0000.thermal", &mstp_clks[MSTP522]),
 	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
+	CLKDEV_DEV_ID("spi_sh_msiof.1", &mstp_clks[MSTP000]),
+	CLKDEV_DEV_ID("spi_sh_msiof.2", &mstp_clks[MSTP208]),
+	CLKDEV_DEV_ID("spi_sh_msiof.3", &mstp_clks[MSTP205]),
 };
 
 #define R8A7791_CLOCK_ROOT(e, m, p0, p1, p30, p31)		\
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Define resources for msiof0,1,2. HWM says there is msiof3, but omit
it because its clock, reset and irqs are not seen on HWM. Anyway, only
msiof0 is registerd, so far, because others lack of chance for testing.
msiof0 has id=1 (spi_sh_msiof.1), for a compatibility with BSP.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 arch/arm/mach-shmobile/setup-r8a7791.c |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/mach-shmobile/setup-r8a7791.c b/arch/arm/mach-shmobile/setup-r8a7791.c
index cddca99..5669fa0 100644
--- a/arch/arm/mach-shmobile/setup-r8a7791.c
+++ b/arch/arm/mach-shmobile/setup-r8a7791.c
@@ -26,6 +26,7 @@
 #include <linux/platform_data/irq-renesas-irqc.h>
 #include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
+#include <linux/spi/sh_msiof.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7791.h>
@@ -200,6 +201,34 @@ static const struct resource thermal_resources[] __initconst = {
 					thermal_resources,		\
 					ARRAY_SIZE(thermal_resources))
 
+static const struct sh_msiof_spi_info sh_msiof_info __initconst = {
+	.rx_fifo_override	= 256,
+	.num_chipselect		= 1,
+	.rx_need_dummy_tx	= 1,
+};
+
+static const struct resource sh_msiof0_resources[] __initconst = {
+	DEFINE_RES_MEM(0xe6e20000, 0x0064),
+	DEFINE_RES_IRQ(gic_spi(156)),
+};
+
+static const struct resource sh_msiof1_resources[] __initconst = {
+	DEFINE_RES_MEM(0xe6e10000, 0x0064),
+	DEFINE_RES_IRQ(gic_spi(157)),
+};
+
+static const struct resource sh_msiof2_resources[] __initconst = {
+	DEFINE_RES_MEM(0xe6e00000, 0x0064),
+	DEFINE_RES_IRQ(gic_spi(158)),
+};
+
+#define r8a7791_register_msiof(idx)					\
+	platform_device_register_resndata(&platform_bus, "spi_sh_msiof", \
+				  (idx+1), sh_msiof##idx##_resources,	\
+				  ARRAY_SIZE(sh_msiof##idx##_resources), \
+				  &sh_msiof_info,		\
+				  sizeof(struct sh_msiof_spi_info))
+
 void __init r8a7791_add_dt_devices(void)
 {
 	r8a7791_register_scif(SCIFA0);
@@ -218,6 +247,7 @@ void __init r8a7791_add_dt_devices(void)
 	r8a7791_register_scif(SCIFA4);
 	r8a7791_register_scif(SCIFA5);
 	r8a7791_register_cmt(00);
+	r8a7791_register_msiof(0);
 }
 
 void __init r8a7791_add_standard_devices(void)
-- 
1.7.9.5

[PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[takasi-y-nDL5PR/MsHhHfZP73Gtkiw]

From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>

Define resources for msiof0,1,2. HWM says there is msiof3, but omit
it because its clock, reset and irqs are not seen on HWM. Anyway, only
msiof0 is registerd, so far, because others lack of chance for testing.
msiof0 has id=1 (spi_sh_msiof.1), for a compatibility with BSP.

Signed-off-by: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
---
 arch/arm/mach-shmobile/setup-r8a7791.c |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/mach-shmobile/setup-r8a7791.c b/arch/arm/mach-shmobile/setup-r8a7791.c
index cddca99..5669fa0 100644
--- a/arch/arm/mach-shmobile/setup-r8a7791.c
+++ b/arch/arm/mach-shmobile/setup-r8a7791.c
@@ -26,6 +26,7 @@
 #include <linux/platform_data/irq-renesas-irqc.h>
 #include <linux/serial_sci.h>
 #include <linux/sh_timer.h>
+#include <linux/spi/sh_msiof.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7791.h>
@@ -200,6 +201,34 @@ static const struct resource thermal_resources[] __initconst = {
 					thermal_resources,		\
 					ARRAY_SIZE(thermal_resources))
 
+static const struct sh_msiof_spi_info sh_msiof_info __initconst = {
+	.rx_fifo_override	= 256,
+	.num_chipselect		= 1,
+	.rx_need_dummy_tx	= 1,
+};
+
+static const struct resource sh_msiof0_resources[] __initconst = {
+	DEFINE_RES_MEM(0xe6e20000, 0x0064),
+	DEFINE_RES_IRQ(gic_spi(156)),
+};
+
+static const struct resource sh_msiof1_resources[] __initconst = {
+	DEFINE_RES_MEM(0xe6e10000, 0x0064),
+	DEFINE_RES_IRQ(gic_spi(157)),
+};
+
+static const struct resource sh_msiof2_resources[] __initconst = {
+	DEFINE_RES_MEM(0xe6e00000, 0x0064),
+	DEFINE_RES_IRQ(gic_spi(158)),
+};
+
+#define r8a7791_register_msiof(idx)					\
+	platform_device_register_resndata(&platform_bus, "spi_sh_msiof", \
+				  (idx+1), sh_msiof##idx##_resources,	\
+				  ARRAY_SIZE(sh_msiof##idx##_resources), \
+				  &sh_msiof_info,		\
+				  sizeof(struct sh_msiof_spi_info))
+
 void __init r8a7791_add_dt_devices(void)
 {
 	r8a7791_register_scif(SCIFA0);
@@ -218,6 +247,7 @@ void __init r8a7791_add_dt_devices(void)
 	r8a7791_register_scif(SCIFA4);
 	r8a7791_register_scif(SCIFA5);
 	r8a7791_register_cmt(00);
+	r8a7791_register_msiof(0);
 }
 
 void __init r8a7791_add_standard_devices(void)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[Linus Walleij]

On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:

> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>
> Define resources for msiof0,1,2. HWM says there is msiof3, but omit
> it because its clock, reset and irqs are not seen on HWM. Anyway, only
> msiof0 is registerd, so far, because others lack of chance for testing.
> msiof0 has id=1 (spi_sh_msiof.1), for a compatibility with BSP.
>
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

So why is this new shiny device not registered from the device
tree instead of adding more hard-coded platform devices to the
ARM tree? The add_standard_devices() seem to add everything
from the DT just fine.

NAK.

Yours,
Linus Walleij

Re: [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[Linus Walleij]

On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:

> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>
> Define resources for msiof0,1,2. HWM says there is msiof3, but omit
> it because its clock, reset and irqs are not seen on HWM. Anyway, only
> msiof0 is registerd, so far, because others lack of chance for testing.
> msiof0 has id=1 (spi_sh_msiof.1), for a compatibility with BSP.
>
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

So why is this new shiny device not registered from the device
tree instead of adding more hard-coded platform devices to the
ARM tree? The add_standard_devices() seem to add everything
from the DT just fine.

NAK.

Yours,
Linus Walleij

Re: [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[Simon Horman]

On Tue, Dec 03, 2013 at 11:12:32AM +0100, Linus Walleij wrote:
> On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> 
> > From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> >
> > Define resources for msiof0,1,2. HWM says there is msiof3, but omit
> > it because its clock, reset and irqs are not seen on HWM. Anyway, only
> > msiof0 is registerd, so far, because others lack of chance for testing.
> > msiof0 has id=1 (spi_sh_msiof.1), for a compatibility with BSP.
> >
> > Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> 
> So why is this new shiny device not registered from the device
> tree instead of adding more hard-coded platform devices to the
> ARM tree? The add_standard_devices() seem to add everything
> from the DT just fine.
> 
> NAK.

Hi Linus,

the way that shmobile is handling moving to DT is multi-faceted.
One such facet is that we currently maintain two ways of booting each board.
One uses legacy-C code and initialises devices using platform devices.
The other, which we call -reference uses DT.

This patch is for the legacy-C board code to use.

This has been the approach that we have been taking for about a year now.
We have recently been giving some consideration to moving to the next stage
which we believe is to enable devices whose drivers don't have DT bindings
(yet) using DT in -reference. With this in place it should be possible
to plan removal of the legacy-C board code.

In the mean time I would prefer if we kept with the pattern that
we have been using up until now.

Re: [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[Simon Horman]

On Tue, Dec 03, 2013 at 11:12:32AM +0100, Linus Walleij wrote:
> On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org> wrote:
> 
> > From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
> >
> > Define resources for msiof0,1,2. HWM says there is msiof3, but omit
> > it because its clock, reset and irqs are not seen on HWM. Anyway, only
> > msiof0 is registerd, so far, because others lack of chance for testing.
> > msiof0 has id=1 (spi_sh_msiof.1), for a compatibility with BSP.
> >
> > Signed-off-by: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
> 
> So why is this new shiny device not registered from the device
> tree instead of adding more hard-coded platform devices to the
> ARM tree? The add_standard_devices() seem to add everything
> from the DT just fine.
> 
> NAK.

Hi Linus,

the way that shmobile is handling moving to DT is multi-faceted.
One such facet is that we currently maintain two ways of booting each board.
One uses legacy-C code and initialises devices using platform devices.
The other, which we call -reference uses DT.

This patch is for the legacy-C board code to use.

This has been the approach that we have been taking for about a year now.
We have recently been giving some consideration to moving to the next stage
which we believe is to enable devices whose drivers don't have DT bindings
(yet) using DT in -reference. With this in place it should be possible
to plan removal of the legacy-C board code.

In the mean time I would prefer if we kept with the pattern that
we have been using up until now.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[Linus Walleij]

On Thu, Dec 5, 2013 at 4:02 AM, Simon Horman <horms@verge.net.au> wrote:
> On Tue, Dec 03, 2013 at 11:12:32AM +0100, Linus Walleij wrote:

>> NAK.
>
> Hi Linus,
>
> the way that shmobile is handling moving to DT is multi-faceted.
> One such facet is that we currently maintain two ways of booting each board.
> One uses legacy-C code and initialises devices using platform devices.
> The other, which we call -reference uses DT.
>
> This patch is for the legacy-C board code to use.
>
> This has been the approach that we have been taking for about a year now.
> We have recently been giving some consideration to moving to the next stage
> which we believe is to enable devices whose drivers don't have DT bindings
> (yet) using DT in -reference. With this in place it should be possible
> to plan removal of the legacy-C board code.
>
> In the mean time I would prefer if we kept with the pattern that
> we have been using up until now.

If you get an OK from the ARM SoC maintainers on this approach I
will rest my case. I have to provide some kind of pushback you know,
lest I fear nothing ever happens...

Yours,
Linus Walleij

Re: [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[Linus Walleij]

On Thu, Dec 5, 2013 at 4:02 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> On Tue, Dec 03, 2013 at 11:12:32AM +0100, Linus Walleij wrote:

>> NAK.
>
> Hi Linus,
>
> the way that shmobile is handling moving to DT is multi-faceted.
> One such facet is that we currently maintain two ways of booting each board.
> One uses legacy-C code and initialises devices using platform devices.
> The other, which we call -reference uses DT.
>
> This patch is for the legacy-C board code to use.
>
> This has been the approach that we have been taking for about a year now.
> We have recently been giving some consideration to moving to the next stage
> which we believe is to enable devices whose drivers don't have DT bindings
> (yet) using DT in -reference. With this in place it should be possible
> to plan removal of the legacy-C board code.
>
> In the mean time I would prefer if we kept with the pattern that
> we have been using up until now.

If you get an OK from the ARM SoC maintainers on this approach I
will rest my case. I have to provide some kind of pushback you know,
lest I fear nothing ever happens...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[Olof Johansson]

On Wed, Dec 11, 2013 at 01:27:34PM +0100, Linus Walleij wrote:
> On Thu, Dec 5, 2013 at 4:02 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Tue, Dec 03, 2013 at 11:12:32AM +0100, Linus Walleij wrote:
> 
> >> NAK.
> >
> > Hi Linus,
> >
> > the way that shmobile is handling moving to DT is multi-faceted.
> > One such facet is that we currently maintain two ways of booting each board.
> > One uses legacy-C code and initialises devices using platform devices.
> > The other, which we call -reference uses DT.
> >
> > This patch is for the legacy-C board code to use.
> >
> > This has been the approach that we have been taking for about a year now.
> > We have recently been giving some consideration to moving to the next stage
> > which we believe is to enable devices whose drivers don't have DT bindings
> > (yet) using DT in -reference. With this in place it should be possible
> > to plan removal of the legacy-C board code.
> >
> > In the mean time I would prefer if we kept with the pattern that
> > we have been using up until now.
> 
> If you get an OK from the ARM SoC maintainers on this approach I
> will rest my case. I have to provide some kind of pushback you know,
> lest I fear nothing ever happens...

So the deal we've had with the Renesas guys is that we've been allowing
some legacy code to go in, but that we got a handshake earlier this year
that they were done adding legacy code as of 3.13 / end of the year, and
they will now start focusing on enabling multiplatform and modernizing
the shmobile platform.

So, is this one of the few straggling drivers still looking to go in? Or
are you anticipating more of this over time? I don't want to see much
more of this added right before it's time to cleanup.


-Olof

Re: [PATCH 09/11] ARM: shmobile: r8a7791: MSIOF platform device

[Olof Johansson]

On Wed, Dec 11, 2013 at 01:27:34PM +0100, Linus Walleij wrote:
> On Thu, Dec 5, 2013 at 4:02 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> > On Tue, Dec 03, 2013 at 11:12:32AM +0100, Linus Walleij wrote:
> 
> >> NAK.
> >
> > Hi Linus,
> >
> > the way that shmobile is handling moving to DT is multi-faceted.
> > One such facet is that we currently maintain two ways of booting each board.
> > One uses legacy-C code and initialises devices using platform devices.
> > The other, which we call -reference uses DT.
> >
> > This patch is for the legacy-C board code to use.
> >
> > This has been the approach that we have been taking for about a year now.
> > We have recently been giving some consideration to moving to the next stage
> > which we believe is to enable devices whose drivers don't have DT bindings
> > (yet) using DT in -reference. With this in place it should be possible
> > to plan removal of the legacy-C board code.
> >
> > In the mean time I would prefer if we kept with the pattern that
> > we have been using up until now.
> 
> If you get an OK from the ARM SoC maintainers on this approach I
> will rest my case. I have to provide some kind of pushback you know,
> lest I fear nothing ever happens...

So the deal we've had with the Renesas guys is that we've been allowing
some legacy code to go in, but that we got a handshake earlier this year
that they were done adding legacy code as of 3.13 / end of the year, and
they will now start focusing on enabling multiplatform and modernizing
the shmobile platform.

So, is this one of the few straggling drivers still looking to go in? Or
are you anticipating more of this over time? I don't want to see much
more of this added right before it's time to cleanup.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/11] ARM: shmobile: koelsch: pinctrl map for MSIOF0

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Enable msifo0_{clk,sync,rx,tx} pins for MSIOF driver.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 arch/arm/mach-shmobile/board-koelsch.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index 6e12914..b4add4c 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -86,6 +86,15 @@ static const struct pinctrl_map koelsch_pinctrl_map[] = {
 	/* SCIF1 (CN20: DEBUG SERIAL1) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7791",
 				  "scif1_data_d", "scif1"),
+	/* MSIOF0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("spi_sh_msiof.1", "pfc-r8a7791",
+				  "msiof0_clk", "msiof0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("spi_sh_msiof.1", "pfc-r8a7791",
+				  "msiof0_sync", "msiof0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("spi_sh_msiof.1", "pfc-r8a7791",
+				  "msiof0_rx", "msiof0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("spi_sh_msiof.1", "pfc-r8a7791",
+				  "msiof0_tx", "msiof0"),
 };
 
 static void __init koelsch_add_standard_devices(void)
-- 
1.7.9.5

[PATCH 10/11] ARM: shmobile: koelsch: pinctrl map for MSIOF0

[takasi-y-nDL5PR/MsHhHfZP73Gtkiw]

From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>

Enable msifo0_{clk,sync,rx,tx} pins for MSIOF driver.

Signed-off-by: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
---
 arch/arm/mach-shmobile/board-koelsch.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index 6e12914..b4add4c 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -86,6 +86,15 @@ static const struct pinctrl_map koelsch_pinctrl_map[] = {
 	/* SCIF1 (CN20: DEBUG SERIAL1) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7791",
 				  "scif1_data_d", "scif1"),
+	/* MSIOF0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("spi_sh_msiof.1", "pfc-r8a7791",
+				  "msiof0_clk", "msiof0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("spi_sh_msiof.1", "pfc-r8a7791",
+				  "msiof0_sync", "msiof0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("spi_sh_msiof.1", "pfc-r8a7791",
+				  "msiof0_rx", "msiof0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("spi_sh_msiof.1", "pfc-r8a7791",
+				  "msiof0_tx", "msiof0"),
 };
 
 static void __init koelsch_add_standard_devices(void)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/11] ARM: shmobile: koelsch: pinctrl map for MSIOF0

[Linus Walleij]

On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:

> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>
> Enable msifo0_{clk,sync,rx,tx} pins for MSIOF driver.
>
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

If this device is registered from the device tree, the pin control
business can also be done from the device tree.

NAK.

Yours,
Linus Walleij

Re: [PATCH 10/11] ARM: shmobile: koelsch: pinctrl map for MSIOF0

[Linus Walleij]

On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:

> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>
> Enable msifo0_{clk,sync,rx,tx} pins for MSIOF driver.
>
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

If this device is registered from the device tree, the pin control
business can also be done from the device tree.

NAK.

Yours,
Linus Walleij

Re: [PATCH 01/11] pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP

[Linus Walleij]

On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:

> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>
> SH_PFC_PIN_GROUP(), pins[], mux[], defines
>  clk, sync, ss1, ss2, rx, tx
> But, msiof?_groups[] defines
>  clk, ctrl, data
>
> Fix msiof[012]_groups members to be consistent to PIN_GROUP.
>
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

This looks all right to me. Laurent is merging PFC patches for this
kernel cycle, please make sure you include him on subsequent
postings. Once Laurent has a finished series I'll pull it into
the pinctrl tree.

I think the device tree changes part of this series can go directly
to Simon though?

Yours,
Linus Walleij

Re: [PATCH 01/11] pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP

[Linus Walleij]

On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org> wrote:

> From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
>
> SH_PFC_PIN_GROUP(), pins[], mux[], defines
>  clk, sync, ss1, ss2, rx, tx
> But, msiof?_groups[] defines
>  clk, ctrl, data
>
> Fix msiof[012]_groups members to be consistent to PIN_GROUP.
>
> Signed-off-by: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>

This looks all right to me. Laurent is merging PFC patches for this
kernel cycle, please make sure you include him on subsequent
postings. Once Laurent has a finished series I'll pull it into
the pinctrl tree.

I think the device tree changes part of this series can go directly
to Simon though?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/11] pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP

[Laurent Pinchart]

Hi Linus,

On Tuesday 03 December 2013 11:08:14 Linus Walleij wrote:
> On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> > From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> > 
> > SH_PFC_PIN_GROUP(), pins[], mux[], defines
> > 
> >  clk, sync, ss1, ss2, rx, tx
> > 
> > But, msiof?_groups[] defines
> > 
> >  clk, ctrl, data
> > 
> > Fix msiof[012]_groups members to be consistent to PIN_GROUP.
> > 
> > Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> 
> This looks all right to me. Laurent is merging PFC patches for this
> kernel cycle, please make sure you include him on subsequent
> postings. Once Laurent has a finished series I'll pull it into
> the pinctrl tree.

I've applied this patch to my tree.

> I think the device tree changes part of this series can go directly
> to Simon though?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/11] pinctrl: sh-pfc: r8a7791: fix msiof groups to follow GROUP

[Laurent Pinchart]

Hi Linus,

On Tuesday 03 December 2013 11:08:14 Linus Walleij wrote:
> On Sun, Dec 1, 2013 at 7:19 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> > From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> > 
> > SH_PFC_PIN_GROUP(), pins[], mux[], defines
> > 
> >  clk, sync, ss1, ss2, rx, tx
> > 
> > But, msiof?_groups[] defines
> > 
> >  clk, ctrl, data
> > 
> > Fix msiof[012]_groups members to be consistent to PIN_GROUP.
> > 
> > Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> 
> This looks all right to me. Laurent is merging PFC patches for this
> kernel cycle, please make sure you include him on subsequent
> postings. Once Laurent has a finished series I'll pull it into
> the pinctrl tree.

I've applied this patch to my tree.

> I think the device tree changes part of this series can go directly
> to Simon though?

-- 
Regards,

Laurent Pinchart

[PATCH 03/11] spi: spi-sh-msiof: let it run even without GPIO

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

In current implementation, CS is controlled by GPIO, which is passed
through spi->controller_data. But because sh-msiof HW module has a
function to output CS by itself, which is already enabled and actual
switch will be done by pinmux, we can silently ignore if GPIO is null.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index ac8795f..2a2b0dd 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -420,8 +420,10 @@ static void sh_msiof_spi_chipselect(struct spi_device *spi, int is_on)
 					  !!(spi->mode & SPI_LSB_FIRST));
 	}
 
-	/* use spi->controller data for CS (same strategy as spi_gpio) */
-	gpio_set_value((unsigned)spi->controller_data, value);
+	/* use spi->controller data for CS (same strategy as spi_gpio),
+	 * if any. otherwise let HW controll CS */
+	if (spi->controller_data)
+		gpio_set_value((unsigned)spi->controller_data, value);
 
 	if (is_on = BITBANG_CS_INACTIVE) {
 		if (test_and_clear_bit(0, &p->flags)) {
-- 
1.7.9.5

[PATCH 03/11] spi: spi-sh-msiof: let it run even without GPIO

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

In current implementation, CS is controlled by GPIO, which is passed
through spi->controller_data. But because sh-msiof HW module has a
function to output CS by itself, which is already enabled and actual
switch will be done by pinmux, we can silently ignore if GPIO is null.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index ac8795f..2a2b0dd 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -420,8 +420,10 @@ static void sh_msiof_spi_chipselect(struct spi_device *spi, int is_on)
 					  !!(spi->mode & SPI_LSB_FIRST));
 	}
 
-	/* use spi->controller data for CS (same strategy as spi_gpio) */
-	gpio_set_value((unsigned)spi->controller_data, value);
+	/* use spi->controller data for CS (same strategy as spi_gpio),
+	 * if any. otherwise let HW controll CS */
+	if (spi->controller_data)
+		gpio_set_value((unsigned)spi->controller_data, value);
 
 	if (is_on == BITBANG_CS_INACTIVE) {
 		if (test_and_clear_bit(0, &p->flags)) {
-- 
1.7.9.5

Re: [PATCH 03/11] spi: spi-sh-msiof: let it run even without GPIO

[Sergei Shtylyov]

Hello.

On 01-12-2013 22:19, takasi-y@ops.dti.ne.jp wrote:

> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

> In current implementation, CS is controlled by GPIO, which is passed
> through spi->controller_data. But because sh-msiof HW module has a
> function to output CS by itself, which is already enabled and actual
> switch will be done by pinmux, we can silently ignore if GPIO is null.

> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> ---
>   drivers/spi/spi-sh-msiof.c |    6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)

> diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
> index ac8795f..2a2b0dd 100644
> --- a/drivers/spi/spi-sh-msiof.c
> +++ b/drivers/spi/spi-sh-msiof.c
> @@ -420,8 +420,10 @@ static void sh_msiof_spi_chipselect(struct spi_device *spi, int is_on)
>   					  !!(spi->mode & SPI_LSB_FIRST));
>   	}
>
> -	/* use spi->controller data for CS (same strategy as spi_gpio) */
> -	gpio_set_value((unsigned)spi->controller_data, value);
> +	/* use spi->controller data for CS (same strategy as spi_gpio),
> +	 * if any. otherwise let HW controll CS */

    The preferred style of multi-line comments is this:

/*
  * bla
  * bla
  */

WBR, Sergei

Re: [PATCH 03/11] spi: spi-sh-msiof: let it run even without GPIO

[Sergei Shtylyov]

Hello.

On 01-12-2013 22:19, takasi-y@ops.dti.ne.jp wrote:

> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

> In current implementation, CS is controlled by GPIO, which is passed
> through spi->controller_data. But because sh-msiof HW module has a
> function to output CS by itself, which is already enabled and actual
> switch will be done by pinmux, we can silently ignore if GPIO is null.

> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> ---
>   drivers/spi/spi-sh-msiof.c |    6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)

> diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
> index ac8795f..2a2b0dd 100644
> --- a/drivers/spi/spi-sh-msiof.c
> +++ b/drivers/spi/spi-sh-msiof.c
> @@ -420,8 +420,10 @@ static void sh_msiof_spi_chipselect(struct spi_device *spi, int is_on)
>   					  !!(spi->mode & SPI_LSB_FIRST));
>   	}
>
> -	/* use spi->controller data for CS (same strategy as spi_gpio) */
> -	gpio_set_value((unsigned)spi->controller_data, value);
> +	/* use spi->controller data for CS (same strategy as spi_gpio),
> +	 * if any. otherwise let HW controll CS */

    The preferred style of multi-line comments is this:

/*
  * bla
  * bla
  */

WBR, Sergei

Re: [PATCH 03/11] spi: spi-sh-msiof: let it run even without GPIO

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:14AM +0900, takasi-y@ops.dti.ne.jp wrote:

> -	/* use spi->controller data for CS (same strategy as spi_gpio) */
> -	gpio_set_value((unsigned)spi->controller_data, value);
> +	/* use spi->controller data for CS (same strategy as spi_gpio),
> +	 * if any. otherwise let HW controll CS */
> +	if (spi->controller_data)
> +		gpio_set_value((unsigned)spi->controller_data, value);

This makes sense in terms of what it tries to do however the standard
thing is to set the GPIO value to an error value if it isn't there
(especially since 0 is in theory a valid GPIO) so the test should be
different.

I'd also suggest changing to use the core cs_gpio field but that's a
separate thing.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 03/11] spi: spi-sh-msiof: let it run even without GPIO

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:14AM +0900, takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org wrote:

> -	/* use spi->controller data for CS (same strategy as spi_gpio) */
> -	gpio_set_value((unsigned)spi->controller_data, value);
> +	/* use spi->controller data for CS (same strategy as spi_gpio),
> +	 * if any. otherwise let HW controll CS */
> +	if (spi->controller_data)
> +		gpio_set_value((unsigned)spi->controller_data, value);

This makes sense in terms of what it tries to do however the standard
thing is to set the GPIO value to an error value if it isn't there
(especially since 0 is in theory a valid GPIO) so the test should be
different.

I'd also suggest changing to use the core cs_gpio field but that's a
separate thing.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 04/11] spi: spi-sh-msiof: set hi/low Active for HW CS

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Set hardware CS(CS control function on MSIOF <-> GPIO CS) polarity
according to SPI_CS_HIGH flag on spi->mode.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 2a2b0dd..8683732 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -169,7 +169,7 @@ static void sh_msiof_spi_set_clk_regs(struct sh_msiof_spi_priv *p,
 
 static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
 				      u32 cpol, u32 cpha,
-				      u32 tx_hi_z, u32 lsb_first)
+				      u32 tx_hi_z, u32 lsb_first, u32 cs_high)
 {
 	u32 tmp;
 	int edge;
@@ -182,8 +182,12 @@ static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
 	 *    1    1         11     11    1    1
 	 */
 	sh_msiof_write(p, FCTR, 0);
-	sh_msiof_write(p, TMDR1, 0xe2000005 | (lsb_first << 24));
-	sh_msiof_write(p, RMDR1, 0x22000005 | (lsb_first << 24));
+
+	tmp = 0;
+	tmp |= !cs_high << 25;
+	tmp |= lsb_first << 24;
+	sh_msiof_write(p, TMDR1, 0xe0000005 | tmp);
+	sh_msiof_write(p, RMDR1, 0x20000005 | tmp);
 
 	tmp = 0xa0000000;
 	tmp |= cpol << 30; /* TSCKIZ */
@@ -417,7 +421,8 @@ static void sh_msiof_spi_chipselect(struct spi_device *spi, int is_on)
 		sh_msiof_spi_set_pin_regs(p, !!(spi->mode & SPI_CPOL),
 					  !!(spi->mode & SPI_CPHA),
 					  !!(spi->mode & SPI_3WIRE),
-					  !!(spi->mode & SPI_LSB_FIRST));
+					  !!(spi->mode & SPI_LSB_FIRST),
+					  !!(spi->mode & SPI_CS_HIGH));
 	}
 
 	/* use spi->controller data for CS (same strategy as spi_gpio),
-- 
1.7.9.5

[PATCH 04/11] spi: spi-sh-msiof: set hi/low Active for HW CS

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Set hardware CS(CS control function on MSIOF <-> GPIO CS) polarity
according to SPI_CS_HIGH flag on spi->mode.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 2a2b0dd..8683732 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -169,7 +169,7 @@ static void sh_msiof_spi_set_clk_regs(struct sh_msiof_spi_priv *p,
 
 static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
 				      u32 cpol, u32 cpha,
-				      u32 tx_hi_z, u32 lsb_first)
+				      u32 tx_hi_z, u32 lsb_first, u32 cs_high)
 {
 	u32 tmp;
 	int edge;
@@ -182,8 +182,12 @@ static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
 	 *    1    1         11     11    1    1
 	 */
 	sh_msiof_write(p, FCTR, 0);
-	sh_msiof_write(p, TMDR1, 0xe2000005 | (lsb_first << 24));
-	sh_msiof_write(p, RMDR1, 0x22000005 | (lsb_first << 24));
+
+	tmp = 0;
+	tmp |= !cs_high << 25;
+	tmp |= lsb_first << 24;
+	sh_msiof_write(p, TMDR1, 0xe0000005 | tmp);
+	sh_msiof_write(p, RMDR1, 0x20000005 | tmp);
 
 	tmp = 0xa0000000;
 	tmp |= cpol << 30; /* TSCKIZ */
@@ -417,7 +421,8 @@ static void sh_msiof_spi_chipselect(struct spi_device *spi, int is_on)
 		sh_msiof_spi_set_pin_regs(p, !!(spi->mode & SPI_CPOL),
 					  !!(spi->mode & SPI_CPHA),
 					  !!(spi->mode & SPI_3WIRE),
-					  !!(spi->mode & SPI_LSB_FIRST));
+					  !!(spi->mode & SPI_LSB_FIRST),
+					  !!(spi->mode & SPI_CS_HIGH));
 	}
 
 	/* use spi->controller data for CS (same strategy as spi_gpio),
-- 
1.7.9.5

Re: [PATCH 04/11] spi: spi-sh-msiof: set hi/low Active for HW CS

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:15AM +0900, takasi-y@ops.dti.ne.jp wrote:
> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> 
> Set hardware CS(CS control function on MSIOF <-> GPIO CS) polarity
> according to SPI_CS_HIGH flag on spi->mode.

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 04/11] spi: spi-sh-msiof: set hi/low Active for HW CS

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:15AM +0900, takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org wrote:
> From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
> 
> Set hardware CS(CS control function on MSIOF <-> GPIO CS) polarity
> according to SPI_CS_HIGH flag on spi->mode.

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 05/11] spi: spi-sh-msiof: rx_need_dummy_tx variant

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

There is a variant of MSIOF, that need dummy data transfer even when
you want only to receive.

This patch adds the option
 .rx_need_dummy_tx
to sh_msiof_spi_info.

Consult "Transmit and Receive Procedures" on HWM, if it says
 - Set SICTR.TSCKE to 1
 - Write dummy transmission data to SITFDR
to *receive*, enable this.
Ape6, Rcar-H2, and Rcar-M2 are found having this type of module.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c   |    4 +++-
 include/linux/spi/sh_msiof.h |    1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 8683732..936d8ab 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -207,7 +207,7 @@ static void sh_msiof_spi_set_mode_regs(struct sh_msiof_spi_priv *p,
 {
 	u32 dr2 = ((bits - 1) << 24) | ((words - 1) << 16);
 
-	if (tx_buf)
+	if (tx_buf || (rx_buf && p->info->rx_need_dummy_tx))
 		sh_msiof_write(p, TMDR2, dr2);
 	else
 		sh_msiof_write(p, TMDR2, dr2 | 1);
@@ -464,6 +464,8 @@ static int sh_msiof_spi_txrx_once(struct sh_msiof_spi_priv *p,
 	/* write tx fifo */
 	if (tx_buf)
 		tx_fifo(p, tx_buf, words, fifo_shift);
+	else if (rx_buf && p->info->rx_need_dummy_tx)
+		tx_fifo(p, rx_buf, words, fifo_shift);
 
 	/* setup clock and rx/tx signals */
 	ret = sh_msiof_modify_ctr_wait(p, 0, CTR_TSCKE);
diff --git a/include/linux/spi/sh_msiof.h b/include/linux/spi/sh_msiof.h
index 2e8db3d..cf36781 100644
--- a/include/linux/spi/sh_msiof.h
+++ b/include/linux/spi/sh_msiof.h
@@ -5,6 +5,7 @@ struct sh_msiof_spi_info {
 	int tx_fifo_override;
 	int rx_fifo_override;
 	u16 num_chipselect;
+	u16 rx_need_dummy_tx:1;
 };
 
 #endif /* __SPI_SH_MSIOF_H__ */
-- 
1.7.9.5

[PATCH 05/11] spi: spi-sh-msiof: rx_need_dummy_tx variant

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

There is a variant of MSIOF, that need dummy data transfer even when
you want only to receive.

This patch adds the option
 .rx_need_dummy_tx
to sh_msiof_spi_info.

Consult "Transmit and Receive Procedures" on HWM, if it says
 - Set SICTR.TSCKE to 1
 - Write dummy transmission data to SITFDR
to *receive*, enable this.
Ape6, Rcar-H2, and Rcar-M2 are found having this type of module.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 drivers/spi/spi-sh-msiof.c   |    4 +++-
 include/linux/spi/sh_msiof.h |    1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 8683732..936d8ab 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -207,7 +207,7 @@ static void sh_msiof_spi_set_mode_regs(struct sh_msiof_spi_priv *p,
 {
 	u32 dr2 = ((bits - 1) << 24) | ((words - 1) << 16);
 
-	if (tx_buf)
+	if (tx_buf || (rx_buf && p->info->rx_need_dummy_tx))
 		sh_msiof_write(p, TMDR2, dr2);
 	else
 		sh_msiof_write(p, TMDR2, dr2 | 1);
@@ -464,6 +464,8 @@ static int sh_msiof_spi_txrx_once(struct sh_msiof_spi_priv *p,
 	/* write tx fifo */
 	if (tx_buf)
 		tx_fifo(p, tx_buf, words, fifo_shift);
+	else if (rx_buf && p->info->rx_need_dummy_tx)
+		tx_fifo(p, rx_buf, words, fifo_shift);
 
 	/* setup clock and rx/tx signals */
 	ret = sh_msiof_modify_ctr_wait(p, 0, CTR_TSCKE);
diff --git a/include/linux/spi/sh_msiof.h b/include/linux/spi/sh_msiof.h
index 2e8db3d..cf36781 100644
--- a/include/linux/spi/sh_msiof.h
+++ b/include/linux/spi/sh_msiof.h
@@ -5,6 +5,7 @@ struct sh_msiof_spi_info {
 	int tx_fifo_override;
 	int rx_fifo_override;
 	u16 num_chipselect;
+	u16 rx_need_dummy_tx:1;
 };
 
 #endif /* __SPI_SH_MSIOF_H__ */
-- 
1.7.9.5

Re: [PATCH 05/11] spi: spi-sh-msiof: rx_need_dummy_tx variant

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:16AM +0900, takasi-y@ops.dti.ne.jp wrote:

>  	if (tx_buf)
>  		tx_fifo(p, tx_buf, words, fifo_shift);
> +	else if (rx_buf && p->info->rx_need_dummy_tx)
> +		tx_fifo(p, rx_buf, words, fifo_shift);

This is going to transmit the contents of the RX buffer.  This means
that if there's any data in there it'll get sent but the expected
behaviour would be to send all zeros.  It's possible some devices may
misbehave if this were to happen.  It would be better to allocate some
zeros with kzalloc() and send that.

Really we should have core support for this, it's not the only
controller with such limitations.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 05/11] spi: spi-sh-msiof: rx_need_dummy_tx variant

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:16AM +0900, takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org wrote:

>  	if (tx_buf)
>  		tx_fifo(p, tx_buf, words, fifo_shift);
> +	else if (rx_buf && p->info->rx_need_dummy_tx)
> +		tx_fifo(p, rx_buf, words, fifo_shift);

This is going to transmit the contents of the RX buffer.  This means
that if there's any data in there it'll get sent but the expected
behaviour would be to send all zeros.  It's possible some devices may
misbehave if this were to happen.  It would be better to allocate some
zeros with kzalloc() and send that.

Really we should have core support for this, it's not the only
controller with such limitations.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 11/11] ARM: shmobile: koelsch: spidev for r2a11302

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Add board info for r2a11302 on-board PMIC to access with spidev.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 arch/arm/mach-shmobile/board-koelsch.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index b4add4c..5ff65ff 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -27,6 +27,7 @@
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
+#include <linux/spi/spi.h>
 #include <mach/common.h>
 #include <mach/r8a7791.h>
 #include <mach/rcar-gen2.h>
@@ -79,6 +80,15 @@ static const struct gpio_keys_platform_data koelsch_keys_pdata __initconst = {
 	.nbuttons	= ARRAY_SIZE(gpio_buttons),
 };
 
+static const struct spi_board_info spi_bus[] __initconst = {
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 6000000,
+		.mode		= SPI_MODE_3,
+		.bus_num	= 1,
+	},
+};
+
 static const struct pinctrl_map koelsch_pinctrl_map[] = {
 	/* SCIF0 (CN19: DEBUG SERIAL0) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7791",
@@ -110,6 +120,7 @@ static void __init koelsch_add_standard_devices(void)
 	platform_device_register_data(&platform_bus, "gpio-keys", -1,
 				      &koelsch_keys_pdata,
 				      sizeof(koelsch_keys_pdata));
+	spi_register_board_info(spi_bus, ARRAY_SIZE(spi_bus));
 }
 
 static const char * const koelsch_boards_compat_dt[] __initconst = {
-- 
1.7.9.5

[PATCH 11/11] ARM: shmobile: koelsch: spidev for r2a11302

[takasi-y]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Add board info for r2a11302 on-board PMIC to access with spidev.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 arch/arm/mach-shmobile/board-koelsch.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index b4add4c..5ff65ff 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -27,6 +27,7 @@
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
+#include <linux/spi/spi.h>
 #include <mach/common.h>
 #include <mach/r8a7791.h>
 #include <mach/rcar-gen2.h>
@@ -79,6 +80,15 @@ static const struct gpio_keys_platform_data koelsch_keys_pdata __initconst = {
 	.nbuttons	= ARRAY_SIZE(gpio_buttons),
 };
 
+static const struct spi_board_info spi_bus[] __initconst = {
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 6000000,
+		.mode		= SPI_MODE_3,
+		.bus_num	= 1,
+	},
+};
+
 static const struct pinctrl_map koelsch_pinctrl_map[] = {
 	/* SCIF0 (CN19: DEBUG SERIAL0) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7791",
@@ -110,6 +120,7 @@ static void __init koelsch_add_standard_devices(void)
 	platform_device_register_data(&platform_bus, "gpio-keys", -1,
 				      &koelsch_keys_pdata,
 				      sizeof(koelsch_keys_pdata));
+	spi_register_board_info(spi_bus, ARRAY_SIZE(spi_bus));
 }
 
 static const char * const koelsch_boards_compat_dt[] __initconst = {
-- 
1.7.9.5

Re: [PATCH 11/11] ARM: shmobile: koelsch: spidev for r2a11302

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:22AM +0900, takasi-y@ops.dti.ne.jp wrote:
> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> 
> Add board info for r2a11302 on-board PMIC to access with spidev.

This doesn't sound clever - why is the PMIC being accessed with spidev
and not with an MFD integrated into the relevant kernel frameworks?
Apart from the issue of integrating in the normal way for Linus the PMIC
typically has the ability to cause lasting physical damage to the
system.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 11/11] ARM: shmobile: koelsch: spidev for r2a11302

[Mark Brown]

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

On Mon, Dec 02, 2013 at 03:19:22AM +0900, takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org wrote:
> From: Takashi Yoshii <takasi-y-nDL5PR/MsHhHfZP73Gtkiw@public.gmane.org>
> 
> Add board info for r2a11302 on-board PMIC to access with spidev.

This doesn't sound clever - why is the PMIC being accessed with spidev
and not with an MFD integrated into the relevant kernel frameworks?
Apart from the issue of integrating in the normal way for Linus the PMIC
typically has the ability to cause lasting physical damage to the
system.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 11/11] ARM: shmobile: koelsch: spidev for r2a11302

[Geert Uytterhoeven]

Hi Yoshii-san,

On Mon, Dec 2, 2013 at 2:24 PM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Dec 02, 2013 at 03:19:22AM +0900, takasi-y@ops.dti.ne.jp wrote:
>> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>>
>> Add board info for r2a11302 on-board PMIC to access with spidev.
>
> This doesn't sound clever - why is the PMIC being accessed with spidev
> and not with an MFD integrated into the relevant kernel frameworks?
> Apart from the issue of integrating in the normal way for Linus the PMIC
> typically has the ability to cause lasting physical damage to the
> system.

Do you have a test application to talk to the PMIC, so I can test if everything
works?
Perhaps this can be turned into a proper PMIC driver?

Thanks in advance!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 11/11] ARM: shmobile: koelsch: spidev for r2a11302

[Geert Uytterhoeven]

Hi Yoshii-san,

On Mon, Dec 2, 2013 at 2:24 PM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Dec 02, 2013 at 03:19:22AM +0900, takasi-y@ops.dti.ne.jp wrote:
>> From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>>
>> Add board info for r2a11302 on-board PMIC to access with spidev.
>
> This doesn't sound clever - why is the PMIC being accessed with spidev
> and not with an MFD integrated into the relevant kernel frameworks?
> Apart from the issue of integrating in the normal way for Linus the PMIC
> typically has the ability to cause lasting physical damage to the
> system.

Do you have a test application to talk to the PMIC, so I can test if everything
works?
Perhaps this can be turned into a proper PMIC driver?

Thanks in advance!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds