[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <42f91b62-2bf9-414d-ad05-6770282637f7@flygoat.com>
Date: Wed, 8 May 2024 21:28:27 +0100
From: Jiaxun Yang <jiaxun.yang@...goat.com>
To: Conor Dooley <conor@...nel.org>
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
在 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".
Thanks
- Jiaxun
>
> Thanks,
> Conor.
Powered by blists - more mailing lists