- 20 6月, 2012 1 次提交
-
-
由 Nishanth Menon 提交于
Commit 9fa2df6b (ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not present) makes the logic: for (i = 0; i < opp_def_size; i++) { <snip> if (!oh || !oh->od) { <snip> continue; } <snip> opp_def++; } In short, the moment we hit a "Bad OPP", we end up looping the list comparing against the bad opp definition pointer for the rest of the iteration count. Instead, increment opp_def in the for loop itself and allow continue to be used in code without much thought so that we check the next set of OPP definition pointers :) Cc: Steve Sakoman <steve@sakoman.com> Cc: Tony Lindgren <tony@atomide.com> Cc: stable@vger.kernel.org Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 23 3月, 2012 1 次提交
-
-
由 Nishanth Menon 提交于
On platforms such as OMAP3, certain variants may not have IVA, SGX or some specific component. We currently have a check to aid fixing wrong population of OPP entries for issues such as typos. This however causes a conflict with valid requirement where the SoC variant does not actually have the module present. So, reduce the severity of the print to a debug statement and skip registering that specific OPP, but continue down the list. Reported-by: NSteve Sakoman <steve@sakoman.com> Reported-by: NMaximilian Schwerin <mvs@tigris.de> Acked-by: NSteve Sakoman <steve@sakoman.com> Tested-by: NMaximilian Schwerin <mvs@tigris.de> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 16 9月, 2011 1 次提交
-
-
由 Kevin Hilman 提交于
Rather than embedding a struct platform_device inside a struct omap_device, decouple them, leaving only a pointer to the platform_device inside the omap_device. Use the arch-specific data field of the platform_device (pdev_archdata) to add an omap_device pointer after the platform_device has been created. Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 22 12月, 2010 1 次提交
-
-
由 Nishanth Menon 提交于
Add OPP data for OMAP34xx and OMAP36xx and initialization functions to populate OPP tables based on current SoC. introduce an OMAP generic opp initialization routine which OMAP3 and OMAP4+ SoCs can use to register their OPP definitions. Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-