From mboxrd@z Thu Jan 1 00:00:00 1970 From: heiko@sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=) Date: Wed, 01 Jul 2015 23:57:57 +0200 Subject: [RFC PATCH 00/15] pwm: add support for atomic update In-Reply-To: <1435738921-25027-1-git-send-email-boris.brezillon@free-electrons.com> References: <1435738921-25027-1-git-send-email-boris.brezillon@free-electrons.com> Message-ID: <3250976.mr9RMtjrdC@diego> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Boris, Am Mittwoch, 1. Juli 2015, 10:21:46 schrieb Boris Brezillon: > Hello Thierry, > > This series adds support for atomic PWM update, or ITO, the capability > to update all the parameters of a PWM device (enabled/disabled, period, > duty and polarity) in one go. > > This implementation is still experimental, and I may have missed some key > aspect, so any feedback are welcome. > > Also note that I haven't protected the state update with any locking. > That's because the existing config does not protect against concurrent > access to a requested PWM device (see the pwm_config implementation). > I guess the PWM framework assume the user will implement the proper locking > scheme if it has to concurrently access the device. > > The 5 first patches prepare the addition of the pwm_state concept, which > will be used to allow atomic updates. > The following patches introduce the pwm_state struct, initial state > retrieval and atomic update concepts. > > Patches 12 and 13 are showing how one can implement the initial state > retrieval and atomic update features in a PWM driver (in this specific > case I implemented it in the rockchip driver). > > The last 2 patches are making use of those changes to improve the > pwm-regulator driver (initializing the regulator state based on the > initial PWM state). at first I got very strange readings (very wrong values and wrong polarity), which resulted from the issues I pointed out in the replies to individual patches. After fixing these, the pwm read-back now returns exactly the expected values :-) . And with the original voltage table from the Chromeos-devicetrees, the pwm- regulator also returns the expected 1.2V that coreboot initially set. Heiko From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Subject: Re: [RFC PATCH 00/15] pwm: add support for atomic update Date: Wed, 01 Jul 2015 23:57:57 +0200 Message-ID: <3250976.mr9RMtjrdC@diego> References: <1435738921-25027-1-git-send-email-boris.brezillon@free-electrons.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: <1435738921-25027-1-git-send-email-boris.brezillon@free-electrons.com> Sender: linux-pwm-owner@vger.kernel.org To: linux-arm-kernel@lists.infradead.org Cc: Boris Brezillon , Thierry Reding , linux-pwm@vger.kernel.org, Alexandre Courbot , linux-fbdev@vger.kernel.org, Lee Jones , Stephen Warren , Tomi Valkeinen , Bryan Wu , Liam Girdwood , Doug Anderson , Mark Brown , Richard Purdie , Jingoo Han , linux-tegra@vger.kernel.org, Maxime Ripard , Jean-Christophe Plagniol-Villard , Jacek Anaszewski , linux-leds@vger.kernel.org List-Id: linux-leds@vger.kernel.org Hi Boris, Am Mittwoch, 1. Juli 2015, 10:21:46 schrieb Boris Brezillon: > Hello Thierry, > > This series adds support for atomic PWM update, or ITO, the capability > to update all the parameters of a PWM device (enabled/disabled, period, > duty and polarity) in one go. > > This implementation is still experimental, and I may have missed some key > aspect, so any feedback are welcome. > > Also note that I haven't protected the state update with any locking. > That's because the existing config does not protect against concurrent > access to a requested PWM device (see the pwm_config implementation). > I guess the PWM framework assume the user will implement the proper locking > scheme if it has to concurrently access the device. > > The 5 first patches prepare the addition of the pwm_state concept, which > will be used to allow atomic updates. > The following patches introduce the pwm_state struct, initial state > retrieval and atomic update concepts. > > Patches 12 and 13 are showing how one can implement the initial state > retrieval and atomic update features in a PWM driver (in this specific > case I implemented it in the rockchip driver). > > The last 2 patches are making use of those changes to improve the > pwm-regulator driver (initializing the regulator state based on the > initial PWM state). at first I got very strange readings (very wrong values and wrong polarity), which resulted from the issues I pointed out in the replies to individual patches. After fixing these, the pwm read-back now returns exactly the expected values :-) . And with the original voltage table from the Chromeos-devicetrees, the pwm- regulator also returns the expected 1.2V that coreboot initially set. Heiko From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Date: Wed, 01 Jul 2015 21:57:57 +0000 Subject: Re: [RFC PATCH 00/15] pwm: add support for atomic update Message-Id: <3250976.mr9RMtjrdC@diego> List-Id: References: <1435738921-25027-1-git-send-email-boris.brezillon@free-electrons.com> In-Reply-To: <1435738921-25027-1-git-send-email-boris.brezillon@free-electrons.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org Hi Boris, Am Mittwoch, 1. Juli 2015, 10:21:46 schrieb Boris Brezillon: > Hello Thierry, > > This series adds support for atomic PWM update, or ITO, the capability > to update all the parameters of a PWM device (enabled/disabled, period, > duty and polarity) in one go. > > This implementation is still experimental, and I may have missed some key > aspect, so any feedback are welcome. > > Also note that I haven't protected the state update with any locking. > That's because the existing config does not protect against concurrent > access to a requested PWM device (see the pwm_config implementation). > I guess the PWM framework assume the user will implement the proper locking > scheme if it has to concurrently access the device. > > The 5 first patches prepare the addition of the pwm_state concept, which > will be used to allow atomic updates. > The following patches introduce the pwm_state struct, initial state > retrieval and atomic update concepts. > > Patches 12 and 13 are showing how one can implement the initial state > retrieval and atomic update features in a PWM driver (in this specific > case I implemented it in the rockchip driver). > > The last 2 patches are making use of those changes to improve the > pwm-regulator driver (initializing the regulator state based on the > initial PWM state). at first I got very strange readings (very wrong values and wrong polarity), which resulted from the issues I pointed out in the replies to individual patches. After fixing these, the pwm read-back now returns exactly the expected values :-) . And with the original voltage table from the Chromeos-devicetrees, the pwm- regulator also returns the expected 1.2V that coreboot initially set. Heiko