linux.git/drivers/soc/ti, branch v5.19 Linux kernel source tree soc: ti: wkup_m3_ipc: Add debug option to halt m3 in suspend 2022-05-03T13:02:09+00:00 Dave Gerlach d-gerlach@ti.com 2022-05-02T03:32:12+00:00 2a21f9e6d9a408dbd09a01caf5fff42c2f70fa82 Add a debugfs option to allow configurable halting of the wkup_m3 during suspend at the last possible point before low power mode entry. This condition can only be resolved through JTAG and advancing beyond the while loop in a8_lp_ds0_handler [1]. Although this hangs the system it forces the system to remain active once it has been entirely configured for low power mode entry, allowing for register inspection through JTAG to help in debugging transition errors. Halt mode can be set using the enable_off_mode entry under wkup_m3_ipc in the debugfs. [1] https://git.ti.com/cgit/processor-firmware/ti-amx3-cm3-pm-firmware/tree/src/pm_services/pm_handlers.c?h=08.02.00.006#n141 Suggested-by: Brad Griffis <bgriffis@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> [dfustini: add link for a8_lp_ds0_handler() in ti-amx3-cm3-pm-firmware] Signed-off-by: Drew Fustini <dfustini@baylibre.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220502033211.1383158-1-dfustini@baylibre.com 
Add a debugfs option to allow configurable halting of the wkup_m3
during suspend at the last possible point before low power mode entry.
This condition can only be resolved through JTAG and advancing beyond
the while loop in a8_lp_ds0_handler [1]. Although this hangs the system
it forces the system to remain active once it has been entirely
configured for low power mode entry, allowing for register inspection
through JTAG to help in debugging transition errors.

Halt mode can be set using the enable_off_mode entry under wkup_m3_ipc
in the debugfs.

[1] https://git.ti.com/cgit/processor-firmware/ti-amx3-cm3-pm-firmware/tree/src/pm_services/pm_handlers.c?h=08.02.00.006#n141

Suggested-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[dfustini: add link for a8_lp_ds0_handler() in ti-amx3-cm3-pm-firmware]
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220502033211.1383158-1-dfustini@baylibre.com
soc: ti: wkup_m3_ipc: Add support for i2c voltage scaling 2022-05-03T13:02:09+00:00 Dave Gerlach d-gerlach@ti.com 2022-04-26T20:07:44+00:00 ea082040fe071d2ba1f8f73792743d7ca9fb218e Allow loading of a binary containing i2c scaling sequences to be provided to the wkup_m3 firmware in order to properly scale voltage rails on the PMIC during low power modes like DeepSleep0. Proper binary format is determined by the FW in use. Code expects firmware to have 0x0C57 present as the first two bytes followed by one byte defining offset to sleep sequence followed by one byte defining offset to wake sequence and then lastly both sequences. Each sequence is a series of I2C transfers in the form: u8 length | u8 chip address | u8 byte0/reg address | u8 byte1 | u8 byteN .. The length indicates the number of bytes to transfer, including the register address. The length of each transfer is limited by the I2C buffer size of 32 bytes. Based on previous work by Russ Dill. [dfustini: replace FW_ACTION_HOTPLUG with FW_ACTION_UEVENT] Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> [dfustini: add NULL argument to rproc_da_to_va() call] Signed-off-by: Drew Fustini <dfustini@baylibre.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220426200741.712842-3-dfustini@baylibre.com 
Allow loading of a binary containing i2c scaling sequences to be
provided to the wkup_m3 firmware in order to properly scale voltage
rails on the PMIC during low power modes like DeepSleep0. Proper binary
format is determined by the FW in use.

Code expects firmware to have 0x0C57 present as the first two bytes
followed by one byte defining offset to sleep sequence followed by one
byte defining offset to wake sequence and then lastly both sequences.
Each sequence is a series of I2C transfers in the form:

u8 length | u8 chip address | u8 byte0/reg address | u8 byte1 | u8 byteN
..

