[PATCH] ARM: omap5: build opp4xxx_data.c

[PATCH] ARM: omap5: build opp4xxx_data.c

[Arnd Bergmann]

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 <arnd@arndb.de>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap at vger.kernel.org

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0520dc4..f5038f5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -77,6 +77,7 @@ ifeq ($(CONFIG_PM_OPP),y)
 obj-y					+= opp.o
 obj-$(CONFIG_ARCH_OMAP3)		+= opp3xxx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= opp4xxx_data.o
+obj-$(CONFIG_SOC_OMAP5)			+= opp4xxx_data.o
 endif
 
 # Power Management

[PATCH] ARM: omap5: build opp4xxx_data.c

[Nishanth Menon]

On 22:29-20130621, Arnd Bergmann wrote:
> 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 <arnd@arndb.de>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: linux-omap at vger.kernel.org
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 0520dc4..f5038f5 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -77,6 +77,7 @@ ifeq ($(CONFIG_PM_OPP),y)
>  obj-y					+= opp.o
>  obj-$(CONFIG_ARCH_OMAP3)		+= opp3xxx_data.o
>  obj-$(CONFIG_ARCH_OMAP4)		+= opp4xxx_data.o
> +obj-$(CONFIG_SOC_OMAP5)			+= opp4xxx_data.o
>  endif
>  

	/*
	 * 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.

-- 
Regards,
Nishanth Menon

[PATCH] ARM: omap5: build opp4xxx_data.c

[Paul Walmsley]

Santosh,

On Fri, 21 Jun 2013, Nishanth Menon wrote:

> 	/*
> 	 * 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.

thanks

- Paul

[PATCH] ARM: omap5: build opp4xxx_data.c

[Santosh Shilimkar]

On Tuesday 25 June 2013 03:20 PM, Paul Walmsley wrote:
> Santosh,
> 
> On Fri, 21 Jun 2013, Nishanth Menon wrote:
> 
>> 	/*
>> 	 * 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.
> 
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.

Regards,
Santosh

[PATCH] ARM: omap5: build opp4xxx_data.c

[Nishanth Menon]

On 15:55-20130625, Santosh Shilimkar wrote:
> On Tuesday 25 June 2013 03:20 PM, Paul Walmsley wrote:
> > Santosh,
> > 
> > On Fri, 21 Jun 2013, Nishanth Menon wrote:
> > 
> >> 	/*
> >> 	 * 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.
> > 
> 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.

-- 
Regards,
Nishanth Menon

[PATCH] ARM: omap5: build opp4xxx_data.c

[Santosh Shilimkar]

On Tuesday 25 June 2013 03:57 PM, Nishanth Menon wrote:
> On 15:55-20130625, Santosh Shilimkar wrote:
>> On Tuesday 25 June 2013 03:20 PM, Paul Walmsley wrote:
>>> Santosh,
>>>
>>> On Fri, 21 Jun 2013, Nishanth Menon wrote:
>>>
>>>> 	/*
>>>> 	 * 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.
>>>
>> 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.
>
The boot is just fine as I said, the setting doesn't have any effect
without the code which is going to use that data.
 
> 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

Regards,
Santosh
 

[PATCH] ARM: omap5: build opp4xxx_data.c

[Nishanth Menon]

On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>
> 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.

Regards,
Nishanth Menon

[PATCH] ARM: omap5: build opp4xxx_data.c

[Santosh Shilimkar]

On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote:
> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>>
>> 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.
> 
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.

Thanks !!

Regards,
Santosh

[PATCH] ARM: omap5: build opp4xxx_data.c

[Kevin Hilman]

Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote:
>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:
>>>
>>> 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.
>> 
> 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.

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.

Kevin

[PATCH] ARM: omap5: build opp4xxx_data.c

[Santosh Shilimkar]

On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 
>> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote:
>>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar
>>> <santosh.shilimkar@ti.com> wrote:
>>>>
>>>> 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.
>>>
>> 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.
> 
> 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.

Regards,
Santosh

[PATCH] ARM: omap5: build opp4xxx_data.c

[Nishanth Menon]

On 16:59-20130625, Santosh Shilimkar wrote:
> On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote:
> > Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> > 
> >> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote:
> >>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar
> >>> <santosh.shilimkar@ti.com> wrote:
> >>>>
> >>>> 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.
> >>>
> >> 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.
> > 
> > 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. 

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/178209.html
-- 
Regards,
Nishanth Menon

[PATCH] ARM: omap5: build opp4xxx_data.c

[Santosh Shilimkar]

On Tuesday 25 June 2013 06:36 PM, Nishanth Menon wrote:
> On 16:59-20130625, Santosh Shilimkar wrote:
>> On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote:
>>>>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar
>>>>> <santosh.shilimkar@ti.com> wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>> 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.
>>>
>>> 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. 
> 
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.
---------------------------------------

Regards,
Santosh

[PATCH] ARM: omap5: build opp4xxx_data.c

[Nishanth Menon]

On 18:43-20130625, Santosh Shilimkar wrote:
> On Tuesday 25 June 2013 06:36 PM, Nishanth Menon wrote:
> > On 16:59-20130625, Santosh Shilimkar wrote:
> >> On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote:
> >>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >>>
> >>>> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote:
> >>>>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar
> >>>>> <santosh.shilimkar@ti.com> wrote:
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>> 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.
> >>>
> >>> 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. 
> > 
> 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:
diff --git a/arch/arm/mach-omap2/voltagedomains54xx_data.c b/arch/arm/mach-omap2/voltagedomains54xx_data.c
index 72b8971..89a5589f 100644
--- a/arch/arm/mach-omap2/voltagedomains54xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains54xx_data.c
@@ -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.
-- 
Regards,
Nishanth Menon

[PATCH] ARM: omap5: build opp4xxx_data.c

[Santosh Shilimkar]

On Tuesday 25 June 2013 07:02 PM, Nishanth Menon wrote:
> On 18:43-20130625, Santosh Shilimkar wrote:
>> On Tuesday 25 June 2013 06:36 PM, Nishanth Menon wrote:
>>> On 16:59-20130625, Santosh Shilimkar wrote:
>>>> On Tuesday 25 June 2013 04:56 PM, Kevin Hilman wrote:
>>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>>
>>>>>> On Tuesday 25 June 2013 04:17 PM, Nishanth Menon wrote:
>>>>>>> On Tue, Jun 25, 2013 at 3:12 PM, Santosh Shilimkar
>>>>>>> <santosh.shilimkar@ti.com> wrote:
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>> 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.
>>>>>
>>>>> 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. 
>>>
>> 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:
> diff --git a/arch/arm/mach-omap2/voltagedomains54xx_data.c b/arch/arm/mach-omap2/voltagedomains54xx_data.c
> index 72b8971..89a5589f 100644
> --- a/arch/arm/mach-omap2/voltagedomains54xx_data.c
> +++ b/arch/arm/mach-omap2/voltagedomains54xx_data.c
> @@ -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.
> 
With Rajendra's series included now, Yes. Can you send an updated patch with
description for Paul to pick it up ?

Regards,
Santosh