1. 18 Feb, 2021 2 commits
    • Tony Lindgren's avatar
      soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva · effe89e4
      Tony Lindgren authored
      On reset deassert, we must wait a bit after the rstst bit change before
      we allow clockdomain autoidle again. Otherwise we get the following oops
      sometimes on dra7 with iva:
      
      Unhandled fault: imprecise external abort (0x1406) at 0x00000000
      44000000.ocp:L3 Standard Error: MASTER MPU TARGET IVA_CONFIG (Read Link):
      At Address: 0x0005A410 : Data Access in User mode during Functional access
      Internal error: : 1406 [#1] SMP ARM
      ...
      (sysc_write_sysconfig) from [<c0782cb0>] (sysc_enable_module+0xcc/0x260)
      (sysc_enable_module) from [<c0782f0c>] (sysc_runtime_resume+0xc8/0x174)
      (sysc_runtime_resume) from [<c0a3e1ac>] (genpd_runtime_resume+0x94/0x224)
      (genpd_runtime_resume) from [<c0a33f0c>] (__rpm_callback+0xd8/0x180)
      
      It is unclear what all devices this might affect, but presumably other
      devices with the rstst bit too can be affected. So let's just enable the
      delay for all the devices with rstst bit for now. Later on we may want to
      limit the list to the know affected devices if needed.
      
      Fixes: d30cd83f ("soc: ti: omap-prm: add support for denying idle for reset clockdomain")
      Reported-by: default avatarYongqin Liu <yongqin.liu@linaro.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      effe89e4
    • Tony Lindgren's avatar
      bus: ti-sysc: Fix warning on unbind if reset is not deasserted · a7b5d7c4
      Tony Lindgren authored
      We currently get thefollowing on driver unbind if a reset is configured
      and asserted:
      
      WARNING: CPU: 0 PID: 993 at drivers/reset/core.c:432 reset_control_assert
      ...
      (reset_control_assert) from [<c0fecda8>] (sysc_remove+0x190/0x1e4)
      (sysc_remove) from [<c0a2bb58>] (platform_remove+0x24/0x3c)
      (platform_remove) from [<c0a292fc>] (__device_release_driver+0x154/0x214)
      (__device_release_driver) from [<c0a2a210>] (device_driver_detach+0x3c/0x8c)
      (device_driver_detach) from [<c0a27d64>] (unbind_store+0x60/0xd4)
      (unbind_store) from [<c0546bec>] (kernfs_fop_write_iter+0x10c/0x1cc)
      
      Let's fix it by checking the reset status.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a7b5d7c4
  2. 15 Feb, 2021 3 commits
    • Tony Lindgren's avatar
      Merge branch 'fixes-v5.11' into fixes · 857de6fe
      Tony Lindgren authored
      857de6fe
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix smartreflex init regression after dropping legacy data · fbfa463b
      Tony Lindgren authored
      When I dropped legacy data for omap4 and dra7 smartreflex in favor of
      device tree based data, it seems I only testd for the "SmartReflex Class3
      initialized" line in dmesg. I missed the fact that there is also
      omap_devinit_smartreflex() that happens later, and now it produces an
      error on boot for "No Voltage table for the corresponding vdd. Cannot
      create debugfs entries for n-values".
      
      This happens as we no longer have the smartreflex instance legacy data,
      and have not yet moved completely to device tree based booting for the
      driver. Let's fix the issue by changing the smartreflex init to use names.
      This should all eventually go away in favor of doing the init in the
      driver based on devicetree compatible value.
      
      Note that dra7xx_init_early() is not calling any voltage domain init like
      omap54xx_voltagedomains_init(), or a dra7 specific voltagedomains init.
      This means that on dra7 smartreflex is still not fully initialized, and
      also seems to be missing the related devicetree nodes.
      
      Fixes: a6b1e717 ("ARM: OMAP2+: Drop legacy platform data for omap4 smartreflex")
      Fixes: e54740b4 ("ARM: OMAP2+: Drop legacy platform data for dra7 smartreflex")
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      fbfa463b
    • Tony Lindgren's avatar
      soc: ti: omap-prm: Fix reboot issue with invalid pcie reset map for dra7 · a249ca66
      Tony Lindgren authored
      Yongqin Liu <yongqin.liu@linaro.org> reported an issue where reboot hangs
      on beagleboard-x15. This started happening after commit 7078a5ba
      ("soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1").
      
      We now assert any 012 type resets on init to prevent unconfigured
      accelerator MMUs getting enabled on init depending on the bootloader or
      kexec configured state.
      
      Turns out that we now also wrongly assert dra7 l3init domain PCIe reset
      bits causing a hang during reboot. Let's fix the l3init reset bits to
      use a 01 map instead of 012 map. There are only two rstctrl bits and not
      three. This is documented in TRM "Table 3-1647. RM_PCIESS_RSTCTRL".
      
      Fixes: 5a68c87a ("soc: ti: omap-prm: dra7: add genpd support for remaining PRM instances")
      Fixes: 7078a5ba ("soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1")
      Cc: Kishon Vijay Abraham I <kishon@ti.com>
      Reported-by: default avatarYongqin Liu <yongqin.liu@linaro.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a249ca66
  3. 14 Feb, 2021 7 commits
  4. 13 Feb, 2021 12 commits
  5. 12 Feb, 2021 13 commits
  6. 11 Feb, 2021 3 commits