diff mbox

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

Message ID 1385921962-19843-9-git-send-email-takasi-y@ops.dti.ne.jp
State Changes Requested
Headers show

Commit Message

takasi-y@ops.dti.ne.jp Dec. 1, 2013, 6:19 p.m. UTC
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(+)

Comments

Linus Walleij Dec. 3, 2013, 10:12 a.m. UTC | #1
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
--
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
Simon Horman Dec. 5, 2013, 3:02 a.m. UTC | #2
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.
--
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
Linus Walleij Dec. 11, 2013, 12:27 p.m. UTC | #3
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
--
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
Olof Johansson Dec. 12, 2013, 12:53 a.m. UTC | #4
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
--
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
diff mbox

Patch

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)