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....@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.aish...@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 _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss