From patchwork Mon Jun 10 12:00:24 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: George Stark X-Patchwork-Id: 13691942 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 DE07FC27C55 for ; Mon, 10 Jun 2024 12:01:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:CC :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=mBxjYv53qhbRWGLcFa+TuPeTbfx55Bbt6+5J6N0mVDo=; b=mbnfT92xShNFhy PL4y8aqDCsylxZ5N6s2q1yuXafGwG6jdlpmHPaj3ojPNxyRfjqFo7q3/b36obA6saES9o65c0sJCb SoN73VHoxUps+JvX0wQprh5Vy9k3ILda0HD/zP+YT0Jg2LGOTQ0ayUNcDFLLk/zvXSSKqRXnNOqJ9 qcNXd4NnUKexhvEc7N18nLO36oNEJjMSXLlfhX0PykPHZIh8QV4FwkRkK+VeKVWk5mW6OkM6bi/sW J8PZ1LB+GNJlpWO6iqvCoO2tg7slm8VGDH+cBZMcZyC5LYHePCVceJCvPw5Gz0Jbn77KYOWUV25n1 aARLRf5WmxoUGpAx+cdA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sGdi8-00000004v32-0lZ0; Mon, 10 Jun 2024 12:01:16 +0000 Received: from mx2.sberdevices.ru ([45.89.224.132] helo=mx1.sberdevices.ru) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sGdhs-00000004uvh-0kIy for linux-arm-kernel@lists.infradead.org; Mon, 10 Jun 2024 12:01:02 +0000 Received: from p-infra-ksmg-sc-msk02.sberdevices.ru (localhost [127.0.0.1]) by mx1.sberdevices.ru (Postfix) with ESMTP id 06D6E120011; Mon, 10 Jun 2024 15:00:56 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.sberdevices.ru 06D6E120011 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salutedevices.com; s=mail; t=1718020856; bh=hdDozi5lsGbUD6cyN4ZLmx54z1ydzCykUd3pd8uPLHM=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=nD1aEVXkwLz16U2BYjwWe1b5PbwbDmmcOEiMFH1kpAEtTrpSB/azqpCEv1vM06Xbh TxgKK+BgE0nac8Wvo6yKmnZJGN2sHDi9SHFld5HV+o2TsrHzs0whCIGEn6XDDs54Fp Qvu5wUuFLDJ+fJ4slxOdCgNoV5GdCesh2HbW/ysHyKhaPdn1ZZOLEMycScJDIwBAYL q5SBQJaPNb9OGpGlzj1UTEPzmVIiKZKnExgKd5oUXDvZuHfElGMjAz0ZuUJ5lsPCN2 IhD10D2NYUyQ/vKLFedIrVRLaYAus53BAIohwDDCtYo4NASVnx23Z4OLkiXQJ/IgB2 EYGFJMZ1TbtLA== Received: from smtp.sberdevices.ru (p-i-exch-sc-m02.sberdevices.ru [172.16.192.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sberdevices.ru (Postfix) with ESMTPS; Mon, 10 Jun 2024 15:00:55 +0300 (MSK) Received: from localhost.localdomain (100.64.160.123) by p-i-exch-sc-m02.sberdevices.ru (172.16.192.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Mon, 10 Jun 2024 15:00:55 +0300 From: George Stark To: , CC: , , , George Stark Subject: [PATCH 0/1] pwm-regulator with voltage table problem Date: Mon, 10 Jun 2024 15:00:24 +0300 Message-ID: <20240610120025.405062-1-gnstark@salutedevices.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [100.64.160.123] X-ClientProxiedBy: p-i-exch-sc-m02.sberdevices.ru (172.16.192.103) To p-i-exch-sc-m02.sberdevices.ru (172.16.192.103) X-KSMG-Rule-ID: 10 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 185831 [Jun 10 2024] X-KSMG-AntiSpam-Version: 6.1.0.4 X-KSMG-AntiSpam-Envelope-From: gnstark@salutedevices.com X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Auth: dkim=none X-KSMG-AntiSpam-Info: LuaCore: 20 0.3.20 743589a8af6ec90b529f2124c2bbfc3ce1d2f20f, {Tracking_from_domain_doesnt_match_to}, salutedevices.com:7.1.1;d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;100.64.160.123:7.1.2;127.0.0.199:7.1.2;smtp.sberdevices.ru:5.0.1,7.1.1, FromAlignment: s, ApMailHostAddress: 100.64.160.123 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean X-KSMG-LinksScanning: Clean X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.0.1.6960, bases: 2024/06/10 11:09:00 #25535815 X-KSMG-AntiVirus-Status: Clean, skipped X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240610_050100_582061_D3C7BCFE X-CRM114-Status: GOOD ( 15.63 ) 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 Here is the situation we've met on an ARM SoC: We have an ARM SoC with dedicated power input for CPU core and supports different CPU clocks. CPU core power is supplied by external regulator, it's controlled by PWM channel from the SoC. DTS has node for pwm-regulator with voltage table (voltage table is used instead of range apparently to use only fine-tuned duty-cycle values) and with boot-on and always-on properties. This regulator is bound to cpu node. The pwm-regulator is inited at very early stage before bootloader in vendor closed-source code. When a pwm-regulator is probed in the kernel it gets pwm current state and search voltage table by dutycycle to figure out the current voltage. If that search failed then the regulator goes to notrecoverbale state and the core sets the minimal power for the regulator. The situation: bootloader sets mean cpu power and mean cpu clock. but that cpu power is not found in the voltage table (value is between table items) due to different versions of bootloader and kernel and the regulator core sets the minimal power but cpu clock stays the same. CPU hangs somewhere during boot. The core problem as I see it is if regulator is bound to CPU (or some other complex consumer) it can't be changed except by the consumer at any stage. So the regulator driver (core part) should wait for the own consumer to init it properly but regulator can't be in unknown state after probing. What you think? The least should be done is to report about the situation. George Stark (1): regulator: core: add warning for not-recoverable state drivers/regulator/core.c | 4 ++++ 1 file changed, 4 insertions(+) --- 2.25.1