From: Federico Vaga <federico.vaga@cern.ch>
To: Peter Rosin <peda@axentia.se>
Cc: Peter Korsgaard <peter@korsgaard.com>,
Andrew Lunn <andrew@lunn.ch>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/5] i2c:ocores: add polling interface
Date: Mon, 11 Feb 2019 14:46:28 +0100 [thread overview]
Message-ID: <14487566.fPVnE3aI26@pcbe13614> (raw)
In-Reply-To: <5bc1757a-3b74-5c77-7c39-00c2513683a1@axentia.se>
On Monday, February 11, 2019 2:35:15 PM CET Peter Rosin wrote:
> >>> @@ -294,7 +427,7 @@ static int ocores_init(struct device *dev, struct
> >>> ocores_i2c *i2c)
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>> /* Init the device */
> >>> oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
> >>>
> >>>
> >>>
> >>> - oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_IEN | OCI2C_CTRL_EN);
> >>> + oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN);
> >>
> >>
> >>
> >>
> >> You fix this up in patch 5 (in what is perhaps carelessly marketed as
> >> fixes for minor checkpatch issues), but for this patch you are actually
> >> no longer making sure that you clear the OCI2C_CTRL_IEN bit as the code
> >> used to before this patch. I think you intended to preserve that
> >> behavior, no?
> >
> >
> > I think you got confused by the two patches because those lines look very
> >
> > similar.
> >
> > In PATCH 5 what you see is the "style fix" to clear EN and IEN before
> > clock
configuration
> >
> > in PATCH 3 (this one) what you see is when later (same function, after
> > clock
configuration) the device is re-enabled (EN), but without
> > enabling the interrupt because on polling configuration we do not want to
> > see interrupt flowing.
> >
> > So, the behavior is preserved for what concern clearing the IEN bit before
> >
clock configuration.
> >
> > am I wrong?
>
>
> No, I don't think I'm confused and I think you are wrong. Current code does
> this:
>
> u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
>
> /* make sure the device is disabled */
> oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_IEN|OCI2C_CTRL_EN));
> ...
> oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_IEN | OCI2C_CTRL_EN));
>
> Here, the final oc_setreg always sets OCI2C_CTRL_IEN.
>
> Patch 3 changes it to:
>
> u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
>
> /* make sure the device is disabled */
> oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_IEN|OCI2C_CTRL_EN));
> ...
> oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN));
>
> Here, the final oc_setreg restores OCI2C_CTRL_IEN to whatever it was
> at function entry.
>
>
> And patch 5 changes it again to:
>
> u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
>
> /* make sure the device is disabled */
> ctrl &= ~(OCI2C_CTRL_IEN | OCI2C_CTRL_EN);
> oc_setreg(i2c, OCI2C_CONTROL, ctrl);
> ...
> oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN));
>
> Here, the final oc_setreg keeps OCI2C_CTRL_IEN cleared. I think you wanted
> this deterministic behavior for patch 3 as well.
Now I see what you mean and I agree. I will move the fix from PATCH 5 to PATCH
3, so that bit IEN is clearly cleared.
thanks
>
> Cheers,
> Peter
next prev parent reply other threads:[~2019-02-11 13:46 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 8:31 [PATCH v4 0/5] i2c:ocores: improvements Federico Vaga
2019-02-11 8:31 ` Federico Vaga
2019-02-11 8:31 ` [PATCH v4 1/5] i2c:ocores: stop transfer on timeout Federico Vaga
2019-02-11 8:31 ` Federico Vaga
2019-02-11 10:24 ` Wolfram Sang
2019-02-11 14:01 ` Andrew Lunn
2019-02-11 14:34 ` Federico Vaga
2019-02-11 14:34 ` Federico Vaga
2019-02-11 14:53 ` Wolfram Sang
2019-02-11 10:44 ` Peter Rosin
2019-02-11 13:02 ` Federico Vaga
2019-02-11 8:31 ` [PATCH v4 2/5] i2c:ocores: do not handle IRQ if IF is not set Federico Vaga
2019-02-11 8:31 ` Federico Vaga
2019-02-11 10:24 ` Wolfram Sang
2019-02-11 8:31 ` [PATCH v4 3/5] i2c:ocores: add polling interface Federico Vaga
2019-02-11 8:31 ` Federico Vaga
2019-02-11 10:25 ` Wolfram Sang
2019-02-11 13:47 ` Federico Vaga
2019-02-11 13:47 ` Federico Vaga
2019-02-11 10:43 ` Peter Rosin
2019-02-11 13:14 ` Federico Vaga
2019-02-11 13:35 ` Peter Rosin
2019-02-11 13:46 ` Federico Vaga [this message]
2019-02-11 8:31 ` [PATCH v4 4/5] i2c:ocores: add SPDX tag Federico Vaga
2019-02-11 8:31 ` Federico Vaga
2019-02-11 10:25 ` Wolfram Sang
2019-02-11 8:31 ` [PATCH v4 5/5] i2c:ocores: checkpatch fixes Federico Vaga
2019-02-11 8:31 ` Federico Vaga
2019-02-11 10:16 ` Peter Rosin
2019-02-11 10:26 ` Wolfram Sang
2019-02-11 10:28 ` Peter Rosin
2019-02-11 10:52 ` Peter Rosin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14487566.fPVnE3aI26@pcbe13614 \
--to=federico.vaga@cern.ch \
--cc=andrew@lunn.ch \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=peter@korsgaard.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.