On 05/07/2014 10:19 AM, Tony Lindgren wrote: > * Joel Fernandes <joelf@xxxxxx> [140424 14:44]: >> There is a platform specific hook just for OMAP1 to set its clk parent. Remove >> this hook and have OMAP1 set its parent in omap1_dm_timer_init. If OMAP1 is >> ever migrated to clock framework, the correct way to do this would be through >> clk_set_parent like other platforms. >> >> Signed-off-by: Joel Fernandes <joelf@xxxxxx> >> --- >> arch/arm/mach-omap1/timer.c | 8 +++++++- >> arch/arm/plat-omap/dmtimer.c | 8 +++----- >> include/linux/platform_data/dmtimer-omap.h | 2 -- >> 3 files changed, 10 insertions(+), 8 deletions(-) >> >> diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c >> index bde7a35..4b9c604 100644 >> --- a/arch/arm/mach-omap1/timer.c >> +++ b/arch/arm/mach-omap1/timer.c >> @@ -140,7 +140,13 @@ static int __init omap1_dm_timer_init(void) >> goto err_free_pdata; >> } >> >> - pdata->set_timer_src = omap1_dm_timer_set_src; >> + /* >> + * Since OMAP1 doesn't support clock framework, set timer clock >> + * source to 32KHz here instead of expecting it to be set by >> + * dmtimer code. >> + */ >> + omap1_dm_timer_set_src(pdev, 0x01); >> + >> pdata->timer_capability = OMAP_TIMER_ALWON | >> OMAP_TIMER_NEEDS_RESET | OMAP_TIMER_HAS_DSP_IRQ; >> > > This does not sound right, omap1 does support clock framework just fine. > It is not using the common clock framework though. > > This breaks omap_dm_timer_set_source() for sure. Setting the source > during init is not a right solution here. Probably best to keep the > pdata hook around, drivers can support pdata and DT data together > just fine. Actually pdata hook in this case is used only in 1 place, and is OMAP1 specific so I felt its better to clean it up. Can you elaborate a bit more on why it breaks? I have no way of testing OMAP1 without hardware. What difference is it to set MOD_CONF_CTRL_1 in omap1's arch_initcall(omap1_dm_timer_init) versus doing so later? -Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
