OMAP3 clocks with ARM vs Thumb

[Adam Ford]

The arch/arm/mach-omap2/omap3/clock.c is being forced to compile with
an ARM target even when thumb2 is the preferred target.  The note in
the makefile states it's due to a bootup issue with OMAP35.

Since Thumb2 can help reduce code size, I thought I'd run some tests.

The DM3730 can boot with clock.c built for Thumb2, but I can confirm
that omap3530 still fails.  Instead of tuning the entire file for ARM,
I thought I might try to identify which function needs to be compiled
for ARM.

I was able to set the target attribute for prcm_init() to build for
ARM while compiling the rest of the file for Thumb, and the OMAP3530
was able to successfully boot.
Unfortunately, doing that broke the DM3730.

I started looking at the differences between the OM36xx and OM34xx
inside prcm_init() it appears as if there are a bunch of static
functions that are unique to either omap34 or omap36, but they are not
drastically different except for one area where some math is done to a
pointer on the OMAP35 and not on the OMAP36/DM7.

/* Moving to the right sysclk and ES rev base */
ptr = ptr + (3 * clk_index) + sil_index;

I could be nothing, but I am not well versed in Thumb2 assembly.  If
someone has any suggestions to try, it would be nice to be able to let
the file be built for Thumb2 for both OMAP35 and OMAP36/DM37.

adam