Commit Graph

19 Commits

Author SHA1 Message Date
Olof Johansson
bcec1221c9 Fixes for omaps for v5.4-rc cycle
Here are fixes for omaps to deal with few regressions, and to fix
 more boot time errors and warnings:
 
 - The recent ti-sysc interconnect target module driver changes had
   incorrect clock bits for both clocks and dts that cause warnings
 
 - For omap3-gta04, gpio changes caused the LCD to break a while back,
   and after discussing things the right fix is to set spi-cs-high
 
 - Recent omapdrm changes to use generic panels caused tfp410 to be
   disabled as we now must enable the generic support for it in
   defconfig
 
 - Recent omapdrm and backlight changes also finally made droid4 LCD
   to work, so let's enable it in the defconfig it can be used out
   of the box. This is not strictly a fix, but we still also have the
   older CONFIG_MFD_TI_LMU options available so this cuts down the
   confusion for trying to guess which display and which backlight
   is needed
 
 - Recent ti-sysc interconnect target module changes need the gpio
   module disabled on some boards, but this now needs to happen at
   the module level, not at the gpio driver level
 
 - Recent changes to probe system timers with ti-sysc caused warnings
   about mismatch in syconfig registers, so let's configure the option
   for RESET_STATUS as available in the TRMs
 
 - Recent changes to probe LCDC with ti-sysc caused warnings about
   mismatch in sysconfig registers, so let's configure the missing
   idlemodes for both platform data and dts as documented in TRMs
 
 - Since we moved mach-omap2 to probe with device tree, we've been
   getting voltage controller warnings. Turns out this code is no
   longer needed, so let's just remove omap2_set_init_voltage() to
   get rid of the pointless warnings
 
 - Configure am4372 dispc memory bandwidth to avoid underflow errors
 -----BEGIN PGP SIGNATURE-----
 
 iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl2U6fcRHHRvbnlAYXRv
 bWlkZS5jb20ACgkQG9Q+yVyrpXMu5RAAi9bqFTwKU3YiA4o0yDufGtx63fMziCD4
 pMct5DMqyIfkCbU6KIp/pC3g3x35zl7WjoAbyB9Q8o33g/9mnQUSSTkB1TID/fZ0
 +d7epXsGPRWymP2B13xOH/yRJv8dDeVWVHLBJdatuaAJ0mygpf4a4ChkXYKp+nhl
 oShxeRiOYYCrhowklmjvzV0atz17QSNc42GvAUpL3aicU9XmeYn7JLcxZ+3dBXuz
 5IRbM/kt66i0owT6Oymf2lvf+UXELLXL/bXINPbPyYrXw94WuIk1z3i3gtQLsRk+
 CyoYczBsgSWZRoFJB03324HY+KhGNHbC6kjfqoWk5UrbbX13L1+tSnKSlFRcZddx
 64HPZISsgPOlx+i4TlTw/7YMq6FbLB8Z9gp+J1hxycynjYrfVQNCJADMlQDqA1DS
 gncdaz0O1RVcQULndFu7EYyLvybUjFmr0Q1wrW7mOFbIQn7KVTNYJ9GUJjWwmYcI
 N9yw6H7FjNad0TA+5prXKvQj+iP6budedW9Ke3mvyhkePMKwvORX5I6aVKjL0vKo
 gjUKuZC2x75GxgiUwYIJwDOEQGkBySFtf7RGFBjJ7l73/r4kDH6X/kG5AQDB0l3e
 sTSgMTM8KbkNWdQsvATSEN0Tf4Z7UsuhAhKLihNmkt7YXaYXEtBu0xoKPR8y6Xbd
 ZkiGMxkpLUY=
 =SkMF
 -----END PGP SIGNATURE-----

Merge tag 'omap-for-v5.4/fixes-rc1-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes

Fixes for omaps for v5.4-rc cycle

Here are fixes for omaps to deal with few regressions, and to fix
more boot time errors and warnings:

- The recent ti-sysc interconnect target module driver changes had
  incorrect clock bits for both clocks and dts that cause warnings

- For omap3-gta04, gpio changes caused the LCD to break a while back,
  and after discussing things the right fix is to set spi-cs-high

- Recent omapdrm changes to use generic panels caused tfp410 to be
  disabled as we now must enable the generic support for it in
  defconfig

- Recent omapdrm and backlight changes also finally made droid4 LCD
  to work, so let's enable it in the defconfig it can be used out
  of the box. This is not strictly a fix, but we still also have the
  older CONFIG_MFD_TI_LMU options available so this cuts down the
  confusion for trying to guess which display and which backlight
  is needed

- Recent ti-sysc interconnect target module changes need the gpio
  module disabled on some boards, but this now needs to happen at
  the module level, not at the gpio driver level

- Recent changes to probe system timers with ti-sysc caused warnings
  about mismatch in syconfig registers, so let's configure the option
  for RESET_STATUS as available in the TRMs

