From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 567A2C47080 for ; Mon, 31 May 2021 19:09:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1F34F61005 for ; Mon, 31 May 2021 19:09:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F34F61005 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=pascalroeleven.nl Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To: Subject:Cc:To:From:Date:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5OBVT8cxmR1WK9IedrUd2XunZB6mT9lZsckYfFexkmE=; b=r2JL7VbNetaX6a /rfEnnO+RbjXkV0zgJ/S0RovXoOy1odMXFLpH+2QUhTxvWDwphY6FOV2Fdfi/1NIdsZb4AKvtM678 d32NWkY1ntDjRZCHoXGE2PTnfNcm1hxS9VHVs577DIU7NUUd692nUB5biMpCqBJxy4T+LwIcyS9ek Ed/X6u4pxkuX3a9RkzBt6Jut7/sTaCowo7PXHX0JpE8BboPonpGoGdWcFiZ7EP2OqvaELKjzSGLHK Sr+KoZEClufE55WPL7jsxY9ACmoqDNcy6lQb+vuHW+gGCDnwsJ/MEN7Gp/KTOZ0sgczptpc3GGQd2 VhK0rKvfEsCWdhbMTSGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lnnGt-00DB2L-W8; Mon, 31 May 2021 19:08:20 +0000 Received: from pmg02-out3.zxcs.nl ([2a06:2ec0:1:b::ffea]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lnnGi-00DB0c-HV for linux-arm-kernel@lists.infradead.org; Mon, 31 May 2021 19:08:10 +0000 Received: from pmg02.zxcs.nl (localhost.localdomain [127.0.0.1]) by pmg02.zxcs.nl (ZXCS) with ESMTP id A0ABA82CD6 for ; Mon, 31 May 2021 21:08:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=pascalroeleven.nl; s=x; h=Content-Transfer-Encoding:Content-Type:Message-ID :References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LD6UHQO51Dg3HgJ9uiOrHpVNhVTobRPfvJr+H5j46UU=; b=FlabRISFHdUqKMnGbTHrMRUfM9 fkaMQ4yX3pEY61AdyZqfJCYNW+h87v54/uor0wX/sLxZTLqwgHq2uLIhJxnF1nI55NuUtH0HsORmu wEbNuYiy52w6OTT6SYBdOEaKkqJzsuAJQJZMHS/OgEp8u/ndjH+yMvh3QUxXw6zD6LTS6z2szD1sR 7Hh6YEbSoRQ7plZsX4O4/jlgly6E5xJEtaikUfyh6TgKEpOsCpwpYlzZ5xxCqQTcYzOxXbeYOiArd FDAndpzMFBBz+5NBYSQprP3JWN2OjolNCYFVOsDmMLeDrBGernxDuBUAxVUCGOwi91iNUm2NLz9sD BGfw7psA==; MIME-Version: 1.0 Date: Mon, 31 May 2021 21:07:54 +0200 From: Pascal Roeleven To: Roman Beranek Cc: =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Thierry Reding , Emil Lenngren , Lee Jones , Maxime Ripard , Chen-Yu Tsai , linux-pwm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-sunxi@googlegroups.com Subject: Re: [PATCH 0/6] pwm: sun4i: only wait 2 cycles prior to disabling In-Reply-To: <20210531044608.1006024-1-roman.beranek@prusa3d.com> References: <20210531044608.1006024-1-roman.beranek@prusa3d.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: dev@pascalroeleven.nl X-Forwarded-For: linux-arm-kernel@lists.infradead.org X-AuthUser: dev@pascalroeleven.nl X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210531_120808_734338_470A9109 X-CRM114-Status: GOOD ( 19.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-05-31 06:46, Roman Beranek wrote: > As Emil Lenngren has previously shown [1], actually only 1-2 cycles of > the prescaler-divided clock are necessary to pass before the PWM turns > off, not a full period. > > To avoid having the PWM re-enabled from another thread while asleep, > ctrl_lock spinlock was converted to a mutex so that it can be released > only after the clock gate has finally been turned on. > > [1] https://linux-sunxi.org/PWM_Controller_Register_Guide > > Roman Beranek (6): > pwm: sun4i: enable clk prior to getting its rate > pwm: sun4i: disable EN bit prior to the delay > pwm: sun4i: replace spinlock with a mutex > pwm: sun4i: simplify calculation of the delay time > pwm: sun4i: shorten the delay to 2 cycles > pwm: sun4i: don't delay if the PWM is already off > > drivers/pwm/pwm-sun4i.c | 56 +++++++++++++++++++---------------------- > 1 file changed, 26 insertions(+), 30 deletions(-) Hi Roman, Thanks for your attempt to fix this. Unfortunately on my A10 device (Topwise A721), the controller still gets stuck in an unrecoverable state after disabling and re-enabling the PWM when it was already on (set in U-Boot), or when enabling it when it was off. In this state, any changes to the period register (using devmem) don't seem to have any effect. It seems to be stuck in the state it was before disabling. The only thing which still works is enabling and disabling. I can't reproduce this behavior manually so I'm not sure what is causing this. Regarding the amount of cycles of sleep; Using a prescaler of 72000 the PWM clock is 3 ms. Although timing tests using devmem seem unreliable (too much overhead?), in U-Boot I need to 'sleep' for at least 7 ms between the commands to make sure the output doesn't sometimes get stuck in the enabled state. So in my case it seems to be at least 3 cycles. I am not sure how reliable this method is. However even if I can get it stuck in the enabled state using a shorter time, it doesn't cause the behavior I mentioned before. I was always able to recover it manually. Increasing the number of cycles to sleep therefore also doesn't solve my problem. Until we can solve that I cannot confirm nor deny if 2 cycles is enough. Regards, Pascal _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel