From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [RFC 0/4] Cleanup PRM and CM regbit headers Date: Tue, 25 Jun 2013 00:14:28 -0700 Message-ID: <20130625071428.GC5523@atomide.com> References: <1372076143-12955-1-git-send-email-rnayak@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-02-ewr.mailhop.org ([204.13.248.72]:30360 "EHLO mho-02-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750936Ab3FYHOe (ORCPT ); Tue, 25 Jun 2013 03:14:34 -0400 Content-Disposition: inline In-Reply-To: <1372076143-12955-1-git-send-email-rnayak@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Rajendra Nayak Cc: paul@pwsan.com, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org * Rajendra Nayak [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