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

[Dirk Behme]

Dear Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:11 Sun 28 Jun     , Dirk Behme wrote:
>> 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.
> They will not have to be mainline until the hardware will be stablized
> or you need to understand board revision support
> as we need to consider this patch as adding a new board not fixing some pio
> mux. It must be clear for anyone that want to bisect code and/or understand what
> you have done
>>>> 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 :)
> I work on complex pin mux system for other soc and arch for years and you can
> simplify it
> 
> You can look in U-Boot or in the kernel you do have this kind of
> implementation. I do not care of wich api we will have but I do want a
> simplest one and one that need to respect these requierements
>  - Human readable
>  - code sharing
>  - only init what is used by U-Boot
> 
>> 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.
> please do not mix mainline requirement and production requirement

No, I do mix. Especially if it so simple as here. The main mainline 
requirement is to solve the problems of our users. By providing them a 
good and flexible boot loader.

If we can serve U-Boot users for a production board with mainline as 
easy as here, we should do it. It doesn't help U-Boot (and open source 
in general?) if we don't care about our users. They want working code 
from mainline, and don't care if the same functionality might be done 
with some even more perfect code. And in this special case, we can 
easily support our users with merging this patch in mainline now and 
improve pin mux silently in the next step.

Best regards

Dirk