1. 05 Nov, 2012 8 commits
    • 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>
      8a3db406
    • 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
      drivers.
      
      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>
      a5b8399f
    • Tomi Valkeinen's avatar
      OMAPDSS: setup default dss fck · 13a1a2b2
      Tomi Valkeinen authored
      We don't currently set the dss fck when starting up. This is not a
      problem, as we setup the fck later when configuring the pixel clocks. Or
      this is how it was for omap2, for the rest of the omaps this may not be
      so.
      
      For DSI, HDMI and also for DPI when using DSI PLL, we don't need to
      change the dss fck, and thus it may be left unconfigured. Usually the
      dss fck is already setup fine by default, but we can't trust this.
      
      This patch sets the dss fck to maximum at probe time.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      13a1a2b2
    • Tomi Valkeinen's avatar
      OMAPDSS: add dss_calc_clock_rates() back · 930b027e
      Tomi Valkeinen authored
      dss_calc_clock_rates() was removed earlier as it was not used, but it is
      needed for DSI PLL calculations, so this patch adds it back.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      930b027e
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: workaround for HSDiv problem · 7a98786c
      Tomi Valkeinen authored
      It looks like on many OMAP versions powers for both HSClk and HSDiv to
      be enabled to have a functional HSDiv.
      
      This patch fixes the issue by forcing both powers on.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      7a98786c
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: skip odd dividers when pck >= 100MHz · b7f1fe54
      Tomi Valkeinen authored
      The DSI PLL and HSDivider can be used to generate the pixel clock for
      LCD overlay manager, which then goes to DPI output. On the DPI output
      pin the voltage of the signal is shifted from the OMAP's internal
      minimal voltage to 1.8V range. The shifting is not instant, and the
      higher the clock frequency, the less time there is to shift the signal
      to nominal voltage.
      
      If the HSDivider's divider is greater than one and odd, the resulting
      pixel clock does not have 50% duty cycle. For example, with a divider of
      3, the duty cycle is 33%.
      
      When combining high frequency (in the area of 140MHz+) and non-50% duty
      cycle, it has been observed the the shifter does not have enough time to
      shift the voltage enough, and this leads to bad signal which is rejected
      by monitors.
      
      As a workaround this patch makes the divider calculation skip all odd
      dividers when the required pixel clock is over 100MHz. The limit of
      100MHz is a guesstimate.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b7f1fe54
    • Tomi Valkeinen's avatar
      OMAPDSS: fix DPI & DSI init order · 046bc575
      Tomi Valkeinen authored
      DPI may use DSI PLL, so it depends on DSI. However, currently DPI driver
      is added first, which causes DPI initialization to fail when it tries to
      get the DSI PLL.
      
      This patch changes the init order to fix this.
      
      A better solution would be to separate DSI PLL and DSI drivers. They
      have dependencies, though, but we could still have DSI PLL as an
      independent entity that we could initialize before any of the output
      drivers.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      046bc575
    • Tomi Valkeinen's avatar
      Merge branch '3.8/misc-2' · 9296dbd7
      Tomi Valkeinen authored
      Merge omapdss miscellaneous patches.
      9296dbd7
  2. 29 Oct, 2012 17 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: split hdmi muxing function · ffc81fc5
      Tomi Valkeinen authored
      Split the omap4_hdmi_mux_pads() function into two parts, one handles the
      tpd12s015 gpio muxing, the other handles the hdmi pins.
      
      This is clearer, as hdmi and tpd12s015 are separate devices, and it also
      allows us to mux those separately with DT.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ricardo Neri <ricardo.neri@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      ffc81fc5
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: remove dssdev depependency from error handler · b276dd09
      Tomi Valkeinen authored
      The dispc error handler tries to "fix" issues by disabling and enabling
      panel. This is problematic, as we're trying to remove the dependency
      from omapdss to the omap_dss_devices. It's also racy, and doesn't really
      fix anything.
      
      This patch removes the use of omap_dss_device from the error handler,
      and just disables and enables the associated overlay manager. This
      should produce similar results as the previous solution, without using
      dssdev.
      
      However, the error handling is still horrible. But the problem boils
      down to one question, to which I don't have a clear answer: what to do
      when a HW error happens?
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b276dd09
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: fix loop in error handler · 4c6c65b0
      Tomi Valkeinen authored
      The dispc's error handler has a loop inside another loop, and both use
      the same loop variable. This is clearly wrong, and this patch makes a
      new variable for the inner loop.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      4c6c65b0
    • Tomi Valkeinen's avatar
      OMAPDSS: fix DSI2 PLL clk names · 901e5fe5
      Tomi Valkeinen authored
      dss_generic_clk_source_names is missing the names for clocks from DSI2
      PLL. Add them.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      901e5fe5
    • Tomi Valkeinen's avatar
      OMAPFB: improve mode selection from EDID · 5e18e352
      Tomi Valkeinen authored
      The current omapfb code goes over all the modes found from the monitors
      EDID data, and searches for a mode that is compatible with the DSS
      hardware and has the highest x-res.
      
      While this works ok as such, it proves problematic when using DSI PLL
      for pixel clock. Calculating DSI PLL dividers is not the fastest of the
      operations, and while doing it for one mode is usually ok, doing it for
      20 modes is noticable.
      
      Also, the first mode given in the EDID data should be the native mode of
      the monitor, and thus also the best mode, so if that can be used, no
      need to look further.
      
      This patch changes the code to use the first mode that is compatible
      with the DSS hardware.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5e18e352
    • Tomi Valkeinen's avatar
      OMAPFB: remove use of extended edid block · 2b5c0d4f
      Tomi Valkeinen authored
      It seems that using the second EDID block causes more problems than is
      of any help. The first mode in the extended block will get
      FB_MODE_IS_FIRST set, which will override the first mode from the first
      EDID block, thus making the default videomode selection not to work
      properly.
      
      This patch removes the use of the extended edid block for now.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      2b5c0d4f
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: make hdmi pclk check more permissive · f236b892
      Tomi Valkeinen authored
      The hdmi driver tries to find the given video timings from its static
      list of timings, to find the required ID for the mode. The check tries
      to find exact match for the pixel clock, among other checks.
      
      with omapfb driver there can be some amount of error in the give pixel
      clock, as the pixel clock is converted between Hz and ps, thus the
      hdmi's check fails to find the mode.
      
      This patch makes the check more allowing, by rounding the pixel clocks
      to nearest MHz.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ricardo Neri <ricardo.neri@ti.com>
      f236b892
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: add 1920x1200 video mode · 7a7ce2c7
      Tomi Valkeinen authored
      Add 1920x1200 video mode to hdmi driver's static modelist.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ricardo Neri <ricardo.neri@ti.com>
      7a7ce2c7
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: use core power on/off with edid & detect · 4489823c
      Tomi Valkeinen authored
      This patch makes use of the hdmi_power_[on|off]_core() functions added
      in the previous patch. The functions are used when reading EDID or
      detecting if a monitor is connected.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ricardo Neri <ricardo.neri@ti.com>
      4489823c
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: split power_on/off to two parts · bb426fc9
      Tomi Valkeinen authored
      There's currently just one power-on function for HDMI, which enables the
      IP and the video output. When reading EDID or detecting if a monitor is
      connected, we don't need the video output.
      
      Enabling the video output for these operations is not a big problem in
      itself, but the quick enable/disable cycles caused by the operations
      seem to cause sync lost errors from time to time. Also, this makes it
      possible to read the EDID before the full video path has been set up.
      
      This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
      and hdmi_power_on_full. The "full" version does what hdmi_power_on does
      currently, and hdmi_power_on_core only enables the core IP. Similar
      changes are made for power_off.
      
      Note that these don't allow the HDMI IP to be first enabled, and later
      enable the video output, but the HDMI IP will first need to be powered
      off before calling the full version. So this is rather limited
      implementation, but it fills the needs for reading EDID.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ricardo Neri <ricardo.neri@ti.com>
      bb426fc9
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: Add IRQ enable/status helpers · 4e0397cf
      Tomi Valkeinen authored
      DISPC irqs need to be handled from the compat layer and also in the
      future by the omapdrm. To make this possible, this patchs adds a set of
      helper functions, so that the irqs can be managed without direct
      register reads/writes.
      
      The following functions are added, and all the current direct reg
      reads/writes are changed to use these.
      
      u32 dispc_read_irqstatus(void);
      void dispc_clear_irqstatus(u32 mask);
      u32 dispc_read_irqenable(void);
      void dispc_write_irqenable(u32 mask);
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      4e0397cf
    • Tomi Valkeinen's avatar
      OMAPDSS: add dispc_ovl_enabled() · 04bd8ac1
      Tomi Valkeinen authored
      Add new dispc function, dispc_ovl_enabled(). This returns if the overlay
      enable bit is set in the registers.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      04bd8ac1
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: make _enable_mgr_out public as "dispc_mgr_enable" · f1a813d3
      Tomi Valkeinen authored
      We need a low level manager-enable function for omapdrm. We have that
      function as dispc internal func, _enable_mgr_out().
      
      This patch exposes that function, and renames it to dispc_mgr_enable().
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      f1a813d3
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: rename dispc_mgr_enable/disable to _sync · 3a979f8a
      Tomi Valkeinen authored
      The current dispc_mgr_enable/disable function are blocking, and do a bit
      too much for omapdrm. We'll expose new enable & disable functions that
      will just set the bits in the registers in the following patches.
      
      This patch renames the current functions to *_sync, to make it clear
      that they are blocking, and also to free up the dispc_mgr_enable/disable
      names for these new functions.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      3a979f8a
    • Tomi Valkeinen's avatar
      OMAPDSS: DISPC: use dss_feat_get_num_ovls() · 392faa0e
      Tomi Valkeinen authored
      Use dss_feat_get_num_ovls() in dispc.c instead of
      omap_dss_get_num_overlays() to remove the dependency to overlay.c. Note
      that we still have uses of omap_dss_get_num_overlays() in dispc.c, but
      these will be moved out in the future patches.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      392faa0e
    • Tomi Valkeinen's avatar
      OMAPDSS: remove initial display code from omapdss · 5d89bcc3
      Tomi Valkeinen authored
      Currently omapdss driver sets up the initial connections between
      overlays, overlay manager and a panel, based on default display
      parameter coming from the board file or via module parameters.
      
      This is unnecessary, as it's the higher level component that should
      decide what display to use and how. This patch removes the code from
      omapdss, and implements similar code to omapfb.
      
      The def_disp module parameter and the default display platform_data
      parameter are kept in omapdss, but omapdss doesn't do anything with
      them. It will just return the default display name with
      dss_get_default_display_name() call, which omapfb uses. This is done to
      keep the backward compatibility.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5d89bcc3
    • Tomi Valkeinen's avatar
      OMAPDSS: export dss_get_def_display_name() · 2bbcce5e
      Tomi Valkeinen authored
      Export dss_get_def_display_name() with the name of
      omapdss_get_def_display_name() so that omapfb can use it after the next
      patch which moves default display handling to omapfb.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      2bbcce5e
  3. 24 Oct, 2012 4 commits
  4. 22 Oct, 2012 2 commits
  5. 18 Oct, 2012 9 commits