Hi Alain,
Thanks for the review
> On 2 Aug 2023, at 12.07, Alain Volmat <alain.volmat@xxxxxxxxxxx> wrote:
>
> Hi Sean,
>
> sorry for the delay for this review. Thank you Andi for
> the review as well.
Also from my side :) Vacation.
>
> Few other comments in addition to what Andi already mentioned.
>
> On Tue, Jul 18, 2023 at 12:54:35PM +0200, Sean Nyekjaer wrote:
>> Add an atomic_xfer method to the driver so that it behaves correctly
>> when controlling a PMIC that is responsible for device shutdown.
>>
>> The atomic_xfer method added is similar to the one from the i2c-mv64xxx
>> driver. When running an atomic_xfer a bool flag in the driver data is
>> set, the interrupt is not unmasked on transfer start, and the IRQ
>> handler is manually invoked while waiting for pending transfers to
>> complete.
>>
>> Signed-off-by: Sean Nyekjaer <sean@xxxxxxxxxx>
>> ---
>> Changes since v1:
>> - Removed dma in atomic
>>
>> drivers/i2c/busses/i2c-stm32f7.c | 111 ++++++++++++++++++++++---------
>> 1 file changed, 78 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
>> index e897d9101434..d944b8f85d1c 100644
>> --- a/drivers/i2c/busses/i2c-stm32f7.c
>> +++ b/drivers/i2c/busses/i2c-stm32f7.c
>> @@ -357,6 +357,7 @@ struct stm32f7_i2c_dev {
>> u32 dnf_dt;
>> u32 dnf;
>> struct stm32f7_i2c_alert *alert;
>> + bool atomic;
>
> I am wondering if this atomic really needs to be within the struct.
> It could well be given as last arg of stm32f7_i2c_xfer_core and
> stm32f7_i2c_xfer functions.
Agree.
>
>
>> };
>>
>>
[ … ]
>> @@ -1670,7 +1676,22 @@ static irqreturn_t stm32f7_i2c_isr_error(int irq, void *data)
>> return IRQ_HANDLED;
>> }
>>
>> -static int stm32f7_i2c_xfer(struct i2c_adapter *i2c_adap,
>> +static int stm32f7_i2c_wait_polling(struct stm32f7_i2c_dev *i2c_dev)
>> +{
>> + ktime_t timeout = ktime_add_ms(ktime_get(), i2c_dev->adap.timeout);
>> +
>> + while (ktime_compare(ktime_get(), timeout) < 0) {
>> + udelay(5);
>> + stm32f7_i2c_isr_event(0, i2c_dev);
>> +
>> + if (try_wait_for_completion(&i2c_dev->complete))
>> + return 1;
>
> I agree with the complete / wait_for_completion approach since it allows
> to keep most of code common by manually calling the isr_event for
> checking status bits. However what about using completion_done instead
> of try_wait_for_completion here ? This shouldn't change much since
> anyway there is a reinit_completion at the beginning of the xfer
> function, but at least function naming feels better since not refering
> to waiting ..
I’ll take a look at the completion_done()
>
>> + }
>>
[ … ]
/Sean
