From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60161C10F25 for ; Mon, 9 Mar 2020 21:48:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 38FD124649 for ; Mon, 9 Mar 2020 21:48:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EnAOLY3l" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726838AbgCIVs1 (ORCPT ); Mon, 9 Mar 2020 17:48:27 -0400 Received: from mail-pj1-f67.google.com ([209.85.216.67]:36819 "EHLO mail-pj1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726118AbgCIVs0 (ORCPT ); Mon, 9 Mar 2020 17:48:26 -0400 Received: by mail-pj1-f67.google.com with SMTP id l41so503224pjb.1; Mon, 09 Mar 2020 14:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=M+Yc5KaBBvqlUu6IX9+jhdSvvYBrtTQ1N/+uZrTujAY=; b=EnAOLY3lknQn3MrFOnTG47rE/msuLtkHcwI9CiqqLxAphICFFDtZpSmVBdHY1gjaT1 nF3ZgHtiuEflpauwpjHLTa11NmOBCgIGoRnB/lC61GeUFJGTQUhR7M5jhLKEkVom/atE rGNK46z/+EJGKYmexGaRptMczx6WalQZ7vm1+hnINGCorC4R+/lDj28HCN2YFObBXibf TbBc8ktb/3tvgKvbKZYVuXQFQ1jCh7q5i2kNRpO8mDbWAxKJ4bf2OPG8x6COaosxKY5L JbUlwomEzIjo5YEQYdlVnYLt8bnVg32QPMRPbi/wBzdkVbfsh8Q61ZV2waG0vTF+9vHY Rdwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=M+Yc5KaBBvqlUu6IX9+jhdSvvYBrtTQ1N/+uZrTujAY=; b=mm7w3L8jqlQIB8Lu2kEgJxyj37wTFyz2EXsB840lnf6J2Wfio0xEfHjW201sfChTZr bjFAuPv5mC1gn1ux0eEJKc0qQimcpXBxZZ5ivDC7wgnc6sVqBYGIuduMOeqhG8qlErOy RjP926mWRMhXUVFWVOOOJdGskqAVJ8PTOYrDmeKZWjCNEKkrdPHQ0KFZi27D7l2XyA3K os0kSgnol6L/ha9RlAtqDD6+rcQlfjiOhZ42NVMvx19h+vXdU+MAPE3YOeNlOyvWwRop ntPccf2Q92sAXrCFu0XijIeg/64JgHKrB+k0pXPAwfy3q5WGocl8lKxZ8Q3fi1tSCFcr h6fA== X-Gm-Message-State: ANhLgQ0bbrk3KOLcIuUyShwCSv7CT+iQh+iyEZ/GhN8VctyhYwSkfVDH 3V9O0t6TCjsx6N/jj/XCZOo= X-Google-Smtp-Source: ADFU+vspwoKFKjFMDUf9nlAvLvUHioLAIIAwk15+/ODm/1HJWpwGZy4//EuoLeQ1SRiulbB+FAF01Q== X-Received: by 2002:a17:90a:ba89:: with SMTP id t9mr1352540pjr.93.1583790503831; Mon, 09 Mar 2020 14:48:23 -0700 (PDT) Received: from localhost ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id q15sm9321748pgn.68.2020.03.09.14.48.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 09 Mar 2020 14:48:23 -0700 (PDT) Date: Mon, 9 Mar 2020 14:48:22 -0700 From: Guenter Roeck To: Guru Das Srinagesh Cc: linux-pwm@vger.kernel.org, Thierry Reding , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Subbaraman Narayanamurthy , linux-kernel@vger.kernel.org, Kamil Debski , Bartlomiej Zolnierkiewicz , Jean Delvare , Liam Girdwood , Mark Brown , linux-hwmon@vger.kernel.org Subject: Re: [PATCH v7 03/13] hwmon: pwm-fan: Use 64-bit division macros for period and duty cycle Message-ID: <20200309214822.GA19773@roeck-us.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-hwmon-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org On Mon, Mar 09, 2020 at 12:35:06PM -0700, Guru Das Srinagesh wrote: > Because period and duty cycle are defined in the PWM framework structs > as ints with units of nanoseconds, the maximum time duration that can be > set is limited to ~2.147 seconds. Redefining them as u64 values will > enable larger time durations to be set. > > As a first step, prepare drivers to handle the switch to u64 period and > duty_cycle by replacing division operations involving pwm period and duty cycle > with their 64-bit equivalents as appropriate. The actual switch to u64 period > and duty_cycle follows as a separate patch. > > Where the dividend is 64-bit but the divisor is 32-bit, use *_ULL > macros: > - DIV_ROUND_UP_ULL > - DIV_ROUND_CLOSEST_ULL > - div_u64 > > Where the divisor is 64-bit (dividend may be 32-bit or 64-bit), use > DIV64_* macros: > - DIV64_U64_ROUND_CLOSEST > - div64_u64 > There is no explanation why this is necessary. What is the use case ? It is hard to imagine a real-world use case with a duty cycle of more than 2 seconds. Guenter