[PATCH v2] clk: ti: fix dual-registration of uart4_ick

On the OMAP AM3517 platform the uart4_ick gets registered twice, causing any power managment to /dev/ttyO3 to fail when trying to wake the device up. This solves the following oops: [] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008 [] PC is at serial_omap_pm+0x48/0x15c

Re: [PATCH] clk: ti: fix dual-registration of uart4_ick

On 25/09/15 06:42, Tero Kristo wrote: > On 09/23/2015 08:30 PM, Tony Lindgren wrote: >> * Ben Dooks [150923 07:53]: >>> On the OMAP AM3517 platform the uart4_ick gets registered >>> twice, causing any power managment to /dev/ttyO3 to fail >>> when trying to wake the

[PATCHv3] arm: omap2: timer: always define omap4_local_timer_init

omap4_local_timer_init() can be used by other platforms as is. At least AM437x wants to use it. Instead of making omap4-only and providing a stub for builds without OMAP4, we can just always define that function. Reported-by: Nishanth Menon Signed-off-by: Felipe Balbi

Re: [PATCHv4] arm: omap2: timer: always define omap4_local_timer_init

On 09/29/2015 11:15 AM, Felipe Balbi wrote: > omap4_local_timer_init() can be used by other > platforms as is. At least AM437x wants to use > it. Instead of making omap4-only and providing > a stub for builds without OMAP4, we can just > make sure that function is always available > for all SoCs

Re: [PATCHv3] arm: omap2: timer: always define omap4_local_timer_init

On 09/29/2015 10:53 AM, Felipe Balbi wrote: > omap4_local_timer_init() can be used by other > platforms as is. At least AM437x wants to use > it. Instead of making omap4-only and providing > a stub for builds without OMAP4, we can just > always define that function. > > Reported-by: Nishanth

[PATCHv4] arm: omap2: timer: always define omap4_local_timer_init

omap4_local_timer_init() can be used by other platforms as is. At least AM437x wants to use it. Instead of making omap4-only and providing a stub for builds without OMAP4, we can just make sure that function is always available for all SoCs that need it. Reported-by: Nishanth Menon

[RFC/PATCH 09/11] clocksource: add TI 32.768 Hz counter driver

Introduce a new clocksource driver for Texas Instruments 32.768 Hz device which is available on most OMAP-like devices. Signed-off-by: Felipe Balbi --- drivers/clocksource/Kconfig| 8 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/timer-ti-32k.c |

[RFC/PATCH 07/11] arm: omap2: timer: remove omap4_local_timer_init

We're now always calling clocksource_of_init() whenever booting with DT, so we can use the generic omap_sync32k_timer_init() (which will be renamed in a follow-up patch) for OMAP4 as well. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 4 ++--

[RFC/PATCH 03/11] arm: omap2: timer: remove __omap_gptimer_init()

since now we can reuse __omap_sync32k_timer_init() for OMAP3-like devices, we can safely remove __omap_gptimer_init(). Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git

[RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

All devices should have a default status. Ignoring the arguments if it should be 'okay' or 'disabled' by default, let's set them all the 'disabled' and have boards enable 32k counter. Signed-off-by: Felipe Balbi --- arch/arm/boot/dts/am4372.dtsi | 1 +

[PATCH 1/2] ti-soc-thermal: implement omap3 support

From: Pavel Machek This adds support for OMAP3 chips to ti-soc-thermal. As requested by TI people, it is marked unreliable and warning is printed. Signed-off-by: Pavel Machek Signed-off-by: Eduardo Valentin ---

[PATCH 0/2] thermal: omap3 support

Folks, I am add these two patches for next merge window. Pavels patch was idling for some time in the mailing list and I found it and gave it a try. In the process, added 36xx support too. DTS part is not done though. Anyways, they are in linux-next now. Have fun. BR, Eduardo Valentin (1):

[PATCH 2/2] thermal: ti-soc-thermal: add OMAP36xx support

Add OMAP36xx support to ti-soc-thermal driver. This chip is also unreliable. The data provided here is based on OMAP36xx TRM: http://www.ti.com/lit/ug/swpu177aa/swpu177aa.pdf Signed-off-by: Eduardo Valentin Signed-off-by: Eduardo Valentin ---

Re: [PATCHv3 1/1] ti-soc-thermal: implement omap3 support

On Tue, Sep 15, 2015 at 01:24:16PM +0200, Pavel Machek wrote: > On Wed 2015-09-09 21:58:09, Eduardo Valentin wrote: > > From: Pavel Machek > > > > This adds support for OMAP3 chips to ti-soc-thermal. As requested by > > TI people, it is marked unreliable and warning is printed. > >

[RFC/PATCH 00/11] arm: omap: counter32k rework

Hi, the following patches de-obfuscate arch/arm/mach-omap2/timer.c and start moving code to drivers/clocksource. So far only counter32k has been moved over. Note that we can't get rid of all the code (yet) because there are still platforms relying to legacy boot and because of the strong

[RFC/PATCH 05/11] arm: omap2: timer: move realtime_counter_init() around

no functional changes, just moving that function closer to its calling location. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 102 ++-- 1 file changed, 50 insertions(+), 52 deletions(-) diff --git

[PATCH] clk: ti: dflt: fix enable_reg validity check

The default clock enabling functions for TI clocks - omap2_dflt_clk_enable() and omap2_dflt_clk_disable() perform a NULL check for the enable_reg field of the clk_hw_omap structure. This enable_reg field however is merely a combination of the index of the master IP module, and the offset from the

[RFC/PATCH 02/11] arm: omap2: timer: add a gptimer argument to sync32k_timer_init()

as it turns out, __omap_gptimer_init() and __omap_sync32k_timer_init() are essentially the same thing, but __omap_gptimer_init() wants to always use gptimer. Instead of forcing all those devices to pass a use_gptimer cmdline argument, we add a new function argument to __omap_sync32k_timer_init()

[RFC/PATCH 04/11] arm: omap2: timer: provide generic sync32k_timer_init function

instead of constantly defining a small wrapper around __omap_sync32k_timer_init(), let's define a generic one which can be used by all OMAPs. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 10 +- arch/arm/mach-omap2/board-ldp.c | 2 +-

[RFC/PATCH 08/11] arm: omap2: timer: rename omap_sync32k_timer_init()

this function is not only about the 32k sync timer, it's OMAP's generic init_time implementation. Let's rename it to make that detail easier to notice. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 14 +++--- arch/arm/mach-omap2/board-ldp.c |

[RFC/PATCH 10/11] arm: omap2: timer: limit hwmod usage to non-DT boots

now that we have a working 32k clocksource driver, we can limit HWMOD usage to non-DT boots and rely on clocksource_of_init() every time we boot with DT. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 30 +++--- 1 file changed, 11

[RFC/PATCH 01/11] arm: omap2: timer: get rid of obfuscating macros

those macros just make it a lot more difficult to grep around and actually find similarities. In this patch, we will simply remove them and replace with actual functions and later commits will come to further clean this up. Signed-off-by: Felipe Balbi ---

[RFC/PATCH 06/11] arm: omap2: timer: always call clocksource_of_init() when DT

If booting with DT, let's make sure to always call clocksource_of_init() as this will make it easier to move timer code to drivers/clocksource in the future. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)

RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

Hello Robert, > From: Robert Schwebel [mailto:r.schwe...@pengutronix.de] > Sent: Tuesday, September 29, 2015 12:50 PM > > -1- > > Barrier side effects of the patch may be beneficial for other reasons. But > AM335x should be immune from this particular issue. > > Is this a matter of fact, or

Re: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

Hi Richard, On Fri, Sep 25, 2015 at 08:44:29PM +, Woodruff, Richard wrote: > > From: Menon, Nishanth > > Sent: Friday, September 25, 2015 9:44 AM > > > > If I688 is not needed on am335x, then it seems there are still some > > > mysteries remaining with this erratum to unravel. Something like

Re: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

On Tue, Sep 29, 2015 at 06:06:36PM +, Woodruff, Richard wrote: > > From: Robert Schwebel [mailto:r.schwe...@pengutronix.de] > > Sent: Tuesday, September 29, 2015 12:50 PM > > > -1- > > > Barrier side effects of the patch may be beneficial for other reasons. > > > But > > AM335x should be