Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 7月, 2011 10 次提交
  3. 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
  5. 20 4月, 2011 1 次提交
  7. 31 3月, 2011 1 次提交
  9. 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
  11. 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
  13. 02 3月, 2011 2 次提交
  15. 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
  17. 28 2月, 2011 1 次提交
  19. 25 2月, 2011 2 次提交
  21. 23 2月, 2011 1 次提交
  23. 18 2月, 2011 1 次提交
  25. 17 2月, 2011 1 次提交
    • H
      OMAP2430: hwmod data: Add USBOTG · 44d02acf
      由 Hema HK 提交于 
      OMAP2430 hwmod data structures are populated with base address, L3 and L4
interface clocks, IRQs and sysconfig register details.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and off-mode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when suspended.
Signed-off-by: NHema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      44d02acf
  27. 22 12月, 2010 2 次提交
    • B
      OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2 · 50ebb777
      由 Benoit Cousson 提交于 
      Since i2c1 and i2c2 are using the same data, remove the two previous
instances and use a common i2c_dev_attr one.

Moreover, that will fix the following warning:
arch/arm/mach-omap2/omap_hwmod_2430_data.c:485:
warning: 'i2c_dev_attr' defined but not used
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Acked-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Charulatha V <charu@ti.com>
      50ebb777
    • 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
  29. 21 12月, 2010 2 次提交
  31. 08 12月, 2010 1 次提交
  33. 10 11月, 2010 1 次提交
  35. 30 9月, 2010 2 次提交
  37. 27 7月, 2010 4 次提交
  39. 21 5月, 2010 1 次提交
  41. 25 2月, 2010 2 次提交
    • 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