Re: [git pull] clk: renesas: Updates for v4.21 (take two)

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-12-07 04:22:03)
> Hi Mike, Stephen,
> 
> The following changes since commit eb38c119dd91c61de26f67050671a84064554f7d:
> 
>   clk: renesas: r7s9210: Add USB clocks (2018-11-13 09:58:51 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.21-tag2
> 
> for you to fetch changes up to 36c4da4f552a126bb29a95dc5c9608795491e32a:
> 
>   clk: renesas: rcar-gen3: Add HS400 quirk for SD clock (2018-12-07 11:45:06 
> +0100)
> 

Thanks. Pulled into clk-next.

[PATCH 0/8] Remove CLK_IS_BASIC usage from clk drivers

[Stephen Boyd]

A collection of patches to remove CLK_IS_BASIC from drivers
that don't look to have any need for it. There are some files
outside of drivers/clk/ that aren't include here because I'll
send those patches to respective maintainers.

Cc: Anders Berg 
Cc: Geert Uytterhoeven 
Cc: Jiancheng Xue 
Cc: Jianguo Sun 
Cc: Krzysztof Kozlowski 
Cc: Kukjin Kim 
Cc: Leo Yan 
Cc: Linus Walleij 
Cc: 
Cc: Sylwester Nawrocki 
Cc: 
Cc: Wei Yongjun 
Cc: Yoshinori Sato 

Stephen Boyd (8):
  clk: renesas: Remove usage of CLK_IS_BASIC
  clk: st: Remove usage of CLK_IS_BASIC
  clk: axm5516: Remove usage of CLK_IS_BASIC
  clk: h8300: Remove usage of CLK_IS_BASIC
  clk: hisilicon: Remove usage of CLK_IS_BASIC
  clk: versatile: sp810: Remove usage of CLK_IS_BASIC
  clk: samsung: s3c2410: Remove usage of CLK_IS_BASIC
  clk: Loongson1: Remove usage of CLK_IS_BASIC

 drivers/clk/clk-axm5516.c | 2 --
 drivers/clk/h8300/clk-h8s2678.c   | 2 +-
 drivers/clk/hisilicon/clk-hi3620.c| 2 +-
 drivers/clk/hisilicon/clk-hisi-phase.c| 2 +-
 drivers/clk/hisilicon/clk-hix5hd2.c   | 2 +-
 drivers/clk/hisilicon/clkgate-separated.c | 2 +-
 drivers/clk/loongson1/clk.c   | 8 +---
 drivers/clk/renesas/clk-div6.c| 2 +-
 drivers/clk/renesas/clk-mstp.c| 2 +-
 drivers/clk/renesas/r9a06g032-clocks.c| 8 
 drivers/clk/renesas/rcar-gen3-cpg.c   | 2 +-
 drivers/clk/renesas/renesas-cpg-mssr.c| 2 +-
 drivers/clk/samsung/clk-s3c2410-dclk.c| 2 +-
 drivers/clk/st/clk-flexgen.c  | 2 +-
 drivers/clk/st/clkgen-fsyn.c  | 4 ++--
 drivers/clk/st/clkgen-pll.c   | 2 +-
 drivers/clk/versatile/clk-sp810.c | 2 +-
 17 files changed, 24 insertions(+), 24 deletions(-)

-- 
Sent by a computer through tubes

Re: [PATCH] clk: vc5: Add suspend/resume support

[Stephen Boyd]

Quoting Marek Vasut (2018-12-04 10:27:21)
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> index decffb3826ec..ac90fb36af1a 100644
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
> return 0;
>  }
>  
> +#ifdef CONFIG_PM_SLEEP
> +static int vc5_suspend(struct device *dev)

Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP

> +{
> +   struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
> +   int ret;
> +
> +   ret = regcache_sync(vc5->regmap);
> +   if (ret != 0) {
> +   dev_err(dev, "Failed to save register map: %d\n", ret);
> +   return ret;

Do we need to block suspend if we can't save the register map away? Or
can we just throw up our hands and not restore on resume?

> +   }
> +   regcache_cache_only(vc5->regmap, true);
> +   regcache_mark_dirty(vc5->regmap);
> +
> +   return 0;
> +}
> +
> +static int vc5_resume(struct device *dev)
> +{
> +   struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
> +   int ret;
> +
> +   regcache_cache_only(vc5->regmap, false);
> +   ret = regcache_sync(vc5->regmap);
> +   if (ret != 0) {
> +   dev_err(dev, "Failed to restore register map: %d\n", ret);
> +   return ret;
> +   }

Simplify to

if (ret)
dev_err()
retun ret;

> +
> +   return 0;
> +}
> +#endif
> +
>  static const struct vc5_chip_info idt_5p49v5923_info = {
> .model = IDT_VC5_5P49V5923,
> .clk_fod_cnt = 2,

Re: [PATCH 00/13] clk: renesas: Miscellaneous fixes

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-11-29 02:49:55)
> Hi Mike, Stephen, Laurent, Kieran,
> 
> This patch series contains several fixes for the Renesas Clock drivers
> and DT bindings, and a small simplification:
>   - Removal of non-existent clocks,
>   - Addition of the CPEX clocks, which can be used a source for a timer
> (CMT1),
>   - Correction of DU parent clocks.
> Most of these have been found by skimming the Hardware Manual Errata.
> 
> This has been boot-tested on Salvator-X(S) (R-Car H3, M3-W, M3-N), Eagle
> (R-Car V3M), and Draak (R-Car D3), except for the DU parts.
> Testing of the DU on R-Car D3 and E3 would be appreciated, as the DU
> driver may have a workaround for the incorrect parent clock rates.
> 
> I intend to queue this in clk-renesas-for-v4.21.
> 

Ok. For the whole series:

Acked-by: Stephen Boyd 

Re: [git pull] clk: renesas: Updates for v4.21

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-11-23 00:56:35)
> Hi Mike, Stephen,
> 
> The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
> 
>   Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.21-tag1
> 
> for you to fetch changes up to eb38c119dd91c61de26f67050671a84064554f7d:
> 
>   clk: renesas: r7s9210: Add USB clocks (2018-11-13 09:58:51 +0100)
> 
> 
> clk: renesas: Updates for v4.21
> 
>   - Add support for SDHI and USB clocks on RZ/A2,
>   - Add support for RPC (SPI Multi I/O Bus Controller) clocks on R-Car
> V3M.
> 
> Thanks for pulling!
> 

Thanks. Pulled into clk-next. Plus I threw a sparse warning fix into the
pile.

Re: [git pull] clk: renesas: Updates for v4.20 (take two)

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-09-28 01:41:39)
> Hi Mike, Stephen,
> 
> The following changes since commit b30c862f2a72002c06df23d05c2ca6b49148c4d4:
> 
>   clk: renesas: r8a77990: Add missing I2C7 clock (2018-08-31 10:33:59 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.20-tag2
> 
> for you to fetch changes up to a53a28dca4124048c90b4a8de457668ede57e67c:
> 
>   clk: renesas: r7s9210: Add SPI clocks (2018-09-28 09:57:09 +0200)
> 
> 
> clk: renesas: Updates for v4.20 (take two)
> 
>   - Add support for CMT timer clocks on R-Car V3H,
>   - Add support for SHDI and various timer clocks on R-Car V3M,
>   - Add support for the new RZ/A2 (R7S9210) SoC, including early clock
> support for the Renesas CPG/MSSR driver,
>   - Add support for the new RZ/G1N (R8A7744) and RZ/G2E (R8A774C0) SoCs,
>   - Convert DT binding includes to SPDX license identifiers,
>   - Small fixes and clean ups.
> 

Thanks. Pulled into clk-next.

Re: [PATCH] clk: renesas: Convert to SPDX identifiers

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-09-25 00:34:05)
> From: Kuninori Morimoto 
> 
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
> 
> Signed-off-by: Kuninori Morimoto 
> [rebased against clk-spdx]
> Signed-off-by: Geert Uytterhoeven 
> ---

Applied to clk-next

Re: [git pull] clk: renesas: Updates for v4.20

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-08-31 06:09:58)
> Hi Mike, Stephen,
> 
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> 
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.20-tag1
> 
> for you to fetch changes up to b30c862f2a72002c06df23d05c2ca6b49148c4d4:
> 
>   clk: renesas: r8a77990: Add missing I2C7 clock (2018-08-31 10:33:59 +0200)
> 

Pulled. Thanks.

Re: [PATCH] clk: renesas: r8a77990: Add missing I2C7 clock

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-08-30 08:28:13)
> When trying to use I2C7 on R-Car E3:
> 
> renesas-cpg-mssr e615.clock-controller: Cannot get module clock 1003: 
> -2
> i2c-rcar e669.i2c: failed to add to PM domain always-on: -2
> i2c-rcar: probe of e669.i2c failed with error -2
> 
> Unlike other R-Car Gen3 SoCs, R-Car E3 has more than 7 I2C bus
> interfaces.  Add the forgotten module clock for the 8th instance to fix
> this.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---

Reviewed-by: Stephen Boyd 

Re: [PATCH] clk: renesas: rcar-gen3: Rename rint to .r

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-07-26 08:25:24)
> All other internal clock names have a period prepended.
> 
> Hence rename the internal RCLK from "rint" to ".r", and move it to the
> section where all other internal clocks are defined.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---

Acked-by: Stephen Boyd 

Re: [git pull] clk: renesas: Updates for v4.19

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-07-04 02:45:52)
> Hi Mike, Stephen,
> 
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.19-tag1
> 
> for you to fetch changes up to 4c3d88526eba214357150764a0e3e5308acbef4a:
> 
>   clk: renesas: Renesas R9A06G032 clock driver (2018-06-25 11:17:13 +0200)
> 
> 
> clk: renesas: Updates for v4.19
> 
>   - Add support for Crypto Engine clocks on R-Car H3,
>   - Add support for the new RZ/N1D SoC.
> 

Thanks. Pulled into clk-next.

