Re: [GIT PULL] ARM: OMAP: hwmod fix for 3.2-rc3

2011-11-21 Thread Cousson, Benoit
On 11/19/2011 12:37 AM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [16 07:27]: Hi Tony, That bug is becoming annoying, and a bunch of folks are hitting that issue during DT dev for 3.3, so it will be cool to fix that ASAP. OK pulling it in. BTW, next time, please try to

Re: [PATCH v2] ARM: OMAP2+: hwmod: Add a new state to handle hwmods left enabled at init

2011-11-21 Thread Govindraj
Hi Rajendra, On Mon, Nov 21, 2011 at 11:45 AM, Rajendra Nayak rna...@ti.com wrote: An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a driver) tries to enable it at a later point, the hwmod

Re: [PATCH v2] ARM: OMAP2+: hwmod: Add a new state to handle hwmods left enabled at init

2011-11-21 Thread Rajendra Nayak
On Monday 21 November 2011 03:33 PM, Govindraj wrote: Hi Rajendra, On Mon, Nov 21, 2011 at 11:45 AM, Rajendra Nayakrna...@ti.com wrote: An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a

[PATCH v3] ARM: OMAP2+: hwmod: Add a new state to handle hwmods left enabled at init

2011-11-21 Thread Rajendra Nayak
An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a driver) tries to enable it at a later point, the hwmod framework throws a WARN() about the device being already in enabled state. Fix this by

Re: [PATCHv9 07/18] mfd: omap-prm: added suspend prepare and complete callbacks

2011-11-21 Thread Tero Kristo
Hi Kevin, On Fri, 2011-11-18 at 11:02 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: These are needed because runtime PM is disabled during suspend, and it is bad if we get interrupts from the PRCM chain handler during it. Now, PRCM interrupt forwarding is disabled until

Re: [PATCHv9 06/18] mfd: omap-prm: added chain interrupt handler

2011-11-21 Thread Tero Kristo
On Fri, 2011-11-18 at 21:18 +0200, Felipe Balbi wrote: Hi, On Thu, Nov 17, 2011 at 02:34:46PM -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Introduce a chained interrupt handler mechanism for the PRCM interrupt, so that individual PRCM event can cleanly be handled

Re: [PATCH v8 17/20] OMAP2+: UART: Use custom activate func for console uart.

2011-11-21 Thread Govindraj
On Sat, Nov 19, 2011 at 2:54 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: Omap-uart can be used as console uart to print early boot messages using earlyprintk so for console uart prevent hwmod reset or idling during bootup. Identify the console_uart set

Re: [PATCH v8 17/20] OMAP2+: UART: Use custom activate func for console uart.

2011-11-21 Thread Govindraj
On Mon, Nov 21, 2011 at 7:17 PM, Govindraj govindraj...@gmail.com wrote: On Sat, Nov 19, 2011 at 2:54 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: Omap-uart can be used as console uart to print early boot messages using earlyprintk so for console uart

Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

2011-11-21 Thread Will Deacon
On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote: The OMAP-specific parts should be queued up in my/Benoît's/Tony's trees, rather than placed directly into -next. Otherwise they are likely to generate merge conflicts with other OMAP changes that we may generate. So I'd

Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

2011-11-21 Thread Ming Lei
Hi, On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote: The OMAP-specific parts should be queued up in my/Benoît's/Tony's trees, rather than placed directly into -next.  Otherwise they are likely to generate

Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

2011-11-21 Thread Will Deacon
On Mon, Nov 21, 2011 at 02:53:54PM +, Ming Lei wrote: On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote: The OMAP-specific parts should be queued up in my/Benoît's/Tony's trees, rather than placed

Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

2011-11-21 Thread Ming Lei
On Mon, Nov 21, 2011 at 11:16 PM, Will Deacon will.dea...@arm.com wrote: On Mon, Nov 21, 2011 at 02:53:54PM +, Ming Lei wrote: On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote: The OMAP-specific parts

Re: [PATCH] ARM: OMAP: dmtimer: fix missing content/correction in low-power mode support

2011-11-21 Thread Ramirez Luna, Omar
Hi, On Tue, Nov 8, 2011 at 12:00 AM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: Since omap_dm_timer_write_reg/__omap_dm_timer_write is now modified to use timer-func_base OCP_CFG should not use this wrapper anymore. Instead use __raw_writel() directly and use timer-io_base instead to

