Commit 6edf3152 authored by Andy Shevchenko's avatar Andy Shevchenko
Browse files

pwm: lpss: Clarify the bypass member semantics in struct pwm_lpss_boardinfo 



Instead of an odd comment, cite the documentation, which says more clearly
what's going on with the programming flow on some of the Intel SoCs.

Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
parent a1e062ab

include/linux/platform_data/x86/pwm-lpss.h

+30 −3
Original line number Diff line number Diff line
@@ -15,9 +15,36 @@ struct pwm_lpss_boardinfo { 
	unsigned int npwm;

	unsigned long base_unit_bits;

	/*

	 * Some versions of the IP may stuck in the state machine if enable

	 * bit is not set, and hence update bit will show busy status till

	 * the reset. For the rest it may be otherwise.

	 * NOTE:

	 * Intel Broxton, Apollo Lake, and Gemini Lake have different programming flow.

	 *

	 * Initial Enable or First Activation

	 * 1. Program the base unit and on time divisor values.

	 * 2. Set the software update bit.

	 * 3. Poll in a loop on the PWMCTRL bit until software update bit is cleared.+

	 * 4. Enable the PWM output by setting PWM Enable.

	 * 5. Repeat the above steps for the next PWM Module.

	 *

	 * Dynamic update while PWM is Enabled

	 * 1. Program the base unit and on-time divisor values.

	 * 2. Set the software update bit.

	 * 3. Repeat the above steps for the next PWM module.

	 *

	 * + After setting PWMCTRL register's SW update bit, hardware automatically

	 * deasserts the SW update bit after a brief delay. It was observed that

	 * setting of PWM enable is typically done via read-modify-write of the PWMCTRL

	 * register. If there is no/little delay between setting software update bit

	 * and setting enable bit via read-modify-write, it is possible that the read

	 * could return with software enable as 1. In that case, the last write to set

	 * enable to 1 could also set sw_update to 1. If this happens, sw_update gets

	 * stuck and the driver code can hang as it explicitly waits for sw_update bit

	 * to be 0 after setting the enable bit to 1. To avoid this race condition,

	 * SW should poll on the software update bit to make sure that it is 0 before

	 * doing the read-modify-write to set the enable bit to 1.

	 *

	 * Also, we noted that if sw_update bit was set in step #1 above then when it

	 * is set again in step #2, sw_update bit never gets cleared and the flow hangs.

	 * As such, we need to make sure that sw_update bit is 0 when doing step #1.

	 */

	bool bypass;

	/*