[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
Jean-Christophe PLAGNIOL-VILLARD
plagnioj at jcrosoft.com
Sun Jun 28 13:50:44 CEST 2009
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
Best Regards,
J.
More information about the U-Boot
mailing list