Paul Walmsley <paul@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
