From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 11CEDC52D7C for ; Fri, 23 Aug 2024 14:30:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DIB0c+jAUWDPXd2QD2p4fPNNQNtlM220AtDEZkMw744=; b=h5Fwx0G4JNOaWQT/e7jeYouVKN bLAYsCOx0Gyq/Fj9KXq0K3ZZT0uRfllFKCEfWJQxo4jE2PSfHqxoOsM8jnT2+L0XOvT8eXX8IcM5G kHsFz7YSZPYdP6L57gUFBbDkixwzoonAHFGg4yKMFu/uu2KQe5T4M1BOkJDsJyBGerKnEOiFmsBo9 KwzQ0mdmx0o0+/TjlBYvq5xOslm0YZ3HQ1QigC+yWJ7znKPYjrDyjSmrl2DOoJGnjc1wYQGJwknMi r+3U7grzYPsVehUHZEdIPOMlUCM2kVyPjSsfcqBxwsAc5O2E0ukAMzxl1fCsZuiEBKNrZrkHHA8xi M8bSfwDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1shVJF-0000000H6n1-02hV; Fri, 23 Aug 2024 14:30:37 +0000 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1shVIS-0000000H6Zy-28Cw for linux-arm-kernel@lists.infradead.org; Fri, 23 Aug 2024 14:29:50 +0000 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2f3cd4ebf84so23876951fa.3 for ; Fri, 23 Aug 2024 07:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1724423387; x=1725028187; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=DIB0c+jAUWDPXd2QD2p4fPNNQNtlM220AtDEZkMw744=; b=eBE0RWcLEGV9f6DyUwQcmPRHnrjHkakENIJgS/crw5qFd6uZ/Acl7mgpqlUdDZDTx8 spGEDxAqyhnf68idHIWu4MxlGJuKX+WUCPuLW4BDTNdHY9nNYmqqCXrDHYKPxCB10Bf8 c0UTa9elv/LqFZIjptzQzJ4rhXlzfIR7k/1ny5HvBP0snZJS+72Z8SLZ7gBUaC7uimr+ N+xjaHQy+lgj3CJPYsk7kyh4po/4npR0+DpYwLaxMaNzUQ3NmodsB3ULWWTu9u0+bPJG jT40JadekI28pTwHPxvHgdsPdIZTAcHqpQsZCPatkSRJ7Wl47+33rbhqQwQBOGME5TfJ 4ffw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724423387; x=1725028187; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DIB0c+jAUWDPXd2QD2p4fPNNQNtlM220AtDEZkMw744=; b=YNtbgZFrx8SykgzXSKTWeiFFleQBE1jePabyeVTcoy/QDdwVo2e7IXPVdzGVvk86eY 9GH43Iy13hBd2JtFdUtU6UtIaFDpPi5ME32MUVajATfsiyQPbZNhrIzvF2ZA2TuXVwom d44xHfryL/w9PnL1lZK/xBf5xQXtDTRR3vGnLAzaNRgeMg0kfAdJZmRSdZw5BWKtZ/QV WYOOd9L1fZg42vIlFPDOEwjsPyw1fivbuAakBLAlh4CRSxn3qP4AdwFunIXC6zqGVxUO qDvrfDMdvAlnqXAXetQskW5xk1YiAjraMoNt9Xgd1B+fvEadkPO9hr5bLfrJxZFzFTCv +5zg== X-Forwarded-Encrypted: i=1; AJvYcCWaNmki2BJjWUC4oAAGU1G8DTYb7D0OMU/9SzH4PZy6i9trKbvF7X46nuRIkxWS0Rj7UHXmKZsf98k+g85bTkUp@lists.infradead.org X-Gm-Message-State: AOJu0YziqTdR2/QdTJEJIF7PCoJQitH/CpTvL8njsJMJiNy+Tp8mhFFX XDgLogIw1cAXuicYqCRNkS0oPTO/l5wSjkP99UK10f0wZJMnNApDGZpchVyhQlw= X-Google-Smtp-Source: AGHT+IHYpZtJVH6Prfq+WLMWjdpDo7o54QqLVKRGeNhWCbFAyaehg6FYfiCh8d9nmrlXwYyq9Ve76g== X-Received: by 2002:a2e:b555:0:b0:2ef:24a0:c176 with SMTP id 38308e7fff4ca-2f4f4916fd1mr18707381fa.28.1724423386214; Fri, 23 Aug 2024 07:29:46 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.177]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c04a4c438fsm2147233a12.61.2024.08.23.07.29.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Aug 2024 07:29:45 -0700 (PDT) Message-ID: Date: Fri, 23 Aug 2024 17:29:44 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: get, prepare, enable a clock not in DT? Content-Language: en-US To: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20240816-ludicrous-lagging-65e750c57ab4@thorsis.com> <384919bc-7d45-445a-bc85-630c599d43ef@tuxon.dev> <20240820-grandpa-down-fec4231f971c@thorsis.com> From: claudiu beznea In-Reply-To: <20240820-grandpa-down-fec4231f971c@thorsis.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240823_072948_686752_9A2CDFCD X-CRM114-Status: GOOD ( 33.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 20.08.2024 15:17, Alexander Dahl wrote: > Hello Claudiu, > > Am Tue, Aug 20, 2024 at 02:54:59PM +0300 schrieb claudiu beznea: >> 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. > > It can feed the main clock and you're right from Clock Generator POV. > However it is not completely undocumented. Section "23.4 Product > Dependencies" of the SAM9X60 datasheet (DS60001579G) says: > > "The OTPC is clocked through the Power Management Controller (PMC). > The user must power on the main RC oscillator and enable the > peripheral clock of the OTPC prior to reading or writing the OTP > memory." > > Apparently this also applies to reading, at least according to my > tests on sam9x60-curiosity. > > btw, the last public release of the atmel-software-package, source for > the sam-ba applets, also enables that clock, although the reasoning > was for writing. [1] > >> 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 > > You're right from the datasheet POV. Not sure if the datasheet is > right here? It's not complete in some register contents anyway, maybe > some things are kept confidential, and OTPC is part of that? > > Maybe someone can confirm my findings on sam9x60-curiosity, e.g. > after I sent a patch series with what I consider fixes for this topic? > >>> (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. > > Great to see I came to the same conclusion. I have a proof-of-concept > working meanwhile, will send a patch series later this week I guess. > > Thanks for your support. > >> Otherwise, you can try to register the main_rc_osc with CLK_IS_CRITICAL for >> simple trials. > > Don't think that is necessary anymore. :-) > > By chance: I don't have a sama7g5 based board at hand for testing. > The datasheet says the same as for sam9x60. > Does the nvmem_microchip_otpc driver actually work without timeout on > sama7g5? Yes! This should be because system bus is clocked from MCK0 (as mentioned in peripheral identifiers table) which is enabled by bootloader. Here is a snapshot of reading the NVMEM on a SAMA7G5 with bootconfig and thermal calibration packets: https://www.linux4sam.org/bin/view/Linux4SAM/ThermalFaq > > Greets > Alex > >> >> 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 >>> >>