public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: claudiu beznea <claudiu.beznea@tuxon.dev>
To: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: get, prepare, enable a clock not in DT?
Date: Tue, 20 Aug 2024 14:54:59 +0300	[thread overview]
Message-ID: <384919bc-7d45-445a-bc85-630c599d43ef@tuxon.dev> (raw)
In-Reply-To: <20240816-ludicrous-lagging-65e750c57ab4@thorsis.com>

Hi, Alexander,

On 16.08.2024 17:34, Alexander Dahl wrote:
> 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.

Not sure how that works (unless undocumented) as figure Figure 28-1. Clock
Generator Block Diagram from [1] states that main_rc_osc feeds only the mainck.

Also, Table 9-1. Peripheral Identifiers from [1] say that there is no clock
control for OTCP on the PMC side.

[1]
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAM9X60-Data-Sheet-DS60001579.pdf

> (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

To expose it though DT you may want to save its hw object to one array
entry in sam9x60_pmc, sam9x60_pmc->chws[] fits best for this atm.

Otherwise, you can try to register the main_rc_osc with CLK_IS_CRITICAL for
simple trials.

Thank you,
Claudiu Beznea

> not as useful as I hoped for, neither was clk.h header docs. :-/
> 
> 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
> 

  parent reply	other threads:[~2024-08-20 11:55 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
2024-08-20 11:54 ` claudiu beznea [this message]
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=384919bc-7d45-445a-bc85-630c599d43ef@tuxon.dev \
    --to=claudiu.beznea@tuxon.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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