Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp2103091rwa; Mon, 22 Aug 2022 02:03:35 -0700 (PDT) X-Google-Smtp-Source: AA6agR7Td6ZbDFw5X8VYsM6z7EdGGFgozRGWQA9GF0QB2VhV/oYDGWZTRXy0OWP8ehu3l6xM9RfH X-Received: by 2002:a62:38d4:0:b0:536:3cde:4d07 with SMTP id f203-20020a6238d4000000b005363cde4d07mr12461718pfa.66.1661159015313; Mon, 22 Aug 2022 02:03:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661159015; cv=none; d=google.com; s=arc-20160816; b=L5TeHUuGOgkdI/lgg0W9kK/XTQ0JDKBzCAeLe9C/4JpfVvyH35iaWFQZJhyxYYAvpR jZOwhz12TfcUVReP35KvalbXe/q9unp0MYlqnhYZu9jS65ykXpmbD4qrxueXFqZtYpuq 8Hy76ni6UGl27pRufuwvfWdrJnF+27xdW4xAcQ2VPMGdL4xxrvSg5OPCczD9qiX0823V 5ynTM2SRoEMsZoaX8r0MrYWlagQrfV3GvP/NPXJoftOzy446+7jfAAHPD99YNUcqoAZW QEv/k3T+7ZLIyGLF1u+SkvTbgoxgc8bO1sgczJEHGFdC2ngyXQ0SITjLRXy+AWSJSp9m aAVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5OBoHrdlmLoJOWu5Z6u5wsXYdDXsGII6yOBzDwmmk64=; b=xbuOrnJfStR2dSohdeW75boG8Vm5Oxpe8JUHElyHGjorQGtYQkJ/U2DwUXpvGC1M2v V8TET055Jg0qXtcFr4g6lqRhRFAS/TB+WCghhafopWSw5VMb2NIQ43se76E/6hE8jHZe 1NY55xZWqXCo62hPcahKFRazD4k2B0juBTubnw5NJMhIJLr0EJTEQxg0HQxCFQraK5lE uAioXmQbmabuxm5W2Uk1/HI3Bfk5xlFs3QtFxx1YnpzF1bgopU7TE2rva+WFVJ6u04DS HEva+F0TnuOGvKB0xV95qXd77c4iA5Z5H3iMiwOzKwtMamslQl0AzbGugO7YR8jGZGbl XUqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Q5AWfYM/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w8-20020a63f508000000b0042a55fa8f5dsi314849pgh.395.2022.08.22.02.03.22; Mon, 22 Aug 2022 02:03:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Q5AWfYM/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231775AbiHVIig (ORCPT + 99 others); Mon, 22 Aug 2022 04:38:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233777AbiHVIi3 (ORCPT ); Mon, 22 Aug 2022 04:38:29 -0400 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A1D0B7C0 for ; Mon, 22 Aug 2022 01:38:24 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id vw19so6045514ejb.1 for ; Mon, 22 Aug 2022 01:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=5OBoHrdlmLoJOWu5Z6u5wsXYdDXsGII6yOBzDwmmk64=; b=Q5AWfYM/rPqlMVN4qyTDPaeV/0+Fk0sK5jGatklasd63Xvzc/Kde3ny7t+KQZiqhIi xsESJzpeoc5Lj7GBHNkmN+DL75GF2tfoLYlTL0t5oybt5T4qkzTZOtSnum4SCRoVeD+5 OwXvk2cy7EyTb3Gu6Hkp4xMVbEeb1iQSjZIJPPlEuaZSTW7Bq71o5TtgXC8JUKif7xJ8 vvKdA/XZ8SX+JhfY6W5XqInUgwpTUMu5HM0oEiNREievTLz9/od5tYsgeuCNeCISgGJI 7BYkKKmxWsn9xLuTDXk1pJ8ACucfi4oWsaMV/NjeMxbD2ocFyhJNvN9MVGBz62abvbCY QbSQ== 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; bh=5OBoHrdlmLoJOWu5Z6u5wsXYdDXsGII6yOBzDwmmk64=; b=cORIPSG1Yz4aGiuMhyhYLVVrhVQ3ss66FdituIdwTRGy9xdi8YA8Xll60LshEaGvG5 EhjhSJWtCyUIjJB791bVcKUB+hXarusHMu97klTEGSYA4yp5Zi7PMEH86xJjk2FHvPNE dB1D+6F6vRpRLnGwrH155+gUKw/1ox+LQ0Z2m25aYV9Rif00YQIYf2GGi/4bbt91DAHX kliZ/sft8fqkBDs+3Z3G+TbPsSHD9uCv7l4fBPr4WVWEGBoNt2NP9mwofGcHZRPn3dPF UFKY0P8Xpk9o7aNJmr9YkxVga3oeQxvHkjlVIn+N1T+Q0jZcRjc5vvbMwMiUoHvgib3d uD5A== X-Gm-Message-State: ACgBeo3E/coQLa4lfLjVrbojd+3K77/f0kDI5vn4vPHxuk3+nlWMJXVG sCYKjQVCAHxWah2zpFnj+sJjgcaMcHFgYrKWbeSxJQ== X-Received: by 2002:a17:906:58c8:b0:6fe:91d5:18d2 with SMTP id e8-20020a17090658c800b006fe91d518d2mr12458571ejs.190.1661157503046; Mon, 22 Aug 2022 01:38:23 -0700 (PDT) MIME-Version: 1.0 References: <20220802095252.2486591-1-foss+kernel@0leil.net> In-Reply-To: <20220802095252.2486591-1-foss+kernel@0leil.net> From: Linus Walleij Date: Mon, 22 Aug 2022 10:38:11 +0200 Message-ID: Subject: Re: [RFC PATCH 0/1] Making Rockchip IO domains dependency from other devices explicit To: Quentin Schulz , Ulf Hansson , "Rafael J. Wysocki" Cc: heiko@sntech.de, linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Quentin Schulz Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 2, 2022 at 11:53 AM Quentin Schulz wrote: > Some background on IO domains on Rockchip: > > On some Rockchip SoCs, some SoC pins are split in what are called IO > domains. > > An IO domain is supplied power externally, by regulators from a PMIC for > example. This external power supply is then used by the IO domain as > "supply" for the IO pins if they are outputs. > > Each IO domain can configure which voltage the IO pins will be operating > on (1.8V or 3.3V). > > There already exists an IO domain driver for Rockchip SoCs[1]. This > driver allows to explicit the relationship between the external power > supplies and IO domains[2]. This makes sure the regulators are enabled > by the Linux kernel so the IO domains are supplied with power and > correctly configured as per the supplied voltage. > This driver is a regulator consumer and does not offer any other > interface for device dependency. What makes me confused about the patch is the relationship, if any, between this "IO domain" and generic power domains (genpd) that has been worked on for ~10 years. I am worried that we are reinventing the world. While my intuitive feeling is that genpd power domains are only on-chip and not considering off-chip pins, I am not so sure that it warrants its own abstraction and want to know whether this can be retrofit into genpd rather than inventing this? Documentation/devicetree/bindings/power/power-domain.yaml include/linux/pm_domain.h Yours, Linus Walleij