Re: [RFC 0/4] Cleanup PRM and CM regbit headers

2013-07-05 Thread Tony Lindgren
* Rajendra Nayak  [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

2013-07-04 Thread Rajendra Nayak
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

2013-07-04 Thread Paul Walmsley
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

2013-07-04 Thread Rajendra Nayak
On Thursday 04 July 2013 05:28 PM, Tony Lindgren wrote:
> * Rajendra Nayak  [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

2013-07-04 Thread Tony Lindgren
* Rajendra Nayak  [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

2013-06-25 Thread Rajendra Nayak
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


Re: [RFC 0/4] Cleanup PRM and CM regbit headers

2013-06-25 Thread Tony Lindgren
* 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
--
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