All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Martin Persson <martin.persson@stericsson.com>,
	Lee Jones <lee.jones@linaro.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/4] Pinmux subsystem
Date: Fri, 13 May 2011 11:59:09 +0200	[thread overview]
Message-ID: <20110513095909.GB2429@pengutronix.de> (raw)
In-Reply-To: <BANLkTi=N8VNh3tPxYH8dQ0UtGpN=xSzKng@mail.gmail.com>

On Thu, May 12, 2011 at 04:02:35PM +0200, Linus Walleij wrote:
> 2011/5/12 Sascha Hauer <s.hauer@pengutronix.de>:
> 
> > What I'm missing though is a generic way a single pad/mux mode
> > combination can be described. Let me take a look around how the
> > different subarchs do this:
> >
> > omap:
> >
> >        _OMAP3_MUXENTRY(DSS_DATA21, 91,
> >                "dss_data21", NULL, "mcspi3_cs0", "dss_data3",
> >                "gpio_91", NULL, NULL, "safe_mode"),
> >        _OMAP3_MUXENTRY(DSS_DATA22, 92,
> >                "dss_data22", NULL, "mcspi3_cs1", "dss_data4",
> >                "gpio_92", NULL, NULL, "safe_mode"),
> >
> > pxa:
> >
> > #define GPIO16_FFUART_TXD       MFP_CFG_OUT(GPIO16, AF3, DRIVE_HIGH)
> > #define GPIO37_FFUART_TXD       MFP_CFG_OUT(GPIO37, AF3, DRIVE_HIGH)
> > #define GPIO39_FFUART_TXD       MFP_CFG_OUT(GPIO39, AF2, DRIVE_HIGH)
> > #define GPIO83_FFUART_TXD       MFP_CFG_OUT(GPIO83, AF2, DRIVE_HIGH)
> > #define GPIO99_FFUART_TXD       MFP_CFG_OUT(GPIO99, AF3, DRIVE_HIGH)
> >
> > i.MX:
> >
> > #define _MX51_PAD_UART3_RXD__CSI1_D0            IOMUX_PAD(0x630, 0x240, 2, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__GPIO1_22           IOMUX_PAD(0x630, 0x240, 3, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__UART1_DTR          IOMUX_PAD(0x630, 0x240, 0, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__UART3_RXD          IOMUX_PAD(0x630, 0x240, 1, 0x09f4, 4, 0)
> > #define _MX51_PAD_UART3_TXD__CSI1_D1            IOMUX_PAD(0x634, 0x244, 2, 0x0000, 0, 0)
> >
> > These all basically describe the same thing: put pad x into one of modes
> > a, b, c and apply certain flags like drive strength on this.
> >
> > the other class of pin muxing I know of is that a whole group of pads
> > can be switched to a particular mode using a mux register like I think
> > is used used in your ux300 driver.
> >
> > I'd like to have a unified way to describe this.
> 
> Hm, so some of the structure I currently have inside the specific U300 driver
> need to become generic, in such way that say by activating 8 different
> padmux functions at the same, this can boil down to a single register
> write instead of 8 different register writes?
> 
> > Do you think it's possible to do some consolidation on this level
> > aswell? It would really bring different SoCs more together.
> 
> I am thinking on the abstract level, now we would have:
> 
> Board:
> static struct pinmux_map pmx_map[] = {
>         PINMUX_MAP("foo0", "foo0-1"),
>         PINMUX_MAP("bar0", "bar0-1"),
> };
> pinmux_register_mappings(pmx_map, ARRAY_SIZE(pmx_map));
> 
> Driver:
> pmx = pinmux_get("foo0", NULL);
> pinmux_enable(pmx);
> 
> For each of the mux functions. Now we need a grouping of
> these functions.

No, the driver API is fine. pinmux_enable can enable multiple pins in
the background and in fact it already does in your U300 example since
the hardware does not allow handling single pins.

What I'm asking for is to get rid of the differing definitions for
pin muxing. That is more an extension to your patches rather than
a change to your patches.

What omap/i.MX/pxa.. need is something like this:

/* describe all functions of a single pad, SoC or package specific */
struct padmux {
	int padno;
	const char *function; /* "uart1-txd", "spi3-mosi", "gpio127" */
	int num_functions;
};

