Re: [PATCH v3 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed

From: moosotc@gmail.com
To: ville.syrjala@linux.intel.com
Cc: Simon Farnsworth <simon.farnsworth@onelan.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed
Date: Tue, 01 Sep 2015 20:26:10 +0300	[thread overview]
Message-ID: <87h9nem4p9.fsf@gmail.com> (raw)
In-Reply-To: <1441127574-32115-1-git-send-email-ville.syrjala@linux.intel.com> (ville syrjala's message of "Tue, 1 Sep 2015 20:12:54 +0300")

ville.syrjala@linux.intel.com writes:

> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Calculate the number of retries we should do for each i2c-over-aux
> message based on the time it takes to perform the i2c transfer vs. the
> aux transfer. We assume the shortest possible length for the aux
> transfer, and the longest possible (exluding clock stretching) for the
> i2c transfer.
>
> The DP spec has some examples on how to calculate this, but we don't
> calculate things quite the same way. The spec doesn't account for the
> retry interval (assumes immediate retry on defer), and doesn't assume
> the best/worst case behaviour as we do.
>
> Note that currently we assume 10 kHz speed for the i2c bus. Some real
> world devices (eg. some Apple DP->VGA dongle) fails with less than 16
> retries. and that would correspond to something close to 15 kHz (with
> our method of calculating things) But let's just go for 10 kHz to be
> on the safe side. Ideally we should query/set the i2c bus speed via
> DPCD but for now this should at leaast remove the regression from the
                                     ^ extra a
> 1->16 byte trasnfer size change. And of course if the sink completes
> the transfer quicker this shouldn't slow things down since we don't
> change the interval between retries.
>
> I did a few experiments with a DP->DVI dongle I have that allows you
> to change the i2c bus speed. Here are the results of me changing the
> actual bus speed and the assumed bus speed and seeing when we start
> to fail the operation:
>
> actual i2c khz          assumed i2c khz         max retries
> 1                       1 ok -> 2 fail          211 ok -> 106 fail
> 5                       8 ok -> 9 fail          27 ok -> 24 fail
> 10                      17 ok -> 18 fail        13 ok -> 12 fail
> 100                     210 ok -> 211 fail      2 ok -> 1 fail
>
> So based on that we have a fairly decent safety margin baked into

[..snip..]

-- 
mailto:moosotc@gmail.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel