1. 04 4月, 2017 1 次提交
    • D
      ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer · 04abaf07
      Dave Gerlach 提交于
      Starting from commit 5de85b9d ("PM / runtime: Re-init runtime PM
      states at probe error and driver unbind") pm_runtime core now changes
      device runtime_status back to after RPM_SUSPENDED after a probe defer.
      Certain OMAP devices make use of "ti,no-idle-on-init" flag which causes
      omap_device_enable to be called during the BUS_NOTIFY_ADD_DEVICE event
      during probe, along with pm_runtime_set_active.
      
      This call to pm_runtime_set_active typically will prevent a call to
      pm_runtime_get in a driver probe function from re-enabling the
      omap_device. However, in the case of a probe defer that happens before
      the driver probe function is able to run, such as a missing pinctrl
      states defer, pm_runtime_reinit will set the device as RPM_SUSPENDED and
      then once driver probe is actually able to run, pm_runtime_get will see
      the device as suspended and call through to the omap_device layer,
      attempting to enable the already enabled omap_device and causing errors
      like this:
      
      omap-gpmc 50000000.gpmc: omap_device: omap_device_enable() called from
      invalid state 1
      omap-gpmc 50000000.gpmc: use pm_runtime_put_sync_suspend() in driver?
      
      We can avoid this error by making sure the pm_runtime status of a device
      matches the omap_device state before a probe attempt. By extending the
      omap_device bus notifier to act on the BUS_NOTIFY_BIND_DRIVER event we
      can check if a device is enabled in omap_device but with a pm_runtime
      status of RPM_SUSPENDED and once again mark the device as RPM_ACTIVE to
      avoid a second incorrect call to omap_device_enable.
      
      Fixes: 5de85b9d ("PM / runtime: Re-init runtime PM states at probe
      error and driver unbind")
      Tested-by: NFranklin S Cooper Jr. <fcooper@ti.com>
      Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      04abaf07
  2. 28 3月, 2017 1 次提交
    • T
      ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot · 351b7c49
      Tony Lindgren 提交于
      Commit 32518852 ("ARM: OMAP4+: Reset CPU1 properly for kexec") started
      unconditionally resetting CPU1 because of a kexec boot issue I was seeing
      earlier on omap4 when doing kexec boot between two different kernel
      versions.
      
      This caused issues on some systems. We should only reset CPU1 as a last
      resort option, and try to avoid it where possible. Doing an unconditional
      CPU1 reset causes issues for example when booting a bootloader configured
      secure OS running on CPU1 as reported by Andrew F. Davis <afd@ti.com>.
      
      We can't completely remove the reset of CPU1 as it would break kexec
      booting from older kernels. But we can limit the CPU1 reset to cases
      where CPU1 is wrongly parked within the memory area used by the booting
      kernel. Then later on we can add support for parking CPU1 for kexec out
      of the SDRAM back to bootrom.
      
      So let's first fix the regression reported by Andrew by making CPU1 reset
      conditional. To do this, we need to:
      
      1. Save configured AUX_CORE_BOOT_1 for later
      
      2. Modify AUX_CORE_BOOT_0 reading code to for HS SoCs to return
         the whole register instead of the CPU mask
      
      3. Check if CPU1 is wrongly parked into the booting kernel by the
         previous kernel and reset if needed
      
      Fixes: 32518852 ("ARM: OMAP4+: Reset CPU1 properly for kexec")
      Reported-by: NAndrew F. Davis <afd@ti.com>
      Cc: Andrew F. Davis <afd@ti.com>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Cc: Santosh Shilimkar <ssantosh@kernel.org>
      Cc: Tero Kristo <t-kristo@ti.com>
      Tested-by: NKeerthy <j-keerthy@ti.com>
      Tested-by: NAndrew F. Davis <afd@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      351b7c49
  3. 05 3月, 2017 2 次提交
    • G
      ARM: OMAP2+: Release device node after it is no longer needed. · b92675d9
      Guenter Roeck 提交于
      The device node returned by of_find_node_by_name() needs to be released
      after it is no longer needed to avoid a device node leak.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b92675d9
    • G
      ARM: OMAP2+: Fix device node reference counts · 10e5778f
      Guenter Roeck 提交于
      After commit 0549bde0 ("of: fix of_node leak caused in
      of_find_node_opts_by_path"), the following error may be
      reported when running omap images.
      
      OF: ERROR: Bad of_node_put() on /ocp@68000000
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc7-next-20170210 #1
      Hardware name: Generic OMAP3-GP (Flattened Device Tree)
      [<c0310604>] (unwind_backtrace) from [<c030bbf4>] (show_stack+0x10/0x14)
      [<c030bbf4>] (show_stack) from [<c05add8c>] (dump_stack+0x98/0xac)
      [<c05add8c>] (dump_stack) from [<c05af1b0>] (kobject_release+0x48/0x7c)
      [<c05af1b0>] (kobject_release)
      	from [<c0ad1aa4>] (of_find_node_by_name+0x74/0x94)
      [<c0ad1aa4>] (of_find_node_by_name)
      	from [<c1215bd4>] (omap3xxx_hwmod_is_hs_ip_block_usable+0x24/0x2c)
      [<c1215bd4>] (omap3xxx_hwmod_is_hs_ip_block_usable) from
      [<c1215d5c>] (omap3xxx_hwmod_init+0x180/0x274)
      [<c1215d5c>] (omap3xxx_hwmod_init)
      	from [<c120faa8>] (omap3_init_early+0xa0/0x11c)
      [<c120faa8>] (omap3_init_early)
      	from [<c120fb2c>] (omap3430_init_early+0x8/0x30)
      [<c120fb2c>] (omap3430_init_early)
      	from [<c1204710>] (setup_arch+0xc04/0xc34)
      [<c1204710>] (setup_arch) from [<c1200948>] (start_kernel+0x68/0x38c)
      [<c1200948>] (start_kernel) from [<8020807c>] (0x8020807c)
      
      of_find_node_by_name() drops the reference to the passed device node.
      The commit referenced above exposes this problem.
      
      To fix the problem, use of_get_child_by_name() instead of
      of_find_node_by_name(); of_get_child_by_name() does not drop
      the reference count of passed device nodes. While semantically
      different, we only look for immediate children of the passed
      device node, so of_get_child_by_name() is a more appropriate
      function to use anyway.
      
      Release the reference to the device node obtained with
      of_get_child_by_name() after it is no longer needed to avoid
      another device node leak.
      
      While at it, clean up the code and change the return type of
      omap3xxx_hwmod_is_hs_ip_block_usable() to bool to match its use
      and the return type of of_device_is_available().
      
      Cc: Qi Hou <qi.hou@windriver.com>
      Cc: Peter Rosin <peda@axentia.se>
      Cc: Rob Herring <robh@kernel.org>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      10e5778f
  4. 02 3月, 2017 1 次提交
  5. 01 3月, 2017 2 次提交
  6. 28 2月, 2017 2 次提交
  7. 17 2月, 2017 1 次提交
  8. 15 2月, 2017 1 次提交
    • T
      ARM: OMAP3: Fix smartreflex platform data regression · 17912508
      Tony Lindgren 提交于
      Commit d9d9cec0 ("ARM: OMAP2+: Remove legacy data from hwmod for
      omap3") dropped platform data that should no longer be used as we're
      booting with device tree. It turns out that smartreflex is still
      using platform data and produces the following errors during probe:
      
      smartreflex smartreflex.0: invalid resource
      smartreflex smartreflex.0: omap_sr_probe: ioremap fail
      smartreflex: probe of smartreflex.0 failed with error -22
      smartreflex smartreflex.1: invalid resource
      smartreflex smartreflex.1: omap_sr_probe: ioremap fail
      smartreflex: probe of smartreflex.1 failed with error -22
      
      Let's fix the regression by adding back the smartreflex hwmod data.
      The long term is to update the smartreflex driver to use device tree
      based probing.
      
      Fixes: d9d9cec0 ("ARM: OMAP2+: Remove legacy data from hwmod
      for omap3")
      Reported-by: NAdam Ford <aford173@gmail.com>
      Tested-by: NAdam Ford <aford173@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      17912508
  9. 31 1月, 2017 2 次提交
  10. 30 1月, 2017 1 次提交
    • V
      PM / OPP: Update OPP users to put reference · 8a31d9d9
      Viresh Kumar 提交于
      This patch updates dev_pm_opp_find_freq_*() routines to get a reference
      to the OPPs returned by them.
      
      Also updates the users of dev_pm_opp_find_freq_*() routines to call
      dev_pm_opp_put() after they are done using the OPPs.
      
      As it is guaranteed the that OPPs wouldn't get freed while being used,
      the RCU read side locking present with the users isn't required anymore.
      Drop it as well.
      
      This patch also updates all users of devfreq_recommended_opp() which was
      returning an OPP received from the OPP core.
      
      Note that some of the OPP core routines have gained
      rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs
      within them.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> [Devfreq]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a31d9d9
  11. 24 1月, 2017 1 次提交
  12. 21 1月, 2017 3 次提交
  13. 07 1月, 2017 1 次提交
  14. 06 1月, 2017 3 次提交
  15. 28 12月, 2016 3 次提交
  16. 25 12月, 2016 1 次提交
  17. 24 11月, 2016 1 次提交
  18. 11 11月, 2016 12 次提交
  19. 10 11月, 2016 1 次提交