On Tue, 2011-05-24 at 16:45 -0700, Kevin Hilman wrote:
Hi Tomi,
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Wed, 2011-05-18 at 17:41 +0300, Tomi Valkeinen wrote:
On Wed, 2011-05-18 at 16:24 +0200, Kevin Hilman wrote:
Looking closer at the code, a zero return happens only when
Hi,
On Tue, May 24, 2011 at 5:22 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 5/23/2011 6:40 AM, Gulati, Shweta wrote:
Benoit,
On Fri, May 20, 2011 at 7:19 PM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Shweta,
On 5/13/2011 8:27 AM, Gulati, Shweta wrote:
To set sr ntarget values for
Tod,
On 5/25/2011 8:20 AM, Todd Poynor wrote:
* Move variable declarations from header file and make these static
(the entire header file should probably go away).
Infact the intial version posted on the list had all these structures
in C file. After some comments on the list we moved them
cpufreq table allocated by opp_init_cpufreq_table is better
freed by OPP layer itself. This allows future modifications to
the table handling to be transparent to the users.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: removed lock of free.
V1: http://marc.info/?t=13061924171r=1w=2
On Tue, May 24, 2011 at 17:01, Kevin Hilman khil...@ti.com wrote:
Menon, Nishanth n...@ti.com writes:
On Thu, May 19, 2011 at 08:12, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
OMAP2 does not use OPP tables at the moment for DVFS. Currently,
we depend on opp table
CC'ing correct ARM mailing list.
On Tue, May 24, 2011 at 3:48 PM, Ashok Babu asho...@gmail.com wrote:
Hi All,
I am no success in booting up the ARM1176 processor with the
linux-2.6.32 kernel.
While googling about the ARM Harvard architecture, I came to know that
we have to flush/invalidate
On Tue, 2011-05-24 at 16:45 -0700, Kevin Hilman wrote:
Hi Tomi,
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Wed, 2011-05-18 at 17:41 +0300, Tomi Valkeinen wrote:
On Wed, 2011-05-18 at 16:24 +0200, Kevin Hilman wrote:
Looking closer at the code, a zero return happens only when
On 5/24/2011 8:12 PM, Steve Calfee wrote:
On 05/23/11 20:39, Ricardo Neri wrote:
Hi Steve,
Le mercredi 18 mai 2011 à 12:07 -0500, Steve Calfee a écrit :
On 05/17/11 22:41, Peter Ujfalusi wrote:
On Tuesday 17 May 2011 22:35:09 Steve Calfee wrote:
I think the generally accepted method of
Hello,
On Wed, May 25, 2011 at 01:18:37PM +0530, Vimal Singh wrote:
CC'ing correct ARM mailing list.
On Tue, May 24, 2011 at 3:48 PM, Ashok Babu asho...@gmail.com wrote:
Hi All,
I am no success in booting up the ARM1176 processor with the
linux-2.6.32 kernel.
While googling about
Hi Santosh,
On Thu, May 19, 2011 at 10:04 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 5/18/2011 11:02 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Provide the the assembly function v7_flush_dcache_all to the
OMAP3 PM module, under CONFIG_CPU_V7.
On Thu, May 19, 2011 at 06:05:21PM +0530, Koyamangalath, Abhilash wrote:
I have tried the patch on am37x evm and the i2c soft-reset time-out issue
doesn't
seem to go off for me. Previously I used to get a log :
[0.00] omap_hwmod: i2c1: softreset failed (waited 1 usec)
[
This is to inform you that you have exceeded your E-mail
Quota Limit and
you need to increase your E-mail Quota Limit because in
less than 96 hours
your E- mail Account will be disabled.Increase your E-mail
Quota Limit and
continue to use your Webmail Account.
To increase your E-mail Quota
Menon, Nishanth n...@ti.com writes:
On Wed, May 18, 2011 at 03:53, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
Patch OMAP2+: voltage: split voltage controller (VC) code into dedicated
layer
splits out the hardcoded value in the code to vc's channel init.
This
Nishanth Menon n...@ti.com writes:
cpufreq table allocated by opp_init_cpufreq_table is better
freed by OPP layer itself. This allows future modifications to
the table handling to be transparent to the users.
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
--
On Wed, May 25, 2011 at 11:17, Kevin Hilman khil...@ti.com wrote:
Menon, Nishanth n...@ti.com writes:
On Wed, May 18, 2011 at 03:53, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
Patch OMAP2+: voltage: split voltage controller (VC) code into dedicated
layer
splits
Tomi Valkeinen tomi.valkei...@ti.com writes:
[...]
You're right, the code is just wrong here and would lead to strange
return value checking in the callers to be correct.
I think the best fix for this problem is to use a signed return value
which can wrap as expected, and then use return
On Wed, May 25, 2011 at 12:39:56PM +0530, Santosh Shilimkar wrote:
Tod,
On 5/25/2011 8:20 AM, Todd Poynor wrote:
* Move variable declarations from header file and make these static
(the entire header file should probably go away).
Infact the intial version posted on the list had all
On Wed, 2011-05-25 at 11:34 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
[...]
You're right, the code is just wrong here and would lead to strange
return value checking in the callers to be correct.
I think the best fix for this problem is to use a
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Wed, 2011-05-25 at 11:34 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
[...]
You're right, the code is just wrong here and would lead to strange
return value checking in the callers to be correct.
I think
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Remove cpu-is checks while enabling/disabling OMAP GPIO module
during a gpio request/free.
Signed-off-by: Charulatha V ch...@ti.com
This looks mostly OK, but one nitpick about the usage of USHRT_MAX.
For most
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
the GPIO driver initializes the non-wakeup GPIO bits for OMAP24xx
(bothe OMAP 2420 and 2430) not for OMAP3 which is incorrect.
Can you cite the
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
In omap3, save/restore context is implemented for GPIO
banks 2-6 as GPIO bank1 is in wakeup domain. Instead
of identifying bank's power domain by bank id, make use
of a flag loses_context which is filled by
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
gpio_context array, which is used to save gpio bank's context,
is used only for OMAP3 architecture.
Move gpio_context as part of gpio_bank structure so that
it can be specific to each gpio bank and can be used
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Modify the omap_gpio_save/restore_context to support OMAP4
architecture so that the OMAP GPIO driver need not be modified
when OMAP4 off mode support is available.
Signed-off-by: Charulatha V ch...@ti.com
I
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Modify omap_gpio_prepare_for_idle() omap_gpio_resume_after_idle()
functions to handle save context restore context respectively in the
OMAP GPIO driver itself instead of calling these functions from pm specific
Kevin Hilman khil...@ti.com writes:
[...]
@@ -1394,11 +1409,17 @@ void omap2_gpio_resume_after_idle(void)
for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
clk_enable(bank-dbck);
-if (!workaround_enabled)
+pdev =
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Make workaround_enabled flag bank-specific instead of using a single
flag for all the banks together. This would be helpful while making
use of runtime framework in OMAP GPIO driver which would make the
driver
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
By adding level and edge detection register offsets and then initializing them
correctly according to OMAP versions during device registrations we can now
remove
lot of revision checks in these functions.
Signed-off-by: Tarun Kanti DebBarma
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
It is not required to use hard-coded offsets any more in context
save and restore functions and instead use the generic offsets
which have been correctly initialized during device registration.
Signed-off-by: Tarun Kanti DebBarma
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
In set_24xx_gpio_triggering(), for OMAP4, GPIO wakeup request
is set for all type of GPIO triggers whereas as per TRM the GPIO
wakeup request can only be generated on edge transitions. Fix this.
OK. Please make
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Getting rid of ifdefs within the function by adding register offset intctrl
and associating OMAP_GPIO_INT_CONTROL in respective SoC specific files.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Use memset to fill omap_gpio_reg_offs structure with 0x
instead of filling each and every undefined register offset
separately with USHRT_MAX in a given OMAP SoC. This would ease
while adding new register
Rev 3 of cleanups for cpufreq to include a couple of bugfixes we found as part
of
additional dvfs testing and code review.
Testing done: OMAP4SDP4430 +.39- I think the only other major platform would be
omap2 - but I doubt it was functional previously - if someone has a chance to
give
it a
Clk name does'nt need to dynamically detected during clk init.
move them off to driver initialization, if we dont have a clk name,
there is no point in registering the driver anyways. The actual clk
get and put is left at cpu_init and exit functions.
Signed-off-by: Nishanth Menon n...@ti.com
---
if we do not have mpu_dev we normally fail in cpu_init. It is better
to fail driver registration if the devices are not available.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, while
OMAP3+ use OPP table to generate and release the cpufreq tables.
Hence use a flag to mark which API to use for allocating and freeing
the tables.
Signed-off-by: Nishanth Menon n...@ti.com
---
OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.
Signed-off-by: Nishanth Menon n...@ti.com
---
By creating freq_table_[alloc|free] we can handle the differences
between OMAP2 and OMAP3+ systems and we have a centralized allocation
and cleanup strategy. We use this to cleanup the freq_table when
cpufreq_frequency_table_cpuinfo fails.
Signed-off-by: Nishanth Menon n...@ti.com
---
Release the mpu_clk in fail paths.
Reported-by: Todd Poynor toddpoy...@google.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git
Minor file header updates to reflect 2011 for omap2-cpufreq code
and remove misleading OMAP3 reference in omap1 cpufreq code.
Should probably be squashed to:
OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
Reported-by: Todd Poynor toddpoy...@google.com
Signed-off-by: Nishanth Menon
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who use the cpufreq table
allocate it once(one freq table for all CPUs) and free them
once the last user is done with it. We also need to protect
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
With register offsets now defined for respective OMAP versions
we can get rid of cpu_class_* checks. In addition, organized
common initialization for the different OMAP silicon versions.
Signed-off-by:
Nishanth Menon n...@ti.com writes:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who use the cpufreq table
allocate it once(one freq table for all CPUs) and free them
once the last user
Nishanth Menon n...@ti.com writes:
Minor file header updates to reflect 2011 for omap2-cpufreq code
and remove misleading OMAP3 reference in omap1 cpufreq code.
Should probably be squashed to:
OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
Reported-by: Todd Poynor
On Wed, May 25, 2011 at 17:16, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who use the cpufreq table
On Wed, May 25, 2011 at 17:18, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
Minor file header updates to reflect 2011 for omap2-cpufreq code
and remove misleading OMAP3 reference in omap1 cpufreq code.
Should probably be squashed to:
OMAP: cpufreq: Split OMAP1 and
On Wed, May 25, 2011 at 04:38:49PM -0700, Nishanth Menon wrote:
OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.
On Wed, May 25, 2011 at 17:51, Todd Poynor toddpoy...@google.com wrote:
+ if (!freq_table) {
+ dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
+ policy-cpu);
Just a minor comment: suggest dev_dbg() or WARN_ONCE() for some of
these
On Wed, May 25, 2011 at 17:53, ym cheng yongmingch...@hotmail.com wrote:
OK,I wil test on s3c2440 board,and share test data.
The series was meant for OMAP, if you meant:
http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=836partnum=S3C2440
as far as I see, this platform
On Wed, May 25, 2011 at 04:38:50PM -0700, Nishanth Menon wrote:
By creating freq_table_[alloc|free] we can handle the differences
between OMAP2 and OMAP3+ systems and we have a centralized allocation
and cleanup strategy. We use this to cleanup the freq_table when
From: Russell King - ARM Linux li...@arm.linux.org.uk
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
Let's unify this before we have additional SoCs re-implementing this
obviously common functionality
On Wed, May 25, 2011 at 18:09, Todd Poynor toddpoy...@google.com wrote:
+ if (result || !freq_table) {
+ dev_err(mpu_dev, %s: cpu%d: unable to get freq table [%d]\n,
+ __func__, policy-cpu, result);
+ return result;
The || !freq_table isn't
On Wed, May 25, 2011 at 04:38:51PM -0700, Nishanth Menon wrote:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who use the cpufreq table
allocate it once(one freq table for all CPUs) and
On Wed, May 25, 2011 at 18:25, Todd Poynor toddpoy...@google.com wrote:
On Wed, May 25, 2011 at 04:38:51PM -0700, Nishanth Menon wrote:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who
From: Aneesh V ane...@ti.com
Add support for detecting the latest in the OMAP4 family: OMAP4460
Among other changes, the new chip also can support 1.5GHz A9s,
1080p stereoscopic 3D and 12 MP stereo (dual camera). In addition,
we have changes to OPPs supported, clock tree etc, hence having a
chip
Hi,
Here is the initial RFC providing base support for OMAP4460, This series
based on v2.6.39 tag boots up on SDP4460:
http://pastebin.pandaboard.org/index.php/view/28646263
Aneesh V (2):
OMAP: ID: introduce chip detection for OMAP4460
OMAP4: HWMOD: make current hwmods common for 4460 and
From: Aneesh V ane...@ti.com
Make all hwmod data used for OMAP4430 available for
the OMAP44XX class so that OMAP4460 can use them.
We will modify the required 4460 hwmod in further patch(es).
[n...@ti.com: just rebased to .39]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Aneesh V
From: Moiz Sonasath m-sonas...@ti.com
For OMAP4460, GPIO-7 of bank1 is used for controling
the TPS modes, hence GPIO1 should not be reset
during init as reset will cause the TPS voltage to
drop to 0.9 V.
Originally from:
From: Rajendra Nayak rna...@ti.com
omap4460 platform has a few clock nodes which are added
and a few which are missing (compared to the 4430 platform)
rename current 4430 definitions to 44XX and followon patches
will introduce the 4460 changes
Signed-off-by: Rajendra Nayak rna...@ti.com
---
From: Rajendra Nayak rna...@ti.com
This patch adds additional register bitshifts for
registers added in OMAP4460 platform.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/cm-regbits-44xx.h | 32
arch/arm/mach-omap2/prm-regbits-44xx.h |
From: Rajendra Nayak rna...@ti.com
OMAP4460 platform has a few clock nodes which are added
and a few which are missing (compared to the 4430 platform)
Update the clock tree accordingly and handle these nodes
using the clock flags (CK_*).
Signed-off-by: Rajendra Nayak rna...@ti.com
---
From: Rajendra Nayak rna...@ti.com
The 4460 platform has changes in the MPU powerdomain,
hence model a new powerdomain for it and identify
is using the CHIP_IS_OMAP446X macro.
Also move all the common powerdomains to use
CHIP_IS_44XX so they are reused on OMAP4460.
Signed-off-by: Rajendra Nayak
From: Rajendra Nayak rna...@ti.com
The 4460 platform has no difference in the clockdomains
as compared to the 4430 platform.
Hence just update the .omap_chip field to make sure
the same clockdomains model data can be reused on the
4460 platform.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
From: Rajendra Nayak rna...@ti.com
The OMAP4460 platform needs DCC (Duty cycle correction)
enabled for frequencies above 1GHz from the MPU DPLL.
Further, on OMAP4460 when the MPU Frequency is above 748Mhz,
the programmable divider for the Async bridge to ABE must be
set to MPU-Freq/8. For lower
On Wed, May 25, 2011 at 06:56:56PM -0700, Nishanth Menon wrote:
...
@@ -427,6 +465,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
u16 freqsel = 0;
struct dpll_data *dd;
int ret;
+ unsigned long orig_rate = 0;
if (!clk || !rate)
OMAP4430 and 4460 have slightly different functional clocks.
we need to map this back into hwmod database as well to ensure
sanity.
Signed-off-by: Nishanth Menon n...@ti.com
---
Depends on the series posted earlier for
http://marc.info/?l=linux-omapm=130637503008641w=2
missed tracking this down
On Wed, May 25, 2011 at 8:41 PM, Nishanth Menon n...@ti.com wrote:
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
snip
+static struct omap_hwmod_opt_clk bandgap446x_opt_clks[] = {
+ { .role = fclk, .clk = bandgap_ts_fclk },
+};
+
On Wed, May 25, 2011 at 20:46, Pandita, Vikram vikram.pand...@ti.com wrote:
On Wed, May 25, 2011 at 8:41 PM, Nishanth Menon n...@ti.com wrote:
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
snip
+static struct omap_hwmod_opt_clk
On 5/26/2011 8:46 AM, Todd Poynor wrote:
On Wed, May 25, 2011 at 06:56:56PM -0700, Nishanth Menon wrote:
...
@@ -427,6 +465,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
u16 freqsel = 0;
struct dpll_data *dd;
int ret;
+ unsigned long
On Wed, May 25, 2011 at 21:13, Rajendra Nayak rna...@ti.com wrote:
On 5/26/2011 8:46 AM, Todd Poynor wrote:
On Wed, May 25, 2011 at 06:56:56PM -0700, Nishanth Menon wrote:
...
@@ -427,6 +465,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk,
unsigned long rate)
u16 freqsel = 0;
On Wed, 2011-05-25 at 13:30 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Wed, 2011-05-25 at 11:34 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
snip
+if (off_mode_enabled) {
+count =
71 matches
Mail list logo
