[PATCH 0/4] omap: merge IGEP v2 and v3
Hi Tony, This is yet another attempt to reduce code duplication in the board files :) Only build tested, since I don't have the hardware, so I belive an Ack from Enric is required. Mike Rapoport (4): omap: igep0020: name refactoring for future merge with IGEP3 omap: igep0020: minor refactoring omap: igep0020: add support for IGEP3 omap: drop board-igep0030.c arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/Makefile |2 - arch/arm/mach-omap2/board-igep0020.c | 286 +- arch/arm/mach-omap2/board-igep0030.c | 438 -- 4 files changed, 174 insertions(+), 553 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-igep0030.c -- 1.7.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] omap: igep0020: name refactoring for future merge with IGEP3
IGEP2 and IGEP3 boards are very similar and can be merged into one file.
Start refactoring with changing igep2 to igep where applicable.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-igep0020.c | 158 +-
1 files changed, 79 insertions(+), 79 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index c62c297e..ad20f7b 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -112,7 +112,7 @@ static void __init igep2_get_revision(void)
* So MTD regards it as 4KiB page size and 256KiB block size 64*(2*2048)
*/
-static struct mtd_partition igep2_onenand_partitions[] = {
+static struct mtd_partition igep_onenand_partitions[] = {
{
.name = X-Loader,
.offset = 0,
@@ -140,21 +140,21 @@ static struct mtd_partition igep2_onenand_partitions[] = {
},
};
-static struct omap_onenand_platform_data igep2_onenand_data = {
- .parts = igep2_onenand_partitions,
- .nr_parts = ARRAY_SIZE(igep2_onenand_partitions),
+static struct omap_onenand_platform_data igep_onenand_data = {
+ .parts = igep_onenand_partitions,
+ .nr_parts = ARRAY_SIZE(igep_onenand_partitions),
.dma_channel= -1, /* disable DMA in OMAP OneNAND driver */
};
-static struct platform_device igep2_onenand_device = {
+static struct platform_device igep_onenand_device = {
.name = omap2-onenand,
.id = -1,
.dev = {
- .platform_data = igep2_onenand_data,
+ .platform_data = igep_onenand_data,
},
};
-static void __init igep2_flash_init(void)
+static void __init igep_flash_init(void)
{
u8 cs = 0;
u8 onenandcs = GPMC_CS_NUM + 1;
@@ -166,7 +166,7 @@ static void __init igep2_flash_init(void)
/* Check if NAND/oneNAND is configured */
if ((ret 0xC00) == 0x800)
/* NAND found */
- pr_err(IGEP2: Unsupported NAND found\n);
+ pr_err(IGEP: Unsupported NAND found\n);
else {
ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
if ((ret 0x3F) == (ONENAND_MAP 24))
@@ -176,18 +176,18 @@ static void __init igep2_flash_init(void)
}
if (onenandcs GPMC_CS_NUM) {
- pr_err(IGEP2: Unable to find configuration in GPMC\n);
+ pr_err(IGEP: Unable to find configuration in GPMC\n);
return;
}
- igep2_onenand_data.cs = onenandcs;
+ igep_onenand_data.cs = onenandcs;
- if (platform_device_register(igep2_onenand_device) 0)
- pr_err(IGEP2: Unable to register OneNAND device\n);
+ if (platform_device_register(igep_onenand_device) 0)
+ pr_err(IGEP: Unable to register OneNAND device\n);
}
#else
-static void __init igep2_flash_init(void) {}
+static void __init igep_flash_init(void) {}
#endif
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
@@ -211,11 +211,11 @@ static inline void __init igep2_init_smsc911x(void)
static inline void __init igep2_init_smsc911x(void) { }
#endif
-static struct regulator_consumer_supply igep2_vmmc1_supply =
+static struct regulator_consumer_supply igep_vmmc1_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
-static struct regulator_init_data igep2_vmmc1 = {
+static struct regulator_init_data igep_vmmc1 = {
.constraints = {
.min_uV = 185,
.max_uV = 315,
@@ -226,13 +226,13 @@ static struct regulator_init_data igep2_vmmc1 = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = igep2_vmmc1_supply,
+ .consumer_supplies = igep_vmmc1_supply,
};
-static struct regulator_consumer_supply igep2_vio_supply =
+static struct regulator_consumer_supply igep_vio_supply =
REGULATOR_SUPPLY(vmmc_aux, omap_hsmmc.1);
-static struct regulator_init_data igep2_vio = {
+static struct regulator_init_data igep_vio = {
.constraints = {
.min_uV = 180,
.max_uV = 180,
@@ -244,34 +244,34 @@ static struct regulator_init_data igep2_vio = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = igep2_vio_supply,
+ .consumer_supplies = igep_vio_supply,
};
-static struct regulator_consumer_supply igep2_vmmc2_supply =
+static struct regulator_consumer_supply igep_vmmc2_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.1);
-static struct regulator_init_data igep2_vmmc2 = {
+static struct
[PATCH 2/4] omap: igep0020: minor refactoring
to allow easy addition of IGEP3
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-igep0020.c | 57 ++
1 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index ad20f7b..ea7cbc6 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -299,17 +299,14 @@ static struct omap2_hsmmc_info mmc[] = {
static struct gpio_led igep_gpio_leds[] = {
[0] = {
.name = gpio-led:red:d0,
- .gpio = IGEP2_GPIO_LED0_RED,
.default_trigger= default-off
},
[1] = {
.name = gpio-led:green:d0,
- .gpio = IGEP2_GPIO_LED0_GREEN,
.default_trigger= default-off,
},
[2] = {
.name = gpio-led:red:d1,
- .gpio = IGEP2_GPIO_LED1_RED,
.default_trigger= default-off,
},
[3] = {
@@ -335,6 +332,10 @@ static struct platform_device igep_led_device = {
static void __init igep_leds_init(void)
{
+ igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+
platform_device_register(igep_led_device);
}
@@ -347,14 +348,15 @@ static struct gpio igep_gpio_leds[] __initdata = {
static inline void igep_leds_init(void)
{
+ int i;
+
if (gpio_request_array(igep_gpio_leds, ARRAY_SIZE(igep_gpio_leds))) {
pr_warning(IGEP v2: Could not obtain leds gpios\n);
return;
}
- gpio_export(IGEP2_GPIO_LED0_RED, 0);
- gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
- gpio_export(IGEP2_GPIO_LED1_RED, 0);
+ for (i = 0; i ARRAY_SIZE(igep_gpio_leds); i++)
+ gpio_export(igep_gpio_leds[i].gpio, 0);
}
#endif
@@ -372,6 +374,18 @@ static int igep_twl_gpio_setup(struct device *dev,
mmc[0].gpio_cd = gpio + 0;
omap2_hsmmc_init(mmc);
+ /* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
+#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
+ ret = gpio_request_one(gpio + TWL4030_GPIO_MAX + 1, GPIOF_OUT_INIT_HIGH,
+ gpio-led:green:d1);
+ if (ret == 0)
+ gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
+ else
+ pr_warning(IGEP: Could not obtain gpio GPIO_LED1_GREEN\n);
+#else
+ igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
+#endif
+
/*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
@@ -385,18 +399,6 @@ static int igep_twl_gpio_setup(struct device *dev,
if (ret 0)
pr_err(IGEP2: Could not obtain gpio for USBH_CPEN);
- /* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
-#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
- ret = gpio_request_one(gpio + TWL4030_GPIO_MAX + 1, GPIOF_OUT_INIT_HIGH,
- gpio-led:green:d1);
- if (ret == 0)
- gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
- else
- pr_warning(IGEP: Could not obtain gpio GPIO_LED1_GREEN\n);
-#else
- igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
-#endif
-
return 0;
};
@@ -531,11 +533,8 @@ static struct twl4030_platform_data igep_twldata = {
/* platform_data for children goes here */
.usb= igep_usb_data,
- .codec = igep2_codec_data,
.gpio = igep_twl4030_gpio_pdata,
- .keypad = igep2_keypad_pdata,
.vmmc1 = igep_vmmc1,
- .vpll2 = igep2_vpll2,
.vio= igep_vio,
};
@@ -549,8 +548,6 @@ static void __init igep_i2c_init(void)
{
int ret;
- omap3_pmic_init(twl4030, igep_twldata);
-
/*
* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz
@@ -559,6 +556,12 @@ static void __init igep_i2c_init(void)
ARRAY_SIZE(igep2_i2c3_boardinfo));
if (ret)
pr_warning(IGEP2: Could not register I2C3 bus (%d)\n, ret);
+
+ igep_twldata.codec = igep2_codec_data;
+ igep_twldata.keypad = igep2_keypad_pdata;
+ igep_twldata.vpll2 = igep2_vpll2;
+
+ omap3_pmic_init(twl4030, igep_twldata);
}
static const struct usbhs_omap_board_data igep2_usbhs_bdata __initconst = {
@@ -630,15 +633,11 @@ static void __init igep_init(void)
/* Register I2C busses and drivers */
igep_i2c_init();
platform_add_devices(igep_devices, ARRAY_SIZE(igep_devices));
- omap_display_init(igep2_dss_data
[PATCH 3/4] omap: igep0020: add support for IGEP3
Add IGEP3 machine support to board-igep0020
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-igep0020.c | 103 ++
1 files changed, 80 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index ea7cbc6..0d6d583 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -55,6 +55,11 @@
#define IGEP2_RC_GPIO_WIFI_NRESET 139
#define IGEP2_RC_GPIO_BT_NRESET137
+#define IGEP3_GPIO_LED0_GREEN 54
+#define IGEP3_GPIO_LED0_RED53
+#define IGEP3_GPIO_LED1_RED16
+#define IGEP3_GPIO_USBH_NRESET 183
+
/*
* IGEP2 Hardware Revision Table
*
@@ -69,6 +74,7 @@
#define IGEP2_BOARD_HWREV_B0
#define IGEP2_BOARD_HWREV_C1
+#define IGEP3_BOARD_HWREV 2
static u8 hwrev;
@@ -76,6 +82,11 @@ static void __init igep2_get_revision(void)
{
u8 ret;
+ if (machine_is_igep0030()) {
+ hwrev = IGEP3_BOARD_HWREV;
+ return;
+ }
+
omap_mux_init_gpio(IGEP2_GPIO_LED1_RED, OMAP_PIN_INPUT);
if (gpio_request_one(IGEP2_GPIO_LED1_RED, GPIOF_IN, GPIO_HW0_REV)) {
@@ -332,24 +343,40 @@ static struct platform_device igep_led_device = {
static void __init igep_leds_init(void)
{
- igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
- igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
- igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+ if (machine_is_igep0020()) {
+ igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+ } else {
+ igep_gpio_leds[0].gpio = IGEP3_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP3_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP3_GPIO_LED1_RED;
+ }
platform_device_register(igep_led_device);
}
#else
static struct gpio igep_gpio_leds[] __initdata = {
- { IGEP2_GPIO_LED0_RED, GPIOF_OUT_INIT_LOW, gpio-led:red:d0 },
- { IGEP2_GPIO_LED0_GREEN, GPIOF_OUT_INIT_LOW, gpio-led:green:d0 },
- { IGEP2_GPIO_LED1_RED, GPIOF_OUT_INIT_LOW, gpio-led:red:d1 },
+ { -EINVAL, GPIOF_OUT_INIT_LOW, gpio-led:red:d0 },
+ { -EINVAL, GPIOF_OUT_INIT_LOW, gpio-led:green:d0 },
+ { -EINVAL, GPIOF_OUT_INIT_LOW, gpio-led:red:d1 },
};
static inline void igep_leds_init(void)
{
int i;
+ if (machine_is_igep0020()) {
+ igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+ } else {
+ igep_gpio_leds[0].gpio = IGEP3_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP3_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP3_GPIO_LED1_RED;
+ }
+
if (gpio_request_array(igep_gpio_leds, ARRAY_SIZE(igep_gpio_leds))) {
pr_warning(IGEP v2: Could not obtain leds gpios\n);
return;
@@ -386,6 +413,9 @@ static int igep_twl_gpio_setup(struct device *dev,
igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
#endif
+ if (machine_is_igep0030())
+ return 0;
+
/*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
@@ -548,18 +578,20 @@ static void __init igep_i2c_init(void)
{
int ret;
- /*
-* Bus 3 is attached to the DVI port where devices like the pico DLP
-* projector don't work reliably with 400kHz
-*/
- ret = omap_register_i2c_bus(3, 100, igep2_i2c3_boardinfo,
- ARRAY_SIZE(igep2_i2c3_boardinfo));
- if (ret)
- pr_warning(IGEP2: Could not register I2C3 bus (%d)\n, ret);
-
- igep_twldata.codec = igep2_codec_data;
- igep_twldata.keypad = igep2_keypad_pdata;
- igep_twldata.vpll2 = igep2_vpll2;
+ if (machine_is_igep0020()) {
+ /*
+* Bus 3 is attached to the DVI port where devices like the
+* pico DLP projector don't work reliably with 400kHz
+*/
+ ret = omap_register_i2c_bus(3, 100, igep2_i2c3_boardinfo,
+ ARRAY_SIZE(igep2_i2c3_boardinfo));
+ if (ret)
+ pr_warning(IGEP2: Could not register I2C3 bus (%d)\n,
ret);
+
+ igep_twldata.codec = igep2_codec_data;
+ igep_twldata.keypad = igep2_keypad_pdata;
+ igep_twldata.vpll2 = igep2_vpll2;
+ }
omap3_pmic_init(twl4030, igep_twldata);
}
@@ -575,6 +607,17 @@ static const struct usbhs_omap_board_data
igep2_usbhs_bdata __initconst = {
.reset_gpio_port[2] = -EINVAL,
};
+static const struct usbhs_omap_board_data
[PATCH 4/4] omap: drop board-igep0030.c
since it is merged into board-igep0020.c
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/Makefile |2 -
arch/arm/mach-omap2/board-igep0030.c | 438 --
3 files changed, 1 insertions(+), 440 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-igep0030.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..19d5891 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -288,6 +288,7 @@ config MACH_IGEP0030
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
+ select MACH_IGEP0020
config MACH_SBC3530
bool OMAP3 SBC STALKER board
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a0c2cae..186f482 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -229,8 +229,6 @@ obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
hsmmc.o
-obj-$(CONFIG_MACH_IGEP0030)+= board-igep0030.o \
- hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o \
diff --git a/arch/arm/mach-omap2/board-igep0030.c
b/arch/arm/mach-omap2/board-igep0030.c
deleted file mode 100644
index 83f6be2..000
--- a/arch/arm/mach-omap2/board-igep0030.c
+++ /dev/null
@@ -1,438 +0,0 @@
-/*
- * Copyright (C) 2010 - ISEE 2007 SL
- *
- * Modified from mach-omap2/board-generic.c
- *
- * 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.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/delay.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/gpio.h
-#include linux/interrupt.h
-
-#include linux/regulator/machine.h
-#include linux/regulator/fixed.h
-#include linux/i2c/twl.h
-#include linux/mmc/host.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-
-#include plat/board.h
-#include plat/common.h
-#include plat/gpmc.h
-#include plat/usb.h
-#include plat/onenand.h
-
-#include mux.h
-#include hsmmc.h
-#include sdram-numonyx-m65kam.h
-#include common-board-devices.h
-
-#define IGEP3_GPIO_LED0_GREEN 54
-#define IGEP3_GPIO_LED0_RED53
-#define IGEP3_GPIO_LED1_RED16
-
-#define IGEP3_GPIO_WIFI_NPD138
-#define IGEP3_GPIO_WIFI_NRESET 139
-#define IGEP3_GPIO_BT_NRESET 137
-
-#define IGEP3_GPIO_USBH_NRESET 183
-
-
-#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
- defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
-
-#define ONENAND_MAP 0x2000
-
-/*
- * x2 Flash built-in COMBO POP MEMORY
- * Since the device is equipped with two DataRAMs, and two-plane NAND
- * Flash memory array, these two component enables simultaneous program
- * of 4KiB. Plane1 has only even blocks such as block0, block2, block4
- * while Plane2 has only odd blocks such as block1, block3, block5.
- * So MTD regards it as 4KiB page size and 256KiB block size 64*(2*2048)
- */
-
-static struct mtd_partition igep3_onenand_partitions[] = {
- {
- .name = X-Loader,
- .offset = 0,
- .size = 2 * (64*(2*2048))
- },
- {
- .name = U-Boot,
- .offset = MTDPART_OFS_APPEND,
- .size = 6 * (64*(2*2048)),
- },
- {
- .name = Environment,
- .offset = MTDPART_OFS_APPEND,
- .size = 2 * (64*(2*2048)),
- },
- {
- .name = Kernel,
- .offset = MTDPART_OFS_APPEND,
- .size = 12 * (64*(2*2048)),
- },
- {
- .name = File System,
- .offset = MTDPART_OFS_APPEND,
- .size = MTDPART_SIZ_FULL,
- },
-};
-
-static struct omap_onenand_platform_data igep3_onenand_pdata = {
- .parts = igep3_onenand_partitions,
- .nr_parts = ARRAY_SIZE(igep3_onenand_partitions),
- .onenand_setup = NULL,
- .dma_channel= -1, /* disable DMA in OMAP OneNAND driver */
-};
-
-static struct platform_device igep3_onenand_device = {
- .name = omap2-onenand,
- .id = -1,
- .dev = {
- .platform_data = igep3_onenand_pdata,
- },
-};
-
-static void __init igep3_flash_init(void)
-{
- u8 cs = 0;
- u8 onenandcs = GPMC_CS_NUM + 1;
-
- for (cs = 0; cs GPMC_CS_NUM; cs++) {
- u32
[PATCH v2] omap: fix build when MTD_NAND_OMAP2 and TOUCHSCREEN_ADS7846 are disabled
Commits 5e6a64b36ce346b7a2d481ef9fa315290eb28e5e (omap: move detection of
NAND CS to common-board-devices) and 96974a249b0cf3537f49115a59be67e2c54f315c
(omap: consolidate touch screen initialization among different boards)
break compilation when CONFIG_MTD_NAND_OMAP2 and
CONFIG_TOUCHSCREEN_ADS7846 are not selected.
Removing ifdefs and stubs from common-board-devices.h fixes the problem.
Signed-off-by: Mike Rapoport m...@compulab.co.il
CC: Oleg Drokin gr...@linuxhacker.ru
---
Hope this one is better.
arch/arm/mach-omap2/common-board-devices.c | 15 +++
arch/arm/mach-omap2/common-board-devices.h | 17 -
2 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/common-board-devices.c
b/arch/arm/mach-omap2/common-board-devices.c
index d57c71d..e94903b 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -50,6 +50,8 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, pmic_i2c_board_info, 1);
}
+#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
+ defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
static struct omap2_mcspi_device_config ads7846_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,/* 0: slave, 1: master */
@@ -105,7 +107,14 @@ void __init omap_ads7846_init(int bus_num, int
gpio_pendown, int gpio_debounce,
spi_register_board_info(ads7846_spi_board_info, 1);
}
+#else
+void __init omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
+ struct ads7846_platform_data *board_pdata)
+{
+}
+#endif
+#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
static struct omap_nand_platform_data nand_data = {
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
};
@@ -146,3 +155,9 @@ void __init omap_nand_flash_init(int options, struct
mtd_partition *parts,
printk(KERN_ERR Unable to register NAND device\n);
}
}
+#else
+void __init omap_nand_flash_init(int options, struct mtd_partition *parts,
+int nr_parts)
+{
+}
+#endif
diff --git a/arch/arm/mach-omap2/common-board-devices.h
b/arch/arm/mach-omap2/common-board-devices.h
index ca03abf..eb80b3b 100644
--- a/arch/arm/mach-omap2/common-board-devices.h
+++ b/arch/arm/mach-omap2/common-board-devices.h
@@ -26,27 +26,10 @@ static inline void omap4_pmic_init(const char *pmic_type,
omap_pmic_init(1, 400, pmic_type, OMAP44XX_IRQ_SYS_1N, pmic_data);
}
-#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
- defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
struct ads7846_platform_data;
void omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
struct ads7846_platform_data *board_pdata);
-#else
-static inline void omap_ads7846_init(int bus_num,
-int gpio_pendown, int gpio_debounce,
-struct ads7846_platform_data *board_data)
-{
-}
-#endif
-
-#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
void omap_nand_flash_init(int opts, struct mtd_partition *parts, int n_parts);
-#else
-static inline void omap_nand_flash_init(int opts, struct mtd_partition *parts,
- int nr_parts)
-{
-}
-#endif
#endif /* __OMAP_COMMON_BOARD_DEVICES__ */
--
1.7.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: cm-t35: add support for cm-t3730
On 05/05/11 11:53, Igor Grinberg wrote:
cm-t3730 is basically the same board as cm-t35, but has DM3730 SoC
assembled and therefore some changes are required.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig|2 +-
arch/arm/mach-omap2/board-cm-t35.c | 62
+++-
2 files changed, 48 insertions(+), 16 deletions(-)
Acked-by: Mike Rapoport m...@compulab.co.il
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..920b6bc 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -266,7 +266,7 @@ config MACH_OMAP_ZOOM3
select REGULATOR_FIXED_VOLTAGE
config MACH_CM_T35
- bool CompuLab CM-T35 module
+ bool CompuLab CM-T35/CM-T3730 modules
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CUS
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 6063be8..c0f6ce0 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -524,7 +524,7 @@ static void __init cm_t35_init_early(void)
}
#ifdef CONFIG_OMAP_MUX
-static struct omap_board_mux board_mux[] __initdata = {
+static struct omap_board_mux cm_t35_common_board_mux[] __initdata = {
/* nCS and IRQ for CM-T35 ethernet */
OMAP3_MUX(GPMC_NCS5, OMAP_MUX_MODE0),
OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
@@ -580,17 +580,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
- /* DSS */
+ /* common DSS */
OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
OMAP3_MUX(DSS_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA8, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
@@ -603,12 +598,6 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(DSS_DATA15, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA16, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA17, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA20, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA21, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
- OMAP3_MUX(DSS_DATA23, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
/* display controls */
OMAP3_MUX(MCBSP1_FSR, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
@@ -621,6 +610,39 @@ static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static void cm_t35_mux_init(void)
+{
+ int mux_mode = OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT;
+
+ omap3_mux_init(cm_t35_common_board_mux, OMAP_PACKAGE_CUS);
+
+ if (cpu_is_omap34xx()) {
+ omap_mux_init_signal(gpio_70, mux_mode);
+ omap_mux_init_signal(gpio_71, mux_mode);
+ omap_mux_init_signal(gpio_72, mux_mode);
+ omap_mux_init_signal(gpio_73, mux_mode);
+ omap_mux_init_signal(gpio_74, mux_mode);
+ omap_mux_init_signal(gpio_75, mux_mode);
+ } else if (cpu_is_omap3630()) {
+ mux_mode = OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT;
+ omap_mux_init_signal(sys_boot0, mux_mode);
+ omap_mux_init_signal(sys_boot1, mux_mode);
+ omap_mux_init_signal(sys_boot3, mux_mode);
+ omap_mux_init_signal(sys_boot4, mux_mode);
+ omap_mux_init_signal(sys_boot5, mux_mode);
+ omap_mux_init_signal(sys_boot6, mux_mode);
+ }
+
+ omap_mux_init_signal(dss_data18, mux_mode);
+ omap_mux_init_signal(dss_data19, mux_mode);
+ omap_mux_init_signal(dss_data20, mux_mode);
+ omap_mux_init_signal(dss_data21, mux_mode);
+ omap_mux_init_signal(dss_data22, mux_mode);
+ omap_mux_init_signal(dss_data23, mux_mode);
+}
+#else
+static inline void cm_t35_mux_init(void) {}
#endif
static struct omap_board_config_kernel cm_t35_config[] __initdata = {
@@ -630,7 +652,7 @@ static void __init cm_t35_init(void)
{
omap_board_config = cm_t35_config
Re: [PATCH 3/4] omap: move detection of NAND CS to common-board-devices
On 05/04/11 07:10, Oleg Drokin wrote: Ok, so here's a simple patch to save everyone trouble, I guess. Though on the other hand I can imagine that perhaps including this generic common-board-devices.c might not be desirable for people that don't use anything from that file. Since the common-board-devices.c has TWL initialization I doubt there would a board that does not use it at all... Would it be a better idea to split it to a file-per-feature? Splitting the common-board-devices into a file-per-feature will diminish its added value, IMO. We can either continue to use #ifdef CONFIG_SOMETHING in both common-board-devices.[ch] as your fix proposes or just drop #ifdefs and inlines from the header. Tony, what is your preference? -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] omap: move detection of NAND CS to common-board-devices
On 05/04/11 09:46, Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [110504 09:35]:
On 05/04/11 07:10, Oleg Drokin wrote:
Ok, so here's a simple patch to save everyone trouble, I guess.
Though on the other hand I can imagine that perhaps including this generic
common-board-devices.c
might not be desirable for people that don't use anything from that file.
Since the common-board-devices.c has TWL initialization I doubt there would a
board that does not use it at all...
Would it be a better idea to split it to a file-per-feature?
Splitting the common-board-devices into a file-per-feature will diminish its
added value, IMO.
We can either continue to use #ifdef CONFIG_SOMETHING in both
common-board-devices.[ch] as your fix proposes or just drop #ifdefs and
inlines
from the header.
Tony, what is your preference?
We should consider the code size too.. Maybe see if you can make them
weak instead of the ifdefs?
Unless I completely misunderstand how weak works, we'll still have ifdefs in .c
file, i.e.
common-board-devices.h:
void __omap_nand_flash_init(int opts, struct mtd_partition *parts, int n_parts)
{
}
void omap_nand_flash_init(int opts, struct mtd_partition *parts, int n_parts)
__attribute__((weak, alias(__omap_nand_flash_init)));
common-board-devices.c:
#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
void omap_nand_flash_init(int opts, struct mtd_partition *parts, int n_parts)
{
...
}
#endif
Yet, we can keep the ifdefs only in common-board-devices.c and get rid if
inlines in the header.
Also, all the code in common-board-devices.c is __init, so it's eventually
dropped in runtime
Tony
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: fix build when MTD_NAND_OMAP2 and TOUCHSCREEN_ADS7846 are disabled
Commits 5e6a64b36ce346b7a2d481ef9fa315290eb28e5e (omap: move detection of
NAND CS to common-board-devices) and 96974a249b0cf3537f49115a59be67e2c54f315c
(omap: consolidate touch screen initialization among different boards)
break compilation when CONFIG_MTD_NAND_OMAP2 and
CONFIG_TOUCHSCREEN_ADS7846 are not selected.
Removing ifdefs and stubs from common-board-devices.h fixes the problem.
Signed-off-by: Mike Rapoport m...@compulab.co.il
CC: Oleg Drokin gr...@linuxhacker.ru
---
17 more lines are gone ;-)
arch/arm/mach-omap2/common-board-devices.h | 17 -
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/common-board-devices.h
b/arch/arm/mach-omap2/common-board-devices.h
index ca03abf..eb80b3b 100644
--- a/arch/arm/mach-omap2/common-board-devices.h
+++ b/arch/arm/mach-omap2/common-board-devices.h
@@ -26,27 +26,10 @@ static inline void omap4_pmic_init(const char *pmic_type,
omap_pmic_init(1, 400, pmic_type, OMAP44XX_IRQ_SYS_1N, pmic_data);
}
-#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
- defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
struct ads7846_platform_data;
void omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
struct ads7846_platform_data *board_pdata);
-#else
-static inline void omap_ads7846_init(int bus_num,
-int gpio_pendown, int gpio_debounce,
-struct ads7846_platform_data *board_data)
-{
-}
-#endif
-
-#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
void omap_nand_flash_init(int opts, struct mtd_partition *parts, int n_parts);
-#else
-static inline void omap_nand_flash_init(int opts, struct mtd_partition *parts,
- int nr_parts)
-{
-}
-#endif
#endif /* __OMAP_COMMON_BOARD_DEVICES__ */
--
1.7.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] omap: cleanup board files
ping? On Mon, Apr 25, 2011 at 1:09 PM, Mike Rapoport m...@compulab.co.il wrote: Hi Tony, These patches cleanup some of the common code in the board files. The changes are basically almost mechanically move the code shared among several boards into some common place. There are a lot of places for further improvement, especially DSS and TWL initialization. I'll try to find some time to sort these out as well. Special thanks to Igor Grinberg for the original idea :) Mike Rapoport (4): omap: consolidate touch screen initialization among different boards omap: use common initialization for PMIC i2c bus omap: move detection of NAND CS to common-board-devices omap: musb: introduce default baord config arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/board-2430sdp.c | 20 +--- arch/arm/mach-omap2/board-3430sdp.c | 85 ++- arch/arm/mach-omap2/board-4430sdp.c | 16 +--- arch/arm/mach-omap2/board-cm-t35.c | 78 +- arch/arm/mach-omap2/board-devkit8000.c | 119 + arch/arm/mach-omap2/board-igep0020.c | 23 + arch/arm/mach-omap2/board-igep0030.c | 21 +--- arch/arm/mach-omap2/board-ldp.c | 77 +- arch/arm/mach-omap2/board-omap3beagle.c | 66 +--- arch/arm/mach-omap2/board-omap3evm.c | 72 + arch/arm/mach-omap2/board-omap3logic.c | 13 +-- arch/arm/mach-omap2/board-omap3pandora.c | 69 +--- arch/arm/mach-omap2/board-omap3stalker.c | 78 +- arch/arm/mach-omap2/board-omap3touchbook.c | 101 ++ arch/arm/mach-omap2/board-omap4panda.c | 17 +--- arch/arm/mach-omap2/board-overo.c | 108 +-- arch/arm/mach-omap2/board-rm680.c | 21 +--- arch/arm/mach-omap2/board-rx51-peripherals.c | 13 +-- arch/arm/mach-omap2/board-zoom-peripherals.c | 21 +--- arch/arm/mach-omap2/common-board-devices.c | 148 ++ arch/arm/mach-omap2/common-board-devices.h | 52 + arch/arm/mach-omap2/usb-musb.c | 14 +++- 23 files changed, 293 insertions(+), 941 deletions(-) create mode 100644 arch/arm/mach-omap2/common-board-devices.c create mode 100644 arch/arm/mach-omap2/common-board-devices.h -- 1.7.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add basic devices support for Nook Color
(adding Felipe to cc)
Felipe, can you comment on the mUSB part, please?
On 04/27/11 19:12, Oleg Drokin wrote:
Hello!
Thanks for the feedback.
On Apr 27, 2011, at 4:49 AM, Mike Rapoport wrote:
MMC/SD interface, i2c, usb.
You should have added these at the first patch instead of Android devices.
So, basically you want all board file changes to come as a single patch,
right?
I would split you series into three patches:
1) TWL updates
2) addition of board-encore
3) defconfig updates
The patch that adds board-encore would include MMC, i2c and mUSB.
---
arch/arm/configs/encore-nookcolor-defconfig | 2015
+++
The defconfig should be a separate patch. You should rather add encore board
options to omap2plus_defconfig.
Hm, ok.
+static struct i2c_board_info __initdata encore_i2c_bus2_info[] = {
+};
+
+
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
This kind of ifdefery is handled inside the musb driver. I'd set the mode to
MUSB_OTG unless you want to explicitly limit it to HOST or PERIPHERAL
Actually it's not.
If I set MUSB_OTG here and then I choose PERIPHERAL mode in the kernel config,
the musb transceiver code will complain about board file and kernel config
mismatch.
The Nook Color is advertised as peripheral device, but OTG must be working too
(not totally working at this point) I think there is value to be able to
configure it
in two different modes.
Frankly, I haven't tried choosing different modes in the kernel config and in
the board data. Still, I believe that board data should define desired operation
mode and the driver should do the best effort to enable the controller in the
desired mode.
Bye,
Oleg
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omap: musb: introduce default baord config
On 04/27/11 07:23, Oleg Drokin wrote:
Hello!
On Apr 24, 2011, at 6:09 PM, Mike Rapoport wrote:
-void __init usb_musb_init(struct omap_musb_board_data *board_data)
+static struct omap_musb_board_data musb_default_board_data = {
+.interface_type = MUSB_INTERFACE_ULPI,
+.mode = MUSB_OTG,
In fact can you make it more generic with ifdefs like this?
(since there are tons of boards taht are client only or would like to be
compiled in some other way):
I didn't want to change current functionality. The purpose of this patch is to
reduce amount of code shared among board files.
If certain board needs mode other than OTG it can still pass musb_board_data.
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
+.power = 100,
+};
+
Thanks!
Bye,
Oleg
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add basic devices support for Nook Color
On 04/27/11 04:52, gr...@linuxhacker.ru wrote:
From: Oleg Drokin gr...@linuxhacker.ru
MMC/SD interface, i2c, usb.
You should have added these at the first patch instead of Android devices.
---
arch/arm/configs/encore-nookcolor-defconfig | 2015
+++
The defconfig should be a separate patch. You should rather add encore board
options to omap2plus_defconfig.
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3encore.c | 325 +-
drivers/mfd/twl-core.c |6 +
The TWL updates should be in a separate patch
4 files changed, 2343 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/configs/encore-nookcolor-defconfig
[ snip ]
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 207f372..b894777 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -189,7 +189,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
hsmmc.o
-obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
+obj-$(CONFIG_MACH_ENCORE)+= board-omap3encore.o \
+hsmmc.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
diff --git a/arch/arm/mach-omap2/board-omap3encore.c
b/arch/arm/mach-omap2/board-omap3encore.c
index 9a00d6b..055549b 100644
--- a/arch/arm/mach-omap2/board-omap3encore.c
+++ b/arch/arm/mach-omap2/board-omap3encore.c
@@ -24,6 +24,7 @@
#include linux/clk.h
#include linux/spi/spi.h
+#include linux/i2c/twl.h
#include linux/interrupt.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
@@ -33,6 +34,7 @@
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include linux/mmc/host.h
#include plat/mcspi.h
#include mach/gpio.h
@@ -48,21 +50,80 @@
#include plat/sram.h
#include plat/display.h
+#include plat/mmc.h
#include plat/omap-serial.h
#include plat/system.h
#include mux.h
+#include hsmmc.h
#include prcm-common.h
#include sdram-hynix-h8mbx00u0mer-0em.h
#include media/v4l2-int-device.h
+#ifndef CONFIG_TWL4030_CORE
+#error no power companion board defined!
+#endif
+
Board should boot even when CONFIG_TWL4030_CORE is not defined, so drop it.
#ifdef CONFIG_ANDROID_RAM_CONSOLE
#include linux/bootmem.h
#endif
+static int encore_twl4030_keymap[] = {
+ KEY(0, 0, KEY_HOME),
+ KEY(0, 1, KEY_VOLUMEUP),
+ KEY(0, 2, KEY_VOLUMEDOWN),
+ 0
+};
+
+static struct matrix_keymap_data encore_twl4030_keymap_data = {
+ .keymap = encore_twl4030_keymap,
+ .keymap_size= ARRAY_SIZE(encore_twl4030_keymap),
+};
+
+static struct twl4030_keypad_data encore_kp_twl4030_data = {
+ .rows = 8,
+ .cols = 8,
+ .keymap_data= encore_twl4030_keymap_data,
+ .rep= 1,
+};
+
+// HOME key code for HW EVT2A
no C++ comments
+static struct gpio_keys_button encore_gpio_buttons[] = {
+ {
+ .code = KEY_POWER,
+ .gpio = 14,
+ .desc = POWER,
+ .active_low = 0,
+ .wakeup = 1,
+ },
+ {
+ .code = KEY_HOME,
+ .gpio = 48,
+ .desc = HOME,
+ .active_low = 1,
+ .wakeup = 1,
+ },
+};
+
+static struct gpio_keys_platform_data encore_gpio_key_info = {
+ .buttons= encore_gpio_buttons,
+ .nbuttons = ARRAY_SIZE(encore_gpio_buttons),
+// .rep= 1,/* auto-repeat */
ditto
+};
+
+static struct platform_device encore_keys_gpio = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = encore_gpio_key_info,
+ },
+};
+
+#define t2_out(c, r, v) twl_i2c_write_u8(c, r, v)
why is t2_out needed here?
+
/* Use address that is most likely unused and untouched by u-boot */
#define ENCORE_RAM_CONSOLE_START 0x8e00
#define ENCORE_RAM_CONSOLE_SIZE (0x2)
@@ -84,20 +145,262 @@ static struct platform_device encore_ram_console_device
= {
static struct platform_device *encore_devices[] __initdata = {
encore_ram_console_device,
+ encore_keys_gpio,
};
static void __init omap_encore_init_early(void)
{
-printk(in early ini\n);
omap2_init_common_infrastructure();
omap2_init_common_devices(h8mbx00u0mer0em_sdrc_params,
Re: [PATCH 1/2] Initial BN Nook Color (Encore) support
On 04/27/11 04:52, gr...@linuxhacker.ru wrote:
From: Oleg Drokin gr...@linuxhacker.ru
Just bare-bones board file that has only serial console working.
---
arch/arm/mach-omap2/Kconfig|5 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3encore.c| 152
arch/arm/plat-omap/include/plat/board-encore.h | 76
arch/arm/plat-omap/include/plat/uncompress.h |1 +
arch/arm/tools/mach-types |2 +-
6 files changed, 236 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3encore.c
create mode 100644 arch/arm/plat-omap/include/plat/board-encore.h
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..5370561 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO
for full description please see the products webpage at
http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit
+config MACH_ENCORE
+bool Barnes Noble Encore (Nook Color)
+depends on ARCH_OMAP3
+select OMAP_PACKAGE_CBP
+
config MACH_OVERO
bool Gumstix Overo board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..207f372 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -189,6 +189,7 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
hsmmc.o
+obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
diff --git a/arch/arm/mach-omap2/board-omap3encore.c
b/arch/arm/mach-omap2/board-omap3encore.c
new file mode 100644
index 000..9a00d6b
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3encore.c
@@ -0,0 +1,152 @@
+/*
+ *
+ * Copyright (C) 2008 Texas Instruments Inc.
+ * Vikram Pandita vikram.pand...@ti.com
+ *
+ * Modified from mach-omap2/board-ldp.c
+ *
+ * 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.
+ *
+ * Apri 2011 Oleg Drokin gr...@linuxhacker.ru - Port to 2.6.39
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/input.h
+#include linux/gpio_keys.h
+#include linux/workqueue.h
+#include linux/err.h
+#include linux/clk.h
+
+#include linux/spi/spi.h
+#include linux/interrupt.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/dma-mapping.h
+#include plat/board-encore.h
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/mcspi.h
+#include mach/gpio.h
+#include plat/board.h
+#include plat/common.h
+#include plat/gpmc.h
+#include plat/usb.h
+#include plat/mux.h
+
+#include asm/system.h // For system_serial_high system_serial_low
No C++ comments, please.
+#include asm/io.h
+#include asm/delay.h
+#include plat/sram.h
+
+#include plat/display.h
+#include plat/omap-serial.h
+
+#include plat/system.h
+
+#include mux.h
+#include prcm-common.h
+
+#include sdram-hynix-h8mbx00u0mer-0em.h
+
+#include media/v4l2-int-device.h
Please check what header files are actually required and drop the rest...
+#ifdef CONFIG_ANDROID_RAM_CONSOLE
+#include linux/bootmem.h
+#endif
AFAIK, there's no CONFIG_ANDROID_ in the kernel
+/* Use address that is most likely unused and untouched by u-boot */
+#define ENCORE_RAM_CONSOLE_START 0x8e00
+#define ENCORE_RAM_CONSOLE_SIZE (0x2)
+
+static struct resource encore_ram_console_resource[] = {
+{
+.start = ENCORE_RAM_CONSOLE_START,
+.end= ENCORE_RAM_CONSOLE_START + ENCORE_RAM_CONSOLE_SIZE - 1,
+.flags = IORESOURCE_MEM,
+}
+};
+
+static struct platform_device encore_ram_console_device = {
+.name = ram_console,
+.id = 0,
+.num_resources = ARRAY_SIZE(encore_ram_console_resource),
+.resource = encore_ram_console_resource,
+};
and there's no ram_console driver as well.
I don't think it'd make sense to register ram_console device at all.
+static struct platform_device *encore_devices[] __initdata = {
+ encore_ram_console_device,
+};
+
+static void __init omap_encore_init_early(void)
+{
+printk(in early ini\n);
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(h8mbx00u0mer0em_sdrc_params,
+
[PATCH v2 4/4] omap: musb: introduce default board config
Most boards use exactly the same configuration for musb initialization.
Create a default that can be shared amount different boards.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
Fixed spelling in $SUBJ, thanks to Felipe Contreras
arch/arm/mach-omap2/board-2430sdp.c |7 +--
arch/arm/mach-omap2/board-3430sdp.c |8 +---
arch/arm/mach-omap2/board-cm-t35.c |8 +---
arch/arm/mach-omap2/board-devkit8000.c |8 +---
arch/arm/mach-omap2/board-igep0020.c |8 +---
arch/arm/mach-omap2/board-igep0030.c |8 +---
arch/arm/mach-omap2/board-ldp.c |8 +---
arch/arm/mach-omap2/board-omap3beagle.c |8 +---
arch/arm/mach-omap2/board-omap3pandora.c |8 +---
arch/arm/mach-omap2/board-omap3stalker.c |8 +---
arch/arm/mach-omap2/board-omap3touchbook.c |8 +---
arch/arm/mach-omap2/board-overo.c|8 +---
arch/arm/mach-omap2/board-rm680.c|8 +---
arch/arm/mach-omap2/board-zoom-peripherals.c |8 +---
arch/arm/mach-omap2/usb-musb.c | 14 +-
15 files changed, 27 insertions(+), 98 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 99b3f2d..a8810f8 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -208,11 +208,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
static struct omap_usb_config sdp2430_usb_config __initdata = {
.otg= 1,
#ifdef CONFIG_USB_GADGET_OMAP
@@ -246,7 +241,7 @@ static void __init omap_2430sdp_init(void)
omap2_usbfs_init(sdp2430_usb_config);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP);
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index b12400e..951e585 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -810,12 +810,6 @@ static struct flash_partitions sdp_flash_partitions[] = {
},
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static void __init omap_3430sdp_init(void)
{
int gpio_pendown;
@@ -832,7 +826,7 @@ static void __init omap_3430sdp_init(void)
gpio_pendown = SDP3430_TS_GPIO_IRQ_SDPV1;
omap_ads7846_init(1, gpio_pendown, 310, NULL);
board_serial_init();
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 1a9e6be..286da17 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -651,12 +651,6 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static struct omap_board_config_kernel cm_t35_config[] __initdata = {
};
@@ -673,7 +667,7 @@ static void __init cm_t35_init(void)
cm_t35_init_led();
cm_t35_init_display();
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index e7dc057..405542a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -509,12 +509,6 @@ static struct platform_device *devkit8000_devices[]
__initdata = {
omap_dm9000_dev,
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
@@ -698,7 +692,7 @@ static void __init devkit8000_init(void)
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
ARRAY_SIZE(devkit8000_nand_partitions));
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b
[PATCH 1/4] omap: consolidate touch screen initialization among different boards
Add common-board-devices.c that will contain the code for peripheral
devices initializatoin shared between multiple boards.
Start small with touchscreen initialization.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-3430sdp.c| 65 ++---
arch/arm/mach-omap2/board-cm-t35.c | 58 +--
arch/arm/mach-omap2/board-devkit8000.c | 56 +--
arch/arm/mach-omap2/board-ldp.c| 57 +--
arch/arm/mach-omap2/board-omap3evm.c | 51 +
arch/arm/mach-omap2/board-omap3pandora.c | 49 +---
arch/arm/mach-omap2/board-omap3stalker.c | 49 +---
arch/arm/mach-omap2/board-omap3touchbook.c | 36 +---
arch/arm/mach-omap2/board-overo.c | 46 +--
arch/arm/mach-omap2/common-board-devices.c | 85
arch/arm/mach-omap2/common-board-devices.h | 18 ++
12 files changed, 128 insertions(+), 444 deletions(-)
create mode 100644 arch/arm/mach-omap2/common-board-devices.c
create mode 100644 arch/arm/mach-omap2/common-board-devices.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..43c5c22 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -270,3 +270,5 @@ obj-$(CONFIG_ARCH_OMAP4)+= hwspinlock.o
disp-$(CONFIG_OMAP2_DSS) := display.o
obj-y += $(disp-m) $(disp-y)
+
+obj-y += common-board-devices.o
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 9afd087..3726465 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -19,7 +19,6 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
-#include linux/spi/ads7846.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include linux/io.h
@@ -48,6 +47,7 @@
#include hsmmc.h
#include pm.h
#include control.h
+#include common-board-devices.h
#define CONFIG_DISABLE_HFCLK 1
@@ -123,58 +123,6 @@ static struct twl4030_keypad_data sdp3430_kp_data = {
.rep= 1,
};
-static int ts_gpio;/* Needed for ads7846_get_pendown_state */
-
-/**
- * @brief ads7846_dev_init : Requests sets GPIO line for pen-irq
- *
- * @return - void. If request gpio fails then Flag KERN_ERR.
- */
-static void ads7846_dev_init(void)
-{
- if (gpio_request(ts_gpio, ADS7846 pendown) 0) {
- printk(KERN_ERR can't get ads746 pen down GPIO\n);
- return;
- }
-
- gpio_direction_input(ts_gpio);
- gpio_set_debounce(ts_gpio, 310);
-}
-
-static int ads7846_get_pendown_state(void)
-{
- return !gpio_get_value(ts_gpio);
-}
-
-static struct ads7846_platform_data tsc2046_config __initdata = {
- .get_pendown_state = ads7846_get_pendown_state,
- .keep_vref_on = 1,
- .wakeup = true,
-};
-
-
-static struct omap2_mcspi_device_config tsc2046_mcspi_config = {
- .turbo_mode = 0,
- .single_channel = 1,/* 0: slave, 1: master */
-};
-
-static struct spi_board_info sdp3430_spi_board_info[] __initdata = {
- [0] = {
- /*
-* TSC2046 operates at a max freqency of 2MHz, so
-* operate slightly below at 1.5MHz
-*/
- .modalias = ads7846,
- .bus_num= 1,
- .chip_select= 0,
- .max_speed_hz = 150,
- .controller_data= tsc2046_mcspi_config,
- .irq= 0,
- .platform_data = tsc2046_config,
- },
-};
-
-
#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
@@ -880,6 +828,8 @@ static struct omap_musb_board_data musb_board_data = {
static void __init omap_3430sdp_init(void)
{
+ int gpio_pendown;
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
@@ -887,13 +837,10 @@ static void __init omap_3430sdp_init(void)
omap3430_i2c_init();
omap_display_init(sdp3430_dss_data);
if (omap_rev() OMAP3430_REV_ES1_0)
- ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
+ gpio_pendown = SDP3430_TS_GPIO_IRQ_SDPV2;
else
- ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV1;
- sdp3430_spi_board_info[0].irq = gpio_to_irq(ts_gpio);
- spi_register_board_info(sdp3430_spi_board_info,
- ARRAY_SIZE(sdp3430_spi_board_info));
- ads7846_dev_init();
+ gpio_pendown = SDP3430_TS_GPIO_IRQ_SDPV1;
+ omap_ads7846_init(1, gpio_pendown
[PATCH 3/4] omap: move detection of NAND CS to common-board-devices
and reduce amount of copy/paste
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-devkit8000.c | 43 +-
arch/arm/mach-omap2/board-omap3beagle.c| 45 +--
arch/arm/mach-omap2/board-omap3touchbook.c | 45 +--
arch/arm/mach-omap2/board-overo.c | 42 +
arch/arm/mach-omap2/common-board-devices.c | 42 ++
arch/arm/mach-omap2/common-board-devices.h | 10 ++
6 files changed, 60 insertions(+), 167 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 983f44b..e7dc057 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -97,13 +97,6 @@ static struct mtd_partition devkit8000_nand_partitions[] = {
},
};
-static struct omap_nand_platform_data devkit8000_nand_data = {
- .options= NAND_BUSWIDTH_16,
- .parts = devkit8000_nand_partitions,
- .nr_parts = ARRAY_SIZE(devkit8000_nand_partitions),
- .dma_channel= -1, /* disable DMA in OMAP NAND driver */
-};
-
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -516,39 +509,6 @@ static struct platform_device *devkit8000_devices[]
__initdata = {
omap_dm9000_dev,
};
-static void __init devkit8000_flash_init(void)
-{
- 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) {
- devkit8000_nand_data.cs = nandcs;
-
- printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
- if (gpmc_nand_init(devkit8000_nand_data) 0)
- printk(KERN_ERR Unable to register NAND device\n);
- }
-}
-
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
@@ -740,7 +700,8 @@ static void __init devkit8000_init(void)
usb_musb_init(musb_board_data);
usbhs_init(usbhs_bdata);
- devkit8000_flash_init();
+ omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
+ARRAY_SIZE(devkit8000_nand_partitions));
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 13a1664..ce3bc2d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -174,15 +174,6 @@ static struct mtd_partition omap3beagle_nand_partitions[]
= {
},
};
-static struct omap_nand_platform_data omap3beagle_nand_data = {
- .options= NAND_BUSWIDTH_16,
- .parts = omap3beagle_nand_partitions,
- .nr_parts = ARRAY_SIZE(omap3beagle_nand_partitions),
- .dma_channel= -1, /* disable DMA in OMAP NAND driver */
- .nand_setup = NULL,
- .dev_ready = NULL,
-};
-
/* DSS */
static int beagle_enable_dvi(struct omap_dss_device *dssdev)
@@ -542,39 +533,6 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
keys_gpio,
};
-static void __init omap3beagle_flash_init(void)
-{
- 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) {
- omap3beagle_nand_data.cs = nandcs;
-
- printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
- if (gpmc_nand_init(omap3beagle_nand_data) 0)
- printk(KERN_ERR Unable to register NAND device\n
[PATCH 2/4] omap: use common initialization for PMIC i2c bus
Introduce omap_pmic_init that registers i2c bus and PMIC device on that
bus and add omap2/3/4 wrappers for common cases.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-2430sdp.c | 13 ++---
arch/arm/mach-omap2/board-3430sdp.c | 12 +---
arch/arm/mach-omap2/board-4430sdp.c | 16 ++--
arch/arm/mach-omap2/board-cm-t35.c | 12 +---
arch/arm/mach-omap2/board-devkit8000.c | 12 +---
arch/arm/mach-omap2/board-igep0020.c | 15 ++-
arch/arm/mach-omap2/board-igep0030.c | 13 ++---
arch/arm/mach-omap2/board-ldp.c | 12 +---
arch/arm/mach-omap2/board-omap3beagle.c | 13 ++---
arch/arm/mach-omap2/board-omap3evm.c | 21 +++--
arch/arm/mach-omap2/board-omap3logic.c | 13 ++---
arch/arm/mach-omap2/board-omap3pandora.c | 12 +---
arch/arm/mach-omap2/board-omap3stalker.c | 21 +++--
arch/arm/mach-omap2/board-omap3touchbook.c | 12 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 ++---
arch/arm/mach-omap2/board-overo.c| 12 +---
arch/arm/mach-omap2/board-rm680.c| 13 ++---
arch/arm/mach-omap2/board-rx51-peripherals.c | 13 ++---
arch/arm/mach-omap2/board-zoom-peripherals.c | 13 ++---
arch/arm/mach-omap2/common-board-devices.c | 21 +
arch/arm/mach-omap2/common-board-devices.h | 24
21 files changed, 78 insertions(+), 232 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 1fa6bb8..99b3f2d 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -41,6 +41,7 @@
#include mux.h
#include hsmmc.h
+#include common-board-devices.h
#define SDP2430_CS0_BASE 0x0400
#define SECONDARY_LCD_GPIO 147
@@ -180,15 +181,6 @@ static struct twl4030_platform_data sdp2430_twldata = {
.vmmc1 = sdp2430_vmmc1,
};
-static struct i2c_board_info __initdata sdp2430_i2c_boardinfo[] = {
- {
- I2C_BOARD_INFO(twl4030, 0x48),
- .flags = I2C_CLIENT_WAKE,
- .irq = INT_24XX_SYS_NIRQ,
- .platform_data = sdp2430_twldata,
- },
-};
-
static struct i2c_board_info __initdata sdp2430_i2c1_boardinfo[] = {
{
I2C_BOARD_INFO(isp1301_omap, 0x2D),
@@ -201,8 +193,7 @@ static int __init omap2430_i2c_init(void)
{
omap_register_i2c_bus(1, 100, sdp2430_i2c1_boardinfo,
ARRAY_SIZE(sdp2430_i2c1_boardinfo));
- omap_register_i2c_bus(2, 2600, sdp2430_i2c_boardinfo,
- ARRAY_SIZE(sdp2430_i2c_boardinfo));
+ omap2_pmic_init(twl4030, sdp2430_twldata);
return 0;
}
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 3726465..b12400e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -528,20 +528,10 @@ static struct twl4030_platform_data sdp3430_twldata = {
.vpll2 = sdp3430_vpll2,
};
-static struct i2c_board_info __initdata sdp3430_i2c_boardinfo[] = {
- {
- I2C_BOARD_INFO(twl4030, 0x48),
- .flags = I2C_CLIENT_WAKE,
- .irq = INT_34XX_SYS_NIRQ,
- .platform_data = sdp3430_twldata,
- },
-};
-
static int __init omap3430_i2c_init(void)
{
/* i2c1 for PMIC only */
- omap_register_i2c_bus(1, 2600, sdp3430_i2c_boardinfo,
- ARRAY_SIZE(sdp3430_i2c_boardinfo));
+ omap3_pmic_init(twl4030, sdp3430_twldata);
/* i2c2 on camera connector (for sensor control) and optional isp1301 */
omap_register_i2c_bus(2, 400, NULL, 0);
/* i2c3 on display connector (for DVI, tfp410) */
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56702c5..7073542 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -42,6 +42,7 @@
#include hsmmc.h
#include timer-gp.h
#include control.h
+#include common-board-devices.h
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
@@ -575,14 +576,6 @@ static struct twl4030_platform_data sdp4430_twldata = {
.usb= omap4_usbphy_data
};
-static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
- {
- I2C_BOARD_INFO(twl6030, 0x48),
- .flags = I2C_CLIENT_WAKE,
- .irq = OMAP44XX_IRQ_SYS_1N,
- .platform_data = sdp4430_twldata,
- },
-};
static struct i2c_board_info __initdata sdp4430_i2c_3_boardinfo[] = {
{
I2C_BOARD_INFO(tmp105, 0x48),
@@ -598,12 +591,7 @@ static struct i2c_board_info
[PATCH 4/4] omap: musb: introduce default baord config
Most boards use exactly the same configuration for musb initialization.
Create a default that can be shared amount different boards.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-2430sdp.c |7 +--
arch/arm/mach-omap2/board-3430sdp.c |8 +---
arch/arm/mach-omap2/board-cm-t35.c |8 +---
arch/arm/mach-omap2/board-devkit8000.c |8 +---
arch/arm/mach-omap2/board-igep0020.c |8 +---
arch/arm/mach-omap2/board-igep0030.c |8 +---
arch/arm/mach-omap2/board-ldp.c |8 +---
arch/arm/mach-omap2/board-omap3beagle.c |8 +---
arch/arm/mach-omap2/board-omap3pandora.c |8 +---
arch/arm/mach-omap2/board-omap3stalker.c |8 +---
arch/arm/mach-omap2/board-omap3touchbook.c |8 +---
arch/arm/mach-omap2/board-overo.c|8 +---
arch/arm/mach-omap2/board-rm680.c|8 +---
arch/arm/mach-omap2/board-zoom-peripherals.c |8 +---
arch/arm/mach-omap2/usb-musb.c | 14 +-
15 files changed, 27 insertions(+), 98 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 99b3f2d..a8810f8 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -208,11 +208,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
static struct omap_usb_config sdp2430_usb_config __initdata = {
.otg= 1,
#ifdef CONFIG_USB_GADGET_OMAP
@@ -246,7 +241,7 @@ static void __init omap_2430sdp_init(void)
omap2_usbfs_init(sdp2430_usb_config);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP);
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index b12400e..951e585 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -810,12 +810,6 @@ static struct flash_partitions sdp_flash_partitions[] = {
},
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static void __init omap_3430sdp_init(void)
{
int gpio_pendown;
@@ -832,7 +826,7 @@ static void __init omap_3430sdp_init(void)
gpio_pendown = SDP3430_TS_GPIO_IRQ_SDPV1;
omap_ads7846_init(1, gpio_pendown, 310, NULL);
board_serial_init();
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 1a9e6be..286da17 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -651,12 +651,6 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static struct omap_board_config_kernel cm_t35_config[] __initdata = {
};
@@ -673,7 +667,7 @@ static void __init cm_t35_init(void)
cm_t35_init_led();
cm_t35_init_display();
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index e7dc057..405542a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -509,12 +509,6 @@ static struct platform_device *devkit8000_devices[]
__initdata = {
omap_dm9000_dev,
};
-static struct omap_musb_board_data musb_board_data = {
- .interface_type = MUSB_INTERFACE_ULPI,
- .mode = MUSB_OTG,
- .power = 100,
-};
-
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
@@ -698,7 +692,7 @@ static void __init devkit8000_init(void)
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
- usb_musb_init(musb_board_data);
+ usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
ARRAY_SIZE(devkit8000_nand_partitions));
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a0fd10e
Re: [PATCH 1/2] arm: omap: fix bug with multiple smsc911x devices
Hi Igor,
On Thu, Apr 21, 2011 at 5:50 PM, Igor Grinberg grinb...@compulab.co.il wrote:
kobject (c06a4250): tried to init an initialized object, something is
seriously wrong.
introduced by commit 66293989:
(omap: convert boards that use SMSC911x to use gpmc-smsc911x)
fixed by allocating struct platform_device dynamically.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
This has been boot tested with nfs root on cm-t35,
and build tested on all other affected boards.
arch/arm/mach-omap2/board-cm-t35.c | 2 ++
arch/arm/mach-omap2/board-igep0020.c | 1 +
arch/arm/mach-omap2/board-ldp.c | 1 +
arch/arm/mach-omap2/board-omap3evm.c | 1 +
arch/arm/mach-omap2/board-omap3logic.c | 1 +
arch/arm/mach-omap2/board-omap3stalker.c | 1 +
arch/arm/mach-omap2/board-overo.c | 2 ++
arch/arm/mach-omap2/board-zoom-debugboard.c | 1 +
arch/arm/mach-omap2/gpmc-smsc911x.c | 16 +---
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 1 +
10 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index b5772c1..7c70f56 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -69,6 +69,7 @@
#include plat/gpmc-smsc911x.h
static struct omap_smsc911x_platform_data cm_t35_smsc911x_cfg = {
+ .id = 0,
.cs = CM_T35_SMSC911X_CS,
.gpio_irq = CM_T35_SMSC911X_GPIO,
.gpio_reset = -EINVAL,
@@ -76,6 +77,7 @@ static struct omap_smsc911x_platform_data
cm_t35_smsc911x_cfg = {
};
static struct omap_smsc911x_platform_data sb_t35_smsc911x_cfg = {
+ .id = 1,
.cs = SB_T35_SMSC911X_CS,
.gpio_irq = SB_T35_SMSC911X_GPIO,
.gpio_reset = -EINVAL,
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5b9bde7..2bf12fb 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -195,6 +195,7 @@ static void __init igep2_flash_init(void) {}
#include plat/gpmc-smsc911x.h
static struct omap_smsc911x_platform_data smsc911x_cfg = {
+ .id = -1,
.cs = IGEP2_SMSC911X_CS,
.gpio_irq = IGEP2_SMSC911X_GPIO,
.gpio_reset = -EINVAL,
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index ea9f049..94cfd82 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -218,6 +218,7 @@ static struct spi_board_info ldp_spi_board_info[]
__initdata = {
};
static struct omap_smsc911x_platform_data smsc911x_cfg = {
+ .id = -1,
I believe you can keep the id field uninitialized, i.e. 0. This
applies to other boards with single smsc device as well.
.cs = LDP_SMSC911X_CS,
.gpio_irq = LDP_SMSC911X_GPIO,
.gpio_reset = -EINVAL,
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 3fc85c6..fc5c1d8 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -104,6 +104,7 @@ static void __init omap3_evm_get_revision(void)
#include plat/gpmc-smsc911x.h
static struct omap_smsc911x_platform_data smsc911x_cfg = {
+ .id = -1,
.cs = OMAP3EVM_SMSC911X_CS,
.gpio_irq = OMAP3EVM_ETHR_GPIO_IRQ,
.gpio_reset = -EINVAL,
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index a49e6cf..06248e7 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -144,6 +144,7 @@ static void __init board_mmc_init(void)
}
static struct omap_smsc911x_platform_data __initdata board_smsc911x_data = {
+ .id = -1,
.cs = OMAP3LOGIC_SMSC911X_CS,
.gpio_irq = -EINVAL,
.gpio_reset = -EINVAL,
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 848016c..ae4eaf5 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -64,6 +64,7 @@
#define OMAP3STALKER_SMC911X_CS 5
static struct omap_smsc911x_platform_data smsc911x_cfg = {
+ .id = -1,
.cs = OMAP3STALKER_SMC911X_CS,
.gpio_irq = OMAP3STALKER_ETHR_GPIO_IRQ,
.gpio_reset = -EINVAL,
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 4016166..165e1fa 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -149,6 +149,7 @@ static inline void __init overo_ads7846_init(void) {
return; }
#include
Re: [PATCH 0/2] OMAP: convert boards that use SMSC911x to use gpmc-smsc911x
Hi Tony, On Mon, Apr 18, 2011 at 2:21 PM, Tony Lindgren t...@atomide.com wrote: * Mike Rapoport m...@compulab.co.il [110417 01:21]: Nice job Mike :) There's a _lot_ of very similar code in different board files. If you'd like to I can try to create something like common-board-devices.c and move most of that code there. It's not the real consolidation Linus wanted, but at least all the copy-pasted device initialization code would be removed. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely Yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP: convert boards that use SMSC911x to use gpmc-smsc911x
There are several OMAP boards that use SMSC911x Ethernet controller. Convert them all to use gpmc-smsc911x for device registration. Mike Rapoport (2): OMAP: gpmc-smsc911x: always set irq flags to IORESOURCE_IRQ_LOWLEVEL OMAP: convert boards that use SMSC911x to use gpmc-smsc911x arch/arm/mach-omap2/board-cm-t35.c | 84 +++-- arch/arm/mach-omap2/board-igep0020.c| 53 ++--- arch/arm/mach-omap2/board-ldp.c | 65 ++-- arch/arm/mach-omap2/board-omap3evm.c| 71 +++--- arch/arm/mach-omap2/board-omap3logic.c |1 - arch/arm/mach-omap2/board-omap3stalker.c| 48 ++-- arch/arm/mach-omap2/board-overo.c | 108 --- arch/arm/mach-omap2/board-zoom-debugboard.c | 56 ++ arch/arm/mach-omap2/gpmc-smsc911x.c |7 +- 9 files changed, 70 insertions(+), 423 deletions(-) -- 1.7.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP: gpmc-smsc911x: always set irq flags to IORESOURCE_IRQ_LOWLEVEL
SMSC911x devices attached to OMAP GPMC always use low level irqs.
Setting the appropriate flag in the irq resourse strucure allows using
.flags field in the omap_smsc911x_platform_data for driver specific
flags
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-omap3logic.c |1 -
arch/arm/mach-omap2/gpmc-smsc911x.c|7 ---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index b726943..a49e6cf 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -147,7 +147,6 @@ static struct omap_smsc911x_platform_data __initdata
board_smsc911x_data = {
.cs = OMAP3LOGIC_SMSC911X_CS,
.gpio_irq = -EINVAL,
.gpio_reset = -EINVAL,
- .flags = IORESOURCE_IRQ_LOWLEVEL,
};
/* TODO/FIXME (comment by Peter Barada, LogicPD):
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 703f150..b331f3c 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -30,7 +30,7 @@ static struct resource gpmc_smsc911x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .flags = IORESOURCE_IRQ,
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
},
};
@@ -79,8 +79,6 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpio_direction_input(gpmc_cfg-gpio_irq);
gpmc_smsc911x_resources[1].start = gpio_to_irq(gpmc_cfg-gpio_irq);
- gpmc_smsc911x_resources[1].flags |=
- (gpmc_cfg-flags IRQF_TRIGGER_MASK);
if (gpio_is_valid(gpmc_cfg-gpio_reset)) {
ret = gpio_request(gpmc_cfg-gpio_reset, smsc911x reset);
@@ -96,6 +94,9 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpio_set_value(gpmc_cfg-gpio_reset, 1);
}
+ if (gpmc_cfg-flags)
+ gpmc_smsc911x_config.flags = gpmc_cfg-flags;
+
if (platform_device_register(gpmc_smsc911x_device) 0) {
printk(KERN_ERR Unable to register smsc911x device\n);
gpio_free(gpmc_cfg-gpio_reset);
--
1.7.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP: convert boards that use SMSC911x to use gpmc-smsc911x
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 84 +++--
arch/arm/mach-omap2/board-igep0020.c| 53 ++---
arch/arm/mach-omap2/board-ldp.c | 65 ++--
arch/arm/mach-omap2/board-omap3evm.c| 71 +++---
arch/arm/mach-omap2/board-omap3stalker.c| 48 ++--
arch/arm/mach-omap2/board-overo.c | 108 ---
arch/arm/mach-omap2/board-zoom-debugboard.c | 56 ++
7 files changed, 66 insertions(+), 419 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 02a12b4..b5772c1 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -66,86 +66,26 @@
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include linux/smsc911x.h
+#include plat/gpmc-smsc911x.h
-static struct smsc911x_platform_config cm_t35_smsc911x_config = {
- .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
- .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+static struct omap_smsc911x_platform_data cm_t35_smsc911x_cfg = {
+ .cs = CM_T35_SMSC911X_CS,
+ .gpio_irq = CM_T35_SMSC911X_GPIO,
+ .gpio_reset = -EINVAL,
.flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
- .phy_interface = PHY_INTERFACE_MODE_MII,
};
-static struct resource cm_t35_smsc911x_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP_GPIO_IRQ(CM_T35_SMSC911X_GPIO),
- .end= OMAP_GPIO_IRQ(CM_T35_SMSC911X_GPIO),
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
- },
-};
-
-static struct platform_device cm_t35_smsc911x_device = {
- .name = smsc911x,
- .id = 0,
- .num_resources = ARRAY_SIZE(cm_t35_smsc911x_resources),
- .resource = cm_t35_smsc911x_resources,
- .dev= {
- .platform_data = cm_t35_smsc911x_config,
- },
-};
-
-static struct resource sb_t35_smsc911x_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP_GPIO_IRQ(SB_T35_SMSC911X_GPIO),
- .end= OMAP_GPIO_IRQ(SB_T35_SMSC911X_GPIO),
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
- },
-};
-
-static struct platform_device sb_t35_smsc911x_device = {
- .name = smsc911x,
- .id = 1,
- .num_resources = ARRAY_SIZE(sb_t35_smsc911x_resources),
- .resource = sb_t35_smsc911x_resources,
- .dev= {
- .platform_data = cm_t35_smsc911x_config,
- },
+static struct omap_smsc911x_platform_data sb_t35_smsc911x_cfg = {
+ .cs = SB_T35_SMSC911X_CS,
+ .gpio_irq = SB_T35_SMSC911X_GPIO,
+ .gpio_reset = -EINVAL,
+ .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
};
-static void __init cm_t35_init_smsc911x(struct platform_device *dev,
- int cs, int irq_gpio)
-{
- unsigned long cs_mem_base;
-
- if (gpmc_cs_request(cs, SZ_16M, cs_mem_base) 0) {
- pr_err(CM-T35: Failed request for GPMC mem for smsc911x\n);
- return;
- }
-
- dev-resource[0].start = cs_mem_base + 0x0;
- dev-resource[0].end = cs_mem_base + 0xff;
-
- if ((gpio_request(irq_gpio, ETH IRQ) == 0)
- (gpio_direction_input(irq_gpio) == 0)) {
- gpio_export(irq_gpio, 0);
- } else {
- pr_err(CM-T35: could not obtain gpio for SMSC911X IRQ\n);
- return;
- }
-
- platform_device_register(dev);
-}
-
static void __init cm_t35_init_ethernet(void)
{
- cm_t35_init_smsc911x(cm_t35_smsc911x_device,
-CM_T35_SMSC911X_CS, CM_T35_SMSC911X_GPIO);
- cm_t35_init_smsc911x(sb_t35_smsc911x_device,
-SB_T35_SMSC911X_CS, SB_T35_SMSC911X_GPIO);
+ gpmc_smsc911x_init(cm_t35_smsc911x_cfg);
+ gpmc_smsc911x_init(sb_t35_smsc911x_cfg);
}
#else
static inline void __init cm_t35_init_ethernet(void) { return; }
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5f8a2fd..bb60414 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -192,57 +192,18 @@ static void __init igep2_flash_init(void) {}
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include linux/smsc911x.h
+#include plat/gpmc-smsc911x.h
-static struct smsc911x_platform_config igep2_smsc911x_config = {
- .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
- .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
- .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
Hi Madhu, Madhusudhan wrote: -Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Thursday, October 07, 2010 8:57 AM To: Mike Rapoport Cc: Madhusudhan Chikkature; David Vrabel; Chris Ball; linux- m...@vger.kernel.org; linux-omap@vger.kernel.org; Adrian Hunter Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) I can confirm exactly the same behavior on my hardware with this version of the patch. Steve, Okay. Did the version you had in your tree worked? I just want to check if I messed up something in my patch. The patch works if applied before commit b417577d3b9bbb06a4ddc9aa955af9bd503f7242 (omap_hsmmc: improve interrupt synchronisation). Apparently, changes in interrupt handling require major rework of the SDIO interrupt handling... Regards, Madhu Steve -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
Hi Madhu,
Madhusudhan Chikkature wrote:
snip
You are correct! The version of the patch in the repo indeed has
'out' in the wrong place and generates a compile error.
Could you post the patch you are using and I will try to reproduce
what you are seeing on my hardware? Best we all work from exactly the
same patch!
Steve
Yes. I think that check breaking the compilation is not needed. How about the
below version? It just removes that check.
This version should apply fine on the latest kernel. I did a sanity test of
MMC/SD cards on OMAP4 SDP.
Steve or Mike can check if SDIO interrupts are working.
With you patch I get the same:
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas: command 0x0003 timed out
libertas: Timeout submitting command 0x0003
libertas: PREP_CMD: command 0x0003 failed: -110
libertas_sdio: probe of mmc1:0001:1 failed with error -110
The libertas driver is expecting and interrupt from the card that signals
completion of the firmware initialization. But the SDIO interrupts are disabled
because every request from host to card has been completed. Moreover, if there
were SDIO interrupts they would be ignored by the omap_hsmmc_do_irq handler
because it returns immediately is there is not request in process.
I've tried to move the check for the SDIO interrupt to the very beginning of the
ISR but to no avail
Regards,
Madhu
From 08b77fd388f19f5df3758a2c59dcdec280f373c8 Mon Sep 17 00:00:00 2001
From: David Vrabel david.vra...@csr.com
Date: Wed, 6 Oct 2010 12:39:18 -0500
Subject: [PATCH 1/2] mmc: omap_hsmmc: enable SDIO card interrupts
Enable the use of SDIO card interrupts.
FCLK must be enabled while SDIO interrupts are enabled or the MMC
module won't wake-up (even though ENAWAKEUP in SYSCONFIG and IWE in
HTCL have been set). Enabling the MMC module to wake-up would require
configuring the MMC module (and the mmci_dat[1] GPIO when the CORE
power domain is OFF) as wake-up sources in the PRCM.
The writes to STAT and ISE when starting a command are unnecessary and
have been removed.
Signed-off-by: David Vrabel david.vra...@csr.com
---
drivers/mmc/host/omap_hsmmc.c | 72 +
1 files changed, 65 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4693e62..948dd9a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -66,6 +66,7 @@
#define SDVS_MASK 0x0E00
#define SDVSCLR0xF1FF
#define SDVSDET0x0400
+#define ENAWAKEUP (1 2)
#define AUTOIDLE 0x1
#define SDBP (1 8)
#define DTO0xe
@@ -76,9 +77,12 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
+#define CIRQ_ENABLE(1 8)
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
@@ -87,10 +91,12 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define IWE(1 24)
#define DW8(1 5)
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 8)
#define ERR(1 15)
#define CMD_TIMEOUT(1 16)
#define DATA_TIMEOUT (1 20)
@@ -184,6 +190,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -551,6 +558,9 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_ENABLE;
+ if (host-sdio_int)
+ irq_mask |= CIRQ;
+
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
@@ -603,7 +613,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE | ENAWAKEUP);
if (host-id == OMAP_MMC1_DEVID) {
if (host-power_mode != MMC_POWER_OFF
@@ -618,7 +628,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}
OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base,
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
Steve Sakoman wrote: On Mon, Oct 4, 2010 at 10:33 AM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 04, 2010 11:57 AM To: Madhusudhan Cc: Mike Rapoport; David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Mon, Oct 4, 2010 at 9:45 AM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 04, 2010 11:32 AM To: Mike Rapoport Cc: David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; madhu...@ti.com Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport m...@compulab.co.il wrote: David Vrabel wrote: On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. I'll try to update the patches in the next few days. Any update on the status of these patches? I'm happy to help test! Steve, I have not been able to test SDIO card interrupts. If you could help test that it's great. Where can I grab the most recent patches? The original set don't apply cleanly. Yes. They may not apply. I can rebase them and send it to you for testing. Are you using the two patches posted by David Vrabel? Yes, I've been using the original patches on 2.6.33 and 2.6.34. The SDIO interrupt patch doesn't apply on 2.6.35 or 36. If you send a revised patch for either I would be happy to test as soon as I get it. I've tried to update the patches on top of 2.6.36-rc3 and I've got stuck. The changes Adrian has made to the interrupt synchronization affect the way the SDIO irq should be implemented and I haven't found a way to resolve it :-( Steve -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
Hi Steve, Steve Sakoman wrote: On Tue, Oct 5, 2010 at 11:17 PM, Mike Rapoport m...@compulab.co.il wrote: I've tried to update the patches on top of 2.6.36-rc3 and I've got stuck. The changes Adrian has made to the interrupt synchronization affect the way the SDIO irq should be implemented and I haven't found a way to resolve it :-( I tried my hand at making the patch apply on 2.6.35: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=51b802d73191c306618cddefbd63379c839589f5 This one fails to build: CC drivers/mmc/host/omap_hsmmc.o drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_start_command': drivers/mmc/host/omap_hsmmc.c:791: warning: unused variable 'int_en_mask' drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_do_irq': drivers/mmc/host/omap_hsmmc.c:1023: error: label 'out' used but not defined drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_irq': drivers/mmc/host/omap_hsmmc.c:1101: warning: label 'out' defined but not used drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend': drivers/mmc/host/omap_hsmmc.c:2346: warning: unused variable 'state' make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1 Moving the 'out' label where I believe it should live I get: libertas_sdio: Libertas SDIO driver libertas_sdio: Copyright Pierre Ossman libertas: command 0x0003 timed out libertas: Timeout submitting command 0x0003 libertas: PREP_CMD: command 0x0003 failed: -110 libertas_sdio: probe of mmc1:0001:1 failed with error -110 It seems to work, but I'm pretty sure I must have messed something up because I get error messages every once in a while: libertas: tx watch dog timeout I don't recall seeing these with the original version of the patch :-( Suggestions as to where I went wrong are welcome! I've applied the patch almost the same way you did and I was not able to get any further than the point above (command 0x0003 timed out). As far as I understand, what we have now is that omap_hsmmc_request_done() calls omap_hsmmc_disable_irq() and the interrupts that come from the 8686 _between_ requests are simply missed. Whatever I've tried to keep the SDIO interrupts on didn't help... :( Steve -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
David Vrabel wrote: On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. I'll try to update the patches in the next few days. David -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 broken with 36-rc1
Hi Ameya,
Ameya Palande wrote:
Hi Tomi,
When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
following error messages:
[0.124145] OMAP DSS rev 2.0
[0.124237] OMAP DISPC rev 3.0
[0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
[0.805419] omapfb omapfb: failed to allocate framebuffer
[0.810882] omapfb omapfb: failed to allocate fbmem
[0.815856] omapfb omapfb: failed to setup omapfb
[0.820648] omapfb: probe of omapfb failed with error -12
Can you try this one:
From 28de4496224d1e2ae72dcb5bb52b72d850d3cc49 Mon Sep 17 00:00:00 2001
From: Mike Rapoport m...@compulab.co.il
Date: Mon, 23 Aug 2010 09:40:09 +0300
Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
ioremap for other memory types
Reported-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
drivers/video/omap2/omapfb/omapfb-main.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 04034d4..7f7b1c2 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1436,7 +1436,10 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi,
unsigned long size,
}
if (ofbi-rotation_type != OMAP_DSS_ROT_VRFB) {
- vaddr = ioremap_wc(paddr, size);
+ if (region_mem_type(paddr) == OMAP_VRAM_MEMTYPE_SDRAM)
+ vaddr = phys_to_virt(paddr);
+ else
+ vaddr = ioremap_wc(paddr, size);
if (!vaddr) {
dev_err(fbdev-dev, failed to ioremap framebuffer\n);
--
1.6.6.2
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 broken with 36-rc1
Mike Rapoport wrote:
Hi Ameya,
Ameya Palande wrote:
Hi Tomi,
When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
following error messages:
[0.124145] OMAP DSS rev 2.0
[0.124237] OMAP DISPC rev 3.0
[0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
[0.805419] omapfb omapfb: failed to allocate framebuffer
[0.810882] omapfb omapfb: failed to allocate fbmem
[0.815856] omapfb omapfb: failed to setup omapfb
[0.820648] omapfb: probe of omapfb failed with error -12
Please discard the previous patch, it's buggy :(
Sorry for the noise.
From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001
From: Mike Rapoport m...@compulab.co.il
Date: Mon, 23 Aug 2010 09:40:09 +0300
Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
ioremap for other memory types
Reported-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/plat-omap/include/plat/vram.h |1 +
drivers/video/omap2/omapfb/omapfb-main.c |2 +-
drivers/video/omap2/vram.c | 10 ++
3 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vram.h
b/arch/arm/plat-omap/include/plat/vram.h
index 0aa4ecd..b1b137c 100644
--- a/arch/arm/plat-omap/include/plat/vram.h
+++ b/arch/arm/plat-omap/include/plat/vram.h
@@ -33,6 +33,7 @@ extern int omap_vram_alloc(int mtype, size_t size, unsigned
long *paddr);
extern int omap_vram_reserve(unsigned long paddr, size_t size);
extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
unsigned long *largest_free_block);
+extern void __iomem *omap_vram_remap(size_t size, unsigned long paddr);
#ifdef CONFIG_OMAP2_VRAM
extern void omap_vram_set_sdram_vram(u32 size, u32 start);
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 04034d4..39f53b1 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1436,7 +1436,7 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi,
unsigned long size,
}
if (ofbi-rotation_type != OMAP_DSS_ROT_VRFB) {
- vaddr = ioremap_wc(paddr, size);
+ vaddr = omap_vram_remap(size, paddr);
if (!vaddr) {
dev_err(fbdev-dev, failed to ioremap framebuffer\n);
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index f6fdc20..37557b6 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -30,6 +30,7 @@
#include linux/debugfs.h
#include linux/jiffies.h
#include linux/module.h
+#include linux/io.h
#include asm/setup.h
@@ -425,6 +426,15 @@ void omap_vram_get_info(unsigned long *vram,
}
EXPORT_SYMBOL(omap_vram_get_info);
+void __iomem *omap_vram_remap(size_t size, unsigned long paddr)
+{
+ if (region_mem_type(paddr) == OMAP_VRAM_MEMTYPE_SDRAM)
+ return phys_to_virt(paddr);
+
+ return ioremap_wc(paddr, size);
+}
+EXPORT_SYMBOL(omap_vram_remap);
+
#if defined(CONFIG_DEBUG_FS)
static int vram_debug_show(struct seq_file *s, void *unused)
{
--
1.6.6.2
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 broken with 36-rc1
Tomi Valkeinen wrote: On Mon, 2010-08-23 at 08:46 +0200, ext Mike Rapoport wrote: Hi Ameya, Ameya Palande wrote: Hi Tomi, When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with following error messages: [0.124145] OMAP DSS rev 2.0 [0.124237] OMAP DISPC rev 3.0 [0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected [0.805419] omapfb omapfb: failed to allocate framebuffer [0.810882] omapfb omapfb: failed to allocate fbmem [0.815856] omapfb omapfb: failed to setup omapfb [0.820648] omapfb: probe of omapfb failed with error -12 I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that works, but not N900... May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer memory from the RAM that is not managed by the kernel, e.g with something like mem=RAM size - fb size vram=fb size,0x8.. ? Tomi -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 broken with 36-rc1
Tomi Valkeinen wrote:
On Mon, 2010-08-23 at 09:19 +0200, ext Mike Rapoport wrote:
Tomi Valkeinen wrote:
I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
works, but not N900...
May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer
memory from the RAM that is not managed by the kernel, e.g with something like
mem=RAM size - fb size vram=fb size,0x8.. ?
No, SRAM cannot be used on OMAP3s, as SRAM is too small to hold a
framebuffer. And no, I don't think it's reserving it from RAM not
managed by the kernel.
The N900 only sets omap_vram_sdram_{start,size} in rx51_video_mem_init.
I think that it should also call omap_vram_reserve_sdram_memblock():
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 5a1005b..fdfe844 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -101,6 +101,7 @@ void __init rx51_video_mem_init(void)
*/
omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
+ omap_vram_reserve_sdram_memblock();
}
#else
What is actually failing there? Looking at Ameya's original post, the
problem is in allocating the framebuffer. Your patch is doing something
_after_ the allocation has failed, so I don't see Ameya's problem having
anything to do with ioremap.
You are right, I've misread the Ameya's original post. I'm fixing another
problem:
OMAPFB: omapfb_init
OMAPFB: omapfb_probe
OMAPFB: create 3 framebuffers
OMAPFB: fb_infos allocated
OMAPFB: allocating 614400 bytes for fb 0
VRAM: alloc mem type 0 size 614400
VRAM: checking region 8f00 4096
VRAM: found 8f00, end 9000
[ cut here ]
WARNING: at arch/arm/mm/ioremap.c:207 __arm_ioremap_pfn_caller+0x48/0x18c()
Modules linked in:
[c004e458] (unwind_backtrace+0x0/0xec) from [c007dfe8]
(warn_slowpath_common+0x4c/0x64)
[c007dfe8] (warn_slowpath_common+0x4c/0x64) from [c007e018]
(warn_slowpath_null+0x18/0x1c)
[c007e018] (warn_slowpath_null+0x18/0x1c) from [c00500c8]
(__arm_ioremap_pfn_caller+0x48/0x18c)
[c00500c8] (__arm_ioremap_pfn_caller+0x48/0x18c) from [c0050270]
(__arm_ioremap_caller+0x54/0x58)
[c0050270] (__arm_ioremap_caller+0x54/0x58) from [c02561e0]
(omapfb_alloc_fbmem+0xf0/0x19c)
[c02561e0] (omapfb_alloc_fbmem+0xf0/0x19c) from [c0257584]
(omapfb_allocate_all_fbs+0x2b8/0x34c)
[c0257584] (omapfb_allocate_all_fbs+0x2b8/0x34c) from [c0257a80]
(omapfb_probe+0x468/0x8dc)
[c0257a80] (omapfb_probe+0x468/0x8dc) from [c028330c]
(platform_drv_probe+0x18/0x1c)
[c028330c] (platform_drv_probe+0x18/0x1c) from [c0282344]
(driver_probe_device+0xc8/0x184)
[c0282344] (driver_probe_device+0xc8/0x184) from [c0282468]
(__driver_attach+0x68/0x8c)
[c0282468] (__driver_attach+0x68/0x8c) from [c0281afc]
(bus_for_each_dev+0x44/0x74)
[c0281afc] (bus_for_each_dev+0x44/0x74) from [c0281438]
(bus_add_driver+0x100/0x288)
[c0281438] (bus_add_driver+0x100/0x288) from [c028275c]
(driver_register+0xa8/0x134)
[c028275c] (driver_register+0xa8/0x134) from [c0022b34]
(omapfb_init+0x24/0x4c)
[c0022b34] (omapfb_init+0x24/0x4c) from [c00483ac]
(do_one_initcall+0xbc/0x194)
[c00483ac] (do_one_initcall+0xbc/0x194) from [c0008574]
(kernel_init+0x94/0x14c)
[c0008574] (kernel_init+0x94/0x14c) from [c0049930]
(kernel_thread_exit+0x0/0x8)
---[ end trace 1b75b31a2719ed1f ]---
omapfb omapfb: failed to ioremap framebuffer
VRAM: free mem paddr 8f00 size 614400
omapfb omapfb: failed to allocate fbmem
OMAPFB: free_resources
OMAPFB: free all fbmem
omapfb omapfb: failed to setup omapfb
omapfb: probe of omapfb failed with error -12
Ameya, you could try turning on the debugs in
drivers/video/omap2/vram.c, and checking what it says. Or see what is in
debugfs/vram file
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] twl4030 reboot workaround
Gopinath, Thara wrote: -Original Message- From: Turquette, Mike Sent: Saturday, July 31, 2010 12:09 AM To: Gopinath, Thara Cc: Mike Rapoport; Mikko Rapeli; linux-omap@vger.kernel.org; sa...@linux.intel.com Subject: Re: [PATCH v2] twl4030 reboot workaround Gopinath, Thara wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike Rapoport Sent: Friday, July 30, 2010 12:41 AM To: Mikko Rapeli Cc: linux-omap@vger.kernel.org; Turquette, Mike; sa...@linux.intel.com Subject: Re: [PATCH v2] twl4030 reboot workaround Hi On Thu, Jul 29, 2010 at 9:41 AM, Mikko Rapeli ext-mikko.rap...@nokia.com wrote: From: Mikko Rapeli ext-mikko.rap...@nokia.com Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2 Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting in the sleep script being executed on TWL4030. This usually results in VDD1 VDD2 voltage collapse while ROM code is executing, followed by an MPU Watch Dog reset or worse, an irrecoverable hang. I had a similar issue when my system hanged on hard reset when there was a TWL sleep script installed. The workaround I've found was to install the sleep script immediately before entering the suspend state and remove the script on the resume path. If you think that such approach is appropriate I can send a patch. How do you hit the off state(Vdd's at 0 V) in the idle path then? Or do you do this every time in the idle thread also? I do not think it is appropriate to add/remove the sleep script before/after every OFF mode case. The script should be programmed once and left alone EXCEPT in the case of warm reset. If there are other corner cases where SYS_OFFMODE goes low, then we should cover those with similar fixes to the warm reset fix, but in general I think the policy should be to leave the scripts alone once programmed Dynamically programming/removing the scripts around OFF transitions increases software overhead for those transitions even more which is very undesirable. This was exactly my concern. The latency increase due to the dynamic addition and removal of sleep scripts around off transitions might not be justifiable. Maybe Mike does not want to hit 0V for Vdd's in the idle thread in which case it can be acceptable to dynamically add the script in the system suspend path and remove it in the resume path. Else I also do not think this approach is acceptable. I've missed the idle case indeed and I agree that dynamic addition and removal of sleep scripts is not an acceptable solution. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] twl4030 reboot workaround
Hi
On Thu, Jul 29, 2010 at 9:41 AM, Mikko Rapeli
ext-mikko.rap...@nokia.com wrote:
From: Mikko Rapeli ext-mikko.rap...@nokia.com
Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2
Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
in the sleep script being executed on TWL4030. This usually results in
VDD1 VDD2 voltage collapse while ROM code is executing, followed by an
MPU Watch Dog reset or worse, an irrecoverable hang.
I had a similar issue when my system hanged on hard reset when there
was a TWL sleep script installed.
The workaround I've found was to install the sleep script immediately
before entering the suspend state and remove the script on the resume
path.
If you think that such approach is appropriate I can send a patch.
Original patch resulted in a crash due to sleeping i2c calls late in the
reboot sequence. Here's how to trigger the crash:
# cat /dev/urandom /foo
sync();
reboot(LINUX_REBOOT_CMD_RESTART2);
Kernel trace from 2.6.32:
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#2] PREEMPT
...
[c00b3210] (exit_mmap+0x1d4/0x1f8) from [c006069c] (mmput+0x34/0x110)
[c006069c] (mmput+0x34/0x110) from [c0064a90] (exit_mm+0x140/0x180)
[c0064a90] (exit_mm+0x140/0x180) from [c00668ec] (do_exit+0x5d8/0x6ac)
[c00668ec] (do_exit+0x5d8/0x6ac) from [c0035858] (die+0x2d4/0x2e0)
[c0035858] (die+0x2d4/0x2e0) from [c0035904] (baddataabort+0x0/0x50)
[c0035904] (baddataabort+0x0/0x50) from [c0274ff4]
(i2c_transfer+0xec/0x104)
[c0274ff4] (i2c_transfer+0xec/0x104) from [0001] (0x1)
Fix is to move reboot preparations into a reboot notifier.
Signed-off-by: Mikko Rapeli ext-mikko.rap...@nokia.com
Acked-by: Mike Turquette mturque...@ti.com
---
v2: added a new line after variable declarations
v1: http://marc.info/?l=linux-omapm=128031011323970w=2
drivers/mfd/twl4030-power.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..5c6da1e 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -28,6 +28,7 @@
#include linux/pm.h
#include linux/i2c/twl.h
#include linux/platform_device.h
+#include linux/reboot.h
#include asm/mach-types.h
@@ -127,6 +128,30 @@ static u8 res_config_addrs[] = {
[RES_Main_Ref] = 0x94,
};
+/*
+ * PRCM on OMAP3 will drive SYS_OFFMODE low during DPLL3 warm reset.
+ * This causes Gaia sleep script to execute, usually killing VDD1 and
+ * VDD2 while code is running. WA is to disable the sleep script
+ * before warm reset.
+ */
+static int twl4030_prepare_for_reboot(struct notifier_block *this,
+ unsigned long cmd, void *p)
+{
+ int err;
+
+ err = twl4030_remove_script(TWL4030_SLEEP_SCRIPT);
+ if (err)
+ pr_err(TWL4030: error trying to disable sleep script!\n);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block twl4030_reboot_notifier = {
+ .notifier_call = twl4030_prepare_for_reboot,
+ .next = NULL,
+ .priority = 0
+};
+
static int __init twl4030_write_script_byte(u8 address, u8 byte)
{
int err;
@@ -549,6 +574,11 @@ void __init twl4030_power_init(struct twl4030_power_data
*twl4030_scripts)
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY);
if (err)
pr_err(TWL4030 Unable to relock registers\n);
+
+ err = register_reboot_notifier(twl4030_reboot_notifier);
+ if (err)
+ pr_err(TWL4030 Failed to register reboot notifier\n);
+
return;
unlock:
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely Yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] omap3: Unify omap2_set_globals_3[43,6x]x functions
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [100630 08:20]:
Sergio Aguirre wrote:
The only difference between them is the physical address of the
uart4 port, which is only present in 36xx chips.
We don't really need to care about keeping these 2 functions, since
the decision to use uart4 is more cleanly done later when we do have
access to omap_revision variable.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-3630sdp.c|2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c|2 +-
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/board-zoom2.c |2 +-
arch/arm/mach-omap2/board-zoom3.c |2 +-
arch/arm/plat-omap/common.c| 10 ++
arch/arm/plat-omap/include/plat/common.h |3 +--
18 files changed, 19 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index dd9c031..4961f3b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -805,7 +805,7 @@ static void __init omap_3430sdp_init(void)
static void __init omap_3430sdp_map_io(void)
{
- omap2_set_globals_343x();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
Maybe we should take it one step further and replace board_map_io
functions with common omap3_map_io?
Could be done yeah. If special handling is needed, it can still
be done in the board-*.c files. Care to do a patch for that?
no problem.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: introduce omap3_map_io
Hi Tony,
Here's the patch. It applies on top of Sergio's patch Unify
omap2_set_globals_3[43,6x]x functions.
---
Most OMAP3-based boards use exactly the same code for .map_io method in
the machine_desc structure.
This patch introduces omap3_map_io and updates board-* files to use it
as .map_io method.
Signed-off-by: Mike Rapoport m...@compulab.co.il
CC: Sergio Aguirre saagui...@ti.com
CC: Tony Lindgren t...@atomide.com
CC: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/board-3430sdp.c|8 +---
arch/arm/mach-omap2/board-3630sdp.c|8 +---
arch/arm/mach-omap2/board-am3517evm.c |8 +---
arch/arm/mach-omap2/board-cm-t35.c |8 +---
arch/arm/mach-omap2/board-devkit8000.c |8 +---
arch/arm/mach-omap2/board-igep0020.c |8 +---
arch/arm/mach-omap2/board-ldp.c|8 +---
arch/arm/mach-omap2/board-omap3beagle.c|8 +---
arch/arm/mach-omap2/board-omap3evm.c |8 +---
arch/arm/mach-omap2/board-omap3pandora.c |8 +---
arch/arm/mach-omap2/board-omap3stalker.c |8 +---
arch/arm/mach-omap2/board-omap3touchbook.c |8 +---
arch/arm/mach-omap2/board-overo.c |8 +---
arch/arm/mach-omap2/board-zoom2.c |8 +---
arch/arm/mach-omap2/board-zoom3.c |8 +---
arch/arm/plat-omap/common.c|6 ++
arch/arm/plat-omap/include/plat/common.h |2 ++
17 files changed, 23 insertions(+), 105 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4961f3b..ecdd2c3 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -803,18 +803,12 @@ static void __init omap_3430sdp_init(void)
usb_ehci_init(ehci_pdata);
}
-static void __init omap_3430sdp_map_io(void)
-{
- omap2_set_globals_3xxx();
- omap34xx_map_common_io();
-}
-
MACHINE_START(OMAP_3430SDP, OMAP3430 3430SDP board)
/* Maintainer: Syed Khasim - Texas Instruments Inc */
.phys_io= 0x4800,
.io_pg_offst= ((0xfa00) 18) 0xfffc,
.boot_params= 0x8100,
- .map_io = omap_3430sdp_map_io,
+ .map_io = omap3_map_io,
.reserve= omap_reserve,
.init_irq = omap_3430sdp_init_irq,
.init_machine = omap_3430sdp_init,
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 72c2130..59860df 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -66,12 +66,6 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
.reset_gpio_port[2] = -EINVAL
};
-static void __init omap_sdp_map_io(void)
-{
- omap2_set_globals_3xxx();
- omap34xx_map_common_io();
-}
-
static struct omap_board_config_kernel sdp_config[] __initdata = {
};
@@ -107,7 +101,7 @@ MACHINE_START(OMAP_3630SDP, OMAP 3630SDP board)
.phys_io= 0x4800,
.io_pg_offst= ((0xfa00) 18) 0xfffc,
.boot_params= 0x8100,
- .map_io = omap_sdp_map_io,
+ .map_io = omap3_map_io,
.reserve= omap_reserve,
.init_irq = omap_sdp_init_irq,
.init_machine = omap_sdp_init,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 4356424..4d0f585 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -461,17 +461,11 @@ static void __init am3517_evm_init(void)
am3517_evm_ethernet_init(am3517_evm_emac_pdata);
}
-static void __init am3517_evm_map_io(void)
-{
- omap2_set_globals_3xxx();
- omap34xx_map_common_io();
-}
-
MACHINE_START(OMAP3517EVM, OMAP3517/AM3517 EVM)
.phys_io= 0x4800,
.io_pg_offst= ((0xd800) 18) 0xfffc,
.boot_params= 0x8100,
- .map_io = am3517_evm_map_io,
+ .map_io = omap3_map_io,
.reserve= omap_reserve,
.init_irq = am3517_evm_init_irq,
.init_machine = am3517_evm_init,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 6ce30b3..b910f72 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -708,12 +708,6 @@ static void __init cm_t35_init_irq(void)
omap_gpio_init();
}
-static void __init cm_t35_map_io(void)
-{
- omap2_set_globals_3xxx();
- omap34xx_map_common_io();
-}
-
static struct omap_board_mux board_mux[] __initdata = {
/* nCS and IRQ for CM-T35 ethernet */
OMAP3_MUX(GPMC_NCS5, OMAP_MUX_MODE0),
@@ -836,7 +830,7 @@ MACHINE_START(CM_T35, Compulab CM-T35)
.phys_io= 0x4800,
.io_pg_offst= ((0xd800) 18) 0xfffc,
.boot_params= 0x8100,
- .map_io
Re: [RFC][PATCH] omap3: Unify omap2_set_globals_3[43,6x]x functions
Sergio Aguirre wrote:
The only difference between them is the physical address of the
uart4 port, which is only present in 36xx chips.
We don't really need to care about keeping these 2 functions, since
the decision to use uart4 is more cleanly done later when we do have
access to omap_revision variable.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-3630sdp.c|2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c|2 +-
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/board-zoom2.c |2 +-
arch/arm/mach-omap2/board-zoom3.c |2 +-
arch/arm/plat-omap/common.c| 10 ++
arch/arm/plat-omap/include/plat/common.h |3 +--
18 files changed, 19 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index dd9c031..4961f3b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -805,7 +805,7 @@ static void __init omap_3430sdp_init(void)
static void __init omap_3430sdp_map_io(void)
{
- omap2_set_globals_343x();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
Maybe we should take it one step further and replace board_map_io functions with
common omap3_map_io?
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 57290fb..72c2130 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -68,7 +68,7 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
static void __init omap_sdp_map_io(void)
{
- omap2_set_globals_36xx();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index 7da92de..4356424 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -463,7 +463,7 @@ static void __init am3517_evm_init(void)
static void __init am3517_evm_map_io(void)
{
- omap2_set_globals_343x();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index bc4c3f8..6ce30b3 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -710,7 +710,7 @@ static void __init cm_t35_init_irq(void)
static void __init cm_t35_map_io(void)
{
- omap2_set_globals_343x();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 922b746..1164258 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -816,7 +816,7 @@ static void __init devkit8000_init(void)
static void __init devkit8000_map_io(void)
{
- omap2_set_globals_343x();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 759e39d..a8544ab 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -534,7 +534,7 @@ static void __init igep2_init(void)
static void __init igep2_map_io(void)
{
- omap2_set_globals_343x();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 9cd2669..9bcb182 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -408,7 +408,7 @@ static void __init omap_ldp_init(void)
static void __init omap_ldp_map_io(void)
{
- omap2_set_globals_343x();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 0ab0c26..7b95cc1 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -509,7 +509,7 @@ static void __init omap3_beagle_init(void)
static void __init omap3_beagle_map_io(void)
{
- omap2_set_globals_343x();
+ omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index
Re: pm_debug/voltage_off_while_idle has gone?
Kevin Hilman wrote: Mike Rapoport m...@compulab.co.il writes: There used to be 'voltage_off_while_idle' attribute in the PM-enabled kernels that allowed to put PMIC into OFF mode. In the current tip of the linux-omap-pm tree this attribute seem to be gone Is there possibility to make PMIC enter the OFF mode when suspending to RAM? Hi Mike, We are currently in the middle of a major rewrite of the SmartReflex and voltage layers of the PM branch. The previous voltage-related work (like voltage_off_while_idle) are still available in the pm-vc branch of my tree, but are not currently merged with the new voltage work due to conflicts. For this particular feature, I suspect you could just apply the first patch in my pm-vc branch to add back this feature. Let me know if that works, I've cherry-picked two commits from your pm-vc and it failed to compile :) After fixing it, I did several small tests, but is seems that PMIC does not execute the power scripts... I'll continue to work on it. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pm_debug/voltage_off_while_idle has gone?
There used to be 'voltage_off_while_idle' attribute in the PM-enabled kernels that allowed to put PMIC into OFF mode. In the current tip of the linux-omap-pm tree this attribute seem to be gone Is there possibility to make PMIC enter the OFF mode when suspending to RAM? -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo serial problems after resume, vs. Beagleboard
Kevin Hilman wrote: Peter Tseng tsenpe...@gmail.com writes: I am seeing some discrepancies between the Overo (I believe I have a Water) and the Beagleboard (I have a Rev. B5) when resuming after a suspend to RAM. Not that it is much comfort, but I have the same problem on Overo but don't see it on any other OMAP3 board. I have yet to debug this particular issue further. I had the same issue on CM-T35 and when I've disabled CONFIG_CPU_IDLE in the kernel configuration the issue disappeared. Maybe it'll be of some help. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo serial problems after resume, vs. Beagleboard
Kevin Hilman wrote: Mike Rapoport m...@compulab.co.il writes: Kevin Hilman wrote: Peter Tseng tsenpe...@gmail.com writes: I am seeing some discrepancies between the Overo (I believe I have a Water) and the Beagleboard (I have a Rev. B5) when resuming after a suspend to RAM. Not that it is much comfort, but I have the same problem on Overo but don't see it on any other OMAP3 board. I have yet to debug this particular issue further. I had the same issue on CM-T35 and when I've disabled CONFIG_CPU_IDLE in the kernel configuration the issue disappeared. Maybe it'll be of some help. That just masks the problem by not auto-gating the UART clocks. Agree, but having this observation may help to identify the real problem :) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap3 nand: fix issue in board file to detect the nand
[Sukumar Ghorai wrote:
From: Sukumar Ghorai s-gho...@ti.com
Board file modified to pass the GMPC phys_base address to nand driver. This is
required to adopt the _prob function as in omap2.c
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 10 ++
arch/arm/mach-omap2/board-devkit8000.c |9 +
arch/arm/mach-omap2/board-omap3beagle.c|9 +
arch/arm/mach-omap2/board-omap3touchbook.c |9 +
arch/arm/mach-omap2/board-overo.c |8
5 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index fb23122..73a32bd
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -240,6 +240,16 @@ static struct platform_device cm_t35_nand_device = {
static void __init cm_t35_init_nand(void)
{
+ struct device *dev = cm_t35_nand_device.dev;
+ int err = 0;
+
+ err = gpmc_cs_request(cm_t35_nand_data.cs,
+ NAND_IO_SIZE,
cm_t35_nand_data.phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return;
+ }
+
if (platform_device_register(cm_t35_nand_device) 0)
pr_err(CM-T35: Unable to register NAND device\n);
Why won't you use gpmc_nand_init instead of platform_device_register?
With gpmc_nand_init there would be no need to request NAND CS in the
board files. Besides, if you convert the boards to use gpmc_nand_init at
the first place, it would simplify further patches.
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index be50d18..86358e3
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -578,6 +578,9 @@ static void __init devkit8000_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
+ struct device *dev = devkit8000_nand_device.dev;
+ int err = 0;
+
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -599,6 +602,12 @@ static void __init devkit8000_flash_init(void)
if (nandcs GPMC_CS_NUM) {
devkit8000_nand_data.cs = nandcs;
+ err = gpmc_cs_request(devkit8000_nand_data.cs,
+ NAND_IO_SIZE,
devkit8000_nand_data.phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return;
+ }
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
if (platform_device_register(devkit8000_nand_device) 0)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index becaebe..d54719d
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -374,6 +374,9 @@ static void __init omap3beagle_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
+ struct device *dev = omap3beagle_nand_device.dev;
+ int err = 0;
+
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -395,6 +398,12 @@ static void __init omap3beagle_flash_init(void)
if (nandcs GPMC_CS_NUM) {
omap3beagle_nand_data.cs = nandcs;
+ err = gpmc_cs_request(omap3beagle_nand_data.cs,
+ NAND_IO_SIZE,
omap3beagle_nand_data.phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return;
+ }
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
if (platform_device_register(omap3beagle_nand_device) 0)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index d6f1b12..088a704
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -456,6 +456,9 @@ static void __init omap3touchbook_flash_init(void)
u8 cs = 0;
u8 nandcs = GPMC_CS_NUM + 1;
+ struct device *dev = omap3touchbook_nand_device.dev;
+ int err = 0;
+
/* find out the chip-select on which NAND exists */
while (cs GPMC_CS_NUM) {
u32 ret = 0;
@@ -477,6 +480,12 @@ static void __init omap3touchbook_flash_init(void)
if (nandcs GPMC_CS_NUM) {
omap3touchbook_nand_data.cs = nandcs;
+ err = gpmc_cs_request(omap3touchbook_nand_data.cs,
+ NAND_IO_SIZE,
omap3touchbook_nand_data.phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return;
+ }
printk(KERN_INFO Registering NAND on CS%d\n, nandcs);
if
Re: Upcoming merge window and omap NAND patches
Ghorai, Ghorai, Sukumar wrote: Tony, I understand your comment/input. And I will work on it. All existing omap3 boards are using same old fashion. So let me see how many board I can test before post the patch. I will update this next week. I'd be glad to test the patches on CM-T35 if you'd like to. Regards, Ghorai -Original Message- From: Vimal Singh [mailto:vimal.neww...@gmail.com] Sent: 2010-05-05 11:42 To: artem.bityuts...@nokia.com Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux- m...@lists.infradead.org; Ghorai, Sukumar; Steve Sakoman; Mike Rapoport Subject: Re: Upcoming merge window and omap NAND patches On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy artem.bityuts...@nokia.com wrote: On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote: Hi all, There are several omap NAND patches pending, but some basic things should be fixed first. 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. To find out what needs to disappear fomr the NAND driver, just do: $ grep baseaddr drivers/mtd/nand/omap2.c Any GPMC register tinkering needs to happen in arch/arm/mach- omap2/gpmc.c. If there are not currently GPMC functions to do something in gpmc.c, then let's add the necessary support there. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. So, as a result, I'm not planning on pushing any omap NAND related patches until these basic issues are fixed. I'll mark these patches as Changes requested in patchwork.kernel.org even if these patches don't have anything else wrong with them. Let's fix the basic things for good, and put the other patches on hold for a while. Sorry if this causes problems! Hi, fair enough. I guess Vimal should address this, as he seems to be the TI mr. NAND, right? :-) Hi All, Sorry again. I am no more with TI and I don't have any board with me too. So, I'm unable to fix these. :( I hope someone else from TI can take care of it. -- Regards, Vimal Singh -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Tony Lindgren wrote: * Mike Rapoport mike.rapop...@gmail.com [100503 13:28]: So it comes down to what provides better tolerance, the explicit NAND timings in nanosecs or (rounded) timings in ticks derived from bootloader settings... My experience is that you can get the nanosec timings from the device datasheet(s) and that just should work for any L3 frequency. And what about boards that can have different NAND flash chips assembled? What datasheet should be used to get the nanosecs? Note, that detecting NAND ID in the bootloader and adjusting timings appropriately is not that big deal, and doing it in the kernel seems to me really impractical. My experience is also that trying to do it the other way around won't work because of rounding errors. Trying to produce nanosecond values out of the tick values just is not accurate enough. I'm still not convinced. Similar approach worked for me with several devices attached to sort of GPMC controllers on different SoC. There always was a way to set timings once in the bootloader and then detect the timings in the kernel and update them during cpu-freq transitions... That's why gpmc-onenand.c and usb-tusb6010.c timings are done the way they are, and they're known to work at various L3 frequencies. I'm not really familiar with OneNAND, but looking at gpmc-onenand.c I see hardcoded timings. Moreover, the nanosecs values seem to get adjusted for different L3 frequencies. So, for NAND it would mean that platform would have to supply several timing sets for different L3 freqs? So maybe just not do anything, and print a warning on gpmc L3 changes if the timings are not set? I don't quite understand where exactly this warning should go. I haven't found any treatment of L3 frequency changes in gpmc related code neither in linux-omap nor in linux-omap-pm... Ah, right. There's currently nothing doing that.. That would have to be done based on cpufreq notifiers (or clock notifiers). But we don't have any of that at least in the mainline yet. Hmm I don't even think we currently scale the L3 for cpufreq.. Right now the best way to test would be by booting at different L3 frequencies. Anyways, my point is that setting gpmc_default_timings based on the bootloader after doing the gpmc_cs_get_timings is most likely unsafe for other L3 frequencies. Regards, Tony -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] omap: gpmc-nand: add ability to keep timings defined by the bootloader
On Mon, May 3, 2010 at 9:24 PM, Tony Lindgren t...@atomide.com wrote:
* Mike Rapoport m...@compulab.co.il [100429 01:44]:
Signed-off-by: Mike Rapoport m...@compulab.co.il
Please add a proper description to all the patches.
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -116,6 +124,11 @@ int __init gpmc_nand_init(struct
omap_nand_platform_data *_nand_data)
return err;
}
+ if (gpmc_nand_data-keep_timings) {
+ gpmc_cs_get_timings(gpmc_nand_data-cs, gpmc_default_timings);
+ gpmc_nand_data-gpmc_t = gpmc_default_timings;
+ }
+
err = gpmc_nand_setup();
if (err 0) {
dev_err(dev, NAND platform setup failed: %d\n, err);
Hmm, so you're setting the timings based on the bootloader values?
I' think the problem with that is that chances are that it still won't
work for other L3 frequencies because of rounding errors.
With gpmc_cs_get_timings() you're already using tick rounded timings,
so you won't get the required accuracy out of those for the other
L3 frequencies.
Agree. But even if the timings are in nanoseconds there are rounding
errors, and there are still chances that L3 frequency change will
break NAND
So it comes down to what provides better tolerance, the explicit NAND
timings in nanosecs or (rounded) timings in ticks derived from
bootloader settings...
So maybe just not do anything, and print a warning on gpmc L3 changes
if the timings are not set?
I don't quite understand where exactly this warning should go. I
haven't found any treatment of L3 frequency changes in gpmc related
code neither in linux-omap nor in linux-omap-pm...
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely Yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] omap: gpmc-nand: introduce omap2_nand_gpmc_round_timings helper
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c | 56 +--
1 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..9434c80 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -34,6 +34,35 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
+static void omap2_nand_gpmc_round_timings(struct gpmc_timings *src,
+ struct gpmc_timings *dst)
+{
+ dst-sync_clk = gpmc_round_ns_to_ticks(src-sync_clk);
+ dst-cs_on = gpmc_round_ns_to_ticks(src-cs_on);
+ dst-adv_on = gpmc_round_ns_to_ticks(src-adv_on);
+
+ /* Read */
+ dst-adv_rd_off = gpmc_round_ns_to_ticks(src-adv_rd_off);
+ dst-oe_on = dst-adv_on;
+ dst-access = gpmc_round_ns_to_ticks(src-access);
+ dst-oe_off = gpmc_round_ns_to_ticks(src-oe_off);
+ dst-cs_rd_off = gpmc_round_ns_to_ticks(src-cs_rd_off);
+ dst-rd_cycle = gpmc_round_ns_to_ticks(src-rd_cycle);
+
+ /* Write */
+ dst-adv_wr_off = gpmc_round_ns_to_ticks(src-adv_wr_off);
+ dst-we_on = dst-oe_on;
+ if (cpu_is_omap34xx()) {
+ dst-wr_data_mux_bus = gpmc_round_ns_to_ticks(
+ src-wr_data_mux_bus);
+ dst-wr_access = gpmc_round_ns_to_ticks(
+ src-wr_access);
+ }
+ dst-we_off = gpmc_round_ns_to_ticks(src-we_off);
+ dst-cs_wr_off = gpmc_round_ns_to_ticks(src-cs_wr_off);
+ dst-wr_cycle = gpmc_round_ns_to_ticks(src-wr_cycle);
+}
+
static int omap2_nand_gpmc_retime(void)
{
struct gpmc_timings t;
@@ -43,32 +72,7 @@ static int omap2_nand_gpmc_retime(void)
return 0;
memset(t, 0, sizeof(t));
- t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
- t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_on);
- t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-adv_on);
-
- /* Read */
- t.adv_rd_off = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-adv_rd_off);
- t.oe_on = t.adv_on;
- t.access = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-access);
- t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-oe_off);
- t.cs_rd_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_rd_off);
- t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-rd_cycle);
-
- /* Write */
- t.adv_wr_off = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-adv_wr_off);
- t.we_on = t.oe_on;
- if (cpu_is_omap34xx()) {
- t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-wr_data_mux_bus);
- t.wr_access = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-wr_access);
- }
- t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-we_off);
- t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
- t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+ omap2_nand_gpmc_round_timings(gpmc_nand_data-gpmc_t, t);
/* Configure GPMC */
gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
--
1.6.6.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] omap: gpmc-nand: add ability to keep timings defined by the bootloader
These patches add ability to keep GPMC timings configured by the bootloader. The platforms have to either define NAND GPMC timinings explicitly via gpmc_t field of omap_nand_platform_data or set keep_timings flag to allow detection of current timing configuration and its subsequent use in omap2_nand_gpmc_retime. v2 changes: - remove debug leftovers - make timing rounding depend on .keep_timing flag and introduce omap2_nand_gpmc_round_timings to facilitate this change Mike Rapoport (3): omap: gpmc: add gpmc_cs_get_timings omap: gpmc-nand: introduce omap2_nand_gpmc_round_timings helper omap: gpmc-nand: add ability to keep timings defined by the bootloader arch/arm/mach-omap2/gpmc-nand.c| 73 +++ arch/arm/mach-omap2/gpmc.c | 76 arch/arm/plat-omap/include/plat/gpmc.h |1 + arch/arm/plat-omap/include/plat/nand.h |1 + 4 files changed, 123 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c| 21 +
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 9434c80..96f0c7f 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -22,6 +22,7 @@
#define WR_RD_PIN_MONITORING 0x0060
static struct omap_nand_platform_data *gpmc_nand_data;
+static struct gpmc_timings gpmc_default_timings;
static struct resource gpmc_nand_resource = {
.flags = IORESOURCE_MEM,
@@ -65,21 +66,28 @@ static void omap2_nand_gpmc_round_timings(struct
gpmc_timings *src,
static int omap2_nand_gpmc_retime(void)
{
+ struct device *dev = gpmc_nand_device.dev;
+ struct gpmc_timings *gpmc_t = gpmc_nand_data-gpmc_t;
struct gpmc_timings t;
int err;
- if (!gpmc_nand_data-gpmc_t)
+ if (!gpmc_t) {
+ dev_warn(dev, No timings provided, skipping retime\n);
return 0;
+ }
- memset(t, 0, sizeof(t));
- omap2_nand_gpmc_round_timings(gpmc_nand_data-gpmc_t, t);
+ if (!gpmc_nand_data-keep_timings) {
+ memset(t, 0, sizeof(t));
+ omap2_nand_gpmc_round_timings(gpmc_nand_data-gpmc_t, t);
+ gpmc_t = t;
+ }
/* Configure GPMC */
gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
GPMC_CONFIG1_DEVICETYPE_NAND);
- err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
if (err)
return err;
@@ -116,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
+ if (gpmc_nand_data-keep_timings) {
+ gpmc_cs_get_timings(gpmc_nand_data-cs, gpmc_default_timings);
+ gpmc_nand_data-gpmc_t = gpmc_default_timings;
+ }
+
err = gpmc_nand_setup();
if (err 0) {
dev_err(dev, NAND platform setup failed: %d\n, err);
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index f8efd54..0f727ea 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -24,6 +24,7 @@ struct omap_nand_platform_data {
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
int devsize;
+ boolkeep_timings;
};
/* size (4 KiB) for IO mapping */
--
1.6.6.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] omap: gpmc: add gpmc_cs_get_timings
Add gpmc_cs_get_timings counterpart of gpmc_cs_set_timings and
convinience macros to read particular timing configuration fields
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc.c | 76
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..527a0da 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -163,6 +163,36 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
}
#ifdef DEBUG
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
+ const char *name)
+#else
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit)
+#endif
+{
+ u32 l;
+ int ticks, mask, nr_bits, time;
+
+ nr_bits = end_bit - st_bit + 1;
+ mask = ((1 nr_bits) - 1);
+
+ l = gpmc_cs_read_reg(cs, reg);
+ ticks = (l st_bit) mask;
+
+ if (ticks == 0)
+ time = 0;
+ else
+ time = gpmc_ticks_to_ns(ticks);
+
+#ifdef DEBUG
+ printk(KERN_INFO
+ GPMC CS%d: %-10s: %3d ticks, %3d ns\n,
+ cs, name, ticks, time);
+#endif
+
+ return time;
+}
+
+#ifdef DEBUG
static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
int time, const char *name)
#else
@@ -206,10 +236,14 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
if (set_gpmc_timing_reg(cs, (reg), (st), (end), \
t-field, #field) 0) \
return -1
+#define GPMC_GET_ONE(reg, st, end, field) \
+ t-field = get_gpmc_timing_reg(cs, (reg), (st), (end), #field)
#else
#define GPMC_SET_ONE(reg, st, end, field) \
if (set_gpmc_timing_reg(cs, (reg), (st), (end), t-field) 0) \
return -1
+#define GPMC_GET_ONE(reg, st, end, field) \
+ t-field = get_gpmc_timing_reg(cs, (reg), (st), (end))
#endif
int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
@@ -227,6 +261,48 @@ int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
return div;
}
+void gpmc_cs_get_timings(int cs, struct gpmc_timings *t)
+{
+ int div;
+ u32 l;
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 0, 3, cs_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 8, 12, cs_rd_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 16, 20, cs_wr_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 0, 3, adv_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 8, 12, adv_rd_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 16, 20, adv_wr_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 0, 3, oe_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 8, 12, oe_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 16, 19, we_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 24, 28, we_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 0, 4, rd_cycle);
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 8, 12, wr_cycle);
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 16, 20, access);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+
+ if (cpu_is_omap34xx()) {
+ GPMC_GET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+ GPMC_GET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
+ }
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
+ div = (l 0x03) + 1;
+#ifdef DEBUG
+ printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
+ cs, (div * gpmc_get_fclk_period()) / 1000, div);
+#endif
+ t-sync_clk = (div * gpmc_get_fclk_period()) / 1000;
+ } else {
+ t-sync_clk = 0;
+ }
+}
+
int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
int div;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 145838a..5c345f1 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -102,6 +102,7 @@ extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_cs_calc_divider(int cs, unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
+extern void gpmc_cs_get_timings(int cs, struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
--
1.6.6.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Vimal Singh wrote:
On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport m...@compulab.co.il wrote:
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c| 19 ++-
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..7c6c027 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -22,6 +22,7 @@
#define WR_RD_PIN_MONITORING 0x0060
static struct omap_nand_platform_data *gpmc_nand_data;
+static struct gpmc_timings gpmc_default_timings;
static struct resource gpmc_nand_resource = {
.flags = IORESOURCE_MEM,
@@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
+static void gpmc_nand_detect_timings(void)
+{
+ struct gpmc_timings t;
+
+ memset(t, 0, sizeof(t));
+ gpmc_cs_get_timings(gpmc_nand_data-cs, gpmc_default_timings);
+}
+
static int omap2_nand_gpmc_retime(void)
{
+ struct device *dev = gpmc_nand_device.dev;
struct gpmc_timings t;
int err;
- if (!gpmc_nand_data-gpmc_t)
+ if (!gpmc_nand_data-gpmc_t) {
+ dev_warn(dev, No timings provided, skipping retime\n);
return 0;
+ }
memset(t, 0, sizeof(t));
t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
@@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
+ if (gpmc_nand_data-keep_timings) {
+ gpmc_nand_detect_timings();
+ gpmc_nand_data-gpmc_t = gpmc_default_timings;
+ }
+
I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
As there, once we get old/default timings we can simply skip the
rounding part and directly jump to setting the timings.
This way it would be the same as to pass 'gpmc_nand_data-gpmc_t =
NULL'. If I correctly understood the previous comments ([1]), the
problem with skipping retime is that when L3 clock changes, the gpmc
timings became wrong. So, if we convert old/default timings to
nanoseconds early during startup every time retime is called it will use
the timing settings in nanoseconds thus yielding proper gpmc registers
configuration.
And, if I'm not terribly mistaken retime should be called each time L3
frequency changes, though with current kernel it's not yet the case...
--
[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/34164/focus=34558
Rest looks fine to me.
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Vimal Singh wrote:
On Thu, Apr 29, 2010 at 12:23 PM, Mike Rapoport m...@compulab.co.il wrote:
Vimal Singh wrote:
On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport m...@compulab.co.il
wrote:
Signed-off-by: Mike Rapoport m...@compulab.co.il
+ if (gpmc_nand_data-keep_timings) {
+ gpmc_nand_detect_timings();
+ gpmc_nand_data-gpmc_t = gpmc_default_timings;
+ }
+
I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
As there, once we get old/default timings we can simply skip the
rounding part and directly jump to setting the timings.
This way it would be the same as to pass 'gpmc_nand_data-gpmc_t =
NULL'. If I correctly understood the previous comments ([1]), the
problem with skipping retime is that when L3 clock changes, the gpmc
timings became wrong. So, if we convert old/default timings to
nanoseconds early during startup every time retime is called it will use
the timing settings in nanoseconds thus yielding proper gpmc registers
configuration.
OK. Then I think we can at least put __rounding__ code inside an 'if'
case, something like:
if (!gpmc_nand_data-keep_timings) {
...
do rounding for supplied timings from board file.
...
}
Sure, no problem.
And, if I'm not terribly mistaken retime should be called each time L3
frequency changes, though with current kernel it's not yet the case...
Yes. This is still left.
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in omap2_nand_gpmc_retime? (was: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied)
Tony Lindgren wrote: * Mike Rapoport m...@compulab.co.il [100427 00:40]: Tony Lindgren wrote: * Mike Rapoport m...@compulab.co.il [100422 01:41]: Ghorai, Sukumar wrote: CM-T35, for instance can be assembled with different NAND flash chips. Besides, boards that use NAND as primary boot device, we anyway depend on proper GPMC configuration in the bootloader chain. Having ability to define GPMC timings in the kernel and keep the settings made by the bootloader adds flexibility level for board designers. Not implementing the retime function for GPMC will cause issues with PM as you cannot scale the L3 frequency without breaking your GPMC timings. I agree that without retime function scaling the frequency will break the GPMC timings. But my point was that there should be an _option_ to keep the timings defined by the bootloader rather than enforce board files to specify timings. Sure. Can you please check one more time your patch and what is still missing after Stanley's fix? That's now in omap-fixes and master branches as commit 11e1ef2d105900a302b7ca92bcaf96a96d0274a1. Since skipping the retime function will break gpmc timings in PM-enabled kernel, we need to implement this option in smarter way. E.g. something like: Yeah we should print some warning if the retime function is not implemented as it can cause mysterious bugs later on. I guess implementing a dummy retime function would be best as then the warning would be related to the actual L3 rate change. While working on implementation of gpmc_nand_detect_timings I've seen that omap2_nand_gpmc_retime converts the timings supplied by the platform to ticks and passes it to gpmc_cs_set_timings which in turn converts the timings to ticks. Is it a bug or am I missing something? Regards, Tony -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in omap2_nand_gpmc_retime?
Vimal Singh wrote: On Wed, Apr 28, 2010 at 8:35 PM, Mike Rapoport m...@compulab.co.il wrote: While working on implementation of gpmc_nand_detect_timings I've seen that omap2_nand_gpmc_retime converts the timings supplied by the platform to ticks and passes it to gpmc_cs_set_timings which in turn converts the timings to ticks. Is it a bug or am I missing something? No, 'omap2_nand_gpmc_retime' does not convert timings supplied by the platform to tick. Rather it rounds the timings passed by the platform to timings in units of 'tick' period. Thanks for the clarification. I still wonder why is this necessary. Anyway gpmc_set_cs_timings will do the conversion? -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
These patches add ability to keep GPMC timings configured by the bootloader. The platforms have to either define NAND GPMC timinings explicitly via gpmc_t field of omap_nand_platform_data or set keep_timings flag to allow detection of current timing configuration and its subsequent use in omap2_nand_gpmc_retime. The following changes since commit 104a77440f05430f29f9d3f4ecb88c1536819585: Tony Lindgren (1): Linux-omap rebuilt: Merged in i2c-omap-for-ben branch and cleaned up cbus branch Mike Rapoport (2): omap: gpmc: add gpmc_cs_get_timings omap: gpmc-nand: add ability to keep timings defined by the bootloader arch/arm/mach-omap2/gpmc-nand.c| 19 +++- arch/arm/mach-omap2/gpmc.c | 79 arch/arm/plat-omap/include/plat/gpmc.h |1 + arch/arm/plat-omap/include/plat/nand.h |1 + 4 files changed, 99 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap: gpmc: add gpmc_cs_get_timings
Add gpmc_cs_get_timings counterpart of gpmc_cs_set_timings and
convinience macros to read particular timing configuration fields
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc.c | 79
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..416336f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -163,6 +163,36 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
}
#ifdef DEBUG
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
+ const char *name)
+#else
+static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit)
+#endif
+{
+ u32 l;
+ int ticks, mask, nr_bits, time;
+
+ nr_bits = end_bit - st_bit + 1;
+ mask = ((1 nr_bits) - 1);
+
+ l = gpmc_cs_read_reg(cs, reg);
+ ticks = (l st_bit) mask;
+
+ if (ticks == 0)
+ time = 0;
+ else
+ time = gpmc_ticks_to_ns(ticks);
+
+#ifdef DEBUG
+ printk(KERN_INFO
+ GPMC CS%d: %-10s: %3d ticks, %3d ns\n,
+ cs, name, ticks, time);
+#endif
+
+ return time;
+}
+
+#ifdef DEBUG
static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
int time, const char *name)
#else
@@ -206,10 +236,14 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
if (set_gpmc_timing_reg(cs, (reg), (st), (end), \
t-field, #field) 0) \
return -1
+#define GPMC_GET_ONE(reg, st, end, field) \
+ t-field = get_gpmc_timing_reg(cs, (reg), (st), (end), #field)
#else
#define GPMC_SET_ONE(reg, st, end, field) \
if (set_gpmc_timing_reg(cs, (reg), (st), (end), t-field) 0) \
return -1
+#define GPMC_GET_ONE(reg, st, end, field) \
+ t-field = get_gpmc_timing_reg(cs, (reg), (st), (end))
#endif
int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
@@ -227,6 +261,51 @@ int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
return div;
}
+void gpmc_cs_get_timings(int cs, struct gpmc_timings *t)
+{
+ int div;
+ u32 l;
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 0, 3, cs_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 8, 12, cs_rd_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG2, 16, 20, cs_wr_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 0, 3, adv_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 8, 12, adv_rd_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG3, 16, 20, adv_wr_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 0, 3, oe_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 8, 12, oe_off);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 16, 19, we_on);
+ GPMC_GET_ONE(GPMC_CS_CONFIG4, 24, 28, we_off);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 0, 4, rd_cycle);
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 8, 12, wr_cycle);
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 16, 20, access);
+
+ GPMC_GET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+
+ if (cpu_is_omap34xx()) {
+ GPMC_GET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+ GPMC_GET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
+ }
+
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
+ div = (l 0x03) + 1;
+#ifdef DEBUG
+ printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
+ cs, (div * gpmc_get_fclk_period()) / 1000, div);
+#endif
+ t-sync_clk = (div * gpmc_get_fclk_period()) / 1000;
+ } else {
+ t-sync_clk = 0;
+ }
+
+ gpmc_dump_regs(cs);
+ gpmc_dump_timings(t);
+}
+
int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
int div;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 145838a..5c345f1 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -102,6 +102,7 @@ extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_cs_calc_divider(int cs, unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
+extern void gpmc_cs_get_timings(int cs, struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
--
1.6.6.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c| 19 ++-
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..7c6c027 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -22,6 +22,7 @@
#define WR_RD_PIN_MONITORING 0x0060
static struct omap_nand_platform_data *gpmc_nand_data;
+static struct gpmc_timings gpmc_default_timings;
static struct resource gpmc_nand_resource = {
.flags = IORESOURCE_MEM,
@@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
+static void gpmc_nand_detect_timings(void)
+{
+ struct gpmc_timings t;
+
+ memset(t, 0, sizeof(t));
+ gpmc_cs_get_timings(gpmc_nand_data-cs, gpmc_default_timings);
+}
+
static int omap2_nand_gpmc_retime(void)
{
+ struct device *dev = gpmc_nand_device.dev;
struct gpmc_timings t;
int err;
- if (!gpmc_nand_data-gpmc_t)
+ if (!gpmc_nand_data-gpmc_t) {
+ dev_warn(dev, No timings provided, skipping retime\n);
return 0;
+ }
memset(t, 0, sizeof(t));
t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
@@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
+ if (gpmc_nand_data-keep_timings) {
+ gpmc_nand_detect_timings();
+ gpmc_nand_data-gpmc_t = gpmc_default_timings;
+ }
+
err = gpmc_nand_setup();
if (err 0) {
dev_err(dev, NAND platform setup failed: %d\n, err);
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index f8efd54..0f727ea 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -24,6 +24,7 @@ struct omap_nand_platform_data {
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
int devsize;
+ boolkeep_timings;
};
/* size (4 KiB) for IO mapping */
--
1.6.6.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [100422 01:41]:
Ghorai, Sukumar wrote:
CM-T35, for instance can be assembled with different NAND flash
chips. Besides, boards that use NAND as primary boot device, we
anyway depend on proper GPMC configuration in the bootloader chain.
Having ability to define GPMC timings in the kernel and keep the
settings made by the bootloader adds flexibility level for board
designers.
Not implementing the retime function for GPMC will cause issues
with PM as you cannot scale the L3 frequency without breaking
your GPMC timings.
I agree that without retime function scaling the frequency will break
the GPMC timings. But my point was that there should be an _option_ to
keep the timings defined by the bootloader rather than enforce board
files to specify timings.
Since skipping the retime function will break gpmc timings in PM-enabled
kernel, we need to implement this option in smarter way. E.g.
something like:
diff --git a/arch/arm/mach-omap2/gpmc-nand.c
b/arch/arm/mach-omap2/gpmc-nand.c
index 64d74f0..65ac0d0 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -34,6 +34,12 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
+static int gpmc_nand_detect_timings(void)
+{
+ /* FIXME: implement timings detection */
+ return -EINVAL;
+}
+
static int omap2_nand_gpmc_retime(void)
{
struct gpmc_timings t;
@@ -109,6 +115,14 @@ int __init gpmc_nand_init(struct
omap_nand_platform_data *_nand_data)
return err;
}
+ if (gpmc_nand_data-keep_timings) {
+ err = gpmc_nand_detect_timings();
+ if (err 0) {
+ dev_err(dev, Cannot detect GPMC timings\n);
+ return err;
+ }
+ }
+
err = gpmc_nand_setup();
if (err 0) {
dev_err(dev, NAND platform setup failed: %d\n, err);
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6ba88d2..cf05d2d 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -24,6 +24,7 @@ struct omap_nand_platform_data {
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
int devsize;
+ boolkeep_timings;
};
/* size (4 KiB) for IO mapping */
Tony
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Ghorai, Sukumar wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Mike Rapoport
Sent: 2010-04-22 10:50
To: linux-omap@vger.kernel.org
Cc: Tony Lindgren; Mike Rapoport
Subject: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Any comments on this?
Mike Rapoport wrote:
The gpmc nand infrastructure crashes when there no timing structure
supplied in the omap_nand_platform_data. Adding check for
gpmc_nand_data-gpmc_t pointer validity resolves the crash and allows to
continue nand initialization without modifying gpmc timings.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-
nand.c
index 64d74f0..3629da3 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -83,6 +83,11 @@ static int gpmc_nand_setup(void)
{
struct device *dev = gpmc_nand_device.dev;
+ if (!gpmc_nand_data-gpmc_t) {
+ dev_info(dev, Keeping gpmc timings\n);
+ return 0;
+ }
[Ghorai] This is the only time its setup the gpmc timings for NAND. And it
should return as error.
Somehow I was under the impression that X-Loader sets up the NAND
timings even if booted from OneNAND or MMC. Apparently I'm wrong :).
What do you think about adding a flag to omap_nand_platform_data that
will allow to keep timings if they were already configured by the
bootloader? This is really useful when the board can be assembled with
different kinds of NAND flashes.
+
/* Set timings in GPMC */
if (omap2_nand_gpmc_retime() 0) {
dev_err(dev, Unable to set gpmc timings\n);
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: cm-t35: enable ds2786 battery gas gauge
From: Yulia Vilensky vilen...@compulab.co.il
This patch depends on ds2786 patch [1], but it does not break anything
even without the ds2786 battery support.
[1] http://lkml.org/lkml/2010/4/22/48
--
Signed-off-by: Yulia Vilensky vilen...@compulab.co.il
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 2de4f79..c28e7bb 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -687,10 +687,23 @@ static struct i2c_board_info __initdata
cm_t35_i2c_boardinfo[] = {
},
};
+#define DS2786_RSNS18 /* Constant sense resistor value */
+
+static int cm_t35_ds2786_rsns_val = DS2786_RSNS;
+
+static struct i2c_board_info __initdata cm_t35_i2c3_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(ds2786, 0x36),
+ .platform_data = cm_t35_ds2786_rsns_val,
+ },
+};
+
static void __init cm_t35_init_i2c(void)
{
omap_register_i2c_bus(1, 2600, cm_t35_i2c_boardinfo,
ARRAY_SIZE(cm_t35_i2c_boardinfo));
+ omap_register_i2c_bus(3, 400, cm_t35_i2c3_boardinfo,
+ ARRAY_SIZE(cm_t35_i2c3_boardinfo));
}
static struct omap_board_config_kernel cm_t35_config[] __initdata = {
--
1.6.6.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: cm-t35: enable ds2786 battery gas gauge
Please discard. Sorry for the noise.
Mike Rapoport wrote:
From: Yulia Vilensky vilen...@compulab.co.il
This patch depends on ds2786 patch [1], but it does not break anything
even without the ds2786 battery support.
[1] http://lkml.org/lkml/2010/4/22/48
--
Signed-off-by: Yulia Vilensky vilen...@compulab.co.il
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 2de4f79..c28e7bb 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -687,10 +687,23 @@ static struct i2c_board_info __initdata
cm_t35_i2c_boardinfo[] = {
},
};
+#define DS2786_RSNS18 /* Constant sense resistor value */
+
+static int cm_t35_ds2786_rsns_val = DS2786_RSNS;
+
+static struct i2c_board_info __initdata cm_t35_i2c3_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(ds2786, 0x36),
+ .platform_data = cm_t35_ds2786_rsns_val,
+ },
+};
+
static void __init cm_t35_init_i2c(void)
{
omap_register_i2c_bus(1, 2600, cm_t35_i2c_boardinfo,
ARRAY_SIZE(cm_t35_i2c_boardinfo));
+ omap_register_i2c_bus(3, 400, cm_t35_i2c3_boardinfo,
+ ARRAY_SIZE(cm_t35_i2c3_boardinfo));
}
static struct omap_board_config_kernel cm_t35_config[] __initdata = {
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Ghorai, Sukumar wrote:
-Original Message-
From: Mike Rapoport [mailto:m...@compulab.co.il]
Sent: 2010-04-22 12:29
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; Tony Lindgren
Subject: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Ghorai, Sukumar wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Mike Rapoport
Sent: 2010-04-22 10:50
To: linux-omap@vger.kernel.org
Cc: Tony Lindgren; Mike Rapoport
Subject: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Any comments on this?
Mike Rapoport wrote:
The gpmc nand infrastructure crashes when there no timing structure
supplied in the omap_nand_platform_data. Adding check for
gpmc_nand_data-gpmc_t pointer validity resolves the crash and allows
to
continue nand initialization without modifying gpmc timings.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-
omap2/gpmc-
nand.c
index 64d74f0..3629da3 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -83,6 +83,11 @@ static int gpmc_nand_setup(void)
{
struct device *dev = gpmc_nand_device.dev;
+ if (!gpmc_nand_data-gpmc_t) {
+ dev_info(dev, Keeping gpmc timings\n);
+ return 0;
+ }
[Ghorai] This is the only time its setup the gpmc timings for NAND. And
it should return as error.
Somehow I was under the impression that X-Loader sets up the NAND
timings even if booted from OneNAND or MMC. Apparently I'm wrong :).
What do you think about adding a flag to omap_nand_platform_data that
will allow to keep timings if they were already configured by the
bootloader? This is really useful when the board can be assembled with
different kinds of NAND flashes.
[Ghorai] firstly we should not depend on u-boot/ x-loader for this GPMC
configuration.
I think each board will have only one device finally.
CM-T35, for instance can be assembled with different NAND flash chips.
Besides, boards that use NAND as primary boot device, we anyway depend
on proper GPMC configuration in the bootloader chain. Having ability to
define GPMC timings in the kernel and keep the settings made by the
bootloader adds flexibility level for board designers.
+
/* Set timings in GPMC */
if (omap2_nand_gpmc_retime() 0) {
dev_err(dev, Unable to set gpmc timings\n);
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely yours,
Mike.
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Any comments on this?
Mike Rapoport wrote:
The gpmc nand infrastructure crashes when there no timing structure
supplied in the omap_nand_platform_data. Adding check for
gpmc_nand_data-gpmc_t pointer validity resolves the crash and allows to
continue nand initialization without modifying gpmc timings.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 64d74f0..3629da3 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -83,6 +83,11 @@ static int gpmc_nand_setup(void)
{
struct device *dev = gpmc_nand_device.dev;
+ if (!gpmc_nand_data-gpmc_t) {
+ dev_info(dev, Keeping gpmc timings\n);
+ return 0;
+ }
+
/* Set timings in GPMC */
if (omap2_nand_gpmc_retime() 0) {
dev_err(dev, Unable to set gpmc timings\n);
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
Hi David,
David Vrabel wrote:
These patches add support for SDIO cards to the omap_hsmmc driver.
Power management changes to prevent SDIO cards from being turned off
and losing all state, and card interrupts.
I've tested your patches with libertas_sdio and after several small
additions I've made it work.
drivers/mmc/host/omap_hsmmc.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 53fa85d..6ed71b7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -82,6 +82,7 @@
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
@@ -189,6 +190,7 @@ struct omap_hsmmc_host {
int protect_card;
int reqs_blocked;
int use_reg;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -763,16 +765,19 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
struct mmc_data *data)
{
int cmdreg = 0, resptype = 0, cmdtype = 0;
+ int int_en_mask = INT_EN_MASK;
dev_dbg(mmc_dev(host-mmc), %s: CMD%d, argument 0x%08x\n,
mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
host-cmd = cmd;
if (host-use_dma)
- OMAP_HSMMC_WRITE(host-base, IE,
-INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE));
- else
- OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ int_en_mask = ~(BRR_ENABLE | BWR_ENABLE);
+
+ if (host-sdio_int)
+ int_en_mask |= CIRQ;
+
+ OMAP_HSMMC_WRITE(host-base, IE, int_en_mask);
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
@@ -1619,10 +1624,12 @@ static void omap_hsmmc_enable_sdio_irq(struct mmc_host
*mmc, int enable)
if (enable) {
clk_enable(host-fclk);
ie |= CIRQ_ENABLE;
- con |= CTPL;
+ con |= CTPL | CLKEXTFREE;
+ host-sdio_int = 1;
} else {
ie = ~CIRQ_ENABLE;
- con = ~CTPL;
+ con = ~(CTPL | CLKEXTFREE);
+ host-sdio_int = 0;
}
OMAP_HSMMC_WRITE(host-base, CON, con);
OMAP_HSMMC_WRITE(host-base, IE, ie);
--
1.6.4.4
I've been unable to test these exact patches as I only have an N900 for
testing and the N900 support in mainline is incomplete.
Changes since v1:
- (hopefully) get all cards working again by removing a second call to
read MMCi_STAT in the interrupt handler.
- flush posted writes after enabling/disabling SDIO interrupts.
- tweak the FIXME commit on disabling FCLK to better match what really
going on (at least I think so anyway).
David Vrabel (2):
mmc: omap_hsmmc: don't turn SDIO cards off when idle
mmc: omap_hsmmc: enable SDIO card interrupts
drivers/mmc/host/omap_hsmmc.c | 114 -
1 files changed, 79 insertions(+), 35 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards
Madhusudhan wrote:
snip
Also, keep in mind that the buffers for transfers must begin and end on
a word boundary. The OMAP's DMA controller can only transfer whole
words to the MMC FIFO.
I've slightly modified your patch mmc: omap_hsmmc: use packet sync'd DMA
and it
seems to work now, at least with SD card and libertas_sdio:
Mike,
As per the latest discussion, David replied that this patch is not needed
and FRAME sync just works fine. So, without this patch does SDIO int
functionality work for you?
I had no luck with David's patches for SDIO IRQ, however with patches previously
sent by Phaneendra ([1]) and fclk hack ([2]) SDIO IRQ works...
Without the fclk hack I get kernel panic in the omap_hsmmc:
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0b4130
Internal error: : 1028 [#1]
last sysfs file: /sys/class/net/lo/operstate
Modules linked in: libertas_sdio libertas cfg80211 lib80211 firmware_class
ads7846 twl4030_keypad
CPU: 0Not tainted (2.6.33-rc4-07078-gd8ebff3-dirty #8)
PC is at omap_hsmmc_irq+0xa8/0x59c
LR is at try_to_wake_up+0xd8/0xf4
pc : [c021c49c]lr : [c004f37c]psr: 6193
sp : c03b5e28 ip : c03c3e08 fp :
r10: 001f r9 : 411fc083 r8 :
r7 : cf9b79c0 r6 : 0100 r5 : 0056 r4 : cf9b7800
r3 : r2 : fa0b4000 r1 : 2193 r0 : 0001
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 8faf0019 DAC: 0017
Process swapper (pid: 0, stack limit = 0xc03b42e8)
Stack: (0xc03b5e28 to 0xc03b6000)
5e20: 4c400e5f 20b6 c006b8ec c03c2190
5e40: c03c2190 c03c1ce8 c03c2190 c03b5e74 c004e020 c03c2190 c03c2190
5e60: c03c2190 01dcd817 004b 515f5afc 20b8 c006b8ec
5e80: 518247cf c040b9a0 c03b5ed8 0034 515f5afc
5ea0: 000225c1 1235a688 c0036e14 c03c0dc8 c006bb88 004a
5ec0: 6c00 15e77dcf 0016 4000 ff40 15e77dcf 84af
5ee0: 84b1 0001 84af c005b4ac
5f00: 00773594 00773594 0001 c006f51c 00773594
5f20: 16d14154 0035 2ff68e8c cf988f40 0056 80023164
5f40: 001f c007972c c03c5b00 0056 c0025014 c03b7bd8 80023164 c007b680
5f60: 0056 c0025014 c002b070 fa20 c0025014 c002ba30
5f80: 1235a688 4013 c03e94d4 c03b4000 c03e8adc c0025014 c03b7bd8
5fa0: 80023164 411fc083 001f cfbfdae0 c03b5fc8 c003bff4 c003c02c
5fc0: 6013 c03b4000 c002d2e0 c040d250 c0008b1c c00084e8
5fe0: c0025018 10c53c7d c03e8c04 80008034
[c021c49c] (omap_hsmmc_irq+0xa8/0x59c) from [c007972c]
(handle_IRQ_event+0x34/0xf0)
[c007972c] (handle_IRQ_event+0x34/0xf0) from [c007b680]
(handle_level_irq+0xdc/0xf4)
[c007b680] (handle_level_irq+0xdc/0xf4) from [c002b070]
(asm_do_IRQ+0x70/0x90)
[c002b070] (asm_do_IRQ+0x70/0x90) from [c002ba30] (__irq_svc+0x30/0x80)
Exception stack(0xc03b5f80 to 0xc03b5fc8)
5f80: 1235a688 4013 c03e94d4 c03b4000 c03e8adc c0025014 c03b7bd8
5fa0: 80023164 411fc083 001f cfbfdae0 c03b5fc8 c003bff4 c003c02c
5fc0: 6013
[c002ba30] (__irq_svc+0x30/0x80) from [c003c02c] (omap3_pm_idle+0x48/0x4c)
[c003c02c] (omap3_pm_idle+0x48/0x4c) from [c002d2e0] (cpu_idle+0x48/0x88)
[c002d2e0] (cpu_idle+0x48/0x88) from [c0008b1c] (start_kernel+0x24c/0x2a4)
[c0008b1c] (start_kernel+0x24c/0x2a4) from [80008034] (0x80008034)
Code: e5973008 e353 1a05 e597203c (e5923130)
---[ end trace 2011509d5458c456 ]---
Kernel panic - not syncing: Fatal exception in interrupt
[1] http://thread.gmane.org/gmane.linux.kernel.mmc/967
[2] http://thread.gmane.org/gmane.linux.kernel.mmc/1107/focus=1109
Regards,
Madhu
---
drivers/mmc/host/omap_hsmmc.c | 23 ---
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..5408bcb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -114,6 +114,7 @@
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MASTER_CLOCK 9600
+#define OMAP_HSMMC_FIFO_WORDS (512/4)
#define DRIVER_NAMEmmci-omap-hs
/* Timeouts for entering power saving states on inactivity, msec */
@@ -884,24 +885,24 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
{
int blksz, nblk, dma_ch;
+ blksz = host-data-blksz;
+ nblk = sg_dma_len(sgl) / blksz;
+
dma_ch = host-dma_ch;
if (data-flags MMC_DATA_WRITE) {
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0, blksz / 4);
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards
Mike Rapoport wrote:
David Vrabel wrote:
Mike Rapoport wrote:
I've started to apply the patches one by one and after the first patch
is applied, the SD card works Ok, but libertas fails to initialize with
the following messages:
modprobe libertas_sdio
[ 82.233489] lib80211: common routines for IEEE802.11 drivers
[ 82.833251] cfg80211: Calling CRDA to update world regulatory domain
[ 83.327911] libertas_sdio: Libertas SDIO driver
[ 83.332489] libertas_sdio: Copyright Pierre Ossman
[ 83.348510] libertas_sdio mmc1:0001:1: firmware: requesting
sd8686_helper.bin
[ 83.497619] libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
[ 83.679229] DMA synchronization event drop occurred with device 47
What block size are you using? It looks like you're using something
less than 512. I've checked the spec again and the DMA packet size
should be the block size in words (and not the FIFO depth).
It's quite possible. I haven't dig too much and I really don't know how
exactly
libertas driver sends/receives the data... I'll continue testing and will try
to get
some more meaningful info
Also, keep in mind that the buffers for transfers must begin and end on
a word boundary. The OMAP's DMA controller can only transfer whole
words to the MMC FIFO.
I've slightly modified your patch mmc: omap_hsmmc: use packet sync'd DMA and
it
seems to work now, at least with SD card and libertas_sdio:
---
drivers/mmc/host/omap_hsmmc.c | 23 ---
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..5408bcb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -114,6 +114,7 @@
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MASTER_CLOCK 9600
+#define OMAP_HSMMC_FIFO_WORDS (512/4)
#define DRIVER_NAMEmmci-omap-hs
/* Timeouts for entering power saving states on inactivity, msec */
@@ -884,24 +885,24 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
{
int blksz, nblk, dma_ch;
+ blksz = host-data-blksz;
+ nblk = sg_dma_len(sgl) / blksz;
+
dma_ch = host-dma_ch;
if (data-flags MMC_DATA_WRITE) {
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0, blksz / 4);
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
sg_dma_address(sgl), 0, 0);
} else {
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0, blksz / 4);
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
sg_dma_address(sgl), 0, 0);
}
- blksz = host-data-blksz;
- nblk = sg_dma_len(sgl) / blksz;
-
omap_set_dma_transfer_params(dma_ch, OMAP_DMA_DATA_TYPE_S32,
- blksz / 4, nblk, OMAP_DMA_SYNC_FRAME,
+ blksz / 4, nblk, OMAP_DMA_SYNC_PACKET,
omap_hsmmc_get_dma_sync_dev(host, data),
!(data-flags MMC_DATA_WRITE));
@@ -944,17 +945,9 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status, void
*data)
static int omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host,
struct mmc_request *req)
{
- int dma_ch = 0, ret = 0, err = 1, i;
+ int dma_ch = 0, ret = 0, err = 1;
struct mmc_data *data = req-data;
- /* Sanity check: all the SG entries must be aligned by block size. */
- for (i = 0; i data-sg_len; i++) {
- struct scatterlist *sgl;
-
- sgl = data-sg + i;
- if (sgl-length % data-blksz)
- return -EINVAL;
- }
if ((data-blksz % 4) != 0)
/* REVISIT: The MMC buffer increments only when MSB is written.
* Return error for blksz which is non multiple of four.
--
1.6.4.4
David
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards
David Vrabel wrote: Mike Rapoport wrote: Hi David, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Less restrictions on the sizes of transfers, power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. I've tried your patches on CM-T35 that has 8686 SDIO and the result was absence of MMC/SDIO devices at all :( Morover, kmmcd hangs: [ 399.427764] INFO: task kmmcd:149 blocked for more than 120 seconds. [...] [ 399.485290] [c01e6264] (mmc_wait_for_cmd+0x64/0x74) from [c01e86b0] (mmc_go_idle+0x60/0xac) I suspect interrupts aren't enabled correctly as this command does not complete. Try reverting this hunk. @@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host, struct mmc_command *cmd, mmc_hostname(host-mmc), cmd-opcode, cmd-arg); host-cmd = cmd; - /* -* Clear status bits and enable interrupts -*/ - OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR); - OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK); - if (host-use_dma) OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE)); Reverting this hunk and reverting/adjusting changes to IRQ handler makes SD card recognizable again. No luck with SDIO interrupts though... I've managed to get libertas_sdio loading properly, but I get lookups when there's some traffic on the interface: [ 1277.755859] BUG: soft lockup - CPU#0 stuck for 61s! [libertas_sdio/0:1212] [ 1277.762786] Modules linked in: libertas_sdio libertas cfg80211 lib80211 firmware_class omap_hsmmc ads7846 twl4030_keypad [ 1277.773803] [ 1277.775299] Pid: 1212, comm: libertas_sdio/0 [ 1277.780029] CPU: 0Not tainted (2.6.33-rc4-07945-gd19df2c-dirty #173) [ 1277.786895] PC is at handle_IRQ_event+0x20/0xf0 [ 1277.791442] LR is at handle_level_irq+0xdc/0xf4 [ 1277.796020] pc : [c0074ea8]lr : [c0076e10]psr: 4113 [ 1277.796020] sp : cfb61ce8 ip : fb058000 fp : fb058018 [ 1277.807556] r10: c0382508 r9 : r8 : 0022 [ 1277.812805] r7 : 0001 r6 : r5 : 0143 r4 : cf990c80 [ 1277.819366] r3 : 0088 r2 : c03c815c r1 : cf990c80 r0 : 0143 [ 1277.825958] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 1277.833282] Control: 10c5387d Table: 8fa1c019 DAC: 0017 David -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Input: ads7846: add regulator support
Just one nitpicking comment below:
On Sat, Feb 13, 2010 at 6:31 PM, Grazvydas Ignotas nota...@gmail.com wrote:
The ADS7846/TSC2046 touchscreen controllers can (and usually are)
connected to various regulators for power, so add regulator support.
Valid regulator will now be required, so boards without complete
regulator setup should either disable regulator framework or enable
CONFIG_REGULATOR_DUMMY.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/input/touchscreen/ads7846.c | 28 +++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index 52d2ca1..8b05d8e 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -27,6 +27,7 @@
#include linux/gpio.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
+#include linux/regulator/consumer.h
#include asm/irq.h
/*
@@ -85,6 +86,7 @@ struct ads7846 {
char name[32];
struct spi_device *spi;
+ struct regulator *reg;
#if defined(CONFIG_HWMON) || defined(CONFIG_HWMON_MODULE)
struct attribute_group *attr_group;
@@ -788,6 +790,8 @@ static void ads7846_disable(struct ads7846 *ts)
}
}
+ regulator_disable(ts-reg);
+
/* we know the chip's in lowpower mode since we always
* leave it that way after every request
*/
@@ -799,6 +803,8 @@ static void ads7846_enable(struct ads7846 *ts)
if (!ts-disabled)
return;
+ regulator_enable(ts-reg);
+
ts-disabled = 0;
ts-irq_disabled = 0;
enable_irq(ts-spi-irq);
@@ -1139,6 +1145,19 @@ static int __devinit ads7846_probe(struct spi_device
*spi)
ts-last_msg = m;
+ ts-reg = regulator_get(spi-dev, vcc);
vcc is way too generic name. What about vcc-ts or vcc-touch?
+ if (IS_ERR(ts-reg)) {
+ dev_err(spi-dev, unable to get regulator: %ld\n,
+ PTR_ERR(ts-reg));
+ goto err_free_gpio;
+ }
+
+ err = regulator_enable(ts-reg);
+ if (err) {
+ dev_err(spi-dev, unable to enable regulator: %d\n, err);
+ goto err_put_regulator;
+ }
+
if (request_irq(spi-irq, ads7846_irq, IRQF_TRIGGER_FALLING,
spi-dev.driver-name, ts)) {
dev_info(spi-dev,
@@ -1148,7 +1167,7 @@ static int __devinit ads7846_probe(struct spi_device
*spi)
spi-dev.driver-name, ts);
if (err) {
dev_dbg(spi-dev, irq %d busy?\n, spi-irq);
- goto err_free_gpio;
+ goto err_disable_regulator;
}
}
@@ -1180,6 +1199,10 @@ static int __devinit ads7846_probe(struct spi_device
*spi)
ads784x_hwmon_unregister(spi, ts);
err_free_irq:
free_irq(spi-irq, ts);
+ err_disable_regulator:
+ regulator_disable(ts-reg);
+ err_put_regulator:
+ regulator_put(ts-reg);
err_free_gpio:
if (ts-gpio_pendown != -1)
gpio_free(ts-gpio_pendown);
@@ -1208,6 +1231,9 @@ static int __devexit ads7846_remove(struct spi_device
*spi)
/* suspend left the IRQ disabled */
enable_irq(ts-spi-irq);
+ regulator_disable(ts-reg);
+ regulator_put(ts-reg);
+
if (ts-gpio_pendown != -1)
gpio_free(ts-gpio_pendown);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely Yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards
Hi David, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Less restrictions on the sizes of transfers, power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. I've tried your patches on CM-T35 that has 8686 SDIO and the result was absence of MMC/SDIO devices at all :( Morover, kmmcd hangs: [ 399.427764] INFO: task kmmcd:149 blocked for more than 120 seconds. [ 399.434082] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 399.442016] kmmcd D c027f804 0 149 2 0x [ 399.448333] [c027f804] (schedule+0x274/0x2ac) from [c027fa08] (schedule_timeout+0x18/0x17c) [ 399.457122] [c027fa08] (schedule_timeout+0x18/0x17c) from [c027f484] (wait_for_common+0xc0/0x14c) [ 399.466461] [c027f484] (wait_for_common+0xc0/0x14c) from [c01e61e0] (mmc_wait_for_req+0x1f4/0x214) [ 399.475860] [c01e61e0] (mmc_wait_for_req+0x1f4/0x214) from [c01e6264] (mmc_wait_for_cmd+0x64/0x74) [ 399.485290] [c01e6264] (mmc_wait_for_cmd+0x64/0x74) from [c01e86b0] (mmc_go_idle+0x60/0xac) [ 399.494079] [c01e86b0] (mmc_go_idle+0x60/0xac) from [c01e6bb8] (mmc_rescan+0x150/0x208) [ 399.502532] [c01e6bb8] (mmc_rescan+0x150/0x208) from [c005e288] (worker_thread+0xf0/0x168) [ 399.511260] [c005e288] (worker_thread+0xf0/0x168) from [c0060dbc] (kthread+0x7c/0x84) [ 399.519531] [c0060dbc] (kthread+0x7c/0x84) from [c002ae50] (kernel_thread_exit+0x0/0x8) I'll try to debug it more today and see what is going on wrong... David Vrabel (3): mmc: omap_hsmmc: use packet sync'd DMA mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts drivers/mmc/host/omap_hsmmc.c | 123 ++--- 1 files changed, 78 insertions(+), 45 deletions(-) -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards
David Vrabel wrote: Mike Rapoport wrote: Hi David, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Less restrictions on the sizes of transfers, power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. I've tried your patches on CM-T35 that has 8686 SDIO and the result was absence of MMC/SDIO devices at all :( Morover, kmmcd hangs: [ 399.427764] INFO: task kmmcd:149 blocked for more than 120 seconds. [...] [ 399.485290] [c01e6264] (mmc_wait_for_cmd+0x64/0x74) from [c01e86b0] (mmc_go_idle+0x60/0xac) I suspect interrupts aren't enabled correctly as this command does not complete. Try reverting this hunk. I did. No changes... I've started to apply the patches one by one and after the first patch is applied, the SD card works Ok, but libertas fails to initialize with the following messages: modprobe libertas_sdio [ 82.233489] lib80211: common routines for IEEE802.11 drivers [ 82.833251] cfg80211: Calling CRDA to update world regulatory domain [ 83.327911] libertas_sdio: Libertas SDIO driver [ 83.332489] libertas_sdio: Copyright Pierre Ossman [ 83.348510] libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin [ 83.497619] libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin [ 83.679229] DMA synchronization event drop occurred with device 47 And then modprobe hangs: [ 258.700561] INFO: task modprobe:1191 blocked for more than 120 seconds. [ 258.707336] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 258.715270] modprobe D c027f794 0 1191 1182 0x0003 [ 258.721588] [c027f794] (schedule+0x274/0x2ac) from [c027f998] (schedule_timeout+0x18/0x17c) [ 258.730377] [c027f998] (schedule_timeout+0x18/0x17c) from [c027f414] (wait_for_common+0xc0/0x14c) [ 258.739746] [c027f414] (wait_for_common+0xc0/0x14c) from [c01e61e0] (mmc_wait_for_req+0x1f4/0x214) [ 258.749145] [c01e61e0] (mmc_wait_for_req+0x1f4/0x214) from [c01ea2a0] (mmc_io_rw_extended+0x188/0x1f0) [ 258.758911] [c01ea2a0] (mmc_io_rw_extended+0x188/0x1f0) from [c01eb1c4] (sdio_io_rw_ext_helper+0xc4/0x184) [ 258.769012] [c01eb1c4] (sdio_io_rw_ext_helper+0xc4/0x184) from [c01eb29c] (sdio_writesb+0x18/0x1c) [ 258.778442] [c01eb29c] (sdio_writesb+0x18/0x1c) from [bf0638dc] (if_sdio_probe+0x63c/0x938 [libertas_sdio]) [ 258.788665] [bf0638dc] (if_sdio_probe+0x63c/0x938 [libertas_sdio]) from [c01ea724] (sdio_bus_probe+0x5c/0x68) [ 258.799041] [c01ea724] (sdio_bus_probe+0x5c/0x68) from [c01a67a4] (driver_probe_device+0xa0/0x14c) [ 258.808441] [c01a67a4] (driver_probe_device+0xa0/0x14c) from [c01a68b0] (__driver_attach+0x60/0x84) [ 258.817932] [c01a68b0] (__driver_attach+0x60/0x84) from [c01a5c8c] (bus_for_each_dev+0x44/0x78) [ 258.827087] [c01a5c8c] (bus_for_each_dev+0x44/0x78) from [c01a6224] (bus_add_driver+0x9c/0x224) [ 258.836212] [c01a6224] (bus_add_driver+0x9c/0x224) from [c01a6c08] (driver_register+0xa8/0x130) [ 258.845367] [c01a6c08] (driver_register+0xa8/0x130) from [bf06701c] (if_sdio_init_module+0x1c/0x3c [libertas_sdio]) [ 258.856292] [bf06701c] (if_sdio_init_module+0x1c/0x3c [libertas_sdio]) from [c0029344] (do_one_initcall+0x54/0x190) [ 258.867187] [c0029344] (do_one_initcall+0x54/0x190) from [c0073130] (sys_init_module+0xb8/0x1e4) [ 258.876403] [c0073130] (sys_init_module+0xb8/0x1e4) from [c0029e80] (ret_fast_syscall+0x0/0x2c) @@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host, struct mmc_command *cmd, mmc_hostname(host-mmc), cmd-opcode, cmd-arg); host-cmd = cmd; - /* -* Clear status bits and enable interrupts -*/ - OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR); - OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK); - if (host-use_dma) OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE)); David -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving board patches from DSS2 to linux-omap
Tomi Valkeinen wrote: Hi, As discussed previously, board file changes in DSS2 tree cause conflicts with linux-omap easily. There are currently three board file patches in DSS2's for-next branch: 722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: add DSS2 display support 7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: Enable DSS2 for AM3517EVM board 40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 for OMAP3EVM board The problem here is of course that DSS2 tree may contain unmerged panel drivers, and those board file changes try to use these new panel drivers. Well, the panel drivers are referenced by name in the board files, so merging board file changes through linux-omap tree should not create merge conflicts and compile problems. There just won't be display until DSS2 tree is merged. Or am I missing something? Now, I don't think there's a perfect solution for this, but I think a working solution would be to put all board file changes to linux-omap tree (with the exception of some rare changes that don't compile without new DSS2 patches), but leave the kernel config unchanged. This way the board file contains references to new panel drivers, but as DSS2 nor the panel drivers are enabled in the Kconfig, the board file code is not used and everything should work as before. Then either I can have Kconfig patches in my tree, which are less likely to conflict, or the Kconfig changes can be done after both linux-omap and dss2 patches have been merged. How does this sound? Tomi Ps. I haven't actually tried those board file patches on top of linux-omap, but I don't see anything there that would cause compilation to fail. -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards
David Vrabel wrote: Mike Rapoport wrote: I've started to apply the patches one by one and after the first patch is applied, the SD card works Ok, but libertas fails to initialize with the following messages: modprobe libertas_sdio [ 82.233489] lib80211: common routines for IEEE802.11 drivers [ 82.833251] cfg80211: Calling CRDA to update world regulatory domain [ 83.327911] libertas_sdio: Libertas SDIO driver [ 83.332489] libertas_sdio: Copyright Pierre Ossman [ 83.348510] libertas_sdio mmc1:0001:1: firmware: requesting sd8686_helper.bin [ 83.497619] libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin [ 83.679229] DMA synchronization event drop occurred with device 47 What block size are you using? It looks like you're using something less than 512. I've checked the spec again and the DMA packet size should be the block size in words (and not the FIFO depth). It's quite possible. I haven't dig too much and I really don't know how exactly libertas driver sends/receives the data... I'll continue testing and will try to get some more meaningful info Also, keep in mind that the buffers for transfers must begin and end on a word boundary. The OMAP's DMA controller can only transfer whole words to the MMC FIFO. David -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: ads7846: add regulator support
Mark Brown wrote: On Fri, Feb 05, 2010 at 10:45:09PM +0200, Mike Rapoport wrote: On Thu, Feb 4, 2010 at 6:21 PM, Mark Brown The bodge I'm thinking of would do something like log an error and substitute in a dummy regulator when regulator_get() would have failed so that the driver sees behaviour equivalent to the stubbed regulator API if the bodge is active. A central thing seems much more sensible here - there's nothing specific to this driver going on here and having the API behave in a consistent manner seems good. I agree that such approach have more sense than checking for -ENODEV in each and every driver that uses the regulator framework. I just wonder, if there should be some mechanism that can switch the substitution of the dummy regulators on and off. And if yes, how should the platform code communicate with the regulator core the need for such dummy regulators... So, having thought about this a bit more we actually have two different use cases here. One is where you've got a system which has software controllable regulators for everything but may not have plumbed in all the supplies, the other is for systems where only a very few supplies are on software controlled regulators which are just trying to save the hassle of hooking up the bulk of the supplies to fixed voltage regulators. These two use cases should probably be handled differently - the first one is really expected to have all the supplies hooked up and so should warn when using the bodge regulator but the warning isn't helpful in the second case. Sounds right to me. We already have some support for boards to set up the API in the form of regulator_set_full_constraints() so we could do something similar for dummy regulators, or create a new single API to set a bunch of options via a struct which is probably less hassle going forward. Struct sounds more reasonable that just a call to e.g. regulator_warn_dummy_fixed_regulator :) -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: ads7846: add regulator support
On Thu, Feb 4, 2010 at 6:21 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Feb 04, 2010 at 04:52:26PM +0200, Grazvydas Ignotas wrote: On Thu, Feb 4, 2010 at 4:24 PM, Mark Brown The bodge I'm thinking of would do something like log an error and substitute in a dummy regulator when regulator_get() would have failed so that the driver sees behaviour equivalent to the stubbed regulator API if the bodge is active. A central thing seems much more sensible here - there's nothing specific to this driver going on here and having the API behave in a consistent manner seems good. I agree that such approach have more sense than checking for -ENODEV in each and every driver that uses the regulator framework. I just wonder, if there should be some mechanism that can switch the substitution of the dummy regulators on and off. And if yes, how should the platform code communicate with the regulator core the need for such dummy regulators... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely Yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: ads7846: add regulator support
Mark Brown wrote:
On Thu, Feb 04, 2010 at 03:39:18PM +0200, Grazvydas Ignotas wrote:
The ADS7846/TSC2046 touchscreen controllers can (and usually are)
connected to various regulators for power, so add regulator support.
Make it optional for now to avoid breaking all current users of this
driver.
This should not be required. The regulator API stubs itself out when it
is not built so all API calls report as successful.
And what about boards that have the ads7846 tied to power rail and still
want to use regulator API for other staff?
+ts-reg = regulator_get(spi-dev, vcc);
+if (!IS_ERR(ts-reg)) {
+err = regulator_enable(ts-reg);
+if (err)
+goto err_put_regulator;
+}
If the regulator API is not compiled in then the regulator_get() will
return succesfully. If the regulator API is in use then failure to
acquire the regulator is a serious problem which really should be at a
minimium be being communicated to the user. For example, the regulator
API may end up powering down regulators which it believes are unused or
the regulator may not be powered by default and needs to be enabled.
The updates to fix up the boards that need this are fairly
straightforward and given that it's fairly easy to identify systems
which are using the driver in mainline so I'd really prefer not to go
down the route of trying to carry on in the face of error, it papers
over stuff now but is not robust in the face of future changes.
The updates are straightforward for boards that actually _have_
regulator powering the touchscreen controller. What about the boards
that do not have such a regulator?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to put TWL/TPS into sleep?
Lesly AM wrote: Hi Mike, - Original Message - From: Mike Rapoport m...@compulab.co.il To: linux-omap@vger.kernel.org Sent: Thursday, January 21, 2010 5:15 PM Subject: How to put TWL/TPS into sleep? Hi all, I'm trying to achieve maximal power savings on omap3 based system with TPS65930 PMIC using twl4030_script and twl4030_resconfig. I've tried different resource mappings and different command sequences in the sleep/wakeup scripts by to no avail. Moreover, with some resource definitions and sleep/wakeup scripts the system behaves in a weird ways, e.g. does not properly respond to hard resets. Most probably my resource remapping and command sequences are wrong and this is the reason for system misbehavior. However, several things are completely unclear to me: * Does TPS/TWL have defaults for sleep-on and sleep-off transitions? AFIK TPS659x TWL4030 is same chip, may have some Si version(ES 1.x) difference. So the power seqeunce used on TWL4030, should work on TPS659x also. * What would happen if nSLEEP1 would go low/high and there is no sleep/wakeup sequence programmed? By default reset value for the resgister pointing to [sleep/wakeup/wrst] seq is 0x3F, which is the exit addr for seq. So the TRITON resources will not have any change. * If I have a sleep sequence that disables some power resources, what would be the state of the other resources? If you are using singular messages in the seq, you can address each resource by specifying the Resource_id. But if you are using broadcast messages, the resources which will respond depends on the Resource_group, TYPE TYPE2 values. I've read the TPS TRM several times to now and I still got now clue about what's going on there :( You can verify wether your clk/volt setup_time holds good. Thanks a lot. This is really helpful :) -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How to put TWL/TPS into sleep?
Hi all, I'm trying to achieve maximal power savings on omap3 based system with TPS65930 PMIC using twl4030_script and twl4030_resconfig. I've tried different resource mappings and different command sequences in the sleep/wakeup scripts by to no avail. Moreover, with some resource definitions and sleep/wakeup scripts the system behaves in a weird ways, e.g. does not properly respond to hard resets. Most probably my resource remapping and command sequences are wrong and this is the reason for system misbehavior. However, several things are completely unclear to me: * Does TPS/TWL have defaults for sleep-on and sleep-off transitions? * What would happen if nSLEEP1 would go low/high and there is no sleep/wakeup sequence programmed? * If I have a sleep sequence that disables some power resources, what would be the state of the other resources? I've read the TPS TRM several times to now and I still got now clue about what's going on there :( -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: low power with linux omap
Massimiliano Cialdi wrote: I wonder how can I control low power feature on omap platform running linux (like omap3evm or beagleboard). There is a system call, an API or a command to run? There's an introduction to OMAP power management at: http://elinux.org/OMAP_Power_Management thanks -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] omap3: pm: re-program the sleep state of TRITON resources by modifying the REMAP register
x0080...@ti.com wrote:
From: Lesly A M x0080...@ti.com
omap3: pm: re-program the sleep state of TRITON resources by modifying the
REMAP register
Removed the warning print with checking order of scripts, since the order
is not important. Only the values configured in the register, which is
pointing to
the starting address of each sequence should be correct.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/twl4030-power.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
Index: linux-omap-pm/drivers/mfd/twl4030-power.c
===
--- linux-omap-pm.orig/drivers/mfd/twl4030-power.c2010-01-19
19:18:56.0 +0530
+++ linux-omap-pm/drivers/mfd/twl4030-power.c 2010-01-19 19:19:02.0
+0530
@@ -416,14 +416,35 @@
return err;
}
- return 0;
+
+ /* Set the remap sleep cmd */
+ err = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, remap,
+ rconfig_addr + REMAP_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 Resource %d remap could not read\n,
+ rconfig-resource);
+ return err;
+ }
+
+ if (rconfig-remap_sleep = 0) {
+ remap = ~SLEEP_STATE_MASK;
+ remap |= rconfig-remap_sleep;
+ }
+
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, remap,
+ rconfig_addr + REMAP_OFFSET);
+ if (err 0) {
+ pr_err(TWL4030 failed to program remap sleep cmd \n);
+ return err;
+ }
+
Is it necessary to initialize the remap sleep twice?
+ return err;
}
static int __init load_twl4030_script(struct twl4030_script *tscript,
u8 address)
{
int err;
- static int order;
/* Make sure the script isn't going beyond last valid address (0x3f) */
if ((address + tscript-size) END_OF_SCRIPT) {
@@ -444,7 +465,6 @@
err = twl4030_config_wakeup12_sequence(address);
if (err)
goto out;
- order = 1;
}
if (tscript-flags TWL4030_WAKEUP3_SCRIPT) {
err = twl4030_config_wakeup3_sequence(address);
@@ -452,10 +472,6 @@
goto out;
}
if (tscript-flags TWL4030_SLEEP_SCRIPT)
- if (order)
- pr_warning(TWL4030: Bad order of scripts (sleep \
- script before wakeup) Leads to boot\
- failure on some boards\n);
err = twl4030_config_sleep_sequence(address);
out:
return err;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP35xx:SDIO IRQ Support for OMAP35xx
Hi Dirk,
Dirk Behme wrote:
On 21.12.2009 17:46, Mike Rapoport wrote:
Hi,
Phaneendra Kumar Alapati wrote:
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Signed-off-by: Phaneendra Kumarph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c | 55
1 files changed, 49 insertions(+), 6 deletions(-)
I've tried the patch on CM-T35 that has Marvell 88W8686 on-board and
surprisingly I get a lot of command timeouts from the libertas driver :(
---
libertas: requeueing command 0x0006 due to timeout (#1)
libertas: Received result 0 to command 6 after 1 retries
libertas: command 0x0006 timed out
---
I hope I'll find time to debug it in the next few days and provide
more valuable
information...
There is a test report from Overo air that there it doesn't work, too:
http://old.nabble.com/Re%3A-Overo-wifi-speed-and-WPA2-connection-issue-p27231874.html
Any news on this patch?
Unfortunately I haven't got time to see why libertas is unhappy with
this patch.. :(
Best regards
Dirk
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..fa94580 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,10 @@
#define SRD(1 26)
#define SOFTRESET(1 1)
#define RESETDONE(1 0)
+#define CIRQ(1 8)
+#define CIRQ_ENABLE(1 8)
+#define CTPL(1 11)
+#define CLKEXTFREE(1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines
should come
@@ -171,6 +175,7 @@ struct omap_hsmmc_host {
intvdd;
intprotect_card;
intreqs_blocked;
+intsdio_int;
structomap_mmc_platform_data*pdata;
};
@@ -436,6 +441,13 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
else
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+if (host-sdio_int) {
+OMAP_HSMMC_WRITE(host-base, ISE,
+(OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+OMAP_HSMMC_WRITE(host-base, IE,
+(OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+}
+
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136)
@@ -640,6 +652,17 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
spin_lock(host-irq_lock);
+data = host-data;
+status = OMAP_HSMMC_READ(host-base, STAT);
+dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+if (status CIRQ) {
+dev_dbg(mmc_dev(host-mmc), SDIO Card Interrupt\n);
+mmc_signal_sdio_irq(host-mmc);
+}
+}
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -649,10 +672,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-data = host-data;
-status = OMAP_HSMMC_READ(host-base, STAT);
-dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
-
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1254,6 +1273,25 @@ static int omap_hsmmc_get_ro(struct mmc_host
*mmc)
return mmc_slot(host).get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
enable)
+{
+struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+host-sdio_int = enable;
+if (enable) {
+OMAP_HSMMC_WRITE(host-base, ISE,
+(OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+OMAP_HSMMC_WRITE(host-base, IE,
+(OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+} else {
+OMAP_HSMMC_WRITE(host-base, IE,
+(OMAP_HSMMC_READ(host-base, IE) (~CIRQ_ENABLE)));
+OMAP_HSMMC_WRITE(host-base, ISE,
+(OMAP_HSMMC_READ(host-base, ISE) (~CIRQ_ENABLE)));
+}
+
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hsmmc_ops
= {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
-/* NYET -- enable_sdio_irq */
+.enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops
omap_hsmmc_ps_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
-/* NYET -- enable_sdio_irq */
+.enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
#ifdef CONFIG_DEBUG_FS
@@ -1657,6 +1695,7
Re: [PATCH 1/6] Regulator: Creating TWL4030 specific file having supplies init data
Anuj Aggarwal wrote:
A new file for TWL4030/TPS65950 is created which has common supplies
and regulator init data structures. They will be referenced from the
various board-evm files depending upon the EVM requirements.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c | 175
++
1 files changed, 175 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c
diff --git a/arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c
b/arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c
new file mode 100644
index 000..0b7cd74
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c
[ snip ]
+/* Regulator initialization data */
+/* VAUX1 */
+struct regulator_init_data vaux1_data = {
The reulator_init_data structs are now global, so I think they should
have twl4030_ prefix
+ .constraints = {
+ .min_uV = 280,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VAUX2 */
+struct regulator_init_data vaux2_data = {
+ .constraints = {
+ .min_uV = 280,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VAUX3 */
+struct regulator_init_data vaux3_data = {
+ .constraints = {
+ .min_uV = 280,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VAUX4 */
+struct regulator_init_data vaux4_data = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VMMC1 */
+struct regulator_init_data vmmc1_data = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .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 = twl4030_vmmc1_supply,
+};
+
+/* VMMC2 */
+struct regulator_init_data vmmc2_data = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 185,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = twl4030_vmmc2_supply,
+};
+
+/* VSIM */
+struct regulator_init_data vsim_data = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 300,
+ .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 = twl4030_vsim_supply,
+};
+
+/* VDAC */
+struct regulator_init_data vdac_data = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+
Re: [PATCH 4/6] Regulator: Modifying Kconfig to choose from the available PMICs
Anuj Aggarwal wrote: Kconfig is modified for OMAP3 EVM so that user can choose the appropriate PMIC (currently only TWL4030). Config options for other PMICs will be added later on. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/mach-omap2/Kconfig |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 606bf04..95b8eb2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -82,6 +82,15 @@ config MACH_OMAP3EVM depends on ARCH_OMAP3 ARCH_OMAP34XX select OMAP_PACKAGE_CBB +config PMIC_TWL4030 + bool TWL4030/TPS65950 Power Module + default y + depends on TWL4030_CORE MACH_OMAP3EVM I don't think PMIC_TWL4030 should depend on MACH_OMAP3EVM + select REGULATOR_TWL4030 if REGULATOR + help + Say yes here if you are using the TWL4030/TPS65950 based power module + for the EVM boards. + config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] Regulator: Makefile modified to include TWL4030-PMIC specific file
Anuj Aggarwal wrote: Makefile is modified so that board-omap35x-twl4030-pmic.c gets compiled for the platforms having TWL4030 as the PMIC. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/mach-omap2/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Can you combine this patch with Modifying Kconfig to choose from the available PMICs patch? Moreover, I think the patches should be reordered so that kernel build won't be broken. Maybe something like: 1 - Creating TWL4030 specific file having supplies init data 2 - Modifying Kconfig and Makefile to choose from the available PMICs 3 - Kconfig modified to select TWL4030 for OMAP3 based platforms 4 - Use common regulator supplies and init data structs diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index b32678b..181be39 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -107,6 +107,7 @@ obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \ mmc-twl4030.o +obj-$(CONFIG_PMIC_TWL4030) += board-omap35x-twl4030-pmic.o obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP35xx:SDIO IRQ Support for OMAP35xx
Hi,
Phaneendra Kumar Alapati wrote:
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Signed-off-by: Phaneendra Kumar ph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c | 55
1 files changed, 49 insertions(+), 6 deletions(-)
I've tried the patch on CM-T35 that has Marvell 88W8686 on-board and
surprisingly I get a lot of command timeouts from the libertas driver :(
---
libertas: requeueing command 0x0006 due to timeout (#1)
libertas: Received result 0 to command 6 after 1 retries
libertas: command 0x0006 timed out
---
I hope I'll find time to debug it in the next few days and provide more valuable
information...
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..fa94580 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,10 @@
#define SRD (1 26)
#define SOFTRESET(1 1)
#define RESETDONE(1 0)
+#define CIRQ (1 8)
+#define CIRQ_ENABLE (1 8)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -171,6 +175,7 @@ struct omap_hsmmc_host {
int vdd;
int protect_card;
int reqs_blocked;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -436,6 +441,13 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
else
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ }
+
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136)
@@ -640,6 +652,17 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
spin_lock(host-irq_lock);
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO Card Interrupt\n);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -649,10 +672,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
- data = host-data;
- status = OMAP_HSMMC_READ(host-base, STAT);
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
-
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1254,6 +1273,25 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return mmc_slot(host).get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+ host-sdio_int = enable;
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ } else {
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) (~CIRQ_ENABLE)));
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) (~CIRQ_ENABLE)));
+ }
+
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hsmmc_ps_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
#ifdef CONFIG_DEBUG_FS
@@ -1657,6 +1695,7 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
host-mapbase = res-start;
host-base = ioremap(host-mapbase, SZ_4K);
host-power_mode = -1;
+
Re: [PATCH 0/2] omap3: cm-t35: enable display subsystem
Hi Tomi, Any updates on this? Mike Rapoport wrote: The below patches add display support for CM-T35 board. The following changes since commit f40542532e96dda5506eb76badea322f2ae4731c: Linus Torvalds (1): Merge branch 'ixp4xx' of git://git.kernel.org/.../chris/linux-2.6 Mike Rapoport (2): OMAP: DSS2: add Toppoly TDO35S panel omap3: cm-t35: add DSS2 display support arch/arm/mach-omap2/board-cm-t35.c | 239 +++- drivers/video/omap2/displays/Kconfig |6 + drivers/video/omap2/displays/Makefile |1 + .../video/omap2/displays/panel-toppoly-tdo35s.c| 112 + 4 files changed, 357 insertions(+), 1 deletions(-) create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] omap3: cm-t35: enable display subsystem
The below patches add display support for CM-T35 board. The following changes since commit f40542532e96dda5506eb76badea322f2ae4731c: Linus Torvalds (1): Merge branch 'ixp4xx' of git://git.kernel.org/.../chris/linux-2.6 Mike Rapoport (2): OMAP: DSS2: add Toppoly TDO35S panel omap3: cm-t35: add DSS2 display support arch/arm/mach-omap2/board-cm-t35.c | 239 +++- drivers/video/omap2/displays/Kconfig |6 + drivers/video/omap2/displays/Makefile |1 + .../video/omap2/displays/panel-toppoly-tdo35s.c| 112 + 4 files changed, 357 insertions(+), 1 deletions(-) create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap3: cm-t35: add DSS2 display support
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 239 +++-
1 files changed, 238 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 1591aae..5e1b098 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -32,6 +32,9 @@
#include linux/i2c/twl4030.h
#include linux/regulator/machine.h
+#include linux/spi/spi.h
+#include linux/spi/tdo24m.h
+
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -41,6 +44,7 @@
#include plat/nand.h
#include plat/gpmc.h
#include plat/usb.h
+#include plat/display.h
#include mach/hardware.h
@@ -248,7 +252,6 @@ static inline void cm_t35_init_nand(void) {}
#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
-#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include plat/mcspi.h
@@ -304,6 +307,193 @@ static void __init cm_t35_init_ads7846(void)
static inline void cm_t35_init_ads7846(void) {}
#endif
+#define CM_T35_LCD_EN_GPIO 157
+#define CM_T35_LCD_BL_GPIO 58
+#define CM_T35_DVI_EN_GPIO 54
+
+static int lcd_bl_gpio;
+static int lcd_en_gpio;
+static int dvi_en_gpio;
+
+static int lcd_enabled;
+static int dvi_enabled;
+
+static int cm_t35_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(lcd_en_gpio, 1);
+ gpio_set_value(lcd_bl_gpio, 1);
+
+ lcd_enabled = 1;
+
+ return 0;
+}
+
+static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ lcd_enabled = 0;
+
+ gpio_set_value(lcd_bl_gpio, 0);
+ gpio_set_value(lcd_en_gpio, 0);
+}
+
+static int cm_t35_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ if (lcd_enabled) {
+ printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
+ return -EINVAL;
+ }
+
+ gpio_set_value(dvi_en_gpio, 0);
+ dvi_enabled = 1;
+
+ return 0;
+}
+
+static void cm_t35_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dvi_en_gpio, 1);
+ dvi_enabled = 0;
+}
+
+static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+static struct omap_dss_device cm_t35_lcd_device = {
+ .name = lcd,
+ .driver_name= toppoly_tdo35s_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 18,
+ .platform_enable= cm_t35_panel_enable_lcd,
+ .platform_disable = cm_t35_panel_disable_lcd,
+};
+
+static struct omap_dss_device cm_t35_dvi_device = {
+ .name = dvi,
+ .driver_name= generic_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .platform_enable= cm_t35_panel_enable_dvi,
+ .platform_disable = cm_t35_panel_disable_dvi,
+};
+
+static struct omap_dss_device cm_t35_tv_device = {
+ .name = tv,
+ .driver_name= venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+ .platform_enable= cm_t35_panel_enable_tv,
+ .platform_disable = cm_t35_panel_disable_tv,
+};
+
+static struct omap_dss_device *cm_t35_dss_devices[] = {
+ cm_t35_lcd_device,
+ cm_t35_dvi_device,
+ cm_t35_tv_device,
+};
+
+static struct omap_dss_board_info cm_t35_dss_data = {
+ .num_devices= ARRAY_SIZE(cm_t35_dss_devices),
+ .devices= cm_t35_dss_devices,
+ .default_device = cm_t35_dvi_device,
+};
+
+static struct platform_device cm_t35_dss_device = {
+ .name = omapdss,
+ .id = -1,
+ .dev= {
+ .platform_data = cm_t35_dss_data,
+ },
+};
+
+static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,/* 0: slave, 1: master */
+};
+
+static struct tdo24m_platform_data tdo24m_config = {
+ .model = TDO35S,
+};
+
+static struct spi_board_info cm_t35_lcd_spi_board_info[] __initdata = {
+ {
+ .modalias = tdo24m,
+ .bus_num= 4,
+ .chip_select= 0,
+ .max_speed_hz = 100,
+ .controller_data= tdo24m_mcspi_config,
+ .platform_data = tdo24m_config,
+ },
+};
+
+static void __init cm_t35_init_display(void)
+{
+ int err;
+
+ lcd_en_gpio = CM_T35_LCD_EN_GPIO;
+ lcd_bl_gpio = CM_T35_LCD_BL_GPIO;
+ dvi_en_gpio = CM_T35_DVI_EN_GPIO
[PATCH 1/2] OMAP: DSS2: add Toppoly TDO35S panel
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |1 +
.../video/omap2/displays/panel-toppoly-tdo35s.c| 112
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index b12a59c..86946e8 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -19,4 +19,10 @@ config PANEL_TAAL
help
Taal DSI command mode panel from TPO.
+config PANEL_TOPPOLY_TDO35S
+tristate Toppoly TDO35S LCD Panel support
+depends on OMAP2_DSS
+help
+ LCD Panel used in CM-T35
+
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 9556464..0b7c3b3 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
\ No newline at end of file
diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
new file mode 100644
index 000..e744b8c
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
@@ -0,0 +1,112 @@
+/*
+ * LCD panel driver for Toppoly TDO35S
+ *
+ * Copyright (C) 2009 CompuLab, Ltd.
+ * Author: Mike Rapoport m...@compulab.co.il
+ *
+ * Based on generic panel support
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include plat/display.h
+
+static struct omap_video_timings toppoly_tdo_panel_timings = {
+ /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = 480,
+ .y_res = 640,
+
+ .pixel_clock= 26000,
+
+ .hfp= 104,
+ .hsw= 8,
+ .hbp= 8,
+
+ .vfp= 4,
+ .vsw= 2,
+ .vbp= 2,
+};
+
+static int toppoly_tdo_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS;
+ dssdev-panel.timings = toppoly_tdo_panel_timings;
+
+ return 0;
+}
+
+static void toppoly_tdo_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int toppoly_tdo_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void toppoly_tdo_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+}
+
+static int toppoly_tdo_panel_suspend(struct omap_dss_device *dssdev)
+{
+ toppoly_tdo_panel_disable(dssdev);
+ return 0;
+}
+
+static int toppoly_tdo_panel_resume(struct omap_dss_device *dssdev)
+{
+ return toppoly_tdo_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver generic_driver = {
+ .probe = toppoly_tdo_panel_probe,
+ .remove = toppoly_tdo_panel_remove,
+
+ .enable = toppoly_tdo_panel_enable,
+ .disable= toppoly_tdo_panel_disable,
+ .suspend= toppoly_tdo_panel_suspend,
+ .resume = toppoly_tdo_panel_resume,
+
+ .driver = {
+ .name = toppoly_tdo35s_panel,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init toppoly_tdo_panel_drv_init(void)
+{
+ return omap_dss_register_driver(generic_driver);
+}
+
+static void __exit toppoly_tdo_panel_drv_exit(void)
+{
+ omap_dss_unregister_driver(generic_driver);
+}
+
+module_init(toppoly_tdo_panel_drv_init);
+module_exit(toppoly_tdo_panel_drv_exit);
+MODULE_LICENSE(GPL);
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: smc91x problems on 2430SDP
On Mon, Dec 14, 2009 at 10:55 PM, Paul Walmsley p...@pwsan.com wrote: Hi, smc91x is preventing 2430SDP from booting. Messages follow at the end of this message. Any ideas? AFAIK, smc91x probes interrupts during initialization. Maybe interrupt flags got wrong somehow, of the interrupt pin mux is not properly set up. - Paul smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre n...@fluxnic.net eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) eth%d: spurious interrupt (mask = 0x0b) ... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely Yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Initial support for Technexion Thunderboard : defconfig
Hi Daniel, On Sun, Dec 13, 2009 at 3:30 PM, Daniel Toussaint dan...@dmhome.net wrote: Dear All, Patches reformatted for mainline. Please send the patches inline rather than as attachment. It is much easier for review. And, usually [PATCH 0/x] message contains brief description of the patchset and does not include actual patches. I'd also suggest making defconfig the last patch in the series. -- Sincerely Yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: cm-t35: add mux initialization (was: Re: [PATCH] omap3: cm-t35: add mux initialization)
Tony,
Tony Lindgren wrote:
* Gadiyar, Anand gadi...@ti.com [091207 08:35]:
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [091206 07:30]:
Tony,
Any chance this can go to 2.6.33?
Sure, I was just waiting to hear back if the OUTPUT_PULLUP is
needed for sure? Or is just OUTPUT enough for musb to work?
Tony
OUTPUT should work too. The ULPI spec recommends a weak pull-up
on STP line, but we needn't really have that. Plain OUTPUT is sufficient.
OK, thanks for checking that. Mike, what do you prefer to do?
I guess in some cases the pull may be needed for a pin
to change faster if an external pull is not used?
We could add the OUTPUT_PULL defines, but we should probably
mark them with comments that they should be rarely needed.
Here's updated cm-t35 mux initialization that should apply to current
linux-omap-2.6/master. Please discard the previous version and sorry for the
noise.
Regards,
Tony
From 0da6d5d13351c2fc121a86ab641e25e4ff017800 Mon Sep 17 00:00:00 2001
From: Mike Rapoport m...@compulab.co.il
Date: Wed, 9 Dec 2009 15:23:24 +0200
Subject: [PATCH] omap3: cm-t35: add mux initialization
CM-T35 can be assembled with different set of peripherals thus making
certain interfaces available to user as GPIOs or dedicated pins. Because
of it CM-T35 bootloader sets up mux configuration only for pins
necessary to boot the system and the rest of the mux configuration is
done by the kernel. Besides, having mux configuration in the kernel
allows to minimize dependancy on bootloader.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-cm-t35.c | 96 +---
2 files changed, 90 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 16c0c13..66de47b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -136,6 +136,7 @@ config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3 ARCH_OMAP34XX
select OMAP_PACKAGE_CUS
+ select OMAP_MUX
config MACH_IGEP0020
bool IGEP0020
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 507c922..1591aae 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -482,13 +482,98 @@ static void __init cm_t35_map_io(void)
omap2_map_common_io();
}
-#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* nCS and IRQ for CM-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS5, OMAP_MUX_MODE0),
+ OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* nCS and IRQ for SB-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS4, OMAP_MUX_MODE0),
+ OMAP3_MUX(GPMC_WAIT3, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* PENDOWN GPIO */
+ OMAP3_MUX(GPMC_NCS6, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* mUSB */
+ OMAP3_MUX(HSUSB0_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_STP, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(HSUSB0_DIR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_NXT, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* MMC 2 */
+ OMAP3_MUX(SDMMC2_DAT4, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT5, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT6, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(SDMMC2_DAT7, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+
+ /* McSPI 1 */
+ OMAP3_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SIMO, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SOMI, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_CS0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+
+ /* McSPI 4 */
+ OMAP3_MUX(MCBSP1_CLKR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
+
+ /* McBSP 2 */
+ OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
+ /* serial ports */
+ OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE1
Re: [PATCH] omap3: cm-t35: add mux initialization
Tony Lindgren wrote:
* Gadiyar, Anand gadi...@ti.com [091207 08:35]:
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [091206 07:30]:
Tony,
Any chance this can go to 2.6.33?
Sure, I was just waiting to hear back if the OUTPUT_PULLUP is
needed for sure? Or is just OUTPUT enough for musb to work?
Tony
OUTPUT should work too. The ULPI spec recommends a weak pull-up
on STP line, but we needn't really have that. Plain OUTPUT is sufficient.
OK, thanks for checking that. Mike, what do you prefer to do?
I'll test without the pull and if it's Ok this way I'll update the mux
initialization patch and drop the OUTPUT_PULL{UP,DOWN}.
I guess in some cases the pull may be needed for a pin
to change faster if an external pull is not used?
We could add the OUTPUT_PULL defines, but we should probably
mark them with comments that they should be rarely needed.
Regards,
Tony
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] omap3: cm-t35: add mux initialization
CM-T35 can be assembled with different set of peripherals thus making
certain interfaces available to user as GPIOs or dedicated pins. Because
of it CM-T35 bootloader sets up mux configuration only for pins
necessary to boot the system and the rest of the mux configuration is
done by the kernel. Besides, having mux configuration in the kernel
allows to minimize dependancy on bootloader.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-cm-t35.c | 95 +--
2 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 034d990..96e7e3f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -108,6 +108,7 @@ config MACH_OMAP_ZOOM3
config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_MUX
config MACH_IGEP0020
bool IGEP0020
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e5f3039..c28afd6 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -482,13 +482,98 @@ static void __init cm_t35_map_io(void)
omap2_map_common_io();
}
-#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* nCS and IRQ for CM-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS5, OMAP_MUX_MODE0),
+ OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* nCS and IRQ for SB-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS4, OMAP_MUX_MODE0),
+ OMAP3_MUX(GPMC_WAIT3, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* PENDOWN GPIO */
+ OMAP3_MUX(GPMC_NCS6, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* mUSB */
+ OMAP3_MUX(HSUSB0_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_STP, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(HSUSB0_DIR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_NXT, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* MMC 2 */
+ OMAP3_MUX(MMC2_DAT4, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MMC2_DAT5, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MMC2_DAT6, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MMC2_DAT7, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+
+ /* McSPI 1 */
+ OMAP3_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SIMO, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SOMI, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_CS0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+
+ /* McSPI 4 */
+ OMAP3_MUX(MCBSP1_CLKR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
+
+ /* McBSP 2 */
+ OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
+ /* serial ports */
+ OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* DSS */
+ OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA8, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA9, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA10, OMAP_MUX_MODE0
Re: [PATCH] omap3: cm-t35: add mux initialization
Tony,
Any chance this can go to 2.6.33?
Mike Rapoport wrote:
Tony,
These patches are follow-ups to your mux rework series.
The first one is pretty trivial and adds OUTPUT_PULL{UP,DOWN} to shorten
the lines in omap_board_mux arrays.
The second patch adds the mux configuration for CM-T35. This is actually
the most compact subset of 'cat /sys/kernel/debug/omap_mux/board' that makes
CM-T35 functional :)
The following changes since commit d8bfa71e2e9d794f9c7e5b019f316804f7f50582:
Tony Lindgren (1):
omap: mux: Add data for 2430
Mike Rapoport (2):
omap3: mux: add shorthands for OUTPUT_PULL{UP,DOWN}
omap3: cm-t35: add mux initialization
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-cm-t35.c | 95 +--
arch/arm/mach-omap2/mux.h |2 +
3 files changed, 92 insertions(+), 6 deletions(-)
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omap3: cm-t35: enable display subsystem
Tony, Any chance this can go to 2.6.33? Mike Rapoport wrote: This patchset adds display support for CM-T35 board. The following changes since commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c: Tony Lindgren (1): Merge branch 'for-next' of git://gitorious.org/linux-omap-dss2/linux Mike Rapoport (3): OMAP: DSS2: add Toppoly TDO35S panel omap3: cm-t35: add DSS2 display support omap3: cm-t35: update defconfig for DSS2 arch/arm/configs/cm_t35_defconfig | 82 +++- arch/arm/mach-omap2/board-cm-t35.c | 234 +++- drivers/video/omap2/displays/Kconfig |6 + drivers/video/omap2/displays/Makefile |1 + .../video/omap2/displays/panel-toppoly-tdo35s.c| 112 ++ 5 files changed, 430 insertions(+), 5 deletions(-) create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] omap3: cm-t35: add DSS2 display support
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 234 +++-
1 files changed, 233 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 22c4529..2d7a819 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -32,6 +32,9 @@
#include linux/i2c/twl4030.h
#include linux/regulator/machine.h
+#include linux/spi/spi.h
+#include linux/spi/tdo24m.h
+
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -42,6 +45,7 @@
#include plat/nand.h
#include plat/gpmc.h
#include plat/usb.h
+#include plat/display.h
#include mach/hardware.h
@@ -248,7 +252,6 @@ static inline void cm_t35_init_nand(void) {}
#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
-#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include plat/mcspi.h
@@ -304,6 +307,193 @@ static void __init cm_t35_init_ads7846(void)
static inline void cm_t35_init_ads7846(void) {}
#endif
+#define CM_T35_LCD_EN_GPIO 157
+#define CM_T35_LCD_BL_GPIO 58
+#define CM_T35_DVI_EN_GPIO 54
+
+static int lcd_bl_gpio;
+static int lcd_en_gpio;
+static int dvi_en_gpio;
+
+static int lcd_enabled;
+static int dvi_enabled;
+
+static int cm_t35_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(lcd_en_gpio, 1);
+ gpio_set_value(lcd_bl_gpio, 1);
+
+ lcd_enabled = 1;
+
+ return 0;
+}
+
+static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ lcd_enabled = 0;
+
+ gpio_set_value(lcd_bl_gpio, 0);
+ gpio_set_value(lcd_en_gpio, 0);
+}
+
+static int cm_t35_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ if (lcd_enabled) {
+ printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
+ return -EINVAL;
+ }
+
+ gpio_set_value(dvi_en_gpio, 0);
+ dvi_enabled = 1;
+
+ return 0;
+}
+
+static void cm_t35_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dvi_en_gpio, 1);
+ dvi_enabled = 0;
+}
+
+static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+static struct omap_dss_device cm_t35_lcd_device = {
+ .name = lcd,
+ .driver_name= toppoly_tdo35s_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 18,
+ .platform_enable= cm_t35_panel_enable_lcd,
+ .platform_disable = cm_t35_panel_disable_lcd,
+};
+
+static struct omap_dss_device cm_t35_dvi_device = {
+ .name = dvi,
+ .driver_name= generic_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .platform_enable= cm_t35_panel_enable_dvi,
+ .platform_disable = cm_t35_panel_disable_dvi,
+};
+
+static struct omap_dss_device cm_t35_tv_device = {
+ .name = tv,
+ .driver_name= venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+ .platform_enable= cm_t35_panel_enable_tv,
+ .platform_disable = cm_t35_panel_disable_tv,
+};
+
+static struct omap_dss_device *cm_t35_dss_devices[] = {
+ cm_t35_lcd_device,
+ cm_t35_dvi_device,
+ cm_t35_tv_device,
+};
+
+static struct omap_dss_board_info cm_t35_dss_data = {
+ .num_devices= ARRAY_SIZE(cm_t35_dss_devices),
+ .devices= cm_t35_dss_devices,
+ .default_device = cm_t35_dvi_device,
+};
+
+static struct platform_device cm_t35_dss_device = {
+ .name = omapdss,
+ .id = -1,
+ .dev= {
+ .platform_data = cm_t35_dss_data,
+ },
+};
+
+static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,/* 0: slave, 1: master */
+};
+
+static struct tdo24m_platform_data tdo24m_config = {
+ .model = TDO35S,
+};
+
+static struct spi_board_info cm_t35_lcd_spi_board_info[] __initdata = {
+ {
+ .modalias = tdo24m,
+ .bus_num= 4,
+ .chip_select= 0,
+ .max_speed_hz = 100,
+ .controller_data= tdo24m_mcspi_config,
+ .platform_data = tdo24m_config,
+ },
+};
+
+static void __init cm_t35_display_init(void)
+{
+ int err;
+
+ lcd_en_gpio = CM_T35_LCD_EN_GPIO;
+ lcd_bl_gpio = CM_T35_LCD_BL_GPIO;
+ dvi_en_gpio = CM_T35_DVI_EN_GPIO
[PATCH 0/3] omap3: cm-t35: enable display subsystem
This patchset adds display support for CM-T35 board. The following changes since commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c: Tony Lindgren (1): Merge branch 'for-next' of git://gitorious.org/linux-omap-dss2/linux Mike Rapoport (3): OMAP: DSS2: add Toppoly TDO35S panel omap3: cm-t35: add DSS2 display support omap3: cm-t35: update defconfig for DSS2 arch/arm/configs/cm_t35_defconfig | 82 +++- arch/arm/mach-omap2/board-cm-t35.c | 234 +++- drivers/video/omap2/displays/Kconfig |6 + drivers/video/omap2/displays/Makefile |1 + .../video/omap2/displays/panel-toppoly-tdo35s.c| 112 ++ 5 files changed, 430 insertions(+), 5 deletions(-) create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] omap3: cm-t35: update defconfig for DSS2
Signed-off-by: Mike Rapoport m...@compulab.co.il --- arch/arm/configs/cm_t35_defconfig | 82 +++-- 1 files changed, 78 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/cm_t35_defconfig b/arch/arm/configs/cm_t35_defconfig index e42c5c8..bd6f882 100644 --- a/arch/arm/configs/cm_t35_defconfig +++ b/arch/arm/configs/cm_t35_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.32-rc4 -# Tue Oct 13 17:10:40 2009 +# Linux kernel version: 2.6.32-rc8 +# Tue Dec 1 12:08:44 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -215,6 +215,7 @@ CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set CONFIG_OMAP_LL_DEBUG_UART3=y +# CONFIG_OMAP_LL_DEBUG_NONE is not set # CONFIG_OMAP_PM_NONE is not set CONFIG_OMAP_PM_NOOP=y CONFIG_ARCH_OMAP34XX=y @@ -227,11 +228,15 @@ CONFIG_ARCH_OMAP3430=y # CONFIG_MACH_OMAP_LDP is not set # CONFIG_MACH_OVERO is not set # CONFIG_MACH_OMAP3EVM is not set +# CONFIG_MACH_OMAP3517EVM is not set # CONFIG_MACH_OMAP3_PANDORA is not set # CONFIG_MACH_OMAP_3430SDP is not set # CONFIG_MACH_NOKIA_RX51 is not set # CONFIG_MACH_OMAP_ZOOM2 is not set +# CONFIG_MACH_OMAP_ZOOM3 is not set CONFIG_MACH_CM_T35=y +# CONFIG_MACH_IGEP0020 is not set +# CONFIG_MACH_OMAP_3630SDP is not set # # Processor Type @@ -963,6 +968,7 @@ CONFIG_SSB_POSSIBLE=y # CONFIG_TPS65010 is not set CONFIG_TWL4030_CORE=y # CONFIG_TWL4030_POWER is not set +# CONFIG_TWL4030_CODEC is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC6387XB is not set @@ -993,8 +999,66 @@ CONFIG_REGULATOR_TWL4030=y # # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set -# CONFIG_FB is not set -# CONFIG_BACKLIGHT_LCD_SUPPORT is not set +CONFIG_FB=y +# CONFIG_FIRMWARE_EDID is not set +# CONFIG_FB_DDC is not set +# CONFIG_FB_BOOT_VESA_SUPPORT is not set +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set +# CONFIG_FB_SYS_FILLRECT is not set +# CONFIG_FB_SYS_COPYAREA is not set +# CONFIG_FB_SYS_IMAGEBLIT is not set +# CONFIG_FB_FOREIGN_ENDIAN is not set +# CONFIG_FB_SYS_FOPS is not set +# CONFIG_FB_SVGALIB is not set +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +# CONFIG_FB_MODE_HELPERS is not set +# CONFIG_FB_TILEBLITTING is not set + +# +# Frame buffer hardware drivers +# +# CONFIG_FB_S1D13XXX is not set +# CONFIG_FB_VIRTUAL is not set +# CONFIG_FB_METRONOME is not set +# CONFIG_FB_MB862XX is not set +# CONFIG_FB_BROADSHEET is not set +# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set +CONFIG_OMAP2_VRAM=y +CONFIG_OMAP2_VRFB=y +CONFIG_OMAP2_DSS=y +CONFIG_OMAP2_VRAM_SIZE=4 +CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y +# CONFIG_OMAP2_DSS_RFBI is not set +CONFIG_OMAP2_DSS_VENC=y +# CONFIG_OMAP2_DSS_SDI is not set +# CONFIG_OMAP2_DSS_DSI is not set +# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set +CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 +CONFIG_FB_OMAP2=y +CONFIG_FB_OMAP2_DEBUG_SUPPORT=y +# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set +CONFIG_FB_OMAP2_NUM_FBS=3 + +# +# OMAP2/3 Display Device Drivers +# +CONFIG_PANEL_GENERIC=y +# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set +# CONFIG_PANEL_SHARP_LS037V7DW01 is not set +CONFIG_PANEL_TOPPOLY_TDO35S=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +# CONFIG_LCD_LMS283GF05 is not set +# CONFIG_LCD_LTV350QV is not set +# CONFIG_LCD_ILI9320 is not set +CONFIG_LCD_TDO24M=y +# CONFIG_LCD_VGG2432A4 is not set +# CONFIG_LCD_PLATFORM is not set +# CONFIG_BACKLIGHT_CLASS_DEVICE is not set # # Display device support @@ -1006,6 +1070,16 @@ CONFIG_REGULATOR_TWL4030=y # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=y +# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set +# CONFIG_FONTS is not set +CONFIG_FONT_8x8=y +CONFIG_FONT_8x16=y +CONFIG_LOGO=y +CONFIG_LOGO_LINUX_MONO=y +CONFIG_LOGO_LINUX_VGA16=y +CONFIG_LOGO_LINUX_CLUT224=y # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=y -- 1.6.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: DSS2: add Toppoly TDO35S panel
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |1 +
.../video/omap2/displays/panel-toppoly-tdo35s.c| 112
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 79d2861..0d0d4f3 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -25,4 +25,10 @@ config PANEL_TAAL
help
Taal DSI command mode panel from TPO.
+config PANEL_TOPPOLY_TDO35S
+tristate Toppoly TDO35S LCD Panel support
+depends on OMAP2_DSS
+help
+ LCD Panel used in CM-T35
+
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index d44e765..e299454 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C) +=
panel-samsung-lte430wq-f0c.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
\ No newline at end of file
diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
new file mode 100644
index 000..e744b8c
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
@@ -0,0 +1,112 @@
+/*
+ * LCD panel driver for Toppoly TDO35S
+ *
+ * Copyright (C) 2009 CompuLab, Ltd.
+ * Author: Mike Rapoport m...@compulab.co.il
+ *
+ * Based on generic panel support
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include plat/display.h
+
+static struct omap_video_timings toppoly_tdo_panel_timings = {
+ /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = 480,
+ .y_res = 640,
+
+ .pixel_clock= 26000,
+
+ .hfp= 104,
+ .hsw= 8,
+ .hbp= 8,
+
+ .vfp= 4,
+ .vsw= 2,
+ .vbp= 2,
+};
+
+static int toppoly_tdo_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS;
+ dssdev-panel.timings = toppoly_tdo_panel_timings;
+
+ return 0;
+}
+
+static void toppoly_tdo_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int toppoly_tdo_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void toppoly_tdo_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+}
+
+static int toppoly_tdo_panel_suspend(struct omap_dss_device *dssdev)
+{
+ toppoly_tdo_panel_disable(dssdev);
+ return 0;
+}
+
+static int toppoly_tdo_panel_resume(struct omap_dss_device *dssdev)
+{
+ return toppoly_tdo_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver generic_driver = {
+ .probe = toppoly_tdo_panel_probe,
+ .remove = toppoly_tdo_panel_remove,
+
+ .enable = toppoly_tdo_panel_enable,
+ .disable= toppoly_tdo_panel_disable,
+ .suspend= toppoly_tdo_panel_suspend,
+ .resume = toppoly_tdo_panel_resume,
+
+ .driver = {
+ .name = toppoly_tdo35s_panel,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init toppoly_tdo_panel_drv_init(void)
+{
+ return omap_dss_register_driver(generic_driver);
+}
+
+static void __exit toppoly_tdo_panel_drv_exit(void)
+{
+ omap_dss_unregister_driver(generic_driver);
+}
+
+module_init(toppoly_tdo_panel_drv_init);
+module_exit(toppoly_tdo_panel_drv_exit);
+MODULE_LICENSE(GPL);
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
