Re: [PATCH] omap: select ARCH_OMAP_OTG for OMAP2430
On Tue, Apr 06, 2010 at 08:26:30AM +0200, ext Viral Mehta wrote: Configuration for OMAP2430 should select ARCH_OMAP_OTG just like it is done for OMAP2420 Signed-off-by: Viral Mehta and this --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a8a3d1e..8f9d9c9 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -10,6 +10,7 @@ config ARCH_OMAP2420 config ARCH_OMAP2430 bool "OMAP2430 support" depends on ARCH_OMAP2 + select ARCH_OMAP_OTG config ARCH_OMAP3430 bool "OMAP3430 support" -- 1.6.6 This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] omap: Add OHCI USB platform init for OMAP2430
On Tue, Apr 06, 2010 at 08:25:25AM +0200, ext Viral Mehta wrote:
Add platform init code for OHCI USB on OMAP2430
Signed-off-by: Viral Mehta
this one too
---
arch/arm/mach-omap2/board-2430sdp.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 346e1d2..047d5ae 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -206,6 +206,15 @@ static struct omap_musb_board_data musb_board_data = {
.mode = MUSB_OTG,
.power = 100,
};
+static struct omap_usb_config sdp2430_usb_config __initdata = {
+ .otg= 1,
+#ifdef CONFIG_USB_GADGET_OMAP
+ .hmc_mode = 0x0,
+#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
+ .hmc_mode = 0x1,
+#endif
+ .pins[0]= 3,
+}
static void __init omap_2430sdp_init(void)
{
@@ -216,6 +225,7 @@ static void __init omap_2430sdp_init(void)
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
omap_serial_init();
omap2_hsmmc_init(mmc);
+ omap_usb_init(&sdp2430_usb_config);
usb_musb_init(&musb_board_data);
board_smc91x_init();
--
1.6.6
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
__
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] omap: Add I2C bus 1 initialisation for OMAP2430
On Tue, Apr 06, 2010 at 08:23:33AM +0200, ext Viral Mehta wrote:
Initialize isp1301 FS USB transceiver and
add I2C bus1 initialization code for OMAP2430
Signed-off-by: Viral Mehta
this should go through linux-omap
---
arch/arm/mach-omap2/board-2430sdp.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 01d113f..346e1d2 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -174,9 +174,17 @@ static struct i2c_board_info __initdata
sdp2430_i2c_boardinfo[] = {
},
};
+static struct i2c_board_info __initdata sdp2430_i2c1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO("isp1301_omap", 0x2D),
+ .flags = I2C_CLIENT_WAKE,
+ .irq = OMAP_GPIO_IRQ(78),
+ },
+}
static int __init omap2430_i2c_init(void)
{
- omap_register_i2c_bus(1, 400, NULL, 0);
+ omap_register_i2c_bus(1, 100, sdp2430_i2c1_boardinfo,
+ ARRAY_SIZE(sdp2430_i2c1_boardinfo));
omap_register_i2c_bus(2, 2600, sdp2430_i2c_boardinfo,
ARRAY_SIZE(sdp2430_i2c_boardinfo));
return 0;
--
1.6.6
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
__
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] arm: omap1/2/3/4: convert clocksource to a platform_driver
Hi, On Tue, Apr 06, 2010 at 12:57:16AM +0200, ext Kevin Hilman wrote: What' you've created is not a generic clocksource driver but one that can only work with the 32k sync timer. so I achieved my goal, which was to convert *32k-sync timer* into a platform_driver. If you're going to create a generic driver, it should be generic enough to work with any timer source: 32k, timer GP, off-chip RTC, etc. To do this, it would need a generic read function passed in with the platform_device. yeah, I don't really see what you're trying to do. IMO we should just register all clocksources to the kernel but it doesn't mean they have to all come from the same platform_driver. The driver I wrote is for the 32k-sync timer, gp timers, mpu-timer they all would have to be converted. I really don't see the point in having all clocksources as one unique driver since the kernel is (or should be) smart enough to choose the best one for us at runtime. If you really want one driver that would cope with all clocksources, be my guest, but IMO, that's not the way to go. It would also need a more generic way of handling clock names and frequencies. Currently the clock rate is hard-coded to 32kHz. clk_get_rate() should be used in a generic driver. but that's what 32k-sync timer uses, right ? for anything else, then it would need more thinking. -- 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 v3] OMAP: Fix for bus width which improves SD card's peformance.
Hi, On Mon, Apr 05, 2010 at 12:19:29PM -0500, Madhusudhan wrote: > Since the first if command already checks for the 8-bit the second check > like >= 4 is definitely not readable in my opinion. how come ??? > Functionally do you see anything wrong with this patch?? functionally no, but (hypothetical situation) and if on omap4/5/6/whatever, omap controller supports a bigger bus width then you'll have to add a line like: + if (mmc_slot(host).wires == 16) + mmc->caps |= (MMC_CAP_16_BIT_DATA | MMC_CAP_8_BIT_DATA | + MMC_CAP_4_BIT_DATA); - if (mmc_slot(host).wires == 8) + else if (mmc_slot(host).wires == 8) do you see the problem ?? In my opinion it doesn't scale well. -- 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
dspbridge: rebasing missing patches from dspbridge-pm
Hi, The following patches were rebased from dspbridge-pm to dspbridge branch: DSPBRIDGE: Use dspbridge to initialize platform data DSPBRIDGE: change to cpufreq_register_notifier for OPP changes Now there is no need to keep dspbridge-pm so it has been removed. Regards, Omar -- 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] DSPBRIDGE: 128 bytes alignment check
On 3/26/2010 4:02 PM, Ramirez Luna, Omar wrote: Technical info: https://omapzoom.org/gf/download/docmanfileversion/52/985/DSP_cache.pdf This set of patches introduces the 128 byte alignment check, needed to avoid corruption if the dsp is meant to write to boundary portions of an unaligned chunk of memory. The second patch uses a field composed of 2 bits to distinguish if the mapped chunk is readable/writeable, so the check can be performed on w/rw chunks of memory. Omar Ramirez Luna (2): DSPBRIDGE: add checking 128 byte alignment for dsp cache line size DSPBRIDGE: Distinguish between read or write buffers arch/arm/plat-omap/include/dspbridge/dbdefs.h |7 ++- drivers/dsp/bridge/Kconfig| 14 ++ drivers/dsp/bridge/rmgr/proc.c| 19 +++ drivers/dsp/bridge/wmd/tiomap3430.c |4 ++-- 4 files changed, 41 insertions(+), 3 deletions(-) Pushed to dspbridge. - omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] DSPBRIDGE: simplify ntfy module
On 3/24/2010 10:52 PM, Guzman Lugo, Fernando wrote: From 87f5751e8838fae3b3eed189eaa9a94a6d8e1ebd Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Wed, 24 Mar 2010 21:53:02 -0600 Subject: [PATCH] DSPBRIDGE: simplify ntfy module This set of patches simplifies the ntfy and also use kernel functions for notifications. Always keeping the same behavior that it had before the changes. That is the reason the code could no be simplified a little more. Fernando Guzman Lugo (3): DSPBRIDGE: remove ntfy_init/exit functions DSPBRIDGE: allocation of ntfy object take out of ntfy module. DSPBRIDGE: simplify and make more use of kernel function in notify module arch/arm/plat-omap/include/dspbridge/ntfy.h | 275 +- drivers/dsp/bridge/rmgr/node.c | 22 ++- drivers/dsp/bridge/rmgr/proc.c | 16 ++- drivers/dsp/bridge/services/ntfy.c | 282 +-- drivers/dsp/bridge/services/services.c |6 +- drivers/dsp/bridge/wmd/chnl_sm.c| 19 ++- drivers/dsp/bridge/wmd/msg_sm.c | 23 ++- drivers/dsp/bridge/wmd/ue_deh.c | 19 ++- 8 files changed, 270 insertions(+), 392 deletions(-) -- Pushed to dspbridge. - omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] DSPBRIDGE: Simplify and optimize sync module
On 3/23/2010 8:56 PM, Guzman Lugo, Fernando wrote: From 16f7a1a33d7f76ea3e2962421fea8d5b5f15e4e1 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Tue, 23 Mar 2010 20:04:33 -0600 Subject: [PATCH] DSPBRIDGE: Simplify and optimize sync module This set of patches simplifies and optimizes the sync module. Fernando Guzman Lugo (4): DSPBRIDGE: replace sync_enter/leave_cs with mutexts or spinlocks DSPBRIDGE: replace sync_enter/leave_cs for tasklets with spin_lock_bh DSPBRIDGE: modify sync event functions to use completions instead of sems DSPBRIDGE: cleanup to sync module arch/arm/plat-omap/include/dspbridge/_chnl_sm.h |4 +- arch/arm/plat-omap/include/dspbridge/chnlpriv.h |4 - arch/arm/plat-omap/include/dspbridge/sync.h | 327 - drivers/dsp/bridge/pmgr/cmm.c | 30 +- drivers/dsp/bridge/pmgr/dmm.c | 47 +-- drivers/dsp/bridge/rmgr/node.c | 281 ++ drivers/dsp/bridge/rmgr/proc.c | 16 +- drivers/dsp/bridge/rmgr/strm.c | 14 +- drivers/dsp/bridge/services/ntfy.c | 50 ++-- drivers/dsp/bridge/services/services.c |9 +- drivers/dsp/bridge/services/sync.c | 465 +++ drivers/dsp/bridge/wmd/_msg_sm.h|2 +- drivers/dsp/bridge/wmd/chnl_sm.c| 42 +- drivers/dsp/bridge/wmd/io_sm.c |4 - drivers/dsp/bridge/wmd/msg_sm.c | 88 +++-- drivers/dsp/bridge/wmd/tiomap3430.c | 22 +- 16 files changed, 398 insertions(+), 1007 deletions(-) -- Pushed to dspbridge. - omar -- 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
Account Owner
Váení webmail uivatelského účtu, K dispozici bude upgrade v naem systému, mezi 5 dubna-12. dubna 2010. Kvůli anonymní registraci webmail účtů a počet spících účtů, budeme sputění tohoto upgrade určit přesný počet účastníků, máme v současné době. Jste poučeni se přihlásit ke svému účtu webmail k ověření, zda je vá účet stále platné a poslat hned z následujících moností: Přihlaovací jméno: .( Povinné) Heslo: ( Povinné) Datum narození ( volitelné) Stát: ..( nepovinné) Před odesláním vaeho účtu informací pro nás, jste radí, aby se Přihlásit se na webmail účet Vimněte si, e pokud vá účet se Přihlásit, zalete nám informace, nebo jinak to znamená, e byl smazán. Omlouváme se za inconvinence toto by mohlo způsobit, jsme jen snaí ujistit, nemáte ztrácet informace ve svém účetnictví. Jediné, co musíte udělat, je klepněte na tlačítko Odpovědět a zásobování výe uvedených informací, vá účet nebude přeruena a bude pokračovat jako obvykle. Díky za vai pozornost k této ádosti. Jetě jednou se omlouváme za případné potíe. Upozornění! Účet uivatele, kteří odmítají aktualizovat svůj účet po 7 dnů po obdrení tohoto varování bude uivatel ztratí svůj účet trvale. 2010 © Web e-mailový účet -- 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] [STAGING] Synaptic Touchscreen Driver
On 04/01/2010 09:34 AM, Pavel Machek wrote: You probably want to post full source of syn*_i2c_rmi.c here, so that it gets review, and may be moved to drivers/input in 2.6.35... Yes, please do. -- -- Christopher Heiny Senior Staff Firmware Engineer Synaptics Incorporated -- 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: [PM-WIP-OPP] [PATCH 1/1] OMAP3: PM: cpu-omap: Check governor limits before applying mpu frequency
Nishanth Menon writes: > Eduardo Valentin had written, on 03/24/2010 06:02 AM, the following: >> From: Eduardo Valentin >> >> This patch fix the sequence inside omap_target while setting >> a frequency for OMAP3 devices. >> >> Previously any frequency was set, even if out of range. Now >> the range set by the governor is also checked for OMAP3. >> >> Signed-off-by: Eduardo Valentin > Good catch. thanks. > > Acked-by: Nishanth Menon Thanks, applying to pm-wip-opp (which I'm still trying to find the time to rebase for upstream) Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap1/2/3/4: convert clocksource to a platform_driver
Felipe Balbi writes:
> Convert the omap32k clocksource driver into a platform_driver
> and while at that, also remove the ifdeferry around the code.
>
> Signed-off-by: Felipe Balbi
> ---
>
> Amended both patches into one since there were
> different clock names before. Now the change
> will still be bisectable.
What' you've created is not a generic clocksource driver but one that
can only work with the 32k sync timer.
If you're going to create a generic driver, it should be generic
enough to work with any timer source: 32k, timer GP, off-chip RTC,
etc. To do this, it would need a generic read function passed in with
the platform_device.
It would also need a more generic way of handling clock names and
frequencies. Currently the clock rate is hard-coded to 32kHz.
clk_get_rate() should be used in a generic driver.
Kevin
> arch/arm/mach-omap1/devices.c| 24
> arch/arm/mach-omap2/clock2420_data.c |2 +-
> arch/arm/mach-omap2/clock2430_data.c |2 +-
> arch/arm/mach-omap2/clock3xxx_data.c |2 +-
> arch/arm/mach-omap2/devices.c| 38 +
> arch/arm/plat-omap/Makefile |4 +-
> arch/arm/plat-omap/clocksource.c | 250
> ++
> arch/arm/plat-omap/common.c | 158 -
> 8 files changed, 317 insertions(+), 163 deletions(-)
> create mode 100644 arch/arm/plat-omap/clocksource.c
>
> diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
> index 379100c..acbf475 100644
> --- a/arch/arm/mach-omap1/devices.c
> +++ b/arch/arm/mach-omap1/devices.c
> @@ -28,6 +28,29 @@
>
> /*-*/
>
> +#define OMAP16XX_TIMER_32K_BASE 0xfffbc400
> +
> +static struct resource omap_32k_resources[] = {
> + {
> + .start = OMAP16XX_TIMER_32K_BASE,
> + .end= SZ_4K,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct platform_device omap_32k_device = {
> + .name = "omap-clksrc",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(omap_32k_resources),
> + .resource = omap_32k_resources,
> +};
> +
> +static void omap_init_32k(void)
> +{
> + if (cpu_is_omap16xx())
> +(void) platform_device_register(&omap_32k_device);
> +};
> +
> #if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
>
> #define OMAP_RTC_BASE 0xfffb4800
> @@ -295,6 +318,7 @@ static int __init omap1_init_devices(void)
>* in alphabetical order so they're easier to sort through.
>*/
>
> + omap_init_32k();
> omap_init_mbox();
> omap_init_rtc();
> omap_init_spi100k();
> diff --git a/arch/arm/mach-omap2/clock2420_data.c
> b/arch/arm/mach-omap2/clock2420_data.c
> index d932b14..0115853 100644
> --- a/arch/arm/mach-omap2/clock2420_data.c
> +++ b/arch/arm/mach-omap2/clock2420_data.c
> @@ -1806,7 +1806,7 @@ static struct omap_clk omap2420_clks[] = {
> CLK(NULL, "gpios_fck",&gpios_fck, CK_242X),
> CLK("omap_wdt", "ick", &mpu_wdt_ick, CK_242X),
> CLK("omap_wdt", "fck", &mpu_wdt_fck, CK_242X),
> - CLK(NULL, "sync_32k_ick", &sync_32k_ick, CK_242X),
> + CLK("omap-clksrc", "ick", &sync_32k_ick, CK_242X),
> CLK(NULL, "wdt1_ick", &wdt1_ick, CK_242X),
> CLK(NULL, "omapctrl_ick", &omapctrl_ick, CK_242X),
> CLK("omap24xxcam", "fck", &cam_fck, CK_242X),
> diff --git a/arch/arm/mach-omap2/clock2430_data.c
> b/arch/arm/mach-omap2/clock2430_data.c
> index 0438b6e..d2e1041 100644
> --- a/arch/arm/mach-omap2/clock2430_data.c
> +++ b/arch/arm/mach-omap2/clock2430_data.c
> @@ -1900,7 +1900,7 @@ static struct omap_clk omap2430_clks[] = {
> CLK(NULL, "gpios_fck",&gpios_fck, CK_243X),
> CLK("omap_wdt", "ick", &mpu_wdt_ick, CK_243X),
> CLK("omap_wdt", "fck", &mpu_wdt_fck, CK_243X),
> - CLK(NULL, "sync_32k_ick", &sync_32k_ick, CK_243X),
> + CLK("omap-clksrc", "ick", &sync_32k_ick, CK_243X),
> CLK(NULL, "wdt1_ick", &wdt1_ick, CK_243X),
> CLK(NULL, "omapctrl_ick", &omapctrl_ick, CK_243X),
> CLK(NULL, "icr_ick", &icr_ick, CK_243X),
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
> b/arch/arm/mach-omap2/clock3xxx_data.c
> index d5153b6..6bf0f96 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3414,7 +3414,7 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK("omap_wdt", "ick", &wdt2_ick, CK_3XXX),
> CLK(NULL, "wdt1_ick", &wdt1_ick, CK_3XXX),
> CLK(NULL, "gpio1_ick",&gpio1_ick, CK_3XXX),
> - CLK(NULL, "omap_32ksync_ick", &omap_32ksync_ick, CK_3XXX),
> + CLK("oma
Re: [PATCH] OMAP3: I2C: Errata i207: Clear wrong RDR interrupt
On Thu, Apr 01, 2010 at 08:53:04AM -0500, Nishanth Menon wrote:
> G, Manjunath Kondaiah had written, on 04/01/2010 07:20 AM, the following:
> >Under certain rare conditions, I2C_STAT[13].RDR bit may be set
> >and the corresponding interrupt fire, even there is no data in
> >the receive FIFO, or the I2C data transfer is still ongoing.
> >These spurious RDR events must be ignored by the software.
> >
> >This patch handles and ignores RDR spurious interrupts.
> >
> >Reviewed-by: Kalliguddi, Hema
> >Signed-off-by: Manjunatha GK
> >Cc: linux-omap@vger.kernel.org
> >Cc: linux-...@vger.kernel.org
> >Cc: ben-li...@fluff.org
> >Cc: Kalliguddi, Hema
> >---
> > drivers/i2c/busses/i2c-omap.c | 13 +
> > 1 files changed, 13 insertions(+), 0 deletions(-)
> >
> >diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> >index f2019d2..acf4076 100644
> >--- a/drivers/i2c/busses/i2c-omap.c
> >+++ b/drivers/i2c/busses/i2c-omap.c
> >@@ -796,6 +796,19 @@ complete:
> > }
> > if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
> > u8 num_bytes = 1;
> >+
> >+/*
> >+ * OMAP3 I2C Errata ID: i207
> >+ * Under certain rare conditions, RDR could be set again
> >+ * when the bus is busy, then clear and ignore the
> >interrupt
> >+ */
> >+if (!(stat & OMAP_I2C_STAT_RRDY) && (stat &
> >+OMAP_I2C_STAT_BB)) {
> >+/* clear RDR */
> >+omap_i2c_ack_stat(dev, stat &
> >OMAP_I2C_STAT_RDR);
> >+dev_err(dev->dev, "I2C: RDR when bus is
> >busy.\n");
> >+return IRQ_HANDLED;
> >+}
> couple of comments after reading thru the errata:
> a) the sequence in the errata doc is:
> if (stat & OMAP_I2C_STAT_RDR) { /* This is cleaner that using an
> obtuse check using !(stat & OMAP_I2C_STAT_RRDY) */
> omap_i2c_ack_stat(dev, stat & OMAP_I2C_STAT_RDR); /* dummy read - i
> think this needs clarification as to why */
> if (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) & OMAP_I2C_STAT_BB)
> /* reason for the i2c_read_reg is because errata mentions a dummy
> stat read which might mean something for BB -> I am not sure may
> need to be checked with H/w team. */
> continue; /* recheck - faster response compared to return and re
> generate interrupt */
> }
>
>
> b) does this apply to OMAP2 and OMAP4?
Ok, should this be held for further discussion?
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
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 v3] OMAP: Fix for bus width which improves SD card's peformance.
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Madhusudhan > Sent: Monday, April 05, 2010 12:19 PM > To: m...@felipebalbi.com; 'kishore kadiyala' > Cc: 'Vimal Singh'; t...@atomide.com; svenk...@ti.com; linux- > o...@vger.kernel.org; linux-ker...@vger.kernel.org; > jarkko.lavi...@nokia.com > Subject: RE: [PATCH v3] OMAP: Fix for bus width which improves SD card's > peformance. > > > > > -Original Message- > > From: Felipe Balbi [mailto:m...@felipebalbi.com] > > Sent: Monday, April 05, 2010 11:49 AM > > To: kishore kadiyala > > Cc: Madhusudhan; Vimal Singh; t...@atomide.com; svenk...@ti.com; linux- > > o...@vger.kernel.org; linux-ker...@vger.kernel.org; > > jarkko.lavi...@nokia.com > > Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's > > peformance. > > > > Hi, > > > > On Mon, Apr 05, 2010 at 06:26:16PM +0530, kishore kadiyala wrote: > > > @@ -2091,9 +2091,9 @@ static int __init omap_hsmmc_probe(struct > > > mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | > > >MMC_CAP_WAIT_WHILE_BUSY; > > > > > > - if (mmc_slot(host).wires >= 8) > > > - mmc->caps |= MMC_CAP_8_BIT_DATA; > > > - else if (mmc_slot(host).wires >= 4) > > > + if (mmc_slot(host).wires == 8) > > > + mmc->caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); > > > + else if (mmc_slot(host).wires == 4) > > > mmc->caps |= MMC_CAP_4_BIT_DATA; > > > > I believe it would be enough to just remove the 'else', so the code > > would look like: > > > > if (mmc_slot(host).wires >= 8) > > mmc->caps |= MMC_CAP_8_BIT_DATA; > > if (mmc_slot(host).wires >= 4) > > Since the first if command already checks for the 8-bit the second check > like >= 4 is definitely not readable in my opinion. > > Functionally do you see anything wrong with this patch?? > Just to clarify my earlier comment on the patch was to resubmit like below: if (mmc_slot(host).wires == 8) mmc->caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); if (mmc_slot(host).wires == 4) mmc->caps |= MMC_CAP_4_BIT_DATA; IMHO, this should be good enough. Regards, Madhu > > mmc->caps |= MMC_CAP_4_BIT_DATA; > > > > -- > > 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 -- 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 v3] OMAP: Fix for bus width which improves SD card's peformance.
> -Original Message- > From: Felipe Balbi [mailto:m...@felipebalbi.com] > Sent: Monday, April 05, 2010 11:49 AM > To: kishore kadiyala > Cc: Madhusudhan; Vimal Singh; t...@atomide.com; svenk...@ti.com; linux- > o...@vger.kernel.org; linux-ker...@vger.kernel.org; > jarkko.lavi...@nokia.com > Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's > peformance. > > Hi, > > On Mon, Apr 05, 2010 at 06:26:16PM +0530, kishore kadiyala wrote: > > @@ -2091,9 +2091,9 @@ static int __init omap_hsmmc_probe(struct > > mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | > > MMC_CAP_WAIT_WHILE_BUSY; > > > > - if (mmc_slot(host).wires >= 8) > > - mmc->caps |= MMC_CAP_8_BIT_DATA; > > - else if (mmc_slot(host).wires >= 4) > > + if (mmc_slot(host).wires == 8) > > + mmc->caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); > > + else if (mmc_slot(host).wires == 4) > > mmc->caps |= MMC_CAP_4_BIT_DATA; > > I believe it would be enough to just remove the 'else', so the code > would look like: > > if (mmc_slot(host).wires >= 8) > mmc->caps |= MMC_CAP_8_BIT_DATA; > if (mmc_slot(host).wires >= 4) Since the first if command already checks for the 8-bit the second check like >= 4 is definitely not readable in my opinion. Functionally do you see anything wrong with this patch?? > mmc->caps |= MMC_CAP_4_BIT_DATA; > > -- > 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: USB on omap2430
On Mon, Apr 05, 2010 at 07:41:25PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, Apr 05, 2010 at 07:32:06PM +0530, Viral Mehta wrote:
> > >> static void __exit isp_exit(void)
> > >> {
> > >>
> > >>
> > >>
> > >> After adding the above code, isp1301's probe is called but that fails
> > >> before it does otg_set_transceiver()
> > >> And I am debugging further on that path.
> >
> > >ok, cool. When you get that done, please send a cleaned up
> > >diff with your signed-off-by line so it can be integrated.
> >
> > I continued debugging further. It fails during USB initialisation.
> > More specifically, in omap_otg_init() function in arch/arm/plat-omap/usb.c
> > It gives a crash dump on the first line itself
> > syscon = omap_readl(OTG_SYSCON_1) & 0x;
>
> without the crash itself, it's pretty difficult to help. It could even
> be just a missing clk_enable(). Although I believe that code shouldn't
> be running for 2430, only for 2420.
>
> Can you try the patch below:
now with patch:
diff --git a/arch/arm/plat-omap/usb.c b/arch/arm/plat-omap/usb.c
index d3bf17c..e9c6452 100644
--- a/arch/arm/plat-omap/usb.c
+++ b/arch/arm/plat-omap/usb.c
@@ -745,7 +745,7 @@ static inline void omap_1510_usb_init(struct
omap_usb_config *config) {}
void __init omap_usb_init(struct omap_usb_config *pdata)
{
- if (cpu_is_omap7xx() || cpu_is_omap16xx() || cpu_is_omap24xx())
+ if (cpu_is_omap7xx() || cpu_is_omap16xx() || cpu_is_omap242x())
omap_otg_init(pdata);
else if (cpu_is_omap15xx())
omap_1510_usb_init(pdata);
--
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 v3] OMAP: Fix for bus width which improves SD card's peformance.
Hi, On Mon, Apr 05, 2010 at 06:26:16PM +0530, kishore kadiyala wrote: > @@ -2091,9 +2091,9 @@ static int __init omap_hsmmc_probe(struct > mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | >MMC_CAP_WAIT_WHILE_BUSY; > > - if (mmc_slot(host).wires >= 8) > - mmc->caps |= MMC_CAP_8_BIT_DATA; > - else if (mmc_slot(host).wires >= 4) > + if (mmc_slot(host).wires == 8) > + mmc->caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); > + else if (mmc_slot(host).wires == 4) > mmc->caps |= MMC_CAP_4_BIT_DATA; I believe it would be enough to just remove the 'else', so the code would look like: if (mmc_slot(host).wires >= 8) mmc->caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires >= 4) mmc->caps |= MMC_CAP_4_BIT_DATA; -- 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: USB on omap2430
Hi,
On Mon, Apr 05, 2010 at 07:32:06PM +0530, Viral Mehta wrote:
> >> static void __exit isp_exit(void)
> >> {
> >>
> >>
> >>
> >> After adding the above code, isp1301's probe is called but that fails
> >> before it does otg_set_transceiver()
> >> And I am debugging further on that path.
>
> >ok, cool. When you get that done, please send a cleaned up
> >diff with your signed-off-by line so it can be integrated.
>
> I continued debugging further. It fails during USB initialisation.
> More specifically, in omap_otg_init() function in arch/arm/plat-omap/usb.c
> It gives a crash dump on the first line itself
> syscon = omap_readl(OTG_SYSCON_1) & 0x;
without the crash itself, it's pretty difficult to help. It could even
be just a missing clk_enable(). Although I believe that code shouldn't
be running for 2430, only for 2420.
Can you try the patch below:
> Apart from that, can I submit the 3 patches that we discussed earlier ?
> (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg25932.html)
> These will not make FS USB functional on OMAP2430 but these changes are
> anyway necessary.
clean those patches first. And I'd like someone else with the 2430sdp
board to test it before I add my SOB.
--
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
[PATCH v2] dma: fix scope of errata i88 upto 3430ES1.0
>From 2799506180649cbb61d24cf2b4171425b2e1fa80 Mon Sep 17 00:00:00 2001
From: Venkatraman S
Date: Mon, 5 Apr 2010 20:56:27 +0530
Subject: [PATCH] dma: fix scope of errata i88 upto 3430ES1.0
DMA errata for special end of block programming is applicable
only for OMAP2430 & OMAP3430 ES1.0.
This patch does the necessary checks before the workaround
is applied. Tested on 3430 SDP
Signed-off-by: Thara Gopinath
Signed-off-by: Venkatraman S
Reviewed-by: Shilimkar Santosh
---
>From v1, removed the redundant omap3430() check
arch/arm/plat-omap/dma.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..a9b480a 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1663,14 +1663,17 @@ int omap_stop_dma_chain_transfers(int chain_id)
channels = dma_linked_lch[chain_id].linked_dmach_q;
/*
-* DMA Errata:
-* Special programming model needed to disable DMA before end of block
+* DMA Errata: i88
+* Special programming model needed
+* to disable DMA before end of block
*/
sys_cf = dma_read(OCP_SYSCONFIG);
- l = sys_cf;
- /* Middle mode reg set no Standby */
- l &= ~((1 << 12)|(1 << 13));
- dma_write(l, OCP_SYSCONFIG);
+ if (cpu_is_omap2430() || (omap_rev() == OMAP3430_REV_ES1_0)) {
+ l = sys_cf;
+ /* Middle mode reg set no Standby */
+ l &= ~((1 << 12)|(1 << 13));
+ dma_write(l, OCP_SYSCONFIG);
+ }
for (i = 0; i < dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
@@ -1689,8 +1692,9 @@ int omap_stop_dma_chain_transfers(int chain_id)
/* Reset the Queue pointers */
OMAP_DMA_CHAIN_QINIT(chain_id);
- /* Errata - put in the old value */
- dma_write(sys_cf, OCP_SYSCONFIG);
+ /* Errata: put back the old value */
+ if (cpu_is_omap2430() || (omap_rev() == OMAP3430_REV_ES1_0))
+ dma_write(sys_cf, OCP_SYSCONFIG);
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: fix scope of errata i88 upto 3430ES1.0
On Mon, Apr 5, 2010 at 7:56 PM, Shilimkar, Santosh
wrote:
> Venkat,
>> -Original Message-
>> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of S,
>> Venkatraman
>> Sent: Friday, April 02, 2010 5:05 PM
>> To: linux-omap@vger.kernel.org
>> Cc: Gopinath, Thara; Tony Lindgren; Shilimkar, Santosh
>> Subject: [PATCH] dma: fix scope of errata i88 upto 3430ES1.0
>>
>> DMA errata for special end of block programming is applicable
>> only for OMAP2430 & OMAP3430 ES1.0.
>> This patch does the necessary checks before the workaround
>> is applied. Tested on 3430 SDP
>>
>> Signed-off-by: Thara Gopinath
>> Signed-off-by: Venkatraman S
>> ---
>> arch/arm/plat-omap/dma.c | 22 ++
>> 1 files changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
>> index 2ab224c..ef965ac 100644
>> --- a/arch/arm/plat-omap/dma.c
>> +++ b/arch/arm/plat-omap/dma.c
>> @@ -1663,14 +1663,18 @@ int omap_stop_dma_chain_transfers(int chain_id)
>> channels = dma_linked_lch[chain_id].linked_dmach_q;
>>
>> /*
>> - * DMA Errata:
>> - * Special programming model needed to disable DMA before end of block
>> + * DMA Errata: i88
>> + * Special programming model needed
>> + * to disable DMA before end of block
>> */
>> sys_cf = dma_read(OCP_SYSCONFIG);
>> - l = sys_cf;
>> - /* Middle mode reg set no Standby */
>> - l &= ~((1 << 12)|(1 << 13));
>> - dma_write(l, OCP_SYSCONFIG);
>> + if (cpu_is_omap2430() || (cpu_is_omap3430() &&
>> + omap_rev() == OMAP3430_REV_ES1_0)) {
> Since the Errata is applicable only for "omap2430" and
> "OMAP3430 ES1.0", below should be enough, isn't it ?
>
> if (cpu_is_omap2430() || omap_rev() == OMAP3430_REV_ES1_0))
Yup.. Looks simpler. I will update.
>> + l = sys_cf;
>> + /* Middle mode reg set no Standby */
>> + l &= ~((1 << 12)|(1 << 13));
>> + dma_write(l, OCP_SYSCONFIG);
>> + }
>>
>> for (i = 0; i < dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
>>
>> @@ -1689,8 +1693,10 @@ int omap_stop_dma_chain_transfers(int chain_id)
>> /* Reset the Queue pointers */
>> OMAP_DMA_CHAIN_QINIT(chain_id);
>>
>> - /* Errata - put in the old value */
>> - dma_write(sys_cf, OCP_SYSCONFIG);
>> + /* Errata: put back the old value */
>> + if (cpu_is_omap2430() || (cpu_is_omap3430() &&
>> + omap_rev() == OMAP3430_REV_ES1_0))
> Same as above comment.
>> + dma_write(sys_cf, OCP_SYSCONFIG);
>>
>> return 0;
>> }
> After fixing above two, the patch is fine with me.
Thanks, I take that as ack ? :-)
Regards,
Venkat.
--
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] MFD: TWL4030: changes for TRITON glitch fix
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, March 19, 2010 5:31 AM
To: Lesly A M
Cc: linux-omap@vger.kernel.org; Nishanth Menon; David Derrick; Samuel Ortiz
Subject: Re: [PATCH] MFD: TWL4030: changes for TRITON glitch fix
Lesly A M writes:
> Fix for TWL5030 Silicon Errata 27 & 28:
> 27 - VDD1, VDD2, may have glitches when their output value is updated.
> 28 - VDD1 and / or VDD2 DCDC clock may stop working when internal clock
> is switched from internal to external.
>
> Workaround requires the TWL DCDCs to use HFCLK instead of internal
oscillator.
> Also enable TWL watchdog before switching the osc to recover
> if the VDD1/VDD2 stop working.
>
> Fix is required for TWL5030 Silicon version less than or equal to ES1.1
> Changes are done under the macro CONFIG_TWL5030_GLITCH_FIX,
> since the IDCODE register on TWL5030 Si is not updated correctly.
>
> Updated the TWL resource settings and volt, clock setuptime.
>
> Changes taken from Nishanth Menons gaia glitch fix patch.
>
> Signed-off-by: Lesly A M
> Cc: Nishanth Menon
> Cc: David Derrick
> Cc: Samuel Ortiz
> ---
Some general comments:
Why do you need a Kconfig option for this?
The changelog says IDCODE is not updated correctly, but the code is
using detection in SW to see if the fix is required, so that should be
default behavior.
Even if SW detection is not reliable, Kconfig is not the right
approach here. Board code should simply set a flag or register
a hook if the fix is required.
This patch has failed my 15 minute rule (if I can't understand a patch
in 15 minutes, blame it on the changelog.)
I'm having troubles understanding the intended sequence of events
here. Various script pointers are being passed around and overwritten
etc., and it is not terribly clear what the outcome is. The changelog
needs some updating to clarify that. A lot of the confusion stems
from what belongs in board files and what belongs in common code.
More comments inline below...
[Lesly] Since the GAIA version checking will note correct, Kconfig option is
added if somebody wants to disable the gai_glitch_fix code during
menuconfig.
We expect the GAIA IDCODE register will be updated properly in the next Si
version.
Do you mean to say that we can add one function ptr in
twl4030_platform_data, which can updated from the board file with the
function for glitch_fix changes.
And this can be passed to twl4030_power_init() along with script_data for
executing if GAIA Si ver less_than 1.2
> This patch has dependency on:
> SmartReflex patch series from Thara.
> Update TRITON power scripts from Lesly.
>
> This patch series is based off Kevin's tree origin/pm branch.
>
> This changes are tested on OMAP3430 SDP board with:
> enable_off_mode
> voltage_off_while_idle
> sleep_while_idle (VDD1/VDD2 voltage scaling to 0v) enabled in
cpuidle and suspned path.
>
> Also tested for reboot and dvfs.
>
> arch/arm/mach-omap2/board-3430sdp.c | 40 +
> arch/arm/mach-omap2/board-zoom-peripherals.c | 40 +
> arch/arm/mach-omap2/include/mach/board-sdp.h |4 +
> arch/arm/mach-omap2/include/mach/board-zoom.h |4 +
> arch/arm/mach-omap2/twl4030-script.c | 84 +++
> arch/arm/mach-omap2/twl4030-script.h |9 ++
> arch/arm/mach-omap2/voltage.c | 10 +++
> arch/arm/mach-omap2/voltage.h |4 +
> arch/arm/plat-omap/Kconfig|7 ++
> drivers/mfd/twl4030-power.c | 106
+
> 10 files changed, 308 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
> index 4f94b6f..d174d21 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -475,6 +475,36 @@ static struct twl4030_resconfig twl4030_rconfig[] = {
> { 0, 0},
> };
>
> +#ifdef CONFIG_TWL5030_GLITCH_FIX
> +static struct twl4030_resconfig twl4030_rconfig_glitchfix[] = {
> + { .resource = RES_VPLL1, .devgroup = DEV_GRP_P1 | DEV_GRP_P3,
> + .type = 3, .type2 = 1, .remap_sleep = RES_STATE_OFF },
> + { .resource = RES_VINTANA1, .devgroup = DEV_GRP_ALL, .type = 1,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_VINTANA2, .devgroup = DEV_GRP_ALL, .type = 0,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_VINTDIG, .devgroup = DEV_GRP_ALL, .type = 1,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_VIO, .devgroup = DEV_GRP_ALL, .type = 2,
> + .type2 = 2, .remap_sleep = RES_STATE_SLEEP },
> + { .resource = RES_VDD1, .devgroup = DEV_GRP_P1 | DEV_GRP_P3,
> + .type = 4, .type2 = 1, .remap_sleep = RES_STATE_OFF },
> + { .resource = RES_VDD2, .devgroup = DEV_GRP_P1 | DEV_GRP_P3,
> + .type = 3, .type2 =
RE: [PATCH] dma: fix scope of errata i88 upto 3430ES1.0
Venkat,
> -Original Message-
> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of S,
> Venkatraman
> Sent: Friday, April 02, 2010 5:05 PM
> To: linux-omap@vger.kernel.org
> Cc: Gopinath, Thara; Tony Lindgren; Shilimkar, Santosh
> Subject: [PATCH] dma: fix scope of errata i88 upto 3430ES1.0
>
> DMA errata for special end of block programming is applicable
> only for OMAP2430 & OMAP3430 ES1.0.
> This patch does the necessary checks before the workaround
> is applied. Tested on 3430 SDP
>
> Signed-off-by: Thara Gopinath
> Signed-off-by: Venkatraman S
> ---
> arch/arm/plat-omap/dma.c | 22 ++
> 1 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 2ab224c..ef965ac 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -1663,14 +1663,18 @@ int omap_stop_dma_chain_transfers(int chain_id)
> channels = dma_linked_lch[chain_id].linked_dmach_q;
>
> /*
> - * DMA Errata:
> - * Special programming model needed to disable DMA before end of block
> + * DMA Errata: i88
> + * Special programming model needed
> + * to disable DMA before end of block
>*/
> sys_cf = dma_read(OCP_SYSCONFIG);
> - l = sys_cf;
> - /* Middle mode reg set no Standby */
> - l &= ~((1 << 12)|(1 << 13));
> - dma_write(l, OCP_SYSCONFIG);
> + if (cpu_is_omap2430() || (cpu_is_omap3430() &&
> + omap_rev() == OMAP3430_REV_ES1_0)) {
Since the Errata is applicable only for "omap2430" and
"OMAP3430 ES1.0", below should be enough, isn't it ?
if (cpu_is_omap2430() || omap_rev() == OMAP3430_REV_ES1_0))
> + l = sys_cf;
> + /* Middle mode reg set no Standby */
> + l &= ~((1 << 12)|(1 << 13));
> + dma_write(l, OCP_SYSCONFIG);
> + }
>
> for (i = 0; i < dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
>
> @@ -1689,8 +1693,10 @@ int omap_stop_dma_chain_transfers(int chain_id)
> /* Reset the Queue pointers */
> OMAP_DMA_CHAIN_QINIT(chain_id);
>
> - /* Errata - put in the old value */
> - dma_write(sys_cf, OCP_SYSCONFIG);
> + /* Errata: put back the old value */
> + if (cpu_is_omap2430() || (cpu_is_omap3430() &&
> + omap_rev() == OMAP3430_REV_ES1_0))
Same as above comment.
> + dma_write(sys_cf, OCP_SYSCONFIG);
>
> return 0;
> }
After fixing above two, the patch is fine with me.
> --
> 1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB on omap2430
Hi,
>> static void __exit isp_exit(void)
>> {
>>
>>
>>
>> After adding the above code, isp1301's probe is called but that fails
>> before it does otg_set_transceiver()
>> And I am debugging further on that path.
>ok, cool. When you get that done, please send a cleaned up
>diff with your signed-off-by line so it can be integrated.
I continued debugging further. It fails during USB initialisation.
More specifically, in omap_otg_init() function in arch/arm/plat-omap/usb.c
It gives a crash dump on the first line itself
syscon = omap_readl(OTG_SYSCON_1) & 0x;
I feel like I need to make some board (OMAP2430) specific changes to this file.
I am not able to progress further. Any pointers will be appreciated.
Apart from that, can I submit the 3 patches that we discussed earlier ?
(http://www.mail-archive.com/linux-omap@vger.kernel.org/msg25932.html)
These will not make FS USB functional on OMAP2430 but these changes are anyway
necessary.
--
Viral
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg25932.html
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
__
--
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 on omap2430
>On Fri, Mar 26, 2010 at 12:08:11PM +0100, ext Viral Mehta wrote: >>I enabled "earlyprintk" and I have copy+pasted crashdump at the end of the >>email. >> >>It is not able to get "otg_get_transceiver()" since transceiver was never set. >>OMAP2430 uses ISP1301 (grepped from SDP manual). >>It is on I2C1 bus and address 0x2D if I read the manual correctly. >isp1301 ?? there's a driver for that on drivers/usb/otg/isp1301_omap.c Again I think I should be clear on that, On OMAP2430, isp1301 transceiver is used for FS USB (or OHCI) only. For HS USB (or musb) the transceiver used is Triton T2. And currently I am debugging FS USB only. Sorry if earlier mail created confusion. -- Viral This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ -- 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/2] OMAP3: Set MPU and IVA bypass Clock Divider
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> Sripathy, Vishwanath
> Sent: Monday, April 05, 2010 5:23 PM
> To: Paul Walmsley
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
>
>
>
> > -Original Message-
> > From: Paul Walmsley [mailto:p...@pwsan.com]
> > Sent: Monday, April 05, 2010 4:44 PM
> > To: Sripathy, Vishwanath
> > Cc: linux-omap@vger.kernel.org
> > Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass
> Clock Divider
> >
> > On Mon, 5 Apr 2010, Sripathy, Vishwanath wrote:
> >
> > > > -Original Message-
> > > > From: Paul Walmsley [mailto:p...@pwsan.com]
> > > >
> > > > On Thu, 1 Apr 2010, Vishwanath BS wrote:
> > > >
> > > > > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
> b/arch/arm/mach-
> > > > omap2/clock3xxx_data.c
> > > > > index d5153b6..d8e57a6
> > > > > --- a/arch/arm/mach-omap2/clock3xxx_data.c
> > > > > +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> > > > > @@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
> > > > > sdrc_ick_p = clk_get(NULL, "sdrc_ick");
> > > > > arm_fck_p = clk_get(NULL, "arm_fck");
> > > > >
> > > > > + /* Set the bypass clock dividers for DPLL1 and DPLL2 */
> > > > > + if (cpu_is_omap3630()) {
> > > > > + clk_set_rate(&dpll1_fck, 4/2);
> > > > > + clk_set_rate(&dpll2_fck, 4/2);
> > > > > + } else {
> > > > > + clk_set_rate(&dpll1_fck, 33200/4);
> > > > > + clk_set_rate(&dpll2_fck, 33200/4);
> > > > > + }
> > > >
> > > > This code is highly OPP-specific. Why is this code needed here?
> > > > Shouldn't the code in resource34xx.c be sufficient?
> > >
> > > Code in resource34xx.c will be executed only when DVFS is
> executed.
> > > However above code makes sure that initial values of Bypass clock
> > > dividers are good. This will ensure that even if DVFS is disabled,
> > > IVA/MPU are never overclocked when they enter bypass mode.
> >
> > My point is that you don't know how the bootloader has
> configured the
> > system at the point when this code executes. You don't
> know what voltage
> > level VDD1 and VDD2 are at; you don't know what state the
> clock tree is
> > in. You only know this when you change OPPs. And the
> selection of the
> > OPP at startup is use-case dependent.
> >
> May be I can move this code to init_opp?
I have been trying to find a good place for the same myself. Though,
my reason is different. The default kernel boots with the OPP3 for
OMAP34xx; but when mpurate is used to set 720; I feel sometimes the
boot may fail if the voltage isn't right.
The voltage does stabilize when smartrelex reflex is initialized.
I was trying to move smartreflex above in the init sequence; after
i2c has been initialized.
Comments/ thoughts?
Best regards,
Sanjeev
>
> > So as far as I can tell, this code shouldn't be there. If
> you want to do
> > something like this, then you should add some generic way
> (e.g., a kernel
> > command line parameter) to set the VDD1 and VDD2 OPPs at boot.
> >
> >
> > - Paul
> --
> 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
[PATCH v3] OMAP: Fix for bus width which improves SD card's peformance.
From: Kishore Kadiyala This patch improves low speeds for SD cards. OMAP-MMC controller's can support maximum bus width of '8'. when bus width is mentioned as "8" in controller data,the SD stack will check whether bus width is "4" and if not it will set bus width to "1" and there by degrading performance. This patch fixes the issue and improves the performance of SD cards. Signed-off-by: Kishore Kadiyala Signed-off-by: Venkatraman S Acked-by: Madhusudhan Chikkature Tested-by: Jarkko Nikula --- In V3 : Updated with Madhu's comments and appended Tested by Nikula In V2 : Appended Signed-off by Venkat and Ack by Madhu Here are my experiment numbers, on a Class 6 SDHC card: Read peformance is increased by 220% Write Performance is increased by 52% drivers/mmc/host/omap_hsmmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) drivers/mmc/host/omap_hsmmc.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 83f0aff..44e79f7 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2091,9 +2091,9 @@ static int __init omap_hsmmc_probe(struct mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY; - if (mmc_slot(host).wires >= 8) - mmc->caps |= MMC_CAP_8_BIT_DATA; - else if (mmc_slot(host).wires >= 4) + if (mmc_slot(host).wires == 8) + mmc->caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); + else if (mmc_slot(host).wires == 4) mmc->caps |= MMC_CAP_4_BIT_DATA; if (mmc_slot(host).nonremovable) -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Monday, April 05, 2010 4:44 PM
> To: Sripathy, Vishwanath
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
>
> On Mon, 5 Apr 2010, Sripathy, Vishwanath wrote:
>
> > > -Original Message-
> > > From: Paul Walmsley [mailto:p...@pwsan.com]
> > >
> > > On Thu, 1 Apr 2010, Vishwanath BS wrote:
> > >
> > > > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-
> > > omap2/clock3xxx_data.c
> > > > index d5153b6..d8e57a6
> > > > --- a/arch/arm/mach-omap2/clock3xxx_data.c
> > > > +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> > > > @@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
> > > > sdrc_ick_p = clk_get(NULL, "sdrc_ick");
> > > > arm_fck_p = clk_get(NULL, "arm_fck");
> > > >
> > > > + /* Set the bypass clock dividers for DPLL1 and DPLL2 */
> > > > + if (cpu_is_omap3630()) {
> > > > + clk_set_rate(&dpll1_fck, 4/2);
> > > > + clk_set_rate(&dpll2_fck, 4/2);
> > > > + } else {
> > > > + clk_set_rate(&dpll1_fck, 33200/4);
> > > > + clk_set_rate(&dpll2_fck, 33200/4);
> > > > + }
> > >
> > > This code is highly OPP-specific. Why is this code needed here?
> > > Shouldn't the code in resource34xx.c be sufficient?
> >
> > Code in resource34xx.c will be executed only when DVFS is executed.
> > However above code makes sure that initial values of Bypass clock
> > dividers are good. This will ensure that even if DVFS is disabled,
> > IVA/MPU are never overclocked when they enter bypass mode.
>
> My point is that you don't know how the bootloader has configured the
> system at the point when this code executes. You don't know what voltage
> level VDD1 and VDD2 are at; you don't know what state the clock tree is
> in. You only know this when you change OPPs. And the selection of the
> OPP at startup is use-case dependent.
>
May be I can move this code to init_opp?
> So as far as I can tell, this code shouldn't be there. If you want to do
> something like this, then you should add some generic way (e.g., a kernel
> command line parameter) to set the VDD1 and VDD2 OPPs at boot.
>
>
> - Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: gpio: fix incorrect matching of IRQ_TYPE_EDGE_BOTH
Since IRQ_TYPE_EDGE_BOTH is defined as (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING), testing against it with a bitwise AND also matches both single-edge cases in addition to the intended both edges case. Fix it, replacing with a more accurate expression. Created and tested againts linux-2.6.34-rc3. Applicable to 2.6.33-stable as well. Signed-off-by: Janusz Krzysztofik --- --- git/arch/arm/plat-omap/gpio.c.orig 2010-04-01 17:54:17.0 +0200 +++ git/arch/arm/plat-omap/gpio.c 2010-04-04 02:34:44.0 +0200 @@ -798,7 +798,7 @@ static int _set_gpio_triggering(struct g case METHOD_MPUIO: reg += OMAP_MPUIO_GPIO_INT_EDGE; l = __raw_readl(reg); - if (trigger & IRQ_TYPE_EDGE_BOTH) + if ((trigger & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) bank->toggle_mask |= 1 << gpio; if (trigger & IRQ_TYPE_EDGE_RISING) l |= 1 << gpio; @@ -812,7 +812,7 @@ static int _set_gpio_triggering(struct g case METHOD_GPIO_1510: reg += OMAP1510_GPIO_INT_CONTROL; l = __raw_readl(reg); - if (trigger & IRQ_TYPE_EDGE_BOTH) + if ((trigger & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) bank->toggle_mask |= 1 << gpio; if (trigger & IRQ_TYPE_EDGE_RISING) l |= 1 << gpio; @@ -846,7 +846,7 @@ static int _set_gpio_triggering(struct g case METHOD_GPIO_7XX: reg += OMAP7XX_GPIO_INT_CONTROL; l = __raw_readl(reg); - if (trigger & IRQ_TYPE_EDGE_BOTH) + if ((trigger & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) bank->toggle_mask |= 1 << gpio; if (trigger & IRQ_TYPE_EDGE_RISING) l |= 1 << gpio; -- 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: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Paul, Sorry for late response. Here is the answer for some of the queries that you had posted. > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Paul Walmsley > Sent: Tuesday, January 26, 2010 11:13 AM > To: Reddy, Teerth > Cc: linux-omap@vger.kernel.org; t...@atomide.com; Kevin Hilman > Subject: RE: [PATCH] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in > SDRC after a Warm-reset > > Hello Teerth, > > On Mon, 25 Jan 2010, Reddy, Teerth wrote: > > > > From: Paul Walmsley [mailto:p...@pwsan.com] > > > > > > I wonder if this also needs to make sure that all the other system > > > initiators are mute before continuing, for the same reason cited in commit > > > 18862cbe47e37beba98f22c088fbe6fe029df889 ? I suppose that, for example, > > > if an interrupt occurs on the IVA2.2 or the DMA controller tries to access > > > the SDRC, it would hopefully only wedge those initiators and not the whole > > > chip? > > Do you think we need to take care of the system initiators if we are > > disabling all the interrupts before going for a warm reset? > > Are you disabling _all_ the interrupts, or just the MPU's interrupts? > Even if you did disable all of the system interrupts, couldn't DMA be > ongoing from/to another system initiator, independently of interrupts? We should disable all MPU interrupts. Yes there can be another initiator active in the system parallelly. However all the system initiators will recover from reset once warm reset is triggered. > > > I think this doesn't seem to hold good here. > > You may be right, but I'd like you to describe your reasoning on this > point. > > > Please let me know if you understanding is wrong. > > My concerns here are twofold: > > 1. If other system initiators are interacting with the SDRC during this > process, is there a danger that the interconnect could enter a state that > would prevent the warm reset from occurring, thus wedging the system? This should not happen since bottle neck would be L4, only initiators accessing L4 are expected to be MPU and DMA (and maybe DSP) and L4 has 4 threads. We cannot think of a blocking scenario. > > 2. When the warm-reset occurs, will it also completely reset other > initiators that may be wedged waiting for some SDRC access to complete? Yes Vishwa > > > - Paul > -- > 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
RE: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
On Mon, 5 Apr 2010, Sripathy, Vishwanath wrote:
> > -Original Message-
> > From: Paul Walmsley [mailto:p...@pwsan.com]
> >
> > On Thu, 1 Apr 2010, Vishwanath BS wrote:
> >
> > > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-
> > omap2/clock3xxx_data.c
> > > index d5153b6..d8e57a6
> > > --- a/arch/arm/mach-omap2/clock3xxx_data.c
> > > +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> > > @@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
> > > sdrc_ick_p = clk_get(NULL, "sdrc_ick");
> > > arm_fck_p = clk_get(NULL, "arm_fck");
> > >
> > > + /* Set the bypass clock dividers for DPLL1 and DPLL2 */
> > > + if (cpu_is_omap3630()) {
> > > + clk_set_rate(&dpll1_fck, 4/2);
> > > + clk_set_rate(&dpll2_fck, 4/2);
> > > + } else {
> > > + clk_set_rate(&dpll1_fck, 33200/4);
> > > + clk_set_rate(&dpll2_fck, 33200/4);
> > > + }
> >
> > This code is highly OPP-specific. Why is this code needed here?
> > Shouldn't the code in resource34xx.c be sufficient?
>
> Code in resource34xx.c will be executed only when DVFS is executed.
> However above code makes sure that initial values of Bypass clock
> dividers are good. This will ensure that even if DVFS is disabled,
> IVA/MPU are never overclocked when they enter bypass mode.
My point is that you don't know how the bootloader has configured the
system at the point when this code executes. You don't know what voltage
level VDD1 and VDD2 are at; you don't know what state the clock tree is
in. You only know this when you change OPPs. And the selection of the
OPP at startup is use-case dependent.
So as far as I can tell, this code shouldn't be there. If you want to do
something like this, then you should add some generic way (e.g., a kernel
command line parameter) to set the VDD1 and VDD2 OPPs at boot.
- Paul
--
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/2] OMAP3: Set MPU and IVA bypass Clock Divider
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Thursday, April 01, 2010 2:57 PM
> To: Sripathy, Vishwanath
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCHV3 1/2] OMAP3: Set MPU and IVA bypass Clock Divider
>
> On Thu, 1 Apr 2010, Vishwanath BS wrote:
>
> > DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM
> > UCs running DSP codec was earlier restricted as DSP crashed.
> > The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
> > The solution is to make sure DPLL1/DPLL2 bypass clock is always less
> > than maximum supported frequency for the specific OPP.
> >
> > Signed-off-by: Vishwanath BS
> > ---
> > arch/arm/mach-omap2/clock3xxx_data.c | 12
> > 1 files changed, 12 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-
> omap2/clock3xxx_data.c
> > index d5153b6..d8e57a6
> > --- a/arch/arm/mach-omap2/clock3xxx_data.c
> > +++ b/arch/arm/mach-omap2/clock3xxx_data.c
>
> ...
>
> > @@ -3597,5 +3601,13 @@ int __init omap3xxx_clk_init(void)
> > sdrc_ick_p = clk_get(NULL, "sdrc_ick");
> > arm_fck_p = clk_get(NULL, "arm_fck");
> >
> > + /* Set the bypass clock dividers for DPLL1 and DPLL2 */
> > + if (cpu_is_omap3630()) {
> > + clk_set_rate(&dpll1_fck, 4/2);
> > + clk_set_rate(&dpll2_fck, 4/2);
> > + } else {
> > + clk_set_rate(&dpll1_fck, 33200/4);
> > + clk_set_rate(&dpll2_fck, 33200/4);
> > + }
>
> This code is highly OPP-specific. Why is this code needed here?
> Shouldn't the code in resource34xx.c be sufficient?
Code in resource34xx.c will be executed only when DVFS is executed. However
above code makes sure that initial values of Bypass clock dividers are good.
This will ensure that even if DVFS is disabled, IVA/MPU are never overclocked
when they enter bypass mode.
Regards
Vishwa
>
>
> - Paul
--
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
