Hi all,
I get the following warning at bootup. This is on mainline kernel
(omap3_defconfig) on a 3430 SDP.
I thought we'd seen this earlier, not sure if there is a fix.
I can provide the full booup log if needed. Any pointers would also
be okay - I can look at a fix if no one else already has.
Hi Kevin,
If my understanding is correct.
The clk_setuptime is board specific, depends on the osc/XTAL used onthe
board. So the clk_setuptime has to come from the board file.
Volt_setuptime volt_offset is PM IC specific, depends on the PM IC's SMPS
characteristics. So this can be updated
On Thu, Mar 18, 2010 at 04:26:04PM +0100, Syrjala Ville (Nokia-D/Helsinki)
wrote:
[...]
Just tried it and seems to be mostly OK. We get lockdep checking as a
bonus. It didn't like setup_plane taking the same rwsem twice so I
added a check to see if the old and new regions are the same
On Thu, Mar 18, 2010 at 06:35:21PM -0700, Tony Lindgren wrote:
-#if defined(CONFIG_HAS_TLS_REG)
- mcr p15, 0, r3, c13, c0, 3 @ set TLS register
-#elif !defined(CONFIG_TLS_REG_EMUL)
- mov r4, #0x0fff
- str r3, [r4, #-15] @ TLS val at
On Fri, Mar 19, 2010 at 03:46:45AM +, Jamie Lokier wrote:
I'm thinking, why not an alternative() macro like on x86, which is a
very nice way to describe run-time patches of one or a few instructions
which depend on arch feature bits.
Having XIP support prevents that kind of thing.
--
To
On Wed, 10 Mar 2010 14:30:00 -0800
Tony Lindgren t...@atomide.com wrote:
* Kevin Hilman khil...@deeprootsystems.com [100310 10:01]:
Tony Lindgren t...@atomide.com writes:
...
Unfortunately, Tony's additional fix did not make it into the version
that was merged to mainline, which results
From: Vaibhav Hiremath hvaib...@ti.com
Refreshed on top of latest linuxtv/master repository and
resubmitting the patch series again.
Please note that this patch is dependent on patch which add ti-media
directory (submitted earlier to this patch series).
Vaibhav Hiremath (2):
OMAP2/3 V4L2: Add
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/devices.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index
Hi Nishanth,
From: Menon, Nishanth
Sent: Thursday, March 18, 2010 7:45 PM
Many modules seem to need some sort of flexible storage mechanism
which is corresponds to a specific opp. To cater to this need, we
provide store, restore and removal apis.
Do we really need that level of flexibility for
Due to check for absolute omap_rev() values against
ES3.0 and ES3.1, the restore pointer for OMAP3630 is
incorrectly assigned.
The problem may be observed with OMAP3430 ES3.1.1
as well.
Submitting this as RFC because I have only compiled
with changes. Haven't yet tried on EVM. Will submit
formal
-Original Message-
From: tomi.valkei...@nokia.com [mailto:tomi.valkei...@nokia.com]
Sent: Friday, March 19, 2010 4:41 PM
To: Hiremath, Vaibhav
Cc: Valkeinen Tomi (Nokia-D/Helsinki); ext Steve Sakoman; linux-
o...@vger.kernel.org
Subject: RE: kernel panic with latest DSS
On
From: Vaibhav Hiremath hvaib...@ti.com
With recent changes happened in OMAP2/3 DSS library for regulator interface, it
is required to define DSI regulator supply, without this DSS (in turn Fbdev)
fails to get regulator.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Tomi Valkeinen
-Original Message-
From: Hiremath, Vaibhav
Sent: Friday, March 19, 2010 4:45 PM
To: 'tomi.valkei...@nokia.com'
Cc: ext Steve Sakoman; linux-omap@vger.kernel.org
Subject: RE: kernel panic with latest DSS
-Original Message-
From: tomi.valkei...@nokia.com
On Thu, Mar 18, 2010 at 01:38:56PM -0500, Olaya, Margarita wrote:
Please find attached the patch. I'm working to fix the issues with the
MUA.
Applied now, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
On Fri, Mar 5, 2010 at 12:12 PM, Guzman Lugo, Fernando x0095...@ti.com wrote:
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -389,4 +389,7 @@ extern u32 drv_request_resources(u32 dw_context, u32
*pDevNodeString);
*/
extern u32
On Fri, Mar 19, 2010 at 08:46:04AM +0100, Deak Imre (Nokia-D/Helsinki) wrote:
On Thu, Mar 18, 2010 at 04:26:04PM +0100, Syrjala Ville (Nokia-D/Helsinki)
wrote:
[...]
Just tried it and seems to be mostly OK. We get lockdep checking as a
bonus. It didn't like setup_plane taking the same
-Original Message-
From: K, Ambresh
Sent: Thursday, March 18, 2010 12:46 PM
To: Gurav , Pramod
Cc: linux-omap@vger.kernel.org; Reddy, Teerth; Sripathy, Vishwanath
Subject: Re: [PATCH v4 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall
latency during DVFS
Gurav , Pramod
-Original Message-
From: K, Ambresh
Sent: Thursday, March 18, 2010 12:48 PM
To: Gurav , Pramod
Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
Subject: Re: [PATCH v2 2/2] OMAP3630 SDRC: Change in DVFS Latency Formula for
OMAP3630
Gurav , Pramod wrote:
This patch uses new
When the 32k sync timer is used for sched_clock(), it should count
time from the kernel boot (clocksource init) instead of the last HW
reset. Otherwise printk.time values will jump suddenly during the boot:
[0.00] calling omap2_clk_arch_init+0x0/0x138 @ 1
[0.00]
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen
Sent: Friday, March 12, 2010 4:22 PM
To: ext Steve Sakoman
Cc: linux-omap@vger.kernel.org
Subject: Re: kernel panic with latest DSS
Can you try this
Kevin Hilman had written, on 03/18/2010 05:49 PM, the following:
Nishanth Menon n...@ti.com writes:
BUG_ON should not ideally contain a functional code. Remove it out.
True. But this code should not be using BUG_ON() in the first place.
We should not crash the whole kernel in this case,
Cousson, Benoit had written, on 03/19/2010 05:14 AM, the following:
Hi Nishanth,
From: Menon, Nishanth
Sent: Thursday, March 18, 2010 7:45 PM
Many modules seem to need some sort of flexible storage mechanism
which is corresponds to a specific opp. To cater to this need, we
provide store,
hi,
On Thu, Mar 18, 2010 at 07:44:50PM +0100, ext Nishanth Menon wrote:
+int opp_store_data(struct omap_opp *opp, char *name, void *data)
+{
+ return -EINVAL;
Would -ENODATA fit better ??
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index bb8120e..15f6f7c 100644
On Thu, Mar 18, 2010 at 07:44:51PM +0100, ext Nishanth Menon wrote:
@@ -131,5 +133,16 @@ void __init omap3_pm_init_opp_table(void)
r |= opp_init_list(OPP_L3, omap3_opp_def_list[1]);
r |= opp_init_list(OPP_DSP, omap3_opp_def_list[2]);
BUG_ON(r);
+
+ /* First get the
On Fri, Mar 19, 2010 at 03:21:34PM +0100, ext Nishanth Menon wrote:
Kevin Hilman had written, on 03/18/2010 05:49 PM, the following:
Nishanth Menon n...@ti.com writes:
BUG_ON should not ideally contain a functional code. Remove it out.
True. But this code should not be using BUG_ON() in
Felipe Balbi had written, on 03/19/2010 09:47 AM, the following:
On Thu, Mar 18, 2010 at 07:44:51PM +0100, ext Nishanth Menon wrote:
@@ -131,5 +133,16 @@ void __init omap3_pm_init_opp_table(void)
r |= opp_init_list(OPP_L3, omap3_opp_def_list[1]);
r |= opp_init_list(OPP_DSP,
On Fri, Mar 19, 2010 at 1:51 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I tried to rebase this patch on top of the latest head and the
user-space client never gets notified of the MMUFAULT. After manually
killing the process, the DSP is restarted correctly though.
Strike that.
* Russell King - ARM Linux li...@arm.linux.org.uk [100319 01:49]:
On Thu, Mar 18, 2010 at 06:35:21PM -0700, Tony Lindgren wrote:
-#if defined(CONFIG_HAS_TLS_REG)
- mcr p15, 0, r3, c13, c0, 3 @ set TLS register
-#elif !defined(CONFIG_TLS_REG_EMUL)
- mov r4, #0x0fff
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe
Contreras
Sent: Friday, March 19, 2010 10:54 AM
To: Guzman Lugo, Fernando
Cc: linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande;
Lesly Arackal Manuel lesl...@ti.com writes:
[...]
Please fix the changelog to not only summarize *what* is being changed,
but *why*.
[Lesly] Why the order is not important.
Since each seq is independent and not falling trough any other seq.
Only thing we have to do is program the start
Aaro Koskinen aaro.koski...@nokia.com writes:
When the 32k sync timer is used for sched_clock(), it should count
time from the kernel boot (clocksource init) instead of the last HW
reset. Otherwise printk.time values will jump suddenly during the boot:
[0.00] calling
Nishanth Menon n...@ti.com writes:
Kevin Hilman had written, on 03/18/2010 05:49 PM, the following:
Nishanth Menon n...@ti.com writes:
BUG_ON should not ideally contain a functional code. Remove it out.
True. But this code should not be using BUG_ON() in the first place.
We should not
Hi,
On Fri, Mar 19, 2010 at 10:25:18AM -0500, Nishanth Menon wrote:
Now, based on your proposal as I understand,
struct omap2_data {
blah_o21
blah_o22
};
struct omap3_data {
blah_o31
blah_o32
blah_o33
}
struct omap4_data {
blah_o41
blah_o42
blah_o31
blah_o32
}
and so on
On Fri, Mar 19, 2010 at 10:46:54AM -0700, Kevin Hilman wrote:
IMO, Using BUG* macros usually indicates improper or incomplete error
handling rather than a real catastrophic system failure.
on the other hand a kernel oops and system hang will always get noted. Rather
than a WARN() which simply
Felipe Balbi had written, on 03/19/2010 12:47 PM, the following:
[...]
now in the approach I took,
you could have:
struct sr_ntarget_type{
unsigned long nTarget;
something else if needed
}
And in SR driver, the module doesnot need to care which silicon it is
running on.. it
Felipe Balbi m...@felipebalbi.com writes:
On Fri, Mar 19, 2010 at 10:46:54AM -0700, Kevin Hilman wrote:
IMO, Using BUG* macros usually indicates improper or incomplete error
handling rather than a real catastrophic system failure.
on the other hand a kernel oops and system hang will always
On Fri, Mar 19, 2010 at 6:18 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Mar 19, 2010 at 6:05 PM, Hebbar, Shivananda x0heb...@ti.com wrote:
Client app must register for MMUFault/DSPSysError events. Then only
You will receive notifications.
It is registered, and it was
Only 3430 and 3630 TRMs says 0xd, 0xe, 0xf = Division not supported.
I tested a 3503 with clock divider values of 0x0d, 0x0e and 0x0f.
It worked fine.
I collected data off the SPI bus successfully at the expected
frequencies of 5859 Hz, 2929 Hz and 1464 Hz.
But then again, the TRMs can have
Kevin Hilman had written, on 03/19/2010 01:42 PM, the following:
Felipe Balbi m...@felipebalbi.com writes:
On Fri, Mar 19, 2010 at 10:46:54AM -0700, Kevin Hilman wrote:
IMO, Using BUG* macros usually indicates improper or incomplete error
handling rather than a real catastrophic system
* Scott Ellis sc...@jumpnowtek.com [100319 12:43]:
Only 3430 and 3630 TRMs says 0xd, 0xe, 0xf = Division not supported.
I tested a 3503 with clock divider values of 0x0d, 0x0e and 0x0f.
It worked fine.
I collected data off the SPI bus successfully at the expected
frequencies of 5859 Hz,
Nishanth Menon n...@ti.com writes:
Kevin Hilman had written, on 03/19/2010 01:42 PM, the following:
Felipe Balbi m...@felipebalbi.com writes:
On Fri, Mar 19, 2010 at 10:46:54AM -0700, Kevin Hilman wrote:
IMO, Using BUG* macros usually indicates improper or incomplete error
handling rather
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Friday, March 19, 2010 1:00 PM
To: Hebbar, Shivananda
Cc: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya
Palande; felipe.contre...@nokia.com
Subject: Re: [PATCH 2/2] DSPBRIDGE: DSP
Kevin Hilman had written, on 03/19/2010 03:49 PM, the following:
Nishanth Menon n...@ti.com writes:
Kevin Hilman had written, on 03/19/2010 01:42 PM, the following:
Felipe Balbi m...@felipebalbi.com writes:
On Fri, Mar 19, 2010 at 10:46:54AM -0700, Kevin Hilman wrote:
IMO, Using BUG*
On Fri, Mar 19, 2010 at 11:49 PM, Guzman Lugo, Fernando x0095...@ti.com wrote:
Do you mean applying DSP recovery process you are no able to receive MMUFault
notifications?
I am going to check that case. Is there any possibility that the process is
stuck waiting other event?
I think
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Friday, March 19, 2010 4:11 PM
To: Guzman Lugo, Fernando
Cc: Hebbar, Shivananda; linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya
Palande; felipe.contre...@nokia.com
Subject: Re: [PATCH 2/2] DSPBRIDGE: DSP
Hi all,
Got a zoom3 finally! This is needed to boot with DEBUG_LL + earlyprintk.
Regards,
Tony
From d1fa6f3fbc46546f3ade9026dcba80d6fd5bd6bd Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Fri, 19 Mar 2010 17:18:45 -0700
Subject: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3
* Tony Lindgren t...@atomide.com [100319 17:30]:
Hi all,
Got a zoom3 finally! This is needed to boot with DEBUG_LL + earlyprintk.
And of course it won't compile because of a missing #.
Here's the working version.
Tony
From d1d25009c085a2ea677da6bc2c905fbcf98e224e Mon Sep 17 00:00:00 2001
* Tony Lindgren t...@atomide.com [100319 17:42]:
* Tony Lindgren t...@atomide.com [100319 17:30]:
Hi all,
Got a zoom3 finally! This is needed to boot with DEBUG_LL + earlyprintk.
And of course it won't compile because of a missing #.
Here's the working version.
One more time. Looks
* Tony Lindgren t...@atomide.com [100319 19:43]:
* Tony Lindgren t...@atomide.com [100319 17:42]:
* Tony Lindgren t...@atomide.com [100319 17:30]:
Hi all,
Got a zoom3 finally! This is needed to boot with DEBUG_LL + earlyprintk.
And of course it won't compile because of a missing
49 matches
Mail list logo
