Received: by 2002:ab2:7855:0:b0:1f9:5764:f03e with SMTP id m21csp240286lqp; Wed, 22 May 2024 03:13:56 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVOQlcKIogs3wFVJm+Sg7GXOscdOOWKocPEoJLIIDxW8ztm/qfiNMMxcJ+aHFvDiq73Owc5KREcQXdjnOy/7eu7B5S6v5jZMNWrZhZ03g== X-Google-Smtp-Source: AGHT+IH9TBp+MFyR71zZl0Jt0+9lH3D2ycER4qJ2vdnLlPvE0pLTLTUTk4PhPs8DfQKXikrs+GSe X-Received: by 2002:a05:6122:3c53:b0:4d8:74a2:6d35 with SMTP id 71dfb90a1353d-4e2185295acmr1315013e0c.9.1716372835952; Wed, 22 May 2024 03:13:55 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716372835; cv=pass; d=google.com; s=arc-20160816; b=kJq9O70GJxA0QGGw9xm9/hBN1y4PMwiOa8N548I+9cLGCJk+1xSUBU0NPMnyBxMkpV ZPjw1IOUGVQcNVxoLfPwclz0/nxnz0p16gTBn5HKvRfUsVLIY0oVRhx9yu2aPMTSapZJ JbyQjZ2+bCkaLADkiBv+iTZWmYov4gk7tDgkJq4k0NTIxF11hBXdi2o+22gGwN/rO/hD WtbAim7WF3hu/36Dv/tzJfkmmpbEGstZ+7pgsAC5YXGyMcGet/jcl9qdy77qVUNDkIng fhmErMV1Lzr1nZZBoE3nYRVsEu8fBAasDEE1uCn0RbAntkBrIny3Z6NwwEM8nN4GKqPp FnaQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=DO6l2sbQprUl00LHpYzwU6fg66m6jPsOyLLlIRt9QQs=; fh=FdzpXZA+IbDiQAhNgUzNezj/pt55AuZWwm6upGqQLrI=; b=CRmYo0tziUE9kamsdg28houA+tDvpI3MHEcyKHn7Vx094Dnk9HpEYMjGQoI125wXt1 1OT23pL5Ebc4oc0qzJk0hrVcybFVpU/bUu/JrampDoETR/nhdAX56IqpZCDkOUn0wK7s odemaB3ycHQtm0ZvI34uC/PKf3KKY/B5fe1l32klUIXtMb6hn2zufWrOceEcavA1AnQ7 3JlYE32uU1De4WQlMienEwASq+RmMyA/Es2DoES6Z3utRjyBLL8Pze3qxUkAc9GGjKCt +1+TjGu6Y83nOJlU5fZw2wFHf9ReheYMmvmzc5nn+UrvzUy9zJaLvdueGi3W/LpZjLqX X/lw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=LMGMBDev; arc=pass (i=1 spf=pass spfdomain=ideasonboard.com dkim=pass dkdomain=ideasonboard.com); spf=pass (google.com: domain of linux-kernel+bounces-186041-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-186041-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id af79cd13be357-792bf33b39dsi451225385a.465.2024.05.22.03.13.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 03:13:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-186041-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=LMGMBDev; arc=pass (i=1 spf=pass spfdomain=ideasonboard.com dkim=pass dkdomain=ideasonboard.com); spf=pass (google.com: domain of linux-kernel+bounces-186041-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-186041-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 9B0CA1C2187A for ; Wed, 22 May 2024 10:13:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C92CF81ADB; Wed, 22 May 2024 10:13:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="LMGMBDev" Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C11E81AA7; Wed, 22 May 2024 10:13:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716372827; cv=none; b=gpkUWP4WLxxkc/i0t7QI//LBKu9/3k0MMhsS07l8GLK05u4EowhHWxy7I5DO6h3nuCy+1GYoPyCmf2kEmJOVkOdFPRqnLIv3y8zdA04U1C4ivUA6qDhymdjwXZcZE+3T87ctvoZfIgMkmHBn8WL0H+PDpkQWQuFn+iSU+d4ED+8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716372827; c=relaxed/simple; bh=1mP4oCCZIocHPEfXo/hwjMohvwOhWaSus8BGK7ZMHLU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o3SFXNbHHKCwyBWGyyUJDkLy0w7tkYPsTyu63rPb+clQzFzCciegRP2aU+V1v3sKG1sxE3PPihKOluZubBmlbRpIRJXLpUY9w7IwnAz+ttPW1S0Up1O2pc7CrEhtxF0bk8pHA4FMSBNVskpashn8mxwk98bIidY8Rtb0E5FuPwM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=LMGMBDev; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi [81.175.209.231]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 70FBAFD6; Wed, 22 May 2024 12:13:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1716372811; bh=1mP4oCCZIocHPEfXo/hwjMohvwOhWaSus8BGK7ZMHLU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LMGMBDev4PAjWhtqVUMjdqFbaSJpAqgilatWhqlbIIY/WUBls4LzhOAnmggVXpziL 8UROPQlZp2DW/GLFYwUAexLeOH/DpKJIpDOFG9wljMtXYZ6ZCAsKZF9e6ybbodcRE2 L5OS7yQRtXmrygLrnKrPZYGUxubH0r6jBtyTlaUc= Date: Wed, 22 May 2024 13:13:35 +0300 From: Laurent Pinchart To: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, linux-pwm@vger.kernel.org, Bartosz Golaszewski , Conor Dooley , Krzysztof Kozlowski , Lee Jones , Linus Walleij , Rob Herring , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Clark Wang Subject: Re: [PATCH 5/5] pwm: adp5585: Add Analog Devices ADP5585 support Message-ID: <20240522101335.GE1935@pendragon.ideasonboard.com> References: <20240520195942.11582-1-laurent.pinchart@ideasonboard.com> <20240520195942.11582-6-laurent.pinchart@ideasonboard.com> <20240521100922.GF16345@pendragon.ideasonboard.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, May 21, 2024 at 03:05:53PM +0200, Uwe Kleine-König wrote: > Hello, > > [dropping Alexandru Ardelean from Cc as their address bounces] > > On Tue, May 21, 2024 at 01:09:22PM +0300, Laurent Pinchart wrote: > > On Tue, May 21, 2024 at 10:51:26AM +0200, Uwe Kleine-König wrote: > > > On Mon, May 20, 2024 at 10:59:41PM +0300, Laurent Pinchart wrote: > > > > + ret = regmap_update_bits(adp5585_pwm->regmap, ADP5585_GENERAL_CFG, > > > > + ADP5585_OSC_EN, ADP5585_OSC_EN); > > > > + if (ret) > > > > + return ret; > > > > + > > > > + return 0; > > > > > > The last four lines are equivalent to > > > > > > return ret; > > > > I prefer the existing code but can also change it. > > Well, I see the upside of your approach. If this was my only concern I > wouldn't refuse to apply the patch. While I have my preferences, I also favour consistency, so I'm happy to comply with the preferred coding style for the subsystem :-) I'll update this in the next version. > > > > + regmap_update_bits(adp5585_pwm->regmap, ADP5585_GENERAL_CFG, > > > > + ADP5585_OSC_EN, 0); > > > > +} > > > > + > > > > +static int pwm_adp5585_apply(struct pwm_chip *chip, > > > > + struct pwm_device *pwm, > > > > + const struct pwm_state *state) > > > > +{ > > > > + struct adp5585_pwm_chip *adp5585_pwm = to_adp5585_pwm_chip(chip); > > > > + u32 on, off; > > > > + int ret; > > > > + > > > > + if (!state->enabled) { > > > > + guard(mutex)(&adp5585_pwm->lock); > > > > + > > > > + return regmap_update_bits(adp5585_pwm->regmap, ADP5585_PWM_CFG, > > > > + ADP5585_PWM_EN, 0); > > > > + } > > > > + > > > > + if (state->period < ADP5585_PWM_MIN_PERIOD_NS || > > > > + state->period > ADP5585_PWM_MAX_PERIOD_NS) > > > > + return -EINVAL; > > > > > > Make this: > > > > > > if (state->period < ADP5585_PWM_MIN_PERIOD_NS) > > > return -EINVAL; > > > > > > period = min(ADP5585_PWM_MAX_PERIOD_NS, state->period) > > > duty_cycle = min(period, state->period); > > > > I haven't been able to find documentation about the expected behaviour. > > What's the rationale for returning an error if the period is too low, > > but silently clamping it if it's too high ? > > Well, it's only implicitly documented in the implementation of > PWM_DEBUG. The reasoning is a combination of the following thoughts: > > - Requiring exact matches is hard to work with, so some deviation > between request and configured value should be allowed. > - Rounding in both directions has strange and surprising effects. The > corner cases (for all affected parties (=consumer, lowlevel driver > and pwm core)) are easier if you only round in one direction. > One ugly corner case in your suggested patch is: > ADP5585_PWM_MAX_PERIOD_NS corresponds to 0xffff clock ticks. > If the consumer requests period=64000.2 clock ticks, you configure > for 64000. If the consumer requests period=65535.2 clock ticks you > return -EINVAL. > Another strange corner case is: Consider a hardware that can > implement the following periods 499.7 ns, 500.2 ns, 500.3 ns and then > only values >502 ns. > If you configure for 501 ns, you'd get 500.3 ns. get_state() would > tell you it's running at 500 ns. If you then configure 500 ns you > won't get 500.3 ns any more. > - If you want to allow 66535.2 clock ticks (and return 65535), what > should be the maximal value that should yield 65535? Each cut-off > value is arbitrary, so using \infty looks reasonable (to me at > least). > - Rounding down is easier than rounding up, because that's what C's / > does. (Well, this is admittedly a bit arbitrary, because if you round > down in .apply() you have to round up in .get_state().) Thank you for the detailed explanation. > > > round-closest is wrong. Testing with PWM_DEBUG should point that out. > > > The right algorithm is: > > > > > > on = duty_cycle / (NSEC_PER_SEC / ADP5585_PWM_OSC_FREQ_HZ) > > > off = period / (NSEC_PER_SEC / ADP5585_PWM_OSC_FREQ_HZ) - on > > > > > > > > > > + if (state->polarity == PWM_POLARITY_INVERSED) > > > > + swap(on, off); > > > > > > Uhh, no. Either you can do inverted polarity or you cannot. Don't claim > > > you can. > > > > OK, but what's the rationale ? This is also an area where I couldn't > > find documentation. > > I don't have a good rationale here. IMHO this inverted polarity stuff is > only a convenience for consumers because the start of the period isn't > visible from the output wave form (apart from (maybe) the moment where > you change the configuration) and so > > .period = 5000, duty_cycle = 1000, polarity = PWM_POLARITY_NORMAL > > isn't distinguishable from > > .period = 5000, duty_cycle = 4000, polarity = PWM_POLARITY_INVERSED > > . But it's a historic assumption of the pwm core that there is a > relevant difference between the two polarities and I want at least a > consistent behaviour among the lowlevel drivers. BTW, this convenience > is the reason I'm not yet clear how I want to implemement a duty_offset. Consistency is certainly good. Inverting the duty cycle to implement inverted polarity would belong in the PWM core if we wanted to implement it in software I suppose. I'll drop it from the driver. > > > > + ret = devm_pwmchip_add(&pdev->dev, &adp5585_pwm->chip); > > > > + if (ret) { > > > > + mutex_destroy(&adp5585_pwm->lock); > > > > + return dev_err_probe(&pdev->dev, ret, "failed to add PWM chip\n"); > > > > + } > > > > + > > > > + return 0; > > > > +} > > > > + > > > > +static void adp5585_pwm_remove(struct platform_device *pdev) > > > > +{ > > > > + struct adp5585_pwm_chip *adp5585_pwm = platform_get_drvdata(pdev); > > > > + > > > > + mutex_destroy(&adp5585_pwm->lock); > > > > > > Huh, this is a bad idea. The mutex is gone while the pwmchip is still > > > registered. AFAIK calling mutex_destroy() is optional, and > > > adp5585_pwm_remove() can just be dropped. Ditto in the error paths of > > > .probe(). > > > > mutex_destroy() is a no-op when !CONFIG_DEBUG_MUTEXES. When the config > > option is selected, it gets more useful. I would prefer moving away from > > the devm_* registration, and unregister the pwm_chip in .remove() > > manually, before destroying the mutex. > > In that case I'd prefer a devm_mutex_init()?! Maybe that would be useful :-) Let's see if I can drop the mutex though. -- Regards, Laurent Pinchart