Hello,
On 2021/6/7, 3:25 PM,Uwe Kleine-Königwrote:
Hello,
On Tue, May 25, 2021 at 12:32:24PM +0800, Billy Tsai wrote:
>> This patch add the support of PWM controller which can be found at aspeed
>> ast2600 soc. The pwm supoorts up to 16 channels and it's part function
>> of multi-function device "pwm-tach controller".
>>
>> Signed-off-by: Billy Tsai <billy_tsai@xxxxxxxxxxxxxx>
>> ---
>> drivers/pwm/Kconfig | 9 +
>> drivers/pwm/Makefile | 1 +
>> drivers/pwm/pwm-aspeed-g6.c | 334 ++++++++++++++++++++++++++++++++++++
> This doesn't match the driver name which is only "aspeed_pwm". Can you
> please use matching names and pick the function prefix accordingly? What
> is the difference between g6 and ast2600?
They are the same. I will use ast2600 to replace g6.
>> + * The software driver fixes the period to 255, which causes the high-frequency
>> + * precision of the PWM to be coarse, in exchange for the fineness of the duty cycle.
>> + *
>> + * Register usage:
>> + * PIN_ENABLE: When it is unset the pwm controller will always output low to the extern.
>> + * Use to determine whether the PWM channel is enabled or disabled
>> + * CLK_ENABLE: When it is unset the pwm controller will reset the duty counter to 0 and
>> + * output low to the PIN_ENABLE mux after that the driver can still change the pwm period
>> + * and duty and the value will apply when CLK_ENABLE be set again.
>> + * Use to determin whether duty_cycle bigger than 0.
> s/determin/determine/
> Unsetting CLK_ENABLE has an immediate effect, right?
Yes.
>> + * PWM_ASPEED_CTRL_INVERSE: When it is toggled the output value will inverse immediately.
>> + * PWM_ASPEED_DUTY_CYCLE_FALLING_POINT/PWM_ASPEED_DUTY_CYCLE_RISING_POINT: When these two
>> + * values are equal it means the duty cycle = 100%.
> Just for my understanding: These allow to implement a phase offset and
> so to implement inverse polarity you can either use
> PWM_ASPEED_CTRL_INVERSE or set these values accordingly, right?
Yes.
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/module.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/sysfs.h>
>> +#include <linux/reset.h>
>> +#include <linux/regmap.h>
>> +#include <linux/bitfield.h>
>> +#include <linux/slab.h>
>> +#include <linux/pwm.h>
>> +#include <linux/math64.h>
>> +
>> +/* The channel number of Aspeed pwm controller */
> Is there an officially correct spelling of "Aspeed" that your marketing
> section would be happy if it were to be used consistently? We have
> "Aspeed" and "ASPEED" in this patch set.
I will use "Aspeed".
>> +static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>> + const struct pwm_state *state)
>> +{
>> + struct device *dev = chip->dev;
>> + struct aspeed_pwm_data *priv = aspeed_pwm_chip_to_data(chip);
>> + u32 index = pwm->hwpwm, duty_pt;
>> + unsigned long rate;
>> + u64 apply_period, div_h, div_l, divisor;
>> +
>> + dev_dbg(dev, "expect period: %lldns, duty_cycle: %lldns", state->period,
>> + state->duty_cycle);
>> +
>> + rate = clk_get_rate(priv->clk);
>> + /*
>> + * Pick the smallest value for div_h so that div_l can be the biggest
>> + * which results in a finer resolution near the target period value.
>> + */
>> + divisor = (u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1) *
>> + (FIELD_MAX(PWM_ASPEED_CTRL_CLK_DIV_L) + 1);
>> + div_h = order_base_2(DIV64_U64_ROUND_UP(rate * state->period, divisor));
>> + if (div_h > 0xf)
>> + div_h = 0xf;
>> +
>> + divisor = ((u64)NSEC_PER_SEC * (PWM_ASPEED_FIXED_PERIOD + 1)) << div_h;
>> + div_l = div64_u64(rate * state->period, divisor);
>> +
>> + if (div_l == 0)
>> + return -ERANGE;
>> +
>> + div_l -= 1;
>> +
>> + if (div_l > 255)
>> + div_l = 255;
>> +
>> + dev_dbg(dev, "clk source: %ld div_h %lld, div_l : %lld\n", rate, div_h,
>> + div_l);
>> +
>> + apply_period = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * _BITULL(div_h) *
>> + (div_l + 1) *
>> + (PWM_ASPEED_FIXED_PERIOD + 1),
>> + rate);
>> + duty_pt = DIV_ROUND_DOWN_ULL(state->duty_cycle *
>> + (PWM_ASPEED_FIXED_PERIOD + 1),
>> + apply_period);
> Don't divide by the result of a division. So better use:
> state->duty_cycle * rate
> ----------------------------------------
> NSEC_PER_SEC * BITULL(div_h) * div_l + 1
> (Is it correct that PWM_ASPEED_FIXED_PERIOD doesn't appear here?)
Yes, it is correct.
