From: Russell King - ARM Linux admin <linux@armlinux.org.uk> To: Linus Walleij <linus.walleij@linaro.org> Cc: linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org Subject: pinctrl states vs pinmux vs gpio (i2c bus recovery) Date: Fri, 6 Dec 2019 17:33:43 +0000 [thread overview] Message-ID: <20191206173343.GX25745@shell.armlinux.org.uk> (raw) Hi Linus, There seems to be a problem in pinctrl land when pinctrls interact with GPIOs. If, for example, an I2C driver wants to attempt bus recovery, and needs to use GPIO mode to control the I2C bus pins to do this, then one may expect code such as found in i2c_imx_init_recovery_info() to work. However, consider that devm_gpiod_get() may invoke pinctrl_gpio_request(), which changes the pinmux settings independently of the pinctrl layer. The result is that after devm_gpiod_get() has completed, the I2C bus pins are in GPIO mode. One may expect: pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_default); to change them back to the default state, but that would be incorrect. The first thing that pinctrl_select_state() does is check whether p->state == state which it will do, as the pinctrl layer hasn't been informed of the change that has happened behind its back at the pinmux level. The result is, one needs to switch the state to gpio mode, and then back to default to ensure that the pins are muxed back to the I2C controller while the I2C controller is supposed to be operational. GPIO mode is only used to recover the bus when a bus hang has happened due to a slave device holding SDA low - and the only way that can be recovered is by toggling the SCL signal. If the controller provides no means to do this other than switching to GPIO mode, the above is necessary. I spotted this while trying out this method of i2c bus recovery on a different I2C controller. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> To: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: pinctrl states vs pinmux vs gpio (i2c bus recovery) Date: Fri, 6 Dec 2019 17:33:43 +0000 [thread overview] Message-ID: <20191206173343.GX25745@shell.armlinux.org.uk> (raw) Hi Linus, There seems to be a problem in pinctrl land when pinctrls interact with GPIOs. If, for example, an I2C driver wants to attempt bus recovery, and needs to use GPIO mode to control the I2C bus pins to do this, then one may expect code such as found in i2c_imx_init_recovery_info() to work. However, consider that devm_gpiod_get() may invoke pinctrl_gpio_request(), which changes the pinmux settings independently of the pinctrl layer. The result is that after devm_gpiod_get() has completed, the I2C bus pins are in GPIO mode. One may expect: pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_default); to change them back to the default state, but that would be incorrect. The first thing that pinctrl_select_state() does is check whether p->state == state which it will do, as the pinctrl layer hasn't been informed of the change that has happened behind its back at the pinmux level. The result is, one needs to switch the state to gpio mode, and then back to default to ensure that the pins are muxed back to the I2C controller while the I2C controller is supposed to be operational. GPIO mode is only used to recover the bus when a bus hang has happened due to a slave device holding SDA low - and the only way that can be recovered is by toggling the SCL signal. If the controller provides no means to do this other than switching to GPIO mode, the above is necessary. I spotted this while trying out this method of i2c bus recovery on a different I2C controller. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2019-12-06 17:33 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-06 17:33 Russell King - ARM Linux admin [this message] 2019-12-06 17:33 ` pinctrl states vs pinmux vs gpio (i2c bus recovery) Russell King - ARM Linux admin 2019-12-09 0:20 ` Linus Walleij 2019-12-09 0:20 ` Linus Walleij 2019-12-13 0:20 ` Russell King - ARM Linux admin 2019-12-13 0:20 ` Russell King - ARM Linux admin 2020-02-27 16:47 ` Alan Ott 2020-02-27 16:47 ` Alan Ott 2020-03-25 12:42 ` Alan Ott 2020-03-25 12:42 ` Alan Ott 2020-03-25 20:06 ` Ludovic.Desroches 2020-03-25 20:06 ` Ludovic.Desroches 2020-03-25 21:09 ` Alan Ott 2020-03-25 21:09 ` Alan Ott 2020-03-26 6:53 ` Ludovic.Desroches 2020-03-26 6:53 ` Ludovic.Desroches 2020-03-26 15:55 ` Alan Ott 2020-03-26 15:55 ` Alan Ott 2020-03-26 20:39 ` Ludovic.Desroches 2020-03-26 20:39 ` Ludovic.Desroches 2020-03-27 16:24 ` Alan Ott 2020-03-27 16:24 ` Alan Ott 2020-03-27 21:43 ` Ludovic.Desroches 2020-03-27 21:43 ` Ludovic.Desroches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191206173343.GX25745@shell.armlinux.org.uk \ --to=linux@armlinux.org.uk \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.