ville.syrjala@xxxxxxxxxxxxxxx writes:
> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxxx
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
