1. 26 Sep, 2012 1 commit
    • Archit Taneja's avatar
      OMAPDSS: outputs: Create and register output instances · 81b87f51
      Archit Taneja authored
      
      
      Add output structs to output driver's private data. Register output instances by
      having an init function in the probes of the platform device drivers for
      different outputs. The *_init_output for each output registers the output and
      fill up the output's plaform device, type and id fields. The *_uninit_output
      functions unregister the output.
      
      In the probe of each interface driver, the output entities are initialized
      before the *_probe_pdata() functions intentionally. This is done to ensure that
      the output entity is prepared before the panels connected to the output are
      registered. We need the output entities to be ready because OMAPDSS will try
      to make connections between overlays, managers, outputs and devices during the
      panel's probe.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      81b87f51
  2. 24 Sep, 2012 1 commit
  3. 18 Sep, 2012 3 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: alloc dssdevs dynamically · 5274484b
      Tomi Valkeinen authored
      
      
      We currently create omap_dss_devices statically in board files, and use
      those devices directly in the omapdss driver. This model prevents us
      from having the platform data (which the dssdevs in board files
      practically are) as read-only, and it's also different than what we will
      use with device tree.
      
      This patch changes the model to be in line with DT model: we allocate
      the dssdevs dynamically, and initialize them according to the data in
      the board file's dssdev (basically we memcopy the dssdev fields).
      
      The allocation and registration is done in the following steps in the
      output drivers:
      
      - Use dss_alloc_and_init_device to allocate and initialize the device.
        The function uses kalloc and device_initialize to accomplish this.
      - Call dss_copy_device_pdata to copy the data from the board file's
        dssdev
      - Use dss_add_device to register the device.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5274484b
    • Tomi Valkeinen's avatar
      OMAPDSS: register only one display device per output · 1521653c
      Tomi Valkeinen authored
      
      
      We have boards with multiple panel devices connected to the same
      physical output, of which only one panel can be enabled at one time.
      Examples of these are Overo, where you can use different daughter boards
      that have different LCDs, and 3430SDP which has an LCD and a DVI output
      and a physical switch to select the active display.
      
      These are supported by omapdss so that we add all the possible display
      devices at probe, but the displays are inactive until somebody enables
      one. At this point the panel driver starts using the DSS, thus reserving
      the physcal resource and excluding the other panels.
      
      This is problematic:
      - Panel drivers can't allocate their resources properly at probe(),
        because the resources can be shared with other panels. Thus they can
        be only reserved at enable time.
      - Managing this in omapdss is confusing. It's not natural to have
        child devices, which may not even exist (for example, a daughterboard
        that is not connected).
      
      Only some boards have multiple displays per output, and of those, only
      very few have possibility of switching the display during runtime.
      Because of the above points:
      - We don't want to make omapdss and all the panel drivers more complex
        just because some boards have complex setups.
      - Only few boards support runtime switching, and afaik even then it's
        not required. So we don't need to support runtime switching.
      
      Thus we'll change to a model where we will have only one display device
      per output and this cannot be (currently) changed at runtime. We'll
      still have the possibility to select the display from multiple options
      during boot with the default display option.
      
      This patch accomplishes the above by changing how the output drivers
      register the display device. Instead of registering all the devices
      given from the board file, we'll only register one. If the default
      display option is set, the output driver selects that display from its
      displays. If the default display is not set, or the default display is
      not one of the output's displays, the output driver selects the first
      display.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      1521653c
    • Tomi Valkeinen's avatar
      OMAPDSS: omap_dss_register_device() doesn't take display index · 8768a52f
      Tomi Valkeinen authored
      
      
      We used to have all the displays of the board in one list, and we made a
      "displayX" directory in the sysfs, where X was the index of the display
      in the list.
      
      This doesn't work anymore with device tree, as there's no single list to
      get the number from, and it doesn't work very well even with non-DT as
      we need to do some tricks to get the index nowadays.
      
      This patch changes omap_dss_register_device() so that it doesn't take
      disp_num as a parameter anymore, but uses a private increasing counter
      for the display number.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      8768a52f
  4. 07 Sep, 2012 2 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: fix set_timings · b82fe7f0
      Tomi Valkeinen authored
      
      
      set_timings function of DSS's output drivers are not consistent. Some of
      them disable the output, set the timings, and re-enable the output. Some
      set the timings on the fly, while the output is enabled. And some just
      store the given timings, so that they will be taken into use next time
      the output is enabled.
      
      We require the DISPC output to be disabled when changing the timings,
      and so we can change all the output drivers' set_timings to just store
      the given timings.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b82fe7f0
    • Tomi Valkeinen's avatar
      OMAPDSS: remove unnecessary includes · fe6a4662
      Tomi Valkeinen authored
      
      
      Remove unnecessary includes from omapdss.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      fe6a4662
  5. 22 Aug, 2012 1 commit
  6. 16 Aug, 2012 1 commit
    • Archit Taneja's avatar
      OMAPDSS: DPI: Maintain copy of number of data lines in driver data · c6b393d4
      Archit Taneja authored
      
      
      The DPI driver currently relies on the omap_dss_device struct to configure the
      number of data lines as specified by the panel. This makes the DPI interface
      driver dependent on the omap_dss_device struct.
      
      Make the DPI driver data maintain it's own data lines field. A panel driver
      is expected to call omapdss_dpi_set_data_lines() before enabling the interface.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      c6b393d4
  7. 13 Aug, 2012 3 commits
    • Archit Taneja's avatar
      OMAPDSS: DPI displays: Take care of panel timings in the driver itself · bdcae3cc
      Archit Taneja authored
      
      
      The timings maintained in omap_dss_device(dssdev->panel.timings) should be
      maintained by the panel driver itself. It's the panel drivers responsibility
      to update it if a new set of timings is to be configured. The DPI interface
      driver shouldn't be responsible of updating the panel timings, it's responsible
      of maintianing it's own copy of timings.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      bdcae3cc
    • Archit Taneja's avatar
      OMAPDSS: DPI: Maintain our own timings field in driver data · c499144c
      Archit Taneja authored
      
      
      The DPI driver currently relies on the timings in omap_dss_device struct to
      configure the DISPC accordingly. This makes the DPI interface driver dependent
      on the omap_dss_device struct.
      
      Make the DPI driver data maintain it's own timings field. The panel driver is
      expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set
      these timings before the panel is enabled.
      
      In the set_timings() op, we still ensure that the omap_dss_device timings
      (dssdev->panel.timings) are configured. This will later be configured only by
      the DPI panel drivers.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      c499144c
    • Archit Taneja's avatar
      OMAPDSS: DPI: Add locking for DPI interface · c8a5e4e8
      Archit Taneja authored
      
      
      The DPI interface driver currently relies on the panel driver to ensure calls
      like omapdss_dpi_display_enable() and omapdss_dpi_display_disable() are executed
      sequentially. Also, currently, there is no way to protect the DPI driver data.
      
      All DPI panel drivers don't ensure this, and in general, a DPI panel driver
      should use it's lock to that ensure it's own driver data and omap_dss_device
      states are taken care of, and not worry about the DPI interface.
      
      Add mutex locking in the DPI enable/disable/set_timings ops.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      c8a5e4e8
  8. 29 Jun, 2012 8 commits
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drivers · f476ae9d
      Archit Taneja authored
      
      
      Replace the DISPC fuctions used to configure LCD channel related manager
      parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that
      the DISPC registers are written at the right time by using the shadow register
      programming model.
      
      The LCD manager configurations is stored as a private data of manager in APPLY.
      It is treated as an extra info as it's the panel drivers which trigger this
      apply via interface drivers, and not a DSS2 user like omapfb or omapdrm.
      
      Storing LCD manager related properties in APPLY also prevents the need to refer
      to the panel connected to the manager for information. This helps in making the
      DSS driver less dependent on panel.
      
      A helper function is added to check whether the manager is LCD or TV. The direct
      DISPC register writes are removed from the interface drivers.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      f476ae9d
    • Archit Taneja's avatar
      OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parameters · 5cf9a264
      Archit Taneja authored
      
      
      Create a dss_lcd_mgr_config struct instance in DPI. Fill up all the parameters
      of the struct with configurations held by the panel, and the configurations
      required by DPI.
      
      Use these to write to the DISPC registers. These direct register writes would be
      later replaced by a function which applies the configuration using the shadow
      register programming model.
      
      The DISPC_DIVISORo registers were written in the functions dpi_set_dispc_clk()
      and dpi_set_dsi_clk(), now they just fill up the dispc_clock_info parameter in
      mgr_config. They are written later in dpi_config_lcd_manager.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      5cf9a264
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div() · f0d08f89
      Archit Taneja authored
      
      
      dipsc_mgr_set_clock div has an int return type to report errors or success.
      The function doesn't really check for errors and always returns 0. Change
      the return type to void.
      
      Checking for the correct DISPC clock divider ranges will be done when a DSS2
      user does a manager apply. This support will be added later.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      f0d08f89
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Remove dispc_mgr_set_pol_freq() · 0e065c79
      Archit Taneja authored
      
      
      dispc_mgr_set_pol_freq() configures the fields in the register DISPC_POL_FREQo.
      All these fields have been moved to omap_video_timings struct, and are now
      programmed in dispc_mgr_set_lcd_timings(). These will be configured when timings
      are applied via dss_mgr_set_timings().
      
      Remove dispc_mgr_set_pol_freq() and it's calls from the interface drivers.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      0e065c79
    • Archit Taneja's avatar
      OMAPDSS: Remove passive matrix LCD support (part 4) · a9105cb5
      Archit Taneja authored
      
      
      Remove configuration of Ac-bias pins
      
      Ac-bias pins need to be configured only for passive matrix displays. Remove
      acbi and acb fields in omap_dss_device and their configuration in panel
      drivers. Don't program these fields in DISP_POL_FREQo register any more.
      
      The panel driver for sharp-ls037v7dw01, and the panel config for
      Innolux AT070TN8 in generic dpi panel driver set acb to a non zero value. This
      is most likely carried over from the old omapfb driver which supported passive
      matrix displays.
      
      Cc: Thomas Weber <weber@corscience.de>
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      a9105cb5
    • Archit Taneja's avatar
      OMAPDSS: Remove passive matrix LCD support (part 3) · d21f43bc
      Archit Taneja authored
      
      
      Remove omap_lcd_display_type enum
      
      The enum omap_lcd_display_type is used to configure the lcd display type in
      DISPC. Remove this enum and always set display type to TFT by creating function
      dss_mgr_set_lcd_type_tft().
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      d21f43bc
    • Archit Taneja's avatar
      OMAPDSS: Remove passive matrix LCD support (part 2) · 5ae9eaa6
      Archit Taneja authored
      
      
      Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.
      
      We don't support passive matrix displays any more. Remove this flag from all the
      panel drivers.
      
      Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      5ae9eaa6
    • Archit Taneja's avatar
      OMAPDSS: Remove passive matrix LCD support (part 1) · 6d523e7b
      Archit Taneja authored
      
      
      Remove clock constraints related to passive matrix displays.
      
      There is a constraint (pcd_min should be 3) for passive matrix displays. Remove
      this constraint in clock divider calculations as we won't support passive
      matrix displays any more.
      
      This cleans up the functions which calculate the clock dividers with DSI's PLL
      or DSS_FCLK as the clock source.
      
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      6d523e7b
  9. 11 May, 2012 7 commits
  10. 09 May, 2012 3 commits
    • Archit Taneja's avatar
      OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled · fcc36619
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      fcc36619
    • Archit Taneja's avatar
      OMAPDSS: MANAGER: Create a function to check manager timings · b917fa39
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      b917fa39
    • Archit Taneja's avatar
      OMAPDSS: Apply manager timings instead of direct DISPC writes · 41721163
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      41721163
  11. 23 Apr, 2012 2 commits
  12. 09 Feb, 2012 1 commit
    • Russell King's avatar
      ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c · 40410715
      Russell King authored
      
      
      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: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      40410715
  13. 02 Dec, 2011 2 commits
  14. 31 Oct, 2011 1 commit
  15. 30 Sep, 2011 3 commits
    • Archit Taneja's avatar
      OMAP: DSS2: Clean up stallmode and io pad mode selection · 569969d6
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      569969d6
    • Tomi Valkeinen's avatar
      OMAP: DSS2: DISPC: rename manager related funcs · 26d9dd0d
      Tomi Valkeinen authored
      
      
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      26d9dd0d
    • Tomi Valkeinen's avatar
      OMAP: DSS2: fix clock sources on error and uninit · 5e785091
      Tomi Valkeinen authored
      
      
      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: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5e785091
  16. 14 Sep, 2011 1 commit