“476e9c90e8e8c3a10e0a4713dc7e230fa14166ed”上不存在“data/2.算法中阶/6.leetcode-双指针/15.最接近的三数之和/solution.md”
  1. 19 4月, 2012 3 次提交
    • P
      ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bits · 515237d6
      Paul Walmsley 提交于
      Extend the OCP_* register offsets in the struct
      omap_hwmod_class_sysconfig to 32 bits.  This is required to add the
      OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16
      bits.
      
      Another possible solution may be to simply add a single 16 bit offset
      field in this structure, and to add code to factor that offset into
      all OCP_* register accesses.  This would save some memory, since
      almost no modules need 32 bit offsets.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      515237d6
    • P
      ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriately · 3d10f0d6
      Paul Walmsley 提交于
      One of the OMAP4 links was missing OCP_USER flags, since it was only
      used by the DSP initiator, and we did not have an OCP_USER_DSP flag.
      Future patches will switch the hwmod code and data to register
      interfaces, rather than hwmods, and it will be mandatory for all
      interfaces to have at least one user bit set.  This patch resolves the
      issue by adding OCP_USER_DSP and marking the DSP-IVA interface
      appropriately.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      
      
      3d10f0d6
    • P
      ARM: OMAP2+: hwmod: add omap_hwmod_get_resource_byname() · 5e8370f1
      Paul Walmsley 提交于
      The timer integration code pokes around in hwmod data structures.
      Those data structures are about to change.  Define a function,
      omap_hwmod_get_resource_byname(), for the timer integration code to
      use instead.
      
      The original patch has been changed to use struct resource by Tony's
      request, although the caller of this function should not be a driver._
      Platform drivers should get their data through the regular platform_*
      functions; DT drivers through the appropriate of_* functions.  This a
      function is only for use by OMAP core code in arch/arm/*omap*.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      5e8370f1
  2. 13 4月, 2012 1 次提交
    • F
      ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data · d99de7f5
      Fernando Guzman Lugo 提交于
      Due to HW limitation, some IPs should not be accessed just after a
      softreset. Since the current hwmod sequence is accessing the sysconfig
      register just after the reset, it might lead to OCP bus error in
      that case.
      
      Add a new field in the sysconfig structure to specify a delay in usecs
      needed after doing a softreset.
      
      In the case of the ISS and FDIF modules, the L3 OCP port will be
      disconnected upon a SW reset. That issue was confirmed with HW simulation
      and an errata should be available soon. The HW recommendation to avoid
      that is to wait for 100 OCP clk cycles, before accessing the IP.
      
      Considering the worse case (OPP50), the L3 bus will run at 100 MHz,
      so a 1 usec delay is needed. Add an x2 margin to be safe.
      Acked-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
      [paul@pwsan.com: dropped FDIF change for now since the hwmod data is not
       yet upstream; the FDIF change will need to be added later once the FDIF
       data is merged]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d99de7f5
  3. 05 4月, 2012 1 次提交
  4. 29 3月, 2012 1 次提交
  5. 28 3月, 2012 1 次提交
  6. 17 3月, 2012 1 次提交
  7. 14 3月, 2012 1 次提交
  8. 12 3月, 2012 5 次提交
  9. 07 3月, 2012 1 次提交
  10. 06 3月, 2012 7 次提交
  11. 29 2月, 2012 1 次提交
    • C
      ARM: OMAP: irqs: Fix NR_IRQS value to handle PRCM interrupts · 5a3ff847
      Cousson, Benoit 提交于
      The following commit: 2f31b516
      Author: Tero Kristo <t-kristo@ti.com>
      Date:   Fri Dec 16 14:37:00 2011 -0700
      
          ARM: OMAP4: PRM: use PRCM interrupt handler
      
      introduced the PRCM interrupt handler and thus the need
      for 64 more interrupts. Since SPARSE_IRQ is still not fully
      functional on OMAP, the NR_IRQS needs to be updated to avoid
      the failure that happen during irq_alloc_descs call inside
      the PRCM driver:
      
      [    0.208221] PRCM: failed to allocate irq descs: -12
      
      Later the mux framework is then unable to request an IRQ from
      the PRCM interrupt handler.
      
      [    1.802795] mux: Failed to setup hwmod io irq -22
      
      Fix that by adding 64 more interrupts for OMAP2PLUS config.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      5a3ff847
  12. 25 2月, 2012 7 次提交
  13. 23 2月, 2012 3 次提交
  14. 22 2月, 2012 2 次提交
  15. 21 2月, 2012 1 次提交
    • O
      ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register} · 993e4fbd
      Ohad Ben-Cohen 提交于
      Expose omap_device_{alloc, delete, register} so we can use them outside
      of omap_device.c.
      
      This approach allows users, which need to manipulate an archdata member
      of a device before it is registered, to do so. This is also useful
      for users who have their devices created very early so they can be used
      at ->reserve() time to reserve CMA memory.
      
      The immediate use case for this is to set the private iommu archdata
      member, which binds a device to its associated iommu controller.
      This way, generic code will be able to attach omap devices to their
      iommus, without calling any omap-specific API.
      
      With this in hand, we can further clean the existing mainline OMAP iommu
      driver and its mainline users, and focus on generic IOMMU approaches
      for future users (rpmsg/remoteproc and the upcoming generic DMA API).
      
      This patch is still considered an interim solution until DT fully materializes
      for omap; at that point, this functionality will be removed as DT will
      take care of creating the devices and configuring them correctly.
      
      Tested on OMAP4 with a generic rpmsg/remoteproc that doesn't use any
      omap-specific IOMMU API anymore.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      993e4fbd
  16. 15 2月, 2012 1 次提交
  17. 09 2月, 2012 1 次提交
    • O
      remoteproc/omap: add a remoteproc driver for OMAP4 · 34ed5a33
      Ohad Ben-Cohen 提交于
      Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and
      and DSP subsystems.
      
      Use the omap_device_* API to control the hardware state, and utilize
      the OMAP mailbox to interrupt the remote processor when a new message
      is pending (the mailbox payload is used to tell it which virtqueue was
      the message placed in).
      
      Conversely, when an inbound mailbox message arrives, tell the remoteproc
      core which virtqueue is triggered.
      
      Later we will also use the mailbox payload to signal omap-specific
      events like remote crashes (which will be used to trigger remoteproc
      recovery) and power management transitions. At that point we will also
      extend the remoteproc core to support this.
      
      Based on (but now quite far from) work done by Fernando Guzman Lugo
      <fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      34ed5a33
  18. 08 2月, 2012 1 次提交
    • S
      ARM: OMAP2: Fix the OMAP2 only build break seen with 2011+ ARM tool-chains · fef67c51
      Santosh Shilimkar 提交于
      With the latest Sourcery G++ Lite 2011.03-41 and latest linaro
      tool-chains OMAP2 only build breaks with below error.
      
      arch/arm/mach-omap2/omap-smc.S: Assembler messages:
      arch/arm/mach-omap2/omap-smc.S:30: Error: selected processor does not support ARM mode `smc #0'
      arch/arm/mach-omap2/omap-smc.S:53: Error: selected processor does not support ARM mode `smc #0'
      arch/arm/mach-omap2/omap-smc.S:61: Error: selected processor does not support ARM mode `smc #0'
      arch/arm/mach-omap2/omap-smc.S:69: Error: selected processor does not support ARM mode `smc #0'
      arch/arm/mach-omap2/omap-smc.S:77: Error: selected processor does not support ARM mode `smc #0'
      make[1]: *** [arch/arm/mach-omap2/omap-smc.o] Error 1
      
      OMAP2 devices doesn't have the security support but the security support
      was getting built because of OMAP2PLUS. Don't build security code for
      OMAP2 devices.
      
      While at it, fix the secure-common line in the Makefile to use tabs
      instead of spaces.
      Reported-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      fef67c51
  19. 06 2月, 2012 1 次提交