Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
On Friday 17 May 2013 01:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130517 01:02]: Paul, Tony, On Friday 05 April 2013 10:20 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file For whatever reason, we again missed the merge window for the subject series, I would like to know your plan on the subject series for at least 3.11. Asking *well in advance* to avoid late merge related discussions. Yes, I think we should have now a omap5 hwmod data sized hole coming up with conversion of omap4 to be DT only. I'll post those patches today for the board file and legacy mux removal for omap4: 12 files changed, 52 insertions(+), 3260 deletions(-) Cool. Those coupled with your am33xx hwmod cleanup patch and your omap4 hwmod cleanup patch should allow us having the omap5 hwmod data without making the diffstats look too bad. Thanks to Vaibhav, AM33XX patch is tested and validated with some updates considering upcoming PM support for AM33XX. So that patch will be included in the series. Rajendra will follow up the patchset if there is some re-basing is needed since I will away for few weeks because of travel. OK, well the omap4 hwmod clean-up patch depends on first dropping the above mentioned omap4 legacy files. Have posted the series which includes AM33XX and OMAP4 data reduction patch as well. regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Paul, Tony, On Friday 05 April 2013 10:20 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file For whatever reason, we again missed the merge window for the subject series, I would like to know your plan on the subject series for at least 3.11. Asking *well in advance* to avoid late merge related discussions. Thanks to Vaibhav, AM33XX patch is tested and validated with some updates considering upcoming PM support for AM33XX. So that patch will be included in the series. Rajendra will follow up the patchset if there is some re-basing is needed since I will away for few weeks because of travel. OMAP5 data is the *only* thing which is gating the device to boot from mainline. Thanks in advance. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130517 01:02]: Paul, Tony, On Friday 05 April 2013 10:20 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file For whatever reason, we again missed the merge window for the subject series, I would like to know your plan on the subject series for at least 3.11. Asking *well in advance* to avoid late merge related discussions. Yes, I think we should have now a omap5 hwmod data sized hole coming up with conversion of omap4 to be DT only. I'll post those patches today for the board file and legacy mux removal for omap4: 12 files changed, 52 insertions(+), 3260 deletions(-) Those coupled with your am33xx hwmod cleanup patch and your omap4 hwmod cleanup patch should allow us having the omap5 hwmod data without making the diffstats look too bad. Thanks to Vaibhav, AM33XX patch is tested and validated with some updates considering upcoming PM support for AM33XX. So that patch will be included in the series. Rajendra will follow up the patchset if there is some re-basing is needed since I will away for few weeks because of travel. OK, well the omap4 hwmod clean-up patch depends on first dropping the above mentioned omap4 legacy files. OMAP5 data is the *only* thing which is gating the device to boot from mainline. That's great! Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
On Monday 15 April 2013 10:36 AM, Hiremath, Vaibhav wrote: -Original Message- From: Shilimkar, Santosh Sent: Wednesday, April 10, 2013 5:02 PM [..] From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data can be stripped from SOC hwmod data file. - The devices like adc, mailbox, gpmc which are missing the device tree bindings, hwmod data is not added since AM33XX is DT only build. When such devices add the dt bindings, respective hwmod data can be added along with it. This seems unnecessary churn to me. DT bindings for most of the devices which you mentioned above are submitted and are at various stages of review process. ADC: GPMC: PWM: The modules are dropped as per what is going for 3.10 merge window. Above 3 modules can be retained if the DT conversion patches are under review and can go along with this patch most likely for 3.11. - The hwmod like firewall etc which are not useful are also dropped. This gets us around ~2000 loc of negative diff. Patch is boot tested on AM335X EVM. I would not recommend to get into unnecessary code churn in the future just to reduce temp Number of Lines of code. This will also kill our autogeneration concept as well. It doesn't break any concept. We just autogenrate what is *useful* rather. BTW, I didn't find any srcipt to auto-generate the AM33XX data so we have to manually do the updates. Can you send me a pointer if you have a sript for this. With script it is much simpler to clean-up the data. I would suggest you to just alone drop base-addr, irq and dma references from hwmod entries. That we are doing anyways. Apart from that we should also clean-up data which is not used and useful. Why do you need unused data like firewall and friends ? So as I understood, you would like to keep the data for ADC, PWM and GPMC which is fine by me. We just need those DT bindings in place so that they go together. Who is following the DT patches for these ? Thanks for looking into it Vaibhav. Are you planning to send updated version of this? I would rather prefer to review next version. Please let me know if you need any help here. Yes :-) It will be great if you take the patch forward and update it based on the discussion. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
-Original Message- From: Shilimkar, Santosh Sent: Wednesday, April 10, 2013 5:02 PM To: Hiremath, Vaibhav Cc: Tony Lindgren; Paul Walmsley; linux-omap@vger.kernel.org; linux- arm-ker...@lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak, Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10 On Wednesday 10 April 2013 04:45 PM, Hiremath, Vaibhav wrote: -Original Message- From: Shilimkar, Santosh Sent: Friday, April 05, 2013 10:20 PM To: Tony Lindgren Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak, Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath, Vaibhav Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10 On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data can be stripped from SOC hwmod data file. - The devices like adc, mailbox, gpmc which are missing the device tree bindings, hwmod data is not added since AM33XX is DT only build. When such devices add the dt bindings, respective hwmod data can be added along with it. This seems unnecessary churn to me. DT bindings for most of the devices which you mentioned above are submitted and are at various stages of review process. ADC: GPMC: PWM: The modules are dropped as per what is going for 3.10 merge window. Above 3 modules can be retained if the DT conversion patches are under review and can go along with this patch most likely for 3.11. - The hwmod like firewall etc which are not useful are also dropped. This gets us around ~2000 loc of negative diff. Patch is boot tested on AM335X EVM. I would not recommend to get into unnecessary code churn in the future just to reduce temp Number of Lines of code. This will also kill our autogeneration concept as well. It doesn't break any concept. We just autogenrate what is *useful* rather. BTW, I didn't find any srcipt to auto-generate the AM33XX data so we have to manually do the updates. Can you send me a pointer if you have a sript for this. With script it is much simpler to clean-up the data. I would suggest you to just alone drop base-addr, irq and dma references from hwmod entries. That we are doing anyways. Apart from that we should also clean-up data which is not used and useful. Why do you need unused data like firewall and friends ? So as I understood, you would like to keep the data for ADC, PWM and GPMC which is fine by me. We just need those DT bindings in place so that they go together. Who is following the DT patches for these ? Thanks for looking into it Vaibhav. Are you planning to send updated version of this? I would rather prefer to review next version. Please let me know if you need any help here. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
On Wednesday 10 April 2013 04:45 PM, Hiremath, Vaibhav wrote: -Original Message- From: Shilimkar, Santosh Sent: Friday, April 05, 2013 10:20 PM To: Tony Lindgren Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak, Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath, Vaibhav Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10 On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data can be stripped from SOC hwmod data file. - The devices like adc, mailbox, gpmc which are missing the device tree bindings, hwmod data is not added since AM33XX is DT only build. When such devices add the dt bindings, respective hwmod data can be added along with it. This seems unnecessary churn to me. DT bindings for most of the devices which you mentioned above are submitted and are at various stages of review process. ADC: GPMC: PWM: The modules are dropped as per what is going for 3.10 merge window. Above 3 modules can be retained if the DT conversion patches are under review and can go along with this patch most likely for 3.11. - The hwmod like firewall etc which are not useful are also dropped. This gets us around ~2000 loc of negative diff. Patch is boot tested on AM335X EVM. I would not recommend to get into unnecessary code churn in the future just to reduce temp Number of Lines of code. This will also kill our autogeneration concept as well. It doesn't break any concept. We just autogenrate what is *useful* rather. BTW, I didn't find any srcipt to auto-generate the AM33XX data so we have to manually do the updates. Can you send me a pointer if you have a sript for this. With script it is much simpler to clean-up the data. I would suggest you to just alone drop base-addr, irq and dma references from hwmod entries. That we are doing anyways. Apart from that we should also clean-up data which is not used and useful. Why do you need unused data like firewall and friends ? So as I understood, you would like to keep the data for ADC, PWM and GPMC which is fine by me. We just need those DT bindings in place so that they go together. Who is following the DT patches for these ? Thanks for looking into it Vaibhav. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, April 05, 2013 10:41 PM To: Shilimkar, Santosh Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak, Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath, Vaibhav Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10 * Santosh Shilimkar santosh.shilim...@ti.com [130405 09:52]: On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data can be stripped from SOC hwmod data file. - The devices like adc, mailbox, gpmc which are missing the device tree bindings, hwmod data is not added since AM33XX is DT only build. When such devices add the dt bindings, respective hwmod data can be added along with it. - The hwmod like firewall etc which are not useful are also dropped. This gets us around ~2000 loc of negative diff. Patch is boot tested on AM335X EVM. Great, that's a nice reduction :) Considering am33xx is DT only, it should be safe.. But can the am33xx guys please test and ack it? I am reviewing the patch-diff and will give my comment as soon as possible. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
On Thu, 2013-04-04 at 16:42 +0530, Santosh Shilimkar wrote:
+ Tero and few more TI folks,
Hi,
Added some comments below.
On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
I agree that we are not making faster progress but as part of the
$subject series itself, for DT only build, we removed around ~4000
lines of data from hwmod. After the merge window, we can trim
the AM33XX and then later OMAP4 when it is made DT only support.
That should give us another 6000 lines of negative diff.
At the same time removal of MUX data for OMAP4 should be
around 2000 lines of negative diff.
You might also notice, we dropped OMAP5 clock data considering
its move under drivers/clk/. Rajendra and Tero already posted
patches [1] for the same on the list. Ofcourse your feedback is
needed to make progress there.
For example, as discussed last year with the TI upstream PM team, an
important first step in this process in my view is to get rid of the
direct PRM/CM register accesses in the OMAP PM code. See commit
c4ceedcb18cf7a06059482a3a1828b9aad9f78cf (ARM: OMAP2+: CM/clock: convert
_omap2_module_wait_ready() to use SoC-independent CM functions) as an
example of this process. This should make it easier to get the PRM/CM
functionality into drivers/. That in turn make it possible to move the
clockdomain, clock, powerdomain, and hwmod code to drivers/.ARM: OMAP2+:
CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM
functions. So far as I can tell, there hasn't been any forward progress
on this.
On this part as well after my discussion with Tony, Tero picked it up
and he and Eduardo posted questions to you [2] considering you
already had some WIP patches as we learned from Tony. I suggest
you send any information on this to Tero since he is leading the
PM effort and has plans to work on these items.
It's also necessary to see more TI contributions in finding and fixing
regressions. Detecting and fixing regressions from the previous kernel
release should be done first, before working on cleanup series or new
feature/SoC additions. Looking at the list of v3.9-rc regressions that
I've found, we've gotten very little organized help from TI on dealing
with them.
This in turn robs the maintainers of time that could be spent doing patch
review or further cleanup work, which benefits no one in the end.
Ideally each regression would be assigned to a member of the TI upstream
team, and the whole process could be completed within one or two weeks.
I agree with you overall.
On couple of specific issues though,
- BOOT-Loader version: IMHO boot-loader should be upgraded here.
We always upgrade kernel for new/fixed features and bootloader should
be no exception.
- Co-processor Power issue: This one is also has boot-loader dependency
but here too, going on path where firmware needs to be loaded to idle
them isn't great idea. We never did that for OMAP2/3 where DSP, Tesla
was present. IMO, we should not bring these devices out of reset and
let the remote_proc() frame works take care of them when it is
available in kernel. Suman from TI is working on it to enable that.
I kind of understand why you insist keeping your old bootloader, as it
makes these issues visible, but well, nothing is going to happen for
them as far as I can see. If Suman can eventually provide a nice hack
that makes this happen, fine, but at least on the PM front, we can do
nothing. Even if we did, the implementation would most likely become so
ugly that it would be rejected by the maintainers anyway. I can't see
any point why to invest time on this.
...
So from my point of view, I'd like to see the following changes before we
accept any new patchsets that add a significant number of lines:
1.
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130405 09:52]: On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data can be stripped from SOC hwmod data file. - The devices like adc, mailbox, gpmc which are missing the device tree bindings, hwmod data is not added since AM33XX is DT only build. When such devices add the dt bindings, respective hwmod data can be added along with it. - The hwmod like firewall etc which are not useful are also dropped. This gets us around ~2000 loc of negative diff. Patch is boot tested on AM335X EVM. Great, that's a nice reduction :) Considering am33xx is DT only, it should be safe.. But can the am33xx guys please test and ack it? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
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=601docCategoryId=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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
+ Tero and few more TI folks,
On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
I agree that we are not making faster progress but as part of the
$subject series itself, for DT only build, we removed around ~4000
lines of data from hwmod. After the merge window, we can trim
the AM33XX and then later OMAP4 when it is made DT only support.
That should give us another 6000 lines of negative diff.
At the same time removal of MUX data for OMAP4 should be
around 2000 lines of negative diff.
You might also notice, we dropped OMAP5 clock data considering
its move under drivers/clk/. Rajendra and Tero already posted
patches [1] for the same on the list. Ofcourse your feedback is
needed to make progress there.
For example, as discussed last year with the TI upstream PM team, an
important first step in this process in my view is to get rid of the
direct PRM/CM register accesses in the OMAP PM code. See commit
c4ceedcb18cf7a06059482a3a1828b9aad9f78cf (ARM: OMAP2+: CM/clock: convert
_omap2_module_wait_ready() to use SoC-independent CM functions) as an
example of this process. This should make it easier to get the PRM/CM
functionality into drivers/. That in turn make it possible to move the
clockdomain, clock, powerdomain, and hwmod code to drivers/.ARM: OMAP2+:
CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM
functions. So far as I can tell, there hasn't been any forward progress
on this.
On this part as well after my discussion with Tony, Tero picked it up
and he and Eduardo posted questions to you [2] considering you
already had some WIP patches as we learned from Tony. I suggest
you send any information on this to Tero since he is leading the
PM effort and has plans to work on these items.
It's also necessary to see more TI contributions in finding and fixing
regressions. Detecting and fixing regressions from the previous kernel
release should be done first, before working on cleanup series or new
feature/SoC additions. Looking at the list of v3.9-rc regressions that
I've found, we've gotten very little organized help from TI on dealing
with them.
This in turn robs the maintainers of time that could be spent doing patch
review or further cleanup work, which benefits no one in the end.
Ideally each regression would be assigned to a member of the TI upstream
team, and the whole process could be completed within one or two weeks.
I agree with you overall.
On couple of specific issues though,
- BOOT-Loader version: IMHO boot-loader should be upgraded here.
We always upgrade kernel for new/fixed features and bootloader should
be no exception.
- Co-processor Power issue: This one is also has boot-loader dependency
but here too, going on path where firmware needs to be loaded to idle
them isn't great idea. We never did that for OMAP2/3 where DSP, Tesla
was present. IMO, we should not bring these devices out of reset and
let the remote_proc() frame works take care of them when it is
available in kernel. Suman from TI is working on it to enable that.
...
So from my point of view, I'd like to see the following changes before we
accept any new patchsets that add a significant number of lines:
1. Organized help from TI in finding and fixing regressions in the -rc
cycle, with the regressions dealt with before any new feature
pull-requests are sent
Agreed. Tero can help here to streamline the process for PM regressions.
Rest of the core regressions and MPU PM, feel free to pass it on to
Rajendra/me. We will try to address them on priority.
2. Help from TI on some of the cleanup work that we've mentioned in the
past, starting with the PRM/CM register access cleanup inside mach-omap2/
Absolutely. As I mentioned earlier, Eduardo and Tero are waiting for your
inputs on this topic.
3. Pairing any large feature or SoC
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]:
+ Tero and few more TI folks,
On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
I agree that we are not making faster progress but as part of the
$subject series itself, for DT only build, we removed around ~4000
lines of data from hwmod. After the merge window, we can trim
the AM33XX and then later OMAP4 when it is made DT only support.
That should give us another 6000 lines of negative diff.
At the same time removal of MUX data for OMAP4 should be
around 2000 lines of negative diff.
Can't we already trim the am33xx hwmod data after your patches for
v3.10 as am33xx is already DT only? Unfortunately we cannot create
negative diffstat in other ways for v3.10 merge window as we cannot
make omap4 DT only just quite yet.
FYI, I have some trivial patches here to drop board and mux support for
omap4 once we can make omap4 DT only, so that will be about 3000 lines
of reduction with estimated 1000 - 2000 lines once I go through the
unneeded platform init code for omap4 for things like MMC and USB.
The rest of the clean-up issues I believe we all agree, we just need
to get it done so we can avoid getting flamed for every new SoC for
the huge data files. To fix the data issue for good, it seems that we can
get started moving both the clock and hwmod data to simple drivers
that can get clocks and hwmod data both from DT and /lib/firmware.
It also seems that we don't need to move all the data at once, which
makes the task easier.
Cheers,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]:
+ Tero and few more TI folks,
On Thursday 04 April 2013 01:12 AM, Paul Walmsley wrote:
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
I agree that we are not making faster progress but as part of the
$subject series itself, for DT only build, we removed around ~4000
lines of data from hwmod. After the merge window, we can trim
the AM33XX and then later OMAP4 when it is made DT only support.
That should give us another 6000 lines of negative diff.
At the same time removal of MUX data for OMAP4 should be
around 2000 lines of negative diff.
Can't we already trim the am33xx hwmod data after your patches for
v3.10 as am33xx is already DT only? Unfortunately we cannot create
negative diffstat in other ways for v3.10 merge window as we cannot
make omap4 DT only just quite yet.
Yes we can and I can take a stab it tomorrow. The only thing is I
might need some support for testing but thats manageable. Will
take a stab at it tomorrow and if everything goes well, post a
patch for smae.
FYI, I have some trivial patches here to drop board and mux support for
omap4 once we can make omap4 DT only, so that will be about 3000 lines
of reduction with estimated 1000 - 2000 lines once I go through the
unneeded platform init code for omap4 for things like MMC and USB.
Cool.
The rest of the clean-up issues I believe we all agree, we just need
to get it done so we can avoid getting flamed for every new SoC for
the huge data files. To fix the data issue for good, it seems that we can
get started moving both the clock and hwmod data to simple drivers
that can get clocks and hwmod data both from DT and /lib/firmware.
It also seems that we don't need to move all the data at once, which
makes the task easier.
Agree.
regards,
santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
For example, as discussed last year with the TI upstream PM team, an
important first step in this process in my view is to get rid of the
direct PRM/CM register accesses in the OMAP PM code. See commit
c4ceedcb18cf7a06059482a3a1828b9aad9f78cf (ARM: OMAP2+: CM/clock: convert
_omap2_module_wait_ready() to use SoC-independent CM functions) as an
example of this process. This should make it easier to get the PRM/CM
functionality into drivers/. That in turn make it possible to move the
clockdomain, clock, powerdomain, and hwmod code to drivers/.ARM: OMAP2+:
CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM
functions. So far as I can tell, there hasn't been any forward progress
on this.
It's also necessary to see more TI contributions in finding and fixing
regressions. Detecting and fixing regressions from the previous kernel
release should be done first, before working on cleanup series or new
feature/SoC additions. Looking at the list of v3.9-rc regressions that
I've found, we've gotten very little organized help from TI on dealing
with them.
This in turn robs the maintainers of time that could be spent doing patch
review or further cleanup work, which benefits no one in the end.
Ideally each regression would be assigned to a member of the TI upstream
team, and the whole process could be completed within one or two weeks.
...
So from my point of view, I'd like to see the following changes before we
accept any new patchsets that add a significant number of lines:
1. Organized help from TI in finding and fixing regressions in the -rc
cycle, with the regressions dealt with before any new feature
pull-requests are sent
2. Help from TI on some of the cleanup work that we've mentioned in the
past, starting with the PRM/CM register access cleanup inside mach-omap2/
3. Pairing any large feature or SoC additions with at least an equal
removal of lines of code
regards,
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
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? 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? 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. ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers More duplicated OMAP4 function prototypes here. 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=601docCategoryId=6 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. 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. ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data This one needs to be acked by Kevin. ARM: OMAP5: Enable build and frameowrk initialisations Looks fine to me. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Paul, On Monday 01 April 2013 10:35 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130320 01:43]: Tony, Here is the pull request for OMAP5 data file patches which are on list from last merge window. As aligned on list, I have dropped clock data from the series. 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. As discussed already on list, you will notice hwmod data loc has come down from ~6000 lines to ~2000 lines becasue of removal of iospace, irq, dma data as well as unused hwmods. Few hwmods for which dt conversion is pending are not added as well but those would add max ~400 loc in future. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_data_files for you to fetch changes up to 8a6a32e589a1a2a5a3fb8ebe8fc7426997bc6d89: ARM: OMAP5: Enable build and frameowrk initialisations (2013-03-19 14:09:11 +0530) Paul, do you have any comments on these? Ping. This branch should be queued separately because of the amount of LOC it adds. But as you may have other PRCM related patches then it's probably best that you queue it. Just to be clear, these are all data files patches which are auto-generated. Thes patchset has already missed last couple of merge windows and its the biggest bottleneck in getting OMAP5 booting from mainline. So I request you to please have a look it quickly so that Tony can line that up for 3.10. Thanks for help in advance !! Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
* Santosh Shilimkar santosh.shilim...@ti.com [130320 01:43]: Tony, Here is the pull request for OMAP5 data file patches which are on list from last merge window. As aligned on list, I have dropped clock data from the series. 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. As discussed already on list, you will notice hwmod data loc has come down from ~6000 lines to ~2000 lines becasue of removal of iospace, irq, dma data as well as unused hwmods. Few hwmods for which dt conversion is pending are not added as well but those would add max ~400 loc in future. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_data_files for you to fetch changes up to 8a6a32e589a1a2a5a3fb8ebe8fc7426997bc6d89: ARM: OMAP5: Enable build and frameowrk initialisations (2013-03-19 14:09:11 +0530) Paul, do you have any comments on these? This branch should be queued separately because of the amount of LOC it adds. But as you may have other PRCM related patches then it's probably best that you queue it. Regards, Tony Benoit Cousson (7): ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files ARM: OMAP5: CM: Add OMAP54XX register and bitfield files ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers ARM: OMAP5: SCRM: Add OMAP54XX header file. ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data Santosh Shilimkar (4): ARM: OMAP5: hwmod_data: Fix UART sysc settings ARM: OMAP5: hwmod-data: Add timer clock activity flags ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data ARM: OMAP5: Enable build and frameowrk initialisations arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/clockdomain.h |1 + arch/arm/mach-omap2/clockdomains54xx_data.c | 464 + arch/arm/mach-omap2/cm-regbits-54xx.h | 1737 arch/arm/mach-omap2/cm1_54xx.h| 216 ++ arch/arm/mach-omap2/cm2_54xx.h| 392 arch/arm/mach-omap2/io.c |7 + arch/arm/mach-omap2/omap_hwmod.h |1 + arch/arm/mach-omap2/omap_hwmod_54xx_data.c| 2151 arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains54xx_data.c | 331 +++ arch/arm/mach-omap2/prcm44xx.h|6 + arch/arm/mach-omap2/prcm_mpu54xx.h| 92 + arch/arm/mach-omap2/prm-regbits-54xx.h| 2701 + arch/arm/mach-omap2/prm54xx.h | 447 arch/arm/mach-omap2/scrm54xx.h| 231 +++ arch/arm/mach-omap2/voltage.h |1 + arch/arm/mach-omap2/voltagedomains54xx_data.c | 102 + 18 files changed, 8885 insertions(+) create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/cm1_54xx.h create mode 100644 arch/arm/mach-omap2/cm2_54xx.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/prm54xx.h create mode 100644 arch/arm/mach-omap2/scrm54xx.h create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Tony, Here is the pull request for OMAP5 data file patches which are on list from last merge window. As aligned on list, I have dropped clock data from the series. 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. As discussed already on list, you will notice hwmod data loc has come down from ~6000 lines to ~2000 lines becasue of removal of iospace, irq, dma data as well as unused hwmods. Few hwmods for which dt conversion is pending are not added as well but those would add max ~400 loc in future. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_data_files for you to fetch changes up to 8a6a32e589a1a2a5a3fb8ebe8fc7426997bc6d89: ARM: OMAP5: Enable build and frameowrk initialisations (2013-03-19 14:09:11 +0530) Benoit Cousson (7): ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files ARM: OMAP5: CM: Add OMAP54XX register and bitfield files ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers ARM: OMAP5: SCRM: Add OMAP54XX header file. ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data Santosh Shilimkar (4): ARM: OMAP5: hwmod_data: Fix UART sysc settings ARM: OMAP5: hwmod-data: Add timer clock activity flags ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data ARM: OMAP5: Enable build and frameowrk initialisations arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/clockdomain.h |1 + arch/arm/mach-omap2/clockdomains54xx_data.c | 464 + arch/arm/mach-omap2/cm-regbits-54xx.h | 1737 arch/arm/mach-omap2/cm1_54xx.h| 216 ++ arch/arm/mach-omap2/cm2_54xx.h| 392 arch/arm/mach-omap2/io.c |7 + arch/arm/mach-omap2/omap_hwmod.h |1 + arch/arm/mach-omap2/omap_hwmod_54xx_data.c| 2151 arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains54xx_data.c | 331 +++ arch/arm/mach-omap2/prcm44xx.h|6 + arch/arm/mach-omap2/prcm_mpu54xx.h| 92 + arch/arm/mach-omap2/prm-regbits-54xx.h| 2701 + arch/arm/mach-omap2/prm54xx.h | 447 arch/arm/mach-omap2/scrm54xx.h| 231 +++ arch/arm/mach-omap2/voltage.h |1 + arch/arm/mach-omap2/voltagedomains54xx_data.c | 102 + 18 files changed, 8885 insertions(+) create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/cm1_54xx.h create mode 100644 arch/arm/mach-omap2/cm2_54xx.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/prm54xx.h create mode 100644 arch/arm/mach-omap2/scrm54xx.h create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
