Message ID | 499B4B64.30109@balister.org (mailing list archive) |
---|---|
State | Changes Requested, archived |
Headers | show |
* Philip Balister <philip@balister.org> [090217 15:42]: > A number of people have tried using the McSPI3 interface with the spidev > driver. Running the spidev_test program shows data coming out of the > interface, but when we connect the SIMO to SOMI pins, the spidev_test > program shows only 0's. Someone tried wiring SOMI to +volts and still > only saw 0 read. > > I'm attaching the patch used to configure the pinmux and the spidev > driver. Any suggestions would be great, we are pretty confused at this > point. > > Thanks, > > Philip > diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c > index fe97bab..ed7fee6 100644 > --- a/arch/arm/mach-omap2/board-omap3beagle.c > +++ b/arch/arm/mach-omap2/board-omap3beagle.c > @@ -23,6 +23,7 @@ > #include <linux/gpio.h> > #include <linux/input.h> > #include <linux/gpio_keys.h> > +#include <linux/spi/spi.h> > > #include <linux/mtd/mtd.h> > #include <linux/mtd/partitions.h> > @@ -311,6 +312,27 @@ static struct platform_device *omap3_beagle_devices[] __initdata = { > &keys_gpio, > }; > > +static struct spi_board_info beagle_spi_board_info[] = { > + { > + .modalias = "spidev", > + .max_speed_hz = 48000000, //48 Mbps > + .bus_num = 3, > + .chip_select = 0, > + .mode = SPI_MODE_1, > + }, > +}; > + > +static struct spi_board_info beagle_spi_board_info2[] = { > + { > + .modalias = "spidev", > + .max_speed_hz = 48000000, //48 Mbps > + .bus_num = 4, > + .chip_select = 0, > + .mode = SPI_MODE_1, > + }, > +}; > + > + > static void __init omap3beagle_flash_init(void) > { > u8 cs = 0; > @@ -358,6 +380,63 @@ static void __init omap3_beagle_init(void) > omap_board_config_size = ARRAY_SIZE(omap3_beagle_config); > omap_serial_init(); > > + > +/* > + printk("Debug ================> MMC2 >>> start\n"); > + omap_cfg_reg(XXX_3430_MMC2_CLK); > + omap_cfg_reg(XXX_3430_MMC2_cmd); > + omap_cfg_reg(XXX_3430_MMC2_dat0); > + omap_cfg_reg(XXX_3430_MMC2_dat1); > + omap_cfg_reg(XXX_3430_MMC2_dat2); > + omap_cfg_reg(XXX_3430_MMC2_dat3); > + omap_cfg_reg(XXX_3430_MMC2_dat4); > + omap_cfg_reg(XXX_3430_MMC2_dat5); > + omap_cfg_reg(XXX_3430_MMC2_dat6); > + omap_cfg_reg(XXX_3430_MMC2_dat7); > + printk("Debug ================> MMC2 >>> end\n"); > + printk("Debug ================> UART2 >>> start\n"); > + omap_cfg_reg(XXX_3430_UART2_cts); > + omap_cfg_reg(XXX_3430_UART2_rts); > + omap_cfg_reg(XXX_3430_UART2_tx); > + omap_cfg_reg(XXX_3430_UART2_rx); > + printk("Debug ================> UART2 >>> end\n"); > +*/ > + > + printk("Debug ================> MCSPI >>> start\n"); > + > + omap_cfg_reg(XXX_3430_MCSPI3_CLK); > + omap_cfg_reg(XXX_3430_MCSPI3_SIMO); > + omap_cfg_reg(XXX_3430_MCSPI3_SOMI); > + omap_cfg_reg(XXX_3430_MCSPI3_CS0); > + omap_cfg_reg(XXX_3430_MCSPI3_CS1); > + //avoid other pins/balls with McSPI function > + omap_cfg_reg(XXX_3430_gpio_88); > + omap_cfg_reg(XXX_3430_gpio_89); > + omap_cfg_reg(XXX_3430_gpio_90); > + omap_cfg_reg(XXX_3430_gpio_91); > + omap_cfg_reg(XXX_3430_gpio_92); > + omap_cfg_reg(XXX_3430_gpio_14); > + omap_cfg_reg(XXX_3430_gpio_15); > + omap_cfg_reg(XXX_3430_gpio_16); > + omap_cfg_reg(XXX_3430_gpio_17); > + omap_cfg_reg(XXX_3430_gpio_21); > + > + omap_cfg_reg(XXX_3430_MCSPI4_CLK); > + omap_cfg_reg(XXX_3430_MCSPI4_SIMO); > + omap_cfg_reg(XXX_3430_MCSPI4_SOMI); > + omap_cfg_reg(XXX_3430_MCSPI4_CS0); > + //avoid other pins/balls with McSPI function > + omap_cfg_reg(XXX_3430_gpio_151); > + printk("Debug ================> MCSPI >>> end\n"); > + > + > + printk("Debug ================> register SLAVE DEVICES using [spidev] protocol driver >>> start\n"); > + spi_register_board_info(beagle_spi_board_info, ARRAY_SIZE(beagle_spi_board_info)); > + spi_register_board_info(beagle_spi_board_info2, ARRAY_SIZE(beagle_spi_board_info2)); > + printk("Debug ================> register SLAVE DEVICES using [spidev] protocol driver >>> end\n"); > + omap_cfg_reg(XXX_3430_gpio_157); //add by yuchih > + > + Maybe some of these debug printk statements should be left out? :) > omap_cfg_reg(J25_34XX_GPIO170); > gpio_request(170, "DVI_nPD"); > /* REVISIT leave DVI powered down until it's needed ... */ > diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c > index 1556688..9b55cf8 100644 > --- a/arch/arm/mach-omap2/mux.c > +++ b/arch/arm/mach-omap2/mux.c > @@ -472,6 +472,87 @@ MUX_CFG_34XX("AF5_34XX_GPIO142", 0x170, > MUX_CFG_34XX("AE5_34XX_GPIO143", 0x172, > OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT) > > +/* UART2 */ > +MUX_CFG_34XX("XXX_3430_UART2_cts", 0x16c, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_UART2_rts", 0x16e, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_UART2_tx", 0x170, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_UART2_rx", 0x172, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLUP) > + > +/* MMC2 */ > +MUX_CFG_34XX("XXX_3430_MMC2_CLK", 0x158, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_cmd", 0x15a, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_dat0", 0x15c, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_dat1", 0x15e, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_dat2", 0x160, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_dat3", 0x162, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_dat4", 0x164, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_dat5", 0x166, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_dat6", 0x168, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_MMC2_dat7", 0x16a, > + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) > + > +/* MCSPI3 */ > +MUX_CFG_34XX("XXX_3430_MCSPI3_CLK", 0x158, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_MCSPI3_SIMO", 0x15a, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_MCSPI3_SOMI", 0x15c, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLUP) > +MUX_CFG_34XX("XXX_3430_MCSPI3_CS0", 0x162, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_MCSPI3_CS1", 0x160, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > + > +MUX_CFG_34XX("XXX_3430_gpio_88", 0x100, //mcspi3_clk > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_gpio_89", 0x102, //mcspi3_simo > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_gpio_90", 0x104, //mcspi3_somi > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_gpio_91", 0x106, //mcspi3_cs0 > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_gpio_92", 0x108, //mcspi3_cs1 > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > + > +MUX_CFG_34XX("XXX_3430_gpio_14", 0x5dc, //mcspi3_simo > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_gpio_15", 0x5de, //mcspi3_somi > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_gpio_16", 0x5e0, //mcspi3_cs0 > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_gpio_17", 0x5e2, //mcspi3_clk > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +MUX_CFG_34XX("XXX_3430_gpio_21", 0x5ea, //mcspi3_cs1 > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > +/* MCSPI4 */ > +MUX_CFG_34XX("XXX_3430_MCSPI4_CLK", 0x18c, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_MCSPI4_SIMO", 0x190, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_MCSPI4_SOMI", 0x192, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLUP) > +MUX_CFG_34XX("XXX_3430_MCSPI4_CS0", 0x196, > + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) > +MUX_CFG_34XX("XXX_3430_gpio_151", 0x182, > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > + > +/* GPIO */ > +MUX_CFG_34XX("XXX_3430_gpio_157", 0x18e, > + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) > + > }; > > #define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins) > @@ -494,6 +575,7 @@ static void __init_or_module omap2_cfg_debug(const struct pin_config *cfg, u16 r > > #ifdef CONFIG_OMAP_MUX_DEBUG > debug = cfg->debug; > + debug = 1; //add by yuchih > #endif > warn = (orig != reg); > if (debug || warn) > @@ -540,6 +622,9 @@ static int __init_or_module omap34xx_cfg_reg(const struct pin_config *cfg) > reg |= cfg->mux_val; > omap2_cfg_debug(cfg, reg); > omap_ctrl_writew(reg, cfg->mux_reg); > + > + omap2_cfg_debug(cfg, reg); //add by yuchih > + > spin_unlock_irqrestore(&mux_spin_lock, flags); > > return 0; > diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-omap/include/mach/mux.h > index 67fddec..3dea82e 100644 > --- a/arch/arm/plat-omap/include/mach/mux.h > +++ b/arch/arm/plat-omap/include/mach/mux.h > @@ -795,7 +795,54 @@ enum omap34xx_index { > AF6_34XX_GPIO140_UP, > AE6_34XX_GPIO141, > AF5_34XX_GPIO142, > - AE5_34XX_GPIO143 > + AE5_34XX_GPIO143, > + > + > + /* UART2 */ > + XXX_3430_UART2_cts, > + XXX_3430_UART2_rts, > + XXX_3430_UART2_tx, > + XXX_3430_UART2_rx, > + > + /* MMC2 */ > + XXX_3430_MMC2_CLK, > + XXX_3430_MMC2_cmd, > + XXX_3430_MMC2_dat0, > + XXX_3430_MMC2_dat1, > + XXX_3430_MMC2_dat2, > + XXX_3430_MMC2_dat3, > + XXX_3430_MMC2_dat4, > + XXX_3430_MMC2_dat5, > + XXX_3430_MMC2_dat6, > + XXX_3430_MMC2_dat7, > + > + /* MCSPI3 */ > + XXX_3430_MCSPI3_CLK, > + XXX_3430_MCSPI3_SIMO, > + XXX_3430_MCSPI3_SOMI, > + XXX_3430_MCSPI3_CS0, > + XXX_3430_MCSPI3_CS1, > + XXX_3430_gpio_88, > + XXX_3430_gpio_89, > + XXX_3430_gpio_90, > + XXX_3430_gpio_91, > + XXX_3430_gpio_92, > + XXX_3430_gpio_14, > + XXX_3430_gpio_15, > + XXX_3430_gpio_16, > + XXX_3430_gpio_17, > + XXX_3430_gpio_21, > + > + /* MCSPI4 */ > + XXX_3430_MCSPI4_CLK, > + XXX_3430_MCSPI4_SIMO, > + XXX_3430_MCSPI4_SOMI, > + XXX_3430_MCSPI4_CS0, > + XXX_3430_gpio_151, //mcspi_clk > + > + /* GPIO*/ > + XXX_3430_gpio_157 > + > }; > > struct omap_mux_cfg { -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 17 February 2009, Philip Balister wrote: > > A number of people have tried using the McSPI3 interface with the spidev > driver. Running the spidev_test program shows data coming out of the > interface, but when we connect the SIMO to SOMI pins, the spidev_test > program shows only 0's. Someone tried wiring SOMI to +volts and still > only saw 0 read. I took a quick glance, and the pinmuxing looks sort of OK if you ignore the names ... use the right balls, not XXX: + AE2_3430_MCSPI3_CLK, + AG5_3430_MCSPI3_SIMO, + AH5_3430_MCSPI3_SOMI, + AF4_3430_MCSPI3_CS0, + AG4_3430_MCSPI3_CS1, I suggest you start with a more focussed patch, only setting up McSPI3. For one thing, the MMC2 pinmuxing will interfere with this set of MCSPI3 configurations. Also, start with a less aggressive bit rate than 48 MHz; that may be OK on a well designed board, but breadboards tend to show flakiness at much over 10 MHz. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Brownell wrote: > On Tuesday 17 February 2009, Philip Balister wrote: >> A number of people have tried using the McSPI3 interface with the spidev >> driver. Running the spidev_test program shows data coming out of the >> interface, but when we connect the SIMO to SOMI pins, the spidev_test >> program shows only 0's. Someone tried wiring SOMI to +volts and still >> only saw 0 read. > > I took a quick glance, and the pinmuxing looks sort of OK if > you ignore the names ... use the right balls, not XXX: > > + AE2_3430_MCSPI3_CLK, > + AG5_3430_MCSPI3_SIMO, > + AH5_3430_MCSPI3_SOMI, > + AF4_3430_MCSPI3_CS0, > + AG4_3430_MCSPI3_CS1, > > I suggest you start with a more focussed patch, only setting > up McSPI3. For one thing, the MMC2 pinmuxing will interfere > with this set of MCSPI3 configurations. > > Also, start with a less aggressive bit rate than 48 MHz; that > may be OK on a well designed board, but breadboards tend to > show flakiness at much over 10 MHz. OK, more results: 1) I do not intend for this to go into the kernel, well unless there is an outcry from beagle users :) Steve Sakoman suggested I do the pinmux setup in u-boot and furnished me with a small u-boot patch. Using this patch and removing the pinmux stuff from the kernel patch lead to working spidev_test. The 48 MHz is the max rate, spidev_test defaults to 500 kHz. (but it appears to work at 48 MHz also. Thanks for taking a look at this! Philip PS: I love photos: http://www.flickr.com/photos/32615155@N00/3291304854/
* Philip Balister <philip@balister.org> [090218 16:39]: > David Brownell wrote: >> On Tuesday 17 February 2009, Philip Balister wrote: >>> A number of people have tried using the McSPI3 interface with the >>> spidev driver. Running the spidev_test program shows data coming out >>> of the interface, but when we connect the SIMO to SOMI pins, the >>> spidev_test program shows only 0's. Someone tried wiring SOMI to >>> +volts and still only saw 0 read. >> >> I took a quick glance, and the pinmuxing looks sort of OK if >> you ignore the names ... use the right balls, not XXX: >> >> + AE2_3430_MCSPI3_CLK, >> + AG5_3430_MCSPI3_SIMO, >> + AH5_3430_MCSPI3_SOMI, >> + AF4_3430_MCSPI3_CS0, >> + AG4_3430_MCSPI3_CS1, >> >> I suggest you start with a more focussed patch, only setting >> up McSPI3. For one thing, the MMC2 pinmuxing will interfere >> with this set of MCSPI3 configurations. >> >> Also, start with a less aggressive bit rate than 48 MHz; that >> may be OK on a well designed board, but breadboards tend to >> show flakiness at much over 10 MHz. > > OK, more results: > > 1) I do not intend for this to go into the kernel, well unless there is > an outcry from beagle users :) Sure we should integrate it, people need it! > Steve Sakoman suggested I do the pinmux setup in u-boot and furnished me > with a small u-boot patch. Using this patch and removing the pinmux > stuff from the kernel patch lead to working spidev_test. The pin muxing should be also available in the kernel especially for boards that have multiple options for the pins. > The 48 MHz is the max rate, spidev_test defaults to 500 kHz. (but it > appears to work at 48 MHz also. > > Thanks for taking a look at this! How about add a cmdline option where you override the spi ports in use? > PS: I love photos: http://www.flickr.com/photos/32615155@N00/3291304854/ Hmm, I can't quite see from the photo where you have wired the cat's tail to.. :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Philip, Can you please post here or on the Beagleboard mailing list the u-boot patch? This muxpin is very tricky and I have experienced many problems when set up in the kernel while it seems to work better from u-boot - don't know why, Grégoire On Wed, 2009-02-18 at 19:39 -0500, Philip Balister wrote: > David Brownell wrote: > > On Tuesday 17 February 2009, Philip Balister wrote: > >> A number of people have tried using the McSPI3 interface with the spidev > >> driver. Running the spidev_test program shows data coming out of the > >> interface, but when we connect the SIMO to SOMI pins, the spidev_test > >> program shows only 0's. Someone tried wiring SOMI to +volts and still > >> only saw 0 read. > > > > I took a quick glance, and the pinmuxing looks sort of OK if > > you ignore the names ... use the right balls, not XXX: > > > > + AE2_3430_MCSPI3_CLK, > > + AG5_3430_MCSPI3_SIMO, > > + AH5_3430_MCSPI3_SOMI, > > + AF4_3430_MCSPI3_CS0, > > + AG4_3430_MCSPI3_CS1, > > > > I suggest you start with a more focussed patch, only setting > > up McSPI3. For one thing, the MMC2 pinmuxing will interfere > > with this set of MCSPI3 configurations. > > > > Also, start with a less aggressive bit rate than 48 MHz; that > > may be OK on a well designed board, but breadboards tend to > > show flakiness at much over 10 MHz. > > OK, more results: > > 1) I do not intend for this to go into the kernel, well unless there is > an outcry from beagle users :) > > > Steve Sakoman suggested I do the pinmux setup in u-boot and furnished me > with a small u-boot patch. Using this patch and removing the pinmux > stuff from the kernel patch lead to working spidev_test. > > The 48 MHz is the max rate, spidev_test defaults to 500 kHz. (but it > appears to work at 48 MHz also. > > Thanks for taking a look at this! > > Philip > > PS: I love photos: http://www.flickr.com/photos/32615155@N00/3291304854/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Gregoire Gentil wrote: > Philip, > > Can you please post here or on the Beagleboard mailing list the u-boot > patch? This muxpin is very tricky and I have experienced many problems > when set up in the kernel while it seems to work better from u-boot - > don't know why, I posted it to the Beagle group. Let me know if you are having trouble finding it. If we come up with a better config for the expansion port, we'll clean it up and submit here. My gut feeling is having SPI interfaces on the expansion connector will be more useful then the MMC interface. Philip
Philip, I found the patch. Thanks. SPI3 is working for me too but I think that there are a couple of errors: - first, in the patch you posted on the beagleboard mailing list, you don't setup CS0 and CS1 pins in u-boot. I think that you should do it. - secondly, you have added more mux configuration in the kernel for SPI3 that should not be SPI3 but those new ones are wrong as they are competing with some USB pins. It's the same error as David pointed you for MMC2. Nevertheless, it's still working. Why? Because I have now a strong feeling that mux configuration is not working in the kernel (at least for the beagleboard). Here are a few facts that would confirm this statement: - MUX setup for USB ehci has never worked in the kernel. It's why the beagleaboard rev-C ehci patch has been transfered to u-boot. - the difference between your patch before and after it was working, is really the u-boot configuration. You haven't really changed anything in the kernel (especially in the spi driver) and as mentioned above, you have even introduced some competing muxes that should have created more trouble if the kernel mux config were working correctly. - I had two other areas where I configured the pins in kernel and it was not working. Only when I eventually did it in u-boot, it started to work. I don't know what's wrong with the pin configuration in the kernel, Grégoire On Thu, 2009-02-19 at 09:14 -0500, Philip Balister wrote: > Gregoire Gentil wrote: > > Philip, > > > > Can you please post here or on the Beagleboard mailing list the u-boot > > patch? This muxpin is very tricky and I have experienced many problems > > when set up in the kernel while it seems to work better from u-boot - > > don't know why, > > I posted it to the Beagle group. Let me know if you are having trouble > finding it. > > If we come up with a better config for the expansion port, we'll clean > it up and submit here. My gut feeling is having SPI interfaces on the > expansion connector will be more useful then the MMC interface. > > Philip > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> - MUX setup for USB ehci has never worked in the kernel. It's why the > beagleaboard rev-C ehci patch has been transfered to u-boot. Do you have CONFIG_OMAP_MUX enabled? It's disabled in beagle's defconfig. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Gregoire Gentil wrote: > Philip, > > I found the patch. Thanks. SPI3 is working for me too but I think that > there are a couple of errors: > > - first, in the patch you posted on the beagleboard mailing list, you > don't setup CS0 and CS1 pins in u-boot. I think that you should do it. Yeah. I wanted to get the info out quickly since there are a couple of longish threads on the Beagle list over the problem. > - secondly, you have added more mux configuration in the kernel for SPI3 > that should not be SPI3 but those new ones are wrong as they are > competing with some USB pins. It's the same error as David pointed you > for MMC2. Nevertheless, it's still working. Why? Because I have now a > strong feeling that mux configuration is not working in the kernel (at > least for the beagleboard). Here are a few facts that would confirm this > statement: I thought I #if 0 ... #endif the kernel mux code? I'll double check. I should try it with un patched u-boot and only the specific pins set in the kernel. I'm juggling too many different things atm :( I also changed the PIN MUX config option in the flag per another question. Philip > > - MUX setup for USB ehci has never worked in the kernel. It's why the > beagleaboard rev-C ehci patch has been transfered to u-boot. > > - the difference between your patch before and after it was working, is > really the u-boot configuration. You haven't really changed anything in > the kernel (especially in the spi driver) and as mentioned above, you > have even introduced some competing muxes that should have created more > trouble if the kernel mux config were working correctly. > > - I had two other areas where I configured the pins in kernel and it was > not working. Only when I eventually did it in u-boot, it started to > work. > > I don't know what's wrong with the pin configuration in the kernel, > > Grégoire > > > On Thu, 2009-02-19 at 09:14 -0500, Philip Balister wrote: >> Gregoire Gentil wrote: >>> Philip, >>> >>> Can you please post here or on the Beagleboard mailing list the u-boot >>> patch? This muxpin is very tricky and I have experienced many problems >>> when set up in the kernel while it seems to work better from u-boot - >>> don't know why, >> I posted it to the Beagle group. Let me know if you are having trouble >> finding it. >> >> If we come up with a better config for the expansion port, we'll clean >> it up and submit here. My gut feeling is having SPI interfaces on the >> expansion connector will be more useful then the MMC interface. >> >> Philip >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" 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-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index fe97bab..ed7fee6 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -23,6 +23,7 @@ #include <linux/gpio.h> #include <linux/input.h> #include <linux/gpio_keys.h> +#include <linux/spi/spi.h> #include <linux/mtd/mtd.h> #include <linux/mtd/partitions.h> @@ -311,6 +312,27 @@ static struct platform_device *omap3_beagle_devices[] __initdata = { &keys_gpio, }; +static struct spi_board_info beagle_spi_board_info[] = { + { + .modalias = "spidev", + .max_speed_hz = 48000000, //48 Mbps + .bus_num = 3, + .chip_select = 0, + .mode = SPI_MODE_1, + }, +}; + +static struct spi_board_info beagle_spi_board_info2[] = { + { + .modalias = "spidev", + .max_speed_hz = 48000000, //48 Mbps + .bus_num = 4, + .chip_select = 0, + .mode = SPI_MODE_1, + }, +}; + + static void __init omap3beagle_flash_init(void) { u8 cs = 0; @@ -358,6 +380,63 @@ static void __init omap3_beagle_init(void) omap_board_config_size = ARRAY_SIZE(omap3_beagle_config); omap_serial_init(); + +/* + printk("Debug ================> MMC2 >>> start\n"); + omap_cfg_reg(XXX_3430_MMC2_CLK); + omap_cfg_reg(XXX_3430_MMC2_cmd); + omap_cfg_reg(XXX_3430_MMC2_dat0); + omap_cfg_reg(XXX_3430_MMC2_dat1); + omap_cfg_reg(XXX_3430_MMC2_dat2); + omap_cfg_reg(XXX_3430_MMC2_dat3); + omap_cfg_reg(XXX_3430_MMC2_dat4); + omap_cfg_reg(XXX_3430_MMC2_dat5); + omap_cfg_reg(XXX_3430_MMC2_dat6); + omap_cfg_reg(XXX_3430_MMC2_dat7); + printk("Debug ================> MMC2 >>> end\n"); + printk("Debug ================> UART2 >>> start\n"); + omap_cfg_reg(XXX_3430_UART2_cts); + omap_cfg_reg(XXX_3430_UART2_rts); + omap_cfg_reg(XXX_3430_UART2_tx); + omap_cfg_reg(XXX_3430_UART2_rx); + printk("Debug ================> UART2 >>> end\n"); +*/ + + printk("Debug ================> MCSPI >>> start\n"); + + omap_cfg_reg(XXX_3430_MCSPI3_CLK); + omap_cfg_reg(XXX_3430_MCSPI3_SIMO); + omap_cfg_reg(XXX_3430_MCSPI3_SOMI); + omap_cfg_reg(XXX_3430_MCSPI3_CS0); + omap_cfg_reg(XXX_3430_MCSPI3_CS1); + //avoid other pins/balls with McSPI function + omap_cfg_reg(XXX_3430_gpio_88); + omap_cfg_reg(XXX_3430_gpio_89); + omap_cfg_reg(XXX_3430_gpio_90); + omap_cfg_reg(XXX_3430_gpio_91); + omap_cfg_reg(XXX_3430_gpio_92); + omap_cfg_reg(XXX_3430_gpio_14); + omap_cfg_reg(XXX_3430_gpio_15); + omap_cfg_reg(XXX_3430_gpio_16); + omap_cfg_reg(XXX_3430_gpio_17); + omap_cfg_reg(XXX_3430_gpio_21); + + omap_cfg_reg(XXX_3430_MCSPI4_CLK); + omap_cfg_reg(XXX_3430_MCSPI4_SIMO); + omap_cfg_reg(XXX_3430_MCSPI4_SOMI); + omap_cfg_reg(XXX_3430_MCSPI4_CS0); + //avoid other pins/balls with McSPI function + omap_cfg_reg(XXX_3430_gpio_151); + printk("Debug ================> MCSPI >>> end\n"); + + + printk("Debug ================> register SLAVE DEVICES using [spidev] protocol driver >>> start\n"); + spi_register_board_info(beagle_spi_board_info, ARRAY_SIZE(beagle_spi_board_info)); + spi_register_board_info(beagle_spi_board_info2, ARRAY_SIZE(beagle_spi_board_info2)); + printk("Debug ================> register SLAVE DEVICES using [spidev] protocol driver >>> end\n"); + omap_cfg_reg(XXX_3430_gpio_157); //add by yuchih + + omap_cfg_reg(J25_34XX_GPIO170); gpio_request(170, "DVI_nPD"); /* REVISIT leave DVI powered down until it's needed ... */ diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index 1556688..9b55cf8 100644 --- a/arch/arm/mach-omap2/mux.c +++ b/arch/arm/mach-omap2/mux.c @@ -472,6 +472,87 @@ MUX_CFG_34XX("AF5_34XX_GPIO142", 0x170, MUX_CFG_34XX("AE5_34XX_GPIO143", 0x172, OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT) +/* UART2 */ +MUX_CFG_34XX("XXX_3430_UART2_cts", 0x16c, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_UART2_rts", 0x16e, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_UART2_tx", 0x170, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_UART2_rx", 0x172, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLUP) + +/* MMC2 */ +MUX_CFG_34XX("XXX_3430_MMC2_CLK", 0x158, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_cmd", 0x15a, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_dat0", 0x15c, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_dat1", 0x15e, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_dat2", 0x160, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_dat3", 0x162, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_dat4", 0x164, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_dat5", 0x166, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_dat6", 0x168, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_MMC2_dat7", 0x16a, + OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT) + +/* MCSPI3 */ +MUX_CFG_34XX("XXX_3430_MCSPI3_CLK", 0x158, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_MCSPI3_SIMO", 0x15a, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_MCSPI3_SOMI", 0x15c, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLUP) +MUX_CFG_34XX("XXX_3430_MCSPI3_CS0", 0x162, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_MCSPI3_CS1", 0x160, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) + +MUX_CFG_34XX("XXX_3430_gpio_88", 0x100, //mcspi3_clk + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_gpio_89", 0x102, //mcspi3_simo + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_gpio_90", 0x104, //mcspi3_somi + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_gpio_91", 0x106, //mcspi3_cs0 + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_gpio_92", 0x108, //mcspi3_cs1 + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) + +MUX_CFG_34XX("XXX_3430_gpio_14", 0x5dc, //mcspi3_simo + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_gpio_15", 0x5de, //mcspi3_somi + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_gpio_16", 0x5e0, //mcspi3_cs0 + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_gpio_17", 0x5e2, //mcspi3_clk + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +MUX_CFG_34XX("XXX_3430_gpio_21", 0x5ea, //mcspi3_cs1 + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) +/* MCSPI4 */ +MUX_CFG_34XX("XXX_3430_MCSPI4_CLK", 0x18c, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_MCSPI4_SIMO", 0x190, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_MCSPI4_SOMI", 0x192, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLUP) +MUX_CFG_34XX("XXX_3430_MCSPI4_CS0", 0x196, + OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT) +MUX_CFG_34XX("XXX_3430_gpio_151", 0x182, + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) + +/* GPIO */ +MUX_CFG_34XX("XXX_3430_gpio_157", 0x18e, + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) + }; #define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins) @@ -494,6 +575,7 @@ static void __init_or_module omap2_cfg_debug(const struct pin_config *cfg, u16 r #ifdef CONFIG_OMAP_MUX_DEBUG debug = cfg->debug; + debug = 1; //add by yuchih #endif warn = (orig != reg); if (debug || warn) @@ -540,6 +622,9 @@ static int __init_or_module omap34xx_cfg_reg(const struct pin_config *cfg) reg |= cfg->mux_val; omap2_cfg_debug(cfg, reg); omap_ctrl_writew(reg, cfg->mux_reg); + + omap2_cfg_debug(cfg, reg); //add by yuchih + spin_unlock_irqrestore(&mux_spin_lock, flags); return 0; diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-omap/include/mach/mux.h index 67fddec..3dea82e 100644 --- a/arch/arm/plat-omap/include/mach/mux.h +++ b/arch/arm/plat-omap/include/mach/mux.h @@ -795,7 +795,54 @@ enum omap34xx_index { AF6_34XX_GPIO140_UP, AE6_34XX_GPIO141, AF5_34XX_GPIO142, - AE5_34XX_GPIO143 + AE5_34XX_GPIO143, + + + /* UART2 */ + XXX_3430_UART2_cts, + XXX_3430_UART2_rts, + XXX_3430_UART2_tx, + XXX_3430_UART2_rx, + + /* MMC2 */ + XXX_3430_MMC2_CLK, + XXX_3430_MMC2_cmd, + XXX_3430_MMC2_dat0, + XXX_3430_MMC2_dat1, + XXX_3430_MMC2_dat2, + XXX_3430_MMC2_dat3, + XXX_3430_MMC2_dat4, + XXX_3430_MMC2_dat5, + XXX_3430_MMC2_dat6, + XXX_3430_MMC2_dat7, + + /* MCSPI3 */ + XXX_3430_MCSPI3_CLK, + XXX_3430_MCSPI3_SIMO, + XXX_3430_MCSPI3_SOMI, + XXX_3430_MCSPI3_CS0, + XXX_3430_MCSPI3_CS1, + XXX_3430_gpio_88, + XXX_3430_gpio_89, + XXX_3430_gpio_90, + XXX_3430_gpio_91, + XXX_3430_gpio_92, + XXX_3430_gpio_14, + XXX_3430_gpio_15, + XXX_3430_gpio_16, + XXX_3430_gpio_17, + XXX_3430_gpio_21, + + /* MCSPI4 */ + XXX_3430_MCSPI4_CLK, + XXX_3430_MCSPI4_SIMO, + XXX_3430_MCSPI4_SOMI, + XXX_3430_MCSPI4_CS0, + XXX_3430_gpio_151, //mcspi_clk + + /* GPIO*/ + XXX_3430_gpio_157 + }; struct omap_mux_cfg {