Received: by 2002:ab2:6a05:0:b0:1f8:1780:a4ed with SMTP id w5csp351738lqo; Fri, 10 May 2024 01:38:17 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUIUb/7Ian1zrHbadF1viEs/JWnPHoO5rUskI8G09HJPMOILTIzE49TgaItuPlYmzvOvVa8kDfc+uwAD7m9q0p9juaUuC8fiBr3nMtJlQ== X-Google-Smtp-Source: AGHT+IFXtAFR+p93zlWyddr/hBFGOIMoDwfHo/P/JCMMrpB0fifbB9V4YKmY2+qyRWb4l8s0LKBU X-Received: by 2002:a17:907:968a:b0:a59:c52b:9933 with SMTP id a640c23a62f3a-a5a2d58544emr169007766b.30.1715330297308; Fri, 10 May 2024 01:38:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1715330297; cv=pass; d=google.com; s=arc-20160816; b=wzpR4B3lCkB4HM1Ac0gppwgmjHyweK8hKA3kVwNVGDPSI8liKkSv8x5KpWWlme433k EhW0gNuTa8jOBXAZm5avyigkLTlRHfuXg2dym6/rRz0U+oSMHUeyOXqXfuqZfncpFh8c 6ycUx+r/ozyp/qw/yLd9VC5bv5rzbGMooeYBA+swx014+9A9QIF3hMpbk4BPa5FZBlpH mQPBj8nkMUUawl2YXmjlF5UC4rPQG+H0IN7iEEfPEUovbXMnpzx3kiW0BHFlnI5VqFX9 DVHczTpemgNiutb8KZzFrGwlZ52wA5ed0iP5jsRdr064NOuJPAF0lma06Jb3hTfoT0eD M1Fw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :dkim-signature; bh=/tC+GCN44EEZRchaMTsHP5n1JMgFOgSzdTOREHbqQhI=; fh=WhrjWTQVuuXB5+aeayyrYd2wzGbxhAhf47w3Cv85U3s=; b=xubiwG9UcROAoe51HZZmHeGXX2mvgULALI/WX0nnF4eOHg6ahaXA18yEiQsg2nqxwD LmHBpPgtdvH6NOjZprmuKWX+xKq3nxAKLnzgyy7QRRWBrENCwHeU80g8JhEEgRUG5PHq yZTfdabUaawDKGcOgw5CYsWu+qQ39AX10jn7QLqj4u2rDQLf429U5avXBOLBXTFNgjXx 4zEWzNGJlk1zXvvg+SU9/V35alRSYacqvdx2coHImUlZa+1V147hJT4y+aPOYg/kHzGj UQmtaZ6iUJaqJ3sy2ld0VDcN/mOidl54VuevjZcWJBI/68dWRVKv5sTJhFo2HeddfZia V9lw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=VYESdqjU; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-175450-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-175450-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id a640c23a62f3a-a5a17ba5866si165751966b.657.2024.05.10.01.38.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 May 2024 01:38:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-175450-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=VYESdqjU; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-175450-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-175450-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id DA5711F21898 for ; Fri, 10 May 2024 08:38:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A340A15E1E3; Fri, 10 May 2024 08:37:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="VYESdqjU" Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C306D5339A for ; Fri, 10 May 2024 08:37:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715330278; cv=none; b=jAQNtb+EfudX9Zd5aFoyO1sFzAEnO2aSiJZouCh19aeGlSIRXMxq+5ce8CJitQiM2mI1+qtB5Gpbu3BTAZxoG6e27r2JLaizkdkM4qzDtmvYb82QUnnXGNcWBXYXXIPJMSE16rhvq7yKjA9zBMdzRj4uyd8zOpj5P4+wNEIJpbo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715330278; c=relaxed/simple; bh=D6MqpekUEL0sSXzIVwtxlgQvE9xvL+OOtP7S3xFSxbk=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=H5naUULHy51fYxVzmIJd0p8Hbk6LkgqZi81PUT+IZotJ9lZSA8qNtfdm044mq+ugwtXRoim/lxsMNsq9pd0KaVsJwoFlJjI3E0k2Pe8dnimk/fLI9Um/msmAbcNuH5uv5g/HVq7PAe0mSZI/7IJJSXi7J3lssxh+zqowd+sVVPk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=VYESdqjU; arc=none smtp.client-ip=209.85.219.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-de462f3d992so1835073276.2 for ; Fri, 10 May 2024 01:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1715330276; x=1715935076; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/tC+GCN44EEZRchaMTsHP5n1JMgFOgSzdTOREHbqQhI=; b=VYESdqjUJUgOO0LbiyXqPq3vMYlePD8NISdDey7Qc8tF2QGT2qqrahItHq6fMfwUOS Ste0JixeVNrNFceML3Q0RL47IffgTIlyONJL3/uir0KObGk2Q817++n+O6TSehIHoQNG kvS5ab57bLFIjOwvk23n+a9Ut/FotS51cSpPG5NjnA1ZvOnSWmrj9sIOSjkv5ssF5rNr iRWglxQyheqErB6Hq5Rxmy+wt4FYOMhG3f6ixn6uCQu6kK2NC8dxI1lsjYrfMZa2DBjS QBxwarmM7A4G8aM/RcFbrUx34/Ka9TSY5Abd3HcYDKA7dNFcbVRQ1BiEP5pcFt3BYta1 7DrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715330276; x=1715935076; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/tC+GCN44EEZRchaMTsHP5n1JMgFOgSzdTOREHbqQhI=; b=AcAkFZr10tzYWrjmislD/BSojFvQNiv8RjIOm3OZLNpAcrcfE27xLVR6hStf5s1scG WEf8x3fkJ5P8e5rhl9rRAKEF0RV/p65+g0LhWpQZwRLV8XnsA6F2/CLwooLyRnq+gyDI ETX5CveLC2FGZNbmUS8Jf2AYciXctajDsZHX0U0/andE5/In7iwWbcUi/9b+ZFjMdRub t0bk0FmOOV5VWXfODyKhQPQxNc8dJAdVWfanriq1QUqGe63QR6o6dIDbiTCmCXp9nNXz SNlVx0Vae4aGRDt9LNUtfpMn3VuLUO8VFg1lM+RV3B44Q+NTztj8V6i9GJFelp4q76/7 m84g== X-Forwarded-Encrypted: i=1; AJvYcCVKprsEx5HUGhpJJtVNbErzc7/acKpk6koo1A76MFt1KbGAaxg0cS39J3Evr2SEO8/xtDEQQk8xhGUVwWTYHj9uXRg1fICGkSrB98tV X-Gm-Message-State: AOJu0YzGMjU838m7FdedIqidmS8xIL5IEO9hyvCNBB3Ub/DDYdL1WzSK GuX01QWIXTLHg5I7WkB8CYvzI6klhPQB9aFIIkgysro9cQDhFqwPdEBNqCX5CL5H5/m6kfg5KMt s8siUEAZ5W/cSSlkg82EHJZoGynRreE/KPngSNQ== X-Received: by 2002:a25:c583:0:b0:de7:61db:9fa0 with SMTP id 3f1490d57ef6-dee4f2e35b4mr2224213276.22.1715330275768; Fri, 10 May 2024 01:37:55 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <2eb72832e852c80e5c11cd69e7d2f14cefd8b1cb.1712903998.git.viresh.kumar@linaro.org> In-Reply-To: From: Ulf Hansson Date: Fri, 10 May 2024 10:37:18 +0200 Message-ID: Subject: Re: [PATCH V2] OPP: Fix required_opp_tables for multiple genpds using same table To: Thorsten Leemhuis Cc: Viresh Kumar , Viresh Kumar , Nishanth Menon , Stephen Boyd , "Rafael J. Wysocki" , linux-pm@vger.kernel.org, Vincent Guittot , Vladimir Lypak , linux-kernel@vger.kernel.org, Linux kernel regressions list Content-Type: text/plain; charset="UTF-8" On Thu, 9 May 2024 at 14:35, Thorsten Leemhuis wrote: > > > > On 12.04.24 08:41, Viresh Kumar wrote: > > The required_opp_tables parsing is not perfect, as the OPP core does the > > parsing solely based on the DT node pointers. > > > > The core sets the required_opp_tables entry to the first OPP table in > > the "opp_tables" list, that matches with the node pointer. > > > > If the target DT OPP table is used by multiple devices and they all > > create separate instances of 'struct opp_table' from it, then it is > > possible that the required_opp_tables entry may be set to the incorrect > > sibling device. > > > > Unfortunately, there is no clear way to initialize the right values > > during the initial parsing and we need to do this at a later point of > > time. > > > > Cross check the OPP table again while the genpds are attached and fix > > them if required. > > > > Also add a new API for the genpd core to fetch the device pointer for > > the genpd. > > > > Cc: Thorsten Leemhuis > > Reported-by: Vladimir Lypak > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218682 > > Did this fall through the cracks? Just wondering, as from here it looks > like for about four weeks now nothing happened to fix the regression > linked above. But I might have missed something. Or is everybody waiting > for a test from the reporter? > > Ciao, Thorsten Hi Thorsten, I have chatted a bit with Viresh about this problem offlist, while both me and him are/have been on vacations. Sorry for the delay and confusion. The latest update from my side is that I am working on a solution, that aim to remove the entire dev|devm_pm_opp_detach_genpd() API. Instead, the plan is to move consumer drivers to use dev_pm_domain_attach_list() to attach multiple PM domains per device. When it comes to hooking up the required-opps-tables/devs, I think genpd should be able to manage this during the device attach process. In this way, consumer drivers shouldn't need to care about this at all. That said, I am hoping that $subject patch should not be needed. Although, I need a bit more time before I am ready to post a patchset for the above. What do you think? Kind regards Uffe > > > > Co-developed-by: Vladimir Lypak > > Signed-off-by: Viresh Kumar > > --- > > V2: > > - Fix an `if` condition. > > - s/Bugzilla/Closes/ and change ordering. > > > > drivers/opp/core.c | 31 ++++++++++++++++++++++++++++++- > > drivers/pmdomain/core.c | 10 ++++++++++ > > include/linux/pm_domain.h | 6 ++++++ > > 3 files changed, 46 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > > index e233734b7220..cb4611fe1b5b 100644 > > --- a/drivers/opp/core.c > > +++ b/drivers/opp/core.c > > @@ -2394,7 +2394,8 @@ static void _opp_detach_genpd(struct opp_table *opp_table) > > static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev, > > const char * const *names, struct device ***virt_devs) > > { > > - struct device *virt_dev; > > + struct device *virt_dev, *gdev; > > + struct opp_table *genpd_table; > > int index = 0, ret = -EINVAL; > > const char * const *name = names; > > > > @@ -2427,6 +2428,34 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev, > > goto err; > > } > > > > + /* > > + * The required_opp_tables parsing is not perfect, as the OPP > > + * core does the parsing solely based on the DT node pointers. > > + * The core sets the required_opp_tables entry to the first OPP > > + * table in the "opp_tables" list, that matches with the node > > + * pointer. > > + * > > + * If the target DT OPP table is used by multiple devices and > > + * they all create separate instances of 'struct opp_table' from > > + * it, then it is possible that the required_opp_tables entry > > + * may be set to the incorrect sibling device. > > + * > > + * Cross check it again and fix if required. > > + */ > > + gdev = dev_to_genpd_dev(virt_dev); > > + if (IS_ERR(gdev)) > > + return PTR_ERR(gdev); > > + > > + genpd_table = _find_opp_table(gdev); > > + if (!IS_ERR(genpd_table)) { > > + if (genpd_table != opp_table->required_opp_tables[index]) { > > + dev_pm_opp_put_opp_table(opp_table->required_opp_tables[index]); > > + opp_table->required_opp_tables[index] = genpd_table; > > + } else { > > + dev_pm_opp_put_opp_table(genpd_table); > > + } > > + } > > + > > /* > > * Add the virtual genpd device as a user of the OPP table, so > > * we can call dev_pm_opp_set_opp() on it directly. > > diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c > > index 4215ffd9b11c..c40eda92a85a 100644 > > --- a/drivers/pmdomain/core.c > > +++ b/drivers/pmdomain/core.c > > @@ -184,6 +184,16 @@ static struct generic_pm_domain *dev_to_genpd(struct device *dev) > > return pd_to_genpd(dev->pm_domain); > > } > > > > +struct device *dev_to_genpd_dev(struct device *dev) > > +{ > > + struct generic_pm_domain *genpd = dev_to_genpd(dev); > > + > > + if (IS_ERR(genpd)) > > + return ERR_CAST(genpd); > > + > > + return &genpd->dev; > > +} > > + > > static int genpd_stop_dev(const struct generic_pm_domain *genpd, > > struct device *dev) > > { > > diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h > > index 772d3280d35f..f24546a3d3db 100644 > > --- a/include/linux/pm_domain.h > > +++ b/include/linux/pm_domain.h > > @@ -260,6 +260,7 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd, > > int pm_genpd_init(struct generic_pm_domain *genpd, > > struct dev_power_governor *gov, bool is_off); > > int pm_genpd_remove(struct generic_pm_domain *genpd); > > +struct device *dev_to_genpd_dev(struct device *dev); > > int dev_pm_genpd_set_performance_state(struct device *dev, unsigned int state); > > int dev_pm_genpd_add_notifier(struct device *dev, struct notifier_block *nb); > > int dev_pm_genpd_remove_notifier(struct device *dev); > > @@ -307,6 +308,11 @@ static inline int pm_genpd_remove(struct generic_pm_domain *genpd) > > return -EOPNOTSUPP; > > } > > > > +static inline struct device *dev_to_genpd_dev(struct device *dev) > > +{ > > + return ERR_PTR(-EOPNOTSUPP); > > +} > > + > > static inline int dev_pm_genpd_set_performance_state(struct device *dev, > > unsigned int state) > > {