public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Dahl <ada@thorsis.com>
To: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	linux-arm-kernel@lists.infradead.org
Cc: Boris Brezillon <bbrezillon@kernel.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>
Subject: Re: get, prepare, enable a clock not in DT?
Date: Mon, 19 Aug 2024 16:33:19 +0200	[thread overview]
Message-ID: <20240819-education-prong-3da4b83d42ed@thorsis.com> (raw)
In-Reply-To: <20240816-ludicrous-lagging-65e750c57ab4@thorsis.com>

Hello everyone,

Am Fri, Aug 16, 2024 at 04:34:48PM +0200 schrieb Alexander Dahl:
> Hello everyone,
> 
> while further investigating timeout issues with the at91 otpc
> controller on sam9x60 [1] I came to the conclusion the main RC
> oscillator on that SoC must be enabled for that driver to work.
> (Verified that by poking single bits in registers through devmem
> already.)
> 
> Fortunately the necessary clk is already registered from the SoC code
> in drivers/clk/at91/sam9x60.c [2] and I can see the clock in sysfs clk
> summary:
> 
>     root@DistroKit:~ head -n4 /sys/kernel/debug/clk/clk_summary 
>                                      enable  prepare  protect                                duty  hardware                            connection
>        clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
>     ---------------------------------------------------------------------------------------------------------------------------------------------
>      main_rc_osc                         0       0        0        12000000    50000000   0     50000      Y   deviceless                      no_connection_id         
> 
> That clock has no parent and is not found anywhere in devicetree, nor
> is it handled by the two clock-producers on that platform, so
> from within mchp_otpc_probe() I just tried this:
> 
>     otpc->clk = devm_clk_get_enabled(&pdev->dev, "main_rc_osc");
> 
> However that returns with -ENOENT, so I assume I can not reference the
> clock just by name?  Same result with this:
> 
>     otpc->clk = devm_clk_get_enabled(NULL, "main_rc_osc");
> 
> How do I get a pointer to that clk then to enable it?  Docs [3] where
> not as useful as I hoped for, neither was clk.h header docs. :-/

Tried this today:

    otpc->clk = __clk_lookup("main_rc_osc");

However calling that from platform driver code smells suspicious and I
get a linker error when building anyways.

Found no other possibility to get a grip on that clock from driver
code.  Do we need to hook that main_rc_osc into dt somehow so it can be
enabled from driver code?

Adding Boris, Alexandre, and Nicolas to Cc, because they were involved
in the at91 clk drivers in the past.  O:-)

Greets
Alex

> From what I understood from header docs reading 'device for clock
> "consumer"' I must pass the device from which I call that clk_get() as
> first parameter, so this would be the otpc device then, right?  What's
> that second parameter clock consumer id then?  Are these terms
> explained somewhere?
> 
> Greets
> Alex
> 
> [1] <20240813-payable-ecology-8a9e739704bb@thorsis.com>
> [2] https://elixir.bootlin.com/linux/v6.10.4/source/drivers/clk/at91/sam9x60.c#L217
> [3] https://kernel.org/doc/html/latest/driver-api/clk.html
> 
> 

  reply	other threads:[~2024-08-19 14:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16 14:34 get, prepare, enable a clock not in DT? Alexander Dahl
2024-08-19 14:33 ` Alexander Dahl [this message]
2024-08-20 11:54 ` claudiu beznea
2024-08-20 12:17   ` Alexander Dahl
2024-08-20 12:20     ` Alexander Dahl
2024-08-23 14:29     ` claudiu beznea
2024-08-28  6:55       ` Alexander Dahl
2024-08-31 15:49         ` claudiu beznea
2024-09-02  8:24           ` Alexander Dahl
2024-09-04  7:33             ` claudiu beznea
2024-09-04 13:26               ` Nicolas Ferre
2024-09-04 14:43                 ` Alexander Dahl
2024-09-04 17:56                   ` Nicolas Ferre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240819-education-prong-3da4b83d42ed@thorsis.com \
    --to=ada@thorsis.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=bbrezillon@kernel.org \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox