[PATCH 1/2] mcspi: Add support for GPIO chip select lines

[PATCH 1/2] mcspi: Add support for GPIO chip select lines

[Ben Gamari]

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 <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 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 <linux/slab.h>
 
 #include <linux/spi/spi.h>
+#include <linux/gpio.h>
 
 #include <plat/dma.h>
 #include <plat/clock.h>
@@ -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);
+	}
 }
 
 static void omap2_mcspi_set_master_mode(struct spi_master *master)
-- 
1.7.0.4


------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

Re: [PATCH 1/2] mcspi: Add support for GPIO chip select lines

[Grant Likely]

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 <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  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 <linux/slab.h>
>  
>  #include <linux/spi/spi.h>
> +#include <linux/gpio.h>
>  
>  #include <plat/dma.h>
>  #include <plat/clock.h>
> @@ -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 

Re: [PATCH 1/2] mcspi: Add support for GPIO chip select lines

[Ben Gamari]

> 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.

Sorry for my ignorance but I really have no idea how one would hook this
up in the board code (which IMHO is where this sort of chip select
configuration belongs). Looking at the beagleboard board file I see no
reference to a spi master platform_device. The SPI devices are registered
through spi_register_board_info. Could you clarify how this would work?

> 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.

That makes sense given the name.

> 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).
> 
Fair enough. I could convince myself that either approach makes more
sense.

- Ben


------------------------------------------------------------------------------
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 

Re: [PATCH 1/2] mcspi: Add support for GPIO chip select lines

[Grant Likely]

Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

>> 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.
>
>Sorry for my ignorance but I really have no idea how one would hook
>this
>up in the board code (which IMHO is where this sort of chip select
>configuration belongs). Looking at the beagleboard board file I see no
>reference to a spi master platform_device. The SPI devices are
>registered
>through spi_register_board_info. Could you clarify how this would work?

The spi_master platform device is registered somewhere in the inappropriate support code. You need to arrange to make sure the correct pdata is attached to it when it gets registered. There /should/ be a mechanism for doing so.

All spi devices already specify a cs number anyway. What you can do is use the cs number as the lookup index into the gpio table, and remember to reserve a cs# for the 'native' cs line.

g.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d

GPIO chip select support in McSPI

[Ben Gamari]

I've included the OMAP list so that I can hopefully get some feedback
from folks more familiar with this code.

Background:

I've been working on adding support for GPIO chip select lines to the
McSPI driver. Grant has been working with me to try getting the
in-kernel interface right and we have finally converged on a solution
whereby a table of GPIO lines will be passed to the McSPI driver through
platform_device.device.platform_data. Unfortunately, as explained below,
there is no clear path to support this in the current McSPI
initialization code.


On Thu, 03 Mar 2011 14:42:07 -0700, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> The spi_master platform device is registered somewhere in the
> inappropriate support code. You need to arrange to make sure the
> correct pdata is attached to it when it gets registered. There
> /should/ be a mechanism for doing so.
> 
> All spi devices already specify a cs number anyway. What you can do is
> use the cs number as the lookup index into the gpio table, and
> remember to reserve a cs# for the 'native' cs line.
> 
I've done as you suggested and added support to the McSPI driver by
passing a GPIO table through platform_data. A patch will be coming
shortly.

Unfortunately, I'm really not sure how to restructure the OMAP code to
pass this information along. Currently the McSPI devices are registered
in arch/arm/mach-omap2/devices.c (omap_init_mcspi). In order to make the
GPIO CS support configurable by board code, we need some way to change
the (currently static) platform_devices prior to registration. Does
anyone have any suggestions on how this code could be refactored to
allow for this with minimal code duplication? Obviously we could just
move the platform_devices into the board files but this seems like a lot
of code duplication to support functionality that few boards will use.

Thoughts?

- Ben

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: GPIO chip select support in McSPI

[Grant Likely]