/* select a particular function and additional settings */
struct function_selector {
	int padno;
	int function;	/* function to select from struct padmux above
			 * (could be const char * to match the function name
			 * instead of the number.
			 */
	unsigned long flags; /* drive strength, open drain, ... */
};

/*
 * map multiple pads to a device. Can be passed by the board or
 * filled from device tree.
 */
struct padgroup {
	const char *devname; /* imxspi.0, atmeluart.1,... */
	struct function_selector *functions;
	int num_functions;
};

(I don't know whether we can agree on a common set of flags, at least I
hope so)

I hope that we can agree on this or a similar set of structs to share
between different architectures.

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 0/4] Pinmux subsystem
Date: Fri, 13 May 2011 11:59:09 +0200	[thread overview]
Message-ID: <20110513095909.GB2429@pengutronix.de> (raw)
In-Reply-To: <BANLkTi=N8VNh3tPxYH8dQ0UtGpN=xSzKng@mail.gmail.com>

On Thu, May 12, 2011 at 04:02:35PM +0200, Linus Walleij wrote:
> 2011/5/12 Sascha Hauer <s.hauer@pengutronix.de>:
> 
> > What I'm missing though is a generic way a single pad/mux mode
> > combination can be described. Let me take a look around how the
> > different subarchs do this:
> >
> > omap:
> >
> > ? ? ? ?_OMAP3_MUXENTRY(DSS_DATA21, 91,
> > ? ? ? ? ? ? ? ?"dss_data21", NULL, "mcspi3_cs0", "dss_data3",
> > ? ? ? ? ? ? ? ?"gpio_91", NULL, NULL, "safe_mode"),
> > ? ? ? ?_OMAP3_MUXENTRY(DSS_DATA22, 92,
> > ? ? ? ? ? ? ? ?"dss_data22", NULL, "mcspi3_cs1", "dss_data4",
> > ? ? ? ? ? ? ? ?"gpio_92", NULL, NULL, "safe_mode"),
> >
> > pxa:
> >
> > #define GPIO16_FFUART_TXD ? ? ? MFP_CFG_OUT(GPIO16, AF3, DRIVE_HIGH)
> > #define GPIO37_FFUART_TXD ? ? ? MFP_CFG_OUT(GPIO37, AF3, DRIVE_HIGH)
> > #define GPIO39_FFUART_TXD ? ? ? MFP_CFG_OUT(GPIO39, AF2, DRIVE_HIGH)
> > #define GPIO83_FFUART_TXD ? ? ? MFP_CFG_OUT(GPIO83, AF2, DRIVE_HIGH)
> > #define GPIO99_FFUART_TXD ? ? ? MFP_CFG_OUT(GPIO99, AF3, DRIVE_HIGH)
> >
> > i.MX:
> >
> > #define _MX51_PAD_UART3_RXD__CSI1_D0 ? ? ? ? ? ?IOMUX_PAD(0x630, 0x240, 2, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__GPIO1_22 ? ? ? ? ? IOMUX_PAD(0x630, 0x240, 3, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__UART1_DTR ? ? ? ? ?IOMUX_PAD(0x630, 0x240, 0, 0x0000, 0, 0)
> > #define _MX51_PAD_UART3_RXD__UART3_RXD ? ? ? ? ?IOMUX_PAD(0x630, 0x240, 1, 0x09f4, 4, 0)
> > #define _MX51_PAD_UART3_TXD__CSI1_D1 ? ? ? ? ? ?IOMUX_PAD(0x634, 0x244, 2, 0x0000, 0, 0)
> >
> > These all basically describe the same thing: put pad x into one of modes
> > a, b, c and apply certain flags like drive strength on this.
> >
> > the other class of pin muxing I know of is that a whole group of pads
> > can be switched to a particular mode using a mux register like I think
> > is used used in your ux300 driver.
> >
> > I'd like to have a unified way to describe this.
> 
> Hm, so some of the structure I currently have inside the specific U300 driver
> need to become generic, in such way that say by activating 8 different
> padmux functions at the same, this can boil down to a single register
> write instead of 8 different register writes?
> 
> > Do you think it's possible to do some consolidation on this level
> > aswell? It would really bring different SoCs more together.
> 
> I am thinking on the abstract level, now we would have:
> 
> Board:
> static struct pinmux_map pmx_map[] = {
>         PINMUX_MAP("foo0", "foo0-1"),
>         PINMUX_MAP("bar0", "bar0-1"),
> };
> pinmux_register_mappings(pmx_map, ARRAY_SIZE(pmx_map));
> 
> Driver:
> pmx = pinmux_get("foo0", NULL);
> pinmux_enable(pmx);
> 
> For each of the mux functions. Now we need a grouping of
> these functions.

