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

[Jean-Christophe PLAGNIOL-VILLARD]

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