Re: [git pull] clk: renesas: Updates for v4.18

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-05-09 09:52:34)
> Hi Mike, Stephen,
> 
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> 
>   Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.18-tag1
> 
> for you to fetch changes up to 3570a2af473789c5d5f5b9e04f72295102967824:
> 
>   clk: renesas: cpg-mssr: Add support for R-Car E3 (2018-05-09 18:43:57 +0200)
> 
> 
> clk: renesas: Updates for v4.18
> 
>   - Add support for the MSIOF module clocks on R-Car M3-N,
>   - Add support for the new RZ/G1C and R-Car E3 SoCs,
>   - Small fixes and cleanups.

Thanks. Pulled into clk-next.

Re: [PATCH 05/61] clk: samsung: simplify getting .drvdata

[Stephen Boyd]

Quoting Wolfram Sang (2018-04-19 07:05:35)
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
> ---

Applied to clk-next

Re: [PATCH 05/61] clk: samsung: simplify getting .drvdata

[Stephen Boyd]

Quoting Sylwester Nawrocki (2018-05-15 02:32:12)
> On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> > We should get drvdata from struct device directly. Going via
> > platform_device is an unneeded step back and forth.
> > 
> > Signed-off-by: Wolfram Sang 
> 
> Acked-by: Sylwester Nawrocki 
> 
> It seems to be the only clk/samsung patch in the v4.18 queue, please
> feel free to apply it directly.

Ok. I'll pick it up.

Re: [git pull] clk: renesas: Updates for v4.17 (take two)

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-03-22 10:09:20)
> Hi Mike, Stephen,
> 
> The following changes since commit 7ce36da900c0a2ff4777d9ba51c4f1cb74205463:
> 
>   clk: renesas: cpg-mssr: Add support for R-Car M3-N (2018-02-26 09:13:29 
> +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.17-tag2
> 
> for you to fetch changes up to 472f5f391819b4b22ec040f227aea26f515b6ae2:
> 
>   clk: renesas: cpg-mssr: Adjust r8a77980 ifdef (2018-03-21 17:35:02 +0100)
> 
> 
> clk: renesas: Updates for v4.17 (take two)
> 
>   - Fix the incorrect display clock on R-Car M3-N,
>   - Always use readl()/writel(),
>   - Small fixes.
> 
> Thanks for pulling!
> 

Thanks. Pulled.

Re: [PATCH] clk: fix false-positive Wmaybe-uninitialized warning

[Stephen Boyd]

Quoting Arnd Bergmann (2018-02-16 07:27:47)
> When we build this driver with on x86-32, gcc produces a false-positive 
> warning:
> 
> drivers/clk/renesas/clk-sh73a0.c: In function 'sh73a0_cpg_clocks_init':
> drivers/clk/renesas/clk-sh73a0.c:155:10: error: 'parent_name' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>return clk_register_fixed_factor(NULL, name, parent_name, 0,
> 
> We can work around that warning by adding a fake initialization, I tried
> and failed to come up with any better workaround. This is currently one
> of few remaining warnings for a 4.14.y randconfig build, so it would be
> good to also have it backported at least to that version. Older versions
> have more randconfig warnings, so we might not care.
> 
> I had not noticed this earlier, because one patch in my randconfig test
> tree removes the '-ffreestanding' option on x86-32, and that avoids
> the warning. The -ffreestanding flag was originally global but moved
> into arch/i386 by Andi Kleen in commit 6edfba1b33c7 ("[PATCH] x86_64:
> Don't define string functions to builtin") as a 'temporary workaround'.
> 
> Like many temporary hacks, this turned out to be rather long-lived, from
> all I can tell we still need a simple fix to asm/string_32.h before it
> can be removed, but I'm not sure about how to best do that.
> 
> Cc: sta...@vger.kernel.org
> Cc: Andi Kleen 
> Signed-off-by: Arnd Bergmann 
> ---

Applied to clk-next

Re: [PATCH 0/8] clk: renesas: Always use readl()/writel()

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-03-16 06:40:14)
> Hi Mike, Stephen,
> 
> On arm32/arm64, there is no reason to use the (soon deprecated)
> clk_readl()/clk_writel(), and the generic readl()/writel() should be
> used in instead.
> 
> Commit 30ad3cf00e94f4a7 ("clk: renesas: rcar-gen3-cpg: Always use
> readl()/writel()") already got rid of them in the R-Car Gen3 clock
> driver, but Stephen noticed that a few new users crept in recently.
> 
> Hence this series fixes that, and replaces all other uses in the Renesas
> clock drivers as a bonus.
> 
> I plan to queue these up in clk-renesas-for-v4.17.
> 

Ok. I'll wait for the PR. Thanks!

Re: [git pull] clk: renesas: Updates for v4.17

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-03-15 02:27:33)
> Hi Stephen,
> 
> On Wed, Mar 14, 2018 at 10:43 PM, Stephen Boyd <sb...@kernel.org> wrote:
> 
> > Did you need to use clk_readl() or was it just copy-paste? I hope we can
> > get rid of that function at some point.
> 
> That's an oversight. I will get rid of them in the second pull request
> for v4.17.
> 

Awesome. Thanks.

Re: [git pull] clk: renesas: Updates for v4.17

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-03-02 02:17:52)
> Hi Mike, Stephen,
> 
> The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
> 
>   Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.17-tag1
> 
> for you to fetch changes up to 7ce36da900c0a2ff4777d9ba51c4f1cb74205463:
> 
>   clk: renesas: cpg-mssr: Add support for R-Car M3-N (2018-02-26 09:13:29 
> +0100)
> 
> 
> clk: renesas: Updates for v4.17
> 
>   - Update legacy DT Kconfig default,
>   - Add support for CPU (Z/Z2) clocks on R-Car H3 and M3-W,
>   - Add support for the watchdog module clocks on R-Car Gen2 and RZ/G1,
>   - Add support for the new R-Car M3-N and V3H SoCs.
> 
> Thanks for pulling!
> 

Thanks. Pulled into clk-next.

Did you need to use clk_readl() or was it just copy-paste? I hope we can
get rid of that function at some point.

Re: [git pull] clk: renesas: Updates for v4.16 (take two)

[Stephen Boyd]

On 01/05, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit 7aff266552d6042b43d3d5a9b13f0009ef862033:
> 
>   clk: renesas: cpg-mssr: Keep wakeup sources active during system suspend 
> (2017-12-14 16:40:36 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.16-tag2
> 
> for you to fetch changes up to a115f6362cee01813c66e10e397b25f2a06aecfb:
> 
>   clk: renesas: r8a7796: Add FDP clock (2018-01-05 11:14:38 +0100)
> 
> 
> clk: renesas: Updates for v4.16 (take two)
> 
>   - Add support for the FDP1-0 module clock on R-Car M3-W.
> 

Pulled into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long

[Stephen Boyd]

On 01/02, Bryan O'Donoghue wrote:
> On 02/01/18 19:01, Stephen Boyd wrote:
> >On 12/31, Bryan O'Donoghue wrote:
> >>On 30/12/17 16:36, Mikko Perttunen wrote:
> >>>FWIW, we had this problem some years ago with the Tegra CPU clock
> >>>- then it was determined that a simpler solution was to have the
> >>>determine_rate callback support unsigned long rates - so clock
> >>>drivers that need to return rates higher than 2^31 can instead
> >>>implement the determine_rate callback. That is what's currently
> >>>implemented.
> >>>
> >>>Mikko
> >>
> >>Granted we could work around it but, having both zero and less than
> >>zero indicate error means you can't support larger than LONG_MAX
> >>which is I think worth fixing.
> >>
> >
> >Ok. But can you implement the determine_rate op instead of the
> >round_rate op for your clk?
> 
> Don't know .

Please try.

> 
> >It's not a work-around, it's the
> >preferred solution. That would allow rates larger than 2^31 for
> >the clk without pushing through a change to all the drivers to
> >express zero as "error" and non-zero as the rounded rate.
> >
> >I'm not entirely opposed to this approach, because we probably
> >don't care to pass the particular error value from a clk provider
> >to a clk consumer about what the error is.
> 
> Which was my thought. The return value of clk_ops->round_rate()
> appears not to get pushed up the stack, which is what the last patch
> in this series deals with.
> 
> [PATCH 33/33] clk: change handling of round_rate() such that only
> zero is an error

Hmm? clk_core_determine_round_nolock() returns 'rate' if rate < 0
from the round_rate op. clk_core_round_rate_nolock() returns that
value to clk_round_rate() which returns it to the consumer.

> 
> >It's actually what we
> >proposed as the solution for clk_round_rate() to return values
> >larger than LONG_MAX to consumers. But doing that consumer API
> >change or this provider side change is going to require us to
> >evaluate all the consumers of these clks to make sure they don't
> >check for some error value that's less than zero. This series
> >does half the work,
> 
> Do you mean users of clk_rounda_rate() ? I have a set of patches for
> that but wanted to separate that from clk_ops->round_rate() so as
> not to send ~70 patches out to LKML at once - even if they are in
> two blocks.

Ok. What have you done to the consumers of clk_round_rate()?
Made them treat 0 as an error instead of less than zero? The
documentation in clk.h needs to be updated. See this patch from
Paul Wamsley[1] for one proposed patch that went nowhere. Also
include Russell King please. It was also proposed to change the
function signature of clk_round_rate() to return unsigned long,
but that didn't go anywhere either.

> 
> If so, I can publish that set too for reference.
> 
> AFAICT on clk_ops->round_rate the last patch #33 ought to cover the
> usage of the return value of clk_ops->round_rate().
> 
> Have I missed something ?

Hopefully not!

> 
> >by changing the provider side, while ignoring
> >the consumer side and any potential fallout of the less than zero
> >to zero return value change.
> >
> 
> Can you look at #33 ? I'm not sure if you saw that one.
> 

Yeah I looked at it. From what I can tell it makes
clk_round_rate() return 0 now instead of whatever negative value
the clk_ops::round_rate function returns.

[1] https://lkml.kernel.org/r/alpine.DEB.2.02.1311251603310.23090@tamien

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long

[Stephen Boyd]

On 12/31, Bryan O'Donoghue wrote:
> On 30/12/17 16:36, Mikko Perttunen wrote:
> >FWIW, we had this problem some years ago with the Tegra CPU clock
> >- then it was determined that a simpler solution was to have the
> >determine_rate callback support unsigned long rates - so clock
> >drivers that need to return rates higher than 2^31 can instead
> >implement the determine_rate callback. That is what's currently
> >implemented.
> >
> >Mikko
> 
> Granted we could work around it but, having both zero and less than
> zero indicate error means you can't support larger than LONG_MAX
> which is I think worth fixing.
> 

Ok. But can you implement the determine_rate op instead of the
round_rate op for your clk? It's not a work-around, it's the
preferred solution. That would allow rates larger than 2^31 for
the clk without pushing through a change to all the drivers to
express zero as "error" and non-zero as the rounded rate.

I'm not entirely opposed to this approach, because we probably
don't care to pass the particular error value from a clk provider
to a clk consumer about what the error is. It's actually what we
proposed as the solution for clk_round_rate() to return values
larger than LONG_MAX to consumers. But doing that consumer API
change or this provider side change is going to require us to
evaluate all the consumers of these clks to make sure they don't
check for some error value that's less than zero. This series
does half the work, by changing the provider side, while ignoring
the consumer side and any potential fallout of the less than zero
to zero return value change.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.16

[Stephen Boyd]

On 12/15, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
> 
>   Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.16-tag1
> 
> for you to fetch changes up to 7aff266552d6042b43d3d5a9b13f0009ef862033:
> 
>   clk: renesas: cpg-mssr: Keep wakeup sources active during system suspend 
> (2017-12-14 16:40:36 +0100)
> 
> 
> clk: renesas: Updates for v4.16
> 
>   - Add support for the LVDS module clock on R-Car V3M,
>   - Keep wakeup sources in Clock Domains active during system suspend,
> which will allow removing workarounds from drivers later.
> 
> Thanks for pulling!
> 
> P.S. There seems to be issues with kernel.org mirrorring. I can't see my
>  tag in the public repo, but the clk-renesas-for-v4.16 branch is
>  up-to-date (last change 18 hours ago).

Thanks. Pulled into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.15 (take two)

[Stephen Boyd]

On 10/20, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit b4021bbe10017d994e5a96ebfd2677bbaf2b37e0:
> 
>   clk: renesas: rcar-gen2: Delete error message for failed memory allocation 
> (2017-09-28 17:57:34 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.15-tag2
> 
> for you to fetch changes up to 3f7a4d084159c52513d1ff77f3b3b880bcf517d9:
> 
>   clk: renesas: rcar-gen3: Restore R clock during resume (2017-10-20 11:16:09 
> +0200)
> 
> 
> clk: renesas: Updates for v4.15 (take two)
> 
>   - Add support for the second display unit clock on RZ/G1E,
>   - Add git repository to MAINTAINERS,
>   - Add suspend/resume support for R-Car Gen3 CPG/MSSR,
>   - Small fixes and cleanups.
> 
> Note: this is on top of my previous pull request, for
> tags/clk-renesas-for-v4.15-tag1, which you haven't pulled yet.
> 

Thanks. Pulled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.15

[Stephen Boyd]

On 10/04, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
> 
>   Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.15-tag1
> 
> for you to fetch changes up to b4021bbe10017d994e5a96ebfd2677bbaf2b37e0:
> 

Thanks. Pulled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] MAINTAINERS: Add git repository to Renesas clock driver section

[Stephen Boyd]

On 10/04, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

I take it this will come through some PR?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: cs2000: Add cs2000_set_saved_rate

[Stephen Boyd]

On 04/20, Yoshihiro Kaneko wrote:
> From: Gaku Inami 
> 
> This patch adds the common function to reset the clk rate in order to
> be able to use it in other cases.
> 
> Signed-off-by: Gaku Inami 
> Signed-off-by: Hiroyuki Yokoyama 
> Signed-off-by: Yoshihiro Kaneko 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: Convert to using %pOF instead of full_name

[Stephen Boyd]

On 07/18, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring <r...@kernel.org>
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Maxime Coquelin <mcoquelin.st...@gmail.com>
> Cc: Alexandre Torgue <alexandre.tor...@st.com>
> Cc: Russell King <li...@armlinux.org.uk>
> Cc: Matthias Brugger <matthias@gmail.com>
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: "Emilio López" <emi...@elopez.com.ar>
> Cc: Peter De Schrijver <pdeschrij...@nvidia.com>
> Cc: Prashant Gaikwad <pgaik...@nvidia.com>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Cc: Jonathan Hunter <jonath...@nvidia.com>
> Cc: Tero Kristo <t-kri...@ti.com>
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/4] clk: renesas: rcar-gen3: Add divider support for PLL1 and PLL3

[Stephen Boyd]

On 07/20, Geert Uytterhoeven wrote:
> On some R-Car Gen3 SoCs (e.g. R-Car D3), PLL1 and PLL3 use a divider
> value different from one.  Extend struct rcar_gen3_cpg_pll_config to handle
> this.  As all multipliers and dividers are small, table size increase
> can be kept limited by storing them in u8s instead of unsigned ints,
> which saves ca. 0.5 KiB for a generic kernel.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 3/4] clk: renesas: rcar-gen3: Add support for SCCG/Clean peripheral clocks

