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 B36B0C43334 for ; Wed, 15 Jun 2022 21:15:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349490AbiFOVPQ (ORCPT ); Wed, 15 Jun 2022 17:15:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349417AbiFOVPG (ORCPT ); Wed, 15 Jun 2022 17:15:06 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 419C05536C for ; Wed, 15 Jun 2022 14:15:05 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id a2so20811990lfg.5 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=MLlK5ScqT30xRQNwleNtAkO/zfE9rho83hFuniNIZt0QO5pziqh7wEgopArQ0tsZvu yqFgZHfv1hEp6kuCvEtXVp2t0GyOWnFD/XZQ/vIyok6DPPq7qaQsWM0J1XcxcfeQK677 sYST6SqglTVkUDzrqMAn1yMRz9rCrIo4UkJ4Tja8ihWAgOL3dXxX/0WuBrwKwudVV49K FJtZcycuVphwn1lqDaNJsnKwTkP5VH4mN2jNayItCMS3H4/YVF3k+UWwGIi0RpvgyY50 hfLg+tui63qPfk1C07Eb6V51JbQQM3D4emib3+/7Kj2jCCWagjXWd2d+gjdktndUqbOj gk2w== X-Gm-Message-State: AJIora+Cg07yPRW0XvJir3B7yjWntX4GaEcMnfJczoh4LUkp/DHAKoi7 WZWVF3WDx8I5pVVHnRPWXRMItCg/HjcLFjcv0MpVOA== 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: linux-pm@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