* Shilimkar, Santosh <santosh.shilimkar@xxxxxx> [111003 22:50]: > On Tue, Oct 4, 2011 at 9:21 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > + Rajendra, Santosh, Benoît > > > > Hi > > > > On Mon, 3 Oct 2011, Tony Lindgren wrote: > > > >> * Paul Walmsley <paul@xxxxxxxxx> [110929 17:40]: > >> > On Thu, 22 Sep 2011, Keerthy wrote: > >> > > >> > > From: Vishwanath BS <vishwanath.bs@xxxxxx> > >> > > > >> > > OMAP4460 specific clocks are not getting added as the > >> > > cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes. > >> > > Changing it to add to OMAP4460 specific clocks also. > >> > > This is clocks are required of temperature sensor. > >> > > > >> > > Signed-off-by: Vishwanath BS <vishwanath.bs@xxxxxx> > >> > > Signed-off-by: Keerthy <j-keerthy@xxxxxx> > >> > > Cc: paul@xxxxxxxxx > >> > > >> > Thanks, this patch has been queued for 3.2. > >> > >> Should this be a fix for the -rc cycle instead? > > > > I don't think it's needed for the -rc series, since we don't have any > > in-tree users of the 4460 temperature sensor. The only impact I can see > > is if the bootloader enables the 4460 temperature sensor clock, and > > doesn't disable it. I assume that would probably prevent the L4 WKUP > > clockdomain from entering clock stop, which would consume a little more > > power. > > > You are correct Paul. It would have also gated the low power states > but at this point of time on mainline, we aren't supporting CORE/PER > low power states for OMAP44XX. > > IIRC, boot-loader isn't enabling the temperature > sensor clock so this patch can wait for next merge window. OK thanks, sounds like v3.2 merge window is safe for this then. Regards, Tony -- 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