"He, Zhengting" <[email protected]> writes: > Hi, All, > After some discussion internally in TI, I think we (as TI catalog) would > like to change the proposal a little bit. > > 1. The macros and source code will have da830 only. (no change) > 2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no change) > 3. The defconfig would be called da830_omapl137_defconfig (no change).
So far, so good. > 4. The file and directory names should also have omapl137. (CHANGE) > > I have listed the following directory and file names which are > required to be changed. (There are not many). With the > file/directory name change, OMAPL137 users can tell which code is > specifically applicable to OMAPL137 at a first glance. Does everyone > agree this change? Personally, I think this is a bit cumbersome. I'm perfectly fine with the user-visible names and strings having both, but enforcing this type of naming into the kernel structure itself is overkill IMHO. Do you expect most users to be digging into the kernel at that level? If so, I would rather see this addressed in Documentation that comes with the product rather than having filenames carry the burden. My $0.02. Kevin > /**************************************************************************/ > /* Directory names to be changed */ > /**************************************************************************/ > include/config/mach/da8xx > > include/config/snd/da8xx > > arch/arm/mach-da8xx > > drivers/char/da8xx_lcd > > drivers/video/da8xx > > /**************************************************************************/ > /* File names to be changed */ > /**************************************************************************/ > arch/arm/mach-da8xx/da8xx.h > > include/config/rtc/drv/da8xx.h > > drivers/usb/musb/da8xx.c > > drivers/video/da8xx/da8xx_fb.c > > drivers/video/da8xx/da8xx_fb.h > > drivers/video/da8xx/da8xx_lcdc.h > > > > Zhengting He (Ph.D) > Application Engineer > DSP Catalog > email: [email protected] > voice: 281-274-4355 > fax: 281-274-2279 > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Mark A. Greer > Sent: 2009年1月22日 11:54 > To: Longley, Lester > Cc: [email protected]; Wells, Kimberly; > McGoldrick, Bobby > Subject: Re: omap-L1xxx > > On Thu, Jan 22, 2009 at 09:53:43AM -0600, Longley, Lester wrote: >> Hi Mark, >> >> From: Mark A. Greer [mailto:[email protected]] >> > On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote: >> > > "Longley, Lester" <[email protected]> writes: >> > > >> > > [ ... ] >> > > >> > > > From: Sergei Shtylyov [mailto:[email protected]] >> > > >> > > [ ... ] >> > > >> > > >> So, how should we reference to OMAP-L1x in kernel (in order to >> > > >> avoid the >> > > >> confusion with real OMAP)? >> > > > >> > > > It's the strong preference from my group, Performance Media, that >> > > > "da830" be *included* in the name. >> > > >> > > Lester, thanks for sharing the views of your group. >> > > >> > > Do you mean included along with the omapl1x name? Or would your team >> > > be OK with only the da830 naming (which would be my preference)? >> > > >> > > For in-kernel code, I think it would be *really* clumsy to have both. >> > > In other words, I would much rather have >> > > >> > > #define DA830_MY_VAR >> > > void da830_my_func(void); >> > > >> > > OR >> > > >> > > #define OMAPL1X_MY_VAR >> > > void omapl1x_my_func(void); >> > > >> > > instead of: >> > > >> > > #define DA830_OMAPL1X_MY_VAR >> > > void da830_omapl1x_my_func(void); >> > > >> > > Which I think would be more confusing than informative. >> > > >> > > > Maybe one could consider that a side benefit of such naming is >> > > > easier distinction versus "real OMAP" (or maybe "original OMAP"). >> > > >> > > Yes, I think that using the d830 naming only would avoid this >> > > confusion. >> > > >> > > > Moreover, many users of the chip will utilize the DSP-side audio >> > > > code available for DA830, and so helping them readily identify the >> > > > appropriate kernel is important to them & to us. This need can >> > > > hopefully be addressed by inclusion of "da830_" prefix in the kernel >> > > > name. >> > > >> > > Will these users have much visibility into the in-kernel naming? Or >> > > are you primarily concerned with the naming of how the kernel as it is >> > > packaged and visible to non kernel-developers. >> > >> > To try to get closure, here is a proposal: >> > >> > File names/macros/config options will have da830 only but the menuconfig >> > prompts will have "DA830/OMAP-L137" in them. The defconfig would be >> > called da8xx_omapl137_defconfig. >> > >> > Everyone agree? >> >> Did you mean "da830_omapl137_defconfig", rather than >> "da8xx_omapl137_defconfig"? > > Oops, yes, that's what I meant. Sorry... > > Mark > -- > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
