1. 02 May, 2013 15 commits
  2. 15 Apr, 2013 1 commit
  3. 11 Apr, 2013 7 commits
    • Tomi Valkeinen's avatar
      drm/omap: add statics to a few structs · 6717cd29
      Tomi Valkeinen authored
      Some static structs are not marked as static. Add it.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      6717cd29
    • Archit Taneja's avatar
      drm/omap: Fix and improve crtc and overlay manager correlation · 0d8f371f
      Archit Taneja authored
      The omapdrm driver currently takes a config/module arg to figure out the number
      of crtcs it needs to create. We could create as many crtcs as there are overlay
      managers in the DSS hardware, but we don't do that because each crtc eats up
      one DSS overlay, and that reduces the number of planes we can attach to a single
      crtc.
      
      Since the number of crtcs may be lesser than the number of hardware overlay
      managers, we need to figure out which overlay managers to use for our crtcs. The
      current approach is to use pipe2chan(), which returns a higher numbered manager
      for the crtc.
      
      The problem with this approach is that it assumes that the overlay managers we
      choose will connect to the encoders the platform's panels are going to use,
      this isn't true, an overlay manager connects only to a few outputs/encoders, and
      choosing any overlay manager for our crtc might lead to a situation where the
      encoder cannot connect to any of the crtcs we have chosen. For example, an
      omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the
      current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot
      connect to the hdmi encoder at all. The only manager that could have connected
      to hdmi was the TV overlay manager.
      
      Therefore, there is a need to choose our overlay managers keeping in mind the
      panels we have on that platform. The new approach iterates through all the
      available panels, creates encoders and connectors for them, and then tries to
      get a suitable overlay manager to create a crtc which can connect to the
      encoders.
      
      We use the dispc_channel field in omap_dss_output to retrieve the desired
      overlay manager's channel number, we then check whether the manager had already
      been assigned to a crtc or not. If it was already assigned to a crtc, we assume
      that out of all the encoders which intend use this crtc, only one will run at a
      time. If the overlay manager wan't assigned to a crtc till then, we create a
      new crtc and link it with the overlay manager.
      
      This approach just looks for the best dispc_channel for each encoder. On DSS HW,
      some encoders can connect to multiple overlay managers. Since we don't try
      looking for alternate overlay managers, there is a greater possibility that 2
      or more encoders end up asking for the same crtc, causing only one encoder to
      run at a time.
      
      Also, this approach isn't the most optimal one, it can do either good or bad
      depending on the sequence in which the panels/outputs are parsed. The optimal
      way would be some sort of back tracking approach, where we improve the set of
      managers we use as we iterate through the list of panels/encoders. That's
      something left for later.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      0d8f371f
    • Archit Taneja's avatar
      drm/omap: Take a fb reference in omap_plane_update() · b03e14fd
      Archit Taneja authored
      When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
      passes control to the update_plane op defined by the drm driver.
      
      In omapdrm, we have a worker thread which queues framebuffers objects received
      from update_plane and displays them at the appropriate time.
      
      It is possible that the framebuffer is destoryed by userspace between the time
      of calling the ioctl and apply-worker being scheduled. If this happens, the
      apply-worker holds a pointer to a framebuffer which is already destroyed.
      
      Take an extra refernece/unreference of the fb in omap_plane_update() to prevent
      this from happening. A reference is taken of the fb passed to update_plane(),
      the previous framebuffer (held by plane->fb) is unreferenced. This will prevent
      drm from destroying the framebuffer till the time it's unreferenced by the
      apply-worker.
      
      This is in addition to the exisitng reference/unreference in update_pin(),
      which is taken for the scanout of the plane's current framebuffer, and an
      unreference the previous framebuffer.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b03e14fd
    • Archit Taneja's avatar
      drm/omap: Make fixed resolution panels work · bddabbe1
      Archit Taneja authored
      The omapdrm driver requires omapdss panel drivers to expose ops like detect,
      set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
      and SDI drivers. At some places, there are no checks to see if the panel driver
      has these ops or not, and that leads to a crash.
      
      The following things are done to make fixed panels work:
      
      - The omap_connector's detect function is modified such that it considers panel
        types which are generally fixed panels as always connected(provided the panel
        driver doesn't have a detect op). Hence, the connector corresponding to these
        panels is always in a 'connected' state.
      
      - If a panel driver doesn't have a check_timings op, assume that it supports the
        mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)
      
      - The function omap_encoder_update shouldn't really do anything for fixed
        resolution panels, make sure that it calls set_timings only if the panel
        driver has one.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      bddabbe1
    • Archit Taneja's avatar
      drm/omap: fix modeset_init if a panel doesn't satisfy omapdrm requirements · 581382e3
      Archit Taneja authored
      modeset_init iterates through all the registered omapdss devices and has some
      initial checks to see if the panel has a driver and the required driver ops for
      it to be usable by omapdrm.
      
      The function bails out from modeset_init if a panel doesn't meet the
      requirements, and stops the registration of the future panels and encoders which
      come after it, that isn't the correct thing to do, we should go through the rest
      of the panels. Replace the 'return's with 'continue's.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      581382e3
    • 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>
      2c6360fb
    • Tomi Valkeinen's avatar
      OMAPDSS: fix dss_fck clock rate rounding · 648a55e1
      Tomi Valkeinen authored
      DSS func clock is calculated with prate / div * m. However, the current
      omapdss code calculates it with prate * m / div, which yields a slightly
      different result when there's a remainder. For example, 432000000 / 14 *
      2 = 61714284, but 432000000 * 2 / 14 = 61714285.
      
      In addition to that, the clock framework wants the clock rate given with
      clk_set_rate to be higher than the actual (truncated) end result. So, if
      prate is 432000000, and div is 14, the real result is 30857142.8571...
      We need to call clk_set_rate with 30857143, which gives us a clock of
      30857142. That's why we need to use DIV_ROUND_UP() when calling
      clk_set_rate.
      
      This patch fixes the clock calculation.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      648a55e1
  4. 10 Apr, 2013 8 commits
  5. 03 Apr, 2013 9 commits
    • Archit Taneja's avatar
      OMAPDSS: VENC: remove platform_enable/disable calls · 77ec05d0
      Archit Taneja authored
      The platform_enable/disable callbacks in board files for VENC omap_dss_device
      instances don't do anything. Hence, we can remove these callbacks from the VENC
      driver.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      77ec05d0
    • Archit Taneja's avatar
      OMAPDSS: n8x0 panel: remove use of platform_enable/disable · af9f6c35
      Archit Taneja authored
      The n8x0 panel driver now manages the gpios required to configure the panel.
      This was previously done in panel_n8x0_data's platform_enable/disable callbacks
      defined in board files using this panel.
      
      All the board files using this panel now pass the gpio information as platform
      data via the panel_n8x0_data struct, which is needed by the panel driver to
      configure the gpios connected to the panel. Hence, the uses of
      platform_enable/disable ops can be safely removed now.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      af9f6c35
    • Archit Taneja's avatar
      OMAPDSS: n8x0 panel: handle gpio data in panel driver · 64f93897
      Archit Taneja authored
      The n8x0 panel driver leaves gpio configurations to the platform_enable and
      disable calls in the platform's board file. These should happen in the panel
      driver itself.
      
      A platform data struct called panel_n8x0_data already exists to hold gpio
      numbers and other platform data. However, the gpio requests are expected to be
      done in the board file and not the panel driver.
      
      Request all the gpios in the panel driver so that the board files which use
      the the panel don't need to do it. This will help in removing the need for the
      panel drivers to have platform related callbacks.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      64f93897
    • Archit Taneja's avatar
      OMAPDSS: picodlp panel: remove platform_enable/disable callbacks · b3fb8b98
      Archit Taneja authored
      The picodlp panel driver now manages the gpios required to configure the
      panel. This was previously done in omap_dss_device's platform_enable/disable
      callbacks defined in board files using this panel.
      
      All the board files using this panel now pass the gpio information as platform
      data via the panel_generic_dpi_data struct, which is needed by the panel driver
      to configure the gpios connected to the panel. Hence, the
      platform_enable/disable ops can be safely removed now.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      b3fb8b98
    • Archit Taneja's avatar
      OMAPDSS: picodlp panel: handle gpio data in panel driver · d52e2e75
      Archit Taneja authored
      The picodlp panel driver leaves gpio requests to the platform's board file.
      These should happen in the panel driver itself.
      
      A platform data struct called picodlp_panel_data already exists to hold gpio
      numbers and other platform data. Request all the gpios in the panel driver so
      that the board files which use the the panel don't need to do it.
      
      This will help in removing the need for the panel drivers to have platform
      related callbacks.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      d52e2e75
    • Archit Taneja's avatar
      OMAPDSS: tpo-td043: remove platform_enable/disable callbacks · 3552fb78
      Archit Taneja authored
      The tpo-td043 panel driver now manages the gpios required to configure the panel.
      This was previously done in omap_dss_device's platform_enable/disable callbacks
      defined in board files using this panel.
      
      All the board files using this panel now pass the gpio information as platform
      data via the panel_tpo_td043_data struct, which is needed by the panel driver to
      configure the gpios connected to the panel. Hence, the platform_enable/disable
      ops can be safely removed now.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      3552fb78
    • Archit Taneja's avatar
      OMAPDSS: tpo-td043 panel: handle gpios in panel driver · 7eab07e4
      Archit Taneja authored
      The tpo-td043mtea1 panel driver leaves gpio configurations to the
      platform_enable and disable calls in the platform's board file. These should
      happen in the panel driver itself.
      
      Create a platform data struct for the panel, this contains the reset gpio
      number used by the panel driver, this struct will be passed to the panel driver
      as platform data. The driver will request and configure the reset gpio rather
      than leaving it to platform callbacks in board files.
      
      This will help in removing the need for the panel drivers to have platform
      related callbacks.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      7eab07e4
    • Archit Taneja's avatar
      OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks · be9a0067
      Archit Taneja authored
      The nec-nl8048 panel driver now manages the gpios required to configure the
      panel. This was previously done in omap_dss_device's platform_enable/disable
      callbacks defined in board files using this panel.
      
      All the board files using this panel now pass the gpio information as platform
      data via the panel_nec_nl8048_data struct, which is needed by the panel driver
      to configure the gpios connected to the panel. Hence, the
      platform_enable/disable ops can be safely removed now.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      be9a0067
    • Archit Taneja's avatar
      OMAPDSS: nec-nl8048 panel: handle gpios in panel driver · 57bc6c51
      Archit Taneja authored
      The nec-nl8048hl11-01 panel driver leaves gpio configurations to the
      platform_enable and disable calls in the platform's board file. These should
      happen in the panel driver itself.
      
      Create a platform data struct for the panel, this contains the gpio numbers
      used by the panel driver, this struct will be passed to the panel driver as
      platform data. The driver will request and configure these gpios rather than
      leaving it to platform callbacks in board files.
      
      This will help in removing the need for the panel drivers to have platform
      related callbacks.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      57bc6c51