Hi Jeff, On Wed, Jan 01, 2020 at 10:39:36PM +0000, Jeff LaBundy wrote: > On Sun, Dec 22, 2019 at 10:48:51PM +0100, Uwe Kleine-König wrote: > > On Sat, Dec 21, 2019 at 03:28:01AM +0000, Jeff LaBundy wrote: > > > Based on your other feedback, I'm moving forward under the impression that > > > you'll still accept option (2); please let me know if I have misunderstood > > > (thank you for being flexible). > > > > Yeah, that's fine. If in the end it shows that this is a bad idea we can > > still change to (3). > > Sounds great. As soon as 5.5-rc5 lands this weekend, I'll rebase v3 and > send it out. > > I failed to catch this in my previous reply, but the comment I've added > to iqs620_pwm_get_state actually reads as follows: > > /* > * Since the device cannot generate a 0% duty cycle, requests to do so > * force subsequent calls to iqs620_pwm_get_state to report the output > * as disabled with duty cycle equal to that which was in use prior to > * the request. This is not ideal, but is the best compromise based on > * the capabilities of the device. > */ > > This matches the present implementation, not your proposed comment that > claims duty cycle is clamped to 1 / 256 ms following a request for a 0% > duty cycle. Yeah, if that's the mechanism that is actually implemented, that's fine of course. > This seems OK since the concept of a duty cycle or period aren't really > relevant if the output is disabled in my opinion. However if you prefer > I update iqs620_pwm_apply to clamp duty cycle to 1 / 256 ms (instead of > leaving it untouched) in this case, please let me know. For a disabled PWM the duty_cycle and period are not relevant, for an enabled PWM running with 0% the period matters (at least in theory) however. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
