From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 22 Jan 2013 17:21:20 -0700 Subject: [U-Boot] [PATCH] tegra: implement pinmux_avoid_func() In-Reply-To: References: <1358871699-31964-1-git-send-email-swarren@wwwdotorg.org> <50FF0415.4080601@wwwdotorg.org> <50FF0F39.8030707@wwwdotorg.org> Message-ID: <50FF2D00.2020803@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 01/22/2013 05:03 PM, Simon Glass wrote: > Hi Stephen, > > On Tue, Jan 22, 2013 at 2:14 PM, Stephen Warren wrote: >> On 01/22/2013 02:42 PM, Simon Glass wrote: >>> Hi Stephen, >>> >>> On Tue, Jan 22, 2013 at 1:26 PM, Stephen Warren wrote: >>>> On 01/22/2013 02:13 PM, Simon Glass wrote: >>>>> Hi Stephen, >>>>> >>>>> On Tue, Jan 22, 2013 at 8:21 AM, Stephen Warren wrote: >>>>>> From: Stephen Warren >>>>>> >>>>>> This selects the "safe" (non-conflicting) mux function for a pin group >>>>>> if the current setting matches the specified function. >>>>>> >>>>>> Many signals can be routed to or from multiple different groups. Each >>>>>> signal must be routed to or from only a single group at a given time. >>>>>> Hence, if we program a particular group for a function, we must ensure >>>>>> no other group is programmed to that same function first. This API >>>>>> makes this easy. >>>>> >>>>> What is the intended use of this function? (sorry, yes, I am confused :-) >>>> >>>> It's a safer way of doing this: >>>> "tegra: pinmux: fix FUNCMUX_NDFLASH_KBC_8_BIT" >>>> http://lists.denx.de/pipermail/u-boot/2013-January/144612.html >>>> >>>> i.e. it address the concerns I raised here: >>>> http://lists.denx.de/pipermail/u-boot/2013-January/144713.html >>>> >>> >>> OK thank you. So is your function only intended for use with T20? >> >> No, I imagine that it should be used for all Tegras; I just wrote it >> long enough ago that there was only Tegra20 at the time. I assume that >> if Lucas wants to use this function as a pre-cursor to his NAND pinmux >> change, he'll update it for whatever Tegra versions are checked in at >> the time first. >> > Thanks, I get it. > > Should Lucas consider adding a warning or some sort of indication that > the function did nothing? Do you mean on Tegra30 where it isn't implemented yet (no - I'd expect to see this implemented instead) or when the current function programmed into HW already doesn't match the value one is trying to avoid (no - I'd expect this to be quite common).