Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2769209pxu; Mon, 7 Dec 2020 15:29:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJxF94xDYzqQKcO+di5DkPajIFCrVBdQ1lztj0QrExff6Yuhrs0dPIM3n7tSRVSoMrEF0ngo X-Received: by 2002:a17:906:d0c2:: with SMTP id bq2mr15689557ejb.1.1607383774824; Mon, 07 Dec 2020 15:29:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607383774; cv=none; d=google.com; s=arc-20160816; b=UUXSkgz8oBRyawtB188l5DBdq5QO4QrPLfRkPNZi5jShshwmJmVQ40s6t3u9QLiPD7 3zsT/i+6533eALcKR6pb9iD30TaIXddp3OV5P38TvpySgtSmM4O766JgVBml79IDnwmH lomrCQPH+7mK59UCBgvv+eEvkxJKTpmxH6KV+AlpCIYuMPKg0mduxMfsiJMdeAtGHK0/ EsMAXUqs+5bmfsFuuhIHfUN2/I775VXxLoooXWcvE3xqDAEHqS2x0ZSZPVqdFixhM+Xz 6qzsmIJF25FoSCCvs6Ihg1LrYBqEh1LHvyYkivtbAe+FQZQWV+VHnKDRBm/HqfFuUMJp MxjA== 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=Q/A+34G5azvLVAZzItgJc85p8GcJ5sBbiHPF0QxmJ30=; b=ZWygoIiCH2bKFEwQXuIFgZOxZQfwyl3Pcuw73pjR4aygZZnGSomoImfGRXm0w/GIrW uMAtK/Q2mdUgj4m1UkPo2DidUNzs5SPdmj+Yr0JocrvMMFY3k6iqf/D7kEMOsD+OBp6B vDFOfOHo5qiFt5pRoUt32hyK9FIMt1SdW6pFopc0UUsz7Wgkx0qn194ccxwA4/MzuiB/ IV2NbKn8PrKFmiot5J5Ofwbr7DIV2EUumqK/QpfqeXrSO551/hZ8igcs41zkDv5wufdV zWb+a0ziBvfBsLR3Ng0R4KZG6XuGi7MXJQajyyctxKtnQHgMYMWoGT4PzwnFuRpT0fnT LXEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pqgruber.com header.s=mail header.b="Spmsib/F"; 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=QUARANTINE 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 a15si3498503edm.287.2020.12.07.15.29.12; Mon, 07 Dec 2020 15:29:34 -0800 (PST) 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="Spmsib/F"; 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=QUARANTINE sp=NONE dis=NONE) header.from=pqgruber.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727044AbgLGXZT (ORCPT + 99 others); Mon, 7 Dec 2020 18:25:19 -0500 Received: from mail.pqgruber.com ([52.59.78.55]:37054 "EHLO mail.pqgruber.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725832AbgLGXZT (ORCPT ); Mon, 7 Dec 2020 18:25:19 -0500 Received: from workstation.tuxnet (213-47-165-233.cable.dynamic.surfer.at [213.47.165.233]) by mail.pqgruber.com (Postfix) with ESMTPSA id F1E15C89267; Tue, 8 Dec 2020 00:24:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqgruber.com; s=mail; t=1607383477; bh=Q/A+34G5azvLVAZzItgJc85p8GcJ5sBbiHPF0QxmJ30=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Spmsib/FDvuF4031BVT+j5DAbyWmFvh7w7gIafR1NUkkzYeOKQXfy8q7kw/MAgUFG 34Bfr1CQR6jBz4eLZQnVUYIqbV3c1M5TBU1iXEadt6eT+nWm37h3c4kY64qkAiegdI K+F2+i6QLg9fkkbgwB6RQstkiBiGDL1qw2YiP98o= Date: Tue, 8 Dec 2020 00:24:35 +0100 From: Clemens Gruber To: Sven Van Asbroeck Cc: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , linux-pwm@vger.kernel.org, Thierry Reding , Lee Jones , Linux Kernel Mailing List , Mika Westerberg , David Jander Subject: Re: [PATCH v4 1/4] pwm: pca9685: Switch to atomic API Message-ID: References: <20201207193629.493241-1-clemens.gruber@pqgruber.com> <20201207220025.42b6g76wq7ph5nvb@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 07, 2020 at 05:34:58PM -0500, Sven Van Asbroeck wrote: > Hi Uwe, > > On Mon, Dec 7, 2020 at 5:00 PM Uwe Kleine-K?nig > wrote: > > > > This is not acceptable, if you have two PWM outputs and a consumer > > modifies one of them the other must change. So if this chip only > > supports a single period length of all channels, the first consumer > > enabling a channel defines the period to be used. All later consumers > > must live with that. (Also the first must be denied modifying the period > > if a second consumer has enabled its PWM.) > > That makes sense. However, a possible wrinkle: when more than one pwm channel > is requested, which one is able to change the period? > > Example: > 1. start with all pwms free > 2. pwm_request(0), pwm_apply(period=200Hz) > 3. pwm_request(1) > 4. pwm_apply(1, period=400Hz) fails? > 5. pwm_apply(0, period=400Hz) succeeds? > > And if (5) succeeds, then pwm_get_state(1) will still return period=200Hz, > because the pwm core doesn't realize anything has changed. Are you ok > with this behaviour? I think we'd have to deny the pwm_apply in step 5 as well. So, only the first consumer is allowed to change the period and only as long as it is the only one that is in use / was requested. But that's definitely a breaking change. Thanks, Clemens