Hello Janusz,
On Thursday 03 December 2009 14:31:20 ext Janusz Krzysztofik wrote:
> > Sorry, but I have totally missed the discussion about this in l-o..
> > It looks good for me as well, the only comment I have is the same as
> > Jarkko for patch 3.
> > I was about to give it a try, but since Jar
You can use so called "auto idle".
I.e. Disable clocks (iclk, fclk) when there is no activities for
certain period of time
- Hu Tao
On Wed, Dec 2, 2009 at 5:32 PM, tarek attia wrote:
>
> I'm not talking about full chip off in suspend ,,but I'm talking about
> tern off some modules while they are
The OMAP usb header file will move in the same merge window as this
driver is getting introduced in, so update the driver now instead of
making a merge-order-dependent patch later on through linux-omap.
Signed-off-by: Olof Johansson
Acked-by: Tony Lindgren
---
Greg, see below for history (you
Thursday 03 December 2009 21:03:02 Tony Lindgren napisał(a):
> Hi,
>
> * Janusz Krzysztofik [091203 04:29]:
> > Reserve space inside omap_mcbsp structure for storing cached copies of
> > McBSP register values.
> > Modify the MCBSP_WRITE() macro to update the cache with every register
> > write ope
On 02/12/09 17:19, Sid Boyce wrote:
> On 02/12/09 17:04, Gadiyar, Anand wrote:
>> Sid Boyce wrote:
>>> Greg,
>>> I've been told you have had the patch on your queue for quite some time.
>>> I don't have the patch details to hand, but drivers/usb/Kconfig and may
>>> be 2 other files affected. I have
OMAP3xxx and OMAP4430 UART IP blocks have a restriction wrt RX FIFO.
Empty RX fifo read causes an abort.
OMAP3xxx:
UART IP revision >= 0x52 have this issue
MVR register format is:
Bits Field Name Description Type Reset
31:8 RESERVED
* Cory Maccarrone [091203 14:08]:
> On Thu, Dec 3, 2009 at 9:36 AM, Tony Lindgren wrote:
> > Hi all,
> >
> > As 2.6.32 is out, I'm planning to send Linus a pull request
> > for the code we have currently in for-next. That's already
> > a huge pile of code with the 7xx merge, header move, and
> >
On Thu, Dec 3, 2009 at 9:36 AM, Tony Lindgren wrote:
> Hi all,
>
> As 2.6.32 is out, I'm planning to send Linus a pull request
> for the code we have currently in for-next. That's already
> a huge pile of code with the 7xx merge, header move, and
> ioremap changes, pm etc:
>
> Then I'll pile up an
Pandita, Vikram wrote:
> >
> >+ if (!int_hsdma) {
> >+ DBG(2, "spurious DMA irq\n");
> >+
> >+ for (bchannel = 0; bchannel < MUSB_HSDMA_CHANNELS;
> >bchannel++) {
> >+ musb_channel = (struct musb_dma_channel *)
> >+
Anand
>From: Anand Gadiyar
>
>MUSB DMA_INTR register may sometimes read zero when infact there
>
>was a pending interrupt. Workaround this by reading the DMA_COUNT
>values for all enabled channels when this condition occurs.
>Flag these channels as the ones needing to be serviced.
>
>Signed-off-b
* Vimal Singh [091202 06:09]:
> >> >> From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001
> >> >> From: Vimal Singh
> >> >> Date: Thu, 19 Nov 2009 19:28:11 +0530
> >> >>
> >> >> This patch series adds flash support for NAND (in sdp, zoom and ldp),
> >> >> OneNAND and NOR (in sd
Hi,
* Janusz Krzysztofik [091203 04:29]:
> Reserve space inside omap_mcbsp structure for storing cached copies of McBSP
> register values.
> Modify the MCBSP_WRITE() macro to update the cache with every register write
> operation.
> Introduce a new macro that reads from the cache instead of hardw
>-Original Message-
>From: Tony Lindgren [mailto:t...@atomide.com]
>Sent: Thursday, December 03, 2009 12:45 PM
>To: Pandita, Vikram
>Cc: linux-omap@vger.kernel.org
>Subject: Re: Merge plans for 2.6.33 merge window
>
>* Pandita, Vikram [091203 10:27]:
>> Tony
>>
>> >-Original Message-
* Artem Bityutskiy [091203 00:46]:
> On Thu, 2009-12-03 at 08:56 +0200, Mika Westerberg wrote:
> > On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote:
> > > * Grant Likely [091202 07:06]:
> > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren
> > > > wrote:
> > > > > * Grant Lik
Hi,
You are right, I checked u-boot from BSP 2.1.1.7 and BSP 2.1.3.11. Is
there any reason to do thing in this way?
I use the u-boot from BSP 1.0.0.
Regards
Wending
>-Original Message-
>From: Gary Thomas [mailto:g...@mlbassoc.com]
>Sent: December 3, 2009 2:18 PM
>To: Weng, Wendi
On 12/03/2009 11:57 AM, Weng, Wending wrote:
Hi,
In the u-boot for omap3evm I use, cleanup_before_linux(in
cpu/omap3/cpu.c or cpu/arm_cortexa8/cpu.c) turns off L2 cache by mistake, it
should not. This causes serious performance problem for me.
The following line "#ifndef CON
Hi,
In the u-boot for omap3evm I use, cleanup_before_linux(in
cpu/omap3/cpu.c or cpu/arm_cortexa8/cpu.c) turns off L2 cache by mistake, it
should not. This causes serious performance problem for me.
The following line "#ifndef CONFIG_L2_OFF" should be "#ifdef
CONFIG_L2_OFF".
#i
* Pandita, Vikram [091203 10:27]:
> Tony
>
> >-Original Message-
> >From: linux-omap-ow...@vger.kernel.org
> >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
> >Lindgren
> >Sent: Thursday, December 03, 2009 11:36 AM
> >To: linux-omap@vger.kernel.org
> >Subject: Merge plans fo
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Weng,
>Wending
>Sent: Thursday, December 03, 2009 12:32 PM
>To: linux-omap@vger.kernel.org
>Subject: u-boot for omap3
>
>Hi all,
>
>Anybody knows who takes care of
Hi all,
Anybody knows who takes care of u-boot for omap3, I wish to fix a L2
cahe related bug if it's not done yet.
Regards
Wending
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
Tony
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
>Lindgren
>Sent: Thursday, December 03, 2009 11:36 AM
>To: linux-omap@vger.kernel.org
>Subject: Merge plans for 2.6.33 merge window
>
>Hi all,
>Then there are som
>-Original Message-
>From: Paul Walmsley [mailto:p...@pwsan.com]
>Sent: Thursday, December 03, 2009 7:01 AM
>To: Sonasath, Moiz
>Cc: linux-omap@vger.kernel.org; Pandita, Vikram; G, Manjunath Kondaiah
>Subject: RE: I2C broken on OMAP 2430SDP?
>
>Hello Moiz,
>
>On Wed, 2 Dec 2009, Sonasath,
I've run across a semi-consistent (~15%) hang on Logic's omap3530 LV SOM
running a 2.6.28-rc8 omap kernel where it dies in twl_mmc_set_voltage().
Adding in printk's perturbs the frequency of failure, but it
consistently dies on the same call. I've added the following
printk's(and others) in twl_mmc
Hi all,
As 2.6.32 is out, I'm planning to send Linus a pull request
for the code we have currently in for-next. That's already
a huge pile of code with the 7xx merge, header move, and
ioremap changes, pm etc:
Then I'll pile up another set of changes for next week
for a second round.
We should tr
On Thu, Dec 3, 2009 at 4:15 PM, Vimal Singh wrote:
> From 948584f4157a9eb99ba085968d23add28cbfd160 Mon Sep 17 00:00:00 2001
> From: Vimal Singh
> Date: Tue, 1 Dec 2009 11:36:56 +0530
> Subject: [PATCH] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
>
> This patch adds 'board-zoom-flash.c', which co
On Thu, Dec 3, 2009 at 5:28 AM, Belisko Marek wrote:
>
> Hi,
>
> when make htcherald_defconfig on current linux-omap tree
> (82f1d8f22f2c65e70206e40a6f17688bf64a892c) compilation fails
> in drivers/video/omap/lcd_htcherald.c.
>
> Following patch fixed this problem.
Marek and I talked on IRC about
Hello Russell,
On Thu, 3 Dec 2009, Russell King - ARM Linux wrote:
> On Thu, Dec 03, 2009 at 05:33:44AM -0700, Paul Walmsley wrote:
> > My preference was to keep data separated from code in the source files; I
> > think it is slightly more readable.
>
> It's less readable because instead of hav
On Thu, Dec 03, 2009 at 05:33:44AM -0700, Paul Walmsley wrote:
> My preference was to keep data separated from code in the source files; I
> think it is slightly more readable.
It's less readable because instead of having similar stuff together, it's
at opposite ends of the file.
> The other con
>From 1786a05d3331850ff5c49e4edafe68a411597173 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Thu, 3 Dec 2009 18:26:45 +0530
Subject: [PATCH] OMAP3: Add support for NAND on LDP board
This patch adds NAND support to LDP board.
Signed-off-by: Vimal Singh
---
arch/arm/mach-omap2/Makefile|
>From 4259c6ae2e6d9b5e316fa8289a9fca729fc6bc83 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Thu, 3 Dec 2009 18:23:37 +0530
Subject: [PATCH] OMAP3: Add support for NAND on ZOOM3 board
This patch adds NAND support to ZOOM3 board.
Signed-off-by: Vimal Singh
---
arch/arm/mach-omap2/Makefile
>From 06890a29ed85068787d2bc3af3c38d29b4e0e421 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Thu, 3 Dec 2009 18:21:44 +0530
Subject: [PATCH] OMAP3: Add support for NAND on ZOOM2 board
This patch adds NAND support to ZOOM2 board.
This uses 'board-zoom-flash.c' for NAND initialization.
Signed-o
>From 948584f4157a9eb99ba085968d23add28cbfd160 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Tue, 1 Dec 2009 11:36:56 +0530
Subject: [PATCH] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
This patch adds 'board-zoom-flash.c', which could be utilized
by boards similar to ZOOM2. (For ex: LDP, ZOOM
>From 1786a05d3331850ff5c49e4edafe68a411597173 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Thu, 3 Dec 2009 18:36:11 +0530
Subject: [PATCH] Adding NAND support for LDP/ZOOM boards
'1st' patch in this series introduces 'board-zoom-flash.c' for NAND
init in ZOOM boards.
Other three patch will a
>From f48199dc44e1bf5f56aa981d20f35dc8ce1113bf Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Tue, 1 Dec 2009 11:24:46 +0530
Subject: [PATCH] OMAP3: Add support for flash on 3430SDP board
This patch adds support for flashes on 3430SDP boards. All three
NAND, NOR and OneNAND are supported. I hav
>From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Thu, 26 Nov 2009 16:10:24 +0530
Subject: [PATCH] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
This patch adds 'board-sdp-flash.c', which could be utilized
by boards similar to 3430SDP. (Fo
>From f48199dc44e1bf5f56aa981d20f35dc8ce1113bf Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Thu, 3 Dec 2009 18:35:37 +0530
Subject: [PATCH] OMAP:SDP: Add flash support for SDP boards
This patch series introduces 'board-sdp-flash.c', for flash devices init on SDP
boards.
'2nd' patch in the ser
>From fadc45cca4026d26d00a759efdc681303b0d3097 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all
>From efeeb1cfc592c827424b4c76b18150e801bdfbab Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Wed, 25 Nov 2009 17:47:46 +0530
Subject: [PATCH] Correcting GPMC_CONFIG1_DEVICETYPE_NAND
For NAND devices '2' should be used with GPMC_CONFIG1_DEVICETYPE
instead of '1'.
Signed-off-by: Vimal Singh
--
>From fadc45cca4026d26d00a759efdc681303b0d3097 Mon Sep 17 00:00:00 2001
From: Vimal Singh
Date: Thu, 3 Dec 2009 18:35:23 +0530
Subject: [PATCH] OMAP: Introducing gpmc-nand.c
This patch series introduces generic gpmc-nand.c for nand device
related gpmc init.
Vimal Singh (2):
Correcting GPMC_CON
Earlier, the hwmod code had considered the OCP_SYSCONFIG.CLOCKACTIVITY
bits to be incremental power saving bits, controlling internal IP
block clock gates. This was a misapprehension. The CLOCKACTIVITY
bits are used to indicate, in advance, which clocks will be cut when
the module acknowledges an
From: Kevin Hilman
The _dev_wakeup_lat_limit field of struct omap_device is u32, so use
UINT_MAX instead of INT_MAX for the default maximum.
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/omap_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-
From: Kevin Hilman
Following the model of to_platform_device(), add to_omap_device()
macro so a platform_device pointer can be converted into an
omap_device pointer.
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/include/plat/omap_device.h |4 +++-
1 files
From: Kevin Hilman
Use
usecs = nsecs / NSEC_PER_USEC;
instead of
usecs = nsecs * NSEC_PER_USEC;
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/omap_device.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap
Reprogram the module's OCP_SYSCONFIG register after module reset (SOFTRESET
= 1). This may not be needed, but the definition of the reset performed by
the SOFTRESET bit is unclear.
Kevin Hilman tested an earlier version of
this patch.
Signed-off-by: Paul Walmsley
Tested-by: Kevin Hilman
---
From: Kevin Hilman
Rather than having to do a usecs = nsecs / NSECS_PER_USEC to
track latency in usecs, just track it in nanoseconds.
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/include/plat/omap_device.h |4 ++--
arch/arm/plat-omap/omap_device.c
From: Kevin Hilman
WARN if a clock/hwmod is missing a clockdomain association since
resulting hwmod will not be able to correctly enable/disable clocks.
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c |3 +++
1 files changed, 3 insertions(+),
From: Kevin Hilman
During suspend and resume, when omap_device deactivation and
activation is happening, the timekeeping subsystem has likely already
been suspended. Thus getnstimeofday() will fail and trigger a WARN().
Use read_persistent_clock() instead of getnstimeofday() to avoid this.
Sig
This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP
hwmod code.
After this patch, the hwmod code will set the module AUTOIDLE bit
(generally .OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon
enable. If the hwmod flag HWMOD_NO_OCP_AUTOIDLE is set, AUTOIDLE will
be set to 0 upon enable.
Replace the existing u8 array of module MPU IRQ lines with a struct
that includes a name - similar to the existing struct
omap_hwmod_dma_info. Device drivers can then use
platform_get_resource_byname() to retrieve specific IRQs without nasty
dependencies on array ordering.
Thanks to Benoît Cousso
Hello,
This series contains some updates and bugfixes for the omap_hwmod/omap_device
code, intended for the 2.6.33 merge window.
- Paul
---
Kevin Hilman (6):
OMAP: omap_device: add to_omap_device() macro
OMAP: omap_device: use UINT_MAX for default wakeup latency limit
OMAP: o
Fix loop bailout off-by-one bugs reported by Juha Leppänen
.
This second version incorporates comments from Russell King
. A new macro, 'omap_test_timeout', has
been created, with cleaner code, and existing code has been converted
to use it.
Signed-off-by: Paul Walmsley
Cc: Juha Leppänen
Cc: R
Replace some bare constants with power states.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c|4 ++--
arch/arm/mach-omap2/powerdomain.c |2 +-
arch/arm/plat-omap/include/plat/powerdomain.h |6 --
3 files changed, 7 in
From: Thara Gopinath
MPU power domain bank 0 bits are displayed in position of bank 1
in PWRSTS and PREPWRSTS registers. So read them from correct
position
Signed-off-by: Thara Gopinath
Cc: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/powerdomain.c |6 +++
From: Roel Kluin
IS_ERR returns only 1 or 0, and the functions return a negative error
in other cases anyways.
Signed-off-by: Roel Kluin
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/powerdomain.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/
The code that reprograms the SDRC memory controller during CORE DVFS,
mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not
ensure that all L3 initiators are prevented from accessing the SDRAM
before modifying the SDRC AC timing and MR registers. This can cause
memory to be corrupted or
OMAP24xx chips don't support software-configurable sleep dependencies.
Test early for this so the compiler can redact the entire function body
on OMAP24xx.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/powerdomain.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
di
This patch rearranges the order of structure members in struct powerdomain
to avoid wasting memory due to alignment restrictions.
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/include/plat/powerdomain.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/
Avoid cluttering the Kconfig space with debug options that are rarely
used. These can now be enabled and disabled by patching the "#undef DEBUG"
in the source files with "#define DEBUG", conforming to the practice for
the rest of the linux-omap code.
Also, while we're here, some lines in plat-oma
Device drivers and loadable modules should not be calling these
prm_* and cm_* functions, so stop exporting them. Only core code
and device driver integration code (in arch/arm/*omap*) should
call these functions.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/prcm.c |6 --
1 file
Hello,
This series contains some powerdomain, clockdomain, and SDRC patches
intended for 2.6.33. There's not much of great importance here;
perhaps the most notable patch is "OMAP3: SDRC: Place SDRC AC timing
and MR changes in CORE DVFS SRAM code behind Kconfig", which can reduce
lockups on syste
The code that reprograms the SDRC memory controller during CORE DVFS,
mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not
ensure that all L3 initiators are prevented from accessing the SDRAM
before modifying the SDRC AC timing and MR registers. This can cause
memory to be corrupted o
From: Tero Kristo
Contains following fixes compared to previous version:
- vfp_pm_suspend uses the same routine as context save
- uses get_cpu / put_cpu to get current CPU id
- removed restore context call completely from OMAP3 idle (not needed)
--
To unsubscribe from this list: send the line
From: Tero Kristo
In some ARM architectures, like OMAP3, the VFP context can be lost during
dynamic sleep cycle. For this purpose, there is now a function
vfp_pm_save_context() that should be called before the VFP is assumed to
lose context. Next VFP trap will then restore context automatically.
From: Tero Kristo
VFP save context is called before MPU/NEON off. Restore is not needed as
the next VFP trap will restore context automatically. Uses the support
routine implemented in arch/arm/vfp/vfpmodule.c.
Signed-off-by: Tero Kristo
Cc: Vishwanath Sripathy
Cc: Rajendra Nayak
Cc: Richard
Hi,
when make htcherald_defconfig on current linux-omap tree
(82f1d8f22f2c65e70206e40a6f17688bf64a892c) compilation fails
in drivers/video/omap/lcd_htcherald.c.
Following patch fixed this problem.
---
drivers/video/omap/lcd_htcherald.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Hello Manjunath,
one comment below:
On Wed, 23 Sep 2009, Manjunath GK wrote:
> Current OMAP3 I2C driver code does not follow the correct sequence for soft
> reset. Due to this, lock up issues are reported during timeout/error cases.
>
> This patch fixes above issue by disabling I2C controller a
Hello Moiz,
On Wed, 2 Dec 2009, Sonasath, Moiz wrote:
> Hello Paul!
>
> Thank you for pointing this out.
>
> I think we are missing a patch here which was actually sent for up-stream but
> did not make through as I don't see it on my latest master branch.
>
> http://patchwork.kernel.org/patch
On Thu, 26 Nov 2009, Thara Gopinath wrote:
> MPU power domain bank 0 bits are displayed in position of bank 1
> in PWRSTS and PREPWRSTS registers. So read them from correct
> position
>
> Signed-off-by: Thara Gopinath
> Cc: Kevin Hilman
Thanks Thara, will queue this up.
- Paul
--
To unsubscri
Hello Russell,
On Thu, 3 Dec 2009, Russell King - ARM Linux wrote:
> On Thu, Dec 03, 2009 at 04:24:35AM -0700, Paul Walmsley wrote:
> > @@ -42,134 +47,19 @@ static void clk_omap1_dummy_disable(struct clk *clk)
> > {
> > }
> >
> > -static const struct clkops clkops_dummy = {
> > - .enable =
Thursday 03 December 2009 10:35:37 Peter Ujfalusi napisał(a):
> Hello,
>
> On Thursday 03 December 2009 09:49:05 ext Jarkko Nikula wrote:
> > On Tue, 1 Dec 2009 04:10:07 +0100
> >
> > Janusz Krzysztofik wrote:
> > > Change the way McBSP registers are maintained: store values written to
> > > the d
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta hardware. Before
that, values read back from McBSP r
Reserve space inside omap_mcbsp structure for storing cached copies of McBSP
register values.
Modify the MCBSP_WRITE() macro to update the cache with every register write
operation.
Introduce a new macro that reads from the cache instead of hardware.
Applies on top of patch 2 from this series:
[PA
On Thu, Dec 03, 2009 at 04:24:35AM -0700, Paul Walmsley wrote:
> @@ -42,134 +47,19 @@ static void clk_omap1_dummy_disable(struct clk *clk)
> {
> }
>
> -static const struct clkops clkops_dummy = {
> - .enable = clk_omap1_dummy_enable,
> - .disable = clk_omap1_dummy_disable,
> -};
...
> +
On Wed, 18 Nov 2009, Kevin Hilman wrote:
> Paul Walmsley writes:
>
> > Hi Kevin
> >
> > On Tue, 17 Nov 2009, Kevin Hilman wrote:
> >
> >> WARN if a clock/hwmod is missing a clockdomain association since
> >> resulting hwmod will not be able to correctly enable/disable clocks.
> >
> > Wouldn't th
Hi,
On Thu, Nov 26, 2009 at 07:39:59AM +0100, ext Ajay Kumar Gupta wrote:
Adding support for MUSB register save and restore during system
suspend and resume.
Changes:
- Added musb_save/restore_context() functions
- Added platform specific musb_platform_save/restore_context()
Hi,
On Thu, Dec 03, 2009 at 11:55:12AM +0100, ext Grazvydas Ignotas wrote:
TPS65950 is catalog part of TWL4030 and has documentation here:
http://focus.ti.com/docs/prod/folders/print/tps65950.html#technicaldocuments
It says that it is software's responsibility to detect the device and
set the r
On Thu, Dec 3, 2009 at 10:39 AM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Dec 02, 2009 at 11:59:22PM +0100, ext Anton Vorontsov wrote:
>>
>> On Thu, Dec 03, 2009 at 12:31:56AM +0200, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Dec 02, 2009 at 10:54:42PM +0100, ext Anton Vorontsov wrote:
>>> >As f
Hello Russell,
On Thu, 3 Dec 2009, Russell King - ARM Linux wrote:
> You say this, but you're keeping the associated code around as well
> which is pointless.
Could you elaborate?
> You also say about polluting the symbol table unnecessarily. What
> about the pollution caused by having two (or
On Thu, Dec 03, 2009 at 03:36:48AM -0700, Paul Walmsley wrote:
> Hello Russell,
>
> On Thu, 3 Dec 2009, Russell King wrote:
>
> > On Thu, Dec 03, 2009 at 03:07:08AM -0700, Paul Walmsley wrote:
> > > -static int clk_omap1_dummy_enable(struct clk *clk)
> > > +int clk_omap1_dummy_enable(struct clk *
On Thu, Dec 03, 2009 at 03:37:34AM -0700, Paul Walmsley wrote:
> Hi Russell,
>
> On Thu, 3 Dec 2009, Russell King wrote:
>
> > Also, why are you emailing me at my rmk+kernel address and claiming
> > that I used this address to make the suggestion. It was my
> > linux@ address.
> >
> > Deleting
Hi Russell,
On Thu, 3 Dec 2009, Russell King wrote:
> Also, why are you emailing me at my rmk+kernel address and claiming
> that I used this address to make the suggestion. It was my
> linux@ address.
>
> Deleting these mails from this mailbox.
Sorry about that. I'll replace the rmk+kernel@ a
Hello Russell,
On Thu, 3 Dec 2009, Russell King wrote:
> On Thu, Dec 03, 2009 at 03:07:08AM -0700, Paul Walmsley wrote:
> > -static int clk_omap1_dummy_enable(struct clk *clk)
> > +int clk_omap1_dummy_enable(struct clk *clk)
> > {
> > return 0;
> > }
> >
> > -static void clk_omap1_dummy_d
Also, why are you emailing me at my rmk+kernel address and claiming
that I used this address to make the suggestion. It was my
linux@ address.
Deleting these mails from this mailbox.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscrib
On Thu, Dec 03, 2009 at 03:07:08AM -0700, Paul Walmsley wrote:
> -static int clk_omap1_dummy_enable(struct clk *clk)
> +int clk_omap1_dummy_enable(struct clk *clk)
> {
> return 0;
> }
>
> -static void clk_omap1_dummy_disable(struct clk *clk)
> +void clk_omap1_dummy_disable(struct clk *clk
mach-omap1/clock.c:omap1_clk_disable_unused() contains a test that
assumes that the clock structures are available in the file's
namespace. After a following patch, this will no longer be the case.
So we need to reimplement that test. It turns out that we already
have a facility in the clock fram
cpu_mask is reused in the OMAP2xxx clock code to match against both the
CPU-specific rate flags (e.g., RATE_IN_2420) and the OMAP clkdev integration
code CPU flags (e.g., CK_242X). This means that any patch that renumbers the
CK_* macros, as the next patch does, will probably break. This patch
se
clock34xx.c contains some macros which probably belong in mach-omap2/sdrc.h.
Move those macros to mach-omap2/sdrc.h.
Signed-off-by: Paul Walmsley http://vger.kernel.org/majordomo-info.html
Some parts of the clock code took advantage of the fact that the statically
allocated clock tree was in clock{,24xx,34xx}.c's local namespace to do some
extra argument checks. These are overzealous and are more difficult to
maintain when the clock tree is in a separate namespace, so, remove them.
Similar to the previous patch, the APLL code relied on the presence of the
static struct clks in its own namespace. The APLL code didn't use them for
validation, however - it adjusted its own internal state depending on
the struct clk * that called it. Now that static struct clks are
leaving the
The OMAP clock code has traditionally defined its clock nodes
statically in header files (e.g., mach-omap1/clock.h). This violates
the general guideline that including a header file should be
side-effect free, or at least as side-effect free as possible. This
series moves all of the statically-al
Hello Russell,
On Tue, 1 Dec 2009, Russell King - ARM Linux wrote:
> On Tue, Dec 01, 2009 at 05:51:39AM -0700, Paul Walmsley wrote:
> > On Tue, 1 Dec 2009, Russell King - ARM Linux wrote:
> >
> > > On Tue, Dec 01, 2009 at 05:57:24PM +0530, Rajendra Nayak wrote:
> > > > This patch defines all the
On Thu, Dec 3, 2009 at 9:29 AM, Dasgupta, Romit wrote:
>
>
>> > Signed-off-by: Romit Dasgupta
>> > ---
>> > diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-
>> omap.c
>> > index 449b6b6..f94df20 100644
>> > --- a/arch/arm/plat-omap/cpu-omap.c
>> > +++ b/arch/arm/plat-omap/cpu-
Hello,
On Thursday 03 December 2009 09:49:05 ext Jarkko Nikula wrote:
> On Tue, 1 Dec 2009 04:10:07 +0100
>
> Janusz Krzysztofik wrote:
> > Change the way McBSP registers are maintained: store values written to
> > the device in a cache in order to make use of those cached values when
> > conve
On Thu, 2009-12-03 at 08:56 +0200, Mika Westerberg wrote:
> On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote:
> > * Grant Likely [091202 07:06]:
> > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren wrote:
> > > > * Grant Likely [091130 09:01]:
> >
> >
> >
> > > >
> > > > may
Hi,
On Wed, Dec 02, 2009 at 11:59:22PM +0100, ext Anton Vorontsov wrote:
On Thu, Dec 03, 2009 at 12:31:56AM +0200, Felipe Balbi wrote:
Hi,
On Wed, Dec 02, 2009 at 10:54:42PM +0100, ext Anton Vorontsov wrote:
>As for the default USB VBUS current value, it could be Kconfig
>option (something ali
Commit 10db25fea4c11661070b97832b8cc3d2af495092 causes the following
kernel messages during N800 boot (and presumably all other 2420
boards):
[0.00] BUG: mapping for 0x5800 at 0xe000 overlaps vmalloc space
[0.00] BUG: mapping for 0x5900 at 0xe100 overlaps vmalloc sp
Out of the three major OMAP2 chip types, OMAP2420, OMAP2430, and OMAP3430,
we only map the IVA on OMAP2420. The memory mapping is not shared between
OMAP2420 and OMAP2430, so it is inappropriate to label those macros as
'24XX'; this patch changes them to '2420'.
Signed-off-by: Paul Walmsley
---
2420 boots currently complain:
[0.00] BUG: mapping for 0x5800 at 0xe000 overlaps vmalloc space
[0.00] BUG: mapping for 0x5900 at 0xe100 overlaps vmalloc space
[0.00] BUG: mapping for 0x5a00 at 0xe200 overlaps vmalloc space
This short series clarifie
98 matches
Mail list logo
