> -----Original Message----- > From: Shilimkar, Santosh > Sent: Friday, September 17, 2010 5:17 AM [..] > > > -----Original Message----- > > > From: [email protected] [mailto:linux-omap- > > > [email protected]] On Behalf Of Shilimkar, Santosh > > > Sent: Friday, September 17, 2010 4:48 AM
[...] > > > --- > > > arch/arm/plat-omap/dmtimer.c | 2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- > omap/dmtimer.c > > > index 44bafda..1d706cf 100644 > > > --- a/arch/arm/plat-omap/dmtimer.c > > > +++ b/arch/arm/plat-omap/dmtimer.c > > > @@ -581,7 +581,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer > > > *timer, int source) > > > * When the functional clock disappears, too quick writes seem > > > * to cause an abort. XXX Is this still necessary? > > > */ > > > - __delay(150000); > > > + __delay(300000); > > What is the rationale for this increase? Lets say we have a CPU bumped > up > > to 1GHz or something will we have weird numbers again? > > > This is the max what we need at any clock speed. As mentioned in commit > "The timer hwmod adaptation will eventually fix it in a proper way" Okay.. taking your word for it ;) PS: hard coded numbers + delays makes the red blue and white lights in my head to go off..(it even makes the siren sound too) ;) Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
