Re: [RFC 0/4] Cleanup PRM and CM regbit headers
* Rajendra Nayak rna...@ti.com [130704 22:49]: On Thursday 04 July 2013 10:14 PM, Paul Walmsley wrote: You mentioned that these patches were generated with some kind of awk/grep scripting. Can you integrate that in an automated way into the autogeneration flow? If the answer is yes, then keep the header. If the answer is no, then the header should be dropped. Benoît, maybe you have an opinion too? Ok, I'll try and integrate those scripts so all this can be done in an automated way even for newer SoCs. As far as whether this should go in -rcX or not, my view is that, as a matter of policy, large changes like this should wait until v3.12. Now, having written that, I also was under the impression that the OMAP5 changes weren't going to be sent upstream unless the total diffstat would be balanced to roughly zero or negative lines. As far as I know, that didn't happen. So I guess, v3.11-rc it is... kernel development by diffstat :-( I don't mind these going in -rcX or 3.12, either way is fine. Removal of unused code should be OK for the early -rc. I doubt that anybody would object it especially considering that's it's a huge pile of unused defines that most likely won't ever be needed for DT based booting. Finally, please repost the whole series once you're done with your changes, as a non-RFC, along with your pull request (if you plan to send one). I guess I should be the one to take these, since I wound up taking the OMAP5 addition... :) I thought so too that you should be the one sending the pull. I will post these out as non-RFC after I do a clean integration into the autogen scripts, and then you can take a call on sending the pull for either -rcX or 3.12 I'd prefer to have it done now for the early -rc series. But if it drags on, we should not merge it during the -rc series. 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: [RFC 0/4] Cleanup PRM and CM regbit headers
* Rajendra Nayak rna...@ti.com [130625 01:49]: On Tuesday 25 June 2013 12:44 PM, Tony Lindgren wrote: Rajendra Nayak (4): ARM: OMAP2: PRM/CM: Cleanup unused header contents ARM: OMAP3: PRM/CM: Cleanup unused header contents ARM: OMAP4: PRM/CM: Cleanup unused header contents ARM: OMAP5: PRM/CM: Cleanup unused header contents arch/arm/mach-omap2/cm-regbits-24xx.h | 317 arch/arm/mach-omap2/cm-regbits-33xx.h | 758 - arch/arm/mach-omap2/cm-regbits-34xx.h | 631 arch/arm/mach-omap2/cm-regbits-44xx.h | 1557 --- arch/arm/mach-omap2/cm-regbits-54xx.h | 1632 --- arch/arm/mach-omap2/prm-regbits-24xx.h | 246 --- arch/arm/mach-omap2/prm-regbits-33xx.h | 305 arch/arm/mach-omap2/prm-regbits-34xx.h | 480 -- arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 -- arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 10 files changed, 10828 deletions(-) If things build and work after applying this, I suggest we send them as a clean-up branch right after -rc1. They build fine, and I boot tested on the omap4/5 boards that I have too. (I had the out of tree clock data pulled in for omap5 before I did this cleanup). It seems that build testing and then randconfig testing should be enough for these if they are unused and only removal. Right, I'll do more testing and even though they should just boot fine on the omap2/3 boards too since all thats removed is anyway unused, I will still do more sanity test before posting them on -rc1. Looks like we have all the pending stuff merged already, this would probably be a good time to post a pull request for these. 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: [RFC 0/4] Cleanup PRM and CM regbit headers
On Thursday 04 July 2013 05:28 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130625 01:49]: On Tuesday 25 June 2013 12:44 PM, Tony Lindgren wrote: Rajendra Nayak (4): ARM: OMAP2: PRM/CM: Cleanup unused header contents ARM: OMAP3: PRM/CM: Cleanup unused header contents ARM: OMAP4: PRM/CM: Cleanup unused header contents ARM: OMAP5: PRM/CM: Cleanup unused header contents arch/arm/mach-omap2/cm-regbits-24xx.h | 317 arch/arm/mach-omap2/cm-regbits-33xx.h | 758 - arch/arm/mach-omap2/cm-regbits-34xx.h | 631 arch/arm/mach-omap2/cm-regbits-44xx.h | 1557 --- arch/arm/mach-omap2/cm-regbits-54xx.h | 1632 --- arch/arm/mach-omap2/prm-regbits-24xx.h | 246 --- arch/arm/mach-omap2/prm-regbits-33xx.h | 305 arch/arm/mach-omap2/prm-regbits-34xx.h | 480 -- arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 -- arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 10 files changed, 10828 deletions(-) If things build and work after applying this, I suggest we send them as a clean-up branch right after -rc1. They build fine, and I boot tested on the omap4/5 boards that I have too. (I had the out of tree clock data pulled in for omap5 before I did this cleanup). It seems that build testing and then randconfig testing should be enough for these if they are unused and only removal. Right, I'll do more testing and even though they should just boot fine on the omap2/3 boards too since all thats removed is anyway unused, I will still do more sanity test before posting them on -rc1. Looks like we have all the pending stuff merged already, this would probably be a good time to post a pull request for these. Ok, will do, thanks. Paul/Benoit, Should I also drop these lines from the file headers since they are no longer same as the outputs from autogen files? * This file is automatically generated from the OMAP hardware databases. * We respectfully ask that any modifications to this file be coordinated * with the public linux-omap@vger.kernel.org mailing list and the * authors above to ensure that the autogeneration scripts are kept * up-to-date with the file contents. regards, Rajendra 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: [RFC 0/4] Cleanup PRM and CM regbit headers
On Thu, 4 Jul 2013, Rajendra Nayak wrote: Paul/Benoit, Should I also drop these lines from the file headers since they are no longer same as the outputs from autogen files? * This file is automatically generated from the OMAP hardware databases. * We respectfully ask that any modifications to this file be coordinated * with the public linux-omap@vger.kernel.org mailing list and the * authors above to ensure that the autogeneration scripts are kept * up-to-date with the file contents. Heh... Here's my view: You mentioned that these patches were generated with some kind of awk/grep scripting. Can you integrate that in an automated way into the autogeneration flow? If the answer is yes, then keep the header. If the answer is no, then the header should be dropped. Benoît, maybe you have an opinion too? As far as whether this should go in -rcX or not, my view is that, as a matter of policy, large changes like this should wait until v3.12. Now, having written that, I also was under the impression that the OMAP5 changes weren't going to be sent upstream unless the total diffstat would be balanced to roughly zero or negative lines. As far as I know, that didn't happen. So I guess, v3.11-rc it is... kernel development by diffstat :-( Finally, please repost the whole series once you're done with your changes, as a non-RFC, along with your pull request (if you plan to send one). I guess I should be the one to take these, since I wound up taking the OMAP5 addition... regards - Paul
Re: [RFC 0/4] Cleanup PRM and CM regbit headers
On Thursday 04 July 2013 10:14 PM, Paul Walmsley wrote: You mentioned that these patches were generated with some kind of awk/grep scripting. Can you integrate that in an automated way into the autogeneration flow? If the answer is yes, then keep the header. If the answer is no, then the header should be dropped. Benoît, maybe you have an opinion too? Ok, I'll try and integrate those scripts so all this can be done in an automated way even for newer SoCs. As far as whether this should go in -rcX or not, my view is that, as a matter of policy, large changes like this should wait until v3.12. Now, having written that, I also was under the impression that the OMAP5 changes weren't going to be sent upstream unless the total diffstat would be balanced to roughly zero or negative lines. As far as I know, that didn't happen. So I guess, v3.11-rc it is... kernel development by diffstat :-( I don't mind these going in -rcX or 3.12, either way is fine. Finally, please repost the whole series once you're done with your changes, as a non-RFC, along with your pull request (if you plan to send one). I guess I should be the one to take these, since I wound up taking the OMAP5 addition... :) I thought so too that you should be the one sending the pull. I will post these out as non-RFC after I do a clean integration into the autogen scripts, and then you can take a call on sending the pull for either -rcX or 3.12 -- 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: [RFC 0/4] Cleanup PRM and CM regbit headers
* Rajendra Nayak rna...@ti.com [130624 05:24]: Hi, Over the years the PRM and CM headers for OMAP have been growing largely due to autogeneration which creates headers for complete PRM and CM register space, regardless of the actual usage of these registers in software. Thanks for working on this. Yes most of this should no longer be needed. The latest master on linux-omap (which also happens to have the OMAP5 data) show these stats for the prm-regbits-*.h and cm-regbits-*.h alone. Not to mention there are other PRM/CM related headers which I am yet to look at. a0131687@ula0131687:~/oldhome/repos/github/linux$ cat arch/arm/mach-omap2/prm-regbits-*.h | wc -l 6285 a0131687@ula0131687:~/oldhome/repos/github/linux$ cat arch/arm/mach-omap2/cm-regbits-*.h | wc -l 5556 Using some simple awk/grep scripting I cleaned these headers to retain only the defines that are currently used and that changes the stats to this below. a0131687@ula0131687:~/oldhome/repos/github/linux$ cat arch/arm/mach-omap2/prm-regbits-*.h | wc -l 352 a0131687@ula0131687:~/oldhome/repos/github/linux$ cat arch/arm/mach-omap2/cm-regbits-*.h | wc -l 661 I am sharing this RFC just to take the discussion forward on how to handle these files, and many others which are also autogenerated, given we have newer SoCs coming up for which the autogen output ends up creating even larger files. Yes we should get to the point where adding new SoCs is just few hundred lines of code plus the new device drivers. Rajendra Nayak (4): ARM: OMAP2: PRM/CM: Cleanup unused header contents ARM: OMAP3: PRM/CM: Cleanup unused header contents ARM: OMAP4: PRM/CM: Cleanup unused header contents ARM: OMAP5: PRM/CM: Cleanup unused header contents arch/arm/mach-omap2/cm-regbits-24xx.h | 317 arch/arm/mach-omap2/cm-regbits-33xx.h | 758 - arch/arm/mach-omap2/cm-regbits-34xx.h | 631 arch/arm/mach-omap2/cm-regbits-44xx.h | 1557 --- arch/arm/mach-omap2/cm-regbits-54xx.h | 1632 --- arch/arm/mach-omap2/prm-regbits-24xx.h | 246 --- arch/arm/mach-omap2/prm-regbits-33xx.h | 305 arch/arm/mach-omap2/prm-regbits-34xx.h | 480 -- arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 -- arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 10 files changed, 10828 deletions(-) If things build and work after applying this, I suggest we send them as a clean-up branch right after -rc1. It seems that build testing and then randconfig testing should be enough for these if they are unused and only removal. 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: [RFC 0/4] Cleanup PRM and CM regbit headers
On Tuesday 25 June 2013 12:44 PM, Tony Lindgren wrote: Rajendra Nayak (4): ARM: OMAP2: PRM/CM: Cleanup unused header contents ARM: OMAP3: PRM/CM: Cleanup unused header contents ARM: OMAP4: PRM/CM: Cleanup unused header contents ARM: OMAP5: PRM/CM: Cleanup unused header contents arch/arm/mach-omap2/cm-regbits-24xx.h | 317 arch/arm/mach-omap2/cm-regbits-33xx.h | 758 - arch/arm/mach-omap2/cm-regbits-34xx.h | 631 arch/arm/mach-omap2/cm-regbits-44xx.h | 1557 --- arch/arm/mach-omap2/cm-regbits-54xx.h | 1632 --- arch/arm/mach-omap2/prm-regbits-24xx.h | 246 --- arch/arm/mach-omap2/prm-regbits-33xx.h | 305 arch/arm/mach-omap2/prm-regbits-34xx.h | 480 -- arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 -- arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 10 files changed, 10828 deletions(-) If things build and work after applying this, I suggest we send them as a clean-up branch right after -rc1. They build fine, and I boot tested on the omap4/5 boards that I have too. (I had the out of tree clock data pulled in for omap5 before I did this cleanup). It seems that build testing and then randconfig testing should be enough for these if they are unused and only removal. Right, I'll do more testing and even though they should just boot fine on the omap2/3 boards too since all thats removed is anyway unused, I will still do more sanity test before posting them on -rc1. regards, Rajendra -- 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
