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 > >>>> <plagn...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
