ARM: omap5: build opp4xxx_data.c

Building OMAP5 support without this file currently results in this link error:

arch/arm/mach-omap2/built-in.o: In function `omap54xx_voltagedomains_init':
:(.init.text+0x6b80): undefined reference to omap446x_vdd_core_volt_data' :(.init.text+0x6b84): undefined reference to omap446x_vdd_mpu_volt_data' :(.init.text+0x6b88): undefined reference to `omap446x_vdd_iva_volt_data'

Signed-off-by Arnd Bergmann <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Benoit Cousson <[email protected]>

Cc Santosh Shilimkar <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc linux-omap at vger.kernel.org

arch/arm/mach-omap2/Makefile +0 -0

index 0520dc4..f5038f5 100644

	/*
	 * XXX Will depend on the process, validation, and binning
	 * for the currently-running IC. Use OMAP4 data for time being.
	 */
#ifdef CONFIG_PM_OPP
	omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data;
	omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data;
	omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data;

#endif

Should we just remove this instead? these are obviously wrong.

Santosh,

Quoted 10 lines · Nishanth Menon

	/*
	 * XXX Will depend on the process, validation, and binning
	 * for the currently-running IC. Use OMAP4 data for time being.
	 */
#ifdef CONFIG_PM_OPP
	omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data;
	omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data;
	omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data;

#endif

Quoted 1 line

Should we just remove this instead? these are obviously wrong.

Are the OMAP4460 values expected to work and be safe for OMAP5, or not? If the latter, please send a patch to remove them.

Quoted 14 lines · Paul Walmsley

Santosh,

Quoted 10 lines · Nishanth Menon

	/*
	 * XXX Will depend on the process, validation, and binning
	 * for the currently-running IC. Use OMAP4 data for time being.
	 */
#ifdef CONFIG_PM_OPP
	omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data;
	omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data;
	omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data;

#endif

Quoted 5 lines

Quoted 1 line

Should we just remove this instead? these are obviously wrong.

Are the OMAP4460 values expected to work and be safe for OMAP5, or not? If the latter, please send a patch to remove them.

The plan was to update the data along with and VC OPP update for OMAP5 which Keerthy is working on. As such without VC code, this data is not doing anything so it is safe.

Quoted 20 lines · Santosh Shilimkar

Quoted 19 lines · Paul Walmsley

Santosh,

Quoted 11 lines · Nishanth Menon

	/*
	 * XXX Will depend on the process, validation, and binning
	 * for the currently-running IC. Use OMAP4 data for time being.
	 */
#ifdef CONFIG_PM_OPP
	omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data;
	omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data;
	omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data;

#endif

Should we just remove this instead? these are obviously wrong.

Are the OMAP4460 values expected to work and be safe for OMAP5, or not? If the latter, please send a patch to remove them.

Quoted 3 lines

The plan was to update the data along with and VC OPP update for OMAP5 which Keerthy is working on. As such without VC code, this data is not doing anything so it is safe.

opp data in mach-omap2 is no longer used. everything is moving to dts and OMAP5 is dts only. *IF* this is preventing boot, then we can hack something in while we continue to debate on what we RFCs we have posted so far.

Further, OPPs are NOT for Voltage Controller (VC). It is meant for specific domains like MPU, SGX etc.. Having that data here, especially wrong data is just plain wrong IMHO.

Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5

Quoted 6 lines · Santosh Shilimkar

Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5

I really wish the OMAP5 devices(the latest ones from Fab) I have would like to function at OMAP4 configurations! Unfortunately the devices tend to follow the data manual for OMAP5.
*if* there is no need for it to boot, I suggest removing it.

Quoted 8 lines · Nishanth Menon

Quoted 6 lines · Santosh Shilimkar

Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5

Quoted 5 lines

I really wish the OMAP5 devices(the latest ones from Fab) I have would like to function at OMAP4 configurations! Unfortunately the devices tend to follow the data manual for OMAP5.
*if* there is no need for it to boot, I suggest removing it.

I don't understand you. For OMAP5, that data without voltage controller support doesn't do anything bad. Since there was some dependency of voltage domain association whit PD's, I have to keep that. I never claimed that OMAP4 settings would work for OMAP5 in absolute terms.

Feel free to post a patch with right data which you seems to have. I don't mind you removing that data as long as the device continues to boot. Patch welcome.

Quoted 20 lines · Santosh Shilimkar

Quoted 8 lines · Nishanth Menon

Quoted 6 lines · Santosh Shilimkar

Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5

Quoted 5 lines

I really wish the OMAP5 devices(the latest ones from Fab) I have would like to function at OMAP4 configurations! Unfortunately the devices tend to follow the data manual for OMAP5.
*if* there is no need for it to boot, I suggest removing it.

