Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
From: ext Felipe Contreras felipe.contre...@gmail.com
Subject: Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
Date: Tue, 5 May 2009 21:32:34 +0200
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?
Working around is easy, but let's go forward, correcting TI's bridgedriver;-)
http://marc.info/?l=linux-omapm=124148814309478w=2
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: [PATCH] input: Add support for the TSC2003 controller.
* Kwangwoo Lee wrote:
[...]
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);
}
Oh, I hadn't noticed. I diffed against 2.6.30-rc4. Do you want me to send a
new patch or will you just rip that piece out?
Thierry
--
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.
On Wed, May 6, 2009 at 3:45 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Kwangwoo Lee wrote:
[...]
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);
}
Oh, I hadn't noticed. I diffed against 2.6.30-rc4. Do you want me to send a
new patch or will you just rip that piece out?
Send fixed patch with your Signed-off-by line.
--
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] OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA
On Tue, May 5, 2009, Jarkko Lavinen wrote: 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 I discovered this while doing MMC writes. I did not check if there was any difference during a read. I notice you have only tested with MMC reads. Here's what I get with and without the patch. - Anand Without patch / # mount -t vfat /dev/mmcblk0 /mnt/mmc / # cat /proc/interrupts | grep mmc 83: 90INTC mmc0 384: 1 twl4030 mmc0 / # dd if=/dev/zero of=/mnt/mmc/32kbs.txt bs=32k count=1000 1000+0 records in 1000+0 records out / # cat /proc/interrupts | grep mmc 83: 3760INTC mmc0 384: 1 twl4030 mmc0 / # dd if=/dev/zero of=/mnt/mmc/1Mbs.txt bs=1M count=32 32+0 records in 32+0 records out / # cat /proc/interrupts | grep mmc 83: 7570INTC mmc0 384: 1 twl4030 mmc0 / # ls -l /mnt/mmc -rwxr-xr-x1 root root 33554432 Dec 31 18:03 1Mbs.txt -rwxr-xr-x1 root root 32768000 Dec 31 18:03 32kbs.txt / # umount /mnt/mmc With patch / # mount -t vfat /dev/mmcblk0 /mnt/mmc / # cat /proc/interrupts | grep mmc 83: 67INTC mmc0 384: 0 twl4030 mmc0 / # dd if=/dev/zero of=/mnt/mmc/32kbs.txt bs=32k count=1000 1000+0 records in 1000+0 records out / # cat /proc/interrupts | grep mmc 83: 3103INTC mmc0 384: 0 twl4030 mmc0 / # dd if=/dev/zero of=/mnt/mmc/1Mbs.txt bs=1M count=32 32+0 records in 32+0 records out / # cat /proc/interrupts | grep mmc 83: 6170INTC mmc0 384: 0 twl4030 mmc0 / # ls -l /mnt/mmc -rwxr-xr-x1 root root 33554432 Dec 31 18:01 1Mbs.txt -rwxr-xr-x1 root root 32768000 Dec 31 18:00 32kbs.txt / # umount /mnt/mmc-- 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.
* Kwangwoo Lee wrote:
On Wed, May 6, 2009 at 3:45 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Kwangwoo Lee wrote:
[...]
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);
}
Oh, I hadn't noticed. I diffed against 2.6.30-rc4. Do you want me to send a
new patch or will you just rip that piece out?
Send fixed patch with your Signed-off-by line.
Attached is the previous patch with said change removed.
Thierry
From: Thierry Reding thierry.red...@avionic-design.de
Subject: [PATCH] tsc2007: Fix for I2C controllers that sleep during transfers.
This patch fixes the tsc2007 driver with I2C controllers that sleep during
transfers. By moving the critical code to a workqueue, I2C transfers can be
scheduled to run in non-interrupt context.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/input/touchscreen/tsc2007.c | 23 +--
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index 4ab0702..2939355 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -70,6 +70,7 @@ struct ts_event {
struct tsc2007 {
struct input_dev *input;
char phys[32];
+ struct work_struct work;
struct hrtimer timer;
struct ts_event tc;
@@ -173,6 +174,9 @@ static void tsc2007_send_event(void *tsc)
dev_dbg(ts-client-dev, point(%4d,%4d), pressure (%4u)\n,
x, y, rt);
+ } else {
+ if (!ts-pendown)
+ ts-pendown = 1;
}
hrtimer_start(ts-timer, ktime_set(0, TS_POLL_PERIOD),
@@ -197,11 +201,19 @@ static int tsc2007_read_values(struct tsc2007 *tsc)
return 0;
}
+static void tsc2007_work(struct work_struct *work)
+{
+ struct tsc2007 *ts = container_of(work, struct tsc2007, work);
+ tsc2007_read_values(ts);
+ tsc2007_send_event(ts);
+}
+
static enum hrtimer_restart tsc2007_timer(struct hrtimer *handle)
{
struct tsc2007 *ts = container_of(handle, struct tsc2007, timer);
+ unsigned long flags = 0;
- spin_lock_irq(ts-lock);
+ spin_lock_irqsave(ts-lock, flags);
if (unlikely(!ts-get_pendown_state() ts-pendown)) {
struct input_dev *input = ts-input;
@@ -217,12 +229,10 @@ static enum hrtimer_restart tsc2007_timer(struct hrtimer *handle)
} else {
/* pen is still down, continue with the measurement */
dev_dbg(ts-client-dev, pen is still down\n);
-
- tsc2007_read_values(ts);
- tsc2007_send_event(ts);
+ schedule_work(ts-work);
}
- spin_unlock_irq(ts-lock);
+ spin_unlock_irqrestore(ts-lock, flags);
return HRTIMER_NORESTART;
}
@@ -252,7 +262,7 @@ static int tsc2007_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct tsc2007 *ts;
- struct tsc2007_platform_data *pdata = pdata = client-dev.platform_data;
+ struct tsc2007_platform_data *pdata = client-dev.platform_data;
struct input_dev *input_dev;
int err;
@@ -279,6 +289,7 @@ static int tsc2007_probe(struct i2c_client *client,
hrtimer_init(ts-timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
ts-timer.function = tsc2007_timer;
+ INIT_WORK(ts-work, tsc2007_work);
spin_lock_init(ts-lock);
--
tg: (091438d..) adx/input/tsc2007 (depends on: adx/master)
Incorporating linux-omap-pm patches into the linux-omap-2.6 mainline
Hi, I've found a linux-omap-pm git repository that has some active development going on for OMAP3 power management. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm/git There are 2 branches, pm and pm-next that contain a lot of new OMAP3 specific power management patches. When will these new features get incorporated into the linux-omap-2.6 mainline? Will it come as part of a new kernel release, say linux-omap3-2.6.30 ? Best regards, Elvis -- 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] [PATCH] twl4030: Add some error checking to twl4030 init
Check for return values of i2c read/write operations and size of scripts being
uploaded to TWL4030
(Removed the unrelated string changes based on David Brownell's comment)
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
drivers/mfd/twl4030-power.c | 52 +++---
1 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9dc493b..8f5d149 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -257,36 +257,40 @@ static int __init config_warmreset_sequence(u8 address)
return err;
}
-void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
{
int rconfig_addr;
+ int err;
u8 type;
if (rconfig-resource NUM_OF_RESOURCES) {
printk(KERN_ERR
TWL4030 Resource %d does not exist\n,
rconfig-resource);
- return;
+ return -EINVAL;
}
rconfig_addr = res_config_addrs[rconfig-resource];
/* Set resource group */
-
if (rconfig-devgroup = 0)
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
rconfig-devgroup 5,
rconfig_addr + DEVGROUP_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR
+ TWL4030 failed to program devgroup);
+ return err;
+ }
/* Set resource types */
-
- if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
- type,
- rconfig_addr + TYPE_OFFSET) 0) {
+ err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, type,
+ rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
printk(KERN_ERR
- TWL4030 Resource %d type could not read\n,
- rconfig-resource);
- return;
+ TWL4030 Resource %d type could not be read\n,
+ rconfig-resource);
+ return err;
}
if (rconfig-type = 0) {
@@ -299,8 +303,15 @@ void twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
type |= rconfig-type2 3;
}
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
type, rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR
+ TWL4030 failed to program resource type);
+ return err;
+ }
+
+ return 0;
}
@@ -309,6 +320,12 @@ static int __init load_triton_script(struct twl4030_script
*tscript)
u8 address = triton_next_free_address;
int err;
+ /* Make sure the script isn't going beyond last valid address */
+ if ((address + tscript-size) (END_OF_SCRIPT-1)) {
+ printk(KERN_ERR TWL4030 script too big error\n);
+ return -EINVAL;
+ }
+
err = twl4030_write_script(address, tscript-script, tscript-size);
if (err)
return err;
@@ -346,15 +363,22 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
for (i = 0; i triton2_scripts-size; i++) {
err = load_triton_script(triton2_scripts-scripts[i]);
- if (err)
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to load scripts);
break;
+ }
}
resconfig = triton2_scripts-resource_config;
if (resconfig) {
while (resconfig-resource) {
- twl4030_configure_resource(resconfig);
+ err = twl4030_configure_resource(resconfig);
resconfig++;
+ if (err 0) {
+ printk(KERN_ERR
+ TWL4030 failed to configure resource);
+ break;
+ }
}
}
--
1.6.0.4
--
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
-Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Wednesday, May 06, 2009 11:03 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org Subject: 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? [Aggarwal, Anuj] It's kind of a tuck sound coming in the end, after 1 or 2 seconds. After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree? [Aggarwal, Anuj] No, it is not. Reason being we already have beagle sdp3430 there, which are both similar to omap3evm, which I pushed. So mine got rejected. We had some discussions on how to handle this scenario but nothing got finalized. Does the beep happens in these cases also (after stopping it with Ctrl+C): aplay -f dat /dev/zero aplay -f dat /dev/urandom [Aggarwal, Anuj] Yes, it comes in both the cases. 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: [alsa-devel] Beep sound in the end of audio file
On Wed, May 6, 2009 at 1:33 AM, Peter Ujfalusi peter.ujfal...@nokia.com wrote: 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 I'm having this problem on PowerPC Audio is played via multiple period buffers Am interrupt is generated on the end of each period The problem occurs at the end of the stream. The period containing the end of stream plays and generates an interrupt. ALSA then calls back with trigger(STOP) But I can't shut off the DMA fast enough on these slower CPUs (not 3Ghz) to prevent the next period from starting to play. This next period contains data from earlier in the stream. When a small amount of it plays it sounds like a short tone beep. The beep is only obvious if the last period being played mostly contains silence. In that case the silence will play, then you will be able to hear the burst of noise separated from the rest of the stream. What I need to know is the address of the last valid sample in the stream. If I knew that I could just program the DMA hardware to stop after it played. I've been staring at ALSA core for a couple of days trying to figure out how to get the address for the end of the stream. CC-ing alsa-devel... Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated -- Péter ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- Jon Smirl jonsm...@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: [alsa-devel] Beep sound in the end of audio file
On Wed, May 6, 2009 at 10:01 AM, Jon Smirl jonsm...@gmail.com wrote: On Wed, May 6, 2009 at 1:33 AM, Peter Ujfalusi peter.ujfal...@nokia.com wrote: 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 I'm having this problem on PowerPC Audio is played via multiple period buffers Am interrupt is generated on the end of each period The problem occurs at the end of the stream. The period containing the end of stream plays and generates an interrupt. ALSA then calls back with trigger(STOP) But I can't shut off the DMA fast enough on these slower CPUs (not 3Ghz) to prevent the next period from starting to play. This next period contains data from earlier in the stream. When a small amount of it plays it sounds like a short tone beep. The beep is only obvious if the last period being played mostly contains silence. In that case the silence will play, then you will be able to hear the burst of noise separated from the rest of the stream. PS - a simple way to see if this is your problem. In the ISR memset the buffer that just finished playing to zero. That will make the problem go away since the stale data is now just silence. What I need to know is the address of the last valid sample in the stream. If I knew that I could just program the DMA hardware to stop after it played. I've been staring at ALSA core for a couple of days trying to figure out how to get the address for the end of the stream. CC-ing alsa-devel... Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated -- Péter ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- Jon Smirl jonsm...@gmail.com -- Jon Smirl jonsm...@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: [alsa-devel] Beep sound in the end of audio file
On Wed, May 06, 2009 at 07:30:03PM +0530, Aggarwal, Anuj wrote: After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree? [Aggarwal, Anuj] No, it is not. Reason being we already have beagle sdp3430 there, which are both similar to omap3evm, which I pushed. So mine got rejected. We had some discussions on how to handle this scenario but nothing got finalized. Not from the ALSA side it didn't... -- 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 2/6] omap iommu: omap2 architecture specific functions
Hi,
+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 (stat (1 i))
+ printk(%s , err_msg[i]);
+ }
+ printk(\n);
+
+ iommu_write_reg(obj, stat, MMU_IRQSTATUS);
+ return stat;
+}
+
-- I see you are acking the MMU fault in the ISR, but I don't think this will
be enough to stop the further generation of MMU faults as the device will again
try to access the same fault address.
In the mean time before the callback mechanism is implemented, we should
consider disabling the MMU for the device that caused the MMU fault to stop
further generation of MMU faults.
+ printk(\n);
+
+ iommu_write_reg(obj, stat, MMU_IRQSTATUS);
+ omap2_iommu_disable(obj) --- [HK]
+ return stat;
+}
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
Re: [PATCH 0/7] Generic gpmc-onenand initialization, v3
* Tony Lindgren t...@atomide.com [090504 17:25]:
Hi all,
Here's the whole series one more time, looks like I missed Juha
from the recipients originally. After all it's mostly Juha's
code! :)
To recap, this series creates a generic gpmc-onenand.c out of the
board-n800-flash.c so we can get this init code to the mainline
kernel. This series is against the linux-omap tree, the patch
against the mainline tree will be posted later.
Pushing this series to linux-omap tree today.
Regards,
Tony
---
Tony Lindgren (7):
onenand_init: Clean-up for checkpatch.pl
onenand init: Convert omap3430sdp to use gpmc-onenand
onenand_init: Allow disabling sync read and write based on flags, v3
onenand init: Pass configuration data from board-*.c files
onenand init: Rename n800_* functions to gpmc_onenand_* functions
onenand init: Build gpmc-onenand.o based on CONFIG_MTD_ONENAND_OMAP2
onenand init: Rename board-n800-flash.c to gpmc-onenand.c
arch/arm/mach-omap2/Makefile |7 +-
arch/arm/mach-omap2/board-3430sdp-flash.c| 28 ---
arch/arm/mach-omap2/board-n800.c | 50
arch/arm/mach-omap2/board-rx51-flash.c | 21 -
arch/arm/mach-omap2/board-rx51-peripherals.c | 47
arch/arm/mach-omap2/board-rx51.c |2
arch/arm/mach-omap2/gpmc-onenand.c | 105
--
arch/arm/plat-omap/include/mach/board.h |8 --
arch/arm/plat-omap/include/mach/onenand.h| 29 +++
9 files changed, 177 insertions(+), 120 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-rx51-flash.c
rename arch/arm/mach-omap2/{board-n800-flash.c = gpmc-onenand.c} (78%)
--
Signature
--
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
[APPLIED] [PATCH] OMAP clock: GPIO de-bounce clocks don#39;t affect module idle
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 2489dcb52022e4a8d2747e7c18c844cd139610c6 PatchWorks http://patchwork.kernel.org/patch/21946/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2489dcb52022e4a8d2747e7c18c844cd139610c6 -- 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 (V2)] TVP514x: Migration to sub-device framework
From: Vaibhav Hiremath hvaib...@ti.com
This patch converts TVP514x driver to sub-device framework
from V4L2-int framework.
NOTE: Please note that this patch has not been tested on any board,
only compilation/build tested.
Changes (From Previous post):
- Added static function to_decoder which will replace all
container_of instances.
- unsigned int replaced with u32.
- Cleaned up for line indentation.
- pdata initialized, was missing in earlier patch.
TODO:
- Add support for some basic video/core functionality like,
.g_chip_ident
.reset
.g_input_status
- Migration master driver to validate this driver.
- validate on Davinci and OMAP boards.
Reviewed By Hans Verkuil.
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/tvp514x.c | 854 ++--
drivers/media/video/tvp514x_regs.h | 10 -
include/media/tvp514x.h|4 -
3 files changed, 330 insertions(+), 538 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4262e60..12b49ad 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -31,7 +31,11 @@
#include linux/i2c.h
#include linux/delay.h
#include linux/videodev2.h
-#include media/v4l2-int-device.h
+
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
#include media/tvp514x.h
#include tvp514x_regs.h
@@ -49,13 +53,13 @@ static int debug;
module_param(debug, bool, 0644);
MODULE_PARM_DESC(debug, Debug level (0-1));
-#define dump_reg(client, reg, val) \
+#define dump_reg(sd, reg, val) \
do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, Reg(0x%.2X): 0x%.2X\n, reg, val); \
+ val = tvp514x_read_reg(sd, reg);\
+ v4l2_info(sd, Reg(0x%.2X): 0x%.2X\n, reg, val); \
} while (0)
-/**
+/*
* enum tvp514x_std - enum for supported standards
*/
enum tvp514x_std {
@@ -64,15 +68,7 @@ enum tvp514x_std {
STD_INVALID
};
-/**
- * enum tvp514x_state - enum for different decoder states
- */
-enum tvp514x_state {
- STATE_NOT_DETECTED,
- STATE_DETECTED
-};
-
-/**
+/*
* struct tvp514x_std_info - Structure to store standard informations
* @width: Line width in pixels
* @height:Number of active lines
@@ -87,35 +83,29 @@ struct tvp514x_std_info {
};
static struct tvp514x_reg tvp514x_reg_list_default[0x40];
-/**
+/*
* struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
* @tvp514x_regs: copy of hw's regs with preset values.
* @pdata: Board specific
- * @client: I2C client data
- * @id: Entry from I2C table
* @ver: Chip version
- * @state: TVP5146/47 decoder state - detected or not-detected
+ * @state: TVP5146/47 decoder state - enabled or disabled.
* @pix: Current pixel format
* @num_fmts: Number of formats
* @fmt_list: Format list
* @current_std: Current standard
* @num_stds: Number of standards
* @std_list: Standards list
- * @route: input and output routing at chip level
+ * @input: Input routing at chip level
+ * @output: Output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device v4l2_int_device;
- struct v4l2_int_slave tvp514x_slave;
+ struct v4l2_subdev sd;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
- struct i2c_client *client;
-
- struct i2c_device_id *id;
int ver;
- enum tvp514x_state state;
+ int state;
struct v4l2_pix_format pix;
int num_fmts;
@@ -124,8 +114,11 @@ struct tvp514x_decoder {
enum tvp514x_std current_std;
int num_stds;
struct tvp514x_std_info *std_list;
-
- struct v4l2_routing route;
+ /*
+* Input and Output Routing parameters
+*/
+ u32 input;
+ u32 output;
};
/* TVP514x default register values */
@@ -191,7 +184,8 @@ static struct tvp514x_reg tvp514x_reg_list_default[] = {
{TOK_TERM, 0, 0},
};
-/* List of image formats supported by TVP5146/47 decoder
+/*
+ * List of image formats supported by TVP5146/47 decoder
* Currently we are using 8 bit mode only, but can be
* extended to 10/20 bit mode.
*/
@@ -240,35 +234,27 @@ static struct tvp514x_std_info tvp514x_std_list[] = {
},
/* Standard: need to add for additional standard */
};
-/*
- * Control structure for Auto Gain
- * This is temporary data, will get replaced once
- * v4l2_ctrl_query_fill supports it.
- */
[PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
* Tony Lindgren t...@atomide.com [090505 21:00]: * 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? Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to add fb support for LDP. I don't have an LDP, maybe you guys can give it a try against the mainline kernel and see if it works! There might be some changes needed to drivers/video/omap/dispc.c too.. And those should be handled by Imre. But if this works, at least we can then add support for few more boards easily while waiting for Imre to send his updates. Cheers, Tony commit 6ceeed27b64fab326963a8a867c7549443e7536e Author: Stanley Miao stanley.m...@windriver.com Date: Wed May 6 15:09:35 2009 -0700 OMAP_LDP: Support LCD display as a FB device on ZOOM MDK Add glue to control the OMAP_LDP LCD as a frame buffer device using the existing dispc.c driver under omapfb. Patch updated for mainline kernel. Note that the drivers/video/omap should be updated to pass omap_lcd_config in platform_data. The patch should also be updated to compile if twl4030 is not selected, and eventually to use the regulator framework. Signed-off-by: Stanley.Miao stanley.m...@windriver.com Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig index 679a4a3..8a979cd 100644 --- a/arch/arm/configs/omap_ldp_defconfig +++ b/arch/arm/configs/omap_ldp_defconfig @@ -685,11 +685,16 @@ CONFIG_GPIOLIB=y # CONFIG_GPIO_SYSFS is not set # +# Memory mapped GPIO expanders: +# + +# # I2C GPIO expanders: # # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set +CONFIG_GPIO_TWL4030=y # # PCI GPIO expanders: @@ -740,12 +745,19 @@ CONFIG_SSB_POSSIBLE=y # # CONFIG_MFD_CORE is not set # CONFIG_MFD_SM501 is not set +# CONFIG_MFD_ASIC3 is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set +# CONFIG_TPS65010 is not set +CONFIG_TWL4030_CORE=y # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC6387XB is not set # CONFIG_MFD_TC6393XB is not set +# CONFIG_PMIC_DA903X is not set +# CONFIG_MFD_WM8400 is not set +# CONFIG_MFD_WM8350_I2C is not set +# CONFIG_MFD_PCF50633 is not set # # Multimedia devices @@ -767,8 +779,45 @@ CONFIG_DAB=y # # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=m -# CONFIG_FB is not set -# CONFIG_BACKLIGHT_LCD_SUPPORT is not set +CONFIG_FB=y +CONFIG_FIRMWARE_EDID=y +# CONFIG_FB_DDC is not set +# CONFIG_FB_BOOT_VESA_SUPPORT is not set +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set +# CONFIG_FB_SYS_FILLRECT is not set +# CONFIG_FB_SYS_COPYAREA is not set +# CONFIG_FB_SYS_IMAGEBLIT is not set +# CONFIG_FB_FOREIGN_ENDIAN is not set +# CONFIG_FB_SYS_FOPS is not set +# CONFIG_FB_SVGALIB is not set +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +CONFIG_FB_MODE_HELPERS=y +CONFIG_FB_TILEBLITTING=y + +# +# Frame buffer hardware drivers +# +# CONFIG_FB_S1D13XXX is not set +# CONFIG_FB_VIRTUAL is not set +# CONFIG_FB_METRONOME is not set +CONFIG_FB_OMAP=y +CONFIG_FB_OMAP_LCD_VGA=y +# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set +# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set +CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=4 +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +# CONFIG_LCD_LTV350QV is not set +# CONFIG_LCD_ILI9320 is not set +# CONFIG_LCD_TDO24M is not set +# CONFIG_LCD_VGG2432A4 is not set +CONFIG_LCD_PLATFORM=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y +# CONFIG_BACKLIGHT_CORGI is not set # # Display device support @@ -780,6 +829,16 @@ CONFIG_VIDEO_OUTPUT_CONTROL=m # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y
Re: Beagleboard rev C memory timings suspend/resume
Hello Jean, sorry about the delay, On Wed, 29 Apr 2009, Jean Pihet wrote: The suspend/resume on Beagleboard has some problem due to bad memory timings. Suspending for more than 5 to 10 seconds shows memory corruption. The new chips on rev Cx boards are using 2 DDR chip selects and it looks like the 2nd memory part is not correctly put into self refresh. As an experimentation I tried the same kernel with 'mem=128M' and it resumes correctly after 1 min in suspend. Nice work, this seems likely to be the cause. I could not find the latest DDR detailed specs from Micron. The part number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this part identical to 2 1Gb parts? The combined part's web page is: http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20IT The SDRAM datasheet is the same that is used for all the other Micron parts that we've run across so far: http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdram_t48m.pdf Now for the code in the kernel, there are some changes needed to support 2 CS'es: - the SDRC parameters need to be updated for the new memory part - the SDRC parameters need to include the ACTIM_CTRL_A_0, ACTIM_CTRL_A_1, ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and RFR_CTRL_1 registers. Since the parameters for the 2nd CS are the same, this can be avoided by writing the same values to the 2 sets of registers - is there a need to differentiate between 1Gb and 2Gb chips, or can we just write the same params for both CS'es even if only one is being used? - the 'configure_sdrc' function in arch/arm/mach-omap2/sram34xx.S needs to program the 2 sets of registers. Here is a patch excerpt below. This patch only does not help the suspend/resume though. Any idea or suggestion? Looks like a good start. Since the two SDRC chip-selects can technically address parts with different timings, we should not assume that the two chip selects will be the same. Admittedly this seems like an unlikely situation, but it's not impossible for non-POP OMAPs. Re: suspend/resume, if you're talking about the code in sleep34xx.S, it looks like this is already in good shape. Re: board SDRC changes: would suggest modifying omap2_sdrc_init() to take either two struct omap_sdrc_params pointers, or one struct with two pointers. omap2_init_common_hw() will also need to be updated for that, and all of the board-*.c files also. Sound reasonable? ldr r11, omap3_sdrc_mr_0 str r6, [r11] ldr r6, [r11] @ posted-write barrier for SDRC + ldr r11, omap3_sdrc_mr_1 + str r6, [r11] + ldr r6, [r11] @ posted-write barrier for SDRC bx lr By the way, there's no need to duplicate the posted-write barrier. There should only be one, appearing right before the 'bx lr'. regards, - 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
[PATCH] rtc: rtc-twl4030 don't mask alarm interrupts on suspend
Hi All,
This patch was originally sent to linux-omap mailing list.
(Please refer to http://markmail.org/thread/o643d7w224zo3i7n)
David Brownell said, if I've tested this:
Acked-by: David Brownell dbrown...@users.sourceforge.net
Of course, I've tested.
Regards,
Kyuwon
--
From: Kim Kyuwon q1@samsung.com
Subject: [PATCH] rtc: rtc-twl4030 don't mask alarm interrupts on suspend
This patch enables the alarm interrupt of TWL4030 RTC to wake up the
system from suspend. You can test this patch with following command.
# echo +10 /sys/class/rtc/rtc0/wakealarm; echo mem /sys/power/state;
Signed-off-by: Kim Kyuwon q1@samsung.com
---
drivers/rtc/rtc-twl4030.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-twl4030.c b/drivers/rtc/rtc-twl4030.c
index ad35f76..c185939 100644
--- a/drivers/rtc/rtc-twl4030.c
+++ b/drivers/rtc/rtc-twl4030.c
@@ -495,9 +495,7 @@ static int twl4030_rtc_suspend(struct platform_device
*pdev, pm_message_t state)
{
irqstat = rtc_irq_bits;
- /* REVISIT alarm may need to wake us from sleep */
- mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_TIMER_M |
-BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
+ mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_TIMER_M);
return 0;
}
--
1.5.2.5
--
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 the size of twl4030 script
Hi All,
I sent this patch about 1 month ago.
Can anybody check I'm sending correct patch?
Thanks you!
Kyuwon.
2009/4/10 Kim Kyuwon chamm...@gmail.com:
The array size of wrst_seq is ARRAY_SIZE(wrst_seq)
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 03acac7..38550e2 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -473,7 +473,7 @@ static struct twl4030_ins wrst_seq[] __initdata = {
};
static struct twl4030_script wrst_script __initdata = {
.script = wrst_seq,
- .size = ARRAY_SIZE(wakeup_seq),
+ .size = ARRAY_SIZE(wrst_seq),
.flags = TRITON_WRST_SCRIPT,
};
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 804fd8e..da814d7 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -450,7 +450,7 @@ static struct twl4030_ins wrst_seq[] __initdata = {
static struct twl4030_script wrst_script __initdata = {
.script = wrst_seq,
- .size = ARRAY_SIZE(wakeup_seq),
+ .size = ARRAY_SIZE(wrst_seq),
.flags = TRITON_WRST_SCRIPT,
};
--
1.5.2.5
--
Kyuwon (규원)
--
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] PM: suspend_device_irqs(): don't disable wakeup IRQs
2009/5/7 Arve Hjønnevåg a...@android.com: 2009/5/6 Kim Kyuwon chamm...@gmail.com: 2009/5/7 Arve Hjønnevåg a...@android.com: On Wed, May 6, 2009 at 5:16 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Rafael J. Wysocki r...@sisk.pl writes: On Wednesday 06 May 2009, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: There is at least one problem with that which is why Kyuwon Kim added the -disable hook to OMAP's irq_chip. The problem is with drivers that call disable_irq() in their suspend hook, usually done to prevent the device from waking the system since on OMAP, any IRQ can be configured to wake the system. This does not sound correct. disable_irq_wake should be used for this. A driver may need to mask its interrupt before suspending but this should not also disable it as a wakeup source. I wish I could use disable_irq_wake(), but it doesn't work in OMAP. This does not sound like a hardware problem. We may need advices of TI engineers. However, as far as I know, It is impossible to disable 'interrupt wake-up' with interrupt enabled. Because an interrupt itself generate a system wake-up event in OMAP3430 (Hardware level). -- Kyuwon -- Arve Hjønnevåg -- 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 2/6] omap iommu: omap2 architecture specific functions
From: ext Kanigeri, Hari h-kanige...@ti.com
Subject: RE: [PATCH 2/6] omap iommu: omap2 architecture specific functions
Date: Wed, 6 May 2009 16:31:37 +0200
Hi,
+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 (stat (1 i))
+ printk(%s , err_msg[i]);
+ }
+ printk(\n);
+
+ iommu_write_reg(obj, stat, MMU_IRQSTATUS);
+ return stat;
+}
+
-- I see you are acking the MMU fault in the ISR, but I don't think
this will be enough to stop the further generation of MMU faults as
the device will again try to access the same fault address.
My idea is that, an iommu fault should be handled by a client
specific/provided callback function enough flexibly that it can handle
more complecated use cases like implementing on-demand dynamic memory
mapping at getting an iommu fault.
linux/arch/arm/plat-omap/iommu.c:
+static irqreturn_t iommu_fault_handler(int irq, void *data)
+{
+ u32 stat, da;
+ u32 *iopgd, *iopte;
+ int err = -EIO;
+ struct iommu *obj = data;
+
+ if (!obj-refcount)
+ return IRQ_NONE;
+
+ /* Dynamic loading TLB or PTE */
+ if (obj-isr)
+ err = obj-isr(obj);
^^
If the above isr function sets a new tlb or pte entry, then
further iommu fault won't happen anymore.
In the mean time before the callback mechanism is implemented, we
should consider disabling the MMU for the device that caused the MMU
fault to stop further generation of MMU faults.
+ printk(\n);
+
+ iommu_write_reg(obj, stat, MMU_IRQSTATUS);
+ omap2_iommu_disable(obj) --- [HK]
+ return stat;
+}
It's not bad idea at all to disable iommu temporary as a default
behavior, but maybe it should be done in the latter half of
iommu_fault_handler().
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
Re: [PATCH] ARM: OMAP: Fix tusb6010 init error and compilation warning
On Thu, 23 Apr 2009 20:06:39 +0300 Kalle Valo kalle.v...@iki.fi wrote: Jarkko Nikula jarkko.nik...@nokia.com writes: Fix tusb6010 init error 5, -19 and compilation warning from function tusb6010_platform_retime warning: 'sysclk_ps' is used uninitialized in this function. I suppose commit c094ba34b8f780885d029ce3c2715a194b780e5d was meant to test for zero fclk_ps instead of sysclk_ps. I was suffering exactly this problem and this patch fixed it. Now usb network works again, thanks a lot for fixing this! Signed-off-by: Jarkko Nikula jarkko.nik...@nokia.com Cc: Roel Kluin roel.kl...@gmail.com Tested-by: Kalle Valo kalle.v...@iki.fi Ping? This patch was a fix for 2.6.30-rcX. -- 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: Beep sound in the end of audio file
On Wednesday 06 May 2009 17:19:49 ext Todd Fischer wrote: Hi, FWIW: while developing a GSTreamer presentation using a BegleBoard (rev C), I noticed the same tuck sound. It also occurs a second or two after the GST application exits. I assumed it was some power management code that was disabling the audio codec after it had gone idle, but never looked into it. BeagleBoard also uses TWL4030. GST command: gst-launch audiotestsrc freq=1000 num-buffers=100 ! alsasink /proc/version: Linux version 2.6.28-omap1 (ddo...@aleph) (gcc version 4.3.1 (GCC) ) #2 Thu Mar 5 08:55:58 CST 2009 The tuck is coming from the codec, when it is powered down (in the old twl4030 codec found in omap-2.6.28 branch of linux-omap). But, it still happens with the latest version, when the codec is muted only. I can observe the tuck on Headset output, but not on the PreDrive... The Headset enable and disable is implemented according to the TRM, but it seams that additional tweaking is needed.. -- 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
