Hi Linus and Stephen, I'm learning the pinctrl subsystem codes these days, and have a confusion about it, I'm very appreciated if you can help.
I noticed that Stephen<swar...@nvidia.com> submitted a patch for pinctrl: http://www.gossamer-threads.com/lists/linux/kernel/1500890?do=post_view_threaded In this patch, Stephen said, "When an SoC muxes pins in a group, it's quite possible for the group to contain e.g. 6 pins, but only 4 of them actually be needed by the HW module that's mux'd to them. In this case, the other 2 pins could be used as GPIOs. However, pinctrl marks all the pins within the group as in-use by the selected mux function. To allow the expected gpiolib interaction, separate the concepts of pin ownership into two parts: One for the mux function and one for GPIO usage. Finally, allow those two ownerships to exist in parallel. " I agree that gpiolib should be able to use the two idle pins as GPIO, but after apply this patch, gpiolib can also request the 4 pins used by HW module succesfully, and this will override the settings of the 4 pins for HW module. I have read the latest Documentation/pinctrl.txt, and there is two examples about muxing logic in "GPIO mode pitfalls" section, let me take example A for instance: pin config logic regs | +- SPI Physical pins --- pad --- pinmux -+- I2C | +- mmc | +- GPIO pin multiplex logic regs Assuming that the pin has been configured as SPI mode, undoubtedly we can't use it as GPIO any longer. However, if we call gpio_request() (gpiolib API) to requet this pin for GPIO purpose, gpio_request() still can return successfully. I think this is unreasonable, gpio_request() should return an "error code" if the pin is in-use by PINMUX. I read the codes of pin_request() in pinmux.c, and guess pinmux_ops->gpio_request_enable() may be responsible to handle this use case, that is, to return an "error code" if the pin has been owned by pinmux. However, no drivers in drivers/pinctrl/ implements such codes in pinmux_ops->gpio_request_enable(). Or, pinctrl subsystem is just resposible to set the pin in GPIO mode, and gpio subsystem (gpiolib) is responsible for other things like set direction, get value if input, or set high/low if output. Is my understanding right? ******************** Let me talk again about the example described by Stephen. If actually only 4 pins of the group which contains 6 pins are needed by HW module, then why does the group be defined to contain 6 pins? I think the group should be defined only containing 4 pins rather than 6 pins, then the other 2 idle pins can be used for any other purpose. Thank you very much in advance! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
