Re: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm

[Yinbo Zhu]

在 2023/8/14 下午4:19, Arnd Bergmann 写道:
> On Mon, Aug 14, 2023, at 09:57, Yinbo Zhu wrote:
> > 在 2023/8/12 下午8:25, Arnd Bergmann 写道:
> > > On Fri, Aug 4, 2023, at 04:54, Yinbo Zhu wrote:
> > > > 在 2023/8/3 下午3:44, Arnd Bergmann 写道:
> > > > > On Thu, Aug 3, 2023, at 08:37, Yinbo Zhu wrote:
> > > >
> > > > > Is this some SRAM that needs to execute the suspend logic
> > > > > in order to shut down memory and cache controllers?
> > > >
> > > >
> > > > Yes, The suspend-to-ram after into pmon firmware code and set
> > > > self-refresh mode in memory controller and ensure that memory data is
> > > > not lost then shut down memory controller.
> > >
> > > I'm sorry I missed your reply earlier, getting back to the
> > > thread now. So it's clear that this code needs to run in a
> > > special memory from your description, but I'm still trying
> > > to understand the details better.
> > >
> > > I found https://github.com/loongson-community/pmon source
> > > code, and a reference to its origin at LSI Logic at
> > > https://www.linux-mips.org/wiki/PMON but otherwise have
> > > no idea about what this actually is, or how it relates
> > > to your UEFI firmware. Did you add UEFI support to PMON,
> > > or do you use it as a first stage loader that loads
> > > the actual UEFI implementation (EDK2 or u-boot, I guess)?
> >
> >
> > Pmon and uefi are two different firmware, and there is no connection
> > between them.
>
> It sounds like we still have problems with terminology. >
> I don't think categorizing UEFI as a firmware is correct,


Sorry to have confused you, uefi firmware is our internal name, which is
actually what you referred to as EDK2, the EDK2 need use UEFI.

> it's the interface used by various firmware implementations
> to load the operating system. As far as I understand,
> loongarch currently mandates the use of UEFI in whichever
> firmware is used, so if you have Pmon installed in ROM > and Pmon does not itself implement UEFI, it would have
> to load some other firmware such as u-boot in order to
> load a kernel through the UEFI protocol, right?


PMON is an independent firmware and loader that can directly load the
operating system and it does not require the use of UEFI.

> Has the assumption that loongarch requires UEFI changed?


LoongArch embedded board was use Pmon firmware, The other one uses UEFI
firmware (EDK2) on LoongArch platform.

> > > > > Or is
> > > > > this a runtime firmware interface similar to how UEFI handles
> > > > > its runtime services to keep the implementation out of
> > > > > the kernel?
> > > >
> > > >
> > > > No, The main cpu and other cpu will offline that after into firmware and
> > > > finished Corresponding operations, the pmon firmware will not run.
> > >
> > > I'm still trying to understand your explanations here.
> > > You say that pmon no longer runs, but that seems to contradict
> > > what you said earlier about branching into pmon firmware code
> > > for suspend.
> >
> >
> > It's not contradictory.  The suspend-to-ram is that from kernel goto to
> > pmon firmware code, then pmon finished corresponding operations, which
> > was to set self-refresh mode in memory controller, then memory HW will
> > maintain its own data and no longer requires software processing, pmon
> > firmware will not run.
>
> That is what I mean with a "runtime firmware interface", i.e. you
> jump into firmware in order to request services from it. Clearly the
> firmware itself does not run while the OS is executing code, but it is
> still there and waiting to be called here, which is similar to
> things like UEFI runtime services, PowerPC RTAS, Arm EL3/trustzone
> based firmware or x86 SMM firmware, except that this is much less
> formalized and only consists of an entry point with undocument
> calling conventions.
>
> > > Is this executing directly from ROM then?
> >
> > Yes.
>
> Is this the only runtime call into the firmware, 


Only when suspend-to-ram occurs, the kernel will call into the firmware.
No other case.

> or are there
> others that are either already called from mainline kernels
> or in your downsteam implementation?
>
> How do you ensure that the DTB matches the actual ROM code
> after rebuilding Pmon? Does Pmon itself fill that field with
> the correct address, or do you rely on it being a hardcoded
> constant?


Use Pmon, firmware team will always ensure that DTB matches the actual
ROM code.  The "suspend-address" of dtb and pmon entry address will
synchronized modification by firmware team.

Thanks,
Yinbo