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 D4656C43334 for ; Wed, 15 Jun 2022 21:15:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349711AbiFOVPN (ORCPT ); Wed, 15 Jun 2022 17:15:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345188AbiFOVPG (ORCPT ); Wed, 15 Jun 2022 17:15:06 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 418E95536A for ; Wed, 15 Jun 2022 14:15:05 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id w20so20776142lfa.11 for ; Wed, 15 Jun 2022 14:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U4zrudTfpKSMt98XR2iufEyV1+uGBR6wStGeT3BqOFk=; b=iSjexz3mLcG79lRlUUZPUPkq8OBBprdOmNRAGkZEcmvAa4eQvTfbPk9WmCpbFPVpE/ 5IjIW1VvqnyWQIMo4gprntm+LphtyDdc7pa9pxQhRyYNbQ3sPypQpGvpVm2goTEqjXnD ZWIHzr9ALIdL8uSDepi8JGqdaUGJ9KO81GTDeglZtZzld+OdfsO6ivUoTALFkKTPaPle EBAdyCHjtkfqlSTu21w/CG11XS8bx7jqZO9mTphBt3RNJEys+Eq0Az+zPC92rLlqpnL4 piH0IU2/m0Nc8T/9Edrwj9ROFMNSzW+SSvqduVjOVc0ysz3DV4UTT7udJAo7v4Z2HhU6 Ud3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U4zrudTfpKSMt98XR2iufEyV1+uGBR6wStGeT3BqOFk=; b=TsZolgP0Q+GnCb2kQX/ASUZ371gOAgi4amxEZGVyn3jwTfbGU+dKyXTgftIAjrWYXG dP6hgacSB4XjFZ8rIShVH9ztNUIHjLYaruoCEILpjZv8dY4GcH6uwD9REge4kgfXevAS qNAuTmDQtcTHtY9q33uCBa0Wyl4jlZR2n0Q0mG5UTA2nQ8W2XGbAL1eQB3EES1o3I9D0 Odu8asChFzQy+u2KuEL6A+NAdd9pRBg9n7f+QquM4hsWBzKI/zhYwZaL8+ATs9tkLW3z MrPz5CP1Ntz+5zv+wLxGctiYwMACvqZW6SnjYOl/EdRLeWH5n/pz1BiAWwPlW5RK8CzS LWyg== X-Gm-Message-State: AJIora/bHdoXJpBspYylrKMQyeKBUhmAKVjLTPVpEGhN892ubeB+/ksi Wff4goxmNHLQEEzK8LDIZMGvWWtOZIllI8jxhn+Y8A== X-Google-Smtp-Source: AGRyM1t5MyamwiCz7PoSdPQ8gjW8OM+EpbSRQMqDHUOoS9LUKaLFPkP4lLu+GObfpyOlL4mcqFgvi/WGO0uAYN5JDkg= X-Received: by 2002:a05:6512:3085:b0:479:3986:1d23 with SMTP id z5-20020a056512308500b0047939861d23mr799565lfd.373.1655327703359; Wed, 15 Jun 2022 14:15:03 -0700 (PDT) MIME-Version: 1.0 References: <20220609150851.23084-1-max.oss.09@gmail.com> In-Reply-To: <20220609150851.23084-1-max.oss.09@gmail.com> From: Ulf Hansson Date: Wed, 15 Jun 2022 14:14:27 -0700 Message-ID: Subject: Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls To: Max Krummenacher Cc: max.krummenacher@toradex.com, linux-pm@vger.kernel.org, Francesco Dolcini , Mark Brown , "Rafael J . Wysocki" , Kevin Hilman , Andrejs Cainikovs , Biju Das , Bjorn Andersson , Catalin Marinas , Dmitry Baryshkov , Fabio Estevam , Geert Uytterhoeven , Krzysztof Kozlowski , Marcel Ziswiler , NXP Linux Team , Pengutronix Kernel Team , Rob Herring , Sascha Hauer , Shawn Guo , Vinod Koul , Will Deacon , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, 9 Jun 2022 at 08:09, Max Krummenacher wrote: > > From: Max Krummenacher > > its power enable by using a regulator. > > The currently implemented PM domain providers are all specific to > a particular system on chip. > > This series adds a PM domain provider driver which enables/disables > a regulator to control its power state. Additionally, marked with RFC, > it adds two commits which actually make use of the new driver to > instantiate a power domain provider and have a number of power > domain consumers use the power domain. > > The perceived use case is to control a common power domain used by > several devices for which not all device drivers nessesarily have > a means to control a regulator. > > It also handles the suspend / resume use case for such devices, > the generic power domain framework will disable the domain once the > last device has been suspend and will enable it again before resuming > the first device. > > The generic power domain code handles a power domain consumer > generically outside of the driver's code. (assuming the 'power-domains' > property references exactly one power domain). > This allows to use the "regulator-pm-pd" driver with an arbitrary > device just by adding the 'power-domains' property to the devices > device tree node. However the device's dt-bindings schema likely does > not allow the property 'power-domains'. > One way to solve this would be to allow 'power-domains' globally > similarly how 'status' and other common properties are allowed as > implicit properties. I don't want to interrupt the discussion, but I still wanted to share my overall thoughts around the suggested approach. Rather than adding some new DT bindings and a new generic DT compatible, I think the current power-domains bindings are sufficient to describe these types of HWs. To me, it looks rather like you are striving towards avoiding open coding for power domain providers that make use of a regulator. Right? To address that problem, I think a better option is to consider introducing a helper library with a set of functions that can be used by these types of power domain providers, in a way to simplify the code. [...] Kind regards Uffe