Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751474AbdFFRqS (ORCPT ); Tue, 6 Jun 2017 13:46:18 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:33055 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751390AbdFFRqQ (ORCPT ); Tue, 6 Jun 2017 13:46:16 -0400 MIME-Version: 1.0 In-Reply-To: <1496315619.2790.8.camel@codethink.co.uk> References: <20170523200856.903752266@linuxfoundation.org> <20170523200859.986280848@linuxfoundation.org> <1496315619.2790.8.camel@codethink.co.uk> From: Mario Kleiner Date: Tue, 6 Jun 2017 19:46:14 +0200 Message-ID: Subject: Re: [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate To: Ben Hutchings Cc: Alex Deucher , LKML , stable , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1991 Lines: 58 On Thu, Jun 1, 2017 at 1:13 PM, Ben Hutchings wrote: > On Tue, 2017-05-23 at 22:08 +0200, Greg Kroah-Hartman wrote: >> 4.4-stable review patch. If anyone has any objections, please let me know. >> >> ------------------ >> >> From: Mario Kleiner >> >> commit d63c277dc672e0c568481af043359420fa9d4736 upstream. >> >> Avoid big roundoff errors in scanline/hactive durations for >> high pixel clocks, especially for >= 500 Mhz, and thereby >> program more accurate display fifo watermarks. > [...] >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c >> @@ -1237,14 +1237,14 @@ static void dce_v10_0_program_watermarks >> { >> struct drm_display_mode *mode = &amdgpu_crtc->base.mode; >> struct dce10_wm_params wm_low, wm_high; >> - u32 pixel_period; >> + u32 active_time; >> u32 line_time = 0; >> u32 latency_watermark_a = 0, latency_watermark_b = 0; >> u32 tmp, wm_mask, lb_vblank_lead_lines = 0; >> >> if (amdgpu_crtc->base.enabled && num_heads && mode) { >> - pixel_period = 1000000 / (u32)mode->clock; >> - line_time = min((u32)mode->crtc_htotal * pixel_period, (u32)65535); >> + active_time = 1000000UL * (u32)mode->crtc_hdisplay / (u32)mode->clock; >> + line_time = min((u32) (1000000UL * (u32)mode->crtc_htotal / (u32)mode->clock), (u32)65535); > [...] > > Won't these multiplications overflow if a >4K display is attached to a > 32-bit machine? > > Ben. > Yes, indeed > 4k causes a new overflow problem! Thanks for catching this. I will prepare a follow-up patch on top of this one, to use ... active_time = (u32) div_u64((u64) mode->crtc_hdisplay * 1000000, (u32)mode->clock); line_time = (u32) div_u64((u64) mode->crtc_htotal * 1000000, (u32)mode->clock); line_time = min(line_time, (u32) 65535); ...instead. Ok? -mario > -- > Ben Hutchings > Software Developer, Codethink Ltd. > >