From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christophe PLAGNIOL-VILLARD Date: Wed, 13 May 2009 00:34:57 +0200 Subject: [U-Boot] [PATCH] OMAP3: Introduce CONFIG option for power code In-Reply-To: <4A09B4BA.6070402@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> <20090512011330.GL18336@game.jcrosoft.org> <4A09B4BA.6070402@googlemail.com> Message-ID: <20090512223457.GH479@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 On 19:41 Tue 12 May , Dirk Behme wrote: > Dear Jean-Christophe, > > Jean-Christophe PLAGNIOL-VILLARD wrote: > > [some unanswered questions removed here?] > >>>> 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 > > Sorry, but this confuses me because I can't find this "start" anywhere. davinci: display correct clock info http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=5516e87d057c13fce05b6fc6e56cf3f4ddfc36b4 davinci: move psc support board-->cpu http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=20bb2384e2b81e77880993134c8f268d59fdfe07 > >>> 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 > > Then, as the easiest way of dealing with directory/file moves is doing > it directly in your git, the best would be if you do this re-sorting > directly. > > NACKing a quite trivial patch (this one) because of an existing > directory/file layout you don't like, while you requested yourself this > change we talk about, and making it a show stopper for adding additional > boards [1] like e.g. Matthias' one, sounds somehow strange to me, btw. > > [1] http://lists.denx.de/pipermail/u-boot/2009-April/051383.html > >>>>> 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 > > No. I don't write a driver. I just use a driver. If you want to name > code that uses a driver a driver again, then you wouldn't need the board > directory any more. Unfortunately, you removed my argumentation > regarding this from the previous mail: > > -- cut -- > .... access board components. If you would move power.c to drivers, it > would be similar if you would move everything in board/* to drivers. > > Please have a look to code in board/davinci/common. These are no > drivers, too. in correct as recently the soc code as device init was move to cpu/arm926ejs/davinci this only remaining code is the trivial dram_init and the EEProm Mac address management > If you go on with > this, you have to create a LED driver for a one liner which > enables/disables a LED using a gpio driver. And at the end you will have > an empty board directory. it's done for the at91 led drivers to avoid copy&paste and it's in cpu/arm926ejs/at91 > >>> 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 > > I think I mentioned above that there are "different chip names". But > anyway ... I agree but to simplify it why not use at the beggening the current supported or use chip > >> or the familly name if they can be manage by >> the same driver > > (no 'driver' btw) we disagree on the term driver is this chip is useable for other board than omap3? if yes (which I suspect correct me if I'm wrong) then it's use is not omap3 specific at all > > ... as mentioned above I will have a look if I can find some matching > naming and send an updated patch with this. ok Best Regards, J.