Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp357686pxb; Wed, 14 Apr 2021 17:44:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzrD4Ss8aq6iZQDJTFP3tpGZdzwTOP8R75ak2aI22MNLo3MqDdv96LJ0B3JhR/SDiOGdjIq X-Received: by 2002:a17:90b:4c43:: with SMTP id np3mr887527pjb.144.1618447446383; Wed, 14 Apr 2021 17:44:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618447446; cv=none; d=google.com; s=arc-20160816; b=aq+oMkP3wjxlQUTX3z/QHwO/znHf4kQpc3xRkZlOQpflJV7efo6xLKsIVbOUNc9I1L NAhinowQ2LnEohhQNC1EjKFZnmp9pcFplWoqJnF2QP/2dLReKaMZDIq7oz+k+oV3VFxH v448r/qIOaVaHdwO2Kg7ZwkulUnFMrOb0lYeUZiBtijaDB9idbqq1zc8V8DwOIkDCiQ1 mb6f5GryjI278m7FgYibOZvoAtV9tScNRFgtcz1+XqoMRP+cC4rChagRIAM8EX71vP6s FHsQipiep1ytZkyqKb4Rf6Wq6jFIQWVwCgWXO4alElp2y5B5gIBXAtBAdecfWFYTyNBo oGqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=NcyhMGkK4f3s6Jb75I3zSLqjm8FszWSB9VvtZQdYA3o=; b=x6p1W5ipgdMjAM8sJMOffk0bAFi2eiMZqfrG98Lt6lA8RtMpdQP8rdi31O1GSLaKyw KCzSn985A4Qya79Kyytx6blq4uWBI0WsZRhJBkxKZRa0TEdHhC4r+pAzw0eDy46XltaH LFEdfLKgGIGo+bzbu5IJ7597PKuokNAWUxb3dUQVO8T+lJNHDi7lTZSjQU/CCinAWk7s gW1PFshFHYjJyoydKT5LegJsWX70phPqp/NEnQkvlijj6dMi4PDSP0iWCya54J3oGA2t 5Ekz7KrC6X0irRfRoAeKQDVJoq3liMvlJNojAWv0i0Hl2F3YAJNlR+tjpyiJQaMgbwfo fFbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pqgruber.com header.s=mail header.b=INppUTN2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=pqgruber.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b14si1311909pfi.0.2021.04.14.17.43.53; Wed, 14 Apr 2021 17:44:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@pqgruber.com header.s=mail header.b=INppUTN2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=pqgruber.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353467AbhDNTp7 (ORCPT + 99 others); Wed, 14 Apr 2021 15:45:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347936AbhDNTp6 (ORCPT ); Wed, 14 Apr 2021 15:45:58 -0400 Received: from mail.pqgruber.com (mail.pqgruber.com [IPv6:2a05:d014:575:f70b:4f2c:8f1d:40c4:b13e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A347C061574; Wed, 14 Apr 2021 12:45:35 -0700 (PDT) Received: from workstation.tuxnet (213-47-165-233.cable.dynamic.surfer.at [213.47.165.233]) by mail.pqgruber.com (Postfix) with ESMTPSA id 56B9FC725CF; Wed, 14 Apr 2021 21:45:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqgruber.com; s=mail; t=1618429534; bh=NcyhMGkK4f3s6Jb75I3zSLqjm8FszWSB9VvtZQdYA3o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=INppUTN2R41mVczgBPa/SGaLm4kMSUW/fkHjLuCQy8DdAGjP1F0Oi0y0493qiBvyq LRWYeFvSQ7JBCfMiQxaL3JMJlcSvw1bHeXRRKto+25h47bjQ+XJTMqin9Wrr8Mnn6M UHU9V5yd1/scDbBE2aMGNlHkS65az6/QRYyoe6hM= Date: Wed, 14 Apr 2021 21:45:32 +0200 From: Clemens Gruber To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: linux-pwm@vger.kernel.org, Thierry Reding , Sven Van Asbroeck , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 1/8] pwm: pca9685: Switch to atomic API Message-ID: References: <20210412132745.76609-1-clemens.gruber@pqgruber.com> <20210412161808.lp2amdfopw74lvz7@pengutronix.de> <20210412201019.vouxx4daumusrcvr@pengutronix.de> <20210413193818.r7oqzdzbxqf5sjj3@pengutronix.de> <20210414192131.2o4c2eia6jnjatp2@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210414192131.2o4c2eia6jnjatp2@pengutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 14, 2021 at 09:21:31PM +0200, Uwe Kleine-K?nig wrote: > On Wed, Apr 14, 2021 at 02:09:14PM +0200, Clemens Gruber wrote: > > Hi Uwe, > > > > On Tue, Apr 13, 2021 at 09:38:18PM +0200, Uwe Kleine-K?nig wrote: > > > Hello Clemens, > > > > > > On Tue, Apr 13, 2021 at 02:11:38PM +0200, Clemens Gruber wrote: > > > > On Mon, Apr 12, 2021 at 10:10:19PM +0200, Uwe Kleine-K?nig wrote: > > > > > On Mon, Apr 12, 2021 at 06:39:28PM +0200, Clemens Gruber wrote: > > > > > > With your suggested round-down, the example with frequency of 200 Hz > > > > > > would no longer result in 30 but 29 and that contradicts the datasheet. > > > > > > > > > > Well, with PRESCALE = 30 we get a frequency of 196.88 Hz and with > > > > > PRESCALE = 29 we get a frequency of 203.45 Hz. So no matter if you pick > > > > > 29 or 30, you don't get 200 Hz. And which of the two possible values is > > > > > the better one depends on the consumer, no matter what rounding > > > > > algorithm the data sheet suggests. Also note that the math here contains > > > > > surprises you don't expect at first. For example, what PRESCALE value > > > > > would you pick to get 284 Hz? [If my mail was a video, I'd suggest to > > > > > press Space now to pause and let you think first :-)] The data sheet's > > > > > formula suggests: > > > > > > > > > > round(25 MHz / (4096 * 284)) - 1 = 20 > > > > > > > > > > The resulting frequency when picking PRESCALE = 20 is 290.644 Hz (so an > > > > > error of 6.644 Hz). If instead you pick PRESCALE = 21 you get 277.433 Hz > > > > > (error = 6.567 Hz), so 21 is the better choice. > > > > > > > > > > Exercise for the reader: > > > > > What is the correct formula to really determine the PRESCALE value that > > > > > yields the best approximation (i.e. minimizing > > > > > abs(real_freq - target_freq)) for a given target_freq? > > > > > > I wonder if you tried this. > > > > We could calculate both round-up and round-down and decide which one is > > closer to "real freq" (even though that is not the actual frequency but > > just our backwards-calculated frequency). > > Yeah, the backwards-calculated frequency is the best assumption we > have. > > > But I can't give you a formula with minimized abs(real_freq-target_freq) > > Is it a different round point than 0.5 and maybe relative to f ? > > > > Please enlighten us :-) > > Sorry, I cannot. I spend ~20 min today after lunch with pencil and > paper, but without success. I was aware that it isn't trivial and this > is the main reason I established round-down as default for new drivers > instead of round-nearest. Oh, I thought you already solved it. I tried too for a while but was unsuccessful. Not trivial indeed! But regarding you establishing round-down: Wouldn't it be even better if the driver did what I suggested above, namely calculate backwards from both the rounded-up as well as the rounded-down prescale value and then write the one with the smallest abs(f_target - f_real) to the register? Clemens