All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Büsch" <m@bues.ch>
To: Jean Delvare <khali@linux-fr.org>
Cc: Michael@freedesktop.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Buesch <mb@bu3sch.de>
Subject: Re: [Intel-gfx] [PATCH 1/2] Give up on edid retries when i2c tells us  that bus is not there
Date: Thu, 20 Oct 2011 15:18:08 +0200	[thread overview]
Message-ID: <20111020151808.30e561e4@milhouse> (raw)
In-Reply-To: <20111020143339.59270702@endymion.delvare>

On Thu, 20 Oct 2011 14:33:39 +0200
Jean Delvare <khali@linux-fr.org> wrote:

> retry mechanism: Chris Wilson and Michael Buesch (both Cc'd.) Chris,
> Michael, do you know of ways to reproduce the issue?

The error could easily reproduced by loading the machine heavily.
So my guess is that it is caused by electrical noise injected into
the i2c bus. Probably due to bad hardware design. But that doesn't matter.
I have to live with that. The error did not trigger again with the workaround
in place, though.

> Can you please
> also confirm that the error code you were receiving was not -ENXIO?

I really don't remember what error code it was.

> Note that the problem is more likely to happen with slow masters,
> because (1) every transaction takes longer and thus has a higher
> probability to be hit by interrupts and (2) long delays mean smaller
> margins to the spec limits, so interrupts are more likely to cause
> trouble. I see that both radeon_i2c and intel_i2c set udelay to 20 µs,
> which means a 25 kbps I2C bus. In general it is recommended to not
> drive the I2C bus below 10 kbps (that's even a hard limit for SMBus
> compliance.) nouveau_i2c is even worse with udelay = 40 µs which is
> equivalent to a 12.5 kbps I2C bus, very close to the low limit.

Hm. Not sure. I don't think the machine had heavy IRQ load.
Just high CPU and memory load (compile the kernel or something like that).

-- 
Greetings, Michael.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2011-10-20 14:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-17 13:12 [PATCH] Improvements in edid detection timings (final) Eugeni Dodonov
2011-10-17 13:12 ` [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there Eugeni Dodonov
2011-10-17 20:41   ` Keith Packard
2011-10-17 21:07     ` Eugeni Dodonov
2011-10-17 22:41       ` Keith Packard
2011-10-18  0:06         ` Eugeni Dodonov
2011-10-18 10:02   ` [Intel-gfx] " Dave Airlie
2011-10-18 13:14     ` Jean Delvare
2011-10-18 13:37       ` Eugeni Dodonov
2011-10-20 12:33         ` Jean Delvare
2011-10-20 12:40           ` Jean Delvare
2011-10-20 13:13           ` Jean Delvare
2011-10-20 13:18           ` Michael Büsch [this message]
2011-10-24 14:40           ` Eugeni Dodonov
2011-10-25 13:03             ` [PATCH] Give up on edid retries when i2c bus is not responding Eugeni Dodonov
2011-10-26 17:06               ` Eugeni Dodonov
2011-10-26 17:18                 ` Chris Wilson
2011-10-26 17:35                   ` Eugeni Dodonov
2011-10-30 15:53             ` [Intel-gfx] [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there Jean Delvare
2011-10-18 14:01     ` Alex Deucher
2011-11-01  0:31     ` [PATCH] edid candidate for -next Eugeni Dodonov
2011-11-01  0:31       ` [PATCH] Give up on edid retries when i2c bus is not responding Eugeni Dodonov
2011-10-31 19:45   ` [Intel-gfx] [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there Chris Wilson
2011-10-17 13:12 ` [PATCH 2/2] Check if the bus is valid prior to discovering edid Eugeni Dodonov

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=20111020151808.30e561e4@milhouse \
    --to=m@bues.ch \
    --cc=Michael@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=khali@linux-fr.org \
    --cc=mb@bu3sch.de \
    /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.