Re: [PATCH 6/7] drm: Add ratelimited versions of the DRM_DEBUG* macros

2016-08-06 Thread Joe Perches
On Fri, 2016-08-05 at 20:30 -0400, Lyude wrote: > There's a couple of places where this would be useful for drivers (such > as reporting DP aux transaction timeouts). Maybe a single static _rs or one for each type would be better than an individual _rs per callsite. __

[PATCH 4/7] drm/amdgpu: Don't print error on aux transaction timeouts

2016-08-06 Thread Lyude
Since it's normal for DRM to retry our aux transaction helpers multiple times in a row, up to 32 times for each attempted transaction, we're making a lot of noise that is no longer necessary now that DRM will just print the return code we give it. Signed-off-by: Lyude --- drivers/gpu/drm/amd/amd

Re: [PATCH 0/7] Minor DP aux transaction fixes

2016-08-06 Thread Christian König
Am 06.08.2016 um 02:30 schrieb Lyude: While I was investigating an unrelated bug on the radeon driver, I noticed that it's become rather difficult to actually read through dmesg with drm.debug turned on, on account of the huge number of messages we end up printing from failed DP aux transactions

[PATCH 5/7] drm/amdgpu: Don't retry 7 times in amdgpu_atombios_dp_get_dpcd()

2016-08-06 Thread Lyude
When this code was written, we didn't retry DP aux transactions on any error, which required retrying important transactions like this in individual drivers. Since that's no longer the case, retrying here is not necessary. As well, we retry any aux transaction on any error 32 times. 7 * 32 = 224, w

[PATCH 0/7] Minor DP aux transaction fixes

2016-08-06 Thread Lyude
While I was investigating an unrelated bug on the radeon driver, I noticed that it's become rather difficult to actually read through dmesg with drm.debug turned on, on account of the huge number of messages we end up printing from failed DP aux transactions that happen every time we reprobe each c