Re: OMAP 3530 McBSP Frame Sync errors
On Thu, Sep 9, 2010 at 6:56 PM, Gary Thomas g...@mlbassoc.com wrote: I'm trying to use McBSP4 with an external CODEC which is a slave device (i.e. the OMAP generates the Frame Sync pulses) In this mode, the BSP is purely the master of these signals. What can it possibly mean to get Frame Sync errors in this case (I'm reading from the external CODEC)? FYI, my registers look like this: PCR0: 0x0f0f RCR1: 0x0040, RCR2: 0x8041 XCR1: 0x0040, XCR2: 0x8041 SRGR1: 0x0f07, SRGR2: 0x101f Any ideas or help? Have you set the right McBSP source clock? It's in DEVCONF1/2 registers. -- Gary Thomas | Consulting for the MLB Associates | Embedded world -- 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: OMAP 3530 McBSP Frame Sync errors
On 09/13/2010 03:07 AM, Grazvydas Ignotas wrote: On Thu, Sep 9, 2010 at 6:56 PM, Gary Thomasg...@mlbassoc.com wrote: I'm trying to use McBSP4 with an external CODEC which is a slave device (i.e. the OMAP generates the Frame Sync pulses) In this mode, the BSP is purely the master of these signals. What can it possibly mean to get Frame Sync errors in this case (I'm reading from the external CODEC)? FYI, my registers look like this: PCR0: 0x0f0f RCR1: 0x0040, RCR2: 0x8041 XCR1: 0x0040, XCR2: 0x8041 SRGR1: 0x0f07, SRGR2: 0x101f Any ideas or help? Have you set the right McBSP source clock? It's in DEVCONF1/2 registers. Yes, the channel works fine, but I only occasionally get errant Frame Sync errors. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over
Hello.
tom.leim...@gmail.com wrote:
From: Ming Lei tom.leim...@gmail.com
Complete the current request only if the data transfer is over.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
---
drivers/usb/musb/musb_gadget.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index f3ee04f..fa826f9 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -501,14 +501,14 @@ void musb_g_tx(struct musb *musb, u8 epnum)
request-zero = 0;
}
- /* ... or if not, then complete it. */
- musb_g_giveback(musb_ep, request, 0);
-
- request = musb_ep-desc ? next_request(musb_ep) : NULL;
- if (!request) {
- DBG(4, %s idle now\n,
- musb_ep-end_point.name);
- return;
+ if (request-actual == request-length) {
But why not modify the conditional above all that code, just excluding
'is_dma' from it. This conditional already includes (request-actual ==
request-length) check. Please recast this patch.
+ musb_g_giveback(musb_ep, request, 0);
+ request = musb_ep-desc ? next_request(musb_ep)
: NULL;
+ if (!request) {
+ DBG(4, %s idle now\n,
+ musb_ep-end_point.name);
+ return;
+ }
}
}
WBR, Sergei
--
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
LCD on Zoom2 dev board with DSS
Hi all, I'm working on a zoom2 dev board (omap34x-II MDP). There is my actual config : I've built kernel 2.6.35 from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git and then applied the following patchs : [PATCH 1/2 V7] OMAP: ZOOM2/3SDP3630: Add display board file for zoom boards http://marc.info/?l=linux-omapm=127445506720934w=2 [PATCH 2/2 V7] OMAP: ZOOM2/3SDP3630: Add display board file for zoom boards http://marc.info/?l=linux-omapm=127445522921326w=2 [PATCH V6] OMAP: DSS: Add NEC NL8048HL11-01B display panel http://marc.info/?l=linux-omapm=127445535621669w=2 Finally I've enabled DSS and lcd NEC_NL8048HL11 in kernel config file. At this time the kernel boots well, and my LCD backlight turns on but I can't see TUX while booting, and I can't draw anything after logging in. I've checked, the framebuffer device is present and configured with size of 800x480. I've played with sys filesystem like on this wiki, but nothing happened: http://www.omappedia.org/wiki/Bootargs_for_enabling_display To enable DSS at boot time, I passed following boot options: vram=10M omapdss.def_disp=lcd Perhaps I've missed something? Thank you in advance. --- Yanick -- 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 on Zoom2 dev board with DSS
Hi, On Mon, Sep 13, 2010 at 07:43:27AM -0500, Yanick Saugy wrote: Finally I've enabled DSS and lcd NEC_NL8048HL11 in kernel config file. At this time the kernel boots well, and my LCD backlight turns on but I can't see TUX while booting, and I can't draw anything after logging to see tux you need to enable CONFIG_LOGO_LINUX_CLUT224 at least. Then you also might want to enable the framebuffer console, just to get some output on the screen. -- 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
Generic PWM kernel driver (with support for OMAP3)
Bill, I was looking at your PWM patch set[1] and it seems this has been pending for a long time (since February). Do you know if this is any closer to being accepted, ie. have you done any additional work or has it been accepted to some maintainer's tree? There was a Google Summer of Code project for BeagleBoard.org[2] to put PWM code into the kernel[3], but the student (Varun, copied) has not yet submitted his patches to the linux-embedded mailing list yet and he wasn't aware of your patch set when he began his work. His patch set[4] also misses some of the features from your patch set. The student's work seems to be based on Scott's work[5] and branched from his tree on github[6]. Have you released an updated patch series to address the feedback comments or shall we introduce a new set? Regards, Jason Kridner http://beagleboard.org/twitter [1] https://patchwork.kernel.org/patch/76229/ [2] http://beagleboard.org/gsoc [3] http://elinux.org/BeagleBoard/GSoC/2010_Projects/Pulse_Width_Modulation [4] http://github.com/neo01124/omap3-pwm [5] http://www.jumpnowtek.com/index.php?option=com_contentview=articleid=56Itemid=63 [6] http://github.com/scottellis/omap3-pwm -- 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 00/10] split out emac cpdma and mdio for reuse
Hi Caglar, [...] Unfortunately emac driver is not stable after this series. I face lock-ups time to time, followed by attached kernel trace. Could you elaborate on your test scenario so that I can try and reproduce the problem at my end? Also, did you have the contents of my commit stack in this particular kernel build? Assuming that the DMA got stuck at some point leading up to the transmit timeout, any ideas as to why a host error was not thrown? To help debug, I'll post out a set of patches that dump out the MAC (and DMA) registers on timeout. That should give us some visibility into the problem. [ 1651.44] nfs: server 192.168.2.34 not responding, still trying [ 1859.01] [ cut here ] [ 1859.01] WARNING: at net/sched/sch_generic.c:258 dev_watchdog+0x184/0x294() [ 1859.02] NETDEV WATCHDOG: eth0 (davinci_emac): transmit queue 0 timed out [...] Regards Cyril. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over
2010/9/13 Sergei Shtylyov sshtyl...@mvista.com: But why not modify the conditional above all that code, just excluding 'is_dma' from it. This conditional already includes (request-actual == request-length) check. Please recast this patch. The two condition is OR relation, not and, so we can't exclude 'is_dma' simply. Anyway, the change is not wrong, right? thanks, -- Lei Ming -- 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: Suspend to RAM broken on BeagleBoard ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Fri, 10 Sep 2010 14:54:23 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: It's the CPUfreq driver that's failing to suspend. Ok. Yes, CPUfreq is not supported in l-o master or pm-core (only in the full pm branch.) If you Kconfig out CPUfreq, this failure will go away. Aah, yes, I forgot about this. I know it's temporary, but wouldn't it be good to disable CPUfreq in omap3_defconfig in this case ? Yes. BTW, I'm now seeing: [ 37.830596] Powerdomain (core_pwrdm) didn't enter target state 1 [ 37.830627] Powerdomain (dss_pwrdm) didn't enter target state 1 when the system is woken up. Looks like DSS has not been initialized, so is not hitting RET. Do you have the DSS driver enabled and built-in? Without this (and until we have DSS converted to hwmod) the DSS HW is not in a state that can hit the low power mode. If the DSS driver is allowed to initialize, even without a panel, it should set the DSS HW in a state that will then allow RET. 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] OMAP2: Add pm_bus.c file for OMAP2 architecture
Varadarajan, Charulatha ch...@ti.com writes: This patch adds pm_bus.o for OMAP2 architecture which is required while using PM runtime APIs on OMAP2. This patch series is created on origin/pm-core and is tested on 2430 SDP board (with watchdog and GPIO patches using PM runtime APIs. These patches would be sent to LO mailing list soon). Signed-off-by: Charulatha V ch...@ti.com Thanks, will merge into runtime PM core before final version is posted. Kevin --- arch/arm/mach-omap2/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 56133d4..a88b75a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -51,7 +51,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= sdrc2xxx.o # Power Management ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o -obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o +obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o pm_bus.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o -- 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/7] omap4: Fixes, hacks for es2.0
[snip] [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/omap4-for-tony My boot log: http://paste.ubuntu.com/491645/ [Ghorai] can you use this bootargs? setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M console=ttyS2,115200n8 And here is the log from my setup. [2.493194] Waiting for root device /dev/mmcblk0p2... [2.502960] mmc0: host does not support reading read-only switch. assuming write-enable. [2.523895] mmc0: new high speed SDHC card at address e1ed [2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB [2.539550] mmcblk0: p1 p2 [2.607360] EXT3-fs: barriers not enabled Using x-loader from http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and upstream u-boot. [Ghorai] can you try with this x-loader https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhODgtN2QzNjUwMzBkNDI2hl=en In the mean time I will try with yours! Cheers, -- Ricardo Salveti de Araujo -- 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
[v4 0/6] OMAP: WDT: Implement WDT in hwmod way
Series of patches to port watchdog module to use hwmod and omap_device apis for OMAP2plus chips. For this hwmod data structures are poulated. This patch series also implements watchdog module to use PM runtime APIs. This patch series is created on origin/pm-core and are tested on OMAP2430, OMAP44430, OMAP3430 SDP boards and zoom3 board. Also verified that this patch series does not break the OMAP1 build. This patch series is dependent on the following patch for testing on OMAP2: https://patchwork.kernel.org/patch/174172/ Version History: --- Version v4: *Implement hwmod adapdation first and then PM runtime adaptation as two different patches in the series *Remove inclusion of omap_device.h in the driver file. Version v3: *Fix Minor comments like renaming omap1 watchdog structures with an omap1_ prefix Some of the v3 links: https://patchwork.kernel.org/patch/119698/ https://patchwork.kernel.org/patch/119696/ Version v2: *Rebase to latest kernel Some of the v2 links: http://www.spinics.net/lists/linux-omap/msg34741.html http://www.spinics.net/lists/linux-omap/msg34673.html Version v1: *Initial series Some of the v1 links: http://www.spinics.net/lists/linux-omap/msg30628.html http://www.spinics.net/lists/linux-omap/msg30625.html Benoit Cousson (1): OMAP4: hwmod data: Add watchdog timer Varadarajan, Charulatha (5): OMAP3: hwmod data: Add watchdog timer OMAP2420: hwmod data: Add watchdog timer OMAP2430: hwmod data: Add watchdog timer OMAP2PLUS: WDT: use omap_device_build for device registration OMAP: WDT: Use PM runtime APIs instead of clk FW APIs arch/arm/mach-omap2/omap_hwmod_2420_data.c | 59 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 59 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 61 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 68 arch/arm/mach-omap2/prcm-common.h |4 ++ arch/arm/plat-omap/devices.c | 64 ++ drivers/watchdog/omap_wdt.c| 57 +-- 7 files changed, 317 insertions(+), 55 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
[v4 1/6] OMAP3: hwmod data: Add watchdog timer
Add watchdog timer hwmod data for OMAP3 chip
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 61
arch/arm/mach-omap2/prcm-common.h |4 ++
2 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..a9812a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -36,6 +36,7 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
+static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -197,6 +198,65 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
};
+/* WDTIMER2 - L4_WKUP interface */
+static struct omap_hwmod_addr_space omap3xxx_wd_timer2_addrs[] = {
+ {
+ .pa_start = 0x48314000,
+ .pa_end = 0x4831407f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__wd_timer2 = {
+ .master = omap3xxx_l4_wkup_hwmod,
+ .slave = omap3xxx_wd_timer2_hwmod,
+ .clk= wdt2_ick,
+ .addr = omap3xxx_wd_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* WDTIMER common */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_wd_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_wd_timer_hwmod_class = {
+ .name = wd_timer,
+ .sysc = omap3xxx_wd_timer_sysc,
+};
+
+/* WDTIMER2 */
+static struct omap_hwmod_ocp_if *omap3xxx_wd_timer2_slaves[] = {
+ omap3xxx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap3xxx_wd_timer2_hwmod = {
+ .name = wd_timer2,
+ .class = omap3xxx_wd_timer_hwmod_class,
+ .main_clk = wdt2_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_WDT2_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_EN_WDT2_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_wd_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -204,6 +264,7 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_wkup_hwmod,
omap3xxx_mpu_hwmod,
omap3xxx_iva_hwmod,
+ omap3xxx_wd_timer2_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 995b7ed..e190c64 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -237,6 +237,8 @@
#define OMAP24XX_ST_USB_MASK (1 0)
/* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */
+#define OMAP24XX_EN_WDT2_SHIFT 3
+#define OMAP24XX_EN_WDT2_MASK (1 3)
#define OMAP24XX_EN_GPIOS_SHIFT2
#define OMAP24XX_EN_GPIOS_MASK (1 2)
#define OMAP24XX_EN_GPT1_SHIFT 0
@@ -344,6 +346,8 @@
#define OMAP3430_ST_D2D_MASK (1 3)
/* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */
+#define OMAP3430_EN_WDT2_SHIFT 5
+#define OMAP3430_EN_WDT2_MASK (1 5)
#define OMAP3430_EN_GPIO1_MASK (1 3)
#define OMAP3430_EN_GPIO1_SHIFT3
#define OMAP3430_EN_GPT12_MASK (1 1)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v4 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings instead of using
clock FW APIs.
Signed-off-by: Charulatha V ch...@ti.com
---
drivers/watchdog/omap_wdt.c | 57 --
1 files changed, 22 insertions(+), 35 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 76b58ab..34bf435 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -38,11 +38,11 @@
#include linux/err.h
#include linux/platform_device.h
#include linux/moduleparam.h
-#include linux/clk.h
#include linux/bitops.h
#include linux/io.h
#include linux/uaccess.h
#include linux/slab.h
+#include linux/pm_runtime.h
#include mach/hardware.h
#include plat/prcm.h
@@ -61,8 +61,6 @@ struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
int omap_wdt_users;
- struct clk *ick;
- struct clk *fck;
struct resource *mem;
struct miscdevice omap_wdt_miscdev;
};
@@ -146,8 +144,7 @@ static int omap_wdt_open(struct inode *inode, struct file
*file)
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
return -EBUSY;
- clk_enable(wdev-ick);/* Enable the interface clock */
- clk_enable(wdev-fck);/* Enable the functional clock */
+ pm_runtime_get_sync(wdev-dev);
/* initialize prescaler */
while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
@@ -177,8 +174,7 @@ static int omap_wdt_release(struct inode *inode, struct
file *file)
omap_wdt_disable(wdev);
- clk_disable(wdev-ick);
- clk_disable(wdev-fck);
+ pm_runtime_put_sync(wdev-dev);
#else
printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
#endif
@@ -260,6 +256,21 @@ static const struct file_operations omap_wdt_fops = {
.release = omap_wdt_release,
};
+static int wdt_runtime_suspend(struct device *dev)
+{
+ return 0;
+}
+
+static int wdt_runtime_resume(struct device *dev)
+{
+ return 0;
+}
+
+static const struct dev_pm_ops gpio_pm_ops = {
+ .runtime_suspend = wdt_runtime_suspend,
+ .runtime_resume = wdt_runtime_resume,
+};
+
static int __devinit omap_wdt_probe(struct platform_device *pdev)
{
struct resource *res, *mem;
@@ -292,19 +303,7 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
wdev-omap_wdt_users = 0;
wdev-mem = mem;
-
- wdev-ick = clk_get(pdev-dev, ick);
- if (IS_ERR(wdev-ick)) {
- ret = PTR_ERR(wdev-ick);
- wdev-ick = NULL;
- goto err_clk;
- }
- wdev-fck = clk_get(pdev-dev, fck);
- if (IS_ERR(wdev-fck)) {
- ret = PTR_ERR(wdev-fck);
- wdev-fck = NULL;
- goto err_clk;
- }
+ wdev-dev = pdev-dev;
wdev-base = ioremap(res-start, resource_size(res));
if (!wdev-base) {
@@ -314,8 +313,8 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, wdev);
- clk_enable(wdev-ick);
- clk_enable(wdev-fck);
+ pm_runtime_enable(wdev-dev);
+ pm_runtime_get_sync(wdev-dev);
omap_wdt_disable(wdev);
omap_wdt_adjust_timeout(timer_margin);
@@ -333,11 +332,7 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
__raw_readl(wdev-base + OMAP_WATCHDOG_REV) 0xFF,
timer_margin);
- /* autogate OCP interface clock */
- __raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG);
-
- clk_disable(wdev-ick);
- clk_disable(wdev-fck);
+ pm_runtime_put_sync(wdev-dev);
omap_wdt_dev = pdev;
@@ -349,12 +344,6 @@ err_misc:
err_ioremap:
wdev-base = NULL;
-
-err_clk:
- if (wdev-ick)
- clk_put(wdev-ick);
- if (wdev-fck)
- clk_put(wdev-fck);
kfree(wdev);
err_kzalloc:
@@ -386,8 +375,6 @@ static int __devexit omap_wdt_remove(struct platform_device
*pdev)
release_mem_region(res-start, resource_size(res));
platform_set_drvdata(pdev, NULL);
- clk_put(wdev-ick);
- clk_put(wdev-fck);
iounmap(wdev-base);
kfree(wdev);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
Hi Caglar, [...] Assuming that the DMA got stuck at some point leading up to the transmit timeout, any ideas as to why a host error was not thrown? To help debug, I'll post out a set of patches that dump out the MAC (and DMA) registers on timeout. That should give us some visibility into the problem. I have posted a couple of additional patches for this on [1]. Would you mind giving these a quick try? The register dumps should prove useful in figuring this out. Regards Cyril. [1] http://arago-project.org/git/people/?p=cyril/linux-tnetv107x.git;a=shortlog;h=refs/heads/emac-cpdma-mdio-fixes -- 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: Suspend to RAM broken on BeagleBoard ?
I have zero knowledge of DSS, but shouldn't the kernel be able to suspend properly even if the DSS driver is disabled ? But maybe it's too complicated to have the DSS init sequence required to allow the system to hit RET outside the DSS driver. Thoughts ? I'm not sure if it's supposed to work from reset state but there are chances DSS is left running by your bootloader. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over
Hello. I wrote: But why not modify the conditional above all that code, just excluding 'is_dma' from it. This conditional already includes (request-actual == request-length) check. Please recast this patch. The two condition is OR relation, not and, so we can't exclude 'is_dma' simply. Yes, we can. You're clearly handling only the DMA case with your added check, the PIO case was already handled. Anyway, the change is not wrong, right? Not wrong, but the check is duplicate. Oops, I've been too fast and haven't realized that the check done here _is_ actually wrong. It causes ZLP send to trigger too fast in the DMA case. So please fix this patch. Felipe, please drop it for now. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0
On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On ES2.0 the L2 cache init parameter ineeds to be changed to take care of cache size. The cache size is 1MB on ES2.0 vs 512KB on ES1.0 This patch fixes the init parameter to update the same using dynamic cpu version check Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap4-common.c | 5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 13dc979..2b32229 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -64,7 +64,10 @@ static int __init omap_l2_cache_init(void) * 32KB way size, 16-way associativity, * parity disabled */ - l2x0_init(l2cache_base, 0x0e05, 0xcfff); + if (omap_rev() == OMAP4430_REV_ES2_0) + l2x0_init(l2cache_base, 0x0e07, 0xcfff); + else + l2x0_init(l2cache_base, 0x0e05, 0xcfff); It's probably better to invert this check - you need 512 kB on ES1 alone, but ES2 and newer will need more. You need the exception only for the ES1 case. (else you will end up patching this section again with newer revisions as well). - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0
-Original Message- From: Gadiyar, Anand Sent: Monday, September 13, 2010 9:58 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com Subject: Re: [PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0 On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On ES2.0 the L2 cache init parameter ineeds to be changed to take care of cache size. The cache size is 1MB on ES2.0 vs 512KB on ES1.0 This patch fixes the init parameter to update the same using dynamic cpu version check Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap4-common.c | 5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach- omap2/omap4-common.c index 13dc979..2b32229 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -64,7 +64,10 @@ static int __init omap_l2_cache_init(void) * 32KB way size, 16-way associativity, * parity disabled */ - l2x0_init(l2cache_base, 0x0e05, 0xcfff); + if (omap_rev() == OMAP4430_REV_ES2_0) + l2x0_init(l2cache_base, 0x0e07, 0xcfff); + else + l2x0_init(l2cache_base, 0x0e05, 0xcfff); It's probably better to invert this check - you need 512 kB on ES1 alone, but ES2 and newer will need more. You need the exception only for the ES1 case. (else you will end up patching this section again with newer revisions as well). Good point -- 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 00/10] split out emac cpdma and mdio for reuse
On Monday 13 September 2010 05:09:15 pm Cyril Chemparathy wrote: Hi Caglar, [...] Unfortunately emac driver is not stable after this series. I face lock-ups time to time, followed by attached kernel trace. Could you elaborate on your test scenario so that I can try and reproduce the problem at my end? Also, did you have the contents of my commit stack in this particular kernel build? Ooops! I didn't noticed your commits till you noted, I was working with DaVinci head. Applying patches in your tree solves all my problems and all my use cases are working now. However, I just barely tested them. To make myself forgiven here are my 'netperf' numbers before and after your patches applied: TCP_STREAM: 54.64 Mbit vs 52.84 Mbit UDP_STREAM: 96.27 Mbit vs 96.22 Mbit Regards, Caglar Assuming that the DMA got stuck at some point leading up to the transmit timeout, any ideas as to why a host error was not thrown? To help debug, I'll post out a set of patches that dump out the MAC (and DMA) registers on timeout. That should give us some visibility into the problem. [ 1651.44] nfs: server 192.168.2.34 not responding, still trying [ 1859.01] [ cut here ] [ 1859.01] WARNING: at net/sched/sch_generic.c:258 dev_watchdog+0x184/0x294() [ 1859.02] NETDEV WATCHDOG: eth0 (davinci_emac): transmit queue 0 timed out [...] Regards Cyril. -- 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/9] net: davinci_emac: allow forced 100/full via phy_id
With this patch, phy_id can be one of the following:
1) NULL : use the first phy on the bus,
2) : force to 100/full, no mdio control
3) bus:addr : use the specified bus and phy
The ability to force 100/full is necessary on some platforms (e.g. da830 evm),
where an on-board switch may be connected on the emac mii.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
drivers/net/davinci_emac.c |2 +-
include/linux/davinci_emac.h |7 +++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 525b84c..363c970 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1566,7 +1566,7 @@ static int emac_dev_open(struct net_device *ndev)
priv-phy_id = dev_name(phy);
}
- if (priv-phy_id) {
+ if (priv-phy_id *priv-phy_id) {
priv-phydev = phy_connect(ndev, priv-phy_id,
emac_adjust_link, 0,
PHY_INTERFACE_MODE_MII);
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 7508e49..9ae9ff0 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -25,6 +25,13 @@ struct emac_platform_data {
u32 ctrl_ram_offset;
u32 hw_ram_addr;
u32 ctrl_ram_size;
+
+ /*
+* phy_id can be one of the following:
+* - NULL : use the first phy on the bus,
+* -: force to 100/full, no mdio control
+* - bus:addr : use the specified bus and phy
+*/
const char *phy_id;
u8 rmii_en;
u8 version;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] davinci: specify phy_id rather than auto-detect
The cpdma/mdio refactoring incorrectly defaulted to using the first phy
detected on the platform. Although auto detection works on most sane
platforms, it can prove to be problematic on some.
For example, the da830/omap-l137 evm has an on-board switch that always
connects 100/full. Consequently, normal phy auto-detection does not work
on this platform.
Rather than risk breaking other boards, this patch reverts to using hard-coded
phy ids on platforms that did so earlier.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
arch/arm/mach-davinci/board-da830-evm.c|2 ++
arch/arm/mach-davinci/board-da850-evm.c|3 +++
arch/arm/mach-davinci/board-dm365-evm.c|4
arch/arm/mach-davinci/board-dm644x-evm.c |3 +++
arch/arm/mach-davinci/board-dm646x-evm.c |5 +
arch/arm/mach-davinci/board-mityomapl138.c |3 +++
arch/arm/mach-davinci/board-neuros-osd2.c |4
arch/arm/mach-davinci/board-sffsdr.c |4
8 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 2613324..1bb89d3 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -31,6 +31,7 @@
#include mach/usb.h
#include mach/aemif.h
+#define DA830_EVM_PHY_ID
/*
* USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4].
*/
@@ -556,6 +557,7 @@ static __init void da830_evm_init(void)
da830_evm_usb_init();
soc_info-emac_pdata-rmii_en = 1;
+ soc_info-emac_pdata-phy_id = DA830_EVM_PHY_ID;
ret = davinci_cfg_reg_list(da830_cpgmac_pins);
if (ret)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 9d4dfcb..5e435b0 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -38,6 +38,7 @@
#include mach/mux.h
#include mach/aemif.h
+#define DA850_EVM_PHY_ID 0:00
#define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8)
#define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15)
@@ -675,6 +676,8 @@ static int __init da850_evm_config_emac(void)
/* Enable/Disable MII MDIO clock */
gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, rmii_en);
+ soc_info-emac_pdata-phy_id = DA850_EVM_PHY_ID;
+
ret = da8xx_register_emac();
if (ret)
pr_warning(da850_evm_init: emac registration failed: %d\n,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f697914..86d9abc 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -54,6 +54,7 @@ static inline int have_tvp7002(void)
return 0;
}
+#define DM365_EVM_PHY_ID 0:01
/*
* A MAX-II CPLD is used for various board control functions.
*/
@@ -527,12 +528,15 @@ fail:
/* externally mux MMC1/ENET/AIC33 to imager */
mux |= BIT(6) | BIT(5) | BIT(3);
} else {
+ struct davinci_soc_info *soc_info = davinci_soc_info;
+
/* we can use MMC1 ... */
dm365evm_mmc_configure();
davinci_setup_mmc(1, dm365evm_mmc_config);
/* ... and ENET ... */
dm365evm_emac_configure();
+ soc_info-emac_pdata-phy_id = DM365_EVM_PHY_ID;
resets = ~BIT(3);
/* ... and AIC33 */
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index c86bf23..44a2f0a 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -39,6 +39,7 @@
#include mach/usb.h
#include mach/aemif.h
+#define DM644X_EVM_PHY_ID 0:01
#define LXT971_PHY_ID (0x001378e2)
#define LXT971_PHY_MASK(0xfff0)
@@ -669,6 +670,7 @@ static int davinci_phy_fixup(struct phy_device *phydev)
static __init void davinci_evm_init(void)
{
struct clk *aemif_clk;
+ struct davinci_soc_info *soc_info = davinci_soc_info;
aemif_clk = clk_get(NULL, aemif);
clk_enable(aemif_clk);
@@ -703,6 +705,7 @@ static __init void davinci_evm_init(void)
davinci_serial_init(uart_config);
dm644x_init_asp(dm644x_evm_snd_data);
+ soc_info-emac_pdata-phy_id = DM644X_EVM_PHY_ID;
/* Register the fixup for PHY on DaVinci */
phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,
davinci_phy_fixup);
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 3f34221..67669bb 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -729,6 +729,7 @@ static struct
[PATCH 4/9] net: davinci_emac: fix rx error handling
This patch adds the following fixes to the emac receive handler:
1. WARN_ON during interface shutdown.
Although harmless, these complaints were quite disconcerting. With this
patch, the receive handler explicitly checks for the shutdown condition, in
which case is bails quietly.
2. Update rx_error stats on dma receive error
3. Rate limit error messages on buffer allocation failures
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
drivers/net/davinci_emac.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 363c970..9e866ae 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1002,13 +1002,22 @@ static void emac_rx_handler(void *token, int len, int
status)
struct sk_buff *skb = token;
struct net_device *ndev = skb-dev;
struct emac_priv*priv = netdev_priv(ndev);
+ struct device *emac_dev = ndev-dev;
int ret;
+ /* free and bail if we are shutting down */
+ if (unlikely(!netif_running(ndev))) {
+ dev_kfree_skb_any(skb);
+ return;
+ }
+
+ /* recycle on recieve error */
if (status 0) {
- /* error */
+ ndev-stats.rx_errors++;
goto recycle;
}
+ /* feed received packet up the stack */
skb_put(skb, len);
skb-protocol = eth_type_trans(skb, ndev);
netif_receive_skb(skb);
@@ -1017,13 +1026,17 @@ static void emac_rx_handler(void *token, int len, int
status)
/* alloc a new packet for receive */
skb = emac_rx_alloc(priv);
+ if (!skb) {
+ if (netif_msg_rx_err(priv) net_ratelimit())
+ dev_err(emac_dev, failed rx buffer alloc\n);
+ return;
+ }
recycle:
- if (skb) {
- ret = cpdma_chan_submit(priv-rxchan, skb, skb-data,
- skb_tailroom(skb), GFP_KERNEL);
- WARN_ON(ret 0);
- }
+ ret = cpdma_chan_submit(priv-rxchan, skb, skb-data,
+ skb_tailroom(skb), GFP_KERNEL);
+ if (WARN_ON(ret 0))
+ dev_kfree_skb_any(skb);
}
static void emac_tx_handler(void *token, int len, int status)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] post cpdma/mdio refactoring fixes
This series consists of fixes for issues found during broader testing of the davinci cpdma/mdio separation series. The fixes included here are: 1. Ability to force 100/full rather than auto-detect phy. This is necessary for the external switch on the da830 evm platform 2. Fix end-of-queue requeue to include checks at submission time (in addition to pre-existing completion time checks). 3. Cleanups to rx path error handling. This prevents unnecessary stack dumps for perfectly legal situations. 4. Work around for emac-soft-reset tie-up to mdio controller. This affects all da8xx family devices (and possibly am35xx as well). 5. Reworked hard-coded scan-time estimate to use a more accurate calculated number instead. 6. Code to generate cpdma register dumps, useful during debug. Many thanks to Mike and Caglar for patiently working with me through these issues, I've taken the liberty of adding their sign offs. Cyril Chemparathy (9): net: davinci_emac: allow forced 100/full via phy_id davinci: specify phy_id rather than auto-detect net: davinci_cpdma: requeue on early end-of-queue net: davinci_emac: fix rx error handling net: davinci_mdio: separate out controller reset net: davinci_mdio: use calculated bus access times net: davinci_mdio: work around emac soft-reset during i/o net: davinci_cpdma: add register dump routines net: davinci_emac: extended register dumps on tx timeout arch/arm/mach-davinci/board-da830-evm.c|2 + arch/arm/mach-davinci/board-da850-evm.c|3 + arch/arm/mach-davinci/board-dm365-evm.c|4 + arch/arm/mach-davinci/board-dm644x-evm.c |3 + arch/arm/mach-davinci/board-dm646x-evm.c |5 + arch/arm/mach-davinci/board-mityomapl138.c |3 + arch/arm/mach-davinci/board-neuros-osd2.c |4 + arch/arm/mach-davinci/board-sffsdr.c |4 + drivers/net/davinci_cpdma.c| 132 ++- drivers/net/davinci_cpdma.h|3 + drivers/net/davinci_emac.c | 31 - drivers/net/davinci_mdio.c | 195 include/linux/davinci_emac.h |7 + 13 files changed, 334 insertions(+), 62 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 3/9] net: davinci_cpdma: requeue on early end-of-queue
When chaining descriptors to the end of a cpdma queue, there is a chance that
the cpdma engine has already traversed the last descriptor and signalled an
end-of-queue. The original cpdma code detected this condition and requeued
descriptors on submission.
With this patch, an early end-of-queue condition is detected on descriptor
submission as well. This is necessary on davinci style emac controllers, and
prevents transmit timeouts when sending out a burst of packets.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
drivers/net/davinci_cpdma.c | 12 ++--
drivers/net/davinci_cpdma.h |1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
index ab7ecd7..abc2b14 100644
--- a/drivers/net/davinci_cpdma.c
+++ b/drivers/net/davinci_cpdma.c
@@ -488,6 +488,7 @@ static void __cpdma_chan_submit(struct cpdma_chan *chan,
struct cpdma_desc __iomem *prev = chan-tail;
struct cpdma_desc_pool *pool = ctlr-pool;
dma_addr_t desc_dma;
+ u32 mode;
desc_dma = desc_phys(pool, desc);
@@ -507,8 +508,10 @@ static void __cpdma_chan_submit(struct cpdma_chan *chan,
chan-stats.tail_enqueue++;
/* next check if EOQ has been triggered already */
- if (desc_read(prev, hw_mode) CPDMA_DESC_EOQ
- chan-state == CPDMA_STATE_ACTIVE) {
+ mode = desc_read(prev, hw_mode);
+ if (((mode (CPDMA_DESC_EOQ | CPDMA_DESC_OWNER)) == CPDMA_DESC_EOQ)
+ (chan-state == CPDMA_STATE_ACTIVE)) {
+ desc_write(prev, hw_mode, mode ~CPDMA_DESC_EOQ);
chan_write(chan, hdp, desc_dma);
chan-stats.misqueued++;
}
@@ -618,6 +621,11 @@ static int __cpdma_chan_process(struct cpdma_chan *chan)
chan-count--;
chan-stats.good_dequeue++;
+ if (status CPDMA_DESC_EOQ) {
+ chan-stats.requeue++;
+ chan_write(chan, hdp, desc_phys(pool, chan-head));
+ }
+
spin_unlock_irqrestore(chan-lock, flags);
__cpdma_chan_free(chan, desc, outlen, status);
diff --git a/drivers/net/davinci_cpdma.h b/drivers/net/davinci_cpdma.h
index d50ee35..9baacca 100644
--- a/drivers/net/davinci_cpdma.h
+++ b/drivers/net/davinci_cpdma.h
@@ -56,6 +56,7 @@ struct cpdma_chan_stats {
u32 empty_dequeue;
u32 busy_dequeue;
u32 good_dequeue;
+ u32 requeue;
u32 teardown_dequeue;
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] net: davinci_cpdma: add register dump routines
This patch adds register dump routines at both controller and channel levels.
These are intended to be used in higher level driver debug dumps, e.g.
emac_dump_regs().
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
drivers/net/davinci_cpdma.c | 120 +++
drivers/net/davinci_cpdma.h |2 +
2 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
index abc2b14..e92b2b6 100644
--- a/drivers/net/davinci_cpdma.c
+++ b/drivers/net/davinci_cpdma.c
@@ -91,6 +91,8 @@ enum cpdma_state {
CPDMA_STATE_TEARDOWN,
};
+const char *cpdma_state_str[] = { idle, active, teardown };
+
struct cpdma_ctlr {
enum cpdma_statestate;
struct cpdma_params params;
@@ -345,6 +347,76 @@ int cpdma_ctlr_stop(struct cpdma_ctlr *ctlr)
return 0;
}
+int cpdma_ctlr_dump(struct cpdma_ctlr *ctlr)
+{
+ struct device *dev = ctlr-dev;
+ unsigned long flags;
+ int i;
+
+ spin_lock_irqsave(ctlr-lock, flags);
+
+ dev_info(dev, CPDMA: state: %s, cpdma_state_str[ctlr-state]);
+
+ dev_info(dev, CPDMA: txidver: %x,
+dma_reg_read(ctlr, CPDMA_TXIDVER));
+ dev_info(dev, CPDMA: txcontrol: %x,
+dma_reg_read(ctlr, CPDMA_TXCONTROL));
+ dev_info(dev, CPDMA: txteardown: %x,
+dma_reg_read(ctlr, CPDMA_TXTEARDOWN));
+ dev_info(dev, CPDMA: rxidver: %x,
+dma_reg_read(ctlr, CPDMA_RXIDVER));
+ dev_info(dev, CPDMA: rxcontrol: %x,
+dma_reg_read(ctlr, CPDMA_RXCONTROL));
+ dev_info(dev, CPDMA: softreset: %x,
+dma_reg_read(ctlr, CPDMA_SOFTRESET));
+ dev_info(dev, CPDMA: rxteardown: %x,
+dma_reg_read(ctlr, CPDMA_RXTEARDOWN));
+ dev_info(dev, CPDMA: txintstatraw: %x,
+dma_reg_read(ctlr, CPDMA_TXINTSTATRAW));
+ dev_info(dev, CPDMA: txintstatmasked: %x,
+dma_reg_read(ctlr, CPDMA_TXINTSTATMASKED));
+ dev_info(dev, CPDMA: txintmaskset: %x,
+dma_reg_read(ctlr, CPDMA_TXINTMASKSET));
+ dev_info(dev, CPDMA: txintmaskclear: %x,
+dma_reg_read(ctlr, CPDMA_TXINTMASKCLEAR));
+ dev_info(dev, CPDMA: macinvector: %x,
+dma_reg_read(ctlr, CPDMA_MACINVECTOR));
+ dev_info(dev, CPDMA: maceoivector: %x,
+dma_reg_read(ctlr, CPDMA_MACEOIVECTOR));
+ dev_info(dev, CPDMA: rxintstatraw: %x,
+dma_reg_read(ctlr, CPDMA_RXINTSTATRAW));
+ dev_info(dev, CPDMA: rxintstatmasked: %x,
+dma_reg_read(ctlr, CPDMA_RXINTSTATMASKED));
+ dev_info(dev, CPDMA: rxintmaskset: %x,
+dma_reg_read(ctlr, CPDMA_RXINTMASKSET));
+ dev_info(dev, CPDMA: rxintmaskclear: %x,
+dma_reg_read(ctlr, CPDMA_RXINTMASKCLEAR));
+ dev_info(dev, CPDMA: dmaintstatraw: %x,
+dma_reg_read(ctlr, CPDMA_DMAINTSTATRAW));
+ dev_info(dev, CPDMA: dmaintstatmasked: %x,
+dma_reg_read(ctlr, CPDMA_DMAINTSTATMASKED));
+ dev_info(dev, CPDMA: dmaintmaskset: %x,
+dma_reg_read(ctlr, CPDMA_DMAINTMASKSET));
+ dev_info(dev, CPDMA: dmaintmaskclear: %x,
+dma_reg_read(ctlr, CPDMA_DMAINTMASKCLEAR));
+
+ if (!ctlr-params.has_ext_regs) {
+ dev_info(dev, CPDMA: dmacontrol: %x,
+dma_reg_read(ctlr, CPDMA_DMACONTROL));
+ dev_info(dev, CPDMA: dmastatus: %x,
+dma_reg_read(ctlr, CPDMA_DMASTATUS));
+ dev_info(dev, CPDMA: rxbuffofs: %x,
+dma_reg_read(ctlr, CPDMA_RXBUFFOFS));
+ }
+
+ for (i = 0; i ARRAY_SIZE(ctlr-channels); i++)
+ if (ctlr-channels[i])
+ cpdma_chan_dump(ctlr-channels[i]);
+
+ spin_unlock_irqrestore(ctlr-lock, flags);
+ return 0;
+}
+
int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
{
unsigned long flags;
@@ -481,6 +553,54 @@ int cpdma_chan_get_stats(struct cpdma_chan *chan,
return 0;
}
+int cpdma_chan_dump(struct cpdma_chan *chan)
+{
+ unsigned long flags;
+ struct device *dev = chan-ctlr-dev;
+
+ spin_lock_irqsave(chan-lock, flags);
+
+ dev_info(dev, channel %d (%s %d) state %s,
+chan-chan_num, is_rx_chan(chan) ? rx : tx,
+chan_linear(chan), cpdma_state_str[chan-state]);
+ dev_info(dev, \thdp: %x\n, chan_read(chan, hdp));
+ dev_info(dev, \tcp: %x\n, chan_read(chan, cp));
+ if (chan-rxfree) {
+ dev_info(dev, \trxfree: %x\n,
+chan_read(chan, rxfree));
+ }
+
+ dev_info(dev, \tstats head_enqueue: %d\n,
+chan-stats.head_enqueue);
+ dev_info(dev, \tstats tail_enqueue: %d\n,
+
[PATCH 5/9] net: davinci_mdio: separate out controller reset
This patch separates out the controller reset logic, and makes this available
via mii_bus-reset.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
drivers/net/davinci_mdio.c | 90 +--
1 files changed, 52 insertions(+), 38 deletions(-)
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
index d34a53a..a9fbc26 100644
--- a/drivers/net/davinci_mdio.c
+++ b/drivers/net/davinci_mdio.c
@@ -85,6 +85,57 @@ struct davinci_mdio_data {
boolsuspended;
};
+static void __davinci_mdio_reset(struct davinci_mdio_data *data)
+{
+ u32 mdio_in, div;
+
+ mdio_in = clk_get_rate(data-clk);
+ div = (mdio_in / data-pdata.bus_freq) - 1;
+ if (div CONTROL_MAX_DIV)
+ div = CONTROL_MAX_DIV;
+
+ /* set enable and clock divider */
+ __raw_writel(div | CONTROL_ENABLE, data-regs-control);
+}
+
+static int davinci_mdio_reset(struct mii_bus *bus)
+{
+ struct davinci_mdio_data *data = bus-priv;
+ u32 phy_mask, ver;
+
+ __davinci_mdio_reset(data);
+
+ /*
+* wait for scan logic to settle:
+* the scan time consists of (a) a large fixed component, and (b) a
+* small component that varies with the mii bus frequency. These
+* were estimated using measurements at 1.1 and 2.2 MHz on tnetv107x
+* silicon. Since the effect of (b) was found to be largely
+* negligible, we keep things simple here.
+*/
+ mdelay(1);
+
+ /* dump hardware version info */
+ ver = __raw_readl(data-regs-version);
+ dev_info(data-dev, davinci mdio revision %d.%d\n,
+(ver 8) 0xff, ver 0xff);
+
+ /* get phy mask from the alive register */
+ phy_mask = __raw_readl(data-regs-alive);
+ if (phy_mask) {
+ /* restrict mdio bus to live phys only */
+ dev_info(data-dev, detected phy mask %x\n, ~phy_mask);
+ phy_mask = ~phy_mask;
+ } else {
+ /* desperately scan all phys */
+ dev_warn(data-dev, no live phy, scanning all\n);
+ phy_mask = 0;
+ }
+ data-bus-phy_mask = phy_mask;
+
+ return 0;
+}
+
/* wait until hardware is ready for another user access */
static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
{
@@ -163,7 +214,6 @@ static int __devinit davinci_mdio_probe(struct
platform_device *pdev)
struct device *dev = pdev-dev;
struct davinci_mdio_data *data;
struct resource *res;
- u32 mdio_in_freq, mdio_out_freq, div, phy_mask, ver;
struct phy_device *phy;
int ret, addr;
@@ -185,6 +235,7 @@ static int __devinit davinci_mdio_probe(struct
platform_device *pdev)
data-bus-name = dev_name(dev);
data-bus-read = davinci_mdio_read,
data-bus-write= davinci_mdio_write,
+ data-bus-reset= davinci_mdio_reset,
data-bus-parent = dev;
data-bus-priv = data;
snprintf(data-bus-id, MII_BUS_ID_SIZE, %x, pdev-id);
@@ -225,43 +276,6 @@ static int __devinit davinci_mdio_probe(struct
platform_device *pdev)
goto bail_out;
}
- mdio_in_freq = clk_get_rate(data-clk);
- div = (mdio_in_freq / data-pdata.bus_freq) - 1;
- if (div CONTROL_MAX_DIV)
- div = CONTROL_MAX_DIV;
- mdio_out_freq = mdio_in_freq / (div + 1);
-
- /* set enable and clock divider */
- __raw_writel(div | CONTROL_ENABLE, data-regs-control);
-
- /*
-* wait for scan logic to settle:
-* the scan time consists of (a) a large fixed component, and (b) a
-* small component that varies with the mii bus frequency. These
-* were estimated using measurements at 1.1 and 2.2 MHz on tnetv107x
-* silicon. Since the effect of (b) was found to be largely
-* negligible, we keep things simple here.
-*/
- mdelay(1);
-
- /* dump hardware version info */
- ver = __raw_readl(data-regs-version);
- dev_info(dev, davinci mdio revision %d.%d\n,
- (ver 8) 0xff, ver 0xff);
-
- /* get phy mask from the alive register */
- phy_mask = __raw_readl(data-regs-alive);
- if (phy_mask) {
- /* restrict mdio bus to live phys only */
- dev_info(dev, detected phy mask %x\n, ~phy_mask);
- phy_mask = ~phy_mask;
- } else {
- /* desperately scan all phys */
- dev_warn(dev, failed to detect live phys, scanning all\n);
- phy_mask = 0;
- }
- data-bus-phy_mask = phy_mask;
-
/* register the mii bus */
ret = mdiobus_register(data-bus);
if (ret)
--
1.7.0.4
--
To unsubscribe from this list: send the line
[PATCH 9/9] net: davinci_emac: extended register dumps on tx timeout
This patch hooks up the emac_dump_regs() function to use cpdma dump routines. Further, we dump registers on transmit timeout, to make such timeouts debuggable. Signed-off-by: Cyril Chemparathy cy...@ti.com Signed-off-by: Michael Williamson michael.william...@criticallink.com Signed-off-by: Caglar Akyuz caglarak...@gmail.com --- drivers/net/davinci_emac.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index 9e866ae..2a628d1 100644 --- a/drivers/net/davinci_emac.c +++ b/drivers/net/davinci_emac.c @@ -460,6 +460,8 @@ static void emac_dump_regs(struct emac_priv *priv) emac_read(EMAC_RXMOFOVERRUNS)); dev_info(emac_dev, EMAC: rx_dma_overruns:%d\n, emac_read(EMAC_RXDMAOVERRUNS)); + + cpdma_ctlr_dump(priv-dma); } /** @@ -1115,6 +1117,8 @@ static void emac_dev_tx_timeout(struct net_device *ndev) if (netif_msg_tx_err(priv)) dev_err(emac_dev, DaVinci EMAC: xmit timeout, restarting TX); + emac_dump_regs(priv); + ndev-stats.tx_errors++; emac_int_disable(priv); cpdma_chan_stop(priv-txchan); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] net: davinci_mdio: work around emac soft-reset during i/o
On certain devices (e.g. da8xx), the hardware design ties emac soft-reset to
the mdio module. In these cases, when the emac device is opened, an in-flight
mdio transaction could fail by returning the controller to idle state. This
patch detects this condition and works around it by retrying the failed
transaction.
In addition, defensive timeouts have been added to prevent an indefinite
lockup in case of an unexpected hardware error.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
drivers/net/davinci_mdio.c | 92 ---
1 files changed, 77 insertions(+), 15 deletions(-)
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
index f2d7639..7615040 100644
--- a/drivers/net/davinci_mdio.c
+++ b/drivers/net/davinci_mdio.c
@@ -36,6 +36,13 @@
#include linux/io.h
#include linux/davinci_emac.h
+/*
+ * This timeout definition is a worst-case ultra defensive measure against
+ * unexpected controller lock ups. Ideally, we should never ever hit this
+ * scenario in practice.
+ */
+#define MDIO_TIMEOUT 100 /* msecs */
+
#define PHY_REG_MASK 0x1f
#define PHY_ID_MASK0x1f
@@ -150,30 +157,53 @@ static int davinci_mdio_reset(struct mii_bus *bus)
}
/* wait until hardware is ready for another user access */
-static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
+static inline int wait_for_user_access(struct davinci_mdio_data *data)
{
struct davinci_mdio_regs __iomem *regs = data-regs;
+ unsigned long timeout = jiffies + msecs_to_jiffies(MDIO_TIMEOUT);
u32 reg;
- while ((reg = __raw_readl(regs-user[0].access)) USERACCESS_GO)
- ;
-
- return reg;
+ while (time_after(timeout, jiffies)) {
+ reg = __raw_readl(regs-user[0].access);
+ if ((reg USERACCESS_GO) == 0)
+ return 0;
+
+ reg = __raw_readl(regs-control);
+ if ((reg CONTROL_IDLE) == 0)
+ continue;
+
+ /*
+* An emac soft_reset may have clobbered the mdio controller's
+* state machine. We need to reset and retry the current
+* operation
+*/
+ dev_warn(data-dev, resetting idled controller\n);
+ __davinci_mdio_reset(data);
+ return -EAGAIN;
+ }
+ dev_err(data-dev, timed out waiting for user access\n);
+ return -ETIMEDOUT;
}
/* wait until hardware state machine is idle */
-static inline void wait_for_idle(struct davinci_mdio_data *data)
+static inline int wait_for_idle(struct davinci_mdio_data *data)
{
struct davinci_mdio_regs __iomem *regs = data-regs;
+ unsigned long timeout = jiffies + msecs_to_jiffies(MDIO_TIMEOUT);
- while ((__raw_readl(regs-control) CONTROL_IDLE) == 0)
- ;
+ while (time_after(timeout, jiffies)) {
+ if (__raw_readl(regs-control) CONTROL_IDLE)
+ return 0;
+ }
+ dev_err(data-dev, timed out waiting for idle\n);
+ return -ETIMEDOUT;
}
static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
{
struct davinci_mdio_data *data = bus-priv;
u32 reg;
+ int ret;
if (phy_reg ~PHY_REG_MASK || phy_id ~PHY_ID_MASK)
return -EINVAL;
@@ -185,14 +215,32 @@ static int davinci_mdio_read(struct mii_bus *bus, int
phy_id, int phy_reg)
return -ENODEV;
}
- wait_for_user_access(data);
reg = (USERACCESS_GO | USERACCESS_READ | (phy_reg 21) |
(phy_id 16));
- __raw_writel(reg, data-regs-user[0].access);
- reg = wait_for_user_access(data);
+
+ while (1) {
+ ret = wait_for_user_access(data);
+ if (ret == -EAGAIN)
+ continue;
+ if (ret 0)
+ break;
+
+ __raw_writel(reg, data-regs-user[0].access);
+
+ ret = wait_for_user_access(data);
+ if (ret == -EAGAIN)
+ continue;
+ if (ret 0)
+ break;
+
+ reg = __raw_readl(data-regs-user[0].access);
+ ret = (reg USERACCESS_ACK) ? (reg USERACCESS_DATA) : -EIO;
+ break;
+ }
+
spin_unlock(data-lock);
- return (reg USERACCESS_ACK) ? (reg USERACCESS_DATA) : -EIO;
+ return ret;
}
static int davinci_mdio_write(struct mii_bus *bus, int phy_id,
@@ -200,6 +248,7 @@ static int davinci_mdio_write(struct mii_bus *bus, int
phy_id,
{
struct davinci_mdio_data *data = bus-priv;
u32 reg;
+ int ret;
if (phy_reg ~PHY_REG_MASK || phy_id ~PHY_ID_MASK)
return -EINVAL;
@@ -211,11 +260,24 @@
[PATCH 6/9] net: davinci_mdio: use calculated bus access times
This patch replaces the hardcoded scan delay with a calculated delay that
adjusts to clock rates. This delay is calculated on the basis of a worst case
bus transaction time, with generous built-in margins of error.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
drivers/net/davinci_mdio.c | 33 +++--
1 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
index a9fbc26..f2d7639 100644
--- a/drivers/net/davinci_mdio.c
+++ b/drivers/net/davinci_mdio.c
@@ -83,11 +83,12 @@ struct davinci_mdio_data {
struct device *dev;
struct mii_bus *bus;
boolsuspended;
+ unsigned long access_time; /* jiffies */
};
static void __davinci_mdio_reset(struct davinci_mdio_data *data)
{
- u32 mdio_in, div;
+ u32 mdio_in, div, mdio_out_khz, access_time;
mdio_in = clk_get_rate(data-clk);
div = (mdio_in / data-pdata.bus_freq) - 1;
@@ -96,6 +97,25 @@ static void __davinci_mdio_reset(struct davinci_mdio_data
*data)
/* set enable and clock divider */
__raw_writel(div | CONTROL_ENABLE, data-regs-control);
+
+ /*
+* One mdio transaction consists of:
+* 32 bits of preamble
+* 32 bits of transferred data
+* 24 bits of bus yield (not needed unless shared?)
+*/
+ mdio_out_khz = mdio_in / (1000 * (div + 1));
+ access_time = (88 * 1000) / mdio_out_khz;
+
+ /*
+* In the worst case, we could be kicking off a user-access immediately
+* after the mdio bus scan state-machine triggered its own read. If
+* so, our request could get deferred by one access cycle. We
+* defensively allow for 4 access cycles.
+*/
+ data-access_time = usecs_to_jiffies(access_time * 4);
+ if (!data-access_time)
+ data-access_time = 1;
}
static int davinci_mdio_reset(struct mii_bus *bus)
@@ -105,15 +125,8 @@ static int davinci_mdio_reset(struct mii_bus *bus)
__davinci_mdio_reset(data);
- /*
-* wait for scan logic to settle:
-* the scan time consists of (a) a large fixed component, and (b) a
-* small component that varies with the mii bus frequency. These
-* were estimated using measurements at 1.1 and 2.2 MHz on tnetv107x
-* silicon. Since the effect of (b) was found to be largely
-* negligible, we keep things simple here.
-*/
- mdelay(1);
+ /* wait for scan logic to settle */
+ msleep(PHY_MAX_ADDR * data-access_time);
/* dump hardware version info */
ver = __raw_readl(data-regs-version);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
On Mon, Sep 13, 2010 at 12:06 PM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/omap4-for-tony My boot log: http://paste.ubuntu.com/491645/ [Ghorai] can you use this bootargs? setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M console=ttyS2,115200n8 And here is the log from my setup. [ 2.493194] Waiting for root device /dev/mmcblk0p2... [ 2.502960] mmc0: host does not support reading read-only switch. assuming write-enable. [ 2.523895] mmc0: new high speed SDHC card at address e1ed [ 2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB [ 2.539550] mmcblk0: p1 p2 [ 2.607360] EXT3-fs: barriers not enabled Using x-loader from http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and upstream u-boot. [Ghorai] can you try with this x-loader https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhODgtN2QzNjUwMzBkNDI2hl=en In the mean time I will try with yours! I'm unable to boot with your x-loader at my ES2.0 (6 and 8 layers), however I'm able to boot it with ES1. Are you sure you're testing it at an ES2 board? This is what I get, it just hangs: Texas Instruments X-Loader 1.41 (Aug 11 2010 - 10:51:13) Could not read bootloader! X-Loader hangs Cheers, -- Ricardo Salveti de Araujo -- 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: Suspend to RAM broken on BeagleBoard ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Hello, On Mon, 13 Sep 2010 07:56:54 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: Looks like DSS has not been initialized, so is not hitting RET. Do you have the DSS driver enabled and built-in? Without this (and until we have DSS converted to hwmod) the DSS HW is not in a state that can hit the low power mode. If the DSS driver is allowed to initialize, even without a panel, it should set the DSS HW in a state that will then allow RET. Indeed: $ grep DSS .config # CONFIG_OMAP2_DSS is not set It's not enabled simply because it isn't enabled by omap3_defconfig. So maybe it should also be fixed for this ? I have zero knowledge of DSS, but shouldn't the kernel be able to suspend properly even if the DSS driver is disabled ? Yes, it should, and it's almost there. But maybe it's too complicated to have the DSS init sequence required to allow the system to hit RET outside the DSS driver. Thoughts ? One of the multiple motivations for moving to the omap_hwmod model of describing all the HW IP blocks in a central location is so that we have a common init and reset for every on-chip device. Once an omap_hwmod exists for a device, during init, the hwmod core will ensure that that block is properly initialized, reset and in a state that will not prevent the chip from entering low-power sleep. This will happen in the hwmod core, and is independent of the existence of a driver for that device, so will solve problems like this one. Currently, we have a hack here and a hack there for common devices that the bootloader blindy leaves in an state that prevents low-power states, but this is clearly a hack and does not scale. omap_hwmod is the solution to scaling this to every IP block. 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
OMAP3 DSP MMU fault + off mode issue
Dear all, I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32). The issue is describing as below mentioned way, 1). The Device is getting DSP MMU Fault when playing MP4 video clip. The system is not hitting off mode in the below scenario, 2). System boot -play mp4 clip -DSP MMU Fault - allow off mode --- Never hits off mode But surprisingly the system is hitting off mode in the below scenario, 3). System boot -allow off mode -play mp4 clip -DSP MMU Fault - allow off mode --- perfectly works - Could you please describe the root cause about the above issues 1 2? - How could solve the above issues? Best Regards, Venkii -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] idle-path reorg for interrupt-enabled runtime PM
From: Kevin Hilman khil...@ti.com This series is a cleanup/reorg/streamline of the core idle path. The goal is to remove all device-specific idle management out of the core idle path into device-specific code. This series starts with some of the device-specific hacks currently in the idle path, and also moves GPIO handling out of the core idle loop. Eventually, all device-specific idle management should be done using the runtime PM hooks of the driver for that device. Until then, temporary hacks belong in the new omap3_device_[idle|resume] functions. Note that for debug purposes, UART is still managed inside the interrupt-disabled idle path. This is for debug purposes only so that any panic/BUG code that gets triggered before the device resume code is run will not crash the system. As soon as the new omap-serial driver is converted to runtime PM, the UART management can be removed from the idle path as well. Patch 1 will be queued in my pm-next branch for .37 and patch 2 should be incorporated into baseline for the GPIO hwmod conversion. Kevin Hilman (2): OMAP3: PM: move device-specific special cases from PM core into CPUidle OMAP2+: GPIO: move late PM out of interrupts-disabled idle path arch/arm/mach-omap2/cpuidle34xx.c | 54 -- arch/arm/mach-omap2/pm.h |2 + arch/arm/mach-omap2/pm24xx.c |2 +- arch/arm/mach-omap2/pm34xx.c | 48 -- arch/arm/plat-omap/gpio.c | 57 arch/arm/plat-omap/include/plat/gpio.h |4 +-- 6 files changed, 113 insertions(+), 54 deletions(-) -- 1.7.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP3: PM: move device-specific special cases from PM core into CPUidle
From: Kevin Hilman khil...@ti.com
In an effort to simplify the core idle path, move any device-specific
special case handling from the core PM idle path into the CPUidle
pre-idle checking path.
This keeps the core, interrupts-disabled idle path streamlined and
independent of any device-specific handling, and also allows CPUidle
to do the checking only for certain C-states as needed. This patch
has the device checks in place for all states with the CHECK_BM flag,
namely all states = C2.
This patch was inspired by a similar patch written by Tero Kristo as
part of a larger series to add INACTIVE state support.
Cc: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 50 ++--
arch/arm/mach-omap2/pm34xx.c | 14 +-
2 files changed, 48 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..0923b82 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -60,7 +60,8 @@ struct omap3_processor_cx {
struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
-struct powerdomain *mpu_pd, *core_pd;
+struct powerdomain *mpu_pd, *core_pd, *per_pd;
+struct powerdomain *cam_pd;
/*
* The latencies/thresholds for various C states have
@@ -233,14 +234,54 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
struct cpuidle_state *state)
{
struct cpuidle_state *new_state = next_valid_state(dev, state);
+ u32 core_next_state, per_next_state = 0, per_saved_state = 0;
+ u32 cam_state;
+ struct omap3_processor_cx *cx;
+ int ret;
if ((state-flags CPUIDLE_FLAG_CHECK_BM) omap3_idle_bm_check()) {
BUG_ON(!dev-safe_state);
new_state = dev-safe_state;
+ goto select_state;
+ }
+
+ cx = cpuidle_get_statedata(state);
+ core_next_state = cx-core_state;
+
+ /*
+* Prevent idle completely if CAM is active.
+* CAM does not have wakeup capability in OMAP3.
+*/
+ cam_state = pwrdm_read_pwrst(cam_pd);
+ if (cam_state == PWRDM_POWER_ON) {
+ new_state = dev-safe_state;
+ goto select_state;
}
+ /*
+* Prevent PER off if CORE is not in retention or off as this
+* would disable PER wakeups completely.
+*/
+ per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
+ if ((per_next_state == PWRDM_POWER_OFF)
+ (core_next_state PWRDM_POWER_RET)) {
+ per_next_state = PWRDM_POWER_RET;
+ pwrdm_set_next_pwrst(per_pd, per_next_state);
+ }
+
+ /* Are we changing PER target state? */
+ if (per_next_state != per_saved_state)
+ pwrdm_set_next_pwrst(per_pd, per_next_state);
+
+select_state:
dev-last_state = new_state;
- return omap3_enter_idle(dev, new_state);
+ ret = omap3_enter_idle(dev, new_state);
+
+ /* Restore original PER state if it was modified */
+ if (per_next_state != per_saved_state)
+ pwrdm_set_next_pwrst(per_pd, per_saved_state);
+
+ return ret;
}
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
@@ -328,7 +369,8 @@ void omap_init_power_states(void)
cpuidle_params_table[OMAP3_STATE_C2].threshold;
omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
- omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID;
+ omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID |
+ CPUIDLE_FLAG_CHECK_BM;
/* C3 . MPU CSWR + Core inactive */
omap3_power_states[OMAP3_STATE_C3].valid =
@@ -426,6 +468,8 @@ int __init omap3_idle_init(void)
mpu_pd = pwrdm_lookup(mpu_pwrdm);
core_pd = pwrdm_lookup(core_pwrdm);
+ per_pd = pwrdm_lookup(per_pwrdm);
+ cam_pd = pwrdm_lookup(cam_pwrdm);
omap_init_power_states();
cpuidle_register_driver(omap3_idle_driver);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 429268e..bb2ba1e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -346,7 +346,6 @@ void omap_sram_idle(void)
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- int per_state_modified = 0;
if (!_omap_sram_idle)
return;
@@ -391,19 +390,10 @@ void omap_sram_idle(void)
if (per_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
- if (per_next_state == PWRDM_POWER_OFF) {
- if
[PATCH 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
From: Kevin Hilman khil...@ti.com
Currently, we wait until late in the idle path where interrupts are
disabled to do runtime-PM-like management for certain special-case
devices like GPIO.
As a prerequiste to moving GPIO to the new runtime PM framework, move
this runtime-PM-like code out of the late idle path into new device
idle and resume functions that can be called before interrupts are
disabled by CPUidle and/or suspend.
In addition, move all the GPIO-specific logic into the GPIO core
instead of keeping GPIO-specific knowledge of power-states, context
saving etc. in the PM core.
Also, call the new device-idle and -resume methods from CPUidle and
static suspend path.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |4 ++
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/pm24xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c | 38 +
arch/arm/plat-omap/gpio.c | 57
arch/arm/plat-omap/include/plat/gpio.h |4 +--
6 files changed, 67 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0923b82..681d823 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -274,9 +274,13 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
pwrdm_set_next_pwrst(per_pd, per_next_state);
select_state:
+ omap3_device_idle();
+
dev-last_state = new_state;
ret = omap3_enter_idle(dev, new_state);
+ omap3_device_resume();
+
/* Restore original PER state if it was modified */
if (per_next_state != per_saved_state)
pwrdm_set_next_pwrst(per_pd, per_saved_state);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 3de6ece..33cae4b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,6 +22,8 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+extern void omap3_device_idle(void);
+extern void omap3_device_resume(void);
struct cpuidle_params {
u8 valid;
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 6aeedea..7bbf0db 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -106,7 +106,7 @@ static void omap2_enter_full_retention(void)
l = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0) | OMAP24XX_USBSTANDBYCTRL;
omap_ctrl_writel(l, OMAP2_CONTROL_DEVCONF0);
- omap2_gpio_prepare_for_idle(PWRDM_POWER_RET);
+ omap2_gpio_prepare_for_idle();
if (omap2_pm_debug) {
omap2_pm_dump(0, 0, 0);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bb2ba1e..9e590d9 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -74,16 +74,6 @@ static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
static struct powerdomain *cam_pwrdm;
-static inline void omap3_per_save_context(void)
-{
- omap_gpio_save_context();
-}
-
-static inline void omap3_per_restore_context(void)
-{
- omap_gpio_restore_context();
-}
-
static void omap3_enable_io_chain(void)
{
int timeout = 0;
@@ -332,6 +322,16 @@ static void restore_table_entry(void)
restore_control_register(control_reg_value);
}
+void omap3_device_idle(void)
+{
+ omap2_gpio_prepare_for_idle();
+}
+
+void omap3_device_resume(void)
+{
+ omap2_gpio_resume_after_idle();
+}
+
void omap_sram_idle(void)
{
/* Variable to tell what needs to be saved and restored
@@ -344,7 +344,7 @@ void omap_sram_idle(void)
int mpu_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
- int core_prev_state, per_prev_state;
+ int core_prev_state;
u32 sdrc_pwr = 0;
if (!_omap_sram_idle)
@@ -387,12 +387,9 @@ void omap_sram_idle(void)
}
/* PER */
- if (per_next_state PWRDM_POWER_ON) {
+ if (per_next_state PWRDM_POWER_ON)
omap_uart_prepare_idle(2);
- omap2_gpio_prepare_for_idle(per_next_state);
- if (per_next_state == PWRDM_POWER_OFF)
- omap3_per_save_context();
- }
+
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
@@ -454,13 +451,8 @@ void omap_sram_idle(void)
omap3_intc_resume_idle();
/* PER */
- if (per_next_state PWRDM_POWER_ON) {
- per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
- omap2_gpio_resume_after_idle();
- if (per_prev_state == PWRDM_POWER_OFF)
- omap3_per_restore_context();
+ if (per_next_state PWRDM_POWER_ON)
RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0
-Original Message- From: Ricardo Salveti [mailto:rsalv...@rsalveti.net] Sent: Tuesday, September 14, 2010 12:22 AM To: Ghorai, Sukumar Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org; t...@atomide.com; Bryan Wu Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0 On Mon, Sep 13, 2010 at 12:06 PM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/omap4-for-tony My boot log: http://paste.ubuntu.com/491645/ [Ghorai] can you use this bootargs? setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M console=ttyS2,115200n8 And here is the log from my setup. [ 2.493194] Waiting for root device /dev/mmcblk0p2... [ 2.502960] mmc0: host does not support reading read-only switch. assuming write-enable. [ 2.523895] mmc0: new high speed SDHC card at address e1ed [ 2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB [ 2.539550] mmcblk0: p1 p2 [ 2.607360] EXT3-fs: barriers not enabled Using x-loader from http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and upstream u-boot. [Ghorai] can you try with this x-loader https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhO DgtN2QzNjUwMzBkNDI2hl=en In the mean time I will try with yours! I'm unable to boot with your x-loader at my ES2.0 (6 and 8 layers), however I'm able to boot it with ES1. Are you sure you're testing it at an ES2 board? This is what I get, it just hangs: Texas Instruments X-Loader 1.41 (Aug 11 2010 - 10:51:13) Could not read bootloader! X-Loader hangs [Ghorai] format the card and copy MLo and followed by u-boot, uImage And yes I am using EX 2.0 6-layer board. Cheers, -- Ricardo Salveti de Araujo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] arm: remove cast from void*
Unnecessary cast from void* in assignment.
Signed-off-by: matt mooney m...@muteddisk.com
---
arch/arm/mach-omap2/mailbox.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 42dbfa4..40ddeca 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -181,7 +181,7 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq)
{
- struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv;
+ struct omap_mbox2_priv *p = mbox-priv;
u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
l = mbox_read_reg(p-irqenable);
@@ -192,7 +192,7 @@ static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq)
{
- struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv;
+ struct omap_mbox2_priv *p = mbox-priv;
u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
l = mbox_read_reg(p-irqdisable);
l = ~bit;
@@ -202,7 +202,7 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq)
{
- struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv;
+ struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
mbox_write_reg(bit, p-irqstatus);
@@ -214,7 +214,7 @@ static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
static int omap2_mbox_is_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq)
{
- struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv;
+ struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
u32 enable = mbox_read_reg(p-irqenable);
u32 status = mbox_read_reg(p-irqstatus);
--
1.7.2.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
