[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250213122719.GE235556@e132581.arm.com>
Date: Thu, 13 Feb 2025 12:27:19 +0000
From: Leo Yan <leo.yan@....com>
To: Rob Herring <robh@...nel.org>
Cc: Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>,
Catalin Marinas <catalin.marinas@....com>,
Jonathan Corbet <corbet@....net>, Marc Zyngier <maz@...nel.org>,
Oliver Upton <oliver.upton@...ux.dev>,
Joey Gouly <joey.gouly@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Zenghui Yu <yuzenghui@...wei.com>,
James Clark <james.clark@...aro.org>,
Anshuman Khandual <anshuman.khandual@....com>,
linux-arm-kernel@...ts.infradead.org,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, kvmarm@...ts.linux.dev
Subject: Re: [PATCH v19 09/11] arm64: Handle BRBE booting requirements
On Wed, Feb 12, 2025 at 03:21:46PM -0600, Rob Herring wrote:
[...]
> > > + - If the kernel is entered at EL1 and EL2 is present:
> > > +
> > > + - BRBCR_EL2.CC (bit 3) must be initialised to 0b1.
> > > + - BRBCR_EL2.MPRED (bit 4) must be initialised to 0b1.
> >
> > Should clarify BRBCR_EL2.TS to be initialised to 0b00 ? Arm ARM
> > claims the reset behaviour of the TS field is unknown value. The
> > assembly code below actually has initializes the TS field as zero.
>
> Humm, we don't currently care what it is initialized to because the
> timestamp is never used. We would care in the future if we use
> timestamps. Will 0b00 be the only correct value? I'm not sure.
In initializaton phase, if set BRBCR_EL2.TS = 0b00, then the timestamp
will be decided by BRBCR_EL1.TS. I expect the BRBE driver will always
write BRBCR_EL1.TS.
Thanks,
Leo
Powered by blists - more mailing lists