From patchwork Wed Dec 21 11:29:11 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Conor Dooley X-Patchwork-Id: 13078675 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 93098C10F1B for ; Wed, 21 Dec 2022 11:31:36 +0000 (UTC) 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:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=H7qtaFb8Xatn13rKRpYCxBcYuAZCTc7Rm4Gj4VSFmsw=; b=ewHSLsidK84zvA rlujTz9n/XqsHTuF3BlvrLK0PDfTuqi3dL2GLfdyR1W/rk90I5g7PZNdacjwfrhc+FENFkq3sJa3c n3ByuzsYHb8uMFienW20t+OB0HNvabL0WxQo9qqPztqcsSOA8aHfYvVDWk2GafITTVrheufdGzfB/ 9DzOtJncvQNtV4h/erwI8zzZTR1QaICryq+mFQQgZBcRLQ7r1Dt1d+3+h+WKQ/Pdia0IuwwiLHx+a lGIRUPjIMm20S6cIG9YC3bWoZJL+WGx5v66G1rrZcUDXm29HUA5YbVY1Q1UQfkvPy5jFc4ngd3C2p 9Ni6CS5kZDYx9XH8z67Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p7xJm-00EDRe-U9; Wed, 21 Dec 2022 11:31:26 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p7xIA-00ECin-0o for linux-riscv@lists.infradead.org; Wed, 21 Dec 2022 11:29:48 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 1A240CE17E1; Wed, 21 Dec 2022 11:29:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B94F1C433D2; Wed, 21 Dec 2022 11:29:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671622174; bh=443F1rXQ30ch6Cy/GlKbcogz3u7FhMGEWGxIcKOK4t4=; h=From:To:Cc:Subject:Date:From; b=RMQAbseOtZa8WnF7g64duHVqiPvpaz4vk/HCxQcnoF99qtJFZqXyXpMtBDogLXsEU A5vrCM2HHH1xjU8p5tLDtA5Yx9Yuuf93425ODKcveJ7OcnVykYZKSJ4bgvbj/5mUGj f3DUUSl4byj9snhlTAQON39F6d4/3Y4ONkYzvl2PuPz9YJHa0xBIlCoXJpc1MKMHhd 6fZIsO41hp/swRnbefRDICf9m390vn0a5QZcC5IBg/7ahN3/jSjCYL17W+uFMhdunD NVW4+T7mzsbk1DTLXMeRHCYYDiX72OszCzzzYgXAqwiJTIVuOs3UlRWPzbsj1GX2W6 FfYlksOyDMgqA== From: Conor Dooley To: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= , Thierry Reding , Conor Dooley Cc: Daire McNamara , linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, linux-riscv@lists.infradead.org Subject: [PATCH v13 0/2] Microchip Soft IP corePWM driver Date: Wed, 21 Dec 2022 11:29:11 +0000 Message-Id: <20221221112912.147210-1-conor@kernel.org> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221221_032946_449591_55D9EB59 X-CRM114-Status: GOOD ( 30.74 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org From: Conor Dooley Hey, v13 is rebased on top of Uwe's series converting get_state() to return int instead of void. Given other changes here, it turns out that I do not need it at all unfortunately! I was wrong about the behaviour of the sync-update bit: It /does not/ get cleared at the start of a new period. I did actually modify the driver to do a read_poll_timeout() on that bit which seemed to work [0], but it turns out that that bit holds it's value until the IP block is reset. I'm really not sure how it worked when I tested the other week... I initially implemented a wait with timers and a timeout - but Uwe suggested dropping the timeouts entirely & instead going back to waiting. The driver now waits in apply() & get_state() for a update to have been applied to the waveform before allowing further modification. Doing so is required as the applied state doesn't appear in the registers until it has appeared at the output. I yoinked the msleep/udelay stuff from the sun4i that you mentioned & modified it a little as the cost of waiting has been placed on subsequent calls. Other than that, v13 has some minor bits of cleanup that Uwe suggested in mchp_core_pwm_apply_locked(). Thanks, Conor. 0 - https://lore.kernel.org/linux-riscv/Y3uZY5mt%2FZIWk3sS@wendy/ Changes since v13: - couple bits of cleanup to apply_locked(), suggested by Uwe: getting rid of a variable & using unsigned long for another. - move the overhead waiting for a change to be applied, for channels with shadow registers, to subsequent calls to apply(). This has the benefit of only waiting when two calls to apply() are close in time rather than eating the delay in every call. Changes since v11: - swap a "bare" multiply & divide for the corresponding helper to prevent overflow - factor out duplicate clk rate acquisition & period calculation - make the period calculation return void by checking the validity of the clock rate in the caller - drop the binding & dt patch, they're on-track for v6.2 via my tree Changes since v10: - reword some comments - try to assign the period if a disable is requested - drop a cast around a u8 -> u16 conversion - fix a check on period_steps that should be on the hw_ variant - split up the period calculation in get_state() to fix the result on 32 bit - add a rate variable in get_state() to only call get_rate() once - redo the locking as suggested to make it more straightforward. - stop checking for enablement in get_state() that was working around intended behaviour of the sysfs interface Changes since v9: - fixed the missing unlock that Dan reported Changes since v8: - fixed a(nother) raw 64 bit division (& built it for riscv32!) - added a check to make sure we don't try to sleep for 0 us Changes since v7: - rebased on 6.0-rc1 - reworded comments you highlighted in v7 - fixed the overkill sleeping - removed the unused variables in calc_duty - added some extra comments to explain behaviours you questioned in v7 - make the mutexes un-interruptible - fixed added the 1s you suggested for the if(period_locked) logic - added setup of the channel_enabled shadowing - fixed the period reporting for the negedge == posedge case in get_state() I had to add the enabled check, as otherwise it broke setting the period for the first time out of reset. - added a test for invalid PERIOD_STEPS values, in which case we abort if we cannot fix the period Changes from v6: - Dropped an unused variable that I'd missed - Actually check the return values of the mutex lock()s - Re-rebased on -next for the MAINTAINERS patch (again...) Changes from v5: - switched to a mutex b/c we must sleep with the lock taken - simplified the locking in apply() and added locking to get_state() - reworked apply() as requested - removed the loop in the period calculation (thanks Uwe!) - add a copy of the enable registers in the driver to save on reads. - remove the second (useless) write to sync_update - added some missing rounding in get_state() - couple other minor cleanups as requested in: https://lore.kernel.org/linux-riscv/20220709160206.cw5luo7kxdshoiua@pengutronix.de/ Changes from v4: - dropped some accidentally added files Changes before v4: https://lore.kernel.org/linux-pwm/20220721172109.941900-1-mail@conchuod.ie Conor Dooley (2): pwm: add microchip soft ip corePWM driver MAINTAINERS: add pwm to PolarFire SoC entry MAINTAINERS | 1 + drivers/pwm/Kconfig | 10 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-microchip-core.c | 436 +++++++++++++++++++++++++++++++ 4 files changed, 448 insertions(+) create mode 100644 drivers/pwm/pwm-microchip-core.c