[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221107231152.GB1779129-robh@kernel.org>
Date: Mon, 7 Nov 2022 17:11:52 -0600
From: Rob Herring <robh@...nel.org>
To: Pierre Gondois <pierre.gondois@....com>
Cc: linux-kernel@...r.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Florian Fainelli <f.fainelli@...il.com>,
Scott Branden <sbranden@...adcom.com>,
Tsahee Zidenberg <tsahee@...apurnalabs.com>,
Antoine Tenart <atenart@...nel.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Kevin Hilman <khilman@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Sudeep Holla <sudeep.holla@....com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Rafał Miłecki <rafal@...ecki.pl>,
Alim Akhtar <alim.akhtar@...sung.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Andreas Färber <afaerber@...e.de>,
Matthias Brugger <mbrugger@...e.com>,
Wei Xu <xuwei5@...ilicon.com>, Chanho Min <chanho.min@....com>,
Andrew Lunn <andrew@...n.ch>,
Gregory Clement <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Lars Povlsen <lars.povlsen@...rochip.com>,
Steen Hegelund <Steen.Hegelund@...rochip.com>,
Daniel Machon <daniel.machon@...rochip.com>,
Avi Fishman <avifishman70@...il.com>,
Tomer Maimon <tmaimon77@...il.com>,
Tali Perry <tali.perry1@...il.com>,
Patrick Venture <venture@...gle.com>,
Nancy Yuen <yuenn@...gle.com>,
Benjamin Fair <benjaminfair@...gle.com>,
Thierry Reding <thierry.reding@...il.com>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Magnus Damm <magnus.damm@...il.com>,
Heiko Stuebner <heiko@...ech.de>,
Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Jisheng Zhang <jszhang@...nel.org>, Nishanth Menon <nm@...com>,
Vignesh Raghavendra <vigneshr@...com>,
Tero Kristo <kristo@...nel.org>, Peng Fan <peng.fan@....com>,
Lucas Stach <l.stach@...gutronix.de>,
Adam Ford <aford173@...il.com>,
Tim Harvey <tharvey@...eworks.com>,
Richard Zhu <hongxing.zhu@....com>,
Joakim Zhang <qiangqing.zhang@....com>,
Markus Niebel <Markus.Niebel@...tq-group.com>,
Marek Vasut <marex@...x.de>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Alexander Stein <alexander.stein@...tq-group.com>,
Paul Elder <paul.elder@...asonboard.com>,
David Heidelberg <david@...t.cz>,
Oliver Graute <oliver.graute@...oconnector.com>,
Liu Ying <victor.liu@....com>, Jacky Bai <ping.bai@....com>,
Chris Packham <chris.packham@...iedtelesis.co.nz>,
Vidya Sagar <vidyas@...dia.com>,
Johan Jonker <jbx6244@...il.com>,
Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 00/23] Update cache properties for arm64 DTS
On Mon, Nov 07, 2022 at 04:56:53PM +0100, Pierre Gondois wrote:
> v2:
> - Update/Add patches for missed cache properties requiring to be
> updated for the following platforns: bcm, amazon, arm, exynos,
> freescale, marvell, mediatek, nvidia, socinext, tesla, ti.
> Missed cache properties were detected using Rob Herring's branch:
> https://github.com/robherring/dt-schema/tree/cache-rework
> - v1 of exynos, tesla were merged.
> - Updated wrong reference in commit message.
> - Added received Rb/Acked-by.
>
> Align arm64 DTS to the DeviceTree specification v0.3 regarding
> cache properties. The patch-set mainly adds 'cache-level' or
> 'cache' compatibility properties.
> For one qcom DTS, level 1 cache nodes are removed as they should
> be in the cpu nodes.
>
> On another node, it seems that the 'cache-unified' is under-used.
> cache-unified:
> If present, specifies the cache has a unified or-
> ganization. If not present, specifies that the
> cache has a Harvard architecture with separate
> caches for instructions and data.
> Only a few l2 cache nodes have this property, and in the absence
> of [|d|i]-cache-size properties (or other), the cache is assumed to be
> split.
>
> The l2 cache of the Rockchip RK3308 platform is thus assumed to be
> split:
> l2: l2-cache {
> compatible = "cache";
> cache-level = <2>;
> };
> when the platform datasheet advertises a unified cache.
>
> No modification/check was made to correct that due to the lack of
> cache information for most platforms.
I suppose in theory a split L2 is possible, but I think in practice that
doesn't exist. The Arm ARM allows for such a thing, but this[1] says L2
caches are unified. IMO, we should just define level 2+ is unified in
the schema and we can relax that if ever needed. I've updated the cache
schema branch[2] with that requirement.
Rob
[1] https://developer.arm.com/documentation/den0024/a/Caches/Cache-terminology
[2] https://github.com/robherring/dt-schema/tree/cache-rework
Powered by blists - more mailing lists