aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/boot/dts/am33xx-l4.dtsi
AgeCommit message (Collapse)Author
2019-11-25ARM: OMAP2+: Add missing LCDC midlemode for am335xTony Lindgren
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>
2019-11-25ARM: dts: Fix gpio0 flags for am335x-icev2Tony Lindgren
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>
2019-09-21ARM: dts: am335x: Fix UARTs lengthEmmanuel Vadot
[ 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>
2019-09-21ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7Tony Lindgren
[ 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>
2019-05-02bus: ti-sysc: Handle devices with no control registersTony Lindgren
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>
2019-05-01ARM: dts: Configure osc clock for d_can on am335xTony Lindgren
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>
2019-03-26ARM: dts: Fix dcan clkctrl clock for am3Tony Lindgren
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>
2019-02-20ARM: dts: am335x: switch to use phy-gmii-selGrygorii Strashko
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>
2019-01-24ARM: dts: am33xx: Remove unnecessary propertiesFelix Brack
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>
2018-12-11ARM: dts: Fix ranges for am335x epwmssTony Lindgren
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>
2018-12-07ARM: dts: Add am335x mcasp with l3 data port rangesTony Lindgren
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>
2018-11-29ARM: dts: Revert am335x mcasp ti-sysc changesTony Lindgren
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>
2018-10-18ARM: dts: am335x: Move l4 child devices to probe them with ti-syscTony Lindgren
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>
2018-10-18ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc dataTony Lindgren
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>