Hello.

He, Zhengting wrote:

>     I think serious customers will need to go into that level and modify the 
> drivers for their customized boards,

   Modifying the drivers for the customized boards is certainly a wrong idea
(though TI programmers seem to misunderstand this).

> special requirement etc. Without the directory/file name changes being made, 
> it is easy for them to find out where the things are that they need to 
> change. It also brings them little confusion.


   If we use "double names" in the Kconfig options, it will be relatively
simple to map the options to the source files. I certainly don't support the
idea of file names like omapl1xx_da8xx.c and we can't just rename them to
omapl1xx.c to not offend the other

> Zhengting He (Ph.D)
> Application Engineer
> DSP Catalog
> email: [email protected]
> voice: 281-274-4355
> fax: 281-274-2279

WBR, Sergei

> -----Original Message-----
> From: Kevin Hilman [mailto:[email protected]] 
> Sent: 2009年1月22日 16:05
> To: He, Zhengting
> Cc: Mark A. Greer; Longley, Lester; Wells, Kimberly; McGoldrick, Bobby; 
> Venkat, Subbu; Friedland, David; Nori, Sekhar; 
> [email protected]
> Subject: Re: omap-L1xxx

> "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.

> Kevin

>>/**************************************************************************/
>>/* Directory names to be changed                                          */
>>/**************************************************************************/
>>include/config/mach/da8xx

>>include/config/snd/da8xx

   These are autogenerated.

>>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

   This is autogenrated file.

>>drivers/usb/musb/da8xx.c

>>drivers/video/da8xx/da8xx_fb.c

>>drivers/video/da8xx/da8xx_fb.h

>>drivers/video/da8xx/da8xx_lcdc.h


   It's a long way before these drivers can get into the community kernel
yet... :-)


>>Zhengting He (Ph.D)
>>Application Engineer
>>DSP Catalog
>>email: [email protected]
>>voice: 281-274-4355
>>fax: 281-274-2279

WBR, Sergei

_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to