The length indicates the number of bytes to transfer, including the
register address. The length of each transfer is limited by the I2C
buffer size of 32 bytes.

Based on previous work by Russ Dill.

[dfustini: replace FW_ACTION_HOTPLUG with FW_ACTION_UEVENT]

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
[dfustini: add NULL argument to rproc_da_to_va() call]
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220426200741.712842-3-dfustini@baylibre.com
soc: ti: wkup_m3_ipc: Add support for IO Isolation 2022-05-03T13:02:09+00:00 Dave Gerlach d-gerlach@ti.com 2022-04-14T19:27:24+00:00 1dcbae86ee669bdb0338954cd0136863f5c96c0a AM43xx support isolation of the IOs so that control is taken from the peripheral they are connected to and overridden by values present in the CTRL_CONF_* registers for the pad in the control module. The actual toggling happens from the wkup_m3, so use a DT property from the wkup_m3_ipc node to allow the PM code to communicate the necessity for placing the IOs into isolation to the firmware. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Drew Fustini <dfustini@baylibre.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220414192722.2978837-3-dfustini@baylibre.com 
AM43xx support isolation of the IOs so that control is taken
from the peripheral they are connected to and overridden by values
present in the CTRL_CONF_* registers for the pad in the control module.

The actual toggling happens from the wkup_m3, so use a DT property from
the wkup_m3_ipc node to allow the PM code to communicate the necessity
for placing the IOs into isolation to the firmware.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220414192722.2978837-3-dfustini@baylibre.com
soc: ti: knav_qmss_queue: Use IS_ERR instead of IS_ERR_OR_NULL when checking knav_queue_open() result 2022-05-03T13:02:05+00:00 Haowen Bai baihaowen@meizu.com 2022-04-24T02:05:43+00:00 d4c41d32cf8af10e4c0a35a6d4995de253b54df6 As the usage of knav_queue_open(): * Returns a handle to the open hardware queue if successful. Use IS_ERR() * to check the returned value for error codes. It will only return error codes, not null. Signed-off-by: Haowen Bai <baihaowen@meizu.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/1650765944-20170-1-git-send-email-baihaowen@meizu.com 
As the usage of knav_queue_open():

* Returns a handle to the open hardware queue if successful. Use IS_ERR()
* to check the returned value for error codes.

It will only return error codes, not null.

Signed-off-by: Haowen Bai <baihaowen@meizu.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/1650765944-20170-1-git-send-email-baihaowen@meizu.com
soc: ti: pm33xx: using pm_runtime_resume_and_get instead of pm_runtime_get_sync 2022-05-03T11:58:10+00:00 Minghao Chi chi.minghao@zte.com.cn 2022-04-18T06:30:59+00:00 2b7042500cab7952bdbf4fe4a84de8712b418c36 Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tony Lindgren <tony@aotmide.com> Link: https://lore.kernel.org/r/20220418063059.2558074-1-chi.minghao@zte.com.cn 
Using pm_runtime_resume_and_get is more appropriate
for simplifing code

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@aotmide.com>
Link: https://lore.kernel.org/r/20220418063059.2558074-1-chi.minghao@zte.com.cn
soc: ti: wkup_m3_ipc: Add support for toggling VTT regulator 2022-04-22T23:12:35+00:00 Dave Gerlach d-gerlach@ti.com 2022-04-09T21:12:15+00:00 f226041424cf87245d39a1b2dfae304308b36b6b Some boards like the AM335x EVM-SK and AM437x GP EVM provide software control via a GPIO pin to toggle the DDR VTT regulator to reduce power consumption in low power states. The VTT regulator should be disabled after enabling self-refresh on suspend, and should be enabled before disabling self-refresh on resume. This is to allow proper self-refresh entry/exit commands to be transmitted to the memory. The "ti,vtt-gpio-pin" device tree property in the wkup_m3_ipc node specifies which GPIO pin to use. This property is communicated to the Wakeup Cortex M3 co-processor where the actual toggling of the GPIO pin happens in CM3 firmware [1]. Please note that the GPIO pin must be on the GPIO0 module as that module is in the wakeup power domain. [1] https://git.ti.com/cgit/processor-firmware/ti-amx3-cm3-pm-firmware/tree/src/pm_services/ddr.c?h=08.02.00.006#n190 Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> [dfustini: remove the unnecessary "ti,needs-vtt-toggle" property] Signed-off-by: Drew Fustini <dfustini@baylibre.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220409211215.2529387-3-dfustini@baylibre.com 
Some boards like the AM335x EVM-SK and AM437x GP EVM provide software
control via a GPIO pin to toggle the DDR VTT regulator to reduce power
consumption in low power states.

