Re: [PATCH v2] pwm: tiehrpwm: Enable EHRPWM controller before setting configuration
From: Gokul Praveen
Date: Mon Jan 12 2026 - 00:51:59 EST
Hi Uwe,
On 10/01/26 04:23, Uwe Kleine-König wrote:
Hello Gokul,
On Fri, Jan 09, 2026 at 11:21:46AM +0530, Gokul Praveen wrote:
On 08/01/26 23:40, Uwe Kleine-König wrote:
On Thu, Jan 08, 2026 at 12:10:35PM +0530, Gokul Praveen wrote:
On 08/01/26 01:17, Rafael V. Volkmer wrote:
Thanks for CC'ing me on this thread.
On 07/01/26 15:21, Uwe Kleine-König wrote:
adding Rafael to Cc: who sent a patch series for this driver that I
didn't come around to review yet. Given that neither he nor me noticed
the problem addressed in this patch I wonder if it applies to all
hardware variants.
I also didn't observe the issue described here in my testing: duty cycle and
period changes always appeared to take effect as expected.
My tests were done on an AM623 EVM.
One possible explanation is that my test flow mostly exercised configuration
while the PWM was already enabled/active, which could mask the effect of a
put_sync/reset happening after configuration.
Yes, this is the reason why the configuration was taking effect for you ,
Rafael, as the PWM was already enabled when setting the configuration hence
masking the effect of a put_sync/reset happening after configuration.
Can you provide a list of commands that show the failure? That would
result in less guessing for me. My plan is to reproduce the failure
tomorrow to better understand it on my boneblack.
Sure Uwe. These are the commands I have tried for PWM signal generation:
cd /sys/class/pwm/pwmchip0
/sys/class/pwm/pwmchip0# echo 0 > export
/sys/class/pwm/pwmchip0# cd pwm0/
/sys/class/pwm/pwmchip0/pwm0# echo 10000000 > period
/sys/class/pwm/pwmchip0/pwm0# echo 3000000 > duty_cycle
/sys/class/pwm/pwmchip0/pwm0# echo "normal" > polarity
/sys/class/pwm/pwmchip0/pwm0# echo 1 > enable
Once these commands were executed, I measured the PWM signal using logic
analyzer and the duty cycle was 100% even though we had set 30% duty cycle
through the sysfs nodes.
After that sequence I "see" a 30% relative duty cycle on my boneblack.
(With the follwing patch applied on top of pwm/for-next:
diff --git a/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts b/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts
index b4fdcf9c02b5..a3f4a4bb64e4 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-boneblack.dts
@@ -173,3 +173,25 @@ &gpio3 {
&baseboard_eeprom {
vcc-supply = <&ldo4_reg>;
};
+
+&am33xx_pinmux {
+ ehrpwm0_pins: ehrpwm0-pins {
+ pinctrl-single,pins = <
+ /* P9.21 UART2_TXD -> ehrpwm0B */
+ AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_OUTPUT_PULLDOWN, MUX_MODE3)
+ /* P9.22 UART2_RXD -> ehrpwm0A */
+ AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_OUTPUT_PULLDOWN, MUX_MODE3)
+ >;
+ };
+};
+
+&ehrpwm0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ehrpwm0_pins>;
+
+ status = "okay";
+};
+
+&epwmss0 {
+ status = "okay";
+};
)
That makes me think the problem isn't understood well yet and needs more
research. @Rafael, does the problem reproduce for you with Gokul's
recipe? (Or did you try that already? I understood your reply as "I
didn't encounter the issue but also didn't test specifically for that.")
As I cannot reproduce the issue, can you please check if adding
pm_runtime_get_sync(pwmchip_parent(chip));
to the probe function makes the problem disappear? Also please boot with
trace_event=pwm
on the command line and provide the content of
/sys/kernel/debug/tracing/trace after reproducing the problem.
sure Uwe, I will try this from my side.
In the meantime, will you able to test the same on TI J784S4 EVM as the issue was reproduced on this board.
Best regards
Uwe