Hi Cedric, 2016-06-02 17:35 GMT+02:00 M'boumba Cedric Madianga <cedric.madianga@xxxxxxxxx>: > Hi, > >>> + >>> +/** >>> + * stm32f4_i2c_xfer() - Transfer combined I2C message >>> + * @i2c_adap: Adapter pointer to the controller >>> + * @msgs: Pointer to data to be written. >>> + * @num: Number of messages to be executed >>> + */ >>> +static int stm32f4_i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[], >>> + int num) >>> +{ >>> + struct stm32f4_i2c_dev *i2c_dev = i2c_get_adapdata(i2c_adap); >>> + int ret, i; >>> + >>> + i2c_dev->busy = true; >>> + >>> + ret = clk_prepare_enable(i2c_dev->clk); >>> + if (ret) { >>> + dev_err(i2c_dev->dev, "Failed to prepare_enable clock\n"); >>> + return ret; >>> + } >>> + >>> + stm32f4_i2c_hw_config(i2c_dev); >> Maybe you could call this only at probe and resume time? >> You would save some register accesses. > Some clarification about this point. > We need to call stm32f4_i2c_hw_config before each I2C transfer as at > the end of I2C communication the peripheral is automatically disabled > and configuration registers are reset. Ok, but I wonder how the IP knows this is the last i2c message to be sent? Or maybe it gets re-initialized as soon as the clk is disabled? Thanks for the inputs, Maxime -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html