[PATCH 2/3] ARM: dts: imx: replace magic number with pin function name

[Shawn Guo]

On Fri, Feb 22, 2013 at 08:27:43AM +0100, Sascha Hauer wrote:
> On Fri, Feb 22, 2013 at 01:52:04PM +0800, Shawn Guo wrote:
> > On Thu, Feb 21, 2013 at 11:36:36AM -0600, Matt Sealey wrote:
> > > On Wed, Feb 20, 2013 at 11:02 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> > > > On Wed, Feb 20, 2013 at 06:03:39PM -0600, Matt Sealey wrote:
> > > >> I am not sure I am getting this point across, but.. damn it.. nack nack nack :D
> > > >>
> > > > Do you see any downgrade side that the series introduces over the
> > > > existing implementation?
> > > 
> > > Because it replaces the horribly stupid existing implementation with
> > > something that doesn't solve the fundamental logical problems caused
> > > by the existing implementation.
> > 
> > When did I say that the series is targeting to solve those "fundamental
> > logical problems" in *your* view?
> > 
> > ...
> > 
> > > What you've fixed it to do, as I read this patch, is this;
> > > 
> > > <arbitrary_pin_name pad_mode>
> > > 
> > No, it's not arbitrary_pin_name.  It's pin function name which comes
> > from hardware manual.  It may not exactly match the public reference
> > manual, but they are obvious to be identified.  For imx6q pad SD2_DAT1
> > example, the manual says:
> > 
> > Select 1 of 6 iomux modes to be used for pad: SD2_DAT1.
> >   000 ALT0 — Select signal SD2_DATA1.
> >   001 ALT1 — Select signal ECSPI5_SS0.
> >   010 ALT2 — Select signal EIM_CS2.
> >   011 ALT3 — Select signal AUD4_TXFS.
> >   100 ALT4 — Select signal KEY_COL7.
> >   101 ALT5 — Select signal GPIO1_IO14.
> 
> What makes them arbitrary is the fact that 110 and 111 are not encoded,
> so there is no way to calculate the register number from the pin number.
> 
> Also
> 
> commit 4a5f7eff8b0b34354e5c63272835e5e2dfe1c933
> Author: Dong Aisheng <dong.aisheng at linaro.org>
> Date:   Fri Jul 6 17:09:23 2012 +0800
> 
>     pinctrl: pinctrl-imx6q: add missed mux function for USBOTG_ID
> 
> Shows that they are indeed arbitrary.
> 
> I'm really with Matt here when he says that this number doesn't have to
> be in the binding.

I think you are still talking about that arbitrary index in the old
binding, while I'm arguing against Matt's the comment on the new one,
saying the macro/pin name is arbitrary.

Shawn