summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/opp.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SSKevin Hilman2012-10-081-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | Currently, a dummy omap_device is created for the MPU sub-system so that a device node exists for MPU DVFS. Specifically, for the association of MPU OPPs to a device node, and so that a voltage regulator can be mapped to a device node. For drivers to get a handle to this device node, an OMAP-specific API has been used. However, the kernel already has device nodes for the CPU(s) in the system, so we can use those instead of an OMAP-specific dummy device and then drivers (like OMAP CPUfreq) can use generic APIs. To use the existing CPU device nodes, modify the OPP creation and regulator registration to use the CPU0 device node for registraion. NOTE: this patch always uses CPU0 as the device node. On all OMAPs today, MPU DVFS scales all CPUs together, so this will not be a problem, but this assumption will need to be changed if independently scalable CPUs are introduced. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* ARM: OMAP: unwrap stringsPaul Walmsley2012-09-121-9/+6
| | | | | | | | | | | | | | | | | | | | Find and unwrap wrapped strings in the style: pr_debug("clockdomain: hardware cannot set/clear wake up of " "%s when %s wakes up\n", clkdm1->name, clkdm2->name); Keeping these strings contiguous seems to be the current Linux kernel policy. The offending lines were found with the following command: pcregrep -rnM '"\s*$\s*"' arch/arm/*omap* While here, some messages have been clarified, some pr_warning( ... calls have been converted to pr_warn( ..., and some printk(KERN_* ... have been converted to pr_*. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad oneNishanth Menon2012-06-201-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9fa2df6b90786301b175e264f5fa9846aba81a65 (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: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not presentNishanth Menon2012-03-231-2/+2
| | | | | | | | | | | | | | | | | | 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: Steve Sakoman <steve@sakoman.com> Reported-by: Maximilian Schwerin <mvs@tigris.de> Acked-by: Steve Sakoman <steve@sakoman.com> Tested-by: Maximilian Schwerin <mvs@tigris.de> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* OMAP: omap_device: decouple platform_device from omap_deviceKevin Hilman2011-09-161-1/+1
| | | | | | | | | | | 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: Kevin Hilman <khilman@ti.com>
* omap: opp: add OMAP3 OPP table data and common initNishanth Menon2010-12-211-0/+93
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: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>