[Intel-gfx] [PATCH v5 07/16] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
Hans de Goede
hdegoede at redhat.com
Tue Jul 28 20:00:23 UTC 2020
Hi,
On 7/28/20 9:36 PM, Andy Shevchenko wrote:
> On Fri, Jul 17, 2020 at 03:37:44PM +0200, Hans de Goede wrote:
>> While looking into adding atomic-pwm support to the pwm-crc driver I
>> noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
>> there is a clock-divider which divides this with a value between 1-128,
>> and there are 256 duty-cycle steps.
>>
>> The pwm-crc code before this commit assumed that a clock-divider
>> setting of 1 means that the PWM output is running at 6 MHZ, if that
>> is true, where do these 256 duty-cycle steps come from?
>>
>> This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that
>> seems unlikely for a PMIC which is using a silicon process optimized for
>> power-switching transistors. It is way more likely that there is an 8
>> bit counter for the duty cycle which acts as an extra fixed divider
>> wrt the PWM output frequency.
>>
>> The main user of the pwm-crc driver is the i915 GPU driver which uses it
>> for backlight control. Lets compare the PWM register values set by the
>> video-BIOS (the GOP), assuming the extra fixed divider is present versus
>> the PWM frequency specified in the Video-BIOS-Tables:
>>
>> Device: PWM Hz set by BIOS PWM Hz specified in VBT
>> Asus T100TA 200 200
>> Asus T100HA 200 200
>> Lenovo Miix 2 8 23437 20000
>> Toshiba WT8-A 23437 20000
>>
>> So as we can see if we assume the extra division by 256 then the register
>> values set by the GOP are an exact match for the VBT values, where as
>> otherwise the values would be of by a factor of 256.
>>
>> This commit fixes the period / duty_cycle calculations to take the
>> extra division by 256 into account.
>
> So, base clock is 6MHz, then 7 bit divisor. That's what original values
> were for. On top of that there is 8-bit duty cycle control ("divide by 256"
> whatever it means) with the output range 23.437kHz..183Hz.
Right, so that range matches with a clock div of 1*256 (6 MHz/256 = 23437.5KHz)
to 128*256 (6 MHz/(128*256) = 183.1Hz) IOW this patch is correct.
Before this patch the code assumed a clkdiv of 1-128 (*), which leads to a
very different output frequency range.
Regards,
Hans
*) 0-127 really, that is fixed in a followup patch
>
>>
>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>> ---
>> Changes in v3:
>> - Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define
>> ---
>> drivers/pwm/pwm-crc.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
>> index 272eeb071147..c056eb9b858c 100644
>> --- a/drivers/pwm/pwm-crc.c
>> +++ b/drivers/pwm/pwm-crc.c
>> @@ -21,8 +21,8 @@
>>
>> #define PWM_MAX_LEVEL 0xFF
>>
>> -#define PWM_BASE_CLK 6000000 /* 6 MHz */
>> -#define PWM_MAX_PERIOD_NS 21333 /* 46.875KHz */
>> +#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */
>> +#define PWM_MAX_PERIOD_NS 5461333 /* 183 Hz */
>>
>> /**
>> * struct crystalcove_pwm - Crystal Cove PWM controller
>> @@ -72,7 +72,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
>>
>> /* changing the clk divisor, need to disable fisrt */
>> crc_pwm_disable(c, pwm);
>> - clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
>> + clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
>>
>> regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
>> clk_div | PWM_OUTPUT_ENABLE);
>> --
>> 2.26.2
>>
>
More information about the Intel-gfx
mailing list