From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Kevin Hilman <khilman@linaro.org>
Cc: Nishanth Menon <nm@ti.com>, Paul Walmsley <paul@pwsan.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-omap <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>,
"J, KEERTHY" <j-keerthy@ti.com>
Subject: Re: [PATCH] ARM: omap5: build opp4xxx_data.c
Date: Tue, 25 Jun 2013 16:59:04 -0400 [thread overview]
Message-ID: <51CA0498.9010506@ti.com> (raw)
In-Reply-To: <87a9mducye.fsf@linaro.org>
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
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:59:04 -0400 [thread overview]
Message-ID: <51CA0498.9010506@ti.com> (raw)
In-Reply-To: <87a9mducye.fsf@linaro.org>
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
next prev parent reply other threads:[~2013-06-25 20:59 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
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 [this message]
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=51CA0498.9010506@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=arnd@arndb.de \
--cc=b-cousson@ti.com \
--cc=j-keerthy@ti.com \
--cc=khilman@linaro.org \
--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.