Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4488993pxv; Tue, 29 Jun 2021 08:11:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhUHNeiMQL/EiMHhnKeib8DbuQLpyOEHN8J/uMXF6GaU/w+w2dZqyo3MHSfTlGXW4sJvkE X-Received: by 2002:a17:906:ae57:: with SMTP id lf23mr16503711ejb.205.1624979463343; Tue, 29 Jun 2021 08:11:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624979463; cv=none; d=google.com; s=arc-20160816; b=vR7A/dPNOm9GfnZIiQ3Z633W2JpYTQbqO/jtdi+Onq/3ZkLHqhLwLaWVk31/5ttlCc g/hyz47yNsnbLm19RAlwLjOt+ehblxSaoQU+x8OBHOLNPtQgFDqrak/yisZqogv4GlEs GV8EehLVYzFkojKGbdxRDyJTm4qwR62n+FayhAsVLSwze89z1ay640xUf7Q9LwmFlK8C MrdaoCHaXMnJuSAWGSZ+Y0em0aYUs7TCw7XcXV21s/+7C+gPZ+y6iGiRecON4vhRFZiW njGH2T3uPD0BcI+ZEGXryg/Xdzp6BIArMJgG3ipogG7sqXLJZKdMyJeDcSgjXz0b9Vpk FOaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wLi/ReYn+FMDqDclGBkonZrrzMrcsqsuKIgDcZh360Y=; b=vY6YLZ3lu0af31ZweP3xq3RqcqK31SfOPIEGUhomrzh+uN860LBQxpRZxfiyzpx7w+ jvcec383TD3Z4JzpnTOFxVdCzCTkUR0Y4nTLc5ulRS22f1thfqgnqiFE85LLjglPZmop xT4V9TxOMMwhLA0XomRMLaexE966go5tJBgYE+FBOsCvupHVxKt7iu4GykHzqmnZFfOW xhEMqu9tqJUsBrnS/9f/V23helQKndwYOlMtxE79UcnqEh6teTuaVrrYwKuy0Mtyk/dW xb4yGXjTsVX/w+8N3TuVeayU49lNOi+JYrN3k6Rgp8fILXjmrHAJemeSFh0lollKnCrJ dcag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BL7L2hE2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id el8si17825592ejc.275.2021.06.29.08.10.38; Tue, 29 Jun 2021 08:11:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BL7L2hE2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S234671AbhF2PMD (ORCPT + 99 others); Tue, 29 Jun 2021 11:12:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234655AbhF2PMC (ORCPT ); Tue, 29 Jun 2021 11:12:02 -0400 Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF5FCC061760 for ; Tue, 29 Jun 2021 08:09:34 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id k206so7739738oif.2 for ; Tue, 29 Jun 2021 08:09:34 -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=wLi/ReYn+FMDqDclGBkonZrrzMrcsqsuKIgDcZh360Y=; b=BL7L2hE2loKs368r+ee+AI+RlZZQa58t+tkSRnZlRGSaJ+h1nwfmNe8qnpI0zT5yCu efdo6KHJrCsi8Oddswo+Fmcl8Fmh9ugakIP6DDUbft4mM9PAjcYe7Pv8Zej8EapJLd4t 2EWK+aYAs/Q/S9Nu9kWhpMvK+BG4nfyPb8n9z0Z6DxqOVDFk4Mk/9/cgNJkrSxujQx63 CVVqY1JQrFRGLIJ9mYP28NePKFU56iPb3MXt75DAHRZtWk1MIlxqBpxdrjaJIkHcCwsq xXYAqN+k3tV9BY9WWwW7lpfaC05EjLy49KDyzdZlHm+z4yt3/p3//k/namH03wOp8uCi 32Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wLi/ReYn+FMDqDclGBkonZrrzMrcsqsuKIgDcZh360Y=; b=Z8d7H+HV1bjf662EjwR5cYAa72VgEzpxHeqGZgB4Kc2Bry6iJtmcVVgYyOkYdV0qUN VxG14AvdYuGHKWolRp71/UoMwtGlNiKhx4tIrzQnYFBhQ3V4x5nVOqy1ejmg2x/p1MVz 0eaYIc3W1Fh0J5MvdtPeBz4z+sflapVHw4Mc/32JLIIe6UR7Z60Da9sJcHFWbCbT1/zu JgeRzlXVnS1BlVzVn/UqEyy1i4ITvzhsxdBjCoOzKpNfkijqKuYmMM6DW4c+8pXvRK4d KvH/vxQRgej91uzf3xC1tWSDK7JtbX8wBdhm2W97VyCrYfokkwSj9x2aSu2I52bjtkwa PIOA== X-Gm-Message-State: AOAM533NZLI/I+8rv18iIh3hJAPHjV7aufIwnKRQBl4tXJJ9hb5Me7aT ZM84S8TveFuzhH9tIfhSUIFjSw== X-Received: by 2002:aca:5dc6:: with SMTP id r189mr25530559oib.164.1624979374103; Tue, 29 Jun 2021 08:09:34 -0700 (PDT) Received: from yoga (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id 94sm4139981otj.33.2021.06.29.08.09.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Jun 2021 08:09:33 -0700 (PDT) Date: Tue, 29 Jun 2021 10:09:31 -0500 From: Bjorn Andersson To: Dmitry Baryshkov Cc: Ulf Hansson , Mark Brown , Stephen Boyd , "Rafael J. Wysocki" , Kevin Hilman , Greg Kroah-Hartman , Linux PM , Linux Kernel Mailing List , Rajendra Nayak Subject: Re: [PATCH 2/2] PM: domain: use per-genpd lockdep class Message-ID: References: <20210611101540.3379937-1-dmitry.baryshkov@linaro.org> <20210611101540.3379937-3-dmitry.baryshkov@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 28 Jun 14:55 CDT 2021, Dmitry Baryshkov wrote: > Hi, > > On 17/06/2021 12:07, Ulf Hansson wrote: > > + Rajendra > > > > On Tue, 15 Jun 2021 at 17:55, Bjorn Andersson > > wrote: [..] > > > But I am unable to find a way for the gdsc driver to get hold of the > > > struct generic_pm_domain of the resources exposed by the rpmhpd driver. > > > > You don't need a handle to the struct generic_pm_domain, to assign a > > parent/child domain. Instead you can use of_genpd_add_subdomain(), > > which takes two "struct of_phandle_args*" corresponding to the > > parent/child device nodes of the genpd providers and then let genpd > > internally do the look up. > [..] > > I think I'd need this function anyway for the gdsc code. During gdsc_init() > we check gdsc status and this requires register access (and thus powering on > the parent domain) before the gdsc is registered itself as a power domain. > But this is a register access in the dispcc block, which is the context that our gdsc_init() operates. So describing that MMCX is the power-domain for dispcc should ensure that the power-domain is enabled. We do however need to make sure that dispcc doesn't hog its power-domain, and that any register accesses in runtime is done with the parenting power-domain enabled. E.g. the clock framework wraps all operations in pm_runtime_get/put(), but I don't see anything in the gnepd code for this. And for gcc I'm worried that we might have some GDSCs that are parented by CX and some by MX, but I do still think that the register accesses are only related to one of these. But this seems like a continuation of the special case in dispcc, so I think we should be able to focus on getting that right before we attempt the general case (and I don't know if we have a need for this today). Regards, Bjorn