1. 14 12月, 2011 1 次提交
  2. 13 12月, 2011 1 次提交
  3. 24 11月, 2011 6 次提交
  4. 08 11月, 2011 12 次提交
    • 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: OMAP2/3: HWMOD: Add SYSS_HAS_RESET_STATUS for dss · 3ce32676
      Tomi Valkeinen 提交于
      OMAP2/3 dss_core has a reset status flag in sysstatus register. Add
      SYSS_HAS_RESET_STATUS flag to HWMOD data so it can be used.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3ce32676
    • 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
    • T
      ARM: OMAP3: HWMOD: fix DSS clock data · 6c3d7e34
      Tomi Valkeinen 提交于
      The OMAP3 HWMOD data currently contains these errors with DSS clocks:
      
      - dss_rfbi is missing ick opt-clock, which is needed for RFBI to
        calculate timings
      
      - dss_dsi is missing ick and sys_clk
      
      - dss_venc is missing dss_96m_fck opt-clock, which is required on
        OMAP3430
      
      - dss_venc's interface and main clocks are wrong, causing VENC to fail
        to start
      
      These problems were temporarily fixed with a DSS patch
      9ede365a ("HACK: OMAP: DSS2: clk hack
      for OMAP2/3"), which can be reverted after this patch (and the similar
      patches for other OMAPs).
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6c3d7e34
    • T
      ARM: OMAP3: HWMOD: Fix DSS reset · 8c3105ca
      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 hasn't caused any problems so far, but
      we may just have been lucky.
      
      dss_core's opt-clocks is also missing dss_96m_fck, which is a DSS clock
      present only on OMAP3430, and thus required on OMAP3430 to finish the
      reset.
      
      This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET and adds the dss_96m_fck
      opt-clock for dss_core in OMAP3 HWMOD data, fixing the issue.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      [paul@pwsan.com: merged duplicate .flags fields]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      8c3105ca
    • T
      ARM: OMAP2xxx: HWMOD: fix DSS clock data · b8ac10d8
      Tomi Valkeinen 提交于
      The OMAP2xxx HWMOD data currently contains two errors with DSS clocks:
      
      - dss_rfbi is missing ick opt-clock, which is needed for RFBI to
        calculate timings
      
      - dss_venc's interface and main clocks are wrong, causing VENC to fail
        to start
      
      These problems were temporarily fixed with a DSS patch
      9ede365a ("HACK: OMAP: DSS2: clk hack
      for OMAP2/3"), which can be reverted after this patch (and the similar
      patches for other OMAPs).
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b8ac10d8
    • T
      ARM: OMAP2xxx: HWMOD: Fix DSS reset · 1258ea59
      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 hasn't caused any problems so far, but
      we may just have been lucky.
      
      This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core in OMAP2xxx
      HWMOD data, fixing the issue.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      [paul@pwsan.com: merged duplicate .flags fields]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      1258ea59
    • K
      ARM: OMAP3: CPUidle: include <linux/export.h> · 5698eb4e
      Kevin Hilman 提交于
      The CPUidle use THIS_MODULE, so needs <linux/export.h>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      5698eb4e
    • T
      ARM: OMAP: Fix export.h or module.h includes · a1bcc1dc
      Tony Lindgren 提交于
      Commit 32aaeffb (Merge branch
      'modsplit-Oct31_2011'...) caused some build errors. Fix these
      and make sure we always have export.h or module.h included
      for MODULE_ and EXPORT_SYMBOL users:
      
      $ grep -rl ^MODULE_ arch/arm/*omap*/*.c | xargs \
        grep -L linux/module.h
        arch/arm/mach-omap2/dsp.c
        arch/arm/mach-omap2/mailbox.c
        arch/arm/mach-omap2/omap-iommu.c
        arch/arm/mach-omap2/smartreflex.c
      
      Also check we either have export.h or module.h included
      for the files exporting symbols:
      
      $ grep -rl EXPORT_SYMBOL arch/arm/*omap*/*.c | xargs \
        grep -L linux/export.h | xargs grep -L linux/module.h
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a1bcc1dc
  5. 07 11月, 2011 3 次提交
  6. 05 11月, 2011 12 次提交
  7. 01 11月, 2011 2 次提交
  8. 24 10月, 2011 2 次提交
  9. 23 10月, 2011 1 次提交
    • M
      ARM: gic: consolidate PPI handling · 292b293c
      Marc Zyngier 提交于
      PPI handling is a bit of an odd beast. It uses its own low level
      handling code and is hardwired to the local timers (hence lacking
      a registration interface).
      
      Instead, switch the low handling to the normal SPI handling code.
      PPIs are handled by the handle_percpu_devid_irq flow.
      
      This also allows the removal of some duplicated code.
      
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Bryan Huntsman <bryanh@codeaurora.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NDavid Brown <davidb@codeaurora.org>
      Tested-by: NDavid Brown <davidb@codeaurora.org>
      Tested-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      292b293c