On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov wrote:
> This allows to avoid talking to a non-existent bus repeatedly until we
> finally timeout. The non-existent bus is signalled by -ENXIO error,
> provided by i2c_algo_bit:bit_doAddress call.
>
> As the advantage of such change, all the
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov eugeni.dodo...@intel.com
wrote:
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such
Hi Eugeni,
On Mon, 24 Oct 2011 12:40:14 -0200, Eugeni Dodonov wrote:
> On Thu, Oct 20, 2011 at 10:33, Jean Delvare wrote:
>
> > Just to clarify: by "connectivity is setup", do you mean code in the
> > driver setting the GPIO pin direction etc., or a display being
> > connected to the graphics
Hi Eugeni,
On Mon, 24 Oct 2011 12:40:14 -0200, Eugeni Dodonov wrote:
On Thu, Oct 20, 2011 at 10:33, Jean Delvare kh...@linux-fr.org wrote:
Just to clarify: by connectivity is setup, do you mean code in the
driver setting the GPIO pin direction etc., or a display being
connected to the
On Thu, Oct 20, 2011 at 10:33, Jean Delvare wrote:
> Just to clarify: by "connectivity is setup", do you mean code in the
> driver setting the GPIO pin direction etc., or a display being
> connected to the graphics card?
>
> I admit I am a little surprised. I2C buses should have their lines up
>
On Thu, Oct 20, 2011 at 10:33, Jean Delvare kh...@linux-fr.org wrote:
Just to clarify: by connectivity is setup, do you mean code in the
driver setting the GPIO pin direction etc., or a display being
connected to the graphics card?
I admit I am a little surprised. I2C buses should have their
On Thu, 20 Oct 2011 14:33:39 +0200
Jean Delvare 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
On Thu, 20 Oct 2011 14:33:39 +0200, Jean Delvare wrote:
> That being said, even then the whole probe sequence shouldn't exceed
> 10 ms, which I wouldn't expect a user to notice. The user-reported 4
> second delay when running xrandr can't be caused by this. 4 seconds for
> 15 attempts is 250 ms
Forgot to attach the patch, sorry. Here it is.
--
Jean Delvare
-- next part --
A non-text attachment was scrubbed...
Name: i2c-algo-bit-export-test.patch
Type: text/x-patch
Size: 1702 bytes
Desc: not available
URL:
On Tue, 18 Oct 2011 11:37:38 -0200, Eugeni Dodonov wrote:
> On 10/18/2011 11:14, Jean Delvare wrote:
> > Hi Dave, Eugeni, Alex,
> >
> > On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
> >>> This allows to avoid talking to a non-existent bus repeatedly until we
> >>> finally timeout. The
On Tue, 18 Oct 2011 11:37:38 -0200, Eugeni Dodonov wrote:
On 10/18/2011 11:14, Jean Delvare wrote:
Hi Dave, Eugeni, Alex,
On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus
Forgot to attach the patch, sorry. Here it is.
--
Jean Delvare
---
drivers/i2c/algos/i2c-algo-bit.c |8 ++--
include/linux/i2c-algo-bit.h |3 +++
2 files changed, 9 insertions(+), 2 deletions(-)
--- linux-3.1-rc10.orig/drivers/i2c/algos/i2c-algo-bit.c 2011-10-20
On Thu, 20 Oct 2011 14:33:39 +0200, Jean Delvare wrote:
That being said, even then the whole probe sequence shouldn't exceed
10 ms, which I wouldn't expect a user to notice. The user-reported 4
second delay when running xrandr can't be caused by this. 4 seconds for
15 attempts is 250 ms per
On Thu, 20 Oct 2011 14:33:39 +0200
Jean Delvare kh...@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
Hi Dave, Eugeni, Alex,
On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
> > This allows to avoid talking to a non-existent bus repeatedly until we
> > finally timeout. The non-existent bus is signalled by -ENXIO error,
> > provided by i2c_algo_bit:bit_doAddress call.
> >
> > As the
On 10/18/2011 11:14, Jean Delvare wrote:
> Hi Dave, Eugeni, Alex,
>
> On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
>>> This allows to avoid talking to a non-existent bus repeatedly until we
>>> finally timeout. The non-existent bus is signalled by -ENXIO error,
>>> provided by
> This allows to avoid talking to a non-existent bus repeatedly until we
> finally timeout. The non-existent bus is signalled by -ENXIO error,
> provided by i2c_algo_bit:bit_doAddress call.
>
> As the advantage of such change, all the other routines which use
> drm_get_edid would benefit for this
On Tue, Oct 18, 2011 at 6:02 AM, Dave Airlie wrote:
>> This allows to avoid talking to a non-existent bus repeatedly until we
>> finally timeout. The non-existent bus is signalled by -ENXIO error,
>> provided by i2c_algo_bit:bit_doAddress call.
>>
>> As the advantage of such change, all the other
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this
Hi Dave, Eugeni, Alex,
On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such
On 10/18/2011 11:14, Jean Delvare wrote:
Hi Dave, Eugeni, Alex,
On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by
On Tue, Oct 18, 2011 at 6:02 AM, Dave Airlie airl...@gmail.com wrote:
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all
On Mon, Oct 17, 2011 at 20:41, Keith Packard wrote:
> On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov
> wrote:
>
> > From what I've checked, the other return error value in this context
> could
> > be -EREMOTEIO, which could be caused by transmission error so it should
> be
> > retried.
>
>
On Mon, Oct 17, 2011 at 18:41, Keith Packard wrote:
> On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov <
> eugeni.dodonov at intel.com> wrote:
>
> > + if (ret == -ENXIO) {
> > + DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> > +
On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov
wrote:
> From what I've checked, the other return error value in this context could
> be -EREMOTEIO, which could be caused by transmission error so it should be
> retried.
Oh, there's -ENOMEM, -EINVAL and probably a few others down in the
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov wrote:
> + if (ret == -ENXIO) {
> + DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> + adapter->name);
> + break;
> + }
This seems
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov eugeni.dodo...@intel.com
wrote:
+ if (ret == -ENXIO) {
+ DRM_DEBUG_KMS(drm: skipping non-existent adapter %s\n,
+ adapter-name);
+ break;
+
On Mon, Oct 17, 2011 at 18:41, Keith Packard kei...@keithp.com wrote:
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov
eugeni.dodo...@intel.com wrote:
+ if (ret == -ENXIO) {
+ DRM_DEBUG_KMS(drm: skipping non-existent adapter
%s\n,
+
On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov eug...@dodonov.net wrote:
From what I've checked, the other return error value in this context could
be -EREMOTEIO, which could be caused by transmission error so it should be
retried.
Oh, there's -ENOMEM, -EINVAL and probably a few others
On Mon, Oct 17, 2011 at 20:41, Keith Packard kei...@keithp.com wrote:
On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov eug...@dodonov.net
wrote:
From what I've checked, the other return error value in this context
could
be -EREMOTEIO, which could be caused by transmission error so it
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
34 matches
Mail list logo
