Hello Haojian,

On Thu, May 23, 2013 at 03:43:27PM +0800, Haojian Zhuang wrote:

On 22 May 2013 22:28, Christian Ruppert [off-list ref] wrote:

quoted

On Mon, May 20, 2013 at 10:10:33AM +0200, Linus Walleij wrote:

quoted

On Thu, May 16, 2013 at 2:12 AM, Stephen Warren [off-list ref] wrote:

quoted

On 05/10/2013 02:25 AM, Christian Ruppert wrote:

quoted

quoted

(*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.

Thanks for the hint. I haven't understood how to associate GPIOs to
other functions, however: Our hardware pin controller makes GPIO pins
available depending on the configuration of the non-GPIO interfaces.
This means that in many configurations, GPIO banks are only partially
available because some pins are used for other purposes. We can't expect
our customers to manually change the pin assignments in the device tree
in order to take this into account for every PCB.

Is there a way to make different pinmux functions mutually exclusive in
pinctrl-single, e.g. a pin is either a GPIO or part of an SPI interface?
Can the same thing be done for example to mux either SPI or I2C on the
same pins? If the answer to both questions is yes, we could predefine
all functions as we currently do and our pinctrl driver could be
entirely replaced with pinctrl-single.

[...]

Greetings,
  Christian

-- 
  Christian Ruppert              ,          [off-list ref]
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pré-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates