On Thu, Aug 04, 2016 at 03:05:16PM +0200, Geert Uytterhoeven wrote:

Hi Rich,

On Sat, Jul 30, 2016 at 5:34 AM, Rich Felker [off-list ref] wrote:

quoted

On Thu, Jul 28, 2016 at 08:51:25PM +0100, Mark Brown wrote:

quoted

On Thu, Jul 28, 2016 at 03:40:45PM -0400, Rich Felker wrote:

quoted

On Thu, Jul 28, 2016 at 08:11:53PM +0100, Mark Brown wrote:

quoted

Why are you not using the clock API for this?  Just require a clock and
use clk_get_rate() to find out what rate it is.

quoted

I thought about that but I'm not familiar with it. I can try to figure
it out quickly and test that approach; don't see any reason it
shouldn't work. Would you insist on having full support for
enabling/disabling the clk when it's in use, or would you be happy
with treating it as a fixed clock that's always-on for now and
possibly extending it with more functionality later if there's ever
hardware where that's relevant/helpful?

It's fine to just enable it at startup and leave it on, though the
runtime PM ops are trivial and you can set auto_runtime_pm to have the
core do the gets and puts.

I was able to get it working via the clk api and I'll include support
for this in the next version of the patch, but to actually use it
depends on changing arch/sh to use the common clk framework; otherwise
there's no way to provide a suitable clk in the DT and have
[devm_]clk_get actually pick it up. Should I keep around the option of
using clock-frequency too? That would be most convenient.

I do have a pending patch from Sato-san to switch arch/sh over to CCF
but it's part of a series and I don't think it's ready to merge. I may
be able to merge just a minimal, safe subset that won't break legacy
non-DT configurations, though.

I think you can use non-CCF clocks with DT, if you register them first.
Cfr. the clk_names[] array and shmobile_clk_workaround() function in
v3.18:arch/arm/mach-shmobile/board-koelsch-reference.c and
v3.18:arch/arm/mach-shmobile/clock.c

Or was that the other way around?

You can, but they will only be registered if a board file or
equivalent registers them. The intent is not to have any board files
for boards supported through device tree and eventually to remove all
the board files from arch/sh.

Rich