[U-Boot] [PATCH] OMAP3: Introduce CONFIG option for power code

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

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

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