Re: ddc/ci over i2c

[Sanford Rockowitz <rockowitz-9+fK6rGKj7RBDgjK7y7TUQ@public.gmane.org>]

On 08/10/2014 02:05 AM, Jean Delvare wrote:
> Hi Sanford,
>
> Thanks for all the explanations.
>
> On Sat, 09 Aug 2014 14:18:35 -0700, Sanford Rockowitz wrote:
>> Lastly, a question.  I have one monitor, a relatively recent
>> "professional" quality Dell P2411H, which has a propensity to return
>> duplicated bytes on read(), .e.g.  0x01020203 instead of 0x010203. The
>> DDC protocol works, but has high retry counts.   Any thoughts on what I
>> might do here as a workaround?
> I'm a bit confused by the question, as I don't understand how you could
> read more bytes than you actually decided. Or do you mean that, when
> reading for example six bytes, you get "1, 2, 2, 3, 4, 5" instead of
> the expected "1, 2, 3, 4, 5, 6", i.e. the byte count is good but you're
> missing the last one (and you have one duplicate)?

The byte count is correct.   There's a duplicate and so I'm missing the 
last byte.  The duplicate can be anywhere in the sequence. I detect the 
problem when some field value is invalid, or more commonly the checksum 
calculation fails.
>
> I have two Dell monitors here, U2312HM and P2414H, I can try to
> reproduce the problem if you give me the code to run.

I'll have to build a simple test case.   Won't be able to get to it for 
a few days.
>
> I can't remember seeing this before, so I have no immediate explanation.
> However some I2C chips use an internal pointer register to select which
> register is being read. Whenever you read a byte, the pointer gets
> increased to point to the next register. I can imagine that, if the
> master reads faster than the slave is able to process, then maybe the
> next read could happen before the pointer register is actually
> increased. That being said, with such a race condition, I'd expect the
> pointer to eventually catch up so you'd get something like "1, 2, 2, 4,
> 5, 6". Is the duplicate byte always early in the sequence, or can it be
> anywhere?

As noted, the duplicate can be anywhere in the sequence.   I'll have to 
study the traces to see if there's a corresponding dropped byte.

> I suggest that you verify that the master properly handles clock
> stretching (to give the slave the opportunity to slow down the
> transfer.) Or simply lower the DDC bus clock speed and see if it helps.
>
I'm using write() and read() on /dev/i2c-n to communicate with the 
monitor.  Is there some way to control clock stretching or DDC bus clock 
speed from userspace?

I just built a custom kernel (first time in years), with the following 
lines in config-local:

CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_ALGO=y

I was puzzling over why I wasn't seeing any output in /var/log/messages 
when your email came in.  I would have thought I'd  be overwhelmed by 
output.  But when communicating with the P2411H, I do see repeated lines 
of the form:

Aug 10 02:55:34 banner kernel: [ 5006.692794] i2c i2c-0: sendbytes: NAK 
bailout.

Sanford