gpio/pinctrl: imx: let IOMUX controller know about on-SoC GPIOs
Get series with b4
b4 am 20160905021201.GC25778@tigerVersions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
| Patch | Shawn Guo |
|---|---|
| Series | A-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/3] gpio/pinctrl: imx: let IOMUX controller know about on-SoC GPIOs
Quoted 33 lines · Vladimir Zapolskiy
Hi Shawn, Fabio,
Quoted 21 lines · Vladimir Zapolskiy
The change establishes a connection between on-SoC IOMUX controller(s) and GPIO controllers found on some SoC from Freescale/NXP iMX series, if a GPIO controller device node contains common gpio-ranges information.
The change is backward compatible with respect to potentially not updated outdated DTB data without gpio-ranges propery, for such boards the only functional change is lowered initcall priority of GPIO controller driver, which in general anyway is exected to be used only after pinctrl/pinmux controller.
If this change is applied the next interesting applications may be done as a follow-up work, for example switching pad function to GPIO on gpiod request, converting iomux controller driver to strict type and so on.
For actual values of gpio-ranges properties please reference series "ARM: dts: imx: add gpio-ranges properties to some iMX GPIO controllers"
http://archive.arm.linux.org.uk/lurker/message/20160819.220621.86d845d1.en.htmlDeepak Das (1):
gpio: mxc: lower level ofgpio_mxc_init()initcallQuoted 8 lines
Vladimir Zapolskiy (2):
pinctrl: imx: accept gpio request/free from pinctrl
gpio: mxc: add generic gpio request/free callbacks to pinctrl
drivers/gpio/gpio-mxc.c| 7 ++++++-drivers/pinctrl/freescale/pinctrl-imx.c| 4 ++--2 files changed, 8 insertions(+), 3 deletions(-)
Quoted 6 lines
no comments so far, please could you express your concerns about this change? IMHO it would be nice to have this feature enabled in v4.9.
I assume that the most worrisome commit is the change of GPIO controller driver init level, but I belive it is safe enough, no?
If I understand it correctly, with the change, most of GPIO client device drivers use the same init level as GPIO driver. So we are not sure if GPIO driver is ready when client drivers try to request GPIO. It shouldn't be a problem if every client driver handle the failure with deferred probing, but I'm not sure that's the case now.
Shawn