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: NPaul Walmsley <paul@pwsan.com>

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>

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>

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>

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>