Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4354591ybb; Tue, 7 Apr 2020 06:01:36 -0700 (PDT) X-Google-Smtp-Source: APiQypLmQ1H5cf1N+r5ixPT5dGepT7MSyWBAojMu4v2xiICMaA2PvOu2zMWwjoPxBJZJV0NZ6n20 X-Received: by 2002:aca:4bc5:: with SMTP id y188mr1579154oia.9.1586264496699; Tue, 07 Apr 2020 06:01:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586264496; cv=none; d=google.com; s=arc-20160816; b=gRPEX5VqSfcKVduMA1iek9R7tAK2Q9oRsVGhDXWXbH5RU+0ysScY6rRX9ULpU0mg26 jP0yH2W/cOXHX/KzF6aSHEzLJ+dOyL+JONF60oJL/Pf+qGPP6sBl5mWTjZpJiWZHNZs0 vStWHV/IIAhLOROe8M7ISwHGtcRpPCXU8JlMOOfM0aazj43Po0umCcyqAHf/IYUwLTTL 50W/jSeI6LrVxF36/73JSAklH59u9p3eZWlN0mCAElG5RsDW9HtqTqs8185ORQ77I+z1 NMFufn3fAA8oFfOQolZG33f2seAq1nMtFoWWUiirsM+iciHQYDXAAO6bIwX+U0kMNmEr uUww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :ironport-sdr:dkim-signature:ironport-sdr; bh=JgpkDjefhUHKkGe2ADWjVREc/IDGBIYUM/Qh/nVjPjA=; b=zLBZ7OBkHAvIdFagKOqwUJ/aMTUDn/z45D3R7qbmpSkCp8P3gCZU4A/Dqqykx9J8oH ixnGL3Zvm2mqbx4axrW4mXW4s0ndfin7mX4wYmf4K7q1LCeIpPrymKwMKQTWaR1gnceV A8R2otGEYyruMlvEhsxC3qPDHK7KIR9a8OfsWC3+I070Tg8YGKs/ugWK3QK1SULenAGo lxkXItHDtan2LUGYzhQhhqvhBjpjSatBohzDGqAxL5MvzxSI0Sj/hUqbWx/VrFdbxf3E qS5/ElWMN5ACzTXwr1L+q4nHHReXxm+PrkXskhZ3yRxJpLtLzV9iT4Mq4pqoYhjc+8C9 P35w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@tq-group.com header.s=key1 header.b=HCmB3RY3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u15si1197678ooq.37.2020.04.07.06.01.22; Tue, 07 Apr 2020 06:01:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@tq-group.com header.s=key1 header.b=HCmB3RY3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728705AbgDGNAr (ORCPT + 99 others); Tue, 7 Apr 2020 09:00:47 -0400 Received: from mx1.tq-group.com ([62.157.118.193]:55697 "EHLO mx1.tq-group.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728555AbgDGNAr (ORCPT ); Tue, 7 Apr 2020 09:00:47 -0400 IronPort-SDR: vX9VCJNXy2/YVgS4o7+c6ZW7Zx+ZX5JTzlyJT/j9Sf+7iyUjSzNyWOwQ+i9XNnB+kmE3u4wMhA usH7lOa6FjADv9Bz+xE75uMcTqVtBxGcPNoNlAF57edkUa6F82j/orVFszRYE20j7heDjSo1Gj MD6mcePXf3xWpW5L+HGp2+6+DwjNOWE5Fmmi7889n+MBgqCJAIjZVEQGkZXPM1tlyt4tu3aOcy 6+Of9TUj4/e1+bRZivppD+N8mNn8gygMxqWyCDZQHKBp/hdn36Vt+S6SZo2aF15WHsYt/D5oDi vU8= X-IronPort-AV: E=Sophos;i="5.72,354,1580770800"; d="scan'208";a="11729933" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 07 Apr 2020 15:00:46 +0200 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Tue, 07 Apr 2020 15:00:46 +0200 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Tue, 07 Apr 2020 15:00:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1586264446; x=1617800446; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=OQ3s2zq914H4XFTE/o+/VvV69xX8LMUBVXfoorhVAPs=; b=HCmB3RY3+j2HQJeg7sQiFyEm5b5fW2+1UpL3+bD3Svctenu7HafWac9T xaZAjOSiqvyyLlP2VCqr3D0MSuim7cJfXkjoYe1YoFgze8flJPpkT7BLR X2p+6+QkfZdgO9zVnkLQDFPQ7dWLtYDaIXgcGqGfB0HU3cM2rrI8p8pzv qNhPixxhQL2LAlZ40GxRDRIT/BY41rs4rSXWkVQjfhBWDZoPUq1uERgxO bDPOlAJ7i1XsGlk3SFFqdY6ieDN+PXhlDrYCz9UUD056oJ0/KjCIYyHb+ Sj+TXrnW9BL0IE2iFeJBqoMQcuOM/2dmfa0JsVZbPuozRyczq89o8YElB g==; IronPort-SDR: AjznDtyTCMfTD+LjD8ZpyeKRkwSJBQS//2NPJiFSj/7uHyH9AbjOMBqCWdlmqqxCFoJ34Vxrf8 DB5zrWcU/GD16xG6ERSPvYSAzlKESJ6qbZ4CVFESZ2O8HSbnAu7vZo30BdSpTtRTHtFMAccCWg fJA+DMv4ayr/jyXb2Kw/97+FNG1KJx9cju7HljfGtSz2R7rq3QJz8IV2TwySyV/+/sJqPiDrTu HdPcrqobJKyfQSkTf1tFYNOvXEGSg3nXzen5xi4v2KlZ+OuQms9pQikL/3NmLFe4wutCIqZE7r T7g= X-IronPort-AV: E=Sophos;i="5.72,354,1580770800"; d="scan'208";a="11729932" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 07 Apr 2020 15:00:45 +0200 Received: from schifferm-ubuntu4.tq-net.de (schifferm-ubuntu4.tq-net.de [10.117.49.26]) by vtuxmail01.tq-net.de (Postfix) with ESMTPA id B6ED8280065; Tue, 7 Apr 2020 15:00:58 +0200 (CEST) Message-ID: <189a1fb7f7aee153151f46fe3bb0f754160472e7.camel@ew.tq-group.com> Subject: Re: (EXT) Re: (EXT) Re: [PATCH 1/4] pwm: pca9685: remove unused duty_cycle struct element From: Matthias Schiffer To: Thierry Reding Cc: Clemens Gruber , Uwe =?ISO-8859-1?Q?Kleine-K=F6nig?= , linux-pwm@vger.kernel.org, Linux Kernel Mailing List , Andy Shevchenko , Sven Van Asbroeck Date: Tue, 07 Apr 2020 15:00:43 +0200 In-Reply-To: <20200406095124.GA475759@ulmo> References: <20200226135229.24929-1-matthias.schiffer@ew.tq-group.com> <20200226151034.7i3h5blmrwre2yzg@pengutronix.de> <32ec35c2b3da119dd2c7bc09742796a0d8a9607e.camel@ew.tq-group.com> <20200330151231.GA1650@workstation.tuxnet> <20200404173546.GA55833@workstation.tuxnet> <20200406095124.GA475759@ulmo> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2020-04-06 at 11:51 +0200, Thierry Reding wrote: > > On Sat, Apr 04, 2020 at 04:17:00PM -0400, Sven Van Asbroeck wrote: > > > > It does look like we have a square peg (this chip) in a round hole > > (the > > standard assumptions the pwm core makes) ? > > There are other chips where a single period is shared across multiple > PWM channels. Typically what we do there is once a period is > configured > for a given channel, all subsequent PWM channel configurations must > use > the same period, or otherwise the driver will return an error code. > > See for example: > > - stm32_pwm_config() in drivers/pwm/pwm-stm32.c > - lpc18xx_pwm_config() in drivers/pwm/pwm-lpc18xx-sct.c > - pwm_imx_tpm_apply_hw() in drivers/pwm/pwm-imx-tpm.c > - fsl_pwm_apply_config() in drivers/pwm/pwm-fsl-ftm.c > > The rationale behind that is that we must not change a PWM > configuration > without a consumer having explicitly requested it. These implementations don't deal with the issue in a consistent way either though: 1) stm32_pwm_config() only checks for channels that are actually enabled, regardless if they're requested 2) lpc18xx_pwm_config() checks requested channels instead "2)" seems more correct to me, as the parameters of a requested channel can't be changed by another user, but it seems to prevent certain sequences. I don't have a good grasp of the the usual PWM request control flow - is it correct that the PWM state is not updated with the PWM args from OF when the PWM is requested? I only see pwm_adjust_config() doing something like that, which is not used in many places (and nothing preventing races) - but I might be overlooking something. Meaning, is it possible that two drivers request PWMs from the same pwmchip of type "2)" (or even a single driver using two PWMs) without configuring them right away may get into a situation where neither can set up a period at all even when all users want to use the same period? Matthias