[Stephen Boyd]

On 07/20, Geert Uytterhoeven wrote:
> On R-Car Gen3 SoCs with a Spread Spectrum Clock Generator (e.g. R-Car
> D3), a peripheral clock divider has been added, to select between clean
> and spread spectrum parents.
> 
> Add a new clock type to the R-Car Gen3 driver core to handle this.
> To avoid increasing the size of struct cpg_core_clk, both parents and
> dividers are stored in the existing parent resp. div fields.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 4/4] clk: renesas: cpg-mssr: Add R8A77995 support

[Stephen Boyd]

On 07/20, Geert Uytterhoeven wrote:
> Add R-Car D3 (R8A77995) Clock Pulse Generator / Module Standby and
> Software Reset support, using the CPG/MSSR driver core and the common
> R-Car Gen3 CPG code.
> 
> Based on the R-Car Series, 3rd Generation Hardware User's Manual, Rev.
> 0.55, Jun. 30, 2017.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: devicet...@vger.kernel.org
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/4] clk: renesas: Add r8a77995 CPG Core Clock Definitions

[Stephen Boyd]

On 07/20, Geert Uytterhoeven wrote:
> Add all R-Car D3 Clock Pulse Generator Core Clock Outputs, as listed
> in Table 8.2f ("List of Clocks [R-Car D3]") of the R-Car Series, 3rd
> Generation Hardware User's Manual (Rev. 0.55, Jun. 30, 2017).
> 
> Note that internal CPG clocks (S0, S1, S2, S3, S1C, S3C, SDSRC, and
> SSPSRC) are not included, as they are used as internal clock sources
> only, and never referenced from DT.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: devicet...@vger.kernel.org
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: cs2000: Add cs2000_set_saved_rate

[Stephen Boyd]

On 04/20, Yoshihiro Kaneko wrote:
> From: Gaku Inami 
> 
> This patch adds the common function to reset the clk rate in order to
> be able to use it in other cases.
> 
> Signed-off-by: Gaku Inami 
> Signed-off-by: Hiroyuki Yokoyama 
> Signed-off-by: Yoshihiro Kaneko 
> ---
> This patch is based on the clk-next branch of linux-clk tree.

Geert?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: rcar-gen3: Fix SD divider setting

[Stephen Boyd]

On 04/20, Yoshihiro Kaneko wrote:
> From: Takeshi Kihara 
> 
> This patch fixed the SD divider settiing for corresponding to the change
> in the HS200/HS400 mode.
> 
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Kaneko 
> ---
> This patch is based on the clk-next branch of linux-clk tree.

Geert?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate

[Stephen Boyd]

On 07/17, Geert Uytterhoeven wrote:
> Hi Wolfram,
> 
> On Mon, Jul 17, 2017 at 11:18 AM, Wolfram Sang  wrote:
> >> >> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an
> >> >> error occurs, but -EINVAL is returned. This patch fixes it.
> >> >>
> >> >> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 
> >> >> support code")
> >> >> Signed-off-by: Takeshi Kihara 
> >> >> Signed-off-by: Yoshihiro Kaneko 
> >> >
> >> > Reviewed-by: Wolfram Sang 
> >>
> >> Why is it desirable to return 0 if an error occurs? Because the return 
> >> type is
> >> unsigned long?
> >
> > Yes, I'd think so. Instead of an arbitrary high, kind-of-random, number, 
> > just
> > return 0 which also indicates that something unexpected happened? Also, all
> > other drivers return zero in an error case (did some quick coccinelle
> > grepping before).
> 
> OK.
> 
> >> Is this routine allowed to fail? I don't see any handling of zero by
> >> its callers.
> >
> > From clk-provider.h:
> >
> >  * @recalc_rate Recalculate the rate of this clock, by querying hardware. 
> > The
> >  *  parent rate is an input parameter.  It is up to the caller 
> > to
> >  *  ensure that the prepare_mutex is held across this call.
> >  *  Returns the calculated rate.  Optional, but recommended - if
> >  *  this op is not set then clock rate will be initialized to 0.
> >
> > What would be the benefit of keeping -EINVAL in an unsigned long?
> 
> I do not mean that -EINVAL is correct. Obviously it isn't. But blindly
> replacing -EINVAL by zero may not be the right solution neither.
> 
> If recalc_rate cannot return an error value, perhaps there is a good reason
> for that?

Presumably you can always figure out what the rate of the clk is,
or at least return the rate of the parent clk if it can't be
figured out for some odd reason. In this case it looks like we
don't have some divider mapping? Why not make it a WARN_ON() and
return 0? Then we can fix the warning by adding the appropriate
mapping in the table and not return some really large frequency.

> 
> I see there's a similar check in cpg_sd_clock_enable(), so the clock also
> cannot be enabled if this condition is met?
> 
> When does this happen? If the firmware leaves a invalid/unsupported setting
> in the register? If we can't recover from that, perhaps the clock's probe
> should just fail instead?
> 
> It looks like the only writer of that field is cpg_sd_clock_set_rate(),
> which always writes a valid/supported value. Is it guaranteed that this
> function is always called first?
> If yes, the checks can just be removed instead?
> 

