[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240509-maimed-wharf-555787f5d773@spud>
Date: Thu, 9 May 2024 18:24:24 +0100
From: Conor Dooley <conor@...nel.org>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
Cc: "paulburton@...nel.org" <paulburton@...nel.org>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 4/5] dt-bindings: mips: Document mti,mips-cm
On Wed, May 08, 2024 at 09:28:27PM +0100, Jiaxun Yang wrote:
>
>
> 在 2024/5/8 18:01, Conor Dooley 写道:
> [...]
> > > So it's actually a register block that can be remapped to anywhere in
> > > MMIO address space. DeviceTree usually passes firmware's mapping location
> > > to kernel.
> > >
> > > There are some other similar bindings like mti,mips-cdmm and mti,mips-cpc,
> > > I just copied phraseology from them, should I try to explain it more here?
> > The description that you've given here is of something that sounded
> > awfully like mapping into a location in DDR etc, is it actually being
> > mapped into a non-memory address?
> It is an overlay being realized at CPU core level so it can be mapped at any
> where, but the firmware convention is to map it to a "non-memory address".
In that case, a description that even eejits like my can understand
sounds like all you need to understand :)
Thanks,
Conor.
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists