linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Sven Peter" <sven@svenpeter.dev>
To: "Martin Povišer" <povik+lin@cutebit.org>,
	"Hector Martin" <marcan@marcan.st>,
	"Michael Ellerman" <mpe@ellerman.id.au>
Cc: linux-kernel@vger.kernel.org, Olof Johansson <olof@lixom.net>,
	Paul Mackerras <paulus@samba.org>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Jean Delvare <khali@linux-fr.org>, Janne Grunau <j@jannau.net>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org
Subject: Re: [PATCH] i2c: pasemi: Wait for write xfers to finish
Date: Tue, 29 Mar 2022 21:58:43 +0200	[thread overview]
Message-ID: <74a36bce-3d6e-4124-add1-8ed44ba2c80d@www.fastmail.com> (raw)
In-Reply-To: <20220329183817.21656-1-povik+lin@cutebit.org>

On Tue, Mar 29, 2022, at 20:38, Martin Povišer wrote:
> Wait for completion of write transfers before returning from the driver.
> At first sight it may seem advantageous to leave write transfers queued
> for the controller to carry out on its own time, but there's a couple of
> issues with it:
>
>  * Driver doesn't check for FIFO space.

Maybe we should also check that in a follow-up patch :-)

>
>  * The queued writes can complete while the driver is in its I2C read
>    transfer path which means it will get confused by the raising of
>    XEN (the 'transaction ended' signal). This can cause a spurious
>    ENODATA error due to premature reading of the MRXFIFO register.
>
> Adding the wait fixes some unreliability issues with the driver. There's
> some efficiency cost to it (especially with pasemi_smb_waitready doing
> its polling), but that will be alleviated once the driver receives
> interrupt support.
>
> Fixes: beb58aa39e6e ("i2c: PA Semi SMBus driver")
> Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
> ---

Reviewed-by: Sven Peter <sven@svenpeter.dev>

>
> Tested on Apple's t8103 chip. To my knowledge the PA Semi controller
> in its pre-Apple occurences behaves the same as far as this patch is
> concerned.
>
>  drivers/i2c/busses/i2c-pasemi-core.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-pasemi-core.c 
> b/drivers/i2c/busses/i2c-pasemi-core.c
> index 7728c8460dc0..9028ffb58cc0 100644
> --- a/drivers/i2c/busses/i2c-pasemi-core.c
> +++ b/drivers/i2c/busses/i2c-pasemi-core.c
> @@ -137,6 +137,12 @@ static int pasemi_i2c_xfer_msg(struct i2c_adapter 
> *adapter,
> 
>  		TXFIFO_WR(smbus, msg->buf[msg->len-1] |
>  			  (stop ? MTXFIFO_STOP : 0));
> +
> +		if (stop) {
> +			err = pasemi_smb_waitready(smbus);
> +			if (err)
> +				goto reset_out;
> +		}

Looks like pasemi_smb_xfer doesn't suffer from the same issue.
I wonder if every device connected to the bus on the original PA Semi boards
only used that path and that's why no one noticed it.


Sven


  reply	other threads:[~2022-03-29 20:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 18:38 [PATCH] i2c: pasemi: Wait for write xfers to finish Martin Povišer
2022-03-29 19:58 ` Sven Peter [this message]
2022-04-15 21:12 ` 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=74a36bce-3d6e-4124-add1-8ed44ba2c80d@www.fastmail.com \
    --to=sven@svenpeter.dev \
    --cc=alyssa@rosenzweig.io \
    --cc=j@jannau.net \
    --cc=khali@linux-fr.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=marcan@marcan.st \
    --cc=mpe@ellerman.id.au \
    --cc=olof@lixom.net \
    --cc=paulus@samba.org \
    --cc=povik+lin@cutebit.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).