From: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> To: Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> Cc: "Dong Aisheng" <dong.aisheng-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, devicetree-discuss <devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>, "Rob Herring" <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>, "Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, "Linux ARM Kernel ML" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org> Subject: Re: [PATCH 2/3] ARM: dts: imx: replace magic number with pin function name Date: Thu, 21 Feb 2013 22:43:03 +0100 [thread overview] Message-ID: <20130221214303.GB1906@pengutronix.de> (raw) In-Reply-To: <CAKGA1bn22xctSj_33HQsWwnVB=RO2OJ=eYvgRD-kF+PiQcnC4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. There are three completely obvious > logical inconsistencies with the existing implementation of a pair of > <arbitrary_pin_index pad_mode>; > > 1) the pin index is completely arbitrary and in any binding every > published for any of these SoC, either broken by design (MX5 and MX6 > have duplicated pin data soaking up arbitrary pin ids in the current > binding, or are not defined in SoC register order (i.e. arbitrary > renumbering). The pin index is indeed completely arbitrary, mostly because the iomuxv3 does not make it possible to number pins. More sane SoCs offered that, there a Pin number could be easily translated into a register offset. I don't know what drugs the FSL engineers have taken to come up with a register layout in which each pin is configured via three register sets which do not stand in any relationship to each other. Unfortunately the pinctrl framework forces us to use a pin index as it needs something to detect resource conflicts. BUT, I think I agree here with you: This pin number should not be exposed to the devicetree, it only adds a level of indirection. > > 2) the pin index is not internally consistent within the device tree > binding - it is a reference to an array inside source code. Your patch > hopes to solve this, but also hopes to solve other things too. It > fails on the second part. > > 3) the pad setting value has been hijacked to include bits that > otherwise would not be set in the same register (SION bit and a > special flag to mean, set up everything except the pad settings) > > What you've fixed it to do, as I read this patch, is this; > > <arbitrary_pin_name pad_mode> > > which the preprocessor expands to; > > <reg_mux mux_mode reg_insel insel_mode reg_pad pad_mode> > > The real problem here is as follows; > > 1) the pin name and function name are still completely arbitrary (in > so far as the old iomux.h macros way, the newer iomux-v3.h way, the > current bindings and the new binding you're pushing do not match the > CPU documentation at all) > > 2) copy pasting a line of 5 values from an example document and adding > your pad mode bits to the end is no more time consuming or > space-consuming than copying a 38-character macro name. New board > designs will use data from the FSL IOMUX tool or other sources and not > bother using macro definitions to define pads. > > 3) macros can be wrong and they will inherit into every device tree, > breaking every board that uses them. That said, so can the examples, > but at least reading the device tree for a board you can cross-check > all the values against, say, the output of many tools provided by > Freescale or existing code or platform support without doing a back > reference or preprocessing the device tree and removing comments). > Yes, macros can be wrong, but they tend to get fixed. Duplicated information almost never gets fixed in all instances they occur. > > MX51_PIN_EIM_23__GPIO1_2 0x6528 > > < > MUX_REG(0x174) ALT(0x5|SION) INS_REG(0x3d8) INS(0x7) PAD_REG(0x654) > PAD(0x7633|PU_100K), /* MX51_EIM_23 GPIO1_2 */ > >; This is basically what the current iomux header do, only that we added the mux/padctrl/selinput register triplet to a single macro. This in my eyes still makes sense, because digging through the datasheet guessing that for a single pin I have to configure registers 0x174, 0x3d8 and 0x654 is cumbersome. Where it became ugly is the predefined values for pullup/dse. Yes, I would really like to have something like you describe above in the devicetree together with the register triplets as handy macros. Also I still like the <pinname>__<function> naming since that's another thing I don't have to look up in the datasheet everytime. If your data comes from the iomux tool then you simply wouldn't use the register triplet macros. This would leave the question how we make up a pin number for the pinctrl framework, but as said, this should be solved inside the kernel and not pushed into the devicetree. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: s.hauer@pengutronix.de (Sascha Hauer) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/3] ARM: dts: imx: replace magic number with pin function name Date: Thu, 21 Feb 2013 22:43:03 +0100 [thread overview] Message-ID: <20130221214303.GB1906@pengutronix.de> (raw) In-Reply-To: <CAKGA1bn22xctSj_33HQsWwnVB=RO2OJ=eYvgRD-kF+PiQcnC4Q@mail.gmail.com> 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@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. There are three completely obvious > logical inconsistencies with the existing implementation of a pair of > <arbitrary_pin_index pad_mode>; > > 1) the pin index is completely arbitrary and in any binding every > published for any of these SoC, either broken by design (MX5 and MX6 > have duplicated pin data soaking up arbitrary pin ids in the current > binding, or are not defined in SoC register order (i.e. arbitrary > renumbering). The pin index is indeed completely arbitrary, mostly because the iomuxv3 does not make it possible to number pins. More sane SoCs offered that, there a Pin number could be easily translated into a register offset. I don't know what drugs the FSL engineers have taken to come up with a register layout in which each pin is configured via three register sets which do not stand in any relationship to each other. Unfortunately the pinctrl framework forces us to use a pin index as it needs something to detect resource conflicts. BUT, I think I agree here with you: This pin number should not be exposed to the devicetree, it only adds a level of indirection. > > 2) the pin index is not internally consistent within the device tree > binding - it is a reference to an array inside source code. Your patch > hopes to solve this, but also hopes to solve other things too. It > fails on the second part. > > 3) the pad setting value has been hijacked to include bits that > otherwise would not be set in the same register (SION bit and a > special flag to mean, set up everything except the pad settings) > > What you've fixed it to do, as I read this patch, is this; > > <arbitrary_pin_name pad_mode> > > which the preprocessor expands to; > > <reg_mux mux_mode reg_insel insel_mode reg_pad pad_mode> > > The real problem here is as follows; > > 1) the pin name and function name are still completely arbitrary (in > so far as the old iomux.h macros way, the newer iomux-v3.h way, the > current bindings and the new binding you're pushing do not match the > CPU documentation at all) > > 2) copy pasting a line of 5 values from an example document and adding > your pad mode bits to the end is no more time consuming or > space-consuming than copying a 38-character macro name. New board > designs will use data from the FSL IOMUX tool or other sources and not > bother using macro definitions to define pads. > > 3) macros can be wrong and they will inherit into every device tree, > breaking every board that uses them. That said, so can the examples, > but at least reading the device tree for a board you can cross-check > all the values against, say, the output of many tools provided by > Freescale or existing code or platform support without doing a back > reference or preprocessing the device tree and removing comments). > Yes, macros can be wrong, but they tend to get fixed. Duplicated information almost never gets fixed in all instances they occur. > > MX51_PIN_EIM_23__GPIO1_2 0x6528 > > < > MUX_REG(0x174) ALT(0x5|SION) INS_REG(0x3d8) INS(0x7) PAD_REG(0x654) > PAD(0x7633|PU_100K), /* MX51_EIM_23 GPIO1_2 */ > >; This is basically what the current iomux header do, only that we added the mux/padctrl/selinput register triplet to a single macro. This in my eyes still makes sense, because digging through the datasheet guessing that for a single pin I have to configure registers 0x174, 0x3d8 and 0x654 is cumbersome. Where it became ugly is the predefined values for pullup/dse. Yes, I would really like to have something like you describe above in the devicetree together with the register triplets as handy macros. Also I still like the <pinname>__<function> naming since that's another thing I don't have to look up in the datasheet everytime. If your data comes from the iomux tool then you simply wouldn't use the register triplet macros. This would leave the question how we make up a pin number for the pinctrl framework, but as said, this should be solved inside the kernel and not pushed into the devicetree. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2013-02-21 21:43 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-20 7:08 [PATCH 0/3] Get rid of big array from imx pinctrl driver Shawn Guo 2013-02-20 7:08 ` [PATCH 1/3] ARM: dts: imx: use pre-processor for device trees Shawn Guo 2013-02-20 9:26 ` Dong Aisheng 2013-02-20 9:25 ` [PATCH 0/3] Get rid of big array from imx pinctrl driver Dong Aisheng [not found] ` <1361344089-16804-3-git-send-email-shawn.guo@linaro.org> 2013-02-20 9:30 ` [PATCH 2/3] ARM: dts: imx: replace magic number with pin function name Dong Aisheng [not found] ` <1361344089-16804-3-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2013-02-20 18:46 ` Stephen Warren 2013-02-20 18:46 ` Stephen Warren [not found] ` <51251A11.2030300-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-02-21 0:03 ` Matt Sealey 2013-02-21 0:03 ` Matt Sealey [not found] ` <CAKGA1bkHH1XC38_VM=QhDrr33uqqSbwe0n+GfXEPs43K_Do=CQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-02-21 0:34 ` Stephen Warren 2013-02-21 0:34 ` Stephen Warren 2013-02-21 5:02 ` Shawn Guo 2013-02-21 5:02 ` Shawn Guo [not found] ` <20130221050247.GD17738-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org> 2013-02-21 17:36 ` Matt Sealey 2013-02-21 17:36 ` Matt Sealey [not found] ` <CAKGA1bn22xctSj_33HQsWwnVB=RO2OJ=eYvgRD-kF+PiQcnC4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-02-21 17:57 ` Matt Sealey 2013-02-21 17:57 ` Matt Sealey 2013-02-21 21:43 ` Sascha Hauer [this message] 2013-02-21 21:43 ` Sascha Hauer [not found] ` <20130221214303.GB1906-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2013-02-22 7:58 ` Shawn Guo 2013-02-22 7:58 ` Shawn Guo 2013-02-22 5:52 ` Shawn Guo 2013-02-22 5:52 ` Shawn Guo [not found] ` <20130222055203.GB27371-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org> 2013-02-22 7:27 ` Sascha Hauer 2013-02-22 7:27 ` Sascha Hauer [not found] ` <20130222072743.GC1906-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2013-02-22 7:36 ` Shawn Guo 2013-02-22 7:36 ` Shawn Guo [not found] ` <20130222073630.GC27371-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org> 2013-02-22 8:12 ` Sascha Hauer 2013-02-22 8:12 ` Sascha Hauer 2013-02-27 6:51 ` Matt Sealey 2013-02-27 6:51 ` Matt Sealey [not found] ` <CAKGA1bmw+CzBDLHty1+L1VdeWLgkPpLSLpGKBJEeQj-ByyzicA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-02-27 7:44 ` Sascha Hauer 2013-02-27 7:44 ` Sascha Hauer [not found] ` <20130227074404.GD1906-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2013-02-27 18:16 ` Matt Sealey 2013-02-27 18:16 ` Matt Sealey [not found] ` <CAKGA1bmqdCiocc_O6hU3ym6uJ-bAjwKMNrt43Qs_dkjEGpX-KQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-02-27 20:00 ` Sascha Hauer 2013-02-27 20:00 ` Sascha Hauer 2013-02-28 3:06 ` Shawn Guo 2013-02-28 3:06 ` Shawn Guo 2013-02-21 4:59 ` Shawn Guo 2013-02-21 4:59 ` Shawn Guo [not found] ` <1361344089-16804-4-git-send-email-shawn.guo@linaro.org> 2013-02-20 9:44 ` [PATCH 3/3] pinctrl: imx: move hard-coding data into device tree Dong Aisheng 2013-02-21 6:04 ` Shawn Guo [not found] ` <1361344089-16804-4-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2013-02-20 19:04 ` Stephen Warren 2013-02-20 19:04 ` Stephen Warren [not found] ` <51251E5A.1080806-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-02-21 5:30 ` Shawn Guo 2013-02-21 5:30 ` Shawn Guo [not found] ` <20130221053020.GE17738-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org> 2013-02-21 7:55 ` Sascha Hauer 2013-02-21 7:55 ` Sascha Hauer 2013-02-21 9:36 ` Dong Aisheng 2013-02-21 9:36 ` Dong Aisheng [not found] ` <CAP1dx+w2bLcztrRJOYs07xxSqVgo3bggJHMFt5LyL5jXQ-h6Mg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-02-21 19:57 ` Stephen Warren 2013-02-21 19:57 ` Stephen Warren [not found] ` <51267C0E.6070902-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2013-02-26 8:02 ` Dong Aisheng 2013-02-26 8:02 ` Dong Aisheng
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130221214303.GB1906@pengutronix.de \ --to=s.hauer-bicnvbalz9megne8c9+irq@public.gmane.org \ --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \ --cc=dong.aisheng-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org \ --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \ --cc=u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.