Setting IACK bit when core is disabled does not clear the "Interrupt Flag"
bit in the status register, and the interrupt remains pending.
Sometimes it causes failure for the very first message transfer, that is
usually a device probe.
Hence, set IACK bit after core is enabled to clear pending interrupt.
Signed-off-by: Grygorii Tertychnyi <[email protected]>
---
drivers/i2c/busses/i2c-ocores.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index a0af027db04c..a52f8fd4e2fe 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -439,8 +439,8 @@ static int ocores_init(struct device *dev, struct ocores_i2c *i2c)
oc_setreg(i2c, OCI2C_PREHIGH, prescale >> 8);
/* Init the device */
- oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN);
+ oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
return 0;
}
--
2.43.0
>>>>> "Grygorii" == Grygorii Tertychnyi <[email protected]> writes:
> Setting IACK bit when core is disabled does not clear the "Interrupt Flag"
> bit in the status register, and the interrupt remains pending.
> Sometimes it causes failure for the very first message transfer, that is
> usually a device probe.
> Hence, set IACK bit after core is enabled to clear pending interrupt.
> Signed-off-by: Grygorii Tertychnyi <[email protected]>
I no longer have access to a device with i2c-ocores, but it sounds
sensible so:
Acked-by: Peter Korsgaard <[email protected]>
> ---
> drivers/i2c/busses/i2c-ocores.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
> index a0af027db04c..a52f8fd4e2fe 100644
> --- a/drivers/i2c/busses/i2c-ocores.c
> +++ b/drivers/i2c/busses/i2c-ocores.c
> @@ -439,8 +439,8 @@ static int ocores_init(struct device *dev, struct ocores_i2c *i2c)
> oc_setreg(i2c, OCI2C_PREHIGH, prescale >> 8);
> /* Init the device */
> - oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
> oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN);
> + oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
> return 0;
> }
> --
> 2.43.0
--
Bye, Peter Korsgaard
…
> Sometimes it causes failure for the very first message transfer, …
Does such an information indicate the need for the tag “Fixes”?
Regards,
Markus
On Sun, May 19, 2024 at 7:25 AM Markus Elfring <[email protected]> wrote:
>
> …
> > Sometimes it causes failure for the very first message transfer, …
>
> Does such an information indicate the need for the tag “Fixes”?
I'm not sure: the original initialization order was introduced by the
very first commit
18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller").
Regards,
Grygorii
On Mon, May 20, 2024 at 03:30:43PM +0200, grygorii tertychnyi wrote:
> On Sun, May 19, 2024 at 7:25 AM Markus Elfring <[email protected]> wrote:
> >
> > …
> > > Sometimes it causes failure for the very first message transfer, …
> >
> > Does such an information indicate the need for the tag “Fixes”?
>
> I'm not sure: the original initialization order was introduced by the
> very first commit
> 18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller").
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
It fixes a problem like an oops, a hang, data corruption, a real
security issue, a hardware quirk, a build error (but not for things
marked CONFIG_BROKEN), or some “oh, that’s not good” issue.
Your description of the very first message transfer failing sounds
like a data corruption? Using the commit which adds the driver is also
fine, some bugs have been there all the time.
Remember to add a
Cc: [email protected]
Andrew
On Mon, May 20, 2024 at 3:41 PM Andrew Lunn <[email protected]> wrote:
>
> On Mon, May 20, 2024 at 03:30:43PM +0200, grygorii tertychnyi wrote:
> > On Sun, May 19, 2024 at 7:25 AM Markus Elfring <[email protected]> wrote:
> > >
> > > …
> > > > Sometimes it causes failure for the very first message transfer, …
> > >
> > > Does such an information indicate the need for the tag “Fixes”?
> >
> > I'm not sure: the original initialization order was introduced by the
> > very first commit
> > 18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller").
>
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>
> It fixes a problem like an oops, a hang, data corruption, a real
> security issue, a hardware quirk, a build error (but not for things
> marked CONFIG_BROKEN), or some “oh, that’s not good” issue.
>
> Your description of the very first message transfer failing sounds
> like a data corruption? Using the commit which adds the driver is also
> fine, some bugs have been there all the time.
Thanks! Yes, it is a data corruption.
> Remember to add a
>
> Cc: [email protected]
I will send v2.
Regards,
Grygorii