LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eddie James <eajames@linux.vnet.ibm.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, robh+dt@kernel.org,
	benh@kernel.crashing.org, joel@jms.id.au, mark.rutland@arm.com,
	gregkh@linuxfoundation.org, rdunlap@infradead.org,
	andy.shevchenko@gmail.com, peda@axentia.se
Subject: Re: [PATCH v10 4/7] i2c: fsi: Add abort and hardware reset procedures
Date: Wed, 27 Jun 2018 08:48:33 -0500	[thread overview]
Message-ID: <3dc50e6b-6985-1920-4f8c-dc7698e2f692@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180626023849.op4rimmsnlv4rgwg@ninjato>



On 06/25/2018 09:38 PM, Wolfram Sang wrote:
> On Wed, Jun 13, 2018 at 02:36:16PM -0500, Eddie James wrote:
>> Add abort procedure for failed transfers. Add engine and bus reset
>> procedures to recover from as many faults as possible.
> I think this is a way too aggressive recovery. Your are doing the 9
> pulse toggles basically on any error while this is only when the device
> keeps SDA low and you want to recover from that. If SDA is not stuck
> low, sending a STOP should do. Or do you have a known case where this is
> not going to work?

It is aggressive, but I don't see the harm in doing this on every error. 
There are some other error conditions with this hardware which may 
require the clock toggling, such as "bus arbitration lost." I think this 
is the safest option for this hardware, and this routine has been tested 
for many years.

>
> Also, you implement the pulse toggling manually. Can't you just populate
> {get|set}_{scl|sda} and use the generic routine we have in the core?

I see that the generic implementation breaks the loop if it sees the 
clock isn't high after setting it, or if SDA goes high. I think it's 
safer to finish the reset for our hardware. Plus, we actually have 
different registers for setting 0 or 1 to the clock/data, so we save 
some cpu cycles by doing it directly instead of implementing set_scl/sda 
and having to check val every time :)

If you feel very strongly that this recovery procedure needs to be 
reduced, then I will work on that and have to do some extensive testing.

Thanks!
Eddie

>


  reply	other threads:[~2018-06-27 13:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-13 19:36 [PATCH v10 0/7] i2c: Add FSI-attached I2C master algorithm Eddie James
2018-06-13 19:36 ` [PATCH v10 1/7] dt-bindings: i2c: Add FSI-attached I2C master dt binding documentation Eddie James
2018-06-26  2:39   ` Wolfram Sang
2018-06-13 19:36 ` [PATCH v10 2/7] i2c: Add FSI-attached I2C master algorithm Eddie James
2018-06-13 19:36 ` [PATCH v10 3/7] i2c: fsi: Add port structures Eddie James
2018-06-20  3:34   ` Benjamin Herrenschmidt
2018-06-20  3:59     ` Joel Stanley
2018-06-13 19:36 ` [PATCH v10 4/7] i2c: fsi: Add abort and hardware reset procedures Eddie James
2018-06-26  2:38   ` Wolfram Sang
2018-06-27 13:48     ` Eddie James [this message]
2018-07-02 18:15       ` Wolfram Sang
2018-07-05 18:50         ` Eddie James
2018-07-05 22:06           ` Wolfram Sang
2018-06-13 19:36 ` [PATCH v10 5/7] i2c: fsi: Add transfer implementation Eddie James
2018-06-26  2:38   ` Wolfram Sang
2018-06-27 13:21     ` Eddie James
2018-07-02 18:24       ` Wolfram Sang
2018-07-05 18:52         ` Eddie James
2018-07-05 21:59           ` Wolfram Sang
2018-06-13 19:36 ` [PATCH v10 6/7] i2c: fsi: Add I2C master locking Eddie James
2018-06-13 19:36 ` [PATCH v10 7/7] i2c: fsi: Add bus recovery Eddie James
2018-06-26  2:38   ` Wolfram Sang
2018-06-27 13:32     ` Eddie James
2018-07-02 18:16       ` Wolfram Sang
2018-06-14  9:05 ` [PATCH v10 0/7] i2c: Add FSI-attached I2C master algorithm Andy Shevchenko
2018-06-18  4:53 ` Joel Stanley
2018-06-26  2:39 ` Wolfram Sang
2018-06-27 13:53   ` Eddie James

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=3dc50e6b-6985-1920-4f8c-dc7698e2f692@linux.vnet.ibm.com \
    --to=eajames@linux.vnet.ibm.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joel@jms.id.au \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peda@axentia.se \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=wsa@the-dreams.de \
    --subject='Re: [PATCH v10 4/7] i2c: fsi: Add abort and hardware reset procedures' \
    /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

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).