Message-ID: <20260130122353.2263273-1-cosmin-gabriel.tanislav.xa@renesas.com>
Date: Fri, 30 Jan 2026 14:23:48 +0200
From: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
To: Biju Das <biju.das.jz@...renesas.com>,
	William Breathitt Gray <wbg@...nel.org>,
	Uwe Kleine-König <ukleinek@...nel.org>,
	Lee Jones <lee@...nel.org>,
	Thierry Reding <thierry.reding@...il.com>
Cc: linux-iio@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-pwm@...r.kernel.org,
	Cosmin Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
Subject: [PATCH 0/5] Renesas MTU3 PWM / counter fixes

The Renesas MTU3 PWM and counter drivers have some issues which have
been observed while adding support for the Renesas RZ/T2H and RZ/N2H
SoCs.

This series fixes the most important issues which prevent normal
functioning of the driver, while other less important issues will be
handled in a future series.

Questions for the PWM maintainer:

1)

The handling introduced in patches 1 and 2 is similar to the approach
taken in commits [1] and [2].

Is this the right approach?

This code snippet below extracted from drivers/pwm/pwm-rzg2l-gpt.c
entirely prevents the period ticks from changing at all when two PWM
channels backed by the same HW channel are in use.

if (rzg2l_gpt->channel_request_count[ch] > 1) {
  u8 sibling_ch = rzg2l_gpt_sibling(pwm->hwpwm);

  if (rzg2l_gpt_is_ch_enabled(rzg2l_gpt, sibling_ch)) {
    if (period_ticks < rzg2l_gpt->period_ticks[ch])
      return -EBUSY;

    period_ticks = rzg2l_gpt->period_ticks[ch];
  }
}

Same logic has been imposed in patches 1 and 2 as the HW limitation is
similar.

Based on the logic here, a second channel can be enabled as long as its
period is larger than the period of the first enabled channel, and the
period and duty cycle will be adjusted to be <= to the period of the
first enabled channel.

But once the second channel is enabled, there's no way to adjust the
period of either channels anymore.

Wouldn't a better solution be that the smallest period between the two
channels is used, so that adjustment is still possible dynamically?

Here is an example.

echo 0 > /sys/class/pwm/pwmchip0/export
echo 1 > /sys/class/pwm/pwmchip0/export
echo 0xFFF000 > /sys/class/pwm/pwmchip0/pwm0/period
echo 0x7FF800 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle
echo 0xFFF000 > /sys/class/pwm/pwmchip0/pwm1/period
echo 0x7FF800 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable
echo 1 > /sys/class/pwm/pwmchip0/pwm1/enable

Now both LEDs are on, let's increase the period.

echo 0xFFFF000 > /sys/class/pwm/pwmchip0/pwm0/period
echo 0x7FFF800 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle

The effective period did not change.

echo 0xFFFF000 > /sys/class/pwm/pwmchip0/pwm1/period
echo 0x7FFF800 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle

The effective period didn't change now either.

echo 0 > /sys/class/pwm/pwmchip0/pwm0/enable
echo 0 > /sys/class/pwm/pwmchip0/pwm1/enable

echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable
echo 1 > /sys/class/pwm/pwmchip0/pwm1/enable

After turning the PWMs off and on again, the effective period is
updated.

If we were to change the period dynamically to the smallest one, the
LEDs would have changed their effective period without needing to be
turned off and on again.

Would this approach be better than the current approach? I can see that
other drivers just refuse updating the period entirely when the PWM
channels must share the same period.


2)

Another issue that I've encountered is that PWM is left enabled even if
the channel is unexported.

Here is an example.

echo 0 > /sys/class/pwm/pwmchip0/export
echo 0xFFFF000 > /sys/class/pwm/pwmchip0/pwm0/period
echo 0x7FFF800 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle
echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable
echo 0 > /sys/class/pwm/pwmchip0/unexport

The connected LED is kept blinking as 0 was not written to enable.

Is this intended? Or should the PWM turn off on unexport?


3)

Should the .get_state() ops read the period and duty cycle from the
hardware if the PWM is not enabled?

Currently the MTU3 driver guards reading period and duty cycle based on
whether the PWM is enabled.

[1]: e373991eb9ff ("pwm: rzg2l-gpt: Accept requests for too high period length")
[2]: fae00ea9f003 ("pwm: rzg2l-gpt: Allow checking period_tick cache value only if sibling channel is enabled")

Cosmin Tanislav (5):
  pwm: rz-mtu3: fix prescale check when enabling 2nd channel
  pwm: rz-mtu3: impose period restrictions
  pwm: rz-mtu3: correctly enable HW channel 4 and 7
  counter: rz-mtu3-cnt: prevent counter from being toggled multiple
    times
  counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel's dev member

 drivers/counter/rz-mtu3-cnt.c | 67 +++++++++++++-----------
 drivers/pwm/pwm-rz-mtu3.c     | 99 ++++++++++++++++++++++++++++-------
 include/linux/mfd/rz-mtu3.h   |  2 +
 3 files changed, 117 insertions(+), 51 deletions(-)

-- 
2.52.0

Powered by blists - more mailing lists