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/<vendor> 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=5516e87d057c13fce05b6... davinci: move psc support board-->cpu http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=20bb2384e2b81e7788099...
But what I can find in both trees are
board/davinci/common board/davinci/dvevm board/davinci/schmoogie board/davinci/<all other Davinci boards>
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 <arch> or the <soc> 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.