1. 27 Jun, 2012 1 commit
  2. 25 Jun, 2012 7 commits
  3. 24 Jun, 2012 7 commits
  4. 23 Jun, 2012 6 commits
  5. 22 Jun, 2012 16 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus-Jun-21-2012' of git://oss.sgi.com/xfs/xfs · 369c4f54
      Linus Torvalds authored
      Pull XFS fixes from Ben Myers:
       - Fix stale data exposure with unwritten extents
       - Fix a warning in xfs_alloc_vextent with ODEBUG
       - Fix overallocation and alignment of pages for xfs_bufs
       - Fix a cursor leak
       - Fix a log hang
       - Fix a crash related to xfs_sync_worker
       - Rename xfs log structure from struct log to struct xlog so we can use
         crash dumps effectively
      
      * tag 'for-linus-Jun-21-2012' of git://oss.sgi.com/xfs/xfs:
        xfs: rename log structure to xlog
        xfs: shutdown xfs_sync_worker before the log
        xfs: Fix overallocation in xfs_buf_allocate_memory()
        xfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near
        xfs: check for stale inode before acquiring iflock on push
        xfs: fix debug_object WARN at xfs_alloc_vextent()
        xfs: xfs_vm_writepage clear iomap_valid when !buffer_uptodate (REV2)
      369c4f54
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · a1163719
      Linus Torvalds authored
      Pull perf updates from Ingo Molnar.
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        ftrace: Make all inline tags also include notrace
        perf: Use css_tryget() to avoid propping up css refcount
        perf tools: Fix synthesizing tracepoint names from the perf.data headers
        perf stat: Fix default output file
        perf tools: Fix endianity swapping for adds_features bitmask
      a1163719
    • Vishwanath BS's avatar
      ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle · fafcdd53
      Vishwanath BS authored
      As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
      control it from cpuidle path for OMAP3.
      
      Also as omap3_disable_io_chain is no longer being used, just remove the
      function.
      Signed-off-by: default avatarVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Reviewed-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      fafcdd53
    • Vishwanath BS's avatar
      ARM: OMAP3PLUS: hwmod: reconfigure IO Daisychain during hwmod mux · 5165882a
      Vishwanath BS authored
      IO Daisychain feature has to be triggered whenever there is a change in
      device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
      
      Now devices can idle independent of the powerdomain, there can be a
      window where device is idled and corresponding powerdomain can be
      ON/INACTIVE state. In such situations, since both module wake up is
      enabled at padlevel as well as io daisychain sequence is triggered,
      there will be 2 PRCM interrupts (Module async wake up via swakeup and
      IO Pad interrupt). But as PRCM Interrupt handler clears the Module
      Padlevel WKST bit in the first interrupt, module specific interrupt
      handler will not triggered for the second time
      
      Also look at detailed explanation given by Rajendra at
      http://www.spinics.net/lists/linux-serial/msg04480.htmlSigned-off-by: default avatarVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Reviewed-by: default avatarRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: remove dependency on pm.c & pm.h; add kerneldoc]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      5165882a
    • Tero Kristo's avatar
      ARM: OMAP3+: PRM: Enable IO wake up · 8a680ea2
      Tero Kristo authored
      Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
      managed in cpuidle path which is not the right place. Subsequent patch
      will remove IO Daisy chain handling in cpuidle path once daisy chain is
      handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
      enable code from the trigger function to init time setup.
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Reviewed-by: default avatarRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: harmonize function names with other PRM functions; add
       kerneldoc; resolve checkpatch warnings]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      8a680ea2
    • Rajendra Nayak's avatar
      ARM: OMAP4: PRM: Add IO Daisychain support · dea6200b
      Rajendra Nayak authored
      IO daisychain is a mechanism that allows individual IO pads to generate
      wakeup events on their own based on a switch of an input signal level.
      This allows the hardware module behind the pad to be powered down, but
      still have device level capability to detect IO events, and once this
      happens the module can be powered back up to resume IO. See section
      3.9.4 in OMAP4430 Public TRM for details.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: use the shared MAX_IOPAD_LATCH_TIME declaration; renamed
       omap4_trigger_io_chain() to conform to other PRM function names;
       added kerneldoc; resolved checkpatch warnings]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      dea6200b
    • Vishwanath BS's avatar
      ARM: OMAP3: PM: Move IO Daisychain function to omap3 prm file · 09659fa7
      Vishwanath BS authored
      Since IO Daisychain modifies only PRM registers, it makes sense to move
      it to PRM File. Also changed the timeout value for IO chain enable to
      100us and added a wait for status disable at the end.
      
      Thanks to Nishanth Menon <nm@ti.com> for contributing a fix to the
      timeout code waiting for WUCLKOUT to go high.
      Signed-off-by: default avatarVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Cc: Nishanth Menon <nm@ti.com>
      Reviewed-by: default avatarRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: renamed omap3_trigger_io_chain() to better describe the
       end result and to match other PRM functions; removed
       omap3_disable_io_chain(); moved MAX_IOPAD_LATCH_TIME to prcm-common as it
       will also be used by the OMAP4 code; removed unnecessary barrier;
       added kerneldoc; added credit for fix from Nishanth]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      09659fa7
    • Mohan V's avatar
      ARM: OMAP3: PM: correct enable/disable of daisy io chain · fe7ea006
      Mohan V authored
      Currently the enabling and disabling of IO Daisy chain is not
      according to the TRM. The below steps are followed to enable/
      disable the IO chain, based loosely on the "Sec 3.5.7.2.2
      I/O Wake-Up Mechanism" section in OMAP3630 Public TRM[1].
      
      Steps to enable IO chain:
      [a] Set PM_WKEN_WKUP.EN_IO bit
      [b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
      [c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
      [d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
      [e] Clear ST_IO_CHAIN bit.
      
      Steps to disable IO chain:
      [a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
      [b] Clear PM_WKEN_WKUP.EN_IO bit
      [c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.
      
      Step [e] & [c] in each case can be skipped, as these are handled
      by the PRCM interrupt handler later.
      
      [1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zipSigned-off-by: default avatarMohan V <mohanv@ti.com>
      Signed-off-by: default avatarVishwanath BS <vishwanath.bs@ti.com>
      [paul@pwsan.com: modified commit message to clarify that these steps are
       based loosely on the TRM section, rather than documented exactly]
      Reviewed-by: default avatarRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: resolved new warnings from checkpatch]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      fe7ea006
    • Kevin Hilman's avatar
      ARM: OMAP2+: PRM: fix compile for OMAP4-only build · 75a4433e
      Kevin Hilman authored
      For OMAP4 only builds, the omap2_prm_* functions have dummy wrappers
      to detect incorrect usage.  However, several unrelated omap3 PRM
      functions have made it inside the #else clause of the #ifdef wrapping
      the omap2_prm stubs, causing them to disappear on OMAP4-only builds.
      
      This was unnoticed until the IO chain support was added and introduced
      a new function in this section which is referenced by omap_hwmod.c:
      
      arch/arm/mach-omap2/omap_hwmod.c: In function '_reconfigure_io_chain':
      arch/arm/mach-omap2/omap_hwmod.c:1665:3: error: implicit declaration of function 'omap3xxx_prm_reconfigure_io_chain' [-Werror=implicit-function-declaration]
      
      Fix by using the #ifdef to only wrap the omap2_prm functions that
      need stubs on OMAP4-only builds.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      [paul@pwsan.com: fixed checkpatch warnings for patch description]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      75a4433e
    • Dave Airlie's avatar
      drm: drop comment about this header being autogenerated. · 59bbe27b
      Dave Airlie authored
      This comment is well out of date.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      59bbe27b
    • Ricardo Neri's avatar
      ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled · dc57aef5
      Ricardo Neri authored
      As per the OMAP4 documentation, audio over HDMI must be transmitted in
      no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
      no-idle/force-idle settings instead of smart-idle mode.
      
      This is required as the DSS interface clock is used as functional clock
      for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
      be choppy, have bad quality or not be audible at all.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri@ti.com>
      [b-cousson@ti.com: Update the subject and align the .flags
      location with the script template]
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      dc57aef5
    • Paul Walmsley's avatar
      ARM: OMAP2+: mux: fix sparse warning · 65e25976
      Paul Walmsley authored
      Commit bbd707ac ("ARM: omap2: use
      machine specific hook for late init") resulted in the addition of this
      sparse warning:
      
      arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static?
      
      Fix by including the header file containing the prototype.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Tony Lindgren <tony@atomide.com>
      65e25976
    • Paul Walmsley's avatar
      ARM: OMAP2+: CM: increase the module disable timeout · b8f15b7e
      Paul Walmsley authored
      Increase the timeout for disabling an IP block to five milliseconds.
      This is to handle the usb_host_fs idle latency, which takes almost
      four milliseconds after a host controller reset.
      
      This is the second of two patches needed to resolve the following
      boot warning:
      
      omap_hwmod: usb_host_fs: _wait_target_disable failed
      
      Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for finding
      an unrelated hunk in a previous version of this patch.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Sergei Shtylyov <sshtylyov@mvista.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      b8f15b7e
    • Paul Walmsley's avatar
      ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks · 9a47d32d
      Paul Walmsley authored
      Until the OMAP4 code is converted to disable the use of the clock
      framework-based clockdomain enable/disable sequence, any clock used as
      a hwmod main_clk must have a clockdomain associated with it.  This
      patch populates some clock structure clockdomain names to resolve the
      following warnings during kernel init:
      
      omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
      omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
      omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
      omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      9a47d32d
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: fix 32k sync timer idle modes · 252a4c54
      Paul Walmsley authored
      The 32k sync timer IP block target idle modes in the hwmod data are
      incorrect.  The IP block does not support any smart-idle modes.
      Update the data to reflect the correct modes.
      
      This problem was initially identified and a diff fragment posted to
      the lists by Benoît Cousson <b-cousson@ti.com>.  A patch description
      bug in the first version was also identified by Benoît.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      252a4c54
    • Djamil Elaidi's avatar
      ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby · 561038f0
      Djamil Elaidi authored
      If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the
      IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
      Signed-off-by: default avatarDjamil Elaidi <d-elaidi@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      561038f0
  6. 21 Jun, 2012 3 commits