1. 06 10月, 2021 1 次提交
  2. 21 9月, 2021 9 次提交
  3. 11 8月, 2021 2 次提交
    • T
      bus: ti-sysc: Fix error handling for sysc_check_active_timer() · 06a089ef
      Tony Lindgren 提交于
      We have changed the return type for sysc_check_active_timer() from -EBUSY
      to -ENXIO, but the gpt12 system timer fix still checks for -EBUSY. We are
      also not returning on other errors like we did earlier as noted by
      Pavel Machek <pavel@denx.de>.
      
      Commit 3ff340e2 ("bus: ti-sysc: Fix gpt12 system timer issue with
      reserved status") should have been updated for commit 65fb7367
      ("bus: ti-sysc: suppress err msg for timers used as clockevent/source").
      
      Let's fix the issue by checking for -ENXIO and returning on any other
      errors as suggested by Pavel Machek <pavel@denx.de>.
      
      Fixes: 3ff340e2 ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status")
      Depends-on: 65fb7367 ("bus: ti-sysc: suppress err msg for timers used as clockevent/source")
      Reported-by: NPavel Machek <pavel@denx.de>
      Reviewed-by: NPavel Machek (CIP) <pavel@denx.de>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      06a089ef
    • T
      soc: ti: Remove pm_runtime_irq_safe() usage for smartreflex · ed4520d6
      Tony Lindgren 提交于
      For the smartreflex device, we need to disable smartreflex on SoC idle,
      and have been using pm_runtime_irq_safe() to do that. But we want to
      remove the irq_safe usage as PM runtime takes a permanent usage count
      on the parent device with it.
      
      In order to remove the need for pm_runtime_irq_safe(), let's gate
      the clock directly in the driver. This removes the need to call PM runtime
      during idle, and allows us to switch to using CPU_PM in the following
      patch.
      
      Note that the smartreflex interconnect target module is configured for smart
      idle, but the clock does not have autoidle capability, and needs to be gated
      manually. If the clock supported autoidle, we would not need to even gate
      the clock.
      
      With this change, we can now remove the related quirk flags for ti-sysc
      also.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      ed4520d6
  4. 27 7月, 2021 2 次提交
  5. 11 6月, 2021 3 次提交
  6. 25 5月, 2021 1 次提交
    • T
      bus: ti-sysc: Fix flakey idling of uarts and stop using swsup_sidle_act · c8692ad4
      Tony Lindgren 提交于
      Looks like the swsup_sidle_act quirk handling is unreliable for serial
      ports. The serial ports just eventually stop idling until woken up and
      re-idled again. As the serial port not idling blocks any deeper SoC idle
      states, it's adds an annoying random flakeyness for power management.
      
      Let's just switch to swsup_sidle quirk instead like we already do for
      omap3 uarts. This means we manually idle the port instead of trying to
      use the hardware autoidle features when not in use.
      
      For more details on why the serial ports have been using swsup_idle_act,
      see commit 66dde54e ("ARM: OMAP2+: hwmod-data: UART IP needs software
      control to manage sidle modes"). It seems that the swsup_idle_act quirk
      handling is not enough though, and for example the TI Android kernel
      changed to using swsup_sidle with commit 77c34c84e1e0 ("OMAP4: HWMOD:
      UART1: disable smart-idle.").
      
      Fixes: b4a9a7a3 ("bus: ti-sysc: Handle swsup idle mode quirks")
      Cc: Carl Philipp Klemm <philipp@uvos.xyz>
      Cc: Ivan Jelincic <parazyd@dyne.org>
      Cc: Merlijn Wajer <merlijn@wizzup.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Sebastian Reichel <sre@kernel.org>
      Cc: Sicelo A. Mhlongo <absicsz@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c8692ad4
  7. 18 5月, 2021 1 次提交
    • T
      bus: ti-sysc: Fix am335x resume hang for usb otg module · 4d7b324e
      Tony Lindgren 提交于
      On am335x, suspend and resume only works once, and the system hangs if
      suspend is attempted again. However, turns out suspend and resume works
      fine multiple times if the USB OTG driver for musb controller is loaded.
      
      The issue is caused my the interconnect target module losing context
      during suspend, and it needs a restore on resume to be reconfigure again
      as debugged earlier by Dave Gerlach <d-gerlach@ti.com>.
      
      There are also other modules that need a restore on resume, like gpmc as
      noted by Dave. So let's add a common way to restore an interconnect
      target module based on a quirk flag. For now, let's enable the quirk for
      am335x otg only to fix the suspend and resume issue.
      
      As gpmc is not causing hangs based on tests with BeagleBone, let's patch
      gpmc separately. For gpmc, we also need a hardware reset done before
      restore according to Dave.
      
      To reinit the modules, we decouple system suspend from PM runtime. We
      replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume()
      with direct calls to internal functions and rely on the driver internal
      state. There no point trying to handle complex system suspend and resume
      quirks via PM runtime.
      
      This is issue should have already been noticed with commit 1819ef2e
      ("bus: ti-sysc: Use swsup quirks also for am335x musb") when quirk
      handling was added for am335x otg for swsup. But the issue went unnoticed
      as having musb driver loaded hides the issue, and suspend and resume works
      once without the driver loaded.
      
      Fixes: 1819ef2e ("bus: ti-sysc: Use swsup quirks also for am335x musb")
      Suggested-by: NDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      4d7b324e
  8. 07 5月, 2021 1 次提交
  9. 24 3月, 2021 2 次提交
  10. 12 3月, 2021 1 次提交
  11. 10 3月, 2021 1 次提交
  12. 08 3月, 2021 3 次提交
  13. 18 2月, 2021 1 次提交
    • T
      bus: ti-sysc: Fix warning on unbind if reset is not deasserted · a7b5d7c4
      Tony Lindgren 提交于
      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: NTony Lindgren <tony@atomide.com>
      a7b5d7c4
  14. 19 11月, 2020 1 次提交
  15. 16 11月, 2020 3 次提交
  16. 26 10月, 2020 2 次提交
    • T
      bus: ti-sysc: Fix bogus resetdone warning on enable for cpsw · e7ae08d3
      Tony Lindgren 提交于
      Bail out early from sysc_wait_softreset() just like we do in sysc_reset()
      if there's no sysstatus srst_shift to fix a bogus resetdone warning on
      enable as suggested by Grygorii Strashko <grygorii.strashko@ti.com>.
      
      We do not currently handle resets for modules that need writing to the
      sysstatus register. If we at some point add that, we also need to add
      SYSS_QUIRK_RESETDONE_INVERTED flag for cpsw as the sysstatus bit is low
      when reset is done as described in the am335x TRM "Table 14-202
      SOFT_RESET Register Field Descriptions"
      
      Fixes: d46f9fbe ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit")
      Suggested-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e7ae08d3
    • T
      bus: ti-sysc: Fix reset status check for modules with quirks · e275d210
      Tony Lindgren 提交于
      Commit d46f9fbe ("bus: ti-sysc: Use optional clocks on for enable and
      wait for softreset bit") started showing a "OCP softreset timed out"
      warning on enable if the interconnect target module is not out of reset.
      This caused the warning to be often triggered for i2c and hdq while the
      devices are working properly.
      
      Turns out that some interconnect target modules seem to have an unusable
      reset status bits unless the module specific reset quirks are activated.
      
      Let's just skip the reset status check for those modules as we only want
      to activate the reset quirks when doing a reset, and not on enable. This
      way we don't see the bogus "OCP softreset timed out" warnings during boot.
      
      Fixes: d46f9fbe ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit")
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e275d210
  17. 24 8月, 2020 1 次提交
  18. 21 7月, 2020 1 次提交
    • T
      clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4 · 6cfcd556
      Tony Lindgren 提交于
      Carlos Hernandez <ceh@ti.com> reported that we now have a suspend and
      resume regresssion on am3 and am4 compared to the earlier kernels. While
      suspend and resume works with v5.8-rc3, we now get errors with rtcwake:
      
      pm33xx pm33xx: PM: Could not transition all powerdomains to target state
      ...
      rtcwake: write error
      
      This is because we now fail to idle the system timer clocks that the
      idle code checks and the error gets propagated to the rtcwake.
      
      Turns out there are several issues that need to be fixed:
      
      1. Ignore no-idle and no-reset configured timers for the ti-sysc
         interconnect target driver as otherwise it will keep the system timer
         clocks enabled
      
      2. Toggle the system timer functional clock for suspend for am3 and am4
         (but not for clocksource on am3)
      
      3. Only reconfigure type1 timers in dmtimer_systimer_disable()
      
      4. Use of_machine_is_compatible() instead of of_device_is_compatible()
         for checking the SoC type
      
      Fixes: 52762fbd ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support")
      Reported-by: NCarlos Hernandez <ceh@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NCarlos Hernandez <ceh@ti.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Link: https://lore.kernel.org/r/20200713162601.6829-1-tony@atomide.com
      6cfcd556
  19. 14 7月, 2020 1 次提交
  20. 03 7月, 2020 3 次提交
    • T
      bus: ti-sysc: Do not disable on suspend for no-idle · a55de412
      Tony Lindgren 提交于
      If we have "ti,no-idle" specified for a module we must not disable
      the the module on suspend to keep things backwards compatible.
      
      Fixes: 386cb766 ("bus: ti-sysc: Handle missed no-idle property in addition to no-idle-on-init")
      Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a55de412
    • T
      bus: ti-sysc: Fix sleeping function called from invalid context for RTC quirk · afe6f1ee
      Tony Lindgren 提交于
      With CONFIG_DEBUG_ATOMIC_SLEEP enabled we can see the following with RTC probe:
      
      BUG: sleeping function called from invalid context at drivers/bus/ti-sysc.c:1736
      ...
      (sysc_quirk_rtc) from [<c060d01c>] (sysc_write_sysconfig+0x1c/0x60)
      (sysc_write_sysconfig) from [<c060d9f4>] (sysc_enable_module+0x11c/0x274)
      (sysc_enable_module) from [<c060f37c>] (sysc_probe+0xe9c/0x1380)
      (sysc_probe) from [<c06e9384>] (platform_drv_probe+0x48/0x98)
      
      Fixes: e8639e1c ("bus: ti-sysc: Handle module unlock quirk needed for some RTC")
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      afe6f1ee
    • T
      bus: ti-sysc: Fix wakeirq sleeping function called from invalid context · 9f911392
      Tony Lindgren 提交于
      With CONFIG_DEBUG_ATOMIC_SLEEP enabled we can see the following with
      wakeirqs and serial console idled:
      
      BUG: sleeping function called from invalid context at drivers/bus/ti-sysc.c:242
      ...
      (sysc_wait_softreset) from [<c0606894>] (sysc_enable_module+0x48/0x274)
      (sysc_enable_module) from [<c0606c5c>] (sysc_runtime_resume+0x19c/0x1d8)
      (sysc_runtime_resume) from [<c0606cf0>] (sysc_child_runtime_resume+0x58/0x84)
      (sysc_child_runtime_resume) from [<c06eb7bc>] (__rpm_callback+0x30/0x12c)
      (__rpm_callback) from [<c06eb8d8>] (rpm_callback+0x20/0x80)
      (rpm_callback) from [<c06eb434>] (rpm_resume+0x638/0x7fc)
      (rpm_resume) from [<c06eb658>] (__pm_runtime_resume+0x60/0x9c)
      (__pm_runtime_resume) from [<c06edc08>] (handle_threaded_wake_irq+0x24/0x60)
      (handle_threaded_wake_irq) from [<c01befec>] (irq_thread_fn+0x1c/0x78)
      (irq_thread_fn) from [<c01bf30c>] (irq_thread+0x140/0x26c)
      
      We have __pm_runtime_resume() call the sysc_runtime_resume() with spinlock
      held and interrupts disabled.
      
      Fixes: d46f9fbe ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit")
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      9f911392