I don't understand you. For OMAP5, that data without voltage controller support doesn't do anything bad. Since there was some dependency of voltage domain association whit PD's, I have to keep that. I never claimed that OMAP4 settings would work for OMAP5 in absolute terms.

Quoted 3 lines

Feel free to post a patch with right data which you seems to have. I don't mind you removing that data as long as the device continues to boot. Patch welcome.

Thanks to Rajendra's cleanup, I don't think we need dummy data anymore:

   http://marc.info/?l=linux-omap&m=137147503827947&w=2

That series is queued for v3.11.

Quoted 26 lines · Kevin Hilman

Quoted 23 lines · Santosh Shilimkar

Quoted 8 lines · Nishanth Menon

Quoted 6 lines · Santosh Shilimkar

Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5

Quoted 5 lines

I really wish the OMAP5 devices(the latest ones from Fab) I have would like to function at OMAP4 configurations! Unfortunately the devices tend to follow the data manual for OMAP5.
*if* there is no need for it to boot, I suggest removing it.

I don't understand you. For OMAP5, that data without voltage controller support doesn't do anything bad. Since there was some dependency of voltage domain association whit PD's, I have to keep that. I never claimed that OMAP4 settings would work for OMAP5 in absolute terms.

Feel free to post a patch with right data which you seems to have. I don't mind you removing that data as long as the device continues to boot. Patch welcome.

Quoted 6 lines

Thanks to Rajendra's cleanup, I don't think we need dummy data anymore:

   http://marc.info/?l=linux-omap&m=137147503827947&w=2

That series is queued for v3.11.

I knew the series but wasn't sure about it getting queued up for 3.11. Nice to see the dependency is getting removed.

Quoted 27 lines · Santosh Shilimkar

Quoted 26 lines · Kevin Hilman

Quoted 23 lines · Santosh Shilimkar

Quoted 8 lines · Nishanth Menon

Quoted 6 lines · Santosh Shilimkar

Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5

Quoted 5 lines

I really wish the OMAP5 devices(the latest ones from Fab) I have would like to function at OMAP4 configurations! Unfortunately the devices tend to follow the data manual for OMAP5.
*if* there is no need for it to boot, I suggest removing it.

I don't understand you. For OMAP5, that data without voltage controller support doesn't do anything bad. Since there was some dependency of voltage domain association whit PD's, I have to keep that. I never claimed that OMAP4 settings would work for OMAP5 in absolute terms.

Feel free to post a patch with right data which you seems to have. I don't mind you removing that data as long as the device continues to boot. Patch welcome.

Quoted 8 lines

Quoted 6 lines

Thanks to Rajendra's cleanup, I don't think we need dummy data anymore:

   http://marc.info/?l=linux-omap&m=137147503827947&w=2

That series is queued for v3.11.

I knew the series but wasn't sure about it getting queued up for 3.11. Nice to see the dependency is getting removed.

Anyways, I tried booting up a kernel built on linux-next-20130625 with omap2plus_defconfig and [1] on OMAP5uEVM and all I see is:
Importing environment from mmc0 ...
reading //zImage
4030024 bytes read in 198 ms (19.4 MiB/s)
reading //omap5-uevm.dtb
17729 bytes read in 16 ms (1.1 MiB/s)
[..]
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
Using Device Tree in place at 80f80000, end 80f87540

Starting kernel ...

If someone can point me to a functional base, it'd be nice, or if there is a known pending fix, it'd be better..
Taking http://marc.info/?l=linux-omap&m=136984555408516&w=2 and rebasing on linux next tag resulted practically in NOP.

Quoted 49 lines · Nishanth Menon

Quoted 27 lines · Santosh Shilimkar

Quoted 26 lines · Kevin Hilman

Quoted 23 lines · Santosh Shilimkar

Quoted 8 lines · Nishanth Menon

Quoted 6 lines · Santosh Shilimkar

Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5

Quoted 5 lines

I really wish the OMAP5 devices(the latest ones from Fab) I have would like to function at OMAP4 configurations! Unfortunately the devices tend to follow the data manual for OMAP5.
*if* there is no need for it to boot, I suggest removing it.

I don't understand you. For OMAP5, that data without voltage controller support doesn't do anything bad. Since there was some dependency of voltage domain association whit PD's, I have to keep that. I never claimed that OMAP4 settings would work for OMAP5 in absolute terms.

Feel free to post a patch with right data which you seems to have. I don't mind you removing that data as long as the device continues to boot. Patch welcome.

Quoted 8 lines

Quoted 6 lines

Thanks to Rajendra's cleanup, I don't think we need dummy data anymore:

   http://marc.info/?l=linux-omap&m=137147503827947&w=2

That series is queued for v3.11.

