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 f
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 t
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 0x
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 wrote:
> * Kevin Hilman [100310 10:01]:
> > Tony Lindgren writes:
> >
...
> > Unfortunately, Tony's additional fix did not make it into the version
> > that was merged to mainline, which results in a crash during
> > probe when using v2.6.34-rc1
From: Vaibhav Hiremath
AM3517 and DM644x uses same CCDC IP, so reusing the driver
for AM3517.
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-am3517evm.c | 160 +
1 files changed, 160 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2
From: Vaibhav Hiremath
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 support for O
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
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 18ad931..83c92cd 100644
--- a/arch/a
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
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: 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 tr
Currently on PM branch, compilation fails when cpufreq is disabled
arch/arm/mach-omap2/clock3xxx_data.c: In function 'omap3xxx_clk_init':
arch/arm/mach-omap2/clock3xxx_data.c:3563: error: 'struct clk_functions'
has no member named 'clk_init_cpufreq_table'
arch/arm/mach-omap2/clock3xxx_data.c:3564:
On Fri, 19 Mar 2010, ext Hiremath, Vaibhav wrote:
-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: ke
> -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
>
>
From: Vaibhav Hiremath
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
Acked-by: Tomi Valkeinen
---
arch/arm/mach-omap2/board-om
> -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 [mai
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
Mor
On Fri, Mar 5, 2010 at 12:12 PM, Guzman Lugo, Fernando 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 drv_release_resour
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 taki
> -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 , Pram
> -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 patc
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] in
> -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 tr
Kevin Hilman had written, on 03/18/2010 05:49 PM, the following:
Nishanth Menon 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, just fail
with
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, resto
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 l
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 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 plac
Felipe Balbi had written, on 03/19/2010 09:43 AM, the following:
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 ??
wondered later on if 0 is better h
* Russell King - ARM Linux [100319 01:50]:
> 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.
>
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, omap3
On Fri, Mar 19, 2010 at 1:51 PM, Felipe Contreras
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. MMUFAULTS are not notified e
* Russell King - ARM Linux [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
> > - str
> -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;
> felipe.contre...@
Tony,
> -Original Message-
> From: Shilimkar, Santosh
> Sent: Thursday, March 18, 2010 11:16 AM
> To: linux-omap@vger.kernel.org
> Cc: Woodruff, Richard; Shilimkar, Santosh
> Subject: [PATCH] omap4: Fix build break when used with gcc-4.4.1 (2009-q3)
>
> From: Richard Woodruff
>
> This p
On Fri, Mar 19, 2010 at 6:05 PM, Hebbar, Shivananda wrote:
> Client app must register for MMUFault/DSPSysError events. Then only
> You will receive notifications.
It is registered, and it was receiving notifications on old versions
of the bridge... not any more.
--
Felipe Contreras
--
To unsubs
"Lesly Arackal Manuel" 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 address of
Please don't top post: http://www.elinux.org/Netiquette
"Lesly Arackal Manuel" writes:
> Hi Kevin,
>
> If my understanding is correct.
>
> The clk_setuptime is board specific, depends on the osc/XTAL used on the
> board. So the clk_setuptime has to come from the board file.
>
> Volt_setuptime &
Aaro Koskinen 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 omap2_clk_arch_init+0x0/0x13
Nishanth Menon writes:
> Kevin Hilman had written, on 03/18/2010 05:49 PM, the following:
>> Nishanth Menon 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
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
> }
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 jus
Felipe Balbi 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 get
> noted. Ra
On Fri, Mar 19, 2010 at 6:18 PM, Felipe Contreras
wrote:
> On Fri, Mar 19, 2010 at 6:05 PM, Hebbar, Shivananda wrote:
>> Client app must register for MMUFault/DSPSysError events. Then only
>> You will receive notifications.
>
> It is registered, and it was receiving notifications on old versions
> 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 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
* Scott Ellis [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, 2929 Hz and 14
Nishanth Menon writes:
> Kevin Hilman had written, on 03/19/2010 01:42 PM, the following:
>> Felipe Balbi 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 catas
>-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] DSPBRIDG
Kevin Hilman had written, on 03/19/2010 03:49 PM, the following:
Nishanth Menon writes:
Kevin Hilman had written, on 03/19/2010 01:42 PM, the following:
Felipe Balbi writes:
On Fri, Mar 19, 2010 at 10:46:54AM -0700, Kevin Hilman wrote:
IMO, Using BUG* macros usually indicates improper or
On Fri, Mar 19, 2010 at 11:49 PM, Guzman Lugo, Fernando 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 mgr_wait_for_bridg
>-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] DSPBRIDG
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
Date: Fri, 19 Mar 2010 17:18:45 -0700
Subject: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3
Zoom2 and 3 have
* Tony Lindgren [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
From: Tony Lindg
* Tony Lindgren [100319 17:42]:
> * Tony Lindgren [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 like what I posted is not
* Tony Lindgren [100319 19:43]:
> * Tony Lindgren [100319 17:42]:
> > * Tony Lindgren [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
57 matches
Mail list logo