No, the driver API is fine. pinmux_enable can enable multiple pins in
the background and in fact it already does in your U300 example since
the hardware does not allow handling single pins.

What I'm asking for is to get rid of the differing definitions for
pin muxing. That is more an extension to your patches rather than
a change to your patches.

What omap/i.MX/pxa.. need is something like this:

/* describe all functions of a single pad, SoC or package specific */
struct padmux {
	int padno;
	const char *function; /* "uart1-txd", "spi3-mosi", "gpio127" */
	int num_functions;
};

/* select a particular function and additional settings */
struct function_selector {
	int padno;
	int function;	/* function to select from struct padmux above
			 * (could be const char * to match the function name
			 * instead of the number.
			 */
	unsigned long flags; /* drive strength, open drain, ... */
};

/*
 * map multiple pads to a device. Can be passed by the board or
 * filled from device tree.
 */
struct padgroup {
	const char *devname; /* imxspi.0, atmeluart.1,... */
	struct function_selector *functions;
	int num_functions;
};

(I don't know whether we can agree on a common set of flags, at least I
hope so)

I hope that we can agree on this or a similar set of structs to share
between different architectures.

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 |

  parent reply	other threads:[~2011-05-13  9:59 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-02 19:16 [PATCH 0/4] Pinmux subsystem Linus Walleij
2011-05-02 19:16 ` Linus Walleij
2011-05-02 22:57 ` Russell King - ARM Linux
2011-05-02 22:57   ` Russell King - ARM Linux
2011-05-10 21:25   ` Linus Walleij
2011-05-10 21:25     ` Linus Walleij
2011-05-10 21:45     ` Russell King - ARM Linux
2011-05-10 21:45       ` Russell King - ARM Linux
2011-05-10 23:15       ` Linus Walleij
2011-05-10 23:15         ` Linus Walleij
2011-05-03 17:27 ` Andrew Lunn
2011-05-03 17:27   ` Andrew Lunn
2011-05-03 19:29   ` Valdis.Kletnieks
2011-05-03 19:29     ` Valdis.Kletnieks at vt.edu
2011-05-10 21:42   ` Linus Walleij
2011-05-10 21:42     ` Linus Walleij
2011-05-11  9:50     ` Andrew Lunn
2011-05-11  9:50       ` Andrew Lunn
2011-05-12  0:41       ` Linus Walleij
2011-05-12  0:41         ` Linus Walleij
2011-05-12  7:00         ` Andrew Lunn
2011-05-12  7:00           ` Andrew Lunn
2011-05-15 13:33     ` Andrew Lunn
2011-05-15 13:33       ` Andrew Lunn
2011-05-15 17:50       ` Linus Walleij
2011-05-15 17:50         ` Linus Walleij
2011-05-17  1:57         ` Kyungmin Park
2011-05-17  1:57           ` Kyungmin Park
2011-05-18 20:02           ` Linus Walleij
2011-05-18 20:02             ` Linus Walleij
2011-05-18 21:21             ` Mark Brown
2011-05-18 21:21               ` Mark Brown
2011-05-12  7:44 ` Sascha Hauer
2011-05-12  7:44   ` Sascha Hauer
2011-05-12  9:40   ` Tony Lindgren
2011-05-12  9:40     ` Tony Lindgren
2011-05-12 14:02   ` Linus Walleij
2011-05-12 14:02     ` Linus Walleij
2011-05-12 21:17     ` RE : " Matthieu Castet
2011-05-12 21:17       ` Matthieu Castet
2011-05-13  7:05       ` RE : " Linus Walleij
2011-05-13  7:05         ` Linus Walleij
2011-05-13 16:03         ` RE : " Matthieu CASTET
2011-05-13 16:03           ` Matthieu CASTET
2011-05-14  7:57           ` RE : " Linus Walleij
2011-05-14  7:57             ` Linus Walleij
2011-05-13  9:59     ` Sascha Hauer [this message]
2011-05-13  9:59       ` Sascha Hauer

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=20110513095909.GB2429@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=grant.likely@secretlab.ca \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.persson@stericsson.com \
    /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 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.