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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
>> 
>>> +  loongson,suspend-address:
>>> +    $ref: /schemas/types.yaml#/definitions/uint64
>>> +    description:
>>> +      The "loongson,suspend-address" is a deep sleep state (Suspend To
>>> +      RAM) firmware entry address which was jumped from kernel and it's
>>> +      value was dependent on specific platform firmware code. In
>>> +      addition, the PM need according to it to indicate that current
>>> +      SoC whether support Suspend To RAM.
>>> +
>> 
>> I just commented on this in the driver patch, assuming this
>> was an MMIO address, but I'm even more confused now, since
>> we try hard to not rely on being able to just interface with
>> firmware like this.
>> 
>> If this is executable code, where does this actually reside?
>
>
> Pmon firmware code.
>
>> 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)?

>> 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.

Is this executing directly from ROM then?

       Arnd




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux