Hello, On Tue, Sep 08, 2015 at 04:18:41PM +0200, Linus Walleij wrote: > On Mon, Sep 7, 2015 at 10:00 AM, Uwe Kleine-König > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > [Me] > > >> If the use case is around the i2c traffic, it is a mode related to I2C, > >> and if this mode is called "GPIO mode" in the data sheet > >> is irrelevant, because it is obviously not used for the generic > >> input/output but the specific I2C. The terminology should be > >> made familiar to whoever needs to go in and read the code later. > > > > The background info that was obviously missing from the part of the > > thread I sent to you is that pinctrl_pm_select_sleep_state is used to > > prepare bitbanging on the i2c bus to do bus recovery. (The controller > > doesn't implement this, so we have to resort to manually drive the > > pins.) > > I don't understand. What does "manually" mean in this context? > Code examples for "manual" and "automatic"? Normally i2c operations are done using the i2c core in the SoC and using the i2c function of the respective pins. Recovery however must be done (manually) by configuring the lines as GPIO and using a sequence of calls to gpio_[gs]et_value. The sleep state of the i2c bus device (usually?) configures the i2c lines as GPIO. Is it ok to (ab)use the sleep state to prepare for the recovery procedure or should we better introduce a dedicated gpio mode pinctrl? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
