From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>, Arnd Bergmann <arnd@arndb.de>,
linux-omap@vger.kernel.org,
Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>,
Tony Lindgren <tony@atomide.com>,
Benoit Cousson <b-cousson@ti.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
"J, KEERTHY" <j-keerthy@ti.com>
Subject: Re: [PATCH] ARM: omap5: build opp4xxx_data.c
Date: Tue, 25 Jun 2013 16:12:03 -0400 [thread overview]
Message-ID: <51C9F993.6050109@ti.com> (raw)
In-Reply-To: <20130625195751.GA6529@kahuna>
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
WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: omap5: build opp4xxx_data.c
Date: Tue, 25 Jun 2013 16:12:03 -0400 [thread overview]
Message-ID: <51C9F993.6050109@ti.com> (raw)
In-Reply-To: <20130625195751.GA6529@kahuna>
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
next prev parent reply other threads:[~2013-06-25 20:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-21 20:29 [PATCH] ARM: omap5: build opp4xxx_data.c Arnd Bergmann
2013-06-21 20:29 ` Arnd Bergmann
2013-06-21 20:42 ` Nishanth Menon
2013-06-21 20:42 ` Nishanth Menon
2013-06-25 19:20 ` Paul Walmsley
2013-06-25 19:20 ` Paul Walmsley
2013-06-25 19:55 ` Santosh Shilimkar
2013-06-25 19:55 ` Santosh Shilimkar
2013-06-25 19:57 ` Nishanth Menon
2013-06-25 19:57 ` Nishanth Menon
2013-06-25 20:12 ` Santosh Shilimkar [this message]
2013-06-25 20:12 ` Santosh Shilimkar
2013-06-25 20:17 ` Nishanth Menon
2013-06-25 20:17 ` Nishanth Menon
2013-06-25 20:24 ` Santosh Shilimkar
2013-06-25 20:24 ` Santosh Shilimkar
2013-06-25 20:56 ` Kevin Hilman
2013-06-25 20:56 ` Kevin Hilman
2013-06-25 20:59 ` Santosh Shilimkar
2013-06-25 20:59 ` Santosh Shilimkar
2013-06-25 22:36 ` Nishanth Menon
2013-06-25 22:36 ` Nishanth Menon
2013-06-25 22:43 ` Santosh Shilimkar
2013-06-25 22:43 ` Santosh Shilimkar
2013-06-25 23:02 ` Nishanth Menon
2013-06-25 23:02 ` Nishanth Menon
2013-06-25 23:27 ` Santosh Shilimkar
2013-06-25 23:27 ` Santosh Shilimkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C9F993.6050109@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=arnd@arndb.de \
--cc=b-cousson@ti.com \
--cc=j-keerthy@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=paul@pwsan.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.