From: Gilson, M. W. <Mar...@jh...> - 2010-07-16 15:45:03
|
/* * board-overo.c (Gumstix Overo) * * Initial code: Steve Sakoman <st...@sa...> * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA * */ #include <linux/clk.h> #include <linux/delay.h> #include <linux/err.h> #include <linux/init.h> #include <linux/io.h> #include <linux/kernel.h> #include <linux/platform_device.h> #include <linux/i2c/twl.h> #include <linux/regulator/machine.h> #include <linux/spi/spi.h> //M.W.G.// #include <linux/spi/mmc_spi.h> //M.W.G.// #include <linux/mtd/mtd.h> #include <linux/mtd/nand.h> #include <linux/mtd/partitions.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> #include <asm/mach/flash.h> #include <asm/mach/map.h> #include <plat/board.h> #include <plat/common.h> #include <plat/display.h> #include <mach/gpio.h> #include <plat/gpmc.h> #include <mach/hardware.h> #include <plat/nand.h> #include <plat/mcspi.h> #include <plat/mux.h> #include <plat/usb.h> #include "mux.h" #include "sdram-micron-mt46h32m32lf-6.h" #include "hsmmc.h" #define OVERO_GPIO_BT_XGATE 15 #define OVERO_GPIO_W2W_NRESET 16 #define OVERO_GPIO_PENDOWN 114 #define OVERO_GPIO_BT_NRESET 164 #define OVERO_GPIO_USBH_CPEN 168 #define OVERO_GPIO_USBH_NRESET 183 #define NAND_BLOCK_SIZE SZ_128K #define GPMC_CS0_BASE 0x60 #define GPMC_CS_SIZE 0x30 #define OVERO_SMSC911X_CS 5 #define OVERO_SMSC911X_GPIO 176 #define OVERO_SMSC911X2_CS 4 #define OVERO_SMSC911X2_GPIO 65 //M.W.G.// #define S1_MMC_SPI_CD_PIN 147 #define S1_MMC_SPI_WP_PIN 146 int s1_mmc_spi_card_detect(struct device *dev) { return !gpio_get_value(S1_MMC_SPI_CD_PIN); } int s1_mmc_spi_write_protect(struct device *dev) { return 1; //active low //return gpio_get_value(S1_MMC_SPI_WP_PIN); } int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void *),void *mmc) { int ret; ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), cd, IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, "mmc_spi-detect", mmc); if (ret) { printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d for detect pin\n", gpio_to_irq(S1_MMC_SPI_CD_PIN)); } return 0; } void s1_mmc_spi_exit(struct device *dev, void *data) { free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); } static struct mmc_spi_platform_data mmc_spi_data = { .init = s1_mmc_spi_init, .exit = s1_mmc_spi_exit, .get_ro = s1_mmc_spi_write_protect, .get_cd = s1_mmc_spi_card_detect, }; //M.W.G.// #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE) #include <linux/smsc911x.h> static struct resource overo_smsc911x_resources[] = { { .name = "smsc911x-memory", .flags = IORESOURCE_MEM, }, { .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL, }, }; static struct resource overo_smsc911x2_resources[] = { { .name = "smsc911x2-memory", .flags = IORESOURCE_MEM, }, { .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL, }, }; static struct smsc911x_platform_config overo_smsc911x_config = { .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW, .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN, .flags = SMSC911X_USE_32BIT , .phy_interface = PHY_INTERFACE_MODE_MII, }; static struct platform_device overo_smsc911x_device = { .name = "smsc911x", .id = 0, .num_resources = ARRAY_SIZE(overo_smsc911x_resources), .resource = overo_smsc911x_resources, .dev = { .platform_data = &overo_smsc911x_config, }, }; static struct platform_device overo_smsc911x2_device = { .name = "smsc911x", .id = 1, .num_resources = ARRAY_SIZE(overo_smsc911x2_resources), .resource = overo_smsc911x2_resources, .dev = { .platform_data = &overo_smsc911x_config, }, }; static struct platform_device *smsc911x_devices[] = { &overo_smsc911x_device, &overo_smsc911x2_device, }; static inline void __init overo_init_smsc911x(void) { unsigned long cs_mem_base, cs_mem_base2; /* set up first smsc911x chip */ if (gpmc_cs_request(OVERO_SMSC911X_CS, SZ_16M, &cs_mem_base) < 0) { printk(KERN_ERR "Failed request for GPMC mem for smsc911x\n"); return; } overo_smsc911x_resources[0].start = cs_mem_base + 0x0; overo_smsc911x_resources[0].end = cs_mem_base + 0xff; if ((gpio_request(OVERO_SMSC911X_GPIO, "SMSC911X IRQ") == 0) && (gpio_direction_input(OVERO_SMSC911X_GPIO) == 0)) { gpio_export(OVERO_SMSC911X_GPIO, 0); } else { printk(KERN_ERR "could not obtain gpio for SMSC911X IRQ\n"); return; } overo_smsc911x_resources[1].start = OMAP_GPIO_IRQ(OVERO_SMSC911X_GPIO); overo_smsc911x_resources[1].end = 0; /* set up second smsc911x chip */ if (gpmc_cs_request(OVERO_SMSC911X2_CS, SZ_16M, &cs_mem_base2) < 0) { printk(KERN_ERR "Failed request for GPMC mem for smsc911x2\n"); return; } overo_smsc911x2_resources[0].start = cs_mem_base2 + 0x0; overo_smsc911x2_resources[0].end = cs_mem_base2 + 0xff; if ((gpio_request(OVERO_SMSC911X2_GPIO, "SMSC911X2 IRQ") == 0) && (gpio_direction_input(OVERO_SMSC911X2_GPIO) == 0)) { gpio_export(OVERO_SMSC911X2_GPIO, 0); } else { printk(KERN_ERR "could not obtain gpio for SMSC911X2 IRQ\n"); return; } overo_smsc911x2_resources[1].start = OMAP_GPIO_IRQ(OVERO_SMSC911X2_GPIO); overo_smsc911x2_resources[1].end = 0; platform_add_devices(smsc911x_devices, ARRAY_SIZE(smsc911x_devices)); } #else static inline void __init overo_init_smsc911x(void) { return; } #endif /* DSS */ static int lcd_enabled; static int dvi_enabled; #define OVERO_GPIO_LCD_EN 144 #define OVERO_GPIO_LCD_BL 145 static void __init overo_display_init(void) { if ((gpio_request(OVERO_GPIO_LCD_EN, "OVERO_GPIO_LCD_EN") == 0) && (gpio_direction_output(OVERO_GPIO_LCD_EN, 1) == 0)) gpio_export(OVERO_GPIO_LCD_EN, 0); else printk(KERN_ERR "could not obtain gpio for " "OVERO_GPIO_LCD_EN\n"); if ((gpio_request(OVERO_GPIO_LCD_BL, "OVERO_GPIO_LCD_BL") == 0) && (gpio_direction_output(OVERO_GPIO_LCD_BL, 1) == 0)) gpio_export(OVERO_GPIO_LCD_BL, 0); else printk(KERN_ERR "could not obtain gpio for " "OVERO_GPIO_LCD_BL\n"); } static int overo_panel_enable_dvi(struct omap_dss_device *dssdev) { if (lcd_enabled) { printk(KERN_ERR "cannot enable DVI, LCD is enabled\n"); return -EINVAL; } dvi_enabled = 1; return 0; } static void overo_panel_disable_dvi(struct omap_dss_device *dssdev) { dvi_enabled = 0; } static struct omap_dss_device overo_dvi_device = { .type = OMAP_DISPLAY_TYPE_DPI, .name = "dvi", .driver_name = "generic_panel", .phy.dpi.data_lines = 24, .platform_enable = overo_panel_enable_dvi, .platform_disable = overo_panel_disable_dvi, }; static int overo_panel_enable_tv(struct omap_dss_device *dssdev) { #define ENABLE_VDAC_DEDICATED 0x03 #define ENABLE_VDAC_DEV_GRP 0x20 twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, ENABLE_VDAC_DEDICATED, TWL4030_VDAC_DEDICATED); twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, ENABLE_VDAC_DEV_GRP, TWL4030_VDAC_DEV_GRP); return 0; } static void overo_panel_disable_tv(struct omap_dss_device *dssdev) { twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x00, TWL4030_VDAC_DEDICATED); twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x00, TWL4030_VDAC_DEV_GRP); } static struct omap_dss_device overo_tv_device = { .name = "tv", .driver_name = "venc", .type = OMAP_DISPLAY_TYPE_VENC, .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO, .platform_enable = overo_panel_enable_tv, .platform_disable = overo_panel_disable_tv, }; static int overo_panel_enable_lcd(struct omap_dss_device *dssdev) { if (dvi_enabled) { printk(KERN_ERR "cannot enable LCD, DVI is enabled\n"); return -EINVAL; } gpio_set_value(OVERO_GPIO_LCD_EN, 1); gpio_set_value(OVERO_GPIO_LCD_BL, 1); lcd_enabled = 1; return 0; } static void overo_panel_disable_lcd(struct omap_dss_device *dssdev) { gpio_set_value(OVERO_GPIO_LCD_EN, 0); gpio_set_value(OVERO_GPIO_LCD_BL, 0); lcd_enabled = 0; } static struct omap_dss_device *overo_dss_devices[] = { &overo_dvi_device, &overo_tv_device, }; static struct omap_dss_board_info overo_dss_data = { .num_devices = ARRAY_SIZE(overo_dss_devices), .devices = overo_dss_devices, .default_device = &overo_dvi_device, }; static struct platform_device overo_dss_device = { .name = "omapdss", .id = -1, .dev = { .platform_data = &overo_dss_data, }, }; static struct regulator_consumer_supply overo_vdda_dac_supply = { .supply = "vdda_dac", .dev = &overo_dss_device.dev, }; static struct regulator_consumer_supply overo_vdds_dsi_supply = { .supply = "vdds_dsi", .dev = &overo_dss_device.dev, }; struct flash_partitions { struct mtd_partition *parts; int nr_parts; }; static struct mtd_partition overo_nand_partitions[] = { { .name = "xloader", .offset = 0, /* Offset = 0x00000 */ .size = 4 * NAND_BLOCK_SIZE, .mask_flags = MTD_WRITEABLE }, { .name = "uboot", .offset = MTDPART_OFS_APPEND, /* Offset = 0x80000 */ .size = 14 * NAND_BLOCK_SIZE, }, { .name = "uboot environment", .offset = MTDPART_OFS_APPEND, /* Offset = 0x240000 */ .size = 2 * NAND_BLOCK_SIZE, }, { .name = "linux", .offset = MTDPART_OFS_APPEND, /* Offset = 0x280000 */ .size = 32 * NAND_BLOCK_SIZE, }, { .name = "rootfs", .offset = MTDPART_OFS_APPEND, /* Offset = 0x680000 */ .size = MTDPART_SIZ_FULL, }, }; static struct flash_partitions overo_flash_partitions[] = { { /* NOR flash */ }, { /* OneNAND */ }, { /* NAND */ .parts = overo_nand_partitions, .nr_parts = ARRAY_SIZE(overo_nand_partitions), }, }; #if defined(CONFIG_MTD_NAND_OMAP2) || \ defined(CONFIG_MTD_NAND_OMAP2_MODULE) /* Note that all values in this struct are in nanoseconds */ static struct gpmc_timings nand_timings = { .sync_clk = 0, .cs_on = 0, .cs_rd_off = 36, .cs_wr_off = 36, .adv_on = 6, .adv_rd_off = 24, .adv_wr_off = 36, .we_off = 30, .oe_off = 48, .access = 54, .rd_cycle = 72, .wr_cycle = 72, .wr_access = 30, .wr_data_mux_bus= 0, }; static struct omap_nand_platform_data overo_nand_data = { .nand_setup = NULL, .gpmc_t = &nand_timings, .dma_channel = -1, /* disable DMA in OMAP NAND driver */ .dev_ready = NULL, .devsize = 1, /* '0' for 8-bit, '1' for 16-bit device */ }; static void __init board_nand_init(struct flash_partitions overo_nand_parts, u8 cs) { overo_nand_data.cs = cs; overo_nand_data.parts = overo_nand_parts.parts; overo_nand_data.nr_parts = overo_nand_parts.nr_parts; overo_nand_data.gpmc_baseaddr = (void *) (OMAP34XX_GPMC_VIRT); overo_nand_data.gpmc_cs_baseaddr = (void *)(OMAP34XX_GPMC_VIRT + GPMC_CS0_BASE + cs * GPMC_CS_SIZE); gpmc_nand_init(&overo_nand_data); } #else static void __init board_nand_init(struct flash_partitions overo_nand_parts, u8 cs) { } #endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */ static void __init overo_flash_init(struct flash_partitions partition_info[]){ u8 cs = 0; u8 nandcs = GPMC_CS_NUM + 1; /* find out the chip-select on which NAND exists */ while (cs < GPMC_CS_NUM) { u32 ret = 0; ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1); if ((ret & 0xC00) == 0x800) { printk(KERN_INFO "Found NAND on CS%d\n", cs); if (nandcs > GPMC_CS_NUM) nandcs = cs; } cs++; } if (nandcs > GPMC_CS_NUM) { printk(KERN_INFO "NAND: Unable to find configuration " "in GPMC\n "); return; } if (nandcs < GPMC_CS_NUM) board_nand_init(partition_info[2], nandcs); } static struct omap2_hsmmc_info mmc[] = { { .mmc = 1, .wires = 4, .gpio_cd = -EINVAL, .gpio_wp = -EINVAL, }, { .mmc = 2, .wires = 4, .gpio_cd = -EINVAL, .gpio_wp = -EINVAL, .transceiver = true, .ocr_mask = 0x00100000, /* 3.3V */ }, {} /* Terminator */ }; static struct regulator_consumer_supply overo_vmmc1_supply = { .supply = "vmmc", }; static int overo_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio) { omap2_hsmmc_init(mmc); overo_vmmc1_supply.dev = mmc[0].dev; return 0; } static struct twl4030_gpio_platform_data overo_gpio_data = { .gpio_base = OMAP_MAX_GPIO_LINES, .irq_base = TWL4030_GPIO_IRQ_BASE, .irq_end = TWL4030_GPIO_IRQ_END, .setup = overo_twl_gpio_setup, }; static struct twl4030_usb_data overo_usb_data = { .usb_mode = T2_USB_MODE_ULPI, }; static struct regulator_init_data overo_vmmc1 = { .constraints = { .min_uV = 1850000, .max_uV = 3150000, .valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY, .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE | REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS, }, .num_consumer_supplies = 1, .consumer_supplies = &overo_vmmc1_supply, }; /* VDAC for DSS driving S-Video (8 mA unloaded, max 65 mA) */ static struct regulator_init_data overo_vdac = { .constraints = { .min_uV = 1800000, .max_uV = 1800000, .valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY, .valid_ops_mask = REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS, }, .num_consumer_supplies = 1, .consumer_supplies = &overo_vdda_dac_supply, }; /* VPLL2 for digital video outputs */ static struct regulator_init_data overo_vpll2 = { .constraints = { .name = "VDVI", .min_uV = 1800000, .max_uV = 1800000, .valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY, .valid_ops_mask = REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS, }, .num_consumer_supplies = 1, .consumer_supplies = &overo_vdds_dsi_supply, }; /* mmc2 (WLAN) and Bluetooth don't use twl4030 regulators */ static struct twl4030_codec_audio_data overo_audio_data = { .audio_mclk = 26000000, }; static struct twl4030_codec_data overo_codec_data = { .audio_mclk = 26000000, .audio = &overo_audio_data, }; static struct twl4030_madc_platform_data overo_madc_data = { .irq_line = 1, }; static struct twl4030_platform_data overo_twldata = { .irq_base = TWL4030_IRQ_BASE, .irq_end = TWL4030_IRQ_END, .gpio = &overo_gpio_data, .madc = &overo_madc_data, .usb = &overo_usb_data, .codec = &overo_codec_data, .vmmc1 = &overo_vmmc1, .vdac = &overo_vdac, .vpll2 = &overo_vpll2, }; static struct i2c_board_info __initdata overo_i2c_boardinfo[] = { { I2C_BOARD_INFO("tps65950", 0x48), .flags = I2C_CLIENT_WAKE, .irq = INT_34XX_SYS_NIRQ, .platform_data = &overo_twldata, }, }; static int __init overo_i2c_init(void) { omap_register_i2c_bus(1, 2600, overo_i2c_boardinfo, ARRAY_SIZE(overo_i2c_boardinfo)); /* i2c2 pins are used for gpio */ omap_register_i2c_bus(3, 400, NULL, 0); return 0; }; //M.W.G.// static struct spi_board_info overo_spi_board_info[] __initdata = { { .modalias = "mmc_spi", .max_speed_hz = 1000000, //8000000, //12000000, .bus_num = 1, .chip_select = 0, .platform_data = &mmc_spi_data, .mode = SPI_MODE_3, }, }; //M.W.G.// static int __init overo_spi_init(void) { spi_register_board_info(overo_spi_board_info, ARRAY_SIZE(overo_spi_board_info)); return 0; } static void __init overo_init_irq(void) { omap2_init_common_hw(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params); omap_init_irq(); omap_gpio_init(); } static struct platform_device *overo_devices[] __initdata = { &overo_dss_device, }; static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = { .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN, .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY, .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN, .phy_reset = true, .reset_gpio_port[0] = -EINVAL, .reset_gpio_port[1] = OVERO_GPIO_USBH_NRESET, .reset_gpio_port[2] = -EINVAL }; #ifdef CONFIG_OMAP_MUX static struct omap_board_mux board_mux[] __initdata = { { .reg_offset = OMAP_MUX_TERMINATOR }, }; #else #define board_mux NULL #endif static struct omap_musb_board_data musb_board_data = { .interface_type = MUSB_INTERFACE_ULPI, #if defined(CONFIG_USB_MUSB_OTG) .mode = MUSB_OTG, #elif defined(CONFIG_USB_GADGET_MUSB_HDRC) .mode = MUSB_PERIPHERAL, #else .mode = MUSB_HOST, #endif .power = 100, }; static void __init overo_init(void) { omap3_mux_init(board_mux, OMAP_PACKAGE_CBB); overo_i2c_init(); platform_add_devices(overo_devices, ARRAY_SIZE(overo_devices)); omap_serial_init(); overo_flash_init(overo_flash_partitions); usb_musb_init(&musb_board_data); usb_ehci_init(&ehci_pdata); overo_spi_init(); overo_init_smsc911x(); overo_display_init(); /* Ensure SDRC pins are mux'd for self-refresh */ omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT); omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT); if ((gpio_request(OVERO_GPIO_W2W_NRESET, "OVERO_GPIO_W2W_NRESET") == 0) && (gpio_direction_output(OVERO_GPIO_W2W_NRESET, 1) == 0)) { gpio_export(OVERO_GPIO_W2W_NRESET, 0); gpio_set_value(OVERO_GPIO_W2W_NRESET, 0); udelay(10); gpio_set_value(OVERO_GPIO_W2W_NRESET, 1); } else { printk(KERN_ERR "could not obtain gpio for " "OVERO_GPIO_W2W_NRESET\n"); } if ((gpio_request(OVERO_GPIO_BT_XGATE, "OVERO_GPIO_BT_XGATE") == 0) && (gpio_direction_output(OVERO_GPIO_BT_XGATE, 0) == 0)) gpio_export(OVERO_GPIO_BT_XGATE, 0); else printk(KERN_ERR "could not obtain gpio for OVERO_GPIO_BT_XGATE\n"); if ((gpio_request(OVERO_GPIO_BT_NRESET, "OVERO_GPIO_BT_NRESET") == 0) && (gpio_direction_output(OVERO_GPIO_BT_NRESET, 1) == 0)) { gpio_export(OVERO_GPIO_BT_NRESET, 0); gpio_set_value(OVERO_GPIO_BT_NRESET, 0); mdelay(6); gpio_set_value(OVERO_GPIO_BT_NRESET, 1); } else { printk(KERN_ERR "could not obtain gpio for " "OVERO_GPIO_BT_NRESET\n"); } if ((gpio_request(OVERO_GPIO_USBH_CPEN, "OVERO_GPIO_USBH_CPEN") == 0) && (gpio_direction_output(OVERO_GPIO_USBH_CPEN, 1) == 0)) gpio_export(OVERO_GPIO_USBH_CPEN, 0); else printk(KERN_ERR "could not obtain gpio for " "OVERO_GPIO_USBH_CPEN\n"); } static void __init overo_map_io(void) { omap2_set_globals_343x(); omap34xx_map_common_io(); } MACHINE_START(OVERO, "Gumstix Overo") .phys_io = 0x48000000, .io_pg_offst = ((0xfa000000) >> 18) & 0xfffc, .boot_params = 0x80000100, .map_io = overo_map_io, .init_irq = overo_init_irq, .init_machine = overo_init, .timer = &omap_timer, MACHINE_END |
From: plasmaphase <mar...@jh...> - 2010-05-05 13:49:09
|
Has anyone attempted using SPI for communications to an SD Card (not the onboard SD card)? If so, would you please provide any information you would consider helpful in getting this working. I'm very new to the gumstix. I'm simply looking to get SPI Mode communication to an SD Card (I have SD Card spi driver, and have solved the 1.8V to 3.3V issue). Thanks. -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p28460935.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bernhard Wörndl-A. <bw...@xd...> - 2010-05-05 13:59:26
|
Hey =) Using SD over SPI is generally not that of a problem, you just need to enable it in the Linux Board Setup. (I did that some time ago, not for the overo/omap, but for a AP7000 and it worked pretty well). But the Overo breaks out an additional MMC interface, that you might be able to use, in order to get higher speed (4bit SD mode instead of 1 bit MMC-SPI mode). I have that solution ready, but haven't changed the kernel yet, to work with it. I'll report to you if i get everything running (hopefully in 2 two 3 days) Regards *Bernhard Wörndl-Aichriedler* Am 05.05.2010 15:30, schrieb plasmaphase: > Has anyone attempted using SPI for communications to an SD Card (not the > onboard SD card)? If so, would you please provide any information you would > consider helpful in getting this working. I'm very new to the gumstix. I'm > simply looking to get SPI Mode communication to an SD Card (I have SD Card > spi driver, and have solved the 1.8V to 3.3V issue). Thanks. > |
From: Bernhard Wörndl-A. <bw...@xd...> - 2010-05-12 18:11:31
|
Currently not really, Are you sure the hardware and the level conversion works? Do you get anything on CS, DI, DO and SCK? Can you send me your board setup? Regards *Bernhard Wörndl-Aichriedler* Am 12.05.2010 20:07, schrieb plasmaphase: > overo mmc_spi: probe of spi1.0 failed with error -16 > > Any ideas? > > > > > Bernhard Wörndl-Aichriedler wrote: > >> Hey =) >> >> This should do the trick: >> >> >> #include<linux/spi/spi.h> >> #include<linux/spi/mmc_spi.h> >> >> >> int s1_mmc_spi_card_detect(struct device *dev) >> { >> return !gpio_get_value(S1_MMC_SPI_CD_PIN); >> } >> >> int s1_mmc_spi_write_protect(struct device *dev) >> { >> return gpio_get_value(S1_MMC_SPI_WP_PIN); >> } >> >> int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void >> *),void *mmc) >> { >> int ret; >> ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), >> cd, >> IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, >> "mmc_spi-detect", mmc); >> if (ret) { >> printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d for >> detect pin\n", >> gpio_to_irq(S1_MMC_SPI_CD_PIN)); >> } >> return 0; >> } >> >> void s1_mmc_spi_exit(struct device *dev, void *data) >> { >> free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); >> } >> >> >> static struct mmc_spi_platform_data mmc_spi_data = { >> .init = s1_mmc_spi_init, >> .exit = s1_mmc_spi_exit, >> .get_ro = s1_mmc_spi_write_protect, >> .get_cd = s1_mmc_spi_card_detect, >> }; >> >> >> static struct spi_board_info spi1_board_info[] __initdata = { >> { >> .modalias = "mmc_spi", >> .max_speed_hz = 12000000, >> .chip_select = 0, >> .platform_data =&mmc_spi_data, >> .mode = SPI_MODE_3, >> }, >> }; >> >> ... >> >> at32_add_device_spi(1, spi1_board_info, ARRAY_SIZE(spi1_board_info)); >> >> from the kernel side, at least after some modification to adopt to the >> omap3. >> >> And the hardware setup is really easy: >> >> >> >> at least for the AP7000, that run on 3.3V >> >> >> Regards >> >> *Bernhard Wörndl-Aichriedler* >> >> Am 05.05.2010 19:56, schrieb plasmaphase: >> >>> Could you expand upon the SPI solution? How do you enable it in the >>> Linux >>> Board Setup? What is it that is required to get this working (links >>> would >>> be adequate/helpful as well). Thanks! >>> >>> >>> Bernhard Wörndl-Aichriedler wrote: >>> >>> >>>> Hey =) >>>> >>>> Using SD over SPI is generally not that of a problem, you just need to >>>> enable it in the Linux Board Setup. >>>> (I did that some time ago, not for the overo/omap, but for a AP7000 and >>>> it worked pretty well). >>>> >>>> But the Overo breaks out an additional MMC interface, that you might be >>>> able to use, in order to get higher speed (4bit SD mode instead of 1 bit >>>> MMC-SPI mode). >>>> I have that solution ready, but haven't changed the kernel yet, to work >>>> with it. I'll report to you if i get everything running (hopefully in 2 >>>> two 3 days) >>>> >>>> >>>> Regards >>>> >>>> *Bernhard Wörndl-Aichriedler* >>>> >>>> Am 05.05.2010 15:30, schrieb plasmaphase: >>>> >>>> >>>>> Has anyone attempted using SPI for communications to an SD Card (not >>>>> the >>>>> onboard SD card)? If so, would you please provide any information you >>>>> would >>>>> consider helpful in getting this working. I'm very new to the gumstix. >>>>> I'm >>>>> simply looking to get SPI Mode communication to an SD Card (I have SD >>>>> Card >>>>> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>>> >>>> >>> >>> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> > |
From: plasmaphase <mar...@jh...> - 2010-05-12 18:22:48
|
I forgot to do the level translation from 1.8V to 3.3V...so that's one problem. I did not see any toggling of SCK, which I would expect to see (even if @ 1.8V). I am using a microSD card...which does not have a WP pin...can I just pull this high? I also am not certain where to place the WP and CD pins on the header, as: #define S1_MMC_SPI_CD_PIN 144 #define S1_MMC_SPI_WP_PIN 145 We will only be using one card, and so I don't think these are necessary except to fake out for the driver...is CD active high or low? Thanks for your quick and helpful responses! Bernhard Wörndl-Aichriedler wrote: > > Currently not really, > > Are you sure the hardware and the level conversion works? > Do you get anything on CS, DI, DO and SCK? > > Can you send me your board setup? > > > Regards > > *Bernhard Wörndl-Aichriedler* > > > Am 12.05.2010 20:07, schrieb plasmaphase: >> overo mmc_spi: probe of spi1.0 failed with error -16 >> >> Any ideas? >> >> >> >> >> Bernhard Wörndl-Aichriedler wrote: >> >>> Hey =) >>> >>> This should do the trick: >>> >>> >>> #include<linux/spi/spi.h> >>> #include<linux/spi/mmc_spi.h> >>> >>> >>> int s1_mmc_spi_card_detect(struct device *dev) >>> { >>> return !gpio_get_value(S1_MMC_SPI_CD_PIN); >>> } >>> >>> int s1_mmc_spi_write_protect(struct device *dev) >>> { >>> return gpio_get_value(S1_MMC_SPI_WP_PIN); >>> } >>> >>> int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void >>> *),void *mmc) >>> { >>> int ret; >>> ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), >>> cd, >>> IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, >>> "mmc_spi-detect", mmc); >>> if (ret) { >>> printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d for >>> detect pin\n", >>> gpio_to_irq(S1_MMC_SPI_CD_PIN)); >>> } >>> return 0; >>> } >>> >>> void s1_mmc_spi_exit(struct device *dev, void *data) >>> { >>> free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); >>> } >>> >>> >>> static struct mmc_spi_platform_data mmc_spi_data = { >>> .init = s1_mmc_spi_init, >>> .exit = s1_mmc_spi_exit, >>> .get_ro = s1_mmc_spi_write_protect, >>> .get_cd = s1_mmc_spi_card_detect, >>> }; >>> >>> >>> static struct spi_board_info spi1_board_info[] __initdata = { >>> { >>> .modalias = "mmc_spi", >>> .max_speed_hz = 12000000, >>> .chip_select = 0, >>> .platform_data =&mmc_spi_data, >>> .mode = SPI_MODE_3, >>> }, >>> }; >>> >>> ... >>> >>> at32_add_device_spi(1, spi1_board_info, >>> ARRAY_SIZE(spi1_board_info)); >>> >>> from the kernel side, at least after some modification to adopt to the >>> omap3. >>> >>> And the hardware setup is really easy: >>> >>> >>> >>> at least for the AP7000, that run on 3.3V >>> >>> >>> Regards >>> >>> *Bernhard Wörndl-Aichriedler* >>> >>> Am 05.05.2010 19:56, schrieb plasmaphase: >>> >>>> Could you expand upon the SPI solution? How do you enable it in the >>>> Linux >>>> Board Setup? What is it that is required to get this working (links >>>> would >>>> be adequate/helpful as well). Thanks! >>>> >>>> >>>> Bernhard Wörndl-Aichriedler wrote: >>>> >>>> >>>>> Hey =) >>>>> >>>>> Using SD over SPI is generally not that of a problem, you just need to >>>>> enable it in the Linux Board Setup. >>>>> (I did that some time ago, not for the overo/omap, but for a AP7000 >>>>> and >>>>> it worked pretty well). >>>>> >>>>> But the Overo breaks out an additional MMC interface, that you might >>>>> be >>>>> able to use, in order to get higher speed (4bit SD mode instead of 1 >>>>> bit >>>>> MMC-SPI mode). >>>>> I have that solution ready, but haven't changed the kernel yet, to >>>>> work >>>>> with it. I'll report to you if i get everything running (hopefully in >>>>> 2 >>>>> two 3 days) >>>>> >>>>> >>>>> Regards >>>>> >>>>> *Bernhard Wörndl-Aichriedler* >>>>> >>>>> Am 05.05.2010 15:30, schrieb plasmaphase: >>>>> >>>>> >>>>>> Has anyone attempted using SPI for communications to an SD Card (not >>>>>> the >>>>>> onboard SD card)? If so, would you please provide any information >>>>>> you >>>>>> would >>>>>> consider helpful in getting this working. I'm very new to the >>>>>> gumstix. >>>>>> I'm >>>>>> simply looking to get SPI Mode communication to an SD Card (I have SD >>>>>> Card >>>>>> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> > > ------------------------------------------------------------------------------ > > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p28539444.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: plasmaphase <mar...@jh...> - 2010-05-12 19:48:30
|
New error: mmc_spi spi1.0: can't share SPI bus mmc_spi: probe of spi1.0 failed with error -16 plasmaphase wrote: > > I forgot to do the level translation from 1.8V to 3.3V...so that's one > problem. I did not see any toggling of SCK, which I would expect to see > (even if @ 1.8V). I am using a microSD card...which does not have a WP > pin...can I just pull this high? I also am not certain where to place the > WP and CD pins on the header, as: > > #define S1_MMC_SPI_CD_PIN 144 > #define S1_MMC_SPI_WP_PIN 145 > > We will only be using one card, and so I don't think these are necessary > except to fake out for the driver...is CD active high or low? > > Thanks for your quick and helpful responses! > > > > > Bernhard Wörndl-Aichriedler wrote: >> >> Currently not really, >> >> Are you sure the hardware and the level conversion works? >> Do you get anything on CS, DI, DO and SCK? >> >> Can you send me your board setup? >> >> >> Regards >> >> *Bernhard Wörndl-Aichriedler* >> >> >> Am 12.05.2010 20:07, schrieb plasmaphase: >>> overo mmc_spi: probe of spi1.0 failed with error -16 >>> >>> Any ideas? >>> >>> >>> >>> >>> Bernhard Wörndl-Aichriedler wrote: >>> >>>> Hey =) >>>> >>>> This should do the trick: >>>> >>>> >>>> #include<linux/spi/spi.h> >>>> #include<linux/spi/mmc_spi.h> >>>> >>>> >>>> int s1_mmc_spi_card_detect(struct device *dev) >>>> { >>>> return !gpio_get_value(S1_MMC_SPI_CD_PIN); >>>> } >>>> >>>> int s1_mmc_spi_write_protect(struct device *dev) >>>> { >>>> return gpio_get_value(S1_MMC_SPI_WP_PIN); >>>> } >>>> >>>> int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void >>>> *),void *mmc) >>>> { >>>> int ret; >>>> ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), >>>> cd, >>>> IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, >>>> "mmc_spi-detect", mmc); >>>> if (ret) { >>>> printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d >>>> for >>>> detect pin\n", >>>> gpio_to_irq(S1_MMC_SPI_CD_PIN)); >>>> } >>>> return 0; >>>> } >>>> >>>> void s1_mmc_spi_exit(struct device *dev, void *data) >>>> { >>>> free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); >>>> } >>>> >>>> >>>> static struct mmc_spi_platform_data mmc_spi_data = { >>>> .init = s1_mmc_spi_init, >>>> .exit = s1_mmc_spi_exit, >>>> .get_ro = s1_mmc_spi_write_protect, >>>> .get_cd = s1_mmc_spi_card_detect, >>>> }; >>>> >>>> >>>> static struct spi_board_info spi1_board_info[] __initdata = { >>>> { >>>> .modalias = "mmc_spi", >>>> .max_speed_hz = 12000000, >>>> .chip_select = 0, >>>> .platform_data =&mmc_spi_data, >>>> .mode = SPI_MODE_3, >>>> }, >>>> }; >>>> >>>> ... >>>> >>>> at32_add_device_spi(1, spi1_board_info, >>>> ARRAY_SIZE(spi1_board_info)); >>>> >>>> from the kernel side, at least after some modification to adopt to the >>>> omap3. >>>> >>>> And the hardware setup is really easy: >>>> >>>> >>>> >>>> at least for the AP7000, that run on 3.3V >>>> >>>> >>>> Regards >>>> >>>> *Bernhard Wörndl-Aichriedler* >>>> >>>> Am 05.05.2010 19:56, schrieb plasmaphase: >>>> >>>>> Could you expand upon the SPI solution? How do you enable it in the >>>>> Linux >>>>> Board Setup? What is it that is required to get this working (links >>>>> would >>>>> be adequate/helpful as well). Thanks! >>>>> >>>>> >>>>> Bernhard Wörndl-Aichriedler wrote: >>>>> >>>>> >>>>>> Hey =) >>>>>> >>>>>> Using SD over SPI is generally not that of a problem, you just need >>>>>> to >>>>>> enable it in the Linux Board Setup. >>>>>> (I did that some time ago, not for the overo/omap, but for a AP7000 >>>>>> and >>>>>> it worked pretty well). >>>>>> >>>>>> But the Overo breaks out an additional MMC interface, that you might >>>>>> be >>>>>> able to use, in order to get higher speed (4bit SD mode instead of 1 >>>>>> bit >>>>>> MMC-SPI mode). >>>>>> I have that solution ready, but haven't changed the kernel yet, to >>>>>> work >>>>>> with it. I'll report to you if i get everything running (hopefully in >>>>>> 2 >>>>>> two 3 days) >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> *Bernhard Wörndl-Aichriedler* >>>>>> >>>>>> Am 05.05.2010 15:30, schrieb plasmaphase: >>>>>> >>>>>> >>>>>>> Has anyone attempted using SPI for communications to an SD Card (not >>>>>>> the >>>>>>> onboard SD card)? If so, would you please provide any information >>>>>>> you >>>>>>> would >>>>>>> consider helpful in getting this working. I'm very new to the >>>>>>> gumstix. >>>>>>> I'm >>>>>>> simply looking to get SPI Mode communication to an SD Card (I have >>>>>>> SD >>>>>>> Card >>>>>>> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> gumstix-users mailing list >>>>>> gum...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>>> >>> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p28540349.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bernhard Wörndl-A. <bw...@xd...> - 2010-05-12 21:11:21
|
Send your setup file please. Is anything else connected to the SPI bus? Or the better question - do you use a breakout board with a touchscreen? Normally the touchscreen controller is connected to the SPI bus - if you are not using it, just remove it's setup. Regards *Bernhard Wörndl-Aichriedler* Am 12.05.2010 21:48, schrieb plasmaphase: > New error: > > mmc_spi spi1.0: can't share SPI bus > mmc_spi: probe of spi1.0 failed with error -16 > > > > > > > > > > > > plasmaphase wrote: > >> I forgot to do the level translation from 1.8V to 3.3V...so that's one >> problem. I did not see any toggling of SCK, which I would expect to see >> (even if @ 1.8V). I am using a microSD card...which does not have a WP >> pin...can I just pull this high? I also am not certain where to place the >> WP and CD pins on the header, as: >> >> #define S1_MMC_SPI_CD_PIN 144 >> #define S1_MMC_SPI_WP_PIN 145 >> >> We will only be using one card, and so I don't think these are necessary >> except to fake out for the driver...is CD active high or low? >> >> Thanks for your quick and helpful responses! >> >> >> >> >> Bernhard Wörndl-Aichriedler wrote: >> >>> Currently not really, >>> >>> Are you sure the hardware and the level conversion works? >>> Do you get anything on CS, DI, DO and SCK? >>> >>> Can you send me your board setup? >>> >>> >>> Regards >>> >>> *Bernhard Wörndl-Aichriedler* >>> >>> >>> Am 12.05.2010 20:07, schrieb plasmaphase: >>> >>>> overo mmc_spi: probe of spi1.0 failed with error -16 >>>> >>>> Any ideas? >>>> >>>> >>>> >>>> >>>> Bernhard Wörndl-Aichriedler wrote: >>>> >>>> >>>>> Hey =) >>>>> >>>>> This should do the trick: >>>>> >>>>> >>>>> #include<linux/spi/spi.h> >>>>> #include<linux/spi/mmc_spi.h> >>>>> >>>>> >>>>> int s1_mmc_spi_card_detect(struct device *dev) >>>>> { >>>>> return !gpio_get_value(S1_MMC_SPI_CD_PIN); >>>>> } >>>>> >>>>> int s1_mmc_spi_write_protect(struct device *dev) >>>>> { >>>>> return gpio_get_value(S1_MMC_SPI_WP_PIN); >>>>> } >>>>> >>>>> int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void >>>>> *),void *mmc) >>>>> { >>>>> int ret; >>>>> ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), >>>>> cd, >>>>> IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, >>>>> "mmc_spi-detect", mmc); >>>>> if (ret) { >>>>> printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d >>>>> for >>>>> detect pin\n", >>>>> gpio_to_irq(S1_MMC_SPI_CD_PIN)); >>>>> } >>>>> return 0; >>>>> } >>>>> >>>>> void s1_mmc_spi_exit(struct device *dev, void *data) >>>>> { >>>>> free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); >>>>> } >>>>> >>>>> >>>>> static struct mmc_spi_platform_data mmc_spi_data = { >>>>> .init = s1_mmc_spi_init, >>>>> .exit = s1_mmc_spi_exit, >>>>> .get_ro = s1_mmc_spi_write_protect, >>>>> .get_cd = s1_mmc_spi_card_detect, >>>>> }; >>>>> >>>>> >>>>> static struct spi_board_info spi1_board_info[] __initdata = { >>>>> { >>>>> .modalias = "mmc_spi", >>>>> .max_speed_hz = 12000000, >>>>> .chip_select = 0, >>>>> .platform_data =&mmc_spi_data, >>>>> .mode = SPI_MODE_3, >>>>> }, >>>>> }; >>>>> >>>>> ... >>>>> >>>>> at32_add_device_spi(1, spi1_board_info, >>>>> ARRAY_SIZE(spi1_board_info)); >>>>> >>>>> from the kernel side, at least after some modification to adopt to the >>>>> omap3. >>>>> >>>>> And the hardware setup is really easy: >>>>> >>>>> >>>>> >>>>> at least for the AP7000, that run on 3.3V >>>>> >>>>> >>>>> Regards >>>>> >>>>> *Bernhard Wörndl-Aichriedler* >>>>> >>>>> Am 05.05.2010 19:56, schrieb plasmaphase: >>>>> >>>>> >>>>>> Could you expand upon the SPI solution? How do you enable it in the >>>>>> Linux >>>>>> Board Setup? What is it that is required to get this working (links >>>>>> would >>>>>> be adequate/helpful as well). Thanks! >>>>>> >>>>>> >>>>>> Bernhard Wörndl-Aichriedler wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hey =) >>>>>>> >>>>>>> Using SD over SPI is generally not that of a problem, you just need >>>>>>> to >>>>>>> enable it in the Linux Board Setup. >>>>>>> (I did that some time ago, not for the overo/omap, but for a AP7000 >>>>>>> and >>>>>>> it worked pretty well). >>>>>>> >>>>>>> But the Overo breaks out an additional MMC interface, that you might >>>>>>> be >>>>>>> able to use, in order to get higher speed (4bit SD mode instead of 1 >>>>>>> bit >>>>>>> MMC-SPI mode). >>>>>>> I have that solution ready, but haven't changed the kernel yet, to >>>>>>> work >>>>>>> with it. I'll report to you if i get everything running (hopefully in >>>>>>> 2 >>>>>>> two 3 days) >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> *Bernhard Wörndl-Aichriedler* >>>>>>> >>>>>>> Am 05.05.2010 15:30, schrieb plasmaphase: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Has anyone attempted using SPI for communications to an SD Card (not >>>>>>>> the >>>>>>>> onboard SD card)? If so, would you please provide any information >>>>>>>> you >>>>>>>> would >>>>>>>> consider helpful in getting this working. I'm very new to the >>>>>>>> gumstix. >>>>>>>> I'm >>>>>>>> simply looking to get SPI Mode communication to an SD Card (I have >>>>>>>> SD >>>>>>>> Card >>>>>>>> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gumstix-users mailing list >>>>>>> gum...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> >> > |
From: plasmaphase <mar...@jh...> - 2010-07-07 11:59:18
|
I have a strange feeling that what's referred to as the Chip Detect pin is actually the Chip Select pin. S1_MMC_SPI_CD_PIN Chip detect is a pin that is pulled low when a card is inserted...it's never interfaced with except for reading to check if a card is in the slot. Is it possible the S1_MMC_SPI_CD_PIN is actually referring to the Chip Select pin? If so, how are they supposed to be defined? #define S1_MMC_SPI_CD_PIN #define S1_MMC_SPI_WP_PIN If not, what exactly does the mmc_spi_init() function do? Bernhard Wörndl-Aichriedler wrote: > > Send your setup file please. > > Is anything else connected to the SPI bus? > Or the better question - do you use a breakout board with a touchscreen? > Normally the touchscreen controller is connected to the SPI bus - if you > are not using it, just remove it's setup. > > Regards > > *Bernhard Wörndl-Aichriedler* > > Am 12.05.2010 21:48, schrieb plasmaphase: >> New error: >> >> mmc_spi spi1.0: can't share SPI bus >> mmc_spi: probe of spi1.0 failed with error -16 >> >> >> >> >> >> >> >> >> >> >> >> plasmaphase wrote: >> >>> I forgot to do the level translation from 1.8V to 3.3V...so that's one >>> problem. I did not see any toggling of SCK, which I would expect to see >>> (even if @ 1.8V). I am using a microSD card...which does not have a WP >>> pin...can I just pull this high? I also am not certain where to place >>> the >>> WP and CD pins on the header, as: >>> >>> #define S1_MMC_SPI_CD_PIN 144 >>> #define S1_MMC_SPI_WP_PIN 145 >>> >>> We will only be using one card, and so I don't think these are necessary >>> except to fake out for the driver...is CD active high or low? >>> >>> Thanks for your quick and helpful responses! >>> >>> >>> >>> >>> Bernhard Wörndl-Aichriedler wrote: >>> >>>> Currently not really, >>>> >>>> Are you sure the hardware and the level conversion works? >>>> Do you get anything on CS, DI, DO and SCK? >>>> >>>> Can you send me your board setup? >>>> >>>> >>>> Regards >>>> >>>> *Bernhard Wörndl-Aichriedler* >>>> >>>> >>>> Am 12.05.2010 20:07, schrieb plasmaphase: >>>> >>>>> overo mmc_spi: probe of spi1.0 failed with error -16 >>>>> >>>>> Any ideas? >>>>> >>>>> >>>>> >>>>> >>>>> Bernhard Wörndl-Aichriedler wrote: >>>>> >>>>> >>>>>> Hey =) >>>>>> >>>>>> This should do the trick: >>>>>> >>>>>> >>>>>> #include<linux/spi/spi.h> >>>>>> #include<linux/spi/mmc_spi.h> >>>>>> >>>>>> >>>>>> int s1_mmc_spi_card_detect(struct device *dev) >>>>>> { >>>>>> return !gpio_get_value(S1_MMC_SPI_CD_PIN); >>>>>> } >>>>>> >>>>>> int s1_mmc_spi_write_protect(struct device *dev) >>>>>> { >>>>>> return gpio_get_value(S1_MMC_SPI_WP_PIN); >>>>>> } >>>>>> >>>>>> int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void >>>>>> *),void *mmc) >>>>>> { >>>>>> int ret; >>>>>> ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), >>>>>> cd, >>>>>> IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, >>>>>> "mmc_spi-detect", mmc); >>>>>> if (ret) { >>>>>> printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d >>>>>> for >>>>>> detect pin\n", >>>>>> gpio_to_irq(S1_MMC_SPI_CD_PIN)); >>>>>> } >>>>>> return 0; >>>>>> } >>>>>> >>>>>> void s1_mmc_spi_exit(struct device *dev, void *data) >>>>>> { >>>>>> free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); >>>>>> } >>>>>> >>>>>> >>>>>> static struct mmc_spi_platform_data mmc_spi_data = { >>>>>> .init = s1_mmc_spi_init, >>>>>> .exit = s1_mmc_spi_exit, >>>>>> .get_ro = s1_mmc_spi_write_protect, >>>>>> .get_cd = s1_mmc_spi_card_detect, >>>>>> }; >>>>>> >>>>>> >>>>>> static struct spi_board_info spi1_board_info[] __initdata = { >>>>>> { >>>>>> .modalias = "mmc_spi", >>>>>> .max_speed_hz = 12000000, >>>>>> .chip_select = 0, >>>>>> .platform_data =&mmc_spi_data, >>>>>> .mode = SPI_MODE_3, >>>>>> }, >>>>>> }; >>>>>> >>>>>> ... >>>>>> >>>>>> at32_add_device_spi(1, spi1_board_info, >>>>>> ARRAY_SIZE(spi1_board_info)); >>>>>> >>>>>> from the kernel side, at least after some modification to adopt to >>>>>> the >>>>>> omap3. >>>>>> >>>>>> And the hardware setup is really easy: >>>>>> >>>>>> >>>>>> >>>>>> at least for the AP7000, that run on 3.3V >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> *Bernhard Wörndl-Aichriedler* >>>>>> >>>>>> Am 05.05.2010 19:56, schrieb plasmaphase: >>>>>> >>>>>> >>>>>>> Could you expand upon the SPI solution? How do you enable it in the >>>>>>> Linux >>>>>>> Board Setup? What is it that is required to get this working (links >>>>>>> would >>>>>>> be adequate/helpful as well). Thanks! >>>>>>> >>>>>>> >>>>>>> Bernhard Wörndl-Aichriedler wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hey =) >>>>>>>> >>>>>>>> Using SD over SPI is generally not that of a problem, you just need >>>>>>>> to >>>>>>>> enable it in the Linux Board Setup. >>>>>>>> (I did that some time ago, not for the overo/omap, but for a AP7000 >>>>>>>> and >>>>>>>> it worked pretty well). >>>>>>>> >>>>>>>> But the Overo breaks out an additional MMC interface, that you >>>>>>>> might >>>>>>>> be >>>>>>>> able to use, in order to get higher speed (4bit SD mode instead of >>>>>>>> 1 >>>>>>>> bit >>>>>>>> MMC-SPI mode). >>>>>>>> I have that solution ready, but haven't changed the kernel yet, to >>>>>>>> work >>>>>>>> with it. I'll report to you if i get everything running (hopefully >>>>>>>> in >>>>>>>> 2 >>>>>>>> two 3 days) >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> *Bernhard Wörndl-Aichriedler* >>>>>>>> >>>>>>>> Am 05.05.2010 15:30, schrieb plasmaphase: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Has anyone attempted using SPI for communications to an SD Card >>>>>>>>> (not >>>>>>>>> the >>>>>>>>> onboard SD card)? If so, would you please provide any information >>>>>>>>> you >>>>>>>>> would >>>>>>>>> consider helpful in getting this working. I'm very new to the >>>>>>>>> gumstix. >>>>>>>>> I'm >>>>>>>>> simply looking to get SPI Mode communication to an SD Card (I have >>>>>>>>> SD >>>>>>>>> Card >>>>>>>>> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> gumstix-users mailing list >>>>>>>> gum...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> gumstix-users mailing list >>>>>> gum...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>>> >>> >>> >> > > ------------------------------------------------------------------------------ > > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p29095229.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: plasmaphase <mar...@jh...> - 2010-05-12 21:18:02
|
Here's a picture of my current setup (how I'm doing level shifting and what pins I'm using to control WP and CD) http://old.nabble.com/file/p28541212/gumstix_spi.jpg The kernel, when booting up, now says: overo mmc_spi spi1.0: ASSUMING SPI bus stays unshared! overo mmc_spi spi1.0: ASSUMING 3.2-3.4 V slot power overo mmc_spi spi1.0: SD/MMC host mmc2, no DMA, no poweroff I see no evidence that the sd card is known in the /dev directory. My first question is this: What should the values of CD and WP be? I'm asking this because there is no write protect on a microSD card, and I am only using 1 card that will always be plugged in, so I'd rather bypass these. I've attached my board-overo.c for further checking if you feel the need. Thanks in advance. http://old.nabble.com/file/p28541212/board-overo.c board-overo.c -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p28541212.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bernhard Wörndl-A. <bw...@xd...> - 2010-05-12 21:35:17
|
Then you might remove this: #if defined(CONFIG_TOUCHSCREEN_ADS7846) || \ defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE) { .modalias = "ads7846", .bus_num = 1, .chip_select = 0, .max_speed_hz = 1500000, .controller_data = &ads7846_mcspi_config, .irq = OMAP_GPIO_IRQ(OVERO_GPIO_PENDOWN), .platform_data = &ads7846_config, }, #endif #if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \ defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE) { .modalias = "lgphilips_lb035q02_panel-spi", .bus_num = 1, .chip_select = 1, .max_speed_hz = 500000, .mode = SPI_MODE_3, }, #endif from your setup, to ensure that the SPI bus stays unshared =) You can simply disable WP and CD just as you like, by putting -EINVAL instead of the gpio pin number. If you disable WP, no write protect - of what a pitty xD But if you disable CD you have to ensure, that the SD card is plugged into the system, when linux boots. Regards *Bernhard Wörndl-Aichriedler* Am 12.05.2010 23:22, schrieb plasmaphase: > no touchscreens on summit board...and I believe I removed both of them from > the kernel configuration. > > > > > > > plasmaphase wrote: > >> Here's a picture of my current setup (how I'm doing level shifting and >> what pins I'm using to control WP and CD) >> >> http://old.nabble.com/file/p28541212/gumstix_spi.jpg >> >> The kernel, when booting up, now says: >> >> overo mmc_spi spi1.0: ASSUMING SPI bus stays unshared! >> overo mmc_spi spi1.0: ASSUMING 3.2-3.4 V slot power >> overo mmc_spi spi1.0: SD/MMC host mmc2, no DMA, no poweroff >> >> I see no evidence that the sd card is known in the /dev directory. >> >> My first question is this: >> >> What should the values of CD and WP be? I'm asking this because there is >> no write protect on a microSD card, and I am only using 1 card that will >> always be plugged in, so I'd rather bypass these. >> >> I've attached my board-overo.c for further checking if you feel the need. >> Thanks in advance. >> >> >> http://old.nabble.com/file/p28541212/board-overo.c board-overo.c >> >> >> >> > |
From: plasmaphase <mar...@jh...> - 2010-07-06 20:27:48
|
I have recently moved to 2.6.33 kernel and noticed there were a few changes to the board-overo.c file. I have not yet been able to get MMC SPI working, but have ported what I had in the previous board-overo.c file and am now getting this error: mmc_spi_data: undeclared here (not in a function) For some reason it is not able to see the mmc_spi_data, even though it's clearly in the board-overo.c file. I've attached my board-overo.c file for reference. If I change the .platform_data = &mmc_spi_data, to .platform_data = 0x0, it compiles, so I know that particular line of code is causing the problem. Any suggestions? http://old.nabble.com/file/p29089733/board-overo.c board-overo.c Bernhard Wörndl-Aichriedler wrote: > > Send your setup file please. > > Is anything else connected to the SPI bus? > Or the better question - do you use a breakout board with a touchscreen? > Normally the touchscreen controller is connected to the SPI bus - if you > are not using it, just remove it's setup. > > Regards > > *Bernhard Wörndl-Aichriedler* > > Am 12.05.2010 21:48, schrieb plasmaphase: >> New error: >> >> mmc_spi spi1.0: can't share SPI bus >> mmc_spi: probe of spi1.0 failed with error -16 >> >> >> >> >> >> >> >> >> >> >> >> plasmaphase wrote: >> >>> I forgot to do the level translation from 1.8V to 3.3V...so that's one >>> problem. I did not see any toggling of SCK, which I would expect to see >>> (even if @ 1.8V). I am using a microSD card...which does not have a WP >>> pin...can I just pull this high? I also am not certain where to place >>> the >>> WP and CD pins on the header, as: >>> >>> #define S1_MMC_SPI_CD_PIN 144 >>> #define S1_MMC_SPI_WP_PIN 145 >>> >>> We will only be using one card, and so I don't think these are necessary >>> except to fake out for the driver...is CD active high or low? >>> >>> Thanks for your quick and helpful responses! >>> >>> >>> >>> >>> Bernhard Wörndl-Aichriedler wrote: >>> >>>> Currently not really, >>>> >>>> Are you sure the hardware and the level conversion works? >>>> Do you get anything on CS, DI, DO and SCK? >>>> >>>> Can you send me your board setup? >>>> >>>> >>>> Regards >>>> >>>> *Bernhard Wörndl-Aichriedler* >>>> >>>> >>>> Am 12.05.2010 20:07, schrieb plasmaphase: >>>> >>>>> overo mmc_spi: probe of spi1.0 failed with error -16 >>>>> >>>>> Any ideas? >>>>> >>>>> >>>>> >>>>> >>>>> Bernhard Wörndl-Aichriedler wrote: >>>>> >>>>> >>>>>> Hey =) >>>>>> >>>>>> This should do the trick: >>>>>> >>>>>> >>>>>> #include<linux/spi/spi.h> >>>>>> #include<linux/spi/mmc_spi.h> >>>>>> >>>>>> >>>>>> int s1_mmc_spi_card_detect(struct device *dev) >>>>>> { >>>>>> return !gpio_get_value(S1_MMC_SPI_CD_PIN); >>>>>> } >>>>>> >>>>>> int s1_mmc_spi_write_protect(struct device *dev) >>>>>> { >>>>>> return gpio_get_value(S1_MMC_SPI_WP_PIN); >>>>>> } >>>>>> >>>>>> int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void >>>>>> *),void *mmc) >>>>>> { >>>>>> int ret; >>>>>> ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), >>>>>> cd, >>>>>> IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, >>>>>> "mmc_spi-detect", mmc); >>>>>> if (ret) { >>>>>> printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d >>>>>> for >>>>>> detect pin\n", >>>>>> gpio_to_irq(S1_MMC_SPI_CD_PIN)); >>>>>> } >>>>>> return 0; >>>>>> } >>>>>> >>>>>> void s1_mmc_spi_exit(struct device *dev, void *data) >>>>>> { >>>>>> free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); >>>>>> } >>>>>> >>>>>> >>>>>> static struct mmc_spi_platform_data mmc_spi_data = { >>>>>> .init = s1_mmc_spi_init, >>>>>> .exit = s1_mmc_spi_exit, >>>>>> .get_ro = s1_mmc_spi_write_protect, >>>>>> .get_cd = s1_mmc_spi_card_detect, >>>>>> }; >>>>>> >>>>>> >>>>>> static struct spi_board_info spi1_board_info[] __initdata = { >>>>>> { >>>>>> .modalias = "mmc_spi", >>>>>> .max_speed_hz = 12000000, >>>>>> .chip_select = 0, >>>>>> .platform_data =&mmc_spi_data, >>>>>> .mode = SPI_MODE_3, >>>>>> }, >>>>>> }; >>>>>> >>>>>> ... >>>>>> >>>>>> at32_add_device_spi(1, spi1_board_info, >>>>>> ARRAY_SIZE(spi1_board_info)); >>>>>> >>>>>> from the kernel side, at least after some modification to adopt to >>>>>> the >>>>>> omap3. >>>>>> >>>>>> And the hardware setup is really easy: >>>>>> >>>>>> >>>>>> >>>>>> at least for the AP7000, that run on 3.3V >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> *Bernhard Wörndl-Aichriedler* >>>>>> >>>>>> Am 05.05.2010 19:56, schrieb plasmaphase: >>>>>> >>>>>> >>>>>>> Could you expand upon the SPI solution? How do you enable it in the >>>>>>> Linux >>>>>>> Board Setup? What is it that is required to get this working (links >>>>>>> would >>>>>>> be adequate/helpful as well). Thanks! >>>>>>> >>>>>>> >>>>>>> Bernhard Wörndl-Aichriedler wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hey =) >>>>>>>> >>>>>>>> Using SD over SPI is generally not that of a problem, you just need >>>>>>>> to >>>>>>>> enable it in the Linux Board Setup. >>>>>>>> (I did that some time ago, not for the overo/omap, but for a AP7000 >>>>>>>> and >>>>>>>> it worked pretty well). >>>>>>>> >>>>>>>> But the Overo breaks out an additional MMC interface, that you >>>>>>>> might >>>>>>>> be >>>>>>>> able to use, in order to get higher speed (4bit SD mode instead of >>>>>>>> 1 >>>>>>>> bit >>>>>>>> MMC-SPI mode). >>>>>>>> I have that solution ready, but haven't changed the kernel yet, to >>>>>>>> work >>>>>>>> with it. I'll report to you if i get everything running (hopefully >>>>>>>> in >>>>>>>> 2 >>>>>>>> two 3 days) >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> *Bernhard Wörndl-Aichriedler* >>>>>>>> >>>>>>>> Am 05.05.2010 15:30, schrieb plasmaphase: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Has anyone attempted using SPI for communications to an SD Card >>>>>>>>> (not >>>>>>>>> the >>>>>>>>> onboard SD card)? If so, would you please provide any information >>>>>>>>> you >>>>>>>>> would >>>>>>>>> consider helpful in getting this working. I'm very new to the >>>>>>>>> gumstix. >>>>>>>>> I'm >>>>>>>>> simply looking to get SPI Mode communication to an SD Card (I have >>>>>>>>> SD >>>>>>>>> Card >>>>>>>>> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> gumstix-users mailing list >>>>>>>> gum...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> gumstix-users mailing list >>>>>> gum...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>>> >>> >>> >> > > ------------------------------------------------------------------------------ > > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > http://old.nabble.com/file/p29089733/board-overo.c board-overo.c -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p29089733.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-07-06 20:39:28
|
Hi, On Tue, Jul 6, 2010 at 1:27 PM, plasmaphase <mar...@jh...> wrote: > > I have recently moved to 2.6.33 kernel and noticed there were a few changes > to the board-overo.c file. I have not yet been able to get MMC SPI working, > but have ported what I had in the previous board-overo.c file and am now > getting this error: > > mmc_spi_data: undeclared here (not in a function) > > For some reason it is not able to see the mmc_spi_data, even though it's > clearly in the board-overo.c file. but, it's inside #if defined(CONFIG_TOUCHSCREEN_ADS7846) || \ defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE) So you have one of those defined? You could also put #error next to the declaration of mmc_spi_data and see if you get the error or not. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: plasmaphase <mar...@jh...> - 2010-07-06 23:14:56
|
Nice catch, thanks! Dave Hylands wrote: > > Hi, > > On Tue, Jul 6, 2010 at 1:27 PM, plasmaphase <mar...@jh...> > wrote: >> >> I have recently moved to 2.6.33 kernel and noticed there were a few >> changes >> to the board-overo.c file. I have not yet been able to get MMC SPI >> working, >> but have ported what I had in the previous board-overo.c file and am now >> getting this error: >> >> mmc_spi_data: undeclared here (not in a function) >> >> For some reason it is not able to see the mmc_spi_data, even though it's >> clearly in the board-overo.c file. > > but, it's inside > > #if defined(CONFIG_TOUCHSCREEN_ADS7846) || \ > defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE) > > So you have one of those defined? > > You could also put > > #error next to the declaration of mmc_spi_data and see if you get the > error or not. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p29091012.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: plasmaphase <mar...@jh...> - 2010-05-05 17:57:02
|
Could you expand upon the SPI solution? How do you enable it in the Linux Board Setup? What is it that is required to get this working (links would be adequate/helpful as well). Thanks! Bernhard Wörndl-Aichriedler wrote: > > Hey =) > > Using SD over SPI is generally not that of a problem, you just need to > enable it in the Linux Board Setup. > (I did that some time ago, not for the overo/omap, but for a AP7000 and > it worked pretty well). > > But the Overo breaks out an additional MMC interface, that you might be > able to use, in order to get higher speed (4bit SD mode instead of 1 bit > MMC-SPI mode). > I have that solution ready, but haven't changed the kernel yet, to work > with it. I'll report to you if i get everything running (hopefully in 2 > two 3 days) > > > Regards > > *Bernhard Wörndl-Aichriedler* > > Am 05.05.2010 15:30, schrieb plasmaphase: >> Has anyone attempted using SPI for communications to an SD Card (not the >> onboard SD card)? If so, would you please provide any information you >> would >> consider helpful in getting this working. I'm very new to the gumstix. >> I'm >> simply looking to get SPI Mode communication to an SD Card (I have SD >> Card >> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p28462910.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bernhard Wörndl-A. <bw...@xd...> - 2010-05-06 14:05:08
|
Hey =) This should do the trick: #include <linux/spi/spi.h> #include <linux/spi/mmc_spi.h> int s1_mmc_spi_card_detect(struct device *dev) { return !gpio_get_value(S1_MMC_SPI_CD_PIN); } int s1_mmc_spi_write_protect(struct device *dev) { return gpio_get_value(S1_MMC_SPI_WP_PIN); } int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void *),void *mmc) { int ret; ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), cd, IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, "mmc_spi-detect", mmc); if (ret) { printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d for detect pin\n", gpio_to_irq(S1_MMC_SPI_CD_PIN)); } return 0; } void s1_mmc_spi_exit(struct device *dev, void *data) { free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); } static struct mmc_spi_platform_data mmc_spi_data = { .init = s1_mmc_spi_init, .exit = s1_mmc_spi_exit, .get_ro = s1_mmc_spi_write_protect, .get_cd = s1_mmc_spi_card_detect, }; static struct spi_board_info spi1_board_info[] __initdata = { { .modalias = "mmc_spi", .max_speed_hz = 12000000, .chip_select = 0, .platform_data = &mmc_spi_data, .mode = SPI_MODE_3, }, }; ... at32_add_device_spi(1, spi1_board_info, ARRAY_SIZE(spi1_board_info)); from the kernel side, at least after some modification to adopt to the omap3. And the hardware setup is really easy: at least for the AP7000, that run on 3.3V Regards *Bernhard Wörndl-Aichriedler* Am 05.05.2010 19:56, schrieb plasmaphase: > Could you expand upon the SPI solution? How do you enable it in the Linux > Board Setup? What is it that is required to get this working (links would > be adequate/helpful as well). Thanks! > > > Bernhard Wörndl-Aichriedler wrote: > >> Hey =) >> >> Using SD over SPI is generally not that of a problem, you just need to >> enable it in the Linux Board Setup. >> (I did that some time ago, not for the overo/omap, but for a AP7000 and >> it worked pretty well). >> >> But the Overo breaks out an additional MMC interface, that you might be >> able to use, in order to get higher speed (4bit SD mode instead of 1 bit >> MMC-SPI mode). >> I have that solution ready, but haven't changed the kernel yet, to work >> with it. I'll report to you if i get everything running (hopefully in 2 >> two 3 days) >> >> >> Regards >> >> *Bernhard Wörndl-Aichriedler* >> >> Am 05.05.2010 15:30, schrieb plasmaphase: >> >>> Has anyone attempted using SPI for communications to an SD Card (not the >>> onboard SD card)? If so, would you please provide any information you >>> would >>> consider helpful in getting this working. I'm very new to the gumstix. >>> I'm >>> simply looking to get SPI Mode communication to an SD Card (I have SD >>> Card >>> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >>> >>> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> > |
From: plasmaphase <mar...@jh...> - 2010-05-12 18:07:24
|
overo mmc_spi: probe of spi1.0 failed with error -16 Any ideas? Bernhard Wörndl-Aichriedler wrote: > > Hey =) > > This should do the trick: > > > #include <linux/spi/spi.h> > #include <linux/spi/mmc_spi.h> > > > int s1_mmc_spi_card_detect(struct device *dev) > { > return !gpio_get_value(S1_MMC_SPI_CD_PIN); > } > > int s1_mmc_spi_write_protect(struct device *dev) > { > return gpio_get_value(S1_MMC_SPI_WP_PIN); > } > > int s1_mmc_spi_init(struct device *dev,irqreturn_t (*cd)(int, void > *),void *mmc) > { > int ret; > ret = request_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), > cd, > IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, > "mmc_spi-detect", mmc); > if (ret) { > printk(KERN_WARNING "mmc_spi_int: could not request IRQ %d for > detect pin\n", > gpio_to_irq(S1_MMC_SPI_CD_PIN)); > } > return 0; > } > > void s1_mmc_spi_exit(struct device *dev, void *data) > { > free_irq(gpio_to_irq(S1_MMC_SPI_CD_PIN), data); > } > > > static struct mmc_spi_platform_data mmc_spi_data = { > .init = s1_mmc_spi_init, > .exit = s1_mmc_spi_exit, > .get_ro = s1_mmc_spi_write_protect, > .get_cd = s1_mmc_spi_card_detect, > }; > > > static struct spi_board_info spi1_board_info[] __initdata = { > { > .modalias = "mmc_spi", > .max_speed_hz = 12000000, > .chip_select = 0, > .platform_data = &mmc_spi_data, > .mode = SPI_MODE_3, > }, > }; > > ... > > at32_add_device_spi(1, spi1_board_info, ARRAY_SIZE(spi1_board_info)); > > from the kernel side, at least after some modification to adopt to the > omap3. > > And the hardware setup is really easy: > > > > at least for the AP7000, that run on 3.3V > > > Regards > > *Bernhard Wörndl-Aichriedler* > > Am 05.05.2010 19:56, schrieb plasmaphase: >> Could you expand upon the SPI solution? How do you enable it in the >> Linux >> Board Setup? What is it that is required to get this working (links >> would >> be adequate/helpful as well). Thanks! >> >> >> Bernhard Wörndl-Aichriedler wrote: >> >>> Hey =) >>> >>> Using SD over SPI is generally not that of a problem, you just need to >>> enable it in the Linux Board Setup. >>> (I did that some time ago, not for the overo/omap, but for a AP7000 and >>> it worked pretty well). >>> >>> But the Overo breaks out an additional MMC interface, that you might be >>> able to use, in order to get higher speed (4bit SD mode instead of 1 bit >>> MMC-SPI mode). >>> I have that solution ready, but haven't changed the kernel yet, to work >>> with it. I'll report to you if i get everything running (hopefully in 2 >>> two 3 days) >>> >>> >>> Regards >>> >>> *Bernhard Wörndl-Aichriedler* >>> >>> Am 05.05.2010 15:30, schrieb plasmaphase: >>> >>>> Has anyone attempted using SPI for communications to an SD Card (not >>>> the >>>> onboard SD card)? If so, would you please provide any information you >>>> would >>>> consider helpful in getting this working. I'm very new to the gumstix. >>>> I'm >>>> simply looking to get SPI Mode communication to an SD Card (I have SD >>>> Card >>>> spi driver, and have solved the 1.8V to 3.3V issue). Thanks. >>>> >>>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p28539272.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: plasmaphase <mar...@jh...> - 2010-05-12 21:22:35
|
no touchscreens on summit board...and I believe I removed both of them from the kernel configuration. plasmaphase wrote: > > Here's a picture of my current setup (how I'm doing level shifting and > what pins I'm using to control WP and CD) > > http://old.nabble.com/file/p28541212/gumstix_spi.jpg > > The kernel, when booting up, now says: > > overo mmc_spi spi1.0: ASSUMING SPI bus stays unshared! > overo mmc_spi spi1.0: ASSUMING 3.2-3.4 V slot power > overo mmc_spi spi1.0: SD/MMC host mmc2, no DMA, no poweroff > > I see no evidence that the sd card is known in the /dev directory. > > My first question is this: > > What should the values of CD and WP be? I'm asking this because there is > no write protect on a microSD card, and I am only using 1 card that will > always be plugged in, so I'd rather bypass these. > > I've attached my board-overo.c for further checking if you feel the need. > Thanks in advance. > > > http://old.nabble.com/file/p28541212/board-overo.c board-overo.c > > > -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p28541255.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: plasmaphase <mar...@jh...> - 2010-05-13 13:20:13
|
I put in the suggested fixes to the board-overo.c file. I am also seeing a curious output during boot: mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty mmc_spi spi1.0: DMA RX last word empty Is this a comms problem or maybe my clock is too fast? I also noticed another problem when editing the board-overo.c file. There were defines further down in the file that were using the same 144, 145 pins. Shouldn't have caused any problems though. -- View this message in context: http://old.nabble.com/SD-Card-SPI-tp28460935p28547409.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bernhard Wörndl-A. <bw...@xd...> - 2010-05-13 13:59:51
|
Hmm... weird. Did you disable the CD and the WP pin? As you said, the pins 144 and 145 are used for display control, so there might be some issues with that. Normally the selected 12MHz should be fine for most of the cards. Do you get anything on the DI? - MISO Regards *Bernhard Wörndl-Aichriedler* Am 13.05.2010 15:20, schrieb plasmaphase: > I put in the suggested fixes to the board-overo.c file. I am also seeing a > curious output during boot: > > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > mmc_spi spi1.0: DMA RX last word empty > > > Is this a comms problem or maybe my clock is too fast? I also noticed > another problem when editing the board-overo.c file. There were defines > further down in the file that were using the same 144, 145 pins. Shouldn't > have caused any problems though. > |