Re: RZG2L gpt-pwm.c driver - Input Capture Limited Functionality and Spinlock Errors

Hi All!

I am trying to get the PWM peripheral on the RZG2L better tailored for our purpose which is to capture square signals between 45% to 55% duty for deriving the frequency of the signal. We are reading the frequency which corresponds to a tach signal and the frequencies we are dealing with are quite low i.e. between 10Hz (200 RPM) to  500 Hz (10000 RPM).

By using the gpt-rzg2l.c inside the /drivers/pwm found here https://github.com/renesas-rz/rz_linux-cip/tree/rz-5.10-cip36 I noticed a few things:

1. The capture via the sysfs is not reliable. The readings can be quite erroneous and it seems that using a moving average solves the fluctuations. But at certain capture calls the reading is off. I do not have data but I have seen readings where the positive cycle time in ns exceeds the total cycle time in ns - a clearly incorrect error. 

2. I have also noticed issues related to spinlock contention. I have a log somewhere which I will attach once I can find it but it seems that the interrupts and the rzg2l_gpt_capture function has a bug relating to the lock and unlock.

3. Capture function getting stuck and not returning via sysfs. So looking at the code I can see that the capture once called will arm the peripheral to enable the count based on the signal. It starts the count to 0 and then when it sees the edge of the signal toggle, it captures the count. To me this seems fine but I am noticing some readings especially when at the lower frequency range will result in the capture read not returning unless a SIGINT is used to terminate the read. 

Has this been seen by anyone else? Is there a specific version of the driver that has been put together for a similar purpose as above? If not any suggestions would be super helpful, I can look at editing the driver and it's registers. I have a version in which I managed to resolve issue 2 i.e. I no longer see any kernel warnings about the spinlock and in this driver I also edit the prescaler set as well based on the period to be read (in this version the period can be set for GPT mode and is used to set the prescaler), this did not seem to resolve any issue. 

Any idea on the noise filtering perhaps masking the pulses? The tach signal comes through an optocoupler, the signal is fairly square with an ~50% duty. I don't think this can cause an issue but just putting it out there. 

Thanks for reading! Let me know if there is any further information or testing I should provide. 

Top Replies