1. 20 4月, 2012 1 次提交
  2. 19 4月, 2012 5 次提交
    • P
      ARM: OMAP: hwmod: remove code support for direct hwmod registration · 11cd4b94
      Paul Walmsley 提交于
      Now that the data has been converted to use interface registration, we
      can remove the (now unused) direct hwmod registration code.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      11cd4b94
    • P
      ARM: OMAP2+: hwmod: add support for link registration · 2221b5cd
      Paul Walmsley 提交于
      Add support for direct IP block interconnect ("link") registration to
      the hwmod code via a new function, omap_hwmod_register_links().  This
      will replace direct registration of hwmods, and a subsequent patch
      will remove omap_hwmod_register().
      
      This change will allow a subsequent patch to remove the hwmod data
      link arrays.  This will reduce the size of the hwmod static data and
      also make it easier to generate the data files.  It will also make it
      possible to share some of the struct omap_hwmod records across
      multiple SoCs, since the link array pointers will be removed from the
      struct omap_hwmod.
      
      The downside is that boot time will increase.  Minimizing boot time
      was the reason why the link arrays were originally introduced.
      Removing them will require extra computation during boot to allocate
      memory and associate IP blocks with their interconnects.  However,
      since the current kernel development focus is on reducing the number
      of lines in arch/arm/mach-omap2/, boot time impact is now seemingly
      considered a lower priority.
      
      This patch contains additional complexity to reduce the number of
      memory allocations required for this change.  This reduces the boot
      time impact: total hwmod link registration time was ~ 2655
      microseconds with a simple allocation strategy, but is now ~ 549
      microseconds[1] with the approach taken by this patch.
      
      1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average
         of 7 samples.  Total uncertainty is +/- 61 microseconds.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      2221b5cd
    • 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
  3. 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
  4. 06 4月, 2012 1 次提交
    • R
      ARM: fix __io macro for PCMCIA · 1ac02d79
      Rob Herring 提交于
      With commit c334bc15 (ARM: make mach/io.h include optional), PCMCIA was
      broken. PCMCIA depends on __io() returning a valid i/o address, and most
      ARM platforms require IO_SPACE_LIMIT be set to 0xffffffff for PCMCIA. This
      needs a better fix with a fixed i/o address mapping, but for now we just
      restore things to the previous behavior.
      
      This fixes at91, omap1, pxa and sa11xx. pxa needs io.h if PCI is enabled,
      but PCMCIA is not. sa11xx already has IO_SPACE_LIMIT set to 0xffffffff,
      so it doesn't need an io.h.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Cc: Joachim Eastwood <joachim.eastwood@jotron.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Andrew Victor <linux@maxim.org.za>
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Tested-by: Paul Parsons <lost.distance@yahoo.com> (pxa270)
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      1ac02d79
  5. 05 4月, 2012 1 次提交
  6. 04 4月, 2012 1 次提交
    • N
      ARM: OMAP: clock: fix race in disable all clocks · 0eb4fd9b
      Nishanth Menon 提交于
      clk_disable_unused is invoked when CONFIG_OMAP_RESET_CLOCKS=y.
      Since clk_disable_unused is called as lateinitcall, there can
      be more than a few workqueues executing off secondary CPU(s).
      The current code does the following:
      a) checks if clk is unused
      b) holds lock
      c) disables clk
      d) unlocks
      
      Between (a) and (b) being executed on CPU0, It is possible to
      have a driver executing on CPU1 which could do a get_sync->clk_get
      (and increase the use_count) of the clock which was just about
      to be disabled by clk_disable_unused.
      
      We ensure instead that the entire list traversal is protected by
      the lock allowing for parent child clock traversal which could be
      potentially be done by runtime operations to be safe as well.
      Reported-by: NTodd Poynor <toddpoynor@google.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0eb4fd9b
  7. 29 3月, 2012 2 次提交
  8. 28 3月, 2012 1 次提交
  9. 17 3月, 2012 1 次提交
  10. 14 3月, 2012 1 次提交
  11. 12 3月, 2012 6 次提交
  12. 09 3月, 2012 1 次提交
  13. 07 3月, 2012 1 次提交
  14. 06 3月, 2012 11 次提交
    • F
      ARM: OMAP: mailbox: trivial whitespace fix · 44c568a8
      Felipe Contreras 提交于
      Trivial whitespace fix
      Signed-off-by: NFelipe Contreras <felipe.contreras@nokia.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      44c568a8
    • J
      ARM: OMAP: Remove definition cpu_is_omap4430() · a90180d1
      Jon Hunter 提交于
      The definition cpu_is_omap4430() always returns 0 even when CONFIG_ARCH_OMAP4
      is enabled. This macro should be removed and the macro cpu_is_omap443x() should
      be used where needed for OMAP4430 devices.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a90180d1
    • D
      ARM: OMAP: clock.c: included linux/debugfs.h twice · 7bb83085
      Danny Kukawka 提交于
      arch/arm/plat-omap/clock.c: included 'linux/debugfs.h' twice,
      remove the duplicate.
      Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7bb83085
    • V
      ARM: OMAP: sram: Add am33xx SRAM support (minimal) · b4c0a8a7
      Vaibhav Bedia 提交于
      Update SRAM start & size for am33xx SoC's.
      
      Note: cpu_is_34xx() is true for am33xx also. Doing
      cpu_is_am33xx() check after cpu_is_34xx() will not
      achieve what we want due to the above reason.
      Hence cpu_is_am33xx() is done before cpu_is_34xx()
      Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b4c0a8a7
    • T
      ARM: OMAP: dmtimer: fix missing content/correction in low-power mode support · dffc9dae
      Tarun Kanti DebBarma 提交于
      Since omap_dm_timer_write_reg/__omap_dm_timer_write is now modified
      to use timer->func_base OCP_CFG should not use this wrapper anymore.
      Instead use __raw_writel() directly and use timer->io_base instead
      to write to OCP_CFG.
      
      The timer->sys_stat is valid only if timer->revision is 1. In the
      context restore function make this correction.
      
      Save the contexts and loss count when timer is stopped.
      Also, disable the clock. Else, clock usecount would become imbalanced.
      Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Tested-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dffc9dae
    • P
      ARM: OMAP2+: omap_device: call all suspend, resume callbacks when... · b7c39a3f
      Paul Walmsley 提交于
      ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set
      
      During system suspend, when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set on
      an omap_device, call the corresponding driver's ->suspend() and
      ->suspend_noirq() callbacks (if present).  Similarly, during resume,
      the driver's ->resume() and ->resume_noirq() callbacks must both be
      called, if present.  (The previous code only called ->suspend_noirq()
      and ->resume_noirq().)
      
      If all of these callbacks aren't called, some important driver
      suspend/resume code may not get executed.
      
      In current mainline, the bug fixed by this patch is only a problem
      under the following conditions:
      
      - the kernel is running on an OMAP4
      
      - an OMAP UART is used as a console
      
      - the kernel command line parameter 'no_console_suspend' is specified
      
      - and the system enters suspend ("echo mem > /sys/power/state").
      
      Under this combined circumstance, the system cannot be awakened via
      the serial port after commit be4b0281c
      ("tty: serial: OMAP: block idle while the UART is transferring data in
      PIO mode").  This is because the OMAP UART driver's ->suspend()
      callback is never called.  The ->suspend() callback would have called
      uart_suspend_port() which in turn would call enable_irq_wake().  Since
      enable_irq_wake() isn't called for the UART's IRQ, check_wakeup_irqs()
      would mask off the UART IRQ in the GIC.
      
      On v3.3 kernels prior to the above commit, serial resume from suspend
      presumably occurred via the PRCM interrupt.  The UART was in
      smart-idle mode, so it was able to send a PRCM wakeup which in turn
      would be converted into a PRCM interrupt to the GIC, waking up the
      kernel.  But after the above commit, when the system is suspended in
      the middle of a UART transmit, the UART IP block would be in no-idle
      mode.  In no-idle mode, the UART won't generate wakeups to the PRCM
      when incoming characters are received; only GIC interrupts.  But since
      the UART driver's ->suspend() callback is never called,
      uart_suspend_port() and enable_irq_wake() is never called; so the UART
      interrupt is masked by check_wakeup_irqs() and the UART can't wake up
      the MPU.
      
      The remaining mechanism that could have awakened the system would have
      been I/O chain wakeups.  These wouldn't be active because the console
      UART's clocks are never disabled when no_console_suspend is used,
      preventing the full chip from idling.  Also, current mainline doesn't
      yet support full chip idle states for OMAP4, so I/O chain wakeups are
      not enabled.
      
      This patch is the result of a collaboration.  John Stultz
      <johnstul@us.ibm.com> and Andy Green <andy.green@linaro.org> reported
      the serial wakeup problem that led to the discovery of this problem.
      Kevin Hilman <khilman@ti.com> narrowed the problem down to the use of
      no_console_suspend.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Andy Green <andy.green@linaro.org>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      b7c39a3f
    • K
      ARM: OMAP: omap_device: remove omap_device_parent · 3ec2decb
      Kevin Hilman 提交于
      Currently all omap_devices are forced to have the dummy device
      'omap_device_parent' as a parent.  This was used to distinguish
      omap_devices from "normal" platform_devices in the OMAP PM core code.
      
      Now that we implement the PM core using PM domains, this is no longer
      needed, and is removed.
      
      This also frees up omap_devices to have a more complex parent/child
      relationships that model actual device relationships.
      
      The only in-tree user of omap_device_parent was the OMAP PM layer to
      handle lost-context count for omap_devices.  That is now converted to
      use the presence of the omap_device_pm_domain instead.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      3ec2decb
    • B
      gpio/omap: Fix IRQ handling for SPARSE_IRQ · 25db711d
      Benoit Cousson 提交于
      The driver is still relying on internal OMAP IRQ defines that
      are not relevant anymore if OMAP is built with SPARSE_IRQ.
      
      Replace the defines with the proper IRQ base number.
      Clean some comment style issue.
      Remove some hidden and ugly cpu_class_is_omap1() inside the
      gpio header.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Tested-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      25db711d
    • S
      ARM: OMAP3+: SmartReflex: use voltage domain name in device attributes · cea6b942
      Shweta Gulati 提交于
      To set sr ntarget values for all volt_domain,
      volt_table is retrieved by doing a look_up of 'vdd_name'
      field from omap_hwmod but voltage domain pointer does not
      belong to omap_hwmod and is not used anywhere else.
      As a part of voltage layer and SR Layer clean up volt
      pointer is removed from omap_hwmod and added in dev
      attributes of SR. The value of the field must match
      the voltage domain names for the binding to be effective.
      
      Tested on OMAP3630 SDP, OMAP3530 Beagleboard and
      OMAP4430 SDP Board.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NShweta Gulati <shweta.gulati@ti.com>
      Acked by: Nishanth Menon <nm@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NJean Pihet <j-pihet@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      cea6b942
    • J
      ASoC: OMAP: ams-delta: drop .set_bias_level callback · 0379c1f5
      Janusz Krzysztofik 提交于
      This functionality has already been implemented in the cx20442 codec
      driver (commit f75a8ff6, "ASoC: cx20442:
      add bias control over a platform provided regulator"), no need to keep
      it here duplicated.
      
      Once done, remove the no longer used AMS_DELTA_LATCH2_MODEM_NRESET
      symbol from the board header file and a call to the regulator_toggle()
      helper function from the old API wrapper found in the board file.  While
      being at it, simplify the way the modem .pm callback handles the
      regulator and drop that helper function and its related consumer setup
      completely.
      
      Depends on patches 1/3 and 2/3 for clean apply and keep things working.
      Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      0379c1f5
    • A
      ARM: OMAP: add minimal support for Nokia RM-696 · 63fc5f3b
      Aaro Koskinen 提交于
      Add minimal support for Nokia RM-696 board.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      63fc5f3b
  15. 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
  16. 25 2月, 2012 5 次提交