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 linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
