On Sun, Apr 12, 2020 at 09:15:16PM -0500, Jeff LaBundy wrote: > This patch adds support for the Azoteq IQS620A, capable of generating > a 1-kHz PWM output with duty cycle between ~0.4% and 100% (inclusive). > > Signed-off-by: Jeff LaBundy > Reviewed-by: Uwe Kleine-König > --- > Note: This patch was originally part of a series that was intended to be taken > through mfd in its entirety. However, attempts to elicit an Ack for this > patch went unanswered, so it was dropped in order to unblock the series. > > The remainder of the series (including pwm bindings) landed in 5.7-rc1, > so this patch is being sent on its own so that it may be taken through > pwm during the next merge window. > > Changes in v5: > - Replaced iqs62x->map with iqs62x->regmap throughout > - Updated iqs620_pwm_probe to read the values of IQS620_PWR_SETTINGS_PWM_OUT > and IQS620_PWM_DUTY_CYCLE so that iqs620_pwm_get_state reflects the actual > state of the device following any changes made by a bootloader > - Dropped #defines for platform_driver name and alias in favor of the actual > string names > > Changes in v4: > - Updated iqs620_pwm_apply and iqs620_pwm_get_state to hold the lock around > only the minimum necessary code > - Removed the completion protecting against early use of chip->pwms[0] from > inside iqs620_pwm_notifier in favor of cached register values > - Updated iqs620_pwm_get_state to use the cached register values instead of > reading IQS620_PWR_SETTINGS_PWM_OUT and IQS620_PWM_DUTY_CYCLE (both equal > to zero by default) > - Added a comment in iqs620_pwm_notifier to note that the parent MFD driver > prints an error message in the event of a device reset > > Changes in v3: > - Updated the commit message to say "~0.4%" instead of "0.4%" > - Clarified the effect of duty cycle and state changes in the 'Limitations' > section and added a restriction regarding 0% duty cycle > - Added a comment in iqs620_pwm_apply to explain how duty cycle is derived > - Updated iqs620_pwm_apply to disable the output first and enable it last to > prevent temporarily driving a stale duty cycle > - Rounded the calculation for duty cycle up and down in iqs620_pwm_get_state > and iqs620_pwm_apply, respectively > - Added a comment in iqs620_pwm_get_state to explain what it reports follow- > ing requests to set duty cycle to 0% > - Added a lock to prevent back-to-back access of IQS620_PWR_SETTINGS_PWM_OUT > and IQS620_PWM_DUTY_CYCLE from being interrupted > - Updated iqs620_pwm_notifier to reference pwm->state directly as opposed to > calling pwm_get_state > - Moved notifier unregistration back to a device-managed action > - Added a completion to prevent iqs620_pwm_notifier from referencing the > pwm_chip structure until it has been initialized by pwmchip_add > > Changes in v2: > - Merged 'Copyright' and 'Author' lines into one in introductory comments > - Added 'Limitations' section to introductory comments > - Replaced 'error' with 'ret' throughout > - Added const qualifier to state argument of iqs620_pwm_apply and removed all > modifications to the variable's contents > - Updated iqs620_pwm_apply to return -ENOTSUPP or -EINVAL if the requested > polarity is inverted or the requested period is below 1 ms, respectively > - Updated iqs620_pwm_apply to disable the PWM output if duty cycle is zero > - Added iqs620_pwm_get_state > - Eliminated tabbed alignment of pwm_ops and platform_driver struct members > - Moved notifier unregistration to already present iqs620_pwm_remove, which > eliminated the need for a device-managed action and ready flag > - Added a comment in iqs620_pwm_probe to explain the order of operations > - Changed Kconfig "depends on" logic to MFD_IQS62X || COMPILE_TEST > > drivers/pwm/Kconfig | 10 ++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-iqs620a.c | 270 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 281 insertions(+) > create mode 100644 drivers/pwm/pwm-iqs620a.c Applied, thanks. Thierry