On Wed, 19 Mar 2014, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Tue, Mar 18, 2014 at 3:44 AM, Jani Nikula > <jani.nikula@xxxxxxxxxxxxxxx> wrote: >> On Tue, 18 Mar 2014, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: >>> Switch to debug only to avoid flooding the logs. >>> This mirrors the behavior in some other drivers. >> >> I'd rather think we should find out why the DP devices are replying with >> repeated native or i2c-over-aux defers. This doesn't help; I'm not in >> favour. > > While I agree with you in theory, in practice this will generate a ton > of regression bug reports since there will be new error messages in > the kernel log on some systems even though the displays are working > fine. I'm only seeing this on certain cards, others are perfectly > fine even with the same monitors and I don't have the bandwidth right > now to debug this further. In all cases the monitors are working > correctly. I'd argue we *want* the regression reports even when everything seems to be working fine. Otherwise we'll never fix the stuff up. Just a while back we used to have an infinite retry loop there in i915, until a buggy dock firmware actually deferred indefinitely. Clearly most devices out there eventually replied with something other than defer. We'd like to find out whether and how much the retry and/or delay should be increased to not hit the error condition at all. That's how I feel anyway. I'd like to see others chime in as well, and I won't insist if y'all think the error message must go. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
