We are currently using a wrong register for dcan revision. Although
this is currently only used for detecting the dcan module, let's
fix it to avoid confusion.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Some interconnect target modules have no module control registers at
all, such as d_can on am335x and am437x.
The d_can register offset at 0 is CTL register with 0x401 as the default
value. I guess I mistook the 0x401 value for a revision register as the
value happens to look similar to what the revision registers typically
have for other modules.
To handle modules with no control registers, we need to improve the
ti-sysc driver a bit to bail out with errors on no control registers,
and then we can remove the bogus revision registers for d_can.
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We need to add mcasp l3 port ranges for mcasp to use a correct l3
data port address for dma.
Fixes: d95adfd458 ("ARM: dts: am437x: Move l4 child devices to
probe them with ti-sysc")
Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
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.
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.
Note that we are not yet moving dss or wkup_m3, those will be moved
later after some related driver changes.
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Similar to commit 8f42cb7f64 ("ARM: dts: omap4: Add l4 interconnect
hierarchy and ti-sysc data"), let's add proper interconnect hierarchy
for l4 interconnect instances with the related ti-sysc interconnect
module data as 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.
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.
Note that we cannot yet include this file from the SoC dtsi file until
the 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.
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tony Lindgren