Re: linux-omap-2.6 git not updated?
* Kevin Hilman khil...@deeprootsystems.com [090813 18:32]: Tony Lindgren t...@atomide.com writes: * Tony Lindgren t...@atomide.com [090812 16:48]: * Gadiyar, Anand gadi...@ti.com [090812 16:27]: Tony, Is something wrong with the kernel.org mirror? The last commit I see is: commit 4baadee6e2dd5228e1b17cb5f931c4e0ed8fcb96 Author: Anand Gadiyar gadi...@ti.com Date: Wed Aug 5 16:22:59 2009 +0300 I do see that the other branches (upstream, omap4, ...) are updated. Looks like only the master is not yet reflecting the patches you applied in the last 7 days. Yeah I have not updated master yet with the patches going upstream. Will reset arch/arm/*omap* in master, and merge in the posted upstream branches. Updated now with the patches queued for mainline. Tony, Can you merge in the .31 fixes branches that RMK has already pulled in also? These are the PM fixes from me and Paul's fixes branch. Those should be all there now. Sounds like we need to rebase our merge window branches after the fixes go into mainline. Regards, 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: [PATCH 02/10] OMAP: iommu: add initial debugfs support
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [PATCH 02/10] OMAP: iommu: add initial debugfs support
Date: Sun, 16 Aug 2009 22:47:32 +0200
On Sun, Aug 16, 2009 at 06:13:55PM +0300, Tony Lindgren wrote:
* Hiroshi DOYU hiroshi.d...@nokia.com [090815 15:06]:
Hi Russell,
From: ext Russell King - ARM Linux li...@arm.linux.org.uk
Subject: Re: [PATCH 02/10] OMAP: iommu: add initial debugfs support
Date: Thu, 13 Aug 2009 11:23:59 +0200
On Wed, Aug 12, 2009 at 03:13:24PM +0300, Tony Lindgren wrote:
+static DEFINE_MUTEX(iommu_debug_lock);
+static char local_buffer[SZ_4K];
I don't like this - what if the data you're sprintf'ing into this
buffer overflows it?
Right.
I have attached the updated version which limits max write counts to
avoid the above buffer overflow.
Thanks, I've update my queue with it.
I'm not sure the patch is correct yet. I think this update introduced
some bugs.
I fixed wrong calculation of line length as below.
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 27b4bfa..7fd97aa 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -223,11 +223,12 @@ static ssize_t omap2_dump_cr(struct iommu *obj, struct
cr_regs *cr, char *buf)
do {\
ssize_t bytes; \
const char *str = %20s: %08x\n; \
- bytes = snprintf(p, 32, str, __stringify(name), \
+ const int maxcol = 32; \
+ bytes = snprintf(p, maxcol, str, __stringify(name), \
iommu_read_reg(obj, MMU_##name)); \
p += bytes; \
len -= bytes; \
- if (len strlen(str) + 1) \
+ if (len maxcol) \
goto out; \
} while (0)
diff --git a/arch/arm/plat-omap/iommu-debug.c b/arch/arm/plat-omap/iommu-debug.c
index 536e897..5a7e409 100644
--- a/arch/arm/plat-omap/iommu-debug.c
+++ b/arch/arm/plat-omap/iommu-debug.c
@@ -121,15 +121,16 @@ static ssize_t debug_write_pagetable(struct file *file,
return count;
}
-#define dump_ioptable_entry_one(lv, da, pteval)\
+#define dump_ioptable_entry_one(lv, da, val) \
({ \
int __err = 0; \
ssize_t bytes; \
+ const int maxcol = 22; \
const char *str = %d: %08x %08x\n;\
- bytes = snprintf(p, 22, str, lv, da, pteval); \
+ bytes = snprintf(p, maxcol, str, lv, da, val); \
p += bytes; \
len -= bytes; \
- if (len strlen(str) + 1) \
+ if (len maxcol) \
__err = -ENOMEM;\
__err; \
})
@@ -229,12 +230,13 @@ static ssize_t debug_read_mmap(struct file *file, char
__user *userbuf,
list_for_each_entry(tmp, obj-mmap, list) {
size_t len;
const char *str = %3d %08x-%08x %6x %8x\n;
+ const int maxcol = 39;
len = tmp-da_end - tmp-da_start;
- p += snprintf(p, strlen(str) + 1, str,
+ p += snprintf(p, maxcol, str,
i, tmp-da_start, tmp-da_end, len, tmp-flags);
- if ((strlen(str) + 1) (PAGE_SIZE - (p - buf)))
+ if (PAGE_SIZE - (p - buf) maxcol)
break;
i++;
}
--
1.6.0.4
0001-OMAP-iommu-add-initial-debugfs-support.patch
Description: Binary data
Re: [PATCH 06/10] OMAP: PM debug: Add PRCM register dump support
Hi,
* Kevin Hilman khil...@deeprootsystems.com [090813 19:53]:
From: Tero Kristo tero.kri...@nokia.com
Allows dumping out current register contents from the debug filesystem, and
also allows user to add arbitrary register save points into code. Current
register contents are available under debugfs at:
[debugfs]/pm_debug/registers/current
To add a save point, do following:
From module init (or somewhere before the save call, called only once):
pm_dbg_init_regset(n); // n=1..4, allocates memory for dump area #n
From arbitrary code location:
pm_dbg_regset_save(n); // n=1..4, saves registers to dump area #n
After this, the register dump can be seen under [debugfs]/pm_debug/registers/n
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm-debug.c | 208
arch/arm/mach-omap2/pm.h |4 +
2 files changed, 212 insertions(+), 0 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/pm-debug.c
mode change 100644 = 100755 arch/arm/mach-omap2/pm.h
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
old mode 100644
new mode 100755
index 9199c17..37b883b
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -157,6 +157,8 @@ void omap2_pm_dump(int mode, int resume, unsigned int us)
#include linux/debugfs.h
#include linux/seq_file.h
+static void pm_dbg_regset_store(u32 *ptr);
+
struct dentry *pm_dbg_dir;
static int pm_dbg_init_done;
@@ -166,6 +168,159 @@ enum {
DEBUG_FILE_TIMERS,
};
+struct pm_module_def {
+ char name[8]; /* Name of the module */
+ short type; /* CM or PRM */
+ unsigned short offset;
+ int low; /* First register address on this module */
+ int high; /* Last register address on this module */
+};
+
+#define MOD_CM 0
+#define MOD_PRM 1
+
+static const struct pm_module_def pm_dbg_reg_modules[] = {
+ { IVA2, MOD_CM, OMAP3430_IVA2_MOD, 0, 0x4c },
+ { OCP, MOD_CM, OCP_MOD, 0, 0x10 },
+ { MPU, MOD_CM, MPU_MOD, 4, 0x4c },
+ { CORE, MOD_CM, CORE_MOD, 0, 0x4c },
+ { SGX, MOD_CM, OMAP3430ES2_SGX_MOD, 0, 0x4c },
+ { WKUP, MOD_CM, WKUP_MOD, 0, 0x40 },
+ { CCR, MOD_CM, PLL_MOD, 0, 0x70 },
+ { DSS, MOD_CM, OMAP3430_DSS_MOD, 0, 0x4c },
+ { CAM, MOD_CM, OMAP3430_CAM_MOD, 0, 0x4c },
+ { PER, MOD_CM, OMAP3430_PER_MOD, 0, 0x4c },
+ { EMU, MOD_CM, OMAP3430_EMU_MOD, 0x40, 0x54 },
+ { NEON, MOD_CM, OMAP3430_NEON_MOD, 0x20, 0x48 },
+ { USB, MOD_CM, OMAP3430ES2_USBHOST_MOD, 0, 0x4c },
+
+ { IVA2, MOD_PRM, OMAP3430_IVA2_MOD, 0x50, 0xfc },
+ { OCP, MOD_PRM, OCP_MOD, 4, 0x1c },
+ { MPU, MOD_PRM, MPU_MOD, 0x58, 0xe8 },
+ { CORE, MOD_PRM, CORE_MOD, 0x58, 0xf8 },
+ { SGX, MOD_PRM, OMAP3430ES2_SGX_MOD, 0x58, 0xe8 },
+ { WKUP, MOD_PRM, WKUP_MOD, 0xa0, 0xb0 },
+ { CCR, MOD_PRM, PLL_MOD, 0x40, 0x70 },
+ { DSS, MOD_PRM, OMAP3430_DSS_MOD, 0x58, 0xe8 },
+ { CAM, MOD_PRM, OMAP3430_CAM_MOD, 0x58, 0xe8 },
+ { PER, MOD_PRM, OMAP3430_PER_MOD, 0x58, 0xe8 },
+ { EMU, MOD_PRM, OMAP3430_EMU_MOD, 0x58, 0xe4 },
+ { GLBL, MOD_PRM, OMAP3430_GR_MOD, 0x20, 0xe4 },
+ { NEON, MOD_PRM, OMAP3430_NEON_MOD, 0x58, 0xe8 },
+ { USB, MOD_PRM, OMAP3430ES2_USBHOST_MOD, 0x58, 0xe8 },
+ { , 0, 0, 0, 0 },
+};
This seems 34xx specific and might easily confuse things for other
processors.
To me it seems you should initialize these registers during init
for the processor type.
Regards,
Tony
+
+#define PM_DBG_MAX_REG_SETS 4
+
+static void *pm_dbg_reg_set[PM_DBG_MAX_REG_SETS];
+
+static int pm_dbg_get_regset_size(void)
+{
+ static int regset_size;
+
+ if (regset_size == 0) {
+ int i = 0;
+
+ while (pm_dbg_reg_modules[i].name[0] != 0) {
+ regset_size += pm_dbg_reg_modules[i].high +
+ 4 - pm_dbg_reg_modules[i].low;
+ i++;
+ }
+ }
+ return regset_size;
+}
+
+static int pm_dbg_show_regs(struct seq_file *s, void *unused)
+{
+ int i, j;
+ unsigned long val;
+ int reg_set = (int)s-private;
+ u32 *ptr;
+ void *store = NULL;
+ int regs;
+ int linefeed;
+
+ if (reg_set == 0) {
+ store = kmalloc(pm_dbg_get_regset_size(), GFP_KERNEL);
+ ptr = store;
+ pm_dbg_regset_store(ptr);
+ } else {
+ ptr = pm_dbg_reg_set[reg_set - 1];
+ }
+
+ i = 0;
+
+ while (pm_dbg_reg_modules[i].name[0] != 0) {
+ regs = 0;
+ linefeed = 0;
+ if (pm_dbg_reg_modules[i].type == MOD_CM)
+ seq_printf(s, MOD: CM_%s (%08x)\n,
+ pm_dbg_reg_modules[i].name,
+ (u32)(OMAP3430_CM_BASE +
+
Re: [PATCH 08/10] OMAP3: Debug observability and ETK padconf implementation
* Kevin Hilman khil...@deeprootsystems.com [090813 19:53]:
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/debobs.c | 240
++
arch/arm/plat-omap/include/mach/debobs.h |7 +
2 files changed, 247 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/debobs.c
create mode 100644 arch/arm/plat-omap/include/mach/debobs.h
diff --git a/arch/arm/mach-omap2/debobs.c b/arch/arm/mach-omap2/debobs.c
new file mode 100644
index 000..397a599
--- /dev/null
+++ b/arch/arm/mach-omap2/debobs.c
@@ -0,0 +1,240 @@
+/*
+ * arch/arm/mach-omap2/debobs.c
Should this name be 34xx-debobs.c?
+ *
+ * Handle debobs pads
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Written by Peter De Schrijver peter.de-schrij...@nokia.com
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/debugfs.h
+#include linux/uaccess.h
+#include linux/module.h
+#include linux/gpio.h
+
+#include mach/control.h
+#include mach/mux.h
+#include mach/board.h
+
+#define ETK_GPIO_BEGIN 12
+#define ETK_GPIO(i) (ETK_GPIO_BEGIN + i)
+#define NUM_OF_DEBOBS_PADS 18
+
+static int debobs_initialized;
+
+enum debobs_pad_mode {
+ GPIO = 0,
+ OBS = 1,
+ ETK = 2,
+ NO_MODE = 3,
+};
+
+static char *debobs_pad_mode_names[] = {
+ [GPIO] = GPIO,
+ [OBS] = OBS,
+ [ETK] = ETK,
+};
+
+struct obs {
+ u16 offset;
+ u8 value;
+ u8 mask;
+};
+
+struct debobs_pad {
+ enum debobs_pad_mode mode;
+ struct obs core_obs;
+ struct obs wakeup_obs;
+};
+
+static struct debobs_pad debobs_pads[NUM_OF_DEBOBS_PADS];
+
+static int debobs_mode_open(struct inode *inode, struct file *file)
+{
+ file-private_data = inode-i_private;
+
+ return 0;
+}
+
+static ssize_t debobs_mode_read(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ char buffer[10];
+ int size;
+ int pad_number = (int)file-private_data;
+ struct debobs_pad *e = debobs_pads[pad_number];
+
+ size = snprintf(buffer, sizeof(buffer), %s\n,
+ debobs_pad_mode_names[e-mode]);
+ return simple_read_from_buffer(user_buf, count, ppos, buffer, size);
+}
+
+static ssize_t debobs_mode_write(struct file *file, const char __user
*user_buf,
+ size_t count, loff_t *ppos)
+{
+ char buffer[10];
+ int buf_size, i, pad_number;
+ u16 muxmode = OMAP34XX_MUX_MODE7;
+
+ memset(buffer, 0, sizeof(buffer));
+ buf_size = min(count, (sizeof(buffer)-1));
+
+ if (copy_from_user(buffer, user_buf, buf_size))
+ return -EFAULT;
+
+ pad_number = (int)file-private_data;
+
+ for (i = 0; i NO_MODE; i++) {
+ if (!strnicmp(debobs_pad_mode_names[i],
+ buffer,
+ strlen(debobs_pad_mode_names[i]))) {
+ switch (i) {
+ case ETK:
+ muxmode = OMAP34XX_MUX_MODE0;
+ break;
+ case GPIO:
+ muxmode = OMAP34XX_MUX_MODE4;
+ break;
+ case OBS:
+ muxmode = OMAP34XX_MUX_MODE7;
+ break;
+ }
+ omap_ctrl_writew(muxmode,
+ OMAP343X_PADCONF_ETK(pad_number));
+ debobs_pads[pad_number].mode = i;
+
+ return count;
+ }
+ }
+
+ return -EINVAL;
+}
We need to keep processor specific stuff out of generic code in general.
Otherwise we'll easily mess up things for the other processors.
+
+static const struct file_operations debobs_mode_fops = {
+ .open = debobs_mode_open,
+ .read = debobs_mode_read,
+ .write = debobs_mode_write,
+};
+
+static int debobs_get(void *data, u64 *val)
+{
+ struct obs *o = data;
+
+ *val = o-value;
+
+ return 0;
+}
+
Re: [PATCH 09/10] OMAP3: Add debug observablity (debobs) Kconfig item
* Kevin Hilman khil...@deeprootsystems.com [090813 19:53]: From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/Makefile |3 +++ arch/arm/plat-omap/Kconfig |7 +++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 735bae5..cc515a4 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -44,6 +44,9 @@ iommu-$(CONFIG_ARCH_OMAP3) += omap3-iommu.o obj-$(CONFIG_OMAP_IOMMU) += $(iommu-y) +# Debobs +obj-$(CONFIG_OMAP3_DEBOBS) += debobs.o + # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index efe85d0..4e90a36 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -143,6 +143,13 @@ config OMAP_32K_TIMER endchoice +config OMAP3_DEBOBS + bool OMAP3 Debug observability support + depends on ARCH_OMAP3 DEBUG_FS + default n + help + Use ETK pads for debug observability + The code in the previous patch seems to be 34xx specific. config OMAP_32K_TIMER_HZ int Kernel internal timer frequency for 32KHz timer range 32 1024 -- 1.6.4 -- To unsubscribe from this list: send the line unsubscribe linux-arm 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 10/10] OMAP: PM: Added suspend target state control to debugfs for OMAP3
* Kevin Hilman khil...@deeprootsystems.com [090813 19:54]:
From: Tero Kristo tero.kri...@nokia.com
Target state can be read / programmed via files under:
[debugfs]/pm_debug/[pwrdm]/suspend
Does this compile when CONFIG_DEBUG_FS is not set?
Tony
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm-debug.c | 31 +--
arch/arm/mach-omap2/pm.h |3 +++
arch/arm/mach-omap2/pm34xx.c | 24
3 files changed, 56 insertions(+), 2 deletions(-)
mode change 100755 = 100644 arch/arm/mach-omap2/pm-debug.c
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
old mode 100755
new mode 100644
index 37b883b..eded6a4
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -24,6 +24,7 @@
#include linux/clk.h
#include linux/err.h
#include linux/io.h
+#include linux/module.h
#include mach/clock.h
#include mach/board.h
@@ -478,10 +479,28 @@ int pm_dbg_regset_init(int reg_set)
return 0;
}
-static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
+static int pwrdm_suspend_get(void *data, u64 *val)
+{
+ *val = omap3_pm_get_suspend_state((struct powerdomain *)data);
+
+ if (*val = 0)
+ return 0;
+ return *val;
+}
+
+static int pwrdm_suspend_set(void *data, u64 val)
+{
+ return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get,
+ pwrdm_suspend_set, %llu\n);
+
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir)
{
int i;
s64 t;
+ struct dentry *d;
t = sched_clock();
@@ -490,6 +509,14 @@ static int __init pwrdms_setup(struct powerdomain
*pwrdm, void *unused)
pwrdm-timer = t;
+ if (strncmp(pwrdm-name, dpll, 4) == 0)
+ return 0;
+
+ d = debugfs_create_dir(pwrdm-name, (struct dentry *)dir);
+
+ (void) debugfs_create_file(suspend, S_IRUGO|S_IWUSR, d,
+ (void *)pwrdm, pwrdm_suspend_fops);
+
return 0;
}
@@ -508,7 +535,7 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(time, S_IRUGO,
d, (void *)DEBUG_FILE_TIMERS, debug_fops);
- pwrdm_for_each(pwrdms_setup, NULL);
+ pwrdm_for_each(pwrdms_setup, (void *)d);
pm_dbg_dir = debugfs_create_dir(registers, d);
if (IS_ERR(pm_dbg_dir))
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 8fa8567..8400f57 100755
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -13,6 +13,9 @@
#include mach/powerdomain.h
+extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
+extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
+
#ifdef CONFIG_PM_DEBUG
extern void omap2_pm_dump(int mode, int resume, unsigned int us);
extern int omap2_pm_debug;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 331dfca..26f2aca 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -664,6 +664,30 @@ static void __init prcm_setup_regs(void)
omap3_d2d_idle();
}
+int omap3_pm_get_suspend_state(struct powerdomain *pwrdm)
+{
+ struct power_state *pwrst;
+
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ if (pwrst-pwrdm == pwrdm)
+ return pwrst-next_state;
+ }
+ return -EINVAL;
+}
+
+int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state)
+{
+ struct power_state *pwrst;
+
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ if (pwrst-pwrdm == pwrdm) {
+ pwrst-next_state = state;
+ return 0;
+ }
+ }
+ return -EINVAL;
+}
+
static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
--
1.6.4
--
To unsubscribe from this list: send the line unsubscribe linux-arm 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: [PATCHv2] OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it
* Kevin Hilman khil...@deeprootsystems.com [090814 21:11]: Jon Hunter jon-hun...@ti.com writes: Kevin Hilman wrote: Jon, you're raising the bar and spoiling us with such descriptive changelogs. If everyone was as thorough as you, the world would be a merrier place. :) Thanks, pushing to PM branch and pm-2.6.29. Kevin No problem. You are welcome. Just an FYI, but for 2.6.29, I was doing some testing this morning and I found that I needed to make the following change to the patch to make it work for 2.6.29. You are probably aware already as this makes the patch similar to your original patch for mmc-reset. - dev_set_name(dev, musb_hdrc); - otg_clk = clk_get(dev, ick); + otg_clk = clk_get(dev, hsotgusb_ick); Ah yes, I thought of that when I first saw the patch but forgot to do that on pm-2.6.29. Thanks, pushing to pm-2.6.29. Where's the dependency with this patch to the PM branch? If there is a dependency, can it be removed for mainline? To me it looks like we should send a patch against the mainline tree via linux-usb list. Regards, Tony 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] Runtime detection of Si features
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 13, 2009 9:43 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] Runtime detection of Si features
Sanjeev Premi pr...@ti.com writes:
The OMAP35x family has multiple variants differing
in the HW features. This patch detects these features
at runtime and prints information during the boot.
Since most of the code seemed repetitive, macros
have been used for readability.
Signed-off-by: Sanjeev Premi pr...@ti.com
I like the feature-based approach.
A couple questions though. Is there a bit/register that reports the
collapsed powerdomains of the devices with modified PRCM?
[sp] Unfortunately no. This is the reason, I used cpu_is_omap3505()
and cpu_is_omap3517() in my previous set of patches. This is what I
plan to do here as well; once I can identify the si based on the
features + the hawkeye number.
Also, how will other code query the features? You're currently
exporting the omap_has_*() functions, but there are no prototypes.
I think you missed the definition of macro OMAP3_HAS_FEATURE.
Since most of the code was repetitive, I used this macro for better
Readability.
I think I'd rather see a static inline functions in mach/cpu.h
for checking features. Comments to that end inlined below...
Yes. That can be done. With this patch I just wanted to get a view
on the overall approach.
---
arch/arm/mach-omap2/id.c | 106
--
1 files changed, 102 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..4476491 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -25,9 +25,49 @@
#include mach/control.h
#include mach/cpu.h
+/*
+ * OMAP3 features
+ */
+#define OMAP3_CONTROL_OMAP_STATUS 0x044c
This should probably go in mach/control.h
[sp] This was originally in control.h. Just shifted here for this
Patch. Will revert it back.
+#define OMAP3_SGX_SHIFT13
+#define OMAP3_SGX_MASK (3 OMAP3_SGX_SHIFT)
+#defineFEAT_SGX_FULL 0
+#defineFEAT_SGX_HALF 1
+#defineFEAT_SGX_NONE 2
+#define OMAP3_IVA_SHIFT12
+#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT)
+#defineFEAT_IVA0
+#defineFEAT_IVA_NONE 1
+
+#define OMAP3_L2CACHE_SHIFT10
+#define OMAP3_L2CACHE_MASK (3 OMAP3_L2CACHE_SHIFT)
+#defineFEAT_L2CACHE_NONE 0
+#defineFEAT_L2CACHE_64KB 1
+#defineFEAT_L2CACHE_128KB 2
+#defineFEAT_L2CACHE_256KB 3
+
+#define OMAP3_ISP_SHIFT5
+#define OMAP3_ISP_MASK (1 OMAP3_ISP_SHIFT)
+#defineFEAT_ISP0
+#defineFEAT_ISP_NONE 1
+
+#define OMAP3_NEON_SHIFT 4
+#define OMAP3_NEON_MASK(1 OMAP3_NEON_SHIFT)
+#defineFEAT_NEON 0
+#defineFEAT_NEON_NONE 1
+
+
+#define OMAP_HAS_L2CACHE 1
+#define OMAP_HAS_IVA (1 1)
+#define OMAP_HAS_SGX (1 2)
+#define OMAP_HAS_NEON (1 3)
+#define OMAP_HAS_ISP (1 4)
+
Use BIT()
Rename to OMAP3_*
move to mach/cpu.h
[sp] Okay
static struct omap_chip_id omap_chip;
static unsigned int omap_revision;
-
+static u32 omap_features ;
Call this omap3_features and make it global (with extern in
mach/cpu.h)
[sp] Okay.
unsigned int omap_rev(void)
{
@@ -35,6 +75,19 @@ unsigned int omap_rev(void)
}
EXPORT_SYMBOL(omap_rev);
+#define OMAP3_HAS_FEATURE(feat,flag)
\
+ unsigned int omap3_has_ ##feat(void)\
make this
static inline unsigned int omap3_has_ ##feat(void) ...
+ { \
+ return (omap_features OMAP_HAS_ ##flag); \
+ } \
+ EXPORT_SYMBOL(omap3_has_ ##feat);
+OMAP3_HAS_FEATURE(l2cache, L2CACHE);
+OMAP3_HAS_FEATURE(sgx, SGX);
+OMAP3_HAS_FEATURE(iva, IVA);
+OMAP3_HAS_FEATURE(neon, NEON);
+OMAP3_HAS_FEATURE(isp, ISP);
+
... and move this set to mach/cpu.h
and I'm ok with the rest of this patch.
Kevin
/**
* omap_chip_is - test whether currently running OMAP
matches a chip type
* @oc: omap_chip_t to test against
@@ -155,7 +208,33 @@ void __init omap24xx_check_revision(void)
pr_info(\n);
}
-void __init omap34xx_check_revision(void)
+#define OMAP3_CHECK_FEATURE(status,feat)
\
Re: [PATCHv3 00/20] OMAP ASoC changes in DMA utilization
On Thursday 13 August 2009 17:35:13 Valentin Eduardo (Nokia-D/Helsinki) wrote: Hello again guys, Here is version 3 of these changes. I've changed just 2 things: - all mcbsp instances are in element mode by default - moved all mcbsp related code to omap-mcbsp.c (although a single callback is still needed) Jarkko, I think we can add your patch for reading strings for dma op mode later on. In my opinion we can take this series as it is now, what do you think Jarkko? At least I don't see too (any?) big problems with it... Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com -- 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 04/13] OMAP2/3 clock: ensure each clock has a unique name
* Paul Walmsley p...@pwsan.com [090815 14:26]:
After the clkdev conversion, struct clk .name fields are free to be
unique and to reflect the underlying hardware naming convention. This
is important since it is useful for some core code that is unrelated
to the platform_device subsystem, such as the clock debugfs code and
the omap_hwmod code, to be able to address clocks by a single unique
identifier, since platform drivers are only weakly bound to clocks.
So, update all of the non-unique clock names in OMAP2/3 to be unique
names. In the future it might be ideal to ensure that the names match
the hardware information exactly, for ease of debugging and reference.
Giving up on the name + id combination is against what we've tried to
do with the clock framework in general. But like you say, when using
clkdev the common name is no longer needed.
Anybody see problems with changing to use unique clock names?
Regards,
Tony
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock24xx.h | 52 +-
arch/arm/mach-omap2/clock34xx.h | 60
---
2 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index d19cf7a..b81c40f 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -1821,7 +1821,7 @@ static struct clk gpt12_fck = {
};
static struct clk mcbsp1_ick = {
- .name = mcbsp_ick,
+ .name = mcbsp1_ick,
.ops= clkops_omap2_dflt_wait,
.id = 1,
.parent = l4_ck,
@@ -1832,7 +1832,7 @@ static struct clk mcbsp1_ick = {
};
static struct clk mcbsp1_fck = {
- .name = mcbsp_fck,
+ .name = mcbsp1_fck,
.ops= clkops_omap2_dflt_wait,
.id = 1,
.parent = func_96m_ck,
@@ -1843,7 +1843,7 @@ static struct clk mcbsp1_fck = {
};
static struct clk mcbsp2_ick = {
- .name = mcbsp_ick,
+ .name = mcbsp2_ick,
.ops= clkops_omap2_dflt_wait,
.id = 2,
.parent = l4_ck,
@@ -1854,7 +1854,7 @@ static struct clk mcbsp2_ick = {
};
static struct clk mcbsp2_fck = {
- .name = mcbsp_fck,
+ .name = mcbsp2_fck,
.ops= clkops_omap2_dflt_wait,
.id = 2,
.parent = func_96m_ck,
@@ -1865,7 +1865,7 @@ static struct clk mcbsp2_fck = {
};
static struct clk mcbsp3_ick = {
- .name = mcbsp_ick,
+ .name = mcbsp3_ick,
.ops= clkops_omap2_dflt_wait,
.id = 3,
.parent = l4_ck,
@@ -1876,7 +1876,7 @@ static struct clk mcbsp3_ick = {
};
static struct clk mcbsp3_fck = {
- .name = mcbsp_fck,
+ .name = mcbsp3_fck,
.ops= clkops_omap2_dflt_wait,
.id = 3,
.parent = func_96m_ck,
@@ -1887,7 +1887,7 @@ static struct clk mcbsp3_fck = {
};
static struct clk mcbsp4_ick = {
- .name = mcbsp_ick,
+ .name = mcbsp4_ick,
.ops= clkops_omap2_dflt_wait,
.id = 4,
.parent = l4_ck,
@@ -1898,7 +1898,7 @@ static struct clk mcbsp4_ick = {
};
static struct clk mcbsp4_fck = {
- .name = mcbsp_fck,
+ .name = mcbsp4_fck,
.ops= clkops_omap2_dflt_wait,
.id = 4,
.parent = func_96m_ck,
@@ -1909,7 +1909,7 @@ static struct clk mcbsp4_fck = {
};
static struct clk mcbsp5_ick = {
- .name = mcbsp_ick,
+ .name = mcbsp5_ick,
.ops= clkops_omap2_dflt_wait,
.id = 5,
.parent = l4_ck,
@@ -1920,7 +1920,7 @@ static struct clk mcbsp5_ick = {
};
static struct clk mcbsp5_fck = {
- .name = mcbsp_fck,
+ .name = mcbsp5_fck,
.ops= clkops_omap2_dflt_wait,
.id = 5,
.parent = func_96m_ck,
@@ -1931,7 +1931,7 @@ static struct clk mcbsp5_fck = {
};
static struct clk mcspi1_ick = {
- .name = mcspi_ick,
+ .name = mcspi1_ick,
.ops= clkops_omap2_dflt_wait,
.id = 1,
.parent = l4_ck,
@@ -1942,7 +1942,7 @@ static struct clk mcspi1_ick = {
};
static struct clk mcspi1_fck = {
- .name = mcspi_fck,
+ .name = mcspi1_fck,
.ops= clkops_omap2_dflt_wait,
.id = 1,
.parent = func_48m_ck,
@@ -1953,7 +1953,7 @@ static struct clk mcspi1_fck = {
};
static struct clk mcspi2_ick = {
- .name = mcspi_ick,
+ .name = mcspi2_ick,
.ops
Re: [PATCHv3 00/20] OMAP ASoC changes in DMA utilization
On Mon, 17 Aug 2009 11:22:30 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: On Thursday 13 August 2009 17:35:13 Valentin Eduardo (Nokia-D/Helsinki) wrote: Hello again guys, Here is version 3 of these changes. I've changed just 2 things: - all mcbsp instances are in element mode by default - moved all mcbsp related code to omap-mcbsp.c (although a single callback is still needed) Jarkko, I think we can add your patch for reading strings for dma op mode later on. In my opinion we can take this series as it is now, what do you think Jarkko? At least I don't see too (any?) big problems with it... Good to remind me. I was almost making a reviewing to this and Janusz's patches yesterday but ended up testing the MUSB and watching some aircrafts instead :-) But shortly going through the 3rd version of the set, only major issue I point that it's not based on top of my patch below so most probably patches 4 and 18 don't apply. Also changed API of omap_mcbsp_start/-stop would allow to remove new exported functions omap_mcbsp_xmit_enable and omap_mcbsp_recv_enable. commit c12abc012e18b362204345c323536f228d65c4db Author: Jarkko Nikula jhnik...@gmail.com Date: Fri Aug 7 09:59:47 2009 +0300 ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/sto Otherwise set looks fine since omap-mcbp.c and omap-pcm.c are not hard glued together and the element mode is the default. -- 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: [RFC][PATCH 0/4] TWL6030 patch series
On Mon, Aug 17, 2009 at 10:46:55AM +0530, Krishnamoorthy, Balaji T wrote: -Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Monday, August 17, 2009 5:30 AM To: Krishnamoorthy, Balaji T Cc: linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com; davi...@pacbell.net; Shilimkar, Santosh; Nayak, Rajendra; sa...@openedhand.com; w...@iguana.be; timo.t.kokko...@nokia.com; ben- li...@fluff.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk; m...@felipebalbi.com Subject: Re: [RFC][PATCH 0/4] TWL6030 patch series Hi Balaji, On Tue, Aug 11, 2009 at 06:30:24PM +0530, Krishnamoorthy, Balaji T wrote: Hi All, Can I have your comments on this so that I can rebase the patch for the upcoming merge window. I looked at the mfd related files, from patchwork.kernel.org. A few comments: * Besides making it look nicer, is there any other reason to change the twl4030-core.c name ? twl-core.c will have common code. twl4030-irq.c will have code specific for TWL4030 family and twl6030-irq.c will have specific code for TWL6030 family. Ok, I'm fine with renaming then. This is to make code easily readable and it wont be misleading. * You should also change drivers/mfd/Kconfig to reflect the more generic twl support. Added TWL6030 family to it, tps659x0 can be added if needed. It's up to you. Your Kconfig entry should be exhaustive as far as supported HW goes. * in drivers/mfd/twl-core.c: - status = twl_init_irq(client-irq, pdata-irq_base, pdata- irq_end); + status = twl_init_irq(client-irq, pdata-irq_base, +pdata-irq_end); Please remove it as it's unrelated to this patchset. Ok * Same for the - ( (devgrp) 13 | 1 12 | (grp) 9 | (type2) 7 \ + ((devgrp) 13 | 1 12 | (grp) 9 | (type2) 7 \ lines from include/linux/i2c/twl4030.h Ok * Why are you moving twl_init_irq and twl_exit_irq to twl.h ? twl_init_irq and twl_exit_irq is defined in twl4030-irq.c and called from twl-core.c. Earlier twl4030-core.c had declaration too. You're now exporting those 2 routines from a include/linux/ header, and I still dont understand why. Cheers, Samuel. Cheers, Samuel. Thanks and Regards, Balaji T K -Original Message- From: Krishnamoorthy, Balaji T Sent: Thursday, August 06, 2009 2:28 PM To: sa...@linux.intel.com Cc: linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com; davi...@pacbell.net; Shilimkar, Santosh; Nayak, Rajendra; sa...@openedhand.com; w...@iguana.be; timo.t.kokko...@nokia.com; ben- li...@fluff.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk; Krishnamoorthy, Balaji T Subject: RE: [RFC][PATCH 0/4] TWL6030 patch series Hi Samuel, Could you please add your comments on the following patch series. series 1 [PATCH 1/4] ARM: OMAP: Rename twl4030* driver files to enable re-use [PATCH 2/4] ARM: OMAP: Rename all twl4030_i2c*. [PATCH 3/4] ARM: OMAP: Rename twl4030_ in rtc-twl.c to make it generic rtc [PATCH 4/4] ARM: OMAP: Rename twl4030_ to twl_ in twl-regulator.c to make it generic reg series 2 dependent on series 1 [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators [RFC][PATCH v2 3/4] OMAP4: PMIC: Add support for twl6030 regulators [RFC][PATCH v2 2/4] OMAP4: PMIC: Add support for twl6030 RTC [RFC][PATCH v2 1/4] OMAP4: PMIC: Add support for twl6030 irq framework Thanks and Regards, Balaji T K -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Krishnamoorthy, Balaji T Sent: Monday, July 20, 2009 7:04 PM To: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com; davi...@pacbell.net; Shilimkar, Santosh; Nayak, Rajendra; sa...@openedhand.com; w...@iguana.be; timo.t.kokko...@nokia.com; ben- li...@fluff.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk Subject: [RFC][PATCH 0/4] TWL6030 patch series The upcoming TWL6030 is companion chip for OMAP4 like the current TWL4030 for OMAP3. This patch series adds support for TWL6030 irq framework, and driver support for RTC and regulator. drivers/mfd/twl6030-irq.c files is newly added as INTERRUPT status registers, ack and clear mechanism has changed from twl4030,5030. drivers/rtc/rtc-twl.c will support twl4030,twl5030, and also twl6030 rtc drivers/regulator/twl-regulator.c will support twl regulators. include/linux/i2c/twl.h will have TWL4030 and TWL6030 offsets selected at compile time by
Re: [RFC][PATCH 1/3] ARM: OMAP: DMA: Add support for DMA channel self linking on OMAP1510
On Mon, 10 Aug 2009 10:50:00 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Implement DMA channel self linking on OMAP1510 using AUTO_INIT and REPEAT flags of the DMA CCR register. Created against linux-2.6.31-rc5. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Tony, I'm fine with this patch. Although the autoinitialization != channel linking, in SW point of view autoinitialization and channel linking with itself looks the same so it's better to re-utilize existing omap_dma_link_lch also for 1510 DMA autoinitialization than inventing own API for it. Acked-by: Jarkko Nikula jhnik...@gmail.com -- 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 04/13] OMAP2/3 clock: ensure each clock has a unique name
Hi Tony, On Mon, 17 Aug 2009, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [090815 14:26]: After the clkdev conversion, struct clk .name fields are free to be unique and to reflect the underlying hardware naming convention. This is important since it is useful for some core code that is unrelated to the platform_device subsystem, such as the clock debugfs code and the omap_hwmod code, to be able to address clocks by a single unique identifier, since platform drivers are only weakly bound to clocks. So, update all of the non-unique clock names in OMAP2/3 to be unique names. In the future it might be ideal to ensure that the names match the hardware information exactly, for ease of debugging and reference. Giving up on the name + id combination is against what we've tried to do with the clock framework in general. This already happened with the clkdev conversion a few months ago. At that point, device drivers address clocks with a clock alias string, e.g., fck, plus a struct device pointer. This patch doesn't change that. What it does remove is the need for internal core code to fake up a struct device simply to access a clock. It also allows us to harmonize the clock names, used internally in core code, with the hardware reality, which uses unique names to identify clocks. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/3] ASoC: OMAP: Make use of DMA channel self linking on OMAP1510
On Mon, 10 Aug 2009 10:50:04 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Use newly implemented DMA channel self linking on OMAP1510 like on other OMAP models. Remove unnecessary DMA transfer restart from interrupt handler routine. The interrupt routine used to maintain a period index, originally needed for counting up periods up to a full buffer in order to restart the DMA transfer. For some time, this counter is also used as a replacement for hardware DMA progress counter that has been found unusable on OMAP1510 in case of playback. Thus, the period index calculation cannot be omitted completely. However, the accuracy of this counter can still suffer from missing DMA interrupts. In order to work correctly, it requires patch 1 from this series also applied: [RFC][PATCH 1/3] ARM: OMAP: DMA: Add support for DMA channel self linking on OMAP1510 Created against linux-2.6.31-rc5. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Nice to see code to be more uniform across the OMAP's. Note this depends on patch 1 which touches the arch/arm/plat-omap/dma.c. Acked-by: Jarkko Nikula jhnik...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3 v3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter
On Tue, 11 Aug 2009 21:44:29 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Enhance period_index accuracy, particularly just before buffer rewind, by making use of DMA interrupt status flags in addition to simply counting up interrupts. Changes since v2: - } + } else if (stat == OMAP_DMA_LAST_IRQ) + return; Is this test needed? This interrupt is set only for playback on omap1510 so this looks null-op. You're right, I have put it here before limiting the flag request to playback on OMAP1510 only. So it can be omitted... + omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ | + OMAP_DMA_LAST_IRQ); Indent OMAP_DMA_LAST_IRQ with tab(s) and spaces to the same column than OMAP_DMA_FRAME_IRQ. Looks nicer then. OK, will fix it. Should the OMAP_DMA_BLOCK_IRQ to be set since it is handled in omap_pcm_dma_irq? This one is already requested from inside omap_request_dma() and used inside omap1_dma_handle_ch() in addition to passing it to us. But for less confusion, it'll be better if requested from here too. I'm fine with this 3rd version. Probably Mark would like to have git format-patch formatted version for avoiding manual commit log editing. Acked-by: Jarkko Nikula jhnik...@gmail.com -- 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 04/13] OMAP2/3 clock: ensure each clock has a unique name
On Mon, Aug 17, 2009 at 03:14:45AM -0600, Paul Walmsley wrote: What it does remove is the need for internal core code to fake up a struct device simply to access a clock. It also allows us to harmonize the clock names, used internally in core code, with the hardware reality, which uses unique names to identify clocks. That problem is already solved. clk_get_sys() -- 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: [RFC][PATCH 0/4] TWL6030 patch series
-Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] On Mon, Aug 17, 2009 at 10:46:55AM +0530, Krishnamoorthy, Balaji T wrote: From: Samuel Ortiz [mailto:sa...@linux.intel.com] * Why are you moving twl_init_irq and twl_exit_irq to twl.h ? twl_init_irq and twl_exit_irq is defined in twl4030-irq.c and called from twl-core.c. Earlier twl4030-core.c had declaration too. You're now exporting those 2 routines from a include/linux/ header, and I still dont understand why. My assumption was that declaration has to be in .h file. But since these two functions are called only from twl-core.c files, I can keep it as before, without moving to twl.h -- 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 04/13] OMAP2/3 clock: ensure each clock has a unique name
Hello Russell, On Mon, 17 Aug 2009, Russell King - ARM Linux wrote: On Mon, Aug 17, 2009 at 03:14:45AM -0600, Paul Walmsley wrote: What it does remove is the need for internal core code to fake up a struct device simply to access a clock. It also allows us to harmonize the clock names, used internally in core code, with the hardware reality, which uses unique names to identify clocks. That problem is already solved. clk_get_sys() That solves the first problem, but not the second. Is there some reason that OMAP core code (aside from the clkdev mapping structures in mach-omap2/clock*.c) should know, or care, whether a platform device name is bound to that clock? On OMAP, we have uniquely-named clock lines in the technical documentation. It is possible that other platforms don't have this. But for us, I'd submit that it makes more sense for internal core code to fetch a clock documented as MMC1_FCLK with: c = omap_clk_get_by_name(mmc1_fck); rather than: c = clk_get_sys(mmci-omap-hs.0, ick); (* ideally, of course, we'd use mmc1_fclk rather than mmc1_fck, this is a legacy issue that has been left for a future patch.) As a side benefit, it also makes our clock debugfs setup easier, so a clock can be identified in the path as simply /debugfs/clock/.../mmc1_fck/, rather than something like /debugfs/clock/.../mmci-omap-hs.0-mmc1_fck/ or /debugfs/clock/.../mmci-omap-hs.0/mmc1_fck. Thoughts? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/13] OMAP2/3 clock: ensure each clock has a unique name
* Paul Walmsley p...@pwsan.com [090817 13:06]: Hello Russell, On Mon, 17 Aug 2009, Russell King - ARM Linux wrote: On Mon, Aug 17, 2009 at 03:14:45AM -0600, Paul Walmsley wrote: What it does remove is the need for internal core code to fake up a struct device simply to access a clock. It also allows us to harmonize the clock names, used internally in core code, with the hardware reality, which uses unique names to identify clocks. That problem is already solved. clk_get_sys() That solves the first problem, but not the second. Is there some reason that OMAP core code (aside from the clkdev mapping structures in mach-omap2/clock*.c) should know, or care, whether a platform device name is bound to that clock? On OMAP, we have uniquely-named clock lines in the technical documentation. It is possible that other platforms don't have this. But for us, I'd submit that it makes more sense for internal core code to fetch a clock documented as MMC1_FCLK with: c = omap_clk_get_by_name(mmc1_fck); rather than: c = clk_get_sys(mmci-omap-hs.0, ick); (* ideally, of course, we'd use mmc1_fclk rather than mmc1_fck, this is a legacy issue that has been left for a future patch.) As a side benefit, it also makes our clock debugfs setup easier, so a clock can be identified in the path as simply /debugfs/clock/.../mmc1_fck/, rather than something like /debugfs/clock/.../mmci-omap-hs.0-mmc1_fck/ or /debugfs/clock/.../mmci-omap-hs.0/mmc1_fck. Thoughts? I guess if we wanted to do this in a generic way, we could have clkdev_get_hw_name() in arch/arm/common/clkdev.c. Then we could have struct omap_clk contain the hardware clock name. But then we're wasting memory and duplicating parts of the names, so I don't think that it would be any better solution compared to renaming the clocks like you're doing. 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
[PATCH] Fix mismatched ifdefs
The #endif at end of the file was missing. However, an additional #else ... #endif was causing the compiler to keep going. The problem was found when compiler started reporting the newly added inline functions were being reported as redeclared by the compiler. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 11e73d9..4fbc6a9 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -317,8 +317,6 @@ IS_OMAP_TYPE(3430, 0x3430) # undef cpu_is_omap730 # define cpu_is_omap730() 1 # endif -#endif -#else # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() 1 @@ -433,3 +431,5 @@ IS_OMAP_TYPE(3430, 0x3430) int omap_chip_is(struct omap_chip_id oci); void omap2_check_revision(void); + +#endif /* __ASM_ARCH_OMAP_CPU_H */ -- 1.6.2.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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Hi Russell,
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Saturday, August 15, 2009 11:47 PM
To: Syed Mohammed, Khasim
Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org
Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Sat, Aug 15, 2009 at 09:47:18PM +0530, Syed Mohammed, Khasim wrote:
Backtrace:
[c002c884] (__flush_dcache_page+0x0/0x3c) from [c002c7c0]
(update_mmu_cache+
0x8c/0xb0)
[c002c734] (update_mmu_cache+0x0/0xb0) from [c008611c]
(handle_mm_fault+0x53
4/0x5ac)
Bingo!
snip
The question is how best to handle determining if a PFN (which could be
somewhere in the range 0 to 0xf for 32-bit address space) is valid
without eating up too much memory. One simple way would be to allocate
a bitmap. That'll eat up 128K of memory though, and we know that we
normally have a small amount of that range used... I think a binary
search of the meminfo struct might be the best all-round solution.
Could you try this patch please?
This patch seem to be working, I don't see any dump like before.
Can you please advice on how to get this patch into kernel? I mean, will you be
handling it or we need to re-submit them with your signed off?
Please let me know if there are any corrections that you want me to test, I
will be more happy to do the same.
Thanks for all your help.
Regards,
Khasim
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 376be1a..cefedf0 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -218,7 +218,6 @@ static inline __deprecated void *bus_to_virt(unsigned
long x)
*
* page_to_pfn(page)convert a struct page * to a PFN number
* pfn_to_page(pfn) convert a _valid_ PFN number to struct page *
- * pfn_valid(pfn) indicates whether a PFN number is valid
*
* virt_to_page(k) convert a _valid_ virtual address to struct page *
* virt_addr_valid(k) indicates whether a virtual address is valid
@@ -227,10 +226,6 @@ static inline __deprecated void *bus_to_virt(unsigned
long x)
#define ARCH_PFN_OFFSET PHYS_PFN_OFFSET
-#ifndef CONFIG_SPARSEMEM
-#define pfn_valid(pfn) ((pfn) = PHYS_PFN_OFFSET (pfn)
(PHYS_PFN_OFFSET + max_mapnr))
-#endif
-
#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) PAGE_SHIFT)
#define virt_addr_valid(kaddr) ((unsigned long)(kaddr) = PAGE_OFFSET
(unsigned long)(kaddr)
(unsigned long)high_memory)
@@ -247,18 +242,6 @@ static inline __deprecated void *bus_to_virt(unsigned
long x)
#define arch_pfn_to_nid(pfn) PFN_TO_NID(pfn)
#define arch_local_page_offset(pfn, nid) LOCAL_MAP_NR((pfn) PAGE_SHIFT)
-#define pfn_valid(pfn) \
- ({ \
- unsigned int nid = PFN_TO_NID(pfn); \
- int valid = nid MAX_NUMNODES; \
- if (valid) {\
- pg_data_t *node = NODE_DATA(nid); \
- valid = (pfn - node-node_start_pfn) \
- node-node_spanned_pages; \
- } \
- valid; \
- })
-
#define virt_to_page(kaddr) \
(ADDR_TO_MAPBASE(kaddr) + LOCAL_MAP_NR(kaddr))
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index 9c746af..3a32af4 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -194,6 +194,10 @@ typedef unsigned long pgprot_t;
typedef struct page *pgtable_t;
+#ifndef CONFIG_SPARSEMEM
+extern int pfn_valid(unsigned long);
+#endif
+
#include asm/memory.h
#endif /* !__ASSEMBLY__ */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8277802..2542583 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -15,6 +15,7 @@
#include linux/mman.h
#include linux/nodemask.h
#include linux/initrd.h
+#include linux/sort.h
#include linux/highmem.h
#include asm/mach-types.h
@@ -334,12 +335,42 @@ static void __init bootmem_free_node(int node, struct
meminfo *mi)
free_area_init_node(node, zone_size, start_pfn, zhole_size);
}
+#ifndef CONFIG_SPARSEMEM
+int pfn_valid(unsigned long pfn)
+{
+ struct meminfo *mi = meminfo;
+ unsigned int mid, left = 0, right = mi-nr_banks;
+
+ while ((mid = (right - left) / 2) 0) {
+ struct membank *bank = mi-bank[mid];
+
+ if (pfn bank_pfn_start(bank))
+ right = mid;
+ else if (pfn = bank_pfn_end(bank))
+ left = mid + 1;
+ else
+ return 1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(pfn_valid);
+#endif
RE: [PATCH] Runtime detection of Si features
-Original Message- From: Menon, Nishanth Sent: Thursday, August 13, 2009 11:29 PM To: Kevin Hilman Cc: Pandita, Vikram; Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] Runtime detection of Si features Nishanth Menon had written, on 08/13/2009 11:43 AM, the following: Kevin Hilman had written, on 08/13/2009 11:40 AM, the following: Pandita, Vikram vikram.pand...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sent: Thursday, August 13, 2009 11:31 AM Since most of the code seemed repetitive, macros have been used for readability. Signed-off-by: Sanjeev Premi pr...@ti.com I like the feature-based approach. A couple questions though. Is there a bit/register that reports the collapsed powerdomains of the devices with modified PRCM? Also, how will other code query the features? You're currently exporting the omap_has_*() functions, but there are no prototypes. I think I'd rather see a static inline functions in mach/cpu.h for checking features. Comments to that end inlined below... Wonder if we can setup some sort of infrastructure for: a) features b) erratas linked to OMAP revs + even better w.r.t silicon module(SGX,I2c) revisions since at times they are used across multiple OMAPs? We are hitting exactly this issue with I2C errata 1.153 Instead of basing the errata check on cpu_is...(), its more appropriate to base it on IP revision of I2C. Shouldn't the IP revision of I2C be avaialble in an I2C revision register an be used in the driver instead of cpu_is*? what I was proposing is a much more generic infrastructure which i2c among other modules can use. Getting IP revision is already available in the specific IP modules REVISION registers - we might want to standardize how drivers handle revision based feature/errata set to ensure that they would have an optimal way to handle the same.. just my 2 cents.. Thinking of this a little more: driver's smart handling aside, having a sysfs entry to dump the features and erratas for each of the modules used is so much nice to have.. sigh.. just wondering if anyone has ideas how feasible this might be.. [sp] If all IPs are able to populate a revision field in the device structure during init/probe then there could be generic APIs get_ip_revision() and is_ip_revision(); Since erratas are linked to the ip versions, this could just be a 'print' problem - whether to a sysfs/ a proc entry. -- Regards, Nishanth Menon -- 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
Getting DSS2 to mainline
Hi, As I'm new to sending patches upstream, I'm not sure how to go forward with DSS2 now. Should I send it to linux-arm-kernel mailing list, or directly to main linux kernel mailing list? Or is there a route through fbdev-devel list for DSS2 to go forward? Tomi -- 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 1/3] MFD: TWL4030: Add support for TWL4030/5030 dynamic power switching
Hi Samuel,
On 09 Aug 04, Samuel Ortiz wrote:
Hi Amit,
My apologies for the late answer, but I'm going through my mail backlog after
a 3 weeks holidays.
And you replied just when I was away :)
Replies inline. Refreshed patchset follows in a new thread.
On Wed, Jul 08, 2009 at 01:49:27PM +0300, Amit Kucheria wrote:
The TWL4030/5030 family of multifunction devices allows board-specific
control of the the various regulators, clock and reset lines through
'scripts' that are loaded into its memory. This allows for Dynamic Power
Switching (DPS).
Implement board-independent core support for DPS that is then used by
board-specific code to load custom DPS scripts.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
Some comments here:
---
drivers/mfd/Kconfig | 13 ++
drivers/mfd/Makefile|1 +
drivers/mfd/twl4030-core.c | 12 ++
drivers/mfd/twl4030-power.c | 384
+++
include/linux/i2c/twl4030.h | 91 +-
5 files changed, 491 insertions(+), 10 deletions(-)
create mode 100644 drivers/mfd/twl4030-power.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 491ac0f..94fa9a0 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -108,6 +108,19 @@ config TWL4030_CORE
high speed USB OTG transceiver, an audio codec (on most
versions) and many other features.
+config TWL4030_POWER
+ bool Support power resources on TWL4030 family chips
+ depends on TWL4030_CORE
+ help
+ Say yes here if you want to use the power resources on the
+ TWL4030 family chips. Most of these resources are regulators,
+ which have a separate driver; some are control signals, such
+ as clock request handshaking.
+
+ This driver uses board-specific data to initialize the resources
+ and load scripts controling which resources are switched off/on
+ or reset when a sleep, wakeup or warm reset event occurs.
+
config MFD_TMIO
bool
default n
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 6f8a9a1..84b9eda 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_TPS65010)+= tps65010.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-irq.o
+obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
obj-$(CONFIG_MFD_CORE) += mfd-core.o
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index ca54996..ee8ede8 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -89,6 +89,12 @@
#define twl_has_madc() false
#endif
+#ifdef CONFIG_TWL4030_POWER
+#define twl_has_power()true
+#else
+#define twl_has_power()false
+#endif
+
#if defined(CONFIG_RTC_DRV_TWL4030) ||
defined(CONFIG_RTC_DRV_TWL4030_MODULE)
#define twl_has_rtc() true
#else
@@ -231,6 +237,8 @@ static struct twl4030mapping
twl4030_map[TWL4030_MODULE_LAST + 1] = {
{ 3, TWL4030_BASEADD_SECURED_REG },
};
+extern void twl4030_power_init(struct twl4030_power_data *triton2_scripts);
Maybe this one should be defined in twl4030.h.
Done.
/*--*/
/* Exported Functions */
@@ -788,6 +796,10 @@ twl4030_probe(struct i2c_client *client, const struct
i2c_device_id *id)
/* setup clock framework */
clocks_init(client-dev);
+ /* load power event scripts */
+ if (twl_has_power() pdata-power)
+ twl4030_power_init(pdata-power);
+
/* Maybe init the T2 Interrupt subsystem */
if (client-irq
pdata-irq_base
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
new file mode 100644
index 000..bb9e45f
--- /dev/null
+++ b/drivers/mfd/twl4030-power.c
@@ -0,0 +1,384 @@
+/*
+ * linux/drivers/i2c/chips/twl4030-power.c
+ *
+ * Handle TWL4030 Power initialization
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2006 Texas Instruments, Inc
+ *
+ * Written by Kalle Jokiniemi
+ * Peter De Schrijver peter.de-schrij...@nokia.com
+ * Several fixes by Amit Kucheria amit.kuche...@verdurent.com
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ *
Re: [PATCH 2/3] MFD: TWL4030: print warning for out-of-order script loading
On 09 Aug 04, Samuel Ortiz wrote:
Hi Amit,
On Wed, Jul 08, 2009 at 01:49:35PM +0300, Amit Kucheria wrote:
When the sleep script is loaded before the wakeup script, there is a
chance that the system might go to sleep before the wakeup script
loading is completed. This will lead to a system that does not wakeup
and has been observed to cause non-booting boards.
Various options were considered to solve this problem, including
modification of the core twl4030 power code to be smart enough to
reorder the loading of the scripts. But it felt too over-engineered.
Hence this patch just warns the DPS script developer so that they may be
reordered in the board-code itself.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
drivers/mfd/twl4030-power.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index bb9e45f..ef4cc4e 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -315,6 +315,7 @@ static int __init load_triton_script(struct
twl4030_script *tscript)
{
u8 address = triton_next_free_address;
int err;
+ static u8 mask = 0;
/* Make sure the script isn't going beyond last valid address */
if ((address + tscript-size) (END_OF_SCRIPT-1)) {
@@ -331,14 +332,20 @@ static int __init load_triton_script(struct
twl4030_script *tscript)
if (tscript-flags TRITON_WRST_SCRIPT)
err |= config_warmreset_sequence(address);
- if (tscript-flags TRITON_WAKEUP12_SCRIPT)
+ if (tscript-flags TRITON_WAKEUP12_SCRIPT) {
err |= config_wakeup12_sequence(address);
+ mask |= TRITON_WAKEUP12_SCRIPT;
+ }
if (tscript-flags TRITON_WAKEUP3_SCRIPT)
err |= config_wakeup3_sequence(address);
- if (tscript-flags TRITON_SLEEP_SCRIPT)
+ if (tscript-flags TRITON_SLEEP_SCRIPT) {
Wouldnt something like:
if (tscript-flags (TRITON_SLEEP_SCRIPT | TRITON_WAKEUP12_SCRIPT)) {
save us from using an additional mask variable and simplify this patch ?
I don't see how this will save the mask variable. What I need to detect
that the SLEEP script is loaded before the WAKEUP script. That should
trigger a warning.
--
-
Amit Kucheria, Kernel Developer, Verdurent
-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] MFD: TWL4030: OMAP: Board-specifc DPS scripts for RX51 board
On 09 Aug 04, Samuel Ortiz wrote:
Hi Amit,
On Wed, Jul 08, 2009 at 01:49:39PM +0300, Amit Kucheria wrote:
Add support for Dynamic Power Switching (DPS) for the RX51 board.
Could I have an Acked-by from Tony or someone from Nokia maintaining this
board (e.g. Lauri) ?
I'll cc Tony in the refreshed patches. Please note that this is not the
final version of the script. As the scripts are optimised, I'll send in
fixes.
Regards,
Amit
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 122
+-
1 files changed, 120 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a0bf67..f7ebec8 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1,5 +1,5 @@
/*
- * linux/arch/arm/mach-omap2/board-rx51-flash.c
+ * linux/arch/arm/mach-omap2/board-rx51-peripherals.c
*
* Copyright (C) 2008-2009 Nokia
*
@@ -278,7 +278,124 @@ static struct twl4030_gpio_platform_data
rx51_gpio_data = {
.setup = rx51_twlgpio_setup,
};
-static struct twl4030_platform_data rx51_twldata = {
+static struct twl4030_ins sleep_on_seq[] __initdata = {
+/*
+ * Turn off VDD1 and VDD2.
+ */
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 4},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_OFF), 2},
+/*
+ * And also turn off the OMAP3 PLLs and the sysclk output.
+ */
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 3},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x17, RES_STATE_OFF), 3},
+};
+
+static struct twl4030_script sleep_on_script __initdata = {
+ .script = sleep_on_seq,
+ .size = ARRAY_SIZE(sleep_on_seq),
+ .flags = TRITON_SLEEP_SCRIPT,
+};
+
+static struct twl4030_ins wakeup_seq[] __initdata = {
+/*
+ * Reenable the OMAP3 PLLs.
+ * Wakeup VDD1 and VDD2.
+ * Reenable sysclk output.
+ */
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 0x30},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 0x30},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 0x37},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 3},
+};
+
+static struct twl4030_script wakeup_script __initdata = {
+ .script = wakeup_seq,
+ .size = ARRAY_SIZE(wakeup_seq),
+ .flags = TRITON_WAKEUP12_SCRIPT,
+};
+
+static struct twl4030_ins wakeup_p3_seq[] __initdata = {
+/*
+ * Wakeup VDD1 (dummy to be able to insert a delay)
+ * Enable CLKEN
+ */
+ {MSG_SINGULAR(DEV_GRP_P1, 0x17, RES_STATE_ACTIVE), 3},
+};
+
+static struct twl4030_script wakeup_p3_script __initdata = {
+ .script = wakeup_p3_seq,
+ .size = ARRAY_SIZE(wakeup_p3_seq),
+ .flags = TRITON_WAKEUP3_SCRIPT,
+};
+
+static struct twl4030_ins wrst_seq[] __initdata = {
+/*
+ * Reset twl4030.
+ * Reset VDD1 regulator.
+ * Reset VDD2 regulator.
+ * Reset VPLL1 regulator.
+ * Enable sysclk output.
+ * Reenable twl4030.
+ */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 0, 1, RES_STATE_ACTIVE),
+ 0x13},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_PP, 0, 2, RES_STATE_WRST), 0x13},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_PP, 0, 3, RES_STATE_OFF), 0x13},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VDD1, RES_STATE_WRST), 0x13},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VDD2, RES_STATE_WRST), 0x13},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VPLL1, RES_STATE_WRST), 0x35},
+ {MSG_SINGULAR(DEV_GRP_P1, RES_HFCLKOUT, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TRITON_WRST_SCRIPT,
+};
+
+static struct twl4030_script *twl4030_scripts[] __initdata = {
+ /* wakeup12 script should be loaded before sleep script, otherwise a
+ board might hit retention before loading of wakeup script is
+ completed. This can cause boot failures depending on timing issues.
+ */
+ wakeup_script,
+ sleep_on_script,
+ wakeup_p3_script,
+ wrst_script,
+};
+
+static struct twl4030_resconfig twl4030_rconfig[] __initdata = {
+ { .resource = RES_VINTANA1, .devgroup = -1, .type = -1, .type2 = 1 },
+ { .resource = RES_VINTANA2, .devgroup = -1, .type = -1, .type2 = 1 },
+ { .resource = RES_VINTDIG, .devgroup = -1, .type = -1, .type2 = 1 },
+ { .resource = RES_VMMC1, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VMMC2, .devgroup = DEV_GRP_NULL, .type = -1,
+ .type2 = 3},
+ { .resource = RES_VAUX1, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VAUX2, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VAUX3, .devgroup = -1, .type =
[PATCH v2] Runtime detection of Si features
The OMAP35x family has multiple variants differing
in the HW features. This patch detects these features
at runtime and prints information during the boot.
Since most of the code seemed repetitive, macros
have been used for readability.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c | 52 +++--
arch/arm/mach-omap2/mmc-twl4030.c |1 +
arch/arm/plat-omap/include/mach/control.h | 34 +++
arch/arm/plat-omap/include/mach/cpu.h | 23 +
4 files changed, 107 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..03b80f2 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,7 @@
static struct omap_chip_id omap_chip;
static unsigned int omap_revision;
+u32 omap3_features;
unsigned int omap_rev(void)
{
@@ -155,7 +156,33 @@ void __init omap24xx_check_revision(void)
pr_info(\n);
}
-void __init omap34xx_check_revision(void)
+#define OMAP3_CHECK_FEATURE(status,feat) \
+ if (((status OMAP3_ ##feat## _MASK) \
+OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
+ omap3_features |= OMAP3_HAS_ ##feat;\
+ }
+
+void __init omap3_check_features(void)
+{
+ u32 status;
+
+ omap3_features = 0;
+
+ status = omap_ctrl_readl(OMAP3_CONTROL_OMAP_STATUS);
+
+ OMAP3_CHECK_FEATURE(status, L2CACHE);
+ OMAP3_CHECK_FEATURE(status, IVA);
+ OMAP3_CHECK_FEATURE(status, SGX);
+ OMAP3_CHECK_FEATURE(status, NEON);
+ OMAP3_CHECK_FEATURE(status, ISP);
+
+ /*
+* TODO: Get additional info (where applicable)
+* e.g. Size of L2 cache.
+*/
+}
+
+void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
@@ -212,6 +239,22 @@ out:
pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
}
+#define OMAP3_SHOW_FEATURE(feat) \
+ if (omap3_has_ ##feat()) { \
+ pr_info ( - #feat : Y); \
+ } else {\
+ pr_info ( - #feat : N); \
+ }
+
+void __init omap3_cpuinfo(void)
+{
+ OMAP3_SHOW_FEATURE(l2cache);
+ OMAP3_SHOW_FEATURE(iva);
+ OMAP3_SHOW_FEATURE(sgx);
+ OMAP3_SHOW_FEATURE(neon);
+ OMAP3_SHOW_FEATURE(isp);
+}
+
/*
* Try to detect the exact revision of the omap we're running on
*/
@@ -223,8 +266,11 @@ void __init omap2_check_revision(void)
*/
if (cpu_is_omap24xx())
omap24xx_check_revision();
- else if (cpu_is_omap34xx())
- omap34xx_check_revision();
+ else if (cpu_is_omap34xx()) {
+ omap3_check_features();
+ omap3_check_revision();
+ omap3_cpuinfo();
+ }
else if (cpu_is_omap44xx()) {
printk(KERN_INFO FIXME: CPU revision = OMAP4430\n);
return;
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 3c04c2f..d68284d 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -10,6 +10,7 @@
* published by the Free Software Foundation.
*/
#include linux/err.h
+#include linux/bitops.h
#include linux/io.h
#include linux/module.h
#include linux/platform_device.h
diff --git a/arch/arm/plat-omap/include/mach/control.h
b/arch/arm/plat-omap/include/mach/control.h
index 826d317..74ec2f9 100644
--- a/arch/arm/plat-omap/include/mach/control.h
+++ b/arch/arm/plat-omap/include/mach/control.h
@@ -202,6 +202,40 @@
#define OMAP3_PADCONF_WAKEUPEVENT0 (1 15)
#define OMAP3_PADCONF_WAKEUPENABLE0(1 14)
+/*
+ * CONTROL OMAP STATUS register to identify OMAP3 features
+ */
+#define OMAP3_CONTROL_OMAP_STATUS 0x044c
+
+#define OMAP3_SGX_SHIFT13
+#define OMAP3_SGX_MASK (3 OMAP3_SGX_SHIFT)
+#defineFEAT_SGX_FULL 0
+#defineFEAT_SGX_HALF 1
+#defineFEAT_SGX_NONE 2
+
+#define OMAP3_IVA_SHIFT12
+#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT)
+#defineFEAT_IVA0
+#defineFEAT_IVA_NONE 1
+
+#define OMAP3_L2CACHE_SHIFT10
+#define OMAP3_L2CACHE_MASK (3 OMAP3_L2CACHE_SHIFT)
+#defineFEAT_L2CACHE_NONE 0
+#defineFEAT_L2CACHE_64KB 1
+#defineFEAT_L2CACHE_128KB 2
+#defineFEAT_L2CACHE_256KB 3
+
+#define OMAP3_ISP_SHIFT5
+#define OMAP3_ISP_MASK (1 OMAP3_ISP_SHIFT)
+#defineFEAT_ISP0
+#defineFEAT_ISP_NONE 1
+
+#define OMAP3_NEON_SHIFT 4
+#define
Re: [PATCHv3 00/20] OMAP ASoC changes in DMA utilization
On Mon, Aug 17, 2009 at 11:07:37AM +0200, Jarkko Nikula wrote: On Mon, 17 Aug 2009 11:22:30 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: On Thursday 13 August 2009 17:35:13 Valentin Eduardo (Nokia-D/Helsinki) wrote: Hello again guys, Here is version 3 of these changes. I've changed just 2 things: - all mcbsp instances are in element mode by default - moved all mcbsp related code to omap-mcbsp.c (although a single callback is still needed) Jarkko, I think we can add your patch for reading strings for dma op mode later on. In my opinion we can take this series as it is now, what do you think Jarkko? At least I don't see too (any?) big problems with it... Good to remind me. I was almost making a reviewing to this and Janusz's patches yesterday but ended up testing the MUSB and watching some aircrafts instead :-) But shortly going through the 3rd version of the set, only major issue I point that it's not based on top of my patch below so most probably patches 4 and 18 don't apply. Also changed API of omap_mcbsp_start/-stop would allow to remove new exported functions omap_mcbsp_xmit_enable and omap_mcbsp_recv_enable. commit c12abc012e18b362204345c323536f228d65c4db Author: Jarkko Nikula jhnik...@gmail.com Date: Fri Aug 7 09:59:47 2009 +0300 ARM: OMAP: McBSP: Fix ASoC on OMAP1510 by fixing API of omap_mcbsp_start/sto Otherwise set looks fine since omap-mcbp.c and omap-pcm.c are not hard glued together and the element mode is the default. Cool. I've rebased and tested the series with beagle using Takashi's tree. I'm about to send version #4 based on his tree then. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe alsa-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Eduardo Valentin -- 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: [alsa-devel] [PATCHv3 00/20] OMAP ASoC changes in DMA utilization
On Mon, Aug 17, 2009 at 02:36:59PM +0300, Eduardo Valentin wrote: Cool. I've rebased and tested the series with beagle using Takashi's tree. I'm about to send version #4 based on his tree then. Please could you use --no-chain-reply-to when sending? It works a lot better with threaded mail readers. -- 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: [alsa-devel] [PATCHv3 00/20] OMAP ASoC changes in DMA utilization
On Mon, Aug 17, 2009 at 01:52:58PM +0200, ext Mark Brown wrote: On Mon, Aug 17, 2009 at 02:36:59PM +0300, Eduardo Valentin wrote: Cool. I've rebased and tested the series with beagle using Takashi's tree. I'm about to send version #4 based on his tree then. Forgot to mention that I've tested this also using those three patches from Janusz Krzysztofik. Please could you use --no-chain-reply-to when sending? It works a lot better with threaded mail readers. Sure! -- Eduardo Valentin -- 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
[PATCHv4 02/20] OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers.
From: Eduardo Valentin eduardo.valen...@nokia.com Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index b85e6e6..ceaf9ee 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,10 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON 0x8C +#define OMAP_MCBSP_REG_THRSH2 0x90 +#define OMAP_MCBSP_REG_THRSH1 0x94 +#define OMAP_MCBSP_REG_IRQST 0xA0 +#define OMAP_MCBSP_REG_IRQEN 0xA4 #define OMAP_MCBSP_REG_XCCR0xAC #define OMAP_MCBSP_REG_RCCR0xB0 -- 1.6.2.GIT -- 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
[PATCHv4 04/20] OMAP: McBSP: Add transmit/receive threshold handler
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch adds a way to handle transmit/receive threshold.
It export to mcbsp users a callback registration procedure.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index ceaf9ee..2544aa5 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -389,6 +389,15 @@ int omap_mcbsp_init(void);
void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data *config,
int size);
void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg *
config);
+#ifdef CONFIG_ARCH_OMAP34XX
+void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold);
+void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold);
+#else
+static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
+{ }
+static inline void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold)
+{ }
+#endif
int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
void omap_mcbsp_start(unsigned int id, int tx, int rx);
--
1.6.2.GIT
--
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
[PATCHv4 11/20] OMAP: McBSP: Retain McBSP FCLK clockactivity
From: Eero Nurkkala ext-eero.nurkk...@nokia.com FCLK may get autogated so that it prevents the McBSP to work properly. It is the bit 9 that must be set for maintaining the McBSP FCLK. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com Acked-by: Jarkko Nikula jarkko.nik...@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h |1 + arch/arm/plat-omap/mcbsp.c |6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index fe10ae8..70e950e 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -254,6 +254,7 @@ #define RDISABLE 0x0001 /** McBSP SYSCONFIG bit definitions / +#define CLOCKACTIVITY(value) ((value)8) #define SIDLEMODE(value) ((value)3) #define ENAWAKEUP 0x0004 #define SOFTRST0x0002 diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 86bfad8..2c274e6 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -316,8 +316,8 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp) u16 syscon; syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); - syscon = ~(ENAWAKEUP | SIDLEMODE(0x03)); - syscon |= (ENAWAKEUP | SIDLEMODE(0x02)); + syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); + syscon |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY(0x02)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, XRDYEN | RRDYEN); @@ -333,7 +333,7 @@ static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp) u16 syscon; syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); - syscon = ~(ENAWAKEUP | SIDLEMODE(0x03)); + syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, 0); -- 1.6.2.GIT -- 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
[PATCHv4 09/20] OMAP: McBSP: Wakeups utilized
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
This patch enables the smart idle mode while
McBPS is being utilized. Once it's done,
force idle mode is taken instead. Apart of it,
it also configures what signals will wake mcbsp up.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h | 17 +++
arch/arm/plat-omap/mcbsp.c | 46 +++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index bd5b759..333061d 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -138,6 +138,7 @@
#define OMAP_MCBSP_REG_THRSH1 0x94
#define OMAP_MCBSP_REG_IRQST 0xA0
#define OMAP_MCBSP_REG_IRQEN 0xA4
+#define OMAP_MCBSP_REG_WAKEUPEN0xA8
#define OMAP_MCBSP_REG_XCCR0xAC
#define OMAP_MCBSP_REG_RCCR0xB0
@@ -253,6 +254,8 @@
#define RDISABLE 0x0001
/** McBSP SYSCONFIG bit definitions /
+#define SIDLEMODE(value) ((value)3)
+#define ENAWAKEUP 0x0004
#define SOFTRST0x0002
/** McBSP DMA operating modes **/
@@ -260,6 +263,20 @@
#define MCBSP_DMA_MODE_THRESHOLD 1
#define MCBSP_DMA_MODE_FRAME 2
+/** McBSP WAKEUPEN bit definitions */
+#define XEMPTYEOFEN0x4000
+#define XRDYEN 0x0400
+#define XEOFEN 0x0200
+#define XFSXEN 0x0100
+#define XSYNCERREN 0x0080
+#define RRDYEN 0x0008
+#define REOFEN 0x0004
+#define RFSREN 0x0002
+#define RSYNCERREN 0x0001
+#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
+XSYNCERREN | RRDYEN | REOFEN | RFSREN | \
+RSYNCERREN)
+
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
u16 spcr2;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 9e69994..136f8c5 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -305,6 +305,46 @@ int omap_mcbsp_get_dma_op_mode(unsigned int id)
return dma_op_mode;
}
EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
+
+static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
+{
+ /*
+* Enable wakup behavior, smart idle and all wakeups
+* REVISIT: some wakeups may be unnecessary
+*/
+ if (cpu_is_omap34xx()) {
+ u16 syscon;
+
+ syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON);
+ syscon = ~(ENAWAKEUP | SIDLEMODE(0x03));
+ syscon |= (ENAWAKEUP | SIDLEMODE(0x02));
+ OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
+
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, WAKEUPEN_ALL);
+ }
+}
+
+static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp)
+{
+ /*
+* Disable wakup behavior, smart idle and all wakeups
+*/
+ if (cpu_is_omap34xx()) {
+ u16 syscon;
+ u16 wakeupen;
+
+ syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON);
+ syscon = ~(ENAWAKEUP | SIDLEMODE(0x03));
+ OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
+
+ wakeupen = OMAP_MCBSP_READ(mcbsp-io_base, WAKEUPEN);
+ wakeupen = ~WAKEUPEN_ALL;
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, wakeupen);
+ }
+}
+#else
+static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp) {}
+static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp) {}
#endif
/*
@@ -366,6 +406,9 @@ int omap_mcbsp_request(unsigned int id)
clk_enable(mcbsp-iclk);
clk_enable(mcbsp-fclk);
+ /* Do procedure specific to omap34xx arch, if applicable */
+ omap34xx_mcbsp_request(mcbsp);
+
/*
* Make sure that transmitter, receiver and sample-rate generator are
* not running before activating IRQs.
@@ -414,6 +457,9 @@ void omap_mcbsp_free(unsigned int id)
if (mcbsp-pdata mcbsp-pdata-ops mcbsp-pdata-ops-free)
mcbsp-pdata-ops-free(id);
+ /* Do procedure specific to omap34xx arch, if applicable */
+ omap34xx_mcbsp_free(mcbsp);
+
clk_disable(mcbsp-fclk);
clk_disable(mcbsp-iclk);
--
1.6.2.GIT
--
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
[PATCHv4 03/20] OMAP: McBSP: Use appropriate value for startup delay
From: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/mcbsp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 0aa2524..e9dd703 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -365,7 +365,13 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
w = OMAP_MCBSP_READ(io_base, SPCR1);
OMAP_MCBSP_WRITE(io_base, SPCR1, w | (rx 1));
- udelay(100);
+ /*
+* Worst case: CLKSRG*2 = 8000khz: (1/8000) * 2 * 2 usec
+* REVISIT: 100us may give enough time for two CLKSRG, however
+* due to some unknown PM related, clock gating etc. reason it
+* is now at 500us.
+*/
+ udelay(500);
if (idle) {
/* Start frame sync */
--
1.6.2.GIT
--
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
[PATCHv4 19/20] ASoC: OMAP: Use McBSP threshold to playback and capture
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch changes the way DMA is done in omap-pcm.c
in order to reduce power consumption. There is no need
to have so much SW control in order to have DMA in idle
state during audio streaming. Configuring McBSP threshold value
and DMA to FRAME_SYNC are sufficient.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 47 +-
sound/soc/omap/omap-pcm.c |7 +-
sound/soc/omap/omap-pcm.h |2 +
3 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 76c32f8..2aec7a6 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -139,28 +139,59 @@ static const unsigned long omap34xx_mcbsp_port[][2] = {
static const unsigned long omap34xx_mcbsp_port[][2] = {};
#endif
+static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+ int samples = snd_pcm_lib_period_bytes(substream) 1;
+
+ /* Configure McBSP internal buffer usage */
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ omap_mcbsp_set_tx_threshold(mcbsp_data-bus_id, samples - 1);
+ else
+ omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, samples - 1);
+}
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+ int bus_id = mcbsp_data-bus_id;
int err = 0;
- if (cpu_is_omap343x() mcbsp_data-bus_id == 1) {
+ if (!cpu_dai-active)
+ err = omap_mcbsp_request(bus_id);
+
+ if (cpu_is_omap343x()) {
+ int max_period;
+
/*
* McBSP2 in OMAP3 has 1024 * 32-bit internal audio buffer.
* Set constraint for minimum buffer size to the same than FIFO
* size in order to avoid underruns in playback startup because
* HW is keeping the DMA request active until FIFO is filled.
*/
+ if (bus_id == 1)
+ snd_pcm_hw_constraint_minmax(substream-runtime,
+ SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
+ 4096, UINT_MAX);
+
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ max_period = omap_mcbsp_get_max_tx_threshold(bus_id);
+ else
+ max_period = omap_mcbsp_get_max_rx_threshold(bus_id);
+
+ max_period++;
+ max_period = 1;
+
snd_pcm_hw_constraint_minmax(substream-runtime,
- SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 4096, UINT_MAX);
+ SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+ 32, max_period);
}
- if (!cpu_dai-active)
- err = omap_mcbsp_request(mcbsp_data-bus_id);
-
return err;
}
@@ -219,7 +250,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
struct omap_mcbsp_reg_cfg *regs = mcbsp_data-regs;
int dma, bus_id = mcbsp_data-bus_id, id = cpu_dai-id;
- int wlen, channels, wpf;
+ int wlen, channels, wpf, sync_mode = OMAP_DMA_SYNC_ELEMENT;
unsigned long port;
unsigned int format;
@@ -235,6 +266,9 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
} else if (cpu_is_omap343x()) {
dma = omap24xx_dma_reqs[bus_id][substream-stream];
port = omap34xx_mcbsp_port[bus_id][substream-stream];
+ omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
+ omap_mcbsp_set_threshold;
+ sync_mode = OMAP_DMA_SYNC_FRAME;
} else {
return -ENODEV;
}
@@ -242,6 +276,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
substream-stream ? Audio Capture : Audio Playback;
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
omap_mcbsp_dai_dma_params[id][substream-stream].port_addr = port;
+ omap_mcbsp_dai_dma_params[id][substream-stream].sync_mode = sync_mode;
cpu_dai-dma_data = omap_mcbsp_dai_dma_params[id][substream-stream];
if (mcbsp_data-configured) {
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
[PATCHv4 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
When no-idle mode is taken, wakeups need not to be enabled.
Moreover, CLOCKACTIVITY bits are unnecessary with this mode
also.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
Acked-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/mcbsp.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 85176a5..56a5688 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -319,16 +319,17 @@ static inline void omap34xx_mcbsp_request(struct
omap_mcbsp *mcbsp)
syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
spin_lock_irq(mcbsp-lock);
- if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
- syscon |= SIDLEMODE(0x02);
- else
+ if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
+ syscon |= (ENAWAKEUP | SIDLEMODE(0x02) |
+ CLOCKACTIVITY(0x02));
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN,
+ XRDYEN | RRDYEN);
+ } else {
syscon |= SIDLEMODE(0x01);
+ }
spin_unlock_irq(mcbsp-lock);
- syscon |= (ENAWAKEUP | CLOCKACTIVITY(0x02));
OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
-
- OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, XRDYEN | RRDYEN);
}
}
--
1.6.2.GIT
--
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
[PATCHv4 10/20] OMAP: McBSP: Change wakeup signals
From: Eduardo Valentin eduardo.valen...@nokia.com
Configure only XRDYEN and RRDYEN wakeup signals
in order to get better power consumption.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |3 ---
arch/arm/plat-omap/mcbsp.c |7 ++-
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 333061d..fe10ae8 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -273,9 +273,6 @@
#define REOFEN 0x0004
#define RFSREN 0x0002
#define RSYNCERREN 0x0001
-#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
-XSYNCERREN | RRDYEN | REOFEN | RFSREN | \
-RSYNCERREN)
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 136f8c5..86bfad8 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -320,7 +320,7 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp
*mcbsp)
syscon |= (ENAWAKEUP | SIDLEMODE(0x02));
OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
- OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, WAKEUPEN_ALL);
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, XRDYEN | RRDYEN);
}
}
@@ -331,15 +331,12 @@ static inline void omap34xx_mcbsp_free(struct omap_mcbsp
*mcbsp)
*/
if (cpu_is_omap34xx()) {
u16 syscon;
- u16 wakeupen;
syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON);
syscon = ~(ENAWAKEUP | SIDLEMODE(0x03));
OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
- wakeupen = OMAP_MCBSP_READ(mcbsp-io_base, WAKEUPEN);
- wakeupen = ~WAKEUPEN_ALL;
- OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, wakeupen);
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, 0);
}
}
#else
--
1.6.2.GIT
--
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
[PATCHv4 15/20] ASoC: OMAP: Make DMA 64 aligned
From: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-pcm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index dd9e728..f769a52 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -305,7 +305,7 @@ static struct snd_pcm_ops omap_pcm_ops = {
.mmap = omap_pcm_mmap,
};
-static u64 omap_pcm_dmamask = DMA_BIT_MASK(32);
+static u64 omap_pcm_dmamask = DMA_BIT_MASK(64);
static int omap_pcm_preallocate_dma_buffer(struct snd_pcm *pcm,
int stream)
@@ -355,7 +355,7 @@ static int omap_pcm_new(struct snd_card *card, struct
snd_soc_dai *dai,
if (!card-dev-dma_mask)
card-dev-dma_mask = omap_pcm_dmamask;
if (!card-dev-coherent_dma_mask)
- card-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ card-dev-coherent_dma_mask = DMA_BIT_MASK(64);
if (dai-playback.channels_min) {
ret = omap_pcm_preallocate_dma_buffer(pcm,
--
1.6.2.GIT
--
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
[PATCHv4 06/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
From: Peter Ujfalusi peter.ujfal...@nokia.com
Do not allow applications to use the full buffer found on
McBSP1,3,4,5. Using the full buffer in threshold mode causes
the McBSP buffer to run dry, which can be observed as channels
are switching (in reality the channels are shifting).
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
arch/arm/mach-omap2/mcbsp.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index f837114..7d22caf 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -129,7 +129,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
@@ -147,7 +147,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
{
.phys_base = OMAP34XX_MCBSP4_BASE,
@@ -156,7 +156,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
{
.phys_base = OMAP34XX_MCBSP5_BASE,
@@ -165,7 +165,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
};
#define OMAP34XX_MCBSP_PDATA_SZARRAY_SIZE(omap34xx_mcbsp_pdata)
--
1.6.2.GIT
--
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
[PATCHv4 08/20] OMAP: McBSP: Add link DMA mode selection
From: Peter Ujfalusi peter.ujfal...@nokia.com
It adds a new sysfs file, where the user can configure the mcbsp mode to use.
If the mcbsp channel is in use, it does not allow the change.
Than in omap_pcm_open we can call the omap_mcbsp_get_opmode to get the mode,
store it, than use it to implement the different modes.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |8 +++
arch/arm/plat-omap/mcbsp.c | 84 +++
2 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 832330d..bd5b759 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -255,6 +255,11 @@
/** McBSP SYSCONFIG bit definitions /
#define SOFTRST0x0002
+/** McBSP DMA operating modes **/
+#define MCBSP_DMA_MODE_ELEMENT 0
+#define MCBSP_DMA_MODE_THRESHOLD 1
+#define MCBSP_DMA_MODE_FRAME 2
+
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
u16 spcr2;
@@ -385,6 +390,7 @@ struct omap_mcbsp {
struct clk *iclk;
struct clk *fclk;
#ifdef CONFIG_ARCH_OMAP34XX
+ int dma_op_mode;
u16 max_tx_thres;
u16 max_rx_thres;
#endif
@@ -401,6 +407,7 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold);
void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold);
u16 omap_mcbsp_get_max_tx_threshold(unsigned int id);
u16 omap_mcbsp_get_max_rx_threshold(unsigned int id);
+int omap_mcbsp_get_dma_op_mode(unsigned int id);
#else
static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
{ }
@@ -408,6 +415,7 @@ static inline void omap_mcbsp_set_rx_threshold(unsigned int
id, u16 threshold)
{ }
static inline u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) { return 0;
}
static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) { return 0;
}
+static inline int omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; }
#endif
int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index ccaa9ae..9e69994 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -282,6 +282,29 @@ u16 omap_mcbsp_get_max_rx_threshold(unsigned int id)
return mcbsp-max_rx_thres;
}
EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold);
+
+/*
+ * omap_mcbsp_get_dma_op_mode just return the current configured
+ * operating mode for the mcbsp channel
+ */
+int omap_mcbsp_get_dma_op_mode(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+ int dma_op_mode;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%u)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ spin_lock_irq(mcbsp-lock);
+ dma_op_mode = mcbsp-dma_op_mode;
+ spin_unlock_irq(mcbsp-lock);
+
+ return dma_op_mode;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
#endif
/*
@@ -1077,9 +1100,65 @@ static DEVICE_ATTR(prop, 0644, prop##_show,
prop##_store);
THRESHOLD_PROP_BUILDER(max_tx_thres);
THRESHOLD_PROP_BUILDER(max_rx_thres);
+static ssize_t dma_op_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct omap_mcbsp *mcbsp = dev_get_drvdata(dev);
+ int dma_op_mode;
+
+ spin_lock_irq(mcbsp-lock);
+ dma_op_mode = mcbsp-dma_op_mode;
+ spin_unlock_irq(mcbsp-lock);
+
+ return sprintf(buf, current mode: %d\n
+ possible mode values are:\n
+ %d - %s\n
+ %d - %s\n
+ %d - %s\n,
+ dma_op_mode,
+ MCBSP_DMA_MODE_ELEMENT, element mode,
+ MCBSP_DMA_MODE_THRESHOLD, threshold mode,
+ MCBSP_DMA_MODE_FRAME, frame mode);
+}
+
+static ssize_t dma_op_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct omap_mcbsp *mcbsp = dev_get_drvdata(dev);
+ unsigned long val;
+ int status;
+
+ status = strict_strtoul(buf, 0, val);
+ if (status)
+ return status;
+
+ spin_lock_irq(mcbsp-lock);
+
+ if (!mcbsp-free) {
+ size = -EBUSY;
+ goto unlock;
+ }
+
+ if (val MCBSP_DMA_MODE_FRAME || val MCBSP_DMA_MODE_ELEMENT) {
+ size = -EINVAL;
+ goto unlock;
+ }
+
+ mcbsp-dma_op_mode = val;
+
+unlock:
+ spin_unlock_irq(mcbsp-lock);
+
+ return size;
+}
+
+static
[PATCHv4 20/20] ASoC: OMAP: Use DMA operating mode of McBSP
From: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 2aec7a6..60c360b 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -144,7 +144,14 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
- int samples = snd_pcm_lib_period_bytes(substream) 1;
+ int dma_op_mode = omap_mcbsp_get_dma_op_mode(mcbsp_data-bus_id);
+ int samples;
+
+ /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
+ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
+ samples = snd_pcm_lib_period_bytes(substream) 1;
+ else
+ samples = 1;
/* Configure McBSP internal buffer usage */
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
@@ -166,6 +173,7 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream
*substream,
err = omap_mcbsp_request(bus_id);
if (cpu_is_omap343x()) {
+ int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id);
int max_period;
/*
@@ -187,7 +195,8 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream
*substream,
max_period++;
max_period = 1;
- snd_pcm_hw_constraint_minmax(substream-runtime,
+ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
+ snd_pcm_hw_constraint_minmax(substream-runtime,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
32, max_period);
}
@@ -268,7 +277,10 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
port = omap34xx_mcbsp_port[bus_id][substream-stream];
omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
omap_mcbsp_set_threshold;
- sync_mode = OMAP_DMA_SYNC_FRAME;
+ /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
+ if (omap_mcbsp_get_dma_op_mode(bus_id) ==
+ MCBSP_DMA_MODE_THRESHOLD)
+ sync_mode = OMAP_DMA_SYNC_FRAME;
} else {
return -ENODEV;
}
--
1.6.2.GIT
--
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
[PATCHv4 14/20] OMAP: McBSP: Let element DMA mode hit retention also
From: Eero Nurkkala ext-eero.nurkk...@nokia.com The device no longer hits retention if element DMA mode is taken for at least the duration of the serial console timeout. Force element DMA mode to shut down through smartidle. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com Acked-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/plat-omap/mcbsp.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 56a5688..b63a720 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -343,6 +343,15 @@ static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp) syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); + /* +* HW bug workaround - If no_idle mode is taken, we need to +* go to smart_idle before going to always_idle, or the +* device will not hit retention anymore. +*/ + syscon |= SIDLEMODE(0x02); + OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); + + syscon = ~(SIDLEMODE(0x03)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, 0); -- 1.6.2.GIT -- 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
[PATCHv4 17/20] ASoC: Add runtime check for RFIG and XFIG
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
This is, no RFIG or XFIG (Not defined in 34xx), correct
initiliazation of rccr and xccr.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
sound/soc/omap/omap-mcbsp.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 6a837ff..a7b0961 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -321,8 +321,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
/* Generic McBSP register settings */
regs-spcr2 |= XINTM(3) | FREE;
regs-spcr1 |= RINTM(3);
- regs-rcr2 |= RFIG;
- regs-xcr2 |= XFIG;
+ /* RFIG and XFIG are not defined in 34xx */
+ if (!cpu_is_omap34xx()) {
+ regs-rcr2 |= RFIG;
+ regs-xcr2 |= XFIG;
+ }
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
regs-xccr = DXENDLY(1) | XDMAEN;
regs-rccr = RFULL_CYCLE | RDMAEN;
--
1.6.2.GIT
--
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
[PATCHv4 07/20] OMAP: McBSP: Rename thres sysfs symbols
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch renames the symbols that handles threshold
sysfs properties. This way we can add more sysfs properties
to them.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/mcbsp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 0bbc912..ccaa9ae 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -1077,24 +1077,24 @@ static DEVICE_ATTR(prop, 0644, prop##_show,
prop##_store);
THRESHOLD_PROP_BUILDER(max_tx_thres);
THRESHOLD_PROP_BUILDER(max_rx_thres);
-static const struct attribute *threshold_attrs[] = {
+static const struct attribute *additional_attrs[] = {
dev_attr_max_tx_thres.attr,
dev_attr_max_rx_thres.attr,
NULL,
};
-static const struct attribute_group threshold_attr_group = {
- .attrs = (struct attribute **)threshold_attrs,
+static const struct attribute_group additional_attr_group = {
+ .attrs = (struct attribute **)additional_attrs,
};
-static inline int __devinit omap_thres_add(struct device *dev)
+static inline int __devinit omap_additional_add(struct device *dev)
{
- return sysfs_create_group(dev-kobj, threshold_attr_group);
+ return sysfs_create_group(dev-kobj, additional_attr_group);
}
-static inline void __devexit omap_thres_remove(struct device *dev)
+static inline void __devexit omap_additional_remove(struct device *dev)
{
- sysfs_remove_group(dev-kobj, threshold_attr_group);
+ sysfs_remove_group(dev-kobj, additional_attr_group);
}
static inline void __devinit omap34xx_device_init(struct omap_mcbsp *mcbsp)
@@ -1102,9 +1102,9 @@ static inline void __devinit omap34xx_device_init(struct
omap_mcbsp *mcbsp)
if (cpu_is_omap34xx()) {
mcbsp-max_tx_thres = max_thres(mcbsp);
mcbsp-max_rx_thres = max_thres(mcbsp);
- if (omap_thres_add(mcbsp-dev))
+ if (omap_additional_add(mcbsp-dev))
dev_warn(mcbsp-dev,
- Unable to create threshold controls\n);
+ Unable to create additional controls\n);
} else {
mcbsp-max_tx_thres = -EINVAL;
mcbsp-max_rx_thres = -EINVAL;
@@ -1114,7 +1114,7 @@ static inline void __devinit omap34xx_device_init(struct
omap_mcbsp *mcbsp)
static inline void __devexit omap34xx_device_exit(struct omap_mcbsp *mcbsp)
{
if (cpu_is_omap34xx())
- omap_thres_remove(mcbsp-dev);
+ omap_additional_remove(mcbsp-dev);
}
#else
static inline void __devinit omap34xx_device_init(struct omap_mcbsp *mcbsp) {}
--
1.6.2.GIT
--
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
[PATCHv4 00/20] OMAP ASoC changes in DMA utilization
Hello again guys, Here is version 4 of these changes. No real changes from previous versions. The only thing is that now I've rebased on top of Takashi's tree: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary as there are pending things there which Jarkko has pointed on previous series. BR, Eduardo Valentin (11): OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers. OMAP: McBSP: Use appropriate value for startup delay OMAP: McBSP: Add transmit/receive threshold handler OMAP: McBSP: Create and export max_(r|t)x_thres property OMAP: McBSP: Rename thres sysfs symbols OMAP: McBSP: Change wakeup signals OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold ASoC: OMAP: Make DMA 64 aligned ASoC: OMAP: Enable DMA burst mode ASoC: OMAP: Use McBSP threshold to playback and capture ASoC: OMAP: Use DMA operating mode of McBSP Eero Nurkkala (7): OMAP: McBSP: Provide functions for ASoC frame syncronization OMAP: McBSP: Wakeups utilized OMAP: McBSP: Retain McBSP FCLK clockactivity OMAP: McBSP: Do not enable wakeups for no-idle mode OMAP: McBSP: Let element DMA mode hit retention also ASoC: Add runtime check for RFIG and XFIG ASoC: Always syncronize audio transfers on frames Peter Ujfalusi (2): OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 OMAP: McBSP: Add link DMA mode selection arch/arm/mach-omap2/mcbsp.c |5 + arch/arm/plat-omap/include/mach/mcbsp.h | 49 arch/arm/plat-omap/mcbsp.c | 377 ++- sound/soc/omap/omap-mcbsp.c | 78 ++- sound/soc/omap/omap-pcm.c | 14 +- sound/soc/omap/omap-pcm.h |2 + 6 files changed, 511 insertions(+), 14 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
[PATCHv4 16/20] ASoC: OMAP: Enable DMA burst mode
From: Eduardo Valentin eduardo.valen...@nokia.com Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index f769a52..f037db0 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -193,6 +193,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ | (cpu_is_omap1510() ? OMAP_DMA_LAST_IRQ : 0)); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; } -- 1.6.2.GIT -- 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
[PATCHv4 18/20] ASoC: Always syncronize audio transfers on frames
From: Eero Nurkkala ext-eero.nurkk...@nokia.com All these steps are required for ASoC to behave correctly. rccr and xccr are format dependent, for example TDM audio has different values than I2S or DSP_A. Also the omap_mcbsp_xmit_enable and/or omap_mcbsp_recv_enable must be called right after the DMA has started. This provides no longer L and R channels switching at random. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com --- sound/soc/omap/omap-mcbsp.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index a7b0961..76c32f8 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -189,8 +189,12 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream *substream, int cmd, case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: - mcbsp_data-active++; omap_mcbsp_start(mcbsp_data-bus_id, play, !play); + /* Make sure data transfer is frame synchronized */ + if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) + omap_mcbsp_xmit_enable(mcbsp_data-bus_id, 1); + else + omap_mcbsp_recv_enable(mcbsp_data-bus_id, 1); break; case SNDRV_PCM_TRIGGER_STOP: @@ -336,11 +340,15 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, /* 1-bit data delay */ regs-rcr2 |= RDATDLY(1); regs-xcr2 |= XDATDLY(1); + regs-rccr |= RFULL_CYCLE | RDMAEN | RDISABLE; + regs-xccr |= (DXENDLY(1) | XDMAEN | XDISABLE); break; case SND_SOC_DAIFMT_DSP_A: /* 1-bit data delay */ regs-rcr2 |= RDATDLY(1); regs-xcr2 |= XDATDLY(1); + regs-rccr |= RFULL_CYCLE | RDMAEN | RDISABLE; + regs-xccr |= (DXENDLY(1) | XDMAEN | XDISABLE); /* Invert FS polarity configuration */ temp_fmt ^= SND_SOC_DAIFMT_NB_IF; break; -- 1.6.2.GIT -- 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
[PATCHv4 01/20] OMAP: McBSP: Provide functions for ASoC frame syncronization
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
ASoC has an annoying bug letting either L or R channel to be
played on L channel. In other words, L and R channels can
switch at random. This provides McBSP funtionality that may
be used to fix this feature.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |2 +
arch/arm/plat-omap/mcbsp.c | 52 +++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 57249bb..b85e6e6 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -389,6 +389,8 @@ int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
void omap_mcbsp_start(unsigned int id, int tx, int rx);
void omap_mcbsp_stop(unsigned int id, int tx, int rx);
+void omap_mcbsp_xmit_enable(unsigned int id, u8 enable);
+void omap_mcbsp_recv_enable(unsigned int id, u8 enable);
void omap_mcbsp_xmit_word(unsigned int id, u32 word);
u32 omap_mcbsp_recv_word(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index a3d2313..0aa2524 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -412,6 +412,58 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
}
EXPORT_SYMBOL(omap_mcbsp_stop);
+void omap_mcbsp_xmit_enable(unsigned int id, u8 enable)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *io_base;
+ u16 w;
+
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
+ return;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return;
+ }
+
+ mcbsp = id_to_mcbsp_ptr(id);
+ io_base = mcbsp-io_base;
+
+ w = OMAP_MCBSP_READ(io_base, XCCR);
+
+ if (enable)
+ OMAP_MCBSP_WRITE(io_base, XCCR, w ~(XDISABLE));
+ else
+ OMAP_MCBSP_WRITE(io_base, XCCR, w | XDISABLE);
+}
+EXPORT_SYMBOL(omap_mcbsp_xmit_enable);
+
+void omap_mcbsp_recv_enable(unsigned int id, u8 enable)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *io_base;
+ u16 w;
+
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
+ return;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return;
+ }
+
+ mcbsp = id_to_mcbsp_ptr(id);
+ io_base = mcbsp-io_base;
+
+ w = OMAP_MCBSP_READ(io_base, RCCR);
+
+ if (enable)
+ OMAP_MCBSP_WRITE(io_base, RCCR, w ~(RDISABLE));
+ else
+ OMAP_MCBSP_WRITE(io_base, RCCR, w | RDISABLE);
+}
+EXPORT_SYMBOL(omap_mcbsp_recv_enable);
+
/* polled mcbsp i/o operations */
int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
{
--
1.6.2.GIT
--
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: [Linux-fbdev-devel] Getting DSS2 to mainline
Hi, Tomi Valkeinen schrieb: Hi, As I'm new to sending patches upstream, I'm not sure how to go forward with DSS2 now. Should I send it to linux-arm-kernel mailing list, or directly to main linux kernel mailing list? Or is there a route through fbdev-devel list for DSS2 to go forward? I am also new to this process but from what I've heard I decided to always cc Andrew Morton a...@linux-foundation.org when I think that something is mature enough for inclusion. That works very well, thanks Andrew. Sending them only to linux-fbdev-devel looks rather like a dead end at least if I look on the fate of some patches in the archive. I always cc the LKML but until now I didn't hear anything from there either so I doubt that would be the right way. I'm sorry if anything of the above is incorrect, it's just my experience. Regards, Florian Tobias Schandinat -- 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: Zoom2 Support on LO Master broken ?
- Original Message - From: Hemanth V heman...@ti.com To: linux-omap@vger.kernel.org Sent: Monday, August 17, 2009 5:48 PM Subject: Zoom2 Support on LO Master broken ? I am unable to boot from quad uart and if I try uart3 I get the below error For quad uart it stops after downloading kernel (ZOOM2 defconfig), probably related to LL_DEBUG setting. 3IP-Config: No network devices available. IP-Config: No network devices available. -- 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: MUSB regression in 2.6.31-rc6
Jarkko Nikula jhnik...@gmail.com writes: By some reason CONFIG_OMAP_LL_DEBUG_UART3=y and CONFIG_DEBUG_LL=y don't work in mainline so hard to trace what is make an oops. You need to apply this patch manually: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=73e5b252eb179f601f2da2538ac3b70c21b2c6c2 -- Kalle Valo -- 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: [PATCHv4 16/20] ASoC: OMAP: Enable DMA burst mode
On Mon, 17 Aug 2009 14:51:15 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: From: Eduardo Valentin eduardo.valen...@nokia.com Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index f769a52..f037db0 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -193,6 +193,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ | (cpu_is_omap1510() ? OMAP_DMA_LAST_IRQ : 0)); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; This seems to be based on first version of Janusz's [RFC] [PATCH 3/3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter. I Attached a version which is based on [PATCH 3/3 v3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter. -- Jarkko From a5eb199316c4731c11c7f5f8d02612ede4de7199 Mon Sep 17 00:00:00 2001 From: Eduardo Valentin eduardo.valen...@nokia.com Date: Mon, 17 Aug 2009 14:51:15 +0300 Subject: [PATCH] ASoC: OMAP: Enable DMA burst mode Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index eab4533..b9633d5 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) else omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; } -- 1.6.3.3
Re: Getting DSS2 to mainline
* Tomi Valkeinen tomi.valkei...@nokia.com [090817 14:25]: Hi, As I'm new to sending patches upstream, I'm not sure how to go forward with DSS2 now. Should I send it to linux-arm-kernel mailing list, or directly to main linux kernel mailing list? Or is there a route through fbdev-devel list for DSS2 to go forward? I suggest send them to fbdev-devel list and cc linux-omap. For the clock alias patches you might want to also cc linux-arm-kernel. Regards, 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: [PATCHv4 02/20] OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers.
* Eduardo Valentin eduardo.valen...@nokia.com [090817 15:06]: From: Eduardo Valentin eduardo.valen...@nokia.com Needs a description. Tony Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index b85e6e6..ceaf9ee 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,10 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON0x8C +#define OMAP_MCBSP_REG_THRSH20x90 +#define OMAP_MCBSP_REG_THRSH10x94 +#define OMAP_MCBSP_REG_IRQST 0xA0 +#define OMAP_MCBSP_REG_IRQEN 0xA4 #define OMAP_MCBSP_REG_XCCR 0xAC #define OMAP_MCBSP_REG_RCCR 0xB0 -- 1.6.2.GIT -- 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: [PATCHv4 15/20] ASoC: OMAP: Make DMA 64 aligned
* Eduardo Valentin eduardo.valen...@nokia.com [090817 15:06]:
From: Eduardo Valentin eduardo.valen...@nokia.com
Description?
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-pcm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index dd9e728..f769a52 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -305,7 +305,7 @@ static struct snd_pcm_ops omap_pcm_ops = {
.mmap = omap_pcm_mmap,
};
-static u64 omap_pcm_dmamask = DMA_BIT_MASK(32);
+static u64 omap_pcm_dmamask = DMA_BIT_MASK(64);
static int omap_pcm_preallocate_dma_buffer(struct snd_pcm *pcm,
int stream)
@@ -355,7 +355,7 @@ static int omap_pcm_new(struct snd_card *card, struct
snd_soc_dai *dai,
if (!card-dev-dma_mask)
card-dev-dma_mask = omap_pcm_dmamask;
if (!card-dev-coherent_dma_mask)
- card-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ card-dev-coherent_dma_mask = DMA_BIT_MASK(64);
if (dai-playback.channels_min) {
ret = omap_pcm_preallocate_dma_buffer(pcm,
--
1.6.2.GIT
--
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: [PATCHv4 16/20] ASoC: OMAP: Enable DMA burst mode
* Jarkko Nikula jhnik...@gmail.com [090817 16:23]: On Mon, 17 Aug 2009 14:51:15 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: From: Eduardo Valentin eduardo.valen...@nokia.com Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index f769a52..f037db0 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -193,6 +193,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ | (cpu_is_omap1510() ? OMAP_DMA_LAST_IRQ : 0)); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; This seems to be based on first version of Janusz's [RFC] [PATCH 3/3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter. I Attached a version which is based on [PATCH 3/3 v3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter. Needs also a patch description. Tony -- Jarkko From a5eb199316c4731c11c7f5f8d02612ede4de7199 Mon Sep 17 00:00:00 2001 From: Eduardo Valentin eduardo.valen...@nokia.com Date: Mon, 17 Aug 2009 14:51:15 +0300 Subject: [PATCH] ASoC: OMAP: Enable DMA burst mode Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index eab4533..b9633d5 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) else omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; } -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] MFD: TWL4030: Add support for TWL4030/5030 dynamic power switching
The TWL4030/5030 family of multifunction devices allows board-specific control of the the various regulators, clock and reset lines through 'scripts' that are loaded into its memory. This allows for Dynamic Power Switching (DPS). Implement board-independent core support for DPS that is then used by board-specific code to load custom DPS scripts. Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com Cc: sa...@linux.intel.com Cc: dbrown...@users.sourceforge.net Cc: linux-omap@vger.kernel.org --- drivers/mfd/Kconfig | 13 ++ drivers/mfd/Makefile|1 + drivers/mfd/twl4030-core.c | 10 + drivers/mfd/twl4030-power.c | 466 +++ include/linux/i2c/twl4030.h | 94 - 5 files changed, 574 insertions(+), 10 deletions(-) create mode 100644 drivers/mfd/twl4030-power.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 491ac0f..94fa9a0 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -108,6 +108,19 @@ config TWL4030_CORE high speed USB OTG transceiver, an audio codec (on most versions) and many other features. +config TWL4030_POWER + bool Support power resources on TWL4030 family chips + depends on TWL4030_CORE + help + Say yes here if you want to use the power resources on the + TWL4030 family chips. Most of these resources are regulators, + which have a separate driver; some are control signals, such + as clock request handshaking. + + This driver uses board-specific data to initialize the resources + and load scripts controling which resources are switched off/on + or reset when a sleep, wakeup or warm reset event occurs. + config MFD_TMIO bool default n diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 6f8a9a1..84b9eda 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_TPS65010)+= tps65010.o obj-$(CONFIG_MENELAUS) += menelaus.o obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-irq.o +obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o obj-$(CONFIG_MFD_CORE) += mfd-core.o diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c index ca54996..28a45a3 100644 --- a/drivers/mfd/twl4030-core.c +++ b/drivers/mfd/twl4030-core.c @@ -89,6 +89,12 @@ #define twl_has_madc() false #endif +#ifdef CONFIG_TWL4030_POWER +#define twl_has_power()true +#else +#define twl_has_power()false +#endif + #if defined(CONFIG_RTC_DRV_TWL4030) || defined(CONFIG_RTC_DRV_TWL4030_MODULE) #define twl_has_rtc() true #else @@ -788,6 +794,10 @@ twl4030_probe(struct i2c_client *client, const struct i2c_device_id *id) /* setup clock framework */ clocks_init(client-dev); + /* load power event scripts */ + if (twl_has_power() pdata-power) + twl4030_power_init(pdata-power); + /* Maybe init the T2 Interrupt subsystem */ if (client-irq pdata-irq_base diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c new file mode 100644 index 000..e7688b0 --- /dev/null +++ b/drivers/mfd/twl4030-power.c @@ -0,0 +1,466 @@ +/* + * linux/drivers/i2c/chips/twl4030-power.c + * + * Handle TWL4030 Power initialization + * + * Copyright (C) 2008 Nokia Corporation + * Copyright (C) 2006 Texas Instruments, Inc + * + * Written by Kalle Jokiniemi + * Peter De Schrijver peter.de-schrij...@nokia.com + * Several fixes by Amit Kucheria amit.kuche...@verdurent.com + * + * This file is subject to the terms and conditions of the GNU General + * Public License. See the file COPYING in the main directory of this + * archive for more details. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include linux/module.h +#include linux/pm.h +#include linux/i2c/twl4030.h +#include linux/platform_device.h + +#include asm/mach-types.h + +static u8 twl4030_start_script_address = 0x2b; + +#define PWR_P1_SW_EVENTS 0x10 +#define PWR_DEVOFF (10) + +#define PHY_TO_OFF_PM_MASTER(p)(p - 0x36) +#define PHY_TO_OFF_PM_RECEIVER(p) (p - 0x5b) + +/* resource - hfclk */ +#define R_HFCLKOUT_DEV_GRP PHY_TO_OFF_PM_RECEIVER(0xe6) + +/* PM events */ +#define R_P1_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x46) +#define R_P2_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x47) +#define R_P3_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x48) +#define R_CFG_P1_TRANSITIONPHY_TO_OFF_PM_MASTER(0x36) +#define
Re: [Linux-fbdev-devel] Getting DSS2 to mainline
On Mon, Aug 17, 2009 at 14:17, Florian Tobias
Schandinatflorianschandi...@gmx.de wrote:
Tomi Valkeinen schrieb:
As I'm new to sending patches upstream, I'm not sure how to go forward
with DSS2 now. Should I send it to linux-arm-kernel mailing list, or
directly to main linux kernel mailing list? Or is there a route through
fbdev-devel list for DSS2 to go forward?
I am also new to this process but from what I've heard I decided to
always cc Andrew Morton a...@linux-foundation.org when I think that
something is mature enough for inclusion. That works very well, thanks
Andrew.
Sending them only to linux-fbdev-devel looks rather like a dead end at
least if I look on the fate of some patches in the archive.
I always cc the LKML but until now I didn't hear anything from there
either so I doubt that would be the right way.
I'm sorry if anything of the above is incorrect, it's just my experience.
Yes, CCing Andrew Morton is The Right Thing To Do.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: [PATCHv4 03/20] OMAP: McBSP: Use appropriate value for startup delay
* Eduardo Valentin eduardo.valen...@nokia.com [090817 15:06]:
From: Eduardo Valentin eduardo.valen...@nokia.com
This too is missing a description.
Tony
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/mcbsp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 0aa2524..e9dd703 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -365,7 +365,13 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
w = OMAP_MCBSP_READ(io_base, SPCR1);
OMAP_MCBSP_WRITE(io_base, SPCR1, w | (rx 1));
- udelay(100);
+ /*
+ * Worst case: CLKSRG*2 = 8000khz: (1/8000) * 2 * 2 usec
+ * REVISIT: 100us may give enough time for two CLKSRG, however
+ * due to some unknown PM related, clock gating etc. reason it
+ * is now at 500us.
+ */
+ udelay(500);
if (idle) {
/* Start frame sync */
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] MFD: TWL4030: print warning for out-of-order script loading
When the sleep script is loaded before the wakeup script, there is a
chance that the system might go to sleep before the wakeup script
loading is completed. This will lead to a system that does not wakeup
and has been observed to cause non-booting boards.
Various options were considered to solve this problem, including
modification of the core twl4030 power code to be smart enough to
reorder the loading of the scripts. But it felt too over-engineered.
Hence this patch just warns the DPS script developer so that they may be
reordered in the board-code itself.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
Cc: sa...@linux.intel.com
Cc: dbrown...@users.sourceforge.net
Cc: linux-omap@vger.kernel.org
---
drivers/mfd/twl4030-power.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index e7688b0..5284c7c 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -379,6 +379,7 @@ static int __init load_twl4030_script(struct twl4030_script
*tscript,
u8 address)
{
int err;
+ static int order;
/* Make sure the script isn't going beyond last valid address (0x3f) */
if ((address + tscript-size) END_OF_SCRIPT) {
@@ -399,6 +400,7 @@ static int __init load_twl4030_script(struct twl4030_script
*tscript,
err = twl4030_config_wakeup12_sequence(address);
if (err)
goto out;
+ order = 1;
}
if (tscript-flags TWL4030_WAKEUP3_SCRIPT) {
err = twl4030_config_wakeup3_sequence(address);
@@ -406,6 +408,10 @@ static int __init load_twl4030_script(struct
twl4030_script *tscript,
goto out;
}
if (tscript-flags TWL4030_SLEEP_SCRIPT)
+ if (order)
+ pr_warning(TWL4030: Bad order of scripts (sleep \
+ script before wakeup) Leads to boot\
+ failure on some boards\n);
err = twl4030_config_sleep_sequence(address);
out:
return err;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 20/20] ASoC: OMAP: Use DMA operating mode of McBSP
* Eduardo Valentin eduardo.valen...@nokia.com [090817 15:06]:
From: Eduardo Valentin eduardo.valen...@nokia.com
And this one too.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 2aec7a6..60c360b 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -144,7 +144,14 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
- int samples = snd_pcm_lib_period_bytes(substream) 1;
+ int dma_op_mode = omap_mcbsp_get_dma_op_mode(mcbsp_data-bus_id);
+ int samples;
+
+ /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
+ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
+ samples = snd_pcm_lib_period_bytes(substream) 1;
+ else
+ samples = 1;
/* Configure McBSP internal buffer usage */
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
@@ -166,6 +173,7 @@ static int omap_mcbsp_dai_startup(struct
snd_pcm_substream *substream,
err = omap_mcbsp_request(bus_id);
if (cpu_is_omap343x()) {
+ int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id);
int max_period;
/*
@@ -187,7 +195,8 @@ static int omap_mcbsp_dai_startup(struct
snd_pcm_substream *substream,
max_period++;
max_period = 1;
- snd_pcm_hw_constraint_minmax(substream-runtime,
+ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
+ snd_pcm_hw_constraint_minmax(substream-runtime,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
32, max_period);
}
@@ -268,7 +277,10 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
port = omap34xx_mcbsp_port[bus_id][substream-stream];
omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
omap_mcbsp_set_threshold;
- sync_mode = OMAP_DMA_SYNC_FRAME;
+ /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
+ if (omap_mcbsp_get_dma_op_mode(bus_id) ==
+ MCBSP_DMA_MODE_THRESHOLD)
+ sync_mode = OMAP_DMA_SYNC_FRAME;
} else {
return -ENODEV;
}
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] MFD: TWL4030: OMAP: Board-specifc DPS scripts for RX51 board
Add support for Dynamic Power Switching (DPS) for the RX51 board.
These scripts are still a work-in-progress. I'll keep sending patches to
update the scripts as they are optimised.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
Cc: sa...@linux.intel.com
Cc: t...@atomide.com
Cc: dbrown...@users.sourceforge.net
Cc: linux-omap@vger.kernel.org
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 122 +-
1 files changed, 120 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a0bf67..8fc6dbf 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1,5 +1,5 @@
/*
- * linux/arch/arm/mach-omap2/board-rx51-flash.c
+ * linux/arch/arm/mach-omap2/board-rx51-peripherals.c
*
* Copyright (C) 2008-2009 Nokia
*
@@ -278,7 +278,124 @@ static struct twl4030_gpio_platform_data rx51_gpio_data =
{
.setup = rx51_twlgpio_setup,
};
-static struct twl4030_platform_data rx51_twldata = {
+static struct twl4030_ins sleep_on_seq[] __initdata = {
+/*
+ * Turn off VDD1 and VDD2.
+ */
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 4},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_OFF), 2},
+/*
+ * And also turn off the OMAP3 PLLs and the sysclk output.
+ */
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 3},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x17, RES_STATE_OFF), 3},
+};
+
+static struct twl4030_script sleep_on_script __initdata = {
+ .script = sleep_on_seq,
+ .size = ARRAY_SIZE(sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+static struct twl4030_ins wakeup_seq[] __initdata = {
+/*
+ * Reenable the OMAP3 PLLs.
+ * Wakeup VDD1 and VDD2.
+ * Reenable sysclk output.
+ */
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 0x30},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 0x30},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 0x37},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 3},
+};
+
+static struct twl4030_script wakeup_script __initdata = {
+ .script = wakeup_seq,
+ .size = ARRAY_SIZE(wakeup_seq),
+ .flags = TWL4030_WAKEUP12_SCRIPT,
+};
+
+static struct twl4030_ins wakeup_p3_seq[] __initdata = {
+/*
+ * Wakeup VDD1 (dummy to be able to insert a delay)
+ * Enable CLKEN
+ */
+ {MSG_SINGULAR(DEV_GRP_P1, 0x17, RES_STATE_ACTIVE), 3},
+};
+
+static struct twl4030_script wakeup_p3_script __initdata = {
+ .script = wakeup_p3_seq,
+ .size = ARRAY_SIZE(wakeup_p3_seq),
+ .flags = TWL4030_WAKEUP3_SCRIPT,
+};
+
+static struct twl4030_ins wrst_seq[] __initdata = {
+/*
+ * Reset twl4030.
+ * Reset VDD1 regulator.
+ * Reset VDD2 regulator.
+ * Reset VPLL1 regulator.
+ * Enable sysclk output.
+ * Reenable twl4030.
+ */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 0, 1, RES_STATE_ACTIVE),
+ 0x13},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_PP, 0, 2, RES_STATE_WRST), 0x13},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_PP, 0, 3, RES_STATE_OFF), 0x13},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VDD1, RES_STATE_WRST), 0x13},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VDD2, RES_STATE_WRST), 0x13},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VPLL1, RES_STATE_WRST), 0x35},
+ {MSG_SINGULAR(DEV_GRP_P1, RES_HFCLKOUT, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *twl4030_scripts[] __initdata = {
+ /* wakeup12 script should be loaded before sleep script, otherwise a
+ board might hit retention before loading of wakeup script is
+ completed. This can cause boot failures depending on timing issues.
+ */
+ wakeup_script,
+ sleep_on_script,
+ wakeup_p3_script,
+ wrst_script,
+};
+
+static struct twl4030_resconfig twl4030_rconfig[] __initdata = {
+ { .resource = RES_VINTANA1, .devgroup = -1, .type = -1, .type2 = 1 },
+ { .resource = RES_VINTANA2, .devgroup = -1, .type = -1, .type2 = 1 },
+ { .resource = RES_VINTDIG, .devgroup = -1, .type = -1, .type2 = 1 },
+ { .resource = RES_VMMC1, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VMMC2, .devgroup = DEV_GRP_NULL, .type = -1,
+ .type2 = 3},
+ { .resource = RES_VAUX1, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VAUX2, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VAUX3, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VAUX4, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VPLL2, .devgroup = -1, .type = -1, .type2 = 3},
+ { .resource = RES_VDAC,
Re: [PATCHv4 00/20] OMAP ASoC changes in DMA utilization
On Mon, 17 Aug 2009 14:50:59 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: Hello again guys, Here is version 4 of these changes. No real changes from previous versions. The only thing is that now I've rebased on top of Takashi's tree: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=summary as there are pending things there which Jarkko has pointed on previous series. Here's my ack to the ASoC part. I tested the set on top of these Janusz's patches: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-August/020170.html http://mailman.alsa-project.org/pipermail/alsa-devel/2009-August/020171.html http://mailman.alsa-project.org/pipermail/alsa-devel/2009-August/020262.html Note, that I posted modified version for the patch 16 based on Janusz's [PATCH 3/3 v3]. Acked-by: Jarkko Nikula jhnik...@gmail.com arch/arm/mach-omap2/mcbsp.c |5 + arch/arm/plat-omap/include/mach/mcbsp.h | 49 arch/arm/plat-omap/mcbsp.c | 377 ++- sound/soc/omap/omap-mcbsp.c | 78 ++- sound/soc/omap/omap-pcm.c | 14 +- sound/soc/omap/omap-pcm.h |2 + 6 files changed, 511 insertions(+), 14 deletions(-) Tony, if you are ok with the OMAP McBSP changes, how it would be best get these merged? Via ASoC, LKML or separately from both subsystems during the merge window? -- 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
[PATCHv5 03/20] OMAP: McBSP: Use appropriate value for startup delay
From: Eduardo Valentin eduardo.valen...@nokia.com
Increasing startup delay value as worst case:
CLKSRG*2 = 8000khz: (1/8000) * 2 * 2 usec
Although, 100us may give enough time for two CLKSRG,
due to some unknown PM related, clock gating etc. reason,
this patch increases it to 500us.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/mcbsp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 0aa2524..e9dd703 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -365,7 +365,13 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
w = OMAP_MCBSP_READ(io_base, SPCR1);
OMAP_MCBSP_WRITE(io_base, SPCR1, w | (rx 1));
- udelay(100);
+ /*
+* Worst case: CLKSRG*2 = 8000khz: (1/8000) * 2 * 2 usec
+* REVISIT: 100us may give enough time for two CLKSRG, however
+* due to some unknown PM related, clock gating etc. reason it
+* is now at 500us.
+*/
+ udelay(500);
if (idle) {
/* Start frame sync */
--
1.6.2.GIT
--
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
[PATCHv4 02/20] OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers.
From: Eduardo Valentin eduardo.valen...@nokia.com Adding McBSP register definition for IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index b85e6e6..ceaf9ee 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,10 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON 0x8C +#define OMAP_MCBSP_REG_THRSH2 0x90 +#define OMAP_MCBSP_REG_THRSH1 0x94 +#define OMAP_MCBSP_REG_IRQST 0xA0 +#define OMAP_MCBSP_REG_IRQEN 0xA4 #define OMAP_MCBSP_REG_XCCR0xAC #define OMAP_MCBSP_REG_RCCR0xB0 -- 1.6.2.GIT -- 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
[PATCHv4 20/20] ASoC: OMAP: Use DMA operating mode of McBSP
From: Eduardo Valentin eduardo.valen...@nokia.com
Configures DMA sync mode depending on McBSP operating mode value.
The value is configurable by McBSP instance. So, depending
on McBSP operating mode, the DMA sync mode is passed from
omap-mcbsp to omap-pcm. Besides that, it also configures
McBSP threshold value depending on which McBSP mode is activated.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 2aec7a6..60c360b 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -144,7 +144,14 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
- int samples = snd_pcm_lib_period_bytes(substream) 1;
+ int dma_op_mode = omap_mcbsp_get_dma_op_mode(mcbsp_data-bus_id);
+ int samples;
+
+ /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
+ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
+ samples = snd_pcm_lib_period_bytes(substream) 1;
+ else
+ samples = 1;
/* Configure McBSP internal buffer usage */
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
@@ -166,6 +173,7 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream
*substream,
err = omap_mcbsp_request(bus_id);
if (cpu_is_omap343x()) {
+ int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id);
int max_period;
/*
@@ -187,7 +195,8 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream
*substream,
max_period++;
max_period = 1;
- snd_pcm_hw_constraint_minmax(substream-runtime,
+ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
+ snd_pcm_hw_constraint_minmax(substream-runtime,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
32, max_period);
}
@@ -268,7 +277,10 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
port = omap34xx_mcbsp_port[bus_id][substream-stream];
omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
omap_mcbsp_set_threshold;
- sync_mode = OMAP_DMA_SYNC_FRAME;
+ /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
+ if (omap_mcbsp_get_dma_op_mode(bus_id) ==
+ MCBSP_DMA_MODE_THRESHOLD)
+ sync_mode = OMAP_DMA_SYNC_FRAME;
} else {
return -ENODEV;
}
--
1.6.2.GIT
--
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][PM] ARM: OMAP34xx: Fix compilation warning
From: Sergio Aguirre saagui...@ti.com This fixes the following compilation warnings: In file included from arch/arm/mach-omap2/resource34xx.c:26: arch/arm/mach-omap2/resource34xx.h:32: warning: function declaration isn't a prototype arch/arm/mach-omap2/resource34xx.h:33: warning: function declaration isn't a prototype Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/mach-omap2/resource34xx.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.h b/arch/arm/mach-omap2/resource34xx.h index 5b5618a..3c70eef 100644 --- a/arch/arm/mach-omap2/resource34xx.h +++ b/arch/arm/mach-omap2/resource34xx.h @@ -29,8 +29,8 @@ #include mach/omap34xx.h extern int sr_voltagescale_vcbypass(u32 t_opp, u32 c_opp, u8 t_vsel, u8 c_vsel); -extern void lock_scratchpad_sem(); -extern void unlock_scratchpad_sem(); +extern void lock_scratchpad_sem(void); +extern void unlock_scratchpad_sem(void); /* * mpu_latency/core_latency are used to control the cpuidle C state. -- 1.6.3.2 0002-ARM-OMAP34xx-Fix-compilation-warning.patch Description: 0002-ARM-OMAP34xx-Fix-compilation-warning.patch
[PATCH] ASoC: OMAP: Enable DMA burst mode
From: Eduardo Valentin eduardo.valen...@nokia.com Improve DMA transfers by enabling Burst transaction. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index eab4533..b9633d5 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) else omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; } -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix mismatched ifdefs
* Sanjeev Premi pr...@ti.com [090817 13:59]: The #endif at end of the file was missing. However, an additional #else ... #endif was causing the compiler to keep going. The problem was found when compiler started reporting the newly added inline functions were being reported as redeclared by the compiler. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 11e73d9..4fbc6a9 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -317,8 +317,6 @@ IS_OMAP_TYPE(3430, 0x3430) # undef cpu_is_omap730 # define cpu_is_omap730() 1 # endif -#endif -#else Hmm, to me it looks like this should remove the second #endif, but keep the #else for the !MULTI_OMAP1 configurations. # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() 1 @@ -433,3 +431,5 @@ IS_OMAP_TYPE(3430, 0x3430) int omap_chip_is(struct omap_chip_id oci); void omap2_check_revision(void); + +#endif /* __ASM_ARCH_OMAP_CPU_H */ And this should not be needed. Regards, Tony -- 1.6.2.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 -- 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
[PATCHv4 15/20] ASoC: OMAP: Make DMA 64 aligned
From: Eduardo Valentin eduardo.valen...@nokia.com
Align DMA address to DMA burst transaction sizes.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-pcm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index dd9e728..f769a52 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -305,7 +305,7 @@ static struct snd_pcm_ops omap_pcm_ops = {
.mmap = omap_pcm_mmap,
};
-static u64 omap_pcm_dmamask = DMA_BIT_MASK(32);
+static u64 omap_pcm_dmamask = DMA_BIT_MASK(64);
static int omap_pcm_preallocate_dma_buffer(struct snd_pcm *pcm,
int stream)
@@ -355,7 +355,7 @@ static int omap_pcm_new(struct snd_card *card, struct
snd_soc_dai *dai,
if (!card-dev-dma_mask)
card-dev-dma_mask = omap_pcm_dmamask;
if (!card-dev-coherent_dma_mask)
- card-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ card-dev-coherent_dma_mask = DMA_BIT_MASK(64);
if (dai-playback.channels_min) {
ret = omap_pcm_preallocate_dma_buffer(pcm,
--
1.6.2.GIT
--
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: [PATCHv4 16/20] ASoC: OMAP: Enable DMA burst mode
Hi Tony On Mon, Aug 17, 2009 at 04:01:29PM +0200, ext Tony Lindgren wrote: * Jarkko Nikula jhnik...@gmail.com [090817 16:23]: On Mon, 17 Aug 2009 14:51:15 +0300 Eduardo Valentin eduardo.valen...@nokia.com wrote: From: Eduardo Valentin eduardo.valen...@nokia.com Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index f769a52..f037db0 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -193,6 +193,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ | (cpu_is_omap1510() ? OMAP_DMA_LAST_IRQ : 0)); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; This seems to be based on first version of Janusz's [RFC] [PATCH 3/3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter. I Attached a version which is based on [PATCH 3/3 v3] ASoC: OMAP: Enhance OMAP1510 DMA progress software counter. Needs also a patch description. I've added patch description for those which were missing and sent them in reply to your commented reply. If you prefer I can send version 5 of this series. BR, Tony -- Jarkko From a5eb199316c4731c11c7f5f8d02612ede4de7199 Mon Sep 17 00:00:00 2001 From: Eduardo Valentin eduardo.valen...@nokia.com Date: Mon, 17 Aug 2009 14:51:15 +0300 Subject: [PATCH] ASoC: OMAP: Enable DMA burst mode Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index eab4533..b9633d5 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) else omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; } -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe alsa-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Eduardo Valentin -- 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] Fix mismatched ifdefs
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, August 17, 2009 8:15 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] Fix mismatched ifdefs * Sanjeev Premi pr...@ti.com [090817 13:59]: The #endif at end of the file was missing. However, an additional #else ... #endif was causing the compiler to keep going. The problem was found when compiler started reporting the newly added inline functions were being reported as redeclared by the compiler. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 11e73d9..4fbc6a9 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -317,8 +317,6 @@ IS_OMAP_TYPE(3430, 0x3430) # undef cpu_is_omap730 # define cpu_is_omap730() 1 # endif -#endif -#else Hmm, to me it looks like this should remove the second #endif, but keep the #else for the !MULTI_OMAP1 configurations. [sp] I did the maching as annotated in the snippet below: #if defined(MULTI_OMAP1) # if defined(CONFIG_ARCH_OMAP730) # undef cpu_is_omap730 # define cpu_is_omap730() is_omap730() # endif # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() is_omap850() # endif #else /* sp - else for multi-omap1 */ # if defined(CONFIG_ARCH_OMAP730) # undef cpu_is_omap730 # define cpu_is_omap730() 1 # endif #endif #else /* sp - seems like needed in the else path of MULTI_OMAP1 * else the symbol could go undefined. */ # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() 1 # endif #endif # if defined(CONFIG_ARCH_OMAP850) # undef cpu_is_omap850 # define cpu_is_omap850() 1 @@ -433,3 +431,5 @@ IS_OMAP_TYPE(3430, 0x3430) int omap_chip_is(struct omap_chip_id oci); void omap2_check_revision(void); + +#endif /* __ASM_ARCH_OMAP_CPU_H */ And this should not be needed. [sp] So where does this end: #ifndef __ASM_ARCH_OMAP_CPU_H #define __ASM_ARCH_OMAP_CPU_H I was hitting the problem possibly due to mutiple inclusion of cpu.h Any static inline function declared at bottom of cpu.h gets the errors like: arch/arm/plat-omap/include/mach/cpu.h:465: error: redefinition of 'omap3_has_iva' arch/arm/plat-omap/include/mach/cpu.h:465: error: previous definition of 'omap3_has_iva' was here Regards, Tony -- 1.6.2.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 -- 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: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
Seems like I did not submit the patch in the right way, before I setup
my mail correctly, attach the patches in the mail.
PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch
From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Fri, 14 Aug 2009 17:34:32 +0800
Subject: [PATCH] Add per-resource mutex for OMAP resource framework
Current OMAP resource fwk uses a global res_mutex
for resource_request and resource_release calls
for all the available resources.It may cause dead
lock if resource_request/resource_release is called
recursively.
For current OMAP3 VDD1/VDD2 resource, the change_level
implementation is mach-omap2/resource34xx.c/set_opp(),
when using resource_release to remove vdd1 constraint,
this function may call resource_release again to release
Vdd2 constrait if target vdd1 level is less than OPP3.
in this scenario, the global res_mutex down operation
will be called again, this will cause the second
down operation hang there.
To fix the problem, per-resource mutex is added
to avoid hangup when resource_request/resource_release
is called recursively.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/include/mach/resource.h |2 ++
arch/arm/plat-omap/resource.c | 27
+++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/resource.h
b/arch/arm/plat-omap/include/mach/resource.h
index f91d8ce..d482fb8 100644
--- a/arch/arm/plat-omap/include/mach/resource.h
+++ b/arch/arm/plat-omap/include/mach/resource.h
@@ -46,6 +46,8 @@ struct shared_resource {
/* Shared resource operations */
struct shared_resource_ops *ops;
struct list_head node;
+ /* Protect each resource */
+ struct mutex resource_mutex;
};
struct shared_resource_ops {
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..5eae4e8 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
return -EEXIST;
INIT_LIST_HEAD(resp-users_list);
+ mutex_init(resp-resource_mutex);
down(res_mutex);
/* Add the resource to the resource list */
@@ -326,14 +327,14 @@ int resource_request(const char *name, struct
device *dev,
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_request: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
/* Call the resource specific validate function */
if (resp-ops-validate_level) {
ret = resp-ops-validate_level(resp, level);
@@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
*dev,
user-level = level;
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
/*
* Recompute and set the current level for the resource.
* NOTE: update_resource level moved out of spin_lock, as it may
call
@@ -371,6 +372,7 @@ res_unlock:
*/
if (!ret)
ret = update_resource_level(resp);
+ret:
return ret;
}
EXPORT_SYMBOL(resource_request);
@@ -393,14 +395,14 @@ int resource_release(const char *name, struct
device *dev)
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
list_for_each_entry(user, resp-users_list, node) {
if (user-dev == dev) {
found = 1;
@@ -421,7 +423,9 @@ int resource_release(const char *name, struct device
*dev)
/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
+
+ret:
return ret;
}
EXPORT_SYMBOL(resource_release);
@@ -438,15 +442,14 @@ int resource_get_level(const char *name)
struct shared_resource *resp;
u32 ret;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
- up(res_mutex);
return -EINVAL;
}
+ mutex_lock(resp-resource_mutex);
ret = resp-curr_level;
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 04:40:27PM +0530, Syed Mohammed, Khasim wrote:
This patch seem to be working, I don't see any dump like before.
Great.
Can you please advice on how to get this patch into kernel? I mean,
will you be handling it or we need to re-submit them with your signed off?
Yes, I'll be sending it. However, I believe the patch I sent contains
one error:
+static int __init meminfo_cmp(const void *_a, const void *_b)
+{
+ const struct membank *a = _a, *b = _b;
+ long cmp = bank_pfn_start(b) - bank_pfn_start(a);
I think this should be bank_pfn_start(a) - bank_pfn_start(b). When you
tested this unmodified patch, did the Memory: line list the memory
bank sizes in reverse order?
--
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 04/13] OMAP2/3 clock: ensure each clock has a unique name
On Mon, Aug 17, 2009 at 04:06:44AM -0600, Paul Walmsley wrote: Hello Russell, On Mon, 17 Aug 2009, Russell King - ARM Linux wrote: On Mon, Aug 17, 2009 at 03:14:45AM -0600, Paul Walmsley wrote: What it does remove is the need for internal core code to fake up a struct device simply to access a clock. It also allows us to harmonize the clock names, used internally in core code, with the hardware reality, which uses unique names to identify clocks. That problem is already solved. clk_get_sys() That solves the first problem, but not the second. Is there some reason that OMAP core code (aside from the clkdev mapping structures in mach-omap2/clock*.c) should know, or care, whether a platform device name is bound to that clock? It's not a platform device name. It's a _device_ name. It really has precisely nothing what so ever to do with platform devices. clkdev really couldn't care if the struct device you gave it was representing a PCI device, AMBA device or a platform device. On OMAP, we have uniquely-named clock lines in the technical documentation. It is possible that other platforms don't have this. But for us, I'd submit that it makes more sense for internal core code to fetch a clock documented as MMC1_FCLK with: c = omap_clk_get_by_name(mmc1_fck); The point is - why invent yet another different clock lookup mechanism when there already exists adequate mechanisms? Second question - there is going to be debugfs support for clkdev coming along. Have you involved yourself with those discussions to ensure that what is being proposed is going to be suitable for OMAPs usage, or is OMAP going to implement its own version independently? -- 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: Pull request for OMAP PM, clock, SDRC 2.6.32 patches
On Sun, Aug 16, 2009 at 07:45:59AM -0600, Paul Walmsley wrote: Hello Russell, Here's the pull request for the thirteen patches posted earlier, plus Hiroshi's clock debugfs error path fix. I'm afraid to say that I think you've left it far too late to send this. I did set a date of the 16th as being the final date to sort out stuff (which was flexible to a degree) but since these patches were only posted on Saturday, and they're still being discussed, I don't think it would make sense for me to pull it today. And this is likely to be the final day that I merge anything into my kernel tree for the next two weeks. regards, - Paul The following changes since commit 3b3119fc549c93df60316d28bdd77c2de3986588: Russell King (1): Merge branch 'ixp4xx-fixes' of git://git.kernel.org/.../chris/linux-2.6 That's stupid. Someone publishing _my_ tree, which I make no guarantees about the life of the commits, for other people to base their work on... That's definitely a big FAIL. Luckily for you though, that commit still exists in my tree, and I've asked Linus to pull that set; so essentially it became immutable only last night. Don't base patches on the contents of my tree without talking to me first please. -- 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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Monday, August 17, 2009 10:21 PM
To: Syed Mohammed, Khasim
Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org
Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 04:40:27PM +0530, Syed Mohammed, Khasim wrote:
This patch seem to be working, I don't see any dump like before.
Great.
Can you please advice on how to get this patch into kernel? I mean,
will you be handling it or we need to re-submit them with your signed off?
Yes, I'll be sending it. However, I believe the patch I sent contains
one error:
Thanks.
+static int __init meminfo_cmp(const void *_a, const void *_b)
+{
+ const struct membank *a = _a, *b = _b;
+ long cmp = bank_pfn_start(b) - bank_pfn_start(a);
I think this should be bank_pfn_start(a) - bank_pfn_start(b). When you
tested this unmodified patch, did the Memory: line list the memory
bank sizes in reverse order?
Unmodified results in
MEM: unordered memory banks. Not freeing memmap.
Memory: 60MB 88MB = 148MB total
Making it a - b results in
Memory: 88MB 60MB = 148MB total
a-b is correct one, fortunately both worked for me.
Regards,
Khasim
--
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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Sat, Aug 15, 2009 at 07:17:11PM +0100, Russell King - ARM Linux wrote:
+#ifndef CONFIG_SPARSEMEM
+int pfn_valid(unsigned long pfn)
+{
+ struct meminfo *mi = meminfo;
+ unsigned int mid, left = 0, right = mi-nr_banks;
+
+ while ((mid = (right - left) / 2) 0) {
+ struct membank *bank = mi-bank[mid];
+
+ if (pfn bank_pfn_start(bank))
+ right = mid;
+ else if (pfn = bank_pfn_end(bank))
+ left = mid + 1;
+ else
+ return 1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(pfn_valid);
+#endif
The above function will ignore the first bank. I don't think that was
intended.
Rabin
--
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 04/13] OMAP2/3 clock: ensure each clock has a unique name
Hello Russell, On Mon, 17 Aug 2009, Russell King - ARM Linux wrote: On Mon, Aug 17, 2009 at 04:06:44AM -0600, Paul Walmsley wrote: On Mon, 17 Aug 2009, Russell King - ARM Linux wrote: On Mon, Aug 17, 2009 at 03:14:45AM -0600, Paul Walmsley wrote: What it does remove is the need for internal core code to fake up a struct device simply to access a clock. It also allows us to harmonize the clock names, used internally in core code, with the hardware reality, which uses unique names to identify clocks. That problem is already solved. clk_get_sys() That solves the first problem, but not the second. Is there some reason that OMAP core code (aside from the clkdev mapping structures in mach-omap2/clock*.c) should know, or care, whether a platform device name is bound to that clock? It's not a platform device name. It's a _device_ name. It really has precisely nothing what so ever to do with platform devices. clkdev really couldn't care if the struct device you gave it was representing a PCI device, AMBA device or a platform device. Sure, I mistyped. So, to revise the question, Is there some reason that OMAP core code (aside from the clkdev mapping structures in mach-omap2/clock*.c) should know, or care, whether a device name is bound to that clock? On OMAP, we have uniquely-named clock lines in the technical documentation. It is possible that other platforms don't have this. But for us, I'd submit that it makes more sense for internal core code to fetch a clock documented as MMC1_FCLK with: c = omap_clk_get_by_name(mmc1_fck); The point is - why invent yet another different clock lookup mechanism when there already exists adequate mechanisms? Is there an existing mechanism that allows us to look up a clock by simply using its unique name? Second question - there is going to be debugfs support for clkdev coming along. Have you involved yourself with those discussions to ensure that what is being proposed is going to be suitable for OMAPs usage, or is OMAP going to implement its own version independently? It's already implemented for OMAP, in mainline, from commit 137b3ee27ab1b27dba081542476054836978ca45. At the moment, clkdev doesn't have anything here. When debugfs support is added to clkdev, I'm sure we'll be happy to switch to it. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Duplicate devkit8000 machine database entry
For people's information: Today, someone has added a new devkit8000 entry for OMAP3 with a useful description of nothing. I'm expiring this entry right now - the machine database isn't supposed to have multiple entries for the same platform. Please ensure that no code is merged which references: CONFIG_MACH_OMAP3_DEVKIT8000, MACH_TYPE_OMAP3_DEVKIT8000, or machine_is_omap3_devkit8000(). Thanks. -- 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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 06:47:18PM +0100, Russell King - ARM Linux wrote:
On Mon, Aug 17, 2009 at 11:03:44PM +0530, Rabin Vincent wrote:
On Sat, Aug 15, 2009 at 07:17:11PM +0100, Russell King - ARM Linux wrote:
+#ifndef CONFIG_SPARSEMEM
+int pfn_valid(unsigned long pfn)
+{
+ struct meminfo *mi = meminfo;
+ unsigned int mid, left = 0, right = mi-nr_banks;
+
+ while ((mid = (right - left) / 2) 0) {
+ struct membank *bank = mi-bank[mid];
+
+ if (pfn bank_pfn_start(bank))
+ right = mid;
+ else if (pfn = bank_pfn_end(bank))
+ left = mid + 1;
+ else
+ return 1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(pfn_valid);
+#endif
The above function will ignore the first bank. I don't think that was
intended.
Why do you say that?
Let's start with 4 membank entries - 0 1 2 3.
0 covers 0-10, 1 covers 20-30, 2 covers 40-50 and 3 covers 60-70.
Let's run through the steps looking for 5:
Initally, left = 0, right = 4, so mid=2. 5 40? Yes, so right becomes 2.
left = 0, right = 2, so mid=1. 5 20? Yes, so right becomes 1.
left = 0, right = 1, so mid=0. 5 0? No. 5 = 10? No. so return 1.
This doesn't look to me like it ignores the first bank. I think you're
wrong. Please provide me with your proof ASAP because right now it's
pending for Linus.
When mid == 0, the loop exits because the condition you have is :
while ((mid = (right - left) / 2) 0) {
^^
Thus bank[0] will never be checked.
Rabin
--
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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 11:31:45PM +0530, Rabin Vincent wrote:
When mid == 0, the loop exits because the condition you have is :
while ((mid = (right - left) / 2) 0) {
^^
Thus bank[0] will never be checked.
Ah yes, right. Damn it.
Oh well, this will probably have to wait a couple of weeks now (by
which time I expect I will have forgotten about the problem.)
--
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
Question(s) regarding OMAP3 PM and PBIAS
Kevin (et al), I have a OMAP35x board that I've done a quick-n-dirty port of 2.6.31-rc5 from Kevin's PM branch (cgit ID 70a1f2249bbe765f78cf5e220e4e3f539b41eb7f), and using the rx51 as a starting pint, added support for the Logic OMAP35x SOM, and using omap3_pm_config defconfig (with my platform added and the others removed). It boots up, but I'm running into a problem with my LAN IRQ (its hooked up to MMC1 dat0, and the external pullup is to Vio_1V8 instead of VMMC1) and the kernel puts IRQ 312 into polled mode due to the interrupt storm - NFSroot is pretty slow but usable. 1) How can I set the PBIAS register to allow MMC1 dat4-7 to be 1.8V instead of 3V that is needed for MMC1 dat0-3 - and do I have to worry about twl_mmc1_set_power reprogramming PBIAS for those pins? On startup, I see messages: Platform driver 'serial8250' needs updating - please use dev_pm_ops 2) What does the message please use dev_pm_ops mean and how can I fix things to suppress it? 3) When I try echo mem /sys/power/state, the console shows: omap3530# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.08 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) mmc0: card 133b removed Powerdomain (mpu_pwrdm) didn't enter target state 1 Powerdomain (neon_pwrdm) didn't enter target state 1 Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (cam_pwrdm) didn't enter target state 1 Powerdomain (dss_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend Restarting tasks ... done. omap3530# mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SD card at address 133b mmcblk1: mmc0:133b SD02G 1.91 GiB mmcblk1: p1 How can I figure out why it didn't go into suspend (i.e. why the powerdomains didn't go into target state 1)? I noticed with CPUIDLE enabled, turning on debug for clock/powerdomains overloads the console with sate change messages. -- Peter Barada pet...@logicpd.com Logic Product Development, Inc. -- 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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Sent: Monday, August 17, 2009 1:05 PM
To: Rabin Vincent
Cc: Syed Mohammed, Khasim; linux-arm-ker...@lists.arm.linux.org.uk; linux-
o...@vger.kernel.org
Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 11:31:45PM +0530, Rabin Vincent wrote:
When mid == 0, the loop exits because the condition you have is :
while ((mid = (right - left) / 2) 0) {
^^
Thus bank[0] will never be checked.
Ah yes, right. Damn it.
Oh well, this will probably have to wait a couple of weeks now (by
which time I expect I will have forgotten about the problem.)
How about this?:
#ifndef CONFIG_SPARSEMEM
int pfn_valid(unsigned long pfn)
{
struct meminfo *mi = meminfo;
unsigned int left = 0, right = mi-nr_banks;
while (left = right) {
unsigned int mid = (right - left) / 2;
struct membank *bank = mi-bank[mid];
if (pfn bank_pfn_start(bank))
right = mid;
else if (pfn = bank_pfn_end(bank))
left = mid + 1;
else
return 1;
}
return 0;
}
EXPORT_SYMBOL(pfn_valid);
#endif
Regards,
Sergio
--
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: MUSB regression in 2.6.31-rc6
Hello, The below referenced patch was helpful to me in resolving the 3twl4030_usb twl4030_usb: ldo init failed error. Examining the minicom.cap attachment, I can see that twl4030_usb is initialized before regulator. If you move the twl4030_usb initialization to after regulator, you should be ok. [PATCH] USB:otg:twl4030-usb.c: mark .init as subsys_initcall_sync http://marc.info/?l=linux-usbm=124913041802639w=2 I also included the aforementioned patch at the end of Re: [PATCH 10/10] OMAP3: update OMAP3 Beagle defconfig, v2 http://marc.info/?l=linux-omapm=125038741913297w=2 Regards, Eric -- 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_hsmmc: Fix for the db clock failure message
Hi,
This patch applies on top of the series [PATCH V2 0/32] mmc and omap_hsmmc
patches posted by Adrian Hunter.
Regards,
Madhu
-
This patch removes the error message Failed to get debounce clock.. printed
out by the HSMMC driver on OMAP3430. The debounce clock needs to be handled only
for OMAP2430.
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 63 +++---
1 file changed, 41 insertions(+), 22 deletions(-)
Index: linux-2.6/drivers/mmc/host/omap_hsmmc.c
===
--- linux-2.6.orig/drivers/mmc/host/omap_hsmmc.c
+++ linux-2.6/drivers/mmc/host/omap_hsmmc.c
@@ -735,8 +735,10 @@ static int omap_hsmmc_switch_opcond(stru
/* Disable the clocks */
clk_disable(host-fclk);
clk_disable(host-iclk);
- if (host-dbclk_enabled)
+ if (cpu_is_omap2430() host-dbclk_enabled) {
clk_disable(host-dbclk);
+ host-dbclk_enabled = 0;
+ }
/* Turn the power off */
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 0, 0);
@@ -746,9 +748,14 @@ static int omap_hsmmc_switch_opcond(stru
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 1,
vdd);
clk_enable(host-iclk);
- if (host-dbclk_enabled)
- clk_enable(host-dbclk);
clk_enable(host-fclk);
+ if (cpu_is_omap2430() !host-dbclk_enabled) {
+ if (clk_enable(host-dbclk) != 0)
+ dev_dbg(mmc_dev(host-mmc), Enabling debounce
+clk failed\n);
+ else
+ host-dbclk_enabled = 1;
+ }
if (ret != 0)
goto err;
@@ -1697,18 +1704,21 @@ static int __init omap_hsmmc_probe(struc
goto err1;
}
- host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
- /*
-* MMC can still work without debounce clock.
-*/
- if (IS_ERR(host-dbclk))
- dev_warn(mmc_dev(host-mmc), Failed to get debounce clock\n);
- else
- if (clk_enable(host-dbclk) != 0)
- dev_dbg(mmc_dev(host-mmc), Enabling debounce
-clk failed\n);
+ if (cpu_is_omap2430()) {
+ host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
+ /*
+* MMC can still work without debounce clock.
+*/
+ if (IS_ERR(host-dbclk))
+ dev_warn(mmc_dev(host-mmc),
+ Failed to get debounce clock\n);
else
- host-dbclk_enabled = 1;
+ if (clk_enable(host-dbclk) != 0)
+ dev_dbg(mmc_dev(host-mmc), Enabling debounce
+clk failed\n);
+ else
+ host-dbclk_enabled = 1;
+ }
/* Since we do only SG emulation, we can have as many segs
* as we want. */
@@ -1825,8 +1835,9 @@ err_irq:
clk_disable(host-iclk);
clk_put(host-fclk);
clk_put(host-iclk);
- if (host-dbclk_enabled) {
- clk_disable(host-dbclk);
+ if (cpu_is_omap2430()) {
+ if (host-dbclk_enabled)
+ clk_disable(host-dbclk);
clk_put(host-dbclk);
}
@@ -1859,8 +1870,9 @@ static int omap_hsmmc_remove(struct plat
clk_disable(host-iclk);
clk_put(host-fclk);
clk_put(host-iclk);
- if (host-dbclk_enabled) {
- clk_disable(host-dbclk);
+ if (cpu_is_omap2430()) {
+ if (host-dbclk_enabled)
+ clk_disable(host-dbclk);
clk_put(host-dbclk);
}
@@ -1910,8 +1922,10 @@ static int omap_hsmmc_suspend(struct pla
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
mmc_host_disable(host-mmc);
clk_disable(host-iclk);
- if (host-dbclk_enabled)
+ if (cpu_is_omap2430() host-dbclk_enabled) {
clk_disable(host-dbclk);
+ host-dbclk_enabled = 0;
+ }
} else {
host-suspended = 0;
if (host-pdata-resume) {
@@ -1942,14 +1956,19 @@ static int omap_hsmmc_resume(struct plat
if (ret)
goto clk_en_err;
- if (host-dbclk_enabled)
- clk_enable(host-dbclk);
-
if (mmc_host_enable(host-mmc) != 0) {
[PATCH 1/3] i2c-omap: Fix I2C status ACK
From: Nishanth Menon n...@ti.com
I2C status ack for [RX]RDR and [RX]RDY could
cause race conditions of clearing the event
twice and a violation of the programing
sequence as defined in TRM This patch fixes
the same.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
drivers/i2c/busses/i2c-omap.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d258b02..94639d0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -674,7 +674,14 @@ omap_i2c_isr(int this_irq, void *dev_id)
err = 0;
complete:
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
+ /*
+* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
+* acked after the data operation is complete.
+* Ref: TRM SWPU114Q Figure 18-31
+*/
+ omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat
+ ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] *** SUBJECT HERE ***
From: Moiz Sonasath m-sonas...@ti.com i2c-omap: I2C clean-up patch This patch includes the following fixes: -Fix I2C status ACK -ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path -Enable workaround for Errata 1.153 based on I2C IP block Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com Moiz Sonasath (3): i2c-omap: Fix I2C status ACK i2c-omap: ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path i2c-omap: Enable workaround for Errata 1.153 based on I2C IP block drivers/i2c/busses/i2c-omap.c | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] i2c-omap: Enable workaround for Errata 1.153 based on
From: Moiz Sonasath m-sonas...@ti.com
Silicon Errata 1.153 has been fixed on OMAP 3630|4430 with the use of a later
version of I2C IP block.
The errata impacts OMAP 2420|2430|3430, enable the workaround for these based
on I2C IP block revision number instead of OMAP CPU type
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 16b39f4..827da08 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -784,7 +784,7 @@ complete:
* memory to the I2C interface.
*/
- if (cpu_is_omap34xx()) {
+ if (dev-rev = OMAP_I2C_REV_ON_3430) {
while (!(stat
OMAP_I2C_STAT_XUDF)) {
if (stat
(OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, stat (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] i2c-omap: Fix I2C status ACK
From: Nishanth Menon n...@ti.com
I2C status ack for [RX]RDR and [RX]RDY could
cause race conditions of clearing the event
twice and a violation of the programing
sequence as defined in TRM This patch fixes
the same.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
drivers/i2c/busses/i2c-omap.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d258b02..94639d0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -674,7 +674,14 @@ omap_i2c_isr(int this_irq, void *dev_id)
err = 0;
complete:
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
+ /*
+* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
+* acked after the data operation is complete.
+* Ref: TRM SWPU114Q Figure 18-31
+*/
+ omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat
+ ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
if (stat OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] i2c-omap: Enable workaround for Errata 1.153 based on
Silicon Errata 1.153 has been fixed on OMAP 3630|4430 with the use of a later
version of I2C IP block.
The errata impacts OMAP 2420|2430|3430, enable the workaround for these based
on I2C IP block revision number instead of OMAP CPU type
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 16b39f4..827da08 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -784,7 +784,7 @@ complete:
* memory to the I2C interface.
*/
- if (cpu_is_omap34xx()) {
+ if (dev-rev = OMAP_I2C_REV_ON_3430) {
while (!(stat
OMAP_I2C_STAT_XUDF)) {
if (stat
(OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, stat (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] i2c-omap: ACK pending [R/X]DR and [R/X]RDY interrupts
ACK any pending read/write interrupts before exiting the ISR either after
completing the operation [ARDY interrupt] or in case of an error
[NACK|AL interrupt]
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 94639d0..16b39f4 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -694,6 +694,9 @@ complete:
}
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
+ omap_i2c_ack_stat(dev, stat
+ (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] *** SUBJECT HERE ***
i2c-omap: I2C clean-up patch This patch includes the following fixes: -Fix I2C status ACK -ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path -Enable workaround for Errata 1.153 based on I2C IP block Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com Moiz Sonasath (3): i2c-omap: Fix I2C status ACK i2c-omap: ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path i2c-omap: Enable workaround for Errata 1.153 based on I2C IP block drivers/i2c/busses/i2c-omap.c | 14 -- 1 files changed, 12 insertions(+), 2 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
RE: Zoom2 Support on LO Master broken ?
Hemanth -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of I am unable to boot from quad uart and if I try uart3 I get the below error For quad uart it stops after downloading kernel (ZOOM2 defconfig), probably related to LL_DEBUG setting. There are couple of problems that I found. The serial.c has recently changed and hence there is a change required in zoom2-debug file. And then there is the correct implementation for low level debug uart for zoom2. I have this work-in-progress patch at: git://dev.omapzoom.org/pub/scm/vikram/omap3.git zoom2_boot with this you can boot the zoom2 fine. Will post the patch series tomorrow. Reference combined patch [1] [1] http://dev.omapzoom.org/?p=vikram/omap3.git;a=commitdiff;h=81280ed52d20ef935e926e43d702ddf918d0f13c 3IP-Config: No network devices available. IP-Config: No network devices available. -- 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 -- 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: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 03:23:18PM -0500, Aguirre Rodriguez, Sergio Alberto
wrote:
#ifndef CONFIG_SPARSEMEM
int pfn_valid(unsigned long pfn)
{
struct meminfo *mi = meminfo;
unsigned int left = 0, right = mi-nr_banks;
while (left = right) {
This condition will cause the while to loop forever when left == right
and pfn bank_pfn_start(bank).
unsigned int mid = (right - left) / 2;
This calculation is incorrect when left != 0 (also in the original
patch).
struct membank *bank = mi-bank[mid];
if (pfn bank_pfn_start(bank))
right = mid;
else if (pfn = bank_pfn_end(bank))
left = mid + 1;
else
return 1;
}
return 0;
}
EXPORT_SYMBOL(pfn_valid);
#endif
Here's a fixed version:
int pfn_valid(unsigned long pfn)
{
struct meminfo *mi = meminfo;
unsigned int left = 0, right = mi-nr_banks;
while (left right) {
unsigned int mid = (left + right) / 2;
struct membank *bank = mi-bank[mid];
if (pfn bank_pfn_start(bank))
right = mid;
else if (pfn = bank_pfn_end(bank))
left = mid + 1;
else
return 1;
}
return 0;
}
Rabin
--
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: [RFC][PATCH 1/2] OMAP4: sDMA drvier: adding OMAP kConfig option CONFIG_OMAP_DMA_DESCRIPTOR_LOAD
Kevin, On Thu, Aug 13, 2009 at 5:09 AM, Kevin Hilmankhil...@deeprootsystems.com wrote: S, Venkatraman svenk...@ti.com writes: The hardware feature is available on OMAP4430 and also expected to be in OMAP3630. Hence the feature flag will control the inclusion of the additional functions. Addition of omap kconfig option CONFIG_OMAP_DMA_DESCRIPTOR_LOAD. Short version: (a.k.a caveman version) - Compile-time option: bad. - Run-time option: good. Long version: Without looking at the docs, I would hope that the some revision reg or similar would report whether this feature is available or not. The user configuring the kernel should not have to know whether his SoC has this feature or not. Kevin -- Thanks for your comments. Yes, the DMA_CAPS_0 register contains flags for linked list capability and it can be checked. Obviously, I intended this (compile time flag) for code space saving for all older platforms. Not only in this file, but all client drivers those that would eventually start using this capability. I am preparing a patch with the runtime check (+ other changes you'd suggested), but I am curious to know what's the general threshold at which compile time flag (and it's associated code savings) is considered a valid trade off? Thanks and regards, Venkat. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
