lkml.org 
[lkml]   [2013]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/2] pinmux: Add TB10x pinmux driver
From
On 22 May 2013 22:28, Christian Ruppert <christian.ruppert@abilis.com> wrote:
>
> On Mon, May 20, 2013 at 10:10:33AM +0200, Linus Walleij wrote:
> > On Thu, May 16, 2013 at 2:12 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > > On 05/10/2013 02:25 AM, Christian Ruppert wrote:
> >
> > >> (*1) TB100 GPIO ranges are defined as a phandle to the I/O function
> > >> which provides all pins of a given GPIO port. This function is not
> > >> necessarily requested from pinctrl and GPIO ports may overlap with
> > >> other functions. The pin controller knows about this and provides
> > >> whatever GPIO pin is available after mapping other requested
> > >> functions.
> > >> (*2) Here, the entire GPIOB port is explicitly requested by the GPIO
> > >> module, i.e. all pins of the port are made available as GPIOs.
> > >
> > > So I think all you're looking for is a way in DT to represent GPIO
> > > ranges? I don't think that should be by string name, but rather numbers:
> > >
> > > (actually, doesn't pinctrl-simple already have this?)
> >
> > Now I'm ever more confused ... we already have this :-)
> >
> > 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).
>
> Adapting the kernel-internal pin numbering in function of the product
> variant doesn't seem such a good idea to me: All pin groups etc. will
> have to be redefined for every product, a huge source of bugs and
> unnecessary static data within the drivers.
>I review two methods you mentioned in this mail.

I think that you want to keep the logic simple. If so, I prefer you can
check pinctrl-single driver first. All pins are defined in DTS instead.

Here's the sample on Hi3620 SoC. And some pins even share one pinctrl
registers.

gpio controller:
gpio-ranges = < &pmx0 3 94 1 &pmx0 7 96 1>;
Each gpio pins in gpio controller could trace to the pin controller.

pin controller:
pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
&range 12 1 0 &range 13 29 1
&range 43 1 0 &range 44 49 1
&range 94 1 1 &range 96 2 1>;

range: gpio-range {
#pinctrl-single,gpio-range-cells = <3>;
};
If the pin could be configured as GPIO mode, we could trace to the
gpio controller by this table. We can see those pins are not continuous,
and it doesn't matter. And it could handle the relations between
multiple gpio controllers and multiple pin controllers.

These pin numbers are only used to bind GPIO number. Customers
needn't to know the details. The device driver only set the pins to
right mode (GPIO or any other) with right configuration. The device
driver even needn't know the GPIO number and the pin number.
Because everything is already handled. They only need the pinctrl
array. I prefer you to check drivers/tty/serial/amba-pl011.c.

In some SoC, both pin26 & pin104 could be configured as GPIO3.
We only need to define one in your DTS because only one could
be effect in the real world.

And we abstract pin number from the register offset. You also needn't
worry the pin name such as AA1, AB1. Those names are used to
communicate with hardware guys, not software guys.

If you want to redefine the pin groups because they're used as LCD pins,
not MMC pins any more. You needn't have to modify the pin arrays in
your pinctrl driver anymore. Because pinctrl-single driver don't define
any pin arrays. You can only define pin arrays in your DTS file.

Is it helpful to you?

Regards
Haojian


\
 
 \ /
  Last update: 2013-05-23 10:21    [W:0.118 / U:0.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site