public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: David Milburn <dmilburn-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
Subject: Re: [PATCH] i2c-piix4-inc-delay-after-starting-transaction
Date: Fri, 02 May 2008 16:25:36 -0500	[thread overview]
Message-ID: <481B86D0.7080306@redhat.com> (raw)
In-Reply-To: <20080502220528.65c07727-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>


Hi Jean,

Jean Delvare wrote:
> Hi David,
> 
> On Tue, 29 Apr 2008 12:00:53 -0500, David Milburn wrote:
> 
>>Per the PIIX4 errata, there maybe a delay between setting the
>>start bit in the Smbus Host Controller Register and the transaction
>>actually starting. If the driver doesn't delay long enough, it
>>may appear that the transaction is complete when actually it
>>hasn't started, this may lead to bus collisions.
> 
> 
> The driver was already waiting at least 1 ms before checking the busy
> bit. I don't see any value mentioned in the PIIX4 specification update,
> so what makes you think that 2 ms is required? And what makes you think
> it's sufficient?

Yes, you are correct it doesn't specify a value, I was trying to
make a minimal increase, but as you state below it probably would
be better to wait intially instead of impacting the polling loop.

> 
> I've never seen any problem with the i2c-piix4 driver on my PIIX4,
> while I tested it hard at HZ=1000. On which chip did you hit the
> problem? On what machine? Which transaction? How frequently? And how
> did you notice? Details please.
> 

It is always reproducible when running "sensors" on a Tyan
Trinity GC-SL (s2707) with a Broadcom ServerWorks Grand Champion
SL chipset and a Winbond W83782D.

With debugging turned on, here is the dmesg leading up to the
timeout (more details at bugzilla.redhat.com BZ 182687).

i2c_adapter i2c-0: Transaction (post): CNT=0c, CMD=aa, ADD=91, DAT0=4b, DAT1=00
i2c_adapter i2c-0: Transaction (pre): CNT=08, CMD=02, ADD=91, DAT0=4b, DAT1=00
i2c_adapter i2c-0: temp 02, timeout 0 MAX_TIMEOUT 500
i2c_adapter i2c-0: Transaction (post): CNT=08, CMD=02, ADD=91, DAT0=4b, DAT1=00
i2c_adapter i2c-0: Transaction (pre): CNT=08, CMD=16, ADD=91, DAT0=4b, DAT1=00
i2c_adapter i2c-0: temp 09, timeout 501 MAX_TIMEOUT 500
i2c_adapter i2c-0: SMBus Timeout!
i2c_adapter i2c-0: Bus collision! SMBus may be locked until next hard reset. (sorry!)
i2c_adapter i2c-0: Failed reset at end of transaction (01)
i2c_adapter i2c-0: Transaction (post): CNT=08, CMD=16, ADD=91, DAT0=4b, DAT1=00
i2c_adapter i2c-0: Transaction (pre): CNT=0c, CMD=00, ADD=91, DAT0=4b, DAT1=00
i2c_adapter i2c-0: SMBus busy (01). Resetting...
i2c_adapter i2c-0: Failed! (01)

>>Signed-off-by: David Milburn <dmilburn-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>---
>> drivers/ata/libata-core.c      |    0 
>> drivers/i2c/busses/i2c-piix4.c |    2 +-
>> 2 files changed, 1 insertion(+), 1 deletion(-)
>>
>>diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
>>index 9bbe96c..84a70ac 100644
>>--- a/drivers/i2c/busses/i2c-piix4.c
>>+++ b/drivers/i2c/busses/i2c-piix4.c
>>@@ -232,7 +232,7 @@ static int piix4_transaction(void)
>> 
>> 	/* We will always wait for a fraction of a second! (See PIIX4 docs errata) */
>> 	do {
>>-		msleep(1);
>>+		msleep(2);
>> 		temp = inb_p(SMBHSTSTS);
>> 	} while ((temp & 0x01) && (timeout++ < MAX_TIMEOUT));
>> 
> 
> 
> This is not only increasing the delay before checking the busy bit
> right after starting a transaction. This also slows down the polling
> loop. And this also has the side effect of doubling the timeout - not
> really your fault, count-based timeouts are broken by design.
> 
> I am additionally worried that you are changing this for all devices,
> while presumably only the PIIX4 (and maybe the 82443MX? not sure) are
> affected. If seems unfair to slow down the more recent devices.
> 
> I'd like you to update your patch to only change the initial wait time
> and not the polling loop interval. It should be fairly easy. I also
> would like you to make this change device-dependent, so that newer
> devices aren't slowed down.

Ok, I will re-submit an updated patch after testing.

Thanks for reviewing,
David

> 
> Thanks,


_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

  parent reply	other threads:[~2008-05-02 21:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29 17:00 [PATCH] i2c-piix4-inc-delay-after-starting-transaction David Milburn
     [not found] ` <20080429170053.GA16863-MyKPER+WmwNgWwbpmQC+TKfLeoKvNuZc@public.gmane.org>
2008-05-02 20:05   ` Jean Delvare
     [not found]     ` <20080502220528.65c07727-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-05-02 21:25       ` David Milburn [this message]
     [not found]         ` <481B86D0.7080306-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-05-03  6:22           ` Jean Delvare
     [not found]             ` <20080503082250.39fdaf60-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-05-03 10:03               ` Jean Delvare

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=481B86D0.7080306@redhat.com \
    --to=dmilburn-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.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