diff mbox series

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

Message ID 20230803063703.5659-2-zhuyinbo@loongson.cn
State Accepted
Commit 6054a676e969b4bbf69be3f1dd7aba2443102848
Headers show
Series soc: loongson2_pm: add power management support | expand

Commit Message

Yinbo Zhu Aug. 3, 2023, 6:37 a.m. UTC
Add the Loongson-2 SoC Power Management Controller binding with DT
schema format using json-schema.

Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 .../soc/loongson/loongson,ls2k-pmc.yaml       | 52 +++++++++++++++++++
 MAINTAINERS                                   |  6 +++
 2 files changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml

Comments

Arnd Bergmann Aug. 3, 2023, 7:44 a.m. UTC | #1
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?
Is this some SRAM that needs to execute the suspend logic
in order to shut down memory and cache controllers? Or is
this a runtime firmware interface similar to how UEFI handles
its runtime services to keep the implementation out of
the kernel?

Does the code work with both traditional suspend-to-ram and
modern suspend-to-idle logic?

      Arnd
Arnd Bergmann Aug. 12, 2023, 12:25 p.m. UTC | #2
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
Yinbo Zhu Aug. 15, 2023, 4:08 a.m. UTC | #3
在 2023/8/14 下午9:41, Arnd Bergmann 写道:
> On Mon, Aug 14, 2023, at 13:57, Yinbo Zhu wrote:
>> 在 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 写道:
>>>>> 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.
> 
> Ok
> 
>>> 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.
> 
> I'm pretty sure we discussed this when the loongarch port
> was originally merged, with the decisionto just use UEFI for
> booting any kernel, as the legacy entry point for the ACPI
> based environment was not really well-defined and the UEFI
> stub was an easy alternative to have more commonality
> with other architectures.
> 
> I see this was already extended for embedded CPUs to use
> the uefi stub with DT in commit 88d4d957edc70 ("LoongArch: Add
> FDT booting support from efi system table"), which seems like
> the right direction. >
> Can you explain why this board would want yet another method
> for entering the kernel? Is there any documentation for the
> boot protocol?

Yes, you're right, the latest PMON does indeed support UEFI, the PMON
used in the product code is still outdated and does not support UEFI.

Actually, whether using EDK2, Pmon firmware, or other firmware, the
LoongArch platform's s3 (suspend-to-ram) requires a suspend-address to
be defined, if dts is supported, it is defined in dts, and if acpi table
is supported, it is defined in acpi table.

> 
>>>>> 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.
> 
> Ok
> 
>>> 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.
> 
> Ok.  So it's linked against libfdt to fill the dtb information,
> or do you have to provide a dtb blob that matches the firmware?


For pmon firmware, the dtb was as part of firmware, the firmware has
defined the address of the DTB's suspend and the address of the firmware
entry, and is consistent.

Thanks,
Yinbo
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml
new file mode 100644
index 000000000000..da2dcfeebf12
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml
@@ -0,0 +1,52 @@ 
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2 Power Manager controller
+
+maintainers:
+  - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - loongson,ls2k0500-pmc
+          - loongson,ls2k1000-pmc
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  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.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    power-management@1fe27000 {
+        compatible = "loongson,ls2k1000-pmc", "syscon";
+        reg = <0x1fe27000 0x58>;
+        interrupt-parent = <&liointc1>;
+        interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+        loongson,suspend-address = <0x0 0x1c000500>;
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1089ef3319f2..608a00473498 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12365,6 +12365,12 @@  S:	Maintained
 F:	Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml
 F:	drivers/soc/loongson/loongson2_guts.c
 
+LOONGSON-2 SOC SERIES PM DRIVER
+M:	Yinbo Zhu <zhuyinbo@loongson.cn>
+L:	linux-pm@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml
+
 LOONGSON-2 SOC SERIES PINCTRL DRIVER
 M:	zhanghongchen <zhanghongchen@loongson.cn>
 M:	Yinbo Zhu <zhuyinbo@loongson.cn>