All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 1/3] media: i2c: Add ADV761X support
Date: Thu, 26 Sep 2013 06:31:58 +0000	[thread overview]
Message-ID: <5243D4DE.1050508@xs4all.nl> (raw)
In-Reply-To: <1380029916-10331-2-git-send-email-valentine.barshak@cogentembedded.com>

On 09/26/2013 12:57 AM, Laurent Pinchart wrote:
> On Wednesday 25 September 2013 18:31:51 Guennadi Liakhovetski wrote:
>> On Wed, 25 Sep 2013, Valentine wrote:
>>> On 09/25/2013 06:08 PM, Guennadi Liakhovetski wrote:
> 
> [snip]
> 
>>>>>>> +/* I2C I/O operations */
>>>>>>> +static s32 adv_smbus_read_byte_data(struct i2c_client *client, u8
>>>>>>> command)
>>>>>>> +{
>>>>>>> +	s32 ret, i;
>>>>>>> +
>>>>>>> +	for (i = 0; i < 3; i++) {
>>>>>>> +		ret = i2c_smbus_read_byte_data(client, command);
>>>>>>
>>>>>> Uhm, why do you need to do this 3 times?... I see adv7842 does that
>>>>>> too...
>>>>>> but e.g. adv7604 dies this only for writing and not for reading...
>>>>>
>>>>> Just thought it would be safe to retry in case of a failure.
>>>>> Other drivers seem to retry I2C I/O as well. This is probably related
>>>>> to the possible cable issues. Not sure. Anyways, retrying doesn't seem
>>>>> to hurt, does it?
>>>>
>>>> It does, because it means there's something we don't understand. IMHO it
>>>> should either work from the first time, or there should be an error,
>>>> that we understand with a following error processing, that _might_
>>>> include re-trying. Re-trying just in case isn't good. Especially if no
>>>> error has been observed.
>>>
>>> I have observed very rare errors when reading HDMI status. Just a couple
>>> of times during this week. I'm not sure of the nature of those errors.
>>> Just thought it would be OK to retry since other decoder drivers do so as
>>> well.
>>
>> Ok, understand. As I said, I personally don't like that, but, I think,
>> Laurent will have a final word on this.
> 
> I don't like the idea of blindly retrying, especially for write operations. If 
> a read fails due to a flaky cable, there's equal chances that a write would 
> fail as well, which could result in writing random values to random registers. 
> Given the side effects that this could have, I'd much rather not retry I/O 
> operations and have the users fix electrical issues. Hiding something this 
> serious could be dangerous.
> 

For a ubiquitous and relatively slow-speed bus the i2c bus is surprisingly
flaky in my experience. I've seen surprisingly many cases where a retry was
useful or even necessary. There can be many causes: electrical issues is one,
and while that shouldn't happen, in practice it does. Interference by other
devices on the bus is another. And sometimes the device itself is flaky: in
the case of the adv7511 trying to enable/disable an interrupt just fails
every so often.

I have yet to see a product bringup where the i2c bringup 'just works'. There
are always problems there.

Regards,

	Hans

  parent reply	other threads:[~2013-09-26  6:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24 13:38 [PATCH 1/3] media: i2c: Add ADV761X support Valentine Barshak
2013-09-24 14:17 ` Hans Verkuil
2013-09-24 15:54 ` Guennadi Liakhovetski
2013-09-24 16:19 ` Guennadi Liakhovetski
2013-09-24 17:37 ` Hans Verkuil
2013-09-24 18:09 ` Andy Walls
2013-09-25  9:57 ` Laurent Pinchart
2013-09-25 10:21 ` Laurent Pinchart
2013-09-25 12:33 ` Valentine
2013-09-25 13:02 ` Valentine
2013-09-25 14:08 ` Guennadi Liakhovetski
2013-09-25 15:16 ` Valentine
2013-09-25 16:31 ` Guennadi Liakhovetski
2013-09-25 17:19 ` Valentine
2013-09-25 18:33 ` Guennadi Liakhovetski
2013-09-25 20:36 ` Valentine
2013-09-25 22:04 ` Laurent Pinchart
2013-09-25 22:57 ` Laurent Pinchart
2013-09-26  6:31 ` Hans Verkuil [this message]
2013-09-26  6:45 ` Hans Verkuil
2013-09-26  6:57 ` Hans Verkuil
2013-09-26  9:36 ` Laurent Pinchart
2013-09-26  9:39 ` Laurent Pinchart

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=5243D4DE.1050508@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=linux-sh@vger.kernel.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 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.