Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp512890ybb; Fri, 3 Apr 2020 07:05:40 -0700 (PDT) X-Google-Smtp-Source: APiQypJPtati395tNeY2JescUoeGMj+UhNJa6YOezr4W2zqQFuxEsS0KhkYUTCrm9zFtzHooQ6Y3 X-Received: by 2002:a9d:69ca:: with SMTP id v10mr6210058oto.64.1585922740114; Fri, 03 Apr 2020 07:05:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585922740; cv=none; d=google.com; s=arc-20160816; b=OMzEJU74Jl42/F27cnUAObk/wYhCzaZLeolcU3r/iLpZP+unV4H3iT4p3JCm6J/oG9 r3LaUR82GjRTIcpNl8vuZIlBTnOtf6MF6Xd4EZsiFqCx2ybnAj3zYED+qBBLxB9fBwMP erlTkTpQ9x8KoJHP8336XFHIyEjEhP0yivGiy7N0N1kQPSgFviXCjHfU9Lawh74Avrtd WdT9UL+aZyc4P2YwMU76goiTzThXwrmfWlqb9/mcGscgX3wswZYMoX2craDTwn1rcmz8 C92saUikhEJ7f7AUjX4EKfnqXCkO90Z91VV5tOUJZ7POO/B9FIaHhCj7FYMsa0JOP+iC UUHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=nyN6iJ8tHcV6t1nK3yXXlZKZhh7wMlFZ/RelcWtfhQ4=; b=szvkwTQ6cXvAUXTr9/5OQQ1AAKHAdSY2a2kyruefx00c0/82kX8LNsTzTuvyPaUn89 0tAGLjobC0fqFDqJfbARsWY4MAFPDpbBhC7iUPytwSI0BKcPXsps+FUwuyGlOhI1biVE oy+IgSut1qFfF4TsJ/Z1JDrzr3VhqqKLBCwwUWQh2rTndSEQ1TBB7M5Ov8AXxglmThc5 6T3ABfEGb3OZtKpPPZmDQrrG9eBs0Q+KESXaxCcT+3WzZ+eMDwNZxDtm/gwar/HDjJp3 6u9WwqsBV1Rm4SOyWYZBk2i085c6uHRENIZjjGeHKy/wkoMKn59HKyojB9eg1GgY3E8P 2hJg== ARC-Authentication-Results: i=1; mx.google.com; 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 l6si4069981otn.219.2020.04.03.07.05.24; Fri, 03 Apr 2020 07:05:40 -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; 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 S2390988AbgDCN7o (ORCPT + 99 others); Fri, 3 Apr 2020 09:59:44 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:60539 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728213AbgDCN7o (ORCPT ); Fri, 3 Apr 2020 09:59:44 -0400 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jKMrE-0005V1-3h; Fri, 03 Apr 2020 15:59:40 +0200 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1jKMrD-000573-17; Fri, 03 Apr 2020 15:59:39 +0200 Date: Fri, 3 Apr 2020 15:59:38 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Lokesh Vutla Cc: Thierry Reding , Tony Lindgren , Linux OMAP Mailing List , linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, Sekhar Nori , Vignesh R , kernel@pengutronix.de Subject: Re: [PATCH v3 4/5] pwm: omap-dmtimer: Do not disable pwm before changing period/duty_cycle Message-ID: <20200403135938.qmrvhclm6evfibqj@pengutronix.de> References: <20200312064042.p7himm3odxjyzroi@pengutronix.de> <20200330141436.GG2431644@ulmo> <20200330191654.waoocllctanh5nk5@pengutronix.de> <20200331204559.GB2954599@ulmo> <20200401082227.sxtarbttsmmhs2of@pengutronix.de> <20200401182833.GB2978178@ulmo> <20200401203156.d7x5ynnnhob3jyoo@pengutronix.de> <20200401213738.GA3052587@ulmo> <20200402140221.bjbol77uegjma6oz@pengutronix.de> <5dbdbc15-ff29-f577-0632-6a28378b0104@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5dbdbc15-ff29-f577-0632-6a28378b0104@ti.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Fri, Apr 03, 2020 at 02:21:38PM +0530, Lokesh Vutla wrote: > On 02/04/20 7:32 PM, Uwe Kleine-K?nig wrote: > > Having said that I don't know how critical this really is. Given that > > the PWM under discussion doesn't complete periods on stop, it probably > > isn't. > > It is a limitation with the existing driver as well. Nothing is being changed > regarding stopping of PWM. The same is marked under the limitations in the driver. What I wrote was ambiguous and I think you understood the meaning I didn't intend. What I wanted to say is: Given that the PWM stops abruptly there is only little (if any at all) advantage of "stop-to-update" over "racy-atomic-update" as we see broken cycles no matter which alternative we pick. > > I spend some time thinking about when the glitch actually happens. > > Currently the load value is written first and then the match value. > > If no period ends between the two writes there is only a problem when in > > the currently running period the match event didn't happen yet. Then we > > see a cycle with > > > > .period = oldperiod + newperiod > > .dutycycle = oldperiod + newdutycycle > > > > (if the new match value isn't hit in the current cycle) or one with > > > > .period = oldperiod > > .duty_cycle = newdutycycle + (oldperiod - newperiod) > > > > (if the new match value is hit in the current cycle). The probability > > that one of the two happen is: olddutycycle / oldperiod which is quite > > probable. (With olddutycycle = oldperiod there is no problem though.) > > > > If after writing the new load value and before writing the new match > > value a period ends it might happen that we see a cycle with > > > > .period = newperiod > > .dutycycle = olddutycycle + (newperiod - oldperiod) > > > > (if the previous match value is used) or one with > > > > .period = 2 * newperiod > > .dutycycle = newperiod + newdutycycle > > > > (if new match value is written too late for the first cycle with the new > > period). > > That's exactly why we have marked in the Limitations sections that the current > period might produce a cycle with mixed settings. Frankly, I'm a bit torn here. > There are other PWMs inside Linux with similar limitations and documented > similarly. If there is an overall objection for such hardware, the entire policy > should be changed or the framework should be updated to allow user to choose for > dynamic updates. IMHO, this series should not be blocked for this decision. Yes, there are other drivers that have similar "problems" and the status quo is that depending on the driver author one or the other workaround is chosen. I think the PWM framework would benefit if there were a common guideline which path to choose in such a situation. > Please consider it for the coming merge window. It's already in next, so I assume it will be merged. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | https://www.pengutronix.de/ |