[U-Boot] [PATCH] OMAP3: Introduce CONFIG option for power code
Dirk Behme
dirk.behme at googlemail.com
Tue May 12 19:41:14 CEST 2009
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. So for me this sounds like "I have some (undiscussed)
changes in mind or in my local tree, nobody does know about, but every
new patch has to care about this (publically unknown) changes" (i.e.
this is 'supposed' to be used to use your wording). If this
understanding is right, no, this way of dealing with patches and
NACKing (?) them doesn't work. If this understanding is wrong, sorry,
please correct.
>> 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. It's board code, which normally is in
board/davinci/<board>/<board>.c file, but is moved to /common to avoid
copy & paste. Same is with OMAP3 power.c code. It was originally in
board/omap3/<board>/<board>.c file, but you (correctly) asked to move
it to a common place to avoid copy & paste. If you like, we can move
it back into <board>.c files
-- cut --
Additionally, if you don't like the Davinci example, let's take an
other one randomly chosen:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=board/freescale/mpc8568mds/mpc8568mds.c;h=8f991e537df10d8ff48d7783e00bb4aeaa231c79;hb=HEAD
Following your argumentation, for pib_init() you would need an IO
expander driver. For pci_init_board() you would need a PCI driver.
Both functions are larger than what we talk about here, btw. 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.
>> 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 ...
> or the familly name if they can be manage by
> the same driver
(no 'driver' btw)
... as mentioned above I will have a look if I can find some matching
naming and send an updated patch with this.
Best regards
Dirk
More information about the U-Boot
mailing list