> -----Original Message----- > From: Dasgupta, Romit > Sent: Tuesday, October 06, 2009 2:14 PM > To: Cousson, Benoit; Menon, Nishanth > Cc: Premi, Sanjeev; Kevin H; linux-omap@vger.kernel.org > Subject: RE: Question on OPP table handling > > >> Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: > >> >> Couple of opinions on why a list with disabled/invalid marker might > not > >> >> make sense as a grand unified OPP table: > >> >> a) it is no better than a list implementation > >> >> b) it is a waste of memory. > >> > [Romit] Put all the OPP tables for different OPPs in __initdata. Copy > >> the runtime detected CPU's OPP table in memory. Others get discarded! > >> > > >> I like this approach.. takers? > >> > > > >I think it is not enough. Some OPPs will be selected based on runtime CPU > >detection, but some OPPs might be disabled dynamically for some usecase > >depending of external parameters. > > [Romit] For a given SoC and type you can have only one OPP table. Isn't > that true?
Yes, it is true but you might have to disable dynamically some OPP (like OPP5 and OPP4) for thermal management reason. The way the resource is handled today, you cannot force the reduction of the frequency in case of thermal issue. I agree that there might be more elegant way to deal with that, but we can take advantage of disabling dynamically any OPP to do it. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
