Message ID | 20240216000837.1868917-2-samuel.holland@sifive.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-67874-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:c619:b0:108:e6aa:91d0 with SMTP id hn25csp201298dyb; Thu, 15 Feb 2024 16:09:12 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXUWdifw3iXl0MGg/9CiFeeyj0TDHJbU/Xzy/UooqsSu8sqhTsR3VZOfTNzrSz+66ieNThHPj3Pk6+wGtABVeT+oE6AKA== X-Google-Smtp-Source: AGHT+IGLyzxKlz/9ZGksZjAcFV409vWB4OYaDP7gdyLstdgUhdXKqCMcHiwNN3xiASron+wk8yio X-Received: by 2002:a50:ef0c:0:b0:55f:fc6f:835a with SMTP id m12-20020a50ef0c000000b0055ffc6f835amr2476546eds.31.1708042152556; Thu, 15 Feb 2024 16:09:12 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708042152; cv=pass; d=google.com; s=arc-20160816; b=Nt3AiDm5b77vdcJYp4SB5vLjEIrq9gKzgclsSijzmF83J+F1+gdpK5NvRgtAhpH/8/ BP811estMjJF98gT1ZfVWyGWbIncdB+g4qMgZiiomOHrL52w2t0FXIPt7d8Nr08hzOv+ EEjpfqj72sc32GMIh+cH1vB60XY153xwdKyHJcyF0qt6zC8E0Jp7VqwU8qinpLfy1frK 4PtvUtCXDuXy2kGmSpI0C5EBX0Y3eBuylVpq2Z8zq0EFaysDgsCDQHbLgiMThS+/Yw4J 0GfCw/gj4oePsMUNcQDfPFh0VnWMwH0qINNqlD4IMqJLlfHQj5vTdmoXbQ5nqEPSbbvh X28Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=oULp81TNDm6rtXJp1+1NlVw8kUN7N6Lx6G6xlg9BNVs=; fh=JPQLSNQRZ7gouaNZAHa0NGpROorXJnrbOx0eSl+VuMk=; b=0YCpTEC0R2UxGSj7wzN0cTL7N2GBJ4/gOi+WSPk4KQf07G2LCc1pePvcepuW+gdPw7 spYqZUmE2NCAjWD8Y9RYj3qe+p/tkpsfYB6tRrTHd4iYBC7REesispDyX04fC7eOpafI nI+XccWWHYJErOtanaH6A9NZ/Cp2R/XtVXCgPnoQtXM0lptD/fB1+m4gk/CmwLI/+T6J btRlS72ORWSXOGHDovHKoSKR3DAZuF5yhsLw/odSMvNlp8tEV3uM3IFhGckxF3tEzBsi gt24c4PKlCD4hmkiQ4+PGQFSy3Xeh14ngYxeUqXPk3vwKDClDFXh51yNNzKzN4G/vloy obwA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=DxDCxmkx; arc=pass (i=1 spf=pass spfdomain=sifive.com dkim=pass dkdomain=sifive.com dmarc=pass fromdomain=sifive.com); spf=pass (google.com: domain of linux-kernel+bounces-67874-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67874-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sifive.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id a35-20020a509ea6000000b0055eba1df579si1066071edf.571.2024.02.15.16.09.12 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 16:09:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-67874-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=DxDCxmkx; arc=pass (i=1 spf=pass spfdomain=sifive.com dkim=pass dkdomain=sifive.com dmarc=pass fromdomain=sifive.com); spf=pass (google.com: domain of linux-kernel+bounces-67874-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-67874-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sifive.com 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 B89B81F2545F for <ouuuleilei@gmail.com>; Fri, 16 Feb 2024 00:09:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A5CED8F48; Fri, 16 Feb 2024 00:08:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="DxDCxmkx" Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 DC5E17F9 for <linux-kernel@vger.kernel.org>; Fri, 16 Feb 2024 00:08:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708042125; cv=none; b=AIQFySvJ2gHjBV/sLl70sA2tulY1t5Bs+1I4W4UIF6JGiWZ6AEXH4CbWUYTOi11NqTN/+I/AqRZhzq7LCbLJ4GoZTEZZEffIJDnqbHPyhTwdUCPuNC42qh/Rj4xR54LoHuThGzFMPxitwYQBuFKrFvvhBFfifU3oCInkfgzH5qs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708042125; c=relaxed/simple; bh=+ztwmbEweby5bHFMBlDPRY9F7IaAz7efgcfvXOjOMFo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BtINdjCUmCoaFUENDLYxNqIizMisAou6ZZSS68l0gbF2MG4ki4fR6XmH3QNknndp1cgxn9Qx6IHRcbuS0Wq6uCVGWlBAcTZ0Mr+BJ+jKefWEPvw6qjx7ei/XDHP1mSsKLnfeoj5MsZwZKiZlg4+NZgTm6N8rU3vMO/NZeoxZDiw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=DxDCxmkx; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1d7881b1843so13147205ad.3 for <linux-kernel@vger.kernel.org>; Thu, 15 Feb 2024 16:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1708042122; x=1708646922; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oULp81TNDm6rtXJp1+1NlVw8kUN7N6Lx6G6xlg9BNVs=; b=DxDCxmkxjrrukDu9xKwUBIYHc+JGcrFCNIUcqbUex3+GhYvfHY4QKNmZDYQF5bg32W 1LZf4MdOo3ae1YogH6bNjOYX4GJ+4SvREvRnZJAye+iIRMK1TIbvaA24P12yZ07A8ARA D+XPXiB3RcSHUFCBbOHGYJZs4xWSyUp8To/xxuWUNYEqftMOMwZ2SC8B8FAYPXpIOgEc zVK4q9r9rJ5s9FisZPtsryqa0sD7A4kwfk9HGJ0HF+0IgIzYHCbyCiBo2OADL1Gfiya5 iZT4vjEqE/6BX9N3/sxNegIejDaVAsqFmS9mtGQeqoLAvkPo0Tg3bGnpJc6/yxEuYeqv F2CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708042122; x=1708646922; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oULp81TNDm6rtXJp1+1NlVw8kUN7N6Lx6G6xlg9BNVs=; b=voLaDMcx7GaI+sMbLX0+aMTv0cU5PYE6q7rRUES3GOfWaCfKvtGPoU1ohTiNZYmkEk cnSnlc4FyXkYaSrQiJpi9OD/71GmaVSf2YeDSvAF2M76il5Oh0cqB1EtyO5WPR4VEJ6e OM46stEuM1kWSzVfFqieGkrJMkQFQqzSr0e9U2RkUoCMnWT4eyCM6fjb80PvQbV5rpEH xTePD4jPkc08atyz2/f+yghvvbII29Z5YssaVNqB4SabAM2cG6XxbEE7YYtC+TeVTk/3 rZfE7hRt3HJremtfG1DWtDk7YX3pMLS6AdG2i1XYwcyX9qgOi/dn+ruBxK6IF2s/j7jT Uywg== X-Forwarded-Encrypted: i=1; AJvYcCVkiiwK+4n0IEk0BtNh0+EIWBOvQ/bpn56e1oWzWEjLaNuif6NOJ7VeLe6IEGZjgE1B8Dx6V/llBFLAh5PBZ77MRpkVylJRsShQ7JcT X-Gm-Message-State: AOJu0YxXlr1zQdFiJwhiTtQp3FNGy0/d6/8RDTfE+o6YkPxiNArWjvdl HoZpm6IZSmkMZyOn7quSZ+wiNfe8qdfwQuiU7a3BVcnqR5oJy6NVFuvWgg3d2MM= X-Received: by 2002:a17:903:1212:b0:1d9:14fb:d142 with SMTP id l18-20020a170903121200b001d914fbd142mr3570668plh.32.1708042122114; Thu, 15 Feb 2024 16:08:42 -0800 (PST) Received: from sw06.internal.sifive.com ([4.53.31.132]) by smtp.gmail.com with ESMTPSA id bb6-20020a170902bc8600b001db3d365082sm1789486plb.265.2024.02.15.16.08.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 16:08:41 -0800 (PST) From: Samuel Holland <samuel.holland@sifive.com> To: Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Eric Lin <eric.lin@sifive.com>, Conor Dooley <conor@kernel.org> Cc: Palmer Dabbelt <palmer@dabbelt.com>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Paul Walmsley <paul.walmsley@sifive.com>, linux-riscv@lists.infradead.org, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, linux-arm-kernel@lists.infradead.org, Samuel Holland <samuel.holland@sifive.com> Subject: [PATCH v1 1/6] dt-bindings: cache: Document the sifive,perfmon-counters property Date: Thu, 15 Feb 2024 16:08:13 -0800 Message-ID: <20240216000837.1868917-2-samuel.holland@sifive.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240216000837.1868917-1-samuel.holland@sifive.com> References: <20240216000837.1868917-1-samuel.holland@sifive.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791012008389115740 X-GMAIL-MSGID: 1791012008389115740 |
Series |
SiFive cache controller PMU drivers
|
|
Commit Message
Samuel Holland
Feb. 16, 2024, 12:08 a.m. UTC
The SiFive Composable Cache controller contains an optional PMU with a
configurable number of event counters. Document a property which
describes the number of available counters.
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
Documentation/devicetree/bindings/cache/sifive,ccache0.yaml | 5 +++++
1 file changed, 5 insertions(+)
Comments
On 16/02/2024 01:08, Samuel Holland wrote: > The SiFive Composable Cache controller contains an optional PMU with a > configurable number of event counters. Document a property which Configurable in what context? By chip designers or by OS? Why this cannot be deduced from the compatible? > describes the number of available counters. > > Signed-off-by: Samuel Holland <samuel.holland@sifive.com> > --- > > Documentation/devicetree/bindings/cache/sifive,ccache0.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > Best regards, Krzysztof
Hi Krzysztof, On 2024-02-17 3:00 AM, Krzysztof Kozlowski wrote: > On 16/02/2024 01:08, Samuel Holland wrote: >> The SiFive Composable Cache controller contains an optional PMU with a >> configurable number of event counters. Document a property which > > Configurable in what context? By chip designers or by OS? Why this > cannot be deduced from the compatible? This parameter is configurable by the chip designers. The information certainly can be deduced from the SoC-specific compatible string, but doing so makes the driver only work on that specific list of SoCs. When provided via a property, the driver can work without changes on any SoC that uses this IP block. (None of the SoCs currently listed in the binding contain a PMU, so there is no backward compatibility concern with adding the new property.) My understanding of the purpose of the SoC-specific compatible string is to handle eventualities (silicon bugs, integration quirks, etc.), not to intentionally limit the driver to a narrow list of hardware. Regards, Samuel >> describes the number of available counters. >> >> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> >> --- >> >> Documentation/devicetree/bindings/cache/sifive,ccache0.yaml | 5 +++++ >> 1 file changed, 5 insertions(+) >>
On 18/02/2024 16:29, Samuel Holland wrote: > Hi Krzysztof, > > On 2024-02-17 3:00 AM, Krzysztof Kozlowski wrote: >> On 16/02/2024 01:08, Samuel Holland wrote: >>> The SiFive Composable Cache controller contains an optional PMU with a >>> configurable number of event counters. Document a property which >> >> Configurable in what context? By chip designers or by OS? Why this >> cannot be deduced from the compatible? > > This parameter is configurable by the chip designers. > > The information certainly can be deduced from the SoC-specific compatible > string, but doing so makes the driver only work on that specific list of SoCs. Usually that's exactly what's expected, so why here usual approach is wrong? > When provided via a property, the driver can work without changes on any SoC > that uses this IP block. (None of the SoCs currently listed in the binding Sorry, properties are not a work-around for missing compatibles. > contain a PMU, so there is no backward compatibility concern with adding the new > property.) > > My understanding of the purpose of the SoC-specific compatible string is to > handle eventualities (silicon bugs, integration quirks, etc.), not to > intentionally limit the driver to a narrow list of hardware. Depends what is the hardware. For most of licensed blocks, the final design is the hardware so equals to its compatible. Best regards, Krzysztof
On Sun, Feb 18, 2024 at 07:35:35PM +0100, Krzysztof Kozlowski wrote: > On 18/02/2024 16:29, Samuel Holland wrote: > > Hi Krzysztof, > > > > On 2024-02-17 3:00 AM, Krzysztof Kozlowski wrote: > >> On 16/02/2024 01:08, Samuel Holland wrote: > >>> The SiFive Composable Cache controller contains an optional PMU with a > >>> configurable number of event counters. Document a property which > >> > >> Configurable in what context? By chip designers or by OS? Why this > >> cannot be deduced from the compatible? > > > > This parameter is configurable by the chip designers. > > > > The information certainly can be deduced from the SoC-specific compatible > > string, but doing so makes the driver only work on that specific list of SoCs. > > Usually that's exactly what's expected, so why here usual approach is wrong? > > > When provided via a property, the driver can work without changes on any SoC > > that uses this IP block. (None of the SoCs currently listed in the binding > > Sorry, properties are not a work-around for missing compatibles. > > > contain a PMU, so there is no backward compatibility concern with adding the new > > property.) > > > > My understanding of the purpose of the SoC-specific compatible string is to > > handle eventualities (silicon bugs, integration quirks, etc.), not to > > intentionally limit the driver to a narrow list of hardware. > > Depends what is the hardware. For most of licensed blocks, the final > design is the hardware so equals to its compatible. While I generally agree, I think a property is fine here for 2 reasons. This is going to vary on just about every design. That's true for any PMU. So maybe this shouldn't even be SiFfive specific. The second is counters available to the OS may not equal the number in h/w because counters could be reserved for different priviledge levels (secure, hypervisor, guest, etc.). No idea if Risc-V supports this, but if not it is a matter of time. That's more likely for a core PMU than an uncore PMU. Rob
diff --git a/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml index 7e8cebe21584..100eda4345de 100644 --- a/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml +++ b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml @@ -81,6 +81,11 @@ properties: The reference to the reserved-memory for the L2 Loosely Integrated Memory region. The reserved memory node should be defined as per the bindings in reserved-memory.txt. + sifive,perfmon-counters: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: Number of PMU counter registers + allOf: - $ref: /schemas/cache-controller.yaml#