From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christophe PLAGNIOL-VILLARD Date: Tue, 12 May 2009 03:13:30 +0200 Subject: [U-Boot] [PATCH] OMAP3: Introduce CONFIG option for power code In-Reply-To: <4A0708EC.3030404@googlemail.com> References: <1241623288-7105-1-git-send-email-dirk.behme@googlemail.com> <20090507204617.GE3302@game.jcrosoft.org> <4A044F6F.6080005@googlemail.com> <20090510151651.GE21079@game.jcrosoft.org> <4A0708EC.3030404@googlemail.com> Message-ID: <20090512011330.GL18336@game.jcrosoft.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > >> as davinci which is starting to be clean > > Sorry, but I can't find any board/ti which would be board/ you > mention above. Even not for davinci. I looked into u-boot-arm-master and > -next. and the code is start to be moved > > But what I can find in both trees are > > board/davinci/common > board/davinci/dvevm > board/davinci/schmoogie > board/davinci/ > > This is 100% the same layout we use for OMAP3 boards. Looks fine to me. not to me > >>> We talk about *board* specific code here, it is totally unrelated to >>> or the we use. This board specific code configures an >>> OMAP3 (SoC) external companion chip which is on the board (or not). >>> Some boards which share the basic layout have this companion chip, >>> some not. Please note that original config options (we remove with >>> this patch) were the *board* config options (e.g. >>> CONFIG_OMAP3_BEAGLE) to enable the compilation of power.c, too. >> as show now the power.c code is shared by a lot's of omap3 boards >> and as you said it's a power companion for the omap3 >> >> so 2 choices >> move the code to cpu/omap3 as it's omap3 specific > > No and no. Above I mentioned why cpu/ is wrong (because it's board > related code) and that it's not OMAP3 (SoC) specific. It's (OMAP3) > *board* specific. > >> or to drivers/ > > Driver makes no sense either, because it's not a driver. Power.c *uses* > drivers e.g. I2C (like the board code) to access board components. no I2C is the communication bus, but you write a i2c drivers to manage the power chips so it's a drivers > > Yes, I can do this. Unfortunately, you can't imagine how clever TI is > with selling mainly the same functionality (chips) with different chip > names. So most probably there is more than on chip name, and I'm not > sure if I will get them right. Most probably only TI marketing > department will get this right ;) why not start with the chip name or the familly name if they can be manage by the same driver Best Regards, J.