On 22 May 2013 22:28, Christian Ruppert <christian.ruppert@xxxxxxxxxx> 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@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
