OMAP4 naming conventions

OMAP4 naming conventions

[Kevin Hilman]

As the OMAP4 patches are coming in, there seems to be a bit of variety
in the naming of functions/macros/variables etc.

Could I propose that we just use omap4_* and OMAP4_* instead of
OMAP44XX_* or OMAP4XXXX_* etc.

I know that OMAP2 and OMAP3 have a variety of forms here too, but
those should probably be cleaned up eventually too.

With proper runtime revision detecting, IMO, we should only really
have the OMAP4 prefix, and leave the sub revision handling to runtime
code.

Thoughts?

Kevin

RE: OMAP4 naming conventions

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Tuesday, May 12, 2009 8:29 PM
> To: linux-omap@vger.kernel.org
> Cc: Shilimkar, Santosh
> Subject: OMAP4 naming conventions
> 
> As the OMAP4 patches are coming in, there seems to be a bit of variety
> in the naming of functions/macros/variables etc.
> 
> Could I propose that we just use omap4_* and OMAP4_* instead of
> OMAP44XX_* or OMAP4XXXX_* etc.
> 
> I know that OMAP2 and OMAP3 have a variety of forms here too, but
> those should probably be cleaned up eventually too.
> 
> With proper runtime revision detecting, IMO, we should only really
> have the OMAP4 prefix, and leave the sub revision handling to runtime
> code.
> 
> Thoughts?

Full ACK.

~sanjeev

> 
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: OMAP4 naming conventions

[Tony Lindgren]

* Premi, Sanjeev <premi@ti.com> [090512 08:01]:
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org 
> > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kevin Hilman
> > Sent: Tuesday, May 12, 2009 8:29 PM
> > To: linux-omap@vger.kernel.org
> > Cc: Shilimkar, Santosh
> > Subject: OMAP4 naming conventions
> > 
> > As the OMAP4 patches are coming in, there seems to be a bit of variety
> > in the naming of functions/macros/variables etc.
> > 
> > Could I propose that we just use omap4_* and OMAP4_* instead of
> > OMAP44XX_* or OMAP4XXXX_* etc.
> > 
> > I know that OMAP2 and OMAP3 have a variety of forms here too, but
> > those should probably be cleaned up eventually too.
> > 
> > With proper runtime revision detecting, IMO, we should only really
> > have the OMAP4 prefix, and leave the sub revision handling to runtime
> > code.
> > 
> > Thoughts?
> 
> Full ACK.

Sounds good to me too.

Tony

RE: OMAP4 naming conventions

[Shilimkar, Santosh]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
> Sent: Tuesday, May 12, 2009 8:29 PM
> To: linux-omap@vger.kernel.org
> Cc: Shilimkar, Santosh
> Subject: OMAP4 naming conventions
> 
> As the OMAP4 patches are coming in, there seems to be a bit of variety
> in the naming of functions/macros/variables etc.
> *
> Could I propose that we just use omap4_* and OMAP4_* instead of
> OMAP44XX_* or OMAP4XXXX_* etc.
> 
> I know that OMAP2 and OMAP3 have a variety of forms here too, but
> those should probably be cleaned up eventually too.
> 
> With proper runtime revision detecting, IMO, we should only really
> have the OMAP4 prefix, and leave the sub revision handling to runtime
> code.
> 
> Thoughts?

Tony has also proposed this during the review. Current macros are using only OMAP44XX_* . And these can be changed to OMAP4_*

Regards,
Santosh
 

Re: OMAP4 naming conventions

[Paul Walmsley]

On Tue, 12 May 2009, Kevin Hilman wrote:

> As the OMAP4 patches are coming in, there seems to be a bit of variety
> in the naming of functions/macros/variables etc.
> 
> Could I propose that we just use omap4_* and OMAP4_* instead of
> OMAP44XX_* or OMAP4XXXX_* etc.
> 
> I know that OMAP2 and OMAP3 have a variety of forms here too, but
> those should probably be cleaned up eventually too.
> 
> With proper runtime revision detecting, IMO, we should only really
> have the OMAP4 prefix, and leave the sub revision handling to runtime
> code.
> 
> Thoughts?

Here are some questions that we should figure out answers to before 
deciding:

How should macros be named that only apply to specific OMAP4 chips (i.e., 
what happens if TI repeats a OMAP2420 to 2430 transition)?

How should macros be handled that are only applicable to later ES levels?  
Tagging ES levels in macros has caught many bugs in the OMAP2/3 code.


- Paul

Re: OMAP4 naming conventions

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> On Tue, 12 May 2009, Kevin Hilman wrote:
>
>> As the OMAP4 patches are coming in, there seems to be a bit of variety
>> in the naming of functions/macros/variables etc.
>> 
>> Could I propose that we just use omap4_* and OMAP4_* instead of
>> OMAP44XX_* or OMAP4XXXX_* etc.
>> 
>> I know that OMAP2 and OMAP3 have a variety of forms here too, but
>> those should probably be cleaned up eventually too.
>> 
>> With proper runtime revision detecting, IMO, we should only really
>> have the OMAP4 prefix, and leave the sub revision handling to runtime
>> code.
>> 
>> Thoughts?
>
> Here are some questions that we should figure out answers to before 
> deciding:
>
> How should macros be named that only apply to specific OMAP4 chips (i.e., 
> what happens if TI repeats a OMAP2420 to 2430 transition)?

I would propose a convention something like:

- OMAP4_* - applies to all OMAP4 chips
- OMAP4xyz_* - applies to the specific 4xyz rev

> How should macros be handled that are only applicable to later ES
> levels?  Tagging ES levels in macros has caught many bugs in the
> OMAP2/3 code.

Since the ES revs would be specific to particular 'xyz' rev, The above
could be extended to use something like OMAP4xyzESn_*

Kevin