From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Hemanth V" Subject: Re: [PATCH 2/2] McSPI Slave and DMA,FIFO support Date: Thu, 21 May 2009 15:09:10 +0530 Message-ID: <00c401c9d9f8$00dbc750$LocalHost@wipultra793> References: <5A47E75E594F054BAF48C5E4FC4B92AB030574190F@dbde02.ent.ti.com> <878wkrpuzp.fsf@deeprootsystems.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Return-path: Received: from comal.ext.ti.com ([198.47.26.152]:39373 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753441AbZEUJjV (ORCPT ); Thu, 21 May 2009 05:39:21 -0400 Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Gadiyar, Anand" , Kevin Hilman , Tony Lindgren Cc: linux-omap@vger.kernel.org ----- Original Message ----- From: "Kevin Hilman" To: "Gadiyar, Anand" Cc: "V, Hemanth" ; Sent: Wednesday, May 20, 2009 10:33 PM Subject: Re: [PATCH 2/2] McSPI Slave and DMA,FIFO support > "Gadiyar, Anand" writes: > >>> -----Original Message----- >>> From: linux-omap-owner@vger.kernel.org >>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hemanth V >>> Sent: Wednesday, May 20, 2009 11:27 AM >>> To: linux-omap@vger.kernel.org >>> Subject: [PATCH 2/2] McSPI Slave and DMA,FIFO support >>> >>> This patch adds MUX changes for SPI2 and also adds an >>> option for test driver >>> >>> Signed-off-by: Hemanth V >>> --- >>> arch/arm/mach-omap2/board-3430sdp.c | 26 ++++++++++++++++++++++++++ >>> arch/arm/mach-omap2/mux.c | 11 +++++++++++ >>> arch/arm/plat-omap/include/mach/mux.h | 7 +++++++ >>> 3 files changed, 44 insertions(+) >>> >>> Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c >>> =================================================================== >>> --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2009-05-20 >>> 11:02:34.000000000 +0530 >>> +++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2009-05-20 >>> 11:05:22.000000000 +0530 >>> @@ -228,6 +228,13 @@ >>> .single_channel = 1, /* 0: slave, 1: master */ >>> }; >>> >>> +#ifdef CONFIG_SPI_DEBUG >>> +static struct omap2_mcspi_device_config dummy_mcspi_config = { >>> + .turbo_mode = 0, >>> + .single_channel = 1, /* 0: slave, 1: master */ >>> +}; >>> +#endif >>> + >>> static struct spi_board_info sdp3430_spi_board_info[] __initdata = { >>> [0] = { >>> /* >>> @@ -242,6 +249,18 @@ >>> .irq = 0, >>> .platform_data = &tsc2046_config, >>> }, >>> +#ifdef CONFIG_SPI_DEBUG >>> + [1] = { >>> + /* SPI test driver attached to SPI2 controller by >>> + * default >>> + */ >>> + .modalias = "spitst", >>> + .bus_num = 2, >>> + .chip_select = 0, >>> + .max_speed_hz = 1500000, >>> + .controller_data = &dummy_mcspi_config, >>> + }, >>> +#endif >>> }; >>> >>> static struct platform_device sdp3430_lcd_device = { >>> @@ -666,6 +685,13 @@ >>> >>> static void __init omap_3430sdp_init(void) >>> { >>> + >>> + /* SPI2 Pin MUX */ >>> + omap_cfg_reg(AA3_3430_McSPI2_CLK); >>> + omap_cfg_reg(Y2_3430_McSPI2_SIMO); >>> + omap_cfg_reg(Y3_3430_McSPI2_SOMI); >>> + omap_cfg_reg(Y4_3430_McSPI2_CS0); >>> + >> >> This will still change the padconf for this port unconditionally. >> >> How do we handle the case where the same platform (SDP in this case) >> could have different configurations McSPI2 vs USBHOST2, etc? Is there >> a clean way, or do we have no option but to use a CONFIG option? > > What about building both as modules and doing the muxing on module > load with a warning if it's taking the pins away from antother > feature. > > Longer term, we need a more dynamic way to request pins when there are > conflicts like this. > > Kevin Might be the easiest option right now is to remove omap_cfg_reg calls and allow users to add it when required. Hemanth > > >