RE: [PATCH] omap3: pm: cpufreq: populate l3 opp1 again
IMHO the best way to unconfuse readers is to remove the entry. The confusion is due to a mismatch between public TRM/white paper and current code, so maybe a simple comment on top of the omap34xx_l3_rate_table will be enough. But why do we want to keep an OPP that will never be used? -- 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/1] OMAP3: PM: Fix compilation issue of omap3_pm_init_opp_table
there are multiple ways to use SR - Not all of them can use OMAP chip registers. certain class of devices would need to use PMICs, Even then you do not need OPP layer. For PMIC based solutions you need to use I2C to get the voltage. So this should be abstracted. OPP layer is just for CPU FREQ. further SRF or it's equivalent will need to query the table for knowing what voltage corresponds to frequency, Why should you know the voltage for a frequency other than your current frequency when you do not scale the frequency of your CPU? Clock framework will give you the current freq. For voltage, we already discussed above. DSPBRidge needs to report to the baseimage what voltage corresponds to the frequency for the baseimage's load balancing/power decision logic etc.. in short when dynamic voltage scaling is needed, we need OPP layer a.k.a CONFIG_PM needs opp layer - not just cpufreq. Please understand CONFIG_PM is not for any kind of __cpufreq or dspfreq__. It is for suspend resume and few other stuff. So why should CONFIG_PM need OPP layer? -- Regards, Nishanth Menon-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-WIP-OPP] [PATCH 2/2]: Change return value from ERR_PTR(..) to NULL in opp layer
Returning NULL pointer from the OPP APIs instead of ERR_PTR where return struct omap_opp *. This is because there is no inherent value in returning ERR_PTR from the opp layer. Returning NULL serves the purpose. NAK. Using ERR_PTR allows returning different types of error conditions, and is common practice across the kernel. Yes, it is true that it is a common practice but in case of the OPP layer I did not see any purpose. The caller of the APIs returning struct omap_opp * can just check for NULL value for failure.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: PM: Dynamic calculation of SDRC clock stabilization delay
I tried to find the code in LO but I think it is not yet present. Right, it is still being discussed. So with that in mind may I propose that the pmc functions we introduce in plat-omap will be present as __init code (so that we ensure no one uses it after the system finishes booting up) as long as the pmc infrastructure is not available for non-Oprofile uses? Personally, I don't like this idea. IMHO, the PMC is not OMAP specific and does not belong in plat-omap even as init code. Either generalize and use existing PMC infrastructure, or use a different timer. Ftrace/Oprofile/Perf are all initialized later during the boot process. Actually if you see where we are using pmc it is in init_IRQ. So until the pmc libraries I think it would be fair to use it. I do not see any problem. Can you point out with any concrete code from the latest OMAP tree? You didn't answer my other question about whether or not a GPtimer could be used for this. You could quickly request/program/free a GPtimer for this too using the omap_dm_timer* API. May be possibe but IMHO it is ugly to setup and more complicated to use than the pmc approach. The other indirect way is like how bogomips is calculated. But that is a different story. We need accuracy in the delay and __may be__ interrupt latency would skew the results. If someone can implement it using Interrupt we would like to see how much access delay they get using irq technique. As I mentioned in an earlier thread, the pmc is used and stopped very early during the kernel boot and AFAICT there should not be any problem (probably we need to check its behavior on EMU/HS devices). This isn't very convicing. Also, it's not just oprofile we have to be worried about. The perf/trace infrastructure arm is also using the PMC. It will not be uncommon to use perf on early boot/init and the use of the PMC in this patch will clearly interfere with that. Wrong! See above. In summary, the PMC is a shared resource and should be treated as such using common code and common APIs. Where is it today? Thanks, -Romit-- 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/1] PM: Thaws refrigerated and to be exited kernel threads
Really? I believe the ktrhead_should_stop is new rule, and code does not seem to follow it. Actually, for example audit does not seem to use kthread_should_stop() at all... ./kernel/rtmutex-tester.c- ./kernel/rtmutex-tester.c-/* Wait for the next command to be executed */ ./kernel/rtmutex-tester.c-schedule(); ./kernel/rtmutex-tester.c:try_to_freeze(); ./kernel/rtmutex-tester.c- ./kernel/rtmutex-tester.c-if (signal_pending(current)) ./kernel/rtmutex-tester.c-flush_signals(current); -- Not a new rule. For these threads you listed no one stops them by sending 'kthread_stop' so the problem does not arise! But for the threads that are stopped by invoking kthread_stop they do check kthread_should_stop. -- 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/1] PM: Thaws refrigerated and to be exited kernel threads
-Original Message-
From: Pavel Machek [mailto:pa...@ucw.cz]
Sent: Sunday, November 08, 2009 1:57 PM
To: Dasgupta, Romit
Cc: Rafael J. Wysocki; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org;
linux...@lists.linux-foundation.org
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel
threads
On Sun 2009-11-08 09:52:52, Dasgupta, Romit wrote:
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel
threads
Hi!
Kicks out a frozen thread from the refrigerator when an active thread
has
invoked kthread_stop on the frozen thread.
...
@@ -49,7 +50,7 @@ void refrigerator(void)
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (!frozen(current))
+ if (!frozen(current) || (!current-mm
kthread_should_stop()))
break;
schedule();
Well, what if the thread does some processing before stopping? That
would break refrigerator assumptions...
The suspend thread will block until the 'to be stopped' thread clears up.
That is
what any call to kthread_stop would boil down to. The target thread would
anyway be out of the refrigerator so I am not sure what assumption you mean
here. Eventually, the target thread would clear up and wake up the suspend
thread and then things would go on as usual.
(Please format to 80 columns).
No, I do not get it.
Lets say we have
evil_data_writer thread that needs to be stopped becuase it writes to
filesystem
nofreeze random_stopper thread
now we create the suspend image, and start writing it out. But that's
okay, evil_data_writer is stopped so it can't do no harm. But now
random_stopper decides to thread_stop() the evil_data_writer, and this
new code allows it to exit the refrigerator, *do some writing*, and
then stop.
That's bad, right?
evil_data_writer will enter refrigerator after invoking 'try_to_freeze'. This
should be followed by a call to kthread_should_stop. There it decides if it
needs to exit the thread (after cleanups if necessary) or not. I have seen that
the bdi_writeback_task function is like that. It does not care if there is
pending data to be written if it detects that someone have invoked a
'kthread_stop' on it. It simply exits. I have seen some other kernel threads
that do not follow this and I think that probably is not right.
--
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/1] PM: Thaws refrigerated and to be exited kernel threads
(Resending with 80 column restriction)
-Original Message-
From: Pavel Machek [mailto:pa...@ucw.cz]
Sent: Sunday, November 08, 2009 1:57 PM
To: Dasgupta, Romit
Cc: Rafael J. Wysocki; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; linux...@lists.linux-foundation.org
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be
exited kernel threads
On Sun 2009-11-08 09:52:52, Dasgupta, Romit wrote:
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be
exited kernel
threads
Hi!
Kicks out a frozen thread from the refrigerator when an
active thread has
invoked kthread_stop on the frozen thread.
...
@@ -49,7 +50,7 @@ void refrigerator(void)
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (!frozen(current))
+ if (!frozen(current) || (!current-mm
kthread_should_stop()))
break;
schedule();
Well, what if the thread does some processing before
stopping? That
would break refrigerator assumptions...
The suspend thread will block until the 'to be stopped'
thread clears up. That is what any call to kthread_stop would
boil down to. The target thread would anyway be out of the
refrigerator so I am not sure what assumption you mean here.
Eventually, the target thread would clear up and wake up the
suspend thread and then things would go on as usual.
(Please format to 80 columns).
No, I do not get it.
Lets say we have
evil_data_writer thread that needs to be stopped becuase it writes to
filesystem
nofreeze random_stopper thread
now we create the suspend image, and start writing it out. But that's
okay, evil_data_writer is stopped so it can't do no harm. But now
random_stopper decides to thread_stop() the evil_data_writer, and this
new code allows it to exit the refrigerator, *do some writing*, and
then stop.
That's bad, right?
evil_data_writer will enter refrigerator after invoking 'try_to_freeze'. This
should be followed by a call to kthread_should_stop. There it decides if it
needs to exit the thread (after cleanups if necessary) or not. I have seen that
the bdi_writeback_task function is like that. It does not care if there is
pending data to be written if it detects that someone have invoked a
'kthread_stop' on it. It simply exits. I have seen some other kernel threads
that do not follow this and I think that probably is not right.
--
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/1] PM: Thaws refrigerated and to be exited kernel threads
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel
threads
Hi!
Kicks out a frozen thread from the refrigerator when an active thread has
invoked kthread_stop on the frozen thread.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/kernel/freezer.c b/kernel/freezer.c
index bd1d42b..c28dbe8 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -9,6 +9,7 @@
#include linux/module.h
#include linux/syscalls.h
#include linux/freezer.h
+#include linux/kthread.h
/*
* freezing is complete, mark current process as frozen
@@ -49,7 +50,7 @@ void refrigerator(void)
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (!frozen(current))
+ if (!frozen(current) || (!current-mm kthread_should_stop()))
break;
schedule();
Well, what if the thread does some processing before stopping? That
would break refrigerator assumptions...
The suspend thread will block until the 'to be stopped' thread clears up. That
is what any call to kthread_stop would boil down to. The target thread would
anyway be out of the refrigerator so I am not sure what assumption you mean
here. Eventually, the target thread would clear up and wake up the suspend
thread and then things would go on as usual.
--
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/1] PM: Thaws refrigerated and to be exited kernel threads
Hi, The following patch overcomes the issue when an active thread invokes kthread_stop on a refrigerated kernel thread. The active thread would block until the exiting kernel thread is cleaned up. If the exiting thread is in refrigerator it never cleans up and the caller blocks. I found the issue while trying out the following: 1) suspend and resume the system with an mmc card. 2) after resume mount a filesystem on the mmc card. 3) unmount the same filesystem. 4) One can see an active bdi thread in the system for the FS. 5) Attempted suspend on the system. This resulted in hang. Here was the dump from khungd # echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. mmc1: card 0001 removed mmc0: card 25b7 removed INFO: task sh:388 blocked for more than 120 seconds. echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. shD c027e86c 0 388 1 0x [c027e86c] (schedule+0x2e0/0x36c) from [c027ee78] (schedule_timeout+0x18/0x1ec) [c027ee78] (schedule_timeout+0x18/0x1ec) from [c027ed10] (wait_for_common+0xe0/0x198) [c027ed10] (wait_for_common+0xe0/0x198) from [c0063dd4] (kthread_stop+0x44/0x78) [c0063dd4] (kthread_stop+0x44/0x78) from [c0090938] (bdi_unregister+0x64/0xa4) [c0090938] (bdi_unregister+0x64/0xa4) from [c0173958] (unlink_gendisk+0x20/0x3c) [c0173958] (unlink_gendisk+0x20/0x3c) from [c00f2338] (del_gendisk+0x84/0xb4) [c00f2338] (del_gendisk+0x84/0xb4) from [c01e6840] (mmc_blk_remove+0x24/0x44) [c01e6840] (mmc_blk_remove+0x24/0x44) from [c01e14f0] (mmc_bus_remove+0x18/0x20) [c01e14f0] (mmc_bus_remove+0x18/0x20) from [c01af6ac] (__device_release_driver+0x64/0xa4) [c01af6ac] (__device_release_driver+0x64/0xa4) from [c01af7e4] (device_release_driver+0x1c/0x28) [c01af7e4] (device_release_driver+0x1c/0x28) from [c01aed5c] (bus_remove_device+0x7c/0x90) [c01aed5c] (bus_remove_device+0x7c/0x90) from [c01ad538] (device_del+0x110/0x160) [c01ad538] (device_del+0x110/0x160) from [c01e15a8] (mmc_remove_card+0x50/0x64) [c01e15a8] (mmc_remove_card+0x50/0x64) from [c01e2ea4] (mmc_sd_remove+0x24/0x30) [c01e2ea4] (mmc_sd_remove+0x24/0x30) from [c01e0dcc] (mmc_suspend_host+0x110/0x1a8) [c01e0dcc] (mmc_suspend_host+0x110/0x1a8) from [c01e7d04] (omap_hsmmc_suspend+0x74/0x104) [c01e7d04] (omap_hsmmc_suspend+0x74/0x104) from [c01b08e8] (platform_pm_suspend+0x50/0x5c) [c01b08e8] (platform_pm_suspend+0x50/0x5c) from [c01b27f0] (pm_op+0x30/0x74) [c01b27f0] (pm_op+0x30/0x74) from [c01b2ec8] (dpm_suspend_start+0x3b4/0x518) [c01b2ec8] (dpm_suspend_start+0x3b4/0x518) from [c0078b20] (suspend_devices_and_enter+0x3c/0x1c4) [c0078b20] (suspend_devices_and_enter+0x3c/0x1c4) from [c0078d88] (enter_state+0xe0/0x138) [c0078d88] (enter_state+0xe0/0x138) from [c0078444] (state_store+0x94/0xbc) [c0078444] (state_store+0x94/0xbc) from [c017e124] (kobj_attr_store+0x18/0x1c) [c017e124] (kobj_attr_store+0x18/0x1c) from [c00f3a08] (sysfs_write_file+0x108/0x13c) [c00f3a08] (sysfs_write_file+0x108/0x13c) from [c00a76b8] (vfs_write+0xac/0x154) [c00a76b8] (vfs_write+0xac/0x154) from [c00a780c] (sys_write+0x3c/0x68) [c00a780c] (sys_write+0x3c/0x68) from [c0025e60] (ret_fast_syscall+0x0/0x2c) Before the hang I did a ps and found the following the following bdi thread active 474 rootSW [flush-179:0] After applying the patch (patch in next email) I saw successful suspend and the offensive thread was cleaned up properly. Thanks, -Romit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
Kicks out a frozen thread from the refrigerator when an active thread has
invoked kthread_stop on the frozen thread.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/kernel/freezer.c b/kernel/freezer.c
index bd1d42b..c28dbe8 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -9,6 +9,7 @@
#include linux/module.h
#include linux/syscalls.h
#include linux/freezer.h
+#include linux/kthread.h
/*
* freezing is complete, mark current process as frozen
@@ -49,7 +50,7 @@ void refrigerator(void)
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
- if (!frozen(current))
+ if (!frozen(current) || (!current-mm kthread_should_stop()))
break;
schedule();
}
--
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/1] PM: Making bdi threads non-freezable
Hello all, For last few days I am facing an interesting suspend resume issue when I have a SD card inserted in a development platform. My kernel is built without CONFIG_MMC_UNSAFE_RESUME. (Most of the problems don't appear with CONFIG_MMC_UNSAFE_RESUME=y but that option seems to be not-recommended). When I try to issue system suspend (S2R) I can see that my shell is hung. Enabling CONFIG_DETECT_HUNG_TASK would reveal the following: # echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. platform_legacy_suspend(): serial8250_suspend+0x0/0x54 returns 1 mmc1: card 0001 removed platform_legacy_suspend(): omap_hsmmc_suspend+0x0/0x104 returns 1 mmc0: card 25b7 removed INFO: task sh:387 blocked for more than 120 seconds. echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. shD c027e89c 0 387 1 0x [c027e89c] (schedule+0x2e0/0x36c) from [c00c36e4] (bdi_sched_wait+0x8/0x10) [c00c36e4] (bdi_sched_wait+0x8/0x10) from [c027f24c] (__wait_on_bit+0x5c/0xa8) [c027f24c] (__wait_on_bit+0x5c/0xa8) from [c027f30c] (out_of_line_wait_on_bit+0x74/0x80) [c027f30c] (out_of_line_wait_on_bit+0x74/0x80) from [c00c3774] (sync_inodes_sb+0x88/0x178) [c00c3774] (sync_inodes_sb+0x88/0x178) from [c00c76e4] (__sync_filesystem+0x5c/0x88) [c00c76e4] (__sync_filesystem+0x5c/0x88) from [c00d02f0] (fsync_bdev+0x18/0x38) [c00d02f0] (fsync_bdev+0x18/0x38) from [c0174230] (invalidate_partition+0x18/0x34) [c0174230] (invalidate_partition+0x18/0x34) from [c00f22d8] (del_gendisk+0x24/0xb4) [c00f22d8] (del_gendisk+0x24/0xb4) from [c01e686c] (mmc_blk_remove+0x24/0x44) [c01e686c] (mmc_blk_remove+0x24/0x44) from [c01e151c] (mmc_bus_remove+0x18/0x20) [c01e151c] (mmc_bus_remove+0x18/0x20) from [c01af6ac] (__device_release_driver+0x64/0xa4) [c01af6ac] (__device_release_driver+0x64/0xa4) from [c01af7e4] (device_release_driver+0x1c/0x28) [c01af7e4] (device_release_driver+0x1c/0x28) from [c01aed5c] (bus_remove_device+0x7c/0x90) [c01aed5c] (bus_remove_device+0x7c/0x90) from [c01ad538] (device_del+0x110/0x160) [c01ad538] (device_del+0x110/0x160) from [c01e15d4] (mmc_remove_card+0x50/0x64) [c01e15d4] (mmc_remove_card+0x50/0x64) from [c01e2ed0] (mmc_sd_remove+0x24/0x30) [c01e2ed0] (mmc_sd_remove+0x24/0x30) from [c01e0df8] (mmc_suspend_host+0x110/0x1a8) [c01e0df8] (mmc_suspend_host+0x110/0x1a8) from [c01e7d30] (omap_hsmmc_suspend+0x74/0x104) [c01e7d30] (omap_hsmmc_suspend+0x74/0x104) from [c01b09bc] (platform_pm_suspend+0x60/0x8c) [c01b09bc] (platform_pm_suspend+0x60/0x8c) from [c01b2820] (pm_op+0x30/0x74) [c01b2820] (pm_op+0x30/0x74) from [c01b2ef8] (dpm_suspend_start+0x3b4/0x518) [c01b2ef8] (dpm_suspend_start+0x3b4/0x518) from [c0078b20] (suspend_devices_and_enter+0x3c/0x1c4) [c0078b20] (suspend_devices_and_enter+0x3c/0x1c4) from [c0078d88] (enter_state+0xe0/0x138) [c0078d88] (enter_state+0xe0/0x138) from [c0078444] (state_store+0x94/0xbc) [c0078444] (state_store+0x94/0xbc) from [c017e124] (kobj_attr_store+0x18/0x1c) [c017e124] (kobj_attr_store+0x18/0x1c) from [c00f3a08] (sysfs_write_file+0x108/0x13c) [c00f3a08] (sysfs_write_file+0x108/0x13c) from [c00a76b8] (vfs_write+0xac/0x154) [c00a76b8] (vfs_write+0xac/0x154) from [c00a780c] (sys_write+0x3c/0x68) [c00a780c] (sys_write+0x3c/0x68) from [c0025e60] (ret_fast_syscall+0x0/0x2c) A closer investigation showed that when this happens the 'bdi' tasks (i.e. forker and the individual flush kthreads) are already in the 'refrigerator' hence we are blocked. I made those tasks as non-freezable and things were fine until I hit yet another deeper issue. I have attached the patch for the first fix in the next part of the mail. The second problem shows up when I have filesystem(s) mounted on the MMC card and I try the following: 1) I successfully suspend/resume followed by 2) attempt to next suspend/resume cycle. This time again I get blocked. khungd outputs the following: INFO: task sh:387 blocked for more than 120 seconds. echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. shD c027e83c 0 387 1 0x [c027e83c] (schedule+0x2e0/0x36c) from [c00c36b0] (bdi_sched_wait+0x8/0x10) [c00c36b0] (bdi_sched_wait+0x8/0x10) from [c027f1ec] (__wait_on_bit+0x5c/0xa8) [c027f1ec] (__wait_on_bit+0x5c/0xa8) from [c027f2ac] (out_of_line_wait_on_bit+0x74/0x80) [c027f2ac] (out_of_line_wait_on_bit+0x74/0x80) from [c00c3740] (sync_inodes_sb+0x88/0x178) [c00c3740] (sync_inodes_sb+0x88/0x178) from [c00c76a8] (__sync_filesystem+0x5c/0x88) [c00c76a8] (__sync_filesystem+0x5c/0x88) from [c00c77a4] (sync_filesystems+0xd0/0x140) [c00c77a4] (sync_filesystems+0xd0/0x140) from [c00c7860] (sys_sync+0x1c/0x3c) [c00c7860] (sys_sync+0x1c/0x3c) from [c0078ce0] (enter_state+0x38/0x138) [c0078ce0] (enter_state+0x38/0x138) from [c0078444] (state_store+0x94/0xbc) [c0078444]
[PATCH 1/1] PM: Making bdi threads non-freezable
Fixes the case when bdi threads are in the refrigerator but file system sync can happen after this. This is possible in MMC when CONFIG_MMC_UNSAFE_RESUME is not set. Signed-off-by: Romit Dasgupta ro...@ti.com --- diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 9d5360c..661229d 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -956,7 +956,6 @@ int bdi_writeback_task(struct bdi_writeback *wb) wait_jiffies = msecs_to_jiffies(dirty_writeback_interval * 10); schedule_timeout_interruptible(wait_jiffies); - try_to_freeze(); } return 0; diff --git a/mm/backing-dev.c b/mm/backing-dev.c index 5a37e20..9383271 100644 --- a/mm/backing-dev.c +++ b/mm/backing-dev.c @@ -273,7 +273,6 @@ static void bdi_task_init(struct backing_dev_info *bdi, spin_unlock(bdi-wb_lock); tsk-flags |= PF_FLUSHER | PF_SWAPWRITE; - set_freezable(); /* * Our parent may run at a different priority, just set us to normal @@ -419,7 +418,6 @@ static int bdi_forker_task(void *ptr) spin_unlock_bh(bdi_lock); wait = msecs_to_jiffies(dirty_writeback_interval * 10); schedule_timeout(wait); - try_to_freeze(); continue; } -- 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/1] PM: Making bdi threads non-freezable
Subject: Re: [PATCH 1/1] PM: Making bdi threads non-freezable On Monday 02 November 2009, Dasgupta, Romit wrote: Fixes the case when bdi threads are in the refrigerator but file system sync can happen after this. This is possible in MMC when CONFIG_MMC_UNSAFE_RESUME is not set. What's going to happen if we attemt to suspend the underlying block device(s) when the bdi thread are doing their job? Is there any synchronisation mechanism for that? There is no explicit synchronization AFAICT. However, it looks like the call to 'del_gendisk' would invoke 'sync_filesystem' down the line. 'sync_filesystem' would end with synchronous writes of inodes followed by a call to '__sync_blockddev'. After this call I believe there should not be any activity pending for the blockdevice. So this should not lead to any race. My tests on the development board did not show any issues. But some FS experts may comment. Regards, -Romit -- 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-pm: Fixes behaviour of some shared resource framework functions
Paul/Kevin, As Madhu explained it looks like there are instances where we forcibly need to bump up to a higher CPU + L3 frequencies (VDD1 + VDD2 scaling). I understand that this should be done by cpufreq governors but here is reason that I think the current cpufreq governors won't be able to handle. Large latency response: The sampling intervals for the cpufreq governors are quite large and thus the latency for the frequency change to occur is large. This was seen in Android UI responsiveness. The initial response of the UI seems to be quite sluggish until after a while when the cpufreq governors would catch up to the required MIPS. I know that Patrick (Cc'd) did some experiments with conservative governor but my understanding is that it still has this basic problem. Tied to the above is necessity for high MIPS for short duration: I also presume that there might be situations where we need very high MIPS but for a very very short interval of time. This would never bump up the frequency as it would more or less be ignored by the cpufreq governors. Please let me know what you think. Thanks, -Romit -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, October 29, 2009 4:15 AM To: Chikkature Rajashekar, Madhusudhan Cc: 'Paul Walmsley'; Dasgupta, Romit; 'linux-omap@vger.kernel.org' Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions Madhusudhan madhu...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Wednesday, October 28, 2009 1:38 PM To: Kevin Hilman Cc: Dasgupta\, Romit; linux-om...@vger.kernel.org Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions On Tue, 13 Oct 2009, Kevin Hilman wrote: Dasgupta, Romit ro...@ti.com writes: (Tested on Zoom2). 'omap_pm_dsp_set_min_opp' 'omap_pm_cpu_set_freq' were using their own struct device *. This is a problem because invoking these functions from different clients would result in setting of the resource level as requested by the last caller. Fixes this by introducing a struct device * to the parameter list for these functions. Signed-off-by: Romit Dasgupta ro...@ti.com This looks like the right fix to me. Paul, any comments? Wait a minute, I am retracting my ack. Romit, the only caller of omap_pm_dsp_set_min_opp() should be DSPBridge and the only caller of omap_pm_cpu_set_freq() should be CPUFreq. So the struct device * pointer is not necessary, unless I am missing something. Can you please explain what you're trying to do? I believe that omap_pm_cpu_set_freq() can be called by drivers to setup the optimal vdd1 opp, right? For example MMC works at opp1 but the performance is certainly better at opp3.When ondemand is enabled drivers need to put certain constraints on vdd1 opp otherwise performance will be hurt. So, if the API takes care of device level calls then drivers can call this fn. So, the root use case is a power vs. performance policy decision. And using the proposed solution, a single driver gets to make a system wide policy decision. I don't like this. For your MMC usecase, I think we need some clarifications. What exactly does better performance mean. Is it better throughput that is needed? or is it really the MPU side that is not running/responding fast enough. If it's throughput, then omap_pm_set_min_bus_tput() should be used. If it's the MPU, what exactly is the problem with ondemand. Is it that it doesn't respond fast enough? Or that it never switches to a higher OPP. 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] omap-pm: Fixes behaviour of some shared resource framework functions
Hello Benoit, One comment below: In fact, this is Mike who started that analysis. We discussed that internally and our point is that if the CPUFreq ondemand or conservative heuristic is not able to increase quickly enough the CPU need to handle correctly the UI, we have to somehow improve or modify the governor in order to provide it a extra information in term of constraint maybe in order to increase immediately the frequency. The information as you mention needs to be supplied by the driver. The governor would then act on behalf of the driver! This begs for a new governor API or a signature change to an existing governor API. This should not be done in the low level omap_pm code; this is not the right level to do that. The issue is in the ondemand and must be fixed there. At the end of the day it would still be the driver making the decision! Regards, -Romit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PM: Fixes warning on suspend errors
Hi,
I get the following errors when I choose devices in /sys/power/pm_test. It
also shows that if 'dpm_suspend_start' fails somewhere down the line then the
kernel does not reset the 'transition_started' variable and we can get warning
similar to below. IMHO 'dpm_resume_noirq' is not the right place for setting
this variable. Please see the patch below which fixes the issue.
Thanks,
-Romit
# [ 113.713958] mmcblk0: mmc1:0001 STM16G 14.8 GiB
[ 113.718902] mmcblk0: unknown partition table
[ 113.745574] [ cut here ]
[ 113.751525] WARNING: at drivers/base/power/main.c:98
device_pm_add+0x94/0xdc()
[ 113.758819] Device: bdi
[ 113.758819] Parentless device registered during a PM transaction
[ 113.773071] Modules linked in:
[ 113.776214] [c002b87c] (unwind_backtrace+0x0/0xdc) from [c004ff58]
(warn_slowpath_common+0x48/0x60)
[ 113.785705] [c004ff58] (warn_slowpath_common+0x48/0x60) from [c004ffa8]
(warn_slowpath_fmt+0x24/0x30)
[ 113.799896] [c004ffa8] (warn_slowpath_fmt+0x24/0x30) from [c01b36b8]
(device_pm_add+0x94/0xdc)
[ 113.808990] [c01b36b8] (device_pm_add+0x94/0xdc) from [c01ad9bc]
(device_add+0x3a8/0x534)
[ 113.817565] [c01ad9bc] (device_add+0x3a8/0x534) from [c01adbd8]
(device_create_vargs+0x78/0xa8)
[ 113.829650] [c01adbd8] (device_create_vargs+0x78/0xa8) from [c0090a9c]
(bdi_register+0x3c/0x154)
[ 113.839263] [c0090a9c] (bdi_register+0x3c/0x154) from [c0090bd4]
(bdi_register_dev+0x20/0x28)
[ 113.851348] [c0090bd4] (bdi_register_dev+0x20/0x28) from [c0173b98]
(add_disk+0xe4/0x124)
[ 113.859954] [c0173b98] (add_disk+0xe4/0x124) from [c01e6b54]
(mmc_blk_probe+0x250/0x288)
[ 113.870513] [c01e6b54] (mmc_blk_probe+0x250/0x288) from [c01e14d4]
(mmc_bus_probe+0x18/0x1c)
[ 113.879394] [c01e14d4] (mmc_bus_probe+0x18/0x1c) from [c01af97c]
(driver_probe_device+0xa0/0x14c)
[ 113.893890] [c01af97c] (driver_probe_device+0xa0/0x14c) from [c01aef44]
(bus_for_each_drv+0x44/0x80)
[ 113.905609] [c01aef44] (bus_for_each_drv+0x44/0x80) from [c01afb60]
(device_attach+0x50/0x68)
[ 113.914550] [c01afb60] (device_attach+0x50/0x68) from [c01aed94]
(bus_probe_device+0x24/0x40)
[ 113.925170] [c01aed94] (bus_probe_device+0x24/0x40) from [c01ad9f0]
(device_add+0x3dc/0x534)
[ 113.934082] [c01ad9f0] (device_add+0x3dc/0x534) from [c01e1688]
(mmc_add_card+0xcc/0x118)
[ 113.945251] [c01e1688] (mmc_add_card+0xcc/0x118) from [c01e2408]
(mmc_attach_mmc+0xdc/0x13c)
[ 113.954132] [c01e2408] (mmc_attach_mmc+0xdc/0x13c) from [c01e12f0]
(mmc_rescan+0x2b0/0x2e8)
[ 113.964874] [c01e12f0] (mmc_rescan+0x2b0/0x2e8) from [c0060840]
(worker_thread+0x16c/0x218)
[ 113.973693] [c0060840] (worker_thread+0x16c/0x218) from [c0063d88]
(kthread+0x7c/0x84)
[ 113.986694] [c0063d88] (kthread+0x7c/0x84) from [c0026ea0]
(kernel_thread_exit+0x0/0x8)
[ 113.995147] ---[ end trace aaa7bf5becc572f5 ]---
Fixes the location where we decide that our power transition is complete.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e0dc407..6b9e991 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -365,7 +365,6 @@ void dpm_resume_noirq(pm_message_t state)
struct device *dev;
mutex_lock(dpm_list_mtx);
- transition_started = false;
list_for_each_entry(dev, dpm_list, power.entry)
if (dev-power.status DPM_OFF) {
int error;
@@ -529,6 +528,7 @@ static void dpm_complete(pm_message_t state)
put_device(dev);
}
list_splice(list, dpm_list);
+ transition_started = false;
mutex_unlock(dpm_list_mtx);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [linux-pm] [PATCH] PM: Fixes warning on suspend errors
Ok. Then the following is the refined and probably more appropriate one.
This fixes the point where we need to complete the power transition when
device suspend fails.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e0dc407..3d0b26a 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -444,6 +444,7 @@ static void dpm_resume(pm_message_t state)
INIT_LIST_HEAD(list);
mutex_lock(dpm_list_mtx);
+ transition_started = false;
while (!list_empty(dpm_list)) {
struct device *dev = to_device(dpm_list.next);
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Alan Stern
Sent: Tuesday, October 27, 2009 7:08 PM
To: Dasgupta, Romit
Cc: Hilman, Kevin; r...@sisk.pl; linux...@lists.linux-foundation.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: Re: [linux-pm] [PATCH] PM: Fixes warning on suspend errors
On Tue, 27 Oct 2009, Dasgupta, Romit wrote:
Hi,
I get the following errors when I choose devices in
/sys/power/pm_test. It
also shows that if 'dpm_suspend_start' fails somewhere down the line then
the kernel does not reset the 'transition_started' variable and we can get
warning similar to below. IMHO 'dpm_resume_noirq' is not the right place for
setting this variable. Please see the patch below which fixes the issue.
Fixes the location where we decide that our power transition is complete.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e0dc407..6b9e991 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -365,7 +365,6 @@ void dpm_resume_noirq(pm_message_t state)
struct device *dev;
mutex_lock(dpm_list_mtx);
- transition_started = false;
list_for_each_entry(dev, dpm_list, power.entry)
if (dev-power.status DPM_OFF) {
int error;
@@ -529,6 +528,7 @@ static void dpm_complete(pm_message_t state)
put_device(dev);
}
list_splice(list, dpm_list);
+ transition_started = false;
mutex_unlock(dpm_list_mtx);
}
The second hunk is okay, but the first hunk isn't. We want to set
transition_started to false as soon as devices start resuming, because
once a resume has begun it's okay to add new devices.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Memory performance / Cache problem
Can you dump the first few lines of the kernel log_buf during the kernel boot? Something like this: [0.00] Linux version 2.6.29-omap1-5-gf9f407c-dirty (ro...@maxwell) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #14 PREEMPT Fri Oct 9 14:04:52 IST 2009 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP ZOOM2 board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] L2 CACHE is enabled in bootloader [0.00] OMAP3430 ES3.1 It should tell you if L2 cache is enabled or not. Thanks, -Romit -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of e...@gmx.de Sent: Monday, October 12, 2009 1:24 PM To: linux-omap@vger.kernel.org Subject: Memory performance / Cache problem I found the memory performance of newer kernels are quit poor on an EVM- Omap3 board. It works with 2-6 times performance on the old 2.6.22 kernel from TI's PSP. Possible reasons: - problem in config the kernel (did omap3_evm_defconfig) - problem in kernel - kernel expects some settings from uboot, which are not done there I have tried the 2.6.29rc3 (from TI's PSP) and the 2.6.31 from git-tree. Both behave quite simular: Transport in MByte: memcpy = 204.073, loop4 = 183.212, loop1 =81.693, rand = 4.534 while the 22 kernel: memcpy = 453.932, loop4 = 469.934, loop1 = 125.031, rand = 29.631 Can someone give me help or can at least confirm that? Best regards Steffen -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Memory performance / Cache problem
Please update to the latest HEAD on the linux-omap pm branch. In the gitweb it shows b7ecc865c5f0885fae4c4401fa78a24084f45c40 Thanks, -Romit -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of e...@gmx.de Sent: Monday, October 12, 2009 2:08 PM To: linux-omap@vger.kernel.org Subject: RE: Memory performance / Cache problem Linux version 2.6.31 (s...@localhost) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1- 203) ) #1 Mon Oct 12 08:30:58 CEST 2009 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3 EVM Memory policy: ECC disabled, Data cache writeback OMAP3430 ES2.1 SRAM: Mapped pa 0x4020 to va 0xe300 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 I see, you get the message about L2 Cache, which I don't have Do you know how to enable this? Shoudn't the kernel configure all this things - not rely on bootloader? I am using the U-Boot 2008.10 (TIs PSP) The old 22 kernel is independet from the uboot in this issue. Thanks Steffen -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Memory performance / Cache problem
I am sorry, the code mentioned is from the Android Public Git tree not LO PM. Sorry for the confusion. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit Sent: Monday, October 12, 2009 2:38 PM To: e...@gmx.de; linux-omap@vger.kernel.org Subject: RE: Memory performance / Cache problem Please update to the latest HEAD on the linux-omap pm branch. In the gitweb it shows b7ecc865c5f0885fae4c4401fa78a24084f45c40 Thanks, -Romit -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of e...@gmx.de Sent: Monday, October 12, 2009 2:08 PM To: linux-omap@vger.kernel.org Subject: RE: Memory performance / Cache problem Linux version 2.6.31 (s...@localhost) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1- 203) ) #1 Mon Oct 12 08:30:58 CEST 2009 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3 EVM Memory policy: ECC disabled, Data cache writeback OMAP3430 ES2.1 SRAM: Mapped pa 0x4020 to va 0xe300 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 I see, you get the message about L2 Cache, which I don't have Do you know how to enable this? Shoudn't the kernel configure all this things - not rely on bootloader? I am using the U-Boot 2008.10 (TIs PSP) The old 22 kernel is independet from the uboot in this issue. Thanks Steffen -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap-pm: Fixes behaviour of some shared resource framework functions
(Tested on Zoom2).
'omap_pm_dsp_set_min_opp' 'omap_pm_cpu_set_freq' were using their own
struct device *. This is a problem because invoking these functions from
different clients would result in setting of the resource level as requested by
the last caller. Fixes this by introducing a struct device * to the parameter
list for these functions.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 8e67861..e9adc67 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -47,6 +47,7 @@ static struct cpufreq_frequency_table *freq_table;
#define MPU_CLKvirt_prcm_set
#endif
+DEFINE_PER_CPU(struct device , cpu_freq_dev);
static struct clk *mpu_clk;
/* TODO: Add support for SDRAM timing changes */
@@ -115,8 +116,9 @@ static int omap_target(struct cpufreq_policy *policy,
int ind;
for (ind = 1; ind = MAX_VDD1_OPP; ind++) {
if (mpu_opps[ind].rate/1000 = target_freq) {
- omap_pm_cpu_set_freq
- (mpu_opps[ind].rate);
+ omap_pm_cpu_set_freq(
+ __get_cpu_var(cpu_freq_dev),
+ mpu_opps[ind].rate);
break;
}
}
diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h
b/arch/arm/plat-omap/include/mach/omap-pm.h
index 583e540..5b26ba1 100644
--- a/arch/arm/plat-omap/include/mach/omap-pm.h
+++ b/arch/arm/plat-omap/include/mach/omap-pm.h
@@ -226,6 +226,7 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void);
/**
* omap_pm_dsp_set_min_opp - receive desired OPP target ID from DSP Bridge
+ * @dev: Identifies the client that wants to set the VDD1 OPP.
* @opp_id: target DSP OPP ID
*
* Set a minimum OPP ID for the DSP. This is intended to be called
@@ -233,7 +234,7 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void);
* information that code receives from the DSP/BIOS load estimator is the
* target OPP ID; hence, this interface. No return value.
*/
-void omap_pm_dsp_set_min_opp(u8 opp_id);
+void omap_pm_dsp_set_min_opp(struct device *dev, u8 opp_id);
/**
* omap_pm_dsp_get_opp - report the current DSP OPP ID
@@ -283,6 +284,7 @@ struct cpufreq_frequency_table
**omap_pm_cpu_get_freq_table(void);
/**
* omap_pm_cpu_set_freq - set the current minimum MPU frequency
+ * @dev: Identifies the client that wants to set the frequency.
* @f: MPU frequency in Hz
*
* Set the current minimum CPU frequency. The actual CPU frequency
@@ -290,7 +292,7 @@ struct cpufreq_frequency_table
**omap_pm_cpu_get_freq_table(void);
* Intended to be called by plat-omap/cpu_omap.c:omap_target(). No
* return value.
*/
-void omap_pm_cpu_set_freq(unsigned long f);
+void omap_pm_cpu_set_freq(struct device *dev, unsigned long f);
/**
* omap_pm_cpu_get_freq - report the current CPU frequency
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index 10463a4..6546527 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -159,7 +159,7 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void)
}
EXPORT_SYMBOL(omap_pm_dsp_get_opp_table);
-void omap_pm_dsp_set_min_opp(u8 opp_id)
+void omap_pm_dsp_set_min_opp(struct device *dev, u8 opp_id)
{
if (opp_id == 0) {
WARN_ON(1);
@@ -244,7 +244,7 @@ struct cpufreq_frequency_table
**omap_pm_cpu_get_freq_table(void)
return NULL;
}
-void omap_pm_cpu_set_freq(unsigned long f)
+void omap_pm_cpu_set_freq(struct device *dev, unsigned long f)
{
if (f == 0) {
WARN_ON(1);
diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-pm-srf.c
index 4350650..aece740 100644
--- a/arch/arm/plat-omap/omap-pm-srf.c
+++ b/arch/arm/plat-omap/omap-pm-srf.c
@@ -169,8 +169,6 @@ void omap_pm_set_max_sdma_lat(struct device *dev, long t)
}
}
-static struct device dummy_dsp_dev;
-
/*
* DSP Bridge-specific constraints
*/
@@ -187,20 +185,15 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void)
}
EXPORT_SYMBOL(omap_pm_dsp_get_opp_table);
-void omap_pm_dsp_set_min_opp(u8 opp_id)
+void omap_pm_dsp_set_min_opp(struct device *dev, u8 opp_id)
{
- if (opp_id == 0) {
+ if (dev == NULL || opp_id == 0) {
WARN_ON(1);
return;
}
pr_debug(OMAP PM: DSP requests minimum VDD1 OPP to be %d\n, opp_id);
-
- /*
-* For now pass a dummy_dev struct for SRF to identify the caller.
-* Maybe its good to have DSP pass this as an argument
-*/
- resource_request(vdd1_opp, dummy_dsp_dev, opp_id);
+ resource_request(vdd1_opp, dev, opp_id);
return;
}
EXPORT_SYMBOL(omap_pm_dsp_set_min_opp);
@@ -246,19 +239,16 @@ struct cpufreq_frequency_table
RE: Question on OPP table handling
Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! -- 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: Question on OPP table handling
Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! I like this approach.. takers? I think it is not enough. Some OPPs will be selected based on runtime CPU detection, but some OPPs might be disabled dynamically for some usecase depending of external parameters. [Romit] For a given SoC and type you can have only one OPP table. Isn't that true? -- 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: Question on OPP table handling
Typo I meant Put all the OPP tables for different CPUs (instead ofOPPs) in __initdata. Copy the run time detected CPU's OPP table in memory. Others get discarded! -Original Message- From: Menon, Nishanth Sent: Tuesday, October 06, 2009 5:34 PM To: Dasgupta, Romit Cc: Premi, Sanjeev; Cousson, Benoit; Kevin H; linux-omap@vger.kernel.org Subject: Re: Question on OPP table handling Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! I like this approach.. takers? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Memory leaks on l-o kernel
Adding LO list:
(Cc'ng Madhu)
Some additional memory leak (not the one reported by CONFIG_DEBUG_KMEMLEAK):
1. In twl4030_mmc_init struct_ omap_mmc_platform_data is allocated using
kzalloc.
2. The pointer to the allocated memory is stored in hsmmc_data which is
__initdata (contents will be lost after the init section cleanup).
Now look at this piece of code:
mmc = kzalloc(sizeof(struct omap_mmc_platform_data), GFP_KERNEL);
if (!mmc) {
pr_err(Cannot allocate memory for mmc device!\n);
return;
}
This is within a loop. For all but first iteration if kzalloc fails, the
function returns and the hsmmc_data is cleaned up (during the init memory
cleanup) and pointer to the successfully allocated omap_mmc_platform_data
blocks are lost.
Thanks,
-Romit
-Original Message-
From: Gadiyar, Anand
Sent: Friday, September 18, 2009 3:27 PM
To: olbp...@list.ti.com - OMAP Linux Baseport Development Team (May contain
non-TIers)
Subject: Memory leaks on l-o kernel
I enabled CONFIG_DEBUG_KMEMLEAK on the linux-omap kernel, and at boot it
throws up this on the SDP:
Worth a look?
kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
/ # cat /sys/kernel/debug/kmemleak
unreferenced object 0xc78e7c00 (size 192):
comm swapper, pid 1, jiffies 4294928994
backtrace:
[c002fa38] save_stack_trace+0x24/0x28
[c00a61b0] create_object+0x134/0x21c
[c00a63b4] kmemleak_alloc+0x40/0x84
[c00a3d74] kmem_cache_alloc+0xa8/0xb8
[c000f224] twl4030_mmc_init+0x54/0x298
[c003b1d4] sdp3430_twl_gpio_setup+0x2c/0x84
[c02bfa14] gpio_twl4030_probe+0x198/0x1b4
[c01c79c0] platform_drv_probe+0x20/0x24
[c01c6ab8] driver_probe_device+0xa8/0x154
[c01c6c34] __device_attach+0x44/0x48
[c01c6044] bus_for_each_drv+0x50/0x90
[c01c6cbc] device_attach+0x58/0x70
[c01c5e80] bus_attach_device+0x30/0x64
[c01c488c] device_add+0x3fc/0x560
[c01c8044] platform_device_add+0xfc/0x158
[c01cd5b0] add_numbered_child+0xe4/0x130
unreferenced object 0xc78e7d00 (size 192):
comm swapper, pid 1, jiffies 4294928994
backtrace:
[c002fa38] save_stack_trace+0x24/0x28
[c00a61b0] create_object+0x134/0x21c
[c00a63b4] kmemleak_alloc+0x40/0x84
[c00a3d74] kmem_cache_alloc+0xa8/0xb8
[c000f224] twl4030_mmc_init+0x54/0x298
[c003b1d4] sdp3430_twl_gpio_setup+0x2c/0x84
[c02bfa14] gpio_twl4030_probe+0x198/0x1b4
[c01c79c0] platform_drv_probe+0x20/0x24
[c01c6ab8] driver_probe_device+0xa8/0x154
[c01c6c34] __device_attach+0x44/0x48
[c01c6044] bus_for_each_drv+0x50/0x90
[c01c6cbc] device_attach+0x58/0x70
[c01c5e80] bus_attach_device+0x30/0x64
[c01c488c] device_add+0x3fc/0x560
[c01c8044] platform_device_add+0xfc/0x158
[c01cd5b0] add_numbered_child+0xe4/0x130
--
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: mmcqd cpu utilization
Madhu, My guess would be that the omap driver doesn't (cannot?) use the hardware to wait for busy to end, so the system must poll. So your guess hints probably at wait_for_completion(complete). Am I correct? Madhu wait_for_completion is blocking call. Please check 'omap_mmc_request' -- 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] mfd: twl: Fix possible NULL pointer violation
Fixes a possible NULL pointer violation. Tested on SDP 3430.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 07e40dc..fd5504c 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -352,11 +352,9 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
}
resconfig = triton2_scripts-resource_config;
- if (resconfig) {
- while (resconfig-resource) {
+ while (resconfig resconfig-resource) {
twl4030_configure_resource(resconfig);
resconfig++;
- }
}
if (twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY))
--
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] mfd: twl: Fix possible NULL pointer violation
Missed some formatting earlier.
Fixes a possible NULL pointer violation. Tested on 3430 SDP.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 07e40dc..e050a5e 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -352,11 +352,9 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
}
resconfig = triton2_scripts-resource_config;
- if (resconfig) {
- while (resconfig-resource) {
- twl4030_configure_resource(resconfig);
- resconfig++;
- }
+ while (resconfig resconfig-resource) {
+ twl4030_configure_resource(resconfig);
+ resconfig++;
}
if (twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY))
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit
Sent: Wednesday, July 22, 2009 1:45 PM
To: Kevin Hilman
Cc: linux-omap@vger.kernel.org Mailing List; sa...@linux.intel.com
Subject: [PATCH] mfd: twl: Fix possible NULL pointer violation
Fixes a possible NULL pointer violation. Tested on SDP 3430.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 07e40dc..fd5504c 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -352,11 +352,9 @@ void __init twl4030_power_init(struct
twl4030_power_data *triton2_scripts)
}
resconfig = triton2_scripts-resource_config;
- if (resconfig) {
- while (resconfig-resource) {
+ while (resconfig resconfig-resource) {
twl4030_configure_resource(resconfig);
resconfig++;
- }
}
if (twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0,
R_PROTECT_KEY))
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: User/kernel memory split
Hemanth, Why do you want the split? Do you have physical mem 1G in your system? Thanks, -Romit -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of V, Hemanth Sent: Monday, July 06, 2009 3:23 PM To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org Subject: User/kernel memory split Hi All Has anyone tried 3.5G/1.5G user/kernel memory split. Are there any know issues in this. Thanks Hemanth arch/arm/Kconfig choice prompt Memory split default VMSPLIT_3G help Select the desired split between kernel and user memory. If you are not absolutely sure what you are doing, leave this option alone! config VMSPLIT_3G bool 3G/1G user/kernel split config VMSPLIT_2G bool 2G/2G user/kernel split config VMSPLIT_1G bool 1G/3G user/kernel split -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: User/kernel memory split
Hemanth, I might be missing something but please see below: Hemanth, Why do you want the split? Do you have physical mem 1G in your system? We want to fit 512MB RAM on 2.6.27 Kernel which doesnot have highmem option. We also donot want to disturb the current I/O memory map [Romit] As long as your physical memory is slightly less than 1GB, I do not think highmem is necessary. For I/O map: Kernel virtual addresses start from 0xC000. Adding 512M to it gives 0xE000. So the virtual memory for IO space needs to be after this. Currently the IO Map is #define L4_WK_34XX_PHYS L4_WK_34XX_BASE /* 0x4830 */ #define L4_WK_34XX_VIRT 0xd830 #define L4_WK_34XX_SIZE SZ_1M #define L4_PER_34XX_VIRT0xd900 #define L4_PER_34XX_SIZESZ_1M #define L4_EMU_34XX_VIRT0xe400 #define L4_EMU_34XX_SIZESZ_64M #define OMAP34XX_GPMC_PHYS OMAP34XX_GPMC_BASE /* 0x6E00 */ #define OMAP34XX_GPMC_VIRT 0xFE00 #define OMAP34XX_GPMC_SIZE SZ_1M #define OMAP343X_SMS_VIRT 0xFC00 #define OMAP343X_SMS_SIZE SZ_1M #define OMAP343X_SDRC_PHYS OMAP343X_SDRC_BASE /* 0x6D00 */ #define OMAP343X_SDRC_VIRT 0xFD00 #define OMAP343X_SDRC_SIZE SZ_1M This is a problem as the existing virtual memory maps for I/O space would overlap with 512M SDRAM. So, we need to redefine the virtual mapping after 0xe000. The IO_OFFSET is 0x9000 currently. For L4_WK_34XX_VIRT we need a minimum of 0xe000 - 0x4830 i.e. 0x97D0 as the new IO_OFFSET. But using this new IO_OFFSET for mapping OMAP343x_GPMC_VIRT would result in an overflow(0x6E00 + 0x97D0 = 0x105D0). Using ioremap for these regions might help. But this needs changes to most drivers. In that case these static mappings could go away and I think they should. Some ARM kernel expert may comment! -Romit -- 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: User/kernel memory split
So are driver owners going to transition to ioremap/iounmap soon? These points were discussed in below thread. http://lists.arm.linux.org.uk/lurker/message/20090626.181403.55450a9c.en.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP35x GP TIMER as a wakeup trigger
Ashwin, Please see below: Could someone familiar with this scheme quickly elaborate all the steps that I need to go through to get the system to come out of suspend purely on the timer? Is it is just enough to setup the timer correctly, enable the interrupt in the appropriate register and assume that the PM layer will get the interrupt and do the right thing, or is there more that I have to do? [Romit] Already this is being done during the CPU Idle path. Yes you need to program the GPT 1 into oneshot mode with expiry time as appropriate. Also set the CM_CLKSEL_WKUP.CLKSEL_GPT1 to sys_32K clock. PM_MPUGRPSEL_WKUP.GRPSEL_GPT1, PM_WKEN_WKUP.EN_GPT1 should be set. Also, as as additional thing, if the PM layer handles the interrupt and begins the wake-up process, if I could know where that specifically happens, that'd be great since I need to know that the wake-up process is being triggered by the GPTIMER as opposed to the other wakeup triggers and deal with that differently. [Romit] prcm_interrupt_handler. Look for PM_WKST_WKUP. Thanks, -Romit -- 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 5/7][RFC] OMAP4: Update common omap machine specific sources.
case CLOCK_EVT_MODE_ONESHOT: @@ -108,6 +109,9 @@ static void __init omap2_gp_clockevent_init(void) omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_SYS_CLK); #endif tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer)); + if (cpu_is_omap44xx()) + /* Assuming 32kHz clk is driving GPT1 */ + tick_rate = 32768; [Romit] This should be read from CM_CLKSEL_WKUP.CLKSEL_GPT1 to be proper. -- 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: omap3 cpuidle interrupt latency
I think the original code had checks in 3 places but as you say it might have changed in linux-omap. I feel the right way to do this is to add a latency (using pm_qos) so that the CPU idle driver doesn't even attempt deeper idle states. Ideally we should use PM_QOS_NETWORK_LATENCY but the menu governor seems to check only PM_QOS_CPU_DMA_LATENCY class. I am not sure why menu governor does not check the other classes of latency. But for now I think if we add to PM_QOS_CPU_DMA_LATENCY when we detect some network activity and remove latency req after a while of network inactivity. Thanks, -Romit From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev [pr...@ti.com] Sent: Saturday, February 28, 2009 11:22 PM To: linux-omap@vger.kernel.org Subject: omap3 cpuidle interrupt latency I have noticed large interrupt latency when the cpuidle is enabled. e.g. response time for ping goes from avg 10-20ms to 800-1000ms. (I am at HEAD of the 'pm' branch) The IRQs and FIQs are disabled at the beginning of the function omap3_enter_idle() but WFI is executed much later in _omap_sram_idle(). In between, there is only one check for pending IRQs - omap_irq_pending() If any interrupt occurs beyond this point is it considered by the WFI? To reduce this latency, I am planning to do either/both of thse: - Add more checks for pending IRQs - Reduce the time for which the IRQs and FIQs are disabled Benefits will depend upon the behavior of WFI. Best regards, Sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: omap3 cpuidle interrupt latency
It would be nice if this device could dynamically set constraints (say by using a short kernel timer during activity or set/remove pm_qos latency) or the prediction aspect of cpuidle could be improved using rules feed from things like interrupt source. [Romit] I was thinking that in the irq handler we should add a requirement via the pm_qos or via the constraint framework (not sure if linux-omap has this) and set some kind of a timer (the idea is to keep arming the timer for clustered or rather closely spaced irq instances). If after a while the timer expires we release the latency req. This way perhaps we can handle the latency problem. Again, I am not sure why the menu governor only looks into the PM_QOS_CPU_DMA_LATENCY class only. I was thinking that it should look into other classes as well. Thanks, -Romit-- 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: Communication protocol through PCI between host and target
PCI defines its own communication protocol. Your target firmware should implement the mandatory PCI Config space protocol and what you want to do on accessing the PCI I/O space. At this point of time I think you should ask what type of device is your target going to look like. If your target device falls among one of the standard devices (like network card, sound card etc.) then Linux kernel supports those infrastructure and you do not have to necessarily create /dev nodes (though nothing prevents you to have a non-standard device model for which you can create /dev nodes). On the other hand, I have seen a non-standard PCI model where a 21555 non-transparent PCI to PCI bridge was used and on top of that a virtual network driver was created. Note that in this case their was no pre-designated master, slave in the bus. You could access the memory of one side from the other through the virtual network interface. You can see this in http://www.kwaak.net/~ard/fotos/epcbin/kernel/celinux-040503.q/Documentation/networking/mvnet.txt though I do not think this type of device is what you have in mind. Thanks, -Romit -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of arun c Sent: Saturday, January 03, 2009 3:17 PM To: linux-...@vger.kernel.org Subject: Communication protocol through PCI between host and target Hi all, I am a newbie here please bear with me. In my custom board the communication between host and target should happen through PCI interface. The target processor runs u-boot, and host processor is running linux. The target devices will be accessed from the host by /dev nodes. To reduce the workload on host all the target calls like open, read ,write ,ioctl are passed directly to the target. There will be a common PCI buffer between host and target and target will take commands from this buffer and execute. The result of executed API also will be put to a shared buffer between host and target. [This is what I am planning to implement] Anybody has come across similar sort of scenario? Any ideas or any pointers will be highly appreciated. Regards, Arun 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 -- 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: Serial port crashes omap3 on boot with 2.6.28rc4
Can you try without CONFIG_DEBUG_LL?
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Koen Kooi
Sent: Friday, November 14, 2008 4:27 PM
To: linux-omap@vger.kernel.org List
Subject: Re: Serial port crashes omap3 on boot with 2.6.28rc4
Op 14 nov 2008, om 11:17 heeft Koen Kooi het volgende geschreven:
Hi,
I updated to the current head
(5ecf98b76fa95078277c9037bb01640fd3de5e2c) and get this on boot
(with debug_ll) on omap3evm:
7omap-dss DISPLAY: panel 'panel-dvi' registered
6Serial: 8250/16550 driver4 ports, IRQ sharing enabled
6serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
,...:4...4../0400..1=..F1.5S.,...:4.3^F!^C../
0.0^F00..1=7KF1.5S..%;..=%..$..F:..5. .!*$0^G..
5. .!*$%^B-J/.0%C0^G...5(V6..!^C0.^D000)^V.6...%C0^G%C%.
%^C!2^G.$...R...%C0^G...8).%
..'%:%.#. ...,..!.74^C3..:..#.#V%...1.V...).5...v8. {...$.r.
3...6..
Any ideas?
I get this on rc3 now as well, it seems that the evm dss2 patch has
some side effects, console is restored when userspace launches getty
regards,
Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[SMC911x ]fix for driver resume and compilation warning
Hi,
I am trying out suspend, resume on an OMAP3 based board. What I see during
resume is that the SMC911x driver resume routing gets stuck after trying to
transmit the packet out of the controller. Some debug messages below:
-- smc911x_drv_resume
eth0: -- smc911x_reset
eth0: smc911x_reset timeout waiting for PM restore
eth0: -- smc911x_enable
eth0: -- smc911x_phy_configure()
eth0: -- smc911x_phy_reset()
eth0: phy caps=0x782d
eth0: phy advertised caps=0x0de1
eth0: -- smc911x_phy_check_media
smc911x_phy_read: phyaddr=0x1, phyreg=0x01, phydata=0x7809
smc911x_phy_read: phyaddr=0x1, phyreg=0x01, phydata=0x7809
eth0: link down
Restarting tasks ... eth0: -- smc911x_hard_start_xmit
eth0: -- smc911x_hardware_send_pkt
eth0: -- smc911x_hard_start_xmit
eth0: -- smc911x_hardware_send_pkt
eth0: -- smc911x_hard_start_xmit
eth0: -- smc911x_hardware_send_pkt
nfs: server 172.24.190.217 not responding, still trying
nfs: server 172.24.190.217 not responding, still trying
The following change makes it work fine: (The change within smc911x_drv_probe
function was to get rid of a compilation warning).
Additionally, the SMC9211 data sheet says that when we enter D2 sleep state, we
need to set the EDPWRDOWN bit in the PHY Mode control/status register and clear
it when we are back to D0. This is not done in the code as far as I can see. So
does it mean that the PHY is not powered down but the controller is? I have
another patch that fixes it. I will send that as well unless I am missing
something.
Thanks,
-Romit
Signed-off-by: Romit Dasgupta [EMAIL PROTECTED]
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 5051554..1f26ab0 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -2050,7 +2050,9 @@ err_out:
*/
static int smc911x_drv_probe(struct platform_device *pdev)
{
+#ifdef SMC_DYNAMIC_BUS_CONFIG
struct smc911x_platdata *pd = pdev-dev.platform_data;
+#endif
struct net_device *ndev;
struct resource *res;
struct smc911x_local *lp;
@@ -2182,9 +2184,9 @@ static int smc911x_drv_resume(struct platform_device *dev)
if (netif_running(ndev)) {
smc911x_reset(ndev);
- smc911x_enable(ndev);
if (lp-phy_type != 0)
smc911x_phy_configure(lp-phy_configure);
+ smc911x_enable(ndev);
netif_device_attach(ndev);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/04] OMAP3 SRF: Generic shared resource f/w
Rajendra,
Few bugs in the code
1) curr_level of the shared_resource is not updated in update_resource_level
2) resource_request invokes spin_lock_irqsave and then if it is a request for a
new device it invokes get_user().
get_user() calls kmalloc with GFP_KERNEL. So it can sleep. Hence you will sleep
with spinlocks held!!
Trying to review the remaining patches.
Regards,
-Romit
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Nayak, Rajendra
Sent: Thursday, October 16, 2008 7:42 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH 01/04] OMAP3 SRF: Generic shared resource f/w
This patch defines and implements the Generic
Shared Resource Framework structures and API's
Signed-off-by: Rajendra Nayak [EMAIL PROTECTED]
---
arch/arm/plat-omap/include/mach/resource.h | 79 +
arch/arm/plat-omap/resource.c | 433
+
2 files changed, 512 insertions(+)
Index: linux-omap-2.6/arch/arm/plat-omap/resource.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/arch/arm/plat-omap/resource.c 2008-10-16
18:04:05.0 +0530
@@ -0,0 +1,433 @@
+/*
+ * linux/arch/arm/plat-omap/resource.c
+ * Shared Resource Framework API implementation
+ *
+ * Copyright (C) 2007-2008 Texas Instruments, Inc.
+ * Rajendra Nayak [EMAIL PROTECTED]
+ *
+ * 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.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
PURPOSE.
+ * History:
+ *
+ */
+
+#include linux/errno.h
+#include linux/err.h
+#include mach/resource.h
+#include linux/slab.h
+
+/*
+ * This is for statically defining the users pool. This static pool is
+ * used early at bootup till kmalloc becomes available.
+ */
+#define MAX_USERS 10
+#define UNUSED0x0
+#define DYNAMIC_ALLOC 0x1
+#define STATIC_ALLOC 0x2
+
+/* res_list contains all registered struct shared_resource */
+static LIST_HEAD(res_list);
+
+/* res_lock protects res_list add and del ops */
+static DEFINE_SPINLOCK(res_lock);
+
+/* Static Pool of users for a resource used till kmalloc becomes available */
+struct users_list usr_list[MAX_USERS];
+
+/* Private/Internal functions */
+
+/**
+ * _resource_lookup - loop up a resource by its name, return a pointer
+ * @name: The name of the resource to lookup
+ *
+ * Looks for a registered resource by its name. Returns a pointer to
+ * the struct shared_resource if found, else returns NULL.
+ * The function is not lock safe.
+ */
+static struct shared_resource *_resource_lookup(const char *name)
+{
+ struct shared_resource *res, *tmp_res;
+
+ if (!name)
+ return NULL;
+
+ res = NULL;
+
+ list_for_each_entry(tmp_res, res_list, node) {
+ if (!strcmp(name, tmp_res-name)) {
+ res = tmp_res;
+ break;
+ }
+ }
+ return res;
+}
+
+/**
+ * resource_lookup - loop up a resource by its name, return a pointer
+ * @name: The name of the resource to lookup
+ *
+ * Looks for a registered resource by its name. Returns a pointer to
+ * the struct shared_resource if found, else returns NULL.
+ * The function holds spinlocks and takes care of atomicity.
+ */
+static struct shared_resource *resource_lookup(const char *name)
+{
+ struct shared_resource *res;
+ unsigned long flags;
+
+ if (!name)
+ return NULL;
+ spin_lock_irqsave(res_lock, flags);
+ res = _resource_lookup(name);
+ spin_unlock_irqrestore(res_lock, flags);
+
+ return res;
+}
+
+/**
+ * update_resource_level - Regenerates and updates the curr_level of the res
+ * @resp: Pointer to the resource
+ *
+ * This function looks at all the users of the given resource and the levels
+ * requested by each of them, and recomputes a target level for the resource
+ * acceptable to all its current usres. It then calls platform specific
+ * change_level to change the level of the resource.
+ * Returns 0 on success, else a non-zero value returned by the platform
+ * specific change_level function.
+ **/
+static int update_resource_level(struct shared_resource *resp)
+{
+ struct users_list *user;
+ unsigned long target_level;
+ int ret;
+
+ /* Regenerate the target_value for the resource */
+ target_level = RES_DEFAULTLEVEL;
+ list_for_each_entry(user, resp-users_list, node)
+ if (user-level target_level)
+ target_level = user-level;
+
+ pr_debug(SRF: Changing Level for resource %s to %ld\n,
+ resp-name, target_level);
+ ret =
RE: [PATCH 01/04] OMAP3 SRF: Generic shared resource f/w
1) curr_level of the shared_resource is not updated in
update_resource_level
Yes, its not. Its done as part of the platform specific change_level call.
[Romit] Kindly see below. I was thinking that it is better that we do not
access any fields of struct shared_resource from outside this file. Would the
line below solve the problem?
+static int update_resource_level(struct shared_resource *resp)
+{
+ struct users_list *user;
+ unsigned long target_level;
+ int ret;
+
+ /* Regenerate the target_value for the resource */
+ target_level = RES_DEFAULTLEVEL;
+ list_for_each_entry(user, resp-users_list, node)
+ if (user-level target_level)
+ target_level = user-level;
+
+ pr_debug(SRF: Changing Level for resource %s to %ld\n,
+ resp-name, target_level);
+ ret = resp-ops-change_level(resp, target_level);
+ if (ret) {
+ printk(KERN_ERR Unable to Change
+ level for resource
%s to %ld\n,
+ resp-name, target_level);
+ } else
resp-curr_level = target_level; /* [Romit] Should be done
here.*/
+ return ret;
+}
2) resource_request invokes spin_lock_irqsave and then if it
is a request for a new device it invokes get_user().
get_user() calls kmalloc with GFP_KERNEL. So it can sleep.
Hence you will sleep with spinlocks held!!
Right, so I'll probably have to add a GFP_ATOMIC flag to that.
I am now thinking If I really need spinlocks, think I can do with mutex's
instead.
The spinlocks were put in place to take care of the omap-pm hooks from
clock f/w which no longer seem to be needed.
[Romit] Trying to review the rest of the patches in the patchset to get a
better picture.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/04] OMAP3 SRF: Generic shared resource f/w
Some more points can be noted resource_init function is not prefixed by __init 1) curr_level of the shared_resource is not updated in update_resource_level Yes, its not. Its done as part of the platform specific change_level call. [Romit] Kindly see below. I was thinking that it is better that we do not access any fields of struct shared_resource from outside this file. Would the line below solve the problem? The actual *target_level* of the resource will depend on the resource type. Hence for say a per_pwrdm_latency resource if some user request's for a latency of no more than 130ms, it inturn translates to a PWRDM_RET level depending on the specific latency to go to RET/OFF. So what is currently done is the current_level of the resource in the above case is set to PWRDM_RET and if done the way you are suggesting will be set to 130ms. [Romit] I agree that the curr_level/target_level will depend on the resource type and that is why it seems to be inside struct shared_resource. Anyway in the update_resource_level function the code is trying to find the maximum target level among the users of the resource. So I am not very clear why it can't be done as I mentioned earlier. Kindly see my replies to other patches you posted. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 03/04] OMAP3 SRF: omap3 srf driver
+ */
+int set_latency(struct shared_resource *resp, u32 latency)
+{
+ u8 *pm_qos_req_added;
+
+ if (resp-curr_level == latency)
+ return 0;
+ else
+ /* Update the resources current level */
+ resp-curr_level = latency;
+
[Romit] I think this should be done outside this function, in
update_resource_level function.
+ pm_qos_req_added = resp-resource_data;
+ if (latency == RES_DEFAULTLEVEL)
+ /* No more users left, remove the pm_qos_req if present */
+ if (*pm_qos_req_added) {
+
pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,
+ resp-name);
+ *pm_qos_req_added = 0;
+ return 0;
+ }
+
+ if (*pm_qos_req_added) {
+ return
pm_qos_update_requirement(PM_QOS_CPU_DMA_LATENCY,
+ resp-name, latency);
+ } else {
[Romit] Shouldn't the following line execute only if pm_qos_add_requirement
returns successfully?
+ *pm_qos_req_added = 1;
+ return pm_qos_add_requirement(PM_QOS_CPU_DMA_LATENCY,
+ resp-name, latency);
+ }
+}
+
+int set_pd_latency(struct shared_resource *resp, u32 latency)
+{
+ u32 pd_lat_level, ind;
+ struct pd_latency_db *pd_lat_db;
+ struct powerdomain *pwrdm;
+
+ pd_lat_db = resp-resource_data;
+ pwrdm = pd_lat_db-pd;
+ pd_lat_level = PD_LATENCY_OFF;
+ /* using the latency db map to the appropriate PD state */
+ for (ind = 0; ind PD_LATENCY_MAXLEVEL; ind++) {
+ if (pd_lat_db-latency[ind] latency) {
+ pd_lat_level = ind;
+ break;
+ }
+ }
+
[Romit] Again is this the right place for this? It should be done only if
set_pwrdm_state returns successfully. So I think that should be checked as well.
+ resp-curr_level = pd_lat_level;
+ set_pwrdm_state(pwrdm, pd_lat_level);
+ return 0;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/04] OMAP3 SRF: Generic shared resource f/w
And finally, you had proposed to move to mutex instead of spin locks. Are you sure that we would do a resource_request or request_release from an interrupt context? If unsure maybe we can keep using spin locks and move to using GFP_ATOMIC. You may decide. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 03/04] OMAP3 SRF: omap3 srf driver
One final point
+int set_pd_latency(struct shared_resource *resp, u32 latency)
+{
+ u32 pd_lat_level, ind;
+ struct pd_latency_db *pd_lat_db;
+ struct powerdomain *pwrdm;
+
+ pd_lat_db = resp-resource_data;
+ pwrdm = pd_lat_db-pd;
+ pd_lat_level = PD_LATENCY_OFF;
+ /* using the latency db map to the appropriate PD state */
+ for (ind = 0; ind PD_LATENCY_MAXLEVEL; ind++) {
+ if (pd_lat_db-latency[ind] latency) {
+ pd_lat_level = ind;
+ break;
+ }
+ }
+
[Romit] Again is this the right place for this? It should be done only if
set_pwrdm_state returns successfully. So I think that should be checked as
well.
+ resp-curr_level = pd_lat_level;
+ set_pwrdm_state(pwrdm, pd_lat_level);
+ return 0;
+}
[Romit] In retrospect, I think the code is not right. Someone sets a latency
for say 30ms and what gets updated is the index in the curr_level. Next [s]he
sets a latency value and we will be comparing index with time. Cant we have a
function that would convert the latency (in time) to the right index?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/01] CPUFreq: OMAP3 cpufreq driver
Ramesh, For scaling from userspace, you can move to the userspace governor. Kindly look into this article: -Original Message- From: [EMAIL PROTECTED] [mailto:linux-omap- [EMAIL PROTECTED] On Behalf Of Gupta, Ramesh Sent: Wednesday, August 27, 2008 7:39 PM To: Nayak, Rajendra; linux-omap@vger.kernel.org Subject: RE: [PATCH 00/01] CPUFreq: OMAP3 cpufreq driver Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajendra Nayak Sent: Monday, August 11, 2008 6:42 PM To: linux-omap@vger.kernel.org Subject: [PATCH 00/01] CPUFreq: OMAP3 cpufreq driver Hi, The patch which follows implements the CPUFreq driver for OMAP3, tested on 3430sdp. The driver uses API's defined as part of the OMAP-PM layer. Performance Governor is selected by default in the defconfig. After bootup, to switch to ondemand or any other governor use the following sysfs interface /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor With the ondemand Governor I am some seeing issues for DSP Bridge. clk_notifier_register call for iva2_ck is successful but I am seeing below messages on opp change request from IVA. 3clock: Could not find fieldval 0 for clock iva2_ck parent dpll2_m2_ck clock: Could not find fieldval 0 for clock iva2_ck parent dpll2_m2_ck 3clock: Could not find fieldval 0 for clock iva2_ck parent dpll2_m2_ck clock: Could not find fieldval 0 for clock iva2_ck parent dpll2_m2_ck Looks like access to memory stalls while opp is changing ( some times I observed MMU Fault messages from IVA while opp is changing). Also some times I observed that after the opp change IVA Power state registers are not accessible( I am getting BUG# soft lock up while accessing IVA Power state registers). Can you please provide your inputs on these issues? Is there any way to manually switch opp using sysfs?( useful for debugging) regards Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/01] CPUFreq: OMAP3 cpufreq driver
Sorry, missed the link http://softwarecommunity.intel.com/articles/eng/1611.htm. Search for The Userspace Governor -Original Message- From: Dasgupta, Romit Sent: Wednesday, August 27, 2008 7:47 PM To: Gupta, Ramesh; Nayak, Rajendra; linux-omap@vger.kernel.org Subject: RE: [PATCH 00/01] CPUFreq: OMAP3 cpufreq driver Ramesh, For scaling from userspace, you can move to the userspace governor. Kindly look into this article: -Original Message- From: [EMAIL PROTECTED] [mailto:linux-omap- [EMAIL PROTECTED] On Behalf Of Gupta, Ramesh Sent: Wednesday, August 27, 2008 7:39 PM To: Nayak, Rajendra; linux-omap@vger.kernel.org Subject: RE: [PATCH 00/01] CPUFreq: OMAP3 cpufreq driver -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Patch [1/2] DaVinci CPPI TX DMA tasklet
As far as I understand, you need to save the toggle bit only after an entire
URB transfer is complete. So if we know that we are transmitting 512 * N bytes.
If N is even we would know that we don't have to change the data toggle and if
it is odd we have to. So, if we start the transfer and the entire urb is
transferred without error then this logic would work fine. On a USB endpoint
error however, we can check the number of BDs successfully transmitted (by
traversing the BD chain) and set the toggle correctly.
Comments?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Subbrathnam, Swaminathan
Sent: Thursday, August 21, 2008 7:28 PM
To: linux-omap@vger.kernel.org
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Patch [1/2] DaVinci CPPI TX DMA tasklet
Signed-off-by: Swaminathan S [EMAIL PROTECTED]
This patch adds tasklet structures to musb to enable
polling for FIFO empty status on the Mentor TX FIFO.
This is requried to enable proper functioning of
DaVinci CPPI TX DMA when performing Tx transfers.
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2096469..804caaf 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -273,6 +273,9 @@ struct musb_hw_ep {
u8 rx_reinit;
u8 tx_reinit;
+#ifdef CONFIG_ARCH_DAVINCI
+ u8 fifo_flush_check; /* Check FIFO empty */
+#endif
#endif
#ifdef CONFIG_USB_GADGET_MUSB_HDRC
@@ -331,6 +334,9 @@ struct musb {
struct list_headin_bulk;/* of musb_qh */
struct list_headout_bulk; /* of musb_qh */
struct musb_qh *periodic[32]; /* tree of interrupt+iso */
+#ifdef CONFIG_ARCH_DAVINCI
+ struct tasklet_struct fifo_check; /* FIFO empty check tasklet */
+#endif
#endif
/* called with IRQs blocked; ON/nonzero implies starting a session,
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 77bcdb9..29e1863 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -69,6 +69,7 @@ struct musb_qh {
u16 maxpacket;
u16 frame; /* for periodic schedule */
unsignediso_idx;/* in urb-iso_frame_desc[] */
+ u8 num_req;/* Number of active requests */
};
/* map from control or bulk queue head to the first qh on that ring */
@@ -89,6 +90,10 @@ extern int musb_hub_control(struct usb_hcd *hcd,
u16 typeReq, u16 wValue, u16 wIndex,
char *buf, u16 wLength);
+#ifdef CONFIG_ARCH_DAVINCI
+extern void musb_fifo_check_tasklet(unsigned long data);
+#endif
+
extern const struct hc_driver musb_hc_driver;
static inline struct urb *next_urb(struct musb_qh *qh)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB driver issue
What is the application you are using and could you turn the musb driver debug options? You can try it by echo D 3 /proc/driver/musb_hdrc (Check if MUSB_DEBUG is enabled). This should give more helpful messages. -Original Message- From: [EMAIL PROTECTED] [mailto:linux-omap-open- [EMAIL PROTECTED] On Behalf Of SUBHRANIL CHOUDHURY Sent: Wednesday, July 30, 2008 5:50 PM To: Gadiyar, Anand Cc: [EMAIL PROTECTED] Subject: Re: USB driver issue hi, I am using Mistral OMAP3430 OSK2.1 board. It is the USB OTG port. The Philips tranciever ISP1504. I am enabling the EHCI and OHCI in the kernel menuconfig. This was the error print i was getting: Unable to handle kernel NULL pointer dereference at virtual address pgd = c54d8000 [] *pgd=81401031, *pte=, *ppte= Internal error: Oops: 817 [#1] Modules linked in: CPU: 0Not tainted (2.6.22.18-omap3 #29) PC is at consistent_sync+0x40/0xa4 LR is at usb_hcd_submit_urb+0x7b0/0x8b4 pc : [c00315ac]lr : [c02307e0]psr: 2013 sp : c1403c48 ip : c1403c58 fp : c1403c54 r10: 8003 r9 : 0020 r8 : 0020 r7 : c483dc20 r6 : c0569000 r5 : c23c040c r4 : ff2d2000 r3 : r2 : 0002 r1 : ff2dba38 r0 : ff2d2000 Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user Control: 00c5387f Table: 854d8018 DAC: 0015 Do you get some clue from this about what is happening? On Wed, Jul 30, 2008 at 5:35 PM, Gadiyar, Anand [EMAIL PROTECTED] wrote: Hi all, I am trying to validate the USB driver on OMAP3430 with the 2.6.22.18kernel. I am facing problems in the process while trying to do a USB transfer with DMA enabled. The apllication is breaking in a function called consistent_sync. The error message is like Unable to handle kernel Null pointer. Which board are you using? Which is the USB port - EHCI/OHCI/OTG? Assuming it is the USB OTG port (because that is the only one where you can enable or disable DMA), what is the transceiver being used on the port? The issue is same with both OHCI and EHCI controller. And the issue is not coming if i disable DMA. I don't think you have control over DMA disabling with the OHCI/EHCI controller. Are you sure you are using the OHCI/EHCI controller? The Unable to handle kernel Null pointer message comes with some more data. We won't be able to help you out without the rest of the log, but the answers to questions above are essential before we move on to this. Has anyone tried USB packet transfer with DMA enabled? Please let me know. Regards, Subhro ___ Linux-omap-open-source mailing list [EMAIL PROTECTED] http://linux.omap.com/mailman/listinfo/linux-omap-open-source -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
