[PATCH v2] clk: clk-gpio: propagate rate change to parent

[PATCH v2] clk: clk-gpio: propagate rate change to parent

[Alexandru Ardelean]

From: Michael Hennerich <michael.hennerich@analog.com>

For an external clock source, which is gated or (mux-ed) via a GPIO, the
rate change should typically be propagated to the parent clock.

The situation where we are requiring this propagation, is when an
external clock is connected to override an internal clock (which typically
has a fixed rate). The external clock can have a different rate than the
internal one, and may also be variable, thus requiring the rate
propagation.

This rate change wasn't propagated until now, and it's unclear about cases
where this shouldn't be propagated. Thus, it's unclear whether this is
fixing a bug, or extending the current driver behavior. Also, it's unsure
about whether this may break any existing setups; in the case that it does,
a device-tree property may be added to disable this flag.

Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
 drivers/clk/clk-gpio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 9d930edd6516..255ed505444c 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -276,11 +276,12 @@ static int gpio_clk_driver_probe(struct platform_device *pdev)
 
 	if (is_mux)
 		clk = clk_register_gpio_mux(&pdev->dev, node->name,
-				parent_names, num_parents, gpiod, 0);
+				parent_names, num_parents, gpiod,
+				CLK_SET_RATE_PARENT);
 	else
 		clk = clk_register_gpio_gate(&pdev->dev, node->name,
 				parent_names ?  parent_names[0] : NULL, gpiod,
-				0);
+				CLK_SET_RATE_PARENT);
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
-- 
2.20.1

[PATCH v3] clk: clk-gpio: propagate rate change to parent

[Alexandru Ardelean]

From: Michael Hennerich <michael.hennerich@analog.com>

For an external clock source, which is gated via a GPIO, the
rate change should typically be propagated to the parent clock.

The situation where we are requiring this propagation, is when an
external clock is connected to override an internal clock (which typically
has a fixed rate). The external clock can have a different rate than the
internal one, and may also be variable, thus requiring the rate
propagation.

This rate change wasn't propagated until now, and it's unclear about cases
where this shouldn't be propagated. Thus, it's unclear whether this is
fixing a bug, or extending the current driver behavior. Also, it's unsure
about whether this may break any existing setups; in the case that it does,
a device-tree property may be added to disable this flag.

Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---

Changelog v2 -> v3:
* limited CLK_SET_RATE_PARENT to both gate clk-gpio drivers; did not pay
  close attention to Stephen's comment when he mentioned to only the gate
  clk-gpio driver

Changelog v1 -> v2:
* added CLK_SET_RATE_PARENT to both gate & mux clk-gpio drivers

 drivers/clk/clk-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 9d930edd6516..13304cf5f2a8 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -280,7 +280,7 @@ static int gpio_clk_driver_probe(struct platform_device *pdev)
 	else
 		clk = clk_register_gpio_gate(&pdev->dev, node->name,
 				parent_names ?  parent_names[0] : NULL, gpiod,
-				0);
+				CLK_SET_RATE_PARENT);
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
-- 
2.20.1

Re: [PATCH v3] clk: clk-gpio: propagate rate change to parent

[Stephen Boyd]

Quoting Alexandru Ardelean (2019-11-07 23:17:18)
> From: Michael Hennerich <michael.hennerich@analog.com>
> 
> For an external clock source, which is gated via a GPIO, the
> rate change should typically be propagated to the parent clock.
> 
> The situation where we are requiring this propagation, is when an
> external clock is connected to override an internal clock (which typically
> has a fixed rate). The external clock can have a different rate than the
> internal one, and may also be variable, thus requiring the rate
> propagation.
> 
> This rate change wasn't propagated until now, and it's unclear about cases
> where this shouldn't be propagated. Thus, it's unclear whether this is
> fixing a bug, or extending the current driver behavior. Also, it's unsure
> about whether this may break any existing setups; in the case that it does,
> a device-tree property may be added to disable this flag.
> 
> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---

Applied to clk-next

Next time please send as a new topic instead of a reply to the original
patch. Makes it easier for me to apply the patch.

Re: [PATCH v3] clk: clk-gpio: propagate rate change to parent

[Ardelean, Alexandru]

On Fri, 2019-11-08 at 13:08 -0800, Stephen Boyd wrote:
> Quoting Alexandru Ardelean (2019-11-07 23:17:18)
> > From: Michael Hennerich <michael.hennerich@analog.com>
> > 
> > For an external clock source, which is gated via a GPIO, the
> > rate change should typically be propagated to the parent clock.
> > 
> > The situation where we are requiring this propagation, is when an
> > external clock is connected to override an internal clock (which
> > typically
> > has a fixed rate). The external clock can have a different rate than
> > the
> > internal one, and may also be variable, thus requiring the rate
> > propagation.
> > 
> > This rate change wasn't propagated until now, and it's unclear about
> > cases
> > where this shouldn't be propagated. Thus, it's unclear whether this is
> > fixing a bug, or extending the current driver behavior. Also, it's
> > unsure
> > about whether this may break any existing setups; in the case that it
> > does,
> > a device-tree property may be added to disable this flag.
> > 
> > Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> 
> Applied to clk-next
> 
> Next time please send as a new topic instead of a reply to the original
> patch. Makes it easier for me to apply the patch.
> 

Ack.
Will do that.

Thanks
Alex