1. 22 Aug, 2012 7 commits
  2. 17 Aug, 2012 1 commit
    • Tomi Valkeinen's avatar
      Merge output work from Archit · 60548a2b
      Tomi Valkeinen authored
      The series removes bunch of dssdev references from the omapdss output drivers.
      This is made to let us move to a common panel framework later, and also allows
      us to implement OMAP's writeback support, which has been proven difficult with
      the current output drivers.
      
      OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings
      OMAPDSS: DPI: Add locking for DPI interface
      OMAPDSS: Displays: Add locking in generic DPI panel driver
      OMAPDSS: DPI: Maintain our own timings field in driver data
      OMAPDSS: DPI displays: Take care of panel timings in the driver itself
      OMAPDSS: DSI: Maintain own copy of timings in driver data
      OMAPDSS: DSI: Add function to set panel size for command mode panels
      OMAPDSS: DSI: Update manager timings on a manual update
      OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings
      OMAPDSS: HDMI: Add locking for hdmi interface set timing functions
      OMAPDSS: SDI: Create a function to set timings
      OMAPDSS: SDI: Maintain our own timings field in driver data
      OMAPDSS: VENC: Split VENC into interface and panel driver
      OMAPDSS: VENC: Maintain our own timings field in driver data
      OMAPDSS: RFBI: Remove partial update support
      OMAPDSS: RFBI: Add function to set panel size
      OMAPDSS: DSI: Maintain copy of pixel format in driver data
      OMAPDSS: RFBI: Maintain copy of pixel size in driver data
      OMAPDSS: RFBI: Maintain copy of number of data lines in driver data
      OMAPDSS: DPI: Maintain copy of number of data lines in driver data
      OMAPDSS: SDI: Maintain copy of data pairs in driver data
      OMAPDSS: DSI: Maintain copy of operation mode in driver data
      OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings
      OMAPDSS: DSI: Maintain copy of video mode timings in driver data
      OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data
      OMAPDSS: VENC: Maintain copy of venc type in driver data
      OMAPDSS: VENC: Maintian copy of video output polarity info in private data
      60548a2b
  3. 16 Aug, 2012 11 commits
    • Archit Taneja's avatar
      OMAPDSS: VENC: Maintian copy of video output polarity info in private data · 89e71956
      Archit Taneja authored
      The VENC driver currently relies on the omap_dss_device struct to configure the
      video output polarity. This makes the VENC interface driver dependent on the
      omap_dss_device struct.
      
      Make the VENC driver data maintain it's own polarity field. A panel driver
      is expected to call omapdss_venc_invert_vid_out_polarity() before enabling the
      interface.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      89e71956
    • Archit Taneja's avatar
      OMAPDSS: VENC: Maintain copy of venc type in driver data · febe2905
      Archit Taneja authored
      The VENC driver currently relies on the omap_dss_device struct to configure the
      venc type. This makes the VENC interface driver dependent on the omap_dss_device
      struct.
      
      Make the VENC driver data maintain it's own 'venc type' field. A panel driver
      is expected to call omapdss_venc_set_type() before enabling the interface or
      changing the type via display sysfs attributes.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      febe2905
    • Archit Taneja's avatar
      OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data · 6e883324
      Archit Taneja authored
      The RFBI driver currently relies on the omap_dss_device struct to receive the
      rfbi specific timings requested by the panel driver. This makes the RFBI
      interface driver dependent on the omap_dss_device struct.
      
      Make the RFBI driver data maintain it's own rfbi specific timings field. The
      panel driver is expected to call omapdss_rfbi_set_interface_timings() to
      configure the rfbi timings before the interface is enabled.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      6e883324
    • Archit Taneja's avatar
      OMAPDSS: DSI: Maintain copy of video mode timings in driver data · 0b3ffe39
      Archit Taneja authored
      The DSI driver currently relies on the omap_dss_device struct to receive the
      video mode timings requested by the panel driver. This makes the DSI interface
      driver dependent on the omap_dss_device struct.
      
      Make the DSI driver data maintain it's own video mode timings field. The panel
      driver is expected to call omapdss_dsi_set_videomode_timings() to configure the
      video mode timings before the interface is enabled.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      0b3ffe39
    • Archit Taneja's avatar
      OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings · 6b849375
      Archit Taneja authored
      The struct omap_dss_dsi_videomode_data holds fields which need to be configured
      for DSI to operate in video mode. Rename the struct to dsi_videomode_timings.
      
      One reason to do this is because most of the fields in the struct are timings
      related. The other reason is to create a generic op for output specific
      timings. This generic op can be considered as a way to set custom or private
      timings for the output.
      
      In the case of OMAP, DSI and RFBI require some more timings apart from the
      relgular DISPC timings. The structs omap_dss_videomode_timings and rfbi_timings
      can be considered as these output specific timings respectively.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      6b849375
    • Archit Taneja's avatar
      OMAPDSS: DSI: Maintain copy of operation mode in driver data · dca2b152
      Archit Taneja authored
      The DSI driver currently relies on the omap_dss_device struct to know the mode
      of operation of the DSI protocol(command or video mode). This makes the DSI
      interface driver dependent on the omap_dss_device struct.
      
      Make the DSI driver data maintain it's own operation mode field. The panel
      driver is expected to call omapdss_dsi_set_operation_mode() before the interface
      is enabled.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      dca2b152
    • Archit Taneja's avatar
      OMAPDSS: SDI: Maintain copy of data pairs in driver data · 889b4fd7
      Archit Taneja authored
      The SDI driver currently relies on the omap_dss_device struct to configure the
      number of data pairs as specified by the panel. This makes the SDI interface
      driver dependent on the omap_dss_device struct.
      
      Make the SDI driver data maintain it's own data lines field. A panel driver
      is expected to call omapdss_sdi_set_datapairs() before enabling the interface.
      Even though we configure the number of data pairs here, this function would be
      finally mapped to a generic interface op called set_data_lines. The datapairs
      argument type has been changed from u8 to int at some places to be in sync with
      the 'set_data_lines' ops of other interfaces.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      889b4fd7
    • 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
    • Archit Taneja's avatar
      OMAPDSS: RFBI: Maintain copy of number of data lines in driver data · 475989b7
      Archit Taneja authored
      The RFBI driver currently relies on the omap_dss_device struct to configure the
      number of data lines as specified by the panel. This makes the RFBI interface
      driver dependent on the omap_dss_device struct.
      
      Make the RFBI driver data maintain it's own data lines field. A panel driver
      is expected to call omapdss_rfbi_set_data_lines() to configure the pixel format
      before enabling the interface or calling omap_rfbi_configure().
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      475989b7
    • Archit Taneja's avatar
      OMAPDSS: RFBI: Maintain copy of pixel size in driver data · b02875be
      Archit Taneja authored
      The RFBI driver currently relies on the omap_dss_device struct to receive the
      desired pixel size of the panel. This makes the RFBI interface driver dependent
      on the omap_dss_device struct.
      
      Make the RFBI driver data maintain it's own pixel format field. A panel driver
      is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format
      before enabling the interface or calling omap_rfbi_configure().
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      b02875be
    • Archit Taneja's avatar
      OMAPDSS: DSI: Maintain copy of pixel format in driver data · 02c3960b
      Archit Taneja authored
      The DSI driver currently relies on the omap_dss_device struct to receive the
      desired pixel format of the panel. This makes the DSI interface driver dependent
      on the omap_dss_device struct.
      
      Make the DSI driver data maintain it's own pixel format field. The panel driver
      is expected to call omapdss_dsi_set_pixel_format() to configure the pixel format
      before the interface is enabled.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      02c3960b
  4. 15 Aug, 2012 8 commits
    • Archit Taneja's avatar
      OMAPDSS: RFBI: Add function to set panel size · 6ff9dd5a
      Archit Taneja authored
      RFBI drivers requires configuration of the update area. Since we don't support
      partial updates, the size to be configures is the panel size itself.
      
      Add a timings field in RFBI's driver data. Apart from x_res and y_res, all the
      other fields are configured to an initial value when RFBI is enabled. A panel
      driver is expected to call omapdss_rfbi_set_size() configure the size of the
      panel.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      6ff9dd5a
    • Archit Taneja's avatar
      OMAPDSS: RFBI: Remove partial update support · 43eab861
      Archit Taneja authored
      Partial update suppport was removed from DISPC and DSI sometime back. The RFBI
      driver still tries to support partial update without the underlying support in
      DISPC.
      
      Remove partial update support from RFBI, only support updates which span acros
      the whole panel size. This also helps in DSI and RFBI having similar update
      ops.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      43eab861
    • Archit Taneja's avatar
      OMAPDSS: VENC: Maintain our own timings field in driver data · a5abf472
      Archit Taneja authored
      The VENC driver currently relies on the timings in omap_dss_device struct to
      configure the DISPC and VENC blocks accordingly. This makes the VENC interface
      driver dependent on the omap_dss_device struct.
      
      Make the VENC driver data maintain it's own timings field. The panel driver is
      expected to call omapdss_venc_set_timings() to set these timings before the
      panel is enabled. Call omapdss_venc_set_timings() before enabling
      venc output, this is done to atleast have the venc output configured to the
      panel's default timings if the DSS user didn't explicitly call the venc panel
      driver's set_timings op.
      
      Make the VENC panel driver configure the new timings is the omap_dss_device
      struct(dssdev->panel.timings). The VENC driver is responsible for maintaining
      only it's own copy of timings.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      a5abf472
    • Archit Taneja's avatar
      OMAPDSS: VENC: Split VENC into interface and panel driver · 156fd99e
      Archit Taneja authored
      The current venc.c driver contains both the interface and panel driver code.
      This makes the driver hard to read, and difficult to understand the work split
      between the interface and panel driver and the how the locking works.
      
      This also makes it easier to clearly define the VENC interface ops called by the
      panel driver.
      
      Split venc.c into venc.c and venc_panel.c representing the interface and panel
      driver respectively. This split is done along the lines of the HDMI interface
      and panel drivers.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      156fd99e
    • Archit Taneja's avatar
      OMAPDSS: SDI: Maintain our own timings field in driver data · 9b4a5716
      Archit Taneja authored
      The SDI driver currently relies on the timings in omap_dss_device struct to
      configure the DISPC accordingly. This makes the SDI interface driver dependent
      on the omap_dss_device struct.
      
      Make the SDI driver data maintain it's own timings field. The panel driver is
      expected to call omapdss_sdi_set_timings() to set these timings before the panel
      is enabled.
      
      Make the SDI panel driver configure the new timings is the omap_dss_device
      struct(dssdev->panel.timings). The SDI driver is responsible for maintaining
      only it's own copy of timings.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      9b4a5716
    • Archit Taneja's avatar
      OMAPDSS: SDI: Create a function to set timings · c7833f7b
      Archit Taneja authored
      Create function omapdss_sdi_set_timings(). Configuring new timings is done the
      same way as before, SDI is disabled, and re-enabled with the new timings in
      dssdev. This just moves the code from the panel drivers to the SDI driver.
      
      The panel drivers shouldn't be aware of how SDI manages to configure a new set
      of timings. This should be taken care of by the SDI driver itself.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      c7833f7b
    • Archit Taneja's avatar
      OMAPDSS: HDMI: Add locking for hdmi interface set timing functions · ed1aa900
      Archit Taneja authored
      The hdmi interface driver exposes functions to the hdmi panel driver to
      configure the interface timings maintained by the hdmi driver.
      
      These timings(stored in hdmi.ip_data.cfg) should be protected by the hdmi lock
      to ensure they are called sequentially, this is similar to how hdmi enable and
      disable functions need locking.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      ed1aa900
    • Archit Taneja's avatar
      OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings · 7849398f
      Archit Taneja authored
      The hdmi driver currently updates only the 'code' member of hdmi_config when
      the op omapdss_hdmi_display_set_timing() is called by the hdmi panel driver.
      The 'timing' field of hdmi_config is updated only when hdmi_power_on is called.
      It makes more sense to configure the whole hdmi_config field in the set_timing
      op called by the panel driver. This way, we don't need to call both functions
      to ensure that our hdmi_config is configured correctly. Also, we don't need to
      calculate hdmi_config during hdmi_power_on, or rely on the omap_video_timings
      in the panel's omap_dss_device struct.
      
      The default timings of the hdmi panel are represented in a cleaner form. Since
      the hdmi output is now configured by it's own copy of timings (in
      hdmi.ip_data.cfg), the panel driver needs to set it to a valid value before
      enabling hdmi output. We now call omapdss_hdmi_set_timing() before enabling
      hdmi output, this is done to atleast have the hdmi output configured to the
      panel's default timings if the DSS user didn't call panel driver's set_timings()
      op explicitly.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      7849398f
  5. 13 Aug, 2012 8 commits
    • Archit Taneja's avatar
      OMAPDSS: DSI: Update manager timings on a manual update · 55cd63ac
      Archit Taneja authored
      During a command mode update using DISPC video port, we may need to swap the
      connected overlay manager's width and height when 90 or 270 degree rotation is
      done via the panel by changing it's address mode.
      
      Call dss_mgr_set_timings() in update_screen_dispc() before starting the manager
      update. The new manager size is updated in the 'timings' field of DSI driver's
      private data via omapdss_dsi_set_size(). A panel driver is expected to call this
      when performing rotation.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      55cd63ac
    • Archit Taneja's avatar
      OMAPDSS: DSI: Add function to set panel size for command mode panels · e352574d
      Archit Taneja authored
      DSI command mode panels don't need to configure a full set of timings to
      configure DSI, they only require the width and the height of the panel in
      pixels.
      
      Use omapdss_dsi_set_size for command mode panels, omapdss_dsi_set_timings is
      meant for video mode panels. When performing rotation via chaning the address
      mode of the panel, we would need to swap width and height when doing 90 or 270
      rotation. Make sure that omapdss_dsi_set_size() makes the new width and height
      visible to DSI.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      e352574d
    • Archit Taneja's avatar
      OMAPDSS: DSI: Maintain own copy of timings in driver data · e67458a8
      Archit Taneja authored
      The DSI driver currently relies on the timings in omap_dss_device struct to
      configure the DISPC and DSI blocks accordingly. This makes the DSI interface
      driver dependent on the omap_dss_device struct.
      
      Make the DSI driver data maintain it's own timings field. A DSI video mode panel
      driver is expected to call omapdss_dsi_set_timings() to set these timings before
      the panel is enabled.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      e67458a8
    • 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: Displays: Add locking in generic DPI panel driver · e19d659b
      Archit Taneja authored
      The generic DPI panel driver doesn't currently have locking to ensure that
      the display states and the driver data is maintained correctly. Add mutex
      locking to take care of this. Add a new get_timings driver op to override the
      default get_timings op. The new driver op contains locking to ensure the correct
      panel timings are seen when a DSS2 user calls device->driver->get_timings.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      e19d659b
    • 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
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings · 27dfddc7
      Archit Taneja authored
      The function dss_mgr_set_timings is supposed to apply timings passed by an
      interface driver. It is not supposed to change the timings. Add const qualifier
      to the omap_video_timings pointer argument in dss_mgr_set_timings().
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      27dfddc7
  6. 10 Aug, 2012 4 commits
  7. 29 Jun, 2012 1 commit
    • Tomi Valkeinen's avatar
      Merge "Apply LCD manager related parameters" from Archit · 974a6582
      Tomi Valkeinen authored
      The LCD interface drivers(DPI, DSI, RFBI, SDI) do some direct DISPC register
      writes to configure LCD manager related fields. This series groups these fields
      into a single struct, and let's the interface driver apply these parameters.
      
      This allows us to:
      
      - Check the LCD manager related parameters before applying them.
      - Remove some omap_dss_device references as APPLY holds the applied parameters.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      974a6582