[RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Hi, This is another version of kmemleak: Fix false positive, which introduces another alias tree to keep track of all alias address of each objects, based on the discussion(*1) You can also find the previous one(*2), which uses special scan area for alias addresses with a conversion function. Compared with both methods, it seems that the current one takes a bit longer to scan as below, tested with 512 elementes of (*3). kmemleak: Fix false positive with alias: # time echo scan /mnt/kmemleak real0m 8.40s user0m 0.00s sys 0m 8.40s kmemleak: Fix false positive with special scan: # time echo scan /mnt/kmemleak real0m 3.96s user0m 0.00s sys 0m 3.96s For our case(*4) to reduce false positives for the 2nd level IOMMU pagetable allocation, the previous special scan seems to be enough lightweight, although there might be possiblity to improve alias one and also I might misunderstand the original proposal of aliasing. Any comment would be appreciated. *1: http://lkml.org/lkml/2010/6/2/282 *2: kmemleak: Fix false positive with special scan http://lkml.org/lkml/2010/6/1/137 *3: kmemleak: Add special scan test case http://lkml.org/lkml/2010/6/1/134 *4: http://lkml.org/lkml/2010/6/1/136 Hiroshi DOYU (1): kmemleak: Fix false positive with alias include/linux/kmemleak.h |4 + mm/kmemleak.c| 198 ++ 2 files changed, 168 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] kmemleak: Fix false positive with alias
There is a false positive case that a pointer is calculated by other
methods than the usual container_of macro. kmemleak_ignore can cover
such a false positive, but it would loose the advantage of memory leak
detection. This patch allows kmemleak to work with such false
positives by aliasing of address. A client module can register an
alias address to an original pointer.
A typical use case could be the IOMMU pagetable allocation which
stores pointers to the second level of page tables with some
conversion, for example, a physical address with attribute bits. Right
now I don't have other use cases but I hope that there could be some
that this special scan works with.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
---
include/linux/kmemleak.h |4 +
mm/kmemleak.c| 198 ++
2 files changed, 168 insertions(+), 34 deletions(-)
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 99d9a67..0a4ccee 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -34,6 +34,7 @@ extern void kmemleak_not_leak(const void *ptr) __ref;
extern void kmemleak_ignore(const void *ptr) __ref;
extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp) __ref;
extern void kmemleak_no_scan(const void *ptr) __ref;
+extern void kmemleak_add_alias(const void *ptr, const void *new) __ref;
static inline void kmemleak_alloc_recursive(const void *ptr, size_t size,
int min_count, unsigned long flags,
@@ -92,6 +93,9 @@ static inline void kmemleak_erase(void **ptr)
static inline void kmemleak_no_scan(const void *ptr)
{
}
+static inline void kmemleak_add_alias(const void *ptr, const void *new)
+{
+}
#endif /* CONFIG_DEBUG_KMEMLEAK */
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2c0d032..fa20304 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -157,6 +157,13 @@ struct kmemleak_object {
unsigned long jiffies; /* creation timestamp */
pid_t pid; /* pid of the current task */
char comm[TASK_COMM_LEN]; /* executable name */
+ struct kmemleak_alias *alias; /* if a pointer is modified */
+};
+
+struct kmemleak_alias {
+ struct list_head alias_list;
+ struct prio_tree_node tree_node;
+ struct kmemleak_object *object;
};
/* flag representing the memory block allocation status */
@@ -179,13 +186,18 @@ struct kmemleak_object {
static LIST_HEAD(object_list);
/* the list of gray-colored objects (see color_gray comment below) */
static LIST_HEAD(gray_list);
+/* the list of objects with alias (see alias comment below) */
+static LIST_HEAD(alias_list);
/* prio search tree for object boundaries */
static struct prio_tree_root object_tree_root;
+/* prio search tree for alias object boundaries */
+static struct prio_tree_root alias_tree_root;
/* rw_lock protecting the access to object_list and prio_tree_root */
static DEFINE_RWLOCK(kmemleak_lock);
/* allocation caches for kmemleak internal data */
static struct kmem_cache *object_cache;
+static struct kmem_cache *alias_cache;
static struct kmem_cache *scan_area_cache;
/* set if tracing memory operations is enabled */
@@ -269,6 +281,8 @@ static void kmemleak_disable(void);
kmemleak_disable(); \
} while (0)
+#define to_address(obj) ((obj)-tree_node.start)
+
/*
* Printing of the objects hex dump to the seq file. The number of lines to be
* printed is limited to HEX_MAX_LINES to prevent seq file spamming. The
@@ -369,7 +383,7 @@ static void dump_object_info(struct kmemleak_object *object)
trace.entries = object-trace;
pr_notice(Object 0x%08lx (size %zu):\n,
- object-tree_node.start, object-size);
+ to_address(object), object-size);
pr_notice( comm \%s\, pid %d, jiffies %lu\n,
object-comm, object-pid, object-jiffies);
pr_notice( min_count = %d\n, object-min_count);
@@ -436,6 +450,8 @@ static void free_object_rcu(struct rcu_head *rcu)
hlist_del(elem);
kmem_cache_free(scan_area_cache, area);
}
+ if (object-alias)
+ kmem_cache_free(alias_cache, object-alias);
kmem_cache_free(object_cache, object);
}
@@ -479,6 +495,41 @@ static struct kmemleak_object
*find_and_get_object(unsigned long ptr, int alias)
return object;
}
+static struct kmemleak_object *find_and_get_object_by_alias(unsigned long ptr,
+ int alias)
+{
+ struct kmemleak_object *object = NULL;
+ struct kmemleak_alias *ao = NULL;
+ struct prio_tree_node *node;
+ struct prio_tree_iter iter;
+ unsigned long flags;
+
+ if (likely(prio_tree_empty(alias_tree_root)))
+ return NULL;
+
+ rcu_read_lock();
+ read_lock_irqsave(kmemleak_lock,
Re: [PATCH] Add OMAP4 Panda support
On Tue, May 18, 2010 at 05:36:36AM +0200, ext Tony Lindgren wrote: Cool, good to see this posted early. However, looks like this can wait until the next merge window though as it was posted so late. should we drop the defconfig, though ? and just add the necessary bits to omap3_defconfig ? -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omap: rx51: board-rx51-peripherals.c updates
On Wed, 26 May 2010 10:30:14 +0300 Jarkko Nikula jhnik...@gmail.com wrote: Hi There are now required sound/soc/ patches in mainline and linux-omap to get basic Nokia N900 audio working. Patch 1/3 is continuation to earlier set, see http://marc.info/?l=linux-omapm=127306914008392w=2 IMO, it should go for 2.6.35 as it's kind of fix for unworking audio due codec being in unknown reset state. Ping? Each of these are for 2.6.36 as the 1/3 doesn't fix any serious regression. -- Jarkko -- 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] Add OMAP4 Panda support
* Felipe Balbi felipe.ba...@nokia.com [100618 09:55]: On Tue, May 18, 2010 at 05:36:36AM +0200, ext Tony Lindgren wrote: Cool, good to see this posted early. However, looks like this can wait until the next merge window though as it was posted so late. should we drop the defconfig, though ? and just add the necessary bits to omap3_defconfig ? Yeah no more defconfig patches until the situation clears on the ARM defconfigs. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: On the APIs for Enabling and Disabling Wakeup capability.
Hi Benoit, I have 2 cases in usb for the need of separate API for setting the auto idle bit. 1. Below the link for omap3430TRM. Please refer 24.1.5.4.2 and 24.1.5.4.3 there is note not to set smart idle and autoidle bit simultaneously. Suggestion is to set the auto idle 0 before setting smart idle. Then set to 1. This applicable for omap4 as well. I don't have the omap4430 pblic TRM to share. http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf 2. There is a Errata in OMAP3 errata #1.59 that If auto idle is set then the USB can't wakeup the system by usb external events. The suggested workaround is to disable the autoIdle for omap3. Regards, Hema -Original Message- From: Cousson, Benoit Sent: Thursday, June 17, 2010 3:04 PM To: Kalliguddi, Hema; Kevin Hilman; Basak, Partha Cc: p...@pwsan.com; Nayak, Rajendra; linux-omap@vger.kernel.org Subject: RE: On the APIs for Enabling and Disabling Wakeup capability. Hi Hema, From: linux-omap-ow...@vger.kernel.org Kevin, There is no errata in the USB which needs the Enable/Disable wakeup to be done Seperately. If it can be handled with omap_devie_enable/idle Apis it is sufficient. But there is a need of setting the Auto idle bit seperately as for the USBOTG there is a need to set the Autoidle only after configuring the smart idle. It is recommended in the TRM not set the auto idle and smart idle together. This I discussed with Partha he sent a mail to you. For setting autoidle there is an api at hwmod layer but not yet omap device layer. Is there a plan to add API at omap device layer for enabling/disabling the autoidle? The whole issue with exposing all the low level stuff at driver level is that the hwmod abstraction become less and less useful. Drivers will start hacking with that for no good reason. And then we will start adding again some omap version specific hacks in the driver. Could you provide the full errata description of that USB_OTG issue? Or at least that TRM part you are talking about. Thanks, Benoit Regards, Hema Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, June 17, 2010 5:56 AM To: Basak, Partha Cc: p...@pwsan.com; Kalliguddi, Hema; Nayak, Rajendra; linux-omap@vger.kernel.org Subject: Re: On the APIs for Enabling and Disabling Wakeup capability. Basak, Partha p-bas...@ti.com writes: I wanted to close on the introduction of two new OMAP device APIs omap_device_enable_wakeup () omap_device_disable_wakeup() in omap_device layer. These APIs are potentially needed by the USB driver (via function pointers) to work around some USB erratum. Alternatively, can we call omap_hwmod_enable_wakeup() via function pointer? Is it agreeable to call these from driver code (via function pointers)in some special cases such as to handle some errata? Hi Partha, First, we need to dig up the Errata details for that USB problem to better understand the USB-specific issue. In addition, Paul and I discussed the option of automatically managing the wakeup during the hwmod enable/idle, since there isn't really a need to have the wakeup enabled when the hwmod is active. Do you see any disadvantages to that? That would be much cleaner than manually managing the wakeup feature per-driver. 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 -- 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] Add OMAP4 Panda support
Hi Felipe, On Jun 18, 2010, at 10:58 AM, Felipe Balbi wrote: should we drop the defconfig, though ? and just add the necessary bits to omap3_defconfig ? When adding support for OMAP4 Panda, and adding the necessary bits to omap3_defconfig, will it be possible to ensure that all OMAP3 devices also work the same, e.g. Gumstix Overo? What about specifics to make Android work in the defconfigs? Best regards, Elvis Dowson -- 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] Add OMAP4 Panda support
On Fri, Jun 18, 2010 at 11:56:02AM +0200, ext Elvis Dowson wrote: When adding support for OMAP4 Panda, and adding the necessary bits to omap3_defconfig, will it be possible to ensure that all OMAP3 devices also work the same, e.g. Gumstix Overo? it should be possible. Ideally all omap2/3/4 boards should boot just fine with omap3_defconfig. What about specifics to make Android work in the defconfigs? I really don't think community should care about Android/MeeGo/Ubuntu etc. -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]OMAP:GPTIMER:1ms tick generation correction
Generation of 1ms granular GPTIMER events using 32KHz or system clocks
as inputs does not have whole number count value to loaded into the register.
This inaccurate count value with respect to 1ms period leads to time drift
subsequently. OMAP3 and later silicones have dedicated registers for GPTIMER1,
GPTIMER2 and GPTIMER10, which can be programmed with computed values to keep
this error controlled within specified limit.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 99 ++---
arch/arm/plat-omap/include/plat/dmtimer.h |1 +
2 files changed, 64 insertions(+), 36 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
old mode 100644
new mode 100755
index c64875f..0d7d85a
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -160,6 +160,9 @@ struct omap_dm_timer {
unsigned reserved:1;
unsigned enabled:1;
unsigned posted:1;
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ unsigned ms_correction:1;
+#endif
};
static int dm_timer_count;
@@ -185,18 +188,18 @@ static const int omap1_dm_timer_count =
ARRAY_SIZE(omap1_dm_timers);
#ifdef CONFIG_ARCH_OMAP2
static struct omap_dm_timer omap2_dm_timers[] = {
- { .phys_base = 0x48028000, .irq = INT_24XX_GPTIMER1 },
- { .phys_base = 0x4802a000, .irq = INT_24XX_GPTIMER2 },
- { .phys_base = 0x48078000, .irq = INT_24XX_GPTIMER3 },
- { .phys_base = 0x4807a000, .irq = INT_24XX_GPTIMER4 },
- { .phys_base = 0x4807c000, .irq = INT_24XX_GPTIMER5 },
- { .phys_base = 0x4807e000, .irq = INT_24XX_GPTIMER6 },
- { .phys_base = 0x4808, .irq = INT_24XX_GPTIMER7 },
- { .phys_base = 0x48082000, .irq = INT_24XX_GPTIMER8 },
- { .phys_base = 0x48084000, .irq = INT_24XX_GPTIMER9 },
- { .phys_base = 0x48086000, .irq = INT_24XX_GPTIMER10 },
- { .phys_base = 0x48088000, .irq = INT_24XX_GPTIMER11 },
- { .phys_base = 0x4808a000, .irq = INT_24XX_GPTIMER12 },
+ { .phys_base = 0x48028000, .irq = INT_24XX_GPTIMER1, .ms_correction = 0
},
+ { .phys_base = 0x4802a000, .irq = INT_24XX_GPTIMER2, .ms_correction = 0
},
+ { .phys_base = 0x48078000, .irq = INT_24XX_GPTIMER3, .ms_correction = 0
},
+ { .phys_base = 0x4807a000, .irq = INT_24XX_GPTIMER4, .ms_correction = 0
},
+ { .phys_base = 0x4807c000, .irq = INT_24XX_GPTIMER5, .ms_correction = 0
},
+ { .phys_base = 0x4807e000, .irq = INT_24XX_GPTIMER6, .ms_correction = 0
},
+ { .phys_base = 0x4808, .irq = INT_24XX_GPTIMER7, .ms_correction = 0
},
+ { .phys_base = 0x48082000, .irq = INT_24XX_GPTIMER8, .ms_correction = 0
},
+ { .phys_base = 0x48084000, .irq = INT_24XX_GPTIMER9, .ms_correction = 0
},
+ { .phys_base = 0x48086000, .irq = INT_24XX_GPTIMER10, .ms_correction =
0 },
+ { .phys_base = 0x48088000, .irq = INT_24XX_GPTIMER11, .ms_correction =
0 },
+ { .phys_base = 0x4808a000, .irq = INT_24XX_GPTIMER12, .ms_correction =
0 },
};
static const char *omap2_dm_source_names[] __initdata = {
@@ -218,18 +221,18 @@ static const int omap2_dm_timer_count =
ARRAY_SIZE(omap2_dm_timers);
#ifdef CONFIG_ARCH_OMAP3
static struct omap_dm_timer omap3_dm_timers[] = {
- { .phys_base = 0x48318000, .irq = INT_24XX_GPTIMER1 },
- { .phys_base = 0x49032000, .irq = INT_24XX_GPTIMER2 },
- { .phys_base = 0x49034000, .irq = INT_24XX_GPTIMER3 },
- { .phys_base = 0x49036000, .irq = INT_24XX_GPTIMER4 },
- { .phys_base = 0x49038000, .irq = INT_24XX_GPTIMER5 },
- { .phys_base = 0x4903A000, .irq = INT_24XX_GPTIMER6 },
- { .phys_base = 0x4903C000, .irq = INT_24XX_GPTIMER7 },
- { .phys_base = 0x4903E000, .irq = INT_24XX_GPTIMER8 },
- { .phys_base = 0x4904, .irq = INT_24XX_GPTIMER9 },
- { .phys_base = 0x48086000, .irq = INT_24XX_GPTIMER10 },
- { .phys_base = 0x48088000, .irq = INT_24XX_GPTIMER11 },
- { .phys_base = 0x48304000, .irq = INT_34XX_GPT12_IRQ },
+ { .phys_base = 0x48318000, .irq = INT_24XX_GPTIMER1, .ms_correction = 1
},
+ { .phys_base = 0x49032000, .irq = INT_24XX_GPTIMER2, .ms_correction = 1
},
+ { .phys_base = 0x49034000, .irq = INT_24XX_GPTIMER3, .ms_correction = 0
},
+ { .phys_base = 0x49036000, .irq = INT_24XX_GPTIMER4, .ms_correction = 0
},
+ { .phys_base = 0x49038000, .irq = INT_24XX_GPTIMER5, .ms_correction = 0
},
+ { .phys_base = 0x4903A000, .irq = INT_24XX_GPTIMER6, .ms_correction = 0
},
+ { .phys_base = 0x4903C000, .irq = INT_24XX_GPTIMER7, .ms_correction = 0
},
+ { .phys_base = 0x4903E001, .irq = INT_24XX_GPTIMER8, .ms_correction = 0
},
+ { .phys_base = 0x4904, .irq = INT_24XX_GPTIMER9, .ms_correction = 0
},
+ { .phys_base = 0x48086000, .irq = INT_24XX_GPTIMER10, .ms_correction =
1 },
+ { .phys_base = 0x48088000, .irq = INT_24XX_GPTIMER11,
Re: [PATCH]OMAP:GPTIMER:1ms tick generation correction
DebBarma, Tarun Kanti had written, on 06/18/2010 07:17 AM, the following:
Generation of 1ms granular GPTIMER events using 32KHz or system clocks
as inputs does not have whole number count value to loaded into the register.
This inaccurate count value with respect to 1ms period leads to time drift
subsequently. OMAP3 and later silicones have dedicated registers for GPTIMER1,
GPTIMER2 and GPTIMER10, which can be programmed with computed values to keep
this error controlled within specified limit.
I could go on and on on the evils of 70 character emails and worst of
all 70 character commit messages :). but it will suffice to say please
fix ur editor for keeping your commit messages 70 chars.
I recommend reading:
http://omapedia.org/wiki/Releasing_to_Linux_kernel_using_patches_and_emails
esp:
http://userweb.kernel.org/~akpm/stuff/tpp.txt
also typos on silicone Vs silcon ;)
few suggestions below:
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 99 ++---
arch/arm/plat-omap/include/plat/dmtimer.h |1 +
2 files changed, 64 insertions(+), 36 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
old mode 100644
new mode 100755
index c64875f..0d7d85a
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -160,6 +160,9 @@ struct omap_dm_timer {
unsigned reserved:1;
unsigned enabled:1;
unsigned posted:1;
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ unsigned ms_correction:1;
+#endif
};
static int dm_timer_count;
@@ -185,18 +188,18 @@ static const int omap1_dm_timer_count =
ARRAY_SIZE(omap1_dm_timers);
#ifdef CONFIG_ARCH_OMAP2
static struct omap_dm_timer omap2_dm_timers[] = {
- { .phys_base = 0x48028000, .irq = INT_24XX_GPTIMER1 },
- { .phys_base = 0x4802a000, .irq = INT_24XX_GPTIMER2 },
- { .phys_base = 0x48078000, .irq = INT_24XX_GPTIMER3 },
- { .phys_base = 0x4807a000, .irq = INT_24XX_GPTIMER4 },
- { .phys_base = 0x4807c000, .irq = INT_24XX_GPTIMER5 },
- { .phys_base = 0x4807e000, .irq = INT_24XX_GPTIMER6 },
- { .phys_base = 0x4808, .irq = INT_24XX_GPTIMER7 },
- { .phys_base = 0x48082000, .irq = INT_24XX_GPTIMER8 },
- { .phys_base = 0x48084000, .irq = INT_24XX_GPTIMER9 },
- { .phys_base = 0x48086000, .irq = INT_24XX_GPTIMER10 },
- { .phys_base = 0x48088000, .irq = INT_24XX_GPTIMER11 },
- { .phys_base = 0x4808a000, .irq = INT_24XX_GPTIMER12 },
+ { .phys_base = 0x48028000, .irq = INT_24XX_GPTIMER1, .ms_correction = 0
},
+ { .phys_base = 0x4802a000, .irq = INT_24XX_GPTIMER2, .ms_correction = 0
},
+ { .phys_base = 0x48078000, .irq = INT_24XX_GPTIMER3, .ms_correction = 0
},
+ { .phys_base = 0x4807a000, .irq = INT_24XX_GPTIMER4, .ms_correction = 0
},
+ { .phys_base = 0x4807c000, .irq = INT_24XX_GPTIMER5, .ms_correction = 0
},
+ { .phys_base = 0x4807e000, .irq = INT_24XX_GPTIMER6, .ms_correction = 0
},
+ { .phys_base = 0x4808, .irq = INT_24XX_GPTIMER7, .ms_correction = 0
},
+ { .phys_base = 0x48082000, .irq = INT_24XX_GPTIMER8, .ms_correction = 0
},
+ { .phys_base = 0x48084000, .irq = INT_24XX_GPTIMER9, .ms_correction = 0
},
+ { .phys_base = 0x48086000, .irq = INT_24XX_GPTIMER10, .ms_correction =
0 },
+ { .phys_base = 0x48088000, .irq = INT_24XX_GPTIMER11, .ms_correction =
0 },
+ { .phys_base = 0x4808a000, .irq = INT_24XX_GPTIMER12, .ms_correction =
0 },
NAK - static structs are default to 0 for fields you dont explicitly
assign.
};
static const char *omap2_dm_source_names[] __initdata = {
@@ -218,18 +221,18 @@ static const int omap2_dm_timer_count =
ARRAY_SIZE(omap2_dm_timers);
#ifdef CONFIG_ARCH_OMAP3
static struct omap_dm_timer omap3_dm_timers[] = {
- { .phys_base = 0x48318000, .irq = INT_24XX_GPTIMER1 },
- { .phys_base = 0x49032000, .irq = INT_24XX_GPTIMER2 },
- { .phys_base = 0x49034000, .irq = INT_24XX_GPTIMER3 },
- { .phys_base = 0x49036000, .irq = INT_24XX_GPTIMER4 },
- { .phys_base = 0x49038000, .irq = INT_24XX_GPTIMER5 },
- { .phys_base = 0x4903A000, .irq = INT_24XX_GPTIMER6 },
- { .phys_base = 0x4903C000, .irq = INT_24XX_GPTIMER7 },
- { .phys_base = 0x4903E000, .irq = INT_24XX_GPTIMER8 },
- { .phys_base = 0x4904, .irq = INT_24XX_GPTIMER9 },
- { .phys_base = 0x48086000, .irq = INT_24XX_GPTIMER10 },
- { .phys_base = 0x48088000, .irq = INT_24XX_GPTIMER11 },
- { .phys_base = 0x48304000, .irq = INT_34XX_GPT12_IRQ },
+ { .phys_base = 0x48318000, .irq = INT_24XX_GPTIMER1, .ms_correction = 1
},
+ { .phys_base = 0x49032000, .irq = INT_24XX_GPTIMER2, .ms_correction = 1
},
+ { .phys_base = 0x49034000, .irq = INT_24XX_GPTIMER3, .ms_correction = 0
},
+ { .phys_base = 0x49036000, .irq = INT_24XX_GPTIMER4, .ms_correction = 0
Re: [PATCH] Add OMAP4 Panda support
Anders, David x0132...@ti.com writes:
Add initial support for the OMAP4430 based Panda board.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/configs/omap4_panda_defconfig | 1094
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda.c | 80 +++
4 files changed, 1179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/omap4_panda_defconfig
create mode 100644 arch/arm/mach-omap2/board-omap4panda.c
[...]
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
new file mode 100644
index 000..95faec0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -0,0 +1,80 @@
+/*
+ * Board support file for OMAP4430 based Panda.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Based on mach-omap2/board-4430sdp.c
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Based on mach-omap2/board-3430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+
+#include mach/hardware.h
+#include mach/omap4-common.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/control.h
+#include plat/timer-gp.h
+#include plat/usb.h
+
+static void __init omap4_panda_init_irq(void)
+{
+ omap2_init_common_hw(NULL, NULL);
+#ifdef CONFIG_OMAP_32K_TIMER
+ omap2_gp_clockevent_set_gptimer(1);
+#endif
+ gic_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_UTMI,
+ .mode = MUSB_PERIPHERAL,
+ .power = 100,
+};
+
+static void __init omap4_panda_init(void)
+{
+ omap_serial_init();
+ /* OMAP4 SDP uses internal transceiver so register nop transceiver */
SDP?
+ usb_nop_xceiv_register();
+ /* FIXME: allow multi-omap to boot until musb is updated for omap4 */
+ if (!cpu_is_omap44xx())
+ usb_musb_init(musb_board_data);
+
+}
+
+static void __init omap4_panda_map_io(void)
+{
+ omap2_set_globals_443x();
+ omap44xx_map_common_io();
+}
+
+MACHINE_START(OMAP4_PANDA, OMAP4 Panda board)
+ /* Maintainer: David Anders - Texas Instruments Inc */
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xfa00) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap4_panda_map_io,
+ .init_irq = omap4_panda_init_irq,
+ .init_machine = omap4_panda_init,
+ .timer = omap_timer,
+MACHINE_END
IIUC, Panda was built to be compatible with the SDP/Blaze, right?
If so, is there any reason we can't support both boards from the same
board file?
Just add the above MACHINE_START.._END section to board-4430sdp.c to handle
the both machine IDs, but all the functions could be common.
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] Add OMAP4 Panda support
Kevin,
The panda isn't 100% compatible with the blaze/sdp. There are/will be some
significant differences. I understand the goal to make the multi-boot images
and to reduce the amount of duplicated code in the kernel, however we can learn
a little about this situation from the BeagleBoard. Due to it being a
development board, many people who are new to embedded development will be
purchasing the Panda and they generally need a clearly defined place to start.
Blaze and SDP are officially support TI products and their machine files can be
easily groomed and maintained. Having a clearly defined individual machine file
and defconfig will make things a lot easier for starting development on the
Panda.
IMHO, I think it is a giant mistake not to have individual machine files and
defconfigs for the panda. This doesn't preclude making sure that they files
work properly with multi-boot images.
Dave
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 18, 2010 9:32 AM
To: Anders, David
Cc: linux-omap@vger.kernel.org; t...@atomide.com
Subject: Re: [PATCH] Add OMAP4 Panda support
Anders, David x0132...@ti.com writes:
Add initial support for the OMAP4430 based Panda board.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/configs/omap4_panda_defconfig | 1094
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda.c | 80 +++
4 files changed, 1179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/omap4_panda_defconfig
create mode 100644 arch/arm/mach-omap2/board-omap4panda.c
[...]
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
new file mode 100644
index 000..95faec0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -0,0 +1,80 @@
+/*
+ * Board support file for OMAP4430 based Panda.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Based on mach-omap2/board-4430sdp.c
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Based on mach-omap2/board-3430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+
+#include mach/hardware.h
+#include mach/omap4-common.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/control.h
+#include plat/timer-gp.h
+#include plat/usb.h
+
+static void __init omap4_panda_init_irq(void)
+{
+ omap2_init_common_hw(NULL, NULL);
+#ifdef CONFIG_OMAP_32K_TIMER
+ omap2_gp_clockevent_set_gptimer(1);
+#endif
+ gic_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_UTMI,
+ .mode = MUSB_PERIPHERAL,
+ .power = 100,
+};
+
+static void __init omap4_panda_init(void)
+{
+ omap_serial_init();
+ /* OMAP4 SDP uses internal transceiver so register nop transceiver */
SDP?
+ usb_nop_xceiv_register();
+ /* FIXME: allow multi-omap to boot until musb is updated for omap4 */
+ if (!cpu_is_omap44xx())
+ usb_musb_init(musb_board_data);
+
+}
+
+static void __init omap4_panda_map_io(void)
+{
+ omap2_set_globals_443x();
+ omap44xx_map_common_io();
+}
+
+MACHINE_START(OMAP4_PANDA, OMAP4 Panda board)
+ /* Maintainer: David Anders - Texas Instruments Inc */
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xfa00) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap4_panda_map_io,
+ .init_irq = omap4_panda_init_irq,
+ .init_machine = omap4_panda_init,
+ .timer = omap_timer,
+MACHINE_END
IIUC, Panda was built to be compatible with the SDP/Blaze, right?
If so, is there any reason we can't support both boards from the same
board file?
Just add the above MACHINE_START.._END section to board-4430sdp.c to handle
the both machine IDs, but all the functions could be common.
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: On the APIs for Enabling and Disabling Wakeup capability.
Kalliguddi, Hema hem...@ti.com writes: Hi Benoit, I have 2 cases in usb for the need of separate API for setting the auto idle bit. 1. Below the link for omap3430TRM. Please refer 24.1.5.4.2 and 24.1.5.4.3 there is note not to set smart idle and autoidle bit simultaneously. Suggestion is to set the auto idle 0 before setting smart idle. Then set to 1. Maybe this sequence should be enforced by the hwmod code itself, rather than the knowledge living in the driver. However, based on the errata below, auto-idle will always be zero so the there should be no conflict in setting smart-idle and auto-idle simultaneously today. This applicable for omap4 as well. I don't have the omap4430 pblic TRM to share. http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf 2. There is a Errata in OMAP3 errata #1.59 that If auto idle is set then the USB can't wakeup the system by usb external events. The suggested workaround is to disable the autoIdle for omap3. This one could be handled at init time in usb-musb.c by setting HWMOD_NO_OCP_AUTOIDLE for the hwmod with a comment summarizing this errata. Note also that Errata 1.166 is another one related to MUSB auto-idle and we have a workaround in the PM branch to ensure that MUSB auto-idle is disabled in the idle path since it may be re-enabled after an off-mode transition. Kevin -Original Message- From: Cousson, Benoit Sent: Thursday, June 17, 2010 3:04 PM To: Kalliguddi, Hema; Kevin Hilman; Basak, Partha Cc: p...@pwsan.com; Nayak, Rajendra; linux-omap@vger.kernel.org Subject: RE: On the APIs for Enabling and Disabling Wakeup capability. Hi Hema, From: linux-omap-ow...@vger.kernel.org Kevin, There is no errata in the USB which needs the Enable/Disable wakeup to be done Seperately. If it can be handled with omap_devie_enable/idle Apis it is sufficient. But there is a need of setting the Auto idle bit seperately as for the USBOTG there is a need to set the Autoidle only after configuring the smart idle. It is recommended in the TRM not set the auto idle and smart idle together. This I discussed with Partha he sent a mail to you. For setting autoidle there is an api at hwmod layer but not yet omap device layer. Is there a plan to add API at omap device layer for enabling/disabling the autoidle? The whole issue with exposing all the low level stuff at driver level is that the hwmod abstraction become less and less useful. Drivers will start hacking with that for no good reason. And then we will start adding again some omap version specific hacks in the driver. Could you provide the full errata description of that USB_OTG issue? Or at least that TRM part you are talking about. Thanks, Benoit Regards, Hema Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, June 17, 2010 5:56 AM To: Basak, Partha Cc: p...@pwsan.com; Kalliguddi, Hema; Nayak, Rajendra; linux-omap@vger.kernel.org Subject: Re: On the APIs for Enabling and Disabling Wakeup capability. Basak, Partha p-bas...@ti.com writes: I wanted to close on the introduction of two new OMAP device APIs omap_device_enable_wakeup () omap_device_disable_wakeup() in omap_device layer. These APIs are potentially needed by the USB driver (via function pointers) to work around some USB erratum. Alternatively, can we call omap_hwmod_enable_wakeup() via function pointer? Is it agreeable to call these from driver code (via function pointers)in some special cases such as to handle some errata? Hi Partha, First, we need to dig up the Errata details for that USB problem to better understand the USB-specific issue. In addition, Paul and I discussed the option of automatically managing the wakeup during the hwmod enable/idle, since there isn't really a need to have the wakeup enabled when the hwmod is active. Do you see any disadvantages to that? That would be much cleaner than manually managing the wakeup feature per-driver. 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 -- 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] Add OMAP4 Panda support
[please don't top-post: http://elinux.org/Netiquette]
Anders, David x0132...@ti.com writes:
The panda isn't 100% compatible with the blaze/sdp. There are/will
be some significant differences. I understand the goal to make the
multi-boot images and to reduce the amount of duplicated code in
the kernel, however we can learn a little about this situation from
the BeagleBoard. Due to it being a development board, many people
who are new to embedded development will be purchasing the Panda and
they generally need a clearly defined place to start. Blaze and SDP
are officially support TI products and their machine files can be
easily groomed and maintained. Having a clearly defined individual
machine file and defconfig will make things a lot easier for
starting development on the Panda.
IMHO, I think it is a giant mistake not to have individual machine
files and defconfigs for the panda. This doesn't preclude making
sure that they files work properly with multi-boot images.
In my view, all this helps argue the case for having shared code
instead of the copy-paste duplicating.
I am not opposed to having a separate board file for Panda. What I am
opposed to is having a separate board file if it's mostly identical to
another board.
If Panda and Blaze are mostly the same, they should share the same
board code and use their separate board files to express their
differences. See how this was done for Zoom2 and Zoom3 which have a
shared set of peripherals and also a shared debug board.
When customers go to build their designs based on Panda, they can
still start from the Panda board file and start hacking away. These
custom boards will then also use the shared common code instead of
duplicating.
Kevin
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 18, 2010 9:32 AM
To: Anders, David
Cc: linux-omap@vger.kernel.org; t...@atomide.com
Subject: Re: [PATCH] Add OMAP4 Panda support
Anders, David x0132...@ti.com writes:
Add initial support for the OMAP4430 based Panda board.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/configs/omap4_panda_defconfig | 1094
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda.c | 80 +++
4 files changed, 1179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/omap4_panda_defconfig
create mode 100644 arch/arm/mach-omap2/board-omap4panda.c
[...]
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
new file mode 100644
index 000..95faec0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -0,0 +1,80 @@
+/*
+ * Board support file for OMAP4430 based Panda.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Based on mach-omap2/board-4430sdp.c
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Based on mach-omap2/board-3430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+
+#include mach/hardware.h
+#include mach/omap4-common.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/control.h
+#include plat/timer-gp.h
+#include plat/usb.h
+
+static void __init omap4_panda_init_irq(void)
+{
+ omap2_init_common_hw(NULL, NULL);
+#ifdef CONFIG_OMAP_32K_TIMER
+ omap2_gp_clockevent_set_gptimer(1);
+#endif
+ gic_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_UTMI,
+ .mode = MUSB_PERIPHERAL,
+ .power = 100,
+};
+
+static void __init omap4_panda_init(void)
+{
+ omap_serial_init();
+ /* OMAP4 SDP uses internal transceiver so register nop transceiver */
SDP?
+ usb_nop_xceiv_register();
+ /* FIXME: allow multi-omap to boot until musb is updated for omap4 */
+ if (!cpu_is_omap44xx())
+ usb_musb_init(musb_board_data);
+
+}
+
+static void __init omap4_panda_map_io(void)
+{
+ omap2_set_globals_443x();
+ omap44xx_map_common_io();
+}
+
+MACHINE_START(OMAP4_PANDA, OMAP4 Panda board)
+ /* Maintainer: David Anders - Texas Instruments Inc */
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xfa00) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap4_panda_map_io,
+ .init_irq = omap4_panda_init_irq,
RE: [PATCH] Add OMAP4 Panda support
IIUC, Panda was built to be compatible with the SDP/Blaze, right? If so, is there any reason we can't support both boards from the same board file? Just add the above MACHINE_START.._END section to board-4430sdp.c to handle the both machine IDs, but all the functions could be common. Nope, the Blaze was built to be compatible with the SDP. The Panda is the beagleboard-like OMAP4 board. - 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] Add OMAP4 Panda support
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 18, 2010 10:14 AM
To: Anders, David
Cc: linux-omap@vger.kernel.org; t...@atomide.com
Subject: Re: [PATCH] Add OMAP4 Panda support
[please don't top-post: http://elinux.org/Netiquette]
Anders, David x0132...@ti.com writes:
The panda isn't 100% compatible with the blaze/sdp. There are/will
be some significant differences. I understand the goal to make the
multi-boot images and to reduce the amount of duplicated code in
the kernel, however we can learn a little about this situation from
the BeagleBoard. Due to it being a development board, many people
who are new to embedded development will be purchasing the Panda and
they generally need a clearly defined place to start. Blaze and SDP
are officially support TI products and their machine files can be
easily groomed and maintained. Having a clearly defined individual
machine file and defconfig will make things a lot easier for
starting development on the Panda.
IMHO, I think it is a giant mistake not to have individual machine
files and defconfigs for the panda. This doesn't preclude making
sure that they files work properly with multi-boot images.
In my view, all this helps argue the case for having shared code
instead of the copy-paste duplicating.
I am not opposed to having a separate board file for Panda. What I am
opposed to is having a separate board file if it's mostly identical to
another board.
If Panda and Blaze are mostly the same, they should share the same
board code and use their separate board files to express their
differences. See how this was done for Zoom2 and Zoom3 which have a
shared set of peripherals and also a shared debug board.
When customers go to build their designs based on Panda, they can
still start from the Panda board file and start hacking away. These
custom boards will then also use the shared common code instead of
duplicating.
Kevin
Panda will have different Ethernet, different video outputs, different usb host
controller configurations, and a number of different pin muxes. Is there a
quantitative way of deciding if there are enough similarities/differences
between boards for having combined/individual machine files?
I agree that Blaze and SDP are similar enough not to have separate files.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 18, 2010 9:32 AM
To: Anders, David
Cc: linux-omap@vger.kernel.org; t...@atomide.com
Subject: Re: [PATCH] Add OMAP4 Panda support
Anders, David x0132...@ti.com writes:
Add initial support for the OMAP4430 based Panda board.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/configs/omap4_panda_defconfig | 1094
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda.c | 80 +++
4 files changed, 1179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/omap4_panda_defconfig
create mode 100644 arch/arm/mach-omap2/board-omap4panda.c
[...]
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-
omap2/board-omap4panda.c
new file mode 100644
index 000..95faec0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -0,0 +1,80 @@
+/*
+ * Board support file for OMAP4430 based Panda.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Based on mach-omap2/board-4430sdp.c
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Based on mach-omap2/board-3430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+
+#include mach/hardware.h
+#include mach/omap4-common.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/control.h
+#include plat/timer-gp.h
+#include plat/usb.h
+
+static void __init omap4_panda_init_irq(void)
+{
+ omap2_init_common_hw(NULL, NULL);
+#ifdef CONFIG_OMAP_32K_TIMER
+ omap2_gp_clockevent_set_gptimer(1);
+#endif
+ gic_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_UTMI,
+ .mode = MUSB_PERIPHERAL,
+ .power = 100,
+};
+
+static void __init omap4_panda_init(void)
+{
+ omap_serial_init();
+ /* OMAP4 SDP
Re: [PATCH] Add OMAP4 Panda support
Anders, David x0132...@ti.com writes:
The panda isn't 100% compatible with the blaze/sdp. There are/will
be some significant differences. I understand the goal to make the
multi-boot images and to reduce the amount of duplicated code in
the kernel, however we can learn a little about this situation from
the BeagleBoard. Due to it being a development board, many people
who are new to embedded development will be purchasing the Panda and
they generally need a clearly defined place to start. Blaze and SDP
are officially support TI products and their machine files can be
easily groomed and maintained. Having a clearly defined individual
machine file and defconfig will make things a lot easier for
starting development on the Panda.
IMHO, I think it is a giant mistake not to have individual machine
files and defconfigs for the panda. This doesn't preclude making
sure that they files work properly with multi-boot images.
In my view, all this helps argue the case for having shared code
instead of the copy-paste duplicating.
I am not opposed to having a separate board file for Panda. What I am
opposed to is having a separate board file if it's mostly identical to
another board.
If Panda and Blaze are mostly the same, they should share the same
board code and use their separate board files to express their
differences. See how this was done for Zoom2 and Zoom3 which have a
shared set of peripherals and also a shared debug board.
When customers go to build their designs based on Panda, they can
still start from the Panda board file and start hacking away. These
custom boards will then also use the shared common code instead of
duplicating.
Kevin
Panda will have different Ethernet, different video outputs,
different usb host controller configurations, and a number of
different pin muxes. Is there a quantitative way of deciding if
there are enough similarities/differences between boards for having
combined/individual machine files?
Not really more of a feeling.
But these feel like important enough differences to merit a separate
board file. I was under the impression that there was a lot more in
common.
So, I'm OK with the separate board file, please fix up the minor comments
below...
I agree that Blaze and SDP are similar enough not to have separate files.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 18, 2010 9:32 AM
To: Anders, David
Cc: linux-omap@vger.kernel.org; t...@atomide.com
Subject: Re: [PATCH] Add OMAP4 Panda support
Anders, David x0132...@ti.com writes:
Add initial support for the OMAP4430 based Panda board.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/configs/omap4_panda_defconfig | 1094
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda.c | 80 +++
4 files changed, 1179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/omap4_panda_defconfig
create mode 100644 arch/arm/mach-omap2/board-omap4panda.c
[...]
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-
omap2/board-omap4panda.c
new file mode 100644
index 000..95faec0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -0,0 +1,80 @@
+/*
+ * Board support file for OMAP4430 based Panda.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Based on mach-omap2/board-4430sdp.c
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Based on mach-omap2/board-3430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+
+#include mach/hardware.h
+#include mach/omap4-common.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/control.h
+#include plat/timer-gp.h
+#include plat/usb.h
+
+static void __init omap4_panda_init_irq(void)
+{
+ omap2_init_common_hw(NULL, NULL);
+#ifdef CONFIG_OMAP_32K_TIMER
+ omap2_gp_clockevent_set_gptimer(1);
+#endif
This part is not needed (here or in board-4430sdp.c) as the default
timer is already 1.
+ gic_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_UTMI,
+ .mode = MUSB_PERIPHERAL,
+ .power = 100,
+};
+
+static void __init omap4_panda_init(void)
Re: [PATCH 2/5] OMAP: hwmod: if IDLEST fields are not set, use module defaults
Kevin Hilman khil...@deeprootsystems.com writes:
In the _setup() hook, check for valid IDLEST fields. If not set, use
the module defaults since they are the same as the module defaults
for most hwmods.
Problem found because _wait_target_ready() will fail if IDLEST
fields are not valid.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
FYI... dropping this patch in favor of simply updating the hwmod data
files to have valid idlest_* fields.
Kevin
arch/arm/mach-omap2/omap_hwmod.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index a127c9b..77fef90 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1036,6 +1036,12 @@ static int _setup(struct omap_hwmod *oh)
oh-_state = _HWMOD_STATE_INITIALIZED;
+ /* if IDLEST values are not set, use module defaults */
+ if (!oh-prcm.omap2.idlest_reg_id)
+ oh-prcm.omap2.idlest_reg_id = oh-prcm.omap2.prcm_reg_id;
+ if (!oh-prcm.omap2.idlest_idle_bit)
+ oh-prcm.omap2.idlest_idle_bit = oh-prcm.omap2.module_bit;
+
r = _enable(oh);
if (r) {
pr_warning(omap_hwmod: %s: cannot be enabled (%d)\n,
--
1.7.0.2
--
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] DSS2 Include VRFB into omap2-3build only
Senthil, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Monday, May 10, 2010 3:03 AM To: Guruswamy, Senthilvadivu Cc: linux-omap@vger.kernel.org; linux-fbdev-de...@lists.sourceforge.net; t...@atomide.com; tomi.valkei...@nokia.com; Hiremath, Vaibhav Subject: Re: [PATCH] DSS2 Include VRFB into omap2-3build only Op 10 mei 2010, om 10:01 heeft Guruswamy, Senthilvadivu het volgende geschreven: Building a multi-omap kernel is not impacted as long as the display is not choosen in the build. Usually display is chosen from the board file. Solving this problem involves doing these selections in run time, NOT in build time. One of the solutions for this is to provide all this selections as part of some platform driver data. It _should_ be possible to build DSS2, VRFB AND Tiler code at the same time for a multi-omap build, and be executed selectively, depending on your silicon detection and board code execution. If you need to deselect it to succeed, then it's broken for multi-omap builds. That's the core problem and it hasn't been addressed until date. Regards, Sergio So you are saying it *IS* broken when wanting vrfb on omap3 and tiler on omap4, right? -Original Message- From: Koen Kooi [mailto:k...@dominion.thruhere.net] Sent: Monday, May 10, 2010 1:10 PM To: Guruswamy, Senthilvadivu Cc: linux-omap@vger.kernel.org; linux-fbdev-de...@lists.sourceforge.net; t...@atomide.com; tomi.valkei...@nokia.com; Hiremath, Vaibhav Subject: Re: [PATCH] DSS2 Include VRFB into omap2-3build only Op 10 mei 2010, om 08:48 heeft Senthilvadivu Guruswamy het volgende geschreven: Exclude VRFB from OMAP4 onwards and include only for OMAP2 and OMAP3 builds. In OMAP4 VRFB HW IP is replaced with a new HW IP TILER --- a/drivers/video/omap2/Kconfig +++ b/drivers/video/omap2/Kconfig @@ -3,6 +3,10 @@ config OMAP2_VRAM config OMAP2_VRFB bool + depends on FB_OMAP2 (!ARCH_OMAP4) + default y if (ARCH_OMAP2 || ARCH_OMAP3) + help + OMAP VRFB buffer support is efficient for rotation How does this work for multi-omap kernels, e.g. building a kernel with beagle and panda support? regards, Koen -- 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: [pm-wip/uart][PATCH 0/5 v2] Serial HWMOD updation and uart4 support for 3630
Kevin Hilman khil...@deeprootsystems.com writes: Govindraj.R govindraj.r...@ti.com writes: Changes from v1: * Incorporated : OMAP clock: Add uart4_ick/fck definitions for 3630 * using omap_mux_request_signal to retreive padconf offset as per Tony's comments. http://marc.info/?l=linux-omapm=127609369220618w=2 This patch series as a dependecy on the patch for omap_mux_request_signal posted earlier https://patchwork.kernel.org/patch/105962/ * Clean up certain comments. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30348.html Patch series is based on remotes/origin/pm-wip/uart branch from Kevin's PM tree. 1.) Add support for UART4 for 3630. 2.) Modify Serial hwmod to avoid hwmod lookup using name string. Govindraj.R (5): OMAP clock: Add uart4_ick/fck definitions for 3630 OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs OMAP3: serial: Fix uart4 handling for 3630 OMAP3: PM: Add prepare idle and resume idle call for uart4 Serial: Avoid using hwmod lookup using name string. Govindraj, Can you add this one to your series and test it on your boards? Actually, my patch doesn't really work either, so it needs some more digging. Basically, there's a problem during static suspend on boards like Zoom3 that don't ever add/register any OMAP UARTs and just use the ones on the debug board. Somehow, we have to keep from adding UARTs to the uart_list unless they are actually registered to board files. 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: [pm-wip/uart][PATCH 5/5 v2] Serial: Avoid using hwmod lookup using name string
Govindraj.R govindraj.r...@ti.com writes:
Avoid using hwmod lookup using name string rather
retreive port info using the hwmod class interface.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 71 ++---
1 files changed, 31 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 128e19b..0380ac8 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -56,8 +56,6 @@
*/
#define DEFAULT_TIMEOUT 0
-#define MAX_UART_HWMOD_NAME_LEN 16
-
struct omap_uart_state {
int num;
int can_sleep;
@@ -601,52 +599,45 @@ static void serial_out_override(struct uart_port *up,
int offset, int value)
}
#endif
-void __init omap_serial_early_init(void)
+static int omap_serial_port_init(struct omap_hwmod *oh, void *user)
{
- int i = 0;
+ struct omap_uart_state *uart;
+ static int i;
- do {
- char oh_name[MAX_UART_HWMOD_NAME_LEN];
- struct omap_hwmod *oh;
- struct omap_uart_state *uart;
+ uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
+ if (WARN_ON(!uart))
+ return -ENOMEM;
- snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
- uart%d, i + 1);
- oh = omap_hwmod_lookup(oh_name);
- if (!oh)
- break;
+ uart-oh = oh;
+ uart-num = i++;
Rather than use a static int for this, you could just use 'num_uarts'
+ list_add_tail(uart-node, uart_list);
+ num_uarts++;
- uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
- if (WARN_ON(!uart))
- return;
+ /*
+ * During UART early init, device need to be probed
+ * to determine SoC specific init before omap_device
+ * is ready. Therefore, don't allow idle here
+ */
extra blank line
- uart-oh = oh;
- uart-num = i++;
- list_add_tail(uart-node, uart_list);
- num_uarts++;
+ uart-oh-flags |= HWMOD_INIT_NO_IDLE;
- /*
- * NOTE: omap_hwmod_init() has not yet been called,
- * so no hwmod functions will work yet.
- */
+ /*
+ * Since UART hwmod is idle/enabled inside the
+ * idle loop, interrupts are already disabled and
+ * thus no locking is needed. Since the mutex-based
+ * locking in hwmod might sleep, allowing locking
+ * may introduce problems.
+ */
extra blank line
- /*
- * During UART early init, device need to be probed
- * to determine SoC specific init before omap_device
- * is ready. Therefore, don't allow idle here
- */
- uart-oh-flags |= HWMOD_INIT_NO_IDLE;
-
- /*
- * Since UART hwmod is idle/enabled inside the
- * idle loop, interrupts are already disabled and
- * thus no locking is needed. Since the mutex-based
- * locking in hwmod might sleep, allowing locking
- * may introduce problems.
- */
- uart-oh-flags |= HWMOD_NO_IDLE_LOCKING;
+ uart-oh-flags |= HWMOD_NO_IDLE_LOCKING;
- } while (1);
+ return 0;
+}
+
+void __init omap_serial_early_init(void)
+{
+ omap_hwmod_for_each_by_class(uart,
+ omap_serial_port_init, NULL);
this could all be on one line
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 4/8] OMAP3: PM: Adding smartreflex hwmod data
Thara Gopinath th...@ti.com writes:
This patch adds the smartreflex hwmod data for OMAP3430
and OMAP3630. A dev_attr is also added to the hwmod
structure for each smartreflex module which contains
SoC specific info like the efuse offsets, test n-values
etc.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
+static struct omap_hwmod_ocp_if omap3_l4_core__sr1 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_sr1_hwmod,
+ .clk= sr_l4_ick,
+ .addr = omap3_sr1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3_sr1_addr_space),
+ .user = OCP_USER_MPU,
For enable to work, these all nee the .prcm.omap2 sub struct filled
out.
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] OMAP3: wait on IDLEST after enabling USBTLL fclk
Gadiyar, Anand wrote:
We need to wait on the IDLEST bit after the clocks are enabled
before attempting to access any register.
Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
i-clock is enabled first, the clkops_omap2_dflt_wait is
short-circuited as the companion f-clock is not enabled.
This can cause a data abort if the IDLEST has not transitioned,
and we try to access a USBTLL register.
Since the USBTLL i-clock and f-clock could be enabled in any order,
this is a bug. Fix it by changing the clkops for the f-clock.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Ping?
---
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock3xxx_data.c
+++ linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1484,7 +1484,7 @@ static struct clk ts_fck = {
static struct clk usbtll_fck = {
.name = usbtll_fck,
- .ops= clkops_omap2_dflt,
+ .ops= clkops_omap2_dflt_wait,
.parent = dpll5_m2_ck,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
.enable_bit = OMAP3430ES2_EN_USBTLL_SHIFT,
--
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: no network on 3630/Zoom3 using omap3_defconfig
Kevin Hilman wrote: Vishwa, Can you have someone investigate/debug why using omap3_defconfig on 3630/Zoom3 results in no network while using omap_zoom3_defconfig seems to work? In addition, this would also be a good opportunity to get rid of the Zoom3-specific defconfig and move towards using the common omap3_defconfig. Kevin Works for me with a 3630SDP. I'll see if I can dig up a zoom3 and test over the weekend. - 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 8/8] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Thara Gopinath th...@ti.com writes: From: Thara Gopinath th...@ti.com Subject: [PATCH 8/8] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers To: linux-omap@vger.kernel.org Cc: khil...@deeprootsystems.com, p...@pwsan.com, b-cous...@ti.com, vishwanath...@ti.com, saw...@ti.com, Thara Gopinath th...@ti.com Date: Sat, 29 May 2010 22:02:28 +0530 This patch adds debug support to the voltage and smartreflex drivers. This means a whole bunch of voltage processor and smartreflex parameters are now visible through the pm debugfs. By default only a read of these parameters are permitted. If you need to write into them then echo 1 /pm_debug/enable_sr_vp_debug The voltage parameters can be viewed at /pm_debug/Voltage/VDDX/parameter and the smartreflex parameters can be viewed at /pm_debug/Smartreflex/SRX/parameter Minor nit: there's no hard rule for this, but these debugfs files and directories are typically all lower-case. Please continue that convention. 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 v3 0/7] DSPBRIDGE: fix mem+cache API issues
From: Ohad Ben-Cohen [mailto:o...@wizery.com] This patchset introduces an approach to eliminate the direct calls to follow_page and to the low level cache APIs. The patchset works by caching the page information while memory is mapped, and then using that information later when needed instead of calling follow_page. The low level cache API is then replaced by standard DMA API. Changes from v2: * Fix rebase error that plagued the v2 series * Added some debug logs to help analyzing missing mapping issues Notes: 1. The global bridge device struct is used by adding an 'extern' to proc. This issue should be handled in a different patch series (the struct should not be global. instead, it should be accessible to the dspbridge code via one of the context objects. This way we will also be able to transform pr_* prints to dev_* prints). 2. The patchset was tested with testsuite, DMM sample app and varios MM and recovery scenarios. Many thanks to Ivan Gomez Castellanos for the help here. Also Many thanks to Felipe Contreras for the thorough review, comments and testing. Thanks, Ohad. --- If you want, you can also reach me at ohadb at ti dot com . Ohad Ben-Cohen (7): DSPBRIDGE: enhance dmm_map_object DSPBRIDGE: maintain mapping and page info DSPBRIDGE: do not call follow_page DSPBRIDGE: do not use low level cache manipulation API DSPBRIDGE: remove mem_flush_cache DSPBRIDGE: add dspbridge API to mark end of DMA DSPBRIDGE: add new PROC_BEGINDMA and PROC_ENDDMA ioctls arch/arm/plat-omap/include/dspbridge/drv.h | 32 +- .../arm/plat-omap/include/dspbridge/dspapi-ioctl.h |9 + arch/arm/plat-omap/include/dspbridge/dspapi.h |2 + arch/arm/plat-omap/include/dspbridge/dspdefs.h |3 +- arch/arm/plat-omap/include/dspbridge/proc.h| 29 ++ drivers/dsp/bridge/core/io_sm.c| 11 +- drivers/dsp/bridge/core/tiomap3430.c |9 +- drivers/dsp/bridge/pmgr/dspapi.c | 34 ++- drivers/dsp/bridge/rmgr/drv.c | 33 -- drivers/dsp/bridge/rmgr/proc.c | 410 10 files changed, 433 insertions(+), 139 deletions(-) Pushed to dspbridge. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
