Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
2012/10/5 Javier Martinez Canillas martinez.jav...@gmail.com: On Fri, Oct 5, 2012 at 10:10 AM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: On Fri, 5 Oct 2012 09:32:07 +0200, Javier Martinez Canillas wrote: As Enric said, u-boot has SPL and NAND support for IGEP since v2012.10-rc1. I just tried kernel a 3.6 with u-boot v2012.10-rc2 and it works for me. Ok, I'll try this out. But I agree that the kernel shouldn't do any assumptions about the bootloader setting correctly the omap mux. Could you please share your bootloader that makes the kernel to fail (or your IGEP NAND patches on top of u-boot U-boot 2011.12) so I can reproduce the issue and try to fix it? Ok, I'm using the X-Loader from git://git.igep.es/pub/scm/x-loader.git, tag v1.4.4-3, on top of which I apply http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/x-loader-1.4.4-3-igep-nand-support.patch to add support for the NAND-based IGEPv2 rev6. In terms of U-Boot, I use U-Boot 2011.12, on top of which I apply http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/u-boot-2011.12-igep-nand-support.patch to add support for the NAND-based IGEPv2 rev6. To make things easier if you don't need to rebuild those, I've put online pre-built binaries of X-Loader and U-Boot I'm using: http://free-electrons.com/~thomas/pub/igep-serial-problem/. Thanks, Thomas Perfect, I'll try it and let you know if I find a fix for the issue. Sorry if someone receives this email twice, I had some problems to send this email and Mail Delivery Subsystem tells me that the Delivery to the following recipient has been delayed. Also I tried and works for me which make me think that could be a hardware issue. Please make sure that pins 6, 8 and 9 of the J990 header are not connected. I'm noticed that some US-to-RS232 converters had problems with this. If you use the IDC10 to DB9 cable take a look at this article: http://labs.isee.biz/index.php/How_to_setup_the_IDC10_cable If it's a hardware issue, then , why it worked before 3.2 ? Well, I'm not sure, but maybe the mux is different for pins of uart1 that are connected to J990 and causes the problem. If you see at the schematic you'll see that J990 x - 10 9 - uart1_rx uart1_tx - 8 7 - x gnd - 6 5 - gnd x - 4 3 - uart3_tx uart3_rx - 2 1 -x If you use directly a IDC10-to-DB9 without cutting hires from 6 to 10 note that : - pin 6 of IDC10 is forced to gnd which corresponds to pin 6 of DB9 which is suposed to be used as DSR (Data Set Ready) - pin 8 of IDC10 is connected to uart1_tx which corresponds to pin 8 of DB9 which is suposed to be used as CTS (Clear to Send) - pin 9 of IDC10 is connected to uart1_rx which corresponds to pin 9 of DB9 which is suposed to be used as RI (Ring Indicator) Regards, Enric -- 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: igep0020: Specify the VPLL2 regulator unconditionally
2012/4/23 Laurent Pinchart laurent.pinch...@ideasonboard.com:
The supply is connected to the DSS DO-D5 pins and is thus needed for
both serial and parallel display interfaces on the igep0030 as well as
the igep0020.
If the igep0030 module isn't connected to a display, no DSI or DPI
display will be specified in board code, and the DSS driver won't enable
to VPLL2 regulator anyway.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/board-igep0020.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..242cdff 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -539,7 +539,10 @@ static void __init igep_i2c_init(void)
{
int ret;
- omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_USB, 0);
+ omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_USB,
+ TWL_COMMON_REGULATOR_VPLL2);
+ igep_twldata.vpll2-constraints.apply_uV = true;
+ igep_twldata.vpll2-constraints.name = VDVI;
if (machine_is_igep0020()) {
/*
@@ -553,10 +556,7 @@ static void __init igep_i2c_init(void)
igep_twldata.keypad = igep2_keypad_pdata;
/* Get common pmic data */
- omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_AUDIO,
- TWL_COMMON_REGULATOR_VPLL2);
- igep_twldata.vpll2-constraints.apply_uV = true;
- igep_twldata.vpll2-constraints.name = VDVI;
+ omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_AUDIO,
0);
}
omap3_pmic_init(twl4030, igep_twldata);
--
Regards,
Laurent Pinchart
--
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
Seems good to me.
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
--
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: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
2012/4/4 Javier Martinez Canillas jav...@dowhile0.org:
board_onenand_init() and board_nand_init() initialization functions are
used to initialize OneNAND and NAND memories respectively. But only
board_nand_init() was visible to be used from board code. This patch makes
possible to initialize a OneNAND flash memory within platform code.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/mach-omap2/board-flash.c | 4 ++--
arch/arm/mach-omap2/board-flash.h | 11 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0349fd2..70a81f9 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -87,7 +87,7 @@ static struct omap_onenand_platform_data board_onenand_data
= {
.dma_channel = -1, /* disable DMA in OMAP OneNAND driver */
};
-static void
+void
__init board_onenand_init(struct mtd_partition *onenand_parts,
u8 nr_parts, u8 cs)
{
@@ -98,7 +98,7 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(board_onenand_data);
}
#else
-static void
+void
__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8
cs)
{
}
diff --git a/arch/arm/mach-omap2/board-flash.h
b/arch/arm/mach-omap2/board-flash.h
index d25503a..c44b70d 100644
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -47,3 +47,14 @@ static inline void board_nand_init(struct mtd_partition
*nand_parts,
{
}
#endif
+
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+extern void board_onenand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs);
+#else
+static inline void board_onenand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs)
+{
+}
+#endif
--
1.7.7.6
Seems good to me.
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
--
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: [RESEND PATCH 2/2] OMAP3: igep0020: Add support for Micron NAND Flash storage memory
2012/4/4 Javier Martinez Canillas jav...@dowhile0.org:
IGEP-based boards can have two different flash memories, a OneNAND or
a NAND device. The boot configuration pins (sys_boot) are used to
specify which memory is available.
Also, this patch removes unnecesary code for registering the OneNAND.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/mach-omap2/board-igep0020.c | 75
++
1 files changed, 31 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 930c0d3..4af615a 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -24,6 +24,8 @@
#include linux/i2c/twl.h
#include linux/mmc/host.h
+#include linux/mtd/nand.h
+
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -39,6 +41,8 @@
#include hsmmc.h
#include sdram-numonyx-m65kam.h
#include common-board-devices.h
+#include board-flash.h
+#include control.h
#define IGEP2_SMSC911X_CS 5
#define IGEP2_SMSC911X_GPIO 176
@@ -60,6 +64,10 @@
#define IGEP3_GPIO_LED1_RED 16
#define IGEP3_GPIO_USBH_NRESET 183
+#define IGEP_SYSBOOT_MASK 0x1f
+#define IGEP_SYSBOOT_NAND 0x0f
+#define IGEP_SYSBOOT_ONENAND 0x10
+
/*
* IGEP2 Hardware Revision Table
*
@@ -110,8 +118,10 @@ static void __init igep2_get_revision(void)
gpio_free(IGEP2_GPIO_LED1_RED);
}
-#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
- defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE) || \
+ defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE)
#define ONENAND_MAP 0x2000
@@ -123,7 +133,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 igep_onenand_partitions[] = {
+static struct mtd_partition igep_flash_partitions[] = {
{
.name = X-Loader,
.offset = 0,
@@ -151,50 +161,27 @@ static struct mtd_partition igep_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 igep_onenand_device = {
- .name = omap2-onenand,
- .id = -1,
- .dev = {
- .platform_data = igep_onenand_data,
- },
-};
+static inline u32 igep_get_sysboot_value(void)
+{
+ return omap_ctrl_readl(OMAP343X_CONTROL_STATUS) IGEP_SYSBOOT_MASK;
+}
static void __init igep_flash_init(void)
{
- u8 cs = 0;
- u8 onenandcs = GPMC_CS_NUM + 1;
-
- for (cs = 0; cs GPMC_CS_NUM; cs++) {
- u32 ret;
- ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
-
- /* Check if NAND/oneNAND is configured */
- if ((ret 0xC00) == 0x800)
- /* NAND found */
- pr_err(IGEP: Unsupported NAND found\n);
- else {
- ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
- if ((ret 0x3F) == (ONENAND_MAP 24))
- /* ONENAND found */
- onenandcs = cs;
- }
- }
-
- if (onenandcs GPMC_CS_NUM) {
- pr_err(IGEP: Unable to find configuration in GPMC\n);
- return;
- }
-
- igep_onenand_data.cs = onenandcs;
-
- if (platform_device_register(igep_onenand_device) 0)
- pr_err(IGEP: Unable to register OneNAND device\n);
+ u32 mux;
+ mux = igep_get_sysboot_value();
+
+ if (mux == IGEP_SYSBOOT_NAND) {
+ pr_info(IGEP: initializing NAND memory device\n);
+ board_nand_init(igep_flash_partitions,
+ ARRAY_SIZE(igep_flash_partitions),
+ 0, NAND_BUSWIDTH_16);
+ } else if (mux == IGEP_SYSBOOT_ONENAND) {
+ pr_info(IGEP: initializing OneNAND memory device\n);
+ board_onenand_init(igep_flash_partitions,
+ ARRAY_SIZE(igep_flash_partitions), 0);
+ } else
+ pr_err(IGEP: Flash: unsupported sysboot sequence found\n);
}
#else
--
1.7.7.6
Seems good to me.
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCHv2 14/15] OMAP: Panda, Beagle, Overo: DVI: Add i2c_bus_num
2011/9/12 Tomi Valkeinen tomi.valkei...@ti.com:
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 1 +
arch/arm/mach-omap2/board-overo.c | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 26bc860..742ac45 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -206,6 +206,7 @@ static void beagle_disable_dvi(struct omap_dss_device
*dssdev)
static struct panel_dvi_platform_data dvi_panel = {
.platform_enable = beagle_enable_dvi,
.platform_disable = beagle_disable_dvi,
+ .i2c_bus_num = 3,
};
static struct omap_dss_device beagle_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c35384e..a38ed273 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -458,6 +458,7 @@ static void omap4_panda_disable_dvi(struct
omap_dss_device *dssdev)
static struct panel_dvi_platform_data omap4_dvi_panel = {
.platform_enable = omap4_panda_enable_dvi,
.platform_disable = omap4_panda_disable_dvi,
+ .i2c_bus_num = 3,
};
struct omap_dss_device omap4_panda_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 06064d5..da94376 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -186,6 +186,7 @@ static void overo_panel_disable_dvi(struct
omap_dss_device *dssdev)
static struct panel_dvi_platform_data dvi_panel = {
.platform_enable = overo_panel_enable_dvi,
.platform_disable = overo_panel_disable_dvi,
+ .i2c_bus_num = 3,
};
static struct omap_dss_device overo_dvi_device = {
--
1.7.4.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
Please, can also include the same modification for IGEP v2 board
(arch/arm/mach-omap2/board-igep0020.c) ?
Best regards,
Enric
--
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: [PATCHv2 14/15] OMAP: Panda, Beagle, Overo: DVI: Add i2c_bus_num
2011/9/12 Tomi Valkeinen tomi.valkei...@ti.com:
On Mon, 2011-09-12 at 11:58 +0200, Enric Balletbò i Serra wrote:
2011/9/12 Tomi Valkeinen tomi.valkei...@ti.com:
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 1 +
arch/arm/mach-omap2/board-overo.c | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 26bc860..742ac45 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -206,6 +206,7 @@ static void beagle_disable_dvi(struct omap_dss_device
*dssdev)
static struct panel_dvi_platform_data dvi_panel = {
.platform_enable = beagle_enable_dvi,
.platform_disable = beagle_disable_dvi,
+ .i2c_bus_num = 3,
};
static struct omap_dss_device beagle_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c35384e..a38ed273 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -458,6 +458,7 @@ static void omap4_panda_disable_dvi(struct
omap_dss_device *dssdev)
static struct panel_dvi_platform_data omap4_dvi_panel = {
.platform_enable = omap4_panda_enable_dvi,
.platform_disable = omap4_panda_disable_dvi,
+ .i2c_bus_num = 3,
};
struct omap_dss_device omap4_panda_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 06064d5..da94376 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -186,6 +186,7 @@ static void overo_panel_disable_dvi(struct
omap_dss_device *dssdev)
static struct panel_dvi_platform_data dvi_panel = {
.platform_enable = overo_panel_enable_dvi,
.platform_disable = overo_panel_disable_dvi,
+ .i2c_bus_num = 3,
};
static struct omap_dss_device overo_dvi_device = {
--
1.7.4.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
Please, can also include the same modification for IGEP v2 board
(arch/arm/mach-omap2/board-igep0020.c) ?
Sure. You have tested that the i2c bus is 3 and it works?
Yes, the i2c bus is 3 on IGEP v2 board and I'm just testing and seem is working.
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
USB Ethernet gadget doesn't work with DM3730
Hi all, Playing with USB ethernet gadget on IGEP boards with mainline kernel (Linux 3.0.0-rc7) I observed one strange behavior. The ethernet gadget works with one board with OMAP3530 but it doesn't with another one with DM3730. The log looks like this: root@igep00x0:~# modprobe g_ether [ 51.420257] g_ether gadget: using random host ethernet address [ 51.427886] usb0: MAC da:93:4b:2d:55:e9 [ 51.431915] usb0: HOST MAC 42:47:83:70:46:b6 [ 51.436706] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 [ 51.443725] g_ether gadget: g_ether ready [ 51.447906] musb-hdrc musb-hdrc: MUSB HDRC host driver [ 51.455871] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 1 [ 51.464141] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 51.471313] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 51.478912] usb usb1: Product: MUSB HDRC host driver [ 51.484161] usb usb1: Manufacturer: Linux 3.0.0-rc7-00027-g8d86e5f musb-hcd [ 51.491485] usb usb1: SerialNumber: musb-hdrc [ 51.498321] hub 1-0:1.0: USB hub found [ 51.502410] hub 1-0:1.0: 1 port detected root@igep00x0:~# ifconfig usb0 192.168.7.2 usb0 Link encap:Ethernet HWaddr DA:93:4B:2D:55:E9 inet addr:192.168.7.2 Bcast:192.168.7.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) root@igep00x0:~# ping 192.168.7.1 PING 192.168.7.1 (192.168.7.1): 56 data bytes With DM3730 I can't ping the other side (the same configuration with OMAP3530 works without problems). Any clue on this ? Cheers, Enric -- 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: [RESEND PATCH 1/4] omap: igep0020: name refactoring for future merge with IGEP3
Hi, 2011/5/17 Tony Lindgren t...@atomide.com: * Enric Balletbò i Serra eballe...@gmail.com [110516 10:11]: Hi Mike, The only comment I wanted to do is maybe I prefer rename the board-igep0020 to board-igep00x0 to be more generic. Apart from this these patch series looks good for me and has my ack. Thanks. I suggest we do the rename separately later on. Otherwise it easily gets classified as crazy churn type of patch, so best to stick to just code coalescing and fixes for this merge window. Ok, so Mike you've my ack, thanks Cheers, Enric -- 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: [RESEND PATCH 1/4] omap: igep0020: name refactoring for future merge with IGEP3
Hi Mike,
The only comment I wanted to do is maybe I prefer rename the
board-igep0020 to board-igep00x0 to be more generic. Apart from this
these patch series looks good for me and has my ack. Thanks.
2011/5/12 Mike Rapoport m...@compulab.co.il:
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,
+
Re: [RESEND PATCH 3/4] omap: igep0020: add support for IGEP3
2011/5/12 Mike Rapoport m...@compulab.co.il:
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_NRESET 137
+#define IGEP3_GPIO_LED0_GREEN 54
+#define IGEP3_GPIO_LED0_RED 53
+#define IGEP3_GPIO_LED1_RED 16
+#define IGEP3_GPIO_USBH_NRESET 183
+
/*
* IGEP2 Hardware Revision Table
*
@@ -69,6 +74,7 @@
#define IGEP2_BOARD_HWREV_B 0
#define IGEP2_BOARD_HWREV_C 1
+#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
Re: [RESEND PATCH 2/4] omap: igep0020: minor refactoring
2011/5/15 Arnd Bergmann a...@arndb.de: On Sunday 15 May 2011, m...@compulab.co.il wrote: We can keep all the data structures that differ between IGEP2 and IGEP3. However, this significantly reduces the benifit of the series. There's already code in the IGEP2 that differentiates between HW revisions, so anyway the board support will require some work for devicetree transition. Eventually, when devicetree will be usable on OMAPs, most of the code currently found in arch/arm/mach-omap2/board* will require some work and I hardly believe that the transition can be automated... True. Let's just use the version you posted then. Arnd Acked-by: Enric Balletbo i Serra eballe...@iseebcn.com -- 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: [RESEND PATCH 4/4] omap: drop board-igep0030.c
2011/5/12 Mike Rapoport m...@compulab.co.il:
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_RED 53
-#define IGEP3_GPIO_LED1_RED 16
-
-#define IGEP3_GPIO_WIFI_NPD 138
-#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,
-
Re: [RESEND PATCH 0/4] omap: merge IGEP v2 and v3
Hi Mike, 2011/5/12 Mike Rapoport m...@compulab.co.il: Hi Tony, I'm resending this with the correct arm-linux mailing list cc'ed.. Just discard the first set, sorry for the noise... 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. Against which tree is based your work ? Cheers, Enric 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
Re: [RFC] About ARM expansion boards and others things
2011/5/4 Vladimir Pantelic vlado...@gmail.com: Enric Balletbò i Serra wrote: Hi guys, I'm thinking probably in a crazy idea, I hope someone can help me or kill definitely this idea from my mind. I'll explain a little more, the real problem is I don't know how to add support for an expansion board for IGEP v2 board. I see most of boards adds the support inside the board-x.c file, for example if the expansion board has a Touchscreen interface using ADS7846/TSC2046 they register ads7846 platform data in board-.c file. This is ok beacause the ads7846 can be detected and if expansion board is not present the detection fails, but maybe other devices in expansion board can't be detected (for example an I/O expansion). So which is the best form to do this ? I'm thinking in create a kernel module for the expansion board that add all the new features, the expansion board should come with a I2C E2PROM for board ID storage, so the idea is create an i2c driver that reads the E2PROM and if found the Board ID inits all the expansion board devices. don't know if you are aware of that: http://elinux.org/BeagleBoardPinMux#Expansion_boards Yes I know it. also beagle.c board file has support for some expansion boards already, maybe there is some code to be shared. But I don't see any support for expansion board in board-omap3beagle.c http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/board-omap3beagle.c;h=33007fd4a0835fd298129c9fda30b844707cc08b;hb=HEAD i see some patches (not published in mainline) that are reading a kernel cmdline. I mean, the bootloader (u-boot) detects if an expansion board is present (mostly via i2c) and then add to the kernel cmdline a parameter with the name of the expansion board. The kernel reads this parameter and initializes the expansion board devices. But not sure if this is a good solution. What solution do you think is better ? Using kernel cmdline or create a separate kernel module for every expansion board ? In fact the purpose of this email is discuss a bit which is the proper solution to add an expansion board to the kernel mainline. Regards, Enric -- 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] About ARM expansion boards and others things
2011/5/4 Igor Grinberg grinb...@compulab.co.il: On 05/03/11 20:25, Enric Balletbò i Serra wrote: Hi guys, I'm thinking probably in a crazy idea, I hope someone can help me or kill definitely this idea from my mind. This is not that crazy as you think it is... I'll explain a little more, the real problem is I don't know how to add support for an expansion board for IGEP v2 board. I see most of boards adds the support inside the board-x.c file, for example if the expansion board has a Touchscreen interface using ADS7846/TSC2046 they register ads7846 platform data in board-.c file. This is ok beacause the ads7846 can be detected and if expansion board is not present the detection fails, but maybe other devices in expansion board can't be detected (for example an I/O expansion). So which is the best form to do this ? I'm thinking in create a kernel module for the expansion board that add all the new features, the expansion board should come with a I2C E2PROM for board ID storage, so the idea is create an i2c driver that reads the E2PROM and if found the Board ID inits all the expansion board devices. Why do you need to create a new driver? Why don't you use the existing one? at24 works nice with most i2c EEPROMs. Let me generalize: 1) Lets call each board that actually has SoC, like IGEP, a System On Module (SoM) 2) SoM has on-board and on-SoC devices 3) expansion has additional on-board devices 4) We are talking about X SoMs and Y extensions 5) Each SoM can be connected to each extension and communicate with its devices. 6) We are looking for a solution to be able to detect the expansion and register the devices it has assembled. Great generalitzation ! I have done a few experiments, I've created a kernel module (driver) for a custom expansion board for IGEP v2, the expansion board has : - I2C E2PROM - ADS7846 touch controller (spi) - Seiko 7.0inch LCD - General purpose I/O The driver is capable to register correctly i2c and spi devices and seems is working but I have problems with the Seiko 7.0inch LCD and configuring the MUX from driver. Like Tony already said the generic MUX API should solve the problem of MUX. But, you will still have a problem with devices that have to be initialized very early, like IO chips. Right, about the MUX, there is any patch or specification for the MUX API ? Basically I wonder if it's possible add another omap_dss_device from kernel module to the omap DSS driver (something like omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any reason to not export the MUX functionality to be used for other drivers ? ... All of this is a crazy idea ? What's the best form to solve the problem ? This is not crazy at all. We already use this concept in our BSP, we detect the expansion by reading data from EEPROM, and register the devices accordingly. We solve the MUX problem by initializing the pins to some default state and once the expansion detection is done, we reconfigure the pins to their right state as required by connected devices. And yes the above is done from board file. So its possilbe read the EEPROM in board file ? How ? I was thinking wasn't possible read the EEPROM in board initialitzation because was in a early state. I don't see any reason to create a driver for the expansion, unless it can be removed/attached on the fly while the SoM is up and running. Completely agree, normally expansion board can't be connected on the fly Nevertheless, some framework or at least an agreement on how we should separate the SoM code from the expansion code. I thought of some convention like board-*.c will stay the code for the SoM and exp-*.c will be used for the expansion code. Now, the code in board-*.c will do the detection of the expansion and run the appropriate exp_*_init() function, which will do the initialization steps for the detected expansion. A bit more complicated solution will be needed if there are several expansions connected all together. Looks good for me if this is the accepted solution. I have had this in my mind for very long time, but did not want to bother, because there were discussions about a totally different approach which uses device trees (DT), where the detection of expansion is moved away from the kernel code. With the DT approach, the kernel (should) get(s) all the information regarding the devices and how they are wired for free (no detection). If I understand correctly, the information about devices (whether on SoM or expansion) could be either statically added to the DT structures or dynamically detected by the bootloader and passed to the kernel (like ATAGS work now). Really interesting, I'll look that, do you think is the future to solve this problem ? Have you tested ? I still doubt what approach would be better... Me too, but I think it's interesting doing a brainstorming about this theme because
[RFC] About ARM expansion boards and others things
Hi guys, I'm thinking probably in a crazy idea, I hope someone can help me or kill definitely this idea from my mind. I'll explain a little more, the real problem is I don't know how to add support for an expansion board for IGEP v2 board. I see most of boards adds the support inside the board-x.c file, for example if the expansion board has a Touchscreen interface using ADS7846/TSC2046 they register ads7846 platform data in board-.c file. This is ok beacause the ads7846 can be detected and if expansion board is not present the detection fails, but maybe other devices in expansion board can't be detected (for example an I/O expansion). So which is the best form to do this ? I'm thinking in create a kernel module for the expansion board that add all the new features, the expansion board should come with a I2C E2PROM for board ID storage, so the idea is create an i2c driver that reads the E2PROM and if found the Board ID inits all the expansion board devices. I have done a few experiments, I've created a kernel module (driver) for a custom expansion board for IGEP v2, the expansion board has : - I2C E2PROM - ADS7846 touch controller (spi) - Seiko 7.0inch LCD - General purpose I/O The driver is capable to register correctly i2c and spi devices and seems is working but I have problems with the Seiko 7.0inch LCD and configuring the MUX from driver. Basically I wonder if it's possible add another omap_dss_device from kernel module to the omap DSS driver (something like omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any reason to not export the MUX functionality to be used for other drivers ? All of this is a crazy idea ? What's the best form to solve the problem ? I hope I have explained well, thanks and cheers, Enric -- 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
omap: USB host disconnects connecting a device through USB HUB
Hi all, I'm experimenting some issues with USB on IGEP v2 board, in certain cases I've an USB disconnect when I plug a device. For me it fails with kernel 2.6.35 but I think it also affect newer kernel, the issue is easy to reproduce following these steps: 1. Power up the board (without any device connected ) 2. When kernel is up, connect a powered USB HUB 2.0 to the USB host port, kernel shows, usb 1-1: new high speed USB device using ehci-omap and address 2 usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.4: new high speed USB device using ehci-omap and address 3 usb 1-1.4: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1.4: Product: USB2.0 Hub hub 1-1.4:1.0: USB hub found hub 1-1.4:1.0: 4 ports detected 3. Then if I connect a device (for example a pendrive) to the HUB I get USB disconnect message usb 1-1: USB disconnect, address 2 usb 1-1.4: USB disconnect, address 3 OTOH, it works without problem 1. if power up the board with the USB HUB connected to the USB Host port and the device connected to the USB hub. 2. if after kernel is up, connect the USB HUB + device to the USB Host port Anyone is experimenting something like this with other OMAP3-based boards ? Regards, Enric Balletbò i Serra -- 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: omap: USB host disconnects connecting a device through USB HUB
Hi, 2011/4/7 Alan Stern st...@rowland.harvard.edu: On Thu, 7 Apr 2011, Enric Balletbò i Serra wrote: Hi all, I'm experimenting some issues with USB on IGEP v2 board, in certain cases I've an USB disconnect when I plug a device. For me it fails with kernel 2.6.35 but I think it also affect newer kernel, the issue is easy to reproduce following these steps: 1. Power up the board (without any device connected ) 2. When kernel is up, connect a powered USB HUB 2.0 to the USB host port, kernel shows, usb 1-1: new high speed USB device using ehci-omap and address 2 usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.4: new high speed USB device using ehci-omap and address 3 usb 1-1.4: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1.4: Product: USB2.0 Hub hub 1-1.4:1.0: USB hub found hub 1-1.4:1.0: 4 ports detected 3. Then if I connect a device (for example a pendrive) to the HUB I get USB disconnect message usb 1-1: USB disconnect, address 2 usb 1-1.4: USB disconnect, address 3 OTOH, it works without problem 1. if power up the board with the USB HUB connected to the USB Host port and the device connected to the USB hub. 2. if after kernel is up, connect the USB HUB + device to the USB Host port Anyone is experimenting something like this with other OMAP3-based boards ? At first glance, it looks like a power-related issue. Current inrush when the device is plugged in, or something like that. What happens if you attach the hub and pendrive to a standard PC? With standard PC works as expected, would be possible a problem with omap-ehci driver ? Maybe Felipe can give some light ? Alan Stern -- 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: [REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
2010/12/13 Tony Lindgren t...@atomide.com: * Enric Balletbò i Serra eballe...@gmail.com [101213 08:47]: Tony, please can this patch be included before 2.6.37 ? Without this patch the wifi module on IGEP v2 board not works. Sorry it's too much for the -rc series. For the -rc series the fixes should be major bugs. This is in the category it never worked before. I will add it to omap-boards branch for the next merge window over the next few days while going through all the pending patches in patchwork. Ok, I'll wait :-) thanks Cheers, Enric -- 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 1/2] omap3: igepv2: Don't call gpio_set_value right after gpio_direction_output
2010/12/12 Laurent Pinchart laurent.pinch...@ideasonboard.com:
gpio_direction_output() has a value argument, there's no need to call
gpio_set_value() explicitly right after.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/board-igep0020.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..20b88c1 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -342,24 +342,21 @@ static void __init igep2_leds_init(void)
static inline void igep2_leds_init(void)
{
if ((gpio_request(IGEP2_GPIO_LED0_RED, gpio-led:red:d0) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED0_RED, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED0_RED, 0) == 0))
gpio_export(IGEP2_GPIO_LED0_RED, 0);
- gpio_set_value(IGEP2_GPIO_LED0_RED, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_RED\n);
if ((gpio_request(IGEP2_GPIO_LED0_GREEN, gpio-led:green:d0) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 0) == 0))
gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
- gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n);
if ((gpio_request(IGEP2_GPIO_LED1_RED, gpio-led:red:d1) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED1_RED, 0) == 0))
gpio_export(IGEP2_GPIO_LED1_RED, 0);
- gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_RED\n);
}
@@ -397,10 +394,9 @@ static int igep2_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, gpio-led:green:d1) == 0)
- (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0)) {
+ (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
- gpio_set_value(gpio + TWL4030_GPIO_MAX + 1, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n);
#else
igep2_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.7.2.2
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
--
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] omap3: igepv2: LED gpio-led:green:d1 is active low
2010/12/12 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Make sure the LED is turned off at boot time, and configure the GPIO LED
device as active low.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/board-igep0020.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 20b88c1..41a4b25 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -317,6 +317,7 @@ static struct gpio_led igep2_gpio_leds[] = {
.name = gpio-led:green:d1,
.default_trigger = heartbeat,
.gpio = -EINVAL, /* gets replaced */
+ .active_low = 1,
},
};
@@ -394,7 +395,7 @@ static int igep2_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, gpio-led:green:d1) == 0)
- (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
+ (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0))
gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n);
--
1.7.2.2
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
--
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: [REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
Hi all,
2010/12/4 Marc Zyngier m...@misterjones.org:
Commit 72f381ba056 (omap3: Remove VMMC2 regulator on IGEP v2)
removed an unused regulator entry, but left the second MMC channel
(used by the Libertas WLAN module) without link to power regulator.
This causes the SDIO module to fail being detected.
This patch adds the two regulators that actually feed the WLAN module
(1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the
second channel is properly detected. Details of the power supply
implementation were kindly provided by Enric Balletbo i Serra.
Also change vmmc1 to use symbolic names instead of direct device
reference.
Tested on an IGEPv2 Rev-B.
Signed-off-by: Marc Zyngier m...@misterjones.org
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-igep0020.c | 61 -
1 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..9a85e60 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -19,6 +19,7 @@
#include linux/interrupt.h
#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
@@ -257,9 +258,8 @@ static inline void __init igep2_init_smsc911x(void) { }
static struct omap_board_config_kernel igep2_config[] __initdata = {
};
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
- .supply = vmmc,
-};
+static struct regulator_consumer_supply igep2_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data igep2_vmmc1 = {
@@ -276,6 +276,52 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies = igep2_vmmc1_supply,
};
+static struct regulator_consumer_supply igep2_vio_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = 1,
+ .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 = igep2_vio_supply,
+};
+
+static struct regulator_consumer_supply igep2_vmmc2_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+
+static struct regulator_init_data igep2_vmmc2 = {
+ .constraints = {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .always_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vmmc2_supply,
+};
+
+static struct fixed_voltage_config igep2_vwlan = {
+ .supply_name = vwlan,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .enabled_at_boot = 1,
+ .init_data = igep2_vmmc2,
+};
+
+static struct platform_device igep2_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 0,
+ .dev = {
+ .platform_data = igep2_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc = 1,
@@ -373,12 +419,6 @@ static int igep2_twl_gpio_setup(struct device *dev,
omap2_hsmmc_init(mmc);
/*
- * link regulators to MMC adapters ... we know the
- * regulators will be set up only *after* we return.
- */
- igep2_vmmc1_supply.dev = mmc[0].dev;
-
- /*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
@@ -489,6 +529,7 @@ static void __init igep2_display_init(void)
static struct platform_device *igep2_devices[] __initdata = {
igep2_dss_device,
+ igep2_vwlan_device,
};
static void __init igep2_init_irq(void)
@@ -519,7 +560,7 @@ static struct twl4030_platform_data igep2_twldata = {
.gpio = igep2_twl4030_gpio_pdata,
.vmmc1 = igep2_vmmc1,
.vpll2 = igep2_vpll2,
-
+ .vio = igep2_vio,
};
static struct i2c_board_info __initdata igep2_i2c1_boardinfo[] = {
--
1.7.3.2
Tony, please can this patch be included before 2.6.37 ? Without this
patch the wifi module on IGEP v2 board not works.
Thanks,
Enric Balletbo i Serra.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
Re: [PATCH] Fix IGEPv2 second MMC channel power supply
Hi, 2010/11/14 Marc Zyngier m...@misterjones.org: On Sun, 14 Nov 2010 19:11:46 +0100 Enric Balletbò i Serra eballe...@gmail.com wrote: Why we need to define an unexistent regulator in board file ? This should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel configuration ? I'm not adding another regulator, but instead simply exposing the fact (or rather my guess) that the same regulator (vmmc1) is powering the two MMC channels. Not having access to the board schematics, I can't tell if that reflects the reality or not. But using CONFIG_DUMMY_REGULATOR seems the wrong idea to me, as it's just papering over the issue. We should be exposing what's really on the board (a fixed regulator if that's the case). So the DUMMY_REGULATOR is only a workaround when a regulator is not defined and shouldn't be used ? Sorry if this is a stupid question but regulator interface is not too clear for me. The reality is this : --- | 3V3 | | 1V8 | --- | | - | WIFI/BT | - | ( MMC2 at 1V8 ) | OMAP | --- 3V3 is a fixed regulator 1V8 is a fixed regulator (VIO from TWL4030) So, which you think is the right solution ? Cheers, Enric -- 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] Fix IGEPv2 second MMC channel power supply
2010/11/14 Felipe Balbi m...@felipebalbi.com:
Hi,
On Sun, 14 Nov 2010 11:34:12 +, Marc Zyngier m...@misterjones.org
wrote:
@@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = igep2_vmmc1_supply,
+ .num_consumer_supplies = 2,
use ARRAY_SIZE(igep2_vmmc1_supplies),
--
balbi
Why we need to define an unexistent regulator in board file ? This
should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel
configuration ?
Cheers,
Enric
--
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
USB Ethernet gadget seems doesn't work with current mainline
Hello all, With current mainline and stable 2.6.35.y branch I've some strange features with USB ethernet gadget ... r...@igep0020:~# uname -a Linux igep0020 2.6.37-rc1+ #1 Fri Nov 5 09:22:53 CET 2010 armv7l unknown unknown GNU/Linux r...@igep0020:~# ifconfig usb0 Link encap:Ethernet HWaddr 5A:A9:54:25:4C:04 inet addr:192.168.7.2 Bcast:192.168.7.255 Mask:255.255.255.0 inet6 addr: fe80::58a9:54ff:fe25:4c04/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:4951 (4.8 KiB) Pinging seems not work r...@igep0020:~# ping -c5 192.168.7.1 PING 192.168.7.1 (192.168.7.1): 56 data bytes --- 192.168.7.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss Curiously if I unplug and plug the USB cable, and ping again ... r...@igep0020:~# ping -c5 192.168.7.1 PING 192.168.7.1 (192.168.7.1): 56 data bytes 64 bytes from 192.168.7.1: seq=0 ttl=64 time=0.397 ms 64 bytes from 192.168.7.1: seq=1 ttl=64 time=0.489 ms 64 bytes from 192.168.7.1: seq=2 ttl=64 time=0.397 ms 64 bytes from 192.168.7.1: seq=3 ttl=64 time=0.366 ms 64 bytes from 192.168.7.1: seq=4 ttl=64 time=0.396 ms --- 192.168.7.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.366/0.409/0.489 ms Works, anyone knows if the ethernet gadget is broken in current mainline or have observed this feature ? Thanks in advance, Enric -- 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: USB Ethernet gadget seems doesn't work with current mainline
Hi, 2010/11/5 Ming Lei tom.leim...@gmail.com: 2010/11/5 Grazvydas Ignotas nota...@gmail.com: hi, On Fri, Nov 5, 2010 at 10:39 AM, Enric Balletbò i Serra eballe...@gmail.com wrote: Hello all, With current mainline and stable 2.6.35.y branch I've some strange features with USB ethernet gadget ... r...@igep0020:~# uname -a Linux igep0020 2.6.37-rc1+ #1 Fri Nov 5 09:22:53 CET 2010 armv7l unknown unknown GNU/Linux r...@igep0020:~# ifconfig usb0 Link encap:Ethernet HWaddr 5A:A9:54:25:4C:04 inet addr:192.168.7.2 Bcast:192.168.7.255 Mask:255.255.255.0 inet6 addr: fe80::58a9:54ff:fe25:4c04/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:4951 (4.8 KiB) Pinging seems not work r...@igep0020:~# ping -c5 192.168.7.1 PING 192.168.7.1 (192.168.7.1): 56 data bytes --- 192.168.7.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss Curiously if I unplug and plug the USB cable, and ping again ... r...@igep0020:~# ping -c5 192.168.7.1 PING 192.168.7.1 (192.168.7.1): 56 data bytes 64 bytes from 192.168.7.1: seq=0 ttl=64 time=0.397 ms 64 bytes from 192.168.7.1: seq=1 ttl=64 time=0.489 ms 64 bytes from 192.168.7.1: seq=2 ttl=64 time=0.397 ms 64 bytes from 192.168.7.1: seq=3 ttl=64 time=0.366 ms 64 bytes from 192.168.7.1: seq=4 ttl=64 time=0.396 ms --- 192.168.7.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.366/0.409/0.489 ms Works, anyone knows if the ethernet gadget is broken in current mainline or have observed this feature ? Please try this patch: http://marc.info/?l=linux-usbm=128576496614332w=2 Report back if it works, maybe then that patch will finally get merged.. No, the patch is not merged to now. Felipe, seems it is time to send out this musb bugfix patches. Thanks, the patch is working for me in mainline on my IGEP's board. Also the issue is fixed on my linux-2.6.35.y branch applying the patch and cherry-picking f11d893de444965dfd3e55f726533ae1df5c6471 usb: musb: support ISO high bandwidth for gadget mode b0fca50f5a94a268ed02cfddf8051ed9343f usb gadget: don't save bind callback in struct usb_gadget_driver Cheers, Enric -- 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 all, 2010/10/10 Mike Rapoport m...@compulab.co.il: 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... On my hardware with this version of the patch and with commit b417577d3b9bbb06a4ddc9aa955af9bd503f7242 previously applied still not working, I'm missing something else ? Cheers, Enric 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 -- 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 add an expansion board on IGEP v2 board.
Hello all, I would ask some technical questions, maybe someone can help me. I would add support for a new expansion board for IGEP v2 board, The expansion board comes with a EEPROM, the EEPROM is used to identify the expansion board, my idea is create a new file for expansion board ( board-igep0020-expansion.c ) and * on board-igep0020.c - Add extern void __init igep2_expansion_init(void); - Call igep2_expansion_init on igep2_init() * on board-igep0020-expansion.c - Create igep2_expansion_init, inside this funciton - Add e2prom device and read board id - If board ID exists then init all expansion devices I'm in the right way ? Comments ? Thanks in advance, Enric -- 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
Add new omap_dss_device after dss_device_registration
Hello all, Can I add a new omap_dss_device after dss_device registration ? Something like add_new_omap_dss_device(lcd_device) or similar ? On IGEP v2 we register only igep2_dvi_device as dss_device, We want to add a new dss_device (igep2_lcd_device) after dss registration. Is it possible ? For example we want to do something like this : step 1: register IGEP v2 dss_devices (dvi) step 2: detect if IGEP expansion board is detected. step 3: if it's detected add new dss_devices (lcd) Thanks in advance, Enric -- 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: Add minimal OMAP3 IGEP module support.
2010/10/2 Tony Lindgren t...@atomide.com: * Enric Balletbo i Serra eballe...@gmail.com [101001 15:18]: The OMAP3 IGEP module is a low-power, high performance production-ready system-on-module (SOM) based on TI's OMAP3 family. Looks OK to me, but also looks like you're missing the uncompress.h DEBUG_LL/EARLY_PRINTK entry? Mmmm, I see I missed I'll send the version two... I'm learning a lot, thanks for your patience :-) Kind regards, Enric -- 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: [PATCHv3 1/6] omap3: Add external VBUS power switch and overcurrent detect on IGEP v2 board.
2010/10/2 David Cohen david.co...@nokia.com: Hi, On Fri, Oct 01, 2010 at 11:09:04PM +0200, ext Enric Balletbo i Serra wrote: GPIO for various devices are missing from the board initialization. This patch adds support for the VBUS and over current gpios. Without this patch, input/outputs from these two sources are ignored. Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com --- arch/arm/mach-omap2/board-igep0020.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c index 175f043..07dbdb7 100644 --- a/arch/arm/mach-omap2/board-igep0020.c +++ b/arch/arm/mach-omap2/board-igep0020.c @@ -274,6 +274,22 @@ static int igep2_twl_gpio_setup(struct device *dev, igep2_vmmc1_supply.dev = mmc[0].dev; igep2_vmmc2_supply.dev = mmc[1].dev; + /* + * REVISIT: need ehci-omap hooks for external VBUS + * power switch and overcurrent detect + */ + if ((gpio_request(gpio + 1, GPIO_EHCI_NOC) 0) || + (gpio_direction_input(gpio + 1) 0)) + pr_err(IGEP2: Could not obtain gpio for EHCI NOC); Shouldb't you return error if it can't request the GPIO? I'm not sure what happens if I return and error, I see only prints a debug message. Maybe the twl4030-gpio maintainer can explain if I need return and error or not. Other omap boards just don't check the gpio_request call and always return 0. I don't consider this a critical error so maybe should be better replace the pr_err with a pr_warning. + + /* + * TWL4030_GPIO_MAX + 0 == ledA, GPIO_USBH_CPEN + * (out, active low) + */ + if ((gpio_request(gpio + TWL4030_GPIO_MAX, GPIO_USBH_CPEN) 0) || + (gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0) 0)) + pr_err(IGEP2: Could not obtain gpio for USBH_CPEN); Same here. + return 0; }; Kind regards, Enric -- 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: musb_hdrc: usb_disconnect is not called when the USB device is disconnected.
2010/7/14 Gadiyar, Anand gadi...@ti.com: Enric Balletbò i Serra Hello, When I disconnect an USB pendrive using twl4030 otg as host (step 2) the usb_disconnect function is not called. OTOH if I reconnect the device (step 3), then the usb_disconnect function is called. Does anyone have any ideas why usb_disconnect is not called when the device is removed? Which kernel version is this? Can you check if this patch fixes the behavior? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d9645fdca444d53907b22a4b73e3967efe09781 I'm using stable kernel 2.6.33.6 And yes this patch is not applied in this version. I applied and solves the issue. Thank you very much. Best regards, -- Enric - Anand Steps to see the feature: Step 1 : Plug a USB pendrive: [ 2116.491546] usb 1-1: new high speed USB device using musb_hdrc and address 6 [ 2116.751861] usb 1-1: New USB device found, idVendor=058f, idProduct=6387 [ 2116.758697] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2116.765899] usb 1-1: Product: Mass Storage [ 2116.770019] usb 1-1: Manufacturer: 2.0 [ 2116.773834] usb 1-1: SerialNumber: A15B7B60 [ 2116.786468] scsi4 : usb-storage 1-1:1.0 [ 2117.797332] scsi 4:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ: 0 ANSI: 2 [ 2117.813293] sd 4:0:0:0: [sda] 1968128 512-byte logical blocks: (1.00 GB/961 MiB) [ 2117.829040] sd 4:0:0:0: [sda] Write Protect is off [ 2117.834014] sd 4:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 2117.834014] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.849212] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.856597] sda: sda1 [ 2117.965698] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.971954] sd 4:0:0:0: [sda] Attached SCSI removable disk [ 2118.738769] FAT: bogus number of reserved sectors [ 2118.743621] VFS: Can't find a valid FAT filesystem on dev sda. Step 2: Unplug the USB pendrive [ nothing here ] Step 3: Plug the USB pendrive: [ 2218.820556] usb 1-1: USB disconnect, address 6 [ 2219.139831] usb 1-1: new high speed USB device using musb_hdrc and address 7 [ 2219.400146] usb 1-1: New USB device found, idVendor=058f, idProduct=6387 [ 2219.406951] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2219.414184] usb 1-1: Product: Mass Storage [ 2219.418304] usb 1-1: Manufacturer: 2.0 [ 2219.422119] usb 1-1: SerialNumber: A15B7B60 [ 2219.434875] scsi5 : usb-storage 1-1:1.0 [ 2220.445770] scsi 5:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ: 0 ANSI: 2 [ 2220.461547] sd 5:0:0:0: [sda] 1968128 512-byte logical blocks:(1.00 GB/961 MiB) [ 2220.476379] sd 5:0:0:0: [sda] Write Protect is off [ 2220.481323] sd 5:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 2220.481323] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.497314] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.504516] sda: sda1 [ 2220.603790] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.610015] sd 5:0:0:0: [sda] Attached SCSI removable disk [ 2221.378570] FAT: bogus number of reserved sectors [ 2221.383453] VFS: Can't find a valid FAT filesystem on dev sda. -- 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: Possible bug in onenand_base ?
Hello,
2010/7/8 Artem Bityutskiy dedeki...@gmail.com:
On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote:
Hello,
2010/7/8 Artem Bityutskiy dedeki...@gmail.com:
On Thu, 2010-07-08 at 11:55 +0200, Enric Balletbò i Serra wrote:
Hello,
I made new tests regarding this issue. Looks like the problem is
reading from the OneNAND device.
Did you try older kernel and then bisecting who is responsible for the
breakage?
Yes, before commit
5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support)
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5988af2319781bc8e0ce418affec4e09cfa77907
my OneNAND is working, after the commit, the OneNAND support is broken.
Ok, we could revert it, but it is better to fix it. CCing the author of
the commit.
Comparing the onenand_base.c file before commit
5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support)
and after the commit I made a little patch which seems solves the
issue. The patch has two parts.
The first part replaces line 380 with 'page = (int) (addr
this-page_shift);' like before apply the Flex-OneNAND support. I
suppose this is not the better solution, but with this the nandtest
tool works for me. Maybe the author of the commit can clarify this.
The second part (1964) adds two lines which I think are missed when
the Flex-OneNAND support was applied.
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 26caf25..a39d906 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -377,7 +377,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block))
this-page_shift;
+ page = (int) (addr this-page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
@@ -1961,6 +1961,9 @@ static int onenand_write_ops_nolock(struct
mtd_info *mtd, loff_t to,
/* In partial page write we don't update bufferram */
onenand_update_bufferram(mtd, to, !ret !subpage);
+ ONENAND_SET_BUFFERRAM1(this);
+ onenand_update_bufferram(mtd, to +
this-writesize, !ret !subpage);
+
if (ret) {
printk(KERN_ERR %s: write failed %d\n,
__func__, ret);
Best regards,
Enric
--
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
musb_hdrc: usb_disconnect is not called when the USB device is disconnected.
Hello, When I disconnect an USB pendrive using twl4030 otg as host (step 2) the usb_disconnect function is not called. OTOH if I reconnect the device (step 3), then the usb_disconnect function is called. Does anyone have any ideas why usb_disconnect is not called when the device is removed? Steps to see the feature: Step 1 : Plug a USB pendrive: [ 2116.491546] usb 1-1: new high speed USB device using musb_hdrc and address 6 [ 2116.751861] usb 1-1: New USB device found, idVendor=058f, idProduct=6387 [ 2116.758697] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2116.765899] usb 1-1: Product: Mass Storage [ 2116.770019] usb 1-1: Manufacturer: 2.0 [ 2116.773834] usb 1-1: SerialNumber: A15B7B60 [ 2116.786468] scsi4 : usb-storage 1-1:1.0 [ 2117.797332] scsi 4:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ: 0 ANSI: 2 [ 2117.813293] sd 4:0:0:0: [sda] 1968128 512-byte logical blocks: (1.00 GB/961 MiB) [ 2117.829040] sd 4:0:0:0: [sda] Write Protect is off [ 2117.834014] sd 4:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 2117.834014] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.849212] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.856597] sda: sda1 [ 2117.965698] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.971954] sd 4:0:0:0: [sda] Attached SCSI removable disk [ 2118.738769] FAT: bogus number of reserved sectors [ 2118.743621] VFS: Can't find a valid FAT filesystem on dev sda. Step 2: Unplug the USB pendrive [ nothing here ] Step 3: Plug the USB pendrive: [ 2218.820556] usb 1-1: USB disconnect, address 6 [ 2219.139831] usb 1-1: new high speed USB device using musb_hdrc and address 7 [ 2219.400146] usb 1-1: New USB device found, idVendor=058f, idProduct=6387 [ 2219.406951] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2219.414184] usb 1-1: Product: Mass Storage [ 2219.418304] usb 1-1: Manufacturer: 2.0 [ 2219.422119] usb 1-1: SerialNumber: A15B7B60 [ 2219.434875] scsi5 : usb-storage 1-1:1.0 [ 2220.445770] scsi 5:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ: 0 ANSI: 2 [ 2220.461547] sd 5:0:0:0: [sda] 1968128 512-byte logical blocks: (1.00 GB/961 MiB) [ 2220.476379] sd 5:0:0:0: [sda] Write Protect is off [ 2220.481323] sd 5:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 2220.481323] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.497314] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.504516] sda: sda1 [ 2220.603790] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.610015] sd 5:0:0:0: [sda] Attached SCSI removable disk [ 2221.378570] FAT: bogus number of reserved sectors [ 2221.383453] VFS: Can't find a valid FAT filesystem on dev sda. Thanks in advance, Enric -- 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: Possible bug in onenand_base ?
Hello,
I made new tests regarding this issue. Looks like the problem is
reading from the OneNAND device.
TEST 1
# modprobe mtd_pagetest dev=4
[ 126.505340]
[ 126.506866] =
[ 126.512756] mtd_pagetest: MTD device: 4
[ 126.520477] mtd_pagetest: MTD device size 262668288, eraseblock
size 262144, page size 4096, count of eraseblocks 1002, pages per
eraseblock 64, OOB size 64
[ 126.535034] mtd_pagetest: scanning for bad eraseblocks
[ 126.540771] mtd_pagetest: scanned 1002 eraseblocks, 0 are bad
[ 126.546630] mtd_pagetest: erasing whole device
[ 128.406890] mtd_pagetest: erased 1002 eraseblocks
[ 128.411712] mtd_pagetest: writing whole device
[ 128.451721] mtd_pagetest: written up to eraseblock 0
[ 137.443817] mtd_pagetest: written up to eraseblock 256
[ 146.440216] mtd_pagetest: written up to eraseblock 512
[ 155.430755] mtd_pagetest: written up to eraseblock 768
[ 163.618225] mtd_pagetest: written 1002 eraseblocks
[ 163.623168] mtd_pagetest: verifying all eraseblocks
[ 163.632965] onenand_wait: ECC error = 0x4488
[ 163.638031] onenand_wait: ECC error = 0x4884
[ 163.642486] onenand_wait: ECC error = 0x
[ 163.647247] onenand_wait: ECC error = 0x
[ 163.651733] mtd_pagetest: error: read failed at 0x0
[ 163.656890] mtd_pagetest: error -74 occurred
[ 163.661224] =
TEST 2
# nandtest -l 262144 /dev/mtd4
ECC corrections: 0
ECC failures : 260
Bad blocks : 0
BBT blocks : 0
: reading...[ 837.103302] onenand_wait: ECC error = 0x8488
[ 837.109832] onenand_wait: ECC error = 0x8488
[ 837.114532] onenand_wait: ECC error = 0x
(...)
[ 837.683624] onenand_wait: ECC error = 0x8448
[ 837.688079] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
(...)
I suspect currently OneNAND with 2 planes is broken. Someone with this
type of device can try these tests ?
Thanks in advance,
Enric
2010/5/12 Enric Balletbò i Serra eballe...@gmail.com:
I answer to myself.
DDP (dual die plane) not implies 'ONENAND_HAS_2PLANE'. A device with
a single die can also have '2 planes'. I'm right ?
Sorry for these newbie questions, I'm just introducing to OneNAND devices.
Cheers,
Enric
2010/5/12 Enric Balletbò i Serra eballe...@gmail.com:
Hello,
I have a bit of time to investigate more.
I have two boards with two different OneNAND chips populated.
The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
[ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[ 26.412170] OneNAND version = 0x0031
[ 26.415771] Chip support all block unlock
[ 26.419830] Chip has 2 plane
The second is a single die of 2-Gbit.
[ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 32.902557] OneNAND version = 0x0031
[ 32.906188] Chip support all block unlock
[ 32.910247] Chip has 2 plane
As I understand the bit 3 of DEVICE_ID register indicates if package
is a single-die or a dual-die, so
- Muxed OneNAND(DDP) 512MB 1.8V 16-bit - device id: 0x58 - bit 3 is
1 - dual-die
- Muxed OneNAND 256MB 1.8V 16-bit - device id: 0x40 - bit 3 is 0
-single-die
The question is, why those devices are reporting 'Chip has 2 plane' ?
Sorry if this is a trivial question but I'm not sure about DDP and '2
plane' concepts. Are the same ?
Cheers,
Enric
2010/5/6 Enric Balletbò i Serra eballe...@gmail.com:
Hi,
2010/5/6 Kyungmin Park kmp...@infradead.org:
Hi,
What's your chip version? maybe some mis-probe it seems to be probed
at 4KiB pagesize OneNAND.
Is a 4-Gbit DDP OneNAND device from Numonyx composed of two 2-Gbit 2KB
page dice stacked together, the device is equipped with two DataRAMs,
and two-plane NAND Flash memory array,
These two component enables simultaneous program of 4KiB (
CONFIG_MTD_ONENAND_2X_PROGRAM)
Cheers,
Enric
Thank you,
Kyungmin Park
On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
Hi,
2010/5/6 Kyungmin Park kyungmin.p...@samsung.com:
Hi,
Can you add this statement at below the code?
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__, page, (int)
onenand_addr(this, block), ((int) addr this-page_shift)
this-page_mask);
Yes,
With this code nandtest fails:
onenand_base.c
377: default:
block = onenand_block(this, addr);
/* (line disabled) page = (int) (addr this-page_shift); */
page = (int) (addr - onenand_addr(this, block))
this-page_shift;
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr
this-page_shift)
this-page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block = ~1;
/* Is it the odd plane
Re: Possible bug in onenand_base ?
Hello, 2010/7/8 Artem Bityutskiy dedeki...@gmail.com: On Thu, 2010-07-08 at 11:55 +0200, Enric Balletbò i Serra wrote: Hello, I made new tests regarding this issue. Looks like the problem is reading from the OneNAND device. Did you try older kernel and then bisecting who is responsible for the breakage? Yes, before commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5988af2319781bc8e0ce418affec4e09cfa77907 my OneNAND is working, after the commit, the OneNAND support is broken. Cheers, Enric -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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
mtd_pagetest fails with omap2 OneNAND driver
Hello, I need some help to understand what is wrong, maybe someone can help me. I'm running an OMAP3-based board with a OneNAND from Numonyx, the problem is some mtd tests fails. An example is the mtd_pagetest, the erase test fails. [ 937.885925] mtd_pagetest: erasetest [ 937.889434] mtd_pagetest: erasing block 0 [ 937.895721] mtd_pagetest: writing 1st page of block 0 [ 937.901550] mtd_pagetest: erasing block 0 [ 937.907623] mtd_pagetest: reading 1st page of block 0 [ 937.912994] mtd_pagetest: verifying 1st page of block 0 is all 0xff [ 937.919342] mtd_pagetest: verifying all 0xff failed at 0 [ 937.924713] mtd_pagetest: finished with 1 errors If I read the mtd contents # mtd_debug read /dev/mtd4 0 1024 output.log # hexdump output.log 000 1caf ecfa 976b aa81 700a 9ce1 5427 32eb looks like the mtd partition it's not erased, but If I use the flash_eraseall tool erases the flash completely without problem # flash_eraseall /dev/mtd4 Erasing 256 Kibyte @ fa8 -- 100 % complete. # mtd_debug read /dev/mtd4 0 1024 output.log Copied 1024 bytes from address 0x in flash to file.log # hexdump output.log 000 * 400 So I don't understand why this test fails. Any idea what might be wrong ? Here the full log [ 775.590270] = [ 775.596160] mtd_pagetest: MTD device: 4 [ 775.603851] mtd_pagetest: MTD device size 262668288, eraseblock size 262144, page size 4096, count of eraseblocks 1002, pages per eraseblock 64, OOB size 64 [ 775.618408] mtd_pagetest: scanning for bad eraseblocks [ 775.624420] mtd_pagetest: scanned 1002 eraseblocks, 0 are bad [ 775.630218] mtd_pagetest: erasing whole device [ 777.486846] mtd_pagetest: erased 1002 eraseblocks [ 777.491638] mtd_pagetest: writing whole device [ 777.531585] mtd_pagetest: written up to eraseblock 0 [ 786.519378] mtd_pagetest: written up to eraseblock 256 [ 795.505706] mtd_pagetest: written up to eraseblock 512 [ 804.488769] mtd_pagetest: written up to eraseblock 768 [ 812.668182] mtd_pagetest: written 1002 eraseblocks [ 812.673126] mtd_pagetest: verifying all eraseblocks [ 812.803375] mtd_pagetest: verified up to eraseblock 0 [ 844.772460] mtd_pagetest: verified up to eraseblock 256 [ 876.734741] mtd_pagetest: verified up to eraseblock 512 [ 908.696838] mtd_pagetest: verified up to eraseblock 768 [ 937.791229] mtd_pagetest: verified 1002 eraseblocks [ 937.796234] mtd_pagetest: crosstest [ 937.800903] mtd_pagetest: reading page at 0x0 [ 937.805877] mtd_pagetest: reading page at 0xfa7f000 [ 937.811096] mtd_pagetest: reading page at 0x0 [ 937.816070] mtd_pagetest: verifying pages read at 0x0 match [ 937.821838] mtd_pagetest: crosstest ok [ 937.825622] mtd_pagetest: erasecrosstest [ 937.829589] mtd_pagetest: erasing block 0 [ 937.835906] mtd_pagetest: writing 1st page of block 0 [ 937.841552] mtd_pagetest: reading 1st page of block 0 [ 937.847198] mtd_pagetest: verifying 1st page of block 0 [ 937.852600] mtd_pagetest: erasing block 0 [ 937.858734] mtd_pagetest: writing 1st page of block 0 [ 937.864379] mtd_pagetest: erasing block 1001 [ 937.870788] mtd_pagetest: reading 1st page of block 0 [ 937.876342] mtd_pagetest: verifying 1st page of block 0 [ 937.881652] mtd_pagetest: erasecrosstest ok [ 937.885925] mtd_pagetest: erasetest [ 937.889434] mtd_pagetest: erasing block 0 [ 937.895721] mtd_pagetest: writing 1st page of block 0 [ 937.901550] mtd_pagetest: erasing block 0 [ 937.907623] mtd_pagetest: reading 1st page of block 0 [ 937.912994] mtd_pagetest: verifying 1st page of block 0 is all 0xff [ 937.919342] mtd_pagetest: verifying all 0xff failed at 0 [ 937.924713] mtd_pagetest: finished with 1 errors [ 937.929870] = Thanks in advance, Enric -- 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: Possible bug in onenand_base ?
Hello,
I have a bit of time to investigate more.
I have two boards with two different OneNAND chips populated.
The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
[ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[ 26.412170] OneNAND version = 0x0031
[ 26.415771] Chip support all block unlock
[ 26.419830] Chip has 2 plane
The second is a single die of 2-Gbit.
[ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 32.902557] OneNAND version = 0x0031
[ 32.906188] Chip support all block unlock
[ 32.910247] Chip has 2 plane
As I understand the bit 3 of DEVICE_ID register indicates if package
is a single-die or a dual-die, so
- Muxed OneNAND(DDP) 512MB 1.8V 16-bit - device id: 0x58 - bit 3 is
1 - dual-die
- Muxed OneNAND 256MB 1.8V 16-bit - device id: 0x40 - bit 3 is 0 -single-die
The question is, why those devices are reporting 'Chip has 2 plane' ?
Sorry if this is a trivial question but I'm not sure about DDP and '2
plane' concepts. Are the same ?
Cheers,
Enric
2010/5/6 Enric Balletbò i Serra eballe...@gmail.com:
Hi,
2010/5/6 Kyungmin Park kmp...@infradead.org:
Hi,
What's your chip version? maybe some mis-probe it seems to be probed
at 4KiB pagesize OneNAND.
Is a 4-Gbit DDP OneNAND device from Numonyx composed of two 2-Gbit 2KB
page dice stacked together, the device is equipped with two DataRAMs,
and two-plane NAND Flash memory array,
These two component enables simultaneous program of 4KiB (
CONFIG_MTD_ONENAND_2X_PROGRAM)
Cheers,
Enric
Thank you,
Kyungmin Park
On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
Hi,
2010/5/6 Kyungmin Park kyungmin.p...@samsung.com:
Hi,
Can you add this statement at below the code?
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__, page, (int)
onenand_addr(this, block), ((int) addr this-page_shift)
this-page_mask);
Yes,
With this code nandtest fails:
onenand_base.c
377: default:
block = onenand_block(this, addr);
/* (line disabled) page = (int) (addr this-page_shift); */
page = (int) (addr - onenand_addr(this, block))
this-page_shift;
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr
this-page_shift)
this-page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block = ~1;
/* Is it the odd plane? */
if (addr this-writesize)
block++;
page = 1;
}
page = this-page_mask;
break;
--- start log nandtest fail ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: writing...
[ 243.144287] onenand_command[382] page 0, 2621440, 0
[ 243.150787] onenand_command[382] page 2, 2621440, 2
[ 243.156158] onenand_command[382] page 4, 2621440, 4
(...)
[ 243.310729] onenand_command[382] page 60, 2621440, 60
[ 243.316223] onenand_command[382] page 62, 2621440, 62
[ 243.322204] onenand_command[382] page 0, 2752512, 0
[ 243.327636] onenand_command[382] page 2, 2752512, 2
[ 243.332977] onenand_command[382] page 4, 2752512, 4
(...)
[ 243.487487] onenand_command[382] page 60, 2752512, 60
[ 243.493041] onenand_command[382] page 62, 2752512, 62
: reading...
[ 243.498535] onenand_command[382] page 0, 2621440, 0
[ 243.505249] onenand_wait: ECC error = 0x8488
[ 243.509552] onenand_command[382] page 1, 2621440, 1
[ 243.514587] onenand_wait: ECC error = 0x8488
[ 243.518890] onenand_command[382] page 2, 2621440, 2
(...)
[ 244.089050] onenand_command[382] page 62, 2621440, 62
[ 244.094268] onenand_wait: ECC error = 0x8448
[ 244.098602] onenand_command[382] page 63, 2621440, 63
[ 244.103790] onenand_wait: ECC error = 0x8488
[ 244.109191] onenand_command[382] page 0, 2752512, 0
[ 244.114196] onenand_wait: ECC error = 0x8488
[ 244.118469] onenand_command[382] page 1, 2752512, 1
[ 244.123535] onenand_wait: ECC error = 0x8488
[ 244.127838] onenand_command[382] page 2, 2752512, 2
(...)
[ 244.698150] onenand_command[382] page 62, 2752512, 62
[ 244.703369] onenand_wait: ECC error = 0x8448
[ 244.707672] onenand_command[382] page 63, 2752512, 63
[ 244.712890] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
Byte 0x5 is 21 should be b7
--- end log nandtest fail ---
With this other code nandtest pass
onenand_base.c
377: default:
block = onenand_block(this, addr);
page = (int) (addr this-page_shift);
/* (line disabled) page = (int) (addr - onenand_addr(this, block
Re: Possible bug in onenand_base ?
I answer to myself.
DDP (dual die plane) not implies 'ONENAND_HAS_2PLANE'. A device with
a single die can also have '2 planes'. I'm right ?
Sorry for these newbie questions, I'm just introducing to OneNAND devices.
Cheers,
Enric
2010/5/12 Enric Balletbò i Serra eballe...@gmail.com:
Hello,
I have a bit of time to investigate more.
I have two boards with two different OneNAND chips populated.
The first one is a dual Die Plan 4-Gbit (2 dice of 2-Gbit)
[ 26.406890] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[ 26.412170] OneNAND version = 0x0031
[ 26.415771] Chip support all block unlock
[ 26.419830] Chip has 2 plane
The second is a single die of 2-Gbit.
[ 32.897735] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[ 32.902557] OneNAND version = 0x0031
[ 32.906188] Chip support all block unlock
[ 32.910247] Chip has 2 plane
As I understand the bit 3 of DEVICE_ID register indicates if package
is a single-die or a dual-die, so
- Muxed OneNAND(DDP) 512MB 1.8V 16-bit - device id: 0x58 - bit 3 is
1 - dual-die
- Muxed OneNAND 256MB 1.8V 16-bit - device id: 0x40 - bit 3 is 0
-single-die
The question is, why those devices are reporting 'Chip has 2 plane' ?
Sorry if this is a trivial question but I'm not sure about DDP and '2
plane' concepts. Are the same ?
Cheers,
Enric
2010/5/6 Enric Balletbò i Serra eballe...@gmail.com:
Hi,
2010/5/6 Kyungmin Park kmp...@infradead.org:
Hi,
What's your chip version? maybe some mis-probe it seems to be probed
at 4KiB pagesize OneNAND.
Is a 4-Gbit DDP OneNAND device from Numonyx composed of two 2-Gbit 2KB
page dice stacked together, the device is equipped with two DataRAMs,
and two-plane NAND Flash memory array,
These two component enables simultaneous program of 4KiB (
CONFIG_MTD_ONENAND_2X_PROGRAM)
Cheers,
Enric
Thank you,
Kyungmin Park
On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
Hi,
2010/5/6 Kyungmin Park kyungmin.p...@samsung.com:
Hi,
Can you add this statement at below the code?
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__, page, (int)
onenand_addr(this, block), ((int) addr this-page_shift)
this-page_mask);
Yes,
With this code nandtest fails:
onenand_base.c
377: default:
block = onenand_block(this, addr);
/* (line disabled) page = (int) (addr this-page_shift); */
page = (int) (addr - onenand_addr(this, block))
this-page_shift;
printk(%s[%d] page %d, %d, %d\n, __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr
this-page_shift)
this-page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block = ~1;
/* Is it the odd plane? */
if (addr this-writesize)
block++;
page = 1;
}
page = this-page_mask;
break;
--- start log nandtest fail ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: writing...
[ 243.144287] onenand_command[382] page 0, 2621440, 0
[ 243.150787] onenand_command[382] page 2, 2621440, 2
[ 243.156158] onenand_command[382] page 4, 2621440, 4
(...)
[ 243.310729] onenand_command[382] page 60, 2621440, 60
[ 243.316223] onenand_command[382] page 62, 2621440, 62
[ 243.322204] onenand_command[382] page 0, 2752512, 0
[ 243.327636] onenand_command[382] page 2, 2752512, 2
[ 243.332977] onenand_command[382] page 4, 2752512, 4
(...)
[ 243.487487] onenand_command[382] page 60, 2752512, 60
[ 243.493041] onenand_command[382] page 62, 2752512, 62
: reading...
[ 243.498535] onenand_command[382] page 0, 2621440, 0
[ 243.505249] onenand_wait: ECC error = 0x8488
[ 243.509552] onenand_command[382] page 1, 2621440, 1
[ 243.514587] onenand_wait: ECC error = 0x8488
[ 243.518890] onenand_command[382] page 2, 2621440, 2
(...)
[ 244.089050] onenand_command[382] page 62, 2621440, 62
[ 244.094268] onenand_wait: ECC error = 0x8448
[ 244.098602] onenand_command[382] page 63, 2621440, 63
[ 244.103790] onenand_wait: ECC error = 0x8488
[ 244.109191] onenand_command[382] page 0, 2752512, 0
[ 244.114196] onenand_wait: ECC error = 0x8488
[ 244.118469] onenand_command[382] page 1, 2752512, 1
[ 244.123535] onenand_wait: ECC error = 0x8488
[ 244.127838] onenand_command[382] page 2, 2752512, 2
(...)
[ 244.698150] onenand_command[382] page 62, 2752512, 62
[ 244.703369] onenand_wait: ECC error = 0x8448
[ 244.707672] onenand_command[382] page 63, 2752512, 63
[ 244.712890] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
Re: Possible bug in onenand_base ?
[ 2025.343811] onenand_command[382] page 1345, 2752512, 1
[ 2025.349151] onenand_command[382] page 1346, 2752512, 2
(...)
[ 2025.672576] onenand_command[382] page 1406, 2752512, 62
[ 2025.677978] onenand_command[382] page 1407, 2752512, 63
: checking...
Finished pass 1 successfully
--- end log nandtest pass ---
In my test environment, it displays the correct page number.
(addr - onenand_addr(this, block) this-page_shift is same as
'(addr this-page_shift) this-page_mask'.
Looks like page number is wrong ?
Cheers,
Enric
Thank you,
Kyungmin Park
On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
eballe...@gmail.com wrote:
Hello all,
After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
Flex-OneNAND support) the onenand support for my device is broken.
Before this commit when I run the nandtest program all is ok
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
002c: checking...
Finished pass 1 successfully
--
Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
fails with:
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: reading...
[ 299.092041] onenand_wait: ECC error = 0x8488
( ... lots of ECC errors ... )
[ 299.092041] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
( ... )
---
Investigating a little I see a significant difference introduced by
this patch. In line
347: page = (int) (addr - onenand_addr(this, block))
this-page_shift; (patch applied)
instead of
347: page = (int) (addr this-page_shift); (without patch)
I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
the line 347 and now works again. Fantastic, but I suspect this is not
the proper solution (probably this breaks other onenands devices, I
can't test).
I'm just introducing in OneNAND devices so anyone can help me to
understand and solve the problem ? Note that my device is a Numonyx
4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
page )
Thanks in advance,
///:~Enric
---
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 081f97d..b1d50a3 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = (int) onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block))
this-page_shift;
+ page = (int) (addr this-page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
---
__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
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
Possible bug in onenand_base ?
Hello all,
After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
Flex-OneNAND support) the onenand support for my device is broken.
Before this commit when I run the nandtest program all is ok
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
002c: checking...
Finished pass 1 successfully
--
Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
fails with:
---
# nandtest /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: reading...
[ 299.092041] onenand_wait: ECC error = 0x8488
( ... lots of ECC errors ... )
[ 299.092041] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
( ... )
---
Investigating a little I see a significant difference introduced by
this patch. In line
347:page = (int) (addr - onenand_addr(this, block))
this-page_shift; (patch applied)
instead of
347:page = (int) (addr this-page_shift); (without patch)
I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
the line 347 and now works again. Fantastic, but I suspect this is not
the proper solution (probably this breaks other onenands devices, I
can't test).
I'm just introducing in OneNAND devices so anyone can help me to
understand and solve the problem ? Note that my device is a Numonyx
4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
page )
Thanks in advance,
///:~Enric
---
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 081f97d..b1d50a3 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = (int) onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block))
this-page_shift;
+ page = (int) (addr this-page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
---
--
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 RESEND] omap3: Fix EHCI port for IGEP v2 board.
Hello,
Felipe, sorry but I don't understand your questions,m maybe I'm
missing something.
All IGEP v2 boards uses USB1HS EHCI port. My mistake was suppose that
port_mode[1] -- EHCI USB1HS but this is not correct, the EHCI USB1HS
is port_mode[0]. This patch only fixes this.
Best regards,
Enric
2010/3/15 Felipe Balbi m...@felipebalbi.com
Hi,
On Mon, Mar 01, 2010 at 04:02:36PM +0100, Enric Balletbo i Serra wrote:
@@ -458,13 +458,13 @@ static struct omap_musb_board_data musb_board_data
= {
};
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst =
{
- .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[1] = -EINVAL,
no way to be backwards compatible ? Is it worth to be backwards
compatible ?
--
balbi
--
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 RESEND] omap3: Fix EHCI port for IGEP v2 board.
Hi, 2010/3/15 Felipe Balbi m...@felipebalbi.com: Hi, please don't top-post. Read more at [1]. Sorry is there a IGEP v1 board available ? Are there any developers around using it ? If true, you should try to be backwards compatible. Yes, IGEP v1 is available but it's a different platform with different processor and aren't compatible. See http://www.igep-platform.com. - IGEPv1 is low-power and fan-less single board computer based on ATMEL ARM9 processor. - IGEPv2 is low-power and fan-less single board computer based on OMAP35x processor. Regards, -- Enric -- 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
OMAPFB: cannot parse default modes
Hello, Testing the Linux Omap master branch on IGEP v2 board I get this feature [ 17.565155] omapfb omapfb: cannot parse default modes My kernel command line is something like '.. omapfb.mode=dvi:1280x720mr...@60' which works without problems with latest 2.6.33-rc8. Any idea about this ? There is something different between 2.6.33 and 2.633-rc8 ? I'm missing something ? Thanks in advance, Enric -- 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: OMAPFB: cannot parse default modes
For me also works, thanks Best regards, Enric 2010/3/4 Tomi Valkeinen tomi.valkei...@nokia.com: On Thu, 2010-03-04 at 16:25 +0100, ext Enric Balletbò i Serra wrote: Hello, Testing the Linux Omap master branch on IGEP v2 board I get this feature [ 17.565155] omapfb omapfb: cannot parse default modes My kernel command line is something like '.. omapfb.mode=dvi:1280x720mr...@60' which works without problems with latest 2.6.33-rc8. Any idea about this ? There is something different between 2.6.33 and 2.633-rc8 ? I'm missing something ? There's no difference between the tagged 2.6.33-rc8 and 2.6.33. But in the current merge window there went a big bunch of DSS patches in, and you are right, setting modes doesn't work in git HEAD. There's some code missing related to mode setting, and it needs some thinking how to make it properly. But here's a quick hack patch I made, that makes mode setting work at least for me on 3430SDP. 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
Re: Question about omap_hsmmc driver
Hi, The mux configuration is set at u-boot level and this works with kernel 2.6.28 so I suppose the mux configuration is setup correctly. Looking at driver I see new data in twl4030_hsmmc_info struct. Please, can you explain a bit the transceiver, ocr_mask and ext_clock ? Just for information, on IGEP v2 the MMC2 should be at 1.8V and don't use twl4030 regulator. Thanks a lot, Enric 2010/1/5 Madhusudhan madhu...@ti.com: Hi Enric, You see from the log there is a timeout on CMD5. This could happen because of multiple reasons. One of them is muxing of CMD/CLK lines. Or it could be due to negotiation of voltage. I would look at these things first. Regards, Madhu From: Enric Balletbò i Serra [mailto:eballe...@gmail.com] Sent: Tuesday, January 05, 2010 10:44 AM To: linux-omap@vger.kernel.org; madhu...@ti.com Subject: Question about omap_hsmmc driver Hi all, I'm having problems trying to run the SDIO WLAN module on my IGEP v2 board using the latest omap kernel (2.6.33-rc2). The SDIO WLAN module is connected to the MMC2 using 4 wires. With an older kernel ( 2.6.28 ) works fine but the same configuration with 2.6.33-rc2 do not detect the SDIO card. Any idea to solve the problem ? There is a substantial modification in this driver. Any help will be appreciated. I attached the log. Thanks in advance, Enric [ 24.521484] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522003] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 24.522033] mmci-omap-hs mmci-omap-hs.1: ENABLED - DISABLED [ 24.522308] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522338] mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 65535 width 0 timing 0 [ 24.545104] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.568298] mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 65535 width 0 timing 0 [ 24.569335] mmc1: starting CMD0 arg flags 00c0 [ 24.569366] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x [ 24.569519] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1 [ 24.569549] mmc1: req done (CMD0): 0: [ 24.572540] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.573547] mmc1: starting CMD8 arg 00aa flags 02f5 [ 24.573577] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x00aa [ 24.573913] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.573913] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.573944] mmc1: req done (CMD8): -110: [ 24.575744] mmc1: starting CMD5 arg flags 02e1 [ 24.575775] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576110] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576141] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576171] mmc1: req failed (CMD5): -110, retrying... [ 24.576171] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576507] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576538] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576568] mmc1: req failed (CMD5): -110, retrying... [ 24.576568] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576904] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576934] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576934] mmc1: req failed (CMD5): -110, retrying... [ 24.576965] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.577301] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.577331] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.577331] mmc1: req done (CMD5): -110: [ 24.578247] mmc1: starting CMD55 arg flags 00f5 [ 24.578247] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.578582] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.578613] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.578643] mmc1: req done (CMD55): -110: [ 24.580444] mmc1: starting CMD55 arg flags 00f5 [ 24.580474] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.580810] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.580810] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.580841] mmc1: req done (CMD55): -110: [ 24.582641] mmc1: starting CMD55 arg flags 00f5 [ 24.582672] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.583007] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.583007] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.583038] mmc1: req done (CMD55): -110: [ 24.584899] mmc1: starting CMD55 arg
Question about omap_hsmmc driver
Hi all, I'm having problems trying to run the SDIO WLAN module on my IGEP v2 board using the latest omap kernel (2.6.33-rc2). The SDIO WLAN module is connected to the MMC2 using 4 wires. With an older kernel ( 2.6.28 ) works fine but the same configuration with 2.6.33-rc2 do not detect the SDIO card. Any idea to solve the problem ? There is a substantial modification in this driver. Any help will be appreciated. I attached the log. Thanks in advance, Enric [ 24.521484] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522003] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 24.522033] mmci-omap-hs mmci-omap-hs.1: ENABLED - DISABLED [ 24.522308] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522338] mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 65535 width 0 timing 0 [ 24.545104] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.568298] mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 65535 width 0 timing 0 [ 24.569335] mmc1: starting CMD0 arg flags 00c0 [ 24.569366] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x [ 24.569519] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1 [ 24.569549] mmc1: req done (CMD0): 0: [ 24.572540] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.573547] mmc1: starting CMD8 arg 00aa flags 02f5 [ 24.573577] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x00aa [ 24.573913] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.573913] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.573944] mmc1: req done (CMD8): -110: [ 24.575744] mmc1: starting CMD5 arg flags 02e1 [ 24.575775] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576110] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576141] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576171] mmc1: req failed (CMD5): -110, retrying... [ 24.576171] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576507] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576538] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576568] mmc1: req failed (CMD5): -110, retrying... [ 24.576568] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576904] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576934] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576934] mmc1: req failed (CMD5): -110, retrying... [ 24.576965] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.577301] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.577331] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.577331] mmc1: req done (CMD5): -110: [ 24.578247] mmc1: starting CMD55 arg flags 00f5 [ 24.578247] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.578582] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.578613] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.578643] mmc1: req done (CMD55): -110: [ 24.580444] mmc1: starting CMD55 arg flags 00f5 [ 24.580474] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.580810] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.580810] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.580841] mmc1: req done (CMD55): -110: [ 24.582641] mmc1: starting CMD55 arg flags 00f5 [ 24.582672] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.583007] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.583007] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.583038] mmc1: req done (CMD55): -110: [ 24.584899] mmc1: starting CMD55 arg flags 00f5 [ 24.584899] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.585235] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.585266] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.585296] mmc1: req done (CMD55): -110: [ 24.587097] mmc1: starting CMD1 arg flags 00e1 [ 24.587097] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x [ 24.587432] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.587463] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.587493] mmc1: req done (CMD1): -110: [ 24.589294] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 24.623962] mmci-omap-hs mmci-omap-hs.1: ENABLED - DISABLED -- 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
Re: [PATCH (for-next)] ASoC: Add support for IGEP v2
This part isn't relevant to ASoC. Shouldn't it go separately through linux-omap? It could possibly get folded into the patch adding this board support in the first place. - Anand Oops, sorry is a mistake I will resend the patch without this. Thanks, Enric 2009/11/18 Gadiyar, Anand gadi...@ti.com: Mike Rapoport wrote: Enric Balletbo i Serra wrote: From: Enric Balletbo i Serra eballe...@iseebcn.com Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/mach-omap2/Kconfig | 2 +- sound/soc/omap/Kconfig | 7 ++ sound/soc/omap/Makefile | 2 + sound/soc/omap/igep0020.c | 148 +++ 4 files changed, 158 insertions(+), 1 deletions(-) create mode 100644 sound/soc/omap/igep0020.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 68866f3..6922198 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -114,7 +114,7 @@ config MACH_OMAP_3630SDP depends on ARCH_OMAP3 ARCH_OMAP34XX config MACH_IGEP0020 - bool IGEP0020 + bool IGEP v2 board depends on ARCH_OMAP3 ARCH_OMAP34XX config MACH_OMAP_4430SDP -- 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
Doubts around SoC audio on omap3
Hi all, I would like to add support for SoC audio on the IGEP v2 board but I have some doubts about how to do. As I have seen in the source code, the SoC driver for IGEP should be the same as omap3evm, overo and cm-t35. So, is better to use the solution adopted by the board CM-T35 or add a specific file for the board IGEP like omap3evm board ? Is there any difference between the omap3evm driver and the overo driver ? Thanks in advance, Enric -- 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: Add support for the IGEP v2 board (rev B)
Ok, I will resubmit in few minuts Thanks, Enric 2009/10/13 Tony Lindgren t...@atomide.com: * Enric Balletbò i Serra eballe...@gmail.com [091009 09:18]: This patch adds minimal IGEP v2 support. Can you please move the defconfig into a separate patch when you resubmit? It makes it easier for people to read the patch. 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
[PATCH 1/2] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
This patch adds minimal IGEP v2 support.
The IGEP v2 board is a low-cost, fan-less and industrial temperature
range single board computer that unleashes laptop-like performance and
expandability without the bulk, expense, or noise of typical desktop
machines. Its architecture shares much in common with other OMAP3 boards.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/mach-omap2/Kconfig |4 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-igep0020.c | 252 ++
3 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-igep0020.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 75b1c7e..9936510 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -85,6 +85,10 @@ config MACH_OMAP_ZOOM2
bool OMAP3 Zoom2 board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+config MACH_IGEP0020
+ bool IGEP0020
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6b7702f..df0bdc4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -74,6 +74,8 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
mmc-twl4030.o \
board-zoom-debugboard.o
+obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
+ mmc-twl4030.o \
obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
new file mode 100644
index 000..15175e0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -0,0 +1,252 @@
+/*
+ * Copyright (C) 2009 Integration Software and Electronic Engineering.
+ *
+ * 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/delay.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/gpio.h
+#include linux/i2c/twl4030.h
+#include linux/regulator/machine.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include mach/common.h
+#include mach/gpmc.h
+#include mach/onenand.h
+#include mach/usb.h
+
+#include mmc-twl4030.h
+
+#define IGEP2_SMSC911X_CS 5
+#define IGEP2_SMSC911X_GPIO 176
+#define IGEP2_GPIO_LED_0_RED 26
+#define IGEP2_GPIO_LED_0_GREEN 27
+#define IGEP2_GPIO_LED_1_RED 28
+
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+
+#include linux/smsc911x.h
+
+static struct resource igep2_smsc911x_resources[] = {
+ {
+ .name = smsc911x-memory,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
+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 ,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
+static struct platform_device igep2_smsc911x_device = {
+ .name = smsc911x,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(igep2_smsc911x_resources),
+ .resource = igep2_smsc911x_resources,
+ .dev= {
+ .platform_data = igep2_smsc911x_config,
+ },
+};
+
+static inline void __init igep2_init_smsc911x(void)
+{
+ unsigned long cs_mem_base;
+
+ if (gpmc_cs_request(IGEP2_SMSC911X_CS, SZ_16M, cs_mem_base) 0) {
+ pr_warning(igep2_init_smsc911x:
+ Failed request for GPMC mem\n);
+ gpmc_cs_free(IGEP2_SMSC911X_CS);
+ return;
+ }
+
+ igep2_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ igep2_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ if ((gpio_request(IGEP2_SMSC911X_GPIO, SMSC911X IRQ) == 0)
+ (gpio_direction_input(IGEP2_SMSC911X_GPIO) == 0)) {
+ gpio_export(IGEP2_SMSC911X_GPIO, 0);
+ } else {
+ pr_warning(igep2_init_smsc911x:
+ Could not obtain gpio for IRQ\n);
+ return;
+ }
+
+ igep2_smsc911x_resources[1].start = OMAP_GPIO_IRQ(IGEP2_SMSC911X_GPIO);
+ igep2_smsc911x_resources[1].end = 0;
+
+ platform_device_register(igep2_smsc911x_device);
+}
+
+#else
+
+static inline void __init igep2_init_smsc911x(void) { }
+
+#endif
+
+static struct
[PATCH 2/2] ARM: OMAP3: IGEP-v2: Add defconfig
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/configs/igep0020_defconfig | 1432 +++ 1 files changed, 1432 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/igep0020_defconfig diff --git a/arch/arm/configs/igep0020_defconfig b/arch/arm/configs/igep0020_defconfig new file mode 100644 index 000..e66dca4 --- /dev/null +++ b/arch/arm/configs/igep0020_defconfig @@ -0,0 +1,1432 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.32-rc4 +# Tue Oct 13 12:53:15 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ARCH_HAS_CPUFREQ=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=17 +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +# CONFIG_SYSFS_DEPRECATED_V2 is not set +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_COMPAT_BRK=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +# CONFIG_FREEZER is not set + +# +# System Type +# +CONFIG_MMU=y +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_NOMADIK is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_L7200 is not set +# CONFIG_ARCH_KIRKWOOD is not set +# CONFIG_ARCH_LOKI is not set +# CONFIG_ARCH_MV78XX0 is not set +# CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_W90X900 is not set +# CONFIG_ARCH_PNX4008 is not set +# CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_MSM is not set +# CONFIG_ARCH_RPC is not set +# CONFIG_ARCH_SA1100 is not set +# CONFIG_ARCH_S3C2410 is not set +# CONFIG_ARCH_S3C64XX is not set
Re: [PATCH] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
Hello Nishanth,
Thanks for your feedback, I'll forward the patch correcting some things
2009/10/10 Nishanth Menon n...@ti.com:
could you add more details on where do we get more data on this platform?
More details will be in new patch and you can get more information here:
www.igep-platform.com
Regards,
Enric
2009/10/10 Nishanth Menon n...@ti.com:
Hi,
Thanks for the patch.. a few minor comments follow from a read through..
Enric Balletbò i Serra had written, on 10/09/2009 10:59 AM, the following:
This patch adds minimal IGEP v2 support.
could you add more details on where do we get more data on this platform?
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/configs/igep0020_defconfig | 1443
++
arch/arm/mach-omap2/Kconfig | 4 +
arch/arm/mach-omap2/Makefile | 2 +
arch/arm/mach-omap2/board-igep0020.c | 239 ++
4 files changed, 1688 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/igep0020_defconfig
create mode 100644 arch/arm/mach-omap2/board-igep0020.c
[...]
--- /dev/null
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -0,0 +1,239 @@
+/*
[..]
+static inline void __init igep2_init_smsc911x(void)
+{
+ unsigned long cs_mem_base;
+
+ if (gpmc_cs_request(IGEP2_SMSC911X_CS, SZ_16M, cs_mem_base) 0)
{
+ printk(KERN_ERR Failed request for GPMC mem for
smsc911x\n);
+ return;
+ }
+
+ igep2_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ igep2_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ if ((gpio_request(IGEP2_SMSC911X_GPIO, SMSC911X IRQ) == 0)
+ (gpio_direction_input(IGEP2_SMSC911X_GPIO) == 0)) {
+ gpio_export(IGEP2_SMSC911X_GPIO, 0);
+ } else {
could you run scripts/checkpatch --strict ../patchName after generating the
patch with git format-patch -s -M -o .. -1 ? one liners dont usually need a
{} also there are few warning inducing code below..
+ printk(KERN_ERR could not obtain gpio for SMSC911X
IRQ\n);
probably dumb question: should'nt we be moving to pr_err and family instead
of printks?
further, if this does not work.. are'nt you supposed to release the cs?
gpmc_cs_free perhaps?
+ return;
+ }
+
+ igep2_smsc911x_resources[1].start =
OMAP_GPIO_IRQ(IGEP2_SMSC911X_GPIO);
+ igep2_smsc911x_resources[1].end = 0;
+
+ platform_device_register(igep2_smsc911x_device);
+}
+
+#else
+
+static inline void __init igep2_init_smsc911x(void) { }
+
+#endif
+
[..]
+ .flags = I2C_CLIENT_WAKE,
+ .irq = INT_34XX_SYS_NIRQ,
+ .platform_data = igep2_twldata,
+ },
+};
+
+static int __init igep2_i2c_init(void)
+{
+ omap_register_i2c_bus(1, 2600, igep2_i2c_boardinfo,
+ ARRAY_SIZE(igep2_i2c_boardinfo));
you may want to step down to 2400
http://marc.info/?l=linux-omapm=125510664919890w=2 if you are using
26Mhz.. if you are using twl5030..
+ omap_register_i2c_bus(3, 400, NULL, 0);
+ return 0;
+}
+
+static void __init igep2_init(void)
+{
+ igep2_i2c_init();
+ omap_serial_init();
+ usb_musb_init();
+
+ igep2_init_smsc911x();
+
+ /* GPIO userspace leds */
+ if ((gpio_request(IGEP2_GPIO_LED_0_RED, GPIO_LED_0_RED) == 0)
(gpio_direction_output(IGEP2_GPIO_LED_0_RED, 1) == 0)) {
+ gpio_export(IGEP2_GPIO_LED_0_RED, 1);
+ } else {
+ printk(KERN_ERR could not obtain gpio for
GPIO_LED_0_RED\n);
do you really want to flag a an error for a led glow?
+ }
+ if ((gpio_request(IGEP2_GPIO_LED_0_GREEN, GPIO_LED_0_GREEN) ==
0)
(gpio_direction_output(IGEP2_GPIO_LED_0_GREEN, 1) == 0)) {
+ gpio_export(IGEP2_GPIO_LED_0_GREEN, 1);
+ } else {
+ printk(KERN_ERR could not obtain gpio for
GPIO_LED_0_GREEN\n);
+ }
+ if ((gpio_request(IGEP2_GPIO_LED_1_RED, GPIO_LED_1_RED) == 0)
(gpio_direction_output(IGEP2_GPIO_LED_1_RED, 1) == 0)) {
here is a an long line?
[...]
--
Regards,
Nishanth Menon
--
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] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
This patch adds minimal IGEP v2 support. The IGEP v2 board is a low-cost, fan-less and industrial temperature range single board computer that unleashes laptop-like performance and expandability without the bulk, expense, or noise of typical desktop machines. Its architecture shares much in common with other OMAP3 boards. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/configs/igep0020_defconfig | 1432 ++ arch/arm/mach-omap2/Kconfig |4 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/board-igep0020.c | 252 ++ 4 files changed, 1690 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/igep0020_defconfig create mode 100644 arch/arm/mach-omap2/board-igep0020.c diff --git a/arch/arm/configs/igep0020_defconfig b/arch/arm/configs/igep0020_defconfig new file mode 100644 index 000..e66dca4 --- /dev/null +++ b/arch/arm/configs/igep0020_defconfig @@ -0,0 +1,1432 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.32-rc4 +# Tue Oct 13 12:53:15 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ARCH_HAS_CPUFREQ=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=17 +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +# CONFIG_SYSFS_DEPRECATED_V2 is not set +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_COMPAT_BRK=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +# CONFIG_FREEZER is not set + +# +# System Type +# +CONFIG_MMU=y +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_NOMADIK is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is
How to add suport for new ARM board IGEP0020
Hi all, I'm a newbie and I have some questions. What is the procedure to publish our patches to add support for a new OMAP3 based board ? Can I send the patches to this list ? Thanks in advance, Enric -- 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] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
This patch adds minimal IGEP v2 support. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/configs/igep0020_defconfig | 1443 ++ arch/arm/mach-omap2/Kconfig |4 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/board-igep0020.c | 239 ++ 4 files changed, 1688 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/igep0020_defconfig create mode 100644 arch/arm/mach-omap2/board-igep0020.c diff --git a/arch/arm/configs/igep0020_defconfig b/arch/arm/configs/igep0020_defconfig new file mode 100644 index 000..639920d --- /dev/null +++ b/arch/arm/configs/igep0020_defconfig @@ -0,0 +1,1443 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.32-rc3 +# Fri Oct 9 16:01:26 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ARCH_HAS_CPUFREQ=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=17 +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +# CONFIG_SYSFS_DEPRECATED_V2 is not set +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_COMPAT_BRK=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +CONFIG_FREEZER=y + +# +# System Type +# +CONFIG_MMU=y +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_NOMADIK is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_L7200 is not set +# CONFIG_ARCH_KIRKWOOD is not set +# CONFIG_ARCH_LOKI is not set +# CONFIG_ARCH_MV78XX0 is not set +# CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_W90X900
