From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Sun, 12 Jul 2009 17:28:36 +0200 Subject: [U-Boot] OMAP MUX handling improvement In-Reply-To: <4A59F829.5010203@gmail.com> References: <20090709170309.dzm4q9q74kk0sc04@host302.hostmonster.com> <782515bb0907091806h40164862td187a1973200e559@mail.gmail.com> <20090712131357.GE7218@game.jcrosoft.org> <4A59F251.1050801@gmail.com> <4A59F3C6.2060607@googlemail.com> <4A59F829.5010203@gmail.com> Message-ID: <4A5A0124.2010108@googlemail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Nishanth Menon wrote: > Dirk Behme said the following on 07/12/2009 09:31 AM: >> Nishanth Menon wrote: >>> Jean-Christophe PLAGNIOL-VILLARD said the following on 07/12/2009 >>> 08:13 AM: >>>>>> _sread*/\ >>>>>> + MUX_VAL(CP(D2D_MBUSFLAG), (IEN | PTD | DIS | M0)) >>>>>> /*d2d_mbusflag*/\ >>>>>> + MUX_VAL(CP(D2D_SBUSFLAG), (IEN | PTD | DIS | M0)) >>>>>> /*d2d_sbusflag*/\ >>>>>> + MUX_VAL(CP(SDRC_CKE0), (IDIS | PTU | EN | M0)) >>>>>> /*sdrc_cke0*/\ >>>>>> + MUX_VAL(CP(SDRC_CKE1), (IDIS | PTU | EN | M0)) >>>>>> /*sdrc_cke1*/ >>>>>> >>>>> one more reason why the mux needs a big change in mux handling :( I >>>>> think we will end up with 1/2 a dozen crazy and code repetition for >>>>> each board... Arrggghhh... >>>>> >>>> NM: yes, it's really not easy to follow here >>>> do you plan to do it soon? >>>> >>> Been a little tied up recent days with "work load" hoping things to ease >>> down.. will try to send out a mux cleanup rev next weekend.. >> Btw, I like the way we do pin mux in U-Boot at the moment (*). Or >> better: I can't imagine a way how to do it even better without >> introducing other disadvantages. But I will enjoy to have a look to >> your changes ;) Maybe you can give us already an idea of how you like >> to change it? >> >> (*) What I like: >> >> Having everything in one file for each board. With this, you can get a >> complete overview of board's pin mux with looking only in one file. >> And you can see immediately for each pin what is configured and how. > Here are few quick things i like and dont like about the mux handling > Pros: > * Simple interface - just a #define > Cons: > * Repetition for every single board for common stuff such as Sdrc dat > regs etc.. This isn't a con for me. Having this in each board directory, you know that it is exactly right for this board and that you don't (accidentally) use some other (generic) code from somewhere else that you never checked. And you have it in one, easy maintainable file. You don't have to search for pin mux in x files scattered around in the source tree, with chance that you miss one if you want to check the pin mux for your board. > * Boards tend to enable *every* mux even if u-boot uses or not. This is a very big pro for me. Again, with this, you can be sure that the pin mux, which you have in one place, is done right for exactly this board. And you don't have to rely on broken kernel pin mux of anything else. With this, you can be sure that your board boots fine without burning something due to wrong pin mux. Even if you don't use all interfaces. > Proposal stage 1: > * move common mux out to a mux.h, where board files can use the defaults > if they like Con: Configuration scattered around in several files, see above. > -> i recollect having send such a patch out some time > back.. but I never got the time to follow up on it. > > Proposal stage 2: > * kick out mux settings from each board, which does not belong there -> > e.g. if the board does not do camera at u-boot level ->move that out to > kernel. Then you first have to fix totally broken kernel pin mux before we can do this ;) Best regards Dirk