[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231012201541.nzlxyjngm3d5asir@zenone.zhora.eu>
Date: Thu, 12 Oct 2023 22:15:41 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Chris Packham <chris.packham@...iedtelesis.co.nz>
Cc: gregory.clement@...tlin.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
pierre.gondois@....com, linux-i2c@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] i2c: mv64xxx: add support for FSM based recovery
Hi Chris,
...
> +static int
> +mv64xxx_i2c_recover_bus(struct i2c_adapter *adap)
> +{
> + struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
> + int ret;
> + u32 val;
> +
> + dev_dbg(&adap->dev, "Trying i2c bus recovery\n");
> + writel(MV64XXX_I2C_UNSTUCK_TRIGGER, drv_data->unstuck_reg);
> + ret = readl_poll_timeout_atomic(drv_data->unstuck_reg, val,
> + !(val & MV64XXX_I2C_UNSTUCK_INPROGRESS),
> + 10, 1000);
mmmhhh... still a bit skeptical about waiting 100 times 10us in
atomic.
I'm still of the opinion that this should run in a separate
thread. Any different opinion from the network?
BTW, first question, considering that you decreased the time
considerably... does it work?
Andi
Powered by blists - more mailing lists