Age | Commit message (Collapse) | Author |
|
commit 17529d43b21c72466e9109d602c6f5c360a1a9e8 upstream.
TRM "Table 13-34. SYSCONFIG Register Field Descriptions" lists both
standbymode and idlemode that should be just the sidle and midle
registers where midle is currently unconfigured for lcdc_sysc. As
the dts data has been generated based on lcdc_sysc, we now have an
empty "ti,sysc-midle" property.
And so we currently get a warning for lcdc because of a difference
with dts provided configuration compared to the legacy platform
data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
the platform data without configuring the modes.
Let's fix the issue by adding the missing midlemode to lcdc_sysc,
and configuring the "ti,sysc-midle" property based on the TRM
values.
Fixes: f711c575cfec ("ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data")
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Robert Nelson <robertcnelson@gmail.com>
Cc: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
commit 4ef5d76b453908f21341e661a9b6f96862f6f589 upstream.
The ti,no-idle-on-init and ti,no-reset-on-init flags need to be at
the interconnect target module level for the modules that have it
defined. Otherwise we get the following warnings:
dts flag should be at module level for ti,no-idle-on-init
dts flag should be at module level for ti,no-reset-on-init
Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc")
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Reported-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
[ Upstream commit 8613e2ca4fff764f23785eadfa54a08631ee682a ]
As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size.
Fix this in the DTS.
Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 89bbc6f1eb90809b1538b3a9c54030c558180e3b ]
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
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>
|
|
Reading the module revision register can cause an external abort on
non-linefetch depending of osc clock is not already enabled. This
started happening with commit 1a5cd7c23cc5 ("bus: ti-sysc: Enable all
clocks directly during init to read revision") as reported by
Sebastian Andrzej Siewior <bigeasy@linutronix.de>.
The reason why the issue happens is because we now attempt to read the
interconnect target module revision register by first manually enabling
all the device clocks in sysc_probe(). And looks like d_can also needs
the osc clock in addition to the module clock, and it may or may not be
enabled depending on the bootloader version and if other devices have
already requested osc clock.
Let's fix the issue by adding osc clock as an optional clock for the
module for am335x. Note that am437x does not seem to list the osc clock
at all, so presumably it is not needed for am437x.
I also noticed that we're incorrectly assuming the revision register for
d_can exists. But the module does not seem to have any revision, sysconfig
or sysstatus registers. But that's mostly a cosmetic issues, so I'll send
a patch separately for that.
Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision")
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
We must not use legacy clock defines for dts clckctrl clocks as the offsets
will be wrong.
Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc")
Cc: Tero Kristo <t-kristo@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>
|
|
Remove the unnecessary properties #address-cells and #size-cells
of node pinmux as there are no child-nodes with property reg.
Signed-off-by: Felix Brack <fb@ltec.ch>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Looks like I missed the ranges for am335x epwmss. Let's set it up the
same way as for am437x and dra7.
Fixes: 87fc89ced3a7 ("ARM: dts: am335x: Move l4 child devices to probe
them with ti-sysc")
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Earlier attempt to move am335x mcasp to probe with ti-sysc
interconnect target module caused audio to stop working and and
the dts changes were reverted by commit 5d2632a577ba ("ARM: dts:
Revert am335x mcasp ti-sysc changes").
Turns out we were missing the l3 data port ranges for mcasp. This
caused mcasp dma to attempt to use wrong port address. So let's
try again essentially reverting the earlier revert and adding the
missing l3 data port ranges.
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Without this McASP FIFO would constantly underflow. EDMA
test via dmatest works though.
Let's revert the change for now until we know the root cause.
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 8f42cb7f64c7 ("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>
|