| Age | Commit message (Collapse) | Author |
|---|
|
With the integration of chip-id detection scheme in kernel[1], there
is no specific need to maintain multitudes of SoC specific config
options, discussed as per [2], we have deprecated the usage in other
places for v5.10-rc1. Drop the configuration for the follow on kernel.
[1] drivers/soc/ti/k3-socinfo.c commit 907a2b7e2fc7 ("soc: ti: add k3 platforms chipid module driver")
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem capable of supporting Gigabit Ethernet, and is
commonly referred to as ICSSG. These SoCs contain typically three
ICSSG instances named ICSSG0, ICSSG1 and ICSSG2. The three ICSSGs are
identical to each other for the most part with minor SoC integration
differences and capabilities. The ICSSG2 supports slightly enhanced
features like SGMII mode Ethernet, while the ICSS0 and ICSSG1 instances
are limited to MII mode only.
The ICSSGs on K3 AM65x SoCs are in general super-sets of the PRUSS on the
AM57xx/66AK2G SoCs. They include two additional auxiliary PRU cores called
RTUs and few other additional sub-modules. The interrupt integration is
also different on the K3 AM65x SoCs and are propagated through various
SoC-level Interrupt Router and Interrupt Aggregator blocks. Other IP level
differences include different constant tables, differences in system event
interrupt input sources etc. They also do not have a programmable module
reset line like those present on AM33xx/AM43xx SoCs. The modules are reset
just like any other IP with the SoC's global cold/warm resets.
The existing pruss platform driver has been updated to support these new
ICSSG instances through new AM65x specific compatibles. A build dependency
with ARCH_K3 is added to enable building all the existing PRUSS platform
drivers for this ARMv8 platform.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1,
each of which has two PRU processor cores. The two PRU-ICSS instances
are identical to each other with few minor SoC integration differences,
and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The Shared Data
RAM size is larger and the number of interrupts coming into MPU INTC
is like the instances on AM437x. There are also few other differences
attributing to integration in Keystone architecture (like no SYSCFG
register or PRCM handshake protocols). Other IP level differences
include different constant table, differences in system event interrupt
input sources etc. They also do not have a programmable module reset
line like those present on AM33xx/AM43xx SoCs. The modules are reset
just like any other IP with the SoC's global cold/warm resets.
The existing PRUSS platform driver has been enhanced to support these
66AK2G PRU-ICSS instances through new 66AK2G specific compatible for
properly probing and booting all the different PRU cores in each
PRU-ICSS processor subsystem. A build dependency with ARCH_KEYSTONE
is added to enable the driver to be built in K2G-only configuration.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The AM57xx family of SoCs supports two PRU-ICSS instances, each of
which has two PRU processor cores. The two PRU-ICSS instances are
identical to each other, and are very similar to the PRU-ICSS1 of
AM33xx/AM43xx except for a few minor differences like the RAM sizes
and the number of interrupts coming into the MPU INTC. They do
not have a programmable module reset line unlike those present on
AM33xx/AM43xx SoCs. The modules are reset just like any other IP
with the SoC's global cold/warm resets. Each PRU-ICSS's INTC is also
preceded by a Crossbar that enables multiple external events to be
routed to a specific number of input interrupt events. Any interrupt
event directed towards PRUSS needs this crossbar to be setup properly
on the firmware side.
The existing PRUSS platform driver has been enhanced to support
these AM57xx PRU-ICSS instances through new AM57xx specific
compatible for properly probing and booting all the different PRU
cores in each PRU-ICSS processor subsystem. A build dependency with
SOC_DRA7XX is also added to enable the driver to be built in
AM57xx-only configuration (there is no separate Kconfig option
for AM57xx vs DRA7xx).
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The AM437x SoCs have two different PRU-ICSS subsystems: PRU-ICSS1
and a smaller PRU-ICSS0. Enhance the PRUSS platform driver to support
both the PRU-ICSS sub-systems on these SoCs.
The PRU-ICSS1 on AM437x is very similar to the PRU-ICSS on AM33xx
except for few minor differences - increased Instruction RAM, increased
Shared Data RAM2, and 1 less interrupt (PRUSS host interrupt 7 which is
redirected to the other PRUSS) towards the MPU INTC. The PRU-ICSS0 is
a cut-down version of the IP, with less DRAM per PRU, no Shared DRAM etc.
It also does not have direct access to L3 bus regions, there is a single
interface to L3 for both PRUSS0 and PRUSS1, and it would have to go
through the PRUSS1's interface. The PRUSS_SYSCFG register is reserved on
PRUSS0, so any external access requires the programming the corresponding
PRUSS_SYSCFG register in PRUSS1. It does have its own dedicated I/O lines
though. Note that this instance does not support any PRU Ethernet related
use cases.
The adaptation uses SoC-specific compatibles in the driver and uses
a newly introduced pruss_match_private_data structure and the
pruss_get_private_data() function to retrieve a PRUSS instance specific
data using a device-name based lookup logic. The reset and the L3 external
access are managed by the parent interconnect ti-sysc bus driver so that
PRUSS1 and PRUSS0 can be independently supported.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present on various TI SoCs such as
AM335x or AM437x or the Keystone 66AK2G. Each SoC can have
one or more PRUSS instances that may or may not be identical.
For example, AM335x SoCs have a single PRUSS, while AM437x has
two PRUSS instances PRUSS1 and PRUSS0, with the PRUSS0 being
a cut-down version of the PRUSS1.
The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.
The PRU-ICSS functionality is achieved through three different
platform drivers addressing a specific portion of the PRUSS.
Some sub-modules of the PRU-ICSS IP reuse some of the existing
drivers (like davinci mdio driver or the generic syscon driver).
This design provides flexibility in representing the different
modules of PRUSS accordingly, and at the same time allowing the
PRUSS driver to add some instance specific configuration within
an SoC.
The PRUSS platform driver deals with the overall PRUSS and is
used for managing the subsystem level resources like various
memories and the CFG module. It is responsible for the creation
and deletion of the platform devices for the child PRU devices
and other child devices (like Interrupt Controller, MDIO node
and some syscon nodes) so that they can be managed by specific
platform drivers. The PRUSS interrupt controller is managed by
an irqchip driver, while the individual PRU RISC cores are
managed by a PRU remoteproc driver.
The driver currently supports the AM335x SoC, and support for
other TI SoCs will be added in subsequent patches.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The Texas Instruments K3 Multicore SoC platforms have chipid module which
is represented by CTRLMMR_xxx_JTAGID register and contains information
about SoC id and revision.
Bits:
31-28 VARIANT Device variant
27-12 PARTNO Part number
11-1 MFG Indicates TI as manufacturer (0x17)
1 Always 1
This patch adds corresponding driver to identify the TI K3 SoC family and
revision, and registers this information with the SoC bus. It is available
under /sys/devices/soc0/ for user space, and can be checked, where needed,
in Kernel using soc_device_match().
Identification is done by:
- checking MFG to be TI ID
- retrieving Device variant (revision)
- retrieving Part number and convert it to the family
- retrieving machine from DT "/model"
Example J721E:
# cat /sys/devices/soc0/{machine,family,revision}
Texas Instruments K3 J721E SoC
J721E
SR1.0
Example AM65x:
# cat /sys/devices/soc0/{machine,family,revision}
Texas Instruments AM654 Base Board
AM65X
SR1.0
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There is one RINGACC module per NAVSS on TI AM65x SoCs.
The RINGACC converts constant-address read and write accesses to equivalent
read or write accesses to a circular data structure in memory. The RINGACC
eliminates the need for each DMA controller which needs to access ring
elements from having to know the current state of the ring (base address,
current offset). The DMA controller performs a read or write access to a
specific address range (which maps to the source interface on the RINGACC)
and the RINGACC replaces the address for the transaction with a new address
which corresponds to the head or tail element of the ring (head for reads,
tail for writes). Since the RINGACC maintains the state, multiple DMA
controllers or channels are allowed to coherently share the same rings as
applicable. The RINGACC is able to place data which is destined towards
software into cached memory directly.
Supported ring modes:
- Ring Mode
- Messaging Mode
- Credentials Mode
- Queue Manager Mode
TI-SCI integration:
Texas Instrument's System Control Interface (TI-SCI) Message Protocol now
has control over Ringacc module resources management (RM) and Rings
configuration.
The corresponding support of TI-SCI Ringacc module RM protocol
introduced as option through DT parameters:
- ti,sci: phandle on TI-SCI firmware controller DT node
- ti,sci-dev-id: TI-SCI device identifier as per TI-SCI firmware spec
if both parameters present - Ringacc driver will configure/free/reset Rings
using TI-SCI Message Ringacc RM Protocol.
The Ringacc driver manages Rings allocation by itself now and requests
TI-SCI firmware to allocate and configure specific Rings only. It's done
this way because, Linux driver implements two stage Rings allocation and
configuration (allocate ring and configure ring) while TI-SCI Message
Protocol supports only one combined operation (allocate+configure).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
Pull ARM Devicetree updates from Olof Johansson:
"We continue to see a lot of new material. I've highlighted some of it
below, but there's been more beyond that as well.
One of the sweeping changes is that many boards have seen their ARM
Mali GPU devices added to device trees, since the DRM drivers have now
been merged.
So, with the caveat that I have surely missed several great
contributions, here's a collection of the material this time around:
New SoCs:
- Mediatek mt8183 (4x Cortex-A73 + 4x Cortex-A53)
- TI J721E (2x Cortex-A72 + 3x Cortex-R5F + 3 DSPs + MMA)
- Amlogic G12B (4x Cortex-A73 + 2x Cortex-A53)
New Boards / platforms:
- Aspeed BMC support for a number of new server platforms
- Kontron SMARC SoM (several i.MX6 versions)
- Novtech's Meerkat96 (i.MX7)
- ST Micro Avenger96 board
- Hardkernel ODROID-N2 (Amlogic G12B)
- Purism Librem5 devkit (i.MX8MQ)
- Google Cheza (Qualcomm SDM845)
- Qualcomm Dragonboard 845c (Qualcomm SDM845)
- Hugsun X99 TV Box (Rockchip RK3399)
- Khadas Edge/Edge-V/Captain (Rockchip RK3399)
Updated / expanded boards and platforms:
- Renesas r7s9210 has a lot of new peripherals added
- Fixes and polish for Rockchip-based Chromebooks
- Amlogic G12A has a lot of peripherals added
- Nvidia Jetson Nano sees various fixes and improvements, and is now
at feature parity with TX1"
* tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (586 commits)
ARM: dts: gemini: Set DIR-685 SPI CS as active low
ARM: dts: exynos: Adjust buck[78] regulators to supported values on Arndale Octa
ARM: dts: exynos: Adjust buck[78] regulators to supported values on Odroid XU3 family
ARM: dts: exynos: Move Mali400 GPU node to "/soc"
ARM: dts: exynos: Fix imprecise abort on Mali GPU probe on Exynos4210
arm64: dts: qcom: qcs404: Add missing space for cooling-cells property
arm64: dts: rockchip: Fix USB3 Type-C on rk3399-sapphire
arm64: dts: rockchip: Update DWC3 modules on RK3399 SoCs
arm64: dts: rockchip: enable rk3328 watchdog clock
ARM: dts: rockchip: add display nodes for rk322x
ARM: dts: rockchip: fix vop iommu-cells on rk322x
arm64: dts: rockchip: Add support for Hugsun X99 TV Box
arm64: dts: rockchip: Define values for the IPA governor for rock960
arm64: dts: rockchip: Fix multiple thermal zones conflict in rk3399.dtsi
arm64: dts: rockchip: add core dtsi file for RK3399Pro SoCs
arm64: dts: rockchip: improve rk3328-roc-cc rgmii performance.
Revert "ARM: dts: rockchip: set PWM delay backlight settings for Minnie"
ARM: dts: rockchip: Configure BT_DEV_WAKE in on rk3288-veyron
arm64: dts: qcom: sdm845-cheza: add initial cheza dt
ARM: dts: msm8974-FP2: Add vibration motor
...
|
|
The irqchip driver depends on the SoC specific driver, but we want
to be able to compile-test it elsewhere:
WARNING: unmet direct dependencies detected for TI_SCI_INTA_MSI_DOMAIN
Depends on [n]: SOC_TI [=n]
Selected by [y]:
- TI_SCI_INTA_IRQCHIP [=y] && TI_SCI_PROTOCOL [=y]
drivers/irqchip/irq-ti-sci-inta.o: In function `ti_sci_inta_irq_domain_probe':
irq-ti-sci-inta.c:(.text+0x204): undefined reference to `ti_sci_inta_msi_create_irq_domain'
Rearrange the Kconfig and Makefile so we build the soc driver whenever
its users are there, regardless of the SOC_TI option.
Fixes: 49b323157bf1 ("soc: ti: Add MSI domain bus support for Interrupt Aggregator")
Fixes: f011df6179bd ("irqchip/ti-sci-inta: Add msi domain support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux into arm/dt
Texas Instruments K3 SoC family changes for 5.3
- Add support for the new J721e SoC, includes basic peripherals needed for
booting up the device
- New peripheral support added for AM654x:
* TI SCI irqchip
* GPIO
* MCU SRAM
* R5Fs
* MSMC RAM
* SERDES and PCIe
* tag 'ti-k3-soc-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux: (26 commits)
arm64: dts: ti: k3-j721e: Add the MCU SRAM node
arm64: dts: ti: k3-j721e: Add interrupt controllers in wakeup domain
arm64: dts: ti: k3-j721e: Add interrupt controllers in main domain
arm64: dts: ti: k3-j721e-main: Add Main NavSS Interrupt controller node
arm64: defconfig: Enable TI's J721E SoC platform
arm64: dts: ti: Add support for J721E Common Processor Board
soc: ti: Add Support for J721E SoC config option
arm64: dts: ti: Add Support for J721E SoC
dt-bindings: serial: 8250_omap: Add compatible for J721E UART controller
dt-bindings: arm: ti: Add bindings for J721E SoC
arm64: dts: ti: am654-base-board: Disable SERDES and PCIe
arm64: dts: k3-am6: Add PCIe Endpoint DT node
arm64: dts: k3-am6: Add PCIe Root Complex DT node
arm64: dts: k3-am6: Add SERDES DT node
arm64: dts: k3-am6: Add mux-controller DT node required for muxing SERDES
arm64: dts: k3-am6: Add "socionext,synquacer-pre-its" property to gic_its
arm64: dts: ti: k3-am65: Add MSMC RAM ranges in interconnect node
arm64: dts: ti: k3-am65: Add R5F ranges in interconnect nodes
arm64: dts: ti: k3-am65-mcu: Add the MCU RAM node
arm64: dts: ti: k3-am65: Add MCU SRAM ranges in interconnect nodes
...
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Add option to build J721E SoC specific components
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
|
|
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull IRQ chip updates from Ingo Molnar:
"A late irqchips update:
- New TI INTR/INTA set of drivers
- Rewrite of the stm32mp1-exti driver as a platform driver
- Update the IOMMU MSI mapping API to be RT friendly
- A number of cleanups and other low impact fixes"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (34 commits)
iommu/dma-iommu: Remove iommu_dma_map_msi_msg()
irqchip/gic-v3-mbi: Don't map the MSI page in mbi_compose_m{b, s}i_msg()
irqchip/ls-scfg-msi: Don't map the MSI page in ls_scfg_msi_compose_msg()
irqchip/gic-v3-its: Don't map the MSI page in its_irq_compose_msi_msg()
irqchip/gicv2m: Don't map the MSI page in gicv2m_compose_msi_msg()
iommu/dma-iommu: Split iommu_dma_map_msi_msg() in two parts
genirq/msi: Add a new field in msi_desc to store an IOMMU cookie
arm64: arch_k3: Enable interrupt controller drivers
irqchip/ti-sci-inta: Add msi domain support
soc: ti: Add MSI domain bus support for Interrupt Aggregator
irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver
dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings
irqchip/ti-sci-intr: Add support for Interrupt Router driver
dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
gpio: thunderx: Use the default parent apis for {request,release}_resources
genirq: Introduce irq_chip_{request,release}_resource_parent() apis
firmware: ti_sci: Add helper apis to manage resources
firmware: ti_sci: Add RM mapping table for am654
firmware: ti_sci: Add support for IRQ management
firmware: ti_sci: Add support for RM core ops
...
|
|
With the system coprocessor managing the range allocation of the
inputs to Interrupt Aggregator, it is difficult to represent
the device IRQs from DT.
The suggestion is to use MSI in such cases where devices wants
to allocate and group interrupts dynamically.
Create a MSI domain bus layer that allocates and frees MSIs for
a device.
APIs that are implemented:
- ti_sci_inta_msi_create_irq_domain() that creates a MSI domain
- ti_sci_inta_msi_domain_alloc_irqs() that creates MSIs for the
specified device and resource.
- ti_sci_inta_msi_domain_free_irqs() frees the irqs attached to the device.
- ti_sci_inta_msi_get_virq() for getting the virq attached to a specific event.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
During RTC-only suspend, power is lost to the wkup domain, so we need to
save and restore the state of that domain. We also need to store some
information within the RTC registers so that u-boot can do the right thing
at powerup.
The state is entered by getting the RTC to bring the pmic_power_en line low
which will instruct the PMIC to disable the appropriate power rails after
putting DDR into self-refresh mode. To bring pmic_power_en low, we need to
get an ALARM2 event. Since we are running from SRAM at that point, it means
calculating what the next second is (via ASM) and programming that into the
RTC. This patch also adds support for wake up source detection.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add option to build AM6 SoC specific components
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
AM335x and AM437x support various low power modes as documented
in section 8.1.4.3 of the AM335x Technical Reference Manual and
section 6.4.3 of the AM437x Technical Reference Manual.
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend state in the kernel. In this state, MPU and
PER domains are turned off with the internal RAM held in
retention to facilitate the resume process. As part of
the boot process, the assembly code is copied over to OCMCRAM
so it can be executed to turn of the EMIF and put DDR into self
refresh.
Both platforms have a Cortex-M3 (WKUP_M3) which assists the MPU
in DeepSleep0 entry and exit. WKUP_M3 takes care
of the clockdomain and powerdomain transitions based on the
intended low power state. MPU needs to load the appropriate
WKUP_M3 binary onto the WKUP_M3 memory space before it can
leverage any of the PM features like DeepSleep. This loading
is handled by the remoteproc driver wkup_m3_rproc.
Communication with the WKUP_M3 is handled by a wkup_m3_ipc
driver that exposes the specific PM functionality to be used
the PM code.
In the current implementation when the suspend process
is initiated, MPU interrupts the WKUP_M3 to let it know about
the intent of entering DeepSleep0 and waits for an ACK. When
the ACK is received MPU continues with its suspend process
to suspend all the drivers and then jumps to assembly in
OCMC RAM. The assembly code puts the external RAM in self-refresh
mode, gates the MPU clock, and then finally executes the WFI
instruction. Execution of the WFI instruction with MPU clock gated
triggers another interrupt to the WKUP_M3 which then continues
with the power down sequence wherein the clockdomain and
powerdomain transition takes place. As part of the sleep sequence,
WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI
execution on WKUP_M3 causes the hardware to disable the main
oscillator of the SoC and from here system remains in sleep state
until a wake source brings the system into resume path.
When a wakeup event occurs, WKUP_M3 starts the power-up
sequence by switching on the power domains and finally
enabling the clock to MPU. Since the MPU gets powered down
as part of the sleep sequence in the resume path ROM code
starts executing. The ROM code detects a wakeup from sleep
and then jumps to the resume location in OCMC which was
populated in one of the IPC registers as part of the suspend
sequence.
Code is based on work by Vaibhav Bedia.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Introduce a ti_sci_pm_domains driver to act as a generic pm domain
provider to allow each device to attach and associate it's ti-sci-id so
that it can be controlled through the TI SCI protocol.
This driver implements a simple genpd where each device node has a
phandle to the power domain node and also must provide an index which
represents the ID to be passed with TI SCI representing the device using
a single phandle cell. The driver manually parses the phandle to get the
cell value. Through this interface the genpd dev_ops start and stop
hooks will use TI SCI to turn on and off each device as determined by
pm_runtime usage.
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
|
|
Introduce a wkup_m3_ipc driver to handle communication between the MPU
and Cortex M3 wkup_m3 present on am335x.
This driver is responsible for actually booting the wkup_m3_rproc and
also handling all IPC which is done using the IPC registers in the control
module, a mailbox, and a separate interrupt back from the wkup_m3. A small
API is exposed for executing specific power commands, which include
configuring for low power mode, request a transition to a low power mode,
and status info on a previous transition.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
The Keystone Navigator DMA driver sets up the dma channels and flows for
the QMSS(Queue Manager SubSystem) who triggers the actual data movements
across clients using destination queues. Every client modules like
NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
Engines has its own instance of packet dma hardware. QMSS has also
an internal packet DMA module which is used as an infrastructure
DMA with zero copy.
Initially this driver was proposed as DMA engine driver but since the
hardware is not typical DMA engine and hence doesn't comply with typical
DMA engine driver needs, that approach was naked. Link to that
discussion -
https://lkml.org/lkml/2014/3/18/340
As aligned, now we pair the Navigator DMA with its companion Navigator
QMSS subsystem driver.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
|
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
Multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions,
queue pool management (allocation, push, pop and notify) and descriptor
pool management. The specifics on the device tree bindings for
QMSS can be found in:
Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txt
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
