linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Wolfram Sang <wsa@kernel.org>,
	linux-i2c <linux-i2c@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/4] i2c: mpc: Interrupt driven transfer
Date: Tue, 13 Apr 2021 22:28:17 +0000	[thread overview]
Message-ID: <09f636b8-c126-af14-fbc3-9d6becb15df5@alliedtelesis.co.nz> (raw)
In-Reply-To: <CAHp75VfR2zNmstvqCSRC2=0hf2DRV7sMdmy9-TDkO07KHwLjGA@mail.gmail.com>


On 14/04/21 1:52 am, Andy Shevchenko wrote:
> On Tue, Apr 13, 2021 at 8:10 AM Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>> The fsl-i2c controller will generate an interrupt after every byte
>> transferred. Make use of this interrupt to drive a state machine which
>> allows the next part of a transfer to happen as soon as the interrupt is
>> received. This is particularly helpful with SMBUS devices like the LM81
>> which will timeout if we take too long between bytes in a transfer.
> Also see my other comments below.
>
> ...
>
>> +// SPDX-License-Identifier: GPL-2.0
> I think it is better to split this with a removal of old stuff and
> updating a copyright notice and go as a last one in the series.
>
> ...
Have split out into new patch.
>> +static char *action_str[] = {
> static const char * const action_str[]
Ack.
>> +       "invalid",
>> +       "start",
>> +       "restart",
>> +       "read begin",
>> +       "read",
>> +       "write",
>> +       "stop",
>> +};
> ...
>
>> +       dev_dbg(i2c->dev, "%s: action = %s\n", __func__,
>> +               action_str[i2c->action]);
> Drop useless __func__. With Dynamic Debug enabled it can be turned on
> and off at run time.

Ack. Other instances of __func__ also.

>
> ...
>
>> +                       /* Generate txack on next to last byte */
> Tx ACK ? Ditto for other comments.
>
> ...
ACK.
>
>> +               dev_dbg(i2c->dev, "%s: %s %02x\n", __func__,
>> +                       action_str[i2c->action], byte);
> You already printed action. Anything changed?
It's mainly the addition of the byte read. I couldn't figure out a 
sensible way of always printing the action then appending the data in 
the read/write case. Open to suggestions.
>
>> +               dev_dbg(i2c->dev, "%s: %s %02x\n", __func__,
>> +                       action_str[i2c->action], msg->buf[i2c->byte_posn]);
> Deduplicate this. Perhaps at the end of switch-case print once with
> whatever temporary variable value you want to.
>
> ...
I thought about this but decided not to because in the write case it's 
printed before going to hardware and in the read case it's after. If I 
moved it after the case I'd have to use something other than 
i2c->byte_posn which seemed error prone.
>
>> +       case MPC_I2C_ACTION_INVALID:
>> +       default:
> Does the first one deserve loud WARN?
> Otherwise, why is it defined at all?
I added MPC_I2C_ACTION_INVALID to make sure that a value of 0 was not 
something that would naturally happen via a zeroed initialization. I 
could probably achieve the same thing by making MPC_I2C_ACTION_START = 1.
>> +               WARN(1, "Unexpected action %d\n", i2c->action);
>> +               break;
> ...
>
>> +static void mpc_i2c_do_intr(struct mpc_i2c *i2c, u8 status)
>>   {
>> +       spin_lock_irqsave(&i2c->lock, flags);
> Why _irqsave?
>
> ...
Primarily because it's the only one I've ever used and it was the one 
similar i2c drivers used when I started this work. I see they've now 
been updated so I don't think there will be a problem switching to 
spin_lock().
>> +               dev_dbg(i2c->dev, "arbiritration lost\n");
> arbitration
Ack.
> ...
>
>> +       if (i2c->expect_rxack && (status & CSR_RXAK)) {
>> +               dev_dbg(i2c->dev, "no RXAK\n");
> You see, you have to be consistent in comments and messages.
> Either use TXAK/RXAK, or more verbose 'Tx ACK/Rx ACK' everywhere.
>
> ...
Updated to "Rx ACK". I think I've got them all now.
>
>> +out:
> out_unlock:
>
>> +       spin_unlock_irqrestore(&i2c->lock, flags);
> ...
>
>> +static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
>> +{
>> +       struct mpc_i2c *i2c = dev_id;
>> +       u8 status = readb(i2c->base + MPC_I2C_SR);
> I would split this assignment, so it will be closer to its user.
Ack.
>> +       if (status & CSR_MIF) {
>> +               writeb(0, i2c->base + MPC_I2C_SR);
>> +               mpc_i2c_do_intr(i2c, status);
>> +               return IRQ_HANDLED;
>>          }
>> +       return IRQ_NONE;
>> +}
> ...
>
>> +       time_left = wait_event_timeout(i2c->waitq, !i2c->block, i2c->adap.timeout);
>> +
> No need for a blank line here.
Ack.
>> +       if (!time_left)
>> +               i2c->rc = -ETIMEDOUT;
>> +       else if (time_left < 0)
> Redundant 'else'
Ack.
>> +               i2c->rc = time_left;
> Can't you return an error code from here, rather than injecting it
> somewhere where it doesn't belong to?
Yes I think so. If I make mpc_i2c_wait_for_completion() return an int 
then have mpc_i2c_execute_msg() check it and set i2c->rc if needed.
>>   }
> --
> With Best Regards,
> Andy Shevchenko

  reply	other threads:[~2021-04-13 22:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13  5:09 [PATCH v3 0/4] i2c: mpc: Refactor to improve responsiveness Chris Packham
2021-04-13  5:09 ` [PATCH v3 1/4] i2c: mpc: use device managed APIs Chris Packham
2021-04-13 12:21   ` Wolfram Sang
2021-04-13 13:31     ` Andy Shevchenko
2021-04-13 13:31       ` Andy Shevchenko
2021-04-13  5:09 ` [PATCH v3 2/4] i2c: mpc: Interrupt driven transfer Chris Packham
2021-04-13 12:22   ` Wolfram Sang
2021-04-13 13:52   ` Andy Shevchenko
2021-04-13 22:28     ` Chris Packham [this message]
2021-04-13 23:23       ` Chris Packham
2021-04-13  5:09 ` [PATCH v3 3/4] i2c: mpc: Remove redundant NULL check Chris Packham
2021-04-13 12:27   ` Wolfram Sang
2021-04-13  5:09 ` [PATCH v3 3/3] MAINTAINERS: Add Chris Packham as FREESCALE MPC I2C maintainer Chris Packham
2021-04-13  5:14   ` Chris Packham
2021-04-13 11:19     ` Andy Shevchenko
2021-04-13  5:09 ` [PATCH v3 4/4] " Chris Packham
2021-04-13 12:27   ` Wolfram Sang

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=09f636b8-c126-af14-fbc3-9d6becb15df5@alliedtelesis.co.nz \
    --to=chris.packham@alliedtelesis.co.nz \
    --cc=andy.shevchenko@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).