I knew the series but wasn't sure about it getting queued up for 3.11. Nice to see the dependency is getting removed.

Anyways, I tried booting up a kernel built on linux-next-20130625 with omap2plus_defconfig and [1] on OMAP5uEVM and all I see is:
Importing environment from mmc0 ...
reading //zImage
4030024 bytes read in 198 ms (19.4 MiB/s)
reading //omap5-uevm.dtb
17729 bytes read in 16 ms (1.1 MiB/s)
[..]
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
Using Device Tree in place at 80f80000, end 80f87540

Quoted 7 lines

Starting kernel ...

If someone can point me to a functional base, it'd be nice, or if there is a known pending fix, it'd be better..
Taking http://marc.info/?l=linux-omap&m=136984555408516&w=2 and rebasing on linux next tag resulted practically in NOP.

As mentioned in the cover-letter, you are probably missing the clock data.
------------
That means for the boot, one clock data patch needs to be applied. It is available on my git tree in 'out_of_tree/omap5_clk_data' branch.
---------------------------------------

Quoted 57 lines · Santosh Shilimkar

Quoted 49 lines · Nishanth Menon

Quoted 27 lines · Santosh Shilimkar

Quoted 26 lines · Kevin Hilman

Quoted 23 lines · Santosh Shilimkar

Quoted 8 lines · Nishanth Menon

Quoted 6 lines · Santosh Shilimkar

Well having voltage data in voltage domain was not my decision ;-) Instead of creating another set of dummy data, I just used what is out there(OMAP4) with clear comment that data needs to be updated. I don't see any problem in this considering we have devices booting and working nicely for OMAP5

Quoted 5 lines

I really wish the OMAP5 devices(the latest ones from Fab) I have would like to function at OMAP4 configurations! Unfortunately the devices tend to follow the data manual for OMAP5.
*if* there is no need for it to boot, I suggest removing it.

I don't understand you. For OMAP5, that data without voltage controller support doesn't do anything bad. Since there was some dependency of voltage domain association whit PD's, I have to keep that. I never claimed that OMAP4 settings would work for OMAP5 in absolute terms.

Feel free to post a patch with right data which you seems to have. I don't mind you removing that data as long as the device continues to boot. Patch welcome.

Quoted 8 lines

Quoted 6 lines

Thanks to Rajendra's cleanup, I don't think we need dummy data anymore:

   http://marc.info/?l=linux-omap&m=137147503827947&w=2

That series is queued for v3.11.

I knew the series but wasn't sure about it getting queued up for 3.11. Nice to see the dependency is getting removed.

Anyways, I tried booting up a kernel built on linux-next-20130625 with omap2plus_defconfig and [1] on OMAP5uEVM and all I see is:
Importing environment from mmc0 ...
reading //zImage
4030024 bytes read in 198 ms (19.4 MiB/s)
reading //omap5-uevm.dtb
17729 bytes read in 16 ms (1.1 MiB/s)
[..]
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
Using Device Tree in place at 80f80000, end 80f87540

Quoted 7 lines

Starting kernel ...

If someone can point me to a functional base, it'd be nice, or if there is a known pending fix, it'd be better..
Taking http://marc.info/?l=linux-omap&m=136984555408516&w=2 and rebasing on linux next tag resulted practically in NOP.

Quoted 5 lines

As mentioned in the cover-letter, you are probably missing the clock data.
------------
That means for the boot, one clock data patch needs to be applied. It is available on my git tree in 'out_of_tree/omap5_clk_data' branch.
---------------------------------------

Thanks on the hint, I had missed it. I merged the for_3.11/out_of_tree/omap5_clk_data from
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
to linux-next-20130625 with a minor conflict in arch/arm/mach-omap2/io.c

omap2plus_defconfig: http://pastebin.com/rTuEn0H6
Then applied:

arch/arm/mach-omap2/voltagedomains54xx_data.c +0 -5

index 72b8971..89a5589f 100644
@@ -89,11 +89,6 @@ void __init omap54xx_voltagedomains_init(void)
 	 * XXX Will depend on the process, validation, and binning
 	 * for the currently-running IC. Use OMAP4 data for time being.
 	 */
-#ifdef CONFIG_PM_OPP
-	omap5_voltdm_mpu.volt_data = omap446x_vdd_mpu_volt_data;
-	omap5_voltdm_mm.volt_data = omap446x_vdd_iva_volt_data;
-	omap5_voltdm_core.volt_data = omap446x_vdd_core_volt_data;
-#endif
 
 	for (i = 0; voltdm = voltagedomains_omap5[i], voltdm; i++)
 		voltdm->sys_clk.name = sys_clk_name;

Result: http://pastebin.com/t8cdd7uj

As kevin mentioned, we can boot without registering wrong voltage data.