From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 137BE1E520C for ; Thu, 1 Jan 2026 23:13:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767309205; cv=none; b=KLniJD/AAChkKMFPTVW0DFesRMmHLPKCMPJw9d0wR+OBfBd6XoMLIzsaXuRT/HhICrSA0B9BMP2Xv0PBO9GGRvGdHnWkQXHey9BcKpx9BhIFRE6QC6mzPRIGG+5zFnVajInFqKmS4+UV3Rmv5QX7TYBST89wad/JxqzNQLHX6P0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767309205; c=relaxed/simple; bh=HRQBTibTQCM91x8NiW/klwqsuqpEV9dFggJZFRsAwyA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Yczkgr7T360PBpPcaikHUY3GjuWlG9H84+FzvVW2G8Nz3QWboyuln/CQuBfCkRCaMX/bpiNZc9yN8jOFi0kVKCFfGFrU3G8atEsm0nWP9J9Cd6D6K70TsBmVGcQqiLyMEKHCksG3+ADxP9464TlTPs3TsgVHMegNWTlpdysG1LI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=C7zbDUtF; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="C7zbDUtF" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-42b3d7c1321so6874594f8f.3 for ; Thu, 01 Jan 2026 15:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767309202; x=1767914002; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=XX9HKgNtdlmWfrvLY2GB/fq8FDIfRuG0UCvzUof1dYc=; b=C7zbDUtF24j8mrtFGopYOdT72k/Ii95+cKLLosUxEwqj7Q7NRLocrHl+4UoLMM5SyC NfLNoniFaeC8tQvm4Md0e55ulWLsB811Dq/K96Jad0v/8zgavLbpxeyhWz+8hCpFvCGn bRMhroOdYzjxN/E9Bsew15wGmsLJklBqPJ8r+zGyPbK0ouW+TW9T37Jzrlh23QEML1Kt zY31zpQHergC2+eqsT7asukAskp5fDB2pbzpdzGs1QKlJKinH0LLZUDlULvi+9SsWj3r 3/RFykb37v8aVr7QEXzpLVUhYfO8X3oF8NIm0J1Dx3cLFzpa2dj3SyZJCCt///ZXT9N0 25GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767309202; x=1767914002; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XX9HKgNtdlmWfrvLY2GB/fq8FDIfRuG0UCvzUof1dYc=; b=G84LiR9ElTIy+a/ZWMgJ1bhyqTAgIMiVE6Yy1rq2awOfPCe3yy5s1PJQ3cH9BhJ7ib 6DXc7jZPHi8uYod4VbXEudqUbi7YHJiiavAMjrTpMJeQoZJQgc35vUFvqDMpwKpUZS20 LbD4B56eNxQtJDSpa9YheiCekRPbA7sV64TlVPeMZu2EfDY6NRQALu57YLtistbG6IEP iKXwzgcM3Swjb/+UEewIOXFZFqoKOu6Kn3VDt7rv/cjiUTOYVcRvUmI3lszB0T6k7XvK gYD6AWotnx6WiZGQvMiegv/R3ZjeuXK9OHAGlCAHfNP2VZsr3X7bQvk6EjSq5ZnwK6jh nhEw== X-Forwarded-Encrypted: i=1; AJvYcCWMpGgmqUmzt0AmLUDUeH+RZUHUgbqYBY0EG7bMQYpN/KRdUzOgTxY0kgaY2ze95TyDZptjVJZKZHi6o2I=@vger.kernel.org X-Gm-Message-State: AOJu0YwLNtb9sIak/WLBcwvDyjZ+fZi6F0AmXad7Fg8vWmMua3qIDt/w hBQidLz8nLFWlsXFTIEYMyI08KYr8s2+IMqsFwKDVG+wb7j8U160wW1P X-Gm-Gg: AY/fxX48LgrfefUj1W1NCtEiU8be3eFq/QbE9VPmT+1wcw53RGtrTXIS7DueegF+SnF SeYqyBN7sRzcdk2FSgnUqufxcElAVIpg/DiPBIe/nBzdnBb7aQfsJUVgiKsTUAFAsLbKsolNT7c bVnhVoLMnrZSRREHuC7GcS2ASBGBOlC2vM4bUYmJV8M3g7+SZ2vV03hsFJSZoO75odvDcqiUd/v kXaMHcjb2nMiFgPR8QL+/q9XfUan/lYZSkYDpyIj3zDsjqiGvrk+2JUNycAdHSAtBQqgMBEy7ya 1aGBdRS5DmymlsCeikHzDLAT0Oe0OyrADryKYIRijTGa0kepDRFWXHQbMKXmNndA0PTsEjbyey8 N5iJuTw2xlIbMvH40WkRlt3gv+30r6+PLZDgrTPyvi9Yq/0Ox8zvJeoKqQ/9diuQjP++GRrOfnc dLNE5Zp0IPuB10mRsh5BwwOUeEGhTH4DlebgleMhH/C8EhQEmNVfpG X-Google-Smtp-Source: AGHT+IGRdJAwC31J1FgOs4yAwsXAwWHqkwrMGWpNW8TLxnN+r0x0jJ2mKENNBTKFctDl0fT7gW7U/g== X-Received: by 2002:a05:6000:1843:b0:431:327:5dcc with SMTP id ffacd0b85a97d-4324e50ebcamr47059470f8f.43.1767309202163; Thu, 01 Jan 2026 15:13:22 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324ea82f6asm83437898f8f.27.2026.01.01.15.13.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Jan 2026 15:13:21 -0800 (PST) Date: Thu, 1 Jan 2026 23:13:20 +0000 From: David Laight To: Marek Vasut Cc: dri-devel@lists.freedesktop.org, kernel test robot , David Airlie , Geert Uytterhoeven , Kieran Bingham , Laurent Pinchart , Maarten Lankhorst , Magnus Damm , Maxime Ripard , Simona Vetter , Thomas Zimmermann , Tomi Valkeinen , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH] drm/rcar-du: dsi: Clean up VCLK divider calculation Message-ID: <20260101231320.16766226@pumpkin> In-Reply-To: <15e7f0e9-9862-4606-83d2-d95e0cb6e821@mailbox.org> References: <20251231145712.60816-1-marek.vasut+renesas@mailbox.org> <20260101114221.6a401790@pumpkin> <15e7f0e9-9862-4606-83d2-d95e0cb6e821@mailbox.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 1 Jan 2026 22:26:34 +0100 Marek Vasut wrote: > On 1/1/26 12:42 PM, David Laight wrote: > > Hello David, > > >> static void rcar_mipi_dsi_pll_calc(struct rcar_mipi_dsi *dsi, > >> unsigned long fin_rate, > >> unsigned long fout_target, > >> - struct dsi_setup_info *setup_info) > >> + struct dsi_setup_info *setup_info, > >> + u16 vclk_divider) > > > > There is no need for this to be u16, unsigned int will generate better code. > > Can you please elaborate on the "better code" part ? Basically the compiler has to generate extra code to ensure the value doesn't exceed 65535. So there will be a mask of the function parameter (passes in a 32bit register). Any arithmetic needs similar masking of the result. You won't see the latter (as much) on x86 (or m68k) because the compiler can use the C 'as if' rule and use the cpu's 8/16 bit registers and alu. But pretty much no other cpu can do that, so extra instructions are needed to stop the value (in a 32bit register) exceeding the limit for the variable. Remember that while C variables can be char/short the values they contain are promoted to 'signed int' before (pretty much) anything is done with the value, any calculated value is then truncated before being assigned back. For on-stack values this is fine - but modern compilers was to keep values in registers as much as possible. > > >> { > >> unsigned int best_err = -1; > >> const struct rcar_mipi_dsi_device_info *info = dsi->info; > >> @@ -360,7 +373,7 @@ static void rcar_mipi_dsi_pll_calc(struct rcar_mipi_dsi *dsi, > >> if (fout < info->fout_min || fout > info->fout_max) > >> continue; > >> > >> - fout = div64_u64(fout, setup_info->vclk_divider); > >> + fout = div64_u64(fout, vclk_divider); > > > > Since vclk_divider is BIT_U32(div [+ 1]) this is just a shift right. > > So pass the bit number instead. > > While I agree this is a shift in the end, it also makes the code harder > to understand. I can add the following change into V2, but I would like > input from Tomi/Laurent on whether we should really push the > optimization in that direction: The shift really is a lot faster. Even on 64bit x86 cpus it can be slow - 35-88 clocks prior to 'Cannon Lake'. AMD cpu get better with Zen3, and using a 64bit divide with 32bits values doesn't slow things down (it does on the Intel cpu). Don't even think about what happens on 32bit cpus. I don't know about other architectures. Just comment as 'x >> n' rather than 'x / (1 << n)' David