kernel/linux.git/include/linux/soc/ti, branch v6.18.21

firmware: ti_sci: Introduce Power Management Ops

2024-10-25T15:45:07+00:00

Introduce power management ops supported by the TISCI Low Power Mode API [1]. 1) TISCI_MSG_LPM_WAKE_REASON Get which wake up source woke the SoC from Low Power Mode. The wake up source IDs will be common for all K3 platforms. 2) TISCI_MSG_LPM_SET_DEVICE_CONSTRAINT Set LPM constraint on behalf of a device. By setting a constraint, the device ensures that it will not be powered off or reset in the selected mode. 3) TISCI_MSG_LPM_SET_LATENCY_CONSTRAINT Set LPM resume latency constraint. By setting a constraint, the host ensures that the resume time from selected mode will be less than the constraint value. [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html Signed-off-by: Dave Gerlach [g-vlaev@ti.com: LPM_WAKE_REASON and IO_ISOLATION support] Signed-off-by: Georgi Vlaev [a-kaur@ti.com: SET_DEVICE_CONSTRAINT support] Signed-off-by: Akashdeep Kaur [vibhore@ti.com: SET_LATENCY_CONSTRAINT support] Signed-off-by: Vibhore Vardhan Signed-off-by: Kevin Hilman Reviewed-by: Akashdeep Kaur Tested-by: Dhruva Gole Signed-off-by: Markus Schneider-Pargmann Tested-by: Kevin Hilman Tested-by: Roger Quadros Acked-by: Dhruva Gole Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-4-ed54cd659a49@baylibre.com Signed-off-by: Nishanth Menon

firmware: ti_sci: Add system suspend and resume call

2024-10-25T15:45:07+00:00

Introduce system suspend call that enables the ti_sci driver to support low power mode when the user space issues a suspend to mem. The following power management operations defined in the TISCI Low Power Mode API [1] are implemented to support suspend and resume: 1) TISCI_MSG_PREPARE_SLEEP Prepare the SOC for entering into a low power mode and provide details to firmware about the state being entered. 2) TISCI_MSG_SET_IO_ISOLATION Control the IO isolation for Low Power Mode. Also, write a ti_sci_prepare_system_suspend call to be used in the driver suspend handler to allow the system to identify the low power mode being entered and if necessary, send TISCI_MSG_PREPARE_SLEEP with information about the mode being entered. Sysfw version >= 10.00.04 support LPM_DM_MANAGED capability [2], where Device Mgr firmware now manages which low power mode is chosen. Going forward, this is the default configuration supported for TI AM62 family of devices. The state chosen by the DM can be influenced by sending constraints using the new LPM constraint APIs. In case the firmware does not support LPM_DM_MANAGED mode, the mode selection logic can be extended as needed. If no suspend-to-RAM modes are supported, return without taking any action. We're using "pm_suspend_target_state" to map the kernel's target suspend state to SysFW low power mode. Make sure this is available only when CONFIG_SUSPEND is enabled. Suspend has to be split into two parts, ti_sci_suspend() will send the prepare sleep message to prepare suspend. ti_sci_suspend_noirq() sets IO isolation which needs to be done as late as possible to avoid any issues. On resume this has to be done as early as possible. [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html Co-developed-by: Dave Gerlach Signed-off-by: Dave Gerlach Signed-off-by: Georgi Vlaev Signed-off-by: Dhruva Gole Signed-off-by: Vibhore Vardhan Signed-off-by: Kevin Hilman Tested-by: Dhruva Gole Signed-off-by: Markus Schneider-Pargmann Tested-by: Roger Quadros Link: https://lore.kernel.org/r/20241007-tisci-syssuspendresume-v13-3-ed54cd659a49@baylibre.com Signed-off-by: Nishanth Menon

ARM: omap1: remove dead code

2023-01-12T09:53:11+00:00

After the removal of the unused board files, I went through the omap1 code to look for code that no longer has any callers and remove that. In particular, support for the omap7xx/omap8xx family is now completely unused, so I'm only leaving omap15xx/omap16xx/omap59xx. Cc: Aaro Koskinen Cc: Janusz Krzysztofik Cc: linux-omap@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Acked-by: Tony Lindgren Acked-by: Kevin Hilman Signed-off-by: Arnd Bergmann

ARM: omap1: fix !ARCH_OMAP1_ANY link failures

2023-01-10T22:05:26+00:00

While compile-testing randconfig builds for the upcoming boardfile removal, I noticed that an earlier patch of mine was completely broken, and the introduction of CONFIG_ARCH_OMAP1_ANY only replaced one set of build failures with another one, now resulting in link failures like ld: drivers/video/fbdev/omap/omapfb_main.o: in function `omapfb_do_probe': drivers/video/fbdev/omap/omapfb_main.c:1703: undefined reference to `omap_set_dma_priority' ld: drivers/dma/ti/omap-dma.o: in function `omap_dma_free_chan_resources': drivers/dma/ti/omap-dma.c:777: undefined reference to `omap_free_dma' drivers/dma/ti/omap-dma.c:1685: undefined reference to `omap_get_plat_info' ld: drivers/usb/gadget/udc/omap_udc.o: in function `next_in_dma': drivers/usb/gadget/udc/omap_udc.c:820: undefined reference to `omap_get_dma_active_status' I tried reworking it, but the resulting patch ended up much bigger than simply avoiding the original problem of unused-function warnings like arch/arm/mach-omap1/mcbsp.c:76:30: error: unused variable 'omap1_mcbsp_ops' [-Werror,-Wunused-variable] As a result, revert the previous fix, and rearrange the code that produces warnings to hide them. For mcbsp, the #ifdef check can simply be removed as the cpu_is_omapxxx() checks already achieve the same result, while in the io.c the easiest solution appears to be to merge the common map bits into each soc specific portion. This gets cleaned in a nicer way after omap7xx support gets dropped, as the remaining SoCs all have the exact same I/O map. Fixes: 615dce5bf736 ("ARM: omap1: fix build with no SoC selected") Cc: stable@vger.kernel.org Acked-by: Aaro Koskinen Signed-off-by: Arnd Bergmann

treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_320.RULE

2022-06-10T12:51:36+00:00

Based on the normalized pattern: this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed as is without any warranty of any kind whether express or implied without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_30.RULE (part 2)

2022-06-10T12:51:35+00:00

Based on the normalized pattern: this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license as published by the free software foundation version 2 this program is distributed as is without any warranty of any kind whether express or implied without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

ARM: omap1: fix build with no SoC selected

2022-04-22T09:08:55+00:00

In a multiplatform randconfig kernel, one can have CONFIG_ARCH_OMAP1 enabled, but none of the specific SoCs. This leads to some build issues as the code is not meant to deal with this configuration at the moment: arch/arm/mach-omap1/io.c:86:20: error: unused function 'omap1_map_common_io' [-Werror,-Wunused-function] arch/arm/mach-omap1/pm.h:113:2: error: "Power management for this processor not implemented yet" [-Werror,-W#warnings] Use the same trick as on OMAP2 and guard the actual compilation of platform code with another Makefile ifdef check based on an option that depends on having at least one SoC enabled. The io.c file still needs to get compiled to allow building device drivers with a dependency on CONFIG_ARCH_OMAP1. Acked-by: Tony Lindgren Signed-off-by: Arnd Bergmann

ARM: omap1: move some headers to include/linux/soc

2022-04-21T13:01:02+00:00

There are three remaining header files that are used by omap1 specific device drivers: - mach/soc.h provides cpu_is_omapXXX abstractions - mach/hardware.h provides omap_read/omap_write functions and physical addresses - mach/mux.h provides an omap specific pinctrl abstraction This is generally not how we do platform abstractions today, and it would be good to completely get rid of these in favor of passing information through platform devices and the pinctrl subsystem. However, given that nobody is working on that, just move it one step forward by splitting out the header files that are used by drivers today from the machine headers that are only used internally. Acked-by: Tony Lindgren Signed-off-by: Arnd Bergmann

ARM: omap1: move mach/usb.h to include/linux/soc

2022-04-21T13:00:59+00:00

The register definitions in this header are used in at least four different places, with little hope of completely cleaning that up. Split up the file into a portion that becomes a linux-wide header under include/linux/soc/ti/, and the parts that are actually only needed by board files. Acked-by: Felipe Balbi Acked-by: Tony Lindgren Signed-off-by: Arnd Bergmann

Merge tag 'mailbox-v5.18' of git://git.linaro.org/landing-teams/working/fujitsu/integration

2022-03-27T21:21:57+00:00

Pull mailbox updates from Jassi Brar: "qcom: - add support for MSM8976 mtk: - enable mt8186 - add ADSP controller driver ti: - use poll mode during suspend tegra: - fix tx channel flush imx: - add i.MX8 SECO MU support - prepare for, and add iMX93 support" * tag 'mailbox-v5.18' of git://git.linaro.org/landing-teams/working/fujitsu/integration: dt-bindings: mailbox: add definition for mt8186 mailbox: ti-msgmgr: Operate mailbox in polled mode during system suspend mailbox: ti-msgmgr: Refactor message read during interrupt handler mailbox: imx: support i.MX93 S401 MU mailbox: imx: support dual interrupts mailbox: imx: extend irq to an array dt-bindings: mailbox: imx-mu: add i.MX93 S4 MU support dt-bindings: mailbox: imx-mu: add i.MX93 MU mailbox: imx: add i.MX8 SECO MU support mailbox: imx: introduce rxdb callback dt-bindings: mailbox: imx-mu: add i.MX8 SECO MU support mailbox: imx: enlarge timeout while reading/writing messages to SCFW mailbox: imx: fix crash in resume on i.mx8ulp mailbox: imx: fix wakeup failure from freeze mode mailbox: mediatek: add support for adsp mailbox controller dt-bindings: mailbox: mtk,adsp-mbox: add mtk adsp-mbox document mailbox: qcom-apcs-ipc: Add compatible for MSM8976 SoC dt-bindings: mailbox: Add compatible for the MSM8976 mailbox: tegra-hsp: Flush whole channel