Olof Johansson [Sat, 3 Oct 2020 19:58:31 +0000 (12:58 -0700)]
Merge tag 'imx-drivers-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/drivers
i.MX drivers update for 5.10:
- Use dev_err_probe() to simplify error handling for i.MX GPCv2 driver.
- Add a check in i.MX SCU power domain driver to ignore the power
domains that are not owned by the current partition.
* tag 'imx-drivers-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
firmware: imx: scu-pd: ignore power domain not owned
soc: imx: gpcv2: Use dev_err_probe() to simplify error handling
Olof Johansson [Sat, 26 Sep 2020 19:56:50 +0000 (12:56 -0700)]
Merge tag 'drivers_soc_for_5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone into arm/drivers
ARM: soc: TI driver updates for v5.10
Consist of:
- Add Ring accelerator support for AM65x
- Add TI PRUSS platform driver and enable it on available platforms
- Extend PRUSS driver for CORECLK_MUX/IEPCLK_MUX support
- UDMA rx ring pair fix
- Add socinfo entry for J7200
* tag 'drivers_soc_for_5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone:
Add missing '#' to fix schema errors:
soc: ti: Convert to DEFINE_SHOW_ATTRIBUTE
dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair request
soc: ti: k3-socinfo: Add entry for J7200
soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX
dt-bindings: soc: ti: Update TI PRUSS bindings regarding clock-muxes
firmware: ti_sci: allow frequency change for disabled clocks by default
soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one
soc: ti: pruss: Enable support for ICSSG subsystems on K3 J721E SoCs
soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs
soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC
soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs
soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs
soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
dt-bindings: soc: ti: Add TI PRUSS bindings
bindings: soc: ti: soc: ringacc: remove ti,dma-ring-reset-quirk
soc: ti: k3: ringacc: add am65x sr2.0 support
Olof Johansson [Sat, 26 Sep 2020 19:39:07 +0000 (12:39 -0700)]
Merge tag 'tee-dev-cleanup-for-v5.10' of git://git.linaro.org:/people/jens.wiklander/linux-tee into arm/drivers
Simplify tee_device_register() and friends
Uses cdev_device_add() instead of the cdev_add() device_add()
combination.
Initializes dev->groups instead of direct calls to sysfs_create_group()
and friends.
* tag 'tee-dev-cleanup-for-v5.10' of git://git.linaro.org:/people/jens.wiklander/linux-tee:
tee: avoid explicit sysfs_create/delete_group by initialising dev->groups
tee: replace cdev_add + device_add with cdev_device_add
$id: 'http://devicetree.org/schemas/soc/ti/ti,pruss.yaml' does not match
'http://devicetree.org/schemas/.*\\.yaml#'
$schema: 'http://devicetree.org/meta-schemas/core.yaml' is not one of
['http://devicetree.org/meta-schemas/core.yaml#',
'http://devicetree.org/meta-schemas/base.yaml#']
Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml: ignoring,
error in schema: $id
Fixes: bd691ce0ba9d ("dt-bindings: soc: ti: Add TI PRUSS bindings") Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Enable support for the BPMP on Tegra234 to avoid relying on Tegra194
being enabled to pull in the needed OF device ID table entry.
On simulation platforms the BPMP hasn't booted up yet by the time we
probe the BPMP driver and the BPMP hasn't had a chance to mark the
doorbell as ringable by the CCPLEX. This corresponding check in the
BPMP driver will therefore fail. Work around this by disabling the
check on simulation platforms.
Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
This function extracts the PRE_SI_PLATFORM field from the HIDREV
register and can be used to determine which platform the kernel runs on
(silicon, simulation, ...). Note that while only Tegra194 and later
define this field, it should be safe to call this on prior generations
as well since this field should read as 0, indicating silicon.
Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
tee: avoid explicit sysfs_create/delete_group by initialising dev->groups
If the dev->groups is initialised, the sysfs group is created as part
of device_add call. There is no need to call sysfs_create/delete_group
explicitly.
tee: replace cdev_add + device_add with cdev_device_add
Commit 233ed09d7fda ("chardev: add helper function to register char devs
with a struct device") added a helper function 'cdev_device_add'.
Make use of cdev_device_add in tee_device_register to replace cdev_add
and device_add. Since cdev_device_add takes care of setting the
kobj->parent, drop explicit initialisation in tee_device_alloc.
Olof Johansson [Tue, 15 Sep 2020 15:10:40 +0000 (08:10 -0700)]
Merge tag 'scmi-updates-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/drivers
ARM SCMI updates for v5.10
Couple of main additions: SCMI system protocol support and ability to
build SCMI driver as a single module which is needed by some transports
like virtio as they may not be ready early during the boot. This also
includes constification of scmi ops and related function pointers.
* tag 'scmi-updates-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Enable building as a single module
firmware: arm_scmi: Move scmi protocols registration into the driver
firmware: arm_scmi: Move scmi bus init and exit calls into the driver
firmware: smccc: Export both smccc functions
firmware: arm_scmi: Fix NULL pointer dereference in mailbox_chan_free
firmware: arm_scmi: Add SCMI device for system power protocol
firmware: arm_scmi: Add system power protocol support
firmware: arm_scmi: Constify static scmi-ops
firmware: arm_scmi: Constify ops pointers in scmi_handle
cpufreq: arm_scmi: Constify scmi_perf_ops pointers
firmware: arm_scmi: Move scmi protocols registration into the driver
In preparation to enable building SCMI as a single module, let us move
the SCMI protocol registration call into the driver. This enables us
to also add unregistration of the SCMI protocols.
The main reason for this is to keep it simple instead of maintaining
it as separate modules and dealing with all possible initcall races
and deferred probe handling. We can move it as separate modules if
needed in future.
firmware: arm_scmi: Move scmi bus init and exit calls into the driver
In preparation to enable building scmi as a single module, let us move
the scmi bus {de-,}initialisation call into the driver.
The main reason for this is to keep it simple instead of maintaining
it as separate modules and dealing with all possible initcall races
and deferred probe handling. We can move it as separate modules if
needed in future.
Sudeep Holla [Tue, 23 Jun 2020 14:33:57 +0000 (15:33 +0100)]
firmware: smccc: Export both smccc functions
We need to export both arm_smccc_1_1_get_conduit and arm_smccc_get_version
to allow several modules make use of them. Arm FFA, Arm SCMI and PTP
drivers are few drivers that are planning to use these functions.
Let us export them in preparation to add support for SCMI as module.
Olof Johansson [Sun, 13 Sep 2020 18:40:17 +0000 (11:40 -0700)]
Merge tag 'arm-soc/for-5.10/drivers' of https://github.com/Broadcom/stblinux into arm/drivers
This pull request contains Broadcom SoCs drivers changes for 5.10,
please pull the following:
- Alvaro adds support for the BCM63xx (DSL) SoCs power domain controller
and adds support for the 6318, 6328, 6362, 63268.
- Florian adds support for tuning the Bus Interface Unit on 72164 and
72165, enables the Brahma-B53 and Cortex-A72 read-ahead cache for the
64-bit capable ARCH_BRCMSTB platforms, and finally updates the GISB
driver to support breakpoint notifications.
* tag 'arm-soc/for-5.10/drivers' of https://github.com/Broadcom/stblinux:
bus: brcmstb_gisb: Add support for breakpoint interrupts
dt-bindings: bus: Document breakpoint interrupt for gisb-arb
soc: bcm: brcmstb: biuctrl: Change RAC data line prefetching after 4 consecutive lines
soc: bcm: brcmstb: biuctrl: Change RAC prefetch distance from +/-1 to +/- 2
soc: bcm: brcmstb: biuctrl: Tune MCP settings for 72165
soc: bcm: brcmstb: biuctrl: Tune MCP settings for 72164
MIPS: BMIPS: dts: add BCM63268 power domain support
MIPS: BMIPS: dts: add BCM6362 power domain support
MIPS: BMIPS: dts: add BCM6328 power domain support
soc: bcm: add BCM63xx power domain driver
MIPS: BMIPS: add BCM6318 power domain definitions
MIPS: BMIPS: add BCM63268 power domain definitions
MIPS: BMIPS: add BCM6362 power domain definitions
MIPS: BMIPS: add BCM6328 power domain definitions
dt-bindings: soc: brcm: add BCM63xx power domain binding
soc: bcm: brcmstb: biuctrl: Enable Read-ahead cache
bus: brcmstb_gisb: Shorten prints
Olof Johansson [Sun, 13 Sep 2020 18:26:36 +0000 (11:26 -0700)]
Merge tag 'memory-controller-drv-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
Memory controller drivers for v5.10
1. Fixes in several drivers for GCC warnings, including kerneldoc fixes
and issues discovered while compile testing.
2. Enable compile testing of most of the drivers.
3. Use dev_err_probe() to simplify the code.
4. omap-gpmc: fix off by one errors, code cleanups and improvements.
5. tegra: remove the GPU from DRM IOMMU group so it would use its own;
few minor fixes.
6. brcmstb_dpfe: fix memory leak and array index out of bounds.
* tag 'memory-controller-drv-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: (26 commits)
memory: fsl-corenet-cf: Fix handling of platform_get_irq() error
memory: omap-gpmc: Fix -Wunused-function warnings
memory: tegra: Remove GPU from DRM IOMMU group
memory: tegra186-emc: Simplify with dev_err_probe()
memory: brcmstb_dpfe: Simplify with dev_err_probe()
memory: samsung: exynos5422-dmc: add missing and fix kerneldoc
memory: samsung: exynos5422-dmc: remove unused exynos5_dmc members
memory: samsung: exynos5422-dmc: rename timing register fields variables
memory: emif: Remove bogus debugfs error handling
memory: omap-gpmc: Fix build error without CONFIG_OF
memory: omap-gpmc: Fix a couple off by ones
memory: brcmstb_dpfe: fix array index out of bounds
memory: brcmstb_dpfe: Fix memory leak
memory: tegra: Correct shift value of apew
memory: Enable compile testing for most of the drivers
memory: brcmstb_dpfe: add separate entry for compile test
memory: tegra: tegra210-emc: fix indentation
memory: renesas-rpc-if: simplify with PTR_ERR_OR_ZERO
memory: omap-gpmc: consistently use !res for NULL checks
memory: omap-gpmc: use WARN() instead of BUG() on wrong free
...
Olof Johansson [Sun, 13 Sep 2020 18:22:09 +0000 (11:22 -0700)]
Merge tag 'renesas-drivers-for-v5.10-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/drivers
Renesas driver updates for v5.10
- Improve visual Kconfig structure.
* tag 'renesas-drivers-for-v5.10-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
soc: renesas: Align driver description titles
soc: renesas: Use menu for Renesas SoC
soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX
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: Roger Quadros <rogerq@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>
Tero Kristo [Sat, 12 Sep 2020 04:47:08 +0000 (21:47 -0700)]
firmware: ti_sci: allow frequency change for disabled clocks by default
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: Nishanth Menon <nm@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Tero Kristo [Sat, 12 Sep 2020 04:47:08 +0000 (21:47 -0700)]
soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one
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: Tero Kristo <t-kristo@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Suman Anna [Sat, 12 Sep 2020 04:43:37 +0000 (21:43 -0700)]
soc: ti: pruss: Enable support for ICSSG subsystems on K3 J721E SoCs
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: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Suman Anna [Sat, 12 Sep 2020 04:43:36 +0000 (21:43 -0700)]
soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs
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>
Suman Anna [Sat, 12 Sep 2020 04:43:36 +0000 (21:43 -0700)]
soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC
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>
Suman Anna [Sat, 12 Sep 2020 04:43:35 +0000 (21:43 -0700)]
soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs
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>
Suman Anna [Sat, 12 Sep 2020 04:43:35 +0000 (21:43 -0700)]
soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs
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>
Suman Anna [Sat, 12 Sep 2020 04:43:34 +0000 (21:43 -0700)]
soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
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>
This patch adds the bindings for the Programmable Real-Time Unit
and Industrial Communication Subsystem (PRU-ICSS) present on various
TI SoCs. The IP is present on multiple TI SoC architecture families
including the OMAP architecture SoCs such as AM33xx, AM437x and
AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is
also present on the Davinci based OMAPL138 SoCs and K3 architecture
based AM65x and J721E SoCs as well.
The IP has a number of sub-modules some of which are represented as
their own devices. This binding covers only the top-level sub-system
devices, and some sub-modules like MDIO, MII_RT (Ethernet MII_RT module
with MII ports) and IEP (Industrial Ethernet Peripheral). The remaining
sub-modules bindings shall be defined in the respective driver
subsystem bindings folders. Couple of full examples have also been
added demonstrating the devices on AM335x and AM437x SoCs.
Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The AM65x SR2.0 Ringacc has fixed errata i2023 "RINGACC, UDMA: RINGACC and
UDMA Ring State Interoperability Issue after Channel Teardown". This errata
also fixed for J271E SoC.
Use SOC bus data for K3 SoC identification and enable i2023 errate w/a only
for the AM65x SR1.0. This also makes obsolete "ti,dma-ring-reset-quirk" DT
property.
firmware: arm_scmi: Fix NULL pointer dereference in mailbox_chan_free
scmi_mailbox is obtained from cinfo->transport_info and the first
call to mailbox_chan_free frees the channel and sets cinfo->transport_info
to NULL. Care is taken to check for non NULL smbox->chan but smbox can
itself be NULL. Fix it by checking for it without which, kernel crashes
with below NULL pointer dereference and eventually kernel panic.
Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000038
Modules linked in: scmi_module(-)
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno
Development Platform, BIOS EDK II Sep 2 2020
pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--)
pc : mailbox_chan_free+0x2c/0x70 [scmi_module]
lr : idr_for_each+0x6c/0xf8
Call trace:
mailbox_chan_free+0x2c/0x70 [scmi_module]
idr_for_each+0x6c/0xf8
scmi_remove+0xa8/0xf0 [scmi_module]
platform_drv_remove+0x34/0x58
device_release_driver_internal+0x118/0x1f0
driver_detach+0x58/0xe8
bus_remove_driver+0x64/0xe0
driver_unregister+0x38/0x68
platform_driver_unregister+0x1c/0x28
scmi_driver_exit+0x38/0x44 [scmi_module]
---[ end trace 17bde19f50436de9 ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x1d0000 from 0xffff800010000000
PHYS_OFFSET: 0x80000000
CPU features: 0x0240022,25806004
Memory Limit: none
---[ end Kernel panic - not syncing: Fatal exception ]---
Link: https://lore.kernel.org/r/20200908112611.31515-1-sudeep.holla@arm.com Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Cc: Cristian Marussi <cristian.marussi@arm.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
firmware: arm_scmi: Add system power protocol support
Add bare protocol support for SCMI system power protocol as needed by
an OSPM agent: basic initialization and SYSTEM_POWER_STATE_NOTIFIER
core notification support.
No event-handling logic is attached to such notification..
The perf_ops are not modified through this pointer. Make them const to
indicate that. This is in preparation to make the scmi-ops pointers in
scmi_handle const.
bus: brcmstb_gisb: Add support for breakpoint interrupts
GISB breakpoint interrupts can be raised when a breakpoint has been
enabled to match a specific master and/or GISB register address. Being
able to print a message, similar to those done during target abort or
timeout greatly helps debug systems.
Florian Fainelli [Fri, 25 Oct 2019 18:34:58 +0000 (11:34 -0700)]
soc: bcm: brcmstb: biuctrl: Change RAC data line prefetching after 4 consecutive lines
Change the RACPREFDATA(x) setting to prefetch the next 256-byte line
after 4 consecutive lines have been used, instead of after 2 consecutive
lines. This does improve the synthetic memcpy benchmark by an additional
+0.5% on top of the previous change for Cortex-A72 CPUs.
Florian Fainelli [Fri, 25 Oct 2019 18:18:06 +0000 (11:18 -0700)]
soc: bcm: brcmstb: biuctrl: Change RAC prefetch distance from +/-1 to +/- 2
Change the RAC prefetch distance from +/- 1 to +/- 2 for Cortex-A72 CPUs
since this provides an average of a 3.8% performance increase for
synthetic memcpy benchmarks.
drivers/memory/omap-gpmc.c:987:12: warning: ‘gpmc_cs_remap’ defined but not used [-Wunused-function]
drivers/memory/omap-gpmc.c:926:20: warning: ‘gpmc_cs_get_name’ defined but not used [-Wunused-function]
drivers/memory/omap-gpmc.c:919:13: warning: ‘gpmc_cs_set_name’ defined but not used [-Wunused-function]
Commit 63a613fdb16c ("memory: tegra: Add gr2d and gr3d to DRM IOMMU
group") added the GPU to the DRM IOMMU group, which doesn't make any
sense. This causes problems when Nouveau tries to attach to the SMMU
and causes it to fall back to using the DMA API.
Remove the GPU from the DRM groups to restore the old behaviour. The
GPU should always have its own IOMMU domain to make sure it can map
buffers into contiguous chunks (for big page support) without getting
in the way of mappings from the DRM group.
memory: samsung: exynos5422-dmc: add missing and fix kerneldoc
Add missing kerneldoc to struct exynos5_dmc and correct the existing
kerneldoc in other places to fix W=1 warnings like:
drivers/memory/samsung/exynos5422-dmc.c:107: warning: Function parameter or member 'freq_hz' not described in 'dmc_opp_table'
drivers/memory/samsung/exynos5422-dmc.c:154: warning: Function parameter or member 'dev' not described in 'exynos5_dmc'
drivers/memory/samsung/exynos5422-dmc.c:357: warning: Excess function parameter 'param' description in 'exynos5_set_bypass_dram_timings'
drivers/memory/samsung/exynos5422-dmc.c:630: warning: Function parameter or member 'flags' not described in 'exynos5_dmc_get_volt_freq'
drivers/memory/samsung/exynos5422-dmc.c:962: warning: cannot understand function prototype: 'struct devfreq_dev_profile exynos5_dmc_df_profile = '
drivers/memory/samsung/exynos5422-dmc.c:1011: warning: Function parameter or member 'reg_timing_row' not described in 'create_timings_aligned'
drivers/memory/samsung/exynos5422-dmc.c:1011: warning: Excess function parameter 'idx' description in 'create_timings_aligned'
drivers/memory/samsung/exynos5422-dmc.c:1345: warning: Excess function parameter 'set' description in 'exynos5_dmc_set_pause_on_switching'
memory: samsung: exynos5422-dmc: remove unused exynos5_dmc members
The struct exynos5_dmc members bypass_rate, mx_mspll_ccore_phy,
mout_mx_mspll_ccore_phy and opp_bypass are not actually used.
Apparently there was a plan to store the OPP for the bypass mode in
opp_bypass member, but driver fails to do it and instead always sets
target voltage during bypass mode.
The driver has file-scope arrays defining fields of timing registers
(e.g. struct timing_reg timing_row) and actual values for these
registers per each OPP in state container (struct
exynos5_dmc.timing_row). The meanings of these are different so use
different names to avoid confusion.
Now, Renesas SoC drivers are under menu, but current descriptions are
not aligned.
This patch aligns them.
- Emma Mobile EV2
- RZ/A1H (R7S72100)
...
- R-Car H2 (R8A77900)
...
- Renesas R-Car H3 ES1.x SoC Platform
...
- R-Car H2 System Controller support
- R-Car M2-W/N System Controller support
- R-Car V2H System Controller support
- R-Car E2 System Controller support
- R-Car H3 System Controller support
- R-Car M3-W System Controller support
- R-Car M3-W+ System Controller support
- R-Car M3-N System Controller support
+ SoC Platform support for Emma Mobile EV2
+ SoC Platform support for RZ/A1H+
...
+ SoC Platform support for R-Car H2
...
+ SoC Platform support for R-Car H3 ES1.x
...
+ System Controller support for R-Car H2
+ System Controller support for R-Car M2-W/N
+ System Controller support for R-Car V2H
+ System Controller support for R-Car E2
+ System Controller support for R-Car H3
+ System Controller support for R-Car M3-W
+ System Controller support for R-Car M3-W+
+ System Controller support for R-Car M3-N
Dan Carpenter [Wed, 26 Aug 2020 11:37:59 +0000 (14:37 +0300)]
memory: emif: Remove bogus debugfs error handling
Callers are generally not supposed to check the return values from
debugfs functions. Debugfs functions never return NULL so this error
handling will never trigger. (Historically debugfs functions used to
return a mix of NULL and error pointers but it was eventually deemed too
complicated for something which wasn't intended to be used in normal
situations).
Dan Carpenter [Tue, 25 Aug 2020 10:47:07 +0000 (13:47 +0300)]
memory: omap-gpmc: Fix a couple off by ones
These comparisons should be >= instead of > to prevent reading one
element beyond the end of the gpmc_cs[] array.
Fixes: cdd6928c589a ("ARM: OMAP2+: Add device-tree support for NOR flash") Fixes: f37e4580c409 ("ARM: OMAP2: Dynamic allocator for GPMC memory space") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Roger Quadros <rogerq@ti.com> Link: https://lore.kernel.org/r/20200825104707.GB278587@mwanda Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Renesas related SoC settings are located on TOP level menu,
thus it is very verbose.
This patch groups Renesas related settings into
"Renesas SoC driver support" menu.
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
Factor out a new, small release_registered_pages() function, in
order to consolidate the logic for discerning between
TEE_SHM_USER_MAPPED and TEE_SHM_KERNEL_MAPPED pages. This also
absorbs the kfree() call that is also required there.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Markus Mayer [Sat, 22 Aug 2020 20:50:00 +0000 (13:50 -0700)]
memory: brcmstb_dpfe: fix array index out of bounds
We would overrun the error_text array if we hit a TIMEOUT condition,
because we were using the error code "ETIMEDOUT" (which is 110) as an
array index.
We fix the problem by correcting the array index and by providing a
function to retrieve error messages rather than accessing the array
directly. The function includes a bounds check that prevents the array
from being overrun.
drivers: optee: allow op-tee to access devices on the i2c bus
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Alex Dewar [Thu, 20 Aug 2020 17:21:18 +0000 (18:21 +0100)]
memory: brcmstb_dpfe: Fix memory leak
In brcmstb_dpfe_download_firmware(), memory is allocated to variable fw by
firmware_request_nowarn(), but never released. Fix up to release fw on
all return paths.
Cc: <stable@vger.kernel.org> Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE") Signed-off-by: Alex Dewar <alex.dewar90@gmail.com> Acked-by: Markus Mayer <mmayer@broadcom.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200820172118.781324-1-alex.dewar90@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
memory: omap-gpmc: remove GPMC_SET_ONE_CD_MAX macro for safety
The GPMC_SET_ONE_CD_MAX macro uses return statement and variable 'cs'
coming from called scope. This is not a good practice. Also
checkpatch complained:
WARNING: Macros with flow control statements should be avoided
ERROR: Macros starting with if should be enclosed by a do - while
loop to avoid possible if/else logic defects
Since GPMC_SET_ONE_CD_MAX macro just calls one function, it can be open
coded. The difference with original code is that function will exit on
error not after every register set, but after a group of sets.
memory: omap-gpmc: remove unused file-scope phys_base and mem_size
The file-scope variables phys_base and mem_size are assigned in
gpmc_probe() but never read.
This fixes build error when compile testing on x86_64 architecture:
drivers/memory/omap-gpmc.c:246:24: error: conflicting types for ‘phys_base’
static resource_size_t phys_base, mem_size;
In file included from arch/x86/include/asm/page.h:12:0,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/irq.h:14,
from drivers/memory/omap-gpmc.c:12:
arch/x86/include/asm/page_64.h:12:22: note: previous declaration of ‘phys_base’ was here
extern unsigned long phys_base;
The driver does not use macros from asm/mach-types.h (neither MACH_TYPE
nor machine_is_xxx()). Removal of this include allows compile testing
on non-ARM architectures which lack this header.
projects / people / ms / linux.git / log
