Hi Linus and Stephen, Can you help on my question? Thanks a lot in advance!
2013/12/26 曹荣荣 <caorr1...@gmail.com>: > 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/
