[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Dirk Behme]

Dear Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 07:40 Sun 28 Jun     , Dirk Behme wrote:
>> Dear Jean-Christophe,
>>
>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 19:12 Thu 25 Jun     , Jason Kridner wrote:
>>>>   On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD
>>>>   <plagnioj at jcrosoft.com> wrote:
>>>>
>>>>     On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
>>>>     > The update consists of following changes:
>>>>     > - remove configuration of not connected pins, effectively
>>>>     >   leaving them in safe mode.
>>>>     > - remove unused GPIOs, setup newly added ones.
>>>>     > - setup pulls for various GPIOs. Disable pulls for game
>>>>     >   buttons, as they have external pulls.
>>>>     > - SDRC CS change based on recent patch for
>>>>     >   Beagle and Overo.
>>>>     >
>>>>     > Old boards are no longer supported, but there was only
>>>>     > small number of test boards made. Updated configuration
>>>>     > is expected to be used for mass production.
>>>>     If user have old version in possession NACK
>>>>
>>>>   I believe no users who would possibly object have the old version (or any
>>>>   version) in possession.  Only the core developers ever got
>>>> these boards.    Is the expectation to create #ifdef or some
>>>> sort of auto-detection
>>>>   (unlikely possible)?
>>> untill the hardware will be really not anymore use yes please
>> If two or three people (from the board manufacturer?) which are more
>> familiar with the development board situation than you say "we don't
>> need it" then this should be accepted. If nobody uses the older
>> boards any more (and this is what I understood they said: "There
>> were only few older boards, we know where they are and they are
>> replaced by new ones") then there is absolutely no reason to pollute
>> U-Boot with support for it. There is no need to add dead code to
>> U-Boot.
> No, it's different no people have a board and some people have a board

What I read is

"no users ... ever got these boards"

I would bet that you have some early (broken?) alpha boards not being 
supported by U-Boot and never used because replaced by fixed 
revisions, too.

>> We should trust the board maintainers somehow.
> It's not me who tell that some people have the board

What I read is

"some internal developers have these boards and they have no problem 
that they are not supported by U-Boot"

> when you will be in possession of the old version of a board and just because
> few people have the board is remove from the mainline you will not be happy.
> So no we will support the both
>>>>     this kind of huge update is non bisectable so we do need to use a true
>>>>     mux api
>>>>     as the kernel lot's of other arch in u-boot
>>>>
>>>>   Why is it not bisectable?
>>> because your mix cleanup, fixup and new board support
>>>>   Do you have a "true mux api" to suggest?
>>> the same as the kernel one is the best for code sharing
>> OMAP3 pin mux in kernel is totally broken.
> do you really think it's a good reason to have copy & paster 

I can't see any copy & paste. What I can see is individual consistent 
pin mux for each board. And that's fine due to different mux 
*necessary* for each board. Not having board specific pin mux in 
kernel is the main reason for broken pin mux in kernel. So what you 
complain about here is the main advantage of U-Boot.

> not a simple api as at91, davinic and others?

I doubt that at91 pin mux api can be used efficiently for OMAP3. But 
I'm happy to be proven the opposite by you :)

What I really think it's not a good reason to make lot of users of a 
final board to depend on an U-Boot fork instead of mainline just 
because of not merging this simple patch.

Best regards

Dirk