Re: OMAP3 DSPBridge review
Hi Vijay, On Thu, Apr 17, 2008 at 11:24 AM, Trilok Soni [EMAIL PROTECTED] wrote: Hi Vijay, On Thu, Apr 17, 2008 at 8:15 AM, Pasam, Vijay [EMAIL PROTECTED] wrote: Hi Trilok: I was just going this dspbridge code, and I was surprised to find layers for un-necessary things, where we could have simply called the linux kernel provided function. Here goes the list: 1. There is un-necessary linux directory inside mpu_driver source codes. e.g src/osal/linux etc. I hope we are writing this code for Linux kernel only. 2. src/osal/linux - As the name suggest for directory it is OS Abstraction layer for Linux. I don't see any need for this at all. In Linux kernel, we follow approach of directly calling the provided functions and not to further wrap it until necessary. src/osal/list.c - This whole file tries implement doubly linked list code, I am sure you can get away this with list.h itself. I don't see any need of further wrapping it. src/osal/kfile.c - Don't use KENREL_VERSION comparision check unless very much necessary, always try to keep driver in sync in latest kernel version instead. - Again there are wrappers for file reading functions provided by kernel. - If this functions are only used for doff loader, then moving it to outside kernel space, then we can get away with this functions. src/osal/mem.c - I see here that you guys are maintaining the pool of memory allocated with dma_alloc_coherent, you guys should have used existing mempool apis instead, look at dspgw code for example. src/osal/isr.c - Not required, please call request_irq/free_irq directly please. I also see lots of #ifdef LINUX and #ifndef LINUX, does TI also target to build this code for WinCE and Symbian like OS. If yes, I don't see how we are going to maintain this along with community. src/osal/dpc.c - please call tasklet functions directly instead. src/pmgr/linux/common/dmm.c - One of the goals of bridge is easier portability to other RTOS. You are right about the additional layer to call into Linux OS. This was intended to port this to other OS'es easily. TI has to decide, what path they have to follow now onwards for bridge, I see no need of OSAL layer, when we are targeting this as Linux kernel driver. It would be tough to get contributions as this code at first sight looks harder to understand. Let's have some ideas on how we can clean this code gradually without breaking API compatibility and IPC layer. Common MMU and Mailbox framework written in Nokia dspgw should also be utilized in this. Forgot to mention that documents folder contains documents in MS$ .doc format. Please publish them in .pdf instead. Later the steps can be converted to dspbridge-wiki pages. -- ---Trilok Soni http://triloksoni.wordpress.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] I2C: i2c subsystem should print error messages
We don't have to print any error message if i2c_add_driver
fails since i2c subsystem already does it.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/i2c/chips/isp1301_omap.c | 10 +-
drivers/i2c/chips/menelaus.c | 10 +-
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/i2c/chips/isp1301_omap.c b/drivers/i2c/chips/isp1301_omap.c
index 6ebff9c..09f9662 100644
--- a/drivers/i2c/chips/isp1301_omap.c
+++ b/drivers/i2c/chips/isp1301_omap.c
@@ -1606,15 +1606,7 @@ static struct i2c_driver isp1301_driver = {
static int __init isp_init(void)
{
- int status = -ENODEV;
-
- printk(KERN_INFO %s: version %s\n, DRIVER_NAME, DRIVER_VERSION);
-
- status = i2c_add_driver(isp1301_driver);
- if (status)
- printk(KERN_ERR %s failed to probe\n, DRIVER_NAME);
-
- return status;
+ return i2c_add_driver(isp1301_driver);
}
module_init(isp_init);
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index 1d7482a..d4d1ccc 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -1281,15 +1281,7 @@ static struct i2c_driver menelaus_i2c_driver = {
static int __init menelaus_init(void)
{
- int res;
-
- res = i2c_add_driver(menelaus_i2c_driver);
- if (res 0) {
- dev_err(the_menelaus-client-dev, driver registration
failed\n);
- return res;
- }
-
- return 0;
+ return i2c_add_driver(menelaus_i2c_driver);
}
static void __exit menelaus_exit(void)
--
1.5.5.49.gf43e2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Add usb support to omap3beagle
add-beagle-usb-support.diff Description: Binary data
Re: [PATCH 3/4] Adding support for OMAP3 Beagle Board
Syed Mohammed, Khasim wrote:
Adding support for OMAP3 Beagle Board
Signed-off-by: Syed Mohammed Khasim [EMAIL PROTECTED]
---
arch/arm/mach-omap2/Kconfig |4 +
arch/arm/mach-omap2/Makefile |1
arch/arm/mach-omap2/board-omap3beagle.c | 79 ++
include/asm-arm/arch-omap/board-omap3beagle.h | 53 +
include/asm-arm/arch-omap/hardware.h |4 +
5 files changed, 141 insertions(+)
Index: my_branch/arch/arm/mach-omap2/Kconfig
===
--- my_branch.orig/arch/arm/mach-omap2/Kconfig 2008-04-16 14:41:28.0
+0530
+++ my_branch/arch/arm/mach-omap2/Kconfig 2008-04-16 14:45:38.0
+0530
@@ -109,3 +109,7 @@
config MACH_OMAP3EVM
bool OMAP 3530 EVM board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+
+config MACH_OMAP3_BEAGLE
+ bool OMAP3 BEAGLE board
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
Index: my_branch/arch/arm/mach-omap2/Makefile
===
--- my_branch.orig/arch/arm/mach-omap2/Makefile 2008-04-16 14:41:28.0
+0530
+++ my_branch/arch/arm/mach-omap2/Makefile 2008-04-16 14:45:38.0
+0530
@@ -35,6 +35,7 @@
board-3430sdp-usb.o \
board-3430sdp-flash.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
board-apollon-mmc.o \
board-apollon-keys.o
Index: my_branch/arch/arm/mach-omap2/board-omap3beagle.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ my_branch/arch/arm/mach-omap2/board-omap3beagle.c 2008-04-16
14:45:52.0 +0530
@@ -0,0 +1,79 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3beagle.c
+ *
+ * Copyright (C) 2008 Texas Instruments
+ *
+ * Modified from mach-omap2/board-3430sdp.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * 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/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+
+#include asm/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include asm/arch/gpio.h
+#include asm/arch/board.h
+#include asm/arch/common.h
+
+static struct omap_uart_config omap3_beagle_uart_config __initdata = {
+ .enabled_uarts = ((1 0) | (1 1) | (1 2)),
+};
+
+static int __init omap3_beagle_i2c_init(void)
+{
+ omap_register_i2c_bus(1, 2600, NULL, 0);
+ omap_register_i2c_bus(2, 400, NULL, 0);
+ omap_register_i2c_bus(3, 400, NULL, 0);
+ return 0;
+}
+
+static void __init omap3_beagle_init_irq(void)
+{
+ omap2_init_common_hw();
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_board_config_kernel omap3_beagle_config[] __initdata = {
+ {OMAP_TAG_UART, omap3_beagle_uart_config },
+};
+
+static void __init omap3_beagle_init(void)
+{
+ omap_board_config = omap3_beagle_config;
+ omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
+ omap_serial_init();
Do you like to add here MMC and USB init like recently proposed by
Koen Kooi?
If I understand correctly, these patches currently won't boot on
BeagleBoard if MMC and USB are missing?
Many thanks
Dirk
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] I2C: TWL4030: Fix Kconfig
Misc cleanup patch. Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- drivers/i2c/chips/Kconfig |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index f3ea82d..5cf4657 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -160,10 +160,6 @@ choice TWL4030 USB transceiver can operate in various mutually-exclusive modes. Select one of them. -config TWL4030_PWRBUTTON -bool TWL4030 Power button Driver - depends on TWL4030_CORE - config TWL4030_USB_HS_ULPI depends on TWL4030_USB bool High-speed ULPI @@ -173,6 +169,10 @@ config TWL4030_USB_HS_ULPI endchoice +config TWL4030_PWRBUTTON +bool TWL4030 Power button Driver + depends on TWL4030_CORE + config TWL4030_POWEROFF bool TWL4030 device poweroff depends on TWL4030_CORE -- 1.5.5.49.gf43e2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hello Hiroshi,
On Thu, 17 Apr 2008, Hiroshi DOYU wrote:
debugfs can provide the infrastructure to trace the dependencies of
clock tree hierarchy quite visibly. This patch enables to keep track
of clock tree hierarchy and expose their attributes under each clock
directry as below:
As a replacement for print_parents, which was read-only, it seems good to
me.
But it would be nice to be able to call into clock functions like
round_rate, set_rate, and set_parent via filesystem writes for debugging
purposes, and I don't think that debugfs supports this.
I have a patch here that I use for internal testing that builds the clock
tree in sysfs, and allows for round_rate/set_rate calls, along with
enable/disable testing. But sysfs may not be the right place. It doesn't
seem like there's any logical place to put it that would not involve major
upstream arm-wrestling. Maybe /sys/devices/platform?
There are also procfs and configfs, I suppose.
Obviously, I could continue to carry my debugging patch in my local tree
here. But you mention powerdomain links. I suspect that we will want to
have a standard place for all of these filesystem entities, particularly
since one could conceive of a completely userspace power management policy
that would control powerdomains and clockdomains via the filesystem. So
it probably makes sense to discuss this now.
A quick comment on the patch itself, inlined below.
+static int clk_debugfs_register_one(struct clk *c)
+{
+ int err;
+ struct dentry *d, *child;
+ struct clk *pa = c-parent;
+ char s[255];
+ char *p = s;
+
+ p += sprintf(p, %s, c-name);
+ if (c-id != 0)
+ sprintf(p, %d, c-id);
perhaps separate the ID and the clock name with a colon, if the ID exists?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
On Thursday 17 April 2008, Paul Walmsley wrote: But it would be nice to be able to call into clock functions like round_rate, set_rate, and set_parent via filesystem writes for debugging purposes, and I don't think that debugfs supports this. It does, if you set up the files properly ... except maybe the set_parent stuff. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hello David, On Thu, 17 Apr 2008, David Brownell wrote: On Thursday 17 April 2008, Paul Walmsley wrote: But it would be nice to be able to call into clock functions like round_rate, set_rate, and set_parent via filesystem writes for debugging purposes, and I don't think that debugfs supports this. It does, if you set up the files properly ... except maybe the set_parent stuff. Could you be more specific? The only write support that I see in the debugfs API is to store bytes into memory locations. We'd need to call functions also upon writes. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hi, From: ext Paul Walmsley [EMAIL PROTECTED] Subject: Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework Date: Thu, 17 Apr 2008 12:45:02 -0600 (MDT) Hello David, On Thu, 17 Apr 2008, David Brownell wrote: On Thursday 17 April 2008, Paul Walmsley wrote: But it would be nice to be able to call into clock functions like round_rate, set_rate, and set_parent via filesystem writes for debugging purposes, and I don't think that debugfs supports this. It does, if you set up the files properly ... except maybe the set_parent stuff. Could you be more specific? The only write support that I see in the debugfs API is to store bytes into memory locations. We'd need to call functions also upon writes. debugfs_create_file(...fops) has take fops as its argument. I guess that this can deal with the above. For set_parent, would it be possible to do that by using debugfs_rename()? And if there will be a little possibility that sysfs attribute can be used by userland in the future, keeping sysfs instead of debugfs doesn't seem not so illegal, does it? Hiroshi DOYU -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add usb support to omap3beagle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 17 apr 2008, om 20:26 heeft David Brownell het volgende geschreven: On Thursday 17 April 2008, Koen Kooi wrote: @@ -69,6 +70,7 @@ omap_board_config_size = ARRAY_SIZE(omap3_beagle_config); omap_serial_init(); sdp_mmc_init(); + sdp3430_usb_init(); } arch_initcall(omap3_beagle_i2c_init); I hope someone makes those sdp_*() routines generic ... or does SDP not stand for Software Development Platform (different board)? Those routines are indeed name after the sdp board, but they seem generic enough to get reused in other boards (e.g. omap3evm or omap3 beagle) without change :) regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFIB522MkyGM64RGpERAqmvAKC8ASHDj63mcwe5bsa2X8OiOUpgAQCfdcZl 6RL3JX4fBhN4NK3rh3XOhTg= =/Erq -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hello David, On Thu, 17 Apr 2008, David Brownell wrote: struct dentry *debugfs_create_file(const char *name, mode_t mode, struct dentry *parent, void *data, const struct file_operations *fops); ... provide a file_operations vector supporting writes. Or building more complex values with seq_file, etc. thanks, missed that. That would indeed work. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hello Hiroshi, David, On Thu, 17 Apr 2008, David Brownell wrote: On Thursday 17 April 2008, Hiroshi DOYU wrote: And if there will be a little possibility that sysfs attribute can be used by userland in the future, keeping sysfs instead of debugfs doesn't seem not so illegal, does it? True, but if we can do a debugfs implementation first, then that seems like a good way to start, no? Userspace PM implementations are probably some months in the future, and we can mandate that debugfs be mounted for those. I happen to think that the clock tree is sensitive enough that it should not be managed from userspace in production systems. (Except possibly through driver-specific APIs which ensure the right rules are followed.) Too easy to break things otherwise. In terms of the clock tree, it would be good to allow userspace-driven OPP changes, analogous to CPUFreq's userspace governor. [ In general, I agree that userspace should not be changing driver clocks directly, just like userspace should not be mucking around in /dev/mem directly :-) ] Clock tree changes (like OPP changes) which are not initiated by drivers do create some additional complexity. Drivers will need to be notified before and after these changes. It turns out that DSP Bridge already needs post-frequency-change notification for the DSP clock - there is a patch here which will soon be posted to add those. Pre-change notifiers are also needed to quiesce DMA, etc.; those are somewhat more difficult, but also in the works. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hi all, On Thu, 2008-04-17 at 13:44 -0600, ext Paul Walmsley wrote: Hello Hiroshi, David, On Thu, 17 Apr 2008, David Brownell wrote: On Thursday 17 April 2008, Hiroshi DOYU wrote: And if there will be a little possibility that sysfs attribute can be used by userland in the future, keeping sysfs instead of debugfs doesn't seem not so illegal, does it? True, but if we can do a debugfs implementation first, then that seems like a good way to start, no? Userspace PM implementations are probably some months in the future, and we can mandate that debugfs be mounted for those. I can hardly see the benefit of a userspace implementation, considering the extra context switch required and the fact the in many cases clocks get enabled in response to irqs. I happen to think that the clock tree is sensitive enough that it should not be managed from userspace in production systems. (Except possibly through driver-specific APIs which ensure the right rules are followed.) Too easy to break things otherwise. In terms of the clock tree, it would be good to allow userspace-driven OPP changes, analogous to CPUFreq's userspace governor. [ In general, I agree that userspace should not be changing driver clocks directly, just like userspace should not be mucking around in /dev/mem directly :-) ] That also sounds akward at best: cpufreq (or similar) is much better suited for this sort of activity; userspace governor would be the userspace controller you refer to, but it is far from being optimal. Userspace should limit itself to changing policies. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
From: ext Paul Walmsley [EMAIL PROTECTED]
Subject: Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap
clock framework
Date: Thu, 17 Apr 2008 13:44:04 -0600 (MDT)
Hello Hiroshi, David,
On Thu, 17 Apr 2008, David Brownell wrote:
On Thursday 17 April 2008, Hiroshi DOYU wrote:
And if there will be a little possibility that sysfs attribute can be
used by userland in the future, keeping sysfs instead of debugfs
doesn't seem not so illegal, does it?
True, but if we can do a debugfs implementation first, then that seems
like a good way to start, no? Userspace PM implementations are probably
some months in the future, and we can mandate that debugfs be mounted for
those.
Agreed. Update ones attached. The diffs against the previous are:
diff -u b/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
--- b/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -524,7 +524,7 @@
p += sprintf(p, %s, c-name);
if (c-id != 0)
- sprintf(p, %d, c-id);
+ sprintf(p, :%d, c-id);
d = debugfs_create_dir(s, pa ? pa-dent : clk_debugfs_root);
if (IS_ERR(d))
return PTR_ERR(d);
diff -u b/include/asm-arm/arch-omap/clock.h b/include/asm-arm/arch-omap/clock.h
--- b/include/asm-arm/arch-omap/clock.h
+++ b/include/asm-arm/arch-omap/clock.h
@@ -86,7 +86,7 @@
__u8rate_offset;
__u8src_offset;
#endif
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_PM_DEBUG) defined(CONFIG_DEBUG_FS)
struct dentry *dent; /* For visible tree hierarchy */
#endif
};
Hiroshi DOYU
From fa06e7a21c08299eaa61e6c367ec8e737a8ff13b Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU [EMAIL PROTECTED]
Date: Thu, 17 Apr 2008 16:51:41 +0300
Subject: [PATCH 2/2] ARM: OMAP: CLKFW: Remove procfs entry for debugging clock
framework
This feature can be covered by debugfs for omap clock framework.
Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
---
arch/arm/plat-omap/clock.c | 96
1 files changed, 0 insertions(+), 96 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 2ae87bf..714dbbf 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -34,41 +34,6 @@ static DEFINE_SPINLOCK(clockfw_lock);
static struct clk_functions *arch_clock;
-#ifdef CONFIG_PM_DEBUG
-
-static void print_parents(struct clk *clk)
-{
- struct clk *p;
- int printed = 0;
-
- list_for_each_entry(p, clocks, node) {
- if (p-parent == clk p-usecount) {
- if (!clk-usecount !printed) {
- printk(MISMATCH: %s\n, clk-name);
- printed = 1;
- }
- printk(\t%-15s\n, p-name);
- }
- }
-}
-
-void clk_print_usecounts(void)
-{
- unsigned long flags;
- struct clk *p;
-
- spin_lock_irqsave(clockfw_lock, flags);
- list_for_each_entry(p, clocks, node) {
- if (p-usecount)
- printk(%-15s: %d\n, p-name, p-usecount);
- print_parents(p);
-
- }
- spin_unlock_irqrestore(clockfw_lock, flags);
-}
-
-#endif
-
/*-
* Standard clock functions defined in include/linux/clk.h
*-*/
@@ -447,67 +412,6 @@ int __init clk_init(struct clk_functions * custom_clocks)
return 0;
}
-#if defined(CONFIG_PM_DEBUG) defined(CONFIG_PROC_FS)
-#include linux/proc_fs.h
-#include linux/seq_file.h
-
-static void *omap_ck_start(struct seq_file *m, loff_t *pos)
-{
- return *pos 1 ? (void *)1 : NULL;
-}
-
-static void *omap_ck_next(struct seq_file *m, void *v, loff_t *pos)
-{
- ++*pos;
- return NULL;
-}
-
-static void omap_ck_stop(struct seq_file *m, void *v)
-{
-}
-
-int omap_ck_show(struct seq_file *m, void *v)
-{
- struct clk *cp;
-
- list_for_each_entry(cp, clocks, node)
- seq_printf(m,%s %ld %d\n, cp-name, cp-rate, cp-usecount);
-
- return 0;
-}
-
-static struct seq_operations omap_ck_op = {
- .start =omap_ck_start,
- .next = omap_ck_next,
- .stop = omap_ck_stop,
- .show = omap_ck_show
-};
-
-static int omap_ck_open(struct inode *inode, struct file *file)
-{
- return seq_open(file, omap_ck_op);
-}
-
-static struct file_operations proc_omap_ck_operations = {
- .open = omap_ck_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= seq_release,
-};
-
-int __init omap_ck_init(void)
-{
- struct proc_dir_entry *entry;
-
- entry = create_proc_entry(omap_clocks, 0, NULL);
- if (entry)
- entry-proc_fops = proc_omap_ck_operations;
-
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
Hello Igor, On Thu, 17 Apr 2008, Igor Stoppa wrote: On Thu, 2008-04-17 at 13:44 -0600, ext Paul Walmsley wrote: True, but if we can do a debugfs implementation first, then that seems like a good way to start, no? Userspace PM implementations are probably some months in the future, and we can mandate that debugfs be mounted for those. I can hardly see the benefit of a userspace implementation, considering the extra context switch required and the fact the in many cases clocks get enabled in response to irqs. I agree that we shouldn't try to move the clock framework to userspace. But, determining what OPP to switch to next, based on system load or other requirements published by drivers or userspace processes; or determining what power state to put powerdomains to -- it would be nice to experiment with a userspace governor for those tasks. It would certainly make development and testing easier. In terms of the clock tree, it would be good to allow userspace-driven OPP changes, analogous to CPUFreq's userspace governor. [ In general, I agree that userspace should not be changing driver clocks directly, just like userspace should not be mucking around in /dev/mem directly :-) ] That also sounds akward at best: cpufreq (or similar) is much better suited for this sort of activity; userspace governor would be the userspace controller you refer to, but it is far from being optimal. Userspace should limit itself to changing policies. CPUFreq is good, but it does not manage non-CPU-frequency knobs very well, and there are plenty of those on OMAP3. Is there any reason why we should not allow the option of userspace OPP selection/powerdomain control for OMAP? If people don't want to use it, they don't have to :-) - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework
On Thursday 17 April 2008, Paul Walmsley wrote: Userspace should limit itself to changing policies. CPUFreq is good, but it does not manage non-CPU-frequency knobs very well, and there are plenty of those on OMAP3. Similar issues are widely acknowledged. Is there any reason why we should not allow the option of userspace OPP selection/powerdomain control for OMAP? If people don't want to use it, they don't have to :-) Sure, allow userspace controls. Even use debugs to prototype them. Just don't build fragile interfaces ... don't expect userspace code to do the equivalent of open heart surgery. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] Adding New Board file for OMAP3 Beagle Board
On Wed, Apr 16, 2008 at 06:08:03PM +0530, Syed Mohammed, Khasim wrote:
Add new board file for OMAP3 Beagle Board.
For more info regarding this board visit http://beagleboard.org
Signed-off-by: Syed Mohammed Khasim [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3beagle.c | 79
1 file changed, 79 insertions(+)
Index: my_branch/arch/arm/mach-omap2/board-omap3beagle.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ my_branch/arch/arm/mach-omap2/board-omap3beagle.c 2008-04-16
14:45:52.0 +0530
@@ -0,0 +1,79 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3beagle.c
+ *
+ * Copyright (C) 2008 Texas Instruments
+ *
+ * Modified from mach-omap2/board-3430sdp.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * 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/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+
+#include asm/hardware.h
where's the board-omap3beagle.h ?
there's only the .c file so hardware.h is not adding anything here?
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include asm/arch/gpio.h
+#include asm/arch/board.h
+#include asm/arch/common.h
+
+static struct omap_uart_config omap3_beagle_uart_config __initdata = {
+ .enabled_uarts = ((1 0) | (1 1) | (1 2)),
+};
+
+static int __init omap3_beagle_i2c_init(void)
+{
+ omap_register_i2c_bus(1, 2600, NULL, 0);
+ omap_register_i2c_bus(2, 400, NULL, 0);
+ omap_register_i2c_bus(3, 400, NULL, 0);
+ return 0;
+}
+
+static void __init omap3_beagle_init_irq(void)
+{
+ omap2_init_common_hw();
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_board_config_kernel omap3_beagle_config[] __initdata = {
+ {OMAP_TAG_UART, omap3_beagle_uart_config },
+};
+
+static void __init omap3_beagle_init(void)
+{
+ omap_board_config = omap3_beagle_config;
+ omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
+ omap_serial_init();
+}
+
+arch_initcall(omap3_beagle_i2c_init);
+
+static void __init omap3_beagle_map_io(void)
+{
+ omap2_set_globals_343x();
+ omap2_map_common_io();
+}
+
+MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
+ /* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xd800) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap3_beagle_map_io,
+ .init_irq = omap3_beagle_init_irq,
+ .init_machine = omap3_beagle_init,
+ .timer = omap_timer,
+MACHINE_END
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Felipe Balbi
[EMAIL PROTECTED]
http://blog.felipebalbi.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add usb support to omap3beagle
On Thu, Apr 17, 2008 at 10:58:32AM +0200, Koen Kooi wrote: The last one didn't go to the list, both mmc and usb externs should go to board-omap3beagle.h and please, care to make the patch inline. It's easier to comment. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] Update audio driver for H2 board
On Tue, Apr 15, 2008 at 10:02:05AM -0400, Eduardo Valentin wrote:
From: Eduardo Valentin [EMAIL PROTECTED]
This patch updates the audio driver based on tsc2101 chip
for H2 board. tsc2101 driver was updated against new spi
framework, but its audio driver for H2 wasn't.
Signed-off-by: Eduardo Valentin [EMAIL PROTECTED]
Some from checkpatch:
-:79: ERROR: use tabs not spaces
-:82: ERROR: use tabs not spaces
-:249: WARNING: line over 80 characters
total: 2 errors, 1 warnings, 0 checks, 205 lines checked
---
arch/arm/mach-omap1/board-h2.c | 72
+++---
sound/arm/omap/omap-alsa-tsc2101-mixer.c |7 ++-
sound/arm/omap/omap-alsa-tsc2101-mixer.h |2 +
sound/arm/omap/omap-alsa-tsc2101.c | 28 +--
sound/arm/omap/omap-alsa-tsc2101.h |5 ++
5 files changed, 71 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index aa1f8af..a576b5b 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -320,6 +320,41 @@ static void h2_lcd_dev_init(struct spi_device *tsc2101)
platform_device_register(h2_lcd_device);
}
+static struct omap_mcbsp_reg_cfg mcbsp_regs = {
+ .spcr2 = FREE | FRST | GRST | XRST | XINTM(3),
+ .spcr1 = RINTM(3) | RRST,
+ .rcr2 = RPHASE | RFRLEN2(OMAP_MCBSP_WORD_8) |
+RWDLEN2(OMAP_MCBSP_WORD_16) | RDATDLY(1),
+ .rcr1 = RFRLEN1(OMAP_MCBSP_WORD_8) | RWDLEN1(OMAP_MCBSP_WORD_16),
+ .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
+XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(1) | XFIG,
+ .xcr1 = XFRLEN1(OMAP_MCBSP_WORD_8) | XWDLEN1(OMAP_MCBSP_WORD_16),
+ .srgr1 = FWID(15),
+ .srgr2 = GSYNC | CLKSP | FSGM | FPER(31),
+
+ .pcr0 = CLKXM | CLKRM | FSXP | FSRP | CLKXP | CLKRP,
+ /*.pcr0 = CLKXP | CLKRP,*//* mcbsp: slave */
+};
+
+static struct omap_alsa_codec_config alsa_config = {
+ .name = H2 TSC2101,
+ .mcbsp_regs_alsa= mcbsp_regs,
+};
+
+static struct platform_device h2_mcbsp1_device = {
+ .name = omap_alsa_mcbsp,
+ .id = 1,
+ .dev = {
+ .platform_data = alsa_config,
+ },
+};
+
+static void h2_audio_dev_init(struct spi_device *tsc2101)
+{
+ h2_mcbsp1_device.dev.platform_data = tsc2101;
+ platform_device_register(h2_mcbsp1_device);
+}
+
static int h2_tsc2101_init(struct spi_device *spi)
{
int r;
@@ -344,6 +379,7 @@ static int h2_tsc2101_init(struct spi_device *spi)
omap_cfg_reg(N15_1610_UWIRE_CS1);
h2_lcd_dev_init(spi);
+ h2_audio_dev_init(spi);
return 0;
err:
@@ -386,48 +422,12 @@ static struct spi_board_info h2_spi_board_info[]
__initdata = {
},
};
-static struct omap_mcbsp_reg_cfg mcbsp_regs = {
- .spcr2 = FREE | FRST | GRST | XRST | XINTM(3),
- .spcr1 = RINTM(3) | RRST,
- .rcr2 = RPHASE | RFRLEN2(OMAP_MCBSP_WORD_8) |
-RWDLEN2(OMAP_MCBSP_WORD_16) | RDATDLY(1),
- .rcr1 = RFRLEN1(OMAP_MCBSP_WORD_8) | RWDLEN1(OMAP_MCBSP_WORD_16),
- .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
-XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(1) | XFIG,
- .xcr1 = XFRLEN1(OMAP_MCBSP_WORD_8) | XWDLEN1(OMAP_MCBSP_WORD_16),
- .srgr1 = FWID(15),
- .srgr2 = GSYNC | CLKSP | FSGM | FPER(31),
-
- .pcr0 = CLKXM | CLKRM | FSXP | FSRP | CLKXP | CLKRP,
- /*.pcr0 = CLKXP | CLKRP,*//* mcbsp: slave */
-};
-
-static struct omap_alsa_codec_config alsa_config = {
- .name = H2 TSC2101,
- .mcbsp_regs_alsa= mcbsp_regs,
- .codec_configure_dev= NULL, /* tsc2101_configure, */
- .codec_set_samplerate = NULL, /* tsc2101_set_samplerate, */
- .codec_clock_setup = NULL, /* tsc2101_clock_setup, */
- .codec_clock_on = NULL, /* tsc2101_clock_on, */
- .codec_clock_off= NULL, /* tsc2101_clock_off, */
- .get_default_samplerate = NULL, /* tsc2101_get_default_samplerate, */
-};
-
-static struct platform_device h2_mcbsp1_device = {
- .name = omap_alsa_mcbsp,
- .id = 1,
- .dev = {
- .platform_data = alsa_config,
- },
-};
-
static struct platform_device *h2_devices[] __initdata = {
h2_nor_device,
h2_nand_device,
h2_smc91x_device,
h2_irda_device,
h2_kp_device,
- h2_mcbsp1_device,
};
static void __init h2_init_smc91x(void)
diff --git a/sound/arm/omap/omap-alsa-tsc2101-mixer.c
b/sound/arm/omap/omap-alsa-tsc2101-mixer.c
index 8faba95..09257d7 100644
--- a/sound/arm/omap/omap-alsa-tsc2101-mixer.c
+++ b/sound/arm/omap/omap-alsa-tsc2101-mixer.c
@@ -43,6 +43,7 @@
#include omap-alsa-tsc2101.h
#include omap-alsa-tsc2101-mixer.h
+#include linux/spi/tsc2101.h
#include linux/types.h
#include sound/initval.h
#include sound/control.h
@@ -68,7 +69,8 @@ static int
RE: OMAP3 DSPBridge review
Hi Trilok: TI has to decide, what path they have to follow now onwards for bridge, I see no need of OSAL layer, when we are targeting this as Linux kernel driver. We are investigating the effort required to do this. We will get back on this. Thanks for the pointer on the documentation. We will fix this. Best Regards Vijay -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
UART driver DMA support
Hi , I am using the OMAP2EVM board based on OMAP2430 and using Linux - 2.6.23 Is the DMA support available as part of the UART driver. Thanks and Regards Rajeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
