| Message ID | 1385921962-19843-9-git-send-email-takasi-y@ops.dti.ne.jp (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
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
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
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
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 --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)