| Message ID | 20221018-clk-range-checks-fixes-v3-29-9a1358472d52@cerno.tech |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | clk: Make determine_rate mandatory for muxes | expand |
Hi Maxime, On 4/4/23 05:11, Maxime Ripard wrote: > The SoCFGPA gate clock implements a mux with a set_parent hook, but > doesn't provide a determine_rate implementation. > > This is a bit odd, since set_parent() is there to, as its name implies, > change the parent of a clock. However, the most likely candidate to > trigger that parent change is a call to clk_set_rate(), with > determine_rate() figuring out which parent is the best suited for a > given rate. > > The other trigger would be a call to clk_set_parent(), but it's far less > used, and it doesn't look like there's any obvious user for that clock. > > So, the set_parent hook is effectively unused, possibly because of an > oversight. However, it could also be an explicit decision by the > original author to avoid any reparenting but through an explicit call to > clk_set_parent(). > > The latter case would be equivalent to setting the flag > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook > to __clk_mux_determine_rate(). Indeed, if no determine_rate > implementation is provided, clk_round_rate() (through > clk_core_round_rate_nolock()) will call itself on the parent if > CLK_SET_RATE_PARENT is set, and will not change the clock rate > otherwise. __clk_mux_determine_rate() has the exact same behavior when > CLK_SET_RATE_NO_REPARENT is set. > > And if it was an oversight, then we are at least explicit about our > behavior now and it can be further refined down the line. > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > --- > drivers/clk/socfpga/clk-gate.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c > index 32ccda960f28..cbba8462a09e 100644 > --- a/drivers/clk/socfpga/clk-gate.c > +++ b/drivers/clk/socfpga/clk-gate.c > @@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw *hwclk, > > static struct clk_ops gateclk_ops = { > .recalc_rate = socfpga_clk_recalc_rate, > + .determine_rate = __clk_mux_determine_rate, > .get_parent = socfpga_clk_get_parent, > .set_parent = socfpga_clk_set_parent, > }; > @@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node) > > init.name = clk_name; > init.ops = ops; > - init.flags = 0; > + init.flags = CLK_SET_RATE_NO_REPARENT; > > init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS); > if (init.num_parents < 2) { > This patch broke SoCFPGA boot serial port. The characters are mangled. Dinh
Hi Dinh, On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote: > On 4/4/23 05:11, Maxime Ripard wrote: > > The SoCFGPA gate clock implements a mux with a set_parent hook, but > > doesn't provide a determine_rate implementation. > > > > This is a bit odd, since set_parent() is there to, as its name implies, > > change the parent of a clock. However, the most likely candidate to > > trigger that parent change is a call to clk_set_rate(), with > > determine_rate() figuring out which parent is the best suited for a > > given rate. > > > > The other trigger would be a call to clk_set_parent(), but it's far less > > used, and it doesn't look like there's any obvious user for that clock. > > > > So, the set_parent hook is effectively unused, possibly because of an > > oversight. However, it could also be an explicit decision by the > > original author to avoid any reparenting but through an explicit call to > > clk_set_parent(). > > > > The latter case would be equivalent to setting the flag > > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook > > to __clk_mux_determine_rate(). Indeed, if no determine_rate > > implementation is provided, clk_round_rate() (through > > clk_core_round_rate_nolock()) will call itself on the parent if > > CLK_SET_RATE_PARENT is set, and will not change the clock rate > > otherwise. __clk_mux_determine_rate() has the exact same behavior when > > CLK_SET_RATE_NO_REPARENT is set. > > > > And if it was an oversight, then we are at least explicit about our > > behavior now and it can be further refined down the line. > > > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > > --- > > drivers/clk/socfpga/clk-gate.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c > > index 32ccda960f28..cbba8462a09e 100644 > > --- a/drivers/clk/socfpga/clk-gate.c > > +++ b/drivers/clk/socfpga/clk-gate.c > > @@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw *hwclk, > > static struct clk_ops gateclk_ops = { > > .recalc_rate = socfpga_clk_recalc_rate, > > + .determine_rate = __clk_mux_determine_rate, > > .get_parent = socfpga_clk_get_parent, > > .set_parent = socfpga_clk_set_parent, > > }; > > @@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node) > > init.name = clk_name; > > init.ops = ops; > > - init.flags = 0; > > + init.flags = CLK_SET_RATE_NO_REPARENT; > > init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS); > > if (init.num_parents < 2) { > > > > This patch broke SoCFPGA boot serial port. The characters are mangled. Do you have any other access to that board? If so, could you dump clk_summary in debugfs with and without that patch? Maxime
Hi Maxime, On 4/25/23 09:48, Maxime Ripard wrote: > Hi Dinh, > > On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote: >> On 4/4/23 05:11, Maxime Ripard wrote: >>> The SoCFGPA gate clock implements a mux with a set_parent hook, but >>> doesn't provide a determine_rate implementation. >>> >>> This is a bit odd, since set_parent() is there to, as its name implies, >>> change the parent of a clock. However, the most likely candidate to >>> trigger that parent change is a call to clk_set_rate(), with >>> determine_rate() figuring out which parent is the best suited for a >>> given rate. >>> >>> The other trigger would be a call to clk_set_parent(), but it's far less >>> used, and it doesn't look like there's any obvious user for that clock. >>> >>> So, the set_parent hook is effectively unused, possibly because of an >>> oversight. However, it could also be an explicit decision by the >>> original author to avoid any reparenting but through an explicit call to >>> clk_set_parent(). >>> >>> The latter case would be equivalent to setting the flag >>> CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook >>> to __clk_mux_determine_rate(). Indeed, if no determine_rate >>> implementation is provided, clk_round_rate() (through >>> clk_core_round_rate_nolock()) will call itself on the parent if >>> CLK_SET_RATE_PARENT is set, and will not change the clock rate >>> otherwise. __clk_mux_determine_rate() has the exact same behavior when >>> CLK_SET_RATE_NO_REPARENT is set. >>> >>> And if it was an oversight, then we are at least explicit about our >>> behavior now and it can be further refined down the line. >>> >>> Signed-off-by: Maxime Ripard <maxime@cerno.tech> >>> --- >>> drivers/clk/socfpga/clk-gate.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c >>> index 32ccda960f28..cbba8462a09e 100644 >>> --- a/drivers/clk/socfpga/clk-gate.c >>> +++ b/drivers/clk/socfpga/clk-gate.c >>> @@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw *hwclk, >>> static struct clk_ops gateclk_ops = { >>> .recalc_rate = socfpga_clk_recalc_rate, >>> + .determine_rate = __clk_mux_determine_rate, >>> .get_parent = socfpga_clk_get_parent, >>> .set_parent = socfpga_clk_set_parent, >>> }; >>> @@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node) >>> init.name = clk_name; >>> init.ops = ops; >>> - init.flags = 0; >>> + init.flags = CLK_SET_RATE_NO_REPARENT; >>> init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS); >>> if (init.num_parents < 2) { >>> >> >> This patch broke SoCFPGA boot serial port. The characters are mangled. > > Do you have any other access to that board? If so, could you dump > clk_summary in debugfs with and without that patch? > That dump from the clk_summary are identical for both cases.
Hi Dinh, On Thu, Apr 27, 2023 at 02:09:48PM -0500, Dinh Nguyen wrote: > Hi Maxime, > > On 4/25/23 09:48, Maxime Ripard wrote: > > Hi Dinh, > > > > On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote: > > > On 4/4/23 05:11, Maxime Ripard wrote: > > > > The SoCFGPA gate clock implements a mux with a set_parent hook, but > > > > doesn't provide a determine_rate implementation. > > > > > > > > This is a bit odd, since set_parent() is there to, as its name implies, > > > > change the parent of a clock. However, the most likely candidate to > > > > trigger that parent change is a call to clk_set_rate(), with > > > > determine_rate() figuring out which parent is the best suited for a > > > > given rate. > > > > > > > > The other trigger would be a call to clk_set_parent(), but it's far less > > > > used, and it doesn't look like there's any obvious user for that clock. > > > > > > > > So, the set_parent hook is effectively unused, possibly because of an > > > > oversight. However, it could also be an explicit decision by the > > > > original author to avoid any reparenting but through an explicit call to > > > > clk_set_parent(). > > > > > > > > The latter case would be equivalent to setting the flag > > > > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook > > > > to __clk_mux_determine_rate(). Indeed, if no determine_rate > > > > implementation is provided, clk_round_rate() (through > > > > clk_core_round_rate_nolock()) will call itself on the parent if > > > > CLK_SET_RATE_PARENT is set, and will not change the clock rate > > > > otherwise. __clk_mux_determine_rate() has the exact same behavior when > > > > CLK_SET_RATE_NO_REPARENT is set. > > > > > > > > And if it was an oversight, then we are at least explicit about our > > > > behavior now and it can be further refined down the line. > > > > > > > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > > > > --- > > > > drivers/clk/socfpga/clk-gate.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c > > > > index 32ccda960f28..cbba8462a09e 100644 > > > > --- a/drivers/clk/socfpga/clk-gate.c > > > > +++ b/drivers/clk/socfpga/clk-gate.c > > > > @@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw *hwclk, > > > > static struct clk_ops gateclk_ops = { > > > > .recalc_rate = socfpga_clk_recalc_rate, > > > > + .determine_rate = __clk_mux_determine_rate, > > > > .get_parent = socfpga_clk_get_parent, > > > > .set_parent = socfpga_clk_set_parent, > > > > }; > > > > @@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node) > > > > init.name = clk_name; > > > > init.ops = ops; > > > > - init.flags = 0; > > > > + init.flags = CLK_SET_RATE_NO_REPARENT; > > > > init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS); > > > > if (init.num_parents < 2) { > > > > > > > > > > This patch broke SoCFPGA boot serial port. The characters are mangled. > > > > Do you have any other access to that board? If so, could you dump > > clk_summary in debugfs with and without that patch? > > > > That dump from the clk_summary are identical for both cases. Thanks for testing I'm a bit confused, there should be no difference in behaviour, and if there was any difference I would expect the clock tree to be somewhat different. Could you still paste the clk_summary (and dmesg) output? Which UART driver is being used? Also, is there a way for me to test it somehow? Thanks, Maxime
Hi Maxime, On 5/4/23 12:04, Maxime Ripard wrote: > Hi Dinh, > > On Thu, Apr 27, 2023 at 02:09:48PM -0500, Dinh Nguyen wrote: >> Hi Maxime, >> >> On 4/25/23 09:48, Maxime Ripard wrote: >>> Hi Dinh, >>> >>> On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote: >>>> On 4/4/23 05:11, Maxime Ripard wrote: >>>>> The SoCFGPA gate clock implements a mux with a set_parent hook, but >>>>> doesn't provide a determine_rate implementation. >>>>> >>>>> This is a bit odd, since set_parent() is there to, as its name implies, >>>>> change the parent of a clock. However, the most likely candidate to >>>>> trigger that parent change is a call to clk_set_rate(), with >>>>> determine_rate() figuring out which parent is the best suited for a >>>>> given rate. >>>>> >>>>> The other trigger would be a call to clk_set_parent(), but it's far less >>>>> used, and it doesn't look like there's any obvious user for that clock. >>>>> >>>>> So, the set_parent hook is effectively unused, possibly because of an >>>>> oversight. However, it could also be an explicit decision by the >>>>> original author to avoid any reparenting but through an explicit call to >>>>> clk_set_parent(). >>>>> >>>>> The latter case would be equivalent to setting the flag >>>>> CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook >>>>> to __clk_mux_determine_rate(). Indeed, if no determine_rate >>>>> implementation is provided, clk_round_rate() (through >>>>> clk_core_round_rate_nolock()) will call itself on the parent if >>>>> CLK_SET_RATE_PARENT is set, and will not change the clock rate >>>>> otherwise. __clk_mux_determine_rate() has the exact same behavior when >>>>> CLK_SET_RATE_NO_REPARENT is set. >>>>> >>>>> And if it was an oversight, then we are at least explicit about our >>>>> behavior now and it can be further refined down the line. >>>>> >>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech> >>>>> --- >>>>> drivers/clk/socfpga/clk-gate.c | 3 ++- >>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c >>>>> index 32ccda960f28..cbba8462a09e 100644 >>>>> --- a/drivers/clk/socfpga/clk-gate.c >>>>> +++ b/drivers/clk/socfpga/clk-gate.c >>>>> @@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw *hwclk, >>>>> static struct clk_ops gateclk_ops = { >>>>> .recalc_rate = socfpga_clk_recalc_rate, >>>>> + .determine_rate = __clk_mux_determine_rate, >>>>> .get_parent = socfpga_clk_get_parent, >>>>> .set_parent = socfpga_clk_set_parent, >>>>> }; >>>>> @@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node) >>>>> init.name = clk_name; >>>>> init.ops = ops; >>>>> - init.flags = 0; >>>>> + init.flags = CLK_SET_RATE_NO_REPARENT; >>>>> init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS); >>>>> if (init.num_parents < 2) { >>>>> >>>> >>>> This patch broke SoCFPGA boot serial port. The characters are mangled. >>> >>> Do you have any other access to that board? If so, could you dump >>> clk_summary in debugfs with and without that patch? >>> >> >> That dump from the clk_summary are identical for both cases. > > Thanks for testing > > I'm a bit confused, there should be no difference in behaviour, and if > there was any difference I would expect the clock tree to be somewhat > different. > > Could you still paste the clk_summary (and dmesg) output? Which UART > driver is being used? > > Also, is there a way for me to test it somehow? > Apologies, but there is a diff with/without this patch: With patch: < l4_sp_clk 3 3 0 100000000 0 0 50000 ? --- Without patch: > l4_sp_clk 4 4 0 100000000 0 0 50000 ? The enable/prepare count is 4 instead of 3 in the case of a working UART. The debug uart is using the lp_sp_clk. The Cyclone5 devkits are pretty cheap if you want to get one. Here is the full out of clk_summary: # cat /sys/kernel/debug/clk/clk_summary enable prepare protect duty hardware clock count count count rate accuracy phase cycle enable ------------------------------------------------------------------------------------------------------- osc1 5 5 0 25000000 0 0 50000 Y sdram_pll 0 0 0 800000000 0 0 50000 Y h2f_usr2_clk 0 0 0 133333333 0 0 50000 Y h2f_user2_clk 0 0 0 133333333 0 0 50000 ? ddr_dq_clk 0 0 0 400000000 0 0 50000 Y ddr_dq_clk_gate 0 0 0 400000000 0 0 50000 ? ddr_2x_dqs_clk 0 0 0 800000000 0 0 50000 Y ddr_2x_dqs_clk_gate 0 0 0 800000000 0 0 50000 ? ddr_dqs_clk 0 0 0 400000000 0 0 50000 Y ddr_dqs_clk_gate 0 0 0 400000000 0 0 50000 ? periph_pll 3 3 0 1000000000 0 0 50000 Y h2f_usr1_clk 0 0 0 1953125 0 0 50000 Y h2f_user1_clk 0 0 0 1953125 0 0 50000 ? per_base_clk 4 4 0 200000000 0 0 50000 Y gpio_db_clk 0 0 0 32000 0 0 50000 ? can1_clk 0 0 0 40000000 0 0 50000 ? can0_clk 0 0 0 100000000 0 0 50000 ? spi_m_clk 1 1 0 200000000 0 0 50000 ? usb_mp_clk 1 1 0 200000000 0 0 50000 ? l4_sp_clk 4 4 0 100000000 0 0 50000 ? l4_mp_clk 1 1 0 100000000 0 0 50000 ? per_nand_mmc_clk 1 1 0 200000000 0 0 50000 Y nand_x_clk 0 0 0 200000000 0 0 50000 ? nand_clk 0 0 0 50000000 0 0 50000 ? nand_ecc_clk 0 0 0 200000000 0 0 50000 ? sdmmc_clk 1 1 0 200000000 0 0 50000 ? sdmmc_clk_divided 1 1 0 50000000 0 0 50000 ? per_qsi_clk 0 0 0 1953125 0 0 50000 Y emac1_clk 1 1 0 250000000 0 0 50000 Y emac_1_clk 1 1 0 250000000 0 0 50000 ? emac0_clk 0 0 0 1953125 0 0 50000 Y emac_0_clk 0 0 0 1953125 0 0 50000 ? dbg_base_clk 0 0 0 6250000 0 0 50000 Y dbg_timer_clk 0 0 0 6250000 0 0 50000 ? dbg_trace_clk 0 0 0 6250000 0 0 50000 ? dbg_at_clk 0 0 0 6250000 0 0 50000 ? dbg_clk 0 0 0 3125000 0 0 50000 ? main_pll 2 3 0 1850000000 0 0 50000 Y cfg_h2f_usr0_clk 0 0 0 123333333 0 0 50000 Y h2f_user0_clk 0 0 0 123333333 0 0 50000 ? cfg_clk 0 0 0 123333333 0 0 50000 ? main_nand_sdmmc_clk 0 0 0 3613281 0 0 50000 Y main_qspi_clk 1 1 0 370000000 0 0 50000 Y qspi_clk 1 1 0 370000000 0 0 50000 ? mainclk 0 1 0 370000000 0 0 50000 Y l3_mp_clk 0 0 0 185000000 0 0 50000 ? l3_sp_clk 0 0 0 92500000 0 0 50000 Y l3_main_clk 0 0 0 370000000 0 0 50000 Y l4_main_clk 0 1 0 370000000 0 0 50000 ? mpuclk 1 1 0 925000000 0 0 50000 Y mpu_l2_ram_clk 0 0 0 462500000 0 0 50000 Y mpu_periph_clk 1 1 0 231250000 0 0 50000 Y Dinh
Hi Dinh, On Tue, May 09, 2023 at 12:37:39PM -0500, Dinh Nguyen wrote: > Hi Maxime, > > On 5/4/23 12:04, Maxime Ripard wrote: > > Hi Dinh, > > > > On Thu, Apr 27, 2023 at 02:09:48PM -0500, Dinh Nguyen wrote: > > > Hi Maxime, > > > > > > On 4/25/23 09:48, Maxime Ripard wrote: > > > > Hi Dinh, > > > > > > > > On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote: > > > > > On 4/4/23 05:11, Maxime Ripard wrote: > > > > > > The SoCFGPA gate clock implements a mux with a set_parent hook, but > > > > > > doesn't provide a determine_rate implementation. > > > > > > > > > > > > This is a bit odd, since set_parent() is there to, as its name implies, > > > > > > change the parent of a clock. However, the most likely candidate to > > > > > > trigger that parent change is a call to clk_set_rate(), with > > > > > > determine_rate() figuring out which parent is the best suited for a > > > > > > given rate. > > > > > > > > > > > > The other trigger would be a call to clk_set_parent(), but it's far less > > > > > > used, and it doesn't look like there's any obvious user for that clock. > > > > > > > > > > > > So, the set_parent hook is effectively unused, possibly because of an > > > > > > oversight. However, it could also be an explicit decision by the > > > > > > original author to avoid any reparenting but through an explicit call to > > > > > > clk_set_parent(). > > > > > > > > > > > > The latter case would be equivalent to setting the flag > > > > > > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook > > > > > > to __clk_mux_determine_rate(). Indeed, if no determine_rate > > > > > > implementation is provided, clk_round_rate() (through > > > > > > clk_core_round_rate_nolock()) will call itself on the parent if > > > > > > CLK_SET_RATE_PARENT is set, and will not change the clock rate > > > > > > otherwise. __clk_mux_determine_rate() has the exact same behavior when > > > > > > CLK_SET_RATE_NO_REPARENT is set. > > > > > > > > > > > > And if it was an oversight, then we are at least explicit about our > > > > > > behavior now and it can be further refined down the line. > > > > > > > > > > > > Signed-off-by: Maxime Ripard <maxime@cerno.tech> > > > > > > --- > > > > > > drivers/clk/socfpga/clk-gate.c | 3 ++- > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c > > > > > > index 32ccda960f28..cbba8462a09e 100644 > > > > > > --- a/drivers/clk/socfpga/clk-gate.c > > > > > > +++ b/drivers/clk/socfpga/clk-gate.c > > > > > > @@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw *hwclk, > > > > > > static struct clk_ops gateclk_ops = { > > > > > > .recalc_rate = socfpga_clk_recalc_rate, > > > > > > + .determine_rate = __clk_mux_determine_rate, > > > > > > .get_parent = socfpga_clk_get_parent, > > > > > > .set_parent = socfpga_clk_set_parent, > > > > > > }; > > > > > > @@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node) > > > > > > init.name = clk_name; > > > > > > init.ops = ops; > > > > > > - init.flags = 0; > > > > > > + init.flags = CLK_SET_RATE_NO_REPARENT; > > > > > > init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS); > > > > > > if (init.num_parents < 2) { > > > > > > > > > > > > > > > > This patch broke SoCFPGA boot serial port. The characters are mangled. > > > > > > > > Do you have any other access to that board? If so, could you dump > > > > clk_summary in debugfs with and without that patch? > > > > > > > > > > That dump from the clk_summary are identical for both cases. > > > > Thanks for testing > > > > I'm a bit confused, there should be no difference in behaviour, and if > > there was any difference I would expect the clock tree to be somewhat > > different. > > > > Could you still paste the clk_summary (and dmesg) output? Which UART > > driver is being used? > > > > Also, is there a way for me to test it somehow? > > > > Apologies, but there is a diff with/without this patch: > > With patch: > < l4_sp_clk 3 3 0 100000000 > 0 0 50000 ? > --- > Without patch: > > l4_sp_clk 4 4 0 100000000 > 0 0 50000 ? > > The enable/prepare count is 4 instead of 3 in the case of a working UART. > The debug uart is using the lp_sp_clk. This is pretty weird, the enable count shouldn't change, really, we're only changing something in the rate rounding path... Is it using the snps,dw-apb-uart driver? Nothing shows up in dmesg? > The Cyclone5 devkits are pretty cheap if you want to get one. Are you talking about the DE10-Nano? It seems out of stock everywhere in Europe :/ Thanks! Maxime
diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c index 32ccda960f28..cbba8462a09e 100644 --- a/drivers/clk/socfpga/clk-gate.c +++ b/drivers/clk/socfpga/clk-gate.c @@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw *hwclk, static struct clk_ops gateclk_ops = { .recalc_rate = socfpga_clk_recalc_rate, + .determine_rate = __clk_mux_determine_rate, .get_parent = socfpga_clk_get_parent, .set_parent = socfpga_clk_set_parent, }; @@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node) init.name = clk_name; init.ops = ops; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT; init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS); if (init.num_parents < 2) {
The SoCFGPA gate clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Signed-off-by: Maxime Ripard <maxime@cerno.tech> --- drivers/clk/socfpga/clk-gate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)