Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp244193imw; Mon, 4 Jul 2022 08:25:44 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tTKn0WlBZBDCDjkKn5eHcTEcVf+lipxsgVARtAiJE+kt7OWfCW2rrzw6QcC2cs7omDS9RN X-Received: by 2002:a50:c209:0:b0:435:6b37:46cb with SMTP id n9-20020a50c209000000b004356b3746cbmr40137864edf.341.1656948343877; Mon, 04 Jul 2022 08:25:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656948343; cv=none; d=google.com; s=arc-20160816; b=Kh1c5uT0gPjjFX9qBzrKiycaNMr5ofXrl+2+Lm4rgQPXxXm8IXNqPV7N+VHzdWNzjE 5t2q+qBEZZwcw5e9ft+6R/d3cjSMlmQubXDzR8McPD7ydTpaywfd2d5wR4H5D9sTyosU TS/GzXmOHpsyxKc03d747UBE5HlgvjM3mmCHQeMTnLEKLLnwIYyjMtSvNJWY03fx8i6Q kmcvN35GFixzKg1kHyjjDek26NXroL5H1NI1a8YNFM4LbyH+hxQAmwQtif5BMqzfc31F fdSmMts0Du/20dPpvEZhAjRJF+17wROLby+adSk9ZSxyXexSIQD0pNmjhEwn2kAXWZyj BXZg== 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; bh=NnV7GDi4ToAtvfZvposa3K0zXlOQCOcEKPDc3BJ6zGw=; b=q5ZTEVnBLRJ8ymkD7bcOK0r6U4UYUyFyL2tlI4HUMatbpcgy7LjxDpoHHl4IuBmbqO Lww9yqvqC8WCyZl/CyMVUAXBJLPvAdU3sC8f7dUsK09uUFS18vwB2z0mUgRpn0LX/573 BrZIoX7v2mCPKzBuHKRhI/HcuO4/gLVFmOnHQUm7gyrMZQ7atXXMUn3ZDo1bfEAaIxnK NDZDMQtSvg4CFLHqCwR80z3tLwDvMF4LxxN3A8/GkqP0jfiyC7l3Esr8H547lrAaAqCP qCZZKgICJZNhP5q1Bxn+dXJYi2F+4tsWJURT91vNb47TnoE/QquNHeOPpsEQ6EsHJqv7 yN3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ji6-20020a170907980600b0070d00528830si16910145ejc.221.2022.07.04.08.25.19; Mon, 04 Jul 2022 08:25:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233637AbiGDPVY (ORCPT + 99 others); Mon, 4 Jul 2022 11:21:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231250AbiGDPVX (ORCPT ); Mon, 4 Jul 2022 11:21:23 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A60895F4C for ; Mon, 4 Jul 2022 08:21:22 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BAD5923A; Mon, 4 Jul 2022 08:21:22 -0700 (PDT) Received: from bogus (unknown [10.57.39.193]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD36E3F792; Mon, 4 Jul 2022 08:21:19 -0700 (PDT) Date: Mon, 4 Jul 2022 16:20:08 +0100 From: Sudeep Holla To: Conor.Dooley@microchip.com Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, Valentina.FernandezAlanis@microchip.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, wangqing@vivo.com, robh+dt@kernel.org, rafael@kernel.org, ionela.voinescu@arm.com, pierre.gondois@arm.com, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v6 00/21] arch_topology: Updates to add socket support and fix cluster ids Message-ID: <20220704152008.pc4s2olkdqfnx34h@bogus> References: <20220704101605.1318280-1-sudeep.holla@arm.com> <6a647b6b-c913-b9d7-a23e-b17a8034c5c8@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a647b6b-c913-b9d7-a23e-b17a8034c5c8@microchip.com> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 04, 2022 at 03:10:30PM +0000, Conor.Dooley@microchip.com wrote: > On 04/07/2022 11:15, Sudeep Holla wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > Hi Greg, > > > > Let me know if you prefer to pull the patches directly or prefer pull > > request. It has been in -next for a while now. > > > > Hi All, > > > > This version updates cacheinfo to populate and use the information from > > there for all the cache topology. > > > > This series intends to fix some discrepancies we have in the CPU topology > > parsing from the device tree /cpu-map node. Also this diverges from the > > behaviour on a ACPI enabled platform. The expectation is that both DT > > and ACPI enabled systems must present consistent view of the CPU topology. > > > > Currently we assign generated cluster count as the physical package identifier > > for each CPU which is wrong. The device tree bindings for CPU topology supports > > sockets to infer the socket or physical package identifier for a given CPU. > > Also we don't check if all the cores/threads belong to the same cluster before > > updating their sibling masks which is fine as we don't set the cluster id yet. > > > > These changes also assigns the cluster identifier as parsed from the device tree > > cluster nodes within /cpu-map without support for nesting of the clusters. > > Finally, it also add support for socket nodes in /cpu-map. With this the > > parsing of exact same information from ACPI PPTT and /cpu-map DT node > > aligns well. > > > > The only exception is that the last level cache id information can be > > inferred from the same ACPI PPTT while we need to parse CPU cache nodes > > in the device tree. > > For DT + RISC-V on PolarFire SoC and SiFive fu540 > Tested-by: Conor Dooley > > Anecdotally, v5 was tested on the !SMP D1 which worked fine when > CONFIG_SMP was enabled. > Thanks a lot for testing on RISC-V, much appreciated! Thanks for your patience and help with v5 so that we could figure out the silly issue finally. -- Regards, Sudeep