Re: [PATCH 1/4] clk: meson: mpll: add init callback and regs

[Michael Turquette]

Hi Jerome,

On Mon, Apr 8, 2019 at 9:38 AM Jerome Brunet  wrote:
>
> On Fri, 2019-04-05 at 13:43 -0700, Stephen Boyd wrote:
> > Quoting Michael Turquette (2019-04-05 08:43:40)
> > > Hi Jerome,
> > >
> > > On Fri, Mar 29, 2019 at 3:58 PM Jerome Brunet  
> > > wrote:
> > > > On Fri, 2019-03-29 at 15:14 -0700, Stephen Boyd wrote:
> > > > > > > We actively discourage using init callbacks. Can you do this some 
> > > > > > > other
> > > > > > > way?
> > > > > >
> > > > > > Yes I'm aware of that but init it the right place to do this.
> > > > > > To be clear, this is not initializing the clock to some particular 
> > > > > > rate, the
> > > > > > rate is preserved.
> > > > > >
> > > > > > It just applies the necessary settings that needs to be done only 
> > > > > > once to make
> > > > > > sure the clock is in working order and that the rate calculated is 
> > > > > > actually
> > > > > > accurate.
> > > > >
> > > > > Ok, but can you do that in your driver's probe routine instead of
> > > > > attaching to the init callback? We want to get rid of "init" at some
> > > > > point so throwing the init sequence stuff into the driver probe around
> > > > > registration is a solution. Or we should think about not discouraging
> > > > > the init callback
> > > >
> > > > Is is callback really a problem after all ?
> > >
> > > It is a problem, insofar as Stephen and I want to remove .init some day.
> > >
> > > > I think we should actively prevent using it to set a particular rate.
> > > >
> > > > Here, the goal is put the clock in working order. The bootloader does 
> > > > not
> > > > always do that for us.
> > >
> > > The above two sentences make it sound like this sequence belongs in 
> > > .prepare().
> > >
> > > I know that you're concerned with setting rate, but I guess it is safe
> > > to assume that you'll always complete .prepare() before you begin to
> > > execute .set_rate(), no? This also avoids the ugliness of putting it
> > > in the .probe(), which I agree doesn't feel like an accurate thing to
> > > do for a clock's own programming sequence.
> > >
> > > .probe() is an OK place to put policy (turn these clocks on or set
> > > them to this rate, for a known-good configuration).
> > >
> >
> > Following along with this reasoning, maybe we need a 'prepare_once'
> > callback that does this the first time the clk is prepared or set_rate
> > is called on it. The problem I have with the init callback is that the
> > semantics of when it's called and what has happened before it's called
> > isn't clearly defined. I'm afraid to remove it and also afraid to move
> > around where it's called from. I've been itching to get it out of under
> > all the locks we're holding at registration time, but I don't know if
> > that's feasible, for example.
> >
>
> If removing .init() is important for you, I would prefer to help guys. That
> being said, we need a decent solution to some use case if this is going to
> work.
>
> I'll illustrate with examples from the meson code but I think they represent
> fairly common cases:
>
> 1) clk-pll: Without the work done init(), the pll just won't lock ...
>
> I agree that we would see the problem when the clock is finally enabled, so we
> could do "init" sequence in .prepare() each time it is called. The sequence
> might be "long" (with a couple of delays in it) so doing it on each call to
> .prepare() is wasting time but it could work.
>
> Something like .prepare_once would help for this.
>
> 2) clk-mpll: Without the work done in .init(), the fractional part of the
> divider will not work, only the integer part works => the rate calculated is
> off by a significant margin. IOW, until the initial setup is done, the result
> of .recalc_rate() is off and cannot be trusted.
>
> .prepare() (and .prepare_once() if called a the same stage) is too late. We
> would need something that runs before any call to .recalc_rate() is made.
>
> We could also think about clocks with the ability to observe and feedback
> (read-only) on the actual output signal. Such thing might need an initial()
> setup as well.
>
> 3) sclk: This is a kind of divider which gates when the value is zero. We need
> t

Re: [PATCH 1/4] clk: meson: mpll: add init callback and regs

[Michael Turquette]

Hi Jerome,

On Fri, Mar 29, 2019 at 3:58 PM Jerome Brunet  wrote:
>
> On Fri, 2019-03-29 at 15:14 -0700, Stephen Boyd wrote:
> > > > We actively discourage using init callbacks. Can you do this some other
> > > > way?
> > >
> > > Yes I'm aware of that but init it the right place to do this.
> > > To be clear, this is not initializing the clock to some particular rate, 
> > > the
> > > rate is preserved.
> > >
> > > It just applies the necessary settings that needs to be done only once to 
> > > make
> > > sure the clock is in working order and that the rate calculated is 
> > > actually
> > > accurate.
> >
> > Ok, but can you do that in your driver's probe routine instead of
> > attaching to the init callback? We want to get rid of "init" at some
> > point so throwing the init sequence stuff into the driver probe around
> > registration is a solution. Or we should think about not discouraging
> > the init callback
>
> Is is callback really a problem after all ?

It is a problem, insofar as Stephen and I want to remove .init some day.

> I think we should actively prevent using it to set a particular rate.
>
> Here, the goal is put the clock in working order. The bootloader does not
> always do that for us.

The above two sentences make it sound like this sequence belongs in .prepare().

I know that you're concerned with setting rate, but I guess it is safe
to assume that you'll always complete .prepare() before you begin to
execute .set_rate(), no? This also avoids the ugliness of putting it
in the .probe(), which I agree doesn't feel like an accurate thing to
do for a clock's own programming sequence.

.probe() is an OK place to put policy (turn these clocks on or set
them to this rate, for a known-good configuration).

Thanks,
Mike

> I could put this in controller driver, but I would have
> to repeat the init pattern for each instance of the clock...not nice
> Using the callback clearly shows the relationship between the init and the
> clock. I think it is a lot better.
>
> In the same series, I have added some init for the controller. In this case
> the init target a group of clocks, so having the init in the controller makes
> sense for that
>
>
>


-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/
Schedule a meeting: https://calendly.com/mturquette

Re: [RFC PATCH 0/3] Add support of busfreq

[Michael Turquette]

Hi Alex,

Some nitpick review comments below.

On Wed, Mar 13, 2019 at 12:33 PM Alexandre Bailon  wrote:
>
> This series implements busfreq, a framework used in MXP's

s/MXP/NXP/

> tree to scale the interconnect and dram frequencies.
> In the vendor tree, device's driver request for a
> performance level, which is used to scale the frequencies.
> This series implements it using the interconnect framework.
> Devices' driver request for bandwidth which is use by busfreq
> to determine a performance level, and then scale the frequency.
>
> Busfreq is quite generic. It could be used for any i.MX SoC.
> A busfreq platform driver just have to define a list of
> interconnect nodes, and some OPPs.
>
> This series is sent as RFC mostly because the current support
> of i.MX SoC won't benefit of busfreq framework, because the
> clocks' driver don't support interconnect / dram frequency
> scaling.

In your v2 cover letter could you post a link to a git branch that has
everything integrated that is needed to test the series? I guess this
is similar to what Aisheng asked for already.

> As exemple, this series implements busfreq for i.MX8MM whose
> upstreaming is in progress. Because this relies on ATF to
> do the frequency scaling, it won't be hard make it work.

It's not clear to me whether this series actual scales the dram
frequency based on what you said above. Is it just theoretical or do
you have it working with a pile of out-of-tree patches? Would be good
to include that pile of patches in your integration branch that I
suggested above.

Thanks,
Mike

>
> As exemple, this series implements busfreq for
> Alexandre Bailon (3):
>   drivers: interconnect: Add a driver for i.MX SoC
>   drivers: interconnect: imx: Add support of i.MX8MM
>   dt-bindings: interconnect: Document fsl,busfreq-imx8mm bindings
>
>  .../bindings/interconnect/imx8mm.txt  |  24 +
>  drivers/interconnect/Kconfig  |   1 +
>  drivers/interconnect/Makefile |   1 +
>  drivers/interconnect/imx/Kconfig  |  17 +
>  drivers/interconnect/imx/Makefile |   2 +
>  drivers/interconnect/imx/busfreq-imx8mm.c | 132 
>  drivers/interconnect/imx/busfreq.c| 570 ++
>  drivers/interconnect/imx/busfreq.h| 123 
>  include/dt-bindings/interconnect/imx8mm.h |  37 ++
>  9 files changed, 907 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interconnect/imx8mm.txt
>  create mode 100644 drivers/interconnect/imx/Kconfig
>  create mode 100644 drivers/interconnect/imx/Makefile
>  create mode 100644 drivers/interconnect/imx/busfreq-imx8mm.c
>  create mode 100644 drivers/interconnect/imx/busfreq.c
>  create mode 100644 drivers/interconnect/imx/busfreq.h
>  create mode 100644 include/dt-bindings/interconnect/imx8mm.h
>
> --
> 2.19.2



-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/
Schedule a meeting: https://calendly.com/mturquette

Re: [PATCH v12 0/7] Introduce on-chip interconnect API

[Michael Turquette]

Hi Olof, Georgi,

Happy new year! :-)

Quoting Georgi Djakov (2018-12-08 21:15:35)
> Hi Olof,
> 
> On 9.12.18 2:33, Olof Johansson wrote:
> > Hi Georgi,
> > 
> > On Sat, Dec 8, 2018 at 9:02 AM Georgi Djakov  
> > wrote:
> >>
> >> Modern SoCs have multiple processors and various dedicated cores (video, 
> >> gpu,
> >> graphics, modem). These cores are talking to each other and can generate a
> >> lot of data flowing through the on-chip interconnects. These interconnect
> >> buses could form different topologies such as crossbar, point to point 
> >> buses,
> >> hierarchical buses or use the network-on-chip concept.
> >>
> >> These buses have been sized usually to handle use cases with high data
> >> throughput but it is not necessary all the time and consume a lot of power.
> >> Furthermore, the priority between masters can vary depending on the running
> >> use case like video playback or CPU intensive tasks.
> >>
> >> Having an API to control the requirement of the system in terms of 
> >> bandwidth
> >> and QoS, so we can adapt the interconnect configuration to match those by
> >> scaling the frequencies, setting link priority and tuning QoS parameters.
> >> This configuration can be a static, one-time operation done at boot for 
> >> some
> >> platforms or a dynamic set of operations that happen at run-time.
> >>
> >> This patchset introduce a new API to get the requirement and configure the
> >> interconnect buses across the entire chipset to fit with the current 
> >> demand.
> >> The API is NOT for changing the performance of the endpoint devices, but 
> >> only
> >> the interconnect path in between them.
> >>
> >> The API is using a consumer/provider-based model, where the providers are
> >> the interconnect buses and the consumers could be various drivers.
> >> The consumers request interconnect resources (path) to an endpoint and set
> >> the desired constraints on this data flow path. The provider(s) receive
> >> requests from consumers and aggregate these requests for all master-slave
> >> pairs on that path. Then the providers configure each participating in the
> >> topology node according to the requested data flow path, physical links and
> >> constraints. The topology could be complicated and multi-tiered and is SoC
> >> specific.
> > 
> > This patch series description fails to describe why you need a brand
> > new subsystem for this instead of either using one of the current
> > ones, or adapting it to fit the needs you have.
> > 
> > Primarily, I'm wondering what's missing from drivers/devfreq to fit your 
> > needs?
> 
> The devfreq subsystem seems to be more oriented towards a device (like
> GPU or CPU) that controls the power/performance characteristics by
> itself and not the performance of other devices. The main problem of
> using it is that it's using a reactive approach - for example monitor
> some performance counters and then reconfigure bandwidth after some
> bottleneck has already occurred. This is suboptimal and might not work
> well. The new solution does the opposite by allowing drivers to
> express their needs in advance and be proactive. Devfreq also does not
> seem suitable for configuring complex, multi-tiered bus topologies and
> aggregating constraints provided by drivers.

[reflowed Georgi's responses]

Agreed that devfreq is not good for this. Like any good driver
framework, the interconnect framework provides a client/consumer api to
device drivers to express their needs (in this case, throughput over a
bus or interconnect).

On modern SoCs these topologies can be quite complicated, which requires
a provider api.

I think that a dedicated framework makes sense for this.

> 
> > The series also doesn't seem to provide any kind of indication how
> > this will be used by end points. You have one driver for one SoC that
> > just contains large tables that are parsed at probe time, but no
> > driver hooks anywhere that will actually change any settings depending
> > on use cases. Also, the bindings as posted don't seem to include any
> > of this kind of information. So it's hard to get a picture of how this
> > is going to be used in reality, which makes it hard to judge whether
> > it is a good solution or not.
> 
> Here are links to some of the examples that are on the mailing list
> already. I really should have  included them in the cover letter. 
> https://lkml.org/lkml/2018/12/7/584
> https://lkml.org/lkml/2018/10/11/499
> https://lkml.org/lkml/2018/9/20/986
> https://lkml.org/lkml/2018/11/22/772
> 
> Platforms drivers for different SoCs are available:
> https://lkml.org/lkml/2018/11/17/368
> https://lkml.org/lkml/2018/8/10/380
> There is a discussion on linux-pm about supporting also Tegra
> platforms in addition to NXP and Qualcomm.

Just FYI, Alex will renew his efforts to port iMX over to this framework
after the new year.

I honestly don't know if this series is ready to be merged or not. I
stopped reviewing it a long time ago. But there is interest in the 

Re: [PATCH RESEND V4 1/9] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk support

[Michael Turquette]

Hi Dong,

Quoting A.s. Dong (2018-10-21 06:10:48)
> For dividers with zero indicating clock is disabled, instead of giving a
> warning each time like "clkx: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not
> set" in exist code, we'd like to introduce enable/disable function for it.
> e.g.
> 000b - Clock disabled
> 001b - Divide by 1
> 010b - Divide by 2
> ...

I feel bad to NAK this patch after it's been on the list for so long,
but this implementation really should belong in your hardware specific
clock provider driver.

This patch expands clk-divider to also be a gate, which is a
non-starter.  Basic clock types were meant to remain basic. I'm already
imagining how this precedent would cause other submissions: "why should
I use composite clock when we can just add new clk_ops to the basic
clock types!" :-(

Also the implementation becomes cleaner when you don't have to make it
coexist with clk-divider.c. You can drop the flags and just implement a
machine specific clock type that combines gates and dividers.

Best regards,
Mike

> 
> Set rate when the clk is disabled will cache the rate request and only
> when the clk is enabled will the driver actually program the hardware to
> have the requested divider value. Similarly, when the clk is disabled we'll
> write a 0 there, but when the clk is enabled we'll restore whatever rate
> (divider) was chosen last.
> 
> It does mean that recalc rate will be sort of odd, because when the clk is
> off it will return 0, and when the clk is on it will return the right rate.
> So to make things work, we'll need to return the cached rate in recalc rate
> when the clk is off and read the hardware when the clk is on.
> 
> NOTE for the default off divider, the recalc rate will still return 0 as
> there's still no proper preset rate. Enable such divider will give user
> a reminder error message.
> 
> Cc: Stephen Boyd 
> Cc: Michael Turquette 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> 
> ---
> ChangeLog:
> v3->v4:
>  * no changes
> v2->v3:
>  * split normal and gate ops
>  * fix the possible racy
> v1->v2:
>  * add enable/disable for the type of CLK_DIVIDER_ZERO_GATE dividers
> ---
>  drivers/clk/clk-divider.c| 152 
> +++
>  include/linux/clk-provider.h |   9 +++
>  2 files changed, 161 insertions(+)
> 
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index b6234a5..b3566fd 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -122,6 +122,9 @@ unsigned long divider_recalc_rate(struct clk_hw *hw, 
> unsigned long parent_rate,
>  
> div = _get_div(table, val, flags, width);
> if (!div) {
> +   if (flags & CLK_DIVIDER_ZERO_GATE)
> +   return 0;
> +
> WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO),
> "%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not 
> set\n",
> clk_hw_get_name(hw));
> @@ -145,6 +148,34 @@ static unsigned long clk_divider_recalc_rate(struct 
> clk_hw *hw,
>divider->flags, divider->width);
>  }
>  
> +static unsigned long clk_divider_gate_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> +   struct clk_divider *divider = to_clk_divider(hw);
> +   unsigned long flags = 0;
> +   unsigned int val;
> +
> +   if (divider->lock)
> +   spin_lock_irqsave(divider->lock, flags);
> +   else
> +   __acquire(divider->lock);
> +
> +   if (!clk_hw_is_enabled(hw)) {
> +   val = divider->cached_val;
> +   } else {
> +   val = clk_readl(divider->reg) >> divider->shift;
> +   val &= clk_div_mask(divider->width);
> +   }
> +
> +   if (divider->lock)
> +   spin_unlock_irqrestore(divider->lock, flags);
> +   else
> +   __release(divider->lock);
> +
> +   return divider_recalc_rate(hw, parent_rate, val, divider->table,
> +  divider->flags, divider->width);
> +}
> +
>  static bool _is_valid_table_div(const struct clk_div_table *table,
>  unsigned int div)
>  {
> @@ -437,6 +468,108 @@ static int clk_divider_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> return 0;
>  }
>  
> +static int clk_divider_gate_set_rate(struct clk_hw *hw, unsigned long rate,
> +   unsigned long parent_rate)
> +{
> +   struct clk_

Re: [PATCH RESEND V4 1/9] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk support

[Michael Turquette]

Hi Dong,

Quoting A.s. Dong (2018-10-21 06:10:48)
> For dividers with zero indicating clock is disabled, instead of giving a
> warning each time like "clkx: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not
> set" in exist code, we'd like to introduce enable/disable function for it.
> e.g.
> 000b - Clock disabled
> 001b - Divide by 1
> 010b - Divide by 2
> ...

I feel bad to NAK this patch after it's been on the list for so long,
but this implementation really should belong in your hardware specific
clock provider driver.

This patch expands clk-divider to also be a gate, which is a
non-starter.  Basic clock types were meant to remain basic. I'm already
imagining how this precedent would cause other submissions: "why should
I use composite clock when we can just add new clk_ops to the basic
clock types!" :-(

Also the implementation becomes cleaner when you don't have to make it
coexist with clk-divider.c. You can drop the flags and just implement a
machine specific clock type that combines gates and dividers.

Best regards,
Mike

> 
> Set rate when the clk is disabled will cache the rate request and only
> when the clk is enabled will the driver actually program the hardware to
> have the requested divider value. Similarly, when the clk is disabled we'll
> write a 0 there, but when the clk is enabled we'll restore whatever rate
> (divider) was chosen last.
> 
> It does mean that recalc rate will be sort of odd, because when the clk is
> off it will return 0, and when the clk is on it will return the right rate.
> So to make things work, we'll need to return the cached rate in recalc rate
> when the clk is off and read the hardware when the clk is on.
> 
> NOTE for the default off divider, the recalc rate will still return 0 as
> there's still no proper preset rate. Enable such divider will give user
> a reminder error message.
> 
> Cc: Stephen Boyd 
> Cc: Michael Turquette 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> 
> ---
> ChangeLog:
> v3->v4:
>  * no changes
> v2->v3:
>  * split normal and gate ops
>  * fix the possible racy
> v1->v2:
>  * add enable/disable for the type of CLK_DIVIDER_ZERO_GATE dividers
> ---
>  drivers/clk/clk-divider.c| 152 
> +++
>  include/linux/clk-provider.h |   9 +++
>  2 files changed, 161 insertions(+)
> 
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index b6234a5..b3566fd 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -122,6 +122,9 @@ unsigned long divider_recalc_rate(struct clk_hw *hw, 
> unsigned long parent_rate,
>  
> div = _get_div(table, val, flags, width);
> if (!div) {
> +   if (flags & CLK_DIVIDER_ZERO_GATE)
> +   return 0;
> +
> WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO),
> "%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not 
> set\n",
> clk_hw_get_name(hw));
> @@ -145,6 +148,34 @@ static unsigned long clk_divider_recalc_rate(struct 
> clk_hw *hw,
>divider->flags, divider->width);
>  }
>  
> +static unsigned long clk_divider_gate_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> +   struct clk_divider *divider = to_clk_divider(hw);
> +   unsigned long flags = 0;
> +   unsigned int val;
> +
> +   if (divider->lock)
> +   spin_lock_irqsave(divider->lock, flags);
> +   else
> +   __acquire(divider->lock);
> +
> +   if (!clk_hw_is_enabled(hw)) {
> +   val = divider->cached_val;
> +   } else {
> +   val = clk_readl(divider->reg) >> divider->shift;
> +   val &= clk_div_mask(divider->width);
> +   }
> +
> +   if (divider->lock)
> +   spin_unlock_irqrestore(divider->lock, flags);
> +   else
> +   __release(divider->lock);
> +
> +   return divider_recalc_rate(hw, parent_rate, val, divider->table,
> +  divider->flags, divider->width);
> +}
> +
>  static bool _is_valid_table_div(const struct clk_div_table *table,
>  unsigned int div)
>  {
> @@ -437,6 +468,108 @@ static int clk_divider_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> return 0;
>  }
>  
> +static int clk_divider_gate_set_rate(struct clk_hw *hw, unsigned long rate,
> +   unsigned long parent_rate)
> +{
> +   struct clk_

Re: [PATCH] MAINTAINERS: add myself as co-maintainer of gpiolib

[Michael Turquette]

Quoting Linus Walleij (2018-10-25 04:15:52)
> On Wed, Oct 24, 2018 at 5:39 PM Bartosz Golaszewski  wrote:
> 
> > From: Bartosz Golaszewski 
> >
> > As discussed with Linus Walleij - I'm adding myself as
> > the co-maintainer.
> >
> > Cc: Benoît Cousson 
> > Cc: Kevin Hilman 
> > Cc: Michael Turquette 
> > Signed-off-by: Bartosz Golaszewski 
> 
> Excellent, patch applied for fixes. Welcome aboard! :D

Completely unnecessary:

Acked-by: Michael Turquette 

;-)

Best regards,
Mike

> 
> Yours,
> Linus Walleij

Re: [PATCH] MAINTAINERS: add myself as co-maintainer of gpiolib

[Michael Turquette]

Quoting Linus Walleij (2018-10-25 04:15:52)
> On Wed, Oct 24, 2018 at 5:39 PM Bartosz Golaszewski  wrote:
> 
> > From: Bartosz Golaszewski 
> >
> > As discussed with Linus Walleij - I'm adding myself as
> > the co-maintainer.
> >
> > Cc: Benoît Cousson 
> > Cc: Kevin Hilman 
> > Cc: Michael Turquette 
> > Signed-off-by: Bartosz Golaszewski 
> 
> Excellent, patch applied for fixes. Welcome aboard! :D

Completely unnecessary:

Acked-by: Michael Turquette 

;-)

Best regards,
Mike

> 
> Yours,
> Linus Walleij

Re: [PATCH] clk: meson-gxbb: set fclk_div3 as CLK_IS_CRITICAL

[Michael Turquette]

Quoting Christian Hewitt (2018-10-13 12:04:46)
> On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
> with reboot; e.g. a ~60 second delay between issuing reboot and the
> board power cycling (and in some OS configurations reboot will fail
> and require manual power cycling).
> 
> Similar to 'commit c987ac6f1f088663b6dad39281071aeb31d450a8 ("clk:
> meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL")' the SCPI Cortex-M4
> Co-Processor seems to depend on FCLK_DIV3 being operational.
> 
> Bisect gives 'commit 05f814402d6174369b3b29832cbb5eb5ed287059 ("clk:
> meson: add fdiv clock gates") between 4.16 and 4.16-rc1 as the first
> bad commit. This added support for the missing clock gates before the
> fixed PLL fixed dividers (FCLK_DIVx) and the clock framework which
> disabled all the unused fixed dividers, thus it disabled a critical
> clock path for the SCPI Co-Processor.
> 
> This change simply sets the FCLK_DIV3 gate as critical to ensure
> nothing can disable it.

I'm a bit skeptical of this. If FCLK_DIV3 is gated at run-time, there is
no side effect other than long and/or failed reboot?

Seems like someone should be managing this clock, and simply leaving it
on all the time isn't necessarily the right approach. Any chance that
you can dig into this behavior to better understand it?

It's easy to solve issues by leaving clocks on all the time, but this
becomes a problem later on when trying to tune a device for power.

Also, if this commit really is the right fix, it should include a
comment for FCLK_DIV3 stating why the CLK_IS_CRITICAL flag was set,
which may be helpful later on to know if it is safe to remove it. Same
is true for FCLK_DIV2 in c987ac6f1f088663b6dad39281071aeb31d450a8.

Regards,
Mike

> 
> Signed-off-by: Christian Hewitt 
> ---
>  drivers/clk/meson/gxbb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 86d3ae5..4c8925d 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -509,6 +509,7 @@ static struct clk_fixed_factor gxbb_fclk_div3_div = {
> .ops = _fixed_factor_ops,
> .parent_names = (const char *[]){ "fixed_pll" },
> .num_parents = 1,
> +   .flags = CLK_IS_CRITICAL,
> },
>  };
>  
> -- 
> 2.7.4

Re: [PATCH] clk: meson-gxbb: set fclk_div3 as CLK_IS_CRITICAL

[Michael Turquette]

Quoting Christian Hewitt (2018-10-13 12:04:46)
> On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
> with reboot; e.g. a ~60 second delay between issuing reboot and the
> board power cycling (and in some OS configurations reboot will fail
> and require manual power cycling).
> 
> Similar to 'commit c987ac6f1f088663b6dad39281071aeb31d450a8 ("clk:
> meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL")' the SCPI Cortex-M4
> Co-Processor seems to depend on FCLK_DIV3 being operational.
> 
> Bisect gives 'commit 05f814402d6174369b3b29832cbb5eb5ed287059 ("clk:
> meson: add fdiv clock gates") between 4.16 and 4.16-rc1 as the first
> bad commit. This added support for the missing clock gates before the
> fixed PLL fixed dividers (FCLK_DIVx) and the clock framework which
> disabled all the unused fixed dividers, thus it disabled a critical
> clock path for the SCPI Co-Processor.
> 
> This change simply sets the FCLK_DIV3 gate as critical to ensure
> nothing can disable it.

I'm a bit skeptical of this. If FCLK_DIV3 is gated at run-time, there is
no side effect other than long and/or failed reboot?

Seems like someone should be managing this clock, and simply leaving it
on all the time isn't necessarily the right approach. Any chance that
you can dig into this behavior to better understand it?

It's easy to solve issues by leaving clocks on all the time, but this
becomes a problem later on when trying to tune a device for power.

Also, if this commit really is the right fix, it should include a
comment for FCLK_DIV3 stating why the CLK_IS_CRITICAL flag was set,
which may be helpful later on to know if it is safe to remove it. Same
is true for FCLK_DIV2 in c987ac6f1f088663b6dad39281071aeb31d450a8.

Regards,
Mike

> 
> Signed-off-by: Christian Hewitt 
> ---
>  drivers/clk/meson/gxbb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 86d3ae5..4c8925d 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -509,6 +509,7 @@ static struct clk_fixed_factor gxbb_fclk_div3_div = {
> .ops = _fixed_factor_ops,
> .parent_names = (const char *[]){ "fixed_pll" },
> .num_parents = 1,
> +   .flags = CLK_IS_CRITICAL,
> },
>  };
>  
> -- 
> 2.7.4

Re: [PATCH v4] clk: add duty cycle support

[Michael Turquette]

Quoting Jerome Brunet (2018-06-19 07:41:41)
> Add the possibility to apply and query the clock signal duty cycle ratio.
> 
> This is useful when the duty cycle of the clock signal depends on some
> other parameters controlled by the clock framework.
> 
> For example, the duty cycle of a divider may depends on the raw divider
> setting (ratio = N / div) , which is controlled by the CCF. In such case,
> going through the pwm framework to control the duty cycle ratio of this
> clock would be a burden.
> 
> A clock provider is not required to implement the operation to set and get
> the duty cycle. If it does not implement .get_duty_cycle(), the ratio is
> assumed to be 50%.
> 
> This change also adds a new flag, CLK_DUTY_CYCLE_PARENT. This flag should
> be used to indicate that a clock, such as gates and muxes, may inherit
> the duty cycle ratio of its parent clock. If a clock does not provide a
> get_duty_cycle() callback and has CLK_DUTY_CYCLE_PARENT, then the call
> will be directly forwarded to its parent clock, if any. For
> set_duty_cycle(), the clock should also have CLK_SET_RATE_PARENT for the
> call to be forwarded
> 
> Signed-off-by: Jerome Brunet 

Applied to clk-core-duty-cycle.

Regards,
Mike

