Texas Instrument's Omap Processor's Linux development mailing list

Thomas Klute | 25 May 17:19

Ftrace Timer on OMAP3

Hi everyone,

we're having some trouble getting useful results from Ftrace on OMAP3
(Gumstix Overo). As you can see in the example output below, function
duration can't be displayed with a precision higher than about 30.5 us,
which matches the frequency of the 32 kHz platform timer. For OMAP1,
using OMAP_MPU_TIMER instead of CONFIG_OMAP_32K_TIMER should provide
better results [1], but I couldn't find anything similar for OMAP3. Just
setting CONFIG_OMAP_32K_TIMER=N didn't change the results. Did I miss
anything, or isn't there any more precise timer?

Best regards,
Thomas Klute

[1]
http://elinux.org/images/0/0c/Bird-LS-2009-Measuring-function-duration-with-ftrace.pdf

Example Ftrace output:

  876.252136 |   0)               |  sys_sendmsg() {
  876.252166 |   0)               |    rom_rtadd() {
  876.252197 |   0)   0.000 us    |      release_queue_for_dst();
  876.252197 |   0)   0.000 us    |      add_route();
  876.252197 |   0) + 30.517 us   |    }
  876.252258 |   0) + 91.553 us   |  }
--
  876.311859 |   0)               |  sys_sendmsg() {
  876.311889 |   0)               |    rom_rtadd() {
  876.311889 |   0) + 30.518 us   |      release_queue_for_dst();
  876.311920 |   0)   0.000 us    |      add_route();

(Continue reading)

headers

jgq516 | 25 May 12:42

[PATCH 0/3] omap3/omap4: add device tree support for wdt

From: Xiao Jiang <jgq516 <at> gmail.com>

This series can be applied to dt branch of linux-omap tree.

Since omap24xx series has different wdt base addr (omap2420: 0x48022000 and
omap2430: 0x49016000) per commit 2817142f31bfbf26c216bf4f9192540c81b2d071, so
I don't add wdt node in omap2.dtsi just like omap3 and omap4, maybe different
dts files are needed for omap2420 and omap2430.

Tested with omap4430 blaze board.

Xiao Jiang (3):
  arm/dts: add wdt node for omap3 and omap4
  OMAP: wdt: add device tree support
  watchdog: omap_wdt: add device tree support

 arch/arm/boot/dts/omap3.dtsi  |    5 +++++
 arch/arm/boot/dts/omap4.dtsi  |    5 +++++
 arch/arm/mach-omap2/devices.c |    2 +-
 drivers/watchdog/omap_wdt.c   |    8 ++++++++
 4 files changed, 19 insertions(+), 1 deletions(-)

--

-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

headers

Woodruff, Richard | 24 May 20:12

usage of sparse or other trick for improved type safety

Hi Tony,

I am hoping to solicit an opinion from you for OMAP frameworks in general.

In some recent review there was some debate about how it was good practice to form parameters in a way which
didn't get misused. Nishanth was having some experience where end users doing custom ports made some hard
to find mistakes.

I was wondering if it is useful to create a standard or it's a waste of time. The knee-jerk reaction to comment
is to consider annotations for driver users of api's, then inside the framework trust internals to do the
right thing. Complexity divide between a driver and some frameworks might be similar to user-vs-kernel.

I think example in this case was IVA and other external subsystems commonly got away using stale
definitions when managing their own power domains. Example seemed a little pedantic but it is true that
this has broken several times through migrations. At customer fan out it causes a lot of effort which could
have been avoided.

Just last week someone was trying to caste away an iomem annotation from external driver based on warning.
For me warning was a good thing and forced discussion.

I do recall you pushing what ARM and Linux tress did in this area back into OMAP years back. Question is if it's
worth internalizing more for our ever growing frameworks.

Thanks,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

(Continue reading)

headers

Andy Gross | 24 May 18:44

[PATCH] staging: omapdrm: fix crash when freeing bad fb

During unload, don't cleanup the framebuffer if it is not valid.

Signed-off-by: Andy Gross <andy.gross <at> ti.com>
---
 drivers/staging/omapdrm/omap_fbdev.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_fbdev.c b/drivers/staging/omapdrm/omap_fbdev.c
