1. 11 5月, 2012 2 次提交
    • T
      OMAPDSS: remove uses of dss_runtime_get/put · 852f0838
      Tomi Valkeinen 提交于
      Now that the omapdss_core device is the parent for all other dss
      devices, we don't need to use the dss_runtime_get/put anymore. Instead,
      enabling omapdss_core will happen automatically when a child device is
      enabled.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      852f0838
    • T
      OMAPDSS: create DPI & SDI drivers · a57dd4fe
      Tomi Valkeinen 提交于
      We currently have separate device/driver for each DSS HW module. The DPI
      and SDI outputs are more or less parts of the DSS or DISPC hardware
      modules, but in SW it makes sense to represent them as device/driver
      pairs similarly to all the other outputs. This also makes sense for
      device tree, as each node under dss will be a platform device, and
      handling DPI & SDI somehow differently than the rest would just make the
      code more complex.
      
      This patch modifies the dpi.c and sdi.c to create drivers for the
      platform devices.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a57dd4fe
  2. 09 5月, 2012 3 次提交
    • A
      OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled · fcc36619
      Archit Taneja 提交于
      The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
      set of timings. If the panel is disabled, they do not disable and re-enable
      the interface. Currently, the manager timings are applied in hdmi_power_on()
      and dpi_set_mode() respectively, these are not called by set_timings if the
      panel is disabled.
      
      When checking overlay and manager data, the DSS driver uses the last applied
      manager timings, and not the timings held by omap_dss_device struct. Hence,
      there is a need to apply the new manager timings even if the panel is disabled.
      
      Apply the manager timings if the panel is disabled. Eventually, there should be
      one common place where the timings are applied independent of the state of the
      panel.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      fcc36619
    • A
      OMAPDSS: MANAGER: Create a function to check manager timings · b917fa39
      Archit Taneja 提交于
      Create a function dss_mgr_check_timings() which wraps around the function
      dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
      from interface drivers.
      
      dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
      takes the timings maintained in the omap_dss_device struct. This would be later
      replaced by the timings stored in the manager's private data.
      
      Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
      omap_video_timings pointer since these functions just check the timings.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      b917fa39
    • A
      OMAPDSS: Apply manager timings instead of direct DISPC writes · 41721163
      Archit Taneja 提交于
      Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
      interface drivers. The latter function ensures that the timing related DISPC
      registers are configured according to the shadow register programming model.
      
      Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit
      is set by dss_mgr_set_timings().
      Signed-off-by: NArchit Taneja <archit@ti.com>
      41721163
  3. 23 4月, 2012 2 次提交
  4. 10 2月, 2012 1 次提交
    • R
      ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c · 40410715
      Russell King 提交于
      When a PMIC is not found, this driver is unable to obtain its
      'vdds_dsi_reg' regulator.  Even through its initialization function
      fails, other code still calls its enable function, which fails to
      check whether it has this regulator before asking for it to be enabled.
      
      This fixes the oops, however a better fix would be to sort out the
      upper layers to prevent them calling into a module which failed to
      initialize.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000038
      pgd = c0004000
      [00000038] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT
      Modules linked in:
      CPU: 0    Not tainted  (3.3.0-rc2+ #228)
      PC is at regulator_enable+0x10/0x70
      LR is at omapdss_dpi_display_enable+0x54/0x15c
      pc : [<c01b9a08>]    lr : [<c01af994>]    psr: 60000013
      sp : c181fd90  ip : c181fdb0  fp : c181fdac
      r10: c042eff0  r9 : 00000060  r8 : c044a164
      r7 : c042c0e4  r6 : c042bd60  r5 : 00000000  r4 : c042bd60
      r3 : c084de48  r2 : c181e000  r1 : c042bd60  r0 : 00000000
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5387d  Table: 80004019  DAC: 00000015
      Process swapper (pid: 1, stack limit = 0xc181e2e8)
      Stack: (0xc181fd90 to 0xc1820000)
      fd80:                                     c001754c c042bd60 00000000 c042bd60
      fda0: c181fdcc c181fdb0 c01af994 c01b9a04 c0016104 c042bd60 c042bd60 c044a338
      fdc0: c181fdec c181fdd0 c01b5ed0 c01af94c c042bd60 c042bd60 c1aa8000 c1aa8a0c
      fde0: c181fe04 c181fdf0 c01b5f54 c01b5ea8 c02fc18c c042bd60 c181fe3c c181fe08
      fe00: c01b2a18 c01b5f48 c01aed14 c02fc160 c01df8ec 00000002 c042bd60 00000003
      fe20: c042bd60 c1aa8000 c1aa8a0c c042eff8 c181fe84 c181fe40 c01b3874 c01b29fc
      fe40: c042eff8 00000000 c042f000 c0449db8 c044ed78 00000000 c181fe74 c042eff8
      fe60: c042eff8 c0449db8 c0449db8 c044ed78 00000000 00000000 c181fe94 c181fe88
      fe80: c01e452c c01b35e8 c181feb4 c181fe98 c01e2fdc c01e4518 c042eff8 c0449db8
      fea0: c0449db8 c181fef0 c181fecc c181feb8 c01e3104 c01e2f48 c042eff8 c042f02c
      fec0: c181feec c181fed0 c01e3190 c01e30c0 c01e311c 00000000 c01e311c c0449db8
      fee0: c181ff14 c181fef0 c01e1998 c01e3128 c18330a8 c1892290 c04165e8 c0449db8
      ff00: c0449db8 c1ab60c0 c181ff24 c181ff18 c01e2e28 c01e194c c181ff54 c181ff28
      ff20: c01e2218 c01e2e14 c039afed c181ff38 c04165e8 c041660c c0449db8 00000013
      ff40: 00000000 c03ffdb8 c181ff7c c181ff58 c01e384c c01e217c c181ff7c c04165e8
      ff60: c041660c c003a37c 00000013 00000000 c181ff8c c181ff80 c01e488c c01e3790
      ff80: c181ff9c c181ff90 c03ffdcc c01e484c c181ffdc c181ffa0 c0008798 c03ffdc4
      ffa0: c181ffc4 c181ffb0 c0056440 c0187810 c003a37c c04165e8 c041660c c003a37c
      ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03ea284 c0008708
      ffe0: 00000000 c03ea208 00000000 c181fff8 c003a37c c03ea214 1073cec0 01f7ee08
      Backtrace:
      [<c01b99f8>] (regulator_enable+0x0/0x70) from [<c01af994>] (omapdss_dpi_display_enable+0x54/0x15c)
       r6:c042bd60 r5:00000000 r4:c042bd60
      [<c01af940>] (omapdss_dpi_display_enable+0x0/0x15c) from [<c01b5ed0>] (generic_dpi_panel_power_on+0x34/0x78)
       r6:c044a338 r5:c042bd60 r4:c042bd60
      [<c01b5e9c>] (generic_dpi_panel_power_on+0x0/0x78) from [<c01b5f54>] (generic_dpi_panel_enable+0x18/0x28)
       r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:c042bd60
      [<c01b5f3c>] (generic_dpi_panel_enable+0x0/0x28) from [<c01b2a18>] (omapfb_init_display+0x28/0x150)
       r4:c042bd60
      [<c01b29f0>] (omapfb_init_display+0x0/0x150) from [<c01b3874>] (omapfb_probe+0x298/0x318)
       r8:c042eff8 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:00000003
      [<c01b35dc>] (omapfb_probe+0x0/0x318) from [<c01e452c>] (platform_drv_probe+0x20/0x24)
      [<c01e450c>] (platform_drv_probe+0x0/0x24) from [<c01e2fdc>] (really_probe+0xa0/0x178)
      [<c01e2f3c>] (really_probe+0x0/0x178) from [<c01e3104>] (driver_probe_device+0x50/0x68)
       r7:c181fef0 r6:c0449db8 r5:c0449db8 r4:c042eff8
      [<c01e30b4>] (driver_probe_device+0x0/0x68) from [<c01e3190>] (__driver_attach+0x74/0x98)
       r5:c042f02c r4:c042eff8
      [<c01e311c>] (__driver_attach+0x0/0x98) from [<c01e1998>] (bus_for_each_dev+0x58/0x98)
       r6:c0449db8 r5:c01e311c r4:00000000
      [<c01e1940>] (bus_for_each_dev+0x0/0x98) from [<c01e2e28>] (driver_attach+0x20/0x28)
       r7:c1ab60c0 r6:c0449db8 r5:c0449db8 r4:c04165e8
      [<c01e2e08>] (driver_attach+0x0/0x28) from [<c01e2218>] (bus_add_driver+0xa8/0x22c)
      [<c01e2170>] (bus_add_driver+0x0/0x22c) from [<c01e384c>] (driver_register+0xc8/0x154)
      [<c01e3784>] (driver_register+0x0/0x154) from [<c01e488c>] (platform_driver_register+0x4c/0x60)
       r8:00000000 r7:00000013 r6:c003a37c r5:c041660c r4:c04165e8
      [<c01e4840>] (platform_driver_register+0x0/0x60) from [<c03ffdcc>] (omapfb_init+0x14/0x34)
      [<c03ffdb8>] (omapfb_init+0x0/0x34) from [<c0008798>] (do_one_initcall+0x9c/0x164)
      [<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03ea284>] (kernel_init+0x7c/0x120)
      [<c03ea208>] (kernel_init+0x0/0x120) from [<c003a37c>] (do_exit+0x0/0x2d8)
       r5:c03ea208 r4:00000000
      Code: e1a0c00d e92dd870 e24cb004 e24dd004 (e5906038)
      ---[ end trace 9e2474c2e193b223 ]---
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      40410715
  5. 02 12月, 2011 2 次提交
  6. 01 11月, 2011 1 次提交
  7. 30 9月, 2011 3 次提交
    • A
      OMAP: DSS2: Clean up stallmode and io pad mode selection · 569969d6
      Archit Taneja 提交于
      Split the function dispc_set_parallel_interface_mode() into 2 separate
      functions called dispc_mgr_set_io_pad_mode() and dispc_mgr_enable_stallmode().
      The current function tries to set 2 different modes(io pad mode and stall mode)
      based on a parameter omap_parallel_interface_mode which loosely corresponds to
      the panel interface type.
      
      This isn't correct because a) these 2 modes are independent to some extent,
      b) we are currently configuring gpout0/gpout1 for DSI panels which is
      unnecessary, c) a DSI Video mode panel won't get configured correctly.
      
      Splitting the functions allows the interface driver to set these modes
      independently and hence allow more flexibility.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      569969d6
    • T
      OMAP: DSS2: DISPC: rename manager related funcs · 26d9dd0d
      Tomi Valkeinen 提交于
      Rename dispc's manager related functions as follows:
      
      - Remove prepending underscores, which were originally used to inform
        that the clocks needs to be enabled. This meaning is no longer valid.
      - Prepend the functions with dispc_mgr_*
      - Remove "channel" from the name, e.g. dispc_enable_channel ->
        dispc_mgr_enable
      
      The idea is to group manager related functions so that it can be deduced
      from the function name that it writes to manager spesific registers.
      
      All dispc_mgr_* functions have enum omap_channel as the first parameter.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      26d9dd0d
    • T
      OMAP: DSS2: fix clock sources on error and uninit · 5e785091
      Tomi Valkeinen 提交于
      DPI and DSI were not cleaning up the clock source in error or uninit
      cases. Set the clock source back to PRCM.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5e785091
  8. 14 9月, 2011 1 次提交
  9. 25 7月, 2011 2 次提交
  10. 13 5月, 2011 3 次提交
  11. 11 5月, 2011 5 次提交
  12. 11 3月, 2011 5 次提交
  13. 10 1月, 2011 3 次提交
  14. 24 2月, 2010 4 次提交
  15. 15 2月, 2010 1 次提交
    • T
      OMAP: DSS2: improve DSS clk src selection · 2f18c4d8
      Tomi Valkeinen 提交于
      dss_select_clk_source() was rather confusing. Selecting the source with
      enums is much clearer.
      
      The clk source selection is also stored into memory, so that we know what
      is the selected source, even when clocks are off. This is important during
      setup, as we need to what clocks to turn on before the clocks are turned
      on.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      2f18c4d8
  16. 12 2月, 2010 1 次提交
    • T
      OMAP: DSS2: enable VDDS_DSI when using DPI · 8a2cfea8
      Tomi Valkeinen 提交于
      It looks like on OMAP3 some DSS pins need VDDS_DSI to function properly.
      
      This has not been confirmed from TI, but looking at figure 15-1 "Display
      subsystem highlight" from the TRM, some data pins come near the DSI and SDI
      blocks. This is not very hard evidence, but the fact remains that with the
      power on, pixels are ok, and with the power off, pixels are not ok.
      
      It may also be that VDDS_SDI is needed to power some pins, but as normally
      both VDDS_SDI and VDDS_DSI come from the same power source, this hasn't
      been shown.
      
      It seems that a single driver can only get a regulator once. This patch
      solves it by getting all the required regulators in one place, and from
      which the submodules then get the regulators they need.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      8a2cfea8
  17. 09 12月, 2009 1 次提交