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

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

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

Best Regards,
J.