index 11acd4c..8c6ed3b 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -208,7 +208,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
 	 */
 	ret = omap_gem_get_paddr(fbdev->bo, &paddr, true);
 	if (ret) {
-		dev_err(dev->dev, "could not map (paddr)!\n");
+		dev_err(dev->dev,
+			"could not map (paddr)!  Skipping framebuffer alloc\n");
 		ret = -ENOMEM;
 		goto fail;
 	}
@@ -388,8 +389,11 @@ void omap_fbdev_free(struct drm_device *dev)

 	fbi = helper->fbdev;

-	unregister_framebuffer(fbi);
-	framebuffer_release(fbi);
+	/* only cleanup framebuffer if it is present */
+	if (fbi) {
+		unregister_framebuffer(fbi);

(Continue reading)

headers

Andy Gross | 24 May 18:43

[PATCH] staging: omapdrm: Fix error paths during dmm init

Failures during the dmm probe can cause the kernel to crash.  Moved
the spinlock to a global and moved list initializations immediately
after the allocation of the dmm private structure.

Signed-off-by: Andy Gross <andy.gross <at> ti.com>
---
 drivers/staging/omapdrm/omap_dmm_priv.h  |    1 -
 drivers/staging/omapdrm/omap_dmm_tiler.c |   44 ++++++++++++++++-------------
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_priv.h b/drivers/staging/omapdrm/omap_dmm_priv.h
index 2f529ab..08b22e9 100644
--- a/drivers/staging/omapdrm/omap_dmm_priv.h
+++ b/drivers/staging/omapdrm/omap_dmm_priv.h
@@ -181,7 +181,6 @@ struct dmm {

 	/* allocation list and lock */
 	struct list_head alloc_head;
-	spinlock_t list_lock;
 };

 #endif
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 1ecb6a7..3bc715d 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -40,6 +40,9 @@
 static struct tcm *containers[TILFMT_NFORMATS];
 static struct dmm *omap_dmm;

(Continue reading)

headers

Russell King - ARM Linux | 24 May 11:04

[PATCH] Fix OMAP4 boot regression

Fix a boot regression in existing kernels causing:

genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq XXX

caused by 1c6c6952 (genirq: Reject bogus threaded irq requests).

Signed-off-by: Russell King <rmk+kernel <at> arm.linux.org.uk>
--
 drivers/mmc/host/omap_hsmmc.c |    2 +-
 drivers/rtc/rtc-twl.c         |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d76fc82..84016cb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1962,7 +1962,7 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev)
 		ret = request_threaded_irq(mmc_slot(host).card_detect_irq,
 					   NULL,
 					   omap_hsmmc_detect,
-					   IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+					   IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
 					   mmc_hostname(mmc), host);
 		if (ret) {
 			dev_dbg(mmc_dev(host->mmc),
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 258abea..c5d06fe 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -510,7 +510,7 @@ static int __devinit twl_rtc_probe(struct platform_device *pdev)

(Continue reading)

headers

Kevin Hilman | 24 May 02:01

MFD USB host: prevents CORE retention in idle

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention
in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle,
thus preventing CORE from hitting retention.

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and
was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I
would've expected that runtime PM would've kicked in and shutdown this
clock.

Any ideas what's going on here?  Is this expected behavior?

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Andy Gross | 23 May 22:08

[PATCH] omap2+: add drm device

Register OMAP DRM/KMS platform device.  DMM is split into a
separate device using hwmod.

Signed-off-by: Andy Gross <andy.gross <at> ti.com>
---
 arch/arm/mach-omap2/Makefile           |    4 ++
 arch/arm/mach-omap2/drm.c              |   61 ++++++++++++++++++++++++++++++++
 drivers/staging/omapdrm/omap_drv.h     |    2 +-
 drivers/staging/omapdrm/omap_priv.h    |   55 ----------------------------
 include/linux/platform_data/omap_drm.h |   52 +++++++++++++++++++++++++++
 5 files changed, 118 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/mach-omap2/drm.c
 delete mode 100644 drivers/staging/omapdrm/omap_priv.h
 create mode 100644 include/linux/platform_data/omap_drm.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..c301ab7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
 obj-y					+= dsp.o
 endif

+ifneq ($(CONFIG_DRM_OMAP),)
+obj-y					+= drm.o
+endif
+
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)		+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4)		+= board-h4.o

