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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8987C433EF for ; Thu, 28 Oct 2021 16:51:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B1590610F8 for ; Thu, 28 Oct 2021 16:51:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230456AbhJ1Qxy (ORCPT ); Thu, 28 Oct 2021 12:53:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36522 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230437AbhJ1Qxx (ORCPT ); Thu, 28 Oct 2021 12:53:53 -0400 Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E0C0C0613B9 for ; Thu, 28 Oct 2021 09:51:25 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id o83so9157067oif.4 for ; Thu, 28 Oct 2021 09:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vdcieApq76aVwV7YeMbL8svFqnVx22XOBF/ZRhqhdrw=; b=VmAzlfQViSU8L2QzalW4BxxyO3g0UOqJWS98/kME2IOfJlFAK1uyLIMYdqNHwB4J3Q tk/T4YqeIUhBk14pYTxaqxaYliGAPfRs4B7iKO3BWERKdjJzRSY/wdOSk/rZBF6ZPKed QiN+Lqj3HC74T4frOj4auTGqAafFJ4KVxg445qaLRQkDIW8MEQ1qREhUkO0c+llAqgK9 0uNIvg1RAiBhIvvnVWcDKMrrG54qz3etlmFfWRquIwUpyACrGtpXgw7LdJc93XksOYtx XW2t8kOKZLhJQ81wjMAvsheSde6OVDVyEhSjeXPKh3gRV0YmSwbv1fMqZqXbebUu54ZS rvfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vdcieApq76aVwV7YeMbL8svFqnVx22XOBF/ZRhqhdrw=; b=3dkW2f18rdSYLj7A/7kjz2wZOvwK2tOpkeQtW1CNf2Uqpet03i84B6pcsrz4YIw2gw mt94Quj569KTzHTrcsoRYqxIgXAYFBqBiudxE/0wbTr0qfU3s6KxV3uSFfhBYMbCrqnW M3stgH82n+qrjG2PYDibaEHC5OXn25NJFxk5vV+v1AVNmeD0rvgpCYQXszPMKbNR6WFu 25J75Xl0bnaMLHRJJIB4M/Ob7LU5ehq7C/mVn3ujo3OWHiPFGT4QpG5BGtQ2D4Imc0CS D2IP7ii9CSzGiV4Vb/r+rPP3CRLTm+iPKxXHyL6t27ty3xy8TVf6+AbCyO8tbUT1TsCE 7MqQ== X-Gm-Message-State: AOAM530aTMayFeoiJnpYJrgoXomFzbGF+GmdHJG61p+J5cyZ4xwE6YZy RiUnO5hxxegEqPaGxSbEPxZzbA== X-Google-Smtp-Source: ABdhPJxFgbLyfR/ke3FH70Vv9T+iJrawjEp7Pk+BsCSCkyiKAoFyC4dXUhGH3nTTI7DWi8fkZYMzig== X-Received: by 2002:a05:6808:171c:: with SMTP id bc28mr9424798oib.18.1635439884570; Thu, 28 Oct 2021 09:51:24 -0700 (PDT) Received: from ripper (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id q15sm1178672otm.15.2021.10.28.09.51.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Oct 2021 09:51:24 -0700 (PDT) Date: Thu, 28 Oct 2021 09:53:14 -0700 From: Bjorn Andersson To: Rajendra Nayak Cc: Ulf Hansson , Stephen Boyd , Viresh Kumar , Sandeep Maheswaram , Rob Herring , Andy Gross , Greg Kroah-Hartman , Felipe Balbi , Doug Anderson , Matthias Kaehlcke , devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, quic_pkondeti@quicinc.com, quic_ppratap@quicinc.com Subject: Re: [PATCH v2 1/3] dt-bindings: usb: qcom,dwc3: Add multi-pd bindings for dwc3 qcom Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu 28 Oct 03:46 PDT 2021, Rajendra Nayak wrote: > > On 10/28/2021 4:05 PM, Ulf Hansson wrote: > > [...] > > > > > > > > Got it. So in this case we could have the various display components > > > > > > that are in the mdss gdsc domain set their frequency via OPP and then > > > > > > have that translate to a level in CX or MMCX. How do we parent the power > > > > > > domains outside of DT? I'm thinking that we'll need to do that if MMCX > > > > > > is parented by CX or something like that and the drivers for those two > > > > > > power domains are different. Is it basic string matching? > > > > > > > > > > In one way or another we need to invoke pm_genpd_add_subdomain() to link > > > > > the two power-domains (actually genpds) together, like what was done in > > > > > 3652265514f5 ("clk: qcom: gdsc: enable optional power domain support"). > > > > > > > > > > In the case of MMCX and CX, my impression of the documentation is that > > > > > they are independent - but if we need to express that CX is parent of > > > > > MMCX, they are both provided by rpmhpd which already supports this by > > > > > just specifying .parent on mmcx to point to cx. > > > > > > > > I was trying to follow the discussion, but it turned out to be a bit > > > > complicated to catch up and answer all things. In any case, let me > > > > just add a few overall comments, perhaps that can help to move things > > > > forward. > > > > > > > > First, one domain can have two parent domains. Both from DT and from > > > > genpd point of view, just to make this clear. > > > > > > > > Although, it certainly looks questionable to me, to hook up the USB > > > > device to two separate power domains, one to control power and one to > > > > control performance. Especially, if it's really the same piece of HW > > > > that is managing both things. > > > [].. > > > > Additionally, if it's correct to model > > > > the USB GDSC power domain as a child to the CX power domain from HW > > > > point of view, we should likely do that. > > > > > > I think this would still require a few things in genpd, since > > > CX and USB GDSC are power domains from different providers. > > > Perhaps a pm_genpd_add_subdomain_by_name()? > > > > > > > I think of_genpd_add_subdomain() should help to address this. No? > > We only describe the provider nodes in DT and not the individual power domains. > For instance GCC is the power domain provider which is in DT, and USB GDSC is one > of the many power domains it supports, similarly RPMHPD is the provider node in > DT and CX is one of the many power domains it supports. > So we would need some non-DT way of hooking up power domains from two different > providers as parent/child. > See 266e5cf39a0f ("arm64: dts: qcom: sm8250: remove mmcx regulator") and 3652265514f5 ("clk: qcom: gdsc: enable optional power domain support") MMCX is declared as power-domain for the dispcc (which is correct in itself) and the gdsc code will register GDSCs as subdomains of the same power-domain. To ensure this code path is invoked the clock driver itself needed this 6158b94ec807 ("clk: qcom: dispcc-sm8250: use runtime PM for the clock controller") So at least in theory, considering only USB the minimum would be to pm_runtime_enable() gcc-7280 and add power-domains = to the gcc node. The "problem" I described would be if there are GDSCs that are subdomains of MX - which I've seen hinted in some documentation. If so we should to specify both CX and MX as power-domains for &gcc and the gdsc implementation needs to be extended to allow us to select between the two. For this I believe a combination of genpd_dev_pm_attach_by_name() and of_genpd_add_subdomain() would do the trick. That is, if there actually are GDSCs exposed by gcc that are not subdomains of CX - otherwise none of this is needed. Regards, Bjorn