| Message ID | 201306212229.54238.arnd@arndb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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@vger.kernel.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html