On Sun, Mar 13, 2011 at 03:04:11PM -0400, Ben Gamari wrote:
> I've included the OMAP list so that I can hopefully get some feedback
> from folks more familiar with this code.
> 
> Background:
> 
> I've been working on adding support for GPIO chip select lines to the
> McSPI driver. Grant has been working with me to try getting the
> in-kernel interface right and we have finally converged on a solution
> whereby a table of GPIO lines will be passed to the McSPI driver through
> platform_device.device.platform_data. Unfortunately, as explained below,
> there is no clear path to support this in the current McSPI
> initialization code.
> 
> 
> On Thu, 03 Mar 2011 14:42:07 -0700, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> > The spi_master platform device is registered somewhere in the
> > inappropriate support code. You need to arrange to make sure the
> > correct pdata is attached to it when it gets registered. There
> > /should/ be a mechanism for doing so.
> > 
> > All spi devices already specify a cs number anyway. What you can do is
> > use the cs number as the lookup index into the gpio table, and
> > remember to reserve a cs# for the 'native' cs line.
> > 
> I've done as you suggested and added support to the McSPI driver by
> passing a GPIO table through platform_data. A patch will be coming
> shortly.
> 
> Unfortunately, I'm really not sure how to restructure the OMAP code to
> pass this information along. Currently the McSPI devices are registered
> in arch/arm/mach-omap2/devices.c (omap_init_mcspi). In order to make the
> GPIO CS support configurable by board code, we need some way to change
> the (currently static) platform_devices prior to registration. Does
> anyone have any suggestions on how this code could be refactored to
> allow for this with minimal code duplication? Obviously we could just
> move the platform_devices into the board files but this seems like a lot
> of code duplication to support functionality that few boards will use.

I see two solutions:
1) platform code registers a bus notifier so that it gets called back
before the device gets bound to a driver.  Then it can augment the
platform data.
2) add an api to arch/arm/mach-omap2/devices.c for providing a cs
table before the device gets registered (must be called before
arch_initcall() time).

g.

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: GPIO chip select support in McSPI

[Ben Gamari]

On Mon, 14 Mar 2011 13:25:36 -0600, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> I see two solutions:
> 1) platform code registers a bus notifier so that it gets called back
> before the device gets bound to a driver.  Then it can augment the
> platform data.
> 
This sounds like it might be a bit involved and I'm not terribly
familiar with these facets of the driver model. This would probably be
the more flexible approach but I think I'll stick with the simpler
option.

> 2) add an api to arch/arm/mach-omap2/devices.c for providing a cs
> table before the device gets registered (must be called before
> arch_initcall() time).
> 
This is along the lines of what I was thinking. Any thoughts on how to
get function called before arch_initcall()?

- Ben

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

Re: GPIO chip select support in McSPI

[Grant Likely]

On Mon, Mar 14, 2011 at 10:22:31PM -0400, Ben Gamari wrote:
> On Mon, 14 Mar 2011 13:25:36 -0600, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> > I see two solutions:
> > 1) platform code registers a bus notifier so that it gets called back
> > before the device gets bound to a driver.  Then it can augment the
> > platform data.
> > 
> This sounds like it might be a bit involved and I'm not terribly
> familiar with these facets of the driver model. This would probably be
> the more flexible approach but I think I'll stick with the simpler
> option.
> 
> > 2) add an api to arch/arm/mach-omap2/devices.c for providing a cs
> > table before the device gets registered (must be called before
> > arch_initcall() time).
> > 
> This is along the lines of what I was thinking. Any thoughts on how to
> get function called before arch_initcall()?

You can call it from .init_machine()

g.

> 
> - Ben

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

[PATCH 2/2] beagle-daq: Initial commit of board devices setup

[Ben Gamari]

---
 arch/arm/mach-omap2/board-omap3beagle.c |  204 ++++++++++++++++++++++++++++++-
 1 files changed, 201 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 14f4224..ad72685 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -29,8 +29,10 @@
 #include <linux/mtd/nand.h>
 #include <linux/mmc/host.h>
 
+#include <linux/spi/spi.h>
 #include <linux/regulator/machine.h>
 #include <linux/i2c/twl.h>
+#include <linux/i2c/pca953x.h>
 
 #include <mach/hardware.h>
 #include <asm/mach-types.h>
@@ -44,6 +46,7 @@
 #include <plat/gpmc.h>
 #include <plat/nand.h>
 #include <plat/usb.h>
+#include <plat/mcspi.h>
 
 #include "mux.h"
 #include "hsmmc.h"
@@ -413,10 +416,18 @@ static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
 	},
 };
 
+static struct pca953x_platform_data beagledaq_gpio_expander_info = {
+	.gpio_base = OMAP_MAX_GPIO_LINES,
+};
+
 static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
