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?
--
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
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
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)
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 */
-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
(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
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
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
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
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
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
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
: 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
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
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
)) {
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
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:
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,
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
(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
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
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
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
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
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
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
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
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:
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
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
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
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())
+ /*
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
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
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
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
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
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
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.
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
+ */
+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
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
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;
+ /*
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,
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
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
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-
48 matches
Mail list logo
