1. 10 7月, 2011 10 次提交
  2. 21 4月, 2011 1 次提交
    • A
      OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup. · f95440ca
      Avinash.H.M 提交于
      GPIO module expects the debounce clocks to be enabled during reset. It doesn't
      reset properly and timeouts are seen, if this clock isn't enabled during
      reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
      which the debounce clocks are enabled during reset.
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NAvinash.H.M <avinashhm@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f95440ca
  3. 20 4月, 2011 1 次提交
  4. 11 3月, 2011 1 次提交
    • A
      OMAP: DSS2: Have separate irq handlers for DISPC and DSI · affe360d
      archit taneja 提交于
      Currently, the core DSS platform device requests for an irq line for OMAP2 and
      OMAP3. Make DISPC and DSI platform devices request for a shared IRQ line.
      
      On OMAP3, the logical OR of DSI and DISPC interrupt lines goes to the MPU. There
      is a register DSS_IRQSTATUS which tells if the interrupt came from DISPC or DSI.
      
      On OMAP2, there is no DSI, only DISPC interrupts goto the MPU. There is no
      DSS_IRQSTATUS register.
      
      Hence, it makes more sense to have separate irq handlers corresponding to the
      DSS sub modules instead of having a common handler.
      
      Since on OMAP3 the logical OR of the lines goes to MPU, the irq line is shared
      among the IRQ handlers.
      
      The hwmod irq info has been removed for DSS to DISPC and DSI for OMAP2 and OMAP3
      hwmod databases. The Probes of DISPC and DSI now request for irq handlers.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      affe360d
  5. 10 3月, 2011 2 次提交
    • A
      omap: hwmod: add syss reset done flags to omap2, omap3 hwmods · d73d65fa
      Avinash.H.M 提交于
      Some of the omap2, omap3 peripherals support software reset. This
      can be done through the softreset bit in sysconfig register.
      The reset status can be checked through resetdone bit of
      sysstatus register. syss_has_reset_status is added to the hwmod
      database of peripherals which have resetdone bit in sysstatus register.
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Reviewed-by: NGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NAvinash.H.M <avinashhm@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d73d65fa
    • P
      OMAP2/3: VENC hwmod: add OCPIF_SWSUP_IDLE flag to interface · c39bee8a
      Paul Walmsley 提交于
      According to the hwmod interface data, the DSS submodule "VENC" uses a
      clock, "dss_54m_fck"/"dss_tv_fck", which the PRCM cannot autoidle.  By
      default, the hwmod code assumes that interface clocks can be autoidled
      by the PRCM.  When the interface clock can't be autoidled by the PRCM,
      those interfaces must be marked with the OCPIF_SWSUP_IDLE flag.
      Otherwise, the "interface clock" will always have a non-zero use
      count, and the device won't enter idle.  This problem was observed on
      N8x0.
      
      Fix the immediate problem by marking the VENC interface with the
      OCPIF_SWSUP_IDLE flag.  But it's not clear that
      "dss_54m_fck"/"dss_tv_fck" is really the correct interface clock for
      VENC.  It may be that the VENC interface should use a
      hardware-autoidling interface clock.  This is the situation on OMAP4,
      which uses "l3_div_ck" as the VENC interface clock, which can be
      autoidled by the PRCM.  Clarification from TI is needed.
      
      Problem found and patch tested on N8x0 by Tony Lindgren
      <tony@atomide.com>.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Senthilvadivu Guruswamy <svadivu@ti.com>
      Cc: Sumit Semwal <sumit.semwal@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c39bee8a
  6. 01 3月, 2011 1 次提交
    • P
      OMAP2+: hwmod: rename some init functions · 550c8092
      Paul Walmsley 提交于
      Rename omap_hwmod_init() to omap_hwmod_register().  Rename
      omap_hwmod_late_init() to omap_hwmod_setup_all().  Also change all of
      the callers to reflect the new names.  While here, update some
      copyrights.
      
      Suggested by Tony Lindgren <tony@atomide.com>.
      
      N.B. The comment in mach-omap2/serial.c may no longer be correct, given
           recent changes in init order.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      550c8092
  7. 28 2月, 2011 1 次提交
  8. 25 2月, 2011 2 次提交
  9. 23 2月, 2011 1 次提交
  10. 18 2月, 2011 1 次提交
  11. 22 12月, 2010 1 次提交
    • P
      OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism · ff2516fb
      Paul Walmsley 提交于
      The OMAP watchdog timer IP blocks require a specific set of register
      writes to occur before they will be disabled[1], even if the device
      clocks appear to be disabled in the CM_*CLKEN registers.  In the MPU
      watchdog case, failure to execute this reset sequence will eventually
      cause the watchdog to reset the OMAP unexpectedly.
      
      Previously, the code to disable this watchdog was manually called from
      mach-omap2/devices.c during device initialization.  This causes the
      watchdog to be unconditionally disabled for a portion of kernel
      initialization.  This should be controllable by the board-*.c files,
      since some system integrators will want full watchdog coverage of
      kernel initialization.  Also, the watchdog disable code was not
      connected to the hwmod shutdown code.  This means that calling
      omap_hwmod_shutdown() will not, in fact, disable the watchdog, and the
      goal of omap_hwmod_shutdown() is to be able to shutdown any on-chip
      OMAP device.
      
      To resolve the latter problem, populate the pre_shutdown pointer in
      the watchdog timer hwmod classes with a function that executes the
      watchdog shutdown sequence.  This allows the hwmod code to fully
      disable the watchdog.
      
      Then, to allow some board files to support watchdog coverage
      throughout kernel initialization, add common code to mach-omap2/io.c
      to cause the MPU watchdog to be disabled on boot unless a board file
      specifically requests it to remain enabled.  Board files can do this
      by changing the watchdog timer hwmod's postsetup state between the
      omap2_init_common_infrastructure() and omap2_init_common_devices()
      function calls.
      
      1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. ZH
         [SWPU222H], Section 16.4.3.6, "Start/Stop Sequence for WDTs (Using
         WDTi.WSPR Register)"
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Charulatha Varadarajan <charu@ti.com>
      ff2516fb
  12. 21 12月, 2010 1 次提交
  13. 08 12月, 2010 1 次提交
  14. 10 11月, 2010 1 次提交
  15. 30 9月, 2010 2 次提交
  16. 27 7月, 2010 4 次提交
  17. 21 5月, 2010 1 次提交
  18. 25 2月, 2010 3 次提交
    • P
      OMAP hwmod: add hwmod class support · 43b40992
      Paul Walmsley 提交于
      Add support for categorizing and iterating over hardware IP blocks by
      the "class" of the IP block.  The class is the type of the IP block:
      e.g., "timer", "timer1ms", etc.  Move the OCP_SYSCONFIG/SYSSTATUS data
      from the struct omap_hwmod into the struct omap_hwmod_class, since
      it's expected to stay consistent for each class.  While here, fix some
      comments.
      
      The hwmod_class structures in this patch were designed and proposed by
      Benoît Cousson <b-cousson@ti.com> and were refined in a discussion
      between Thara Gopinath <thara@ti.com>, Kevin Hilman
      <khilman@deeprootsystems.com>, and myself.
      
      This patch uses WARN() lines that are longer than 80 characters, as
      Kevin noted a broader lkml consensus to increase greppability by
      keeping the messages all on one line.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
      Cc: Thara Gopinath <thara@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      43b40992
    • P
      OMAP hwmod: convert header files with static allocations into C files · 7359154e
      Paul Walmsley 提交于
      Code should be able to #include any header file without the fear that
      the header file will go allocating memory.  This is a coding style
      issue, similar to commit 82e9bd58.
      Move the existing hwmod data from .h files to .c files.
      
      While here, convert "omap34xx" to "omap3xxx" in the hwmod files, since
      most of these structures should be reusable across all OMAP3 chips.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      7359154e
    • P
      OMAP hwmod: convert hwmod to use hardware clock names rather than clkdev dev+con · 50ebdac2
      Paul Walmsley 提交于
      The OMAP hwmod core code is intended to use SoC IP block description
      structures that are autogenerated from TI's OMAP hardware database.
      Currently the hwmod code uses clkdev device + connection addressing to
      identify clocks.  This causes problems in the hwmod autogeneration
      process, since the TI hardware database doesn't use platform_device or
      clkdev addressing; it uses a single clock signal name string, which
      tends to bear some resemblance to what is used in the OMAP TRMs.  This
      patch converts the hwmod code and existing data to use omap_clk_get_by_name(),
      introduced in the previous patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      50ebdac2
  19. 21 10月, 2009 1 次提交
    • T
      omap: headers: Move remaining headers from include/mach to include/plat · ce491cf8
      Tony Lindgren 提交于
      Move the remaining headers under plat-omap/include/mach
      to plat-omap/include/plat. Also search and replace the
      files using these headers to include using the right path.
      
      This was done with:
      
      #!/bin/bash
      mach_dir_old="arch/arm/plat-omap/include/mach"
      plat_dir_new="arch/arm/plat-omap/include/plat"
      headers=$(cd $mach_dir_old && ls *.h)
      omap_dirs="arch/arm/*omap*/ \
      drivers/video/omap \
      sound/soc/omap"
      other_files="drivers/leds/leds-ams-delta.c \
      drivers/mfd/menelaus.c \
      drivers/mfd/twl4030-core.c \
      drivers/mtd/nand/ams-delta.c"
      
      for header in $headers; do
      	old="#include <mach\/$header"
      	new="#include <plat\/$header"
      	for dir in $omap_dirs; do
      		find $dir -type f -name \*.[chS] | \
      			xargs sed -i "s/$old/$new/"
      	done
      	find drivers/ -type f -name \*omap*.[chS] | \
      		xargs sed -i "s/$old/$new/"
      	for file in $other_files; do
      		sed -i "s/$old/$new/" $file
      	done
      done
      
      for header in $(ls $mach_dir_old/*.h); do
      	git mv $header $plat_dir_new/
      done
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ce491cf8
  20. 04 9月, 2009 1 次提交