On Fri, 2009-01-23 at 15:13 -0600, Steve Chen wrote: > On Fri, 2009-01-23 at 14:15 -0600, He, Zhengting wrote: > > Sergei, > > > > Why do you think "modifying the drivers for customized boards is a > > wrong idea"? MV or open source cannot support every board that every > > customer makes, right? Or do I misunderstanding your point? > Drivers should be generic which can be shared by arch type (SOC).
^^ several > Typically, a customer would modify or create board specific code for > their custom hardware. > > > > > When you said "we can't just rename them to omapl1xx.c to not offend > > the other", do you mean renaming it will change other part of the source > > code, makefile etc.? It might be tedious but is that a lot of effort? > > > > Zhengting He (Ph.D) > > Application Engineer > > DSP Catalog > > email: [email protected] > > voice: 281-274-4355 > > fax: 281-274-2279 > > > > > > > > > > -----Original Message----- > > From: Sergei Shtylyov [mailto:[email protected]] > > Sent: 2009年1月23日 13:44 > > To: He, Zhengting > > Cc: Kevin Hilman; [email protected]; Wells, > > Kimberly; McGoldrick, Bobby; Venkat, Subbu; Friedland, David > > Subject: Re: omap-L1xxx > > > > 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 > > > _______________________________________________ > 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
