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

Yinbo Zhu
2023-08-14T07:58:25Z

在 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:
>>>
>>>> + 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)?

Pmon and uefi are two different firmware, and there is no connection
between them.

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

>
> Is this executing directly from ROM then?

Yes.

Thanks,
Yinbo