> ---
> 
> The series has been developed to handled the sample clocks provided by
> audio clock controller of amlogic's A113 SoC. To support i2s modes, this
> clock need to have a 50% duty cycle ratio, while it should be just one
> pulse of the parent clock in dsp modes.
> 
> Changes since v3 [2]:
>  - rebased on top of v4.18-rc1
> 
> Changes since v2 [1]:
>  - Fix kbuild robot issue with the trace file (imcomplete change related
>to clk_duty structure)
> 
> Changes since v1 [0]:
>  - Use a structure to hold the duty cycle ratio
>  - Change the way parent traversal is done, so the core framework is
>more aware of what is going on. Pass-through ops dropped as a result
>  - Only one debugfs entry for the duty cycle ratio, instead of 2
>  - Minor fixes as pointed out by Stephen
> 
> [0]: https://lkml.kernel.org/r/20180416175743.20826-1-jbru...@baylibre.com
> [1]: https://lkml.kernel.org/r/20180420153431.13003-1-jbru...@baylibre.com
> [2]: https://lkml.kernel.org/r/20180420211141.28929-1-jbru...@baylibre.com
> 
>  drivers/clk/clk.c| 199 
> +--
>  include/linux/clk-provider.h |  26 ++
>  include/linux/clk.h  |  33 +++
>  include/trace/events/clk.h   |  36 
>  4 files changed, 289 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 97c09243fb21..e108f591d84a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -68,6 +68,7 @@ struct clk_core {
> unsigned long   max_rate;
> unsigned long   accuracy;
> int phase;
> +   struct clk_duty duty;
> struct hlist_head   children;
> struct hlist_node   child_node;
> struct hlist_head   clks;
> @@ -2412,6 +2413,172 @@ int clk_get_phase(struct clk *clk)
>  }
>  EXPORT_SYMBOL_GPL(clk_get_phase);
>  
> +static void clk_core_reset_duty_cycle_nolock(struct clk_core *core)
> +{
> +   /* Assume a default value of 50% */
> +   core->duty.num = 1;
> +   core->duty.den = 2;
> +}
> +
> +static int clk_core_update_duty_cycle_parent_nolock(struct clk_core *core);
> +
> +static int clk_core_update_duty_cycle_nolock(struct clk_core *core)
> +{
> +   struct clk_duty *duty = >duty;
> +   int ret = 0;
> +
> +   if (!core->ops->get_duty_cycle)
> +   return clk_core_update_duty_cycle_parent_nolock(core);
> +
> +   ret = core->ops->get_duty_cycle(core->hw, duty);
> +   if (ret)
> +   goto reset;
> +
> +   /* Don't trust the clock provider too much */
> +   if (duty->den == 0 || duty->num > duty->den) {
> +   ret = -EINVAL;
> +   goto reset;
> +   }
> +
> +   return 0;
> +
> +reset:
> +   clk_core_reset_duty_cycle_nolock(core);
> +   return ret;
> +}
> +
> +static int clk_core_update_duty_cycle_parent_nolock(struct clk_core *core)
> +{
> +   int ret = 0;
> +
> +   if (core->parent &&
> +   core->flags & CLK_DUTY_CYCLE_PARENT) {
> +   ret = clk_core_update_duty_cycle_nolock(core->parent);
> +   memcpy(>duty, >parent->duty, sizeof(core->duty));
> +   } else {
> +   clk_core_reset_duty_cycle_nolock(core);
> +   }
> +
> +   return ret;
> +}
> +
> +static int clk_core_set_duty_cycle_parent_nolock(struct clk_core *core,
> +struct clk_duty *duty);
> +
> +static int clk_core_set_duty_cycle_nolock(struct clk_core *core,
> + struct clk_duty *duty)
> +{
> +   int ret;
> +
> +   lockdep_assert_held(_lock);
> +
> +   if (clk_core_rate_is_protected(core))
> +   return -EBUSY;
> +
> +   

Re: [PATCH v4] clk: add duty cycle support

[Michael Turquette]

Quoting Jerome Brunet (2018-06-19 07:41:41)
> Add the possibility to apply and query the clock signal duty cycle ratio.
> 
> This is useful when the duty cycle of the clock signal depends on some
> other parameters controlled by the clock framework.
> 
> For example, the duty cycle of a divider may depends on the raw divider
> setting (ratio = N / div) , which is controlled by the CCF. In such case,
> going through the pwm framework to control the duty cycle ratio of this
> clock would be a burden.
> 
> A clock provider is not required to implement the operation to set and get
> the duty cycle. If it does not implement .get_duty_cycle(), the ratio is
> assumed to be 50%.
> 
> This change also adds a new flag, CLK_DUTY_CYCLE_PARENT. This flag should
> be used to indicate that a clock, such as gates and muxes, may inherit
> the duty cycle ratio of its parent clock. If a clock does not provide a
> get_duty_cycle() callback and has CLK_DUTY_CYCLE_PARENT, then the call
> will be directly forwarded to its parent clock, if any. For
> set_duty_cycle(), the clock should also have CLK_SET_RATE_PARENT for the
> call to be forwarded
> 
> Signed-off-by: Jerome Brunet 

Applied to clk-core-duty-cycle.

Regards,
Mike

> ---
> 
> The series has been developed to handled the sample clocks provided by
> audio clock controller of amlogic's A113 SoC. To support i2s modes, this
> clock need to have a 50% duty cycle ratio, while it should be just one
> pulse of the parent clock in dsp modes.
> 
> Changes since v3 [2]:
>  - rebased on top of v4.18-rc1
> 
> Changes since v2 [1]:
>  - Fix kbuild robot issue with the trace file (imcomplete change related
>to clk_duty structure)
> 
> Changes since v1 [0]:
>  - Use a structure to hold the duty cycle ratio
>  - Change the way parent traversal is done, so the core framework is
>more aware of what is going on. Pass-through ops dropped as a result
>  - Only one debugfs entry for the duty cycle ratio, instead of 2
>  - Minor fixes as pointed out by Stephen
> 
> [0]: https://lkml.kernel.org/r/20180416175743.20826-1-jbru...@baylibre.com
> [1]: https://lkml.kernel.org/r/20180420153431.13003-1-jbru...@baylibre.com
> [2]: https://lkml.kernel.org/r/20180420211141.28929-1-jbru...@baylibre.com
> 
>  drivers/clk/clk.c| 199 
> +--
>  include/linux/clk-provider.h |  26 ++
>  include/linux/clk.h  |  33 +++
>  include/trace/events/clk.h   |  36 
>  4 files changed, 289 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 97c09243fb21..e108f591d84a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -68,6 +68,7 @@ struct clk_core {
> unsigned long   max_rate;
> unsigned long   accuracy;
> int phase;
> +   struct clk_duty duty;
> struct hlist_head   children;
> struct hlist_node   child_node;
> struct hlist_head   clks;
> @@ -2412,6 +2413,172 @@ int clk_get_phase(struct clk *clk)
>  }
>  EXPORT_SYMBOL_GPL(clk_get_phase);
>  
> +static void clk_core_reset_duty_cycle_nolock(struct clk_core *core)
> +{
> +   /* Assume a default value of 50% */
> +   core->duty.num = 1;
> +   core->duty.den = 2;
> +}
> +
> +static int clk_core_update_duty_cycle_parent_nolock(struct clk_core *core);
> +
> +static int clk_core_update_duty_cycle_nolock(struct clk_core *core)
> +{
> +   struct clk_duty *duty = >duty;
> +   int ret = 0;
> +
> +   if (!core->ops->get_duty_cycle)
> +   return clk_core_update_duty_cycle_parent_nolock(core);
> +
> +   ret = core->ops->get_duty_cycle(core->hw, duty);
> +   if (ret)
> +   goto reset;
> +
> +   /* Don't trust the clock provider too much */
> +   if (duty->den == 0 || duty->num > duty->den) {
> +   ret = -EINVAL;
> +   goto reset;
> +   }
> +
> +   return 0;
> +
> +reset:
> +   clk_core_reset_duty_cycle_nolock(core);
> +   return ret;
> +}
> +
> +static int clk_core_update_duty_cycle_parent_nolock(struct clk_core *core)
> +{
> +   int ret = 0;
> +
> +   if (core->parent &&
> +   core->flags & CLK_DUTY_CYCLE_PARENT) {
> +   ret = clk_core_update_duty_cycle_nolock(core->parent);
> +   memcpy(>duty, >parent->duty, sizeof(core->duty));
> +   } else {
> +   clk_core_reset_duty_cycle_nolock(core);
> +   }
> +
> +   return ret;
> +}
> +
> +static int clk_core_set_duty_cycle_parent_nolock(struct clk_core *core,
> +struct clk_duty *duty);
> +
> +static int clk_core_set_duty_cycle_nolock(struct clk_core *core,
> + struct clk_duty *duty)
> +{
> +   int ret;
> +
> +   lockdep_assert_held(_lock);
> +
> +   if (clk_core_rate_is_protected(core))
> +   return -EBUSY;
> +
> +   

Re: [PATCH 2/2] clk: fix CLK_SET_RATE_GATE with clock rate protection

[Michael Turquette]

Quoting Jerome Brunet (2018-06-19 06:40:51)
> CLK_SET_RATE_GATE should prevent any operation which may result in a rate
> change or glitch while the clock is prepared/enabled.
> 
> IOW, the following sequence is not allowed anymore with CLK_SET_RATE_GATE:
> * clk_get()
> * clk_prepare_enable()
> * clk_get_rate()
> * clk_set_rate()
> 
> At the moment this is enforced on the leaf clock of the operation, not
> along the tree. This problematic because, if a PLL has the CLK_RATE_GATE,
> it won't be enforced if the clk_set_rate() is called on its child clocks.
> 
> Using clock rate protection, we can now enforce CLK_SET_RATE_GATE along the
> clock tree
> 
> Acked-by: Linus Walleij 
> Tested-by: Quentin Schulz 
> Tested-by: Maxime Ripard 
> Signed-off-by: Jerome Brunet 

Applied to clk-core-set-rate-gate.

Thanks,
Mike

> ---
>  drivers/clk/clk.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 9760b526ca31..97c09243fb21 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -691,6 +691,9 @@ static void clk_core_unprepare(struct clk_core *core)
> "Unpreparing critical %s\n", core->name))
> return;
>  
> +   if (core->flags & CLK_SET_RATE_GATE)
> +   clk_core_rate_unprotect(core);
> +
> if (--core->prepare_count > 0)
> return;
>  
> @@ -765,6 +768,16 @@ static int clk_core_prepare(struct clk_core *core)
>  
> core->prepare_count++;
>  
> +   /*
> +* CLK_SET_RATE_GATE is a special case of clock protection
> +* Instead of a consumer claiming exclusive rate control, it is
> +* actually the provider which prevents any consumer from making any
> +* operation which could result in a rate change or rate glitch while
> +* the clock is prepared.
> +*/
> +   if (core->flags & CLK_SET_RATE_GATE)
> +   clk_core_rate_protect(core);
> +
> return 0;
>  unprepare:
> clk_core_unprepare(core->parent);
> @@ -1888,9 +1901,6 @@ static int clk_core_set_rate_nolock(struct clk_core 
> *core,
> if (clk_core_rate_is_protected(core))
> return -EBUSY;
>  
> -   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
> -   return -EBUSY;
> -
> /* calculate new rates and get the topmost changed clock */
> top = clk_calc_new_rates(core, req_rate);
> if (!top)
> -- 
> 2.14.3
> 

Re: [PATCH 2/2] clk: fix CLK_SET_RATE_GATE with clock rate protection

[Michael Turquette]

Quoting Jerome Brunet (2018-06-19 06:40:51)
> CLK_SET_RATE_GATE should prevent any operation which may result in a rate
> change or glitch while the clock is prepared/enabled.
> 
> IOW, the following sequence is not allowed anymore with CLK_SET_RATE_GATE:
> * clk_get()
> * clk_prepare_enable()
> * clk_get_rate()
> * clk_set_rate()
> 
> At the moment this is enforced on the leaf clock of the operation, not
> along the tree. This problematic because, if a PLL has the CLK_RATE_GATE,
> it won't be enforced if the clk_set_rate() is called on its child clocks.
> 
> Using clock rate protection, we can now enforce CLK_SET_RATE_GATE along the
> clock tree
> 
> Acked-by: Linus Walleij 
> Tested-by: Quentin Schulz 
> Tested-by: Maxime Ripard 
> Signed-off-by: Jerome Brunet 

Applied to clk-core-set-rate-gate.

Thanks,
Mike

> ---
>  drivers/clk/clk.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 9760b526ca31..97c09243fb21 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -691,6 +691,9 @@ static void clk_core_unprepare(struct clk_core *core)
> "Unpreparing critical %s\n", core->name))
> return;
>  
> +   if (core->flags & CLK_SET_RATE_GATE)
> +   clk_core_rate_unprotect(core);
> +
> if (--core->prepare_count > 0)
> return;
>  
> @@ -765,6 +768,16 @@ static int clk_core_prepare(struct clk_core *core)
>  
> core->prepare_count++;
>  
> +   /*
> +* CLK_SET_RATE_GATE is a special case of clock protection
> +* Instead of a consumer claiming exclusive rate control, it is
> +* actually the provider which prevents any consumer from making any
> +* operation which could result in a rate change or rate glitch while
> +* the clock is prepared.
> +*/
> +   if (core->flags & CLK_SET_RATE_GATE)
> +   clk_core_rate_protect(core);
> +
> return 0;
>  unprepare:
> clk_core_unprepare(core->parent);
> @@ -1888,9 +1901,6 @@ static int clk_core_set_rate_nolock(struct clk_core 
> *core,
> if (clk_core_rate_is_protected(core))
> return -EBUSY;
>  
> -   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
> -   return -EBUSY;
> -
> /* calculate new rates and get the topmost changed clock */
> top = clk_calc_new_rates(core, req_rate);
> if (!top)
> -- 
> 2.14.3
> 

Re: [PATCH 1/2] clk: qcom: drop CLK_SET_RATE_GATE from sdc clocks

[Michael Turquette]

Quoting Jerome Brunet (2018-06-19 06:40:50)
> the mmci driver (drivers/mmc/host/mmci.c) does the following sequence:
> * clk_prepare_enable()
> * clk_set_rate()
> 
> on SDCx_clk which is a children of SDCx_src. SDCx_src has
> CLK_SET_RATE_GATE so this sequence should not be allowed but this was not
> enforced. IOW, the flag is ignored. Dropping the flag won't change
> anything to the current behaviour of the platform.
> 
> CLK_SET_RATE_GATE is being fixed and enforced now. If the flag was kept,
> the mmci driver would receive -EBUSY when calling clk_set_rate()
> 
> Signed-off-by: Jerome Brunet 

Applied to clk-qcom-set-rate-gate.

Thanks,
Mike

> ---
>  drivers/clk/qcom/gcc-ipq806x.c | 3 ---
>  drivers/clk/qcom/gcc-mdm9615.c | 2 --
>  drivers/clk/qcom/gcc-msm8660.c | 5 -
>  drivers/clk/qcom/gcc-msm8960.c | 5 -
>  4 files changed, 15 deletions(-)
> 
> diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
> index 28eb200d0f1e..5f61225657ab 100644
> --- a/drivers/clk/qcom/gcc-ipq806x.c
> +++ b/drivers/clk/qcom/gcc-ipq806x.c
> @@ -1220,7 +1220,6 @@ static struct clk_rcg sdc1_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1269,7 +1268,6 @@ static struct clk_rcg sdc3_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1353,7 +1351,6 @@ static struct clk_rcg tsif_ref_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> diff --git a/drivers/clk/qcom/gcc-mdm9615.c b/drivers/clk/qcom/gcc-mdm9615.c
> index b99dd406e907..849046fbed6d 100644
> --- a/drivers/clk/qcom/gcc-mdm9615.c
> +++ b/drivers/clk/qcom/gcc-mdm9615.c
> @@ -947,7 +947,6 @@ static struct clk_rcg sdc1_src = {
> .parent_names = gcc_cxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -996,7 +995,6 @@ static struct clk_rcg sdc2_src = {
> .parent_names = gcc_cxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> diff --git a/drivers/clk/qcom/gcc-msm8660.c b/drivers/clk/qcom/gcc-msm8660.c
> index c347a0d44bc8..7e930e25c79f 100644
> --- a/drivers/clk/qcom/gcc-msm8660.c
> +++ b/drivers/clk/qcom/gcc-msm8660.c
> @@ -1558,7 +1558,6 @@ static struct clk_rcg sdc1_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1607,7 +1606,6 @@ static struct clk_rcg sdc2_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1656,7 +1654,6 @@ static struct clk_rcg sdc3_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1705,7 +1702,6 @@ static struct clk_rcg sdc4_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1754,7 +1750,6 @@ static struct clk_rcg sdc5_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
> index eb551c75fba6..fd495e0471bb 100644
> --- a/drivers/clk/qcom/gcc-msm8960.c
> +++ b/drivers/clk/qcom/gcc-msm8960.c
> @@ -1628,7 +1628,6 @@ static struct clk_rcg sdc1_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1677,7 +1676,6 @@ static struct clk_rcg sdc2_src = {
> 

Re: [PATCH 1/2] clk: qcom: drop CLK_SET_RATE_GATE from sdc clocks

[Michael Turquette]

Quoting Jerome Brunet (2018-06-19 06:40:50)
> the mmci driver (drivers/mmc/host/mmci.c) does the following sequence:
> * clk_prepare_enable()
> * clk_set_rate()
> 
> on SDCx_clk which is a children of SDCx_src. SDCx_src has
> CLK_SET_RATE_GATE so this sequence should not be allowed but this was not
> enforced. IOW, the flag is ignored. Dropping the flag won't change
> anything to the current behaviour of the platform.
> 
> CLK_SET_RATE_GATE is being fixed and enforced now. If the flag was kept,
> the mmci driver would receive -EBUSY when calling clk_set_rate()
> 
> Signed-off-by: Jerome Brunet 

Applied to clk-qcom-set-rate-gate.

Thanks,
Mike

> ---
>  drivers/clk/qcom/gcc-ipq806x.c | 3 ---
>  drivers/clk/qcom/gcc-mdm9615.c | 2 --
>  drivers/clk/qcom/gcc-msm8660.c | 5 -
>  drivers/clk/qcom/gcc-msm8960.c | 5 -
>  4 files changed, 15 deletions(-)
> 
> diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
> index 28eb200d0f1e..5f61225657ab 100644
> --- a/drivers/clk/qcom/gcc-ipq806x.c
> +++ b/drivers/clk/qcom/gcc-ipq806x.c
> @@ -1220,7 +1220,6 @@ static struct clk_rcg sdc1_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1269,7 +1268,6 @@ static struct clk_rcg sdc3_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1353,7 +1351,6 @@ static struct clk_rcg tsif_ref_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> diff --git a/drivers/clk/qcom/gcc-mdm9615.c b/drivers/clk/qcom/gcc-mdm9615.c
> index b99dd406e907..849046fbed6d 100644
> --- a/drivers/clk/qcom/gcc-mdm9615.c
> +++ b/drivers/clk/qcom/gcc-mdm9615.c
> @@ -947,7 +947,6 @@ static struct clk_rcg sdc1_src = {
> .parent_names = gcc_cxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -996,7 +995,6 @@ static struct clk_rcg sdc2_src = {
> .parent_names = gcc_cxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> diff --git a/drivers/clk/qcom/gcc-msm8660.c b/drivers/clk/qcom/gcc-msm8660.c
> index c347a0d44bc8..7e930e25c79f 100644
> --- a/drivers/clk/qcom/gcc-msm8660.c
> +++ b/drivers/clk/qcom/gcc-msm8660.c
> @@ -1558,7 +1558,6 @@ static struct clk_rcg sdc1_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1607,7 +1606,6 @@ static struct clk_rcg sdc2_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1656,7 +1654,6 @@ static struct clk_rcg sdc3_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1705,7 +1702,6 @@ static struct clk_rcg sdc4_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1754,7 +1750,6 @@ static struct clk_rcg sdc5_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
> index eb551c75fba6..fd495e0471bb 100644
> --- a/drivers/clk/qcom/gcc-msm8960.c
> +++ b/drivers/clk/qcom/gcc-msm8960.c
> @@ -1628,7 +1628,6 @@ static struct clk_rcg sdc1_src = {
> .parent_names = gcc_pxo_pll8,
> .num_parents = 2,
> .ops = _rcg_ops,
> -   .flags = CLK_SET_RATE_GATE,
> },
> }
>  };
> @@ -1677,7 +1676,6 @@ static struct clk_rcg sdc2_src = {
> 

Re: [PATCH 0/9] clk: davinci: outstanding fixes

[Michael Turquette]

Hi David,

Quoting David Lechner (2018-05-25 11:11:41)
> This is a resend of all of the outstanding DaVinci clock patches plus one new
> patch. All of the patches (except the new one) have been reviewed and tested
> by someone other than me.
> 
> The new patch ("clk: davinci: Fix link errors when not all SoCs are enabled")
> should be fairly trivial.
> 
> I am resending them all in one series to hopefully make it easier to get them
> picked up by having them in the correct order to avoid merge conflicts. This
> series is based on the clk/clk-davinci-psc-da830 branch.

I picked them all and pushed to clk/clk-davinci based on -rc1. There are
some comments on the individual patches, all of which are of the "please
revisit this and fix it up later" variety.

Going forward I'm happy for you and/or Sekhar to send clk PRs to Stephen
and myself. The same rules apply for PRs: all patches need to be posted
to the list the old fashioned way for review. But PRs make our lives a
bit easier, especially when dealing with chip variants from the same SoC
family like we have with davinci.

Best regards,
Mike

> 
> David Lechner (7):
>   clk: davinci: pll-dm355: drop pll2_sysclk2
>   clk: davinci: pll-dm355: fix SYSCLKn parent names
>   clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups
>   clk: davinci: pll: allow dev == NULL
>   clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
>   clk: davinci: psc: allow for dev == NULL
>   clk: davinci: Fix link errors when not all SoCs are enabled
> 
> Sekhar Nori (2):
>   clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
>   clk: davinci: psc-dm365: fix few clocks
> 
>  drivers/clk/davinci/pll-da830.c  |   5 +-
>  drivers/clk/davinci/pll-da850.c  |  37 ++--
>  drivers/clk/davinci/pll-dm355.c  |  22 ++-
>  drivers/clk/davinci/pll-dm365.c  |   9 +-
>  drivers/clk/davinci/pll-dm644x.c |   9 +-
>  drivers/clk/davinci/pll-dm646x.c |  11 +-
>  drivers/clk/davinci/pll.c| 299 +--
>  drivers/clk/davinci/pll.h|  41 +++--
>  drivers/clk/davinci/psc-dm355.c  |   7 +-
>  drivers/clk/davinci/psc-dm365.c  |  22 ++-
>  drivers/clk/davinci/psc-dm644x.c |   3 +-
>  drivers/clk/davinci/psc-dm646x.c |   3 +-
>  drivers/clk/davinci/psc.c|  72 ++--
>  drivers/clk/davinci/psc.h|  12 ++
>  include/linux/clk/davinci.h  |  40 +
>  15 files changed, 418 insertions(+), 174 deletions(-)
>  create mode 100644 include/linux/clk/davinci.h
> 
> -- 
> 2.17.0
> 

Re: [PATCH 0/9] clk: davinci: outstanding fixes

[Michael Turquette]

Hi David,

Quoting David Lechner (2018-05-25 11:11:41)
> This is a resend of all of the outstanding DaVinci clock patches plus one new
> patch. All of the patches (except the new one) have been reviewed and tested
> by someone other than me.
> 
> The new patch ("clk: davinci: Fix link errors when not all SoCs are enabled")
> should be fairly trivial.
> 
> I am resending them all in one series to hopefully make it easier to get them
> picked up by having them in the correct order to avoid merge conflicts. This
> series is based on the clk/clk-davinci-psc-da830 branch.

I picked them all and pushed to clk/clk-davinci based on -rc1. There are
some comments on the individual patches, all of which are of the "please
revisit this and fix it up later" variety.

Going forward I'm happy for you and/or Sekhar to send clk PRs to Stephen
and myself. The same rules apply for PRs: all patches need to be posted
to the list the old fashioned way for review. But PRs make our lives a
bit easier, especially when dealing with chip variants from the same SoC
family like we have with davinci.

Best regards,
Mike

> 
> David Lechner (7):
>   clk: davinci: pll-dm355: drop pll2_sysclk2
>   clk: davinci: pll-dm355: fix SYSCLKn parent names
>   clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups
>   clk: davinci: pll: allow dev == NULL
>   clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
>   clk: davinci: psc: allow for dev == NULL
>   clk: davinci: Fix link errors when not all SoCs are enabled
> 
> Sekhar Nori (2):
>   clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
>   clk: davinci: psc-dm365: fix few clocks
> 
>  drivers/clk/davinci/pll-da830.c  |   5 +-
>  drivers/clk/davinci/pll-da850.c  |  37 ++--
>  drivers/clk/davinci/pll-dm355.c  |  22 ++-
>  drivers/clk/davinci/pll-dm365.c  |   9 +-
>  drivers/clk/davinci/pll-dm644x.c |   9 +-
>  drivers/clk/davinci/pll-dm646x.c |  11 +-
>  drivers/clk/davinci/pll.c| 299 +--
>  drivers/clk/davinci/pll.h|  41 +++--
>  drivers/clk/davinci/psc-dm355.c  |   7 +-
>  drivers/clk/davinci/psc-dm365.c  |  22 ++-
>  drivers/clk/davinci/psc-dm644x.c |   3 +-
>  drivers/clk/davinci/psc-dm646x.c |   3 +-
>  drivers/clk/davinci/psc.c|  72 ++--
>  drivers/clk/davinci/psc.h|  12 ++
>  include/linux/clk/davinci.h  |  40 +
>  15 files changed, 418 insertions(+), 174 deletions(-)
>  create mode 100644 include/linux/clk/davinci.h
> 
> -- 
> 2.17.0
> 

Re: [PATCH 6/9] clk: davinci: pll: allow dev == NULL

[Michael Turquette]

Hi David,

Quoting David Lechner (2018-05-25 11:11:47)
> This modifies the TI Davinci PLL clock driver to allow for the case
> when dev == NULL. On some (most) SoCs that use this driver, the PLL
> clock needs to be registered during early boot because it is used
> for clocksource/clkevent and there will be no platform device available.

A lot of this stuff feels like a step backwards. E.g:

> diff --git a/drivers/clk/davinci/pll.c b/drivers/clk/davinci/pll.c
> index 23a24c944f1d..2eb981e61185 100644
> --- a/drivers/clk/davinci/pll.c
> +++ b/drivers/clk/davinci/pll.c
> @@ -11,6 +11,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -223,6 +224,7 @@ static const struct clk_ops dm365_pll_ops = {
>  
>  /**
>   * davinci_pll_div_register - common *DIV clock implementation
> + * @dev: The PLL platform device or NULL
>   * @name: the clock name
>   * @parent_name: the parent clock name
>   * @reg: the *DIV register
> @@ -240,17 +242,21 @@ static struct clk *davinci_pll_div_register(struct 
> device *dev,
> const struct clk_ops *divider_ops = _divider_ops;
> struct clk_gate *gate;
> struct clk_divider *divider;
> +   struct clk *clk;
> +   int ret;
>  
> -   gate = devm_kzalloc(dev, sizeof(*gate), GFP_KERNEL);
> +   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> if (!gate)
> return ERR_PTR(-ENOMEM);
>  
> gate->reg = reg;
> gate->bit_idx = DIV_ENABLE_SHIFT;
>  
> -   divider = devm_kzalloc(dev, sizeof(*divider), GFP_KERNEL);
> -   if (!divider)
> -   return ERR_PTR(-ENOMEM);
> +   divider = kzalloc(sizeof(*divider), GFP_KERNEL);
> +   if (!divider) {
> +   ret = -ENOMEM;
> +   goto err_free_gate;
> +   }
>  
> divider->reg = reg;
> divider->shift = DIV_RATIO_SHIFT;

Oh no my poor devm_ helpers!

I understand that we need to support early boot drivers better, so this
patch can be merged.

However I'm curious if you're tracking Bartosz's early_platform_driver
efforts? Converting to that if it is ever merged would likely be
cleaner:

https://lkml.kernel.org/r/20180511162028.20616-1-b...@bgdev.pl

Best regards,
Mike

Re: [PATCH 6/9] clk: davinci: pll: allow dev == NULL

[Michael Turquette]

Hi David,

Quoting David Lechner (2018-05-25 11:11:47)
> This modifies the TI Davinci PLL clock driver to allow for the case
> when dev == NULL. On some (most) SoCs that use this driver, the PLL
> clock needs to be registered during early boot because it is used
> for clocksource/clkevent and there will be no platform device available.

A lot of this stuff feels like a step backwards. E.g:

> diff --git a/drivers/clk/davinci/pll.c b/drivers/clk/davinci/pll.c
> index 23a24c944f1d..2eb981e61185 100644
> --- a/drivers/clk/davinci/pll.c
> +++ b/drivers/clk/davinci/pll.c
> @@ -11,6 +11,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -223,6 +224,7 @@ static const struct clk_ops dm365_pll_ops = {
>  
>  /**
>   * davinci_pll_div_register - common *DIV clock implementation
> + * @dev: The PLL platform device or NULL
>   * @name: the clock name
>   * @parent_name: the parent clock name
>   * @reg: the *DIV register
> @@ -240,17 +242,21 @@ static struct clk *davinci_pll_div_register(struct 
> device *dev,
> const struct clk_ops *divider_ops = _divider_ops;
> struct clk_gate *gate;
> struct clk_divider *divider;
> +   struct clk *clk;
> +   int ret;
>  
> -   gate = devm_kzalloc(dev, sizeof(*gate), GFP_KERNEL);
> +   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> if (!gate)
> return ERR_PTR(-ENOMEM);
>  
> gate->reg = reg;
> gate->bit_idx = DIV_ENABLE_SHIFT;
>  
> -   divider = devm_kzalloc(dev, sizeof(*divider), GFP_KERNEL);
> -   if (!divider)
> -   return ERR_PTR(-ENOMEM);
> +   divider = kzalloc(sizeof(*divider), GFP_KERNEL);
> +   if (!divider) {
> +   ret = -ENOMEM;
> +   goto err_free_gate;
> +   }
>  
> divider->reg = reg;
> divider->shift = DIV_RATIO_SHIFT;

Oh no my poor devm_ helpers!

I understand that we need to support early boot drivers better, so this
patch can be merged.

However I'm curious if you're tracking Bartosz's early_platform_driver
efforts? Converting to that if it is ever merged would likely be
cleaner:

https://lkml.kernel.org/r/20180511162028.20616-1-b...@bgdev.pl

Best regards,
Mike

Re: [PATCH 00/12] introduce support for early platform drivers

[Michael Turquette]

Hi Rob,

Quoting Rob Herring (2018-05-14 06:20:57)
> On Mon, May 14, 2018 at 6:38 AM, Bartosz Golaszewski  wrote:
> > 2018-05-11 22:13 GMT+02:00 Rob Herring :
> >> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski  
> >> wrote:
> >>> This series is a follow-up to the RFC[1] posted a couple days ago.
> >>>
> >>> NOTE: this series applies on top of my recent patches[2] that move the 
> >>> previous
> >>> implementation of early platform devices to arch/sh.
> >>>
> >>> Problem:
> >>>
> >>> Certain class of devices, such as timers, certain clock drivers and irq 
> >>> chip
> >>> drivers need to be probed early in the boot sequence. The currently 
> >>> preferred
> >>> approach is using one of the OF_DECLARE() macros. This however does not 
> >>> create
> >>> a platform device which has many drawbacks - such as not being able to use
> >>> devres routines, dev_ log functions or no way of deferring the init OF 
> >>> function
> >>> if some other resources are missing.
> >>
> >> I skimmed though this and it doesn't look horrible (how's that for
> >> positive feedback? ;) ). But before going into the details, I think
> >> first there needs to be agreement this is the right direction.
> >>
> >> The question does remain though as to whether this class of devices
> >> should be platform drivers. They can't be modules. They can't be
> >> hotplugged. Can they be runtime-pm enabled? So the advantage is ...
> >>
> >
> > The main (but not the only) advantage for drivers that can both be
> > platform drivers and OF_DECLARE drivers is that we get a single entry
> > point and can reuse code without resorting to checking if (!dev). It
> > results in more consistent code base. Another big advantage is
> > consolidation of device tree and machine code for SoC drivers used in
> > different boards of which some are still using board files and others
> > are defined in DT (see: DaVinci).
> >
> >> I assume that the clock maintainers had some reason to move clocks to
> >> be platform drivers. It's just not clear to me what that was.
> >>
> >>> For drivers that use both platform drivers and OF_DECLARE the situation 
> >>> is even
> >>> more complicated as the code needs to take into account that there can 
> >>> possibly
> >>> be no struct device present. For a specific use case that we're having 
> >>> problems
> >>> with, please refer to the recent DaVinci common-clock conversion patches 
> >>> and
> >>> the nasty workaround that this problem implies[3].
> >>
> >> So devm_kzalloc will work with this solution? Why did we need
> >> devm_kzalloc in the first place? The clocks can never be removed and
> >> cleaning up on error paths is kind of pointless. The system would be
> >> hosed, right?
> >>
> >
> > It depends - not all clocks are necessary for system to boot.
> 
> That doesn't matter. You have a single driver for all/most of the
> clocks, so the driver can't be removed.

-ECANOFWORMS

A couple of quick rebuttals, but I imagine we're going to disagree on
the platform_driver thing as a matter of taste no matter what...

1) There should be multiple clk drivers in a properly modeled system.
Some folks still incorrectly put all clocks in a system into a single
driver because That's How We Used To Do It, and some systems (simpler
ones) really only have a single clock generator IP block.

Excepting those two reasons above, we really should have separate
drivers for clocks controlled by the PMIC, for the (one or more) clock
generator blocks inside of the AP/SoC, and then even more for the
drivers that map to IP blocks that have their own clock gens.

Good examples of the latter are display controllers that generate their
own PLL and pixel clock. Or MMC controllers that have a
runtime-programmable clock divider. Examples of these are merged into
mainline.

2) Stephen and I wanted clock drivers to actually be represented in the
driver model. There were these gigantic clock drivers that exclusively
used CLK_OF_DECLARE and they just sort of floated out there in the
ether... no representation in sysfs, no struct device to map onto a
clock controller struct, etc.

I'd be happy to hear why you think that platform_driver is a bad fit for
a device driver that generally manages memory-mapped system resources
that are part of the system glue and not really tied to a specific bus.
Sounds like a good fit to me.

If platform_driver doesn't handle the early boot thing well, that tells
me that we have a problem to solve in platform_driver, not in the clk
subsystem or drivers.

3) Lots of clock controllers should be loadable modules. E.g. i2c clock
expanders, potentially external PMIC-related drivers, external audio
codecs, etc.

Again, repeating my point #1 above, just because many platforms have a
monolithic clock driver does not mean that this is the Right Way to do
it.

Best regards,
Mike

> 
> >>> We also used to have an early platform drivers implementation but they 
> >>> were not
> >>> integrated with the linux device model at all - they 

Re: [PATCH 00/12] introduce support for early platform drivers

[Michael Turquette]

Hi Rob,

Quoting Rob Herring (2018-05-14 06:20:57)
> On Mon, May 14, 2018 at 6:38 AM, Bartosz Golaszewski  wrote:
> > 2018-05-11 22:13 GMT+02:00 Rob Herring :
> >> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski  
> >> wrote:
> >>> This series is a follow-up to the RFC[1] posted a couple days ago.
> >>>
> >>> NOTE: this series applies on top of my recent patches[2] that move the 
> >>> previous
> >>> implementation of early platform devices to arch/sh.
> >>>
> >>> Problem:
> >>>
> >>> Certain class of devices, such as timers, certain clock drivers and irq 
> >>> chip
> >>> drivers need to be probed early in the boot sequence. The currently 
> >>> preferred
> >>> approach is using one of the OF_DECLARE() macros. This however does not 
> >>> create
> >>> a platform device which has many drawbacks - such as not being able to use
> >>> devres routines, dev_ log functions or no way of deferring the init OF 
> >>> function
> >>> if some other resources are missing.
> >>
> >> I skimmed though this and it doesn't look horrible (how's that for
> >> positive feedback? ;) ). But before going into the details, I think
> >> first there needs to be agreement this is the right direction.
> >>
> >> The question does remain though as to whether this class of devices
> >> should be platform drivers. They can't be modules. They can't be
> >> hotplugged. Can they be runtime-pm enabled? So the advantage is ...
> >>
> >
> > The main (but not the only) advantage for drivers that can both be
> > platform drivers and OF_DECLARE drivers is that we get a single entry
> > point and can reuse code without resorting to checking if (!dev). It
> > results in more consistent code base. Another big advantage is
> > consolidation of device tree and machine code for SoC drivers used in
> > different boards of which some are still using board files and others
> > are defined in DT (see: DaVinci).
> >
> >> I assume that the clock maintainers had some reason to move clocks to
> >> be platform drivers. It's just not clear to me what that was.
> >>
> >>> For drivers that use both platform drivers and OF_DECLARE the situation 
> >>> is even
> >>> more complicated as the code needs to take into account that there can 
> >>> possibly
> >>> be no struct device present. For a specific use case that we're having 
> >>> problems
> >>> with, please refer to the recent DaVinci common-clock conversion patches 
> >>> and
> >>> the nasty workaround that this problem implies[3].
> >>
> >> So devm_kzalloc will work with this solution? Why did we need
> >> devm_kzalloc in the first place? The clocks can never be removed and
> >> cleaning up on error paths is kind of pointless. The system would be
> >> hosed, right?
> >>
> >
> > It depends - not all clocks are necessary for system to boot.
> 
> That doesn't matter. You have a single driver for all/most of the
> clocks, so the driver can't be removed.

-ECANOFWORMS

A couple of quick rebuttals, but I imagine we're going to disagree on
the platform_driver thing as a matter of taste no matter what...

1) There should be multiple clk drivers in a properly modeled system.
Some folks still incorrectly put all clocks in a system into a single
driver because That's How We Used To Do It, and some systems (simpler
ones) really only have a single clock generator IP block.

Excepting those two reasons above, we really should have separate
drivers for clocks controlled by the PMIC, for the (one or more) clock
generator blocks inside of the AP/SoC, and then even more for the
drivers that map to IP blocks that have their own clock gens.

Good examples of the latter are display controllers that generate their
own PLL and pixel clock. Or MMC controllers that have a
runtime-programmable clock divider. Examples of these are merged into
mainline.

2) Stephen and I wanted clock drivers to actually be represented in the
driver model. There were these gigantic clock drivers that exclusively
used CLK_OF_DECLARE and they just sort of floated out there in the
ether... no representation in sysfs, no struct device to map onto a
clock controller struct, etc.

I'd be happy to hear why you think that platform_driver is a bad fit for
a device driver that generally manages memory-mapped system resources
that are part of the system glue and not really tied to a specific bus.
Sounds like a good fit to me.

If platform_driver doesn't handle the early boot thing well, that tells
me that we have a problem to solve in platform_driver, not in the clk
subsystem or drivers.

3) Lots of clock controllers should be loadable modules. E.g. i2c clock
expanders, potentially external PMIC-related drivers, external audio
codecs, etc.

Again, repeating my point #1 above, just because many platforms have a
monolithic clock driver does not mean that this is the Right Way to do
it.

Best regards,
Mike

> 
> >>> We also used to have an early platform drivers implementation but they 
> >>> were not
> >>> integrated with the linux device model at all - they 

Re: [PATCH 4/9] clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled

[Michael Turquette]

Quoting David Lechner (2018-05-25 11:11:45)
> From: Sekhar Nori 
> 
> PLL2 SYSCLK1 on DM646x is connected to DDR2 PHY and cannot
> be disabled. Mark it so to prevent unused clock disable
> infrastructure from disabling it.
> 
> Signed-off-by: Sekhar Nori 
> Reviewed-by: David Lechner 
> ---
>  drivers/clk/davinci/pll-dm646x.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/davinci/pll-dm646x.c 
> b/drivers/clk/davinci/pll-dm646x.c
> index a61cc3256418..0ae827e3ce80 100644
> --- a/drivers/clk/davinci/pll-dm646x.c
> +++ b/drivers/clk/davinci/pll-dm646x.c
> @@ -72,7 +72,7 @@ static const struct davinci_pll_clk_info dm646x_pll2_info = 
> {
> .flags = 0,
>  };
>  
> -SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, 0);
> +SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, SYSCLK_ALWAYS_ENABLED);

Nitpick: I dislike setting a platform-specific flag that just sets a
framework-specific flag during clk registration.

I know there is some legacy here so I'll take this patch as-is, but
perhaps cleaning this up to directly use CLK_IS_CRITICAL can be added to
someone's todo list?

Thanks,
Mike

>  
>  int dm646x_pll2_init(struct device *dev, void __iomem *base)
>  {
> -- 
> 2.17.0
> 

Re: [PATCH 4/9] clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled

[Michael Turquette]

Quoting David Lechner (2018-05-25 11:11:45)
> From: Sekhar Nori 
> 
> PLL2 SYSCLK1 on DM646x is connected to DDR2 PHY and cannot
> be disabled. Mark it so to prevent unused clock disable
> infrastructure from disabling it.
> 
> Signed-off-by: Sekhar Nori 
> Reviewed-by: David Lechner 
> ---
>  drivers/clk/davinci/pll-dm646x.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/davinci/pll-dm646x.c 
> b/drivers/clk/davinci/pll-dm646x.c
> index a61cc3256418..0ae827e3ce80 100644
> --- a/drivers/clk/davinci/pll-dm646x.c
> +++ b/drivers/clk/davinci/pll-dm646x.c
> @@ -72,7 +72,7 @@ static const struct davinci_pll_clk_info dm646x_pll2_info = 
> {
> .flags = 0,
>  };
>  
> -SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, 0);
> +SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, SYSCLK_ALWAYS_ENABLED);

Nitpick: I dislike setting a platform-specific flag that just sets a
framework-specific flag during clk registration.

I know there is some legacy here so I'll take this patch as-is, but
perhaps cleaning this up to directly use CLK_IS_CRITICAL can be added to
someone's todo list?

Thanks,
Mike

>  
>  int dm646x_pll2_init(struct device *dev, void __iomem *base)
>  {
> -- 
> 2.17.0
> 

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

[Michael Turquette]

Quoting Jerome Brunet (2018-02-02 04:50:28)
> On Thu, 2018-02-01 at 09:43 -0800, Stephen Boyd wrote:
> > > > > Applied to clk-protect-rate, with the exception that I did not apply
> > > > > "clk: fix CLK_SET_RATE_GATE with clock rate protection" as it breaks
> > > > > qcom clk code.
> > > > > 
> > > > > Stephen, do you plan to fix up the qcom clock code so that the
> > > > > SET_RATE_GATE improvement can go in?
> > > > > 
> > > > 
> > > > I started working on it a while back. Let's see if I can finish
> > > > it off this weekend.
> > > > 
> > > 
> > > Hi Stephen,
> > > 
> > > Have you been able find something to fix the qcom code regarding this 
> > > issue ?
> > > 
> > 
> > This is what I have. I'm unhappy with a few things. First, I made
> > a spinlock for each clk, which is overkill. Most likely, just a
> > single spinlock is needed per clk-controller device. Second, I
> > haven't finished off the branch/gate part, so gating/ungating of
> > branches needs to be locked as well to prevent branches from
> > turning on while rates change. And finally, the 'branches' list is
> > duplicating a bunch of information about the child clks of an
> > RCG, so it feels like we need a core framework API to enable and
> > disable clks forcibly while remembering what is enabled/disabled
> > or at least to walk the clk tree and call some function.
> 
> Looks similar to Mike's CCR idea ;)

Giving clk provider drivers more control over the clocks that they
provide is a similar concept, but the ancient ccr series dealt almost
exclusively with set_rate and set_parent ops.

> 
> > 
> > The spinlock per clk-controller is duplicating the regmap lock we
> > already have, so we may want a regmap API to grab the lock, and
> > then another regmap API to do reads/writes without grabbing the
> > lock, and then finally release the lock with a regmap unlock API.
> 
> There is 'regsequence' for multiple write in a burst, but that's only if you 
> do
> write only ... I suppose you are more in read/update/writeback mode, so it
> probably does not help much.
> 
> Maybe we could extend regmap's regsequence, to do a sequence of
> regmap_update_bits() ?
> 
> Another possibility could be to provide your own lock/unlock ops when
> registering the regmap. With this, you might be able to supply your own 
> spinlock
> to regmap. This is already supported by regmap, would it help ?

Stephen, was there ever an update on your end? This patch has been
dangling for a while and I thought it was time to ping on it.

Regards,
Mike

> 
> > This part is mostly an optimization, but it would be nice to have
> > so that multiple writes could be done in sequence. This way, the
> > RCG code could do the special locking sequence and the branch
> > code could do the fire and forget single bit update.
>
 

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

[Michael Turquette]

Quoting Jerome Brunet (2018-02-02 04:50:28)
> On Thu, 2018-02-01 at 09:43 -0800, Stephen Boyd wrote:
> > > > > Applied to clk-protect-rate, with the exception that I did not apply
> > > > > "clk: fix CLK_SET_RATE_GATE with clock rate protection" as it breaks
> > > > > qcom clk code.
> > > > > 
> > > > > Stephen, do you plan to fix up the qcom clock code so that the
> > > > > SET_RATE_GATE improvement can go in?
> > > > > 
> > > > 
> > > > I started working on it a while back. Let's see if I can finish
> > > > it off this weekend.
> > > > 
> > > 
> > > Hi Stephen,
> > > 
> > > Have you been able find something to fix the qcom code regarding this 
> > > issue ?
> > > 
> > 
> > This is what I have. I'm unhappy with a few things. First, I made
> > a spinlock for each clk, which is overkill. Most likely, just a
> > single spinlock is needed per clk-controller device. Second, I
> > haven't finished off the branch/gate part, so gating/ungating of
> > branches needs to be locked as well to prevent branches from
> > turning on while rates change. And finally, the 'branches' list is
> > duplicating a bunch of information about the child clks of an
> > RCG, so it feels like we need a core framework API to enable and
> > disable clks forcibly while remembering what is enabled/disabled
> > or at least to walk the clk tree and call some function.
> 
> Looks similar to Mike's CCR idea ;)

Giving clk provider drivers more control over the clocks that they
provide is a similar concept, but the ancient ccr series dealt almost
exclusively with set_rate and set_parent ops.

> 
> > 
> > The spinlock per clk-controller is duplicating the regmap lock we
> > already have, so we may want a regmap API to grab the lock, and
> > then another regmap API to do reads/writes without grabbing the
> > lock, and then finally release the lock with a regmap unlock API.
> 
> There is 'regsequence' for multiple write in a burst, but that's only if you 
> do
> write only ... I suppose you are more in read/update/writeback mode, so it
> probably does not help much.
> 
> Maybe we could extend regmap's regsequence, to do a sequence of
> regmap_update_bits() ?
> 
> Another possibility could be to provide your own lock/unlock ops when
> registering the regmap. With this, you might be able to supply your own 
> spinlock
> to regmap. This is already supported by regmap, would it help ?

Stephen, was there ever an update on your end? This patch has been
dangling for a while and I thought it was time to ping on it.

Regards,
Mike

> 
> > This part is mostly an optimization, but it would be nice to have
> > so that multiple writes could be done in sequence. This way, the
> > RCG code could do the special locking sequence and the branch
> > code could do the fire and forget single bit update.
>
 

Re: [PATCH v2 4/8] clk: migrate the count of orphaned clocks at init

[Michael Turquette]

Excerpts from Heiko Stübner's message of February 15, 2018 1:01 pm:

Am Mittwoch, 14. Februar 2018, 14:43:36 CET schrieb Jerome Brunet:

The orphan clocks reparents should migrate any existing count from the
orphan clock to its new acestor clocks, otherwise we may have
inconsistent counts in the tree and end-up with gated critical clocks

Assuming we have two clocks, A and B.
* Clock A has CLK_IS_CRITICAL flag set.
* Clock B is an ancestor of A which can gate. Clock B gate is left
  enabled by the bootloader.

Step 1: Clock A is registered. Since it is a critical clock, it is
enabled. The clock being still an orphan, no parent are enabled.

Step 2: Clock B is registered and reparented to clock A (potentially
through several other clocks). We are now in situation where the enable
count of clock A is 1 while the enable count of its ancestors is 0, which
is not good.

Step 3: in lateinit, clk_disable_unused() is called, the enable_count of
clock B being 0, clock B is gated and and critical clock A actually gets
disabled.

This situation was found while adding fdiv_clk gates to the meson8b
platform.  These clocks parent clk81 critical clock, which is the mother
of all peripheral clocks in this system. Because of the issue described
here, the system is crashing when clk_disable_unused() is called.

The situation is solved by reverting
commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting during
registration"). To avoid breaking again the situation described in this
commit
description, enabling critical clock should be done before walking the
orphan list. This way, a parent critical clock may not be accidentally
disabled due to the CLK_OPS_PARENT_ENABLE mechanism.

Fixes: f8f8f1d04494 ("clk: Don't touch hardware when reparenting during
registration") Cc: Stephen Boyd 
Cc: Shawn Guo 
Cc: Dong Aisheng 
Signed-off-by: Jerome Brunet 


On a rk3288-veyron Chromebook
Tested-by: Heiko Stuebner 

This made the hdmi on the machine work again with 4.16-rc1 .
(hdmi-cec clock is sourced from the i2c connected pmic which provides
the 32kHz clock needed)

So it would be really cool if this could make it into 4.16-rc :-)


I separated this patch out into clk-fixes to be set for -rc5 or -rc6.

Regards,
Mike




Heiko

Re: [PATCH v2 4/8] clk: migrate the count of orphaned clocks at init

[Michael Turquette]

Excerpts from Heiko Stübner's message of February 15, 2018 1:01 pm:

Am Mittwoch, 14. Februar 2018, 14:43:36 CET schrieb Jerome Brunet:

The orphan clocks reparents should migrate any existing count from the
orphan clock to its new acestor clocks, otherwise we may have
inconsistent counts in the tree and end-up with gated critical clocks

Assuming we have two clocks, A and B.
* Clock A has CLK_IS_CRITICAL flag set.
* Clock B is an ancestor of A which can gate. Clock B gate is left
  enabled by the bootloader.

Step 1: Clock A is registered. Since it is a critical clock, it is
enabled. The clock being still an orphan, no parent are enabled.

Step 2: Clock B is registered and reparented to clock A (potentially
through several other clocks). We are now in situation where the enable
count of clock A is 1 while the enable count of its ancestors is 0, which
is not good.

Step 3: in lateinit, clk_disable_unused() is called, the enable_count of
clock B being 0, clock B is gated and and critical clock A actually gets
disabled.

This situation was found while adding fdiv_clk gates to the meson8b
platform.  These clocks parent clk81 critical clock, which is the mother
of all peripheral clocks in this system. Because of the issue described
here, the system is crashing when clk_disable_unused() is called.

The situation is solved by reverting
commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting during
registration"). To avoid breaking again the situation described in this
commit
description, enabling critical clock should be done before walking the
orphan list. This way, a parent critical clock may not be accidentally
disabled due to the CLK_OPS_PARENT_ENABLE mechanism.

Fixes: f8f8f1d04494 ("clk: Don't touch hardware when reparenting during
registration") Cc: Stephen Boyd 
Cc: Shawn Guo 
Cc: Dong Aisheng 
Signed-off-by: Jerome Brunet 


On a rk3288-veyron Chromebook
Tested-by: Heiko Stuebner 

This made the hdmi on the machine work again with 4.16-rc1 .
(hdmi-cec clock is sourced from the i2c connected pmic which provides
the 32kHz clock needed)

So it would be really cool if this could make it into 4.16-rc :-)


I separated this patch out into clk-fixes to be set for -rc5 or -rc6.

Regards,
Mike




Heiko

Re: [PATCH v2 00/19] clk: meson: use regmap in clock controllers

[Michael Turquette]

Bonjour Jerome,

Excerpts from Jerome Brunet's message of February 12, 2018 6:58 am:

This changeset is a rework of meson's clock controllers to use regmap
instead of directly using io memory. It based clk-meson next/drivers
and depends on few core clock patches, mainly to export generic clocks
helpers: [0],[1]. The line count is pretty high but the changes are
actually fairly simple and repetitive.

This work has been triggered by the fact that the HHI register space on
gxbb and axg provides more than just clocks. The display driver already
uses a syscon for HHI on gxbb. This is why gxbb did not use
devm_ioremap_resource() to map the registers, since it would have
reserved the memory region, preventing another driver from re-mapping
it. The cleaner solution is, of course, to use syscon to handle. The
purpose of this changeset is to allow it. Even if meson8b does not need
this ATM, there is real reason to leave it behind. It is actually easier
to migrate it as well, so all meson clock drivers may support regmap
only.

The rework starts with a few easy clean-ups. The real deal starts with
patch 5, which adds meson's clk_regmap. This will be used as common
structure to implement all the controller clocks. Having this replaces
the gxbb AO controller specific regmap gate. This structure will also be
re-used in upcoming controllers, such as the axg's AO and audio
controllers.  Each clock type is then migrated, one at a time, to this
new structure.

While at it, the meson clock drivers have been cleaned-up a bit,
removing the gate embedded in the mpll driver, simplifying the pll
driver and removing the legacy cpu_clk of meson8b.

The new code around the cpu clk of the meson8b is just re-implementation,
using simple elements, of the old cpu_clk. As explained by Martin, the
old cpu_clk would hang quite often when changing the rate of the cpu
clock. Surprisingly, the new implementation improved the situation a bit,
but still hangs from time to time. As this is not acceptable, the cpu
clk subtree as been switched to a read-only mode, preventing any change
of the cpu rate, until an acceptable solution is found.

With this series applied, the clock controllers of the gxbb, gxl and axg
SoC will try get regmap from their parent DT node. If this fails, they
will fallback to mapping the register themselves. This fallback will be
kept until platform DTs have changed so clock controllers is a child of
the HHI system controller.


Looks OK to me. As we discussed off-list, can you send this (and the
other meson patches) as a PR based on top of the clk-helpers branch in
the clk git tree? That should satisfy the dependencies (I hope).

Best regards,
Mike



Based on this changeset, more patches are coming. For those interested,
the WIP is available here [2]

Changes since v1 [3]:
* Fixed a few typos in patches descriptions
* Fixed cpu clock names on meson8b, as suggested by Martin
* Switched cpu clock subtree to reead-only mode
* Fix clk_regmap mux documentation, as reported by Yixun

[0]: https://lkml.kernel.org/r/20180118110144.30619-1-jbru...@baylibre.com
[1]: https://lkml.kernel.org/r/20180122105759.12206-1-jbru...@baylibre.com
[2]: https://github.com/jeromebrunet/linux/tree/v4.17/meson/clk-regmap
[1]: https://lkml.kernel.org/r/20180131180945.18025-1-jbru...@baylibre.com

Jerome Brunet (19):
  clk: meson: use dev pointer where possible
  clk: meson: use devm_of_clk_add_hw_provider
  clk: meson: only one loop index is necessary in probe
  clk: meson: remove obsolete comments
  clk: meson: add regmap clocks
  clk: meson: switch gxbb ao_clk to clk_regmap
  clk: meson: remove superseded aoclk_gate_regmap
  clk: meson: add regmap to the clock controllers
  clk: meson: migrate gates to clk_regmap
  clk: meson: migrate dividers to clk_regmap
  clk: meson: migrate muxes to clk_regmap
  clk: meson: add regmap helpers for parm
  clk: meson: migrate mplls clocks to clk_regmap
  clk: meson: migrate the audio divider clock to clk_regmap
  clk: meson: migrate plls clocks to clk_regmap
  clk: meson: split divider and gate part of mpll
  clk: meson: rework meson8b cpu clock
  clk: meson: remove obsolete cpu_clk
  clk: meson: use hhi syscon if available

 drivers/clk/meson/Kconfig |9 +
 drivers/clk/meson/Makefile|5 +-
 drivers/clk/meson/axg.c   |  722 +
 drivers/clk/meson/axg.h   |6 +-
 drivers/clk/meson/clk-audio-divider.c |   63 +-
 drivers/clk/meson/clk-cpu.c   |  178 -
 drivers/clk/meson/clk-mpll.c  |  132 +---
 drivers/clk/meson/clk-pll.c   |  243 +++---
 drivers/clk/meson/clk-regmap.c|  166 
 drivers/clk/meson/clk-regmap.h|  111 +++
 drivers/clk/meson/clkc.h  |   93 +--
 drivers/clk/meson/gxbb-aoclk-regmap.c |   46 --
 drivers/clk/meson/gxbb-aoclk.c|   20 +-
 drivers/clk/meson/gxbb-aoclk.h|   11 -
 drivers/clk/meson/gxbb.c  | 1402 ++---
 

Re: [PATCH v2 00/19] clk: meson: use regmap in clock controllers

[Michael Turquette]

Bonjour Jerome,

Excerpts from Jerome Brunet's message of February 12, 2018 6:58 am:

This changeset is a rework of meson's clock controllers to use regmap
instead of directly using io memory. It based clk-meson next/drivers
and depends on few core clock patches, mainly to export generic clocks
helpers: [0],[1]. The line count is pretty high but the changes are
actually fairly simple and repetitive.

This work has been triggered by the fact that the HHI register space on
gxbb and axg provides more than just clocks. The display driver already
uses a syscon for HHI on gxbb. This is why gxbb did not use
devm_ioremap_resource() to map the registers, since it would have
reserved the memory region, preventing another driver from re-mapping
it. The cleaner solution is, of course, to use syscon to handle. The
purpose of this changeset is to allow it. Even if meson8b does not need
this ATM, there is real reason to leave it behind. It is actually easier
to migrate it as well, so all meson clock drivers may support regmap
only.

The rework starts with a few easy clean-ups. The real deal starts with
patch 5, which adds meson's clk_regmap. This will be used as common
structure to implement all the controller clocks. Having this replaces
the gxbb AO controller specific regmap gate. This structure will also be
re-used in upcoming controllers, such as the axg's AO and audio
controllers.  Each clock type is then migrated, one at a time, to this
new structure.

While at it, the meson clock drivers have been cleaned-up a bit,
removing the gate embedded in the mpll driver, simplifying the pll
driver and removing the legacy cpu_clk of meson8b.

The new code around the cpu clk of the meson8b is just re-implementation,
using simple elements, of the old cpu_clk. As explained by Martin, the
old cpu_clk would hang quite often when changing the rate of the cpu
clock. Surprisingly, the new implementation improved the situation a bit,
but still hangs from time to time. As this is not acceptable, the cpu
clk subtree as been switched to a read-only mode, preventing any change
of the cpu rate, until an acceptable solution is found.

With this series applied, the clock controllers of the gxbb, gxl and axg
SoC will try get regmap from their parent DT node. If this fails, they
will fallback to mapping the register themselves. This fallback will be
kept until platform DTs have changed so clock controllers is a child of
the HHI system controller.


Looks OK to me. As we discussed off-list, can you send this (and the
other meson patches) as a PR based on top of the clk-helpers branch in
the clk git tree? That should satisfy the dependencies (I hope).

Best regards,
Mike



Based on this changeset, more patches are coming. For those interested,
the WIP is available here [2]

Changes since v1 [3]:
* Fixed a few typos in patches descriptions
* Fixed cpu clock names on meson8b, as suggested by Martin
* Switched cpu clock subtree to reead-only mode
* Fix clk_regmap mux documentation, as reported by Yixun

[0]: https://lkml.kernel.org/r/20180118110144.30619-1-jbru...@baylibre.com
[1]: https://lkml.kernel.org/r/20180122105759.12206-1-jbru...@baylibre.com
[2]: https://github.com/jeromebrunet/linux/tree/v4.17/meson/clk-regmap
[1]: https://lkml.kernel.org/r/20180131180945.18025-1-jbru...@baylibre.com

Jerome Brunet (19):
  clk: meson: use dev pointer where possible
  clk: meson: use devm_of_clk_add_hw_provider
  clk: meson: only one loop index is necessary in probe
  clk: meson: remove obsolete comments
  clk: meson: add regmap clocks
  clk: meson: switch gxbb ao_clk to clk_regmap
  clk: meson: remove superseded aoclk_gate_regmap
  clk: meson: add regmap to the clock controllers
  clk: meson: migrate gates to clk_regmap
  clk: meson: migrate dividers to clk_regmap
  clk: meson: migrate muxes to clk_regmap
  clk: meson: add regmap helpers for parm
  clk: meson: migrate mplls clocks to clk_regmap
  clk: meson: migrate the audio divider clock to clk_regmap
  clk: meson: migrate plls clocks to clk_regmap
  clk: meson: split divider and gate part of mpll
  clk: meson: rework meson8b cpu clock
  clk: meson: remove obsolete cpu_clk
  clk: meson: use hhi syscon if available

 drivers/clk/meson/Kconfig |9 +
 drivers/clk/meson/Makefile|5 +-
 drivers/clk/meson/axg.c   |  722 +
 drivers/clk/meson/axg.h   |6 +-
 drivers/clk/meson/clk-audio-divider.c |   63 +-
 drivers/clk/meson/clk-cpu.c   |  178 -
 drivers/clk/meson/clk-mpll.c  |  132 +---
 drivers/clk/meson/clk-pll.c   |  243 +++---
 drivers/clk/meson/clk-regmap.c|  166 
 drivers/clk/meson/clk-regmap.h|  111 +++
 drivers/clk/meson/clkc.h  |   93 +--
 drivers/clk/meson/gxbb-aoclk-regmap.c |   46 --
 drivers/clk/meson/gxbb-aoclk.c|   20 +-
 drivers/clk/meson/gxbb-aoclk.h|   11 -
 drivers/clk/meson/gxbb.c  | 1402 ++---
 

Re: [PATCH v2 00/12] Introduce STM32MP1 clock driver

[Michael Turquette]

Excerpts from gabriel.fernan...@st.com's message of March 8, 2018 8:53 am:

From: Gabriel Fernandez 

v2:
  - Don't use MFD, use existing binding of STM32 RCC.
  - Rework Peripheral and Kernel clocks
  - cosmetic changes

This patch-set introduces clock driver for STM32MP157 based on Arm Cortex-A7.
The driver patch is split in several patches (by kind of clock) to facilitate
code reviewing.


Applied to clk-stm32mp1 towards v4.17.

Regards,
Mike



Gabriel Fernandez (12):
  dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings
  clk: stm32mp1: Introduce STM32MP1 clock driver
  clk: stm32mp1: add MP1 gate for hse/hsi/csi oscillators
  clk: stm32mp1: add Source Clocks for PLLs
  clk: stm32mp1: add PLL clocks
  clk: stm32mp1: add Post-dividers for PLL
  clk: stm32mp1: add Sub System clocks
  clk: stm32mp1: add Kernel timers
  clk: stm32mp1: add Peripheral & Kernel Clocks
  clk: stm32mp1: add RTC clock
  clk: stm32mp1: add MCO clocks
  clk: stm32mp1: add Debug clocks

 .../devicetree/bindings/clock/st,stm32mp1-rcc.txt  |   60 +
 drivers/clk/Kconfig|6 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk-stm32mp1.c | 2117 
 include/dt-bindings/clock/stm32mp1-clks.h  |  254 +++
 5 files changed, 2438 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.txt
 create mode 100644 drivers/clk/clk-stm32mp1.c
 create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h

--
1.9.1

Re: [PATCH v2 00/12] Introduce STM32MP1 clock driver

[Michael Turquette]

Excerpts from gabriel.fernan...@st.com's message of March 8, 2018 8:53 am:

From: Gabriel Fernandez 

v2:
  - Don't use MFD, use existing binding of STM32 RCC.
  - Rework Peripheral and Kernel clocks
  - cosmetic changes

This patch-set introduces clock driver for STM32MP157 based on Arm Cortex-A7.
The driver patch is split in several patches (by kind of clock) to facilitate
code reviewing.


Applied to clk-stm32mp1 towards v4.17.

Regards,
Mike



Gabriel Fernandez (12):
  dt-bindings: Document STM32MP1 Reset Clock Controller (RCC) bindings
  clk: stm32mp1: Introduce STM32MP1 clock driver
  clk: stm32mp1: add MP1 gate for hse/hsi/csi oscillators
  clk: stm32mp1: add Source Clocks for PLLs
  clk: stm32mp1: add PLL clocks
  clk: stm32mp1: add Post-dividers for PLL
  clk: stm32mp1: add Sub System clocks
  clk: stm32mp1: add Kernel timers
  clk: stm32mp1: add Peripheral & Kernel Clocks
  clk: stm32mp1: add RTC clock
  clk: stm32mp1: add MCO clocks
  clk: stm32mp1: add Debug clocks

 .../devicetree/bindings/clock/st,stm32mp1-rcc.txt  |   60 +
 drivers/clk/Kconfig|6 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk-stm32mp1.c | 2117 
 include/dt-bindings/clock/stm32mp1-clks.h  |  254 +++
 5 files changed, 2438 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.txt
 create mode 100644 drivers/clk/clk-stm32mp1.c
 create mode 100644 include/dt-bindings/clock/stm32mp1-clks.h

--
1.9.1

Re: [PATCH v2 0/8] clk: helpers and fixes

[Michael Turquette]

Excerpts from Jerome Brunet's message of February 14, 2018 5:43 am:

This changset is consist of various patches I have recently sent
for the clock framework. They are gathered here for your convinience.

The first two changes exports helpers of the generic clocks (divider and
mux). The goal is to avoid code duplication when writing clock driver
derived from these generic clock drivers.

The rest fixes various issues found in the clock framework while working on
a rework of meson's clock controllers [0]


Applied to clk-helpers towards v4.17.

Regards,
Mike



Changes since the v1s:
 * dropped lpc32xx divider read-only patches as requested by
   Vladimir Zapolskiy [2]
 * Squashed generic divider read-only patches
 * Squashed mux documentations patches

[0]: https://lkml.kernel.org/r/20180212145846.19380-1-jbru...@baylibre.com
[2]: https://lkml.kernel.org/r/54782a8f-9735-a574-d8e1-7ff3e9173...@mleia.com

Jerome Brunet (8):
  clk: divider: export clk_div_mask() helper
  clk: mux: add helper function for index/value translation
  clk: fix determine rate error with pass-through clock
  clk: migrate the count of orphaned clocks at init
  clk: call the clock init() callback before any other ops callback
  clk: fix mux clock documentation
  clk: divider: read-only divider can propagate rate change
  clk: qcom: use divider_ro_round_rate helper

 drivers/clk/clk-divider.c | 58 ++-
 drivers/clk/clk-mux.c | 75 ---
 drivers/clk/clk.c | 63 -
 drivers/clk/qcom/clk-regmap-divider.c | 20 +++---
 include/linux/clk-provider.h  | 23 ++-
 5 files changed, 146 insertions(+), 93 deletions(-)

--
2.14.3

Re: [PATCH v2 0/8] clk: helpers and fixes

[Michael Turquette]

Excerpts from Jerome Brunet's message of February 14, 2018 5:43 am:

This changset is consist of various patches I have recently sent
for the clock framework. They are gathered here for your convinience.

The first two changes exports helpers of the generic clocks (divider and
mux). The goal is to avoid code duplication when writing clock driver
derived from these generic clock drivers.

The rest fixes various issues found in the clock framework while working on
a rework of meson's clock controllers [0]


Applied to clk-helpers towards v4.17.

Regards,
Mike



Changes since the v1s:
 * dropped lpc32xx divider read-only patches as requested by
   Vladimir Zapolskiy [2]
 * Squashed generic divider read-only patches
 * Squashed mux documentations patches

[0]: https://lkml.kernel.org/r/20180212145846.19380-1-jbru...@baylibre.com
[2]: https://lkml.kernel.org/r/54782a8f-9735-a574-d8e1-7ff3e9173...@mleia.com

Jerome Brunet (8):
  clk: divider: export clk_div_mask() helper
  clk: mux: add helper function for index/value translation
  clk: fix determine rate error with pass-through clock
  clk: migrate the count of orphaned clocks at init
  clk: call the clock init() callback before any other ops callback
  clk: fix mux clock documentation
  clk: divider: read-only divider can propagate rate change
  clk: qcom: use divider_ro_round_rate helper

 drivers/clk/clk-divider.c | 58 ++-
 drivers/clk/clk-mux.c | 75 ---
 drivers/clk/clk.c | 63 -
 drivers/clk/qcom/clk-regmap-divider.c | 20 +++---
 include/linux/clk-provider.h  | 23 ++-
 5 files changed, 146 insertions(+), 93 deletions(-)

--
2.14.3

Re: [PATCH v5 12/44] clk: davinci: Add platform information for TI DA850 PSC

[Michael Turquette]

Hi Bartosz, all,

On Fri, Feb 9, 2018 at 8:22 AM, Bartosz Golaszewski  wrote:
> 2018-01-08 3:17 GMT+01:00 David Lechner :
>> This adds platform-specific declarations for the PSC clocks on TI DA850/
>> OMAP-L138/AM18XX SoCs.
>>
>> Signed-off-by: David Lechner 
>> ---
>>  drivers/clk/davinci/Makefile|   1 +
>>  drivers/clk/davinci/psc-da850.c | 117 
>> 
>>  include/linux/clk/davinci.h |   1 +
>>  3 files changed, 119 insertions(+)
>>  create mode 100644 drivers/clk/davinci/psc-da850.c
>>
>> diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
>> index fb14c8c..aef0390 100644
>> --- a/drivers/clk/davinci/Makefile
>> +++ b/drivers/clk/davinci/Makefile
>> @@ -11,4 +11,5 @@ obj-$(CONFIG_ARCH_DAVINCI_DM646x) += pll-dm646x.o
>>
>>  obj-y += psc.o
>>  obj-$(CONFIG_ARCH_DAVINCI_DA830)   += psc-da830.o
>> +obj-$(CONFIG_ARCH_DAVINCI_DA850)   += psc-da850.o
>>  endif
>> diff --git a/drivers/clk/davinci/psc-da850.c 
>> b/drivers/clk/davinci/psc-da850.c
>> new file mode 100644
>> index 000..3b4583d
>> --- /dev/null
>> +++ b/drivers/clk/davinci/psc-da850.c
>> @@ -0,0 +1,117 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * PSC clock descriptions for TI DA850/OMAP-L138/AM18XX
>> + *
>> + * Copyright (C) 2017 David Lechner 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "psc.h"
>> +
>> +static const struct davinci_psc_clk_info da850_psc0_info[] __initconst = {
>> +   LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(3, 0, aemif, pll0_sysclk3, 0),
>> +   LPSC(4, 0, spi0, pll0_sysclk2, 0),
>> +   LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
>> +   LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>> +   LPSC(7, 0, arm_rom, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(9, 0, uart0, pll0_sysclk2, 0),
>> +   LPSC(13, 0, pruss, pll0_sysclk2, 0),
>> +   LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
>> +   LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
>> +   { }
>> +};
>> +
>> +static const struct davinci_psc_clk_info da850_psc1_info[] __initconst = {
>> +   LPSC(0, 0, tpcc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(1, 0, usb0, pll0_sysclk2, 0),
>> +   LPSC(2, 0, usb1, pll0_sysclk4, 0),
>> +   LPSC(3, 0, gpio, pll0_sysclk4, 0),
>> +   LPSC(5, 0, emac, pll0_sysclk4, 0),
>> +   LPSC(6, 0, emif3, pll0_sysclk5, LPSC_ALWAYS_ENABLED),
>> +   LPSC(7, 0, mcasp0, async3, 0),
>> +   LPSC(8, 0, sata, pll0_sysclk2, LPSC_FORCE),
>> +   LPSC(9, 0, vpif, pll0_sysclk2, 0),
>> +   LPSC(10, 0, spi1, async3, 0),
>> +   LPSC(11, 0, i2c1, pll0_sysclk4, 0),
>> +   LPSC(12, 0, uart1, async3, 0),
>> +   LPSC(13, 0, uart2, async3, 0),
>> +   LPSC(14, 0, mcbsp0, async3, 0),
>> +   LPSC(15, 0, mcbsp1, async3, 0),
>> +   LPSC(16, 0, lcdc, pll0_sysclk2, 0),
>> +   LPSC(17, 0, ehrpwm, async3, 0),
>> +   LPSC(18, 0, mmcsd1, pll0_sysclk2, 0),
>> +   LPSC(20, 0, ecap, async3, 0),
>> +   LPSC(21, 0, tptc2, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   { }
>> +};
>> +
>> +void __init da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1)
>> +{
>> +   struct clk_onecell_data *clk_data;
>> +
>> +   clk_data = davinci_psc_register_clocks(psc0, da850_psc0_info, 16);
>> +   if (!clk_data)
>> +   return;
>> +
>> +   clk_register_clkdev(clk_data->clks[3], NULL, "ti-aemif");
>> +   clk_register_clkdev(clk_data->clks[3], "aemif", "davinci-nand.0");
>> +   clk_register_clkdev(clk_data->clks[4], NULL, "spi_davinci.0");
>> +   clk_register_clkdev(clk_data->clks[5], NULL, "da830-mmc.0");
>> +   clk_register_clkdev(clk_data->clks[9], NULL, "serial8250.0");
>> +   clk_register_clkdev(clk_data->clks[14], "arm", NULL);
>> +   clk_register_clkdev(clk_data->clks[15], NULL, "davinci-rproc.0");
>> +
>> +   clk_free_onecell_data(clk_data);
>> +
>> +   clk_data = davinci_psc_register_clocks(psc1, da850_psc1_info, 32);
>> +   if (!clk_data)
>> +   return;
>> +
>> +   clk_register_clkdev(clk_data->clks[1], "usb20_psc_clk", NULL);
>> +   clk_register_clkdev(clk_data->clks[1], NULL, "musb-da8xx");
>> +   clk_register_clkdev(clk_data->clks[1], NULL, "cppi41-dmaengine");
>> +   clk_register_clkdev(clk_data->clks[2], NULL, "ohci-da8xx");
>> +   clk_register_clkdev(clk_data->clks[3], "gpio", NULL);
>> +   clk_register_clkdev(clk_data->clks[5], NULL, "davinci_emac.1");
>> +   clk_register_clkdev(clk_data->clks[5], "fck", "davinci_mdio.0");
>> +   clk_register_clkdev(clk_data->clks[7], NULL, "davinci-mcasp.0");
>> +   clk_register_clkdev(clk_data->clks[8], "fck", 

Re: [PATCH v5 12/44] clk: davinci: Add platform information for TI DA850 PSC

[Michael Turquette]

Hi Bartosz, all,

On Fri, Feb 9, 2018 at 8:22 AM, Bartosz Golaszewski  wrote:
> 2018-01-08 3:17 GMT+01:00 David Lechner :
>> This adds platform-specific declarations for the PSC clocks on TI DA850/
>> OMAP-L138/AM18XX SoCs.
>>
>> Signed-off-by: David Lechner 
>> ---
>>  drivers/clk/davinci/Makefile|   1 +
>>  drivers/clk/davinci/psc-da850.c | 117 
>> 
>>  include/linux/clk/davinci.h |   1 +
>>  3 files changed, 119 insertions(+)
>>  create mode 100644 drivers/clk/davinci/psc-da850.c
>>
>> diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
>> index fb14c8c..aef0390 100644
>> --- a/drivers/clk/davinci/Makefile
>> +++ b/drivers/clk/davinci/Makefile
>> @@ -11,4 +11,5 @@ obj-$(CONFIG_ARCH_DAVINCI_DM646x) += pll-dm646x.o
>>
>>  obj-y += psc.o
>>  obj-$(CONFIG_ARCH_DAVINCI_DA830)   += psc-da830.o
>> +obj-$(CONFIG_ARCH_DAVINCI_DA850)   += psc-da850.o
>>  endif
>> diff --git a/drivers/clk/davinci/psc-da850.c 
>> b/drivers/clk/davinci/psc-da850.c
>> new file mode 100644
>> index 000..3b4583d
>> --- /dev/null
>> +++ b/drivers/clk/davinci/psc-da850.c
>> @@ -0,0 +1,117 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * PSC clock descriptions for TI DA850/OMAP-L138/AM18XX
>> + *
>> + * Copyright (C) 2017 David Lechner 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "psc.h"
>> +
>> +static const struct davinci_psc_clk_info da850_psc0_info[] __initconst = {
>> +   LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(3, 0, aemif, pll0_sysclk3, 0),
>> +   LPSC(4, 0, spi0, pll0_sysclk2, 0),
>> +   LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
>> +   LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>> +   LPSC(7, 0, arm_rom, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(9, 0, uart0, pll0_sysclk2, 0),
>> +   LPSC(13, 0, pruss, pll0_sysclk2, 0),
>> +   LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
>> +   LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
>> +   { }
>> +};
>> +
>> +static const struct davinci_psc_clk_info da850_psc1_info[] __initconst = {
>> +   LPSC(0, 0, tpcc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   LPSC(1, 0, usb0, pll0_sysclk2, 0),
>> +   LPSC(2, 0, usb1, pll0_sysclk4, 0),
>> +   LPSC(3, 0, gpio, pll0_sysclk4, 0),
>> +   LPSC(5, 0, emac, pll0_sysclk4, 0),
>> +   LPSC(6, 0, emif3, pll0_sysclk5, LPSC_ALWAYS_ENABLED),
>> +   LPSC(7, 0, mcasp0, async3, 0),
>> +   LPSC(8, 0, sata, pll0_sysclk2, LPSC_FORCE),
>> +   LPSC(9, 0, vpif, pll0_sysclk2, 0),
>> +   LPSC(10, 0, spi1, async3, 0),
>> +   LPSC(11, 0, i2c1, pll0_sysclk4, 0),
>> +   LPSC(12, 0, uart1, async3, 0),
>> +   LPSC(13, 0, uart2, async3, 0),
>> +   LPSC(14, 0, mcbsp0, async3, 0),
>> +   LPSC(15, 0, mcbsp1, async3, 0),
>> +   LPSC(16, 0, lcdc, pll0_sysclk2, 0),
>> +   LPSC(17, 0, ehrpwm, async3, 0),
>> +   LPSC(18, 0, mmcsd1, pll0_sysclk2, 0),
>> +   LPSC(20, 0, ecap, async3, 0),
>> +   LPSC(21, 0, tptc2, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> +   { }
>> +};
>> +
>> +void __init da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1)
>> +{
>> +   struct clk_onecell_data *clk_data;
>> +
>> +   clk_data = davinci_psc_register_clocks(psc0, da850_psc0_info, 16);
>> +   if (!clk_data)
>> +   return;
>> +
>> +   clk_register_clkdev(clk_data->clks[3], NULL, "ti-aemif");
>> +   clk_register_clkdev(clk_data->clks[3], "aemif", "davinci-nand.0");
>> +   clk_register_clkdev(clk_data->clks[4], NULL, "spi_davinci.0");
>> +   clk_register_clkdev(clk_data->clks[5], NULL, "da830-mmc.0");
>> +   clk_register_clkdev(clk_data->clks[9], NULL, "serial8250.0");
>> +   clk_register_clkdev(clk_data->clks[14], "arm", NULL);
>> +   clk_register_clkdev(clk_data->clks[15], NULL, "davinci-rproc.0");
>> +
>> +   clk_free_onecell_data(clk_data);
>> +
>> +   clk_data = davinci_psc_register_clocks(psc1, da850_psc1_info, 32);
>> +   if (!clk_data)
>> +   return;
>> +
>> +   clk_register_clkdev(clk_data->clks[1], "usb20_psc_clk", NULL);
>> +   clk_register_clkdev(clk_data->clks[1], NULL, "musb-da8xx");
>> +   clk_register_clkdev(clk_data->clks[1], NULL, "cppi41-dmaengine");
>> +   clk_register_clkdev(clk_data->clks[2], NULL, "ohci-da8xx");
>> +   clk_register_clkdev(clk_data->clks[3], "gpio", NULL);
>> +   clk_register_clkdev(clk_data->clks[5], NULL, "davinci_emac.1");
>> +   clk_register_clkdev(clk_data->clks[5], "fck", "davinci_mdio.0");
>> +   clk_register_clkdev(clk_data->clks[7], NULL, "davinci-mcasp.0");
>> +   clk_register_clkdev(clk_data->clks[8], "fck", "ahci_da850");
>> +   clk_register_clkdev(clk_data->clks[9], NULL, "vpif");
>> +  

Re: [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation

[Michael Turquette]

Quoting Matthias Brugger (2017-12-20 09:13:12)
> 
> 
> On 12/19/2017 02:32 AM, Stephen Boyd wrote:
> > On 12/14, Matthias Brugger wrote:
> >> Hi Stephen, Michael,
> >>
> >> On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> >>> The ethsys registers a reset controller, so we need to specify a
> >>> reset cell. This patch fixes the documentation.
> >>>
> >>> Signed-off-by: Matthias Brugger 
> >>> ---
> >>>  Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git 
> >>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt 
> >>> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> index 7aa3fa167668..6cc7840ff37a 100644
> >>> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> @@ -20,4 +20,5 @@ ethsys: clock-controller@1b00 {
> >>> compatible = "mediatek,mt2701-ethsys", "syscon";
> >>> reg = <0 0x1b00 0 0x1000>;
> >>> #clock-cells = <1>;
> >>> +   #reset-cells = <1>;
> >>>  };
> >>>
> >>
> >> Will you take this patch through the clk tree, or shall I take it through 
> >> my SoC
> >> tree?
> >>
> > 
> > It's resets, we are clk maintainers. I'm clkfused.
> > 
> > You can take it, along with my
> > 
> > Acked-by: Stephen Boyd 
> > 
> > if you like/expect conflicts.
> > 
> 
> These are resets in the clock IP-block. I'll take it through my branch, I 
> don't
> expect any conflicts.

Sounds good to me.

Best regards,
Mike

> 
> Regards,
> Matthias

Re: [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation

[Michael Turquette]

Quoting Matthias Brugger (2017-12-20 09:13:12)
> 
> 
> On 12/19/2017 02:32 AM, Stephen Boyd wrote:
> > On 12/14, Matthias Brugger wrote:
> >> Hi Stephen, Michael,
> >>
> >> On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> >>> The ethsys registers a reset controller, so we need to specify a
> >>> reset cell. This patch fixes the documentation.
> >>>
> >>> Signed-off-by: Matthias Brugger 
> >>> ---
> >>>  Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git 
> >>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt 
> >>> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> index 7aa3fa167668..6cc7840ff37a 100644
> >>> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >>> @@ -20,4 +20,5 @@ ethsys: clock-controller@1b00 {
> >>> compatible = "mediatek,mt2701-ethsys", "syscon";
> >>> reg = <0 0x1b00 0 0x1000>;
> >>> #clock-cells = <1>;
> >>> +   #reset-cells = <1>;
> >>>  };
> >>>
> >>
> >> Will you take this patch through the clk tree, or shall I take it through 
> >> my SoC
> >> tree?
> >>
> > 
> > It's resets, we are clk maintainers. I'm clkfused.
> > 
> > You can take it, along with my
> > 
> > Acked-by: Stephen Boyd 
> > 
> > if you like/expect conflicts.
> > 
> 
> These are resets in the clock IP-block. I'll take it through my branch, I 
> don't
> expect any conflicts.

Sounds good to me.

Best regards,
Mike

> 
> Regards,
> Matthias

Re: [PATCH] clk: fix spin_lock/unlock imbalance on bad clk_enable() reentrancy

[Michael Turquette]

Quoting David Lechner (2017-12-20 10:53:27)
> On 12/19/2017 04:29 PM, Michael Turquette wrote:
> > Hi David,
> > 
> > Quoting David Lechner (2017-12-15 08:29:56)
> >> On 12/12/2017 10:14 PM, David Lechner wrote:
> >>> On 12/12/2017 05:43 PM, David Lechner wrote:
> >>>> If clk_enable() is called in reentrant way and spin_trylock_irqsave() is
> >>>> not working as expected, it is possible to get a negative enable_refcnt
> >>>> which results in a missed call to spin_unlock_irqrestore().
> >>>>
> >>>> It works like this:
> >>>>
> >>>> 1. clk_enable() is called.
> >>>> 2. clk_enable_unlock() calls spin_trylock_irqsave() and sets
> >>>>      enable_refcnt = 1.
> >>>> 3. Another clk_enable() is called before the first has returned
> >>>>      (reentrant), but somehow spin_trylock_irqsave() is returning true.
> >>>>      (I'm not sure how/why this is happening yet, but it is happening
> >>>> to me
> >>>>      with arch/arm/mach-davinci clocks that I am working on).
> >>>
> >>> I think I have figured out that since CONFIG_SMP=n and
> >>> CONFIG_DEBUG_SPINLOCK=n on my kernel that
> >>>
> >>> #define arch_spin_trylock(lock)({ barrier(); (void)(lock); 1; })
> >>>
> >>> in include/linux/spinlock_up.h is causing the problem.
> >>>
> >>> So, basically, reentrancy of clk_enable() is broken for non-SMP systems,
> >>> but I'm not sure I know how to fix it.
> >>>
> >>>
> >>
> >> Here is what I came up with for a fix. If it looks reasonable, I will
> >> resend as a proper patch.
> >>
> >> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >> index bb1b1f9..53fad5f 100644
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -136,12 +136,23 @@ static void clk_prepare_unlock(void)
> >>   mutex_unlock(_lock);
> >>}
> >>
> >> +#ifdef CONFIG_SMP
> >> +#define NO_SMP 0
> >> +#else
> >> +#define NO_SMP 1
> >> +#endif
> >> +
> >>static unsigned long clk_enable_lock(void)
> >>   __acquires(enable_lock)
> >>{
> >> -   unsigned long flags;
> >> +   unsigned long flags = 0;
> >>
> >> -   if (!spin_trylock_irqsave(_lock, flags)) {
> >> +   /*
> >> +* spin_trylock_irqsave() always returns true on non-SMP system
> >> (unless
> > 
> > Ugh, wrapped lines in patch make me sad.
> 
> Sorry, I was being lazy. :-/
> 
> > 
> >> +* spin lock debugging is enabled) so don't call
> >> spin_trylock_irqsave()
> >> +* unless we are on an SMP system.
> >> +*/
> >> +   if (NO_SMP || !spin_trylock_irqsave(_lock, flags)) {
> > 
> > I'm not sure that this looks reasonable. The inverse logic (NO_SMP = 0
> > being equivalent to SMP = 1) just makes things harder to read for no
> > reason.
> > 
> > More to the point, did you fix your enable/disable call imbalance? If
> > so, did you test that fix without this patch? I'd like to know if fixing
> > the enable/disable imbalance is Good Enough. I'd prefer to take only
> > that change and not this patch.
> 
> Without this patch, the imbalance in calls to spin lock/unlock are 
> fixed, but I still get several WARN_ONCE_ON() because the reference 
> count becomes negative, so I would not call it Good Enough.

Several WARN_ON_ONCE? Have you narrowed down exactly which conditions in
the lock/unlock path are firing?

Also, I wasn't referring to the lock/unlock imbalance in my email above.
I was referring to the enable count mismatch. Have you fixed that bug? I
assume it's an incorrect clk consumer driver causing it.

Regards,
Mike

> 
> > 
> > Best regards,
> > Mike
> > 
> >>   if (enable_owner == current) {
> >>   enable_refcnt++;
> >>   __acquire(enable_lock);
> >>
> 

Re: [PATCH] clk: fix spin_lock/unlock imbalance on bad clk_enable() reentrancy

[Michael Turquette]

Quoting David Lechner (2017-12-20 10:53:27)
> On 12/19/2017 04:29 PM, Michael Turquette wrote:
> > Hi David,
> > 
> > Quoting David Lechner (2017-12-15 08:29:56)
> >> On 12/12/2017 10:14 PM, David Lechner wrote:
> >>> On 12/12/2017 05:43 PM, David Lechner wrote:
> >>>> If clk_enable() is called in reentrant way and spin_trylock_irqsave() is
> >>>> not working as expected, it is possible to get a negative enable_refcnt
> >>>> which results in a missed call to spin_unlock_irqrestore().
> >>>>
> >>>> It works like this:
> >>>>
> >>>> 1. clk_enable() is called.
> >>>> 2. clk_enable_unlock() calls spin_trylock_irqsave() and sets
> >>>>      enable_refcnt = 1.
> >>>> 3. Another clk_enable() is called before the first has returned
> >>>>      (reentrant), but somehow spin_trylock_irqsave() is returning true.
> >>>>      (I'm not sure how/why this is happening yet, but it is happening
> >>>> to me
> >>>>      with arch/arm/mach-davinci clocks that I am working on).
> >>>
> >>> I think I have figured out that since CONFIG_SMP=n and
> >>> CONFIG_DEBUG_SPINLOCK=n on my kernel that
> >>>
> >>> #define arch_spin_trylock(lock)({ barrier(); (void)(lock); 1; })
> >>>
> >>> in include/linux/spinlock_up.h is causing the problem.
> >>>
> >>> So, basically, reentrancy of clk_enable() is broken for non-SMP systems,
> >>> but I'm not sure I know how to fix it.
> >>>
> >>>
> >>
> >> Here is what I came up with for a fix. If it looks reasonable, I will
> >> resend as a proper patch.
> >>
> >> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >> index bb1b1f9..53fad5f 100644
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -136,12 +136,23 @@ static void clk_prepare_unlock(void)
> >>   mutex_unlock(_lock);
> >>}
> >>
> >> +#ifdef CONFIG_SMP
> >> +#define NO_SMP 0
> >> +#else
> >> +#define NO_SMP 1
> >> +#endif
> >> +
> >>static unsigned long clk_enable_lock(void)
> >>   __acquires(enable_lock)
> >>{
> >> -   unsigned long flags;
> >> +   unsigned long flags = 0;
> >>
> >> -   if (!spin_trylock_irqsave(_lock, flags)) {
> >> +   /*
> >> +* spin_trylock_irqsave() always returns true on non-SMP system
> >> (unless
> > 
> > Ugh, wrapped lines in patch make me sad.
> 
> Sorry, I was being lazy. :-/
> 
> > 
> >> +* spin lock debugging is enabled) so don't call
> >> spin_trylock_irqsave()
> >> +* unless we are on an SMP system.
> >> +*/
> >> +   if (NO_SMP || !spin_trylock_irqsave(_lock, flags)) {
> > 
> > I'm not sure that this looks reasonable. The inverse logic (NO_SMP = 0
> > being equivalent to SMP = 1) just makes things harder to read for no
> > reason.
> > 
> > More to the point, did you fix your enable/disable call imbalance? If
> > so, did you test that fix without this patch? I'd like to know if fixing
> > the enable/disable imbalance is Good Enough. I'd prefer to take only
> > that change and not this patch.
> 
> Without this patch, the imbalance in calls to spin lock/unlock are 
> fixed, but I still get several WARN_ONCE_ON() because the reference 
> count becomes negative, so I would not call it Good Enough.

Several WARN_ON_ONCE? Have you narrowed down exactly which conditions in
the lock/unlock path are firing?

Also, I wasn't referring to the lock/unlock imbalance in my email above.
I was referring to the enable count mismatch. Have you fixed that bug? I
assume it's an incorrect clk consumer driver causing it.

Regards,
Mike

> 
> > 
> > Best regards,
> > Mike
> > 
> >>   if (enable_owner == current) {
> >>   enable_refcnt++;
> >>   __acquire(enable_lock);
> >>
> 

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

[Michael Turquette]

Quoting Jerome Brunet (2017-12-01 13:51:50)
> This Patchset is related the RFC [0] and the discussion around
> CLK_SET_RATE_GATE available here [1]
> 
> This patchset introduce clock protection to the CCF core. This can then
> be used for:
> 
> * Provide a way for a consumer to claim exclusivity over the rate control
>   of a provider. Some clock consumers require that a clock rate must not
>   deviate from its selected frequency. There can be several reasons for
>   this, not least of which is that some hardware may not be able to
>   handle or recover from a glitch caused by changing the clock rate while
>   the hardware is in operation. For such HW, The ability to get exclusive
>   control of a clock's rate, and release that exclusivity, could be seen
>   as a fundamental clock rate control primitive. The exclusivity is not
>   preemptible, so when claimed more than once, is rate is effectively
>   locked.
> 
> * Provide a similar functionality to providers themselves, fixing
>   CLK_SET_RATE_GATE flag (enforce clock gating along the tree). While
>   there might still be a few platforms relying the broken implementation,
>   tests done has shown this change to be pretty safe.

Applied to clk-protect-rate, with the exception that I did not apply
"clk: fix CLK_SET_RATE_GATE with clock rate protection" as it breaks
qcom clk code.

Stephen, do you plan to fix up the qcom clock code so that the
SET_RATE_GATE improvement can go in?

Thanks,
Mike

> 
> Changes since v4: [4]
>  - Fixup documentation comments
>  - Fix error on exclusive API when CCF is disabled
> 
> Changes since v3: [3]
>  - Reorder patches following Stephen comments
>  - Add before/after examples to the cosmetic change
>  - Remove loops around protection where possible
>  - Rename the API from "protect" to "exclusive" which decribe what the
>code better
> 
> Changes since v2: [2]
>  - Fix issues reported by Adriana Reus (Thanks !)
>  - Dropped patch "clk: move CLK_SET_RATE_GATE protection from prepare
>to enable". This was broken as the protect count, like the prepare_count
>should only be accessed under the prepare_lock.
> 
> Changes since v1: [1]
>  - Check if the rate would actually change before continuing, and bail-out
>early if not.
> 
> Changes since RFC: [0]
>  - s/clk_protect/clk_rate_protect
>  - Request rework around core_nolock function
>  - Add clk_set_rate_protect
>  - Reword clk_rate_protect and clk_unprotect documentation
>  - Add few comments to explain the code
>  - Add fixes for CLK_SET_RATE_GATE
> 
> This was tested with the audio use case mentioned in [1]
> 
> [0]: https://lkml.kernel.org/r/20170321183330.26722-1-jbru...@baylibre.com
> [1]: 
> https://lkml.kernel.org/r/148942423440.82235.17188153691656009029@resonance
> [2]: https://lkml.kernel.org/r/20170521215958.19743-1-jbru...@baylibre.com
> [3]: https://lkml.kernel.org/r/20170612194438.12298-1-jbru...@baylibre.com
> [4]: https://lkml.kernel.org/r/20170924200030.6227-1-jbru...@baylibre.com
> 
> Jerome Brunet (10):
>   clk: fix incorrect usage of ENOSYS
>   clk: take the prepare lock out of clk_core_set_parent
>   clk: add clk_core_set_phase_nolock function
>   clk: rework calls to round and determine rate callbacks
>   clk: use round rate to bail out early in set_rate
>   clk: add clock protection mechanism to clk core
>   clk: cosmetic changes to clk_summary debugfs entry
>   clk: fix CLK_SET_RATE_GATE with clock rate protection
>   clk: add clk_rate_exclusive api
>   clk: fix set_rate_range when current rate is out of range
> 
>  drivers/clk/clk.c| 509 
> +--
>  include/linux/clk-provider.h |   1 +
>  include/linux/clk.h  |  62 ++
>  3 files changed, 502 insertions(+), 70 deletions(-)
> 
> -- 
> 2.14.3
> 

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

[Michael Turquette]

Quoting Jerome Brunet (2017-12-01 13:51:50)
> This Patchset is related the RFC [0] and the discussion around
> CLK_SET_RATE_GATE available here [1]
> 
> This patchset introduce clock protection to the CCF core. This can then
> be used for:
> 
> * Provide a way for a consumer to claim exclusivity over the rate control
>   of a provider. Some clock consumers require that a clock rate must not
>   deviate from its selected frequency. There can be several reasons for
>   this, not least of which is that some hardware may not be able to
>   handle or recover from a glitch caused by changing the clock rate while
>   the hardware is in operation. For such HW, The ability to get exclusive
>   control of a clock's rate, and release that exclusivity, could be seen
>   as a fundamental clock rate control primitive. The exclusivity is not
>   preemptible, so when claimed more than once, is rate is effectively
>   locked.
> 
> * Provide a similar functionality to providers themselves, fixing
>   CLK_SET_RATE_GATE flag (enforce clock gating along the tree). While
>   there might still be a few platforms relying the broken implementation,
>   tests done has shown this change to be pretty safe.

Applied to clk-protect-rate, with the exception that I did not apply
"clk: fix CLK_SET_RATE_GATE with clock rate protection" as it breaks
qcom clk code.

Stephen, do you plan to fix up the qcom clock code so that the
SET_RATE_GATE improvement can go in?

Thanks,
Mike

> 
> Changes since v4: [4]
>  - Fixup documentation comments
>  - Fix error on exclusive API when CCF is disabled
> 
> Changes since v3: [3]
>  - Reorder patches following Stephen comments
>  - Add before/after examples to the cosmetic change
>  - Remove loops around protection where possible
>  - Rename the API from "protect" to "exclusive" which decribe what the
>code better
> 
> Changes since v2: [2]
>  - Fix issues reported by Adriana Reus (Thanks !)
>  - Dropped patch "clk: move CLK_SET_RATE_GATE protection from prepare
>to enable". This was broken as the protect count, like the prepare_count
>should only be accessed under the prepare_lock.
> 
> Changes since v1: [1]
>  - Check if the rate would actually change before continuing, and bail-out
>early if not.
> 
> Changes since RFC: [0]
>  - s/clk_protect/clk_rate_protect
>  - Request rework around core_nolock function
>  - Add clk_set_rate_protect
>  - Reword clk_rate_protect and clk_unprotect documentation
>  - Add few comments to explain the code
>  - Add fixes for CLK_SET_RATE_GATE
> 
> This was tested with the audio use case mentioned in [1]
> 
> [0]: https://lkml.kernel.org/r/20170321183330.26722-1-jbru...@baylibre.com
> [1]: 
> https://lkml.kernel.org/r/148942423440.82235.17188153691656009029@resonance
> [2]: https://lkml.kernel.org/r/20170521215958.19743-1-jbru...@baylibre.com
> [3]: https://lkml.kernel.org/r/20170612194438.12298-1-jbru...@baylibre.com
> [4]: https://lkml.kernel.org/r/20170924200030.6227-1-jbru...@baylibre.com
> 
> Jerome Brunet (10):
>   clk: fix incorrect usage of ENOSYS
>   clk: take the prepare lock out of clk_core_set_parent
>   clk: add clk_core_set_phase_nolock function
>   clk: rework calls to round and determine rate callbacks
>   clk: use round rate to bail out early in set_rate
>   clk: add clock protection mechanism to clk core
>   clk: cosmetic changes to clk_summary debugfs entry
>   clk: fix CLK_SET_RATE_GATE with clock rate protection
>   clk: add clk_rate_exclusive api
>   clk: fix set_rate_range when current rate is out of range
> 
>  drivers/clk/clk.c| 509 
> +--
>  include/linux/clk-provider.h |   1 +
>  include/linux/clk.h  |  62 ++
>  3 files changed, 502 insertions(+), 70 deletions(-)
> 
> -- 
> 2.14.3
> 

Re: [PATCH] clk: fix spin_lock/unlock imbalance on bad clk_enable() reentrancy

[Michael Turquette]

Hi David,

Quoting David Lechner (2017-12-15 08:29:56)
> On 12/12/2017 10:14 PM, David Lechner wrote:
> > On 12/12/2017 05:43 PM, David Lechner wrote:
> >> If clk_enable() is called in reentrant way and spin_trylock_irqsave() is
> >> not working as expected, it is possible to get a negative enable_refcnt
> >> which results in a missed call to spin_unlock_irqrestore().
> >>
> >> It works like this:
> >>
> >> 1. clk_enable() is called.
> >> 2. clk_enable_unlock() calls spin_trylock_irqsave() and sets
> >>     enable_refcnt = 1.
> >> 3. Another clk_enable() is called before the first has returned
> >>     (reentrant), but somehow spin_trylock_irqsave() is returning true.
> >>     (I'm not sure how/why this is happening yet, but it is happening 
> >> to me
> >>     with arch/arm/mach-davinci clocks that I am working on).
> > 
> > I think I have figured out that since CONFIG_SMP=n and 
> > CONFIG_DEBUG_SPINLOCK=n on my kernel that
> > 
> > #define arch_spin_trylock(lock)({ barrier(); (void)(lock); 1; })
> > 
> > in include/linux/spinlock_up.h is causing the problem.
> > 
> > So, basically, reentrancy of clk_enable() is broken for non-SMP systems, 
> > but I'm not sure I know how to fix it.
> > 
> > 
> 
> Here is what I came up with for a fix. If it looks reasonable, I will 
> resend as a proper patch.
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index bb1b1f9..53fad5f 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -136,12 +136,23 @@ static void clk_prepare_unlock(void)
>  mutex_unlock(_lock);
>   }
> 
> +#ifdef CONFIG_SMP
> +#define NO_SMP 0
> +#else
> +#define NO_SMP 1
> +#endif
> +
>   static unsigned long clk_enable_lock(void)
>  __acquires(enable_lock)
>   {
> -   unsigned long flags;
> +   unsigned long flags = 0;
> 
> -   if (!spin_trylock_irqsave(_lock, flags)) {
> +   /*
> +* spin_trylock_irqsave() always returns true on non-SMP system 
> (unless

Ugh, wrapped lines in patch make me sad.

> +* spin lock debugging is enabled) so don't call 
> spin_trylock_irqsave()
> +* unless we are on an SMP system.
> +*/
> +   if (NO_SMP || !spin_trylock_irqsave(_lock, flags)) {

I'm not sure that this looks reasonable. The inverse logic (NO_SMP = 0
being equivalent to SMP = 1) just makes things harder to read for no
reason.

More to the point, did you fix your enable/disable call imbalance? If
so, did you test that fix without this patch? I'd like to know if fixing
the enable/disable imbalance is Good Enough. I'd prefer to take only
that change and not this patch.

Best regards,
Mike

>  if (enable_owner == current) {
>  enable_refcnt++;
>  __acquire(enable_lock);
> 

Re: [PATCH] clk: fix spin_lock/unlock imbalance on bad clk_enable() reentrancy

[Michael Turquette]

Hi David,

Quoting David Lechner (2017-12-15 08:29:56)
> On 12/12/2017 10:14 PM, David Lechner wrote:
> > On 12/12/2017 05:43 PM, David Lechner wrote:
> >> If clk_enable() is called in reentrant way and spin_trylock_irqsave() is
> >> not working as expected, it is possible to get a negative enable_refcnt
> >> which results in a missed call to spin_unlock_irqrestore().
> >>
> >> It works like this:
> >>
> >> 1. clk_enable() is called.
> >> 2. clk_enable_unlock() calls spin_trylock_irqsave() and sets
> >>     enable_refcnt = 1.
> >> 3. Another clk_enable() is called before the first has returned
> >>     (reentrant), but somehow spin_trylock_irqsave() is returning true.
> >>     (I'm not sure how/why this is happening yet, but it is happening 
> >> to me
> >>     with arch/arm/mach-davinci clocks that I am working on).
> > 
> > I think I have figured out that since CONFIG_SMP=n and 
> > CONFIG_DEBUG_SPINLOCK=n on my kernel that
> > 
> > #define arch_spin_trylock(lock)({ barrier(); (void)(lock); 1; })
> > 
> > in include/linux/spinlock_up.h is causing the problem.
> > 
> > So, basically, reentrancy of clk_enable() is broken for non-SMP systems, 
> > but I'm not sure I know how to fix it.
> > 
> > 
> 
> Here is what I came up with for a fix. If it looks reasonable, I will 
> resend as a proper patch.
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index bb1b1f9..53fad5f 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -136,12 +136,23 @@ static void clk_prepare_unlock(void)
>  mutex_unlock(_lock);
>   }
> 
> +#ifdef CONFIG_SMP
> +#define NO_SMP 0
> +#else
> +#define NO_SMP 1
> +#endif
> +
>   static unsigned long clk_enable_lock(void)
>  __acquires(enable_lock)
>   {
> -   unsigned long flags;
> +   unsigned long flags = 0;
> 
> -   if (!spin_trylock_irqsave(_lock, flags)) {
> +   /*
> +* spin_trylock_irqsave() always returns true on non-SMP system 
> (unless

Ugh, wrapped lines in patch make me sad.

> +* spin lock debugging is enabled) so don't call 
> spin_trylock_irqsave()
> +* unless we are on an SMP system.
> +*/
> +   if (NO_SMP || !spin_trylock_irqsave(_lock, flags)) {

I'm not sure that this looks reasonable. The inverse logic (NO_SMP = 0
being equivalent to SMP = 1) just makes things harder to read for no
reason.

More to the point, did you fix your enable/disable call imbalance? If
so, did you test that fix without this patch? I'd like to know if fixing
the enable/disable imbalance is Good Enough. I'd prefer to take only
that change and not this patch.

Best regards,
Mike

>  if (enable_owner == current) {
>  enable_refcnt++;
>  __acquire(enable_lock);
> 

Re: [PATCH v2 1/2] clk: tegra: Mark HCLK, SCLK, EMC, MC and PLL_P outputs as critical

[Michael Turquette]

Quoting Dmitry Osipenko (2017-12-19 12:20:56)
> On 19.12.2017 22:56, Michael Turquette wrote:
> > Quoting Dmitry Osipenko (2017-12-18 19:59:06)
> >> Machine dies if HCLK, SCLK or EMC is disabled, hence mark these clocks
> >> as critical. Currently some of drivers do not manage clocks properly,
> >> expecting clocks to be 'always enabled', these clocks are MC and PLL_P
> >> outputs. Let's mark MC or PLL_P outputs as critical for now and revert
> >> this change once drivers would be corrected.
> > 
> > Are the drivers that do not manage their clocks correctly merged
> > upstream? If so can we fix those drivers instead of marking clocks as
> > critical?
> 
> All the drivers are in upstream for a quite long time already. We should be 
> able
> to correct them, but I haven't tried yet.
> 
> > If not can we annotate the flags below with a comment stating to remove
> > the critical clock flag once the consumer driver gets a clue?
> I'll try to take a look at how much effort it would take to correct the 
> drivers
> during the next few days and will send v3 with either the comment being added 
> or
> 'always enabled' clocks being dropped from the patch.

Great, thanks for looking into it. Critical clocks are an easy-to-abuse
feature and we should really be using the clk.h api as much as possible
in place of the critical clocks mechanism.

Best regards,
Mike

Re: [PATCH v2 1/2] clk: tegra: Mark HCLK, SCLK, EMC, MC and PLL_P outputs as critical

[Michael Turquette]

Quoting Dmitry Osipenko (2017-12-19 12:20:56)
> On 19.12.2017 22:56, Michael Turquette wrote:
> > Quoting Dmitry Osipenko (2017-12-18 19:59:06)
> >> Machine dies if HCLK, SCLK or EMC is disabled, hence mark these clocks
> >> as critical. Currently some of drivers do not manage clocks properly,
> >> expecting clocks to be 'always enabled', these clocks are MC and PLL_P
> >> outputs. Let's mark MC or PLL_P outputs as critical for now and revert
> >> this change once drivers would be corrected.
> > 
> > Are the drivers that do not manage their clocks correctly merged
> > upstream? If so can we fix those drivers instead of marking clocks as
> > critical?
> 
> All the drivers are in upstream for a quite long time already. We should be 
> able
> to correct them, but I haven't tried yet.
> 
> > If not can we annotate the flags below with a comment stating to remove
> > the critical clock flag once the consumer driver gets a clue?
> I'll try to take a look at how much effort it would take to correct the 
> drivers
> during the next few days and will send v3 with either the comment being added 
> or
> 'always enabled' clocks being dropped from the patch.

Great, thanks for looking into it. Critical clocks are an easy-to-abuse
feature and we should really be using the clk.h api as much as possible
in place of the critical clocks mechanism.

Best regards,
Mike

Re: [PATCH v2 1/2] clk: tegra: Mark HCLK, SCLK, EMC, MC and PLL_P outputs as critical

[Michael Turquette]

Quoting Dmitry Osipenko (2017-12-18 19:59:06)
> Machine dies if HCLK, SCLK or EMC is disabled, hence mark these clocks
> as critical. Currently some of drivers do not manage clocks properly,
> expecting clocks to be 'always enabled', these clocks are MC and PLL_P
> outputs. Let's mark MC or PLL_P outputs as critical for now and revert
> this change once drivers would be corrected.

Are the drivers that do not manage their clocks correctly merged
upstream? If so can we fix those drivers instead of marking clocks as
critical?

If not can we annotate the flags below with a comment stating to remove
the critical clock flag once the consumer driver gets a clue?

Regards,
Mike

> 
> Signed-off-by: Dmitry Osipenko 
> Acked-By:  Peter De Schrijver 
> ---
> 
> Change log:
> v2: Fixed accidentally missed marking EMC as critical on Tegra30 and
> Tegra124. Switched to a use of common EMC gate definition on Tegra20
> and Tegra30.
> 
>  drivers/clk/tegra/clk-divider.c  |  3 ++-
>  drivers/clk/tegra/clk-emc.c  |  2 +-
>  drivers/clk/tegra/clk-tegra-periph.c | 27 ++--
>  drivers/clk/tegra/clk-tegra-super-gen4.c |  8 ---
>  drivers/clk/tegra/clk-tegra114.c |  5 ++---
>  drivers/clk/tegra/clk-tegra124.c | 10 -
>  drivers/clk/tegra/clk-tegra20.c  | 36 
> +++-
>  drivers/clk/tegra/clk-tegra210.c |  6 +++---
>  drivers/clk/tegra/clk-tegra30.c  | 17 ++-
>  drivers/clk/tegra/clk.h  |  2 +-
>  10 files changed, 63 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/clk/tegra/clk-divider.c b/drivers/clk/tegra/clk-divider.c
> index 16e0aee14773..ffae26a7c823 100644
> --- a/drivers/clk/tegra/clk-divider.c
> +++ b/drivers/clk/tegra/clk-divider.c
> @@ -194,6 +194,7 @@ static const struct clk_div_table mc_div_table[] = {
>  struct clk *tegra_clk_register_mc(const char *name, const char *parent_name,
>   void __iomem *reg, spinlock_t *lock)
>  {
> -   return clk_register_divider_table(NULL, name, parent_name, 0, reg,
> +   return clk_register_divider_table(NULL, name, parent_name,
> + CLK_IS_CRITICAL, reg,
>   16, 1, 0, mc_div_table, lock);
>  }
> diff --git a/drivers/clk/tegra/clk-emc.c b/drivers/clk/tegra/clk-emc.c
> index 11a5066e5c27..5234acd30e89 100644
> --- a/drivers/clk/tegra/clk-emc.c
> +++ b/drivers/clk/tegra/clk-emc.c
> @@ -515,7 +515,7 @@ struct clk *tegra_clk_register_emc(void __iomem *base, 
> struct device_node *np,
>  
> init.name = "emc";
> init.ops = _clk_emc_ops;
> -   init.flags = 0;
> +   init.flags = CLK_IS_CRITICAL;
> init.parent_names = emc_parent_clk_names;
> init.num_parents = ARRAY_SIZE(emc_parent_clk_names);
>  
> diff --git a/drivers/clk/tegra/clk-tegra-periph.c 
> b/drivers/clk/tegra/clk-tegra-periph.c
> index c02711927d79..97bc7b43f40a 100644
> --- a/drivers/clk/tegra/clk-tegra-periph.c
> +++ b/drivers/clk/tegra/clk-tegra-periph.c
> @@ -830,7 +830,7 @@ static struct tegra_periph_init_data gate_clks[] = {
> GATE("xusb_host", "xusb_host_src", 89, 0, tegra_clk_xusb_host, 0),
> GATE("xusb_ss", "xusb_ss_src", 156, 0, tegra_clk_xusb_ss, 0),
> GATE("xusb_dev", "xusb_dev_src", 95, 0, tegra_clk_xusb_dev, 0),
> -   GATE("emc", "emc_mux", 57, 0, tegra_clk_emc, CLK_IGNORE_UNUSED),
> +   GATE("emc", "emc_mux", 57, 0, tegra_clk_emc, CLK_IS_CRITICAL),
> GATE("sata_cold", "clk_m", 129, TEGRA_PERIPH_ON_APB, 
> tegra_clk_sata_cold, 0),
> GATE("ispa", "isp", 23, 0, tegra_clk_ispa, 0),
> GATE("ispb", "isp", 3, 0, tegra_clk_ispb, 0),
> @@ -971,7 +971,8 @@ static void __init div_clk_init(void __iomem *clk_base,
>  
>  static void __init init_pllp(void __iomem *clk_base, void __iomem *pmc_base,
> struct tegra_clk *tegra_clks,
> -   struct tegra_clk_pll_params *pll_params)
> +   struct tegra_clk_pll_params *pll_params,
> +   bool tegra30)
>  {
> struct clk *clk;
> struct clk **dt_clk;
> @@ -987,6 +988,7 @@ static void __init init_pllp(void __iomem *clk_base, void 
> __iomem *pmc_base,
> }
>  
> for (i = 0; i < ARRAY_SIZE(pllp_out_clks); i++) {
> +   unsigned long flags = CLK_SET_RATE_PARENT;
> struct pll_out_data *data;
>  
> data = pllp_out_clks + i;
> @@ -995,14 +997,27 @@ static void __init init_pllp(void __iomem *clk_base, 
> void __iomem *pmc_base,
> if (!dt_clk)
> continue;
>  
> +   /*
> +* On all Tegra generations pll_p_out3 is used as an auxiliary
> +* clock source by multiple peripherals.
> +*/
> +

Re: [PATCH v2 1/2] clk: tegra: Mark HCLK, SCLK, EMC, MC and PLL_P outputs as critical

[Michael Turquette]

Quoting Dmitry Osipenko (2017-12-18 19:59:06)
> Machine dies if HCLK, SCLK or EMC is disabled, hence mark these clocks
> as critical. Currently some of drivers do not manage clocks properly,
> expecting clocks to be 'always enabled', these clocks are MC and PLL_P
> outputs. Let's mark MC or PLL_P outputs as critical for now and revert
> this change once drivers would be corrected.

Are the drivers that do not manage their clocks correctly merged
upstream? If so can we fix those drivers instead of marking clocks as
critical?

If not can we annotate the flags below with a comment stating to remove
the critical clock flag once the consumer driver gets a clue?

Regards,
Mike

> 
> Signed-off-by: Dmitry Osipenko 
> Acked-By:  Peter De Schrijver 
> ---
> 
> Change log:
> v2: Fixed accidentally missed marking EMC as critical on Tegra30 and
> Tegra124. Switched to a use of common EMC gate definition on Tegra20
> and Tegra30.
> 
>  drivers/clk/tegra/clk-divider.c  |  3 ++-
>  drivers/clk/tegra/clk-emc.c  |  2 +-
>  drivers/clk/tegra/clk-tegra-periph.c | 27 ++--
>  drivers/clk/tegra/clk-tegra-super-gen4.c |  8 ---
>  drivers/clk/tegra/clk-tegra114.c |  5 ++---
>  drivers/clk/tegra/clk-tegra124.c | 10 -
>  drivers/clk/tegra/clk-tegra20.c  | 36 
> +++-
>  drivers/clk/tegra/clk-tegra210.c |  6 +++---
>  drivers/clk/tegra/clk-tegra30.c  | 17 ++-
>  drivers/clk/tegra/clk.h  |  2 +-
>  10 files changed, 63 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/clk/tegra/clk-divider.c b/drivers/clk/tegra/clk-divider.c
> index 16e0aee14773..ffae26a7c823 100644
> --- a/drivers/clk/tegra/clk-divider.c
> +++ b/drivers/clk/tegra/clk-divider.c
> @@ -194,6 +194,7 @@ static const struct clk_div_table mc_div_table[] = {
>  struct clk *tegra_clk_register_mc(const char *name, const char *parent_name,
>   void __iomem *reg, spinlock_t *lock)
>  {
> -   return clk_register_divider_table(NULL, name, parent_name, 0, reg,
> +   return clk_register_divider_table(NULL, name, parent_name,
> + CLK_IS_CRITICAL, reg,
>   16, 1, 0, mc_div_table, lock);
>  }
> diff --git a/drivers/clk/tegra/clk-emc.c b/drivers/clk/tegra/clk-emc.c
> index 11a5066e5c27..5234acd30e89 100644
> --- a/drivers/clk/tegra/clk-emc.c
> +++ b/drivers/clk/tegra/clk-emc.c
> @@ -515,7 +515,7 @@ struct clk *tegra_clk_register_emc(void __iomem *base, 
> struct device_node *np,
>  
> init.name = "emc";
> init.ops = _clk_emc_ops;
> -   init.flags = 0;
> +   init.flags = CLK_IS_CRITICAL;
> init.parent_names = emc_parent_clk_names;
> init.num_parents = ARRAY_SIZE(emc_parent_clk_names);
>  
> diff --git a/drivers/clk/tegra/clk-tegra-periph.c 
> b/drivers/clk/tegra/clk-tegra-periph.c
> index c02711927d79..97bc7b43f40a 100644
> --- a/drivers/clk/tegra/clk-tegra-periph.c
> +++ b/drivers/clk/tegra/clk-tegra-periph.c
> @@ -830,7 +830,7 @@ static struct tegra_periph_init_data gate_clks[] = {
> GATE("xusb_host", "xusb_host_src", 89, 0, tegra_clk_xusb_host, 0),
> GATE("xusb_ss", "xusb_ss_src", 156, 0, tegra_clk_xusb_ss, 0),
> GATE("xusb_dev", "xusb_dev_src", 95, 0, tegra_clk_xusb_dev, 0),
> -   GATE("emc", "emc_mux", 57, 0, tegra_clk_emc, CLK_IGNORE_UNUSED),
> +   GATE("emc", "emc_mux", 57, 0, tegra_clk_emc, CLK_IS_CRITICAL),
> GATE("sata_cold", "clk_m", 129, TEGRA_PERIPH_ON_APB, 
> tegra_clk_sata_cold, 0),
> GATE("ispa", "isp", 23, 0, tegra_clk_ispa, 0),
> GATE("ispb", "isp", 3, 0, tegra_clk_ispb, 0),
> @@ -971,7 +971,8 @@ static void __init div_clk_init(void __iomem *clk_base,
>  
>  static void __init init_pllp(void __iomem *clk_base, void __iomem *pmc_base,
> struct tegra_clk *tegra_clks,
> -   struct tegra_clk_pll_params *pll_params)
> +   struct tegra_clk_pll_params *pll_params,
> +   bool tegra30)
>  {
> struct clk *clk;
> struct clk **dt_clk;
> @@ -987,6 +988,7 @@ static void __init init_pllp(void __iomem *clk_base, void 
> __iomem *pmc_base,
> }
>  
> for (i = 0; i < ARRAY_SIZE(pllp_out_clks); i++) {
> +   unsigned long flags = CLK_SET_RATE_PARENT;
> struct pll_out_data *data;
>  
> data = pllp_out_clks + i;
> @@ -995,14 +997,27 @@ static void __init init_pllp(void __iomem *clk_base, 
> void __iomem *pmc_base,
> if (!dt_clk)
> continue;
>  
> +   /*
> +* On all Tegra generations pll_p_out3 is used as an auxiliary
> +* clock source by multiple peripherals.
> +*/
> +   if (strcmp(data->pll_out_name, 

Re: [PATCH v2] clk: check ops pointer on clock register

[Michael Turquette]

Quoting Jerome Brunet (2017-12-19 00:33:29)
> Nothing really prevents a provider from (trying to) register a clock
> without providing the clock ops structure.
> 
> We do check the individual fields before using them, but not the
> structure pointer itself. This may have the usual nasty consequences when
> the pointer is dereferenced, most likely when checking one the field
> during the initialization.
> 
> This is fixed by returning an error on clock register if the ops pointer
> is NULL.
> 
> Signed-off-by: Jerome Brunet 

Applied to clk-check-ops-ptr

Regards,
Mike

> ---
> Changes since v1:
>  * Add WARN_ON so the error cannot be silently ignored
>  * Remove fixes tag
> 
>  drivers/clk/clk.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 8a1860a36c77..211f97e8dc65 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2683,7 +2683,13 @@ struct clk *clk_register(struct device *dev, struct 
> clk_hw *hw)
> ret = -ENOMEM;
> goto fail_name;
> }
> +
> +   if (WARN_ON(!hw->init->ops)) {
> +   ret = -EINVAL;
> +   goto fail_ops;
> +   }
> core->ops = hw->init->ops;
> +
> if (dev && pm_runtime_enabled(dev))
> core->dev = dev;
> if (dev && dev->driver)
> @@ -2745,6 +2751,7 @@ struct clk *clk_register(struct device *dev, struct 
> clk_hw *hw)
> kfree_const(core->parent_names[i]);
> kfree(core->parent_names);
>  fail_parent_names:
> +fail_ops:
> kfree_const(core->name);
>  fail_name:
> kfree(core);
> -- 
> 2.14.3
> 

Re: [PATCH v2] clk: check ops pointer on clock register

[Michael Turquette]

Quoting Jerome Brunet (2017-12-19 00:33:29)
> Nothing really prevents a provider from (trying to) register a clock
> without providing the clock ops structure.
> 
> We do check the individual fields before using them, but not the
> structure pointer itself. This may have the usual nasty consequences when
> the pointer is dereferenced, most likely when checking one the field
> during the initialization.
> 
> This is fixed by returning an error on clock register if the ops pointer
> is NULL.
> 
> Signed-off-by: Jerome Brunet 

Applied to clk-check-ops-ptr

Regards,
Mike

> ---
> Changes since v1:
>  * Add WARN_ON so the error cannot be silently ignored
>  * Remove fixes tag
> 
>  drivers/clk/clk.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 8a1860a36c77..211f97e8dc65 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2683,7 +2683,13 @@ struct clk *clk_register(struct device *dev, struct 
> clk_hw *hw)
> ret = -ENOMEM;
> goto fail_name;
> }
> +
> +   if (WARN_ON(!hw->init->ops)) {
> +   ret = -EINVAL;
> +   goto fail_ops;
> +   }
> core->ops = hw->init->ops;
> +
> if (dev && pm_runtime_enabled(dev))
> core->dev = dev;
> if (dev && dev->driver)
> @@ -2745,6 +2751,7 @@ struct clk *clk_register(struct device *dev, struct 
> clk_hw *hw)
> kfree_const(core->parent_names[i]);
> kfree(core->parent_names);
>  fail_parent_names:
> +fail_ops:
> kfree_const(core->name);
>  fail_name:
> kfree(core);
> -- 
> 2.14.3
> 

Re: [PATCH] clk: check ops pointer on clock register

[Michael Turquette]

Hi Jerome & Stephen,

On Mon, Dec 18, 2017 at 12:06 PM, Jerome Brunet  wrote:
> On Mon, 2017-12-18 at 11:03 -0800, Stephen Boyd wrote:
>> On 12/18, Jerome Brunet wrote:
>> > Nothing really prevents a provider from (trying to) register a clock
>> > without providing the clock ops structure.
>> >
>> > We do check the individual fields before using them, but not the
>> > structure pointer itself. This may have the usual nasty consequences when
>> > the pointer is dereferenced, mostly likely when checking one the field
>> > during the initialization.
>>
>> Yes, that nasty consequence should be a kernel oops,
>
> Precisely
>
>> and the
>> developer should notice that before submitting the driver for
>> inclusion.
>
> Agreed. But people may make mistakes, which is why (at least partly) we
> do checks, isn't it ?

Agreed the developers should test before submitting, but procedurally
generated clocks (e.g. registering clocks in a loop using a
predictable register map, etc) could lead to a situation where a
developer doesn't test every possible iteration.

Hypothetical, but easy easy easy to fix with Jerome's patch.

>
>> I don't think we really care to return an error here
>> if this happens.
>>
>
> I don't understand why we would let a oops happen when can catch the error
> properly ?
>

Agreed with Jerome on this one.

Let's flip it on its head: any downside to this patch? If not I can merge.

Regards,
Mike

Re: [PATCH] clk: check ops pointer on clock register

[Michael Turquette]

Hi Jerome & Stephen,

On Mon, Dec 18, 2017 at 12:06 PM, Jerome Brunet  wrote:
> On Mon, 2017-12-18 at 11:03 -0800, Stephen Boyd wrote:
>> On 12/18, Jerome Brunet wrote:
>> > Nothing really prevents a provider from (trying to) register a clock
>> > without providing the clock ops structure.
>> >
>> > We do check the individual fields before using them, but not the
>> > structure pointer itself. This may have the usual nasty consequences when
>> > the pointer is dereferenced, mostly likely when checking one the field
>> > during the initialization.
>>
>> Yes, that nasty consequence should be a kernel oops,
>
> Precisely
>
>> and the
>> developer should notice that before submitting the driver for
>> inclusion.
>
> Agreed. But people may make mistakes, which is why (at least partly) we
> do checks, isn't it ?

Agreed the developers should test before submitting, but procedurally
generated clocks (e.g. registering clocks in a loop using a
predictable register map, etc) could lead to a situation where a
developer doesn't test every possible iteration.

Hypothetical, but easy easy easy to fix with Jerome's patch.

>
>> I don't think we really care to return an error here
>> if this happens.
>>
>
> I don't understand why we would let a oops happen when can catch the error
> properly ?
>

Agreed with Jerome on this one.

Let's flip it on its head: any downside to this patch? If not I can merge.

Regards,
Mike

Re: [PATCH 0/2] Add support for Hi6220 coresight

[Michael Turquette]

Quoting Wei Xu (2017-10-13 10:57:02)
> Hi Leo,
> 
> On 2017/10/7 13:18, Leo Yan wrote:
> > Hi Stephen, Wei,
> > 
> > On Thu, Aug 31, 2017 at 06:33:01PM -0700, Stephen Boyd wrote:
> >> On 09/01, Leo Yan wrote:
> >>> This patch series adds support for coresight on Hi6220; the first patch
> >>> is to fix coresight PLL so can avoid system hang after we enable
> >>> coresight, the second patch is to add DT binding according to coresight
> >>> topology.
> >>>
> >>> The patch has been tested on Hikey; By using OpenCSD snapshot mode, it
> >>> can successfully decode ETF and ETB trace data.
> >>>
> >>
> >> I can take the first one and second one goes through arm-soc?
> > 
> > Could you pick these two patches for Hi6220 coresight enabling for
> > this merge window? Or need me resend these two patches?
> 
> Applied patch 2 into hisilicon dt tree with slight fix.
> Thanks!

Cool. Patch #1 applied to clk tree.

Regards,
Mike

> 
> BR,
> Wei
> 
> > 
> > Thanks,
> > Leo Yan
> > 
> > .
> > 
> 

Re: [PATCH 0/2] Add support for Hi6220 coresight

[Michael Turquette]

Quoting Wei Xu (2017-10-13 10:57:02)
> Hi Leo,
> 
> On 2017/10/7 13:18, Leo Yan wrote:
> > Hi Stephen, Wei,
> > 
> > On Thu, Aug 31, 2017 at 06:33:01PM -0700, Stephen Boyd wrote:
> >> On 09/01, Leo Yan wrote:
> >>> This patch series adds support for coresight on Hi6220; the first patch
> >>> is to fix coresight PLL so can avoid system hang after we enable
> >>> coresight, the second patch is to add DT binding according to coresight
> >>> topology.
> >>>
> >>> The patch has been tested on Hikey; By using OpenCSD snapshot mode, it
> >>> can successfully decode ETF and ETB trace data.
> >>>
> >>
> >> I can take the first one and second one goes through arm-soc?
> > 
> > Could you pick these two patches for Hi6220 coresight enabling for
> > this merge window? Or need me resend these two patches?
> 
> Applied patch 2 into hisilicon dt tree with slight fix.
> Thanks!

Cool. Patch #1 applied to clk tree.

Regards,
Mike

> 
> BR,
> Wei
> 
> > 
> > Thanks,
> > Leo Yan
> > 
> > .
> > 
> 

Re: [PATCH v4 09/10] clk: add clk_rate_exclusive api

[Michael Turquette]

Hi Jérôme,

On Tue, Oct 31, 2017 at 5:29 PM, Jerome Brunet <jbru...@baylibre.com> wrote:
> On Thu, 2017-10-26 at 07:26 +0200, Michael Turquette wrote:
>> Hi Jerome,
>>
>> Quoting Jerome Brunet (2017-09-24 22:00:29)
>> > @@ -1778,6 +1867,50 @@ int clk_set_rate(struct clk *clk, unsigned long 
>> > rate)
>> >  EXPORT_SYMBOL_GPL(clk_set_rate);
>> >
>> >  /**
>> > + * clk_set_rate_exclusive - specify a new rate get exclusive control
>> > + * @clk: the clk whose rate is being changed
>> > + * @rate: the new rate for clk
>> > + *
>> > + * This is a combination of clk_set_rate() and clk_rate_exclusive_get()
>> > + * within a critical section
>> > + *
>> > + * This can be used initially to ensure that at least 1 consumer is
>> > + * statisfied when several consumers are competing for exclusivity over 
>> > the
>> > + * same clock provider.
>>
>> Please add the following here:
>>
>>   Calls to clk_rate_exclusive_get() should be balanced with calls to
>>   clk_rate_exclusive_put().
>
> Oh indeed !
> I can do a resend with it or, if you prefer, you may directly amend the patch.
> As you prefer

Previously we agreed that these should go onto the next -rc1 so that
they have more soak time. Being a very lazy person, may I ask you to
rebase the patches on -rc1 when it comes out (with this small change)
and then I'll pull them? You can send a PR directly if you like.

Best regards,
Mike

>
> Thanks
>
>>
>> Otherwise looks good to me.
>>
>> Best regards,
>> Mike
>

Re: [PATCH v4 09/10] clk: add clk_rate_exclusive api

[Michael Turquette]

Hi Jérôme,

On Tue, Oct 31, 2017 at 5:29 PM, Jerome Brunet  wrote:
> On Thu, 2017-10-26 at 07:26 +0200, Michael Turquette wrote:
>> Hi Jerome,
>>
>> Quoting Jerome Brunet (2017-09-24 22:00:29)
>> > @@ -1778,6 +1867,50 @@ int clk_set_rate(struct clk *clk, unsigned long 
>> > rate)
>> >  EXPORT_SYMBOL_GPL(clk_set_rate);
>> >
>> >  /**
>> > + * clk_set_rate_exclusive - specify a new rate get exclusive control
>> > + * @clk: the clk whose rate is being changed
>> > + * @rate: the new rate for clk
>> > + *
>> > + * This is a combination of clk_set_rate() and clk_rate_exclusive_get()
>> > + * within a critical section
>> > + *
>> > + * This can be used initially to ensure that at least 1 consumer is
>> > + * statisfied when several consumers are competing for exclusivity over 
>> > the
>> > + * same clock provider.
>>
>> Please add the following here:
>>
>>   Calls to clk_rate_exclusive_get() should be balanced with calls to
>>   clk_rate_exclusive_put().
>
> Oh indeed !
> I can do a resend with it or, if you prefer, you may directly amend the patch.
> As you prefer

Previously we agreed that these should go onto the next -rc1 so that
they have more soak time. Being a very lazy person, may I ask you to
rebase the patches on -rc1 when it comes out (with this small change)
and then I'll pull them? You can send a PR directly if you like.

Best regards,
Mike

>
> Thanks
>
>>
>> Otherwise looks good to me.
>>
>> Best regards,
>> Mike
>

Re: [PATCH v4 09/10] clk: add clk_rate_exclusive api

[Michael Turquette]

Hi Jerome,

Quoting Jerome Brunet (2017-09-24 22:00:29)
> @@ -1778,6 +1867,50 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
>  EXPORT_SYMBOL_GPL(clk_set_rate);
>  
>  /**
> + * clk_set_rate_exclusive - specify a new rate get exclusive control
> + * @clk: the clk whose rate is being changed
> + * @rate: the new rate for clk
> + *
> + * This is a combination of clk_set_rate() and clk_rate_exclusive_get()
> + * within a critical section
> + *
> + * This can be used initially to ensure that at least 1 consumer is
> + * statisfied when several consumers are competing for exclusivity over the
> + * same clock provider.

Please add the following here:

  Calls to clk_rate_exclusive_get() should be balanced with calls to
  clk_rate_exclusive_put().

Otherwise looks good to me.

Best regards,
Mike

Re: [PATCH v4 09/10] clk: add clk_rate_exclusive api

[Michael Turquette]

Hi Jerome,

Quoting Jerome Brunet (2017-09-24 22:00:29)
> @@ -1778,6 +1867,50 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
>  EXPORT_SYMBOL_GPL(clk_set_rate);
>  
>  /**
> + * clk_set_rate_exclusive - specify a new rate get exclusive control
> + * @clk: the clk whose rate is being changed
> + * @rate: the new rate for clk
> + *
> + * This is a combination of clk_set_rate() and clk_rate_exclusive_get()
> + * within a critical section
> + *
> + * This can be used initially to ensure that at least 1 consumer is
> + * statisfied when several consumers are competing for exclusivity over the
> + * same clock provider.

Please add the following here:

  Calls to clk_rate_exclusive_get() should be balanced with calls to
  clk_rate_exclusive_put().

Otherwise looks good to me.

Best regards,
Mike

Re: [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API

[Michael Turquette]

Hi all,

On Fri, Oct 20, 2017 at 3:34 PM, Bjorn Andersson
 wrote:
> On Fri 20 Oct 07:43 PDT 2017, Georgi Djakov wrote:
>
>> Hi,
>>
>> On 09/08/2017 08:18 PM, Georgi Djakov wrote:
>> > This patch introduce a new API to get requirements and configure the
>> > interconnect buses across the entire chipset to fit with the current 
>> > demand.
>> >
>> > The API is using a consumer/provider-based model, where the providers are
>> > the interconnect buses and the consumers could be various drivers.
>> > The consumers request interconnect resources (path) between endpoints and
>> > set the desired constraints on this data flow path. The providers receive
>> > requests from consumers and aggregate these requests for all master-slave
>> > pairs on that path. Then the providers configure each participating in the
>> > topology node according to the requested data flow path, physical links and
>> > constraints. The topology could be complicated and multi-tiered and is SoC
>> > specific.
>> >
>> > Signed-off-by: Georgi Djakov 
>> > ---
>> >  Documentation/interconnect/interconnect.rst |  93 +++
>> >  drivers/Kconfig |   2 +
>> >  drivers/Makefile|   1 +
>> >  drivers/interconnect/Kconfig|  10 +
>> >  drivers/interconnect/Makefile   |   1 +
>> >  drivers/interconnect/interconnect.c | 382 
>> > 
>> >  include/linux/interconnect-consumer.h   |  73 ++
>> >  include/linux/interconnect-provider.h   | 119 +
>> >  8 files changed, 681 insertions(+)
>> >  create mode 100644 Documentation/interconnect/interconnect.rst
>> >  create mode 100644 drivers/interconnect/Kconfig
>> >  create mode 100644 drivers/interconnect/Makefile
>> >  create mode 100644 drivers/interconnect/interconnect.c
>> >  create mode 100644 include/linux/interconnect-consumer.h
>> >  create mode 100644 include/linux/interconnect-provider.h
>>
>> Any comments on this patch?
>>
>
> Sorry, I still haven't found the time to do a proper review of this yet.

Same.

>
>> I am planning to change the prefix that is used for naming for example
>> the functions from "interconnect_" to something shorter like icbus_.
>>
>
> This isn't implementing a bus; if you feel that just ic_ is too short I
> would suggest naming things inter_. (But keep the full name in the file
> names)

Not trying to bikeshed too much, but how about icc_ for "interconnect
controller"? No idea if that is a hash collision with other in-kernel
apis.

Just "ic_" looks to me like "integrated circuit".

Regards,
Mike

>
> Regards,
> Bjorn

Re: [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API

[Michael Turquette]

Hi all,

On Fri, Oct 20, 2017 at 3:34 PM, Bjorn Andersson
 wrote:
> On Fri 20 Oct 07:43 PDT 2017, Georgi Djakov wrote:
>
>> Hi,
>>
>> On 09/08/2017 08:18 PM, Georgi Djakov wrote:
>> > This patch introduce a new API to get requirements and configure the
>> > interconnect buses across the entire chipset to fit with the current 
>> > demand.
>> >
>> > The API is using a consumer/provider-based model, where the providers are
>> > the interconnect buses and the consumers could be various drivers.
>> > The consumers request interconnect resources (path) between endpoints and
>> > set the desired constraints on this data flow path. The providers receive
>> > requests from consumers and aggregate these requests for all master-slave
>> > pairs on that path. Then the providers configure each participating in the
>> > topology node according to the requested data flow path, physical links and
>> > constraints. The topology could be complicated and multi-tiered and is SoC
>> > specific.
>> >
>> > Signed-off-by: Georgi Djakov 
>> > ---
>> >  Documentation/interconnect/interconnect.rst |  93 +++
>> >  drivers/Kconfig |   2 +
>> >  drivers/Makefile|   1 +
>> >  drivers/interconnect/Kconfig|  10 +
>> >  drivers/interconnect/Makefile   |   1 +
>> >  drivers/interconnect/interconnect.c | 382 
>> > 
>> >  include/linux/interconnect-consumer.h   |  73 ++
>> >  include/linux/interconnect-provider.h   | 119 +
>> >  8 files changed, 681 insertions(+)
>> >  create mode 100644 Documentation/interconnect/interconnect.rst
>> >  create mode 100644 drivers/interconnect/Kconfig
>> >  create mode 100644 drivers/interconnect/Makefile
>> >  create mode 100644 drivers/interconnect/interconnect.c
>> >  create mode 100644 include/linux/interconnect-consumer.h
>> >  create mode 100644 include/linux/interconnect-provider.h
>>
>> Any comments on this patch?
>>
>
> Sorry, I still haven't found the time to do a proper review of this yet.

Same.

>
>> I am planning to change the prefix that is used for naming for example
>> the functions from "interconnect_" to something shorter like icbus_.
>>
>
> This isn't implementing a bus; if you feel that just ic_ is too short I
> would suggest naming things inter_. (But keep the full name in the file
> names)

Not trying to bikeshed too much, but how about icc_ for "interconnect
controller"? No idea if that is a hash collision with other in-kernel
apis.

Just "ic_" looks to me like "integrated circuit".

Regards,
Mike

>
> Regards,
> Bjorn

Re: [PATCH v2 0/7] Improve ap806 clk support on Marvell Armada 7K/8K

[Michael Turquette]

Hi Gregory,

Quoting Gregory CLEMENT (2017-05-31 23:07:21)
> Hi,
> 
> This series modifies the device tree binding of the clock of the AP806
> part that we find in the Marvell Armada 7K/8K SoCs.
> 
> As for the previsous series the only change in this second version is
> about the binding documentation: all the documentation related changes
> are now move in their own patches. It allows to provide a stable -dt
> branch for theses changes. I also added the acked-by from Rob Herring.
> 
> Here again the last two patches modifying the device tree _must_ be
> merged through the mvebu tree to avoid future conflict.

The approach (and the patches) look good to me. I took the DT binding
description changes (patches 2 & 4) into clk-ap806-dt stable branch:

https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/log/?h=clk-ap806-dt

Anyone can merge the above branch if they need it as a dep.

The driver changes (patches 1, 3 & 5) are merged on into clk-ap806,
which is based on top of clk-ap806-dt:

https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/log/?h=clk-ap806

Everything has been merged into clk-next. I did not touch the .dts files
at all.

Regards,
Mike

> 
> For the record:
> As for the CP110, we want to be able to ease the integration of new
> clocks without breaking the backward compatibility. It is done in
> patch 3.
> 
> We also want to ease the integration of the pinctrl node in the device
> tree. It is the purpose of the patch 5.
> 
> In this series (as in the previous one for CP110), even if there is
> some change in the device tree binding we paid attention to the
> backward compatibility, and the driver can still work with the old
> device tree.
> 
> Thanks,
> 
> Gregory
> 
> Gregory CLEMENT (7):
>   clk: mvebu: ap806: cosmetic improvement
>   dt-bindings: ap806: do not depend anymore of the *-clock-output-names
>   clk: mvebu: ap806: do not depend anymore of the *-clock-output-names
>   dt-bindings: ap806: introduce a new binding
>   clk: mvebu: ap806: introduce a new binding
>   arm64: dts: marvell: remove clock-output-names on ap806
>   arm64: dts: marvell: use new binding for the system controller on ap806
> 
>  Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt |  
> 24 ++--
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi |  
> 23 +++
>  drivers/clk/mvebu/ap806-system-controller.c   | 
> 107 +++-
>  3 files changed, 97 insertions(+), 57 deletions(-)
> 
> base-commit: 4139fcd6c66df1c3d3fa0a0a7cf7f8a8c601a16c
> -- 
> git-series 0.9.1

Re: [PATCH v2 0/7] Improve ap806 clk support on Marvell Armada 7K/8K

[Michael Turquette]

Hi Gregory,

Quoting Gregory CLEMENT (2017-05-31 23:07:21)
> Hi,
> 
> This series modifies the device tree binding of the clock of the AP806
> part that we find in the Marvell Armada 7K/8K SoCs.
> 
> As for the previsous series the only change in this second version is
> about the binding documentation: all the documentation related changes
> are now move in their own patches. It allows to provide a stable -dt
> branch for theses changes. I also added the acked-by from Rob Herring.
> 
> Here again the last two patches modifying the device tree _must_ be
> merged through the mvebu tree to avoid future conflict.

The approach (and the patches) look good to me. I took the DT binding
description changes (patches 2 & 4) into clk-ap806-dt stable branch:

https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/log/?h=clk-ap806-dt

Anyone can merge the above branch if they need it as a dep.

The driver changes (patches 1, 3 & 5) are merged on into clk-ap806,
which is based on top of clk-ap806-dt:

https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/log/?h=clk-ap806

Everything has been merged into clk-next. I did not touch the .dts files
at all.

Regards,
Mike

> 
> For the record:
> As for the CP110, we want to be able to ease the integration of new
> clocks without breaking the backward compatibility. It is done in
> patch 3.
> 
> We also want to ease the integration of the pinctrl node in the device
> tree. It is the purpose of the patch 5.
> 
> In this series (as in the previous one for CP110), even if there is
> some change in the device tree binding we paid attention to the
> backward compatibility, and the driver can still work with the old
> device tree.
> 
> Thanks,
> 
> Gregory
> 
> Gregory CLEMENT (7):
>   clk: mvebu: ap806: cosmetic improvement
>   dt-bindings: ap806: do not depend anymore of the *-clock-output-names
>   clk: mvebu: ap806: do not depend anymore of the *-clock-output-names
>   dt-bindings: ap806: introduce a new binding
>   clk: mvebu: ap806: introduce a new binding
>   arm64: dts: marvell: remove clock-output-names on ap806
>   arm64: dts: marvell: use new binding for the system controller on ap806
> 
>  Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt |  
> 24 ++--
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi |  
> 23 +++
>  drivers/clk/mvebu/ap806-system-controller.c   | 
> 107 +++-
>  3 files changed, 97 insertions(+), 57 deletions(-)
> 
> base-commit: 4139fcd6c66df1c3d3fa0a0a7cf7f8a8c601a16c
> -- 
> git-series 0.9.1

Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K

[Michael Turquette]

Quoting Rob Herring (2017-05-31 07:23:58)
> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
> > On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
> >  wrote:
> > >  On mar., mai 23 2017, Linus Walleij  wrote:
> > 
> > >> Please rebase and resend the rest of the patches.
> > >
> > > Actually I was wrong with my assumption that there was no dependency.
> > > For the binding documentation there is dependecy accross the series I
> > > sent.
> > >
> > > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> > > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> > > CP110 pin controllers" [3] from the series "Add support for the pin
> > > controllers on the Marvell Armada 7K/8K".
> > >
> > > As you are maintainer of both gpio and pinctrl subsystem it will be easy
> > > to resolv.
> > 
> > Please send all patches in one big series in that case, so I can apply
> > them all to a branch and merge that branch into both trees.
> > 
> > > But these last patches depend also on "clk: mvebu: ap806: introduce a
> > > new binding" [3] in the clock series "Improve ap806 clk support on
> > > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> > > binding" [4] in the clock series "Improve cp110 clk support on Marvell
> > > Armada 7K/8K".
> > 
> > That sounds messy.
> > 
> > > So for these particular patches, either I rebase them on the v4.12-rc2
> > > and there will be a small merge conflict during the merge window for
> > > v4.13, or we can ask a stable branch with only these few patches (I am
> > > adding the clock maintainer to this email).
> > >
> > > If we chose this last option I can split the clock patches to have patch
> > > modifying only the binding documentation.
> > 
> > I think you can make a patch just modifying the binding documentation
> > and then apply that patch to *both* trees, just make sure the patch
> > is *final* and not applied in different versions in clk and pinctrl.
> 
> I thought we try to avoid doing that.
> 
> > I think cross-tree branches for documentation clashes is too much
> > bureaucracy.
> 
> I can just take all the doc patches separately. Or you can take the 
> clock one too.

Stephen and I have started making a -dt branch for each new clk driver
which. This stable branch has only the dt bindings/headers in it (no
driver code).

I'll make such a branch for ap806 this week and everyone can merge that
in as a dep.

Regards,
Mike

> 
> > Make sure your clock patch is finalized and preferably also applied
> > to the clk tree then put it in the bottom of the patch set you send
> > to me as well and I will proceed like above.
> > 
> > Yours,
> > Linus Walleij

Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K

[Michael Turquette]

Quoting Rob Herring (2017-05-31 07:23:58)
> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
> > On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
> >  wrote:
> > >  On mar., mai 23 2017, Linus Walleij  wrote:
> > 
> > >> Please rebase and resend the rest of the patches.
> > >
> > > Actually I was wrong with my assumption that there was no dependency.
> > > For the binding documentation there is dependecy accross the series I
> > > sent.
> > >
> > > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> > > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> > > CP110 pin controllers" [3] from the series "Add support for the pin
> > > controllers on the Marvell Armada 7K/8K".
> > >
> > > As you are maintainer of both gpio and pinctrl subsystem it will be easy
> > > to resolv.
> > 
> > Please send all patches in one big series in that case, so I can apply
> > them all to a branch and merge that branch into both trees.
> > 
> > > But these last patches depend also on "clk: mvebu: ap806: introduce a
> > > new binding" [3] in the clock series "Improve ap806 clk support on
> > > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> > > binding" [4] in the clock series "Improve cp110 clk support on Marvell
> > > Armada 7K/8K".
> > 
> > That sounds messy.
> > 
> > > So for these particular patches, either I rebase them on the v4.12-rc2
> > > and there will be a small merge conflict during the merge window for
> > > v4.13, or we can ask a stable branch with only these few patches (I am
> > > adding the clock maintainer to this email).
> > >
> > > If we chose this last option I can split the clock patches to have patch
> > > modifying only the binding documentation.
> > 
> > I think you can make a patch just modifying the binding documentation
> > and then apply that patch to *both* trees, just make sure the patch
> > is *final* and not applied in different versions in clk and pinctrl.
> 
> I thought we try to avoid doing that.
> 
> > I think cross-tree branches for documentation clashes is too much
> > bureaucracy.
> 
> I can just take all the doc patches separately. Or you can take the 
> clock one too.

Stephen and I have started making a -dt branch for each new clk driver
which. This stable branch has only the dt bindings/headers in it (no
driver code).

I'll make such a branch for ap806 this week and everyone can merge that
in as a dep.

Regards,
Mike

> 
> > Make sure your clock patch is finalized and preferably also applied
> > to the clk tree then put it in the bottom of the patch set you send
> > to me as well and I will proceed like above.
> > 
> > Yours,
> > Linus Walleij

Re: [PATCH v4 03/11] clk: bcm: Add clocks for Stingray SOC

[Michael Turquette]

Hello Anup,

Quoting Anup Patel (2017-05-22 04:58:19)
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Are all of those headers really needed?

> +CLK_OF_DECLARE(sr_genpll3_clk, "brcm,sr-genpll3",
> +   sr_genpll3_clk_init);

Why use CLK_OF_DECLARE here? You've got a proper platform driver here.

Regards,
Mike

Re: [PATCH v4 03/11] clk: bcm: Add clocks for Stingray SOC

[Michael Turquette]

Hello Anup,

Quoting Anup Patel (2017-05-22 04:58:19)
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Are all of those headers really needed?

> +CLK_OF_DECLARE(sr_genpll3_clk, "brcm,sr-genpll3",
> +   sr_genpll3_clk_init);

Why use CLK_OF_DECLARE here? You've got a proper platform driver here.

Regards,
Mike

Re: [PATCH] MAINTAINERS: Add maintainers for the meson clock driver

[Michael Turquette]

Quoting Jerome Brunet (2017-03-31 12:14:17)
> Suggested-by: Michael Turquette <mturque...@baylibre.com>
> Cc: Kevin Hilman <khil...@baylibre.com>,
> Signed-off-by: Jerome Brunet <jbru...@baylibre.com>
> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
> ---
> 
> Hi Mike, Stephen,
> 
> If this is OK with you, this will be the first patch of our upcoming pull
> request.

Sounds goods to me.

Regards,
Mike

> 
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c265a5fe4848..8cb237925b06 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1069,6 +1069,16 @@ F:   drivers/pinctrl/meson/
>  F: drivers/mmc/host/meson*
>  N: meson
>  
> +ARM/Amlogic Meson SoC CLOCK FRAMEWORK
> +M: Neil Armstrong <narmstr...@baylibre.com>
> +M: Jerome Brunet <jbru...@baylibre.com>
> +L: linux-amlo...@lists.infradead.org
> +S: Maintained
> +F: drivers/clk/meson/
> +F: include/dt-bindings/clock/meson*
> +F: include/dt-bindings/clock/gxbb*
> +F: Documentation/devicetree/bindings/clock/amlogic*
> +
>  ARM/Annapurna Labs ALPINE ARCHITECTURE
>  M: Tsahee Zidenberg <tsa...@annapurnalabs.com>
>  M: Antoine Tenart <antoine.ten...@free-electrons.com>
> -- 
> 2.9.3
> 

Re: [PATCH] MAINTAINERS: Add maintainers for the meson clock driver

[Michael Turquette]

Quoting Jerome Brunet (2017-03-31 12:14:17)
> Suggested-by: Michael Turquette 
> Cc: Kevin Hilman ,
> Signed-off-by: Jerome Brunet 
> Signed-off-by: Neil Armstrong 
> ---
> 
> Hi Mike, Stephen,
> 
> If this is OK with you, this will be the first patch of our upcoming pull
> request.

Sounds goods to me.

Regards,
Mike

> 
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c265a5fe4848..8cb237925b06 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1069,6 +1069,16 @@ F:   drivers/pinctrl/meson/
>  F: drivers/mmc/host/meson*
>  N: meson
>  
> +ARM/Amlogic Meson SoC CLOCK FRAMEWORK
> +M: Neil Armstrong 
> +M: Jerome Brunet 
> +L: linux-amlo...@lists.infradead.org
> +S: Maintained
> +F: drivers/clk/meson/
> +F: include/dt-bindings/clock/meson*
> +F: include/dt-bindings/clock/gxbb*
> +F: Documentation/devicetree/bindings/clock/amlogic*
> +
>  ARM/Annapurna Labs ALPINE ARCHITECTURE
>  M: Tsahee Zidenberg 
>  M: Antoine Tenart 
> -- 
> 2.9.3
> 

Re: [PATCH v3 1/4] dt-bindings: clock: gxbb: expose UART clocks

[Michael Turquette]

Quoting Helmut Klein (2017-03-31 18:54:34)
> Expose the clock ids of the three none AO uarts to the dt-bindings
> 
> Signed-off-by: Helmut Klein <hgkr.kl...@gmail.com>

Acked-by: Michael Turquette <mturque...@baylibre.com>

> ---
>  drivers/clk/meson/gxbb.h  | 6 +++---
>  include/dt-bindings/clock/gxbb-clkc.h | 3 +++
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> index 8ee2022ce5d5..1edfaa5fe307 100644
> --- a/drivers/clk/meson/gxbb.h
> +++ b/drivers/clk/meson/gxbb.h
> @@ -194,7 +194,7 @@
>  /* #define CLKID_SAR_ADC */
>  #define CLKID_SMART_CARD 24
>  #define CLKID_RNG0   25
> -#define CLKID_UART0  26
> +/* CLKID_UART0 */
>  #define CLKID_SDHC   27
>  #define CLKID_STREAM 28
>  #define CLKID_ASYNC_FIFO 29
> @@ -216,7 +216,7 @@
>  #define CLKID_ADC45
>  #define CLKID_BLKMV  46
>  #define CLKID_AIU47
> -#define CLKID_UART1  48
> +/* CLKID_UART1 */
>  #define CLKID_G2D49
>  /* CLKID_USB0 */
>  /* CLKID_USB1 */
> @@ -236,7 +236,7 @@
>  /* CLKID_USB0_DDR_BRIDGE */
>  #define CLKID_MMC_PCLK   66
>  #define CLKID_DVIN   67
> -#define CLKID_UART2  68
> +/* CLKID_UART2 */
>  /* #define CLKID_SANA */
>  #define CLKID_VPU_INTR   70
>  #define CLKID_SEC_AHB_AHB3_BRIDGE 71
> diff --git a/include/dt-bindings/clock/gxbb-clkc.h 
> b/include/dt-bindings/clock/gxbb-clkc.h
> index 692846c7941b..7b329df47752 100644
> --- a/include/dt-bindings/clock/gxbb-clkc.h
> +++ b/include/dt-bindings/clock/gxbb-clkc.h
> @@ -15,13 +15,16 @@
>  #define CLKID_SPI  34
>  #define CLKID_I2C  22
>  #define CLKID_SAR_ADC  23
> +#define CLKID_UART026
>  #define CLKID_ETH  36
> +#define CLKID_UART148
>  #define CLKID_USB0 50
>  #define CLKID_USB1 51
>  #define CLKID_USB  55
>  #define CLKID_HDMI_PCLK63
>  #define CLKID_USB1_DDR_BRIDGE  64
>  #define CLKID_USB0_DDR_BRIDGE  65
> +#define CLKID_UART268
>  #define CLKID_SANA 69
>  #define CLKID_GCLK_VENCI_INT0  77
>  #define CLKID_AO_I2C   93
> --
> 2.11.0
> 

Re: [PATCH v3 1/4] dt-bindings: clock: gxbb: expose UART clocks

[Michael Turquette]

Quoting Helmut Klein (2017-03-31 18:54:34)
> Expose the clock ids of the three none AO uarts to the dt-bindings
> 
> Signed-off-by: Helmut Klein 

Acked-by: Michael Turquette 

> ---
>  drivers/clk/meson/gxbb.h  | 6 +++---
>  include/dt-bindings/clock/gxbb-clkc.h | 3 +++
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> index 8ee2022ce5d5..1edfaa5fe307 100644
> --- a/drivers/clk/meson/gxbb.h
> +++ b/drivers/clk/meson/gxbb.h
> @@ -194,7 +194,7 @@
>  /* #define CLKID_SAR_ADC */
>  #define CLKID_SMART_CARD 24
>  #define CLKID_RNG0   25
> -#define CLKID_UART0  26
> +/* CLKID_UART0 */
>  #define CLKID_SDHC   27
>  #define CLKID_STREAM 28
>  #define CLKID_ASYNC_FIFO 29
> @@ -216,7 +216,7 @@
>  #define CLKID_ADC45
>  #define CLKID_BLKMV  46
>  #define CLKID_AIU47
> -#define CLKID_UART1  48
> +/* CLKID_UART1 */
>  #define CLKID_G2D49
>  /* CLKID_USB0 */
>  /* CLKID_USB1 */
> @@ -236,7 +236,7 @@
>  /* CLKID_USB0_DDR_BRIDGE */
>  #define CLKID_MMC_PCLK   66
>  #define CLKID_DVIN   67
> -#define CLKID_UART2  68
> +/* CLKID_UART2 */
>  /* #define CLKID_SANA */
>  #define CLKID_VPU_INTR   70
>  #define CLKID_SEC_AHB_AHB3_BRIDGE 71
> diff --git a/include/dt-bindings/clock/gxbb-clkc.h 
> b/include/dt-bindings/clock/gxbb-clkc.h
> index 692846c7941b..7b329df47752 100644
> --- a/include/dt-bindings/clock/gxbb-clkc.h
> +++ b/include/dt-bindings/clock/gxbb-clkc.h
> @@ -15,13 +15,16 @@
>  #define CLKID_SPI  34
>  #define CLKID_I2C  22
>  #define CLKID_SAR_ADC  23
> +#define CLKID_UART026
>  #define CLKID_ETH  36
> +#define CLKID_UART148
>  #define CLKID_USB0 50
>  #define CLKID_USB1 51
>  #define CLKID_USB  55
>  #define CLKID_HDMI_PCLK63
>  #define CLKID_USB1_DDR_BRIDGE  64
>  #define CLKID_USB0_DDR_BRIDGE  65
> +#define CLKID_UART268
>  #define CLKID_SANA 69
>  #define CLKID_GCLK_VENCI_INT0  77
>  #define CLKID_AO_I2C   93
> --
> 2.11.0
> 

Re: [PATCH v1 0/8] clk: meson: gxbb: more clock controller update for audio support

[Michael Turquette]

Hi Jerome,

Adding Neil Armstong to Cc.

Quoting Jerome Brunet (2017-03-28 07:45:57)
> The patchset is the 2nd round of update to the meson gxbb clock controller
> to add initial audio support. The patchset is based on clk-next.
> 
> There is not much out of the ordinary here (adding new clocks and exposing
> them) except maybe for 2 patches:
> Patch #2: Adds a safety check while registering clocks to protect against
>   holes in clk_hw_onecell_data, if it ever happens. Same thing is
>   done for the meson8b clock controller. 
> Patch #3: Adds a new clock divider driver to implement the necessary
>   policy for the i2s master clock (see patch changelog)
> 
> This patchset has been test on the gxbb p200 and gxl p230.

First off, this series looks fine to me. Please add,

Acked-by: Michael Turquette <mturque...@baylibre.com>

Secondly, it seems the AmLogic clock drivers have mostly calmed down and
things are in the "add new clocks when we need them" phase, which is
nice. Since you and Neil are doing a lot of this work, might I suggest
that you both start collecting patches for the AmLogic/meson clock
drivers begin submitting pull requests to Stephen and myself?

As usual the rules are the same as always: all patches in the PR must
first be posted for review on the list. PRs should correspond to signed
tags. Stephen and I might ignore PRs sent after -rc4, and will
definitely ignore PRs sent after -rc6 since we want some stabilization
time before the merge window. Base your branch on -rc1, not on clk-next.

Also feel free to submit a patch to MAINTAINERS with either one or both
of you maintaining the meson clk stuff, assuming that you're OK to
review all of those patches and collect them into a PR.

Thoughts?

If it sounds good to you then I suggest grabbing the clk-meson branch
from the clk tree and using that as a baseline for your first PR. In the
future you'll just Linus' -rc1, but I have already created a branch for
this cycle. You can apply these 8 patches with my Ack and send a PR by
-rc6 (possibly with other stuff collected from Martin, etc).

Thanks,
Mike

> 
> Jerome Brunet (8):
>   dt-bindings: clock: gxbb: expose spdif clock gates
>   clk: meson: gxbb: protect against holes in the onecell_data array
>   clk: meson: add audio clock divider support
>   clk: meson: gxbb: add cts_amclk
>   clk: meson: gxbb: add cts_mclk_i958
>   clk: meson: gxbb: add cts_i958 clock
>   dt-bindings: clock: gxbb: expose i2s master clock
>   dt-bindings: clock: gxbb: expose spdif master clock
> 
>  drivers/clk/meson/Makefile|   2 +-
>  drivers/clk/meson/clk-audio-divider.c | 149 
> ++
>  drivers/clk/meson/clkc.h  |  10 +++
>  drivers/clk/meson/gxbb.c  | 144 
>  drivers/clk/meson/gxbb.h  |  13 ++-
>  include/dt-bindings/clock/gxbb-clkc.h |   5 ++
>  6 files changed, 319 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/clk/meson/clk-audio-divider.c
> 
> -- 
> 2.9.3
> 

Re: [PATCH v1 0/8] clk: meson: gxbb: more clock controller update for audio support

[Michael Turquette]

Hi Jerome,

Adding Neil Armstong to Cc.

Quoting Jerome Brunet (2017-03-28 07:45:57)
> The patchset is the 2nd round of update to the meson gxbb clock controller
> to add initial audio support. The patchset is based on clk-next.
> 
> There is not much out of the ordinary here (adding new clocks and exposing
> them) except maybe for 2 patches:
> Patch #2: Adds a safety check while registering clocks to protect against
>   holes in clk_hw_onecell_data, if it ever happens. Same thing is
>   done for the meson8b clock controller. 
> Patch #3: Adds a new clock divider driver to implement the necessary
>   policy for the i2s master clock (see patch changelog)
> 
> This patchset has been test on the gxbb p200 and gxl p230.

First off, this series looks fine to me. Please add,

Acked-by: Michael Turquette 

Secondly, it seems the AmLogic clock drivers have mostly calmed down and
things are in the "add new clocks when we need them" phase, which is
nice. Since you and Neil are doing a lot of this work, might I suggest
that you both start collecting patches for the AmLogic/meson clock
drivers begin submitting pull requests to Stephen and myself?

As usual the rules are the same as always: all patches in the PR must
first be posted for review on the list. PRs should correspond to signed
tags. Stephen and I might ignore PRs sent after -rc4, and will
definitely ignore PRs sent after -rc6 since we want some stabilization
time before the merge window. Base your branch on -rc1, not on clk-next.

Also feel free to submit a patch to MAINTAINERS with either one or both
of you maintaining the meson clk stuff, assuming that you're OK to
review all of those patches and collect them into a PR.

Thoughts?

If it sounds good to you then I suggest grabbing the clk-meson branch
from the clk tree and using that as a baseline for your first PR. In the
future you'll just Linus' -rc1, but I have already created a branch for
this cycle. You can apply these 8 patches with my Ack and send a PR by
-rc6 (possibly with other stuff collected from Martin, etc).

Thanks,
Mike

> 
> Jerome Brunet (8):
>   dt-bindings: clock: gxbb: expose spdif clock gates
>   clk: meson: gxbb: protect against holes in the onecell_data array
>   clk: meson: add audio clock divider support
>   clk: meson: gxbb: add cts_amclk
>   clk: meson: gxbb: add cts_mclk_i958
>   clk: meson: gxbb: add cts_i958 clock
>   dt-bindings: clock: gxbb: expose i2s master clock
>   dt-bindings: clock: gxbb: expose spdif master clock
> 
>  drivers/clk/meson/Makefile|   2 +-
>  drivers/clk/meson/clk-audio-divider.c | 149 
> ++
>  drivers/clk/meson/clkc.h  |  10 +++
>  drivers/clk/meson/gxbb.c  | 144 
>  drivers/clk/meson/gxbb.h  |  13 ++-
>  include/dt-bindings/clock/gxbb-clkc.h |   5 ++
>  6 files changed, 319 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/clk/meson/clk-audio-divider.c
> 
> -- 
> 2.9.3
> 

Re: [PATCH v2 0/5] clk: meson: Fix GXBB and GXL/GXM GP0 PLL

[Michael Turquette]

Hi Neil,

Quoting Neil Armstrong (2017-03-22 03:32:22)
> This patchset fixes support for the Amlogic GXBB then GXL/GXM embedded GP0 
> PLL.
> 
> The current support is done via a very generic interface where only the
> N/M/OD parameters are changed in the control registers.
> 
> But unlike the Fixed PLL, this PLL is not initialized by the bootloader or
> firmware, and needs some parameters to initialize and lock correctly.
> 
> This patchset also adds the GXL variant compatible string which is already
> supported by the GXL and GXM DT nodes.
> 
> Changes since v1 at [1]:
>  - Rebase on the Mali clocks patchset at [2]
>  - also depends on v2 Audio Clocks patchset from Jerome Brunet at [3]
>  - Add match table and separate tables for gxl
>  - Switch to probe function to use match table data only
>  - Rename unreset_for_lock to clear_reset_for_lock

Thanks for the quick changes. Applied to clk-meson, a stable branch,
which was merged into clk-next.

Best regards,
Mike

> 
> [1] 
> http://lkml.kernel.org/r/1489411604-18700-1-git-send-email-narmstr...@baylibre.com
> [2] 
> http://lkml.kernel.org/r/1490177935-9646-1-git-send-email-narmstr...@baylibre.com
> [3] http://lkml.kernel.org/r/20170309104154.28295-1-jbru...@baylibre.com
> 
> Neil Armstrong (5):
>   clk: meson: Add support for parameters for specific PLLs
>   clk: meson-gxbb: Add GP0 PLL init parameters
>   clk: meson-gxbb: Add GXL/GXM GP0 Variant
>   clk: meson-gxbb: Expose GP0 dt-bindings clock id
>   dt-bindings: clock: gxbb-clkc: Add GXL compatible variant
> 
>  .../bindings/clock/amlogic,gxbb-clkc.txt   |   3 +-
>  drivers/clk/meson/clk-pll.c|  53 +++-
>  drivers/clk/meson/clkc.h   |  23 ++
>  drivers/clk/meson/gxbb.c   | 314 
> +++--
>  drivers/clk/meson/gxbb.h   |   4 +-
>  include/dt-bindings/clock/gxbb-clkc.h  |   1 +
>  6 files changed, 366 insertions(+), 32 deletions(-)
> 
> -- 
> 1.9.1
> 

Re: [PATCH v2 0/5] clk: meson: Fix GXBB and GXL/GXM GP0 PLL

[Michael Turquette]

Hi Neil,

Quoting Neil Armstrong (2017-03-22 03:32:22)
> This patchset fixes support for the Amlogic GXBB then GXL/GXM embedded GP0 
> PLL.
> 
> The current support is done via a very generic interface where only the
> N/M/OD parameters are changed in the control registers.
> 
> But unlike the Fixed PLL, this PLL is not initialized by the bootloader or
> firmware, and needs some parameters to initialize and lock correctly.
> 
> This patchset also adds the GXL variant compatible string which is already
> supported by the GXL and GXM DT nodes.
> 
> Changes since v1 at [1]:
>  - Rebase on the Mali clocks patchset at [2]
>  - also depends on v2 Audio Clocks patchset from Jerome Brunet at [3]
>  - Add match table and separate tables for gxl
>  - Switch to probe function to use match table data only
>  - Rename unreset_for_lock to clear_reset_for_lock

Thanks for the quick changes. Applied to clk-meson, a stable branch,
which was merged into clk-next.

Best regards,
Mike

> 
> [1] 
> http://lkml.kernel.org/r/1489411604-18700-1-git-send-email-narmstr...@baylibre.com
> [2] 
> http://lkml.kernel.org/r/1490177935-9646-1-git-send-email-narmstr...@baylibre.com
> [3] http://lkml.kernel.org/r/20170309104154.28295-1-jbru...@baylibre.com
> 
> Neil Armstrong (5):
>   clk: meson: Add support for parameters for specific PLLs
>   clk: meson-gxbb: Add GP0 PLL init parameters
>   clk: meson-gxbb: Add GXL/GXM GP0 Variant
>   clk: meson-gxbb: Expose GP0 dt-bindings clock id
>   dt-bindings: clock: gxbb-clkc: Add GXL compatible variant
> 
>  .../bindings/clock/amlogic,gxbb-clkc.txt   |   3 +-
>  drivers/clk/meson/clk-pll.c|  53 +++-
>  drivers/clk/meson/clkc.h   |  23 ++
>  drivers/clk/meson/gxbb.c   | 314 
> +++--
>  drivers/clk/meson/gxbb.h   |   4 +-
>  include/dt-bindings/clock/gxbb-clkc.h  |   1 +
>  6 files changed, 366 insertions(+), 32 deletions(-)
> 
> -- 
> 1.9.1
> 

Re: [PATCH v4 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Michael Turquette]

Quoting Kevin Hilman (2017-03-24 12:20:31)
> Neil Armstrong  writes:
> 
> > The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> >
> > The node is simply added in the meson-gxbb.dtsi file.
> >
> > For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> > patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> > dtsi files.
> >
> > Signed-off-by: Neil Armstrong 
> 
> LGTM, I can apply this when the clk driver changes are merged (feel free
> to let me know when that happens, in case I'm not paying attention.)

Applied to clk-meson, a stable branch, which has been merged into
clk-next.

Kevin, the dtsi is all yours.

Regards,
Mike

> 
> 
> nit: This series (and previous ones) use MALI, but I believe the correct
> way is Mali. Could you standarize on that throughout the series?
> 
> 
> Kevin
> 
> > ---
> >  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 37 
> >  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 
> > 
> >  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
> >  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
> >  4 files changed, 82 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
> > b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > index 04b3324..0617a3d 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > @@ -478,6 +478,43 @@
> >   };
> >  };
> >  
> > + {
> > + mali: gpu@c {
> > + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> > + reg = <0x0 0xc 0x0 0x4>;
> > + interrupts = ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ;
> > + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> > + "pp0", "ppmmu0", "pp1", "ppmmu1",
> > + "pp2", "ppmmu2";
> > + clocks = < CLKID_CLK81>, < CLKID_MALI>;
> > + clock-names = "bus", "core";
> > +
> > + /*
> > +  * Mali clocking is provided by two identical clock paths
> > +  * MALI_0 and MALI_1 muxed to a single clock by a glitch
> > +  * free mux to safely change frequency while running.
> > +  */
> > + assigned-clocks = < CLKID_MALI_0_SEL>,
> > +   < CLKID_MALI_0>,
> > +   < CLKID_MALI>; /* Glitch free mux */
> > + assigned-clock-parents = < CLKID_FCLK_DIV3>,
> > +  <0>, /* Do Nothing */
> > +  < CLKID_MALI_0>;
> > + assigned-clock-rates = <0>, /* Do Nothing */
> > +<6>,
> > +<0>; /* Do Nothing */
> > + };
> > +};
> > +
> >  _A {
> >   clocks = < CLKID_I2C>;
> >  };
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi 
> > b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> > new file mode 100644
> > index 000..f06cc234
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> > @@ -0,0 +1,43 @@
> > +/*
> > + * Copyright (c) 2017 BayLibre SAS
> > + * Author: Neil Armstrong 
> > + *
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > + */
> > +
> > + {
> > + mali: gpu@c {
> > + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> > + reg = <0x0 0xc 0x0 0x4>;
> > + interrupts = ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ;
> > + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> > + "pp0", "ppmmu0", "pp1", "ppmmu1",
> > + "pp2", "ppmmu2";
> > + clocks = < CLKID_CLK81>, < CLKID_MALI>;
> > + clock-names = "bus", "core";
> > +
> > + /*
> > +  * Mali clocking is provided by two identical clock paths
> > +  * MALI_0 and MALI_1 muxed to a single clock by a glitch
> > +  * free mux to safely change frequency while running.
> > +  */
> > + assigned-clocks = < CLKID_MALI_0_SEL>,
> > +   < CLKID_MALI_0>,
> > +   < CLKID_MALI>; /* Glitch free mux */
> > + assigned-clock-parents = < 

Re: [PATCH v4 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Michael Turquette]

Quoting Kevin Hilman (2017-03-24 12:20:31)
> Neil Armstrong  writes:
> 
> > The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> >
> > The node is simply added in the meson-gxbb.dtsi file.
> >
> > For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> > patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> > dtsi files.
> >
> > Signed-off-by: Neil Armstrong 
> 
> LGTM, I can apply this when the clk driver changes are merged (feel free
> to let me know when that happens, in case I'm not paying attention.)

Applied to clk-meson, a stable branch, which has been merged into
clk-next.

Kevin, the dtsi is all yours.

Regards,
Mike

> 
> 
> nit: This series (and previous ones) use MALI, but I believe the correct
> way is Mali. Could you standarize on that throughout the series?
> 
> 
> Kevin
> 
> > ---
> >  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 37 
> >  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 
> > 
> >  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
> >  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
> >  4 files changed, 82 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
> > b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > index 04b3324..0617a3d 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > @@ -478,6 +478,43 @@
> >   };
> >  };
> >  
> > + {
> > + mali: gpu@c {
> > + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> > + reg = <0x0 0xc 0x0 0x4>;
> > + interrupts = ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ;
> > + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> > + "pp0", "ppmmu0", "pp1", "ppmmu1",
> > + "pp2", "ppmmu2";
> > + clocks = < CLKID_CLK81>, < CLKID_MALI>;
> > + clock-names = "bus", "core";
> > +
> > + /*
> > +  * Mali clocking is provided by two identical clock paths
> > +  * MALI_0 and MALI_1 muxed to a single clock by a glitch
> > +  * free mux to safely change frequency while running.
> > +  */
> > + assigned-clocks = < CLKID_MALI_0_SEL>,
> > +   < CLKID_MALI_0>,
> > +   < CLKID_MALI>; /* Glitch free mux */
> > + assigned-clock-parents = < CLKID_FCLK_DIV3>,
> > +  <0>, /* Do Nothing */
> > +  < CLKID_MALI_0>;
> > + assigned-clock-rates = <0>, /* Do Nothing */
> > +<6>,
> > +<0>; /* Do Nothing */
> > + };
> > +};
> > +
> >  _A {
> >   clocks = < CLKID_I2C>;
> >  };
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi 
> > b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> > new file mode 100644
> > index 000..f06cc234
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> > @@ -0,0 +1,43 @@
> > +/*
> > + * Copyright (c) 2017 BayLibre SAS
> > + * Author: Neil Armstrong 
> > + *
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > + */
> > +
> > + {
> > + mali: gpu@c {
> > + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> > + reg = <0x0 0xc 0x0 0x4>;
> > + interrupts = ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ,
> > +  ;
> > + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> > + "pp0", "ppmmu0", "pp1", "ppmmu1",
> > + "pp2", "ppmmu2";
> > + clocks = < CLKID_CLK81>, < CLKID_MALI>;
> > + clock-names = "bus", "core";
> > +
> > + /*
> > +  * Mali clocking is provided by two identical clock paths
> > +  * MALI_0 and MALI_1 muxed to a single clock by a glitch
> > +  * free mux to safely change frequency while running.
> > +  */
> > + assigned-clocks = < CLKID_MALI_0_SEL>,
> > +   < CLKID_MALI_0>,
> > +   < CLKID_MALI>; /* Glitch free mux */
> > + assigned-clock-parents = < CLKID_FCLK_DIV3>,
> > +  <0>, /* Do 

Re: [PATCH v2 0/9] clk: meson: update clock controller for audio support

[Michael Turquette]

Quoting Kevin Hilman (2017-03-10 16:39:27)
> Jerome Brunet  writes:
> 
> > This patchset is a first round of update to the meson clock controllers
> > to bring audio support. The patchset is based on clk-next. It could be
> > rebased on amlogic tree later on, if you prefer the patches to go through
> > Kevin's tree.
> 
> I'd prefer these go through the clk tree, and get an immutable branch
> that I can use for my stuff that goes through the arm-soc tree.

Applied to clk-meson, a stable branch, which has been merged into
clk-next.

Kevin, feel free to use clk-meson or any commit id therein: they will
not be rebased.

Regards,
Mike

> 
> Kevin
> 
> > First patch fix an issue found while writing patch 5 (Giving ternary
> > operator to SET_PARM)
> >
> > Following Stephen comment on the v1, patch 2 adds the const qualifiers
> > missing upstream.
> >
> > Patches 3 and 4 put the generic muxes and divisors declaration in tables so
> > the register address fixup works in the same way as the clock gates. We are
> > going to add more of these clock types for audio or gpu support, so we
> > can't continue to fix addresses individually like it is currently done.
> >
> > Patches 5 to 8 improve the support of the mpll clocks, now allowing the
> > rate to be set. Among other things, the mplls are the parent clocks of the
> > i2s and spdif clocks.
> >
> > Patch 9 expose the clock gates required to power on the i2s output.
> >
> > These patches have been tested on the meson gxbb p200 board, as part of the
> > ongoing work to bring audio support to meson SoC family.
> >
> > Changes since v1 [0]:
> >  * Add SET_PARM fix to the series
> >  * Add missing const qualifiers to the clock arrays
> >  * No more additional patches required as SAR clocks have been merged
> >
> > [0]: http://lkml.kernel.org/r/20170228133002.17894-1-jbru...@baylibre.com
> >
> > Jerome Brunet (9):
> >   clk: meson: fix SET_PARM macro
> >   clk: meson: add missing const qualifiers on gate arrays
> >   clk: meson8b: put dividers and muxes in tables
> >   clk: gxbb: put dividers and muxes in tables
> >   clk: meson: mpll: add rw operation
> >   clk: meson: gxbb: mpll: use rw operation
> >   clk: meson8b: add the mplls clocks 0, 1 and 2
> >   clk: meson: mpll: correct N2 maximum value
> >   dt-bindings: clk: gxbb: expose i2s output clock gates
> >
> >  drivers/clk/meson/clk-mpll.c  | 152 
> > --
> >  drivers/clk/meson/clkc.h  |   6 +-
> >  drivers/clk/meson/gxbb.c  |  66 ---
> >  drivers/clk/meson/gxbb.h  |  10 +--
> >  drivers/clk/meson/meson8b.c   | 127 ++--
> >  drivers/clk/meson/meson8b.h   |  20 -
> >  include/dt-bindings/clock/gxbb-clkc.h |   5 ++
> >  7 files changed, 356 insertions(+), 30 deletions(-)

Re: [PATCH v2 0/9] clk: meson: update clock controller for audio support

[Michael Turquette]

Quoting Kevin Hilman (2017-03-10 16:39:27)
> Jerome Brunet  writes:
> 
> > This patchset is a first round of update to the meson clock controllers
> > to bring audio support. The patchset is based on clk-next. It could be
> > rebased on amlogic tree later on, if you prefer the patches to go through
> > Kevin's tree.
> 
> I'd prefer these go through the clk tree, and get an immutable branch
> that I can use for my stuff that goes through the arm-soc tree.

Applied to clk-meson, a stable branch, which has been merged into
clk-next.

Kevin, feel free to use clk-meson or any commit id therein: they will
not be rebased.

Regards,
Mike

> 
> Kevin
> 
> > First patch fix an issue found while writing patch 5 (Giving ternary
> > operator to SET_PARM)
> >
> > Following Stephen comment on the v1, patch 2 adds the const qualifiers
> > missing upstream.
> >
> > Patches 3 and 4 put the generic muxes and divisors declaration in tables so
> > the register address fixup works in the same way as the clock gates. We are
> > going to add more of these clock types for audio or gpu support, so we
> > can't continue to fix addresses individually like it is currently done.
> >
> > Patches 5 to 8 improve the support of the mpll clocks, now allowing the
> > rate to be set. Among other things, the mplls are the parent clocks of the
> > i2s and spdif clocks.
> >
> > Patch 9 expose the clock gates required to power on the i2s output.
> >
> > These patches have been tested on the meson gxbb p200 board, as part of the
> > ongoing work to bring audio support to meson SoC family.
> >
> > Changes since v1 [0]:
> >  * Add SET_PARM fix to the series
> >  * Add missing const qualifiers to the clock arrays
> >  * No more additional patches required as SAR clocks have been merged
> >
> > [0]: http://lkml.kernel.org/r/20170228133002.17894-1-jbru...@baylibre.com
> >
> > Jerome Brunet (9):
> >   clk: meson: fix SET_PARM macro
> >   clk: meson: add missing const qualifiers on gate arrays
> >   clk: meson8b: put dividers and muxes in tables
> >   clk: gxbb: put dividers and muxes in tables
> >   clk: meson: mpll: add rw operation
> >   clk: meson: gxbb: mpll: use rw operation
> >   clk: meson8b: add the mplls clocks 0, 1 and 2
> >   clk: meson: mpll: correct N2 maximum value
> >   dt-bindings: clk: gxbb: expose i2s output clock gates
> >
> >  drivers/clk/meson/clk-mpll.c  | 152 
> > --
> >  drivers/clk/meson/clkc.h  |   6 +-
> >  drivers/clk/meson/gxbb.c  |  66 ---
> >  drivers/clk/meson/gxbb.h  |  10 +--
> >  drivers/clk/meson/meson8b.c   | 127 ++--
> >  drivers/clk/meson/meson8b.h   |  20 -
> >  include/dt-bindings/clock/gxbb-clkc.h |   5 ++
> >  7 files changed, 356 insertions(+), 30 deletions(-)

Re: [PATCH 3/5] clk: meson-gxbb: Add GXL/GXM GP0 Variant

[Michael Turquette]

Quoting Neil Armstrong (2017-03-22 02:22:57)
> On 03/22/2017 12:49 AM, Michael Turquette wrote:
> > Hi Neil,
> > 
> > Quoting Neil Armstrong (2017-03-13 06:26:42)
> >> @@ -821,6 +893,7 @@ struct pll_params_table gxbb_gp0_params_table[] = {
> >> _hdmi_pll,
> >> _sys_pll,
> >> _gp0_pll,
> >> +   _gp0_pll,
> 
> Yes, because this is the table used to change the register base, this won't 
> harm in any way
> to add SoC variant clocks, since they they are initialized using the 
> gxbb_hw_onecell_data table.
> 
> > 
> > Is there a reason for adding the pointer to this array here? It seems to
> > me that the gxbb_gp0_pll and gxl_gp0_pll are mutually exclusive, so
> > perhaps two different tables should be used?
> > 
> >>  };
> >>  
> >>  static struct meson_clk_mpll *const gxbb_clk_mplls[] = {
> >> @@ -923,6 +996,10 @@ static int gxbb_clkc_probe(struct platform_device 
> >> *pdev)
> >> struct clk *parent_clk;
> >> struct device *dev = >dev;
> >>  
> >> +   /* Override GP0 clock for GXL/GXM */
> >> +   if (of_device_is_compatible(dev->of_node, "amlogic,gxl-clkc"))
> >> +   gxbb_hw_onecell_data.hws[CLKID_GP0_PLL] = _gp0_pll.hw;
> > 
> > Similarly, this above is a little ugly compared to dedicated tables for
> > each variant.
> 
> Here is the true uglyness, but would you like to have the exact same 
> gxbb_hw_onecell_data
> duplicated for only two different clocks ?
> The gxbb_hw_onecell_data table is 105 lines, and when adding new clocks, we 
> will need to
> make sure they are still synchronized.
> 
> If you have a better idea... I can still push a v2 with such table with also a
> separate gxbb_clk_plls table stored in a struct given from 
> of_device_get_match_data()

I was not thinking of duplicating all of the clock data table, but
breaking out the parts with variation into separate tables. E.g. a
common table, a gxbb table and a gp0 table.

But on second look your original solution is fine, especially since
those two new tables I mentioned would only have a single element in
them, which is silly.

Ack.

Regards,
Mike

> 
> Neil
> 
> > 
> > Regards,
> > Mike
> > 
> >> +
> >> /*  Generic clocks and PLLs */
> >> clk_base = of_iomap(dev->of_node, 0);
> >> if (!clk_base) {
> >> @@ -996,6 +1073,7 @@ static int gxbb_clkc_probe(struct platform_device 
> >> *pdev)
> >>  
> >>  static const struct of_device_id gxbb_clkc_match_table[] = {
> >> { .compatible = "amlogic,gxbb-clkc" },
> >> +   { .compatible = "amlogic,gxl-clkc" },
> >> { }
> >>  };
> >>  
> >> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> >> index 8ee2022..7f99bf6 100644
> >> --- a/drivers/clk/meson/gxbb.h
> >> +++ b/drivers/clk/meson/gxbb.h
> >> @@ -71,6 +71,8 @@
> >>  #define HHI_GP0_PLL_CNTL2  0x44 /* 0x11 offset in data sheet 
> >> */
> >>  #define HHI_GP0_PLL_CNTL3  0x48 /* 0x12 offset in data sheet 
> >> */
> >>  #define HHI_GP0_PLL_CNTL4  0x4c /* 0x13 offset in data sheet 
> >> */
> >> +#defineHHI_GP0_PLL_CNTL5   0x50 /* 0x14 offset in 
> >> data sheet */
> >> +#defineHHI_GP0_PLL_CNTL1   0x58 /* 0x16 offset in 
> >> data sheet */
> >>  
> >>  #define HHI_XTAL_DIVN_CNTL 0xbc /* 0x2f offset in data sheet 
> >> */
> >>  #define HHI_TIMER90K   0xec /* 0x3b offset in data sheet 
> >> */
> >> -- 
> >> 1.9.1
> >>
> 

Re: [PATCH 3/5] clk: meson-gxbb: Add GXL/GXM GP0 Variant

[Michael Turquette]

Quoting Neil Armstrong (2017-03-22 02:22:57)
> On 03/22/2017 12:49 AM, Michael Turquette wrote:
> > Hi Neil,
> > 
> > Quoting Neil Armstrong (2017-03-13 06:26:42)
> >> @@ -821,6 +893,7 @@ struct pll_params_table gxbb_gp0_params_table[] = {
> >> _hdmi_pll,
> >> _sys_pll,
> >> _gp0_pll,
> >> +   _gp0_pll,
> 
> Yes, because this is the table used to change the register base, this won't 
> harm in any way
> to add SoC variant clocks, since they they are initialized using the 
> gxbb_hw_onecell_data table.
> 
> > 
> > Is there a reason for adding the pointer to this array here? It seems to
> > me that the gxbb_gp0_pll and gxl_gp0_pll are mutually exclusive, so
> > perhaps two different tables should be used?
> > 
> >>  };
> >>  
> >>  static struct meson_clk_mpll *const gxbb_clk_mplls[] = {
> >> @@ -923,6 +996,10 @@ static int gxbb_clkc_probe(struct platform_device 
> >> *pdev)
> >> struct clk *parent_clk;
> >> struct device *dev = >dev;
> >>  
> >> +   /* Override GP0 clock for GXL/GXM */
> >> +   if (of_device_is_compatible(dev->of_node, "amlogic,gxl-clkc"))
> >> +   gxbb_hw_onecell_data.hws[CLKID_GP0_PLL] = _gp0_pll.hw;
> > 
> > Similarly, this above is a little ugly compared to dedicated tables for
> > each variant.
> 
> Here is the true uglyness, but would you like to have the exact same 
> gxbb_hw_onecell_data
> duplicated for only two different clocks ?
> The gxbb_hw_onecell_data table is 105 lines, and when adding new clocks, we 
> will need to
> make sure they are still synchronized.
> 
> If you have a better idea... I can still push a v2 with such table with also a
> separate gxbb_clk_plls table stored in a struct given from 
> of_device_get_match_data()

I was not thinking of duplicating all of the clock data table, but
breaking out the parts with variation into separate tables. E.g. a
common table, a gxbb table and a gp0 table.

But on second look your original solution is fine, especially since
those two new tables I mentioned would only have a single element in
them, which is silly.

Ack.

Regards,
Mike

> 
> Neil
> 
> > 
> > Regards,
> > Mike
> > 
> >> +
> >> /*  Generic clocks and PLLs */
> >> clk_base = of_iomap(dev->of_node, 0);
> >> if (!clk_base) {
> >> @@ -996,6 +1073,7 @@ static int gxbb_clkc_probe(struct platform_device 
> >> *pdev)
> >>  
> >>  static const struct of_device_id gxbb_clkc_match_table[] = {
> >> { .compatible = "amlogic,gxbb-clkc" },
> >> +   { .compatible = "amlogic,gxl-clkc" },
> >> { }
> >>  };
> >>  
> >> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> >> index 8ee2022..7f99bf6 100644
> >> --- a/drivers/clk/meson/gxbb.h
> >> +++ b/drivers/clk/meson/gxbb.h
> >> @@ -71,6 +71,8 @@
> >>  #define HHI_GP0_PLL_CNTL2  0x44 /* 0x11 offset in data sheet 
> >> */
> >>  #define HHI_GP0_PLL_CNTL3  0x48 /* 0x12 offset in data sheet 
> >> */
> >>  #define HHI_GP0_PLL_CNTL4  0x4c /* 0x13 offset in data sheet 
> >> */
> >> +#defineHHI_GP0_PLL_CNTL5   0x50 /* 0x14 offset in 
> >> data sheet */
> >> +#defineHHI_GP0_PLL_CNTL1   0x58 /* 0x16 offset in 
> >> data sheet */
> >>  
> >>  #define HHI_XTAL_DIVN_CNTL 0xbc /* 0x2f offset in data sheet 
> >> */
> >>  #define HHI_TIMER90K   0xec /* 0x3b offset in data sheet 
> >> */
> >> -- 
> >> 1.9.1
> >>
> 

Re: [PATCH v3 2/3] clk: meson-gxbb: Add MALI clocks

[Michael Turquette]

Quoting Neil Armstrong (2017-03-22 02:14:40)
> On 03/22/2017 12:31 AM, Michael Turquette wrote:
> > Hi Neil,
> > 
> > Quoting Neil Armstrong (2017-03-09 04:53:46)
> >> The Mali is clocked by two identical clock paths behind a glitch free mux
> >> to safely change frequency while running.
> >>
> >> The two "mali_0" and "mali_1" clocks are composed of a mux, divider and 
> >> gate.
> >> Expose these two clocks trees using generic clocks.
> >> Finally the glitch free mux is added as "mali" clock.
> >>
> >> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
> >> ---
> >>  drivers/clk/meson/gxbb.c | 139 
> >> +++
> >>  1 file changed, 139 insertions(+)
> >>
> >> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> >> index 5059c7b..d9f7fef 100644
> >> --- a/drivers/clk/meson/gxbb.c
> >> +++ b/drivers/clk/meson/gxbb.c
> >> @@ -634,6 +634,131 @@
> >> },
> >>  };
> >>  
> >> +/*
> >> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
> >> + * muxed by a glitch-free switch.
> >> + */
> >> +
> >> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> >> +static const char *gxbb_mali_0_1_parent_names[] = {
> >> +   "xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> >> +   "fclk_div4", "fclk_div3", "fclk_div5"
> >> +};
> >> +
> >> +static struct clk_mux gxbb_mali_0_sel = {
> >> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> >> +   .mask = 0x7,
> >> +   .shift = 9,
> >> +   .table = mux_table_mali_0_1,
> >> +   .lock = _lock,
> >> +   .hw.init = &(struct clk_init_data){
> >> +   .name = "mali_0_sel",
> >> +   .ops = _mux_ops,
> >> +   /*
> >> +* bits 10:9 selects from 8 possible parents:
> >> +* xtal, gp0_pll, mpll2, mpll1, fclk_div7,
> >> +* fclk_div4, fclk_div3, fclk_div5
> >> +*/
> >> +   .parent_names = gxbb_mali_0_1_parent_names,
> >> +   .num_parents = 8,
> >> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> > 
> > Are all of these CLK_IGNORE_UNUSED flags necessary? If so, why? I'm just
> > wondering if this is yet another display-related use case where a
> > hand-off mechanism would work better?
> 
> Hi,
> 
> I'm just precocious about how these clocks will be handled, since the Mali 
> driver
> is out of tree, I'm not sure about how they will be handled at all.

Sure, but out of tree driver users can always use the clk_disable_unused
bootarg if needed.

> 
> But I can test and remove these if we consider my out-of-tree driver platform
> code as reference.

Great, thanks.

Best regards,
Mike

> 
> Neil
> 
> > 
> > Thanks,
> > Mike
> > 
> >> +   },
> >> +};
> >> +
> >> +static struct clk_divider gxbb_mali_0_div = {
> >> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> >> +   .shift = 0,
> >> +   .width = 7,
> >> +   .lock = _lock,
> >> +   .hw.init = &(struct clk_init_data){
> >> +   .name = "mali_0_div",
> >> +   .ops = _divider_ops,
> >> +   .parent_names = (const char *[]){ "mali_0_sel" },
> >> +   .num_parents = 1,
> >> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> >> +   },
> >> +};
> >> +
> >> +static struct clk_gate gxbb_mali_0 = {
> >> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> >> +   .bit_idx = 8,
> >> +   .lock = _lock,
> >> +   .hw.init = &(struct clk_init_data){
> >> +   .name = "mali_0",
> >> +   .ops = _gate_ops,
> >> +   .parent_names = (const char *[]){ "mali_0_div" },
> >> +   .num_parents = 1,
> >> +   .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> >> +   },
> >> +};
> >> +
> >> +static struct clk_mux gxbb_mali_1_sel = {
> >> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> >> +   .mask = 0x7,
> >> +   .s

Re: [PATCH v3 2/3] clk: meson-gxbb: Add MALI clocks

[Michael Turquette]

Quoting Neil Armstrong (2017-03-22 02:14:40)
> On 03/22/2017 12:31 AM, Michael Turquette wrote:
> > Hi Neil,
> > 
> > Quoting Neil Armstrong (2017-03-09 04:53:46)
> >> The Mali is clocked by two identical clock paths behind a glitch free mux
> >> to safely change frequency while running.
> >>
> >> The two "mali_0" and "mali_1" clocks are composed of a mux, divider and 
> >> gate.
> >> Expose these two clocks trees using generic clocks.
> >> Finally the glitch free mux is added as "mali" clock.
> >>
> >> Signed-off-by: Neil Armstrong 
> >> ---
> >>  drivers/clk/meson/gxbb.c | 139 
> >> +++
> >>  1 file changed, 139 insertions(+)
> >>
> >> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> >> index 5059c7b..d9f7fef 100644
> >> --- a/drivers/clk/meson/gxbb.c
> >> +++ b/drivers/clk/meson/gxbb.c
> >> @@ -634,6 +634,131 @@
> >> },
> >>  };
> >>  
> >> +/*
> >> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
> >> + * muxed by a glitch-free switch.
> >> + */
> >> +
> >> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> >> +static const char *gxbb_mali_0_1_parent_names[] = {
> >> +   "xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> >> +   "fclk_div4", "fclk_div3", "fclk_div5"
> >> +};
> >> +
> >> +static struct clk_mux gxbb_mali_0_sel = {
> >> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> >> +   .mask = 0x7,
> >> +   .shift = 9,
> >> +   .table = mux_table_mali_0_1,
> >> +   .lock = _lock,
> >> +   .hw.init = &(struct clk_init_data){
> >> +   .name = "mali_0_sel",
> >> +   .ops = _mux_ops,
> >> +   /*
> >> +* bits 10:9 selects from 8 possible parents:
> >> +* xtal, gp0_pll, mpll2, mpll1, fclk_div7,
> >> +* fclk_div4, fclk_div3, fclk_div5
> >> +*/
> >> +   .parent_names = gxbb_mali_0_1_parent_names,
> >> +   .num_parents = 8,
> >> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> > 
> > Are all of these CLK_IGNORE_UNUSED flags necessary? If so, why? I'm just
> > wondering if this is yet another display-related use case where a
> > hand-off mechanism would work better?
> 
> Hi,
> 
> I'm just precocious about how these clocks will be handled, since the Mali 
> driver
> is out of tree, I'm not sure about how they will be handled at all.

Sure, but out of tree driver users can always use the clk_disable_unused
bootarg if needed.

> 
> But I can test and remove these if we consider my out-of-tree driver platform
> code as reference.

Great, thanks.

Best regards,
Mike

> 
> Neil
> 
> > 
> > Thanks,
> > Mike
> > 
> >> +   },
> >> +};
> >> +
> >> +static struct clk_divider gxbb_mali_0_div = {
> >> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> >> +   .shift = 0,
> >> +   .width = 7,
> >> +   .lock = _lock,
> >> +   .hw.init = &(struct clk_init_data){
> >> +   .name = "mali_0_div",
> >> +   .ops = _divider_ops,
> >> +   .parent_names = (const char *[]){ "mali_0_sel" },
> >> +   .num_parents = 1,
> >> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> >> +   },
> >> +};
> >> +
> >> +static struct clk_gate gxbb_mali_0 = {
> >> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> >> +   .bit_idx = 8,
> >> +   .lock = _lock,
> >> +   .hw.init = &(struct clk_init_data){
> >> +   .name = "mali_0",
> >> +   .ops = _gate_ops,
> >> +   .parent_names = (const char *[]){ "mali_0_div" },
> >> +   .num_parents = 1,
> >> +   .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> >> +   },
> >> +};
> >> +
> >> +static struct clk_mux gxbb_mali_1_sel = {
> >> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> >> +   .mask = 0x7,
> >> +   .shift = 25,
> >> +   .table = mux_ta

Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API

[Michael Turquette]

Hi Georgi,

Quoting Georgi Djakov (2017-03-01 10:22:34)
> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt 
> b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> new file mode 100644
> index ..c62d86e4c52d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> @@ -0,0 +1,91 @@
> +Interconnect Provider Device Tree Bindings
> +=

I agree with Rob to skip the DT bindings for now. However I did review
this privately in February and I'll re-post my review comments here for
when the bindings do get discussed at a later date:

> +Optional properties:
> +interconnect-port : A phandle and interconnect provider specifier as defined 
> by
> +   bindings of the interconnect provider specified by phandle.
> +   This denotes the port to which the interconnect consumer is
> +   wired. It is used when there are multiple interconnect 
> providers
> +   that have one or multiple links between them.

Go ahead and remove the interconnect-port property description from the
provider part of the binding. It should be sufficient to say,
"interconnect providers can also be interconnect consumers, such as in
the case where two network-on-chip fabrics interface directly".

> +
> +Example:
> +
> +   snoc: snoc@058 {
> +   compatible = "qcom,msm-bus-snoc";
> +   reg = <0x58 0x14000>;
> +   #interconnect-cells = <1>;
> +   clock-names = "bus_clk", "bus_a_clk";
> +   clocks = < RPM_SMD_SNOC_CLK>, < 
> RPM_SMD_SNOC_A_CLK>;
> +   status = "okay";
> +   interconnect-port = < MAS_SNOC_CFG>,
> +   < SNOC_BIMC_0_MAS>,
> +   < SNOC_BIMC_1_MAS>,
> +   < SNOC_PNOC_SLV>;
> +   };
> +   bimc: bimc@040 {
> +   compatible = "qcom,msm-bus-bimc";
> +   reg = <0x40 0x62000>;
> +   #interconnect-cells = <1>;
> +   clock-names = "bus_clk", "bus_a_clk";
> +   clocks = < RPM_SMD_BIMC_CLK>, < 
> RPM_SMD_BIMC_A_CLK>;
> +   status = "okay";
> +   interconnect-port = < BIMC_SNOC_MAS>;
> +   };
> +   pnoc: pnoc@50 {
> +   compatible = "qcom,msm-bus-pnoc";
> +   reg = <0x50 0x11000>;
> +   #interconnect-cells = <1>;
> +   clock-names = "bus_clk", "bus_a_clk";
> +   clocks = < RPM_SMD_PCNOC_CLK>, < 
> RPM_SMD_PCNOC_A_CLK>;
> +   status = "okay";
> +   interconnect-port = < PNOC_SNOC_SLV>;
> +   };
> +
> += interconnect consumers =
> +
> +The interconnect consumers are device nodes which consume the interconnect
> +path(s) provided by the interconnect provider. There can be multiple
> +interconnect providers on a SoC and the consumer may consume multiple paths
> +from different providers depending on usecase and the components it has to
> +interact with.
> +
> +Required-properties:
> +interconnect-port : A phandle and interconnect provider specifier as defined 
> by
> +   bindings of the interconnect provider specified by phandle.
> +   This denotes the port to which the interconnect consumer is
> +   wired.
> +interconnect-path : List of phandles to the data path endpoints.

More copy/paste from February review:

"Path" means everything between the endpoints (e.g. the details of the
graph traversal), whereas this DT property is really only meant to
defint the target endpoint. Let's rename it to interconnect-target.

When referring to endpoints I think we should some pairing terminology
like: src,dst or local,remote or initiator,target.

So how about:
s/interconnect-port/interconnect-sources/
s/interconnect-path/interconnect-targets/

This keeps things symmetrical and the (source,target) pair just makes
sense. I used plural as well since there can be multiple ports.

It might even make sense to shorten it with: source-ports, target-ports

> +interconnect-path-names : List of interconnect path name strings sorted in 
> the
> +   same order as the interconnect-path property.  Consumers 
> drivers
> +   will use interconnect-path-names to match the link names with
> +   interconnect specifiers.

Let's not use string names. No reason to copy the clkdev-style of
resource lookups when an integer id will do just fine.

> +
> +Example:
> +
> +   sdhci@07864000 {
> +   ...
> +   interconnect-port = < MAS_PNOC_SDCC_2>;
> +   interconnect-path = <_uart2>;

interconnect-path 

Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API

[Michael Turquette]

Hi Georgi,

Quoting Georgi Djakov (2017-03-01 10:22:34)
> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt 
> b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> new file mode 100644
> index ..c62d86e4c52d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> @@ -0,0 +1,91 @@
> +Interconnect Provider Device Tree Bindings
> +=

I agree with Rob to skip the DT bindings for now. However I did review
this privately in February and I'll re-post my review comments here for
when the bindings do get discussed at a later date:

> +Optional properties:
> +interconnect-port : A phandle and interconnect provider specifier as defined 
> by
> +   bindings of the interconnect provider specified by phandle.
> +   This denotes the port to which the interconnect consumer is
> +   wired. It is used when there are multiple interconnect 
> providers
> +   that have one or multiple links between them.

Go ahead and remove the interconnect-port property description from the
provider part of the binding. It should be sufficient to say,
"interconnect providers can also be interconnect consumers, such as in
the case where two network-on-chip fabrics interface directly".

> +
> +Example:
> +
> +   snoc: snoc@058 {
> +   compatible = "qcom,msm-bus-snoc";
> +   reg = <0x58 0x14000>;
> +   #interconnect-cells = <1>;
> +   clock-names = "bus_clk", "bus_a_clk";
> +   clocks = < RPM_SMD_SNOC_CLK>, < 
> RPM_SMD_SNOC_A_CLK>;
> +   status = "okay";
> +   interconnect-port = < MAS_SNOC_CFG>,
> +   < SNOC_BIMC_0_MAS>,
> +   < SNOC_BIMC_1_MAS>,
> +   < SNOC_PNOC_SLV>;
> +   };
> +   bimc: bimc@040 {
> +   compatible = "qcom,msm-bus-bimc";
> +   reg = <0x40 0x62000>;
> +   #interconnect-cells = <1>;
> +   clock-names = "bus_clk", "bus_a_clk";
> +   clocks = < RPM_SMD_BIMC_CLK>, < 
> RPM_SMD_BIMC_A_CLK>;
> +   status = "okay";
> +   interconnect-port = < BIMC_SNOC_MAS>;
> +   };
> +   pnoc: pnoc@50 {
> +   compatible = "qcom,msm-bus-pnoc";
> +   reg = <0x50 0x11000>;
> +   #interconnect-cells = <1>;
> +   clock-names = "bus_clk", "bus_a_clk";
> +   clocks = < RPM_SMD_PCNOC_CLK>, < 
> RPM_SMD_PCNOC_A_CLK>;
> +   status = "okay";
> +   interconnect-port = < PNOC_SNOC_SLV>;
> +   };
> +
> += interconnect consumers =
> +
> +The interconnect consumers are device nodes which consume the interconnect
> +path(s) provided by the interconnect provider. There can be multiple
> +interconnect providers on a SoC and the consumer may consume multiple paths
> +from different providers depending on usecase and the components it has to
> +interact with.
> +
> +Required-properties:
> +interconnect-port : A phandle and interconnect provider specifier as defined 
> by
> +   bindings of the interconnect provider specified by phandle.
> +   This denotes the port to which the interconnect consumer is
> +   wired.
> +interconnect-path : List of phandles to the data path endpoints.

More copy/paste from February review:

"Path" means everything between the endpoints (e.g. the details of the
graph traversal), whereas this DT property is really only meant to
defint the target endpoint. Let's rename it to interconnect-target.

When referring to endpoints I think we should some pairing terminology
like: src,dst or local,remote or initiator,target.

So how about:
s/interconnect-port/interconnect-sources/
s/interconnect-path/interconnect-targets/

This keeps things symmetrical and the (source,target) pair just makes
sense. I used plural as well since there can be multiple ports.

It might even make sense to shorten it with: source-ports, target-ports

> +interconnect-path-names : List of interconnect path name strings sorted in 
> the
> +   same order as the interconnect-path property.  Consumers 
> drivers
> +   will use interconnect-path-names to match the link names with
> +   interconnect specifiers.

Let's not use string names. No reason to copy the clkdev-style of
resource lookups when an integer id will do just fine.

> +
> +Example:
> +
> +   sdhci@07864000 {
> +   ...
> +   interconnect-port = < MAS_PNOC_SDCC_2>;
> +   interconnect-path = <_uart2>;

interconnect-path 

Re: [PATCH 3/5] clk: meson-gxbb: Add GXL/GXM GP0 Variant

[Michael Turquette]

Hi Neil,

Quoting Neil Armstrong (2017-03-13 06:26:42)
> @@ -821,6 +893,7 @@ struct pll_params_table gxbb_gp0_params_table[] = {
> _hdmi_pll,
> _sys_pll,
> _gp0_pll,
> +   _gp0_pll,

Is there a reason for adding the pointer to this array here? It seems to
me that the gxbb_gp0_pll and gxl_gp0_pll are mutually exclusive, so
perhaps two different tables should be used?

>  };
>  
>  static struct meson_clk_mpll *const gxbb_clk_mplls[] = {
> @@ -923,6 +996,10 @@ static int gxbb_clkc_probe(struct platform_device *pdev)
> struct clk *parent_clk;
> struct device *dev = >dev;
>  
> +   /* Override GP0 clock for GXL/GXM */
> +   if (of_device_is_compatible(dev->of_node, "amlogic,gxl-clkc"))
> +   gxbb_hw_onecell_data.hws[CLKID_GP0_PLL] = _gp0_pll.hw;

Similarly, this above is a little ugly compared to dedicated tables for
each variant.

Regards,
Mike

> +
> /*  Generic clocks and PLLs */
> clk_base = of_iomap(dev->of_node, 0);
> if (!clk_base) {
> @@ -996,6 +1073,7 @@ static int gxbb_clkc_probe(struct platform_device *pdev)
>  
>  static const struct of_device_id gxbb_clkc_match_table[] = {
> { .compatible = "amlogic,gxbb-clkc" },
> +   { .compatible = "amlogic,gxl-clkc" },
> { }
>  };
>  
> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> index 8ee2022..7f99bf6 100644
> --- a/drivers/clk/meson/gxbb.h
> +++ b/drivers/clk/meson/gxbb.h
> @@ -71,6 +71,8 @@
>  #define HHI_GP0_PLL_CNTL2  0x44 /* 0x11 offset in data sheet */
>  #define HHI_GP0_PLL_CNTL3  0x48 /* 0x12 offset in data sheet */
>  #define HHI_GP0_PLL_CNTL4  0x4c /* 0x13 offset in data sheet */
> +#defineHHI_GP0_PLL_CNTL5   0x50 /* 0x14 offset in data 
> sheet */
> +#defineHHI_GP0_PLL_CNTL1   0x58 /* 0x16 offset in data 
> sheet */
>  
>  #define HHI_XTAL_DIVN_CNTL 0xbc /* 0x2f offset in data sheet */
>  #define HHI_TIMER90K   0xec /* 0x3b offset in data sheet */
> -- 
> 1.9.1
> 

Re: [PATCH 3/5] clk: meson-gxbb: Add GXL/GXM GP0 Variant

[Michael Turquette]

Hi Neil,

Quoting Neil Armstrong (2017-03-13 06:26:42)
> @@ -821,6 +893,7 @@ struct pll_params_table gxbb_gp0_params_table[] = {
> _hdmi_pll,
> _sys_pll,
> _gp0_pll,
> +   _gp0_pll,

Is there a reason for adding the pointer to this array here? It seems to
me that the gxbb_gp0_pll and gxl_gp0_pll are mutually exclusive, so
perhaps two different tables should be used?

>  };
>  
>  static struct meson_clk_mpll *const gxbb_clk_mplls[] = {
> @@ -923,6 +996,10 @@ static int gxbb_clkc_probe(struct platform_device *pdev)
> struct clk *parent_clk;
> struct device *dev = >dev;
>  
> +   /* Override GP0 clock for GXL/GXM */
> +   if (of_device_is_compatible(dev->of_node, "amlogic,gxl-clkc"))
> +   gxbb_hw_onecell_data.hws[CLKID_GP0_PLL] = _gp0_pll.hw;

Similarly, this above is a little ugly compared to dedicated tables for
each variant.

Regards,
Mike

> +
> /*  Generic clocks and PLLs */
> clk_base = of_iomap(dev->of_node, 0);
> if (!clk_base) {
> @@ -996,6 +1073,7 @@ static int gxbb_clkc_probe(struct platform_device *pdev)
>  
>  static const struct of_device_id gxbb_clkc_match_table[] = {
> { .compatible = "amlogic,gxbb-clkc" },
> +   { .compatible = "amlogic,gxl-clkc" },
> { }
>  };
>  
> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> index 8ee2022..7f99bf6 100644
> --- a/drivers/clk/meson/gxbb.h
> +++ b/drivers/clk/meson/gxbb.h
> @@ -71,6 +71,8 @@
>  #define HHI_GP0_PLL_CNTL2  0x44 /* 0x11 offset in data sheet */
>  #define HHI_GP0_PLL_CNTL3  0x48 /* 0x12 offset in data sheet */
>  #define HHI_GP0_PLL_CNTL4  0x4c /* 0x13 offset in data sheet */
> +#defineHHI_GP0_PLL_CNTL5   0x50 /* 0x14 offset in data 
> sheet */
> +#defineHHI_GP0_PLL_CNTL1   0x58 /* 0x16 offset in data 
> sheet */
>  
>  #define HHI_XTAL_DIVN_CNTL 0xbc /* 0x2f offset in data sheet */
>  #define HHI_TIMER90K   0xec /* 0x3b offset in data sheet */
> -- 
> 1.9.1
> 

Re: [PATCH 1/5] clk: meson: Add support for parameters for specific PLLs

[Michael Turquette]

Quoting Neil Armstrong (2017-03-13 06:26:40)
> In recent Amlogic GXBB, GXL and GXM SoCs, the GP0 PLL needs some specific
> parameters in order to initialize and lock correctly.
> 
> This patch adds an optional PARAM table used to initialize the PLL to a
> default value with it's parameters in order to achieve to desired frequency.
> 
> The GP0 PLL in GXBB, GXL/GXM also needs some tweaks in the initialization
> steps, and these are exposed along the PARAM table.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/clk/meson/clk-pll.c | 52 
> +++--
>  drivers/clk/meson/clkc.h| 23 
>  2 files changed, 73 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> index 4adc1e8..aff223b 100644
> --- a/drivers/clk/meson/clk-pll.c
> +++ b/drivers/clk/meson/clk-pll.c
> @@ -116,6 +116,29 @@ static const struct pll_rate_table 
> *meson_clk_get_pll_settings(struct meson_clk_
> return NULL;
>  }
>  
> +/* Specific wait loop for GXL/GXM GP0 PLL */
> +static int meson_clk_pll_wait_lock_reset(struct meson_clk_pll *pll,
> +struct parm *p_n)
> +{
> +   int delay = 100;
> +   u32 reg;
> +
> +   while (delay > 0) {
> +   reg = readl(pll->base + p_n->reg_off);
> +   writel(reg | MESON_PLL_RESET, pll->base + p_n->reg_off);
> +   udelay(10);
> +   writel(reg & ~MESON_PLL_RESET, pll->base + p_n->reg_off);
> +
> +   mdelay(1);

Can you add a comment explaining where the delay values come from? Can
they vary from chip to chip?

> +
> +   reg = readl(pll->base + p_n->reg_off);
> +   if (reg & MESON_PLL_LOCK)
> +   return 0;
> +   delay--;
> +   }
> +   return -ETIMEDOUT;
> +}
> +
>  static int meson_clk_pll_wait_lock(struct meson_clk_pll *pll,
>struct parm *p_n)
>  {
> @@ -132,6 +155,15 @@ static int meson_clk_pll_wait_lock(struct meson_clk_pll 
> *pll,
> return -ETIMEDOUT;
>  }
>  
> +static void meson_clk_pll_init_params(struct meson_clk_pll *pll)
> +{
> +   int i;
> +
> +   for (i = 0 ; i < pll->params.params_count ; ++i)
> +   writel(pll->params.params_table[i].value,
> +  pll->base + pll->params.params_table[i].reg_off);
> +}
> +
>  static int meson_clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
>   unsigned long parent_rate)
>  {
> @@ -151,10 +183,16 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> if (!rate_set)
> return -EINVAL;
>  
> +   /* Initialize the PLL in a clean state if specified */
> +   if (pll->params.params_count)
> +   meson_clk_pll_init_params(pll);
> +
> /* PLL reset */
> p = >n;
> reg = readl(pll->base + p->reg_off);
> -   writel(reg | MESON_PLL_RESET, pll->base + p->reg_off);
> +   /* If no_init_reset is provided, avoid resetting at this point */
> +   if (!pll->params.no_init_reset)
> +   writel(reg | MESON_PLL_RESET, pll->base + p->reg_off);
>  
> reg = PARM_SET(p->width, p->shift, reg, rate_set->n);
> writel(reg, pll->base + p->reg_off);
> @@ -184,7 +222,17 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> }
>  
> p = >n;
> -   ret = meson_clk_pll_wait_lock(pll, p);
> +   /* If unreset_for_lock is provided, remove the reset bit here */
> +   if (pll->params.unreset_for_lock) {

Small nitpick, but I find "unreset" to be confusing. Since 'reset' here
is a bit that can be set and unset, maybe use clear_reset_for_lock
instead?

Regards,
Mike

> +   reg = readl(pll->base + p->reg_off);
> +   writel(reg & ~MESON_PLL_RESET, pll->base + p->reg_off);
> +   }
> +
> +   /* If reset_lock_loop, use a special loop including resetting */
> +   if (pll->params.reset_lock_loop)
> +   ret = meson_clk_pll_wait_lock_reset(pll, p);
> +   else
> +   ret = meson_clk_pll_wait_lock(pll, p);
> if (ret) {
> pr_warn("%s: pll did not lock, trying to restore old rate 
> %lu\n",
> __func__, old_rate);
> diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
> index 9bb70e7..5f1c12d 100644
> --- a/drivers/clk/meson/clkc.h
> +++ b/drivers/clk/meson/clkc.h
> @@ -62,6 +62,28 @@ struct pll_rate_table {
> .frac   = (_frac),  \
> }   \
>  
> +struct pll_params_table {
> +   unsigned int reg_off;
> +   unsigned int value;
> +};
> +
> +#define PLL_PARAM(_reg, _val)  \
> +   { 

Re: [PATCH 1/5] clk: meson: Add support for parameters for specific PLLs

[Michael Turquette]

Quoting Neil Armstrong (2017-03-13 06:26:40)
> In recent Amlogic GXBB, GXL and GXM SoCs, the GP0 PLL needs some specific
> parameters in order to initialize and lock correctly.
> 
> This patch adds an optional PARAM table used to initialize the PLL to a
> default value with it's parameters in order to achieve to desired frequency.
> 
> The GP0 PLL in GXBB, GXL/GXM also needs some tweaks in the initialization
> steps, and these are exposed along the PARAM table.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/clk/meson/clk-pll.c | 52 
> +++--
>  drivers/clk/meson/clkc.h| 23 
>  2 files changed, 73 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> index 4adc1e8..aff223b 100644
> --- a/drivers/clk/meson/clk-pll.c
> +++ b/drivers/clk/meson/clk-pll.c
> @@ -116,6 +116,29 @@ static const struct pll_rate_table 
> *meson_clk_get_pll_settings(struct meson_clk_
> return NULL;
>  }
>  
> +/* Specific wait loop for GXL/GXM GP0 PLL */
> +static int meson_clk_pll_wait_lock_reset(struct meson_clk_pll *pll,
> +struct parm *p_n)
> +{
> +   int delay = 100;
> +   u32 reg;
> +
> +   while (delay > 0) {
> +   reg = readl(pll->base + p_n->reg_off);
> +   writel(reg | MESON_PLL_RESET, pll->base + p_n->reg_off);
> +   udelay(10);
> +   writel(reg & ~MESON_PLL_RESET, pll->base + p_n->reg_off);
> +
> +   mdelay(1);

Can you add a comment explaining where the delay values come from? Can
they vary from chip to chip?

> +
> +   reg = readl(pll->base + p_n->reg_off);
> +   if (reg & MESON_PLL_LOCK)
> +   return 0;
> +   delay--;
> +   }
> +   return -ETIMEDOUT;
> +}
> +
>  static int meson_clk_pll_wait_lock(struct meson_clk_pll *pll,
>struct parm *p_n)
>  {
> @@ -132,6 +155,15 @@ static int meson_clk_pll_wait_lock(struct meson_clk_pll 
> *pll,
> return -ETIMEDOUT;
>  }
>  
> +static void meson_clk_pll_init_params(struct meson_clk_pll *pll)
> +{
> +   int i;
> +
> +   for (i = 0 ; i < pll->params.params_count ; ++i)
> +   writel(pll->params.params_table[i].value,
> +  pll->base + pll->params.params_table[i].reg_off);
> +}
> +
>  static int meson_clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
>   unsigned long parent_rate)
>  {
> @@ -151,10 +183,16 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> if (!rate_set)
> return -EINVAL;
>  
> +   /* Initialize the PLL in a clean state if specified */
> +   if (pll->params.params_count)
> +   meson_clk_pll_init_params(pll);
> +
> /* PLL reset */
> p = >n;
> reg = readl(pll->base + p->reg_off);
> -   writel(reg | MESON_PLL_RESET, pll->base + p->reg_off);
> +   /* If no_init_reset is provided, avoid resetting at this point */
> +   if (!pll->params.no_init_reset)
> +   writel(reg | MESON_PLL_RESET, pll->base + p->reg_off);
>  
> reg = PARM_SET(p->width, p->shift, reg, rate_set->n);
> writel(reg, pll->base + p->reg_off);
> @@ -184,7 +222,17 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> }
>  
> p = >n;
> -   ret = meson_clk_pll_wait_lock(pll, p);
> +   /* If unreset_for_lock is provided, remove the reset bit here */
> +   if (pll->params.unreset_for_lock) {

Small nitpick, but I find "unreset" to be confusing. Since 'reset' here
is a bit that can be set and unset, maybe use clear_reset_for_lock
instead?

Regards,
Mike

> +   reg = readl(pll->base + p->reg_off);
> +   writel(reg & ~MESON_PLL_RESET, pll->base + p->reg_off);
> +   }
> +
> +   /* If reset_lock_loop, use a special loop including resetting */
> +   if (pll->params.reset_lock_loop)
> +   ret = meson_clk_pll_wait_lock_reset(pll, p);
> +   else
> +   ret = meson_clk_pll_wait_lock(pll, p);
> if (ret) {
> pr_warn("%s: pll did not lock, trying to restore old rate 
> %lu\n",
> __func__, old_rate);
> diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
> index 9bb70e7..5f1c12d 100644
> --- a/drivers/clk/meson/clkc.h
> +++ b/drivers/clk/meson/clkc.h
> @@ -62,6 +62,28 @@ struct pll_rate_table {
> .frac   = (_frac),  \
> }   \
>  
> +struct pll_params_table {
> +   unsigned int reg_off;
> +   unsigned int value;
> +};
> +
> +#define PLL_PARAM(_reg, _val)  \
> +   {   \
> +  

Re: [PATCH v2 6/9] clk: meson: gxbb: mpll: use rw operation

[Michael Turquette]

Quoting Jerome Brunet (2017-03-09 02:41:51)
> Use read/write operations for the mpll clocks instead of the
> read-only ones.
> 
> Signed-off-by: Jerome Brunet 

Looks good to me.

Regards,
Mike

> ---
>  drivers/clk/meson/gxbb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 79fb8989f8dd..5059c7bbdbb3 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -459,7 +459,7 @@ static struct meson_clk_mpll gxbb_mpll0 = {
> .lock = _lock,
> .hw.init = &(struct clk_init_data){
> .name = "mpll0",
> -   .ops = _clk_mpll_ro_ops,
> +   .ops = _clk_mpll_ops,
> .parent_names = (const char *[]){ "fixed_pll" },
> .num_parents = 1,
> },
> @@ -489,7 +489,7 @@ static struct meson_clk_mpll gxbb_mpll1 = {
> .lock = _lock,
> .hw.init = &(struct clk_init_data){
> .name = "mpll1",
> -   .ops = _clk_mpll_ro_ops,
> +   .ops = _clk_mpll_ops,
> .parent_names = (const char *[]){ "fixed_pll" },
> .num_parents = 1,
> },
> @@ -519,7 +519,7 @@ static struct meson_clk_mpll gxbb_mpll2 = {
> .lock = _lock,
> .hw.init = &(struct clk_init_data){
> .name = "mpll2",
> -   .ops = _clk_mpll_ro_ops,
> +   .ops = _clk_mpll_ops,
> .parent_names = (const char *[]){ "fixed_pll" },
> .num_parents = 1,
> },
> -- 
> 2.9.3
> 

Re: [PATCH v2 6/9] clk: meson: gxbb: mpll: use rw operation

[Michael Turquette]

Quoting Jerome Brunet (2017-03-09 02:41:51)
> Use read/write operations for the mpll clocks instead of the
> read-only ones.
> 
> Signed-off-by: Jerome Brunet 

Looks good to me.

Regards,
Mike

> ---
>  drivers/clk/meson/gxbb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 79fb8989f8dd..5059c7bbdbb3 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -459,7 +459,7 @@ static struct meson_clk_mpll gxbb_mpll0 = {
> .lock = _lock,
> .hw.init = &(struct clk_init_data){
> .name = "mpll0",
> -   .ops = _clk_mpll_ro_ops,
> +   .ops = _clk_mpll_ops,
> .parent_names = (const char *[]){ "fixed_pll" },
> .num_parents = 1,
> },
> @@ -489,7 +489,7 @@ static struct meson_clk_mpll gxbb_mpll1 = {
> .lock = _lock,
> .hw.init = &(struct clk_init_data){
> .name = "mpll1",
> -   .ops = _clk_mpll_ro_ops,
> +   .ops = _clk_mpll_ops,
> .parent_names = (const char *[]){ "fixed_pll" },
> .num_parents = 1,
> },
> @@ -519,7 +519,7 @@ static struct meson_clk_mpll gxbb_mpll2 = {
> .lock = _lock,
> .hw.init = &(struct clk_init_data){
> .name = "mpll2",
> -   .ops = _clk_mpll_ro_ops,
> +   .ops = _clk_mpll_ops,
> .parent_names = (const char *[]){ "fixed_pll" },
> .num_parents = 1,
> },
> -- 
> 2.9.3
> 

Re: [PATCH v3 2/3] clk: meson-gxbb: Add MALI clocks

[Michael Turquette]

Hi Neil,

Quoting Neil Armstrong (2017-03-09 04:53:46)
> The Mali is clocked by two identical clock paths behind a glitch free mux
> to safely change frequency while running.
> 
> The two "mali_0" and "mali_1" clocks are composed of a mux, divider and gate.
> Expose these two clocks trees using generic clocks.
> Finally the glitch free mux is added as "mali" clock.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/clk/meson/gxbb.c | 139 
> +++
>  1 file changed, 139 insertions(+)
> 
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 5059c7b..d9f7fef 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -634,6 +634,131 @@
> },
>  };
>  
> +/*
> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
> + * muxed by a glitch-free switch.
> + */
> +
> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> +static const char *gxbb_mali_0_1_parent_names[] = {
> +   "xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> +   "fclk_div4", "fclk_div3", "fclk_div5"
> +};
> +
> +static struct clk_mux gxbb_mali_0_sel = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .mask = 0x7,
> +   .shift = 9,
> +   .table = mux_table_mali_0_1,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_0_sel",
> +   .ops = _mux_ops,
> +   /*
> +* bits 10:9 selects from 8 possible parents:
> +* xtal, gp0_pll, mpll2, mpll1, fclk_div7,
> +* fclk_div4, fclk_div3, fclk_div5
> +*/
> +   .parent_names = gxbb_mali_0_1_parent_names,
> +   .num_parents = 8,
> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),

Are all of these CLK_IGNORE_UNUSED flags necessary? If so, why? I'm just
wondering if this is yet another display-related use case where a
hand-off mechanism would work better?

Thanks,
Mike

> +   },
> +};
> +
> +static struct clk_divider gxbb_mali_0_div = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .shift = 0,
> +   .width = 7,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_0_div",
> +   .ops = _divider_ops,
> +   .parent_names = (const char *[]){ "mali_0_sel" },
> +   .num_parents = 1,
> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static struct clk_gate gxbb_mali_0 = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .bit_idx = 8,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_0",
> +   .ops = _gate_ops,
> +   .parent_names = (const char *[]){ "mali_0_div" },
> +   .num_parents = 1,
> +   .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static struct clk_mux gxbb_mali_1_sel = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .mask = 0x7,
> +   .shift = 25,
> +   .table = mux_table_mali_0_1,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_1_sel",
> +   .ops = _mux_ops,
> +   /*
> +* bits 10:9 selects from 8 possible parents:
> +* xtal, gp0_pll, mpll2, mpll1, fclk_div7,
> +* fclk_div4, fclk_div3, fclk_div5
> +*/
> +   .parent_names = gxbb_mali_0_1_parent_names,
> +   .num_parents = 8,
> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static struct clk_divider gxbb_mali_1_div = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .shift = 16,
> +   .width = 7,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_1_div",
> +   .ops = _divider_ops,
> +   .parent_names = (const char *[]){ "mali_1_sel" },
> +   .num_parents = 1,
> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static struct clk_gate gxbb_mali_1 = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .bit_idx = 24,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_1",
> +   .ops = _gate_ops,
> +   .parent_names = (const char *[]){ "mali_1_div" },
> +   .num_parents = 1,
> +   .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static u32 mux_table_mali[] = {0, 1};
> +static const char *gxbb_mali_parent_names[] = {
> +   "mali_0", "mali_1"
> +};
> +
> +static struct clk_mux gxbb_mali = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .mask = 1,
> +   .shift = 31,
> +   .table = mux_table_mali,
> +   .lock = _lock,

Re: [PATCH v3 2/3] clk: meson-gxbb: Add MALI clocks

[Michael Turquette]

Hi Neil,

Quoting Neil Armstrong (2017-03-09 04:53:46)
> The Mali is clocked by two identical clock paths behind a glitch free mux
> to safely change frequency while running.
> 
> The two "mali_0" and "mali_1" clocks are composed of a mux, divider and gate.
> Expose these two clocks trees using generic clocks.
> Finally the glitch free mux is added as "mali" clock.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/clk/meson/gxbb.c | 139 
> +++
>  1 file changed, 139 insertions(+)
> 
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 5059c7b..d9f7fef 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -634,6 +634,131 @@
> },
>  };
>  
> +/*
> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
> + * muxed by a glitch-free switch.
> + */
> +
> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> +static const char *gxbb_mali_0_1_parent_names[] = {
> +   "xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> +   "fclk_div4", "fclk_div3", "fclk_div5"
> +};
> +
> +static struct clk_mux gxbb_mali_0_sel = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .mask = 0x7,
> +   .shift = 9,
> +   .table = mux_table_mali_0_1,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_0_sel",
> +   .ops = _mux_ops,
> +   /*
> +* bits 10:9 selects from 8 possible parents:
> +* xtal, gp0_pll, mpll2, mpll1, fclk_div7,
> +* fclk_div4, fclk_div3, fclk_div5
> +*/
> +   .parent_names = gxbb_mali_0_1_parent_names,
> +   .num_parents = 8,
> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),

Are all of these CLK_IGNORE_UNUSED flags necessary? If so, why? I'm just
wondering if this is yet another display-related use case where a
hand-off mechanism would work better?

Thanks,
Mike

> +   },
> +};
> +
> +static struct clk_divider gxbb_mali_0_div = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .shift = 0,
> +   .width = 7,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_0_div",
> +   .ops = _divider_ops,
> +   .parent_names = (const char *[]){ "mali_0_sel" },
> +   .num_parents = 1,
> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static struct clk_gate gxbb_mali_0 = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .bit_idx = 8,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_0",
> +   .ops = _gate_ops,
> +   .parent_names = (const char *[]){ "mali_0_div" },
> +   .num_parents = 1,
> +   .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static struct clk_mux gxbb_mali_1_sel = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .mask = 0x7,
> +   .shift = 25,
> +   .table = mux_table_mali_0_1,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_1_sel",
> +   .ops = _mux_ops,
> +   /*
> +* bits 10:9 selects from 8 possible parents:
> +* xtal, gp0_pll, mpll2, mpll1, fclk_div7,
> +* fclk_div4, fclk_div3, fclk_div5
> +*/
> +   .parent_names = gxbb_mali_0_1_parent_names,
> +   .num_parents = 8,
> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static struct clk_divider gxbb_mali_1_div = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .shift = 16,
> +   .width = 7,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_1_div",
> +   .ops = _divider_ops,
> +   .parent_names = (const char *[]){ "mali_1_sel" },
> +   .num_parents = 1,
> +   .flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static struct clk_gate gxbb_mali_1 = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .bit_idx = 24,
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mali_1",
> +   .ops = _gate_ops,
> +   .parent_names = (const char *[]){ "mali_1_div" },
> +   .num_parents = 1,
> +   .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> +   },
> +};
> +
> +static u32 mux_table_mali[] = {0, 1};
> +static const char *gxbb_mali_parent_names[] = {
> +   "mali_0", "mali_1"
> +};
> +
> +static struct clk_mux gxbb_mali = {
> +   .reg = (void *)HHI_MALI_CLK_CNTL,
> +   .mask = 1,
> +   .shift = 31,
> +   .table = mux_table_mali,
> +   .lock = _lock,
> +   .hw.init = 

Re: [PATCH v2 7/9] clk: meson8b: add the mplls clocks 0, 1 and 2

[Michael Turquette]

Quoting Jerome Brunet (2017-03-09 02:41:52)
> Signed-off-by: Jerome Brunet 

Hmm, even for obvious patches like this it is still better to have some
sort of changelog :-/

Otherwise patch appears fine to me.

Regards,
Mike

> ---
>  drivers/clk/meson/meson8b.c | 103 
> 
>  drivers/clk/meson/meson8b.h |  20 -
>  2 files changed, 122 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
> index 2937443d4505..e9985503165c 100644
> --- a/drivers/clk/meson/meson8b.c
> +++ b/drivers/clk/meson/meson8b.c
> @@ -245,6 +245,96 @@ static struct clk_fixed_factor meson8b_fclk_div7 = {
> },
>  };
>  
> +static struct meson_clk_mpll meson8b_mpll0 = {
> +   .sdm = {
> +   .reg_off = HHI_MPLL_CNTL7,
> +   .shift   = 0,
> +   .width   = 14,
> +   },
> +   .sdm_en = {
> +   .reg_off = HHI_MPLL_CNTL7,
> +   .shift   = 15,
> +   .width   = 1,
> +   },
> +   .n2 = {
> +   .reg_off = HHI_MPLL_CNTL7,
> +   .shift   = 16,
> +   .width   = 9,
> +   },
> +   .en = {
> +   .reg_off = HHI_MPLL_CNTL7,
> +   .shift   = 14,
> +   .width   = 1,
> +   },
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mpll0",
> +   .ops = _clk_mpll_ops,
> +   .parent_names = (const char *[]){ "fixed_pll" },
> +   .num_parents = 1,
> +   },
> +};
> +
> +static struct meson_clk_mpll meson8b_mpll1 = {
> +   .sdm = {
> +   .reg_off = HHI_MPLL_CNTL8,
> +   .shift   = 0,
> +   .width   = 14,
> +   },
> +   .sdm_en = {
> +   .reg_off = HHI_MPLL_CNTL8,
> +   .shift   = 15,
> +   .width   = 1,
> +   },
> +   .n2 = {
> +   .reg_off = HHI_MPLL_CNTL8,
> +   .shift   = 16,
> +   .width   = 9,
> +   },
> +   .en = {
> +   .reg_off = HHI_MPLL_CNTL8,
> +   .shift   = 14,
> +   .width   = 1,
> +   },
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mpll1",
> +   .ops = _clk_mpll_ops,
> +   .parent_names = (const char *[]){ "fixed_pll" },
> +   .num_parents = 1,
> +   },
> +};
> +
> +static struct meson_clk_mpll meson8b_mpll2 = {
> +   .sdm = {
> +   .reg_off = HHI_MPLL_CNTL9,
> +   .shift   = 0,
> +   .width   = 14,
> +   },
> +   .sdm_en = {
> +   .reg_off = HHI_MPLL_CNTL9,
> +   .shift   = 15,
> +   .width   = 1,
> +   },
> +   .n2 = {
> +   .reg_off = HHI_MPLL_CNTL9,
> +   .shift   = 16,
> +   .width   = 9,
> +   },
> +   .en = {
> +   .reg_off = HHI_MPLL_CNTL9,
> +   .shift   = 14,
> +   .width   = 1,
> +   },
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mpll2",
> +   .ops = _clk_mpll_ops,
> +   .parent_names = (const char *[]){ "fixed_pll" },
> +   .num_parents = 1,
> +   },
> +};
> +
>  /*
>   * FIXME cpu clocks and the legacy composite clocks (e.g. clk81) are both PLL
>   * post-dividers and should be modeled with their respective PLLs via the
> @@ -491,6 +581,9 @@ static struct clk_hw_onecell_data meson8b_hw_onecell_data 
> = {
> [CLKID_AO_AHB_SRAM] = _ao_ahb_sram.hw,
> [CLKID_AO_AHB_BUS]  = _ao_ahb_bus.hw,
> [CLKID_AO_IFACE]= _ao_iface.hw,
> +   [CLKID_MPLL0]   = _mpll0.hw,
> +   [CLKID_MPLL1]   = _mpll1.hw,
> +   [CLKID_MPLL2]   = _mpll2.hw,
> },
> .num = CLK_NR_CLKS,
>  };
> @@ -501,6 +594,12 @@ static struct meson_clk_pll *const meson8b_clk_plls[] = {
> _sys_pll,
>  };
>  
> +static struct meson_clk_mpll *const meson8b_clk_mplls[] = {
> +   _mpll0,
> +   _mpll1,
> +   _mpll2,
> +};
> +
>  static struct clk_gate *const meson8b_clk_gates[] = {
> _clk81,
> _ddr,
> @@ -609,6 +708,10 @@ static int meson8b_clkc_probe(struct platform_device 
> *pdev)
> for (i = 0; i < ARRAY_SIZE(meson8b_clk_plls); i++)
> meson8b_clk_plls[i]->base = clk_base;
>  
> +   /* Populate base address for MPLLs */
> +   for (i = 0; i < ARRAY_SIZE(meson8b_clk_mplls); i++)
> +   meson8b_clk_mplls[i]->base = clk_base;
> +
> /* Populate the base address for CPU clk */
> meson8b_cpu_clk.base = clk_base;
>  
> diff --git a/drivers/clk/meson/meson8b.h b/drivers/clk/meson/meson8b.h
> index 010e9582888d..3881defc8644 100644
> --- 

Re: [PATCH v2 3/9] clk: meson8b: put dividers and muxes in tables

[Michael Turquette]

Quoting Jerome Brunet (2017-03-09 02:41:48)
> Until now, there was only 1 divider and 1 mux declared for the meson8b
> platform. With the ongoing work on various system, including audio, this
> is about to change. Use the same approach as gates for dividers and muxes,
> putting them in tables to fix the register address at runtime.
> 
> Signed-off-by: Jerome Brunet 

Looks good to me.

Regards,
Mike

> ---
>  drivers/clk/meson/meson8b.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
> index d1cc4d7cc8ff..2937443d4505 100644
> --- a/drivers/clk/meson/meson8b.c
> +++ b/drivers/clk/meson/meson8b.c
> @@ -582,6 +582,14 @@ static struct clk_gate *const meson8b_clk_gates[] = {
> _ao_iface,
>  };
>  
> +static struct clk_mux *const meson8b_clk_muxes[] = {
> +   _mpeg_clk_sel,
> +};
> +
> +static struct clk_divider *const meson8b_clk_dividers[] = {
> +   _mpeg_clk_div,
> +};
> +
>  static int meson8b_clkc_probe(struct platform_device *pdev)
>  {
> void __iomem *clk_base;
> @@ -604,15 +612,21 @@ static int meson8b_clkc_probe(struct platform_device 
> *pdev)
> /* Populate the base address for CPU clk */
> meson8b_cpu_clk.base = clk_base;
>  
> -   /* Populate the base address for the MPEG clks */
> -   meson8b_mpeg_clk_sel.reg = clk_base + (u32)meson8b_mpeg_clk_sel.reg;
> -   meson8b_mpeg_clk_div.reg = clk_base + (u32)meson8b_mpeg_clk_div.reg;
> -
> /* Populate base address for gates */
> for (i = 0; i < ARRAY_SIZE(meson8b_clk_gates); i++)
> meson8b_clk_gates[i]->reg = clk_base +
> (u32)meson8b_clk_gates[i]->reg;
>  
> +   /* Populate base address for muxes */
> +   for (i = 0; i < ARRAY_SIZE(meson8b_clk_muxes); i++)
> +   meson8b_clk_muxes[i]->reg = clk_base +
> +   (u32)meson8b_clk_muxes[i]->reg;
> +
> +   /* Populate base address for dividers */
> +   for (i = 0; i < ARRAY_SIZE(meson8b_clk_dividers); i++)
> +   meson8b_clk_dividers[i]->reg = clk_base +
> +   (u32)meson8b_clk_dividers[i]->reg;
> +
> /*
>  * register all clks
>  * CLKID_UNUSED = 0, so skip it and start with CLKID_XTAL = 1
> -- 
> 2.9.3
> 

Re: [PATCH v2 5/9] clk: meson: mpll: add rw operation

[Michael Turquette]

Quoting Jerome Brunet (2017-03-09 02:41:50)
> This patch adds new callbacks to the meson-mpll driver to control
> and set the pll rate. For this, we also need to add the enable bit and
> sdm enable bit. The corresponding parameters are added to mpll data
> structure.
> 
> Signed-off-by: Jerome Brunet 

Patch looks good to me. I'm really happy to see the mpll's get sorted
out finally!

Regards,
Mike

> ---
>  drivers/clk/meson/clk-mpll.c | 152 
> +--
>  drivers/clk/meson/clkc.h |   4 +-
>  drivers/clk/meson/gxbb.c |  30 +
>  3 files changed, 180 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/clk/meson/clk-mpll.c b/drivers/clk/meson/clk-mpll.c
> index 03af79005ddb..342b85d4e22a 100644
> --- a/drivers/clk/meson/clk-mpll.c
> +++ b/drivers/clk/meson/clk-mpll.c
> @@ -64,16 +64,50 @@
>  #include 
>  #include "clkc.h"
>  
> -#define SDM_MAX 16384
> +#define SDM_DEN 16384
> +#define SDM_MIN 1
> +#define SDM_MAX 16383
> +#define N2_MIN 4
> +#define N2_MAX 127
>  
>  #define to_meson_clk_mpll(_hw) container_of(_hw, struct meson_clk_mpll, hw)
>  
> +static unsigned long rate_from_params(unsigned long parent_rate,
> + unsigned long sdm,
> + unsigned long n2)
> +{
> +   return (parent_rate * SDM_DEN) / ((SDM_DEN * n2) + sdm);
> +}
> +
> +static void params_from_rate(unsigned long requested_rate,
> +unsigned long parent_rate,
> +unsigned long *sdm,
> +unsigned long *n2)
> +{
> +   uint64_t div = parent_rate;
> +   unsigned long rem = do_div(div, requested_rate);
> +
> +   if (div < N2_MIN) {
> +   *n2 = N2_MIN;
> +   *sdm = SDM_MIN;
> +   } else if (div > N2_MAX) {
> +   *n2 = N2_MAX;
> +   *sdm = SDM_MAX;
> +   } else {
> +   *n2 = div;
> +   *sdm = DIV_ROUND_UP(rem * SDM_DEN, requested_rate);
> +   if (*sdm < SDM_MIN)
> +   *sdm = SDM_MIN;
> +   else if (*sdm > SDM_MAX)
> +   *sdm = SDM_MAX;
> +   }
> +}
> +
>  static unsigned long mpll_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
>  {
> struct meson_clk_mpll *mpll = to_meson_clk_mpll(hw);
> struct parm *p;
> -   unsigned long rate = 0;
> unsigned long reg, sdm, n2;
>  
> p = >sdm;
> @@ -84,11 +118,119 @@ static unsigned long mpll_recalc_rate(struct clk_hw *hw,
> reg = readl(mpll->base + p->reg_off);
> n2 = PARM_GET(p->width, p->shift, reg);
>  
> -   rate = (parent_rate * SDM_MAX) / ((SDM_MAX * n2) + sdm);
> +   return rate_from_params(parent_rate, sdm, n2);
> +}
> +
> +static long mpll_round_rate(struct clk_hw *hw,
> +   unsigned long rate,
> +   unsigned long *parent_rate)
> +{
> +   unsigned long sdm, n2;
> +
> +   params_from_rate(rate, *parent_rate, , );
> +   return rate_from_params(*parent_rate, sdm, n2);
> +}
> +
> +static int mpll_set_rate(struct clk_hw *hw,
> +unsigned long rate,
> +unsigned long parent_rate)
> +{
> +   struct meson_clk_mpll *mpll = to_meson_clk_mpll(hw);
> +   struct parm *p;
> +   unsigned long reg, sdm, n2;
> +   unsigned long flags = 0;
> +
> +   params_from_rate(rate, parent_rate, , );
> +
> +   if (mpll->lock)
> +   spin_lock_irqsave(mpll->lock, flags);
> +   else
> +   __acquire(mpll->lock);
> +
> +   p = >sdm;
> +   reg = readl(mpll->base + p->reg_off);
> +   reg = PARM_SET(p->width, p->shift, reg, sdm);
> +   writel(reg, mpll->base + p->reg_off);
> +
> +   p = >sdm_en;
> +   reg = readl(mpll->base + p->reg_off);
> +   reg = PARM_SET(p->width, p->shift, reg, 1);
> +   writel(reg, mpll->base + p->reg_off);
> +
> +   p = >n2;
> +   reg = readl(mpll->base + p->reg_off);
> +   reg = PARM_SET(p->width, p->shift, reg, n2);
> +   writel(reg, mpll->base + p->reg_off);
> +
> +   if (mpll->lock)
> +   spin_unlock_irqrestore(mpll->lock, flags);
> +   else
> +   __release(mpll->lock);
>  
> -   return rate;
> +   return 0;
> +}
> +
> +static void mpll_enable_core(struct clk_hw *hw, int enable)
> +{
> +   struct meson_clk_mpll *mpll = to_meson_clk_mpll(hw);
> +   struct parm *p;
> +   unsigned long reg;
> +   unsigned long flags = 0;
> +
> +   if (mpll->lock)
> +   spin_lock_irqsave(mpll->lock, flags);
> +   else
> +   __acquire(mpll->lock);
> +
> +   p = >en;
> +   reg = readl(mpll->base + p->reg_off);
> +   reg = PARM_SET(p->width, p->shift, reg, enable ? 1 : 0);
> +   writel(reg, mpll->base + p->reg_off);
> +
> +   if (mpll->lock)
> +   

Re: [PATCH v3 1/3] clk: meson-gxbb: Add MALI clock IDS

[Michael Turquette]

Quoting Neil Armstrong (2017-03-09 04:53:45)
> Add missing MALI clock IDs and expose the muxes and gates in the dt-bindings.
> 
> Signed-off-by: Neil Armstrong 

Looks good to me.

Regards,
Mike

> ---
>  drivers/clk/meson/gxbb.h  | 9 -
>  include/dt-bindings/clock/gxbb-clkc.h | 5 +
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> index 274f587..73efdc3 100644
> --- a/drivers/clk/meson/gxbb.h
> +++ b/drivers/clk/meson/gxbb.h
> @@ -268,8 +268,15 @@
>  /* CLKID_SAR_ADC_CLK */
>  /* CLKID_SAR_ADC_SEL */
>  #define CLKID_SAR_ADC_DIV99
> +/* CLKID_MALI_0_SEL */
> +#define CLKID_MALI_0_DIV101
> +/* CLKID_MALI_0*/
> +/* CLKID_MALI_1_SEL */
> +#define CLKID_MALI_1_DIV104
> +/* CLKID_MALI_1*/
> +/* CLKID_MALI  */
>  
> -#define NR_CLKS  100
> +#define NR_CLKS  107
>  
>  /* include the CLKIDs that have been made part of the stable DT binding */
>  #include 
> diff --git a/include/dt-bindings/clock/gxbb-clkc.h 
> b/include/dt-bindings/clock/gxbb-clkc.h
> index f08f06d..ef7d6b7 100644
> --- a/include/dt-bindings/clock/gxbb-clkc.h
> +++ b/include/dt-bindings/clock/gxbb-clkc.h
> @@ -35,5 +35,10 @@
>  #define CLKID_SD_EMMC_C96
>  #define CLKID_SAR_ADC_CLK  97
>  #define CLKID_SAR_ADC_SEL  98
> +#define CLKID_MALI_0_SEL   100
> +#define CLKID_MALI_0   102
> +#define CLKID_MALI_1_SEL   103
> +#define CLKID_MALI_1   105
> +#define CLKID_MALI 106
>  
>  #endif /* __GXBB_CLKC_H */
> -- 
> 1.9.1
> 

Re: [PATCH v2 7/9] clk: meson8b: add the mplls clocks 0, 1 and 2

[Michael Turquette]

Quoting Jerome Brunet (2017-03-09 02:41:52)
> Signed-off-by: Jerome Brunet 

Hmm, even for obvious patches like this it is still better to have some
sort of changelog :-/

Otherwise patch appears fine to me.

Regards,
Mike

> ---
>  drivers/clk/meson/meson8b.c | 103 
> 
>  drivers/clk/meson/meson8b.h |  20 -
>  2 files changed, 122 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
> index 2937443d4505..e9985503165c 100644
> --- a/drivers/clk/meson/meson8b.c
> +++ b/drivers/clk/meson/meson8b.c
> @@ -245,6 +245,96 @@ static struct clk_fixed_factor meson8b_fclk_div7 = {
> },
>  };
>  
> +static struct meson_clk_mpll meson8b_mpll0 = {
> +   .sdm = {
> +   .reg_off = HHI_MPLL_CNTL7,
> +   .shift   = 0,
> +   .width   = 14,
> +   },
> +   .sdm_en = {
> +   .reg_off = HHI_MPLL_CNTL7,
> +   .shift   = 15,
> +   .width   = 1,
> +   },
> +   .n2 = {
> +   .reg_off = HHI_MPLL_CNTL7,
> +   .shift   = 16,
> +   .width   = 9,
> +   },
> +   .en = {
> +   .reg_off = HHI_MPLL_CNTL7,
> +   .shift   = 14,
> +   .width   = 1,
> +   },
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mpll0",
> +   .ops = _clk_mpll_ops,
> +   .parent_names = (const char *[]){ "fixed_pll" },
> +   .num_parents = 1,
> +   },
> +};
> +
> +static struct meson_clk_mpll meson8b_mpll1 = {
> +   .sdm = {
> +   .reg_off = HHI_MPLL_CNTL8,
> +   .shift   = 0,
> +   .width   = 14,
> +   },
> +   .sdm_en = {
> +   .reg_off = HHI_MPLL_CNTL8,
> +   .shift   = 15,
> +   .width   = 1,
> +   },
> +   .n2 = {
> +   .reg_off = HHI_MPLL_CNTL8,
> +   .shift   = 16,
> +   .width   = 9,
> +   },
> +   .en = {
> +   .reg_off = HHI_MPLL_CNTL8,
> +   .shift   = 14,
> +   .width   = 1,
> +   },
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mpll1",
> +   .ops = _clk_mpll_ops,
> +   .parent_names = (const char *[]){ "fixed_pll" },
> +   .num_parents = 1,
> +   },
> +};
> +
> +static struct meson_clk_mpll meson8b_mpll2 = {
> +   .sdm = {
> +   .reg_off = HHI_MPLL_CNTL9,
> +   .shift   = 0,
> +   .width   = 14,
> +   },
> +   .sdm_en = {
> +   .reg_off = HHI_MPLL_CNTL9,
> +   .shift   = 15,
> +   .width   = 1,
> +   },
> +   .n2 = {
> +   .reg_off = HHI_MPLL_CNTL9,
> +   .shift   = 16,
> +   .width   = 9,
> +   },
> +   .en = {
> +   .reg_off = HHI_MPLL_CNTL9,
> +   .shift   = 14,
> +   .width   = 1,
> +   },
> +   .lock = _lock,
> +   .hw.init = &(struct clk_init_data){
> +   .name = "mpll2",
> +   .ops = _clk_mpll_ops,
> +   .parent_names = (const char *[]){ "fixed_pll" },
> +   .num_parents = 1,
> +   },
> +};
> +
>  /*
>   * FIXME cpu clocks and the legacy composite clocks (e.g. clk81) are both PLL
>   * post-dividers and should be modeled with their respective PLLs via the
> @@ -491,6 +581,9 @@ static struct clk_hw_onecell_data meson8b_hw_onecell_data 
> = {
> [CLKID_AO_AHB_SRAM] = _ao_ahb_sram.hw,
> [CLKID_AO_AHB_BUS]  = _ao_ahb_bus.hw,
> [CLKID_AO_IFACE]= _ao_iface.hw,
> +   [CLKID_MPLL0]   = _mpll0.hw,
> +   [CLKID_MPLL1]   = _mpll1.hw,
> +   [CLKID_MPLL2]   = _mpll2.hw,
> },
> .num = CLK_NR_CLKS,
>  };
> @@ -501,6 +594,12 @@ static struct meson_clk_pll *const meson8b_clk_plls[] = {
> _sys_pll,
>  };
>  
> +static struct meson_clk_mpll *const meson8b_clk_mplls[] = {
> +   _mpll0,
> +   _mpll1,
> +   _mpll2,
> +};
> +
>  static struct clk_gate *const meson8b_clk_gates[] = {
> _clk81,
> _ddr,
> @@ -609,6 +708,10 @@ static int meson8b_clkc_probe(struct platform_device 
> *pdev)
> for (i = 0; i < ARRAY_SIZE(meson8b_clk_plls); i++)
> meson8b_clk_plls[i]->base = clk_base;
>  
> +   /* Populate base address for MPLLs */
> +   for (i = 0; i < ARRAY_SIZE(meson8b_clk_mplls); i++)
> +   meson8b_clk_mplls[i]->base = clk_base;
> +
> /* Populate the base address for CPU clk */
> meson8b_cpu_clk.base = clk_base;
>  
> diff --git a/drivers/clk/meson/meson8b.h b/drivers/clk/meson/meson8b.h
> index 010e9582888d..3881defc8644 100644
> --- 

Re: [PATCH v2 3/9] clk: meson8b: put dividers and muxes in tables

[Michael Turquette]

Quoting Jerome Brunet (2017-03-09 02:41:48)
> Until now, there was only 1 divider and 1 mux declared for the meson8b
> platform. With the ongoing work on various system, including audio, this
> is about to change. Use the same approach as gates for dividers and muxes,
> putting them in tables to fix the register address at runtime.
> 
> Signed-off-by: Jerome Brunet 

Looks good to me.

Regards,
Mike

> ---
>  drivers/clk/meson/meson8b.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
> index d1cc4d7cc8ff..2937443d4505 100644
> --- a/drivers/clk/meson/meson8b.c
> +++ b/drivers/clk/meson/meson8b.c
> @@ -582,6 +582,14 @@ static struct clk_gate *const meson8b_clk_gates[] = {
> _ao_iface,
>  };
>  
> +static struct clk_mux *const meson8b_clk_muxes[] = {
> +   _mpeg_clk_sel,
> +};
> +
> +static struct clk_divider *const meson8b_clk_dividers[] = {
> +   _mpeg_clk_div,
> +};
> +
>  static int meson8b_clkc_probe(struct platform_device *pdev)
>  {
> void __iomem *clk_base;
> @@ -604,15 +612,21 @@ static int meson8b_clkc_probe(struct platform_device 
> *pdev)
> /* Populate the base address for CPU clk */
> meson8b_cpu_clk.base = clk_base;
>  
> -   /* Populate the base address for the MPEG clks */
> -   meson8b_mpeg_clk_sel.reg = clk_base + (u32)meson8b_mpeg_clk_sel.reg;
> -   meson8b_mpeg_clk_div.reg = clk_base + (u32)meson8b_mpeg_clk_div.reg;
> -
> /* Populate base address for gates */
> for (i = 0; i < ARRAY_SIZE(meson8b_clk_gates); i++)
> meson8b_clk_gates[i]->reg = clk_base +
> (u32)meson8b_clk_gates[i]->reg;
>  
> +   /* Populate base address for muxes */
> +   for (i = 0; i < ARRAY_SIZE(meson8b_clk_muxes); i++)
> +   meson8b_clk_muxes[i]->reg = clk_base +
> +   (u32)meson8b_clk_muxes[i]->reg;
> +
> +   /* Populate base address for dividers */
> +   for (i = 0; i < ARRAY_SIZE(meson8b_clk_dividers); i++)
> +   meson8b_clk_dividers[i]->reg = clk_base +
> +   (u32)meson8b_clk_dividers[i]->reg;
> +
> /*
>  * register all clks
>  * CLKID_UNUSED = 0, so skip it and start with CLKID_XTAL = 1
> -- 
> 2.9.3
> 

Re: [PATCH v2 5/9] clk: meson: mpll: add rw operation

[Michael Turquette]

Quoting Jerome Brunet (2017-03-09 02:41:50)
> This patch adds new callbacks to the meson-mpll driver to control
> and set the pll rate. For this, we also need to add the enable bit and
> sdm enable bit. The corresponding parameters are added to mpll data
> structure.
> 
> Signed-off-by: Jerome Brunet 

Patch looks good to me. I'm really happy to see the mpll's get sorted
out finally!

Regards,
Mike

> ---
>  drivers/clk/meson/clk-mpll.c | 152 
> +--
>  drivers/clk/meson/clkc.h |   4 +-
>  drivers/clk/meson/gxbb.c |  30 +
>  3 files changed, 180 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/clk/meson/clk-mpll.c b/drivers/clk/meson/clk-mpll.c
> index 03af79005ddb..342b85d4e22a 100644
> --- a/drivers/clk/meson/clk-mpll.c
> +++ b/drivers/clk/meson/clk-mpll.c
> @@ -64,16 +64,50 @@
>  #include 
>  #include "clkc.h"
>  
> -#define SDM_MAX 16384
> +#define SDM_DEN 16384
> +#define SDM_MIN 1
> +#define SDM_MAX 16383
> +#define N2_MIN 4
> +#define N2_MAX 127
>  
>  #define to_meson_clk_mpll(_hw) container_of(_hw, struct meson_clk_mpll, hw)
>  
> +static unsigned long rate_from_params(unsigned long parent_rate,
> + unsigned long sdm,
> + unsigned long n2)
> +{
> +   return (parent_rate * SDM_DEN) / ((SDM_DEN * n2) + sdm);
> +}
> +
> +static void params_from_rate(unsigned long requested_rate,
> +unsigned long parent_rate,
> +unsigned long *sdm,
> +unsigned long *n2)
> +{
> +   uint64_t div = parent_rate;
> +   unsigned long rem = do_div(div, requested_rate);
> +
> +   if (div < N2_MIN) {
> +   *n2 = N2_MIN;
> +   *sdm = SDM_MIN;
> +   } else if (div > N2_MAX) {
> +   *n2 = N2_MAX;
> +   *sdm = SDM_MAX;
> +   } else {
> +   *n2 = div;
> +   *sdm = DIV_ROUND_UP(rem * SDM_DEN, requested_rate);
> +   if (*sdm < SDM_MIN)
> +   *sdm = SDM_MIN;
> +   else if (*sdm > SDM_MAX)
> +   *sdm = SDM_MAX;
> +   }
> +}
> +
>  static unsigned long mpll_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
>  {
> struct meson_clk_mpll *mpll = to_meson_clk_mpll(hw);
> struct parm *p;
> -   unsigned long rate = 0;
> unsigned long reg, sdm, n2;
>  
> p = >sdm;
> @@ -84,11 +118,119 @@ static unsigned long mpll_recalc_rate(struct clk_hw *hw,
> reg = readl(mpll->base + p->reg_off);
> n2 = PARM_GET(p->width, p->shift, reg);
>  
> -   rate = (parent_rate * SDM_MAX) / ((SDM_MAX * n2) + sdm);
> +   return rate_from_params(parent_rate, sdm, n2);
> +}
> +
> +static long mpll_round_rate(struct clk_hw *hw,
> +   unsigned long rate,
> +   unsigned long *parent_rate)
> +{
> +   unsigned long sdm, n2;
> +
> +   params_from_rate(rate, *parent_rate, , );
> +   return rate_from_params(*parent_rate, sdm, n2);
> +}
> +
> +static int mpll_set_rate(struct clk_hw *hw,
> +unsigned long rate,
> +unsigned long parent_rate)
> +{
> +   struct meson_clk_mpll *mpll = to_meson_clk_mpll(hw);
> +   struct parm *p;
> +   unsigned long reg, sdm, n2;
> +   unsigned long flags = 0;
> +
> +   params_from_rate(rate, parent_rate, , );
> +
> +   if (mpll->lock)
> +   spin_lock_irqsave(mpll->lock, flags);
> +   else
> +   __acquire(mpll->lock);
> +
> +   p = >sdm;
> +   reg = readl(mpll->base + p->reg_off);
> +   reg = PARM_SET(p->width, p->shift, reg, sdm);
> +   writel(reg, mpll->base + p->reg_off);
> +
> +   p = >sdm_en;
> +   reg = readl(mpll->base + p->reg_off);
> +   reg = PARM_SET(p->width, p->shift, reg, 1);
> +   writel(reg, mpll->base + p->reg_off);
> +
> +   p = >n2;
> +   reg = readl(mpll->base + p->reg_off);
> +   reg = PARM_SET(p->width, p->shift, reg, n2);
> +   writel(reg, mpll->base + p->reg_off);
> +
> +   if (mpll->lock)
> +   spin_unlock_irqrestore(mpll->lock, flags);
> +   else
> +   __release(mpll->lock);
>  
> -   return rate;
> +   return 0;
> +}
> +
> +static void mpll_enable_core(struct clk_hw *hw, int enable)
> +{
> +   struct meson_clk_mpll *mpll = to_meson_clk_mpll(hw);
> +   struct parm *p;
> +   unsigned long reg;
> +   unsigned long flags = 0;
> +
> +   if (mpll->lock)
> +   spin_lock_irqsave(mpll->lock, flags);
> +   else
> +   __acquire(mpll->lock);
> +
> +   p = >en;
> +   reg = readl(mpll->base + p->reg_off);
> +   reg = PARM_SET(p->width, p->shift, reg, enable ? 1 : 0);
> +   writel(reg, mpll->base + p->reg_off);
> +
> +   if (mpll->lock)
> +   

Re: [PATCH v3 1/3] clk: meson-gxbb: Add MALI clock IDS

[Michael Turquette]

Quoting Neil Armstrong (2017-03-09 04:53:45)
> Add missing MALI clock IDs and expose the muxes and gates in the dt-bindings.
> 
> Signed-off-by: Neil Armstrong 

Looks good to me.

Regards,
Mike

> ---
>  drivers/clk/meson/gxbb.h  | 9 -
>  include/dt-bindings/clock/gxbb-clkc.h | 5 +
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> index 274f587..73efdc3 100644
> --- a/drivers/clk/meson/gxbb.h
> +++ b/drivers/clk/meson/gxbb.h
> @@ -268,8 +268,15 @@
>  /* CLKID_SAR_ADC_CLK */
>  /* CLKID_SAR_ADC_SEL */
>  #define CLKID_SAR_ADC_DIV99
> +/* CLKID_MALI_0_SEL */
> +#define CLKID_MALI_0_DIV101
> +/* CLKID_MALI_0*/
> +/* CLKID_MALI_1_SEL */
> +#define CLKID_MALI_1_DIV104
> +/* CLKID_MALI_1*/
> +/* CLKID_MALI  */
>  
> -#define NR_CLKS  100
> +#define NR_CLKS  107
>  
>  /* include the CLKIDs that have been made part of the stable DT binding */
>  #include 
> diff --git a/include/dt-bindings/clock/gxbb-clkc.h 
> b/include/dt-bindings/clock/gxbb-clkc.h
> index f08f06d..ef7d6b7 100644
> --- a/include/dt-bindings/clock/gxbb-clkc.h
> +++ b/include/dt-bindings/clock/gxbb-clkc.h
> @@ -35,5 +35,10 @@
>  #define CLKID_SD_EMMC_C96
>  #define CLKID_SAR_ADC_CLK  97
>  #define CLKID_SAR_ADC_SEL  98
> +#define CLKID_MALI_0_SEL   100
> +#define CLKID_MALI_0   102
> +#define CLKID_MALI_1_SEL   103
> +#define CLKID_MALI_1   105
> +#define CLKID_MALI 106
>  
>  #endif /* __GXBB_CLKC_H */
> -- 
> 1.9.1
>