This also works. I'm dropping this patch from my queue for now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V3 8/8] clk: vc5: Add support for IDT VersaClock 5P49V6901

[Stephen Boyd]

On 07/09, Marek Vasut wrote:
> Update IDT VersaClock 5 driver to support IDT VersaClock 6 5P49V6901.
> This chip has two clock inputs (external XTAL or external CLKIN), four
> fractional dividers (FODs) and five clock outputs (four universal clock
> outputs and one reference clock output at OUT0_SELB_I2C).
> 
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: Alexey Firago <alexey_fir...@mentor.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: linux-renesas-soc@vger.kernel.org
> Tested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> on Salvator-XS with the display LVDS output.
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V3 3/8] clk: vc5: Do not warn about disabled output buffer input muxes

[Stephen Boyd]

On 07/09, Marek Vasut wrote:
> The output buffer input mux can be configured in either of three
> states -- disabled, input from FOD, input from previous output.
> If the output buffer input mux is set to disabled, the code in
> vc5_clk_out_get_parent() would consider this an invalid setting
> and warn about it, which is not necessarily the case.
> 
> In case the output buffer input mux is disabled, default to input
> from FOD to have some parent and don't print the warning.
> 
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Alexey Firago <alexey_fir...@mentor.com>
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: linux-renesas-soc@vger.kernel.org
> Tested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> on Salvator-XS with the display LVDS output.
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V3 1/8] clk: vc5: Prevent division by zero on unconfigured outputs

[Stephen Boyd]

On 07/09, Marek Vasut wrote:
> In case the initial values of the FOD registers are not configured in
> the OTP or by the bootloader, it is possible that the FOD registers
> will contain zeroes. The code in vc5_fod_recalc_rate() immediately
> feeds the FOD divider value obtained from the FOD registers into the
> div64_u64() and if the FOD divider value is zero, triggers division
> by zero exception.
> 
> Check if the FOD divider value is zero and return the frequency of
> the FOD output as 0 Hz if it is so. This prevents the division by
> zero exception.
> 
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Alexey Firago <alexey_fir...@mentor.com>
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: linux-renesas-soc@vger.kernel.org
> Tested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> on Salvator-XS with the display LVDS output.
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V3 2/8] clk: vc5: Fix trivial typo

[Stephen Boyd]

On 07/09, Marek Vasut wrote:
> Fix trivial typo in vc5_clk_out_unprepare() , s/Enable/Disable/ .
> 
> Signed-off-by: Marek Vasut <marek.vasut+rene...@gmail.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Alexey Firago <alexey_fir...@mentor.com>
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: linux-renesas-soc@vger.kernel.org
> Tested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> on Salvator-XS with the display LVDS output.
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: renesas: rcar-usb2-clock-sel: Add R-Car USB 2.0 clock selector PHY

[Stephen Boyd]

On 06/28, Yoshihiro Shimoda wrote:
> +
> +
> + platform_set_drvdata(pdev, priv);
> + dev_set_drvdata(dev, priv);
> +
> + init.name = "rcar_usb2_clock_sel";
> + init.ops = _clock_sel_clock_ops;
> + init.flags = CLK_IS_BASIC;

Please drop CLK_IS_BASIC unless you need it.

> + init.parent_names = NULL;
> + init.num_parents = 0;
> + priv->hw.init = 
> +
> + clk = clk_register(NULL, >hw);
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + error = of_clk_add_provider(np, of_clk_src_simple_get, clk);

Can you use clk_hw_register() and of_clk_add_hw_provider()
please?

> + if (error)
> + return error;
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops rcar_usb2_clock_sel_pm_ops = {
> + .suspend= rcar_usb2_clock_sel_suspend,
> + .resume = rcar_usb2_clock_sel_resume,
> +};
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 3/8] clk: vc5: Do not warn about disabled output buffer input muxes

[Stephen Boyd]

On 06/29, Marek Vasut wrote:
> @@ -549,6 +552,7 @@ static unsigned char vc5_clk_out_get_parent(struct clk_hw 
> *hw)
>  
>   dev_warn(>client->dev,
>"Invalid clock output configuration (%02x)\n", src);
> +
>   return 0;
>  }
>  

Please drop this hunk as it isn't relevant to the patch.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: cpg-mssr: Use of_device_get_match_data() helper

[Stephen Boyd]

On 06/09, Geert Uytterhoeven wrote:
> If CONFIG_OF=n:
> 
> drivers/clk/renesas/renesas-cpg-mssr.c: In function ‘cpg_mssr_probe’:
> drivers/clk/renesas/renesas-cpg-mssr.c:702: warning: dereferencing ‘void 
> *’ pointer
> drivers/clk/renesas/renesas-cpg-mssr.c:702: error: request for member 
> ‘data’ in something not a structure or union
> 
> To fix this, use the of_device_get_match_data() helper, for which a
> dummy version is provided if CONFIG_OF=n.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH/RFC 1/2] clk: renesas: Rework Kconfig and Makefile logic

[Stephen Boyd]

On 04/25, Geert Uytterhoeven wrote:
> The goals are to:
>   - Allow precise control over and automatic selection of which
> (sub)drivers are used for which SoC (which may change in the
> future),
>   - Allow adding support for new SoCs easily,
>   - Allow compile-testing of all (sub)drivers,
>   - Keep driver selection logic in the subsystem-specific Kconfig
> independent from the architecture-specific Kconfig (i.e. no "select"
> from arch/arm64/Kconfig.platforms), to avoid dependencies.
> 
> This is implemented by:
>   - Introducing Kconfig symbols for all drivers and sub-drivers,
>   - Introducing the Kconfig symbol CLK_RENESAS, which is enabled
> automatically when building for a Renesas ARM platform, and which
> enables all required drivers without interaction of the user, based
> on SoC-specific ARCH_* symbols,
>   - Allowing the user to enable any Kconfig symbol manually if
> COMPILE_TEST is enabled,
>   - Using the new Kconfig symbols instead of the ARCH_* symbols to
> control compilation in the Makefile,
>   - Always entering drivers/clk/renesas/ during the build.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: cs2000: Fix the setting of saved_rate during the resume process

[Stephen Boyd]

On 04/23, Geert Uytterhoeven wrote:
> Hi Stephen,
> 
> On Sat, Apr 22, 2017 at 4:10 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> > On 04/20, Yoshihiro Kaneko wrote:
> >> From: Gaku Inami <gaku.inami...@bp.renesas.com>
> >>
> >> In the resume process, there is the case that other drivers call
> >> cs2000_enable before cs2000_resume is called. Since the order of
> >> resume process is not guaranteed, it is needed to reset the clk
> >> rate in any cases before cs2000 is used.
> >>
> >> Also, the current cs2000 driver is using resume_early function.
> >> The using .resume_early is bad idea because the dependency with
> >> other drivers is to be complicated.
> >>
> >> This patch adds to reset the clk rate in cs2000_enable and
> >> changes to use from .resume_early to .resume.
> >>
> >> Signed-off-by: Gaku Inami <gaku.inami...@bp.renesas.com>
> >> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama...@renesas.com>
> >> Signed-off-by: Yoshihiro Kaneko <ykaneko0...@gmail.com>
> >> ---
> >
> > Was this supposed to be sent as a series? This is the second
> > patch in the series?
> >
> > In what situation does a driver call clk_prepare() on the clocks
> > in here before the device's resume callback is called? I would
> > think that any devices that use the clks provided by this driver
> > would be probe defered until the clks are registered, so they
> > would be later in the suspend/resume list than this clk driver?
> 
> Deferred probing is used during driver initialization only.
> This patch is about clock users calling into the clock API during the resume
> procedure, before the clock provider has been resumed.
> 

Right, and which driver is calling into the clk API in their
resume function before the clk provider is resume? Presumably the
clk provider had probed "first", or at least was ordered in the
dpm_list before the consumer drivers so that this problem
wouldn't happen.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: cs2000: Fix the setting of saved_rate during the resume process

[Stephen Boyd]

On 04/20, Yoshihiro Kaneko wrote:
> From: Gaku Inami 
> 
> In the resume process, there is the case that other drivers call
> cs2000_enable before cs2000_resume is called. Since the order of
> resume process is not guaranteed, it is needed to reset the clk
> rate in any cases before cs2000 is used.
> 
> Also, the current cs2000 driver is using resume_early function.
> The using .resume_early is bad idea because the dependency with
> other drivers is to be complicated.
> 
> This patch adds to reset the clk rate in cs2000_enable and
> changes to use from .resume_early to .resume.
> 
> Signed-off-by: Gaku Inami 
> Signed-off-by: Hiroyuki Yokoyama 
> Signed-off-by: Yoshihiro Kaneko 
> ---

Was this supposed to be sent as a series? This is the second
patch in the series? 

In what situation does a driver call clk_prepare() on the clocks
in here before the device's resume callback is called? I would
think that any devices that use the clks provided by this driver
would be probe defered until the clks are registered, so they
would be later in the suspend/resume list than this clk driver?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: rcar-gen3: Add Z clock divider support

[Stephen Boyd]

On 04/21, Geert Uytterhoeven wrote:
> 
> > --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> > +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> 
> > +static unsigned long cpg_z_clk_recalc_rate(struct clk_hw *hw,
> > +  unsigned long parent_rate)
> > +{
> > +   struct cpg_z_clk *zclk = to_z_clk(hw);
> > +   unsigned int mult;
> > +   unsigned int val;
> > +   unsigned long rate;
> > +
> > +   val = (clk_readl(zclk->reg) & CPG_FRQCRC_ZFC_MASK)
> > +   >> CPG_FRQCRC_ZFC_SHIFT;
> > +   mult = 32 - val;
> > +
> > +   rate = div_u64((u64)parent_rate * mult + 16, 32);
> > +   /* Round to closest value at 100MHz unit */
> > +   rate = 1*DIV_ROUND_CLOSEST(rate, 1);
> 
> Mike, Stephen: what's your opinion about such rounding tricks?
> 

What's wrong with the true rate? I'd prefer we calculate the true
rate unless there's some reason. Typically that's what a comment
is for, not to explain what the code is doing which is usually
self evident from reading it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 0/3] clk: cs2000: tidyup missing settings

