On Mon, Feb 10, 2014 at 6:17 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: >> On Thu, Feb 6, 2014 at 1:26 PM, Laurent Pinchart wrote: >> > On Friday 22 June 2012 11:33:51 Laurent Pinchart wrote: >> >> On Thursday 10 February 2011 08:45:00 Kevin Hilman wrote: >> >> > Sanjeev Premi <premi@xxxxxx> writes: >> >> > > This patch adds support for speed enhanced variant of OMAP35x >> >> > > processors. These parts allow ARM and IVA running at 720MHz >> >> > > and 520MHz respectively. >> >> > > >> >> > > These parts can be detected at runtime by reading contents of >> >> > > PRODID.SKUID[3:0] at 0x4830A20C [1]. >> >> > > >> >> > > This patch specifically does following: >> >> > > * Add new OPP to omap34xx_opp_def_list[] - disabled by default. >> >> > > * Detect devices capable of running at new OPP. >> >> > > * Enable new OPP only if device supports it. >> >> > > * Check for presence of IVA before attempting to enable the >> >> > > corresponding OPP. >> >> > > >> >> > > [1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf >> >> > > >> >> > > It appears from discussions (on this patch) that a variant of >> >> > > OMAP3430 supports this OPP but lacks runtime detection. This >> >> > > OPP can be enabled for these device by either: >> >> > > 1) Setting the bit corresponding to OMAP3_HAS_720MHZ >> >> > > in 'omap3_features'. (Refer changes to id.c) >> >> > > >> >> > > 2) Removing check for omap3_has_720mhz() before enabling >> >> > > the OPP. (Refer changes to opp3xxx_data.c) >> >> > > >> >> > > 3) Calling opp_enable() for 720MHz/VDD1 and 520MHz/VDD2 in >> >> > > the board file. (Refer changes to opp3xxx_data.c). >> >> > > This should, ideally, be done before omap3_opp_init() is >> >> > > called during device_initcall(). >> >> > > >> >> > > CAUTION: This should be done for identified parts only. >> >> > > Else, the device could be damaged permanently. >> >> > > >> >> > > Signed-off-by: Sanjeev Premi <premi@xxxxxx> >> >> > > Reviewed-by: G, Manjunath Kondaiah <manjugk@xxxxxx> >> >> > >> >> > Acked-by: Kevin Hilman <khilman@xxxxxx> >> >> >> >> This patch seems to never have made it upstream. Is there a reason for >> >> that >> >> ? >> > >> > Ping ? >> >> We'd have to figure out a proper opp modifier logic with device tree. >> considering that non-dt boot is slowly getting dismantled in mach-omap2, to >> add new capabilities in non-dt is not really a good idea at this point in >> time - Further, we do have equivalent requirements in other TI SoCs as well > > Good point, but I'm not sure to see where this patch is specific to legacy > boot. The two functions it modifies, and omap3xxx_check_features() and > omap3_opp_init(), are called for DT boot as well. omap3_opp_init() ->omap_init_opp_table returns if of_have_populated_dt(). check_features enable a flag for omap3_opp_init to pick the right OPPs up -> this is precisely the intent of something like opp modifier logic. Regards, Nishanth Menon -- 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
