| Message ID | abf03223-5745-0c79-7840-176c551134c5@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [RFC/RFT] pwm: meson: make full use of common clock framework | expand |
Hello Heiner, On Tue, Mar 28, 2023 at 10:59 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: > > Newer versions of the PWM block use a core clock with external mux, > divider, and gate. These components either don't exist any longer in > the PWM block, or they are bypassed. > To minimize needed changes for supporting the new version, the internal > divider and gate should be handled by CCF too. That sounds like a good way forward to me > I didn't see a good way to split the patch, therefore it's somewhat > bigger. What it does: > > - The internal mux is handled by CCF already. Register also internal > divider and gate with CCF, so that we have one representation of the > input clock: [mux] parent of [divider] parent of [gate] > > - Now that CCF selects an appropriate mux parent, we don't need the > DT-provided default parent any longer. Accordingly we can also omit > setting the mux parent directly in the driver. > > - Instead of manually handling the pre-div divider value, let CCF > set the input clock. Targeted input clock frequency is > 0xffff * 1/period for best precision. > > - For the "inverted pwm disabled" scenario target an input clock > frequency of 1GHz. This ensures that the remaining low pulses > have minimum length. Unfortunately I didn't have much time today so I didn't get to reviewing this. > I don't have hw with the old PWM block, therefore I couldn't test this > patch. With the not yet included extension for the new PWM block > (channel->clock directly coming from get_clk(external_clk)) I didn't > notice any problem. My system uses PWM for the CPU voltage regulator > and for the SDIO 32kHz clock. > > Note: The clock gate in the old PWM block is permanently disabled. > This seems to indicate that it's not used by the new PWM block. > > I'd appreciate testing on the different platforms using the old > PWM block. I have tested basic functionality on a X96 Air (SM1 SoC, the version with Gbit/s PHY) where the VDDCPU regulator is PWM based and the 32kHz clock for wifi is generated by the PWM controller. The RTL8822CS SDIO wifi card is still working (firmware download, basic connectivity and connecting to an AP) and the system survived a minute of 100% CPU usage without hanging. For reference: # cat /sys/kernel/debug/pwm platform/ffd19000.pwm, 2 PWM devices pwm-0 (wifi32k ): requested enabled period: 30518 ns duty: 15259 ns polarity: normal pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal platform/ff807000.pwm, 2 PWM devices pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal platform/ff802000.pwm, 2 PWM devices pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal pwm-1 (regulator-vddcpu ): requested enabled period: 1500 ns duty: 1125 ns polarity: normal # grep \.pwm /sys/kernel/debug/clk/clk_summary ffd19000.pwm#mux0 1 1 0 648999985 0 0 50000 Y ffd19000.pwm#div0 1 1 0 648999985 0 0 50000 Y ffd19000.pwm#gate0 1 1 0 648999985 0 0 50000 Y ffd19000.pwm#mux1 0 0 0 24000000 0 0 50000 Y ffd19000.pwm#div1 0 0 0 24000000 0 0 50000 Y ffd19000.pwm#gate1 0 0 0 24000000 0 0 50000 N ff807000.pwm#mux1 0 0 0 24000000 0 0 50000 Y ff807000.pwm#div1 0 0 0 24000000 0 0 50000 Y ff807000.pwm#gate1 0 0 0 24000000 0 0 50000 N ff807000.pwm#mux0 0 0 0 24000000 0 0 50000 Y ff807000.pwm#div0 0 0 0 24000000 0 0 50000 Y ff807000.pwm#gate0 0 0 0 24000000 0 0 50000 N ff802000.pwm#mux1 1 1 0 24000000 0 0 50000 Y ff802000.pwm#div1 1 1 0 24000000 0 0 50000 Y ff802000.pwm#gate1 1 1 0 24000000 0 0 50000 Y ff802000.pwm#mux0 0 0 0 24000000 0 0 50000 Y ff802000.pwm#div0 0 0 0 24000000 0 0 50000 Y ff802000.pwm#gate0 0 0 0 24000000 0 0 50000 N hdmi_pll is the parent of ffd19000.pwm#mux0 - before it was using the 24MHz XTAL. I haven't tested what happens when I change the video mode (that board is currently not connected to any HDMI screen). Later this week I can also try this e.g. on my Odroid-C1 (with 32-bit Meson8b SoC) to verify that we don't have any 32-bit compatibility issues. Best regards, Martin
On 03.04.2023 23:01, Martin Blumenstingl wrote: > Hello Heiner, > > On Tue, Mar 28, 2023 at 10:59 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >> >> Newer versions of the PWM block use a core clock with external mux, >> divider, and gate. These components either don't exist any longer in >> the PWM block, or they are bypassed. >> To minimize needed changes for supporting the new version, the internal >> divider and gate should be handled by CCF too. > That sounds like a good way forward to me > >> I didn't see a good way to split the patch, therefore it's somewhat >> bigger. What it does: >> >> - The internal mux is handled by CCF already. Register also internal >> divider and gate with CCF, so that we have one representation of the >> input clock: [mux] parent of [divider] parent of [gate] >> >> - Now that CCF selects an appropriate mux parent, we don't need the >> DT-provided default parent any longer. Accordingly we can also omit >> setting the mux parent directly in the driver. >> >> - Instead of manually handling the pre-div divider value, let CCF >> set the input clock. Targeted input clock frequency is >> 0xffff * 1/period for best precision. >> >> - For the "inverted pwm disabled" scenario target an input clock >> frequency of 1GHz. This ensures that the remaining low pulses >> have minimum length. > Unfortunately I didn't have much time today so I didn't get to reviewing this. > >> I don't have hw with the old PWM block, therefore I couldn't test this >> patch. With the not yet included extension for the new PWM block >> (channel->clock directly coming from get_clk(external_clk)) I didn't >> notice any problem. My system uses PWM for the CPU voltage regulator >> and for the SDIO 32kHz clock. >> >> Note: The clock gate in the old PWM block is permanently disabled. >> This seems to indicate that it's not used by the new PWM block. >> >> I'd appreciate testing on the different platforms using the old >> PWM block. > I have tested basic functionality on a X96 Air (SM1 SoC, the version > with Gbit/s PHY) where the VDDCPU regulator is PWM based and the 32kHz > clock for wifi is generated by the PWM controller. > The RTL8822CS SDIO wifi card is still working (firmware download, > basic connectivity and connecting to an AP) and the system survived a > minute of 100% CPU usage without hanging. > > For reference: > # cat /sys/kernel/debug/pwm > platform/ffd19000.pwm, 2 PWM devices > pwm-0 (wifi32k ): requested enabled period: 30518 ns > duty: 15259 ns polarity: normal > pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal > > platform/ff807000.pwm, 2 PWM devices > pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal > pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal > > platform/ff802000.pwm, 2 PWM devices > pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal > pwm-1 (regulator-vddcpu ): requested enabled period: 1500 ns > duty: 1125 ns polarity: normal > > # grep \.pwm /sys/kernel/debug/clk/clk_summary > ffd19000.pwm#mux0 1 1 0 648999985 > 0 0 50000 Y > ffd19000.pwm#div0 1 1 0 > 648999985 0 0 50000 Y > ffd19000.pwm#gate0 1 1 0 > 648999985 0 0 50000 Y > ffd19000.pwm#mux1 0 0 0 24000000 > 0 0 50000 Y > ffd19000.pwm#div1 0 0 0 24000000 > 0 0 50000 Y > ffd19000.pwm#gate1 0 0 0 24000000 > 0 0 50000 N > ff807000.pwm#mux1 0 0 0 24000000 > 0 0 50000 Y > ff807000.pwm#div1 0 0 0 24000000 > 0 0 50000 Y > ff807000.pwm#gate1 0 0 0 24000000 > 0 0 50000 N > ff807000.pwm#mux0 0 0 0 24000000 > 0 0 50000 Y > ff807000.pwm#div0 0 0 0 24000000 > 0 0 50000 Y > ff807000.pwm#gate0 0 0 0 24000000 > 0 0 50000 N > ff802000.pwm#mux1 1 1 0 24000000 > 0 0 50000 Y > ff802000.pwm#div1 1 1 0 24000000 > 0 0 50000 Y > ff802000.pwm#gate1 1 1 0 24000000 > 0 0 50000 Y > ff802000.pwm#mux0 0 0 0 24000000 > 0 0 50000 Y > ff802000.pwm#div0 0 0 0 24000000 > 0 0 50000 Y > ff802000.pwm#gate0 0 0 0 24000000 > 0 0 50000 N > > hdmi_pll is the parent of ffd19000.pwm#mux0 - before it was using the > 24MHz XTAL. > I haven't tested what happens when I change the video mode (that board > is currently not connected to any HDMI screen). > That's a good point. AFAICS drivers/gpu/drm/meson/meson_vclk.c fiddles with the hdmi clock registers. So we may want to avoid using hdmi_pll or vid_pll as pwm parent. Below is a quick (and hopefully not too dirty) follow-up patch disabling the hdmi/video clock parent. Would be great if you can test this patch on top. > Later this week I can also try this e.g. on my Odroid-C1 (with 32-bit > Meson8b SoC) to verify that we don't have any 32-bit compatibility > issues. > > > Best regards, > Martin diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c index 2b1debda4..81900e03a 100644 --- a/drivers/pwm/pwm-meson.c +++ b/drivers/pwm/pwm-meson.c @@ -348,7 +348,7 @@ static const struct pwm_ops meson_pwm_ops = { }; static const char * const pwm_meson8b_parent_names[] = { - "xtal", "vid_pll", "fclk_div4", "fclk_div3" + "xtal", "fclk_div4", "fclk_div3" }; static const struct meson_pwm_data pwm_meson8b_data = { @@ -357,7 +357,7 @@ static const struct meson_pwm_data pwm_meson8b_data = { }; static const char * const pwm_gxbb_parent_names[] = { - "xtal", "hdmi_pll", "fclk_div4", "fclk_div3" + "xtal", "fclk_div4", "fclk_div3" }; static const struct meson_pwm_data pwm_gxbb_data = { @@ -415,7 +415,7 @@ static const struct meson_pwm_data pwm_g12a_ao_cd_data = { }; static const char * const pwm_g12a_ee_parent_names[] = { - "xtal", "hdmi_pll", "fclk_div4", "fclk_div3" + "xtal", "fclk_div4", "fclk_div3" }; static const struct meson_pwm_data pwm_g12a_ee_data = { @@ -470,6 +470,7 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) for (i = 0; i < meson->chip.npwm; i++) { struct meson_pwm_channel *channel = &meson->channels[i]; + static const u32 mux_parents_wo_vid[] = {0, 2, 3}; const char *clk_parent[1]; struct clk *mux_clk, *div_clk; @@ -490,6 +491,10 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) channel->mux.table = NULL; channel->mux.hw.init = &init; + /* 3 parents indicates that video clock parent should be omitted */ + if (init.num_parents == 3) + channel->mux.table = mux_parents_wo_vid; + mux_clk = devm_clk_register(dev, &channel->mux.hw); if (IS_ERR(mux_clk)) { err = PTR_ERR(mux_clk);
On Wed 05 Apr 2023 at 22:43, Heiner Kallweit <hkallweit1@gmail.com> wrote: > On 03.04.2023 23:01, Martin Blumenstingl wrote: >> Hello Heiner, >> >> On Tue, Mar 28, 2023 at 10:59 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >>> >>> Newer versions of the PWM block use a core clock with external mux, >>> divider, and gate. These components either don't exist any longer in >>> the PWM block, or they are bypassed. >>> To minimize needed changes for supporting the new version, the internal >>> divider and gate should be handled by CCF too. >> That sounds like a good way forward to me >> >>> I didn't see a good way to split the patch, therefore it's somewhat >>> bigger. What it does: >>> >>> - The internal mux is handled by CCF already. Register also internal >>> divider and gate with CCF, so that we have one representation of the >>> input clock: [mux] parent of [divider] parent of [gate] >>> >>> - Now that CCF selects an appropriate mux parent, we don't need the >>> DT-provided default parent any longer. Accordingly we can also omit >>> setting the mux parent directly in the driver. >>> >>> - Instead of manually handling the pre-div divider value, let CCF >>> set the input clock. Targeted input clock frequency is >>> 0xffff * 1/period for best precision. >>> >>> - For the "inverted pwm disabled" scenario target an input clock >>> frequency of 1GHz. This ensures that the remaining low pulses >>> have minimum length. >> Unfortunately I didn't have much time today so I didn't get to reviewing this. >> >>> I don't have hw with the old PWM block, therefore I couldn't test this >>> patch. With the not yet included extension for the new PWM block >>> (channel->clock directly coming from get_clk(external_clk)) I didn't >>> notice any problem. My system uses PWM for the CPU voltage regulator >>> and for the SDIO 32kHz clock. >>> >>> Note: The clock gate in the old PWM block is permanently disabled. >>> This seems to indicate that it's not used by the new PWM block. >>> >>> I'd appreciate testing on the different platforms using the old >>> PWM block. >> I have tested basic functionality on a X96 Air (SM1 SoC, the version >> with Gbit/s PHY) where the VDDCPU regulator is PWM based and the 32kHz >> clock for wifi is generated by the PWM controller. >> The RTL8822CS SDIO wifi card is still working (firmware download, >> basic connectivity and connecting to an AP) and the system survived a >> minute of 100% CPU usage without hanging. >> >> For reference: >> # cat /sys/kernel/debug/pwm >> platform/ffd19000.pwm, 2 PWM devices >> pwm-0 (wifi32k ): requested enabled period: 30518 ns >> duty: 15259 ns polarity: normal >> pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal >> >> platform/ff807000.pwm, 2 PWM devices >> pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal >> pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal >> >> platform/ff802000.pwm, 2 PWM devices >> pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal >> pwm-1 (regulator-vddcpu ): requested enabled period: 1500 ns >> duty: 1125 ns polarity: normal >> >> # grep \.pwm /sys/kernel/debug/clk/clk_summary >> ffd19000.pwm#mux0 1 1 0 648999985 >> 0 0 50000 Y >> ffd19000.pwm#div0 1 1 0 >> 648999985 0 0 50000 Y >> ffd19000.pwm#gate0 1 1 0 >> 648999985 0 0 50000 Y >> ffd19000.pwm#mux1 0 0 0 24000000 >> 0 0 50000 Y >> ffd19000.pwm#div1 0 0 0 24000000 >> 0 0 50000 Y >> ffd19000.pwm#gate1 0 0 0 24000000 >> 0 0 50000 N >> ff807000.pwm#mux1 0 0 0 24000000 >> 0 0 50000 Y >> ff807000.pwm#div1 0 0 0 24000000 >> 0 0 50000 Y >> ff807000.pwm#gate1 0 0 0 24000000 >> 0 0 50000 N >> ff807000.pwm#mux0 0 0 0 24000000 >> 0 0 50000 Y >> ff807000.pwm#div0 0 0 0 24000000 >> 0 0 50000 Y >> ff807000.pwm#gate0 0 0 0 24000000 >> 0 0 50000 N >> ff802000.pwm#mux1 1 1 0 24000000 >> 0 0 50000 Y >> ff802000.pwm#div1 1 1 0 24000000 >> 0 0 50000 Y >> ff802000.pwm#gate1 1 1 0 24000000 >> 0 0 50000 Y >> ff802000.pwm#mux0 0 0 0 24000000 >> 0 0 50000 Y >> ff802000.pwm#div0 0 0 0 24000000 >> 0 0 50000 Y >> ff802000.pwm#gate0 0 0 0 24000000 >> 0 0 50000 N >> >> hdmi_pll is the parent of ffd19000.pwm#mux0 - before it was using the >> 24MHz XTAL. >> I haven't tested what happens when I change the video mode (that board >> is currently not connected to any HDMI screen). >> > > That's a good point. AFAICS drivers/gpu/drm/meson/meson_vclk.c fiddles > with the hdmi clock registers. So we may want to avoid using hdmi_pll > or vid_pll as pwm parent. Below is a quick (and hopefully not too dirty) > follow-up patch disabling the hdmi/video clock parent. > Would be great if you can test this patch on top. > >> Later this week I can also try this e.g. on my Odroid-C1 (with 32-bit >> Meson8b SoC) to verify that we don't have any 32-bit compatibility >> issues. >> >> >> Best regards, >> Martin > > diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c > index 2b1debda4..81900e03a 100644 > --- a/drivers/pwm/pwm-meson.c > +++ b/drivers/pwm/pwm-meson.c > @@ -348,7 +348,7 @@ static const struct pwm_ops meson_pwm_ops = { > }; > > static const char * const pwm_meson8b_parent_names[] = { > - "xtal", "vid_pll", "fclk_div4", "fclk_div3" > + "xtal", "fclk_div4", "fclk_div3" > }; > > static const struct meson_pwm_data pwm_meson8b_data = { > @@ -357,7 +357,7 @@ static const struct meson_pwm_data pwm_meson8b_data = { > }; > > static const char * const pwm_gxbb_parent_names[] = { > - "xtal", "hdmi_pll", "fclk_div4", "fclk_div3" > + "xtal", "fclk_div4", "fclk_div3" > }; > > static const struct meson_pwm_data pwm_gxbb_data = { > @@ -415,7 +415,7 @@ static const struct meson_pwm_data pwm_g12a_ao_cd_data = { > }; > > static const char * const pwm_g12a_ee_parent_names[] = { > - "xtal", "hdmi_pll", "fclk_div4", "fclk_div3" > + "xtal", "fclk_div4", "fclk_div3" > }; > > static const struct meson_pwm_data pwm_g12a_ee_data = { > @@ -470,6 +470,7 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) > > for (i = 0; i < meson->chip.npwm; i++) { > struct meson_pwm_channel *channel = &meson->channels[i]; > + static const u32 mux_parents_wo_vid[] = {0, 2, 3}; > const char *clk_parent[1]; > struct clk *mux_clk, *div_clk; > > @@ -490,6 +491,10 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) > channel->mux.table = NULL; > channel->mux.hw.init = &init; > > + /* 3 parents indicates that video clock parent should be omitted */ > + if (init.num_parents == 3) > + channel->mux.table = mux_parents_wo_vid; > + If you are reworking the pwm driver and its clock usage, I would suggest to also stop using global clock names within the driver. The way it is used right now is not great. It is essentially the pwm driver directly poking the clock tree, without going through DT as it should. You could have clkin0/1/2/3 from DT, using fw_name for the clock mux. This how it should be used. All input being optionnal, you would not any dirty trick in the driver to skip an input. You would just not provide it through DT. This approach would be compatible with all the SoCs (compared to our current approach which require a new table for each SoC) Off the course the bindings would be different, so it would probably require a new compatible (-v2 ?) > mux_clk = devm_clk_register(dev, &channel->mux.hw); > if (IS_ERR(mux_clk)) { > err = PTR_ERR(mux_clk);
On 05/04/2023 22:59, Jerome Brunet wrote: > > On Wed 05 Apr 2023 at 22:43, Heiner Kallweit <hkallweit1@gmail.com> wrote: > >> On 03.04.2023 23:01, Martin Blumenstingl wrote: >>> Hello Heiner, >>> >>> On Tue, Mar 28, 2023 at 10:59 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >>>> >>>> Newer versions of the PWM block use a core clock with external mux, >>>> divider, and gate. These components either don't exist any longer in >>>> the PWM block, or they are bypassed. >>>> To minimize needed changes for supporting the new version, the internal >>>> divider and gate should be handled by CCF too. >>> That sounds like a good way forward to me >>> >>>> I didn't see a good way to split the patch, therefore it's somewhat >>>> bigger. What it does: >>>> >>>> - The internal mux is handled by CCF already. Register also internal >>>> divider and gate with CCF, so that we have one representation of the >>>> input clock: [mux] parent of [divider] parent of [gate] >>>> >>>> - Now that CCF selects an appropriate mux parent, we don't need the >>>> DT-provided default parent any longer. Accordingly we can also omit >>>> setting the mux parent directly in the driver. >>>> >>>> - Instead of manually handling the pre-div divider value, let CCF >>>> set the input clock. Targeted input clock frequency is >>>> 0xffff * 1/period for best precision. >>>> >>>> - For the "inverted pwm disabled" scenario target an input clock >>>> frequency of 1GHz. This ensures that the remaining low pulses >>>> have minimum length. >>> Unfortunately I didn't have much time today so I didn't get to reviewing this. >>> >>>> I don't have hw with the old PWM block, therefore I couldn't test this >>>> patch. With the not yet included extension for the new PWM block >>>> (channel->clock directly coming from get_clk(external_clk)) I didn't >>>> notice any problem. My system uses PWM for the CPU voltage regulator >>>> and for the SDIO 32kHz clock. >>>> >>>> Note: The clock gate in the old PWM block is permanently disabled. >>>> This seems to indicate that it's not used by the new PWM block. >>>> >>>> I'd appreciate testing on the different platforms using the old >>>> PWM block. >>> I have tested basic functionality on a X96 Air (SM1 SoC, the version >>> with Gbit/s PHY) where the VDDCPU regulator is PWM based and the 32kHz >>> clock for wifi is generated by the PWM controller. >>> The RTL8822CS SDIO wifi card is still working (firmware download, >>> basic connectivity and connecting to an AP) and the system survived a >>> minute of 100% CPU usage without hanging. >>> >>> For reference: >>> # cat /sys/kernel/debug/pwm >>> platform/ffd19000.pwm, 2 PWM devices >>> pwm-0 (wifi32k ): requested enabled period: 30518 ns >>> duty: 15259 ns polarity: normal >>> pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal >>> >>> platform/ff807000.pwm, 2 PWM devices >>> pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal >>> pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal >>> >>> platform/ff802000.pwm, 2 PWM devices >>> pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal >>> pwm-1 (regulator-vddcpu ): requested enabled period: 1500 ns >>> duty: 1125 ns polarity: normal >>> >>> # grep \.pwm /sys/kernel/debug/clk/clk_summary >>> ffd19000.pwm#mux0 1 1 0 648999985 >>> 0 0 50000 Y >>> ffd19000.pwm#div0 1 1 0 >>> 648999985 0 0 50000 Y >>> ffd19000.pwm#gate0 1 1 0 >>> 648999985 0 0 50000 Y >>> ffd19000.pwm#mux1 0 0 0 24000000 >>> 0 0 50000 Y >>> ffd19000.pwm#div1 0 0 0 24000000 >>> 0 0 50000 Y >>> ffd19000.pwm#gate1 0 0 0 24000000 >>> 0 0 50000 N >>> ff807000.pwm#mux1 0 0 0 24000000 >>> 0 0 50000 Y >>> ff807000.pwm#div1 0 0 0 24000000 >>> 0 0 50000 Y >>> ff807000.pwm#gate1 0 0 0 24000000 >>> 0 0 50000 N >>> ff807000.pwm#mux0 0 0 0 24000000 >>> 0 0 50000 Y >>> ff807000.pwm#div0 0 0 0 24000000 >>> 0 0 50000 Y >>> ff807000.pwm#gate0 0 0 0 24000000 >>> 0 0 50000 N >>> ff802000.pwm#mux1 1 1 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#div1 1 1 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#gate1 1 1 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#mux0 0 0 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#div0 0 0 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#gate0 0 0 0 24000000 >>> 0 0 50000 N >>> >>> hdmi_pll is the parent of ffd19000.pwm#mux0 - before it was using the >>> 24MHz XTAL. >>> I haven't tested what happens when I change the video mode (that board >>> is currently not connected to any HDMI screen). >>> >> >> That's a good point. AFAICS drivers/gpu/drm/meson/meson_vclk.c fiddles >> with the hdmi clock registers. So we may want to avoid using hdmi_pll >> or vid_pll as pwm parent. Below is a quick (and hopefully not too dirty) >> follow-up patch disabling the hdmi/video clock parent. >> Would be great if you can test this patch on top. >> >>> Later this week I can also try this e.g. on my Odroid-C1 (with 32-bit >>> Meson8b SoC) to verify that we don't have any 32-bit compatibility >>> issues. >>> >>> >>> Best regards, >>> Martin >> >> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c >> index 2b1debda4..81900e03a 100644 >> --- a/drivers/pwm/pwm-meson.c >> +++ b/drivers/pwm/pwm-meson.c >> @@ -348,7 +348,7 @@ static const struct pwm_ops meson_pwm_ops = { >> }; >> >> static const char * const pwm_meson8b_parent_names[] = { >> - "xtal", "vid_pll", "fclk_div4", "fclk_div3" >> + "xtal", "fclk_div4", "fclk_div3" >> }; >> >> static const struct meson_pwm_data pwm_meson8b_data = { >> @@ -357,7 +357,7 @@ static const struct meson_pwm_data pwm_meson8b_data = { >> }; >> >> static const char * const pwm_gxbb_parent_names[] = { >> - "xtal", "hdmi_pll", "fclk_div4", "fclk_div3" >> + "xtal", "fclk_div4", "fclk_div3" >> }; >> >> static const struct meson_pwm_data pwm_gxbb_data = { >> @@ -415,7 +415,7 @@ static const struct meson_pwm_data pwm_g12a_ao_cd_data = { >> }; >> >> static const char * const pwm_g12a_ee_parent_names[] = { >> - "xtal", "hdmi_pll", "fclk_div4", "fclk_div3" >> + "xtal", "fclk_div4", "fclk_div3" >> }; >> >> static const struct meson_pwm_data pwm_g12a_ee_data = { >> @@ -470,6 +470,7 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) >> >> for (i = 0; i < meson->chip.npwm; i++) { >> struct meson_pwm_channel *channel = &meson->channels[i]; >> + static const u32 mux_parents_wo_vid[] = {0, 2, 3}; >> const char *clk_parent[1]; >> struct clk *mux_clk, *div_clk; >> >> @@ -490,6 +491,10 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) >> channel->mux.table = NULL; >> channel->mux.hw.init = &init; >> >> + /* 3 parents indicates that video clock parent should be omitted */ >> + if (init.num_parents == 3) >> + channel->mux.table = mux_parents_wo_vid; >> + > > If you are reworking the pwm driver and its clock usage, I would suggest > to also stop using global clock names within the driver. The way it is > used right now is not great. It is essentially the pwm driver directly > poking the clock tree, without going through DT as it should. > > You could have clkin0/1/2/3 from DT, using fw_name for the clock mux. > This how it should be used. All input being optionnal, you would not any > dirty trick in the driver to skip an input. You would just not provide > it through DT. > > This approach would be compatible with all the SoCs (compared to our > current approach which require a new table for each SoC) > > Off the course the bindings would be different, so it would probably > require a new compatible (-v2 ?) Note the driver should still support the current bindings. Neil > >> mux_clk = devm_clk_register(dev, &channel->mux.hw); >> if (IS_ERR(mux_clk)) { >> err = PTR_ERR(mux_clk); > > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic
On 05.04.2023 22:59, Jerome Brunet wrote: > > On Wed 05 Apr 2023 at 22:43, Heiner Kallweit <hkallweit1@gmail.com> wrote: > >> On 03.04.2023 23:01, Martin Blumenstingl wrote: >>> Hello Heiner, >>> >>> On Tue, Mar 28, 2023 at 10:59 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >>>> >>>> Newer versions of the PWM block use a core clock with external mux, >>>> divider, and gate. These components either don't exist any longer in >>>> the PWM block, or they are bypassed. >>>> To minimize needed changes for supporting the new version, the internal >>>> divider and gate should be handled by CCF too. >>> That sounds like a good way forward to me >>> >>>> I didn't see a good way to split the patch, therefore it's somewhat >>>> bigger. What it does: >>>> >>>> - The internal mux is handled by CCF already. Register also internal >>>> divider and gate with CCF, so that we have one representation of the >>>> input clock: [mux] parent of [divider] parent of [gate] >>>> >>>> - Now that CCF selects an appropriate mux parent, we don't need the >>>> DT-provided default parent any longer. Accordingly we can also omit >>>> setting the mux parent directly in the driver. >>>> >>>> - Instead of manually handling the pre-div divider value, let CCF >>>> set the input clock. Targeted input clock frequency is >>>> 0xffff * 1/period for best precision. >>>> >>>> - For the "inverted pwm disabled" scenario target an input clock >>>> frequency of 1GHz. This ensures that the remaining low pulses >>>> have minimum length. >>> Unfortunately I didn't have much time today so I didn't get to reviewing this. >>> >>>> I don't have hw with the old PWM block, therefore I couldn't test this >>>> patch. With the not yet included extension for the new PWM block >>>> (channel->clock directly coming from get_clk(external_clk)) I didn't >>>> notice any problem. My system uses PWM for the CPU voltage regulator >>>> and for the SDIO 32kHz clock. >>>> >>>> Note: The clock gate in the old PWM block is permanently disabled. >>>> This seems to indicate that it's not used by the new PWM block. >>>> >>>> I'd appreciate testing on the different platforms using the old >>>> PWM block. >>> I have tested basic functionality on a X96 Air (SM1 SoC, the version >>> with Gbit/s PHY) where the VDDCPU regulator is PWM based and the 32kHz >>> clock for wifi is generated by the PWM controller. >>> The RTL8822CS SDIO wifi card is still working (firmware download, >>> basic connectivity and connecting to an AP) and the system survived a >>> minute of 100% CPU usage without hanging. >>> >>> For reference: >>> # cat /sys/kernel/debug/pwm >>> platform/ffd19000.pwm, 2 PWM devices >>> pwm-0 (wifi32k ): requested enabled period: 30518 ns >>> duty: 15259 ns polarity: normal >>> pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal >>> >>> platform/ff807000.pwm, 2 PWM devices >>> pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal >>> pwm-1 ((null) ): period: 0 ns duty: 0 ns polarity: normal >>> >>> platform/ff802000.pwm, 2 PWM devices >>> pwm-0 ((null) ): period: 0 ns duty: 0 ns polarity: normal >>> pwm-1 (regulator-vddcpu ): requested enabled period: 1500 ns >>> duty: 1125 ns polarity: normal >>> >>> # grep \.pwm /sys/kernel/debug/clk/clk_summary >>> ffd19000.pwm#mux0 1 1 0 648999985 >>> 0 0 50000 Y >>> ffd19000.pwm#div0 1 1 0 >>> 648999985 0 0 50000 Y >>> ffd19000.pwm#gate0 1 1 0 >>> 648999985 0 0 50000 Y >>> ffd19000.pwm#mux1 0 0 0 24000000 >>> 0 0 50000 Y >>> ffd19000.pwm#div1 0 0 0 24000000 >>> 0 0 50000 Y >>> ffd19000.pwm#gate1 0 0 0 24000000 >>> 0 0 50000 N >>> ff807000.pwm#mux1 0 0 0 24000000 >>> 0 0 50000 Y >>> ff807000.pwm#div1 0 0 0 24000000 >>> 0 0 50000 Y >>> ff807000.pwm#gate1 0 0 0 24000000 >>> 0 0 50000 N >>> ff807000.pwm#mux0 0 0 0 24000000 >>> 0 0 50000 Y >>> ff807000.pwm#div0 0 0 0 24000000 >>> 0 0 50000 Y >>> ff807000.pwm#gate0 0 0 0 24000000 >>> 0 0 50000 N >>> ff802000.pwm#mux1 1 1 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#div1 1 1 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#gate1 1 1 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#mux0 0 0 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#div0 0 0 0 24000000 >>> 0 0 50000 Y >>> ff802000.pwm#gate0 0 0 0 24000000 >>> 0 0 50000 N >>> >>> hdmi_pll is the parent of ffd19000.pwm#mux0 - before it was using the >>> 24MHz XTAL. >>> I haven't tested what happens when I change the video mode (that board >>> is currently not connected to any HDMI screen). >>> >> >> That's a good point. AFAICS drivers/gpu/drm/meson/meson_vclk.c fiddles >> with the hdmi clock registers. So we may want to avoid using hdmi_pll >> or vid_pll as pwm parent. Below is a quick (and hopefully not too dirty) >> follow-up patch disabling the hdmi/video clock parent. >> Would be great if you can test this patch on top. >> >>> Later this week I can also try this e.g. on my Odroid-C1 (with 32-bit >>> Meson8b SoC) to verify that we don't have any 32-bit compatibility >>> issues. >>> >>> >>> Best regards, >>> Martin >> >> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c >> index 2b1debda4..81900e03a 100644 >> --- a/drivers/pwm/pwm-meson.c >> +++ b/drivers/pwm/pwm-meson.c >> @@ -348,7 +348,7 @@ static const struct pwm_ops meson_pwm_ops = { >> }; >> >> static const char * const pwm_meson8b_parent_names[] = { >> - "xtal", "vid_pll", "fclk_div4", "fclk_div3" >> + "xtal", "fclk_div4", "fclk_div3" >> }; >> >> static const struct meson_pwm_data pwm_meson8b_data = { >> @@ -357,7 +357,7 @@ static const struct meson_pwm_data pwm_meson8b_data = { >> }; >> >> static const char * const pwm_gxbb_parent_names[] = { >> - "xtal", "hdmi_pll", "fclk_div4", "fclk_div3" >> + "xtal", "fclk_div4", "fclk_div3" >> }; >> >> static const struct meson_pwm_data pwm_gxbb_data = { >> @@ -415,7 +415,7 @@ static const struct meson_pwm_data pwm_g12a_ao_cd_data = { >> }; >> >> static const char * const pwm_g12a_ee_parent_names[] = { >> - "xtal", "hdmi_pll", "fclk_div4", "fclk_div3" >> + "xtal", "fclk_div4", "fclk_div3" >> }; >> >> static const struct meson_pwm_data pwm_g12a_ee_data = { >> @@ -470,6 +470,7 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) >> >> for (i = 0; i < meson->chip.npwm; i++) { >> struct meson_pwm_channel *channel = &meson->channels[i]; >> + static const u32 mux_parents_wo_vid[] = {0, 2, 3}; >> const char *clk_parent[1]; >> struct clk *mux_clk, *div_clk; >> >> @@ -490,6 +491,10 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) >> channel->mux.table = NULL; >> channel->mux.hw.init = &init; >> >> + /* 3 parents indicates that video clock parent should be omitted */ >> + if (init.num_parents == 3) >> + channel->mux.table = mux_parents_wo_vid; >> + > > If you are reworking the pwm driver and its clock usage, I would suggest > to also stop using global clock names within the driver. The way it is > used right now is not great. It is essentially the pwm driver directly > poking the clock tree, without going through DT as it should. > > You could have clkin0/1/2/3 from DT, using fw_name for the clock mux. > This how it should be used. All input being optionnal, you would not any > dirty trick in the driver to skip an input. You would just not provide > it through DT. > > This approach would be compatible with all the SoCs (compared to our > current approach which require a new table for each SoC) > > Off the course the bindings would be different, so it would probably > require a new compatible (-v2 ?) > I think the approach would be right. Some potential issues I see: - Then we would have three pwm bindings: 1. We have to keep the current binding in order not to break potential non-Linux DT users. 2. The new binding, what you call v2. 3. The binding for the new chip versions with core pwm clock. For the v2 binding I'm not sure how to handle the following. Board DTS files have: &pwm_ab { pinctrl-0 = <&pwm_a_e_pins>; pinctrl-names = "default"; clocks = <&xtal>; clock-names = "clkin0"; status = "okay"; }; Means if we describe the mux parent clocks in the parent platform dtsi, then we would overwrite the clocks property here and lose the information (at least that's my understanding). I'm not sure its worth the effort considering that we talk about a legacy pwm block. >> mux_clk = devm_clk_register(dev, &channel->mux.hw); >> if (IS_ERR(mux_clk)) { >> err = PTR_ERR(mux_clk); >
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c index 16d79ca5d..2b1debda4 100644 --- a/drivers/pwm/pwm-meson.c +++ b/drivers/pwm/pwm-meson.c @@ -86,12 +86,13 @@ static struct meson_pwm_channel_data { }; struct meson_pwm_channel { + unsigned long rate; unsigned int hi; unsigned int lo; - u8 pre_div; - struct clk *clk_parent; struct clk_mux mux; + struct clk_divider div; + struct clk_gate gate; struct clk *clk; }; @@ -124,16 +125,6 @@ static int meson_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm) struct device *dev = chip->dev; int err; - if (channel->clk_parent) { - err = clk_set_parent(channel->clk, channel->clk_parent); - if (err < 0) { - dev_err(dev, "failed to set parent %s for %s: %d\n", - __clk_get_name(channel->clk_parent), - __clk_get_name(channel->clk), err); - return err; - } - } - err = clk_prepare_enable(channel->clk); if (err < 0) { dev_err(dev, "failed to enable clock %s: %d\n", @@ -156,8 +147,9 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm, const struct pwm_state *state) { struct meson_pwm_channel *channel = &meson->channels[pwm->hwpwm]; - unsigned int duty, period, pre_div, cnt, duty_cnt; + unsigned int duty, period, cnt, duty_cnt; unsigned long fin_freq; + u64 freq; duty = state->duty_cycle; period = state->period; @@ -165,7 +157,11 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm, if (state->polarity == PWM_POLARITY_INVERSED) duty = period - duty; - fin_freq = clk_get_rate(channel->clk); + freq = div64_u64(NSEC_PER_SEC * (u64)0xffff, period); + if (freq > ULONG_MAX) + freq = ULONG_MAX; + + fin_freq = clk_round_rate(channel->clk, freq); if (fin_freq == 0) { dev_err(meson->chip.dev, "invalid source clock frequency\n"); return -EINVAL; @@ -173,46 +169,35 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm, dev_dbg(meson->chip.dev, "fin_freq: %lu Hz\n", fin_freq); - pre_div = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * 0xffffLL); - if (pre_div > MISC_CLK_DIV_MASK) { - dev_err(meson->chip.dev, "unable to get period pre_div\n"); - return -EINVAL; - } - - cnt = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * (pre_div + 1)); + cnt = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC); if (cnt > 0xffff) { dev_err(meson->chip.dev, "unable to get period cnt\n"); return -EINVAL; } - dev_dbg(meson->chip.dev, "period=%u pre_div=%u cnt=%u\n", period, - pre_div, cnt); + dev_dbg(meson->chip.dev, "period=%u cnt=%u\n", period, cnt); if (duty == period) { - channel->pre_div = pre_div; channel->hi = cnt; channel->lo = 0; } else if (duty == 0) { - channel->pre_div = pre_div; channel->hi = 0; channel->lo = cnt; } else { - /* Then check is we can have the duty with the same pre_div */ - duty_cnt = div64_u64(fin_freq * (u64)duty, - NSEC_PER_SEC * (pre_div + 1)); + duty_cnt = div64_u64(fin_freq * (u64)duty, NSEC_PER_SEC); if (duty_cnt > 0xffff) { dev_err(meson->chip.dev, "unable to get duty cycle\n"); return -EINVAL; } - dev_dbg(meson->chip.dev, "duty=%u pre_div=%u duty_cnt=%u\n", - duty, pre_div, duty_cnt); + dev_dbg(meson->chip.dev, "duty=%u duty_cnt=%u\n", duty, duty_cnt); - channel->pre_div = pre_div; channel->hi = duty_cnt; channel->lo = cnt - duty_cnt; } + channel->rate = fin_freq; + return 0; } @@ -222,16 +207,15 @@ static void meson_pwm_enable(struct meson_pwm *meson, struct pwm_device *pwm) struct meson_pwm_channel_data *channel_data; unsigned long flags; u32 value; + int err; channel_data = &meson_pwm_per_channel_data[pwm->hwpwm]; - spin_lock_irqsave(&meson->lock, flags); + err = clk_set_rate(channel->clk, channel->rate); + if (err) + dev_err(meson->chip.dev, "setting clock rate failed\n"); - value = readl(meson->base + REG_MISC_AB); - value &= ~(MISC_CLK_DIV_MASK << channel_data->clk_div_shift); - value |= channel->pre_div << channel_data->clk_div_shift; - value |= channel_data->clk_en_mask; - writel(value, meson->base + REG_MISC_AB); + spin_lock_irqsave(&meson->lock, flags); value = FIELD_PREP(PWM_HIGH_MASK, channel->hi) | FIELD_PREP(PWM_LOW_MASK, channel->lo); @@ -270,16 +254,16 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, /* * This IP block revision doesn't have an "always high" * setting which we can use for "inverted disabled". - * Instead we achieve this using the same settings - * that we use a pre_div of 0 (to get the shortest - * possible duration for one "count") and + * Instead we achieve this by setting an arbitrary, + * very high frequency, resulting in the shortest + * possible duration for one "count" and * "period == duty_cycle". This results in a signal * which is LOW for one "count", while being HIGH for * the rest of the (so the signal is HIGH for slightly * less than 100% of the period, but this is the best * we can achieve). */ - channel->pre_div = 0; + channel->rate = 1000000000; channel->hi = ~0; channel->lo = 0; @@ -304,7 +288,6 @@ static unsigned int meson_pwm_cnt_to_ns(struct pwm_chip *chip, struct meson_pwm *meson = to_meson_pwm(chip); struct meson_pwm_channel *channel; unsigned long fin_freq; - u32 fin_ns; /* to_meson_pwm() can only be used after .get_state() is called */ channel = &meson->channels[pwm->hwpwm]; @@ -313,9 +296,7 @@ static unsigned int meson_pwm_cnt_to_ns(struct pwm_chip *chip, if (fin_freq == 0) return 0; - fin_ns = div_u64(NSEC_PER_SEC, fin_freq); - - return cnt * fin_ns * (channel->pre_div + 1); + return div_u64(NSEC_PER_SEC * (u64)cnt, fin_freq); } static int meson_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, @@ -334,11 +315,8 @@ static int meson_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm, value = readl(meson->base + REG_MISC_AB); - tmp = channel_data->pwm_en_mask | channel_data->clk_en_mask; - state->enabled = (value & tmp) == tmp; - - tmp = value >> channel_data->clk_div_shift; - channel->pre_div = FIELD_GET(MISC_CLK_DIV_MASK, tmp); + tmp = channel_data->pwm_en_mask; + state->enabled = __clk_is_enabled(channel->clk) && (value & tmp) == tmp; value = readl(meson->base + channel_data->reg_offset); @@ -492,6 +470,8 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) for (i = 0; i < meson->chip.npwm; i++) { struct meson_pwm_channel *channel = &meson->channels[i]; + const char *clk_parent[1]; + struct clk *mux_clk, *div_clk; snprintf(name, sizeof(name), "%s#mux%u", dev_name(dev), i); @@ -510,18 +490,57 @@ static int meson_pwm_init_channels(struct meson_pwm *meson) channel->mux.table = NULL; channel->mux.hw.init = &init; - channel->clk = devm_clk_register(dev, &channel->mux.hw); - if (IS_ERR(channel->clk)) { - err = PTR_ERR(channel->clk); + mux_clk = devm_clk_register(dev, &channel->mux.hw); + if (IS_ERR(mux_clk)) { + err = PTR_ERR(mux_clk); dev_err(dev, "failed to register %s: %d\n", name, err); return err; } - snprintf(name, sizeof(name), "clkin%u", i); + snprintf(name, sizeof(name), "%s#div%u", dev_name(dev), i); + + init.name = name; + init.ops = &clk_divider_ops; + init.flags = CLK_SET_RATE_PARENT; + clk_parent[0] = __clk_get_name(mux_clk); + init.parent_names = clk_parent; + init.num_parents = 1; + + channel->div.reg = meson->base + REG_MISC_AB; + channel->div.shift = meson_pwm_per_channel_data[i].clk_div_shift; + channel->div.width = __builtin_popcountl(MISC_CLK_DIV_MASK); + channel->div.hw.init = &init; + channel->div.flags = 0; + channel->div.lock = &meson->lock; + + div_clk = devm_clk_register(dev, &channel->div.hw); + if (IS_ERR(div_clk)) { + err = PTR_ERR(div_clk); + dev_err(dev, "failed to register %s: %d\n", name, err); + return err; + } - channel->clk_parent = devm_clk_get_optional(dev, name); - if (IS_ERR(channel->clk_parent)) - return PTR_ERR(channel->clk_parent); + snprintf(name, sizeof(name), "%s#gate%u", dev_name(dev), i); + + init.name = name; + init.ops = &clk_gate_ops; + init.flags = CLK_SET_RATE_PARENT; + clk_parent[0] = __clk_get_name(div_clk); + init.parent_names = clk_parent; + init.num_parents = 1; + + channel->gate.reg = meson->base + REG_MISC_AB; + channel->gate.bit_idx = __ffs(meson_pwm_per_channel_data[i].clk_en_mask); + channel->gate.hw.init = &init; + channel->gate.flags = 0; + channel->gate.lock = &meson->lock; + + channel->clk = devm_clk_register(dev, &channel->gate.hw); + if (IS_ERR(channel->clk)) { + err = PTR_ERR(channel->clk); + dev_err(dev, "failed to register %s: %d\n", name, err); + return err; + } } return 0;
Newer versions of the PWM block use a core clock with external mux, divider, and gate. These components either don't exist any longer in the PWM block, or they are bypassed. To minimize needed changes for supporting the new version, the internal divider and gate should be handled by CCF too. I didn't see a good way to split the patch, therefore it's somewhat bigger. What it does: - The internal mux is handled by CCF already. Register also internal divider and gate with CCF, so that we have one representation of the input clock: [mux] parent of [divider] parent of [gate] - Now that CCF selects an appropriate mux parent, we don't need the DT-provided default parent any longer. Accordingly we can also omit setting the mux parent directly in the driver. - Instead of manually handling the pre-div divider value, let CCF set the input clock. Targeted input clock frequency is 0xffff * 1/period for best precision. - For the "inverted pwm disabled" scenario target an input clock frequency of 1GHz. This ensures that the remaining low pulses have minimum length. I don't have hw with the old PWM block, therefore I couldn't test this patch. With the not yet included extension for the new PWM block (channel->clock directly coming from get_clk(external_clk)) I didn't notice any problem. My system uses PWM for the CPU voltage regulator and for the SDIO 32kHz clock. Note: The clock gate in the old PWM block is permanently disabled. This seems to indicate that it's not used by the new PWM block. I'd appreciate testing on the different platforms using the old PWM block. Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> --- drivers/pwm/pwm-meson.c | 133 +++++++++++++++++++++++----------------- 1 file changed, 76 insertions(+), 57 deletions(-)