[Stephen Boyd]

On 04/18, Kuninori Morimoto wrote:
> 
> Hi Stephen
> 
> These are missing settings for current cs2000.
> it is working without these settings, thus, not urgent.
> But, necessary for correct/safety operation.

Thanks. Applied all to clk-next. 

> 
> Kuninori Morimoto (3):
>   clk: cs2000: enable clock skipping mode
>   clk: cs2000: tidyup DEVICE_CFG2 settings
>   clk: cs2000: select 12.20 High Accuracy on LFRatioCfg
> 
>  drivers/clk/clk-cs2000-cp.c | 25 ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> -- 
> 1.9.1
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] clk: cs2000: use existing priv_to_dev() to getting struct device

[Stephen Boyd]

On 04/11, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> Signed-off-by: Kuninori Morimoto 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] cs-2000-cp: keep Reserved bit on each register

[Stephen Boyd]

On 04/05, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> Thus CS2000 datasheet is indicating below, this patch
> follows it.
> 
> WARNING: All "Reserved" registers must maintain their default
>  state to ensure proper functional operation.
> 
> Signed-off-by: Kuninori Morimoto 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.12 (take two)

[Stephen Boyd]

On 04/05, Geert Uytterhoeven wrote:
> Hi Stephen,
> 
> On Wed, Apr 5, 2017 at 9:56 PM, Stephen Boyd <sb...@codeaurora.org> wrote:
> > On 03/31, Geert Uytterhoeven wrote:
> >> The following changes since commit 
> >> cecbe87d73006cb321dec79b349e3fefd1a80962:
> >>
> >>   clk: renesas: rcar-gen3: Add workaround for PLL0/2/4 errata on H3 ES1.0 
> >> (2017-03-21 11:12:23 +0100)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> >> tags/clk-renesas-for-v4.12-tag2
> >>
> >> for you to fetch changes up to bb1953067c05be30a605ee1d5b05a2677735bb37:
> >>
> >>   clk: renesas: rcar-gen3-cpg: Add support for RCLK on R-Car H3 ES2.0 
> >> (2017-03-30 13:26:02 +0200)
> >>
> >> 
> >> clk: renesas: Updates for v4.12 (take two)
> >>
> >>   - Add support for the Clock Pulse Generator / Module Standby and
> >> Software Reset module on revision ES2.0 of the R-Car H3 SoC, which
> >> differs from ES1.x in some areas.
> >>
> >> Note that this pull request is on top of my previous pull request for
> >> v4.12, which accidentally had a wrong version number in the subject
> >> line, and which I believe you haven't pulled yet.
> >
> > Thanks. I pulled both by pulling this one tag.
> 
> Thanks, but if you pull the second tag only, you don't record the contents
> of the first tag, do you?
> 

I copied the words into the commit message. Not sure anyone cares
that the first tag signature is lost.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.12 (take two)

[Stephen Boyd]

On 03/31, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit cecbe87d73006cb321dec79b349e3fefd1a80962:
> 
>   clk: renesas: rcar-gen3: Add workaround for PLL0/2/4 errata on H3 ES1.0 
> (2017-03-21 11:12:23 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.12-tag2
> 
> for you to fetch changes up to bb1953067c05be30a605ee1d5b05a2677735bb37:
> 
>   clk: renesas: rcar-gen3-cpg: Add support for RCLK on R-Car H3 ES2.0 
> (2017-03-30 13:26:02 +0200)
> 
> 
> clk: renesas: Updates for v4.12 (take two)
> 
>   - Add support for the Clock Pulse Generator / Module Standby and
> Software Reset module on revision ES2.0 of the R-Car H3 SoC, which
> differs from ES1.x in some areas.
> 
> Note that this pull request is on top of my previous pull request for
> v4.12, which accidentally had a wrong version number in the subject
> line, and which I believe you haven't pulled yet.

Thanks. I pulled both by pulling this one tag.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] cs-2000-cp: keep Reserved bit on each register

[Stephen Boyd]

On 04/05, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> Thus CS2000 datasheet is indicating below, this patch
> follows it.
> 
> WARNING: All "Reserved" registers must maintain their default
>  state to ensure proper functional operation.
> 
> Signed-off-by: Kuninori Morimoto 

Is this v2? I see two of these from different days.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 0/3] arm: dts: renesas: Drop _clk suffix from clock node names

[Stephen Boyd]

On 04/03, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> The current practice is to not add _clk suffixes to clock node names in
> DT, as these names are used as the actual clock names.
> 
> This patch removes the remaining offenders in the various Renesas DTSes.
> 

This changes the names in the clk framework too though? If you're
ok with that I'm ok too.

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.11 (take two)

[Stephen Boyd]

On 01/27, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit e6bdf28eff475a026b922abe78ae710e7179bdf7:
> 
>   clk: renesas: r8a7796: Add MSIOF controller clocks (2016-12-27 10:56:08 
> +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.11-tag2
> 
> for you to fetch changes up to d963654e109565cf73399815d7585917f2d69a30:
> 
>   clk: renesas: r8a7796: Add IIC-DVFS clock (2017-01-27 08:59:24 +0100)
> 
> 
> clk: renesas: Updates for v4.11 (take two)
> 
>   - Use CLK_IS_CRITICAL to handle critical clocks,
>   - Add Reset Control Support for R-Car Gen2 and Gen3, and RZ/G1,
>   - Add IIC-DVFS clocks for R-Car H3 and M3-W,
>   - Minor cleanups.
> 

Thanks. Pulled into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: mstp: Reformat cpg_mstp_clock_register() for git diff

[Stephen Boyd]

On 01/23, Geert Uytterhoeven wrote:
> As the function header of cpg_mstp_clock_register() is split in an
> unusual way, "git diff" gets confused when changes to the body of
> the function are made, and attributes them to the wrong function.
> 
> Reformat the function header to fix this.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

I'm not sure it's really necessary, but ok.

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 4/8] clk: renesas: cpg-mssr: Add support for reset control

[Stephen Boyd]

On 01/20, Geert Uytterhoeven wrote:
> Add optional support for the Reset Control feature of the Renesas Clock
> Pulse Generator / Module Standby and Software Reset module on R-Car
> Gen2, R-Car Gen3, and RZ/G1 SoCs.
> 
> This allows to reset SoC devices using the Reset Controller API.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 3/8] clk: renesas: cpg-mssr: Rename cpg_mssr_priv.mstp_lock

[Stephen Boyd]

On 01/20, Geert Uytterhoeven wrote:
> The spinlock is used to protect Read-Modify-Write register accesses,
> which won't be limited to SMSTPCR register accesses.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/8] clk: renesas: cpg-mssr: Document suitability for RZ/G1

[Stephen Boyd]

On 01/20, Geert Uytterhoeven wrote:
> The Renesas CPG/MSSR driver is already in active use for RZ/G1 since
> commits c0b2d75d2a4bf6a3 ("clk: renesas: cpg-mssr: Add R8A7743 support")
> and 9127d54bb8947159 ("clk: renesas: cpg-mssr: Add R8A7745 support").
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/8] clk: renesas: cpg-mssr: Document reset control support

[Stephen Boyd]

On 01/20, Geert Uytterhoeven wrote:


> Document properties needed to use the Reset Control feature of the
> Renesas Clock Pulse Generator / Module Standby and Software Reset
> module.
> 
> Signed-off-by: Geert Uytterhoeven 

Subject should be "dt-bindings: clock:" ?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: cs2000: add Suspend/Redume feature

[Stephen Boyd]

On 01/10, Kuninori Morimoto wrote:
> From: Khiem Nguyen 
> 
> CS2000 needs re-setup when redume, otherwise, it can't
> handle correct clock rate.
> 
> Signed-off-by: Khiem Nguyen 
> [Kuninori: cleanup original patch]
> Signed-off-by: Kuninori Morimoto 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V6 2/2] clk: vc5: Add support for IDT VersaClock 5P49V5923 and 5P49V5933

[Stephen Boyd]

On 01/12, Marek Vasut wrote:
> Add driver for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips. These
> chips have two clock inputs, XTAL or CLK, which are muxed into single
> PLL/VCO input. In case of 5P49V5923, the XTAL in built into the chip
> while the 5P49V5923 requires external XTAL.
> 
> The PLL feeds two fractional dividers. Each fractional divider feeds
> output mux, which allows selecting between clock from the fractional
> divider itself or from output mux on output N-1. In case of output
> mux 0, the output N-1 is instead connected to the output from the mux
> feeding the PLL.
> 
> The driver thus far supports only the 5P49V5923 and 5P49V5933, while
> it should be easily extensible to the whole 5P49V59xx family of chips
> as they are all pretty similar.
> 
> Signed-off-by: Marek Vasut <marek.va...@gmail.com>
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> Tested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.11

[Stephen Boyd]

On 01/13, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
> 
>   Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.11-tag1
> 
> for you to fetch changes up to e6bdf28eff475a026b922abe78ae710e7179bdf7:
> 
>   clk: renesas: r8a7796: Add MSIOF controller clocks (2016-12-27 10:56:08 
> +0100)
> 

Thanks. Pulled into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/2] clk: renesas: mstp: Make INTC-SYS a critical clock

[Stephen Boyd]

On 01/17, Geert Uytterhoeven wrote:
> INTC-SYS is the module clock for the GIC.  Accessing the GIC while it is
> disabled causes:
> 
> Unhandled fault: asynchronous external abort (0x1211) at 0x
> 
> Currently, the GIC-400 driver cannot enable its module clock for several
> reasons:
>   - It does not use a platform device, so Runtime PM is not an option,
>   - gic_of_init() runs before any clocks are registered, so it cannot
> enable the clock explicitly,
>   - gic_of_init() cannot return -EPROBE_DEFER, as IRQCHIP_DECLARE()
> doesn't support deferred probing.
> 
> Hence we have to keep on relying on the boot loader for enabling the
> module clock.
> 
> To prevent the module clock from being disabled when the CCF core thinks
> it is unused, and thus causing a system lock-up, add a check to the MSTP
> clock driver and enable CLK_IS_CRITICAL. This will make sure the module
> clock is never disabled.
> 
> This is a hard dependency for describing the INTC-SYS clock in DT on
> R-Mobile APE6 and R-Car Gen2.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

