1. 19 Apr, 2012 40 commits
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: add System Control Module · a0b5d813
      Paul Walmsley authored
      Add the System Control Module hwmod and associated interconnect data.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      a0b5d813
    • Benoît Cousson's avatar
      ARM: OMAP4: hwmod data: add the OCP-WP IP block · 9a817bc8
      Benoît Cousson authored
      Add the OCP-WP hwmod and associated interconnect data.  The OCP-WP,
      or OCP watchpoint, can be used to collect interconnect data and
      transmit it via the STM port.
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      9a817bc8
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: add OCM RAM IP block · e17f18c0
      Paul Walmsley authored
      Add the OCM RAM IP block and interconnect data.  This is an oh-chip
      block of SRAM connected directly to the L3 bus.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      e17f18c0
    • Benoît Cousson's avatar
      ARM: OMAP4: hwmod data: add remaining USB-related IP blocks · 0c668875
      Benoît Cousson authored
      Add the OCP2SCP IP block and interconnect data.  The OCP2SCP can be
      used in conjunction with the on-chip embedded USB PHY, associated with
      the OTG controller.
      
      Add the on-chip full-speed USB host controller IP block and
      interconnect data.
      
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      0c668875
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: add some interconnect-related IP blocks · 42b9e387
      Paul Walmsley authored
      Add the SL2 interface IP block and interconnect data.  The SL2 is related
      to the IVA-HD subsystem.
      
      Add IP block and interconnect data for the C2C ("Chip-to-chip")
      interconnect.  This can provide a direct system interconnect link to
      other devices stacked on the OMAP package.
      
      Add the ELM IP block and interconnect data.  The ELM can be used
      to locate errors in NAND flash connected to the GPMC.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      42b9e387
    • Benoît Cousson's avatar
      ARM: OMAP4: hwmod data: add McASP · 896d4e98
      Benoît Cousson authored
      Add the McASP hwmod and associated interconnect data.  The McASP is a
      general-purpose audio serial port.
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      896d4e98
    • Benoît Cousson's avatar
      ARM: OMAP4: hwmod data: add the Slimbus IP blocks · 1e3b5e59
      Benoît Cousson authored
      Add the Slimbus hwmods and associated interconnect data.  The Slimbus
      IP blocks implement a two-wire serial interface.
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      
      
      1e3b5e59
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: add GPU · 9def390e
      Paul Walmsley authored
      Add the GPU hwmod and associated interconnect data.  The GPU is a
      graphics accelerator.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      9def390e
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: add EMIF1 and 2 · bf30f950
      Paul Walmsley authored
      Add the EMIF1 and 2 hwmods and associated interconnect data.  The EMIFs
      are SDRAM interface IP blocks.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      bf30f950
    • Benoît Cousson's avatar
      ARM: OMAP4: hwmod data: add GPMC · eb42b5d3
      Benoît Cousson authored
      Add the GPMC hwmod and associated interconnect data.   The GPMC is a
      programmable parallel-bus memory controller.
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      
      eb42b5d3
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: add HDQ/1-wire · a091c08e
      Paul Walmsley authored
      Add the HDQ/1-wire hwmod and associated interconnect data.  The
      HDQ/1-wire IP block is a low-speed serial interconnect.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarBenoît Cousson <b-cousson@ti.com>
      a091c08e
    • Ming Lei's avatar
      ARM: OMAP4: hwmod data: introduce fdif(face detect module) hwmod · b050f688
      Ming Lei authored
      Add hwmod data for the OMAP4 FDIF IP block.
      
      This patch also includes a change (originally from Fernando Guzman
      Lugo <fernando.lugo@ti.com>) to set a softreset delay for the FDIF IP
      block:
      
         http://www.spinics.net/lists/arm-kernel/msg161874.htmlSigned-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Acked-by: default avatarBenoît Cousson <b-cousson@ti.com>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      [paul@pwsan.com: rearranged to match script output; fixed FDIF end address to
       match script data; wrote trivial changelog; combined the FDIF portion of
       Fernando's srst_udelay patch]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      b050f688
    • Paul Walmsley's avatar
      ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common · 6ba5a69e
      Paul Walmsley authored
      The PRM and CM implicit clockdomains will soon be used by OMAP44xx.
      So, make them common to OMAP2+ and modify the OMAP4 clockdomains code
      so use of these clockdomains doesn't crash the system.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      6ba5a69e
    • Paul Walmsley's avatar
      ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP · 3af35fbc
      Paul Walmsley authored
      N800 logs this message on boot:
      
      [    0.182281] omap_hwmod: iva: cannot be enabled for reset (3)
      
      Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2
      hwmod for OMAP2430.  There is still more information to be added, but
      this should resolve the immediate issue.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      3af35fbc
    • Paul Walmsley's avatar
      ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomain · f42c5496
      Paul Walmsley authored
      The IVA hwmod data is missing some fields that cause the following
      warning on boot:
      
      [    0.118011] omap_hwmod: iva: cannot be enabled for reset (3)
      
      Fix by encoding the IP block's main functional clock, reset lines, and
      clockdomain.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      f42c5496
    • Paul Walmsley's avatar
      ARM: OMAP3: hwmod data: fix IVA interface clock · 064931ab
      Paul Walmsley authored
      The OMAP3 hwmod data listed iva2_ck as an interface clock between the
      IVA and L3.  This is incorrect.  iva2_ck is not an interface clock.
      Since it cannot auto-idle, specifying it here prevents the IVA and at
      least one of the CORE clockdomains from going idle, which causes PM
      problems such as these upon system suspend:
      
      [   70.626129] Powerdomain (iva2_pwrdm) didn't enter target state 1
      [   70.626190] Powerdomain (core_pwrdm) didn't enter target state 1
      
      Fix by specifying the actual interface clock in the hwmod data.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      064931ab
    • Paul Walmsley's avatar
      ARM: OMAP2xxx: hwmod data: share common interface data · 6a29755f
      Paul Walmsley authored
      Several struct omap_hwmod_ocp_if records can be shared between OMAP2420
      and OMAP2430.  Move these shared records out of the chip-specific files
      into mach-omap2/omap_hwmod_2xxx_interconnect_data.c.  This should save some
      memory and source lines, at the cost of readability.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      
      6a29755f
    • Paul Walmsley's avatar
      ARM: OMAP2xxx: hwmod data: share common hwmods between OMAP2420 and OMAP2430 · cb48427e
      Paul Walmsley authored
      After the link registration conversion, it's much easier to share some
      hwmod data between OMAP2420 and 2430.  Move the shareable data into a
      common file.  This should save some memory and lines of source, at the
      cost of readability.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      
      
      cb48427e
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod data: remove forward declarations, reorganize · 844a3b63
      Paul Walmsley authored
      Reorganize the hwmod data to declare the IP blocks first and the
      interconnects second.  This allows us to remove the forward
      declarations, which this patch also does. Saves some lines of source
      data.  While here, take the opportunity to synchronize the order of
      the OMAP44xx hwmod data with the autogenerator output -- it's slightly
      different due to past mismerges -- and fix a few minor typos and
      whitespace problems in the files.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      844a3b63
    • Paul Walmsley's avatar
      ARM: OMAP: hwmod: remove code support for direct hwmod registration · 11cd4b94
      Paul Walmsley authored
      Now that the data has been converted to use interface registration, we
      can remove the (now unused) direct hwmod registration code.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      11cd4b94
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod data: convert to link registration · 0a78c5c5
      Paul Walmsley authored
      Register interconnect links between IP blocks, rather than the IP
      blocks themselves.  (The IP blocks will be registered as a side-effect
      of registering the links.)
      
      The objective is to reduce the number of lines of static data and
      facilitate the sharing of IP block data between different SoCs.  These
      objectives come at the penalty of increased boot time due to increased
      computation.
      
      While here, fix a few whitespace problems and inaccurate variable names.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      0a78c5c5
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: add support for link registration · 2221b5cd
      Paul Walmsley authored
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      2221b5cd
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing it · 24dbc213
      Paul Walmsley authored
      An IP block's MPU interface port only needs to be found once.  The result
      can be cached to speed further lookups.  This patch consolidates these
      two steps into a single function.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      24dbc213
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_if · 5d95dde7
      Paul Walmsley authored
      To reduce the number of lines of data in the OMAP portion of the Linux
      code base, subsequent patches will remove the lists of hwmod
      interconnect links from the static hwmod data.  These lists will be
      built dynamically during boot.  To ease this transition, this patch
      centralizes the way that interconnect links are iterated into a single
      function, _fetch_next_ocp_if().
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      5d95dde7
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: add _find_mpu_rt_port() · 2d6141ba
      Paul Walmsley authored
      Most IP blocks on the OMAP SoC have an interconnect link that is
      intended to be used by the MPU to communicate with the IP block.
      Several parts of the hwmod code need to be able to identify this link.
      Currently, this is open-coded.  However, future patches will change
      the way that interconnect links are represented and will make
      identifying the link more complex.  So to avoid code duplication, this
      patch centralizes the MPU port link identification code into a new
      function, _find_mpu_rt_port().
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      2d6141ba
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bits · 515237d6
      Paul Walmsley authored
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      515237d6
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: uncomment some "excluded" hwmods · 53c4c6c3
      Paul Walmsley authored
      Some hwmods were commented out from the OMAP4 data, under the theory
      that they shouldn't be added until drivers were ready.  But part of
      the utility of the hwmod code is that it can reset and properly
      initialize IP blocks that have no drivers associated with them.
      Rather than commenting the links in the future hwmod data conversion
      patches, discussing this with Benoit, it seems best to simply
      uncomment them now.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      53c4c6c3
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriately · 3d10f0d6
      Paul Walmsley authored
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      
      
      3d10f0d6
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: remove bandgap hwmod · 8291113f
      Paul Walmsley authored
      Commit 407a6888 ("OMAP4: hwmod data:
      Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU") adds a
      hwmod for the bandgap die temperature sensor IP block.  This IP block
      has no interconnect port or firewall region, nor does it have an
      independent register space or OCP control registers.  Its registers
      are embedded in the System Control Module (SCM) IP block.  So it
      appears that the bandgap device should be created by the SCM driver.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      8291113f
    • Paul Walmsley's avatar
      ARM: OMAP3: hwmod data: GPTIMER12 is attached to a separate interconnect · 43085705
      Paul Walmsley authored
      GPTIMER12 is attached to the L4 SEC interconnect, not directly to L4 WKUP.
      Add the L4 SEC interconnect and attach GPTIMER12 to it.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      43085705
    • Paul Walmsley's avatar
      ARM: OMAP3: hwmod data: add DSS->L3 interconnect for 3430ES1 · d69dc648
      Paul Walmsley authored
      The OMAP3 hwmod data was missing a DSS->L3 interconnect link for the
      OMAP3430 ES1 DSS hwmod.  Since the hwmod code and data is being modified
      to register interfaces rather than hwmods, this would result in the DSS hwmod
      not being registered correctly on OMAP3430ES1.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      
      
      d69dc648
    • Paul Walmsley's avatar
      ARM: OMAP3: hwmod data: fix interfaces for the MMC hwmods · 4a9efb62
      Paul Walmsley authored
      Commit a52e2ab6 ("ARM: OMAP3: hwmod
      data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1")
      didn't link the MMC hwmods to the interconnects correctly.  Future
      patches will register hwmods by interface, so if this is not fixed,
      the MMC IP blocks won't be registered.  Update the interface data
      records to point to the correct IP blocks.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      
      
      4a9efb62
    • Paul Walmsley's avatar
      ARM: OMAP2/3: hwmod data: update old names · bec93811
      Paul Walmsley authored
      Some of the 2xxx and 3xxx hwmod data files use the old naming style
      for hwmods, ending in a "_hwmod".  These names are used by the OMAP
      integration code to map hwmods to platform_devices, so they need to be
      consistent, or the platform_devices won't be created.  Remove the
      _hwmod suffix to conform with the rest of the OMAP SoC data.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      bec93811
    • Paul Walmsley's avatar
      ARM: OMAP2+: timer: use a proper interface to get hwmod data · 6c0c27fd
      Paul Walmsley authored
      arch/arm/mach-omap2/timer.c pokes around inside the hwmod data
      structures.  Since the hwmod data structures are about to change, this
      code will break.  This patch modifies the timer code to use
      recently-added hwmod functions instead.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      6c0c27fd
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: add omap_hwmod_get_resource_byname() · 5e8370f1
      Paul Walmsley authored
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      5e8370f1
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: provide a function to return the address space of the MPU RT · c9aafd23
      Paul Walmsley authored
      A subsequent patch will need to know the struct omap_hwmod_addr_space
      record corresponding to the module's register target, used by the MPU.
      So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space().  Then
      modify its sole current user, _populate_mpu_rt_base(), to extract the
      MPU RT base address itself from the struct omap_hwmod_addr_space record.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      c9aafd23
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: revise hardreset behavior · 747834ab
      Paul Walmsley authored
      Change the way that hardreset lines are handled by the hwmod code.
      Hardreset lines are generally associated with initiator IP blocks.
      Prior to this change, the hwmod code expected to control hardreset
      lines itself, asserting them on shutdown and deasserting them upon
      enable.  But driver authors inside TI have commented to us that their
      drivers require direct control over these lines.  Unfortunately, these
      drivers haven't been posted publicly yet, so it's hard to determine
      exactly what is needed, a priori.  This change attempts to set forth
      some reasonable semantics that should be an improvement over the
      current code.
      
      The semantics implemented by this patch are as follows:
      
      - If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
        associated hardreset lines during IP block setup.  This is intended
        to place the IP blocks into a known state that will not interfere
        with other devices during kernel boot.
      
      - IP blocks with hardreset lines will not be automatically enabled or
        idled during setup.  Instead, they will be left in the INITIALIZED
        state.
      
      - When the hwmod code is asked to enable, idle, or shutdown an IP
        block with asserted hardreset lines, the hwmod code will do nothing.
        The driver integration code must do the remaining work needed to
        control these IP blocks.  Once this driver integration code is posted
        to the lists, hopefully we can consolidate it and move it inside the
        hwmod code.
      
      Custom reset functions for IP blocks with hardreset lines still should
      be supported and are strongly endorsed.  It is intended that every
      subsystem with hardreset lines should have a custom reset function
      that can place their subsystem into quiescent idle with the hardreset
      lines deasserted.
      
      This reverts most of commit 5365efbe
      ("OMAP: hwmod: Add hardreset management support").  Later code
      reorganizations caused the sequencing of the code from this patch to
      be changed, anyway.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      747834ab
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: reorganize and document the reset and configuration process · 64813c3f
      Paul Walmsley authored
      Reorganize the code involved in resetting and configuring an IP block
      to make it easier to read and maintain.  This involves improving
      documentation, splitting some large functions up into smaller ones to
      better conform with Documentation/CodingStyle, and removing some
      unnecessary code.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      64813c3f
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: reorganize and document the initialization process · 381d033a
      Paul Walmsley authored
      Reorganize the code involved in initializing the internal data for
      each hwmod to make it easier to read and maintain.  This involves
      improving documentation and removing some duplicated and unnecessary
      code.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      381d033a
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: revise the IP block reset process · 30e105c0
      Paul Walmsley authored
      Revise the IP block reset process.  This patch ensures that the
      OCP_SYSCONFIG registers are reloaded after a custom reset.  Since
      OCP_SYSCONFIG bits are cleared during reset, they should be
      reprogrammed unless the IP block is being left in reset.  (The only IP
      blocks that are left in reset are IP blocks with hardreset lines and
      no custom reset function.)  If the IP block is left in reset, then it
      is inaccessible to the MPU, and an access to the OCP_SYSCONFIG
      register will cause an abort.
      
      This version incorporates comments from Omar Ramirez Luna
      <omar.ramirez@ti.com> to skip the OCP_SYSCONFIG access after asserting
      hardreset lines.  This allows the MMU (IOMMU) IP block, which has
      both hardreset lines and an OCP_SYSCONFIG register.
      
      Also, ignore _ocp_softreset() errors if the IP block doesn't include a
      softreset bit.  This is needed since a subsequent patch will start
      taking the return value of the _reset() function seriously.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      30e105c0