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 B506FC6FA8E for ; Tue, 27 Sep 2022 12:50:40 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9MwIxM9UDj9RqGD+7gfS7GPE9DB+J942Z9Bia1PnBQA=; b=mkD43n5/i0kFJF 9FqT3fML91ctinYbOP432OLn3aqA5W5Jf7nBLUCWMZ+sivGF+jyDE24k359aQL6njGeFj7BWf++dW MoSvBzHyg8OWEM68NkCli70OXuUevft+8UBBX5O89zMYpCcVfG+yYuc6fUUBnqRdcjvf1GaiH67rs 5ngFr+RoLrggLcyH3HBJ4IaYSUKSJL0Q//TBtbyncI7tkYd1hBoSPuUtcrzZejOv2atnVCQwDWAMb Xji4GnvCiEi50Lz/4/qosbWfqF7JoPVnUQ1YWbMlzugyy3F49ojjTjb28Lonl0xJrv0wkQuZPNMnQ Kh3rvcG0XweGxEMtJbLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1odA1a-00AZqt-V7; Tue, 27 Sep 2022 12:49:23 +0000 Received: from mail-qk1-f176.google.com ([209.85.222.176]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1odA1X-00AZo0-Mb for linux-arm-kernel@lists.infradead.org; Tue, 27 Sep 2022 12:49:21 +0000 Received: by mail-qk1-f176.google.com with SMTP id h28so5951828qka.0 for ; Tue, 27 Sep 2022 05:49:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=kxKNS5DDyDVwQYf8SSh+Z282XSXl8OO2BaUjOfJxTOs=; b=qTGbxhkAGjs0Gnuk+rz4u/ytdNepXGLa/meBqIkShLEIsxkp0OXkaL14/MbF2iCvhw qbANFloNKaGSVdQIPAAO3f/UduxT7i56Ku+/KN02xdkQ05E2nT0ObV+ie3U6QFfYtK1f 8RV2GZu4VQg6MCtPHOHasqypoZUSgpvcMZh5a7yP8RdA2VKewy52Df2xhOjtu4MlmcWb nRGBhpMEzucfiONdALgfkZoGOL2PGTvUmP7sHmts3tGQrkLXW2SsnTur5xM4+5LEVYGi G422ELGNUgCFCA+Ga/25CgPU37V17vUKwVmDB+TkvMLo7CJavkZAyJtL6UrHlVX9Ec3j Q0eQ== X-Gm-Message-State: ACrzQf3Y3tlwcwWhHdTn2fyBC+357zDVVswnZo3wDVKr8ZEvqZf1b09b VrFpJNGQIetqPkWKcf35RhhLSqM26aefFw== X-Google-Smtp-Source: AMsMyM7/MLqT6fw3FqTbcGO7TAy0G/2+cBUO/i9XpGRJQeZZbFbBbiRM2KL4oj1pifUZovx5FRU2og== X-Received: by 2002:a05:620a:4c:b0:6ce:b5f:1320 with SMTP id t12-20020a05620a004c00b006ce0b5f1320mr17812288qkt.569.1664282957191; Tue, 27 Sep 2022 05:49:17 -0700 (PDT) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id z8-20020ac87108000000b003445d06a622sm730459qto.86.2022.09.27.05.49.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Sep 2022 05:49:16 -0700 (PDT) Received: by mail-yb1-f180.google.com with SMTP id 4so3923517ybe.2 for ; Tue, 27 Sep 2022 05:49:15 -0700 (PDT) X-Received: by 2002:a25:8e84:0:b0:696:466c:baa with SMTP id q4-20020a258e84000000b00696466c0baamr24148017ybl.604.1664282955514; Tue, 27 Sep 2022 05:49:15 -0700 (PDT) MIME-Version: 1.0 References: <20220609150851.23084-1-max.oss.09@gmail.com> <20220726160337.GA41736@francesco-nb.int.toradex.com> <20220728112146.GA97654@francesco-nb.int.toradex.com> <20220909142247.GA238001@francesco-nb.int.toradex.com> <70ee4f8e-7529-307e-656c-2a65d0187af6@linaro.org> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 27 Sep 2022 14:49:02 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls To: Ulf Hansson Cc: Krzysztof Kozlowski , Francesco Dolcini , Mark Brown , Krzysztof Kozlowski , Robin Murphy , Max Krummenacher , Linus Walleij , Max Krummenacher , Linux PM list , "Rafael J . Wysocki" , Kevin Hilman , Andrejs Cainikovs , Biju Das , Bjorn Andersson , Catalin Marinas , Dmitry Baryshkov , Fabio Estevam , Geert Uytterhoeven , Marcel Ziswiler , NXP Linux Team , Pengutronix Kernel Team , Rob Herring , Sascha Hauer , Shawn Guo , Vinod Koul , Will Deacon , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , Linux Kernel Mailing List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220927_054919_765170_25FB4954 X-CRM114-Status: GOOD ( 52.21 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Ulf, On Tue, Sep 27, 2022 at 11:49 AM Ulf Hansson wrote: > > >>>> The main concern that was raised on this topic was that we have to > > >>>> somehow link the power-domain to the specific peripherals (the power > > >>>> domain consumer) in the device tree. > > >>> > > >>> Yes, that is needed. Although, I don't see how that is a concern? > > >>> > > >>> We already have the valid bindings to use for this, see more below. > > >>> > > >>>> > > >>>> Adding the power-domain property there will trigger validation errors > > >>>> unless we do explicitly add the power-domains to the schema for each > > >>>> peripheral we need this. To me this does not really work, but maybe I'm > > >>>> not understanding something. > > >>>> > > >>>> This is what Rob wrote on the topic [1]: > > >>>> > No. For 'power-domains' bindings have to define how many there are and > > >>>> > what each one is. > > >>>> > > >>>> Just as an example from patch [2]: > > >>>> > > >>>> can1: can@0 { > > >>>> compatible = "microchip,mcp251xfd"; > > >>>> power-domains = <&pd_sleep_moci>; > > >>>> }; > > >>>> > > >>>> leads to: > > >>>> > > >>>> imx8mm-verdin-nonwifi-dahlia.dtb: can@0: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+' > > >>>> From schema: .../bindings/net/can/microchip,mcp251xfd.yaml > > >>> > > >>> I think it should be fine to just add the below line to the DT > > >>> bindings, for each peripheral device to fix the above problem. > > >>> > > >>> power-domains: true > > >> > > >> Again, as Rob said, no, because it must be strictly defined. So for > > >> example: "maxItems: 1" for simple cases. But what if device is then part > > >> of two power domains? > > >> > > >>> > > >>> That should be okay, right? > > >> > > >> Adding it to each peripheral scales poorly. Especially that literally > > >> any device can be part of such power domain. > > > > > > Right. > > > > > >> > > >> If we are going with power domain approach, then it should be applicable > > >> basically to every device or to every device of some class (e.g. I2C, > > >> SPI). This means it should be added to respective core schema in > > >> dtschema repo, in a way it does not interfere with other power-domains > > >> properties (existing ones). > > > > > > Isn't that already taken care of [1]? > > > > No, because it does not define the items (what are the power domains and > > how many). This binding expects that any device has maxItems restricting it. > > Right, apologize for my ignorance. > > > > > > > > > If there is more than one power domain per device, perhaps we may need > > > to extend it with a more strict binding? But, that doesn't seem to be > > > the case here - and if it turns out to be needed later on, we can > > > always extend the bindings, no? > > > > > > Note also that we already have DT bindings specifying "power-domains: > > > true" to deal with the above. Isn't that what we want? > > > > You mentioned it before and both me and Rob already responded - no, > > because it does not restrict the number of items. > > Okay, so maxItems need to be specified for each peripheral. It's not a > big deal, right? > > Of course, it would be even easier if the core schema would use a > default "maxItems: 1" for power domain consumers, which of course must > be possible to be overridden for those consumers that need something > else. But perhaps it's not that simple. :-) It's not that simple: being part of a PM Domain is not a property of the device being described, but a property of the integration into the SoC. All synchronous hardware needs power (single/multiple), clock(s), and reset(s). But the granularity of control over power(s), clocks, and resets depends on the integration. So the related properties can appear anywhere. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel