Abhijit,
> I had used this flag earlier as there was nothing fixed as to name it as ES1
> that time. So now it can
> be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think
> CHIP_IS_OMAP4430 would be redundant
> in that case and should be removed. A patch would be essential to take
Hello Paul,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Wednesday, January 20, 2010 2:44 AM
> To: abhijit.pag...@ti.com
> Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm-
> ker..
Y, Kishore wrote:
> As per TRM, this bit is valid only for ARGB formats and experts
suggested that we can safely assume pre-multiplied data always in real
world
I asked a few experts here, and they weren't so sure, and neither am I.
I don't see any problems making this feature configurab
:) Thanks..
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, January 20, 2010 11:15 AM
> To: G.N, Vijayakumar
> Cc: Turquette, Mike; Kauppi Ari (EXT-Ixonos/Oulu); linux-omap@vger.kernel.org;
> khil...@deeprootsystems.com; Sripathy, Vishwanath
> Subject:
Hello Vijayakumar,
On Wed, 20 Jan 2010, G.N, Vijayakumar wrote:
> This seems to better than which currently I have; I will incorporate and
> test it for the same. I will add few more comments to have a better
> clarity in the same function.
That's fine but please keep in mind this section fro
Hello everyone,
We are facing an issue with Framebuffer (omapfb) driver while
starting Xorg.
Currently we are using Devkit8000 and trying to boot Linux with our inhouse
rootfs. While booting the X throws an error saying:
(EE) omapfb(0): FBIOBLANK: Invalid argument
However, X
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Tuesday, January 19, 2010 11:39 PM
> To: Turquette, Mike
> Cc: Kauppi Ari (EXT-Ixonos/Oulu); G.N, Vijayakumar;
> linux-omap@vger.kernel.org;
> khil...@deeprootsystems.com; Sripathy, Vishwanath
> Subject: Re: [PATC
We need to set the omap_chip.oc carefully for the clocks to work.
To fix this, set the omap_chip.oc in omap3_check_features() based
on the CONTROL_IDCODE and silicon revision registers.
Also add handling for 34xx es3.1.2 as es3.1 for now.
Fixes booting on at least overo board.
Based on an earli
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): de644557a6b1d76fdd266169098f25226c56f778
PatchWorks
http://patchwork.kernel.org/patch/73874/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): ee913c7626c571c04d8e4e2c60e9c3b017c84bcc
PatchWorks
http://patchwork.kernel.org/patch/73873/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 37c8293d289cce5521a3a41b16dc76778ecb7c15
PatchWorks
http://patchwork.kernel.org/patch/73871/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): fab8bd5484c20e376fb385224bfd6d3efce812a3
PatchWorks
http://patchwork.kernel.org/patch/73877/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 6bf57f2a555e6281e306e6f3c6f2589920417f05
PatchWorks
http://patchwork.kernel.org/patch/73870/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 87884cb776d702996ae49e69551b051f1f1f13cd
PatchWorks
http://patchwork.kernel.org/patch/73862/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): c82913f6ee8b9087c6d6af0dfc9f785df0b6604b
PatchWorks
http://patchwork.kernel.org/patch/73864/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 18c432f15cb98a39c8661b98492ccf35c68fde03
PatchWorks
http://patchwork.kernel.org/patch/73875/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 4216cecee0a7ded105f7dd062c11020ebd507de4
PatchWorks
http://patchwork.kernel.org/patch/73866/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): d27abb4eef3952f9b8a560ec3b58817ed3864a7c
PatchWorks
http://patchwork.kernel.org/patch/73869/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): af292b1280b7119d23e9fb38ddb550bd4145fb3b
PatchWorks
http://patchwork.kernel.org/patch/73863/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 9691b46e52d46ff385231f75e7d23be8cd8b3db1
PatchWorks
http://patchwork.kernel.org/patch/73867/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 55b1762e17a6e26f2f77193bc36baa1973affd7d
PatchWorks
http://patchwork.kernel.org/patch/73865/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 1170802cecc4cff40833b423af73eb3195bbeb15
PatchWorks
http://patchwork.kernel.org/patch/73876/
Git (Likely to change, and takes a while to get mirro
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-testing
Initial commit ID (Likely to change): 75ecde9c4fcf2ec04419f86344b523190af79704
PatchWorks
http://patchwork.kernel.org/patch/73868/
Git (Likely to change, and takes a while to get mirro
If DSP baseimage requests for invalid OPPs, do not pass them
to the rest of the linux kernel subsystem. with a test baseimage
it was found to send
IO_DispatchPM: WMDIOCTL_CONSTRAINT_REQUEST with parameter 0.
this is an invalid OPP ID and should not be passed anywhere.
we add a param check for this
* Adrian Hunter [100116 17:31]:
> From 33beb5bc36cba739971dc8919a6929925ad3dafc Mon Sep 17 00:00:00 2001
> From: Tony Lindgren
> Date: Wed, 13 Jan 2010 10:27:17 -0800
> Subject: [PATCH] omap: Add functions for dynamic remuxing of pins
>
> Make the omap_mux_read and write available for board code
Hello Sanjeev,
some comments.
On Fri, 8 Jan 2010, Sanjeev Premi wrote:
> This patch checks if clk_get() returned success for
> the clocks used in function omap2_clk_arch_init().
>
> Signed-off-by: Sanjeev Premi
> ---
> arch/arm/mach-omap2/clock34xx.c | 25 +++--
> 1 fil
writes:
>
>
>>-Original Message-
>>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: 18 January, 2010 20:41
>>To: Kristo Tero (Nokia-D/Tampere)
>>Cc: linux-omap@vger.kernel.org
>>Subject: Re: [PATCHv3 5/6] OMAP: Powerdomains: Add support for
>>checking if pwrdm/clkdm
With LOCK_DEP enabled and DEBUG_OBJECTS_TIMERS, DSPBridge
SYNC_WaitOnMultipleEvents will fail with message
"ODEBUG: object is on stack, but not annotated"
since the timeout timer is on the stack, we should rightly use
init_timer_on_stack.
Cc: Ameya Palande
Cc: Deepak Chitriki
Cc: Felipe Contrera
Hi Kevin,
On Mon, 18 Jan 2010, Kevin Hilman wrote:
> Add _MASK suffix to CM_FCLKEN_IVA2 bitfieds to conform with the rest
> of the usage in cm-regbits-34xx.h of using _SHIFT and _MASK suffixes.
>
> Signed-off-by: Kevin Hilman
By the way, I moved this patch to a 'for_2.6.33rc_e' branch, pending
Hi Tony,
The following changes since commit 7284ce6c9f6153d1777df5f310c959724d1bd446:
Linus Torvalds (1):
Linux 2.6.33-rc4
are available in the git repository at:
git://git.pwsan.com/linux-2.6 for_2.6.33rc_d
Paul Walmsley (1):
OMAP1 clock: fix for "BUG: spinlock lockup on CPU
Hi Kevin,
On Tue, 19 Jan 2010, Kevin Hilman wrote:
> Paul Walmsley writes:
>
> > OMAP clockdomains and powerdomains are currently defined statically,
> > only registered at boot, and never unregistered, so we can remove the
> > unregister function and the locking. A variant of this was origin
Paul Walmsley writes:
> OMAP clockdomains and powerdomains are currently defined statically,
> only registered at boot, and never unregistered, so we can remove the
> unregister function and the locking. A variant of this was originally
> suggested a while ago by Dmitry Baryshkov .
>
> Signed-o
Move all clksel-related clock functions from mach-omap2/clock.c to
mach-omap2/clkt_clksel.c. This is intended to make the clock code
easier to understand, since all of the functions needed to manage
clksel clocks are now located in their own file, rather than being
mixed with other, unrelated func
Move static functions to the top of the file and ensure that their names
are prefixed with an underscore to conform with the practice in the newer
OMAP clock code files.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock.c | 88 ++-
1 files chang
Mark the OMAP3-specific DPLL functions as being OMAP3-specific by moving
them from mach-omap2/dpll.c to mach-omap2/dpll3xxx.c.
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/dpll3xxx.c |0
2 files changed, 1 insertions(+),
Move all static functions up to the top of the file to match the
practice in other OMAP clock code. Make omap3_noncore_dpll_program()
static (noted by sparse) and prepend an underscore to the function
name to mark that it is file-local.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/dpll3
Move the DPLL+CORE composite clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_dpllcore.c. This is intended to make the clock
code easier to understand, since all of the functions needed to manage
the OMAP2 DPLL+CORE clock are now located in their own file, rather
than being mixed with other
Move the APLL-related clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_apll.c. This is intended to make the clock code
easier to understand, since all of the functions needed to manage APLLs
are now located in their own file, rather than being mixed with other,
unrelated functions.
Clock d
Split the DPLL3 M2 divider clock functions out of clock34xx.c and move
them into mach-omap2/clkt3xxx_dpll3m2.c. This is intended to make the
clock code easier to understand, since all of the functions needed to
manage the OMAP3 DPLL3 M2 divider are now located in their own file,
rather than being m
omap2_clk_prepare_for_reboot() is only applicable to OMAP2xxx chips,
so rename it to omap2xxx_clk_prepare_for_reboot() and only call it when
running on OMAP2xxx chips. Remove the old stub in the OMAP3 clock code.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock.h |1 -
arch/ar
Rename the omap2_clk_init() in the OMAP2, 3, and 4 clock code to be
omap2xxx_clk_init(), omap3xxx_clk_init(), etc. Remove all traces of
the (commented) old virt_prcm_set code from omap3xxx_clk_init() and
omap4xxx_clk_init(), since this will be handled with the OPP code that
is cooking in the PM br
Move the osc_clk clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_osc. This is intended to make the clock code
easier to understand, since all of the functions needed to manage the
osc_clk are now located in their own file, rather than being mixed
with other, unrelated functions.
Clock deb
Resolve all remaining sparse warnings in the OMAP clock code.
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/clock.c |2 +-
arch/arm/plat-omap/include/plat/clock.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/ar
Now that almost all of the code has been removed from clock2xxx.c and
clock34xx.c, many of the includes are now unnecessary and can be removed.
While we're here, standardize the initial comment blocks.
Signed-off-by: Paul Walmsley
Cc: Richard Woodruff
Cc: Jouni Högander
---
arch/arm/mach-omap2
In the OMAP3xxx clock code, remove the #ifdef CONFIG_ARCH_OMAP3 in
clock34xx.c, since this file is only compiled for OMAP3xxx builds. Also,
rename omap2_clk_arch_init in this file to omap3xxx_clk_arch_init() to
pave the way for multi-OMAP kernels. Ensure that it is not executed
on non-OMAP3xxx sy
omap2430_clk_i2chs_find_idlest() doesn't need to be compiled in on
non-2430 builds, so skip it in those cases to save memory.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock2xxx.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2x
Move the DVFS virtual clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_virt_prcm_set.c. This is intended to make the
clock code easier to understand, since all of the functions needed to
manage the virt_prcm_set clock are now located in their own file,
rather than being mixed with other, un
Move the sys_clk clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_sys.c. This is intended to make the clock code
easier to understand, since all of the functions needed to manage the
sys_clk are now located in their own file, rather than being mixed
with other, unrelated functions.
Clock d
Move all DPLL-related clock functions from mach-omap2/clock.c to
mach-omap2/clkt_dpll.c. This is intended to make the clock code
easier to understand, since all of the functions needed to manage
DPLLs are now located in their own file, rather than being mixed with
other, unrelated functions.
Cloc
The struct clk_functions for OMAP2, 3, and 4 are all essentially the
same, so combine them. This removes one multi-OMAP kernel impediment
and saves memory on multi-OMAP builds.
The stubs for omap2_clk_{init,exit}_cpufreq() code will removed once
the OPP layer code that's currently in Kevin's PM b
Hi,
This second version of this series improves the patch changelogs
and adds some code comments.
This patch series splits clock2xxx.c and clock34xx.c by
clock "type", e.g., DPLLs, APLLs, clksel clocks, etc. The point
is to make the code easier to read and easier to debug (by
restricting the sco
On Tue, 2010-01-19 at 22:16 +, Mark Brown wrote:
> On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
> > Maybe a standard #define WATCHDOG_NAME
> > .identity = WATCHGOD_NAME
>
> I don't really see that the indrection via the #define would buy us
> anything?
Maybe not, just a sugge
On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
> Maybe a standard #define WATCHDOG_NAME
> .identity = WATCHGOD_NAME
I don't really see that the indrection via the #define would buy us
anything?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of
vdd1_rate_table_bridge was used for determining cpu frequency
associated with an operating point. Instead of using cpu_set_freq() we
can use dsp_set_min_opp() to achieve the same thing and get rid of all
the code associated with vdd1_rate_table_bridge.
Signed-off-by: Ameya Palande
CC: Omar Ramire
Hi Alan,
> > please comment on following patch.
>
> Why move them out - why not just make them const ?
There's 2 options:
1) we only make them const now. And we move them out later when we do the
conversion to the generic watchdog api (which means that we will rip out the
code for the open, re
On Tue, Jan 19, 2010 at 16:42, Joe Perches wrote:
> On Tue, 2010-01-19 at 22:17 +0100, Wim Van Sebroeck wrote:
>> -static struct watchdog_info at32_wdt_info = {
>> +static const struct watchdog_info at32_wdt_info = {
>
> It'd be good to use a consistent structure name:
>
> static const struct watch
On Tue, 2010-01-19 at 22:17 +0100, Wim Van Sebroeck wrote:
> -static struct watchdog_info at32_wdt_info = {
> +static const struct watchdog_info at32_wdt_info = {
It'd be good to use a consistent structure name:
static const struct watchdog_info ident = {
etc...
}
$ grep -Poh "struct\s*w
On Tue, 19 Jan 2010 22:17:59 +0100
Wim Van Sebroeck wrote:
> Hi All,
>
> please comment on following patch.
Why move them out - why not just make them const ?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majo
Resending with Abhijit's correct E-mail address.
- Paul
-- Forwarded message --
Date: Tue, 19 Jan 2010 14:14:08 -0700 (MST)
From: Paul Walmsley
Subject: [PATCH] OMAP CPU ID: fix OMAP4 build failure
Hello Abhijit,
it seems that my for_2.6.34 branch does not build unless the fol
Hi All,
please comment on following patch.
Kind regards,
Wim.
commit 88d0b1a9c071d26e7b4831320067c84b04ea04a8
Author: Wim Van Sebroeck
Date: Sat Dec 26 18:55:22 2009 +
[WATCHDOG] watchdog_info separation and constify
make sure that the watchdog_info struct is seperated from
Hello Abhijit,
it seems that my for_2.6.34 branch does not build unless the following
patch, or one like it, is included. Any comments?
- Paul
From: Paul Walmsley
omap_4430sdp_defconfig currently does not build due to some missing CPU IDs:
In file included from arch/arm/mach-omap2/power
Fixes and cleanups accumulated due to baseline sync.
This set should be applied after "Return right error codes" patch set.
Fernando Guzman Lugo (4):
DSPBRIDGE: remove NLDR_Free wrapper function
DSPBRIDGE: Optimize remove resource functions
DSPBRIDGE: remove wrong comment from RequestBridge
From: Fernando Guzman Lugo
This patches prints DSP traces always removing the need to
compile debug version and enable DSP traces.
Signed-off-by: Fernando Guzman Lugo
---
drivers/dsp/bridge/wmd/io_sm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/brid
From: Fernando Guzman Lugo
This patch optimizes the remove resource functions, i.e DMM,
Stream and Nodes.
Signed-off-by: Fernando Guzman Lugo
---
drivers/dsp/bridge/rmgr/drv.c | 86 +
1 files changed, 35 insertions(+), 51 deletions(-)
diff --git a/driv
From: Fernando Guzman Lugo
This patch removes an unused variable parameter from
resource cleanup code.
Signed-off-by: Fernando Guzman Lugo
---
.../plat-omap/include/dspbridge/resourcecleanup.h |3 +--
drivers/dsp/bridge/rmgr/drv.c |5 +
drivers/dsp/bridge/rmgr
From: Fernando Guzman Lugo
This patch removes a wrong pointer and set to NULL dwSysCtrlBase
as it shouldn't be used anymore after iounmap.
Signed-off-by: Fernando Guzman Lugo
---
drivers/dsp/bridge/rmgr/drv.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/driver
Rename DEBUG to CONFIG_BRIDGE_DEBUG on preprocessor conditions
that trigger debug statements.
This was conflicting with pr_debug/dev_dbg definitions.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/dbg.h |4 ++--
drivers/dsp/bridge/Makefile|2 +-
From: Fernando Guzman Lugo
This patch removes the NLDR_Free which is a wrapper function
Signed-off-by: Fernando Guzman Lugo
---
arch/arm/plat-omap/include/dspbridge/nldr.h |1 -
arch/arm/plat-omap/include/dspbridge/nldrdefs.h |1 -
drivers/dsp/bridge/rmgr/nldr.c |
One more thing.
On Tue, 19 Jan 2010, Paul Walmsley wrote:
> On Tue, 19 Jan 2010, Ranjith Lohithakshan wrote:
>
> > diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
> > b/arch/arm/mach-omap2/cm-regbits-34xx.h
> > index 6923deb..4ff0e24 100644
> > --- a/arch/arm/mach-omap2/cm-regbits-34xx.h
> >
Hi Ranjith,
a few minor comments:
On Tue, 19 Jan 2010, Ranjith Lohithakshan wrote:
> This patch adds clock support for the following AM35xx modules
> - Ethernet MAC
> - CAN Controller (HECC)
> - New MUSB OTG Controller with integrated Phy
> - Video Processing Front End (V
Hi Ranjith,
On Tue, 19 Jan 2010, Ranjith Lohithakshan wrote:
> The patch series add support for the new modules on AM35xx IP Sub-System
> (IPSS) and incorporates all the earlier review comments.
>
> Since AM35xx follows a completely different scheme for indicating clock
> idle status, the find_i
On Fri, 15 Jan 2010, Reddy, Teerth wrote:
> Will send the updated patch.
Thanks, all your above responses make sense. What do you think about some
of the other comments I had, re: disabling interrupts, etc?
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the
Hi Felipe,
On Tue, 5 Jan 2010, Paul Walmsley wrote:
> On Tue, 5 Jan 2010, Felipe Balbi wrote:
> > On Tue, Jan 05, 2010 at 03:42:08AM +0100, ext Paul Walmsley wrote:
> > > OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array,
> > > so this patch ensures that it is freed if CPUFreq t
(cc'ing Ranjith)
Hi Alexander,
On Fri, 15 Jan 2010, Alexander Shishkin wrote:
> On Fri, Jan 15, 2010 at 02:07:04 -0700, Paul Walmsley wrote:
> > Split the DPLL3 M2 divider clock functions out of clock34xx.c and move them
> > into clkt3xxx_dpll3m2.c to improve maintainability.
>
> I'm not very f
Hi,
On Tue, 19 Jan 2010, Mike Turquette wrote:
> Kauppi Ari (EXT-Ixonos/Oulu) wrote:
> > On Mon, 2010-01-18 at 19:04 +0100, ext Paul Walmsley wrote:
(some missing attribution here)
> > > > +int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
> > > > +{
> > > > + u32 v;
> > > >
From: Fernando Guzman Lugo
This patch fixes bad error codes returned by some functions,
it validates status of previously unchecked functions and
removes unused conditional statements or status variables.
Signed-off-by: Fernando Guzman Lugo
---
drivers/dsp/bridge/rmgr/dbdcd.c | 31 -
From: Fernando Guzman Lugo
This patch fixes bad error codes returned by some functions,
it validates status of previously unchecked functions and
removes unused conditional statements or status variables.
Signed-off-by: Fernando Guzman Lugo
---
drivers/dsp/bridge/wmd/chnl_sm.c| 230 ++
This set of patches fixes the overwritten or missing error codes
returned from different bridge layers.
Fernando Guzman Lugo (3):
DSPBRIDGE: return right error codes wmd directory
DSPBRIDGE: return right error codes services directory
DSPBRIDGE: return right error codes rmgr directory
driv
From: Fernando Guzman Lugo
This patch fixes bad error codes returned by some functions,
it validates status of previously unchecked functions and
removes unused conditional statements or status variables.
Signed-off-by: Fernando Guzman Lugo
---
drivers/dsp/bridge/services/cfg.c |8 +--
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Y, Kishore
> Sent: Tuesday, January 19, 2010 6:42 PM
> To: Tomi Valkeinen
> Cc: linux-omap@vger.kernel.org
> Subject: [PATCH 1/2] OMAP: DSS: Add display board file for zo
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Y, Kishore
> Sent: Tuesday, January 19, 2010 6:39 PM
> To: Tomi Valkeinen
> Cc: linux-omap@vger.kernel.org
> Subject: [PATCH] OMAP: DSS: Add NEC NL8048HL11-01B display pan
Kauppi Ari (EXT-Ixonos/Oulu) wrote:
On Mon, 2010-01-18 at 19:04 +0100, ext Paul Walmsley wrote:
Vijayakumar, Mike,
Without this workaround the divider value goes
to its reset state after the corresponding PWRDN bit is set from the
CM_CLKEN_PLL register. The correct divider value can be restored
From: Lesly A M
omap3: pm: Use generic TRITON power scripts for ZOOM[2,3], 3630SDP board
Removed the sleep/wakeup/warm_rest sequence from the board file.
Using the api(use_generic_twl4030_script) to update
the sleep/wakeup/warm_rest sequence & voltsetup_time in the board file.
Signed-off-by: Le
From: Lesly A M
omap3: pm: Use generic TRITON power scripts for OMAP3430 board
Removed the sleep/wakeup/warm_rest sequence from the board file.
Using the api(use_generic_twl4030_script) to update
the sleep/wakeup/warm_rest sequence & voltsetup_time in the board file.
Signed-off-by: Lesly A M
C
From: Lesly A M
omap3: pm: Generic TRITON power scripts for OMAP3 based boards
Copying the sleep/wakeup/warm_rest sequence & voltsetup_time to a new
twl430 script file, since these changes are specific to the power companion
chip.
This can be used by different OMAP3 boards with the same power c
From: Lesly A M
omap3: pm: Update Triton2 scripts
Updated the sleep, wakeup & warm_reset sequence as recommended by David Derrick.
Used broadcast command, modified the resource type association and remap
sleep_state.
Added the new script changes for zoom[2,3] boards.
VDD1, VDD2 and VPLL1 are r
From: Lesly A M
omap3: pm: Using separate clk/volt setup_time for RET and OFF states
Copied the setuptime in each board file, since OMAP3430 & OMAP3630
has different voltage levels for the same states.
Made the changes to program the setup time according to
the target state of CORE power domain
From: Lesly A M
omap3: pm: re-program the sleep state of TRITON resources by modifying the
REMAP register
Removed the warning print with checking order of scripts, since the order
is not important. Only the values configured in the register, which is pointing
to
the starting address of each se
On Tue, 2010-01-19 at 06:56 +0530, Pandita, Vikram wrote:
>
> >-Original Message-
> >From: linux-omap-ow...@vger.kernel.org
> >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
> >Lindgren
> >Sent: Friday, January 15, 2010 7:35 PM
> >To: linux-arm-ker...@lists.infradead.org
> >C
map3: pm: Update TRITON power scripts and making it generic
This series of patch implements a updated TRITON power scripts.
Also moving the sleep, wakeup & warm_reset sequence to a generic script file,
which can be used by different OMAP3 board with the power companion chip
TWL4030.
V1: Initial
>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 abs
Hello Benoit,
>>You do not need the OPP table for querying voltage alone. You can read that
>>from the OMAP chip registers directly. So OPP layer is not necessary when
>>we do not use cpufreq!
>I do agree that we should not need CPUfreq, but cannot use the voltage from
>the VP either; you need t
On Tue, 19 Jan 2010, Paul Walmsley wrote:
> On Tue, 19 Jan 2010, Nayak, Rajendra wrote:
>
> > >-Original Message-
> > >From: Paul Walmsley [mailto:p...@pwsan.com]
> > >
> > >Hi Rajendra,
> > >
> > >On Mon, 18 Jan 2010, Nayak, Rajendra wrote:
> > >
> > >> Ok, so I will repost it as an att
Kishore,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Y, Kishore
> Sent: Tuesday, January 19, 2010 7:09 AM
> To: Tomi Valkeinen
> Cc: linux-omap@vger.kernel.org
> Subject: [PATCH] OMAP: DSS: Add NEC NL8048HL11-01B d
On Tue, 19 Jan 2010, Nayak, Rajendra wrote:
> >-Original Message-
> >From: Paul Walmsley [mailto:p...@pwsan.com]
> >Sent: Monday, January 18, 2010 10:42 PM
> >To: Nayak, Rajendra
> >Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> >Subject: RE: [PATCH 0/3] OMAP4: prc
Hi Kishore,
Please see my comments below.
/Mikkel
On Tue, Jan 19, 2010 at 07:09:15, Y, Kishore wrote:
> Cc: linux-omap@vger.kernel.org
> Subject: [PATCH] OMAP: DSS: Add NEC NL8048HL11-01B display panel
>
> From: Erik Gilling
>
> NEC WVGA LCD NL8048HL11-01B support has been added.
>
> Signed-
Hi Romit,
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>
>Menon, Nishanth wrote:
>> Dasgupta, Romit had written, on 01/19/2010 08:43 AM, the following:
> 3430 opps, and we should move it to opp34xx.c(I hate having new
>files :( )..
> It should be only
> #ifdef CONFIG_CPU
Dasgupta, Romit had written, on 01/19/2010 08:50 AM, the following:
Menon, Nishanth wrote:
Dasgupta, Romit had written, on 01/19/2010 08:43 AM, the following:
3430 opps, and we should move it to opp34xx.c(I hate having new files :( )..
It should be only
#ifdef CONFIG_CPU_FREQ. OPP has nothing t
Menon, Nishanth wrote:
> Dasgupta, Romit had written, on 01/19/2010 08:43 AM, the following:
3430 opps, and we should move it to opp34xx.c(I hate having new files :(
)..
It should be only
#ifdef CONFIG_CPU_FREQ. OPP has nothing to do with CONFIG_PM.
Why do you need CP
Dasgupta, Romit had written, on 01/19/2010 08:43 AM, the following:
3430 opps, and we should move it to opp34xx.c(I hate having new files :( )..
It should be only
#ifdef CONFIG_CPU_FREQ. OPP has nothing to do with CONFIG_PM.
Why do you need CPU_FREQ for suspend/resume??
voltage control - SR ne
1 - 100 of 138 matches
Mail list logo