-       {
-               I2C_BOARD_INFO("eeprom", 0x50),
-       },
+	{
+		I2C_BOARD_INFO("eeprom", 0x50),
+	},
+	{
+		I2C_BOARD_INFO("tca6416", 0x21),
+		.platform_data = &beagledaq_gpio_expander_info,
+	},
 };
 
 static int __init omap3_beagle_i2c_init(void)
@@ -425,6 +436,9 @@ static int __init omap3_beagle_i2c_init(void)
 			ARRAY_SIZE(beagle_i2c_boardinfo));
 	/* Bus 3 is attached to the DVI port where devices like the pico DLP
 	 * projector don't work reliably with 400kHz */
+	gpio_request(139, "GPIO-IRQ");
+	gpio_direction_input(139);
+	beagledaq_gpio_expander_info.irq_base = gpio_to_irq(139);
 	omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom));
 	return 0;
 }
@@ -499,6 +513,188 @@ static struct platform_device *omap3_beagle_devices[] __initdata = {
 	&beagle_dss_device,
 };
 
+int csmux_set_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	return -ENOSYS;
+}
+
+int csmux_set_direction_output(struct gpio_chip *chip, unsigned offset, int value)
+{
+	return -ENOSYS;
+}
+
+static int csmux_get(struct gpio_chip *chip, unsigned offset)
+{
+	return -ENOSYS;
+}
+
+#define BEAGLEDAQ_CONVSTART    145
+#define BEAGLEDAQ_ADC_CS_EN	135
+#define BEAGLEDAQ_ADC_CS_MUX0	134
+#define BEAGLEDAQ_ADC_CS_MUX1	133
+#define BEAGLEDAQ_DAC_CS_EN	161
+#define BEAGLEDAQ_DAC_CS_MUX0	157
+#define BEAGLEDAQ_DAC_CS_MUX1	162
+
+static void adc_csmux_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	gpio_set_value(BEAGLEDAQ_ADC_CS_EN, 0);
+	gpio_set_value(BEAGLEDAQ_ADC_CS_MUX0, (offset & 0x1) != 0);
+	gpio_set_value(BEAGLEDAQ_ADC_CS_MUX1, (offset & 0x2) != 0);
+	if (value) gpio_set_value(BEAGLEDAQ_ADC_CS_EN, 1);
+}
+
+static const char* adc_csmux_names[] = { "adc1", "adc2", "adc3", "adc4" };
+
+static struct gpio_chip adc_csmux_chip = {
+	.label = "BeagleDAQ ADC chip selects",
+	.direction_input = csmux_set_direction_input,
+	.get = csmux_get,
+	.direction_output = csmux_set_direction_output,
+	.set = adc_csmux_set,
+	.base = -1,
+	.ngpio = 4,
+	.names = adc_csmux_names,
+};
+
+void dac_csmux_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	gpio_set_value(BEAGLEDAQ_DAC_CS_EN, 0);
+	gpio_set_value(BEAGLEDAQ_DAC_CS_MUX0, (offset & 0x1) != 0);
+	gpio_set_value(BEAGLEDAQ_DAC_CS_MUX1, (offset & 0x2) != 0);
+	if (value) gpio_set_value(BEAGLEDAQ_DAC_CS_EN, 1);
+};
+
+static const char* dac_csmux_names[] = { "dac1", "dac2", "dac3", "dac4" };
+
+static struct gpio_chip dac_csmux_chip = {
+	.label = "BeagleDAQ DAC chip selects",
+	.dev = NULL,
+	.direction_input = csmux_set_direction_input,
+	.get = csmux_get,
+	.direction_output = csmux_set_direction_output,
+	.set = dac_csmux_set,
+	.base = -1,
+	.ngpio = 4,
+	.names = dac_csmux_names,
+};
+
+#define MBIT_SEC 1000000
+static struct spi_board_info beagle_mcspi_board_info[] = {
+	// spi 3.0
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 20*MBIT_SEC,
+		.bus_num	= 3,
+		.chip_select	= 0,
+		.mode		= SPI_MODE_1,
+	},
+	// spi 3.1
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 20*MBIT_SEC,
+		.bus_num	= 3,
+		.chip_select	= 1,
+		.mode		= SPI_MODE_1,
+	},
+	// spi 3.2
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 20*MBIT_SEC,
+		.bus_num	= 3,
+		.chip_select	= 2,
+		.mode		= SPI_MODE_1,
+	},
+	// spi 3.3
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 20*MBIT_SEC,
+		.bus_num	= 3,
+		.chip_select	= 3,
+		.mode		= SPI_MODE_1,
+	},
+
+	// spi 4.0
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 20*MBIT_SEC,
+		.bus_num	= 4,
+		.chip_select	= 0,
+		.mode		= SPI_MODE_1,
+	},
+	// spi 4.1
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 20*MBIT_SEC,
+		.bus_num	= 4,
+		.chip_select	= 1,
+		.mode		= SPI_MODE_1,
+	},
+	// spi 4.2
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 20*MBIT_SEC,
+		.bus_num	= 4,
+		.chip_select	= 2,
+		.mode		= SPI_MODE_1,
+	},
+	// spi 4.3
+	{
+		.modalias	= "spidev",
+		.max_speed_hz	= 20*MBIT_SEC,
+		.bus_num	= 4,
+		.chip_select	= 3,
+		.mode		= SPI_MODE_1,
+	},
+};
+
+static void __init omap3_beagle_config_mcspi3_pins(void)
+{
+	// NOTE: Clock pins need to be in input mode
+	omap_mux_init_signal("sdmmc2_clk.mcspi3_clk", OMAP_PIN_INPUT);
+	omap_mux_init_signal("sdmmc2_cmd.mcspi3_simo", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("sdmmc2_dat0.mcspi3_somi", OMAP_PIN_INPUT_PULLUP);
+	omap_mux_init_signal("sdmmc2_dat3.gpio135", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("sdmmc2_dat2.gpio134", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("sdmmc2_dat1.gpio133", OMAP_PIN_OUTPUT);
+}
+
+static void __init omap3_beagle_config_mcspi4_pins(void)
+{
+	// NOTE: Clock pins need to be in input mode
+	omap_mux_init_signal("mcbsp1_clkr.mcspi4_clk", OMAP_PIN_INPUT);
+	omap_mux_init_signal("mcbsp1_dx.mcspi4_simo", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("mcbsp1_dr.mcspi4_somi", OMAP_PIN_INPUT_PULLUP);
+	omap_mux_init_signal("mcbsp1_fsx.gpio161", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("mcbsp1_fsr.gpio157", OMAP_PIN_OUTPUT);
+	omap_mux_init_signal("mcbsp1_clkx.gpio162", OMAP_PIN_OUTPUT);
+}
+
+static void __init omap3_beagledaq_init(void)
+{
+	gpio_request_one(BEAGLEDAQ_CONVSTART, GPIOF_OUT_INIT_LOW, "BeagleDAQ conversion trigger");
+	gpio_export(BEAGLEDAQ_CONVSTART, false);
+
+	omap3_beagle_config_mcspi3_pins();
+	omap3_beagle_config_mcspi4_pins();
+
+	gpiochip_add(&adc_csmux_chip);
+	gpiochip_add(&dac_csmux_chip);
+
+	beagle_mcspi_board_info[0].controller_data = (void*) adc_csmux_chip.base + 0;
+	beagle_mcspi_board_info[1].controller_data = (void*) adc_csmux_chip.base + 1;
+	beagle_mcspi_board_info[2].controller_data = (void*) adc_csmux_chip.base + 2;
+	beagle_mcspi_board_info[3].controller_data = (void*) adc_csmux_chip.base + 3;
+
+	beagle_mcspi_board_info[4].controller_data = (void*) dac_csmux_chip.base + 0;
+	beagle_mcspi_board_info[5].controller_data = (void*) dac_csmux_chip.base + 1;
+	beagle_mcspi_board_info[6].controller_data = (void*) dac_csmux_chip.base + 2;
+	beagle_mcspi_board_info[7].controller_data = (void*) dac_csmux_chip.base + 3;
+
+	spi_register_board_info(beagle_mcspi_board_info,
+			ARRAY_SIZE(beagle_mcspi_board_info));
+}
+
 static void __init omap3beagle_flash_init(void)
 {
 	u8 cs = 0;
@@ -567,6 +763,8 @@ static void __init omap3_beagle_init(void)
 			ARRAY_SIZE(omap3_beagle_devices));
 	omap_serial_init();
 
+	omap3_beagledaq_init();
+
 	omap_mux_init_gpio(170, OMAP_PIN_INPUT);
 	gpio_request(170, "DVI_nPD");
 	/* REVISIT leave DVI powered down until it's needed ... */
-- 
1.7.0.4


------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb