From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [PATCH 1/2] mcspi: Add support for GPIO chip select lines Date: Wed, 2 Mar 2011 14:50:26 -0700 Message-ID: <20110302215026.GA22854@angua.secretlab.ca> References: <1297635034-24504-1-git-send-email-bgamari.foss@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: spi-devel-general-TtF/mJH4Jtrk1uMJSBkQmQ@public.gmane.org To: Ben Gamari Return-path: Content-Disposition: inline In-Reply-To: <1297635034-24504-1-git-send-email-bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org On Sun, Feb 13, 2011 at 05:10:33PM -0500, Ben Gamari wrote: > Many applications require more chip select lines than the board or > processor allow. Introduce a mechanism to allow use of GPIO pins as chip > select lines with the McSPI controller. To use this functionality, one > simply specifies the GPIO number in spi_board_info.controller_data. > > Signed-off-by: Ben Gamari > --- > drivers/spi/omap2_mcspi.c | 13 ++++++++----- > 1 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c > index 951a160..ca4a7dc 100644 > --- a/drivers/spi/omap2_mcspi.c > +++ b/drivers/spi/omap2_mcspi.c > @@ -35,6 +35,7 @@ > #include > > #include > +#include > > #include > #include > @@ -235,11 +236,13 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable) > > static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active) > { > - u32 l; > - > - l = mcspi_cached_chconf0(spi); > - MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); > - mcspi_write_chconf0(spi, l); > + if (spi->controller_data) { > + gpio_set_value((unsigned) spi->controller_data, cs_active); > + } else { > + u32 l = mcspi_cached_chconf0(spi); > + MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active); > + mcspi_write_chconf0(spi, l); > + } Yes, this is a better approach. However, I'd rather see the gpio data passed as an array to the spi master platform_device via the private_data structure. controller_data is really intended to be a pointer that the spi_master can populate if it needs to, so it is not a good idea to populate it in setup code instead. Also, I see cs line wireups more as a property of the controller than a property of the device (there is some debate on this area, but in the end it probably is more important to be consistent about how the data is passed than the relative merits between master-centric or slave-centric; which really means I get to make the decision about which approach spi_masters should take). g. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev