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,
Comments inline
Thanks & Regards,
Lesly A M
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, March 19, 2010 4:51 AM
To: Lesly A M
Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
Samuel Ortiz
Subject: Re: [PATCH
Tony Lindgren wrote:
> Also, I wonder if the change __kuser_get_tls is safe?
>
> + ldr r0, [pc, #(16 - 8)] @ TLS set at 0x0ff0?
> + cmp r0, #0 @ assume hw TLS if not set
> + mrceq p15, 0, r0, c13, c0, 3 @ read TLS register
Yo
* Tony Lindgren [100318 18:31]:
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -269,6 +269,24 @@ static void __init cacheid_init(void)
> extern struct proc_info_list *lookup_processor_type(unsigned int);
> extern struct machine_desc *lookup_machine_type(unsigned int);
>
>
* Tony Lindgren [100318 09:55]:
> * Catalin Marinas [100318 04:10]:
> > On Wed, 2010-03-17 at 19:11 +, Tony Lindgren wrote:
> > > * Catalin Marinas [100317 11:04]:
> > > > On Wed, 2010-03-17 at 17:57 +, Tony Lindgren wrote:
> > > > > HAS_TLS reg is only on ARM11 starting with r1p0:
> > >
Lesly A M writes:
> Fix for TWL5030 Silicon Errata 27 & 28:
> 27 - VDD1, VDD2, may have glitches when their output value is updated.
> 28 - VDD1 and / or VDD2 DCDC clock may stop working when internal clock
> is switched from internal to external.
>
> Workaround requires the TWL DCDCs to use HFCL
Lesly A M writes:
> Copied the setuptime in each board file, since OMAP3430 & OMAP3630
> has different voltage levels for the same states.
So that suggests there should be 2 tables (one per SoC), rather than
one for each board file. IOW, the setup times are SoC specific, not
board specific, so
Lesly A M writes:
> Keeping the twl4030_config_sleep_sequence() call under the flag checking will
> fix
> the over writting of other sequences with the sleep sequences when loading
> the scripts.
Sorry, but I read this 4-5 times and still have no idea what it means,
or how it relates to this p
Tero Kristo writes:
> From: Tero Kristo
>
> Added omap3_pwrdm_set_next_pwrst and omap3_pwrdm_read_next_pwrst. These
> functions add support for INACTIVE and ON states to the standard OMAP
> powerdomain functions, and add caching logic for the next state. HW
> directly supports the reading of INA
Tero Kristo writes:
> From: Tero Kristo
>
> Added definitions for OMAP3430ES2_ST_SGX_SHIFT and OMAP3430ES2_ST_SGX_MASK
> as these were missing.
>
> Signed-off-by: Tero Kristo
FYI... looks like Paul already merged this one.
Kevin
> ---
> arch/arm/mach-omap2/cm-regbits-34xx.h |4
> 1
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 a warning.
If you're cleaning this up, can you make it fail more
There shouldn't be any dependency on the definitions generated
by autoconf.h, besides it is automatically included by the
build system.
This solves the following warning:
In file included from arch/arm/plat-omap/include/dspbridge/host_os.h:20,
from arch/arm/mach-omap2/io.c:51:
in
These patches are required for the next rebase to 2.6.33 kernel.
They fix a warning and header locations for files moved from mach
to plat.
Omar Ramirez Luna (2):
DSPBRIDGE: Remove autoconf.h dependency from host_os header
DSPBRIDGE: Fix header locations mach to plat
arch/arm/mach-omap2/dsp
Fix header locations, replaced mach to plat
Signed-off-by: Omar Ramirez Luna
Acked-by: Ameya Palande
---
arch/arm/mach-omap2/dspbridge.c|2 +-
arch/arm/plat-omap/include/dspbridge/host_os.h |2 +-
drivers/dsp/bridge/wmd/tiomap3430.c|2 +-
3 files changed,
On Thursday, March 18, 2010 12:28 PM Kevin Hilman wrote:
>
> [...]
>
>> Looks like MUA trouble. From the message headers it looks like you
>> might be using Outlook or something, I'm not sure what to suggest
>> for that - enough folks at TI are submitting patches that
>> something must've bee
Gopinath, Thara had written, on 03/18/2010 04:15 AM, the following:
[..]
This patch series is based on Kevin's PM tree origin/pm-wip-opp branch
and is dependent on the following patches not yet applied onto this branch.
http://patchwork.kernel.org/patch/81504/
http://patchwork.k
From: Phil Carmody
kernel.h provides a neat function for DIV_ROUND_UP which should
be used instead of replicating it in code
Cc: Ambresh K
Cc: Benoit Cousson
Cc: Eduardo Valentin
Cc: Kevin Hilman
Cc: Sanjeev Premi
Cc: Tero Kristo
Cc: Thara Gopinath
Signed-off-by: Nishanth Menon
Signed-o
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.
Cc: Ambresh K
Cc: Benoit Cousson
Cc: Eduardo Valentin
Cc: Kevin Hilman
Cc: Phil Carmody
Cc: Sanjeev Premi
Cc: Tero Kris
Opp layer cleanup series - tries the following:
a) remove the BUG_ON being used on functional statements
b) improve the voltage conversion routine a bit
c) introduce a per-opp data storage mechanism
d) remove the hardcoded vdd1-vdd2 thruput dependency using the generic
opp data storage mechanism
BUG_ON should not ideally contain a functional code. Remove it out.
Ref: http://marc.info/?l=linux-kernel&m=109391212925546&w=2
Cc: Ambresh K
Cc: Benoit Cousson
Cc: Eduardo Valentin
Cc: Kevin Hilman
Cc: Phil Carmody
Cc: Sanjeev Premi
Cc: Tero Kristo
Cc: Thara Gopinath
Signed-off-by: Nish
referencing l3 threshold based on OPP ID is hardcoded for OMAP3430
This is wrong when we consider OMAP3630 and beyond. use the store
and restore of data to handle this information
Cc: Ambresh K
Cc: Benoit Cousson
Cc: Eduardo Valentin
Cc: Kevin Hilman
Cc: Phil Carmody
Cc: Sanjeev Premi
Cc: Te
On Thursday, March 18, 2010 12:16 PM Mark Brown wrote:
>
> The quoted printable encoding should be fine but note that
> the 'aic26.o'
> has been word wrapped onto a new line, which is why patch
> says the diff
> is corrupted. The same word wrapping issue is occurring in
> other places
> in the
Mark Brown writes:
> On Thu, Mar 18, 2010 at 12:59:49PM -0500, Olaya, Margarita wrote:
>> From: Misael Lopez Cruz
>>
>> Initial version of TWL6040 codec driver.
>>
>> The TWL6040 codec uses a proprietary PDM-based digital audio interface.
>> Audio paths supported are:
>
> I'm getting exactly t
On Thu, Mar 18, 2010 at 12:59:49PM -0500, Olaya, Margarita wrote:
> From: Misael Lopez Cruz
>
> Initial version of TWL6040 codec driver.
>
> The TWL6040 codec uses a proprietary PDM-based digital audio interface.
> Audio paths supported are:
I'm getting exactly the same results trying to apply
From: Misael Lopez Cruz
Initial version of TWL6040 codec driver.
The TWL6040 codec uses a proprietary PDM-based digital audio interface.
Audio paths supported are:
- Input: Main Mic, Sub Mic, Headset Mic, Auxiliary-FM Left/Right
- Output: Headset Left/Right, Handsfree Left/Right
TWL6040 codec
On Wed, Mar 17, 2010 at 05:42:38PM -0500, Olaya, Margarita wrote:
> From: Misael Lopez Cruz
>
> Initial version of TWL6040 codec driver.
I'm having trouble applying this - using patch by hand says:
patching file sound/soc/codecs/Kconfig
Hunk #1 FAILED at 35.
Hunk #2 succeeded at 168 with fuzz 2
On Thu, Mar 18, 2010 at 05:38:30PM +0100, Samuel Ortiz wrote:
> On Thu, Mar 18, 2010 at 12:10:21PM +, Mark Brown wrote:
> > On Wed, Mar 17, 2010 at 05:42:29PM -0500, Olaya, Margarita wrote:
> > > Correction for chips:
> > > twl6030 is Phoenix Power chip
> > > twl6040 is Phoenix Audio chip
> >
* Catalin Marinas [100318 04:10]:
> On Wed, 2010-03-17 at 19:11 +, Tony Lindgren wrote:
> > * Catalin Marinas [100317 11:04]:
> > > On Wed, 2010-03-17 at 17:57 +, Tony Lindgren wrote:
> > > > Here's an updated version of this patch with more details.
> > > >
> > > > Looks like VFPv3 is on
On Thu, Mar 18, 2010 at 12:10:21PM +, Mark Brown wrote:
> On Wed, Mar 17, 2010 at 05:42:29PM -0500, Olaya, Margarita wrote:
> > Correction for chips:
> > twl6030 is Phoenix Power chip
> > twl6040 is Phoenix Audio chip
>
> > Signed-off-by: Margarita Olaya Cabrera
>
> Samuel, are you OK with d
On Thu, Mar 18, 2010 at 03:52:00PM +0100, Rok Markovi?? wrote:
> Yes muted sound was the culprit. :), why does not kernel enable sound by
> default and why are there so many mixer controls.
It is difficult for the kernel to know what a sensible configuration is
for all hardware at all times - mu
Hi,
first of all you shouldn't top-post.
On Thu, Mar 18, 2010 at 04:06:48PM +0200, Dmitry Kasatkin wrote:
> omap_sha1_md5_init() only able to get global dd
> no other choice.
>
> so what is the point to have it as ctx->dd.
the point of not having to global variables is that the driver should
wo
On Thu, Mar 18, 2010 at 09:52:39AM +0100, Deak Imre (Nokia-D/Helsinki) wrote:
> On Wed, Mar 17, 2010 at 09:14:25PM +0100, Syrjala Ville (Nokia-D/Helsinki)
> wrote:
> > On Wed, Mar 17, 2010 at 06:34:07PM +0100, Deak Imre (Nokia-D/Helsinki)
> > wrote:
> > > Hi,
> > >
> > > couple of minor comments
Pramod Gurav writes:
> From: Teerth Reddy
>
> The patch has the changes to calculate the dpll3 clock stabilization
> delay dynamically. The SRAM delay is calibrated during bootup using the
> gptimers and used while calculating the stabilization delay. By using
> the dynamic method the dependency
Hello,
If you are using version numbering in your patch series, please be
sure to update the version number for *all patches* in series. Even
if only one patch of the series has changed in the updated series,
please update the version number for all patches. Having different
version numbers with
Yes muted sound was the culprit. :), why does not kernel enable sound by
default and why are there so many mixer controls.
Rok
Dne četrtek 18 marca 2010 ob 15:40:02 je Jarkko Nikula napisal(a):
> Hi
>
> On Thu, 18 Mar 2010 08:23:55 +0100
>
> Rok Markovič wrote:
> > I am trying to play sound
"G, Manjunath Kondaiah" writes:
>> +#ifdef CONFIG_ARCH_OMAP3
>> +void (*_omap3_sram_delay)(unsigned int);
>> +unsigned int measure_sram_delay(unsigned int loop)
>> +{
>> +static struct omap_dm_timer *gpt;
>> +unsigned long flags, diff = 0, gt_rate, mpurate;
>> +unsigned int delay_sra
Hi
On Thu, 18 Mar 2010 08:23:55 +0100
Rok Markovič wrote:
> I am trying to play sound on overo board. With latest kernel I cannot get
> any sound, while with kernel 2.6.33-rc6-07400-ga05966f-dirty sound is
> played by ALSA correctly. I am using ALSA 1.0.22 with asound.conf like
Beagle plays
Add missing selection of CUS package.
Replace whitespace with tab.
Signed-off-by: Thomas Weber
---
arch/arm/mach-omap2/Kconfig |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a8a3d1e..e776075 100644
---
On Wed, Mar 17, 2010 at 05:42:29PM -0500, Olaya, Margarita wrote:
> Correction for chips:
> twl6030 is Phoenix Power chip
> twl6040 is Phoenix Audio chip
> Signed-off-by: Margarita Olaya Cabrera
Samuel, are you OK with doing this via the ASoC tree?
> ---
> drivers/mfd/twl-core.c |4 ++--
>
Sets the regulator values to NULL if they are not defined. This
is required to fix the kernel panic in exit path when EHCI module
is removed on the platforms where EHCI regulator are not set.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/host/ehci-omap.c |6 --
1 files changed, 4 inser
On Wed, 2010-03-17 at 19:11 +, Tony Lindgren wrote:
> * Catalin Marinas [100317 11:04]:
> > On Wed, 2010-03-17 at 17:57 +, Tony Lindgren wrote:
> > > Here's an updated version of this patch with more details.
> > >
> > > Looks like VFPv3 is only available on V7:
> > >
> > > http://www.arm.
Hi
I am trying to play sound on overo board. With latest kernel I cannot get
any sound, while with kernel 2.6.33-rc6-07400-ga05966f-dirty sound is
played by ALSA correctly. I am using ALSA 1.0.22 with asound.conf like
this:
pcm.dsp0 {
type plug
slave.pcm "dmix"
}
ctl.mixer0 {
This patch removes get_vdd1_opp and get_vdd2_opp API's and replaces
them with get_curr_vdd1_voltage and get_curr_vdd2_voltage API's.
N-target values are now linked to voltages and the link bewtween
voltage and n-target values is managed internally in smartreflex
driver and sr_devices.c
get_curr_vd
This patch introduces OMAP3 specific values for Smartreflex and
Voltage processor registers as per the latest TI recommendations.
This patch also improves the smartreflex and voltage processor
enable disable sequences as per the latest recommendations.
These recommendations were first formed based
This patch adds the hwmod strucutres and other hwmod data for
OMAP3 Smartreflex IP's.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 94
1 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3
This patch converts the exisitng smartreflex library into a
platform driver with device , driver registrations using hardware mods.
As part of this Ntarget values are passed as platform data.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/smart
This patch cleans up smartreflex.h removing all unnecessary and
duplicate definitions.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/smartreflex.h | 99 +---
1 files changed, 58 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex
This patch creates voltage.c and voltage.h files and
moves all voltage processor and voltage controller specific code
from smartreflex.c and other places in the OMAP3 codebase into
these two files.
This along with smartreflex class driver addition will make
smartreflex.c a generic driver to support
This patch adds support to pdata enable smartreflex autocompenstion
during init based on enable_on_init flag passed as pdata.
This patch also adds enabling of autocompensation by
default (setting enable_on_init flag to true) in case of ES3.1
OMAP3430 chip. In the current implementation
this step
This patch disables smartreflex across both frequency and voltage
scaling instead of just across voltage scaling as before.
This is the hardware recommended practice.
This bug was first reported and solved on Nokia N900
code base by Nishanth Menon and Paul Walmsley.
This patch also does some chang
This patch enables smartreflex class 3 driver in omap3_pm_defconfig.
Signed-off-by: Thara Gopinath
---
arch/arm/configs/omap3_pm_defconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap3_pm_defconfig
b/arch/arm/configs/omap3_pm_defconfig
index 6e8
This patch corrects typo in some of the API names in smartreflex driver.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/pm34xx.c |8
arch/arm/mach-omap2/smartreflex.c | 26 +-
arch/arm/mach-omap2/smartreflex.h |8
3 files changed, 2
This patch introduces VP force update method of voltage scaling
and enables it by default. The older method of vc bypass is now
configuratble through a menu config option. VP force update is the
hardware recommended method of voltage scaling.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2
Smartreflex error config register is special as it contains
certain status bits which if written a 1 into means a clear
of those bits. This patch takes special care during modify of
this register that no status bits in this register are accidently
set to 1.
This issue was first reported by Nishant
There are two separate modules in SmartReflex-AVS :
MinMaxAvg module and Error module. Class3 uses the Error module only.
In Class2 you can choose between either module since it is software based.
The registers are mapped to the modules as followed:
MinMaxAvg module: AccumData, MinMaxAvgEnable, Mi
OMAP3 smartreflex modules are capable of two different classes
of implementaion -
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration.
OMAP3 along with T2/Gaia supports the Class 3 implementaion.
With a different PMIC it can support Class 2 implementaio
This patch adds smartreflex class 3 driver. This driver hooks
up with the generic smartreflex driver smartreflex.c to abstract
out class specific implementations out of the generic driver.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/sm
This patch moves the hooks to enable disable smartreflex
autocompensation to pm debugfs from the /sys/power/.
To enable autocompensation for smartreflex SR do
echo 1 > /pm_debug/sr_autocomp
To disable autocompensation for smartreflex SR do
echo 0 > /pm_debug/sr_autocomp
Signed-off
This patch removes the pointer sr1, sr2 in smartreflex.c and
instead creatse a list for keeping track of multiple smartreflex
instances.. This makes it scalable for next gen OMAPs where there
are more than two smartreflex modules.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/smartreflex
The main motivations behind this patch series are the following
1. Making smartreflex a platform driver with omap-device layer.
2. Separating voltage specific code from smartreflex.c and other
locations and consolidating them into voltage.c and voltage.h.
3. Smartreflex module can have Class 3 o
On Wed, Mar 17, 2010 at 09:14:25PM +0100, Syrjala Ville (Nokia-D/Helsinki)
wrote:
> On Wed, Mar 17, 2010 at 06:34:07PM +0100, Deak Imre (Nokia-D/Helsinki) wrote:
> > Hi,
> >
> > couple of minor comments inlined.
> >
> > On Fri, Mar 05, 2010 at 02:26:19PM +0100, Syrjala Ville (Nokia-D/Helsinki)
On Wed, 2010-03-17 at 17:42 -0500, Olaya, Margarita wrote:
> From: Misael Lopez Cruz
>
> Initial version of TWL6040 codec driver.
>
> The TWL6040 codec uses a proprietary PDM-based digital audio interface.
> Audio paths supported are:
>
> - Input: Main Mic, Sub Mic, Headset Mic, Auxiliary-FM Le
On Wed, 2010-03-17 at 17:42 -0500, Olaya, Margarita wrote:
> Correction for chips:
> twl6030 is Phoenix Power chip
> twl6040 is Phoenix Audio chip
>
> Signed-off-by: Margarita Olaya Cabrera
Acked-by: Liam Girdwood
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
ht
Hi,
Valkeinen Tomi (Nokia-D/Helsinki) wrote:
Hi,
On Wed, 2010-03-17 at 13:35 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
SDI now makes use of vdds_sdi regulator supply.
DPI can now be disabled on systems that don't have it
changes since v1:
- Incorporated review comments
- no more omap3xx
Gurav , Pramod wrote:
This patch uses new formula to derive the dpll3 clock Stabilization
delay during DVFS for OMAP3630. The formula used is :
Latency = 2 * SYS_CLK + 10 * CLKOUTX2
1usec buffer time is added for safety.
Signed-off-by: Vishwanath Sripathy
Signed-off-by: Pramod Gurav
---
arc
Gurav , Pramod wrote:
From: Teerth Reddy
The patch has the changes to calculate the dpll3 clock stabilization
delay dynamically. The SRAM delay is calibrated during bootup using the
gptimers and used while calculating the stabilization delay. By using
the dynamic method the dependency on the ty
66 matches
Mail list logo