The VTT regulator should be disabled after enabling self-refresh on
suspend, and should be enabled before disabling self-refresh on resume.
This is to allow proper self-refresh entry/exit commands to be
transmitted to the memory.

The "ti,vtt-gpio-pin" device tree property in the wkup_m3_ipc node
specifies which GPIO pin to use. This property is communicated to the
Wakeup Cortex M3 co-processor where the actual toggling of the GPIO pin
happens in CM3 firmware [1].

Please note that the GPIO pin must be on the GPIO0 module as that module
is in the wakeup power domain.

[1] https://git.ti.com/cgit/processor-firmware/ti-amx3-cm3-pm-firmware/tree/src/pm_services/ddr.c?h=08.02.00.006#n190

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
[dfustini: remove the unnecessary "ti,needs-vtt-toggle" property]
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220409211215.2529387-3-dfustini@baylibre.com
soc: ti: knav_qmss_queue: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync 2022-04-22T23:12:06+00:00 Minghao Chi chi.minghao@zte.com.cn 2022-04-18T06:29:55+00:00 12eeb74925da70eb39d90abead9de9793be3d4c8 Using pm_runtime_resume_and_get is more appropriate for simplifying code. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220418062955.2557949-1-chi.minghao@zte.com.cn 
Using pm_runtime_resume_and_get is more appropriate for simplifying
code.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220418062955.2557949-1-chi.minghao@zte.com.cn
soc: ti: knav_dma: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync 2022-04-15T20:04:53+00:00 Minghao Chi chi.minghao@zte.com.cn 2022-04-12T08:29:23+00:00 d3e3116f253591a473873fab8363ecb998ddde13 Using pm_runtime_resume_and_get is more appropriate for simplifying code. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20220412082923.2532649-1-chi.minghao@zte.com.cn 
Using pm_runtime_resume_and_get is more appropriate
for simplifying code.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20220412082923.2532649-1-chi.minghao@zte.com.cn
soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc 2022-04-15T19:59:23+00:00 QintaoShen unSimple1993@163.com 2022-03-24T07:44:03+00:00 ba56291e297d28aa6eb82c5c1964fae2d7594746 The allocation funciton devm_kcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devm_kcalloc in previous code. Signed-off-by: QintaoShen <unSimple1993@163.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/1648107843-29077-1-git-send-email-unSimple1993@163.com 
The allocation funciton devm_kcalloc may fail and return a null pointer,
which would cause a null-pointer dereference later.
It might be better to check it and directly return -ENOMEM just like the
usage of devm_kcalloc in previous code.

Signed-off-by: QintaoShen <unSimple1993@163.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/1648107843-29077-1-git-send-email-unSimple1993@163.com
soc: ti: omap_prm: Use of_device_get_match_data() 2022-04-15T19:31:03+00:00 Minghao Chi (CGEL ZTE) chi.minghao@zte.com.cn 2022-03-07T03:37:36+00:00 cabfa5b46573b4e5ded52b4296a831745c6d32b5 Since omap_prm_id_table all have (and expected to have) data entries, use of_device_get_match_data() to simplify the code. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220307033736.2075221-1-chi.minghao@zte.com.cn 
Since omap_prm_id_table all have (and expected to have) data entries,
use of_device_get_match_data() to simplify the code.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20220307033736.2075221-1-chi.minghao@zte.com.cn