- Recent changes to probe LCDC with ti-sysc caused warnings about
  mismatch in sysconfig registers, so let's configure the missing
  idlemodes for both platform data and dts as documented in TRMs

- Since we moved mach-omap2 to probe with device tree, we've been
  getting voltage controller warnings. Turns out this code is no
  longer needed, so let's just remove omap2_set_init_voltage() to
  get rid of the pointless warnings

- Configure am4372 dispc memory bandwidth to avoid underflow errors

* tag 'omap-for-v5.4/fixes-rc1-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: am4372: Set memory bandwidth limit for DISPC
  ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage()
  ARM: OMAP2+: Add missing LCDC midlemode for am335x
  ARM: OMAP2+: Fix missing reset done flag for am3 and am43
  ARM: dts: Fix gpio0 flags for am335x-icev2
  ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules
  ARM: omap2plus_defconfig: Enable DRM_TI_TFP410
  DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again
  ARM: dts: Fix wrong clocks for dra7 mcasp
  clk: ti: dra7: Fix mcasp8 clock bits

Link: https://lore.kernel.org/r/pull-1570040410-308159@atomide.com
Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-03 09:15:19 -07:00
Tony Lindgren
17529d43b2 ARM: OMAP2+: Add missing LCDC midlemode for am335x
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: f711c575cf ("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>
2019-09-25 10:07:27 -07:00
Tony Lindgren
4ef5d76b45 ARM: dts: Fix gpio0 flags for am335x-icev2
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: 87fc89ced3 ("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>
2019-09-24 09:24:28 -07:00
Arnd Bergmann
feeb04ce91 Drop legacy platform data omap variants for v5.4
We can now drop more platform data in favor of dts data for most
 devices like cpsw, gpio, i2c, mmc, uart and watchdog.
 
 In general we can do this by dropping legacy "ti,hwmods" custom dts
 property, and the platform data assuming the related dts data is correct.
 This is best done as single patch as otherwise we'd have to revert two
 patches in case of any unexpected issues, and we're just removing data.
 
 Fro cpsw, before we can do this, we need to configure the cpsw mdio clocks
 properly in dts though in the first patch. For omap4 i2c, we've already
 dropped the platform data earlier, but have been still allocting it
 dynamically based on the dts data based on the "ti,hwmods" property, but
 that is no longer needed. For d2d, we are missing the dts data, so we
 first add it and then drop the platform data.
 
 For dra7, we drop platform data and "ti,hwmods" for mcasp and mcspi.
 We've already dropped platform data earlier for gpio, i2c, mmc, and
 uart so we just need to drop "ti,hwmods" property for those.
 
 Note that this branch is based on earlier ti-sysc-fixes branch.
 -----BEGIN PGP SIGNATURE-----
 
 iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl1mxxsRHHRvbnlAYXRv
 bWlkZS5jb20ACgkQG9Q+yVyrpXOoPhAAxRtVcr86Fsb535T6/Zy4wKpshvDIXrlZ
 AxfT+NlDxgsZRWSTFYlRIPxEyWpIQDDBL34Y4UMO2gKB0pWGhFfiuUi2SNXntWaj
 VsM5QeMAG/9LFIdUw08XwR/ahrUQnBbNNkHkw/7mL/q/Tsu3NDeIV4ipSz5Qj7vE
 SljP/8DTTkR8TyUWBy3p64UZctx/QMdurg3zuwqCiT3wWEVQRnFesTS1zCzhbZId
 sDbvYc46CaIkgNjlsCgzZuBIpbLH7EtJWZXb01DAqVVidCaO6r82BvAqfXcDCLwj
 sOZOFBQ77ch+zpjlPcYv99TIOQFWnrCIXzKpZfZIJkO6Iu6ugGvPFN99x6WTHZLC
 fGLPz6I9qaObuHLuypkcJCOVmGGQmDJiKnAruJX5peOmLQlV4UaYhNoLkQv3RSC+
 6XeSB0+ycVu2CY35kNwTNVWOGVOYC8a8Umw5pUPVHn94DZgr4qmHEy9Jv0/S0BNy
 04ldN5rufhFBK2A0Vs9HKGRgQfYZ1l2MHxB7LGMFt0jXxzZWGcl7HqZWGcWIuLDr
 ohjwKVCGS6SCofC5qSxAzrdasqhkR/V7Yi0uge2PYGrLX7evoD5fIZADrUcVXcRS
 KI9jcj/7+OTCd9QbkobHGFYa6HZN/66jp0uhnoToTNhbGQXDDGhG5U7Zd+bWXP6i
 nBc7gmpXJEo=
 =mBPp
 -----END PGP SIGNATURE-----

Merge tag 'omap-for-v5.4/ti-sysc-drop-pdata-take2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/late

Drop legacy platform data omap variants for v5.4

We can now drop more platform data in favor of dts data for most
devices like cpsw, gpio, i2c, mmc, uart and watchdog.

In general we can do this by dropping legacy "ti,hwmods" custom dts
property, and the platform data assuming the related dts data is correct.
This is best done as single patch as otherwise we'd have to revert two
patches in case of any unexpected issues, and we're just removing data.

Fro cpsw, before we can do this, we need to configure the cpsw mdio clocks
properly in dts though in the first patch. For omap4 i2c, we've already
dropped the platform data earlier, but have been still allocting it
dynamically based on the dts data based on the "ti,hwmods" property, but
that is no longer needed. For d2d, we are missing the dts data, so we
first add it and then drop the platform data.

For dra7, we drop platform data and "ti,hwmods" for mcasp and mcspi.
We've already dropped platform data earlier for gpio, i2c, mmc, and
uart so we just need to drop "ti,hwmods" property for those.

Note that this branch is based on earlier ti-sysc-fixes branch.

* tag 'omap-for-v5.4/ti-sysc-drop-pdata-take2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: Drop legacy custom hwmods property for dra7 gpio
  ARM: dts: Drop legacy custom hwmods property for dra7 mmc
  ARM: dts: Drop legacy custom hwmods property for dra7 i2c
  ARM: dts: Drop legacy custom hwmods property for dra7 uart
  ARM: OMAP2+: Drop legacy platform data for dra7 mcasp
  ARM: OMAP2+: Drop legacy platform data for dra7 mcspi
  ARM: OMAP2+: Drop legacy platform data for omap4 d2d
  ARM: dts: Configure d2d dts data for omap4
  ARM: OMAP2+: Drop legacy watchdog platform data for omap4
  ARM: dts: Drop custom hwmod property for omap4 i2c
  ARM: OMAP2+: Drop legacy platform data for cpsw on dra7
  ARM: OMAP2+: Drop legacy platform data for cpsw on am3 and am4
  ARM: dts: Add fck for cpsw mdio for omap variants

Link: https://lore.kernel.org/r/pull-1567016893-318461@atomide.com-3
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04 17:21:31 +02:00
Tony Lindgren
7abe746191 ARM: OMAP2+: Drop legacy platform data for cpsw on am3 and am4
We can now probe cpsw with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property for am3 and am4.

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: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:15 -07:00
Tony Lindgren
1faa415c9c ARM: dts: Add fck for cpsw mdio for omap variants
In preparation for dropping legacy platform data and custom ti,hwmods
property, we need to make functional clock available for mdio for the
SoCs so the the mdio driver can find it.

The mdio hardware currently relies on a mdio_hwmod to manage the clock
for omap variants. This is wrong though as there are no separate
sysconfig registers for mdio. All the cpsw related components are just
children of the gmac module.

Note that since mdio is a child of cpsw, just doing pm_runtime_get()
in the mdio driver enables the clock. However, since mdio is also used
by davinci that does not implement runtime PM, let's just add the fck
for now.

Also note that am437x mdio already has a clock, let's update it to
not use the legacy clock naming to unify things further.

Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:14 -07:00
Tony Lindgren
58e16d792a Merge branch 'ti-sysc-fixes' into fixes 2019-08-13 03:40:10 -07:00
Emmanuel Vadot
8613e2ca4f ARM: dts: am335x: Fix UARTs length
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>
2019-08-13 03:18:38 -07:00
Tony Lindgren
89bbc6f1eb ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7
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>
2019-07-24 00:51:27 -07:00
Tony Lindgren
e4f50c8d10 bus: ti-sysc: Handle devices with no control registers
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-02 06:29:46 -07:00
Tony Lindgren
516f1117d0 ARM: dts: Configure osc clock for d_can on am335x
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 1a5cd7c23c ("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: 1a5cd7c23c ("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-05-01 14:24:09 -07:00
Tony Lindgren
7d56bedb27 ARM: dts: Fix dcan clkctrl clock for am3
We must not use legacy clock defines for dts clckctrl clocks as the offsets
will be wrong.

Fixes: 87fc89ced3 ("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-03-26 11:26:24 -07:00
Grygorii Strashko
fcfa0e84ea ARM: dts: am335x: switch to use phy-gmii-sel
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-02-20 08:14:04 -08:00
Felix Brack
7da10df988 ARM: dts: am33xx: Remove unnecessary properties
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>
2019-01-24 08:15:33 -08:00
Tony Lindgren
f4ef6fd078 ARM: dts: Fix ranges for am335x epwmss
Looks like I missed the ranges for am335x epwmss. Let's set it up the
same way as for am437x and dra7.

Fixes: 87fc89ced3 ("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-11 07:31:25 -08:00
Tony Lindgren
f2fb18c7cc ARM: dts: Add am335x mcasp with l3 data port ranges
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 5d2632a577 ("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-12-07 09:27:29 -08:00
Tony Lindgren
5d2632a577 ARM: dts: Revert am335x mcasp ti-sysc changes
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-11-29 11:05:35 -08:00
Tony Lindgren
87fc89ced3 ARM: dts: am335x: Move l4 child devices to probe them with ti-sysc
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-18 10:04:02 -07:00
Tony Lindgren
f711c575cf ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data
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>
2018-10-18 10:04:02 -07:00