RE: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
> From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com] > Sent: Wednesday, May 09, 2012 11:52 AM > To: Ashwin Bihari > Cc: linux-omap; Tony Lindgren > Subject: RE: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits > > On Wed, 2012-05-09 at 10:38 -0500, Ashwin Bihari wrote: > > > -Original Message- > > > From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com] > > > Sent: Wednesday, May 09, 2012 3:16 AM > > > To: Ashwin Bihari > > > Cc: linux-omap; Tony Lindgren > > > Subject: Re: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 > > > DevKits > > > > > This doesn't play well with device-tree. We can't do such callbacks > > > when we move to DT. > > > > > > I know we have similar code for other boards, and this can't be > > > properly fixed right now, but I'm still a bit hesitant to add more > > > such code because I'm the one that has to clean it up later for DT =). > > > > > > I can handle the LCD_PANEL_PWR gpio, but the backlight is something > > > that should be removed from the panel enable callbacks. You could > > > look at drivers/video/backlight/ and see if there's something there > > > that could be used for your board. Or implement a new BL driver, if > nothing fits. > > > > > > Tomi > > > > Tomi, > > > > Let me take a look at your linux-omap-dss2 tree and learn a bit more about > > DT and figure out how to modify the LCD support so it better aligns with > > your > > work and I'll re-submit that patch again.. > > I haven't published any DT stuff yet. But there's the DT cleanup series I have > posted, which tries to re-structure stuff for some displays to be more DT > compatible. > > The basic idea is that with DT there are no board files, and all device > specific > configuration values are in the DT data. So GPIO numbers etc. > are defined in the DT data, and the device driver will read them and use > them. > > But DT support is not working yet, and we anyway need to support both DT > and the old way for some time, so the board files should be changed to this > direction. What this means for dss is that the panel specific GPIOs etc. need > to be defined in a device specific struct, which is passed to the panel > driver. > > For example, see my cleanup series, and > include/video/omap-panel-tfp410.h, > drivers/video/omap2/displays/panel-tfp410.c and the board files using that. > > All this is still a bit alive and changing, so you could also choose to wait > a bit > until things stabilize =). > > Tomi Tomi, I will take a look at the files you mentioned so for my own information, but will hold off on submitting anything until things are stable, as you suggested. Thanks -- -- -- ~ Ashwin
RE: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
> Sent: Wednesday, May 09, 2012 3:16 AM
> To: Ashwin Bihari
> Cc: linux-omap; Tony Lindgren
> Subject: Re: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
> > +static int omap3logic_panel_enable_lcd(struct omap_dss_device
> > +*dssdev) {
> > + gpio_set_value(LCD_PANEL_PWR, 1);
> > + if (machine_is_omap3530_lv_som())
> > + gpio_set_value(OMAP3530_LV_SOM_BACKLIGHT_PWR, 1);
> > + else if (machine_is_omap3_torpedo()) {
> > + gpio_set_value(OMAP3530_TORPEDO_BACKLIGHT_PWR, 1);
> > +
> > + gpio_set_value(OMAP3530_TORPEDO_MDISP, 1);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int omap3logic_panel_disable_lcd(struct omap_dss_device
> > +*dssdev) {
> > + gpio_set_value(LCD_PANEL_PWR, 0);
> > + if (machine_is_omap3530_lv_som())
> > + gpio_set_value(OMAP3530_LV_SOM_BACKLIGHT_PWR, 0);
> > + else if (machine_is_omap3_torpedo()) {
> > + gpio_set_value(OMAP3530_TORPEDO_BACKLIGHT_PWR, 0);
> > +
> > + gpio_set_value(OMAP3530_TORPEDO_MDISP, 0);
> > + }
> > +
> > + return 0;
> > +}
>
> This doesn't play well with device-tree. We can't do such callbacks when we
> move to DT.
>
> I know we have similar code for other boards, and this can't be properly fixed
> right now, but I'm still a bit hesitant to add more such code because I'm the
> one that has to clean it up later for DT =).
>
> I can handle the LCD_PANEL_PWR gpio, but the backlight is something that
> should be removed from the panel enable callbacks. You could look at
> drivers/video/backlight/ and see if there's something there that could be
> used for your board. Or implement a new BL driver, if nothing fits.
>
> Tomi
Tomi,
Let me take a look at your linux-omap-dss2 tree and learn a bit more about DT
and figure out how to modify the LCD support so it better aligns with your work
and I'll re-submit that patch again..
Thanks
-- -- --
~ Ashwin
RE: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Tuesday, May 08, 2012 8:13 PM > To: Ashwin Bihari > Cc: linux-omap; Tomi Valkeinen > Subject: Re: [PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits > > * Ashwin Bihari [120507 12:41]: > > Use the generic DSS panel driver that provides support for the 4.3" > > Sharp LQ043T1DG01 that comes standard on the > > OMAP3530 SOM-LV and Torpedo DevKits. > > Applying the 1/2 of this into board branch, but this probably needs to be > coordinated with changes Tomi is doing. > > Regards, > > Tony > > Tony, I'll work with Tomi and modify the LCD support to align with what he is doing with DSS.. Thanks -- -- -- ~ Ashwin -- 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
Additional support for LogicPD OMAP3530
Tony, I should've CC'ed you on my initial posting, and will do so with future posts, but here is a ping with the 2 patches[1] I sent that add MSUB and LCD support for the LogicPD OMAP3530 SOM-LV and Torpedo DevKits. Please let me know if you any comments or anyone (or mailing list) I should also CC for these patches. [1] - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg68037.html Thanks ~ Ashwin <>
[PATCH 2/2] Add LCD support for the LogicPD OMAP3530 DevKits
Use the generic DSS panel driver that provides support for
the 4.3" Sharp LQ043T1DG01 that comes standard on the
OMAP3530 SOM-LV and Torpedo DevKits.
Signed-off-by: Ashwin Bihari
---
arch/arm/mach-omap2/board-omap3logic.c | 147
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index c008bf8..f0545c9 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -47,6 +47,8 @@
#include
#include
#include
+#include
+#include
#define OMAP3LOGIC_SMSC911X_CS 1
@@ -57,6 +59,11 @@
#define OMAP3_TORPEDO_MMC_GPIO_CD 127
#define OMAP3_TORPEDO_SMSC911X_GPIO_IRQ129
+#define LCD_PANEL_PWR 155
+#define OMAP3530_LV_SOM_BACKLIGHT_PWR 8
+#define OMAP3530_TORPEDO_BACKLIGHT_PWR 154
+#define OMAP3530_TORPEDO_MDISP 56
+
static struct regulator_consumer_supply omap3logic_vmmc1_supply[] = {
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
};
@@ -104,6 +111,10 @@ static struct twl4030_platform_data omap3logic_twldata = {
static int __init omap3logic_i2c_init(void)
{
+ omap3_pmic_get_config(&omap3logic_twldata,
+ TWL_COMMON_PDATA_USB,
+ TWL_COMMON_REGULATOR_VDAC |
TWL_COMMON_REGULATOR_VPLL2);
+
omap3_pmic_init("twl4030", &omap3logic_twldata);
return 0;
}
@@ -207,6 +218,36 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* DSS */
+ OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA8, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA9, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA10, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA11, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA12, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA13, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA14, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA15, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA16, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA17, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA20, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA21, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA23, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -216,17 +257,123 @@ static struct regulator_consumer_supply dummy_supplies[]
= {
REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
};
+#if defined(CONFIG_PANEL_GENERIC_DPI) || \
+ defined(CONFIG_PANEL_GENERIC_DPI_MODULE)
+static void __init omap3logic_display_init(void)
+{
+ int r;
+
+ omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_OUTPUT);
+ if (machine_is_omap3530_lv_som())
+ omap_mux_init_gpio(OMAP3530_LV_SOM_BACKLIGHT_PWR,
OMAP_PIN_OUTPUT);
+ else if (machine_is_omap3_torpedo()) {
+ omap_mux_init_gpio(OMAP3530_TORPEDO_BACKLIGHT_PWR,
OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(OMAP3530_TORPEDO_MDISP, OMAP_PIN_OUTPUT);
+ }
+
+ r = gpio_request(LCD_PANEL_PWR, "lcd enable");
+ if (r) {
+ printk(KERN_ERR "Failed to get DSS panel enable GPIO\n");
+ return;
+ }
+ gpio_direction_output(LCD_PANEL_PWR, 0);
+
+ if (machine_is_omap3530_lv_som()) {
+ r = gpio_request(OMAP3530_LV_SOM_BACKLIGHT_PWR, "lcd backlight
enable");
+ if (r) {
+ printk(KERN_ERR "Failed to get DSS panel backlight
enable GPIO\n");
+ return;
+ }
+
[PATCH 0/2] Add MUSB and LCD support to LogicPD OMAP3530 DevKits
The following patch add MUSB (OTG) and LCD (Sharp 4.3" LQ043T1DG01) support to the LogicPD OMAP3530 DevKits. Ashwin Bihari (2): Add MSUB support for the LogicPD OMAP3530 DevKits Add LCD support for the LogicPD OMAP3530 DevKits arch/arm/mach-omap2/board-omap3logic.c | 173 +++- 1 files changed, 172 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Add MSUB support for the LogicPD OMAP3530 DevKits
Add support for the OMAP3 MUSB OTG controller to the LogicPD
OMAP3530 SOM-LV[1] and Torpedo[2] DevKits
[1] - www.logicpd.com/products/system-on-modules/omap35x-som-lv/
[2] - www.logicpd.com/products/system-on-modules/omap35x-torpedo-som/
Signed-off-by: Ashwin Bihari
---
arch/arm/mach-omap2/board-omap3logic.c | 26 +-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3logic.c
b/arch/arm/mach-omap2/board-omap3logic.c
index 9b3c141..c008bf8 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -4,8 +4,9 @@
* Copyright (C) 2010 Li-Pro.Net
* Stephan Linz
*
- * Copyright (C) 2010 Logic Product Development, Inc.
+ * Copyright (C) 2010-2012 Logic Product Development, Inc.
* Peter Barada
+ * Ashwin BIhari
*
* Modified from Beagle, EVM, and RX51
*
@@ -45,6 +46,7 @@
#include
#include
#include
+#include
#define OMAP3LOGIC_SMSC911X_CS 1
@@ -85,6 +87,11 @@ static struct twl4030_gpio_platform_data
omap3logic_gpio_data = {
| BIT(13) | BIT(15) | BIT(16) | BIT(17),
};
+static struct twl4030_usb_data omap3logic_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
+
static struct twl4030_platform_data omap3logic_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -92,6 +99,7 @@ static struct twl4030_platform_data omap3logic_twldata = {
/* platform_data for children goes here */
.gpio = &omap3logic_gpio_data,
.vmmc1 = &omap3logic_vmmc1,
+ .usb= &omap3logic_usb_data,
};
static int __init omap3logic_i2c_init(void)
@@ -185,6 +193,20 @@ static inline void __init board_smsc911x_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* mUSB */
+ OMAP3_MUX(HSUSB0_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_STP, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(HSUSB0_DIR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_NXT, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -205,6 +227,8 @@ static void __init omap3logic_init(void)
board_mmc_init();
board_smsc911x_init();
+ usb_musb_init(NULL);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--
1.7.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: DM3730 BSP issue with msleep()
On Mon, Apr 23, 2012 at 1:13 PM, Ashwin Bihari wrote:
> Greetings,
>
> I'm trying to add support for our DM3730-based SOMs to the latest
> Kernel and am basing my work on the latest and greatest Linux-next
> (3.4.0-rc4-next-20120423-dirty currently) and am finding an
> interesting issue with the use of msleep.
>
> I'm trying to bring up a basic system with SD and Ethernet support for
> starters, and am finding that the MMC detection code just hangs, after
> some digging around I found the issue to be related to the use of
> mmc_delay() calls which depending on the timeout required either uses
> mdelay() or msleep(). All of the calls to mdelay() succeed, while the
> msleep() call hangs.
>
> Interestingly, msleep() is used in earlier
> (arch/arm/mach-omap2)/board-* level files and that seems to function
> properly.
>
> I got around the mmc_delay() properly by using the change below (this
> is only temporary), but I end up hanging somewhere farther along and
> the last few lines are:
>
> [ 2.047088] twl_rtc twl_rtc: Power up reset detected.
> [ 2.052673] twl_rtc twl_rtc: Enabling TWL-RTC
> [ 2.064331] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
> [ 2.073028] i2c /dev entries driver
> [ 2.080505] Driver for 1-wire Dallas network protocol.
> [ 2.091522] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
> [ 2.101043] twl4030_wdt twl4030_wdt: Failed to register misc device
> [ 2.107940] twl4030_wdt: probe of twl4030_wdt failed with error -16
> [ 2.12] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
> [ 2.382659] usbcore: registered new interface driver usbhid
> [ 2.388549] usbhid: USB HID core driver
> [ 2.392822] oprofile: hardware counters not available
> [ 2.398284] oprofile: using timer interrupt.
> [ 2.403961] TCP: cubic registered
> [ 2.407623] Initializing XFRM netlink socket
> [ 2.412506] NET: Registered protocol family 17
> [ 2.417388] NET: Registered protocol family 15
> [ 2.422821] Registering the dns_resolver key type
> [ 2.428222] VFP support v0.3: implementor 41 architecture 3 part 30
> variant c rev 3
> [ 2.436676] ThumbEE CPU extension supported.
> [ 2.493072] clock: disabling unused clocks to save power
> [ 2.545989] twl_rtc twl_rtc: setting system clock to 2000-01-01
> 00:00:00 UTC (946684800)
> [ 2.560760] Waiting for root device /dev/mmcblk0p2...
> [ 2.783111] mmc0: host does not support reading read-only switch.
> assuming write-enable.
> [ 2.794372] mmc0: new high speed SDHC card at address b368
> [ 2.814636] mmcblk0: mmc0:b368 0 3.74 GiB
> [ 2.828704] mmcblk0: p1 p2
>
> Does anyone have any pointers for me to try out to see what's going on?
>
>
> diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
> index 3bdafbc..7062f15 100644
> --- a/drivers/mmc/core/core.h
> +++ b/drivers/mmc/core/core.h
> @@ -48,12 +48,16 @@ void mmc_power_off(struct mmc_host *host);
>
> static inline void mmc_delay(unsigned int ms)
> {
> + cond_resched();
> + mdelay(ms);
> +#if 0
> if (ms < 1000 / HZ) {
> cond_resched();
> mdelay(ms);
> } else {
> msleep(ms);
> }
> +#endif
> }
>
> void mmc_rescan(struct work_struct *work);
>
>
> -- Ashwin
I've continued to debug this a bit further and have been updating to
the latest versions of linux-next to see if any of the behavior change
and it hasn't yet. However, I did try to see if I could use an EXT2
ramdisk (that I know works on other Kernels I have) to avoid any
potential issues I am having with the SD and it turns out that the
ramdisk also doesn't mount. The mounting of the ramdisk root also
hangs in some of the very code "fs/namespace.c" code that I haven't
even touched.
I have a OMAP3530 SOM that works with the same image and it boots from
ramdisk, SD and all without any problems.
I must be missing or have no configured something at a very early
level to get this messed up..any ideas?
-- Ashwin
--
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
DM3730 BSP issue with msleep()
Greetings,
I'm trying to add support for our DM3730-based SOMs to the latest
Kernel and am basing my work on the latest and greatest Linux-next
(3.4.0-rc4-next-20120423-dirty currently) and am finding an
interesting issue with the use of msleep.
I'm trying to bring up a basic system with SD and Ethernet support for
starters, and am finding that the MMC detection code just hangs, after
some digging around I found the issue to be related to the use of
mmc_delay() calls which depending on the timeout required either uses
mdelay() or msleep(). All of the calls to mdelay() succeed, while the
msleep() call hangs.
Interestingly, msleep() is used in earlier
(arch/arm/mach-omap2)/board-* level files and that seems to function
properly.
I got around the mmc_delay() properly by using the change below (this
is only temporary), but I end up hanging somewhere farther along and
the last few lines are:
[2.047088] twl_rtc twl_rtc: Power up reset detected.
[2.052673] twl_rtc twl_rtc: Enabling TWL-RTC
[2.064331] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[2.073028] i2c /dev entries driver
[2.080505] Driver for 1-wire Dallas network protocol.
[2.091522] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
[2.101043] twl4030_wdt twl4030_wdt: Failed to register misc device
[2.107940] twl4030_wdt: probe of twl4030_wdt failed with error -16
[2.12] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
[2.382659] usbcore: registered new interface driver usbhid
[2.388549] usbhid: USB HID core driver
[2.392822] oprofile: hardware counters not available
[2.398284] oprofile: using timer interrupt.
[2.403961] TCP: cubic registered
[2.407623] Initializing XFRM netlink socket
[2.412506] NET: Registered protocol family 17
[2.417388] NET: Registered protocol family 15
[2.422821] Registering the dns_resolver key type
[2.428222] VFP support v0.3: implementor 41 architecture 3 part 30
variant c rev 3
[2.436676] ThumbEE CPU extension supported.
[2.493072] clock: disabling unused clocks to save power
[2.545989] twl_rtc twl_rtc: setting system clock to 2000-01-01
00:00:00 UTC (946684800)
[2.560760] Waiting for root device /dev/mmcblk0p2...
[2.783111] mmc0: host does not support reading read-only switch.
assuming write-enable.
[2.794372] mmc0: new high speed SDHC card at address b368
[2.814636] mmcblk0: mmc0:b368 0 3.74 GiB
[2.828704] mmcblk0: p1 p2
Does anyone have any pointers for me to try out to see what's going on?
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 3bdafbc..7062f15 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -48,12 +48,16 @@ void mmc_power_off(struct mmc_host *host);
static inline void mmc_delay(unsigned int ms)
{
+ cond_resched();
+ mdelay(ms);
+#if 0
if (ms < 1000 / HZ) {
cond_resched();
mdelay(ms);
} else {
msleep(ms);
}
+#endif
}
void mmc_rescan(struct work_struct *work);
-- Ashwin
--
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 TWL4030/TPS65950 power off
Greetings, In one of the older Kernels, there was a twl4030-poweroff driver that provided a hook to shutdown the OMAP when the "poweroff" or "shutdown -h now" command was issued in Linux. This also put the TWL4030/TPS65950 into it's power on state awaiting a press of the power button. My most recent experience with this functionality working is with a 2.6.32 Kernel. I'm trying to get this functionality going with a 3.1.10 Kernel. I've brought over the same twl4030-poweroff driver, but now the system just crashes during shutdown as opposed to nice going down. The file 'drivers/mfd/twl4030-power.c' does define the PWR_P1_SW_EVENTS and PWR_DEVOFF bit, but the PWR_DEVOFF bit is never used to turn the system off, why is it even defined and what is the right way of turning of the system now? -- Ashwin -- 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: Linux 3.0 DSS support
Sending to the mailing list properly to see if anyone has any other ideas for me to pursue..darn rich formatting prevented the previous mails from getting to the list! On Tue, Oct 18, 2011 at 12:59 PM, Ashwin Bihari wrote: > On Mon, Oct 17, 2011 at 3:19 AM, Tomi Valkeinen > wrote: >> >> On 10/14/2011 07:52 PM, Ashwin Bihari wrote: >>> >>> Greetings, >>> >>> I'm trying to add support for our custom DM3730 based board to the Linux >>> 3.0 Kernel and am having issues with the DSS support. I also have a >>> AM3517 and BeagleBoard xM devkit as reference hardware. I've done some >>> searching and have found that the AM3517 display support isn't fully >>> functioning, so I tried to focus on the BeagleBoard xM which seems to be >>> doing something but the LCD never comes to life. >> >> I don't have any of those boards, and I'm totally unfamiliar with DM3730 >> and AM3517, so I can't if the mainline works with them or not. But I presume >> DM3730 and AM3517 are using the same DSS hardware than OMAPs? From DSS >> driver's perspective everything should be there, and if their board files >> contain the definitions for the displays, then they should work. > > The DM3730 is essentially a die-shrink of the OMAP3530, so faster speed but > same functionality. Heck, virtually all of the same OMAP3530 drivers just > work on the DM3730, which is why I'm so darn confused as to why this isn't > working. > >>> >>> I'm currently using the following bootargs: >>> >>> console=ttyO2,115200n8 mpurate=auto buddy=none vram=12M >>> omapfb.mode=dvi:640x480MR-16@60 omapfb.debug=y omapdss.def_disp=dvi >>> root=/dev/ram0 rw ramdisk_size=65536 initrd=0x8100,64M >>> rootfstype=ext2 >>> >>> I have tried different resolutions which all yield the same blank screen >>> on the LCD with it going into power-save mode.. >>> >>> I've looked at all the current board-* files that define displays and >>> have done the same for my display, and the display portion itself seems >>> to run and my LCD gets powered-on and the backlight turned on, but I >>> don't see a valid HSYNC or VSYNC signal out there.. >> >> So are you using the DVI output or what? If so, is the DVI framer enabled? >> Is pin muxing set up correctly? > > On the BeagleBoardXM, yes I was using the DVI for the output, on my custom > DM3730 hardware, we're using the LCD as the output. The pin muxing is setup > correctly as far as I can tell, and I will check on the DVI framer to > confirm that it's working. > The pin muxing for all of the DSS pins are set to be MODE0.. > >>> >>> On the BeagleBoard xM, I also see the following debug messages from >>> OMAPDSS and OMAPFB >>> >>> ---Begin OMAPDSS-- >>> [ 1.175659] omapdss DSS: clk ick, rate 5000 >>> [ 1.175689] omapdss DSS: clk fck, rate 9600 >>> [ 1.175720] omapdss DSS: clk sys_clk, rate 1300 >>> [ 1.175750] omapdss DSS: clk tv_clk, rate 5400 >>> [ 1.175781] omapdss DSS: clk video_clk, rate 9600 >>> [ 1.175842] omapdss DSS: initial ctx id 0 >>> [ 1.264221] omapdss CORE: bus_match. dev display0/generic_dpi_panel, >>> drv venc >>> [ 1.264953] omapdss CORE: bus_match. dev display1/venc, drv venc >>> [ 1.265045] omapdss CORE: driver_probe: dev display1/venc, drv venc >>> [ 1.265045] omapdss VENC: init_display >>> [ 1.265533] omapdss CORE: probe done for device display1 >>> [ 1.265594] omapdss DSS: save context >>> [ 1.266479] omapdss CORE: bus_match. dev display0/generic_dpi_panel, >>> drv generic_dpi_panel >>> [ 1.266540] omapdss CORE: driver_probe: dev >>> display0/generic_dpi_panel, drv generic_dpi_panel >>> [ 1.266571] omapdss DPI: init_display >>> [ 1.266815] omapdss DSS: save context >>> [ 1.266906] omapdss DSS: save context >>> [ 1.266967] omapdss DSS: save context >>> [ 1.267028] omapdss CORE: probe done for device display0 >>> [ 1.267059] omapdss CORE: bus_match. dev display1/venc, drv >>> generic_dpi_panel >>> [ 2.689788] omapdss DPI: dpi_set_timings >>> [ 2.698883] omapdss MANAGER: omap_dss_mgr_apply(lcd) >>> [ 2.699157] omapdss MANAGER: configure_manager(0) >>> [ 2.699218] omapdss MANAGER: configure_manager(1) >>> [ 2.699279] omapdss DSS: save context >>> [ 2.715332] omapdss OVERLAY: check_overlay 0: (0,0 640x480 -> >&g
Re: [PATCH v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo
On Mon, Oct 11, 2010 at 1:45 PM, Tim Nordell wrote: > On 10/11/10 12:30, Tony Lindgren wrote: >> Uhh, so whose patches are these originally? >> >> We have them now queued with Tim Nordell as the author. Please let me know >> ASAP if you want me to change that. >> >> Regards, >> >> Tony > > The history for those patches, for me, originated with Jacob Tanenbaum's > patchset. I was taking over for him as he was going back to school. I > did some misc. changes for further submission, but I was not the > original author. I don't know Stephan's involvement - however, in the > source files he's attributed credit in the header, as well as one of my > coworkers so presumably there was some involvement on both ends. I > recognize some of the code as coming from our kernel release, so likely > it was a hybrid originally between Stephan, Peter, and Jacob. > > That's about the extent that I know. > > - Tim Tony, LogicPD engineers did the initial porting and then Stephan Linz re-started the work on the, then recent, 2.6.32 Kernel using our BSP as a starting point. He was kind enough to send those LogicPD and we began putting it together against the latest Linux Kernel for inclusion and that was done by Jacob over the summer and finished off by Tim. Stephan Linz is credited in the patch and Peter Barada (another LogicPD employee) is listed as the maintainer though his part (along with me) in getting these specific patches out have been more behind the scenes. So having the names listed as they are now is OK. In the upcoming months we will be pushing out additional support for the LogicPD's boards and it will most likely come up a variety of LogicPD engineers depending on our workload.. Thanks -- Ashwin -- 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: AM3517 (Sitara) MMC2 help
On Wed, Aug 25, 2010 at 9:51 AM, Gadiyar, Anand wrote: > Ashwin Bihari wrote: >> On Wed, Aug 25, 2010 at 4:12 AM, Igor Grinberg >> wrote: >> > On 08/25/10 03:29, Laine Walker-Avina wrote: >> >> On Tue, Aug 24, 2010 at 5:42 AM, Igor Grinberg >> >> wrote: > ... > >> >> Make sure the MMC2_CLK pin is muxed as an input so the clock can >> >> feedback to the module. >> > >> > omap2_mmc_mux() in arch/arm/mach-omap2/devices.c is handling this >> > and I think properly or else any omap will fail using the mmc2. >> > >> >> Also, you may need to set >> >> CONTROL_DEVCONF1.MMCSDIO2ADPCLKISEL=1 if that exists on the Sitara. I >> >> had the same problem on the OMAP3x. >> > >> > I will try that. >> > > > ... > >> I've got this exact same problem on a OMAP35x based board. We have >> MMC1 connected to a SD card cage and MMC2 connected to an eMMC. I can >> detect an inserted SD card and eMMC during boot up, but if I suspend >> and resume the device, I get a ton of timeout errors on MMC1 (the SD >> slot) and the RFS that's being used from it ends up having lots of >> EXT3 journal errors and ends up hosing itself.. >> >> I've confirmed that the CONTROL_DEVCONF1.MMCSDIO2ADPCLKISEL is set to >> 1 as well and that doesn't affect any change. >> >> I was using a 2.6.29 Kernel on this board before and it had no >> problems, I then jumped to 2.6.32 and this problem appeared. I'm now >> running the latest linux-next (2.6.35) Kernel and it also presents the >> problem.. >> >> Any guidance would be appreciated.. > > Ashwin, > > I'm not sure your problem is the same as the one originally posted. > Do you have CONFIG_MMC_UNSAFE_RESUME enabled? > > - Anand > Anand, Yup, have MMC_UNSAFE_RESUME set. I'm actually using the "omap3_defconfig" to build my Kernel.. CONFIG_MMC=y CONFIG_MMC_DEBUG=y CONFIG_MMC_UNSAFE_RESUME=y # MMC/SD/SDIO Card Drivers CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_MMC_TEST is not set # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_SDHCI is not set CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y # CONFIG_MMC_SPI is not set The interesting thing is that enabling MMC2 causes me issues on MMC1 though I'm not doing anything on MMC2's eMMC apart from discovering it.. Thanks -- Ashwin -- 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: AM3517 (Sitara) MMC2 help
-- Ashwin On Wed, Aug 25, 2010 at 4:12 AM, Igor Grinberg wrote: > On 08/25/10 03:29, Laine Walker-Avina wrote: >> On Tue, Aug 24, 2010 at 5:42 AM, Igor Grinberg >> wrote: >>> Hi, >>> >>> I have am3517 based board and Libertas sdio (4 wires) >>> wifi connected directly (no transceiver / level shifter) on mmc2 >>> (which is named mmc1 in s/w). >>> >>> am3517 is configured (h/w) for 3.3V and so is Libertas wifi. >>> >>> dmesg | grep mmc1 shows: >>> >>> --cut-- >>> mux: Setting signal sdmmc1_clk.sdmmc1_clk 0x -> 0x0118 >>> mux: Setting signal sdmmc1_cmd.sdmmc1_cmd 0x -> 0x0118 >>> mux: Setting signal sdmmc1_dat0.sdmmc1_dat0 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat1.sdmmc1_dat1 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat2.sdmmc1_dat2 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat3.sdmmc1_dat3 0x0100 -> 0x0118 >>> mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 >>> mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD52 arg 0c00 flags 0195 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x0c00 >>> mmc1: req done (CMD52): -110: >>> mmc1: starting CMD52 arg 8c08 flags 0195 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x8c08 >>> mmc1: req done (CMD52): -110: >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD0 arg flags 00c0 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x >>> mmc1: req done (CMD0): 0: >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD8 arg 01aa flags 02f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x01aa >>> mmc1: req done (CMD8): -110: >>> mmc1: starting CMD5 arg flags 02e1 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req done (CMD5): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD1 arg flags 00e1 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x >>> mmc1: req done (CMD1): -110: >>> mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 >>> ---cut- >>> >>> Libertas is powered up and gets reseted properly. >>> On the oscilloscope, I see some communication going >>> on the CMD line and stops after some time. >>> >>> am3517 PSP from TI, does not even registers/enables >>> the wifi combo found on am3517evm. >>> >>> Have anybody got the mmc2 working on am3517? >>> May be with transceiver? >>> >>> Any help will be appreciated. >>> >>> Thanks >>> >>> -- >>> Regards, >>> Igor. >>> >>> -- >>> 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 >>> >> Make sure the MMC2_CLK pin is muxed as an input so the clock can >> feedback to the module. > > omap2_mmc_mux() in arch/arm/mach-omap2/devices.c is handling this > and I think properly or else any omap will fail using the mmc2. > >> Also, you may need to set >> CONTROL_DEVCONF1.MMCSDIO2ADPCLKISEL=1 if that exists on the Sitara. I >> had the same problem on the OMAP3x. > > I will try that. > > Thanks > > -- > Regards, > Igor. > > -- > 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 > I've got this exact same problem on a OMAP35x based board. We have MMC1 connected to a SD card cage and MMC2 connected to an eMMC.
Re: OMAP 3530 LV-SOM support (was: Re: Patch format for submission?)
On Thu, Apr 29, 2010 at 1:18 PM, Zygo Blaxell wrote: > On Thu, Aug 20, 2009 at 06:02:06PM +0200, Stephan Linz wrote: >> Am Mittwoch, 19. August 2009 schrieb Peter Barada: >> > 1) Does anyone have a URL of the format patches should be in that are >> > submitted to the linux-omap list? >> > >> > I've got some patches to add base support for the Logic OMAP 35x SOM and >> > Torpedo boards and I'd like to submit them in the right format for >> > inclusion and push into mainline. >> >> Hi Peter, >> >> nice to see your announcement here at linux-omap. Today I've finished my own >> port for the Logic OMAP 35x SOM based on 2.6.31-rc1. We should share our >> results befor submitting any patches to the list, or not? > > That's the last message I can find from either of you on this topic. > I'm in the process of rolling yet another patch set for 2.6.32. Was any > further work done on this, or anything posted anywhere? > Zygo, No, the LogicPD OMAP 35x support didn't quite make it out to the list, we are taking another crack at it shortly and would definitely love to collaborate to get the changes out. We did create a Gitorious repo[1], but that's sitting at 2.6.31-rc1 and we've internally got a newer version of the Kernel up to date.. So we should definitely discuss off-list on how to pool our efforts to get the support into the L-O tree.. Regards -- Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 Switch between multiple displays
On Tue, Dec 1, 2009 at 4:45 AM, Tomi Valkeinen wrote: > Hi, > > On Mon, 2009-11-30 at 20:26 +0100, ext Ashwin Bihari wrote: >> My system is going to have to support multiple display panels and >> switch between them using runtime checks. I've got two displays >> currently registered and confirmed with: >> >> # cat displays >> lcd e:1 u:1 t:0 h:480/2/2/41 v:272/2/6/10 p:1 r:0 i:0 >> lcd e:0 u:1 t:0 h:480/2/2/41 v:800/2/6/10 p:1 r:0 i:0 >> >> Short of adding a new module parameter for me to key off the >> panel_name to make the choice, is there some other way already >> implemented for me to indicate which display the DSS2 system should >> use as the default display panel? > > You are using an old version of DSS2. With later versions you can use > omapdss.def_disp kernel parameter (see DSS documentation), or > default_device field in omap_dss_board_info. > > Tomi > Hi Tomi, Ahh Ok.. I was using the Kernel within Android 1.6 which is 2.6.29-rc3, good to know that there is a scheme for this in the later version. Hopefully when we make the jump to Android 2.0 and 2.6.31, we'll pick up the DSS2 changes as well. Regards -- Ashwin -- 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
DSS2 Switch between multiple displays
My system is going to have to support multiple display panels and switch between them using runtime checks. I've got two displays currently registered and confirmed with: # cat displays lcd e:1 u:1 t:0 h:480/2/2/41 v:272/2/6/10 p:1 r:0 i:0 lcd e:0 u:1 t:0 h:480/2/2/41 v:800/2/6/10 p:1 r:0 i:0 Short of adding a new module parameter for me to key off the panel_name to make the choice, is there some other way already implemented for me to indicate which display the DSS2 system should use as the default display panel? -- Ashwin -- 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: OMAP35x GP TIMER as a wakeup trigger
On Mon, Apr 27, 2009 at 6:17 PM, Kevin Hilman wrote: > Ashwin Bihari writes: > >> I need to implement a timer as a wake up trigger while my custom board >> is in the suspended state. I read in the TRM that all of the GPTIMERs >> have the capability of generating a wake up interrupt. I'm using the >> 2.6.28-rc8 PM Kernel which contains the patch to enable all the >> GPTIMERS as wake up sources. > > Try the patch below on the current PM branch. I use this for > debugging PM code when no other wakeup sources (keypad, UART, etc. are > working.) > > Kevin > Kevin. The patch worked like a charm, thank you very much. -- Ashwin -- 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: OMAP35x GP TIMER as a wakeup trigger
On Mon, Apr 27, 2009 at 12:08 PM, Premi, Sanjeev wrote: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ashwin Bihari >> Sent: Monday, April 27, 2009 9:20 PM >> To: linux-omap@vger.kernel.org Mailing List >> Subject: OMAP35x GP TIMER as a wakeup trigger >> >> Greetings, >> >> I need to implement a timer as a wake up trigger while my custom board >> is in the suspended state. I read in the TRM that all of the GPTIMERs >> have the capability of generating a wake up interrupt. I'm using the >> 2.6.28-rc8 PM Kernel which contains the patch to enable all the >> GPTIMERS as wake up sources. > > Are you refering to the "suspend" state coming from: > echo mem > /sys/power/state > OR > One of the idle states C0-C6? > > To understand the wakeup sequence from suspend; take a look at: > arch/arm/mach-omap2/serial.c > ...esp the IOPAD configuration. > > You will have to do something similar. > > ~sanjeev > Sanjeev, I was talking about the former (echo mem > /sys/power/state) and I will take a look at the serial.c file and might return with more questions. :) Regards -- Ashwin -- 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
OMAP35x GP TIMER as a wakeup trigger
Greetings, I need to implement a timer as a wake up trigger while my custom board is in the suspended state. I read in the TRM that all of the GPTIMERs have the capability of generating a wake up interrupt. I'm using the 2.6.28-rc8 PM Kernel which contains the patch to enable all the GPTIMERS as wake up sources. Could someone familiar with this scheme quickly elaborate all the steps that I need to go through to get the system to come out of suspend purely on the timer? Is it is just enough to setup the timer correctly, enable the interrupt in the appropriate register and assume that the PM layer will get the interrupt and do the right thing, or is there more that I have to do? Also, as as additional thing, if the PM layer handles the interrupt and begins the wake-up process, if I could know where that specifically happens, that'd be great since I need to know that the wake-up process is being triggered by the GPTIMER as opposed to the other wakeup triggers and deal with that differently. Regards -- Ashwin -- 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: lcd rotation in omapfb_main.c
On Wed, Apr 22, 2009 at 8:39 AM, twebb wrote: > On Tue, Apr 21, 2009 at 6:29 PM, Marek Vasut wrote: >> On Wednesday 22 of April 2009 00:18:54 twebb wrote: >>> I'm trying to start up the LCD panel on a new omap35xx-based platform >>> in portrait mode, though the native orientation of the display is >>> landscape. I'm running linux-2.6.27-omap1. However, when I change >>> "def_rotate" to 90 in omapfb_main.c, it doesn't seem to make any >>> difference in the orientation of the display. Any ideas why this >>> might be happening? Could there be outstanding fixes/patches I need? >> >> change it to 1 or something ... btw. this should be configurable through some >> platform_data. Also, dont bring up new platform on deprecated kernel. >>> > > Since when is linux-omap v2.6.27-omap1 deprecated? It's only 5 months > old! Am I missing something here? > > And the def_rotate is defined to be in degrees - I'm pretty sure > setting it to 1 won't work. Deprecated is probably a poor choice of words, but if you are indeed bringing up a new platform, doing so on the newest Kernel you can find will ensure that bringing in newer changes from the time you begin your work will be easier. The L-O tree is already about 2.6.30, so you're essentially 3 revisions out and you're just setting yourself up for a bunch of work to port numerous changes into your Kernel. And as Greg KH would probably say, 5 months in Kernel development land is a really long period of time. :) -- Ashwin -- 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: Kernel support of the Zoom OMAP35X Development kit
On Wed, Mar 25, 2009 at 1:33 PM, Tony Lindgren wrote: > * Ashwin Bihari [090325 10:21]: >> On Wed, Mar 25, 2009 at 1:13 PM, Philip Balister wrote: >> > I looked at the kit kernel and didn't see support for this board: >> > >> > http://www.logicpd.com/products/devkit/ti/zoom_omap3_development_kit >> > >> > What are my chances getting this board going with the Linux-omap git >> > kernel? >> > >> > If that doesn't work, what boards give easy access to the GPMC pins and >> > work >> > with the linux-omap kernel? >> > >> > Philip >> > >> >> Philip, >> >> We have support for the OMAP3530LV_SOM (the LogicPD DevKit in the >> link) on 2.6.28-rc8. We have patches available against that particular >> release of the Linux OMAP tree and that'll get you up to speed on the >> SOM to do your work. Register yourself on the website and you should >> get access to the patches there. > > How about send the board-*.c and other patches you have against the > mainline kernel to this list so we can review them? > > Then let's queue them up for integration to the mainline kernel for > the next merge window! > > Cheers, > > Tony > Tony, We're trying to move our stuff forward to the 2.6.29 tree and there's probably more value in submitting patches against that as opposed to 2.6.28.. Regards -- Ashwin -- 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: Kernel support of the Zoom OMAP35X Development kit
On Wed, Mar 25, 2009 at 1:13 PM, Philip Balister wrote: > I looked at the kit kernel and didn't see support for this board: > > http://www.logicpd.com/products/devkit/ti/zoom_omap3_development_kit > > What are my chances getting this board going with the Linux-omap git kernel? > > If that doesn't work, what boards give easy access to the GPMC pins and work > with the linux-omap kernel? > > Philip > Philip, We have support for the OMAP3530LV_SOM (the LogicPD DevKit in the link) on 2.6.28-rc8. We have patches available against that particular release of the Linux OMAP tree and that'll get you up to speed on the SOM to do your work. Register yourself on the website and you should get access to the patches there. Regards -- Ashwin -- 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: mmc0 detection timing at kernel startup, linux-omap-2.6.27-omap1
On Fri, Mar 20, 2009 at 9:59 AM, twebb wrote: > On Fri, Mar 20, 2009 at 9:53 AM, Ashwin Bihari wrote: >> On Fri, Mar 20, 2009 at 9:44 AM, Koen Kooi wrote: >>> >>> Op 20 mrt 2009, om 14:34 heeft Ashwin Bihari het volgende geschreven: >>> >>>> You need to add the Kernel option "rootdelay=1" to basically delay the >>>> Kernel for a moment while attempting to using the SDcard as the RFS >>>> mount point. >>> >>> Since kernel 2.6.24 you can use 'rootwait', which will wait till it becomes >>> available so you don't need to keep futzing the value for different SD >>> cards. >>> >>> regards, >>> >>> Koen >>> >> >> Koen, >> >> I wasn't aware of that option, it definitely beats futzing with wait delays! >> >> -- Ashwin >> > > The 'rootwait' works too, thanks for your suggestions. > > By the way, is rootfstype=ext3 required? I know I've had to use it in > the past with JFFS2, but am wondering if ext3 might be handled by > default. > I most recently used an EXT2 image as my RFS and I didn't have to specifically specify the rootfstype for it to work. So my guess is that the FS type is probably auto-detected during mount time. -- Ashwin -- 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: mmc0 detection timing at kernel startup, linux-omap-2.6.27-omap1
On Fri, Mar 20, 2009 at 9:44 AM, Koen Kooi wrote: > > Op 20 mrt 2009, om 14:34 heeft Ashwin Bihari het volgende geschreven: > >> You need to add the Kernel option "rootdelay=1" to basically delay the >> Kernel for a moment while attempting to using the SDcard as the RFS >> mount point. > > Since kernel 2.6.24 you can use 'rootwait', which will wait till it becomes > available so you don't need to keep futzing the value for different SD > cards. > > regards, > > Koen > Koen, I wasn't aware of that option, it definitely beats futzing with wait delays! -- Ashwin -- 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: mmc0 detection timing at kernel startup, linux-omap-2.6.27-omap1
You need to add the Kernel option "rootdelay=1" to basically delay the Kernel for a moment while attempting to using the SDcard as the RFS mount point. -- Ashwin On Fri, Mar 20, 2009 at 9:06 AM, twebb wrote: > I'm using linux-omap-2.6.27-omap1 and am seeing an apparent timing > issue at kernel startup. The board is an OMAP 35x EVM and is > configured to boot from the SDcard. Everything works find IF a > keyboard is connected to the USB port of the EVM - the kernel detects > the mmcblk0 device (SDcard) and all it's partitions, and mounts > mmcblk0p1 appropriately as root. However, if the keyboard is not > installed the SDcard is not recognized and the kernel panics. Same > kernel, same kernel args, save everything - just different response > based on whether keyboard is attached or not. Any ideas? I'm > including the good and bad kernel startup logs below... > > Thanks, > twebb > > * Good * > Linux version 2.6.27-omap1 (j...@jb) (gcc version 4.2.1 (CodeSourcery Source > ry G++ Lite 2007q3-51)) #16 Thu Mar 19 16:59:31 EDT 2009 > CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f > Machine: OMAP3 EVM > Memory policy: ECC disabled, Data cache writeback > OMAP3430 ES2.1 > SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 > CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3 > CPU0: Level 1 cache is separate instruction and data > CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets, > supports RA > CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets, > supports RA WB WT > CPU0: Level 2 cache is unified > CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512 sets, > supports WA RA WB WT > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 > Kernel command line: mem=128M console=ttyS2,115200e8 noinitrd init=init > root=/de > v/mmcblk0p2 rw rootfstype=ext3 > Clocking rate (Crystal/DPLL/ARM core): 26.0/166/500 MHz > GPMC revision 5.0 > IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts > Total of 96 interrupts on 1 active controller > OMAP34xx GPIO hardware version 2.5 > PID hash table entries: 512 (order: 9, 2048 bytes) > OMAP clockevent source: GPTIMER1 at 32768 Hz > Console: colour dummy device 80x30 > Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) > Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > Memory: 128MB = 128MB total > Memory: 126108KB available (3048K code, 447K data, 148K init) > Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696) > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > net_namespace: 288 bytes > android_power_init > android_power_init done > NET: Registered protocol family 16 > MUX: setup J21_34XX_I2C1_SDA (0xd80021bc): 0x1718 -> 0x0118 > MUX: setup K21_34XX_I2C1_SCL (0xd80021ba): 0x1718 -> 0x0118 > MUX: setup AE15_34XX_I2C2_SDA (0xd80021c0): 0x1718 -> 0x0118 > MUX: setup AF15_34XX_I2C2_SCL (0xd80021be): 0x1718 -> 0x0118 > MUX: setup AG14_34XX_I2C3_SDA (0xd80021c4): 0x1718 -> 0x0118 > MUX: setup AF14_34XX_I2C3_SCL (0xd80021c2): 0x1718 -> 0x0118 > OMAP DMA hardware revision 4.0 > USB: No board-specific platform config found > i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz > twl4030: PIH (irq 7) chaining IRQs 368..375 > twl4030: power (irq 373) chaining IRQs 376..383 > twl4030: gpio (irq 368) chaining IRQs 384..401 > i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz > i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz > twl4030_usb twl4030_usb: Initialized TWL4030 USB module > SCSI subsystem initialized > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 > musb_hdrc: USB OTG mode controller at d80ab000 using DMA, IRQ 92 > NET: Registered protocol family 2 > IP route cache hash table entries: 1024 (order: 0, 4096 bytes) > TCP established hash table entries: 4096 (order: 3, 32768 bytes) > TCP bind hash table entries: 4096 (order: 2, 16384 bytes) > TCP: Hash tables configured (established 4096 bind 4096) > TCP reno registered > NET: Registered protocol family 1 > NetWinder Floating Point Emulator V0.97 (double precision) > ashmem: initialized > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > msgmni has been set to 246 > io scheduler noop registered > io scheduler anticipatory registered (default) > io scheduler deadline registered > io scheduler cfq registered > omapfb: configured for panel omap3edge > omapfb: DISPC version 3.0 initialized > Console: switching to colour frame buffer device 60x40 > omapfb: Framebuffer initialized. Total vram 1228800 planes 1 > omapfb: Pixclock 24000 kHz hfreq 45.2 kHz vfreq 70.3 Hz > Serial: 8250/16550 driver4 ports, IRQ sharing enabled > serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 > serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73)
Fwd: Naming convention used in mux.c
Sending to the list in plain text, argh!
-- Ashwin
-- Forwarded message --
From: Ashwin Bihari
Date: Thu, Jan 29, 2009 at 10:45 AM
Subject: Re: Naming convention used in mux.c
To: "Hiremath, Vaibhav"
Cc: "linux-omap@vger.kernel.org"
Vaibhav,
I was also confused by that when I began playing with the OMAP and
only found those references to make sense when I looked at the
schematics of the board I'm working on. If you look at the Terminal
Pin documents for your specific OMAP you will see the alphabet and
numbers make sense. But you need to know which alphabet/number
specifically is designated to a particular function and this is
something the hardware engineer would do while connecting the OMAP to
the rest of the peripherals on the board.
Regards
-- Ashwin
On Thu, Jan 29, 2009 at 10:34 AM, Hiremath, Vaibhav wrote:
>
> Hi,
>
> Can anybody tell me the meaning of naming convention used in mux.c file, e.g.
> -
>
> MUX_CFG_34XX("AH8_34XX_GPIO29", 0x5fa,
>OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
> MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
>OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
>
> What the suffix "AH8_" and "J25_" means here? I looked into TRM and could not
> able to co-relate with any meaningful?
>
> Thanks,
> Vaibhav Hiremath
> Platform Support Products
> Texas Instruments Inc
> Ph: +91-80-25099927
>
> --
> 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
MUSB OTG Interrupts
Greetings, I've got a very curious problem with my OMAP3 based board. I'm using the OMAPZOOM kernel v2.6.27-rc3 and have enabled MUSB in OTG mode (both host and perihperhal). I've got the file-backed-storage gadget. If I plug the mini-B connector to the board, it gets the appropriate interrupt and recognizes that it needs to be operate in peripheral mode and goes about it's business. However, when I plug in the mini-A connector to the board, there is no interrupt and no activity. I can then unplug the mini-A connector, and plug in the mini-B connector to get the interrupts and activity again. If I boot the board up with the mini-A connector plugged in, it is properly found/recognized during driver installation and any devices attached are properly found and can be used. The IRQs at this time fire properly. I have a thumb drive connected to a high speed hub connected to the OMAP board, and the drive is found, I can mount it and do everything. Now, in this particular case, if I unplug the mini-A connector and plug either the mini-A or mini-B connector, nothing happens at all. Why am I only getting interrupts with the mini-B connector and not the mini-A connector? Additionally, why does everything fail after my second scenario above? Regards ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Update USBHOST pinmux settings
On Fri, Sep 26, 2008 at 11:44 AM, Gadiyar, Anand <[EMAIL PROTECTED]> wrote: >> -Original Message----- >> From: Ashwin Bihari [mailto:[EMAIL PROTECTED] > > >> >> Anand, >> >> Can you configure the USBHOST to just use the OHCI controller with a >> Phy and not use the EHCI controller at all? >> >> Regards >> ~ Ashwin > > Hi Ashwin, > > Yes, you can configure USBHOST to just use the OHCI controller > with a PHY and not use EHCI at all. > > Patches coming up on this as soon as I can find the time. This > one was the first in the series - it'll take a little bit of > time to add all the pieces, so I'm sending out the patches as > I generate them. > > Regards, > Anand Anand, That's great to hear..I look forward to see the patches.. Regards ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Update USBHOST pinmux settings
On Fri, Sep 26, 2008 at 11:34 AM, Gadiyar, Anand <[EMAIL PROTECTED]> wrote:
> From: Anand Gadiyar <[EMAIL PROTECTED]>
>
> Add pin-mux settings for OHCI in PHY mode.
> Also change settings for EHCI in TLL mode.
>
> Signed-off-by: Anand Gadiyar <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/mux.c | 67
> +++---
> arch/arm/plat-omap/include/mach/mux.h | 26 -
> 2 files changed, 80 insertions(+), 13 deletions(-)
>
> Index: tony/arch/arm/mach-omap2/mux.c
> ===
> --- tony.orig/arch/arm/mach-omap2/mux.c 2008-09-04 12:57:33.0 +0530
> +++ tony/arch/arm/mach-omap2/mux.c 2008-09-26 20:49:24.963867406 +0530
> @@ -298,13 +298,13 @@ MUX_CFG_34XX("T2_3430_USB2HS_PHY_D7", 0x
>
> /* TLL - HSUSB: 12-pin TLL Port 1*/
> MUX_CFG_34XX("Y8_3430_USB1HS_TLL_CLK", 0x5da,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> -MUX_CFG_34XX("Y9_3430_USB1HS_TLL_STP", 0x5d8,
>OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("Y9_3430_USB1HS_TLL_STP", 0x5d8,
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AA14_3430_USB1HS_TLL_DIR", 0x5ec,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AA11_3430_USB1HS_TLL_NXT", 0x5ee,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("W13_3430_USB1HS_TLL_D0", 0x5dc,
>OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("W12_3430_USB1HS_TLL_D1", 0x5de,
> @@ -324,13 +324,13 @@ MUX_CFG_34XX("Y13_3430_USB1HS_TLL_D7", 0
>
> /* TLL - HSUSB: 12-pin TLL Port 2*/
> MUX_CFG_34XX("AA8_3430_USB2HS_TLL_CLK", 0x5f0,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> -MUX_CFG_34XX("AA10_3430_USB2HS_TLL_STP", 0x5f2,
>OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AA10_3430_USB2HS_TLL_STP", 0x5f2,
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AA9_3430_USB2HS_TLL_DIR", 0x5f4,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AB11_3430_USB2HS_TLL_NXT", 0x5f6,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AB10_3430_USB2HS_TLL_D0", 0x5f8,
>OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AB9_3430_USB2HS_TLL_D1", 0x5fa,
> @@ -350,13 +350,13 @@ MUX_CFG_34XX("T2_3430_USB2HS_TLL_D7", 0x
>
> /* TLL - HSUSB: 12-pin TLL Port 3*/
> MUX_CFG_34XX("AA6_3430_USB3HS_TLL_CLK", 0x180,
> - OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_OUTPUT)
> -MUX_CFG_34XX("AB3_3430_USB3HS_TLL_STP", 0x166,
>OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AB3_3430_USB3HS_TLL_STP", 0x166,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AA3_3430_USB3HS_TLL_DIR", 0x168,
> - OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("Y3_3430_USB3HS_TLL_NXT", 0x16a,
> - OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AA5_3430_USB3HS_TLL_D0", 0x186,
>OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("Y4_3430_USB3HS_TLL_D1", 0x184,
> @@ -373,6 +373,49 @@ MUX_CFG_34XX("AA13_3430_USB3HS_TLL_D6",
>OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AA12_3430_USB3HS_TLL_D7", 0x172,
>OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +
> +/* PHY FSUSB: FS Serial PHY 4-pin mode for Port 1*/
> +MUX_CFG_34XX("AF10_3430_USB1FS_PHY_MM1_RXDP", 0x5d8,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AG9_3430_USB1FS_PHY_MM1_RXDM", 0x5ee,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("W13_3430_USB1FS_PHY_MM1_RXRCV", 0x5dc,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("W12_3430_USB1FS_PHY_MM1_TXSE0", 0x5de,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("W11_3430_USB1FS_PHY_MM1_TXDAT", 0x5e0,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("Y11_3430_USB1FS_PHY_MM1_TXEN_N", 0x5ea,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +
> +/* PHY FSUSB: FS Serial PHY 4-pin mode for Port 2*/
> +MUX_CFG_34XX("AF7_3430_USB2FS_PHY_MM2_RXDP", 0x5f2,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AH7_3430_USB2FS_PHY_MM2_RXDM", 0x5f6,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULL
Re: OMAP support in mainline?
On Fri, Sep 19, 2008 at 3:10 PM, Philip Balister <[EMAIL PROTECTED]> wrote: > Steve Sakoman wrote: >> >> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <[EMAIL PROTECTED]> >> wrote: >> >>> And they aren't working too well with current l-o git either with MUSB >>> being >>> broken. There's a patch to fix client mode, but host mode still isn't >>> working. >> >> Host mode musb is working just fine on Overo with the "set >> transceiver" patch. Not sure why you are having trouble with Beagle >> (and can't check since I don't have my Beagle board with me at the >> moment) > > Does anyone have any suggestions how to figure out what is broken about OTG > used a host on the Beagle? > > Philip > On a related point..I built Kernel v.2.6.27-rc3 from the OMAPZOOM tree with MUSB OTG support. I plug in the mini-B connector into our board, and I get the interrupt and proper recognition that a peripheral mode should be used. When the mini-A connector is plugged in, however, nothing happens. Since there is only one interrupt that triggers the check on which cable-type was plugged in, why would the mini-A cable not cause an interrupt to be generated? I've also tried compiling the code in just MUSB HOST. Nothing happens, when I plug in the mini-B cable, it's detected by markedly less things happen because I don't have peripheral support. Regards ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting 2.6.25 from git to run on omap35x evm
On Wed, Sep 17, 2008 at 4:11 PM, twebb <[EMAIL PROTECTED]> wrote: > On Wed, Sep 17, 2008 at 3:36 PM, Ashwin Bihari <[EMAIL PROTECTED]> wrote: >>> >>> Does anyone (TI?) know how far apart their linux-2.6.22.18 (SDK 1.0.0) >>> is from the linux-omap-2.6.git and when they might converge? Along >>> these lines, which defconfig to use for OMAP35x EVM: SDK = >>> omap3evm_defconfig or linux-omap-2.6.25 = omap3_evm_defconfig >>> (different names and different contents)? >>> >> >> If you take a look at the http://git.omapzoom.org tree as opposed to >> the official Linux OMAP tree, that things will be more linear to your >> 2.6.22.18 tree. I'm currently moving our 2.6.22.18 codebase to >> 2.6.27-rc3 based on the OMAPZOOM tree and it's faring a lot better >> then when I tried the official tree. >> >> So use OMAPZOOM to quickly jump ahead and once up-to-date you can >> figure out what the next step is to get more towards the official L-O >> tree.. >> >> Regards >> ~ Ashwin >> > > Great, that's helpful. Do you know omapzoom linux-2.6.25 to be > somewhat functional with OMAP 35x EVM, or would you suggest going with > something newer like v2.6.26-ti-07252008? Or must I go to 2.6.27-rc3? > I assume newer (to a point) would result in better stability on the > 35x EVM? > > Thanks, > twebb > The EVM is a board option in this tree, so you're going to have the best possible luck with the latest and greatest code base. I have a custom board based on the OMAP3530. So I'm actually adding a new board-type and the necessary pieces appropriate for my platform. Regards ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting 2.6.25 from git to run on omap35x evm
On Wed, Sep 17, 2008 at 3:23 PM, twebb <[EMAIL PROTECTED]> wrote: > On Wed, Sep 17, 2008 at 2:59 PM, Koen Kooi <[EMAIL PROTECTED]> wrote: >> >> Why 2.6.25? Git has 2.6.26 already and currenly is at 2.6.27rc6, so why go >> from one obsolete version to another obsolete one? .27rc is pretty broken on >> the EVM atm, ut .26 should work fine. >> > Was going with 2.6.25 because once I get basic functionality on the > EVM with linux-omap-2.6.25, next step is applying a separate > 2.6.25-based patch. So 2.6.26 should work OK on 35xEVM? If so, I'll > see if patch applies without problems and give it a try. > > Does anyone (TI?) know how far apart their linux-2.6.22.18 (SDK 1.0.0) > is from the linux-omap-2.6.git and when they might converge? Along > these lines, which defconfig to use for OMAP35x EVM: SDK = > omap3evm_defconfig or linux-omap-2.6.25 = omap3_evm_defconfig > (different names and different contents)? > > Thanks. > twebb > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > If you take a look at the http://git.omapzoom.org tree as opposed to the official Linux OMAP tree, that things will be more linear to your 2.6.22.18 tree. I'm currently moving our 2.6.22.18 codebase to 2.6.27-rc3 based on the OMAPZOOM tree and it's faring a lot better then when I tried the official tree. So use OMAPZOOM to quickly jump ahead and once up-to-date you can figure out what the next step is to get more towards the official L-O tree.. Regards ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Working with Linux-Omap GIT Tree
A quick question about the OMAP GIT trees as I'm playing with them right now. There are two trees that I can see, one at http://git.omapzoom.org/repo/omapkernel and another at git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git. The OMAPZoom tree seems to have a few of the files that are missing from the git.kernel.org tree that I was looking to modify.. Which tree should I be using to put my board-support files into? Or is it a combination of the two? Regards On Thu, Sep 4, 2008 at 3:04 PM, Aguirre Rodriguez, Sergio Alberto <[EMAIL PROTECTED]> wrote: > And one more thing... > > If you have a driver which was previously including a header like this: > > #include > > You have to change it to: > > #include > > To point to the new location. > > Regards, > Sergio > > -Original Message- > From: Ashwin Bihari [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2008 1:51 PM > To: Aguirre Rodriguez, Sergio Alberto > Cc: linux-omap@vger.kernel.org > Subject: Re: Working with Linux-Omap GIT Tree > > On Thu, Sep 4, 2008 at 2:44 PM, Aguirre Rodriguez, Sergio Alberto > <[EMAIL PROTECTED]> wrote: >> Hi Ashwin, >> >> The folder you're looking for has been moved to arch/arm/plat-omap/include/ >> >> This has to have the same contents you had in that version + the following >> changes to them. >> >> Hope this helped you. >> >> Regards, >> Sergio > > Hi Sergio, > > Thanks for the pointer on the move. I should've spent more time poking > around the trees I guess. Sorry for the noise.. > > ~ Ashwin > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omapzoom tree broken?
On Tue, Sep 9, 2008 at 1:59 PM, Russell King - ARM Linux <[EMAIL PROTECTED]> wrote: > When trying to fetch the omapzoom tree, I get: > > got a4ae90758b3c38012c875a62d0dd8a20a30e413b > walk a4ae90758b3c38012c875a62d0dd8a20a30e413b > Getting alternates list for http://git.omapzoom.org/repo/omapkernel > Getting pack list for http://git.omapzoom.org/repo/omapkernel > Getting index for pack 567cbb972dbfa42338e1269ca4a4a03ec2b1d35f > Resuming fetch of index for pack 567cbb972dbfa42338e1269ca4a4a03ec2b1d35f at > byte 5890048 > error: wrong index v1 file size in > .git/objects/pack/pack-567cbb972dbfa42338e1269ca4a4a03ec2b1d35f.idx > Segmentation fault > > Could we have it accessible via git the protocol please, rather than > http? Russell, I just pulled the omapzoom tree for the first time and it had no problems in the "git clone". Perhaps something to do with fetching into an existing repo? ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Working with Linux-Omap GIT Tree
On Thu, Sep 4, 2008 at 2:44 PM, Aguirre Rodriguez, Sergio Alberto <[EMAIL PROTECTED]> wrote: > Hi Ashwin, > > The folder you're looking for has been moved to arch/arm/plat-omap/include/ > > This has to have the same contents you had in that version + the following > changes to them. > > Hope this helped you. > > Regards, > Sergio Hi Sergio, Thanks for the pointer on the move. I should've spent more time poking around the trees I guess. Sorry for the noise.. ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Working with Linux-Omap GIT Tree
Greetings, I've been tasked with taking all of the code for our OMAP based board currently based on the 2.6.22.18 Kernel to the latest version and so I decided that I would do things in a way that not allowed me to move our code forward but also allow me to take any new changes made to the Linux-Omap tree. To that end, I cloned the GIT tree from git.kernel.org/linux/kernel/git/tmlind/linux-omap-2.6.git and am looking at the HEAD of the tree. I was going to start creating branches for each step of my integration effort which would allow me to keep things separate and also allow me to pull any changes from the mainline tree. When I pulled the tree I noticied that most of the files from the include/arch-arm/ directory were missing save for a couple of directories. I then visited the web interface and see the same situation looking at the latest v2.6.27-rc5 tag from 6 days ago or the latest commit marked Master. I then began going back to previous tags and previous commits to see where this changed and had to go all the way back to v2.6.26-omap1 tag (commit d6daf8d8cc5ccf90247def5551ee9c3e8555e848) to see the contents of the include/arch-asm directory, and the commit immediately after (commit a7448db4826efb097e94f601f4cd9b37053e81bf) is where the files are all missing. I'm a bonafide newbie when it comes to GIT and am trying to get my hands around this while trying not to mess things up in a way that would require me to re-do a lot of things.. So what's the right way for me to get the latest tree so that I can begin integrating my code rather than using a tag some 3-4 weeks ago which contains all the files I'm interested in modifying? Regards ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling MUSB support
On Wed, Aug 27, 2008 at 9:40 AM, Gadiyar, Anand <[EMAIL PROTECTED]> wrote: >> Greetings, >> >> I'm trying to test out the MUSB support on my OMAP-3530 based device >> with the TWL4030 Phy. I'm using 2.6.22.18 and have tried to enable all >> different settings related to MUSB and nothing seems to happen. The >> TWL4030_USB driver builds and loads and claims that a cable is plugged >> in even when nothing is plugged in. >> >> The "musb_hdrc" driver loads up and registers with IRQs 92 and 93. The >> TWL4030_USB driver registers with IRQ 373. As I plug-in and remove the >> cable from the USB port, no interrupts are generated and the driver is >> completely oblivious to what's happening.. >> >> I'm trying to configure the MUSB driver as a Host-only to start with, >> I've also tried to set it as OTG with no change. >> >> My current ".config" is as follows, could someone point me to any >> configuration option or anything that I'm missing.. > > Can you try "echo F > /proc/driver/musb_hdrc" twice? > Or try building it in gadget mode? > > Or use the current kernel (recommended option). > > - Anand > I tried this command saw no activity, I tried the other commands "C", "T" also with no effect. My reigster dump looks like: musb_proc_write 847: R: dump all registers fadd pwr inTx inRx inTe inRe intU inUe fram indx tstm dctl 00e0 fffe 00f7 000f 0081 dma_ch cntladdress count ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling MUSB support
On Wed, Aug 27, 2008 at 9:38 AM, Felipe Balbi <[EMAIL PROTECTED]> wrote: > On Wed, Aug 27, 2008 at 09:26:34AM -0400, ext Ashwin Bihari wrote: >> Greetings, >> >> I'm trying to test out the MUSB support on my OMAP-3530 based device >> with the TWL4030 Phy. I'm using 2.6.22.18 and have tried to enable all > > I'll probably start the same discussion again, that's a rather old > kernel. It would be nice to try out current git tree from [1] and report > again if it works or not. > > I tried musb on omap2420 (with tusb), omap3430 and omap3530 (beagle > board) and all of them are working. I'm working on a custom board namely the LogicPD Zoom OMAP3530 LV SOM and we have support for our devkit in the 2.6.22.18 Kernel. Bringing all of our changes to the latest tree would take me a bit of time and I just want to validate the hardware to ensure that things are working in their current state. I suppose, like I did previously for the EHCI USB controller, I could back-port the changes specific to the MUSB back from the latest Kernel to my version. Could you send me your configuration for the beagle board? My hardware configuration resembles that particular board. > >> different settings related to MUSB and nothing seems to happen. The >> TWL4030_USB driver builds and loads and claims that a cable is plugged >> in even when nothing is plugged in. > > Sounds like a bug in twl4030-usb.c I agree.. > >> The "musb_hdrc" driver loads up and registers with IRQs 92 and 93. The >> TWL4030_USB driver registers with IRQ 373. As I plug-in and remove the >> cable from the USB port, no interrupts are generated and the driver is >> completely oblivious to what's happening.. > > Do you have id pin grounded ? > >> I'm trying to configure the MUSB driver as a Host-only to start with, >> I've also tried to set it as OTG with no change. > > Use it as otg and put a gadget driver as well, it's better. > >> My current ".config" is as follows, could someone point me to any >> configuration option or anything that I'm missing.. > > I'd just suggest you to use as otg and put a gadget driver. Would use OTG Host not make things significantly easy as far as software goes without having to determine the roles based on which end of the USB cable is plugged in? > > Which board are you using ? Is it some development board or a custom > board ? > > Development boards have a defconfig that might help you. Unfortuatenly, this is a custom board for which we are creating the defconfig..so isn't easy to jump to the latest Kernel and use another defconfig.. ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Enabling MUSB support
Greetings, I'm trying to test out the MUSB support on my OMAP-3530 based device with the TWL4030 Phy. I'm using 2.6.22.18 and have tried to enable all different settings related to MUSB and nothing seems to happen. The TWL4030_USB driver builds and loads and claims that a cable is plugged in even when nothing is plugged in. The "musb_hdrc" driver loads up and registers with IRQs 92 and 93. The TWL4030_USB driver registers with IRQ 373. As I plug-in and remove the cable from the USB port, no interrupts are generated and the driver is completely oblivious to what's happening.. I'm trying to configure the MUSB driver as a Host-only to start with, I've also tried to set it as OTG with no change. My current ".config" is as follows, could someone point me to any configuration option or anything that I'm missing.. Regards # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.18-omap3 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_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_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set 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_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=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_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set CONFIG_BLK_DEV_IO_TRACE=y # CONFIG_LSF 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" # # System Type # # 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_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_IMX 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_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y # # TI OMAP Implementations # # CONFIG_ARCH_OMAP1 is not set # CONFIG_ARCH_OMAP2 is not set CONFIG_ARCH_OMAP3=y # # OMAP Feature Selections # CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_BOOT_TAG=y CONFIG_OMAP_BOOT_REASON=y # CONFIG_OMAP_COMPONENT_VERSION is not set # CONFIG_OMAP_GPIO_SWITCH is not set CONFIG_OMAP_MUX=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_OMAP_MUX_WARNINGS=y # CONFIG_OMAP_MMU_FWK is not set # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y CONFIG_OMAP_LL_DEBUG_UART1=y # CONFIG_OMAP_LL_DEBUG_UART2 is not set # CONFIG_OMAP_LL_DEBUG_UART3 is not set CONFIG_OMAP_SERIAL_WAKE=y # CONFIG_OMAP_ZEBU is not set CONFIG_HS_SERIAL_SUPPOR
Re: HS USB errors on OMAP3530
On Thu, Aug 7, 2008 at 3:38 PM, David Brownell <[EMAIL PROTECTED]> wrote: > On Thursday 07 August 2008, Ashwin Bihari wrote: > >> sd 0:0:0:0: [sda] Attached SCSI removable disk >> usb 1-2: reset high speed USB device using ehci-omap and address 2 >> usb 1-2: device descriptor read/64, error -110 >> usb 1-2: device descriptor read/64, error -110 >> usb 1-2: reset high speed USB device using ehci-omap and address 2 >> usb 1-2: device descriptor read/64, error -110 >> usb 1-2: device descriptor read/64, error -110 >> usb 1-2: reset high speed USB device using ehci-omap and address 2 >> usb 1-2: device not accepting address 2, error -110 >> usb 1-2: reset high speed USB device using ehci-omap and address 2 >> usb 1-2: device not accepting address 2, error -110 >> usb 1-2: USB disconnect, address 2 >> sd 0:0:0:0: Device offlined - not ready after error recovery >> Result: hostbyte=0x01 driverbyte=0x00 >> end_request: I/O error, dev sda, sector 775288 >> end_request: I/O error, dev sda, sector 775288 >> ... > > I wouldn't assume this is specifically an OMAP issue -- though > it might be in this case. If you could throw a USB sniffer at > the problem and report what that shows, it may be enlightening... > > Folk have been reporting these symptoms for some time, but > nobody can quite track it down. I think one person who was > able to observe the problem (I've never seen it) reported that > switching disk, USB cable, *OR* PC host made the problem go > away ... but MS-Windows didn't see it on the same hardware. > > As I recall, one person had some recent success shrinking the > "let SET_ADDRESS settle" mdelay in drivers/usb/hub.c (near > line 2535). Strictly speaking, that shouldn't be needed. > > - Dave > Dave, I did use a Total Phase Beagle 480USB protocol analyzer when this issue first manifested, but there is nothing that jumped out at me as a possible error or glitch. It just looks like the transactions just stopped mid-way without any rhyme or reason. I've noticed this issue with a couple of HS flash drives, as well as, a FS CD-ROM drive. Would the "let SET_ADDRESS settle" change only affect the initial detection? My initial insertion of device works great, the errors I showed are after I do a read of a large amount of data from the Flash drive and essentially wedge something in the USB stream. Regards ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
HS USB errors on OMAP3530
Greetings, I've got a OMAP3530 based board on which I'm having some trouble with HS USB transfers. I plug in a HS USB Flash drive and it is properly detected. I can mount the drive and write any amount of data to it without any problems. However, when I start reading from the drive, the action halts at some random point with the USB driver indicating that it got less data than it requested in it's transaction. Once this failure occurs, the port gets reset and the inserted Flash drive is "detected" again but none of the descriptors can be retrieved to actually configure/enumerate the device. After a few more reset cycles the process just halts. The console messages are the following.. --- Console Messages --- <7>usb-storage: waiting for device to settle before scanning scsi 0:0:0:0: Direct-Access USB DISK 2.0 PMAP PQ: 0 ANSI: 0 CCS sd 0:0:0:0: [sda] 964608 512-byte hardware sectors (494 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] 964608 512-byte hardware sectors (494 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device not accepting address 2, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device not accepting address 2, error -110 usb 1-2: USB disconnect, address 2 sd 0:0:0:0: Device offlined - not ready after error recovery Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 775288 end_request: I/O error, dev sda, sector 775288 Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 775528 end_request: I/O error, dev sda, sector 775528 usb 1-2: new high speed USB device using ehci-omap and address 3 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: new high speed USB device using ehci-omap and address 4 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: new high speed USB device using ehci-omap and address 5 usb 1-2: device not accepting address 5, error -110 usb 1-2: new high speed USB device using ehci-omap and address 6 usb 1-2: device not accepting address 6, error -110 hub 1-0:1.0: unable to enumerate USB device on port 2 --- End Messages -- Why the writes succeed without any issues while the reads fail has me completely stumped. I'm currently using The Linux Kernel version 2.6.24.7 from omapzoom.org with the /drivers/usb code from the latest 2.6.26 back-ported. Attempting to jump to the newest Kernel would require some work to get my board-specific code all happy and I'm in the process of doing that.. I would love to hear from ideas on what might be going on and what I should be looking at to get this resolved. Regards ~ Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
