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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1A3FC83F13 for ; Mon, 28 Aug 2023 10:46:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231847AbjH1Kpr (ORCPT ); Mon, 28 Aug 2023 06:45:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232063AbjH1Kpo (ORCPT ); Mon, 28 Aug 2023 06:45:44 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CF11136 for ; Mon, 28 Aug 2023 03:45:24 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-99c0cb7285fso402080466b.0 for ; Mon, 28 Aug 2023 03:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1693219522; x=1693824322; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7OanaXXnrMsaEfBjCXrcfdtKi7g9UEMwaAf60pZJsSc=; b=C1oa92btKyiq9BivM1fEjwLmi66V9PA7yJw4LUzkelTctM0ppXJ//6PCvBudrgPQCi nEis/LIE3gfdzxcrDS8lyKyjEPmxAyLdoVQW/z79vVwyZOlcbX0JxAxePNCGQRxl8TvP YaUF8nWONY/lPa/awNeyRtbr64JYs45xfZaQYjTcXKx0pLWS07q+sZkiK3TtfaF5e5c6 Rp1Tgl/Vkwo1lXaUSL37MZu6AyX9p2R5TN8S1Ow4OLVaw/fSoPRQ2guC7OF7QRJD17rb jEo6fFDE0Uf52p1ZgJEckdYTJgfmz+1FvVZpC1gSRzJEPyex18gFdedoKdRTWn88Lv8r +bZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693219522; x=1693824322; h=content-transfer-encoding:in-reply-to:from:references:cc: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=7OanaXXnrMsaEfBjCXrcfdtKi7g9UEMwaAf60pZJsSc=; b=STxuxqgnUJTWRYYpeHiiXuZzydorO9VCAoO3eLpBJbMUiqjWrUm/6J/KULzL8LMLt6 G6ad+EzPKzy2xIwyIu/YG5NwcFwYBJenYM/AxzE52NA7btNeZGeuenFimURddqKCYsWR ehigWSkEVZwnLeQRA7yvMNJxAx2iw75GbjmkFiFe5npbb5DkbYyoGzuYIhYflL/uRvdj a90phhn6ii4fGFj9ekyI50hZxJ90PxXqu6tk/N+W1V4QyJAoCVUyBsQ2JvuwLhnOLeh0 D/Afk/0xJXNw1GYrs+xOlpsdDfYqSHtsrB5r/gKbOG7OFOUa2rHGQB88GSZVk3C0r23/ CW1A== X-Gm-Message-State: AOJu0Yy+ZiMDLhv30YW5h3KKNK6g1A+nefzylPb3Dva5ChkRzCUFIm+N a05CzzAC2eC5tSiIJVflVTvNCg== X-Google-Smtp-Source: AGHT+IHTA017TesrZlA/sySPLP1brYSSYzfcBNjrMk0jhiVJiNfeXLqU0j3wzbMWlEZaqDpfvcftoQ== X-Received: by 2002:a17:906:7392:b0:9a1:d087:e0bd with SMTP id f18-20020a170906739200b009a1d087e0bdmr11535283ejl.6.1693219522129; Mon, 28 Aug 2023 03:45:22 -0700 (PDT) Received: from [192.168.0.22] ([77.252.47.225]) by smtp.gmail.com with ESMTPSA id cf20-20020a170906b2d400b0098e78ff1a87sm4500818ejb.120.2023.08.28.03.45.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Aug 2023 03:45:21 -0700 (PDT) Message-ID: <8f9f24c7-c93f-4cb8-bbd2-f0a8502d5f1b@linaro.org> Date: Mon, 28 Aug 2023 12:45:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH 1/2] dt-bindings: power: Add regulator-pd yaml file Content-Language: en-US To: Ulf Hansson Cc: Shenwei Wang , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Liam Girdwood , Mark Brown , "imx@lists.linux.dev" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , dl-linux-imx References: <20230818153446.1076027-1-shenwei.wang@nxp.com> <4e2c18e3-b1ed-6361-3998-5de060d2bcf0@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 28/08/2023 11:59, Ulf Hansson wrote: > On Sat, 26 Aug 2023 at 19:31, Krzysztof Kozlowski > wrote: >> >> On 25/08/2023 17:44, Shenwei Wang wrote: >>>> >>>> The genpd provider then needs to be a consumer of the resources it needs. In >>>> this case a couple of regulators it seems like. >>>> >>> >>> If I understood your reply correctly, it seems that the current implementation of >>> regulator-pd is what you have described. Please correct me if I'm mistaken. >>> >>> The following are the diff of scu-pd and this regulator-pd. >>> >>> power-controller { power-controller { >>> compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd"; | compatible = "regulator-power-domain"; >>> #power-domain-cells = <1>; #power-domain-cells = <1>; >>> > >>> > regulator-number = <2>; >>> > regulator-0-supply = <®1>; >>> > regulator-1-supply = <®2>; >>> }; }; >>> >>> Are you suggesting to move the regulator-pd to the imx directory and add a company prefix >>> to the compatible string? >> >> There is no such part of iMX processor as such regulator-power-domain, >> so I don't recommend that approach. DTS nodes represent hardware, not >> your SW layers. > > I would agree if this was pure SW layers, but I don't think it is. At > least, if I have understood the earlier discussions correctly [1], > there are certainly one or more power-domains here. The power-domains > just happen to be powered through something that can be modelled as a > regular regulator(s). No? No. It was for controlling power of multiple devices, supplied by multiple different or similar regulators, where Linux drivers for these devices (so not even all drivers...) do not have regulator control. The bindings for these devices allow power-domains, but not regulator. There are no multiple power domains in the problem. Even term "power domain" is questionable here, because we tend to look power domain as part of SoC. Here it is some selected part of the circuitry, like few totally independent devices which share purpose and power rails. But more important is my first paragraph - this is purely to avoid adding regulators to these devices. Best regards, Krzysztof