Re: [PATCH v2] OMAP: I2C: Fix the interrupt clearing in OMAP4

2011-11-21 Thread Kevin Hilman
Shubhrajyoti D shubhrajy...@ti.com writes: For OMAP4 Interrupt enable register is a legacy register. I don't see anything in the docs mentioning this is legacy. In fact, that register is used extensivly throughout the driver, even for OMAP4. I think the CLR/SET registers were added to aid

Re: [PATCH v3] ARM: OMAP2+: hwmod: Add a new state to handle hwmods left enabled at init

2011-11-21 Thread Kevin Hilman
Rajendra Nayak rna...@ti.com writes: An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a driver) tries to enable it at a later point, the hwmod framework throws a WARN() about the device

Re: [PATCH 4/4] mcx: initial support for HTKW mcx board

2011-11-21 Thread Ilya Yanok
Hi Tony, On 19.11.2011 04:36, Tony Lindgren wrote: Well, it already boots with DT actually. Did you mean booting with DT and board-generic? I have to admit I don't know how to proceed here: Good to hear you're already playing with it. Yes, let's work on making all the boards work with DT

[PATCH v3 0/5] common clk framework

2011-11-21 Thread Mike Turquette
Hi all, A quick refresher: the clock framework APIs in include/linux/clk.h have allowed platforms to develop their own platform-specific implementations to manage clocks; this meant that everyone had their own definition of struct clk, duplicated much code and contributed negatively to the

[PATCH v3 1/5] clk: Kconfig: add entry for HAVE_CLK_PREPARE

2011-11-21 Thread Mike Turquette
The common clk framework provides clk_prepare and clk_unprepare implementations. Create an entry for HAVE_CLK_PREPARE so that GENERIC_CLK can select it. Signed-off-by: Mike Turquette mturque...@linaro.org --- drivers/clk/Kconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff

[PATCH v3 2/5] Documentation: common clk API

2011-11-21 Thread Mike Turquette
Provide documentation for the common clk structures and APIs. This code can be found in drivers/clk/ and include/linux/clk.h. Signed-off-by: Mike Turquette mturque...@linaro.org --- Documentation/clk.txt | 312 + 1 files changed, 312

[PATCH v3 3/5] clk: introduce the common clock framework

2011-11-21 Thread Mike Turquette
The common clk framework is an attempt to define a common struct clk which can be used by most platforms, and an API that drivers can always use safely for managing clks. The net result is consolidation of many different struct clk definitions and platform-specific clk framework implementations.

[PATCH v3 4/5] clk: basic gateable and fixed-rate clks

2011-11-21 Thread Mike Turquette
Many platforms support simple gateable clks and fixed-rate clks that should not be re-implemented by every platform. This patch introduces a gateable clk with a common programming model of gate control via a write of 1 bit to a register. Both set-to-enable and clear-to-enable are supported.

[PATCH v3 5/5] clk: export tree topology and clk data via sysfs

2011-11-21 Thread Mike Turquette
Introduces kobject support for the common struct clk, exports per-clk data via read-only callbacks and models the clk tree topology in sysfs. Also adds support for generating the clk tree in clk_init and migrating nodes when input sources are switches in clk_set_parent. Signed-off-by: Mike

Re: [PATCH v2] OMAP: I2C: Fix the interrupt clearing in OMAP4

2011-11-21 Thread Shubhrajyoti
On Tuesday 22 November 2011 12:05 AM, Kevin Hilman wrote: Shubhrajyoti D shubhrajy...@ti.com writes: For OMAP4 Interrupt enable register is a legacy register. I don't see anything in the docs mentioning this is legacy. In fact, that register is used extensivly throughout the driver, even for

[PATCH v3] OMAP: I2C: Fix the interrupt clearing in OMAP4

2011-11-21 Thread Shubhrajyoti D
However on OMAP4 we were writing 1 to IRQENABLE_CLR which clears only the arbitration lost interrupt. The patch intends to fix the same by writing 0 to the IE register. Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com ---

Re: [PATCH v3] OMAP: I2C: Fix the interrupt clearing in OMAP4

2011-11-21 Thread Shubhrajyoti
On Tuesday 22 November 2011 11:31 AM, Shubhrajyoti D wrote: However on OMAP4 we were writing 1 to IRQENABLE_CLR which clears only the arbitration lost interrupt. The patch intends to fix the same by writing 0 to the IE register. Please ignore this patch I will send another one in a while.