[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130524120259.GC5203@ab42.lan>
Date: Fri, 24 May 2013 14:03:00 +0200
From: Christian Ruppert <christian.ruppert@...lis.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Stephen Warren <swarren@...dotorg.org>,
Haojian Zhuang <haojian.zhuang@...aro.org>,
Shiraz HASHIM <shiraz.hashim@...com>,
Patrice CHOTARD <patrice.chotard@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Grant Likely <grant.likely@...retlab.ca>,
Rob Herring <rob.herring@...xeda.com>,
Rob Landley <rob@...dley.net>,
Sascha Leuenberger <sascha.leuenberger@...lis.com>,
Pierrick Hascoet <pierrick.hascoet@...lis.com>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 1/2] pinmux: Add TB10x pinmux driver
On Fri, May 24, 2013 at 11:20:31AM +0200, Linus Walleij wrote:
> On Wed, May 22, 2013 at 4:28 PM, Christian Ruppert
> <christian.ruppert@...lis.com> wrote:
> > On Mon, May 20, 2013 at 10:10:33AM +0200, Linus Walleij wrote:
>
> >> It's not even pinctrl-simple-centric it is completely generic.
> >> The code is in drivers/gpio/gpiolib-of.c.
> >>
> >> It was written by Shiraz Hashin and Haojian Zhuang.
> >> At the time I augmented the core code quite a bit to make
> >> a good fit.
> >
> > I agree. Unluckily, it uses pinctrl-internal pin numbering which we
> > would have to make coherent with the physical pin numbers of the
> > individual packaging variants of the chip in order to expose them to
> > customers (see my previous mail at https://lkml.org/lkml/2013/5/22/207).
>
> Again, the Linux pin numberspace is sparse, you can use whatever
> pin number you like as long as it fits in a u32 and does not overlap
> with other pins.
>
> If you have a problem that the physical pin numbers and the
> bank offsets or bits you need to poke or something doesn't
> match, that is an issue for the *driver* not for the pin control
> subsystem. However the pin control core may provide
> cross-mapping helpers as discussed elsewhere, but the
> pin control internal numbering is *not* an issue. Those are
> just "some number" on a certain pin controller, use the number
> from the datasheet if you like.
Understood. What I'm looking for is a way to support different products
with different physical pin numbering, ideally without changing Linux
internal pin numbers from one product variant under the constraints
highlighted in the thread you call "elsewhere".
Greetings,
Christian
--
Christian Ruppert , <christian.ruppert@...lis.com>
/|
Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri
_// | bilis Systems CH-1228 Plan-les-Ouates
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists