1. 23 7月, 2016 1 次提交
    • D
      ARM: OMAP4+: Have _omap4_wait_target_* check for valid clkctrl_offs · 428929c7
      Dave Gerlach 提交于
      Previously the low-level CM call internal to the
      _omap4_wait_target_ready/disable calls was responsible for checking for
      a valid clkctrl_offs. Now we must also consider the value of the
      prcm.omap4.flags because if HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET is set in
      the flags then clkctrl_offs of 0 is valid.
      
      Let's add this check into the _omap4_wait_target_ready/disable where we
      have access to both the clkctrl_offs and the flags values and simply
      return 0 without calling the low level CM call at all, which would have
      returned 0 anyway if the clktrl_offs was zero.
      Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
      Acked-by: NTero Kristo <t-kristo@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      428929c7
  2. 04 7月, 2016 2 次提交
  3. 11 4月, 2016 1 次提交
    • S
      ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence · c20c8f75
      Suman Anna 提交于
      The omap_hwmod _enable() function can return success without setting
      the hwmod state to _HWMOD_STATE_ENABLED for IPs with reset lines when
      all of the reset lines are asserted. The omap_hwmod _idle() function
      also performs a similar check, but after checking for the hwmod state
      first. This triggers the WARN when pm_runtime_get and pm_runtime_put
      are invoked on IPs with all reset lines asserted. Reverse the checks
      for hwmod state and reset lines status to fix this.
      
      Issue found during a unbind operation on a device with reset lines
      still asserted, example backtrace below
      
       ------------[ cut here ]------------
       WARNING: CPU: 1 PID: 879 at arch/arm/mach-omap2/omap_hwmod.c:2207 _idle+0x1e4/0x240()
       omap_hwmod: mmu_dsp: idle state can only be entered from enabled state
       Modules linked in:
       CPU: 1 PID: 879 Comm: sh Not tainted 4.4.0-00008-ga989d951331a #3
       Hardware name: Generic OMAP5 (Flattened Device Tree)
       [<c0018e60>] (unwind_backtrace) from [<c0014dc4>] (show_stack+0x10/0x14)
       [<c0014dc4>] (show_stack) from [<c037ac28>] (dump_stack+0x90/0xc0)
       [<c037ac28>] (dump_stack) from [<c003f420>] (warn_slowpath_common+0x78/0xb4)
       [<c003f420>] (warn_slowpath_common) from [<c003f48c>] (warn_slowpath_fmt+0x30/0x40)
       [<c003f48c>] (warn_slowpath_fmt) from [<c0028c20>] (_idle+0x1e4/0x240)
       [<c0028c20>] (_idle) from [<c0029080>] (omap_hwmod_idle+0x28/0x48)
       [<c0029080>] (omap_hwmod_idle) from [<c002a5a4>] (omap_device_idle+0x3c/0x90)
       [<c002a5a4>] (omap_device_idle) from [<c0427a90>] (__rpm_callback+0x2c/0x60)
       [<c0427a90>] (__rpm_callback) from [<c0427ae4>] (rpm_callback+0x20/0x80)
       [<c0427ae4>] (rpm_callback) from [<c0427f84>] (rpm_suspend+0x138/0x74c)
       [<c0427f84>] (rpm_suspend) from [<c0428b78>] (__pm_runtime_idle+0x78/0xa8)
       [<c0428b78>] (__pm_runtime_idle) from [<c041f514>] (__device_release_driver+0x64/0x100)
       [<c041f514>] (__device_release_driver) from [<c041f5d0>] (device_release_driver+0x20/0x2c)
       [<c041f5d0>] (device_release_driver) from [<c041d85c>] (unbind_store+0x78/0xf8)
       [<c041d85c>] (unbind_store) from [<c0206df8>] (kernfs_fop_write+0xc0/0x1c4)
       [<c0206df8>] (kernfs_fop_write) from [<c018a120>] (__vfs_write+0x20/0xdc)
       [<c018a120>] (__vfs_write) from [<c018a9cc>] (vfs_write+0x90/0x164)
       [<c018a9cc>] (vfs_write) from [<c018b1f0>] (SyS_write+0x44/0x9c)
       [<c018b1f0>] (SyS_write) from [<c0010420>] (ret_fast_syscall+0x0/0x1c)
       ---[ end trace a4182013c75a9f50 ]---
      
      While at this, fix the sequence in _shutdown() as well, though there
      is no easy reproducible scenario.
      
      Fixes: 747834ab ("ARM: OMAP2+: hwmod: revise hardreset behavior")
      Signed-off-by: NSuman Anna <s-anna@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c20c8f75
  4. 27 3月, 2016 1 次提交
    • L
      ARM: OMAP2+: hwmod: Fix updating of sysconfig register · 3ca4a238
      Lokesh Vutla 提交于
      Commit 127500cc ("ARM: OMAP2+: Only write the sysconfig on idle
      when necessary") talks about verification of sysconfig cache value before
      updating it, only during idle path. But the patch is adding the
      verification in the enable path. So, adding the check in a proper place
      as per the commit description.
      
      Not keeping this check during enable path as there is a chance of losing
      context and it is safe to do on idle as the context of the register will
      never be lost while the device is active.
      Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
      Acked-by: NTero Kristo <t-kristo@ti.com>
      Cc: Jon Hunter <jonathanh@nvidia.com>
      Cc: <stable@vger.kernel.org> # 3.12+
      Fixes: commit 127500cc "ARM: OMAP2+: Only write the sysconfig on idle when necessary"
      [paul@pwsan.com: appears to have been caused by my own mismerge of the
       originally posted patch]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3ca4a238
  5. 07 3月, 2016 1 次提交
  6. 04 12月, 2015 1 次提交
    • T
      ARM: OMAP2+: Change core_initcall levels to postcore_initcall · 8dd5ea72
      Tony Lindgren 提交于
      We want to be able to probe a few selected device drivers before hwmod
      code populates the clocks in omap_hwmod_setup_all(). This allows us to
      convert most of the clock drivers into regular device drivers.
      
      We only need a few minimal clock drivers early for the system timers to
      select between the 32KiHz clock and the high frequency oscillator.
      
      With these changes, initializing the clock drivers can be just done at
      core_initcall time with something like:
      
      np = of_find_node_by_name(NULL, "plls");
      if (np)
      	of_platform_populate(np, NULL, NULL, NULL);
      
      And then these clocks will be available for the interconnect code to use.
      
      Having most of the clock drivers being regular device drivers allows
      us to use the nice things like devm_* functions and dev_err and dev_dbg.
      As an extra bonus, this also allows us to develop the clock drivers for
      new SoCs as loadable modules initially for cases where we can boot up
      the system based on the bootloader configured clocks.
      
      To do this, let's change the core_initcalls to postcore_initcall under
      mach-omap2.
      
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      8dd5ea72
  7. 13 11月, 2015 1 次提交
  8. 24 7月, 2015 1 次提交
  9. 23 7月, 2015 1 次提交
    • R
      ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc · 9a258afa
      Roger Quadros 提交于
      For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so
      _find_mpu_rt_port(oh) will return NULL thus preventing ready state check
      on those modules after the module is enabled.
      
      This can potentially cause a bus access error if the module is accessed
      before the module is ready.
      
      Fix this by unconditionally calling _init_mpu_rt_base() during hwmod
      _init(). Do ioremap only if we need SYSC access.
      
      Eventhough _wait_target_ready() check doesn't really need MPU RT port but
      just the PRCM registers, we still mandate that the hwmod must have an
      MPU RT port if ready state check needs to be done. Else it would mean that
      the module is not accessible by MPU so there is no point in waiting
      for target to be ready.
      
      e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.
      
      [   16.672978] ------------[ cut here ]------------
      [   16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x234/0x35c()
      [   16.687946] 44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read): Data Access in User mode during Functional access
      [   16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts c_can dc
      [   16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 3.14.26-02561-gf733aa036398 #180
      [   16.739747] Backtrace:
      [   16.742336] [<c0011108>] (dump_backtrace) from [<c00112a4>] (show_stack+0x18/0x1c)
      [   16.750285]  r6:00000093 r5:00000009 r4:eab5b8a8 r3:00000000
      [   16.756252] [<c001128c>] (show_stack) from [<c05a4418>] (dump_stack+0x20/0x28)
      [   16.763870] [<c05a43f8>] (dump_stack) from [<c0037120>] (warn_slowpath_common+0x6c/0x8c)
      [   16.772408] [<c00370b4>] (warn_slowpath_common) from [<c00371e4>] (warn_slowpath_fmt+0x38/0x40)
      [   16.781550]  r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
      [   16.788626] [<c00371b0>] (warn_slowpath_fmt) from [<c027fa94>] (l3_interrupt_handler+0x234/0x35c)
      [   16.797968]  r3:ed0cd480 r2:c0730508
      [   16.801747] [<c027f860>] (l3_interrupt_handler) from [<c0063758>] (handle_irq_event_percpu+0x54/0x1bc)
      [   16.811533]  r10:ed005600 r9:c084855b r8:0000002a r7:00000000 r6:00000000 r5:0000002a
      [   16.819780]  r4:ed0e6d80
      [   16.822453] [<c0063704>] (handle_irq_event_percpu) from [<c00638f0>] (handle_irq_event+0x30/0x40)
      [   16.831789]  r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6:00000000 r5:0000002a
      [   16.840052]  r4:ed005600
      [   16.842744] [<c00638c0>] (handle_irq_event) from [<c00661d8>] (handle_fasteoi_irq+0x74/0x128)
      [   16.851702]  r4:ed005600 r3:00000000
      [   16.855479] [<c0066164>] (handle_fasteoi_irq) from [<c0063068>] (generic_handle_irq+0x28/0x38)
      [   16.864523]  r4:0000002a r3:c0066164
      [   16.868294] [<c0063040>] (generic_handle_irq) from [<c000ef60>] (handle_IRQ+0x38/0x8c)
      [   16.876612]  r4:c081c640 r3:00000202
      [   16.880380] [<c000ef28>] (handle_IRQ) from [<c00084f0>] (gic_handle_irq+0x30/0x5c)
      [   16.888328]  r6:eab5ba38 r5:c0804460 r4:fa24010c r3:00000100
      [   16.894303] [<c00084c0>] (gic_handle_irq) from [<c05a8d80>] (__irq_svc+0x40/0x50)
      [   16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80)
      [   16.907499] ba20:                                                       00000000 00000006
      [   16.916108] ba40: fa1d0000 fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 bf011420 eb2b6960
      [   16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 600f0013 ffffffff
      [   16.933317]  r7:eab5ba6c r6:ffffffff r5:600f0013 r4:bf07702c
      [   16.939317] [<bf077000>] (c_can_plat_read_reg_aligned_to_16bit [c_can_platform]) from [<bf035220>] (c_can_get_berr_counter+0x38/0x64 [c_can])
      [   16.952696] [<bf0351e8>] (c_can_get_berr_counter [c_can]) from [<bf010294>] (can_fill_info+0x124/0x15c [can_dev])
      [   16.963480]  r5:ec8c9740 r4:ed3d3000
      [   16.967253] [<bf010170>] (can_fill_info [can_dev]) from [<c0502fa8>] (rtnl_fill_ifinfo+0x58c/0x8fc)
      [   16.976749]  r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
      [   16.981613] [<c0502a1c>] (rtnl_fill_ifinfo) from [<c0503408>] (rtnl_dump_ifinfo+0xf0/0x1dc)
      [   16.990401]  r10:ec8c9740 r9:00000000 r8:00000000 r7:00000000 r6:ebd4d1b4 r5:ed3d3000
      [   16.998671]  r4:00000000
      [   17.001342] [<c0503318>] (rtnl_dump_ifinfo) from [<c050e6e4>] (netlink_dump+0xa8/0x1e0)
      [   17.009772]  r10:00000000 r9:00000000 r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 r5:ec8c9740
      [   17.018050]  r4:ebd4d000
      [   17.020714] [<c050e63c>] (netlink_dump) from [<c050ec10>] (__netlink_dump_start+0x104/0x154)
      [   17.029591]  r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
      [   17.034454] [<c050eb0c>] (__netlink_dump_start) from [<c0505604>] (rtnetlink_rcv_msg+0x110/0x1f4)
      [   17.043778]  r7:00000000 r6:ec8c9980 r5:00000f40 r4:ebf3e6c0
      [   17.049743] [<c05054f4>] (rtnetlink_rcv_msg) from [<c05108e8>] (netlink_rcv_skb+0xb4/0xc8)
      [   17.058449]  r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0
      [   17.065534] [<c0510834>] (netlink_rcv_skb) from [<c0504134>] (rtnetlink_rcv+0x24/0x2c)
      [   17.073854]  r6:ebd4d000 r5:00000014 r4:ec8c9980 r3:c0504110
      [   17.079846] [<c0504110>] (rtnetlink_rcv) from [<c05102ac>] (netlink_unicast+0x180/0x1ec)
      [   17.088363]  r4:ed0c6800 r3:c0504110
      [   17.092113] [<c051012c>] (netlink_unicast) from [<c0510670>] (netlink_sendmsg+0x2ac/0x380)
      [   17.100813]  r10:00000000 r8:00000008 r7:ec8c9980 r6:ebd4d000 r5:eab5be70 r4:eab5bee4
      [   17.109083] [<c05103c4>] (netlink_sendmsg) from [<c04dfdb4>] (sock_sendmsg+0x90/0xb0)
      [   17.117305]  r10:00000000 r9:eab5a000 r8:becdda3c r7:0000000c r6:ea978400 r5:eab5be70
      [   17.125563]  r4:c05103c4
      [   17.128225] [<c04dfd24>] (sock_sendmsg) from [<c04e1c28>] (SyS_sendto+0xb8/0xdc)
      [   17.136001]  r6:becdda5c r5:00000014 r4:ecd37040
      [   17.140876] [<c04e1b70>] (SyS_sendto) from [<c000e680>] (ret_fast_syscall+0x0/0x30)
      [   17.148923]  r10:00000000 r8:c000e804 r7:00000122 r6:becdda5c r5:0000000c r4:becdda5c
      [   17.157169] ---[ end trace 2b71e15b38f58bad ]---
      
      Fixes: 6423d6df ("ARM: OMAP2+: hwmod: check for module address space during init")
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: <stable@vger.kernel.org>
      9a258afa
  10. 21 7月, 2015 1 次提交
  11. 16 7月, 2015 1 次提交
  12. 02 6月, 2015 1 次提交
  13. 09 5月, 2015 2 次提交
  14. 02 3月, 2015 1 次提交
  15. 26 2月, 2015 1 次提交
  16. 27 1月, 2015 1 次提交
  17. 21 1月, 2015 1 次提交
  18. 18 1月, 2015 1 次提交
    • M
      ARM: OMAP: Work around hardcoded interrupts · 0fb22a8f
      Marc Zyngier 提交于
      Commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain")
      changed the GIC driver to use a non-legacy IRQ domain on DT
      platforms. This patch assumes that DT-driven systems are getting
      all of their interrupts from device tree.
      
      Turns out that OMAP has quite a few hidden gems, and still uses
      hardcoded interrupts despite having fairly complete DTs.
      
      This patch attempts to work around these by offering a translation
      method that can be called directly from the hwmod code, if present.
      The same hack is sprinkled over PRCM and TWL.
      
      It isn't pretty, but it seems to do the job without having to add
      more hacks to the interrupt controller code.
      
      Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: NNishanth Menon <nm@ti.com>
      [tony@atomide.com: updated to fix make randconfig issue]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      0fb22a8f
  19. 08 1月, 2015 1 次提交
  20. 20 11月, 2014 1 次提交
  21. 14 11月, 2014 1 次提交
    • F
      ARM: OMAP2+: hwmod: drop unnecessary list initialization · 79005fbd
      Felipe Balbi 提交于
      ml->node and sl->node are currently initialized
      by means of INIT_LIST_HEAD(). That initialiation
      is followed by a list_add() call.
      
      Looking at what both these functions do we will have:
      
      	ml->node.next = &ml->node;
      	ml->node.prev = &ml->node;
      	oi->master->master_ports.next.prev = &ml->node;
      	ml->node.next = &oi->master->master_ports.next;
      	ml->node.prev = &oi->master->master_ports;
      	oi->master->master_ports.next = &ml->node;
      
      from this, it's clear that both INIT_LIST_HEAD() calls
      are unnecessary and can be safely removed.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      79005fbd
  22. 27 10月, 2014 12 次提交
  23. 19 9月, 2014 1 次提交
  24. 18 9月, 2014 1 次提交
  25. 17 9月, 2014 1 次提交
    • T
      ARM: OMAP3: Fix I/O chain clock line assertion timed out error · 7db143b8
      Tony Lindgren 提交于
      We are getting "PRM: I/O chain clock line assertion timed out" errors
      on early omaps for device tree based booting. This is because we are
      unconditionally calling reconfigure_io_chain while legacy booting
      has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c.
      
      For device tree based booting, we are calling reconfigure_io_chain
      unconditionally from pinctrl framework. So we need to add a check for
      omap3_has_io_chain_ctrl() to avoid the errors for trying to access
      a register that does not exist.
      
      For es3.0, the documentation in "4.11.2 Device Off-Mode Configuration"
      just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in
      documentation for "4.11.2.2 I/O Wake-Up Mechanism" that describes the
      PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get
      added until in es3.1 probaly to fix issues with flakey wake-up events.
      
      We are doing proper checks for ST_IO_CHAIN already in id.c and with
      omap3_has_io_chain_ctrl(). For more information, see also commit
      b02b9172 ("ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock
      control detection").
      
      Let's fix the issue by selecting the right function during init for
      reconfigure_io_chain depending on the omap revision. For es3.0 and
      earlier we need to just toggle EN_IO. By doing this, we can move the
      check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code
      in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain.
      
      Thanks to Paul Walmsley and Nishanth Menon for help with debugging the
      issue.
      
      Fixes: 30a69ef7 ("ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap")
      Cc: Kevin Hilman <khilman@kernel.org>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Reviewed-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7db143b8
  26. 28 8月, 2014 1 次提交
  27. 26 8月, 2014 1 次提交
    • T
      ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled · cc824534
      Tony Lindgren 提交于
      Looks like MUSB cable removal can cause wake-up interrupts to
      stop working for device tree based booting at least for UART3
      even as nothing is dynamically remuxed. This can be fixed by
      calling reconfigure_io_chain() for device tree based booting
      in hwmod code. Note that we already do that for legacy booting
      if the legacy mux is configured.
      
      My guess is that this is related to UART3 and MUSB ULPI
      hsusb0_data0 and hsusb0_data1 support for Carkit mode that
      somehow affect the configured IO chain for UART3 and require
      rearming the wake-up interrupts.
      
      In general, for device tree based booting, pinctrl-single
      calls the rearm hook that in turn calls reconfigure_io_chain
      so calling reconfigure_io_chain should not be needed from the
      hwmod code for other events.
      
      So let's limit the hwmod rearming of iochain only to
      HWMOD_FORCE_MSTANDBY where MUSB is currently the only user
      of it. If we see other devices needing similar changes we can
      add more checks for it.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: stable@vger.kernel.org # v3.16
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      cc824534