1. 19 4月, 2012 6 次提交
    • P
      ARM: OMAP2+: hwmod data: remove forward declarations, reorganize · 844a3b63
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      844a3b63
    • P
      ARM: OMAP2+: hwmod data: convert to link registration · 0a78c5c5
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      0a78c5c5
    • P
      ARM: OMAP4: hwmod data: uncomment some "excluded" hwmods · 53c4c6c3
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      53c4c6c3
    • 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: OMAP4: hwmod data: remove bandgap hwmod · 8291113f
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      8291113f
    • P
      ARM: OMAP4: hwmod data: remove pseudo-hwmods associated with hardreset lines · f2f5736c
      Paul Walmsley 提交于
      Remove the pseudo-hwmods associated with hardreset lines from the
      OMAP4 data file.  Future patches will convert this data to register
      hwmods by interfaces, rather than registering hwmods directly.  The
      pseudo-hwmods aren't associated with any interfaces, so this will
      create a problem.
      
      After this change, the hwmod code will reset processor IPs at the
      hwmod level, rather than by individual hardreset lines.  So, for
      example, if the IVA device driver code wishes to place one of the
      sequencer cores into reset, while leaving the other active, it must do
      so itself by calling the appropriate PRM functions.
      
      This patch will cause a change in the initialization behavior of the
      DSP, IVA, and IPU.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      f2f5736c
  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. 04 4月, 2012 1 次提交
  4. 06 3月, 2012 2 次提交
  5. 26 1月, 2012 1 次提交
  6. 16 12月, 2011 2 次提交
  7. 08 11月, 2011 5 次提交
    • A
      ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader · b923d40d
      Archit Taneja 提交于
      Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
      inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
      cannot reset the DISPC module just like that, but the outputs need to be
      disabled first.
      
      Add function dispc_disable_outputs() which disables all active overlay manager
      and ensure all frame transfers are completed.
      
      Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
      DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
      DSS2 driver starts.
      
      This resolves the hang issue(caused by a L3 error during boot) seen on the
      beagle board C3, which has a factory bootloader that enables display. The issue
      is resolved with this patch.
      
      Thanks to Tomi and Sricharan for some additional testing.
      Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Tested-by: NR, Sricharan <r.sricharan@ti.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      [paul@pwsan.com: restructured code, removed omap_{read,write}l(), removed
       cpu_is_omap*() calls and converted to dev_attr]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b923d40d
    • T
      ARM: OMAP: HWMOD: Unify DSS resets for OMAPs · 13662dc5
      Tomi Valkeinen 提交于
      This patch adds a custom DSS reset function used on OMAPs from OMAP2
      forward.
      
      The function doesn't actually do a reset, it only waits for the reset to
      complete. The reason for this is that on OMAP4 there is no possibility
      to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets
      all the other DSS modules also, thus breaking the HWMOD model where
      every DSS module is handled independently.
      
      This fixes the problem with DSS reset on OMAP4, caused by the fact that
      because there's no SW reset for dss_core on OMAP4, the HWMOD framework
      doesn't try to reset dss_core and thus the DSS clocks were never enabled
      at the same time. This causes causes the HWMOD reset to fail for
      dss_dispc and dss_rfbi.
      
      The common reset function will also allow us to fix another problem in
      the future: before doing a reset we need to disable DSS outputs, which
      are in some cases enabled by the bootloader, as otherwise DSS HW seems
      to get more or less stuck, requiring a power reset to recover.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      [paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o
       unconditionally to avoid an error when !CONFIG_OMAP2_DSS]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      13662dc5
    • T
      ARM: OMAP4: HWMOD: fix DSS clock data · 4d0698d9
      Tomi Valkeinen 提交于
      The OMAP4 HWMOD data currently contains errors with DSS clocks:
      
      dss_hdmi and dss_venc have their main_clks wrong. The clocks should be
      dss_48mhz_clk and dss_tv_clk, respectively.
      
      These problems were temporarily fixed with the DSS patches
      9ede365a ("HACK: OMAP: DSS2: clk hack
      for OMAP2/3"), and df5d3ed2 ("OMAP:
      DSS2: HDMI: fix hdmi clock name"), which can be reverted after this
      patch.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4d0698d9
    • T
      ARM: OMAP4: HWMOD: Add HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core · 37ad0855
      Tomi Valkeinen 提交于
      DSS needs all DSS clocks to be enabled to be able to finish reset
      properly. Before v3.1-rc1 the omapdss driver was managing clocks and
      resets correctly. However, when omapdss started using runtime PM at
      v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
      
      HWMOD framework does not currently enable all the DSS clocks when
      resetting the DSS hardware. This causes the HWMOD frameworks boot-time
      reset to fail, possibly leaving the DSS hardware in undefined state.
      
      This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core. The flag
      is actually not used on OMAP4, because dss_core hardware does not have
      soft-reset functionality and thus the HWMOD framework never resets nor
      waits for the reset to finish.
      
      However, while the flag is not strictly needed currently, I think it
      represents the HW correctly: all the DSS clocks should be enabled after
      power-on to allow DSS hardware to finish its reset.
      
      A custom reset function will be added in the following patches which
      manages this correctly for OMAP4.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      37ad0855
    • T
      ARM: OMAP4: HWMOD: remove extra clocks · 4247878e
      Tomi Valkeinen 提交于
      Remove the dss_dss_clk from dss_core's opt-clocks. dss_dss_clk already
      defined as the dss main_clk, and thus is not needed as an opt-clock.
      
      Remove opt-clocks for dss_dispc, as dispc only uses the main_clk.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4247878e
  8. 22 9月, 2011 2 次提交
  9. 15 9月, 2011 1 次提交
    • P
      OMAP2+: hwmod: remove OMAP_CHIP* · d6504acd
      Paul Walmsley 提交于
      At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
      replace it instead with chip family, variant, and ES level-specific lists
      of hwmods to register.
      
      Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the
      AM3517/3505 support, and for other review comments.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Gražvydas Ignotas <notasas@gmail.com>
      d6504acd
  10. 10 7月, 2011 19 次提交
    • B
      OMAP4: hwmod data: Add modulemode entry in omap_hwmod structure · 03fdefe5
      Benoit Cousson 提交于
      Add a new field to provide the mode supported by the module.
      The mode will control the way mandatory clocks are managed by the PRCM.
      
        0 : Module is temporarily disabled by SW. OCP access to module are stalled.
            Can be used to change timing parameter of GPMC module.
        1 : Module is managed automatically by HW according to clock domain
            transition. A clock domain sleep transition put module into idle.
            A wakeup domain transition put it back into function.
            If CLKTRCTRL=3, any OCP access to module is always granted.
            Module clocks may be gated according to the clock domain state.
        2 : Module is explicitly enabled. Interface clock (if not used for
            functions) may be gated according to the clock domain state.
            Functional clocks are guarantied to stay present. As long as
            in this configuration, power domain sleep transition cannot happen.
      
      Some modules will have a modulemode initialized at 1 (HWCTRL) by default.
      This is the case for interconnect and simple module like GPIO, WDT, MAILBOX.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      03fdefe5
    • B
      OMAP4: hwmod data: Add PRM context register offset · 27bb00b5
      Benoit Cousson 提交于
      Add a 'context_offs' entry in the prcm.omap4 structure to all
      IPs when applicable.
      The offset will be used to retrieve the per module context lost
      information now available on OMAP4.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      27bb00b5
    • B
      OMAP4: hwmod: Replace RSTCTRL absolute address with offset macros · eaac329d
      Benoit Cousson 提交于
      The RSTCTRL register was accessed using an absolute address.
      The usage of hardcoded macros to calculate virtual address from physical
      one should be avoided as much as possible.
      The usage of an offset will allow future improvement like migration from
      the current architecture code toward a module driver.
      
      Update prm_xxx accessors, move definition to the proper header file and
      update copyrights.
      Change the s16 register offset parameter to u16.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: use '_prminst_' in function names that are part of the
       prminst44xx.c file]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      eaac329d
    • B
      OMAP4: hwmod: Replace CLKCTRL absolute address with offset macros · d0f0631d
      Benoit Cousson 提交于
      The CLKCTRL register was accessed using an absolute address.
      The usage of hardcoded macros to calculate virtual address from physical
      one should be avoided as much as possible.
      The usage of a offset will allow future improvement like migration from
      the current architecture code toward a module driver.
      
      Update cm_xxx accessor, move definition to the proper header file and
      update copyrights.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Todd Poynor <toddpoynor@google.com>
      [paul@pwsan.com: renamed 'omap4_cm_' fns to 'omap4_cminst_'; removed empty
       fn prototype section from cm44xx.h; incorporated comments from Todd;
       documented some functions]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d0f0631d
    • B
      OMAP4: hwmod data: Add clock domain attribute · a5322c6f
      Benoit Cousson 提交于
      In OMAP PRCM terminology, the clock domain is defined as a group of IPs
      that share some clocks and most of the time an interface clock.
      Every IP does belong to a clockdomain.
      For the moment the clock domain attribute is affected to a clock node.
      The issue with that approach, is that a clock might or not belong to a
      clock domain. Moreover during module transition, it is up to a module
      to handle properly the clock domain state and not to a clock node.
      
      Create a clkdm_name attribute to provide this information per hwmod.
      
      Populate this attribute for every OMAP4 hwmod entries.
      
      Future cleanup series with remove that information from the OMAP4 clock
      when it is relevant.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: fix the mpuss_clkdm name]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a5322c6f
    • A
      OMAP: hwmod: fix the i2c-reset timeout during bootup · 6d3c55fd
      Avinash.H.M 提交于
      The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a
      special sequence to reset the module. The sequence is
       - Disable the I2C.
       - Write to SOFTRESET bit.
       - Enable the I2C.
       - Poll on the RESETDONE bit.
      The sequence is implemented as a function and the i2c_class is updated with
      the correct 'reset' pointer.  omap_hwmod_softreset function is implemented
      which triggers the softreset by writing into sysconfig register. On following
      this sequence, i2c module resets properly and timeouts are not seen.
      
      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>
      [paul@pwsan.com: combined this patch with a patch to remove
       HWMOD_INIT_NO_RESET from the 44xx hwmod flags; change register
       offset conditional code to use the IP block revision; minor code
       cleanup]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6d3c55fd
    • A
      I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr · 4d4441a6
      Andy Green 提交于
      This adds the new functionality flags for omap i2c unit to all OMAP2
      hwmod definitions
      
      Cc: patches@linaro.org
      Cc: Ben Dooks <ben-linux@fluff.org>
      Reported-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NAndy Green <andy.green@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4d4441a6
    • A
      I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision · db791a75
      Andy Green 提交于
      Since we cannot trust (or even reliably find) the OMAP I2C
      peripheral unit's own revision register, we must inform the
      OMAP i2c driver of which IP version it is running on.  We
      do this by tagging the omap_hwmod_class for i2c on all the
      OMAP2+ platform / cpu specific hwmod init and passing it up
      to the driver (next patches).
      
      Cc: patches@linaro.org
      Cc: Ben Dooks <ben-linux@fluff.org>
      Reported-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NAndy Green <andy.green@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      db791a75
    • A
      I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c · 3e600522
      Andy Green 提交于
      Peter Maydell noticed when running under QEMU he was getting
      errors reporting 32-bit access to I2C peripheral unit registers
      that are documented to be 8 or 16-bit only[1][2]
      
      The I2C driver is blameless as it wraps its accesses in a
      function using __raw_writew and __raw_readw, it turned out it
      is the hwmod stuff.
      
      However the hwmod code already has a flag to force a
      perhipheral unit to only be accessed using 16-bit operations.
      
      This patch applies the 16-bit only flag to the 2430,
      OMAP3xxx and OMAP44xx hwmod structs.  2420 was already
      correctly marked up as 16-bit.
      
      The 2430 change will need testing by TI as arranged
      in the comments to the previous patch version.
      
      When the 16-bit flag is or-ed with other flags, it is placed
      first as requested in comments.
      
      [1] OMAP4430 Technical reference manual section 23.1.6.2
      [2] OMAP3530 Techincal reference manual section 18.6
      
      Cc: patches@linaro.org
      Cc: Ben Dooks <ben-linux@fluff.org>
      Reported-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NAndy Green <andy.green@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3e600522
    • T
      OMAP4: hwmod data: Change DSS main_clk scheme · da7cdfac
      Tomi Valkeinen 提交于
      Currently using pm_runtime with DSS requires the DSS driver to enable
      the DSS functional clock before calling pm_runtime_get(). That makes it
      impossible to use pm_runtime in DSS as it is meant to be used, with
      pm_runtime callbacks.
      
      This patch changes the hwmod database for OMAP4 so that enabling the
      hwmod via pm_runtime will also enable the DSS functional clock, allowing
      us to use pm_runtime properly in DSS driver.
      
      The DSS HWMOD side is not really correct, not before nor after this
      patch, and getting DSS to retention will probably not work currently.
      However, it is not supported in the mainline kernel anyway, so this
      won't break anything.
      
      So this patch allows us to write the pm_runtime adaptation for the DSS
      driver the way it should be done, and the HWMOD/PM side can be fixed
      later.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      da7cdfac
    • T
      OMAP4: hwmod data: Modify DSS opt clocks · 3a23aafc
      Tomi Valkeinen 提交于
      Add missing DSS optional clocks to HWMOD data for OMAP4xxx.
      
      Add HWMOD_CONTROL_OPT_CLKS_IN_RESET flag for dispc to fix dispc reset.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      [b-cousson@ti.com: Remove a comment and update the subject]
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      [paul@pwsan.com: removed DSS "fck" role and some clkdev aliases at Tomi's
       request]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3a23aafc
    • B
      OMAP4: hwmod data: Align interconnect format with regular modules · 7e69ed97
      Benoit Cousson 提交于
      The interconnect modules were using a slightly different layout than
      the regular modules.
      Align the layout for better consitency.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7e69ed97
    • B
      OMAP4: hwmod data: Fix bad alignement · 00fe610b
      Benoit Cousson 提交于
      Fix .prcm alignement and usb_otg_hs class and hwmod structures.
      
      Add a couple of more potential hwmods in the comment.
      Remove hsi, since it is already included in the data.
      
      Remove one blank line.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      00fe610b
    • B
      OMAP4: hwmod data: Remove un-needed parens · 7ecc5373
      Benoit Cousson 提交于
      A couple of parens were added around some flags.
      
      Remove them, since they are not needed and not used
      for any other hwmods.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7ecc5373
    • B
      OMAP4: hwmod data: Fix L3 interconnect data order and alignement · 9b4021be
      Benoit Cousson 提交于
      Change the position of the ocp_if structure to match the template.
      
      Remove unneeded comma at the end of address space flag field.
      
      Remove USER_SDMA since this ocp link is only from the l3_main_1
      path that is accessible only from the MPU in that case and not
      the SDMA.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      9b4021be
    • P
      omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays · bc614958
      Paul Walmsley 提交于
      Previously, struct omap_hwmod_dma_info arrays were unterminated; and
      users of these arrays used the ARRAY_SIZE() macro to determine the
      length of the array.  However, ARRAY_SIZE() only works when the array
      is in the same scope as the macro user.
      
      So far this hasn't been a problem.  However, to reduce duplicated
      data, a subsequent patch will move common data to a separate, shared
      file.  When this is done, ARRAY_SIZE() will no longer be usable.
      
      This patch removes ARRAY_SIZE() usage for struct omap_hwmod_dma_info
      arrays and uses a sentinel value (irq == -1) as the array terminator
      instead.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      bc614958
    • P
      omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays · 212738a4
      Paul Walmsley 提交于
      Previously, struct omap_hwmod_mpu_irqs arrays were unterminated; and
      users of these arrays used the ARRAY_SIZE() macro to determine the
      length of the array.  However, ARRAY_SIZE() only works when the array
      is in the same scope as the macro user.
      
      So far this hasn't been a problem.  However, to reduce duplicated
      data, a subsequent patch will move common data to a separate, shared
      file.  When this is done, ARRAY_SIZE() will no longer be usable.
      
      This patch removes ARRAY_SIZE() usage for struct omap_hwmod_mpu_irqs
      arrays and uses a sentinel value (irq == -1) as the array terminator
      instead.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      212738a4
    • P
      omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays · 78183f3f
      Paul Walmsley 提交于
      Previously, struct omap_hwmod_addr_space arrays were unterminated; and
      users of these arrays used the ARRAY_SIZE() macro to determine the
      length of the array.  However, ARRAY_SIZE() only works when the array
      is in the same scope as the macro user.
      
      So far this hasn't been a problem.  However, to reduce duplicated
      data, a subsequent patch will move common data to a separate, shared
      file.  When this is done, ARRAY_SIZE() will no longer be usable.
      
      This patch removes ARRAY_SIZE() usage for struct omap_hwmod_addr_space
      arrays and uses a null structure member as the array terminator
      instead.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      
      
      
      
      78183f3f
    • B
      OMAP4: hwmod data: Add MSTANDBY_SMART_WKUP flag · c614ebf6
      Benoit Cousson 提交于
      Add the flag to every IPs that support it to allow the
      framework to enable it instead of the SMART_STANDBY default
      mode.
      Without that, an IP with busmaster capability will not
      be able to wakeup the interconnect at all.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c614ebf6