Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp3969473ybh; Tue, 17 Mar 2020 09:46:46 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvUlYKV0ZwOu2u0eW6rgh/wdawgjDk00YVhxavHxpwXwtFFeGtVO2cUV+ZhqxM8z0DG5xfz X-Received: by 2002:aca:eb4e:: with SMTP id j75mr228861oih.18.1584463606353; Tue, 17 Mar 2020 09:46:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584463606; cv=none; d=google.com; s=arc-20160816; b=lj/P6sgESFXTrgWvLgEIJAjp1jJ2kyNxPA8qFPiRE3vqzdkl9K1bIobKsqi1f3YcIV 5KQXOsuKRoc8Gk9Etf/I3iSXYrZ/qkYiWmSr3BDcMVt8EaYrIGufRJYI/SQo3tysGUtb MWUh6Clz1/otYE3lCugyy/2wTW3BvZAhWewPY7TR1jxMk0xZyFugFFuMF0kRc1feaIfy FpBN+5h+YQLmLGl7Xl+bVVt7iad6dYKsRAngRT69J8mvBMQ6o8Fg5UBC3zxSuh8MKec6 EPDIQ2n9Xt5dPFgx2iG8VvIaf9d0JtKCiCtALlUJhR3cDj0LiuhJxg8k/Mg1lGLXHEmY EzmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=5eJQW9u/oqLF6BZRfUiV1G5G6DviGGlWCr2b1498xxQ=; b=Dere5n4NOZnNz8NXA5P7/m9XHrdIu6MSN9ref+CKS8YaB2jyrxufpB0r5lsEmSh4C9 hAWr+lozF1uBYNwC5S4Z7dMEufjHohSYuTlRbRS8OLTMm8rW6xfhrk56P5dyk2qUmLZx KW9BwzkG2yeSGOFv9JaPHlOjSdLvHPPpIP08Ik1WzGp4ieS6l2d2g+PoRtyxisFd+K4j ehlIfflDlJqf0uPNMCmGtawUEJBEhZUj0hciZLJ3IdTZEmwgZN5RSxboP1o6pVB31gvL SZnUlAdn2RhVb4rwNZXx3yxzdnsiukd8I78Uwtyh51CFf198jGCoBehguoB0QD6DvYxt hrJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LMRx7nwW; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u137si1859636oie.160.2020.03.17.09.46.32; Tue, 17 Mar 2020 09:46:46 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=LMRx7nwW; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726757AbgCQQqM (ORCPT + 99 others); Tue, 17 Mar 2020 12:46:12 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:34917 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726016AbgCQQqM (ORCPT ); Tue, 17 Mar 2020 12:46:12 -0400 Received: by mail-ot1-f65.google.com with SMTP id k26so22422435otr.2; Tue, 17 Mar 2020 09:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5eJQW9u/oqLF6BZRfUiV1G5G6DviGGlWCr2b1498xxQ=; b=LMRx7nwWe7cMHMOWNUg05zRuPgY6DofzFHMhj1gQnEGael6LRUmB87NFm94a/wAfQX qykah79BwhO1P0ntFvhaKtyeXHgmlW5N/BGaWP5tIlIMKLhnE+3K5J8zhdQEUNxGgANf mXgbeSIOtdcNdJ2mSwcAt00z0uL/hD3bOfgu7xKu2E8K4MYFOKF5f/4rqd54WT8p+4JU Gzt//MblJ65rZBgIlXAHxF4Riy/dM6uPNIerdGo5NXG0RHt9RJHKUdWeTrkrfGrEMpeP U9ixsy97/bDAWsXfWP/01XRU5DVl8ZcLaF4BgdJ2y7RJ4bx/dRXjPBaFxBoG5mN/5vsB z+YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5eJQW9u/oqLF6BZRfUiV1G5G6DviGGlWCr2b1498xxQ=; b=RfpjAdih189gR1m9EytlEdi4rmNm3i6BvpNSS5Z8Fvl/NeACW0/hXfxFXRKYVb4VD5 A65CDR9/G+AjO1cBZb3I4ctwra+yTbTZNp7Ntt1c2y7J/yD6a5B/6LalZ2MuSjbpnMjl zIzmSm+6Gwjws3Ezj7XlrtCfBjlhgcO68ew+jrh60thGIzmu0Ps7FPBF2DrZu6HKOziv oWDcGJHyh0pfoh6f0QQwdpoUaMCd2cRqYaZKuQSQfr17803CI/Dj2b6LEEZE2Tz+mQ/4 mftaMMUF8hydG/a9mXPah6Mflz9h25NJSZ3KSuCcI4MGIrdLy4xmDeUUDsrwOnJgzHsV A3IA== X-Gm-Message-State: ANhLgQ35rZVu1xRGN0xqC6ylF1+GTpyYTqvW9gmbvWR1eleQaWl/zv73 stiXmaCYHnp52oo7dLN39HuXGleMW136HHG70A0= X-Received: by 2002:a9d:560b:: with SMTP id e11mr116304oti.226.1584463569050; Tue, 17 Mar 2020 09:46:09 -0700 (PDT) MIME-Version: 1.0 References: <20200317155906.31288-1-dev@pascalroeleven.nl> In-Reply-To: <20200317155906.31288-1-dev@pascalroeleven.nl> From: Emil Lenngren Date: Tue, 17 Mar 2020 17:45:58 +0100 Message-ID: Subject: Re: [RFC PATCH 0/4] pwm: sun4i: Properly turn pwm off and fix stuck output state To: Pascal Roeleven Cc: Thierry Reding , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Maxime Ripard , Chen-Yu Tsai , Philipp Zabel , linux-pwm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, LKML , linux-sunxi@googlegroups.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, Den tis 17 mars 2020 kl 17:00 skrev Pascal Roeleven : > > Hi all, > > For the last few days I've been debugging a lot to get pwm working again since > recent changes in 5.6-rc1 broke it for me. > > Testing shows the pwm controller crashes (or the output gets stuck) when the > period register is written when the channel is disabled while the clock gate is > still on. Usually after multiple writes, but one write can also lead to > unpredictable behaviour. Patch 3 and 4 fix this. > > Patch 2 contains a fix which wouldn't completely turn off the pwm if the > output is disabled. The clock gate needs to stay on for at least one more > period to ensure the output is properly disabled. This issue has been around > for a long time but has probably stayed unnoticed because if the duty_cycle is > also changed to 0, you can't tell the difference. > > Patch 1 removes some leftovers which aren't needed anymore. > > Obviously these patches work for my device, but I'd like to hear your opinion > if any of these changes make sense. After days, this one is a bit blurry for me. > > Thanks to Uwe for some help with debugging. > > Pascal. > > Pascal Roeleven (4): > pwm: sun4i: Remove redundant needs_delay > pwm: sun4i: Disable pwm before turning off clock gate > pwm: sun4i: Move delay to function > pwm: sun4i: Delay after writing the period > > drivers/pwm/pwm-sun4i.c | 53 ++++++++++++++++++++--------------------- > 1 file changed, 26 insertions(+), 27 deletions(-) > > -- > 2.20.1 > I also worked on sun4i-pwm some time ago, fixing a bunch of issues. One was that disabling the pwm sometimes didn't turn off the signal, because the gate and enable bit were modified in the same clock cycle. Another was that the current code used an unnecessary sleep of a whole period length (or more?) in case of an update to the period, which could be very time-consuming if it's a very long interval, like 2 seconds. Note that the behaviour is not unpredictable, if you know how it works ;) I fiddled around a long time with devmem2, an oscilloscope and the prescaler set to max to figure out how works internally. Please try my version I just posted at https://pastebin.com/GWrhWzPJ. It is based on this version from May 28, 2019: https://github.com/torvalds/linux/blob/f50a7f3d9225dd374455f28138f79ae3074a7a3d/drivers/pwm/pwm-sun4i.c. Sorry for not posting it inline, but GMail would break the formatting. It contains quite many comments about how it works internally. I also wrote a section at http://linux-sunxi.org/PWM_Controller, but it might be a bit old (two years), so please rather look at the code and the comments. /Emil