| Message ID | 20230803063703.5659-2-zhuyinbo@loongson.cn (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | soc: loongson2_pm: add power management support | expand |
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
在 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. > 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. > > Does the code work with both traditional suspend-to-ram and > modern suspend-to-idle logic? Yes, It can support suspend-to-ram and suspend-to-idle. Thanks, Yinbo
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
在 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
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, 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? Has the assumption that loongarch requires UEFI changed? >>>> 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, 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? Arnd
在 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
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? >>>> 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? Arnd
在 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 --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>