Skip to content

L
linux
Switch branch/tag
  1. 03 Oct, 2020 1 commit
  3. 26 Sep, 2020 5 commits
  5. 21 Sep, 2020 2 commits
  7. 18 Sep, 2020 10 commits
  9. 16 Sep, 2020 1 commit
  11. 15 Sep, 2020 1 commit
  13. 14 Sep, 2020 4 commits
  15. 13 Sep, 2020 4 commits
  17. 12 Sep, 2020 12 commits
    • Peter Ujfalusi's avatar
      dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair request · 6259c844
      Peter Ujfalusi authored 
      The original commit mixed up the forward and completion ring IDs for the
rx flow configuration.
Acked-by: default avatarVinod Koul <vkoul@kernel.org>
Reviewed-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
Fixes: 4927b1ab ("dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pair")
Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      6259c844
    • Peter Ujfalusi's avatar
      soc: ti: k3-socinfo: Add entry for J7200 · 4f020441
      Peter Ujfalusi authored 
      Update K3 chipinfo driver to support new TI J7200 SoC.
It's JTAG PARTNO is 0xBB6D.
Reviewed-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      4f020441
    • Grzegorz Jaszczyk's avatar
      soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX · ba59c9b4
      Grzegorz Jaszczyk authored 
      The IEPCLK_MUX is present on all SoCs whereas the CORECLK_MUX is present
only on AM65x SoCs and J721E. Add support for both these CLK muxes.

This allows the clock rates and clock parents for these to be controlled
through DT leveraging the clk infrastructure for configuring the default
parents and rates.
Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
Signed-off-by: default avatarGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      ba59c9b4
    • Grzegorz Jaszczyk's avatar
      dt-bindings: soc: ti: Update TI PRUSS bindings regarding clock-muxes · 25bafac9
      Grzegorz Jaszczyk authored 
      ICSS/ICSSG modules have an IEP clock mux that allow selection of
internal IEP clock from 2 clock sources.

ICSSG module has a CORE clock mux that allows selection of internal CORE
clock from 2 clock sources.

Add binding information for these 2 clock muxes.
Signed-off-by: default avatarGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      25bafac9
    • Tero Kristo's avatar
      firmware: ti_sci: allow frequency change for disabled clocks by default · 71b61082
      Tero Kristo authored 
      If a clock is disabled, its frequency should be allowed to change as
it is no longer in use. Add a flag towards this to the firmware clock
API handler routines.
Acked-by: default avatarNishanth Menon <nm@ti.com>
Tested-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      71b61082
    • Tero Kristo's avatar
      soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one · efa5c01c
      Tero Kristo authored 
      Current implementation of the genpd support over TI SCI uses a single
genpd across the whole SoC, and attaches multiple devices to this. This
solution has its drawbacks, like it is currently impossible to attach
more than one power domain to a device; the core genpd implementation
requires one genpd per power-domain entry in DT for a single device.
Also, some devices like USB apparently require their own genpd during
probe time, the current shared approach in use does not work at all.

Switch the implementation over to use a single genpd per power domain
entry in DT. The domains are registered with the onecell approach, but
we also add our own xlate service due to recent introduction of the
extended flag for TI SCI PM domains; genpd core xlate service requires
a single cell per powerdomain, but we are using two cells.
Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      efa5c01c
    • Suman Anna's avatar
      soc: ti: pruss: Enable support for ICSSG subsystems on K3 J721E SoCs · 557003a9
      Suman Anna authored 
      The K3 J721E family of SoCs have a revised version of the PRU-ICSS (ICSSG)
processor subsystem present on K3 AM65x SoCs. These SoCs contain typically
two ICSSG instances named ICSSG0 and ICSSG1. The two ICSSGs are identical
to each other for the most part with minor SoC integration differences and
capabilities. The ICSSG1 supports slightly enhanced features like SGMII
mode Ethernet, while the ICSSG0 instance is limited to MII mode only.

There is no change in the Interrupt Controller w.r.t AM65x. All other
integration aspects are very similar to the ICSSGs on AM65x SoCs.

The existing pruss platform driver has been updated to support these new
ICSSG instances through new J721E specific compatibles.
Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
Signed-off-by: default avatarGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      557003a9
    • Suman Anna's avatar
      soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs · 6530cd9b
      Suman Anna authored 
      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: default avatarSuman Anna <s-anna@ti.com>
Signed-off-by: default avatarGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      6530cd9b
    • Suman Anna's avatar
      soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC · 3227c8da
      Suman Anna authored 
      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: default avatarAndrew F. Davis <afd@ti.com>
Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
Signed-off-by: default avatarGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      3227c8da
    • Suman Anna's avatar
      soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs · ae19b8a1
      Suman Anna authored 
      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: default avatarSuman Anna <s-anna@ti.com>
Signed-off-by: default avatarGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      ae19b8a1
    • Suman Anna's avatar
      soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs · 78251639
      Suman Anna authored 
      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: default avatarSuman Anna <s-anna@ti.com>
Signed-off-by: default avatarAndrew F. Davis <afd@ti.com>
Signed-off-by: default avatarGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      78251639
    • Suman Anna's avatar
      soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs · dc112956
      Suman Anna authored 
      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: default avatarSuman Anna <s-anna@ti.com>
Signed-off-by: default avatarAndrew F. Davis <afd@ti.com>
Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
Signed-off-by: default avatarGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      dc112956
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7