The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	 Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	 platform-driver-x86@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] platform/x86/intel-uncore-freq: Do not present separate package-die domain
Date: Mon, 12 Aug 2024 14:16:46 +0300 (EEST)	[thread overview]
Message-ID: <cd7cc6b8-4993-937b-072b-8fbc1e309a4d@linux.intel.com> (raw)
In-Reply-To: <20240731185756.1853197-1-srinivas.pandruvada@linux.intel.com>

On Wed, 31 Jul 2024, Srinivas Pandruvada wrote:

> The scope of uncore control is per power domain in a package and die.
> A package-die can have multiple power domains on some processors. In this
> case package-die domain (root domain) aggregates all information from
> power domains in it.
> 
> On some processors, CPUID enumerates the die number same as power domain
> ID. In this case there is one to one relationship between package-die and
> power domain ID. There is no use of aggregating information from all
> power domain IDs as the information will be duplicate and confusing. In
> this case do not create separate package-die domain.

Hi Srinivas,

I got confused by this changelog because its order is quite illogical.

First paragraph talks about case A. When you say "all information" 
is "aggregated", I immediately make the assumption that the aggregated 
information is what is wanted because, well, you normally want "all 
information" and nothing else is being told here.

Second paragraph starts to talk about case B and then suddenly switches to 
talk what should have been done in case A (that aggregated information is 
useless/confusing).

So I think some reorganization of the sentences would be useful to not 
jump between cases mid-paragraph without any hints.

(I hope my explanation is enough to highlight why it was hard to follow).

When I finally understood what the changelog was saying, I found out the 
code change is fine too but it first looked like it was doing exactly the 
opposite to my expectations/reasonale given in the changelog.

-- 
 i.


> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
>  .../x86/intel/uncore-frequency/uncore-frequency-tpmi.c     | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c
> index 9fa3037c03d1..6c2e607968f2 100644
> --- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c
> +++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c
> @@ -427,6 +427,9 @@ static int uncore_probe(struct auxiliary_device *auxdev, const struct auxiliary_
>  
>  	auxiliary_set_drvdata(auxdev, tpmi_uncore);
>  
> +	if (topology_max_dies_per_package() > 1)
> +		return 0;
> +
>  	tpmi_uncore->root_cluster.root_domain = true;
>  	tpmi_uncore->root_cluster.uncore_root = tpmi_uncore;
>  
> @@ -450,7 +453,9 @@ static void uncore_remove(struct auxiliary_device *auxdev)
>  {
>  	struct tpmi_uncore_struct *tpmi_uncore = auxiliary_get_drvdata(auxdev);
>  
> -	uncore_freq_remove_die_entry(&tpmi_uncore->root_cluster.uncore_data);
> +	if (tpmi_uncore->root_cluster.root_domain)
> +		uncore_freq_remove_die_entry(&tpmi_uncore->root_cluster.uncore_data);
> +
>  	remove_cluster_entries(tpmi_uncore);
>  
>  	uncore_freq_common_exit();
> 

  reply	other threads:[~2024-08-12 11:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31 18:57 [PATCH] platform/x86/intel-uncore-freq: Do not present separate package-die domain Srinivas Pandruvada
2024-08-12 11:16 ` Ilpo Järvinen [this message]
2024-08-12 17:09   ` srinivas pandruvada
2024-08-13  7:51     ` Ilpo Järvinen
2024-08-13 13:58       ` srinivas pandruvada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cd7cc6b8-4993-937b-072b-8fbc1e309a4d@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox