1. 02 May, 2013 1 commit
  2. 11 Apr, 2013 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: widen the pck search when using dss fck · 2c6360fb
      Tomi Valkeinen authored
      When not using DSI PLL to generate the pixel clock, but DSS FCK, the
      possible pixel clock rates are rather limited. DSS FCK is currently used
      on OMAP2 and OMAP3.
      When using Beagleboard with a monitor that supports high resolutions,
      the clock rates do not match (at least for me) for the monitor's pixel
      clocks within the current threshold in the code, which is +/- 1MHz.
      This patch widens the search up to +/- 15MHz. The search is done in
      steps, i.e. it first tries to find a rather exact clock, than a bit less
      exact, etc. so this should not change the cases where a clock was
      already found.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
  3. 03 Apr, 2013 5 commits
  4. 13 Dec, 2012 1 commit
    • Tomi Valkeinen's avatar
      OMAPDSS: fix TV-out issue with DSI PLL · bd0f5cc3
      Tomi Valkeinen authored
      Commit 0e8276ef
       (OMAPDSS: DPI: always
      use DSI PLL if available) made dpi.c use DSI PLL for its clock. This
      works fine, for DPI, but has a nasty side effect on OMAP3:
      On OMAP3 the same clock is used for DISPC fclk and LCD output. Thus,
      after the above patch, DSI PLL is used for DISPC and LCD output. If
      TV-out is used, the TV-out needs DISPC. And if DPI is turned off, the
      DSI PLL is also turned off, disabling DISPC.
      For this to work, we'd need proper DSS internal clock handling, with
      refcounts, which is a non-trivial project.
      This patch fixes the issue for now by disabling the use of DSI PLL for
      DPI on OMAP3.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
  5. 07 Dec, 2012 2 commits
  6. 27 Nov, 2012 1 commit
  7. 05 Nov, 2012 4 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: always use DSI PLL if available · 0e8276ef
      Tomi Valkeinen authored
      We currently get the decision whether to use PRCM or DSI PLL clock for
      DPI from the board file. This is not a good way to handle it, and it
      won't work with device tree.
      This patch changes DPI to always use DSI PLL if it's available.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: verify if DSI PLL is operational · 6061675b
      Tomi Valkeinen authored
      The SoCs that have DSI module should have a working DSI PLL. However,
      some rare boards have not connected the powers to the DSI PLL.
      This patch adds a function that tries to power up the DSI PLL, and
      reports if that doesn't succeed. DPI uses this function to fall back to
      PRCM clocks if DSI PLL doesn't work.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll · 8a3db406
      Tomi Valkeinen authored
      Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we
      can just check if dpi.dsidev != NULL.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • Tomi Valkeinen's avatar
      OMAPDSS: hide dss_select_dispc_clk_source() · a5b8399f
      Tomi Valkeinen authored
      dss.c currently exposes functions to configure the dispc source clock
      and lcd source clock. There are configured separately from the output
      However, there is no safe way for the output drivers to handle dispc
      clock, as it's shared between the outputs. Thus, if, say, the DSI driver
      sets up DSI PLL and configures both the dispc and lcd clock sources to
      that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
      Thus the output drivers should really only be concerned about the lcd
      clock, which is what the output drivers actually use. There's lot to do
      to clean up the dss clock handling, but this patch takes one step
      forward and removes the use of dss_select_dispc_clk_source() from the
      output drivers.
      After this patch, the output drivers only configure the lcd source
      clock. On omap4+ the dispc src clock is never changed from the default
      PRCM source. On omap3, where the dispc and lcd clocks are actually the
      same, setting the lcd clock source sets the dispc clock source.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
  8. 29 Oct, 2012 1 commit
  9. 28 Sep, 2012 1 commit
  10. 26 Sep, 2012 2 commits
    • Archit Taneja's avatar
      OMAPDSS: DPI: Replace dssdev->manager with dssdev->output->manager references · 5d512fcd
      Archit Taneja authored
      With addition of output entities, a device connects to an output, and an output
      connects to overlay manager. Replace the dssdev->manager references with
      dssdev->output->manager to access the manager correctly.
      When enabling the DPI output, check whether the output entity connected to
      display is not NULL.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • 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>
  11. 24 Sep, 2012 1 commit
  12. 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
      - Use dss_add_device to register the device.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • 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
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
    • 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>
  13. 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>
    • 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>
  14. 22 Aug, 2012 1 commit
  15. 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>
  16. 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>
    • 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>
    • 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>
  17. 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    • 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>
    • 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>
  18. 11 May, 2012 2 commits