Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1857103ybh; Fri, 13 Mar 2020 08:35:30 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsqN8SUPReX2KnZcLFFLz3CxYSGuoyy+ikrnhS6F24G43HWEoQd8GXkJlBSJgujz4hOg+Bj X-Received: by 2002:aca:4843:: with SMTP id v64mr7229573oia.13.1584113730366; Fri, 13 Mar 2020 08:35:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584113730; cv=none; d=google.com; s=arc-20160816; b=ICCS6UNXQ8Fv0DzVIYH+iomdE5Z638BSpWmRUDAAHMxZxNoFB6uFrnR7qCaaJpdYPj BVxm9G5l10rZQqz5ur2X0v9AxBk/Ej0OYH41xQVfPP7McoeE3+pZVljnc52BwPXoFoCf KM9IzpZOohkFB79xFQgKIvXuDMswSImBRgRvxbu4HxBfZ6XQ/PVcWCvwLU/1rPETaH3i Y33MtLkoS9CfCfebHP7DWQ/4fl+2h3DZcQI7Q7xN8nZYhrgpD1BK6BYqg4g0392+UR8f tPp4BzeDhGR63ukIMO8vmB8XfrOeHYFimaIdaIVk7nn7a6MfomYJ/o6U0haUrWADupR4 3l/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Ohq7ObtwtnshU0y0v38q5MPivi5OvLGIJuVak0eZWHs=; b=IHnttsBmPjf5z7aqCVEGcbQs87oaNM6JvC9CDK+mEMOv3atEmTXafFNs1mUaWvEu76 88uhpCZYbuf85vgt6B9YAHCpxPZM6B2D0WAmdA63D+fQ4oOqo7THSW6tEC1p37q2s1o7 XiZCvlyBOdaU/gKkI2Z1LShzOwpgPgmBAPU4tiWZTD1593hkezB8mMcq1lpJnnCN3ln1 chBkW5Ia6cdRTegm980EjYxXQOnugknNYN6iElJjniv45aWkyEfZ2VB+ljfwR6e8tmIg Z61WdoZVpReE97FFUaENT7ByeEphn7FVngkN5QTU8RaEFs43q2cbpriwNWOkoqBgozV1 dOng== 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 e11si1331290oib.152.2020.03.13.08.35.16; Fri, 13 Mar 2020 08:35:30 -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 S1726874AbgCMPey (ORCPT + 99 others); Fri, 13 Mar 2020 11:34:54 -0400 Received: from muru.com ([72.249.23.125]:60066 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726664AbgCMPex (ORCPT ); Fri, 13 Mar 2020 11:34:53 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 06E3C8087; Fri, 13 Mar 2020 15:35:38 +0000 (UTC) Date: Fri, 13 Mar 2020 08:34:49 -0700 From: Tony Lindgren To: Lokesh Vutla Cc: Thierry Reding , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Linux OMAP Mailing List , linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, Sekhar Nori , Vignesh R , Sebastian Reichel Subject: Re: [PATCH v2 4/6] pwm: omap-dmtimer: Fix pwm disabling sequence Message-ID: <20200313153449.GD37466@atomide.com> References: <20200228095651.32464-1-lokeshvutla@ti.com> <20200228095651.32464-5-lokeshvutla@ti.com> <20200306181443.GJ37466@atomide.com> <9129d4fe-a17e-2fa6-764c-6a746fa5096d@ti.com> <20200309180123.GP37466@atomide.com> <666dbb7a-db98-d16a-ee73-27d353d2a317@ti.com> <20200310155242.GT37466@atomide.com> <296e28b7-7925-5dfa-ce5a-c0b2a2f1c2e0@ti.com> <20200312005849.GY37466@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200312005849.GY37466@atomide.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Tony Lindgren [200312 00:59]: > * Lokesh Vutla [200311 04:14]: > > However, I see an issue with the patch itself as pm_runtime is not disabled > > after the pwm is stopped. Not sure how that could be nullified with this approach. > > Hmm yeah not sure what could be used to clear things > when the current cycle is completed unless there's > some interrupt for it. You could enable pm_runtime_use_autosuspend() for pwm use, then set the timeout to the cycle length, then in the runtime_suspend make sure the enable bit is cleared if requested. But this too seems inaccurate, it would be best to clear the enable bit on some cycle completion interrupt if such thing is available. Regards, Tony