| Age | Commit message (Collapse) | Author |
|---|
|
omap-for-v5.6/ti-sysc-drop-pdata
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with device tree only configuration using
ti-sysc interconnect target module driver. Let's configure the
module, but keep the legacy "ti,hwmods" peroperty to avoid new boot
time warnings. The legacy property will be removed in later patches
together with the legacy platform data.
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add RNG interconnect data for omap4 similar to what dra7 has. The
clock is OMAP4_CM_L4SEC_RNG_CLKCTRL_OFFSET at offset address 0x01c0,
which matches what dra7 also has with DRA7_L4SEC_CLKCTRL_INDEX(0x1c0).
Note that we need to also add the related l4_secure clock entries.
I've only added RNG, the others can be added as they get tested.
They are probably very similar to what we already have for dra7
in dra7_l4sec_clkctrl_regs[].
With the clock tagged CLKF_SOC_NONSEC, clock is set disabled for secure
devices and clk_get() will fail. Additionally we disable the RNG target
module on droid4 to avoid introducing new boot time warnings.
Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
|
|
Convert omap4 IOMMUs to use ti-sysc instead of legacy omap-hwmod based
implementation. Enable the IOMMUs also while doing this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Sebastian Reichel <sre@kernel.org>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Bin Liu <b-liu@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Franklin S Cooper Jr <fcooper@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We need this to pass auxdata to all the sdma instances.
Cc: devicetree@vger.kernel.org
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/dt
PRM reset control dts changes for v5.5 merge window
This series of changes adds the PRM reset driver nodes for am3/4, omap4/5
and dra7 SoCs. The reset driver changes make it easier to add support for
various accelerators for TI SoCs in a more generic way.
Note that this branch is based on the PRM reset driver changes branch.
* tag 'omap-for-v5.5/prm-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: omap5: Add PRM data
ARM: dts: am43xx: Add PRM data
ARM: dts: am33xx: Add PRM data
ARM: dts: omap4: add PRM nodes
ARM: dts: dra7: add PRM nodes
soc: ti: omap-prm: add omap5 PRM data
soc: ti: omap-prm: add am4 PRM data
soc: ti: omap-prm: add dra7 PRM data
soc: ti: omap-prm: add data for am33xx
soc: ti: omap-prm: add omap4 PRM data
soc: ti: omap-prm: add support for denying idle for reset clockdomain
soc: ti: omap-prm: poll for reset complete during de-assert
soc: ti: add initial PRM driver with reset control support
dt-bindings: omap: add new binding for PRM instances
Link: https://lore.kernel.org/r/pull-1572623173-281197@atomide.com
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the custom ti,hwmods dts property. We have already
dropped the platform data earlier, but have been still allocating it
dynamically, which is no longer needed.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the custom ti,hwmods dts property. We have already
dropped the platform data earlier, but have been still allocating it
dynamically, which is no longer needed.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add PRM nodes for omap4 series of SoCs. These are initially used to
support reset control for some of the nodes, but will be extended
later to add powerdomain control and support for PRCM irqs among
other things.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's configure the related dts data based on what we have
defined in the legacy platform data.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the custom ti,hwmods dts property. We have already
dropped the platform data earlier and have been allocating it
dynamically.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
With recent ti-sysc driver changes, we can now finally probe most
modules without needing the custom ti,hwmods property.
Let's drop it for omap4 MMC as we can test that for runtime PM
for core retention idle mode for wlcore WLAN.
Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
With recent ti-sysc driver changes, we can now finally probe most
modules without needing the custom ti,hwmods property.
Let's start with omap4 uart as we can test that for runtime PM
for core retention idle mode.
Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
While reviewing the missing mcasp ranges I noticed omap4 hsi range
for gdd is wrong so let's fix it.
I'm not aware of any omap4 devices in mainline kernel though that use
hsi though.
Fixes: 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc")
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Compared to 4430, 4460 and 4470 just have slightly different
l4 cfg ranges.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
With l4 interconnect hierarchy and ti-sysc interconnect target module
data in place, we can simply move all the related child devices to
their proper location and enable probing using ti-sysc.
In general the first child device address range starts at range 0
from the ti-sysc interconnect target so the move involves adjusting
the child device reg properties for that.
And we cannot yet move mmu_dsp until we have a proper reset controller
driver for rstctrl registers.
In case of any regressions, problem devices can be reverted to probe
with legacy platform data as needed by moving them back and removing
the related interconnect target module node.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Let's add proper interconnect hierarchy for l4 interconnect
instances with the related ti-sysc interconnect module data as
documented in Documentation/devicetree/bindings/bus/ti-sysc.txt.
Using ti-sysc driver binding allows us to start dropping
legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c
files later on in favor of ti-sysc dts data.
For setting up a proper hierarchy for the interconnect and
ti-sysc data, there are multiple reasons:
1. We can use dts ranges to protect registers from being
ioremapped from other devices and prevent hard to track
issues with failed flush of posted write between modules
2. Some of the ranges may not be accessible to operating systems
at all if configured so on high-security devices
3. The interconnect hierarchy provides proper clockdomain
hierarchy that can be used for genpd later on
4. We can avoid almost all deferred probe related issues simply
by probing the resource providing interconnect instance first
for l4 wkup instance
5. With deferred probe issues gone, we can probe everything
later at module_init time except for system timer and interrupt
controller and their clocks.
This data is generated based on platform data from a booted system
and the interconnect acces protection registers for ranges. To avoid
regressions, we initially validate the device tree provided data
against the existing platform data on boot.
Each interconnect instance is typically divided into segments
to avoid powering up the whole interconnect. And each segment
has one or more ranges TI specific interconnect target modules
connected to it. Some devices can also have a separate data
access port directly to the parent L3 interconnect for DMA that
can be set up as a separate range.
Note that we cannot yet include this file from omap4.dtsi
until child devices are moved to their proper locations in
the interconnect hierarchy in the following patch. Otherwise
we would have the each module probed twice.
Also note that this does not yet add l4 abe instance, that will
be added separately later on.
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
