linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/3] pinctrl: imx: add pinmux-imx53 support
Date: Mon, 5 Dec 2011 22:18:38 +0100	[thread overview]
Message-ID: <20111205211838.GG27267@pengutronix.de> (raw)
In-Reply-To: <CACRpkdaYz+-nZA6atxA+5kvWOO84YeSHQPNiojq_R4zkHUGz3Q@mail.gmail.com>

On Mon, Dec 05, 2011 at 05:57:42PM +0100, Linus Walleij wrote:
> On Sun, Dec 4, 2011 at 12:49 PM, Dong Aisheng <b29396@freescale.com> wrote:
> 
> > +enum imx_mx53_pads {
> > + ? ? ? MX53_GPIO_19 = 0,
> > + ? ? ? MX53_KEY_COL0 = 1,
> (...)
> 
> First I thought it looked a bit strange since you needed enums for all pads
> but then I realized that your macros use the same enumerator name to
> name the pad and then it looks sort of clever.
> 
> But maybe put in a comment about that here:
> 
> > +/* Pad names for the pinmux subsystem */
> 
> Like this:
> 
> /*
>  * Pad names for the pinmux subsystem.
>  * These pad names are constructed from the pin enumerator names
>  * in the IMX_PINCTRL_PIN() macro.
>  */
> 
> > +static const struct pinctrl_pin_desc mx53_pads[] = {
> > + ? ? ? IMX_PINCTRL_PIN(MX53_GPIO_19),
> > + ? ? ? IMX_PINCTRL_PIN(MX53_KEY_COL0),
> (...)
> 
> > +/* mx53 pin groups and mux mode */
> > +static const unsigned mx53_fec_pins[] = {
> > + ? ? ? MX53_FEC_MDC,
> > + ? ? ? MX53_FEC_MDIO,
> > + ? ? ? MX53_FEC_REF_CLK,
> > + ? ? ? MX53_FEC_RX_ER,
> > + ? ? ? MX53_FEC_CRS_DV,
> > + ? ? ? MX53_FEC_RXD1,
> > + ? ? ? MX53_FEC_RXD0,
> > + ? ? ? MX53_FEC_TX_EN,
> > + ? ? ? MX53_FEC_TXD1,
> > + ? ? ? MX53_FEC_TXD0,
> > +};
> 
> I understand this.
> 
> > +static const unsigned mx53_fec_mux[] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
> 
> But what is this? Just zeroes? Why?
> Especially with a const so they really cannot be anything
> else. The same pin (0) can only be enumerated once.
> 
> > +static const unsigned mx53_sd1_pins[] = {
> > + ? ? ? MX53_SD1_CMD,
> > + ? ? ? MX53_SD1_CLK,
> > + ? ? ? MX53_SD1_DATA0,
> > + ? ? ? MX53_SD1_DATA1,
> > + ? ? ? MX53_SD1_DATA2,
> > + ? ? ? MX53_SD1_DATA3,
> > +
> > +};
> > +static const unsigned mx53_sd1_mux[] = { 0, 0, 0, 0, 0, 0 };
> 
> And here again.
> 
> > +static const unsigned mx53_sd3_pins[] = {
> > + ? ? ? MX53_PATA_DATA8,
> > + ? ? ? MX53_PATA_DATA9,
> > + ? ? ? MX53_PATA_DATA10,
> > + ? ? ? MX53_PATA_DATA11,
> > + ? ? ? MX53_PATA_DATA0,
> > + ? ? ? MX53_PATA_DATA1,
> > + ? ? ? MX53_PATA_DATA2,
> > + ? ? ? MX53_PATA_DATA3,
> > + ? ? ? MX53_PATA_IORDY,
> > + ? ? ? MX53_PATA_RESET_B,
> > +
> > +};
> > +static const unsigned mx53_sd3_mux[] = { 4, 4, 4, 4, 4, 4, 4, 4, 2, 2 };
> 
> This also looks strange. Can you explain what these muxes are?

Freescale has named the pins after their primary function which is quite
confusing.

The above means:

MX53_PATA_DATA8 -> mux mode 4
MX53_PATA_DATA9 -> mux mode 4
...

This brings me to the point that currently we have the pins described as

#define MX53_PAD_<name>__<function>

which means that you don't have to look into the datasheet to get the
different options for a pin (and don't have a chance to get it wrong).
I don't really want to lose this.

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 |

  reply	other threads:[~2011-12-05 21:18 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-04 11:49 [RFC PATCH 1/3] pinctrl: imx: add pinmux imx core driver Dong Aisheng
2011-12-04 11:49 ` [RFC PATCH 2/3] pinctrl: imx: add pinmux-imx53 support Dong Aisheng
2011-12-04 16:11   ` Sascha Hauer
2011-12-05  2:43     ` Dong Aisheng
2011-12-05  7:51       ` Sascha Hauer
2011-12-06  3:21         ` Dong Aisheng-B29396
2011-12-05 17:03       ` Linus Walleij
2011-12-05 17:01     ` Linus Walleij
2011-12-06  3:42       ` Dong Aisheng-B29396
2011-12-05 16:57   ` Linus Walleij
2011-12-05 21:18     ` Sascha Hauer [this message]
2011-12-06  5:54       ` Dong Aisheng-B29396
2011-12-06  6:58         ` Shawn Guo
2011-12-06  7:21           ` Dong Aisheng-B29396
2011-12-06  6:25       ` Shawn Guo
2011-12-06  7:33         ` Lothar Waßmann
2011-12-06  8:00           ` Shawn Guo
2011-12-06  8:05           ` Uwe Kleine-König
2011-12-07  9:01           ` Linus Walleij
2011-12-06 10:53         ` Sascha Hauer
2011-12-06  3:39     ` Dong Aisheng
2011-12-04 11:49 ` [RFC PATCH 3/3] pinctrl: imx: add pinmux-imx6q support Dong Aisheng
2011-12-06  7:23   ` Shawn Guo
2011-12-06  7:23     ` Dong Aisheng-B29396
2011-12-06 14:44       ` Shawn Guo
2011-12-07  9:09       ` Linus Walleij
2011-12-07  9:18         ` Dong Aisheng-B29396
2011-12-05 13:09 ` [RFC PATCH 1/3] pinctrl: imx: add pinmux imx core driver Linus Walleij
2011-12-06  3:41   ` Dong Aisheng-B29396
2011-12-06  7:06 ` Shawn Guo
2011-12-06  7:13   ` Dong Aisheng-B29396
2011-12-06  7:32     ` Shawn Guo
2011-12-06  7:39 ` Shawn Guo
2011-12-06  7:35   ` Dong Aisheng-B29396
2011-12-06  9:42 ` Shawn Guo
2011-12-06  9:38   ` Dong Aisheng-B29396

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=20111205211838.GG27267@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).