Re: [PATCH] input: Add support for the TSC2003 controller.
* Trilok Soni wrote:
Hi Therry,
On Mon, May 4, 2009 at 8:27 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Trilok Soni wrote:
Hi Thierry,
On Mon, May 4, 2009 at 5:07 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Kwangwoo Lee wrote:
Hi Thierry and Trilok,
On Wed, Apr 29, 2009 at 10:23 PM, Trilok Soni soni.tri...@gmail.com
wrote:
Hi Thierry,
I have added linux-omap community. How different is this chip from
tsc2007. It looks to me that this chip is not much different from
tsc2007 (this is just quick look at the driver). If they
are similar please consider using i2c_device_id feature in tsc2007 to
accommodate this chip.
I agree with the Trilok's opinion.
[snip]
I only noticed the tsc2007 driver some time ago, when the tsc2003 was
already
finished (it's actually pretty old, I just never got around to submitting
it). However I never got the tsc2007 to work on my platform because it
uses
sleeping functions inside the timer handler, which results in an oops
right
after the first touchscreen interrupt.
I guess I could try and fix the tsc2007 properly instead of having a
second,
pretty similar driver in the tree.
This could be because of improper locking? If you share a crash we can
have look at it.
Attached is a patch that fixes things for me. The problem was that the I2C
transfers were done in interrupt context which fails for the controller I
use
(PXA270). The attached patch uses a struct work_struct to schedule the I2C
transfers so they are executed in non-interrupt context.
I've tested the patch on a minimal system with tslib and it work fine with
ts_calibrate and friends.
Thanks for the patch. It looks good. Let's wait for Kwangwoo Lee to
verify it on his platform. Also please add tsc2003 entry into
i2c_device_ids so that i2c_board_info can specify the .name as
tsc2003.
A second patch is attached that merely adds the tsc2003 to the list of
supported device IDs. I've split the patch off because it has nothing to do
with the other changes.
Thierry
From: Thierry Reding thierry.red...@avionic-design.de
Subject: [PATCH] tsc2007: Add support for TSC2003 chips.
The TSC2003 is very similar to the TSC2007 an can be supported by the same
driver with no additional changes.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/input/touchscreen/tsc2007.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index 6efb54d..599aa67 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -360,6 +360,7 @@ static int tsc2007_remove(struct i2c_client *client)
static struct i2c_device_id tsc2007_idtable[] = {
{ tsc2007, 0 },
+ { tsc2003, 0 },
{ }
};
--
tg: (84e274c..) adx/input/tsc2003 (depends on: adx/input/tsc2007)
OMAP3: PM: Add the wakeup source driver, v4
Sometimes, it is necessary to find out what does wake up my board from
suspend?. Notifying wake-up source feature may be used to blame unexpected
wake-up events which increase power consumption. And user mode applications can
act smartly according to the wake-up event from Suspend-to-RAM state to
minimize power consumption. Note that this driver can't inform wake-up events
from idle state. This driver uses sysfs interface to give information to user
mode applications like:
cat /sys/power/omap_resume_irq
cat /sys/power/omap_resume_event
This driver also provides the I/O pad wake-up source configuration. Specific
GPIO settings in the board file are:
/* I/O pad wakeup source configuration */
static struct iopad_wake boardname_iopad_wake[] = {
{
.mux_index = AE7_34XX_GPIO24,
.alias = KEY_PWRON,
},
{
.mux_index = ETK_D9_GPIO23,
.alias = USB_DETECT,
},
};
static struct omap_wake_platform_data boardname_wake_data = {
.iopad_wakes= boardname_iopad_wake,
.iopad_wake_num = ARRAY_SIZE(boardname_iopad_wake),
};
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
The patch adds Kconfig options OMAP34xx wakeup source support under System
type-TI OMAP implementations menu.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 21 ++-
arch/arm/mach-omap2/omapdev-common.h |3 +
arch/arm/mach-omap2/omapdev3xxx.h | 63 +
arch/arm/mach-omap2/pm34xx.c | 13 +
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h|5 +
arch/arm/mach-omap2/wake34xx.c| 409 +
arch/arm/plat-omap/Kconfig|9 +
arch/arm/plat-omap/include/mach/irqs.h|4 +
arch/arm/plat-omap/include/mach/mux.h |3 +
arch/arm/plat-omap/include/mach/omapdev.h |3 +
arch/arm/plat-omap/include/mach/wake.h| 52
arch/arm/plat-omap/mux.c | 25 ++-
14 files changed, 605 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c58bab4..cfc5a13 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP3_WAKE) += wake34xx.o
endif
# SmartReflex driver
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 700fc3d..18ac725 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -33,9 +33,6 @@
#define INTC_MIR_SET0 0x008c
#define INTC_PENDING_IRQ0 0x0098
-/* Number of IRQ state bits in each MIR register */
-#define IRQ_BITS_PER_REG 32
-
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own bank. Register definitions are
@@ -193,6 +190,24 @@ int omap_irq_pending(void)
return 0;
}
+void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
+{
+ int i, j = 0;
+
+ for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
+ struct omap_irq_bank *bank = irq_banks + i;
+ int irq;
+
+ for (irq = 0; irq bank-nr_irqs j len;
+ irq += IRQ_BITS_PER_REG) {
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ pending_irqs[j++] = intc_bank_read_reg(bank,
+ (INTC_PENDING_IRQ0 + offset));
+ }
+ }
+}
+
void __init omap_init_irq(void)
{
unsigned long nr_of_irqs = 0;
diff --git a/arch/arm/mach-omap2/omapdev-common.h
b/arch/arm/mach-omap2/omapdev-common.h
index a2d4855..57b9b0b 100644
--- a/arch/arm/mach-omap2/omapdev-common.h
+++ b/arch/arm/mach-omap2/omapdev-common.h
@@ -228,10 +228,13 @@ static struct omapdev *omapdevs[] = {
hsmmc2_3xxx_omapdev,
mcspi3_3xxx_omapdev,
gptimer1_3xxx_omapdev,
+ gptimer12_3xxx_omapdev,
prm_3xxx_omapdev,
cm_3xxx_omapdev,
omap_32ksynct_3xxx_omapdev,
gpio1_3xxx_omapdev,
+ io_3xxx_omapdev,
+ io_chain_3xxx_omapdev,
wdtimer2_3xxx_omapdev,
wdtimer1_3xxx_omapdev,
rng_3xxx_omapdev,
diff --git a/arch/arm/mach-omap2/omapdev3xxx.h
Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3
On Thu, Apr 30, 2009 at 11:21 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Also, I still think the WKST register reading should be done in the PRCM interrupt handler. In your previous attempt, you were seeing a bunch of non-device wakeup related interrupts. Can you try again with the attached patch (thanks to Paul Walmseley) which should help us debug why you were seeing spurious PRCM interrupts. First of all, sorry for giving you the wrong information in the previous mail. I found that we actually have configured GPTIMER12 as the system timer. And I tried with the attached patch, but I can't see any debug message. However even now, PRCM interrupt handler is invoked quite often due to the system timer. That's what I assumed was happening. As far as I know, after Peter's [OMAP3: PM: CPUidle: Add new lower-latency C1 state] patch is applied, the system is in 'wfi' state in every idle state. So whenever the system timer wake up the system from idle, I think PRCM interrupt occurs. Do you think still the WKST register should be read in the PRCM interrupt handler? ;) Yes. The WKST registers are already being read in the handler so they can be properly cleared. All you are adding is the saving of them. In addition, you should not enter idle between the time the system wakes from resume and your resume handler runs so you should be able to get the correct WKST values. OK, Your idea is more reasonable. I modified as you said. thanks. Also, I know we discussed this before, but I think the GPIO wakeup source stuff really belongs in a separate patch, and if you think it is still useful, and cannot be done by just enabling a GPIO IRQ from the board file, I suggest you propose a patch to the generic GPIO layer to add this interface. OK, I will remove this GPIO wakeup feature. But I want to know more detailed information about wakeup event . So, instead of using the GPIO wakeup, I'm planning using WAKEUPEVENT bit in CONTROL_PADCONF_x registers. That sounds OK. The current mux layer is lacking any knowledge of the wake bits in the PADCONF regs, so I'd be interested in any ideas you have of adding that support. I added my ideas about CONTROL_PADCONF_x into the new version of wake source driver. I will send it soon. Please review this new version again and feel free to give your opinion. Regards, Kyuwon (규원) -- 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] OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA
On Tue, Apr 21, 2009 at 09:39:22AM +0200, ext Gadiyar, Anand wrote: From: Anand Gadiyar gadi...@ti.com OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA This considerably reduces the number of interrupts during a transfer and ought to result in some power saving. I tried the patch with reading from the raw mmc block device to /dev/null with dd (with bs 32k and 1M). I cannot see any difference in interrupt count from /proc/interrupts or in read speed. At least the patch works. Cpu was 34340es3. I also trid without the patch just disabling the Buffer Read/write Ready bits from INT_EN_MASK which is then written to both MMCHS_IE and MMCHS_ISE. Still no change in read speed nor mmc irq count. Cheers Jarkko Lavinen -- 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/6] Initial support for omap iommu driver
Some of TI OMAP series have the peripheral devices with their own Memory Management Unit(IOMMU), which is composed of its own TLB and optional H/W pagetable (TWL). These MMUs doesn't depend on MPU(ARM) MMU at all, but their algorithms are quite similar and they share the same physical address space. This patch provides with common in-kernel iommu APIs such OMAP peripheral devices(Camera ISP, IVA1, IVA2, DSP and the equivalent ones in the latest OMAP successors) to handle peripheral device IOMMUs in the same manner. tlb and pagetable primitives has been updated with Russell's comments on: http://marc.info/?l=linux-omapm=122087083712670w=2 Generalizing this omap iommu code independently from each device drivers, Camera(ISP), TI bridge(IVA/DSP), dspgateway(DSP) and the future OMAP equivalent device would be more robust and reduce the maintenance cost since keeping this critical code at one place can avoid some risks, like wrong MMU settings, which may cause critical damages on the system. --- The following changes since commit 091438dd5668396328a3419abcbc6591159eb8d1: Linus Torvalds (1): Linux 2.6.30-rc4 are available in the git repository at: http://git.gitorious.org/lk/mainline.git iommu Hiroshi DOYU (6): omap iommu: tlb and pagetable primitives omap iommu: omap2 architecture specific functions omap iommu: omap3 iommu device registration omap iommu: simple virtual address space management omap iommu: entries for Kconfig and Makefile omap2 iommu: entries for Kconfig and Makefile arch/arm/include/asm/io.h|6 + arch/arm/mach-omap2/Makefile |5 + arch/arm/mach-omap2/iommu2.c | 323 ++ arch/arm/mach-omap2/omap3-iommu.c| 105 arch/arm/mm/ioremap.c| 11 + arch/arm/plat-omap/Kconfig |8 + arch/arm/plat-omap/Makefile |1 + arch/arm/plat-omap/include/mach/iommu.h | 168 + arch/arm/plat-omap/include/mach/iommu2.h | 96 +++ arch/arm/plat-omap/include/mach/iovmm.h | 94 +++ arch/arm/plat-omap/iommu.c | 996 ++ arch/arm/plat-omap/iopgtable.h | 72 +++ arch/arm/plat-omap/iovmm.c | 890 ++ 13 files changed, 2775 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/iommu2.c create mode 100644 arch/arm/mach-omap2/omap3-iommu.c create mode 100644 arch/arm/plat-omap/include/mach/iommu.h create mode 100644 arch/arm/plat-omap/include/mach/iommu2.h create mode 100644 arch/arm/plat-omap/include/mach/iovmm.h create mode 100644 arch/arm/plat-omap/iommu.c create mode 100644 arch/arm/plat-omap/iopgtable.h create mode 100644 arch/arm/plat-omap/iovmm.c -- 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/6] omap iommu: omap2 architecture specific functions
The structure 'arch_mmu' accommodates the difference between omap1 and
omap2/3.
This patch provides omap2/3 specific functions
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/iommu2.c | 323 ++
arch/arm/plat-omap/include/mach/iommu2.h | 96 +
2 files changed, 419 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/iommu2.c
create mode 100644 arch/arm/plat-omap/include/mach/iommu2.h
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
new file mode 100644
index 000..015f22a
--- /dev/null
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -0,0 +1,323 @@
+/*
+ * omap iommu: omap2/3 architecture specific functions
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@nokia.com,
+ * Paul Mundt and Toshihiro Kobayashi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/device.h
+#include linux/jiffies.h
+#include linux/module.h
+#include linux/stringify.h
+
+#include mach/iommu.h
+
+/*
+ * omap2 architecture specific register bit definitions
+ */
+#define IOMMU_ARCH_VERSION 0x0011
+
+/* SYSCONF */
+#define MMU_SYS_IDLE_SHIFT 3
+#define MMU_SYS_IDLE_FORCE (0 MMU_SYS_IDLE_SHIFT)
+#define MMU_SYS_IDLE_NONE (1 MMU_SYS_IDLE_SHIFT)
+#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
+#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
+
+#define MMU_SYS_SOFTRESET (1 1)
+#define MMU_SYS_AUTOIDLE 1
+
+/* SYSSTATUS */
+#define MMU_SYS_RESETDONE 1
+
+/* IRQSTATUS IRQENABLE */
+#define MMU_IRQ_MULTIHITFAULT (1 4)
+#define MMU_IRQ_TABLEWALKFAULT (1 3)
+#define MMU_IRQ_EMUMISS(1 2)
+#define MMU_IRQ_TRANSLATIONFAULT (1 1)
+#define MMU_IRQ_TLBMISS(1 0)
+#define MMU_IRQ_MASK \
+ (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_EMUMISS | \
+MMU_IRQ_TRANSLATIONFAULT)
+
+/* MMU_CNTL */
+#define MMU_CNTL_SHIFT 1
+#define MMU_CNTL_MASK (7 MMU_CNTL_SHIFT)
+#define MMU_CNTL_EML_TLB (1 3)
+#define MMU_CNTL_TWL_EN(1 2)
+#define MMU_CNTL_MMU_EN(1 1)
+
+#define get_cam_va_mask(pgsz) \
+ (((pgsz) == MMU_CAM_PGSZ_16M) ? 0xff00 :\
+((pgsz) == MMU_CAM_PGSZ_1M) ? 0xfff0 :\
+((pgsz) == MMU_CAM_PGSZ_64K) ? 0x :\
+((pgsz) == MMU_CAM_PGSZ_4K) ? 0xf000 : 0)
+
+static int omap2_iommu_enable(struct iommu *obj)
+{
+ u32 l, pa;
+ unsigned long timeout;
+
+ if (!obj-iopgd || !IS_ALIGNED((u32)obj-iopgd, SZ_16K))
+ return -EINVAL;
+
+ pa = virt_to_phys(obj-iopgd);
+ if (!IS_ALIGNED(pa, SZ_16K))
+ return -EINVAL;
+
+ iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
+
+ timeout = jiffies + msecs_to_jiffies(20);
+ do {
+ l = iommu_read_reg(obj, MMU_SYSSTATUS);
+ if (l MMU_SYS_RESETDONE)
+ break;
+ } while (time_after(jiffies, timeout));
+
+ if (!(l MMU_SYS_RESETDONE)) {
+ dev_err(obj-dev, can't take mmu out of reset\n);
+ return -ENODEV;
+ }
+
+ l = iommu_read_reg(obj, MMU_REVISION);
+ dev_info(obj-dev, %s: version %d.%d\n, obj-name,
+(l 4) 0xf, l 0xf);
+
+ l = iommu_read_reg(obj, MMU_SYSCONFIG);
+ l = ~MMU_SYS_IDLE_MASK;
+ l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
+ iommu_write_reg(obj, l, MMU_SYSCONFIG);
+
+ iommu_write_reg(obj, MMU_IRQ_MASK, MMU_IRQENABLE);
+ iommu_write_reg(obj, pa, MMU_TTB);
+
+ l = iommu_read_reg(obj, MMU_CNTL);
+ l = ~MMU_CNTL_MASK;
+ l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
+ iommu_write_reg(obj, l, MMU_CNTL);
+
+ return 0;
+}
+
+static void omap2_iommu_disable(struct iommu *obj)
+{
+ u32 l = iommu_read_reg(obj, MMU_CNTL);
+
+ l = ~MMU_CNTL_MASK;
+ iommu_write_reg(obj, l, MMU_CNTL);
+ iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
+
+ dev_dbg(obj-dev, %s is shutting down\n, obj-name);
+}
+
+static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
+{
+ int i;
+ u32 stat, da;
+ const char *err_msg[] = {
+ tlb miss,
+ translation fault,
+ emulation miss,
+ table walk fault,
+ multi hit fault,
+ };
+
+ stat = iommu_read_reg(obj, MMU_IRQSTATUS);
+ stat = MMU_IRQ_MASK;
+ if (!stat)
+ return 0;
+
+ da = iommu_read_reg(obj, MMU_FAULT_AD);
+ *ra = da;
+
+ dev_err(obj-dev, %s:\tda:%08x , __func__, da);
+
+ for (i = 0; i ARRAY_SIZE(err_msg); i++) {
+ if
[PATCH 1/6] omap iommu: tlb and pagetable primitives
This patch provides:
- iotlb_*() : iommu tlb operations
- iopgtable_*() : iommu pagetable(twl) operations
- iommu_*() : the other generic operations
and the entry points to register and acquire iommu object.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/include/mach/iommu.h | 168 +
arch/arm/plat-omap/iommu.c | 996 +++
arch/arm/plat-omap/iopgtable.h | 72 ++
3 files changed, 1236 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/iommu.h
create mode 100644 arch/arm/plat-omap/iommu.c
create mode 100644 arch/arm/plat-omap/iopgtable.h
diff --git a/arch/arm/plat-omap/include/mach/iommu.h
b/arch/arm/plat-omap/include/mach/iommu.h
new file mode 100644
index 000..769b00b
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/iommu.h
@@ -0,0 +1,168 @@
+/*
+ * omap iommu: main structures
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __MACH_IOMMU_H
+#define __MACH_IOMMU_H
+
+struct iotlb_entry {
+ u32 da;
+ u32 pa;
+ u32 pgsz, prsvd, valid;
+ union {
+ u16 ap;
+ struct {
+ u32 endian, elsz, mixed;
+ };
+ };
+};
+
+struct iommu {
+ const char *name;
+ struct module *owner;
+ struct clk *clk;
+ void __iomem*regbase;
+ struct device *dev;
+
+ unsigned intrefcount;
+ struct mutexiommu_lock; /* global for this whole object */
+
+ /*
+* We don't change iopgd for a situation like pgd for a task,
+* but share it globally for each iommu.
+*/
+ u32 *iopgd;
+ spinlock_t page_table_lock; /* protect iopgd */
+
+ int nr_tlb_entries;
+
+ struct list_headmmap;
+ struct mutexmmap_lock; /* protect mmap */
+
+ int (*isr)(struct iommu *obj);
+
+ void *ctx; /* iommu context: registres saved area */
+};
+
+struct cr_regs {
+ union {
+ struct {
+ u16 cam_l;
+ u16 cam_h;
+ };
+ u32 cam;
+ };
+ union {
+ struct {
+ u16 ram_l;
+ u16 ram_h;
+ };
+ u32 ram;
+ };
+};
+
+struct iotlb_lock {
+ short base;
+ short vict;
+};
+
+/* architecture specific functions */
+struct iommu_functions {
+ unsigned long version;
+
+ int (*enable)(struct iommu *obj);
+ void (*disable)(struct iommu *obj);
+ u32 (*fault_isr)(struct iommu *obj, u32 *ra);
+
+ void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
+ void (*tlb_load_cr)(struct iommu *obj, struct cr_regs *cr);
+
+ struct cr_regs *(*alloc_cr)(struct iommu *obj, struct iotlb_entry *e);
+ int (*cr_valid)(struct cr_regs *cr);
+ u32 (*cr_to_virt)(struct cr_regs *cr);
+ void (*cr_to_e)(struct cr_regs *cr, struct iotlb_entry *e);
+ ssize_t (*dump_cr)(struct iommu *obj, struct cr_regs *cr, char *buf);
+
+ u32 (*get_pte_attr)(struct iotlb_entry *e);
+
+ void (*save_ctx)(struct iommu *obj);
+ void (*restore_ctx)(struct iommu *obj);
+ ssize_t (*dump_ctx)(struct iommu *obj, char *buf);
+};
+
+struct iommu_platform_data {
+ const char *name;
+ const char *clk_name;
+ const int nr_tlb_entries;
+};
+
+#if defined(CONFIG_ARCH_OMAP1)
+#error iommu for this processor not implemented yet
+#else
+#include mach/iommu2.h
+#endif
+
+/*
+ * utilities for super page(16MB, 1MB, 64KB and 4KB)
+ */
+
+#define iopgsz_max(bytes) \
+ (((bytes) = SZ_16M) ? SZ_16M : \
+((bytes) = SZ_1M) ? SZ_1M : \
+((bytes) = SZ_64K) ? SZ_64K : \
+((bytes) = SZ_4K) ? SZ_4K : 0)
+
+#define bytes_to_iopgsz(bytes) \
+ (((bytes) == SZ_16M) ? MMU_CAM_PGSZ_16M : \
+((bytes) == SZ_1M) ? MMU_CAM_PGSZ_1M : \
+((bytes) == SZ_64K) ? MMU_CAM_PGSZ_64K : \
+((bytes) == SZ_4K) ? MMU_CAM_PGSZ_4K : -1)
+
+#define iopgsz_to_bytes(iopgsz)\
+ (((iopgsz) == MMU_CAM_PGSZ_16M) ? SZ_16M : \
+((iopgsz) == MMU_CAM_PGSZ_1M) ? SZ_1M : \
+((iopgsz) == MMU_CAM_PGSZ_64K) ? SZ_64K : \
+((iopgsz) == MMU_CAM_PGSZ_4K) ? SZ_4K : 0)
+
+#define iopgsz_ok(bytes) (bytes_to_iopgsz(bytes) = 0)
+
+/*
+ * global functions
+ */
+extern u32 iommu_arch_version(void);
+
+extern void iotlb_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e);
+extern u32
[PATCH 4/6] omap iommu: simple virtual address space management
This patch provides a device drivers, which has a omap iommu, with
address mapping APIs between device virtual address(iommu), physical
address and MPU virtual address.
There are 4 possible patterns for iommu virtual address(iova/da) mapping.
|iova/mapping iommu_ page
| dapa va (d)-(p)-(v) functiontype
---
1 | c c c1 - 1 - 1_kmap() / _kunmap() s
2 | c c,a c1 - 1 - 1 _kmalloc()/ _kfree()s
3 | c d c1 - n - 1_vmap() / _vunmap() s
4 | c d,a c1 - n - 1 _vmalloc()/ _vfree()n*
'iova': device iommu virtual address
'da': alias of 'iova'
'pa': physical address
'va': mpu virtual address
'c':contiguous memory area
'd':dicontiguous memory area
'a':anonymous memory allocation
'()': optional feature
'n':a normal page(4KB) size is used.
's':multiple iommu superpage(16MB, 1MB, 64KB, 4KB) size is used.
'*':not yet, but feasible.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/include/asm/io.h |6
arch/arm/mm/ioremap.c | 11
arch/arm/plat-omap/include/mach/iovmm.h | 94 +++
arch/arm/plat-omap/iovmm.c | 890 +++
4 files changed, 1001 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/iovmm.h
create mode 100644 arch/arm/plat-omap/iovmm.c
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d2a59cf..cbdadfe 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -75,6 +75,12 @@ extern void __iomem * __arm_ioremap(unsigned long, size_t,
unsigned int);
extern void __iounmap(volatile void __iomem *addr);
/*
+ * external interface to remap single page with appropriate type
+ */
+extern int ioremap_page(unsigned long virt, unsigned long phys,
+ unsigned int mtype);
+
+/*
* Bad read/write accesses...
*/
extern void __readwrite_bug(const char *fn);
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 9f88dd3..8441351 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -110,6 +110,17 @@ static int remap_area_pages(unsigned long start, unsigned
long pfn,
return err;
}
+int ioremap_page(unsigned long virt, unsigned long phys, unsigned int mtype)
+{
+ const struct mem_type *type;
+
+ type = get_mem_type(mtype);
+ if (!type)
+ return -EINVAL;
+
+ return remap_area_pages(virt, __phys_to_pfn(phys), PAGE_SIZE, type);
+}
+EXPORT_SYMBOL(ioremap_page);
void __check_kvm_seq(struct mm_struct *mm)
{
diff --git a/arch/arm/plat-omap/include/mach/iovmm.h
b/arch/arm/plat-omap/include/mach/iovmm.h
new file mode 100644
index 000..bdc7ce5
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/iovmm.h
@@ -0,0 +1,94 @@
+/*
+ * omap iommu: simple virtual address space management
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __IOMMU_MMAP_H
+#define __IOMMU_MMAP_H
+
+struct iovm_struct {
+ struct iommu*iommu; /* iommu object which this belongs to */
+ u32 da_start; /* area definition */
+ u32 da_end;
+ u32 flags; /* IOVMF_: see below */
+ struct list_headlist; /* linked in ascending order */
+ const struct sg_table *sgt; /* keep 'page' - 'da' mapping */
+ void*va; /* mpu side mapped address */
+};
+
+/*
+ * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
+ *
+ * lower 16 bit is used for h/w and upper 16 bit is for s/w.
+ */
+#define IOVMF_SW_SHIFT 16
+#define IOVMF_HW_SIZE (1 IOVMF_SW_SHIFT)
+#define IOVMF_HW_MASK (IOVMF_HW_SIZE - 1)
+#define IOVMF_SW_MASK (~IOVMF_HW_MASK)UL
+
+/*
+ * iovma: h/w flags derived from cam and ram attribute
+ */
+#define IOVMF_CAM_MASK (~((1 10) - 1))
+#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
+
+#define IOVMF_PGSZ_MASK(3 0)
+#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
+#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
+#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
+#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
+
+#define IOVMF_ENDIAN_MASK (1 9)
+#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
+#define IOVMF_ENDIAN_LITTLEMMU_RAM_ENDIAN_LITTLE
+
+#define IOVMF_ELSZ_MASK(3 7)
+#define IOVMF_ELSZ_8
[PATCH 3/6] omap iommu: omap3 iommu device registration
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/omap3-iommu.c | 105 +
1 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap3-iommu.c
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
new file mode 100644
index 000..367f36a
--- /dev/null
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -0,0 +1,105 @@
+/*
+ * omap iommu: omap3 device registration
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/platform_device.h
+
+#include mach/iommu.h
+
+#define OMAP3_MMU1_BASE0x480bd400
+#define OMAP3_MMU2_BASE0x5d00
+#define OMAP3_MMU1_IRQ 24
+#define OMAP3_MMU2_IRQ 28
+
+static struct resource omap3_iommu_res[] = {
+ { /* Camera ISP MMU */
+ .start = OMAP3_MMU1_BASE,
+ .end= OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_MMU1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ { /* IVA2.2 MMU */
+ .start = OMAP3_MMU2_BASE,
+ .end= OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_MMU2_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+#define NR_IOMMU_RES (ARRAY_SIZE(omap3_iommu_res) / 2)
+
+static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
+ {
+ .name = isp,
+ .nr_tlb_entries = 8,
+ .clk_name = cam_ick,
+ },
+ {
+ .name = iva2,
+ .nr_tlb_entries = 32,
+ .clk_name = iva2_ck,
+ },
+};
+#define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
+
+static struct platform_device *omap3_iommu_pdev[NR_IOMMU_DEVICES];
+
+static int __init omap3_iommu_init(void)
+{
+ int i, err;
+
+ for (i = 0; i NR_IOMMU_DEVICES; i++) {
+ struct platform_device *pdev;
+
+ pdev = platform_device_alloc(omap-iommu, i + 1);
+ if (!pdev) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+ err = platform_device_add_resources(pdev,
+ omap3_iommu_res[2 * i], NR_IOMMU_RES);
+ if (err)
+ goto err_out;
+ err = platform_device_add_data(pdev, omap3_iommu_pdata[i],
+ sizeof(omap3_iommu_pdata[0]));
+ if (err)
+ goto err_out;
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_out;
+ omap3_iommu_pdev[i] = pdev;
+ }
+ return 0;
+
+err_out:
+ while (i--)
+ platform_device_put(omap3_iommu_pdev[i]);
+ return err;
+}
+module_init(omap3_iommu_init);
+
+static void __exit omap3_iommu_exit(void)
+{
+ int i;
+
+ for (i = 0; i NR_IOMMU_DEVICES; i++)
+ platform_device_unregister(omap3_iommu_pdev[i]);
+}
+module_exit(omap3_iommu_exit);
+
+MODULE_AUTHOR(Hiroshi DOYU);
+MODULE_DESCRIPTION(omap iommu: omap3 device registration);
+MODULE_LICENSE(GPL v2);
--
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 5/6] omap iommu: entries for Kconfig and Makefile
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/plat-omap/Kconfig |8 arch/arm/plat-omap/Makefile |1 + 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 9dd68fa..505e6ab 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -115,6 +115,14 @@ config OMAP_MBOX_FWK Say Y here if you want to use OMAP Mailbox framework support for DSP, IVA1.0 and IVA2 in OMAP1/2/3. +config OMAP_IOMMU + tristate IOMMU support + depends on ARCH_OMAP + default n + help + Say Y here if you want to use OMAP IOMMU support for IVA2 and + Camera in OMAP3. + choice prompt System timer default OMAP_MPU_TIMER diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 04a100c..a832795 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -13,6 +13,7 @@ obj- := obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o +obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o obj-$(CONFIG_CPU_FREQ) += cpu-omap.o obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] omap2 iommu: entries for Kconfig and Makefile
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/mach-omap2/Makefile |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index c49d9bf..88629a7 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -28,6 +28,11 @@ endif obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o +iommu-y+= iommu2.o +iommu-$(CONFIG_ARCH_OMAP3) += omap3-iommu.o + +obj-$(CONFIG_OMAP_IOMMU) += $(iommu-y) + # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No OMAP PM code on the PM branch???
Peter Barada pet...@logicpd.com writes: I'm looking through Kevin's PM branch, and I've done a quick-port of 2.6.30-rc1 to Logic's OMAP3530 LV SOM starting with the rk21 board code, and echo mem /sys/power/state does nothing. Worse, cat /sys/power/state doesn't show anything. Since 2.6.30, there is no OMAP PM code in linux-omap master branch. The only working PM is now in the PM branch. I am currently rebasing the PM branch to 2.6.30-rc series and it should be published this week. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] onenand_init: Allow disabling sync read and write based on flags, v2 (Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to gpmc-onenand.c)
* vimal singh vimalsi...@ti.com [090504 22:52]: On Mon, May 4, 2009 at 9:29 PM, Tony Lindgren t...@atomide.com wrote: * vimal singh vimalsi...@ti.com [090503 22:36]: On Fri, May 1, 2009 at 11:08 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [090430 11:56]: * Tony Lindgren t...@atomide.com [090430 07:06]: * vimal singh vimalsi...@ti.com [090429 23:33]: 'gpmc-onenand.c' is still confusing name. This is not going to used in all boards anyway. Why do you think this cannot be used for all boards? The GPMC timings are totally based on the onenand chip features. And these two patches make omap3430sdp to work with the gpmc-onenand code. Sync mode does not work, but it seems like it was never enabled for sdp anyways. Similar patch should work for other boards too. Setting the sync_write depends on flags and processor, not just flags. Here's a fixed version of this patch. OK, these both patches seems good to me... OK, thanks for looking. Earlier I was in impression that this patch series is basically to remove board-*-flash.c files. Since in 3430sdp boards we find out 'CS' number for flash devices dynamically in different versions of boards. So, I was confused. Well looks like those functions are used for at least few boards, so we could have functions like gpmc_probe_onenand() and gpmc_probe_nor() functions that could be called from board-*.c files. That way we could have generic gpmc-onenand.c and gpmc-nor.c, and still do the necessary probe logic in the board-*.c files. But then how we'll be taking care of timing parameter configuration, for different chips (part numbers), as some of these parts may vary in timing specifications, and also for different working frequencies. Well at least gpmc-onenand.c already configures things based on the onenand revision, see ONENAND_REG_VERSION_ID in gpmc_onenand.c. We should be able to calculate the timings for the connected chip rather than using hardcoded values for each board. This will save lots of time bringing up new boards. And if we are going to put those information in board-*.c, then rather I will prefer separate board-*-flash.c file to handle all this. Sure we can have it that way if there's a need for that. It depends how much code is left to initialize there in the end. To me it sounds like it would contain just the partition tables and few lines to query the GPMC for connected flash chips. The rest we should be able to initialize in a generic way. 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
Beep sound in the end of audio file
Hi, After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help. Any idea how this can be avoided? Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated -- 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
next PM branch preview
Hello, I've rebased the PM branch on to current linux-omap HEAD (currently 2.6.30-rc4) and it is available from my tree[1] as the branch named 'pm-next' There's still a couple issues for me to work, out but since people have been asking, I've made it publicly available. So far, I have only tested full-chip retention in suspend and PM idle (not CPUidle) using minimal kernels on the following platforms: - 3430SDP: initramfs - RX51: OneNAND rootfs - OMAP3EVM: initramfs - Beagle: initramfs Not tested: - CPUidle - DVFS (CPUfreq) Known issues: - 3430SDP: CORE pwrdm does not hit retention - hangs on return from OFF - OMAP3EVM: debounce used on TS GPIO (in GPIO6) and result in Clock gpio6_dbck didn't enable in 10 tries Also note that I only build minimal kernels using very few drivers. So I've also added the defconfigs I used for the boards so it's clear what I'm using to test. They are named *_pm_defconfig. Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.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: [PATCH 3/6] omap iommu: omap3 iommu device registration
On Tue, May 5, 2009 at 3:47 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/omap3-iommu.c | 105
+
1 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap3-iommu.c
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
new file mode 100644
index 000..367f36a
--- /dev/null
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -0,0 +1,105 @@
+/*
+ * omap iommu: omap3 device registration
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU hiroshi.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/platform_device.h
+
+#include mach/iommu.h
+
+#define OMAP3_MMU1_BASE 0x480bd400
+#define OMAP3_MMU2_BASE 0x5d00
+#define OMAP3_MMU1_IRQ 24
+#define OMAP3_MMU2_IRQ 28
+
+static struct resource omap3_iommu_res[] = {
+ { /* Camera ISP MMU */
+ .start = OMAP3_MMU1_BASE,
+ .end = OMAP3_MMU1_BASE + MMU_REG_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_MMU1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ { /* IVA2.2 MMU */
+ .start = OMAP3_MMU2_BASE,
+ .end = OMAP3_MMU2_BASE + MMU_REG_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_MMU2_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
This will break TI's bridgedriver, right?
Can camera ISP and IVA request the registration of their respective
IOMMU's from their codebase?
--
Felipe Contreras
--
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: LDP support
On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [090428 15:07]: Tony, et.al., Any ideas when more LDP support will be pushed into mainline (such as the framebuffer support)? I'll be looking at the board-*.c patches for the next merge window hopefully this week or next week. Looks like LDP keyboard, touchscreen RTC are pretty much ready to go. Then the MMC has some regulator updates, but AFAIK the MMC should work OK already. For the framebuffer, Imre and Tomi know the status the best, so I've added them to Cc. Imre has been meaning to send a bunch of drivers/video/omap changes to the fbdev list for a while now and LDP framebuffer may depend on those. Imre, any news on the status of sending the fb patches upstream? Then there are the upcoming DSS patches from Tomi, but those still need some work before they're ready to go. Is there any news on this? Will we see more functional OMAP3 / LDP support queued for the next merge window? -- 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/6] omap iommu: tlb and pagetable primitives
Hi Doyu-san,
+static void iotlb_lock_set(struct iommu *obj, struct iotlb_lock *l) {
+ u32 val;
+
+ BUG_ON(l-base != 0); /* Currently no preservation is used */
-- Did you notice any issues in the IOMMU driver by enabling the preservation?
Bridge driver is locking the memory segment that is used for IPC in the TLB and
by not having the preservation we might see a hit in the performance.
Thank you,
Best regards,
Hari
--
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 clock: GPIO de-bounce clocks don't affect module idle state
GPIO de-bounce clocks don't have any impact on the module idle state, so
the clock code should not wait for the module to enable after the de-bounce
clocks are enabled.
Problem found by Kevin Hilman khil...@deeprootsystems.com.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clock34xx.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 6763b8f..017a30e 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -2182,7 +2182,7 @@ static struct clk wkup_32k_fck = {
static struct clk gpio1_dbck = {
.name = gpio1_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = wkup_32k_fck,
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO1_SHIFT,
@@ -2427,7 +2427,7 @@ static struct clk per_32k_alwon_fck = {
static struct clk gpio6_dbck = {
.name = gpio6_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO6_SHIFT,
@@ -2437,7 +2437,7 @@ static struct clk gpio6_dbck = {
static struct clk gpio5_dbck = {
.name = gpio5_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO5_SHIFT,
@@ -2447,7 +2447,7 @@ static struct clk gpio5_dbck = {
static struct clk gpio4_dbck = {
.name = gpio4_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO4_SHIFT,
@@ -2457,7 +2457,7 @@ static struct clk gpio4_dbck = {
static struct clk gpio3_dbck = {
.name = gpio3_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO3_SHIFT,
@@ -2467,7 +2467,7 @@ static struct clk gpio3_dbck = {
static struct clk gpio2_dbck = {
.name = gpio2_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO2_SHIFT,
--
1.6.3.rc1.51.gea0b7
--
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: LDP support
* Russell King - ARM Linux li...@arm.linux.org.uk [090505 12:52]: On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [090428 15:07]: Tony, et.al., Any ideas when more LDP support will be pushed into mainline (such as the framebuffer support)? I'll be looking at the board-*.c patches for the next merge window hopefully this week or next week. Looks like LDP keyboard, touchscreen RTC are pretty much ready to go. Then the MMC has some regulator updates, but AFAIK the MMC should work OK already. For the framebuffer, Imre and Tomi know the status the best, so I've added them to Cc. Imre has been meaning to send a bunch of drivers/video/omap changes to the fbdev list for a while now and LDP framebuffer may depend on those. Imre, any news on the status of sending the fb patches upstream? Then there are the upcoming DSS patches from Tomi, but those still need some work before they're ready to go. Is there any news on this? Will we see more functional OMAP3 / LDP support queued for the next merge window? Yes fro the stuff listed above, but still no news on the framebuffer patches. Imre? 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] input: Add support for the TSC2003 controller.
Hi Thierry,
On Mon, May 4, 2009 at 11:57 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Trilok Soni wrote:
Hi Thierry,
On Mon, May 4, 2009 at 5:07 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Kwangwoo Lee wrote:
Hi Thierry and Trilok,
On Wed, Apr 29, 2009 at 10:23 PM, Trilok Soni soni.tri...@gmail.com
wrote:
Hi Thierry,
I have added linux-omap community. How different is this chip from
tsc2007. It looks to me that this chip is not much different from
tsc2007 (this is just quick look at the driver). If they
are similar please consider using i2c_device_id feature in tsc2007 to
accommodate this chip.
I agree with the Trilok's opinion.
[snip]
I only noticed the tsc2007 driver some time ago, when the tsc2003 was
already
finished (it's actually pretty old, I just never got around to submitting
it). However I never got the tsc2007 to work on my platform because it uses
sleeping functions inside the timer handler, which results in an oops right
after the first touchscreen interrupt.
I guess I could try and fix the tsc2007 properly instead of having a
second,
pretty similar driver in the tree.
This could be because of improper locking? If you share a crash we can
have look at it.
Attached is a patch that fixes things for me. The problem was that the I2C
transfers were done in interrupt context which fails for the controller I use
(PXA270). The attached patch uses a struct work_struct to schedule the I2C
transfers so they are executed in non-interrupt context.
Thanks for the patch. It looks good. :)
The code in the patch is already merged in the main kernel tree.
@@ -235,7 +245,7 @@ static irqreturn_t tsc2007_irq(int irq, void *handle)
spin_lock_irqsave(ts-lock, flags);
if (likely(ts-get_pendown_state())) {
- disable_irq(ts-irq);
+ disable_irq_nosync(ts-irq);
hrtimer_start(ts-timer, ktime_set(0, TS_POLL_DELAY),
HRTIMER_MODE_REL);
}
Thanks.
I've tested the patch on a minimal system with tslib and it work fine with
ts_calibrate and friends.
Thierry
--
Kwangwoo Lee kwangwoo@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] input: Add support for the TSC2003 controller.
Hi, On Tue, May 5, 2009 at 2:21 AM, Trilok Soni soni.tri...@gmail.com wrote: Hi Therry, On Mon, May 4, 2009 at 8:27 PM, Thierry Reding thierry.red...@avionic-design.de wrote: * Trilok Soni wrote: Hi Thierry, On Mon, May 4, 2009 at 5:07 PM, Thierry Reding thierry.red...@avionic-design.de wrote: * Kwangwoo Lee wrote: Hi Thierry and Trilok, On Wed, Apr 29, 2009 at 10:23 PM, Trilok Soni soni.tri...@gmail.com wrote: Hi Thierry, I have added linux-omap community. How different is this chip from tsc2007. It looks to me that this chip is not much different from tsc2007 (this is just quick look at the driver). If they are similar please consider using i2c_device_id feature in tsc2007 to accommodate this chip. I agree with the Trilok's opinion. [snip] I only noticed the tsc2007 driver some time ago, when the tsc2003 was already finished (it's actually pretty old, I just never got around to submitting it). However I never got the tsc2007 to work on my platform because it uses sleeping functions inside the timer handler, which results in an oops right after the first touchscreen interrupt. I guess I could try and fix the tsc2007 properly instead of having a second, pretty similar driver in the tree. This could be because of improper locking? If you share a crash we can have look at it. Attached is a patch that fixes things for me. The problem was that the I2C transfers were done in interrupt context which fails for the controller I use (PXA270). The attached patch uses a struct work_struct to schedule the I2C transfers so they are executed in non-interrupt context. I've tested the patch on a minimal system with tslib and it work fine with ts_calibrate and friends. Thanks for the patch. It looks good. Let's wait for Kwangwoo Lee to verify it on his platform. Also please add tsc2003 entry into i2c_device_ids so that i2c_board_info can specify the .name as tsc2003. I tested the patch in my platform with tslib. And it looks good. Thanks, -- Kwangwoo Lee kwangwoo@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: Beep sound in the end of audio file
Hello, On Tuesday 05 May 2009 20:03:57 ext Aggarwal, Anuj wrote: Hi, After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help. Any idea how this can be avoided? I have not heard from this kind of problem so far, which does not mean, that it does not exist ;) Can you describe the beep sound? After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree? Does the beep happens in these cases also (after stopping it with Ctrl+C): aplay -f dat /dev/zero aplay -f dat /dev/urandom CC-ing alsa-devel... Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated -- Péter -- 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/6] omap iommu: tlb and pagetable primitives
Hi Hari,
From: ext Kanigeri, Hari h-kanige...@ti.com
Subject: RE: [PATCH 1/6] omap iommu: tlb and pagetable primitives
Date: Tue, 5 May 2009 22:19:55 +0200
Hi Doyu-san,
+static void iotlb_lock_set(struct iommu *obj, struct iotlb_lock *l) {
+ u32 val;
+
+ BUG_ON(l-base != 0); /* Currently no preservation is used */
-- Did you notice any issues in the IOMMU driver by enabling the
preservation?
Bridge driver is locking the memory segment that is used for IPC in
the TLB and by not having the preservation we might see a hit in the
performance.
The current user of this driver is camera isp and no need for tlb
preservation for it, but it's on todo list for other clients.
--
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