> diff --git a/drivers/clk/renesas/clk-mstp.c b/drivers/clk/renesas/clk-mstp.c
> index 937576d99407..c0319b8acf3521a2 100644
> --- a/drivers/clk/renesas/clk-mstp.c
> +++ b/drivers/clk/renesas/clk-mstp.c
> @@ -144,6 +144,11 @@ static int cpg_mstp_clock_is_enabled(struct clk_hw *hw)

Sad that git gets confused about which function this is in.

>   init.name = name;
>   init.ops = _mstp_clock_ops;
>   init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT;
> + /* INTC-SYS is the module clock of the GIC, and must not be disabled */
> + if (!strcmp(name, "intc-sys")) {
> + pr_debug("MSTP %s setting CLK_IS_CRITICAL\n", name);
> + init.flags |= CLK_IS_CRITICAL;
> + }
>   init.parent_names = _name;
>   init.num_parents = 1;
>  

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 0/2] clk: renesas: Use CLK_IS_CRITICAL to handle critical clocks

[Stephen Boyd]

On 01/17, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> This patch series adds support for the CLK_IS_CRITICAL flag to drivers
> for module clocks on Renesas ARM SoCs.  For now, this is used to prevent
> disabling of the ARM GIC module clock, which would lead to a system
> lock-up when accessing the GIC's registers.
> 
>   1. The first patch migrates the Renesas CPG/MSSR driver from the
>  never merged CLK_ENABLE_HAND_OFF flag to the CLK_IS_CRITICAL flag.
>  Note that as the driver already handled critical clocks (i.e. it
>  ignored them :-), this is not a prerequisite for linking the GIC to
>  its module clock in DT.
> 
>   2. The second patch makes sure the CLK_IS_CRITICAL flag is set for the
>  INTC-SYS clock on SoCs not (yet) using the Renesas CPG/MSSR driver.
>  Note that this is a hard dependency for describing the INTC-SYS
>  clock in DT on R-Mobile APE6 and R-Car Gen2.
> 
> I plan to queue these patches in my clk-renesas-for-v4.11 branch, if
> you agree.
> 

Would the runtime PM patches for ccf make things any better here?
I still plan to support CLK_ENABLE_HAND_OFF somehow, but it's not
at the top of my priority list right now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] clk: renesas: cpg-mssr: Migrate to CLK_IS_CRITICAL

[Stephen Boyd]

On 01/17, Geert Uytterhoeven wrote:
> When the Renesas CPG/MSSR driver was introduced, it was anticipated that
> critical clocks would be handled through a new CLK_ENABLE_HAND_OFF flag
> soon.  However, CLK_ENABLE_HAND_OFF never made it upstream.
> 
> Instead, commit 32b9b10961860860 ("clk: Allow clocks to be marked as
> CRITICAL") introduced CLK_IS_CRITICAL, a flag with slightly differing
> semantics.  Still, it can be used to prevent e.g. the GIC module clock
> from being turned off, until the GIC-400 driver has full support for
> Runtime PM.
> 
> Hence migrate the Renesas CPG/MSSR driver from CLK_ENABLE_HAND_OFF to
> CLK_IS_CRITICAL.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: vc5: Add support for IDT VersaClock 5P49V5923B

[Stephen Boyd]

On 01/10, Marek Vasut wrote:
> On 01/10/2017 01:23 AM, Stephen Boyd wrote:
> > On 01/05, Marek Vasut wrote:
> >> On 01/05/2017 03:13 PM, Laurent Pinchart wrote:
> >>> Hi Marek,
> >>
> >> Hi!
> >>
> >> [...]
> >>
> >>>>>>> +static unsigned long vc5_mux_recalc_rate(struct clk_hw *hw,
> >>>>>>> +unsigned long parent_rate)
> >>>>>>> +{
> >>>>>>> +   struct vc5_driver_data *vc5 =
> >>>>>>> +   container_of(hw, struct vc5_driver_data, clk_mux);
> >>>>>>> +   unsigned long idiv;
> >>>>>>> +   u8 div;
> >>>>>>> +
> >>>>>>> +   /* FIXME: Needs locking ? */
> >>>>>
> >>>>> Let's fix it then :-)
> >>>>
> >>>> I would like to get feedback on this one, does it ?
> >>>
> >>> That's a question for Mike or Stephen I believe.
> >>
> >> OK
> > 
> > What's the question?
> 
> Whether or not I need a lock around the code in vc5_mux_recalc_rate(),
> since I am also tweaking the predivider bits there to assure the
> (downstream) PLL supplied from the mux always gets clock in range it can
> handle. This tweaking is mostly inspired by clk-si5351.c driver.

Don't rely on locking in the core for register locking within a
device. That makes a dependency headache if we want to rework the
locking scheme in the core, which we want to do eventually.

Also, please don't cause side effects during recalc_rate(). The
callback is meant to calculate the rate of the clock, not adjust
hardware based on what arguments are passed to it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: vc5: Add support for IDT VersaClock 5P49V5923B

[Stephen Boyd]

On 01/05, Marek Vasut wrote:
> On 01/05/2017 03:13 PM, Laurent Pinchart wrote:
> > Hi Marek,
> 
> Hi!
> 
> [...]
> 
> > +static unsigned long vc5_mux_recalc_rate(struct clk_hw *hw,
> > +unsigned long parent_rate)
> > +{
> > +   struct vc5_driver_data *vc5 =
> > +   container_of(hw, struct vc5_driver_data, clk_mux);
> > +   unsigned long idiv;
> > +   u8 div;
> > +
> > +   /* FIXME: Needs locking ? */
> >>>
> >>> Let's fix it then :-)
> >>
> >> I would like to get feedback on this one, does it ?
> > 
> > That's a question for Mike or Stephen I believe.
> 
> OK

What's the question?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: renesas: mstp: Support 8-bit registers for r7s72100

[Stephen Boyd]

On 12/21, Chris Brandt wrote:
> On December 21, 2016, Geert Uytterhoeven wrote:
> > >> Mike/Stephen: as this is a fix for stable (v3.16+), can you please
> > >> take it directly?
> > >
> > > Sure, is it a fix for something that has been exposed as a problem in
> > > this merge window? Just trying to gauge the urgency of merging this.
> > 
> > No, I don't think it has been exposed by changes in this merge window (the
> > only RZ/A1 changes were the enablement of SDHI and MMC).
> > Chris, can you please confirm?
> 
> That's correct. In reality, none of the existing RZ/A1 drivers in the kernel
> should have ever worked (ETH, SPI, I2C, MTU2, etc...) because on chip reset
> all the peripheral clocks are turned off.
> 
> However...like Geert mentioned...the boot loader was turning everything on
> shortly after reset so even though the clock driver never worked, it made
> it seems so. Oops.
> 
> Of course now going forward, I use a modified boot loader to turn everything
> back off (except the serial console) so I can confirm that clock gating is
> really working.
> 

Ok, it seems like a more urgent fix due to the fact that the
bootloader update has caused the drivers to stop working. I'll
make sure to send it as a fix this release cycle.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: renesas: mstp: Support 8-bit registers for r7s72100

[Stephen Boyd]

On 12/15, Chris Brandt wrote:
> The RZ/A1 is different than the other Renesas SOCs because the MSTP
> registers are 8-bit instead of 32-bit and if you try writing values as
> 32-bit nothing happens...meaning this driver never worked for r7s72100.
> 
> Fixes: b6face404f38 ("ARM: shmobile: r7s72100: add essential clock nodes to 
> dtsi")
> Signed-off-by: Chris Brandt 
> ---

Applied to clk-fixes

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: renesas: mstp: Support 8-bit registers for r7s72100

[Stephen Boyd]

On 12/19, Geert Uytterhoeven wrote:
> Hi Chris, Mike, Stephen,
> 
> On Thu, Dec 15, 2016 at 6:00 PM, Chris Brandt  
> wrote:
> > The RZ/A1 is different than the other Renesas SOCs because the MSTP
> > registers are 8-bit instead of 32-bit and if you try writing values as
> > 32-bit nothing happens...meaning this driver never worked for r7s72100.
> 
> Thanks for your patch!
> 
> The only reason it ever worked was that almost all module clocks are
> enabled at boot time...
> 
> > Fixes: b6face404f38 ("ARM: shmobile: r7s72100: add essential clock nodes to 
> > dtsi")
> > Signed-off-by: Chris Brandt 
> 
> Reviewed-by: Geert Uytterhoeven 
> Tested-by: Geert Uytterhoeven 
> 
> Mike/Stephen: as this is a fix for stable (v3.16+), can you please take it
> directly?

Sure, is it a fix for something that has been exposed as a
problem in this merge window? Just trying to gauge the urgency of
merging this.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.10 (take two)

[Stephen Boyd]

On 11/07, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit dbdcc4f996df280eb2758095b4774ea62da8a2a7:
> 
>   clk: renesas: r8a7796: Add DU and LVDS clocks (2016-11-02 20:40:08 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.10-tag2
> 
> for you to fetch changes up to 1936be95e013802291201c1ed193e04fd1ed3d13:

Ok. Pulled into clk-next. I'm a little wary here as I haven't
seen any indication from arm-soc maintainers (not Simon) that
they'll take this cross tree merge. I guess we'll see how it
goes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.10 (take one)

[Stephen Boyd]

On 11/14, Geert Uytterhoeven wrote:
> Hi Stephen,
> 
> On Fri, Nov 11, 2016 at 12:35 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> > On 11/07, Geert Uytterhoeven wrote:
> >> clk: renesas: Updates for v4.10 (take one)
> >>
> >>   - SYS-DMAC, (H)SCIF, I2C, DRIF, and graphics related clocks for R-Car
> >> M3-W,
> >>   - Minor fixes and cleanups.
> >>
> >> Thanks for pulling!
> >> 
> >> Geert Uytterhoeven (4):
> >>   clk: renesas: cpg-mssr: Always use readl()/writel()
> >>   clk: renesas: rcar-gen3-cpg: Always use readl()/writel()
> >>   clk: renesas: cpg-mssr: Fix inverted debug check
> >
> > Hm.. I already applied this one to clk-next. If you're going to
> > apply patches can you please indicate if they've been picked up
> > and/or not send them To: Mike and I, please?
> 
> Sorry, I'll be more clear in the future.
> 
> I believe this is not a blocker for pulling, is it?

No I guess not. Pulled into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.10 (take one)

[Stephen Boyd]

On 11/07, Geert Uytterhoeven wrote:
> clk: renesas: Updates for v4.10 (take one)
> 
>   - SYS-DMAC, (H)SCIF, I2C, DRIF, and graphics related clocks for R-Car
> M3-W,
>   - Minor fixes and cleanups.
> 
> Thanks for pulling!
> 
> Geert Uytterhoeven (4):
>   clk: renesas: cpg-mssr: Always use readl()/writel()
>   clk: renesas: rcar-gen3-cpg: Always use readl()/writel()
>   clk: renesas: cpg-mssr: Fix inverted debug check

Hm.. I already applied this one to clk-next. If you're going to
apply patches can you please indicate if they've been picked up
and/or not send them To: Mike and I, please?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
> 
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
> 
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
> 
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
> 
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
> 
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
> 
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
> 
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
> 

TL;DR: Sounds fine, I'll be on the lookout for the PR.

Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.

So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like 

if (rcar_rst_read_mode_pins())
return;

with

if (rcar_rst_read_mode_pins() != -ENODEV)
return;


Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.

In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: cpg-mssr: Fix inverted debug check

[Stephen Boyd]

On 10/04, Geert Uytterhoeven wrote:
> The intention was to enable the checks if debugging is enabled, not
> disabled.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: r8a7796: Add DRIF clock

[Stephen Boyd]

On 10/13, Ramesh Shanmugasundaram wrote:
> This patch adds DRIF module clocks for r8a7796 SoC.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> <ramesh.shanmugasunda...@bp.renesas.com>
> ---

Doesn't apply to clk-next so I assume Geert will pick it up?

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Stephen Boyd]

On 10/31, Geert Uytterhoeven wrote:
> Hi Mike, Stephen, Arnd, Olof, Kevin,
> 
> Is the merge strategy [see # below] OK for you?
> Thanks a lot!
> 
> On Mon, Oct 31, 2016 at 9:19 AM, Simon Horman  wrote:
> > On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> >> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> >>  wrote:
> >> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> >> > state of the mode pins either by a call from the platform code, or
> >> > directly by using a hardcoded register access. This is a bit messy, and
> >> > creates a dependency between driver and platform code.
> >> >
> >> > This patch series converts the various Renesas R-Car clock drivers
> >> > and support code from reading the mode pin states using a hardcoded
> >> > register access to using a new minimalistic R-Car RST driver.
> >> >
> >> > All R-Car clock drivers will rely on the presence in DT of a device node
> >> > for the RST module.  Backwards compatibility with old DTBs is retained
> >> > only for R-Car Gen2, which has fallback code using its own private copy
> >> > of rcar_gen2_read_mode_pins().
> >> >
> >> > After this, there is still one remaining user of
> >> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> >> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> >> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> >> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> >> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >> >
> >> > This series consists of 5 parts:
> >> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >> >  driver,
> >> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >> >  files,
> >> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >> >  RST driver,
> >> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >> >  from the platform code,
> >> >   E. Patches 21-23 remove dead code from the clock drivers.
> >> >
> >> > As is usually the case with moving functionality from platform code to
> >> > DT, there are lots of hard dependencies:
> >> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >> > Part A have been approved,
> >> >   - The clock driver updates in Part C depend functionally on the driver
> >> > code in Part A, and on the DT updates in Part B,
> >> >   - The board code cleanups in Part D depend on the clock driver updates
> >> > in Part C,
> >> >   - The block driver cleanups in part E depend on the board code
> >> > cleanups in part D.
> >> >
> >> > Hence to maintain the required lockstep between SoC driver, clock
> >> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> >> > all patches in a single branch against v4.9-rc1, and send pull requests
> >> > to both Mike/Stephen (clock) and Simon (rest).
> >> >
> >> > ***
> >>
> >> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >> > approach above?
> >>
> >> Is this OK for you?
> 
> #
> 
> (link to the full series at
>  https://groups.google.com/forum/#!topic/linux.kernel/fLSFsjOgPT8)

Would the pull requests for clk also have dts changes at the base
of the tree? Perhaps clk side can just ack the clk patches and
then have it all routed through arm-soc? The only worry I have is
if we need to make some sort of change in clk side that conflicts
with these changes. I don't usually like taking dts changes
through clk tree, so I'd like to avoid that if possible.

Part E could happen anytime after everything else happens, so
that doesn't seem like a concern. Part C could also be made to
only call into the new reset drivers if the reset dts nodes are
present? If that's done then we could merge clk patches anytime
and remove the dead code and the node search at some later time
when everything has settled?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 0/2] clk: renesas: cpg-mssr: Always use readl()/writel()

[Stephen Boyd]

On 09/23, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The Renesas CPG/MSSR clock drivers use a mix of clk_readl()/clk_writel()
> and readl()/writel() to access the clock registers. Settle on the
> generic readl()/writel().
> 
> I plan to queue this up in clk-renesas-for-v4.10.
> 
> Geert Uytterhoeven (2):
>   clk: renesas: cpg-mssr: Always use readl()/writel()
>   clk: renesas: rcar-gen3-cpg: Always use readl()/writel()
> 
>  drivers/clk/renesas/rcar-gen3-cpg.c| 14 +++---
>  drivers/clk/renesas/renesas-cpg-mssr.c |  9 -
>  2 files changed, 11 insertions(+), 12 deletions(-)
> 

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.9 (take three)

[Stephen Boyd]

On 09/14, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit 074969813350cda4c624a585489cc1b3550414bc:
> 
>   clk: renesas: r8a7796: Add SDIF clocks (2016-08-23 10:30:41 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.9-tag3
> 
> for you to fetch changes up to 5fad71f58f4c236118358c98f65a7251e9c718f7:
> 
>   clk: renesas: r8a7796: Add CMT clocks (2016-09-12 11:08:01 +0200)

Thanks. Pulled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] MAINTAINERS: Add section for Renesas clock drivers

[Stephen Boyd]

On 08/31, Geert Uytterhoeven wrote:
> Add a section for Renesas clock drivers, as found on Renesas ARM SoCs,
> and list myself as the maintainer.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.9 (take two)

[Stephen Boyd]

On 08/30, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit b51d5275016c6edbf4656eaee30d836fef127016:
> 
>   clk: renesas: r8a7796: Add watchdog module clock (2016-08-09 09:53:47 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.9-tag2
> 
> for you to fetch changes up to 074969813350cda4c624a585489cc1b3550414bc:
> 
>   clk: renesas: r8a7796: Add SDIF clocks (2016-08-23 10:30:41 +0200)
> 
> 
> clk: renesas: r8a7796: Add SDHI clocks
> 
> Add all clocks needed to use the SDHI interfaces on the Renesas R-Car M3-W
> (r8a7796) SoC.
> 

Thanks. Pulled into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.9

[Stephen Boyd]

On 08/17, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
> 
>   Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.9-tag1
> 
> for you to fetch changes up to b51d5275016c6edbf4656eaee30d836fef127016:
> 
>   clk: renesas: r8a7796: Add watchdog module clock (2016-08-09 09:53:47 +0200)
> 
> 
> clk: renesas: r8a7796: Add watchdog clocks
> 
> Add all clocks related to the Watchdog Timer (WDT) controller on the
> Renesas R-Car M3-W (r8a7796) SoC.
> 

Pulled into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: r8a7795: Fix SD clocks

[Stephen Boyd]

On 08/10, Geert Uytterhoeven wrote:
> From: Yoshihiro Shimoda 
> 
> According to the datasheet, SDn clocks are from the SDSRC clock. And
> the SDSRC has a 1/2 divider. So, we should have ".sdsrc" as an internal
> core clock. Otherwise, since the sdhi driver will calculate clock for
> a sd card using the wrong parent clock rate, and then performance will
> be not good.
> 
> Fixes: 90c073e53909da85 ("clk: shmobile: r8a7795: Add SD divider support")
> Signed-off-by: Yoshihiro Shimoda 
> Acked-by: Dirk Behme 
> Tested-by: Wolfram Sang 
> Signed-off-by: Geert Uytterhoeven 
> Cc: sta...@vger.kernel.org
> ---

Applied to clk-fixes

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.8 (take two)

[Stephen Boyd]

On 06/29, Geert Uytterhoeven wrote:
> 
> Thanks, but it seems something went wrong: commit d9cce3a8ebb871c5 is not a
> merge commit, but the combination of all 7 commits from the pull request?

Hmm... weird. I fixed it now.

> 
> > unless you really need it. Just use readl/writel directly. I
> > should put a big fat warning over those functions that they
> > shouldn't be used.
> 
> Hence all users under drivers/clk/renesas/ should be converted to readl()?

Probably.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.8 (take two)

[Stephen Boyd]

On 06/23, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit e4e2d7c388350eba8b1dbc2569441ac9b545a8c4:
> 
>   clk: renesas: cpg-mssr: Add support for R-Car M3-W (2016-06-06 11:58:35 
> +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.8-tag2
> 
> for you to fetch changes up to e4c82863fd17bacb60080481c11eb0303d3f83d0:
> 
>   clk: renesas: r8a7795: Add THS/TSC clock (2016-06-21 09:21:06 +0200)
> 
> 
> clk: renesas: Updates for v4.8 (take two)
> 
>   - Add support for R-Car V2H,
>   - Add FDP1, DRIF, and thermal clocks on R-Car H3,
>   - Correct a wrong parent clock.
> 
> This pull request is based on my previous request "[git pull] clk:
> renesas: Add support for R-Car M3-W".
> For proper merge history (auto-grabbing the commit message from the
> signed tag), you should pull tags/clk-renesas-for-v4.8-tag1 first.
> As  is a hard dependency for the
> initial r8a7796.dtsi file, I would appreciate if you could do that
> sooner rather than later, so Simon can pull it as well, and start
> queueing up the DT files for R-Car M3-W, which need to go through
> arm-soc.

Thanks. Pulled into clk-next. BTW, please don't use clk_readl()
unless you really need it. Just use readl/writel directly. I
should put a big fat warning over those functions that they
shouldn't be used.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Add support for R-Car M3-W

[Stephen Boyd]

On 06/28, Geert Uytterhoeven wrote:
> It is not; there's just a second pull request with more commits on top.
> 
> I think you best pull this one first, as git will use the summary from the
> signed tag. The signed tag of the second pull request only summarizes
> the additions, compared to the first tag.
> 

Ok. Pulled into clk-next. Thanks.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Add support for R-Car M3-W

[Stephen Boyd]

On 06/21, Geert Uytterhoeven wrote:
> Hi Stephen,
> 
> On Tue, Jun 21, 2016 at 2:51 AM, Stephen Boyd <sb...@codeaurora.org> wrote:
> > On 06/06, Geert Uytterhoeven wrote:
> >>   Hi Mike, Stephen,
> >>
> >> The following changes since commit 
> >> 1a695a905c18548062509178b98bc91e67510864:
> >>
> >>   Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> >> tags/clk-renesas-for-v4.8-tag1
> >>
> >> for you to fetch changes up to e4e2d7c388350eba8b1dbc2569441ac9b545a8c4:
> >>
> >>   clk: renesas: cpg-mssr: Add support for R-Car M3-W (2016-06-06 11:58:35 
> >> +0200)
> >>
> >
> > Checkpatch complains...
> >
> > ERROR: Use of const init definition must use __initconst
> > #712: FILE: drivers/clk/renesas/rcar-gen3-cpg.c:248:
> > +static const struct rcar_gen3_cpg_pll_config *cpg_pll_config __initdata;
> >
> > Seems like a valid problem. Any chance it can be fixed?
> 
> It is a false positive: the data pointed to is const, the pointer
> variable isn't.
> 

Argh thanks. It would be nice if sparse complained about that
instead of checkpatch so that we got a better parse on the actual
type that is marked initdata. Anyway, I see this pull is
superseded now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Add support for R-Car M3-W

[Stephen Boyd]

On 06/06, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
> 
>   Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.8-tag1
> 
> for you to fetch changes up to e4e2d7c388350eba8b1dbc2569441ac9b545a8c4:
> 
>   clk: renesas: cpg-mssr: Add support for R-Car M3-W (2016-06-06 11:58:35 
> +0200)
> 

Checkpatch complains...

ERROR: Use of const init definition must use __initconst
#712: FILE: drivers/clk/renesas/rcar-gen3-cpg.c:248:
+static const struct rcar_gen3_cpg_pll_config *cpg_pll_config __initdata;

Seems like a valid problem. Any chance it can be fixed?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.7 (take three)

[Stephen Boyd]

On 05/02, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
>   Hi Mike, Stephen,
> 
> The following changes since commit 2066390ad47b374f3d35075a32325b47d15bf735:
> 
>   clk: renesas: cpg-mssr: Export cpg_mssr_{at,de}tach_dev() (2016-04-20 
> 09:17:07 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.7-tag3
> 
> for you to fetch changes up to d04a75af450782db2937603bb6706bf6fa7c6f37:
> 
>   clk: renesas: cpg-mssr: Use always-on governor for Clock Domain (2016-04-28 
> 10:32:55 +0200)
> 
> 
> clk: renesas: Updates for v4.7 (take three)
> 
>   - Support for CSI2 and VIN module clocks on R-Car H3,
>   - Renesas CPG/MSTP and CPG/MSSR Clock Domain fixes.
> 

Thanks. Pulled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: R-Car SYSC PM Domain Preparation

[Stephen Boyd]

On 04/20, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
>   Hi Mike, Stephen,
> 
> The following changes since commit 12a56817b329d8a73ab53bad09aa976aeea46db9:
> 
>   clk: renesas: mstp: Clarify cpg_mstp_{at,de}tach_dev() domain parameter 
> (2016-04-07 17:27:13 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.7-tag2
> 
> for you to fetch changes up to 2066390ad47b374f3d35075a32325b47d15bf735:
> 
>   clk: renesas: cpg-mssr: Export cpg_mssr_{at,de}tach_dev() (2016-04-20 
> 09:17:07 +0200)
> 
> 
> clk: renesas: R-Car SYSC PM Domain Preparation
> 
>   - Export the CPG/MSSR and CPG/MSTP attach/detach_dev callbacks, so
> they can be called by the R-Car SYSC PM Domain driver.
> 
> As this is a hard dependency for R-Car SYSC PM Domains, I would
> appreciate if you could pull this sooner rather than later, so Simon can
> pull it as well, and queue on top of it the bulk of the R-Car SYSC PM
> Domain work, and enablement of DU and VSP on R-Car H3 which depends on
> these PM Domains.
> 

Thanks for the tag! Pulled into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: let clk_disable() return immediately if clk is NULL or error

[Stephen Boyd]

On 04/14, Masahiro Yamada wrote:
> 
> OK, now I notice another problem in my code;
> if foo_clk_init() fails for reason [2],
> clk_disable() WARN's due to zero enable_count.
> 
> if (WARN_ON(core->enable_count == 0))
>  return;
> 
> 
> 
> Perhaps, I got screwed up by splitting clock init stuff
> into a helper function.

Yep! Can't we just split the enable/disable out into another
function separate from the clk_get/put part? That would make
things more symmetric and avoid this problem.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: let clk_disable() return immediately if clk is NULL or error

[Stephen Boyd]

On 04/05, Masahiro Yamada wrote:
> The clk_disable() in the common clock framework (drivers/clk/clk.c)
> returns immediately if a given clk is NULL or an error pointer.  It
> allows clock consumers to call clk_disable() without IS_ERR_OR_NULL
> checking if drivers are only used with the common clock framework.
> 
> Unfortunately, NULL/error checking is missing from some of non-common
> clk_disable() implementations.  This prevents us from completely
> dropping NULL/error checking from callers.  Let's make it tree-wide
> consistent by adding IS_ERR_OR_NULL(clk) to all callees.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Greg Ungerer 
> Acked-by: Wan Zongshun 
> ---
> 
> Stephen,
> 
> This patch has been unapplied for a long time.
> 
> Please let me know if there is something wrong with this patch.
> 

I'm mostly confused why we wouldn't want to encourage people to
call clk_disable or unprepare on a clk that's an error pointer.
Typically an error pointer should be dealt with, instead of
silently ignored, so why wasn't it dealt with by passing it up
the probe() path?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: div6: use RENESAS for #define

[Stephen Boyd]

On 03/08, Simon Horman wrote:
> Name the #define guarding compilation of this header
> __RENESAS_CLK_DIV6_H__ rather than __SHMOBILE_CLK_DIV6_H__.
> 
> This is a follow-up to renaming the directory in which this file lives from
> shmobile to renesas which is in turn part of an ongoing process to migrate
> from ARCH_SHMOBILE to ARCH_RENESAS the motivation for which being that
> RENESAS seems to be a more appropriate name than SHMOBILE for the majority
> of Renesas ARM based SoCs.
> 
> Signed-off-by: Simon Horman 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: renesas: Rename header file renesas.h

[Stephen Boyd]

On 03/08, Simon Horman wrote:
> This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> 
> Along with the above mentioned Kconfig changes it seems appropriate
> to also rename files.
> 
> Signed-off-by: Simon Horman 
> 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: renesas: move drivers to renesas directory

[Stephen Boyd]

On 03/03, Geert Uytterhoeven wrote:
> On Thu, Mar 3, 2016 at 3:18 AM, Simon Horman  
> wrote:
> > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> >
> > Along with the above mentioned Kconfig changes it seems appropriate
> > to also rename directories that only hold drivers for such SoCs.
> >
> > Signed-off-by: Simon Horman 
> 
> Acked-by: Geert Uytterhoeven 
> 

Applied to clk-next.

> > Patch pruduced using git format-patch -M
> > This produces a patch without the diff of each renamed file
> > which results in a ~204K patch. Let me know if you would prefer that
> > or a pull-request.
> 
> How will we proceed?
> Note that I have an outstanding pull request for drivers/clk/shmobile.
> 

Git took care of it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: shmobile: Remove ARCH_SHMOBILE_MULTI

[Stephen Boyd]

On 02/23, Simon Horman wrote:
> On Tue, Feb 23, 2016 at 09:19:27AM +0100, Geert Uytterhoeven wrote:
> > CC The New Mike ;-)
> > 
> > On Tue, Feb 23, 2016 at 1:57 AM, Simon Horman
> >  wrote:
> > > As of 9b5ba0df4ea4 ("ARM: shmobile: Introduce ARCH_RENESAS") all platforms
> > > that use Renesas clock drivers now select ARCH_RENESAS. As it is present 
> > > in
> > > drivers/clk/Makefile ARCH_SHMOBILE_MULTI may now be removed.
> > >
> > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> > > ARCH_RENESAS the motivation for which being that RENESAS seems to be a 
> > > more
> > > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> > >
> > > Signed-off-by: Simon Horman 
> > 
> > Acked-by: Geert Uytterhoeven 
> > 

Applied to clk-next

> > >  drivers/clk/Makefile | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > >  Based on clk-next
> > >
> > > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > > index bae4be6501df..b19af449d2f3 100644
> > > --- a/drivers/clk/Makefile
> > > +++ b/drivers/clk/Makefile
> > > @@ -70,7 +70,6 @@ obj-$(CONFIG_COMMON_CLK_PXA)  += pxa/
> > >  obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
> > >  obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
> > >  obj-$(CONFIG_COMMON_CLK_SAMSUNG)   += samsung/
> > > -obj-$(CONFIG_ARCH_SHMOBILE_MULTI)  += shmobile/
> > 
> > Should we rename clk/shmobile/ to clk/renesas/?
> > Or is that too much of a hassle?
> 
> I think it is a good idea.  And I suspect it shouldn't be too difficult if
> we coordinate things with Mike to handle any in-flight patches for that
> directory.

Feel free to send the patch.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project