Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> 於 2022年3月7日 週一 下午9:10寫道： > > Hello, > > On Mon, Mar 07, 2022 at 08:50:10PM +0800, hammer hsieh wrote: > > Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> 於 2022年3月5日 週六 上午2:57寫道： > > > On Fri, Mar 04, 2022 at 02:20:12PM +0800, Hammer Hsieh wrote: > > > > diff --git a/drivers/pwm/pwm-sunplus.c b/drivers/pwm/pwm-sunplus.c > > > > new file mode 100644 > > > > index 0000000..170534f > > > > --- /dev/null > > > > +++ b/drivers/pwm/pwm-sunplus.c > > > > @@ -0,0 +1,229 @@ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +/* > > > > + * PWM device driver for SUNPLUS SoCs > > > > > > Is there a public manual available for this hardware? If yes, please add > > > a link here. > > > > yes, will add links as below > > https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview > > https://sunplus.atlassian.net/wiki/spaces/doc/pages/461144198/12.+Pulse+Width+Modulation+PWM > > > > > > + * > > > > + * Limitations: > > > > + * - Only supports normal polarity. > > > > > > How does the HW behave when it's disabled? Usual candidates are: > > > - It freezes at where it currently is > > > - It outputs low > > > - It becomes tristate > > > > > > Please note this in the Limitations section, too. > > > > > > Another thing to mention is if running periods are completed when the > > > parameters change. > > > > > > > ok, will add note as below > > Limitations: > > - Only supports normal polarity. > > - It output low when PWM channel disabled. > > - When the parameters change, current running period will not be completed > > and run new settings immediately. > > Sounds good. > > Other thing that might maybe happen: in .apply() you write the register > for period first and then the one for duty_cycle. Can it happen, that > for a moment the output is defined by new period and old duty_cycle? > That would be another thing to note. > ok, i will add note for it. - In .apply() PWM output need to write register FREQ and DUTY. When first write FREQ done and not yet write DUTY, it has short timing gap use new FREQ and old DUTY. > > > > +struct sunplus_pwm { > > > > + struct pwm_chip chip; > > > > + void __iomem *base; > > > > + struct clk *clk; > > > > + u32 approx_period[PWM_SUP_NUM]; > > > > + u32 approx_duty_cycle[PWM_SUP_NUM]; > > > > +}; > > > > + > > > > +static inline struct sunplus_pwm *to_sunplus_pwm(struct pwm_chip *chip) > > > > +{ > > > > + return container_of(chip, struct sunplus_pwm, chip); > > > > +} > > > > + > > > > +static void sunplus_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm) > > > > +{ > > > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > > > + u32 value; > > > > + > > > > + /* disable pwm channel output */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > > + value &= ~BIT(pwm->hwpwm); > > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > > + /* disable pwm channel clk source */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL1); > > > > + value &= ~BIT(pwm->hwpwm); > > > > + writel(value, priv->base + PWM_SUP_CONTROL1); > > > > > > the .free callback isn't supposed to modify the hardware. > > > > But how to turn pwm channel off ? > > I add .free function for turn it off. > > In user space > > cd /sys/class/pwm/pwmchip0 > > echo 0 > export > > cd pwm0 > > echo 20000000 > period > > echo 1000000 > duty_cycle > > echo 1 > enable > > cd .. > > echo 0 > unexport ; turn off pwm will call .free function > > unexport should just keep the PWM configured as is. To turn it of, don't > unexport but echo 0 > enable. > ok, i will remove .free function. > > > > + u32 tmp, rate; > > > > + u64 max_period, period_ns, duty_ns, clk_rate; > > > > + > > > > + if (state->polarity != pwm->state.polarity) > > > > + return -EINVAL; > > > > + > > > > + if (!state->enabled) { > > > > + /* disable pwm channel output */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > > + value &= ~BIT(pwm->hwpwm); > > > > > > I'd give this one a name. Something like: > > > > > > #define PWM_SUP_CONTROL_EN(ch) BIT(ch) > > > > > > (Pick the right name from the manual.) > > > > That means it need to implement > > PWM_SUP_CONTROL_EN(ch) and PWM_SUP_CONTROL_DIS(ch) ? > > PWM_SUP_CONTROL_EN(ch) should be enough, PWM_SUP_CONTROL_DIS(ch) would > just be 0 which doens't make much sense. > ok , i will add #define PWM_SP7021_CONTROL_EN(ch) BIT(ch). value &= ~BIT(pwm->hwpwm); should be change to value &= ~PWM_SP7021_CONTROL_EN(pwm->hwpwm); > > > > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > > + /* disable pwm channel clk source */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL1); > > > > + value &= ~BIT(pwm->hwpwm); > > > > + writel(value, priv->base + PWM_SUP_CONTROL1); > > > > + return 0; > > > > + } > > > > + > > > > + clk_rate = clk_get_rate(priv->clk); > > > > + rate = (u32)clk_rate / 100000; > > > > > > This cast doesn't change anything, does it? > > > > yes, clk_rate should be 202.5MHz, to prevent overflow use 2025 to calculate. > > I only talked about the cast, so > > rate = clk_rate / 100000; > > should have the same effect and is a tad nicer. > since i use mul_u64_u64_div_u64(a,b,c) max_period = mul_u64_u64_div_u64(PWM_SP7021_FREQ_MAX, (u64)PWM_SP7021_FREQ_SCALER * NSEC_PER_SEC, clk_rate); seems not necessary for "rate = clk_rate / 100000". > > > > + max_period = PWM_SUP_FREQ_MAX * (PWM_SUP_FREQ_SCALER * 10000 / rate); > > > > > > Here you have rounding issues. Consider rate = 3329. Then you get > > > max_period = 0xffff * (2560000 / 3329) = 0xffff * 768 = 50330880. > > > > > > However the actual result is 50396395.31... > > > > > > Also dividing by the result of a division looses precision. > > > > > > > I am not sure how to fix the rounding issue.(thinking...) > > the mul_u64_u64_div_u64 I suggested should be good. > it works. dd_freq = mul_u64_u64_div_u64(clk_rate, period_ns, (u64)PWM_SP7021_FREQ_SCALER * NSEC_PER_SEC); > > > > + if (dd_freq == 0) > > > > + return -EINVAL; > > > > + > > > > + if (dd_freq > PWM_SUP_FREQ_MAX) > > > > + dd_freq = PWM_SUP_FREQ_MAX; > > > > + > > > > + writel(dd_freq, priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > > > > + > > > > + /* cal and set pwm duty */ > > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > > + value |= BIT(pwm->hwpwm); > > > > + value1 = readl(priv->base + PWM_SUP_CONTROL1); > > > > + value1 |= BIT(pwm->hwpwm); > > > > + if (duty_ns == period_ns) { > > > > + value |= BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > > > > + duty = PWM_SUP_DUTY_MAX; > > > > + } else { > > > > + value &= ~BIT(pwm->hwpwm + PWM_BYPASS_BIT_SHIFT); > > > > + tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER; > > > > + tmp /= priv->approx_period[pwm->hwpwm]; > > > > > > Please use the exact values available. > > > > The same reason, in case of enable PWM_DEBUG. > > first call .apply , then it will call .get_state for verify the calculation. > > The overall goal is not to please PWM_DEBUG, but to use exact > calculations and if you did that, PWM_DEBUG should be happy, too. > sure, will remove approx_xxxx code. > > > > + duty = (u32)tmp; > > > > + duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT); > > > > + } > > > > + writel(duty, priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > > > > + writel(value1, priv->base + PWM_SUP_CONTROL1); > > > > + writel(value, priv->base + PWM_SUP_CONTROL0); > > > > > > What is the difference between CONTROL1 and CONTROL0? > > > > PWM CONTROL0 for PWM channel switch. > > PWM CONTROL1 for PWM clock source switch. > > Actually PWM supports 8 channels , but clock source only 4 sets. > > For easy control(now submit), I just support 4 PWM channels, and one > > clock source for one pwm channel. > > For complicated control(not now), 8 PWM channels 4 clock source , need > > to manage clock source / pwm channel enable or not > > while request/free pwm channel. > > So you can use (say) clk 2 to "drive" PWM channel 6? Where is that > mapping defined. Only implementing 4 channels with a 1:1 mapping is ok, > but you might want to ensure the mapping is indeed 1:1. > PWM CONTROL0 REG[7:0] for PWM channel on/off PWM CONTROL1 REG[3:0] for PWM clock source on/off PWM FREQ REG[15:0] freq = 1/clk_rate *256 * FREQ REG[15:0] PWM DUTY REG[7:0] for duty, REG[9:8] for clock source select. duty |= (pwm->hwpwm << PWM_DD_SEL_BIT_SHIFT); can make sure clock source 0 for pwm0 clock source 1 for pwm1 clock source 2 for pwm2 clock source 3 for pwm3 > > > > + return 0; > > > > +} > > > > + > > > > +static void sunplus_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, > > > > + struct pwm_state *state) > > > > +{ > > > > + struct sunplus_pwm *priv = to_sunplus_pwm(chip); > > > > + u32 value, freq, duty, rate, freq_tmp, duty_tmp; > > > > + u64 tmp, clk_rate; > > > > + > > > > + value = readl(priv->base + PWM_SUP_CONTROL0); > > > > + > > > > + if (value & BIT(pwm->hwpwm)) { > > > > + clk_rate = clk_get_rate(priv->clk); > > > > + rate = (u32)clk_rate / 100000; > > > > + freq = readl(priv->base + PWM_SUP_FREQ(pwm->hwpwm)); > > > > + duty = readl(priv->base + PWM_SUP_DUTY(pwm->hwpwm)); > > > > + duty &= ~GENMASK(9, 8); > > > > + > > > > + freq_tmp = rate * priv->approx_period[pwm->hwpwm] / (PWM_SUP_FREQ_SCALER * 100); > > > > + duty_tmp = priv->approx_duty_cycle[pwm->hwpwm] * PWM_SUP_FREQ_SCALER / > > > > + priv->approx_period[pwm->hwpwm]; > > > > + > > > > + if (freq == freq_tmp && duty == duty_tmp) { > > > > + state->period = priv->approx_period[pwm->hwpwm] * 100; > > > > + state->duty_cycle = priv->approx_duty_cycle[pwm->hwpwm] * 100; > > > > + } else { > > > > + tmp = (u64)freq * PWM_SUP_FREQ_SCALER * 10000; > > > > + state->period = div64_u64(tmp, rate); > > > > + tmp = (u64)freq * (u64)duty * 10000; > > > > + state->duty_cycle = div64_u64(tmp, rate); > > > > + } > > > > + state->enabled = true; > > > > + } else { > > > > + state->enabled = false; > > > > + } > > > > + > > > > + state->polarity = PWM_POLARITY_NORMAL; > > > > +} > > > > > > When .get_state() is first called, .apply wasn't called yet. Then > > > priv->approx_period[pwm->hwpwm] is zero and the returned result is > > > wrong. Please read the register values and calculate the implemented > > > output without caching. > > > > The same reason, in case of enable PWM_DEBUG. > > first call .apply , then it will call .get_state for verify the calculation. > > > > In get_state, I thought about that. > > first called .get_state, read register value to calculate period and duty_cycle. > > after calling .apply , caching data approx_period / approx_duty_cycle > > will not zero. > > then get_state will use caching data to do PWM_DEBUG self verification. > > I will think about how to solve the PWM_DEBUG ".apply is not idempotent" issue. > > I'd say: Don't cache anything. In .get_state() just read the registers and > determine .duty_cycle and .period from them, and in .apply() do the > inverse. > got it. i will modify code like below, and it works. state->period = mul_u64_u64_div_u64((u64)freq, (u64)PWM_SP7021_FREQ_SCALER * NSEC_PER_SEC, clk_rate) + 1UL; state->duty_cycle = mul_u64_u64_div_u64((u64)freq, (u64)duty * NSEC_PER_SEC, clk_rate) + 1UL; seems like i need to plus 1 for it, or ".apply is not idempotent" will happen. > > > > + priv->clk = devm_clk_get_optional(dev, NULL); > > > > + if (IS_ERR(priv->clk)) > > , > > + return dev_err_probe(dev, PTR_ERR(priv->clk), > > > > + "get pwm clock failed\n"); > > > > > > If priv->clk is the dummy clk, clk_get_rate returns 0. This is bad as > > > (at lease up to now) you divide by rate in .apply(). > > > > > > > I check many pwm drivers , they are called devm_clk_get_optional( ) or > > devm_clk_get( ). > > Could you tell me how to do it in a probe ? > > You can only sensibly use devm_clk_get_optional() if you don't rely on > the rate of the clk. So the way to go here is to just use > devm_clk_get(). > ok, will modify it, change to devm_clk_get(). > > > > + ret = devm_add_action_or_reset(dev, > > > > + (void(*)(void *))clk_disable_unprepare, > > > > > > Without checking my C book I'm unsure if this is save on all platforms. > > > I'd implement a oneline function for this. > > > > ok, will implement it in one line. > > static void sunplus_pwm_clk_release(*data) > > { > > struct clk *clk = data; > > clk_disable_unprepare(clk); > > } > > ret = devm_add_action_or_reset(dev, sunplus_pwm_clk_release, priv->clk); > > > > *nod* > > > > > + priv->clk); > > > > + if (ret) > > > > > > missing error message > > > > > > > I didn't see another driver add an error message, is it necessary? > > IMHO yes. (Though the most likely error -ENOMEM, in this case no error > message should be emitted.) > ok, will add error message like below. if (ret < 0) { dev_err(dev, "failed to release clock: %d\n", ret); return ret; } or should i modify like if (ret < 0) { dev_err(dev, "failed to release clock: %d\n", ret); return ERR_PTR(ret); } i didn't find reference code for it, not sure which one is better? thank you. > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ |
