From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: tony@atomide.com, khilman@deeprootsystems.com,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Date: Thu, 4 Apr 2013 16:04:26 +0530 [thread overview]
Message-ID: <515D5732.6000705@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1304031953010.16711@utopia.booyaka.com>
Paul,
On Thursday 04 April 2013 01:39 AM, Paul Walmsley wrote:
> cc Kevin
>
> Hi
>
> On Wed, 20 Mar 2013, Santosh Shilimkar wrote:
>
>> Benoit Cousson (7):
>> ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files
>
> So it looks like this patch never made it to the mailing list. Was it too
> big? If so, please try splitting it into two or more pieces. Looking at
> the git branch that you posted for pulling, the patch adds two files, so
> maybe you can just create one patch for each file?
>
Size was not an issue mostly. Looks like that entire series got affected
because of the TI mailer issue which was reported by ARM list maintainer.
I lost many emails during that.
> Also, looking at the bottom of the arch/arm/mach-omap2/prm54xx.h from this
> commit 600e78bb51c0ee081f0da14f879c3e4a1dee9896, there are a bunch of
> function prototypes that reference OMAP44xx. Shouldn't these reference
> OMAP54xx, or be removed from this file? If you're reusing the OMAP4 PRM
> functions for OMAP5, then shouldn't they be moved out from the OMAP4
> header files into a separate header file?
>
Yes. I some how ignored this considering the files were auto-generated.
Have fixed this one now in v2 [1] which is posted on list
>> ARM: OMAP5: CM: Add OMAP54XX register and bitfield files
>
> There are similar problems with this patch. It doesn't look like it ever
> made it to the linux-omap list, in my inbox, anyway. And again the
> function prototypes make several references to OMAP4, when they should
> refer to OMAP5 or be removed from this file.
>
Fixed in v2
>> ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers
>
> More duplicated OMAP4 function prototypes here.
>
Fixed in v2
>> ARM: OMAP5: SCRM: Add OMAP54XX header file.
>
> Looks fine to me.
>
>> ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header
>> ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header
>
> These two look okay to me based on a superficial inspection. Is there a
> public TRM posted for OMAP5? It's not in the obvious place, so there's no
> way to review these against the TRM:
>
> http://www.ti.com/lsds/ti/omap-applications-processors/technical-documents.page?familyId=601&docCategoryId=6
>
Public TRM got delayed becasue of recent changes at TI. As per the latest
I heard, April end the TRM should be public. But as you know auto-generated
data is often more accurate than TRM :)
>> ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
>
> Looks like this one hasn't been reposted after the changes that were made
> to it after Tony's comments? If I've just missed the list post, please
> send a link. Otherwise, the updated patch should be reposted.
>
As mentioned earlier, the series was lost mostly because of mailer issue.
Posted v2 has this patch now.
>> Santosh Shilimkar (4):
>> ARM: OMAP5: hwmod_data: Fix UART sysc settings
>> ARM: OMAP5: hwmod-data: Add timer clock activity flags
>
> These two should be rolled into the "ARM: OMAP5: hwmod data: Create
> initial OMAP5 SOC hwmod data" patch.
>
Folded in v2.
>> ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data
>
> This one needs to be acked by Kevin.
>
Kevin has been cc'ed on this one.
>> ARM: OMAP5: Enable build and frameowrk initialisations
>
> Looks fine to me.
>
Thanks a lot for quick response. Please let me know if I missed any
of your comments in v2.
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg235575.html
WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Date: Thu, 4 Apr 2013 16:04:26 +0530 [thread overview]
Message-ID: <515D5732.6000705@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1304031953010.16711@utopia.booyaka.com>
Paul,
On Thursday 04 April 2013 01:39 AM, Paul Walmsley wrote:
> cc Kevin
>
> Hi
>
> On Wed, 20 Mar 2013, Santosh Shilimkar wrote:
>
>> Benoit Cousson (7):
>> ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files
>
> So it looks like this patch never made it to the mailing list. Was it too
> big? If so, please try splitting it into two or more pieces. Looking at
> the git branch that you posted for pulling, the patch adds two files, so
> maybe you can just create one patch for each file?
>
Size was not an issue mostly. Looks like that entire series got affected
because of the TI mailer issue which was reported by ARM list maintainer.
I lost many emails during that.
> Also, looking at the bottom of the arch/arm/mach-omap2/prm54xx.h from this
> commit 600e78bb51c0ee081f0da14f879c3e4a1dee9896, there are a bunch of
> function prototypes that reference OMAP44xx. Shouldn't these reference
> OMAP54xx, or be removed from this file? If you're reusing the OMAP4 PRM
> functions for OMAP5, then shouldn't they be moved out from the OMAP4
> header files into a separate header file?
>
Yes. I some how ignored this considering the files were auto-generated.
Have fixed this one now in v2 [1] which is posted on list
>> ARM: OMAP5: CM: Add OMAP54XX register and bitfield files
>
> There are similar problems with this patch. It doesn't look like it ever
> made it to the linux-omap list, in my inbox, anyway. And again the
> function prototypes make several references to OMAP4, when they should
> refer to OMAP5 or be removed from this file.
>
Fixed in v2
>> ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers
>
> More duplicated OMAP4 function prototypes here.
>
Fixed in v2
>> ARM: OMAP5: SCRM: Add OMAP54XX header file.
>
> Looks fine to me.
>
>> ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header
>> ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header
>
> These two look okay to me based on a superficial inspection. Is there a
> public TRM posted for OMAP5? It's not in the obvious place, so there's no
> way to review these against the TRM:
>
> http://www.ti.com/lsds/ti/omap-applications-processors/technical-documents.page?familyId=601&docCategoryId=6
>
Public TRM got delayed becasue of recent changes at TI. As per the latest
I heard, April end the TRM should be public. But as you know auto-generated
data is often more accurate than TRM :)
>> ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
>
> Looks like this one hasn't been reposted after the changes that were made
> to it after Tony's comments? If I've just missed the list post, please
> send a link. Otherwise, the updated patch should be reposted.
>
As mentioned earlier, the series was lost mostly because of mailer issue.
Posted v2 has this patch now.
>> Santosh Shilimkar (4):
>> ARM: OMAP5: hwmod_data: Fix UART sysc settings
>> ARM: OMAP5: hwmod-data: Add timer clock activity flags
>
> These two should be rolled into the "ARM: OMAP5: hwmod data: Create
> initial OMAP5 SOC hwmod data" patch.
>
Folded in v2.
>> ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data
>
> This one needs to be acked by Kevin.
>
Kevin has been cc'ed on this one.
>> ARM: OMAP5: Enable build and frameowrk initialisations
>
> Looks fine to me.
>
Thanks a lot for quick response. Please let me know if I missed any
of your comments in v2.
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg235575.html
next prev parent reply other threads:[~2013-04-04 10:32 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 8:40 [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10 Santosh Shilimkar
2013-03-20 8:40 ` Santosh Shilimkar
2013-04-01 17:05 ` Tony Lindgren
2013-04-01 17:05 ` Tony Lindgren
2013-04-03 3:52 ` Santosh Shilimkar
2013-04-03 3:52 ` Santosh Shilimkar
2013-04-03 19:42 ` Paul Walmsley
2013-04-03 19:42 ` Paul Walmsley
2013-04-04 11:12 ` Santosh Shilimkar
2013-04-04 11:12 ` Santosh Shilimkar
2013-04-04 16:52 ` Tony Lindgren
2013-04-04 16:52 ` Tony Lindgren
2013-04-04 16:57 ` Santosh Shilimkar
2013-04-04 16:57 ` Santosh Shilimkar
2013-04-05 16:50 ` Santosh Shilimkar
2013-04-05 16:50 ` Santosh Shilimkar
2013-04-05 17:10 ` Tony Lindgren
2013-04-05 17:10 ` Tony Lindgren
2013-04-09 18:03 ` Hiremath, Vaibhav
2013-04-09 18:03 ` Hiremath, Vaibhav
2013-04-10 11:15 ` Hiremath, Vaibhav
2013-04-10 11:15 ` Hiremath, Vaibhav
2013-04-10 11:32 ` Santosh Shilimkar
2013-04-10 11:32 ` Santosh Shilimkar
2013-04-15 5:06 ` Hiremath, Vaibhav
2013-04-15 5:06 ` Hiremath, Vaibhav
2013-04-15 6:20 ` Santosh Shilimkar
2013-04-15 6:20 ` Santosh Shilimkar
2013-04-18 4:49 ` Hiremath, Vaibhav
2013-04-18 4:49 ` Hiremath, Vaibhav
2013-04-10 11:23 ` Hiremath, Vaibhav
2013-04-10 11:23 ` Hiremath, Vaibhav
2013-05-17 8:00 ` Santosh Shilimkar
2013-05-17 8:00 ` Santosh Shilimkar
2013-05-17 17:22 ` Tony Lindgren
2013-05-17 17:22 ` Tony Lindgren
2013-05-29 16:41 ` Santosh Shilimkar
2013-05-29 16:41 ` Santosh Shilimkar
2013-04-05 12:42 ` Tero Kristo
2013-04-05 12:42 ` Tero Kristo
2013-04-03 20:09 ` Paul Walmsley
2013-04-03 20:09 ` Paul Walmsley
2013-04-04 10:34 ` Santosh Shilimkar [this message]
2013-04-04 10:34 ` 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=515D5732.6000705@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--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.