Date: Thu, 12 May 2011 02:40:01 -0700
From: Tony Lindgren <tony@atomide.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Linus Walleij <linus.walleij@stericsson.com>, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        Grant Likely <grant.likely@secretlab.ca>,
        Martin Persson <martin.persson@stericsson.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH 0/4] Pinmux subsystem
Message-ID: <20110512094001.GH31483@atomide.com>
References: <1304363768-30338-1-git-send-email-linus.walleij@stericsson.com>
 <20110512074421.GA2429@pengutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110512074421.GA2429@pengutronix.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1133
Lines: 28

* Sascha Hauer <s.hauer@pengutronix.de> [110512 00:40]:
> 
> 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. If we ever want to move
> this into the device tree we need this anyway as I think it's not an
> option to have completely different SoC specific descriptions in the
> device tree.

Me too. Otherwise we'll have multiple different device tree implementations.

We might as well have the data in suitable format for device tree to
start with, and then have common access functions that can be replaced
for various platforms if necessary.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/