(Continue reading)

headers

scott owen | 23 May 11:16

MP-23

You are a great winner of 5crore 45larks by microsoft. send Name:Mobile:Address:Country for claims
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Jon Hunter | 22 May 22:17

[PATCH 4/5] ARM: OMAP1: Add dmtimer clock data

From: Jon Hunter <jon-hunter <at> ti.com>

Add clock data for the 8 dmtimers present on OMAP16xx (including OMAP5912)
and OMAP17xx devices. These timers support 3 different clock sources which
are the 32kHz clock, ARMXOR clock and an external clock source.

Signed-off-by: Jon Hunter <jon-hunter <at> ti.com>
---
 arch/arm/mach-omap1/clock_data.c |  140 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 140 insertions(+)

diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index d60f690..27acf4c 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -83,6 +83,12 @@ static struct clk ck_ref = {
 	.rate		= 12000000,
 };

+static struct clk ck_32k = {
+	.name		= "ck_32k",
+	.ops		= &clkops_null,
+	.rate		= 32768,
+};
+
 static struct clk ck_dpll1 = {
 	.name		= "ck_dpll1",
 	.ops		= &clkops_null,
@@ -677,6 +683,127 @@ static struct clk i2c_ick = {
 	.recalc		= &followparent_recalc,

(Continue reading)

headers

Jon Hunter | 22 May 22:17

[PATCH 5/5] ARM: OMAP: For all OMAP devices use clock framework to set dmtimer clock source

From: Jon Hunter <jon-hunter <at> ti.com>

OMAP1 and OMAP2+ devices had architecture specific functions for configuring
the dmtimer clock source. This was simply because the OMAP1 devices did not
support the clock framework for dynamically setting a clock's parent. Now OMAP1
can use the clock framework to set the parent clock, remove the architecture
specific functions and use a common function to set the parent clock for all
OMAP devices. This common function is based upon the OMAP2+
omap2_dm_timer_set_src() as this was using the clock framework.

Signed-off-by: Jon Hunter <jon-hunter <at> ti.com>
---
 arch/arm/mach-omap1/timer.c               |   15 +------
 arch/arm/mach-omap2/timer.c               |   61 -----------------------------
 arch/arm/plat-omap/dmtimer.c              |   43 +++++++++++++++++++-
 arch/arm/plat-omap/include/plat/dmtimer.h |    1 -
 4 files changed, 43 insertions(+), 77 deletions(-)

diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 64c65bc..6ef4f6d 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -41,19 +41,6 @@

 #define OMAP1_DM_TIMER_COUNT		8

-static int omap1_dm_timer_set_src(struct platform_device *pdev,
-				int source)
-{
-	int n = (pdev->id - 1) << 1;

(Continue reading)

1478	May 2012
1235	April 2012
1487	March 2012
1389	February 2012
948	January 2012
1161	December 2011
862	November 2011
658	October 2011
1478	September 2011
1216	August 2011
1121	July 2011
1213	June 2011
1196	May 2011
785	April 2011
1839	March 2011
2005	February 2011
1656	January 2011
1592	December 2010
1452	November 2010
1440	October 2010
1616	September 2010
1229	August 2010
881	July 2010
1131	June 2010
1893	May 2010
1222	April 2010
1151	March 2010
1407	February 2010
1419	January 2010
1361	December 2009
1371	November 2009
1286	October 2009
744	September 2009
1478	August 2009
722	July 2009
1007	June 2009
1026	May 2009
690	April 2009
1253	March 2009
967	February 2009
1185	January 2009
665	December 2008
1117	November 2008
1208	October 2008
1589	September 2008
992	August 2008
437	July 2008
592	June 2008
572	May 2008
732	April 2008
350	March 2008
11	February 2008
22	January 2008
261	December 2007
468	November 2007
316	October 2007
247	September 2007
562	August 2007
175	July 2007
321	June 2007
564	May 2007
208	April 2007
294	March 2007
181	February 2007
248	January 2007
194	December 2006
316	November 2006
218	October 2006
151	September 2006
263	August 2006
113	July 2006
152	June 2006
356	May 2006
158	April 2006
297	March 2006
205	February 2006
276	January 2006
263	December 2005
133	November 2005

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31