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 device up.
>>>
>>> This solves
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
[]
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
---
changes since v2:
-
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
Signed-off-by:
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 Menon
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 th
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
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 just
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 immu
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()
i
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 a/arch/arm/mach-omap2/timer.c b/arch/arm/
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
coupling
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 +
arch/arm/boot/dts/am437x-gp-evm.dts
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 | 121 +
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 ++--
arch/arm/mach-omap2/common.h
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 a/arch/arm/mach-omap2/timer.c b/arc
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
---
arch/arm/mach-omap2/timer.c | 70 ++
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(-)
diff --git a/ar
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 +-
arch/arm/mach-omap2/boar
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 | 2 +-
arch/arm/
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 insertions(+), 19 deletion
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):
t
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
---
.../devicetree/bindings/thermal/ti_soc_thermal.txt |
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.
> >
> > Cc: Zhang
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
---
.../devicetree/bindings/thermal/ti_soc_thermal.txt | 7 ++
drivers/thermal/ti-so
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 m
26 matches
Mail list logo