Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp826731pxf; Thu, 1 Apr 2021 14:54:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyOx9oArjVC1OLOFdXS2pKE3T4bOFxCSDBVmuTw1TPFqk8NQEr3bjjbKD0Zg7P7Ed69/AsV X-Received: by 2002:a02:c610:: with SMTP id i16mr9988786jan.36.1617314066218; Thu, 01 Apr 2021 14:54:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617314066; cv=none; d=google.com; s=arc-20160816; b=M4BI/Ita6AK0H7MU+2PaFXZRUUmkwfzk2edjJr79Ppumaz7CtvWaeb42B/KZfJ1DJ+ i1g0Gd+pRaLOotIJ9dlXhGqtcs6xTOPYAvN+THpuOCURY9MUGE/PPqlQZ3+/2SL8qiwi X7YtSk5Ljvv5I+gklvD9Tfq6Cz4sephrQ1OopWIkrp51EG0nfIExXPkT4i/1rMkqW5ZJ ZqHUBTGj/ordz3PwTV0iQ2iZkAXZ+rYMJ9FKYlr57uCjcoku9F5yhML3R/DFQ1UBz+e/ nWgb3eexjcly/j87vvb69HgK90yfoG0H/b50h1l3pxLKpR2Mg6nvt1e3GQFNAZRwVt3T pEYQ== 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=0N8Xv5M2r8DuA0G72Eh5WJ4TQMU7XOSE5/H0mYt14VA=; b=NDTfIKdCgKMeNIe+NGKD5FXPJhVswJrpBzpe5LuC1e+2G4IV+RDph5MTLIf+1jzUcB rve8okAaRwgg8C86cLwgd6DrcKUixc0MNkpy88DUWWT4qARjqmGrJLyIYHrQErEwyWHM DdC2EBXUGwYYoJbKv5sktU3pTUawXJbZnRysx3iwgHq20NQSPM6tjz5SwW1MO7OIPuQB iHFDu4h3EiOfSytV/cBD1kwHizoG0Aqes262SPavc3NR0fffY+ZScvwOEMUPWmU+tGOX 7at9eNzkrG64koKzQsqe4PAZXLRAUBBLFIpzTdvHDG+7RQxhX1WN5hpw0DtNOelrlBKa jUzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pqgruber.com header.s=mail header.b=jZNJzO5f; 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 v5si7432570ilc.160.2021.04.01.14.54.11; Thu, 01 Apr 2021 14:54:26 -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=jZNJzO5f; 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 S234502AbhDAVxz (ORCPT + 99 others); Thu, 1 Apr 2021 17:53:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233974AbhDAVxz (ORCPT ); Thu, 1 Apr 2021 17:53:55 -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 2186DC0613E6; Thu, 1 Apr 2021 14:53:55 -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 48BF7C729F1; Thu, 1 Apr 2021 23:53:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqgruber.com; s=mail; t=1617314033; bh=0N8Xv5M2r8DuA0G72Eh5WJ4TQMU7XOSE5/H0mYt14VA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jZNJzO5feCcaWCsJY6YrHmOqx2LgB3TJkW0gS09OzzdJHoA4LttrhVahRm3i9sE9V yc2sWiZxQa9cE+T8zNFiNtpF78P6ZgbM4tkZSwyeq2QAPWhDYxI5lYoW0dLQpAWoou 7OmqfWqPsiQcRVeX0M9QBH5OaNpkpo9mEqQqPlss= Date: Thu, 1 Apr 2021 23:53:51 +0200 From: Clemens Gruber To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: linux-pwm@vger.kernel.org, Thierry Reding , Sven Van Asbroeck , linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 4/7] pwm: pca9685: Support staggered output ON times Message-ID: References: <20210329125707.182732-1-clemens.gruber@pqgruber.com> <20210329125707.182732-4-clemens.gruber@pqgruber.com> <20210329170357.par7c3izvtmtovlj@pengutronix.de> <20210329180206.rejl32uajslpvbgi@pengutronix.de> <20210401205936.nnraoeeyo5nx3elf@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210401205936.nnraoeeyo5nx3elf@pengutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 01, 2021 at 10:59:36PM +0200, Uwe Kleine-K?nig wrote: > On Wed, Mar 31, 2021 at 03:55:49PM +0200, Clemens Gruber wrote: > > On Wed, Mar 31, 2021 at 02:26:14PM +0200, Clemens Gruber wrote: > > > On Mon, Mar 29, 2021 at 08:02:06PM +0200, Uwe Kleine-K?nig wrote: > > > > On Mon, Mar 29, 2021 at 07:16:38PM +0200, Clemens Gruber wrote: > > > > > On Mon, Mar 29, 2021 at 07:03:57PM +0200, Uwe Kleine-K?nig wrote: > > > > > > On Mon, Mar 29, 2021 at 02:57:04PM +0200, Clemens Gruber wrote: > > > > > > > The PCA9685 supports staggered LED output ON times to minimize current > > > > > > > surges and reduce EMI. > > > > > > > When this new option is enabled, the ON times of each channel are > > > > > > > delayed by channel number x counter range / 16, which avoids asserting > > > > > > > all enabled outputs at the same counter value while still maintaining > > > > > > > the configured duty cycle of each output. > > > > > > > > > > > > > > Signed-off-by: Clemens Gruber > > > > > > > > > > > > Is there a reason to not want this staggered output? If it never hurts I > > > > > > suggest to always stagger and drop the dt property. > > > > > > > > > > There might be applications where you want multiple outputs to assert at > > > > > the same time / to be synchronized. > > > > > With staggered outputs mode always enabled, this would no longer be > > > > > possible as they are spread out according to their channel number. > > > > > > > > > > Not sure how often that usecase is required, but just enforcing the > > > > > staggered mode by default sounds risky to me. > > > > > > > > There is no such guarantee in the PWM framework, so I don't think we > > > > need to fear breaking setups. Thierry? > > > > > > Still, someone might rely on it? But let's wait for Thierry's opinion. > > > > > > > > > > > One reason we might not want staggering is if we have a consumer who > > > > cares about config transitions. (This however is moot it the hardware > > > > doesn't provide sane transitions even without staggering.) > > > > > > > > Did I already ask about races in this driver? I assume there is a > > > > free running counter and the ON and OFF registers just define where in > > > > the period the transitions happen, right? Given that changing ON and OFF > > > > needs two register writes probably all kind of strange things can > > > > happen, right? (Example thought: for simplicity's sake I assume ON is > > > > always 0. Then if you want to change from OFF = 0xaaa to OFF = 0xccc we > > > > might see a period with 0xacc. Depending on how the hardware works we > > > > might even see 4 edges in a single period then.) > > > > > > Yes, there is a free running counter from 0 to 4095. > > > And it is probably true, that there can be short intermediate states > > > with our two register writes. > > > > > > There is a separate mode "Update on ACK" (MODE2 register, bit 3 "OCH"), > > > which is 0 by default (Outputs change on STOP command) but could be set > > > to 1 (Outputs change on ACK): > > > "Update on ACK requires all 4 PWM channel registers to be loaded before > > > outputs will change on the last ACK." > > > > This would require the auto-increment feature to be enabled, then > > multiple registers could be written before the STOP condition: > > LEDn_ON_L, LEDn_ON_H, LEDn_OFF_L & LEDn_OFF_H > > (With OCH=0 in MODE2) > > Maybe a continued START would work, too?! Yes, maybe. But according to the datasheet bus transaction examples, it's enough to have one START condition and write multiple (continuous) registers using the auto-increment feature. And repeated START does not seem to be supported via regmap..? Clemens