1. 16 8月, 2012 7 次提交
    • A
      OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings · 6b849375
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      6b849375
    • A
      OMAPDSS: DSI: Maintain copy of operation mode in driver data · dca2b152
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      dca2b152
    • A
      OMAPDSS: SDI: Maintain copy of data pairs in driver data · 889b4fd7
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      889b4fd7
    • A
      OMAPDSS: DPI: Maintain copy of number of data lines in driver data · c6b393d4
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      c6b393d4
    • A
      OMAPDSS: RFBI: Maintain copy of number of data lines in driver data · 475989b7
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      475989b7
    • A
      OMAPDSS: RFBI: Maintain copy of pixel size in driver data · b02875be
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      b02875be
    • A
      OMAPDSS: DSI: Maintain copy of pixel format in driver data · 02c3960b
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      02c3960b
  2. 15 8月, 2012 8 次提交
    • A
      OMAPDSS: RFBI: Add function to set panel size · 6ff9dd5a
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      6ff9dd5a
    • A
      OMAPDSS: RFBI: Remove partial update support · 43eab861
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      43eab861
    • A
      OMAPDSS: VENC: Maintain our own timings field in driver data · a5abf472
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      a5abf472
    • A
      OMAPDSS: VENC: Split VENC into interface and panel driver · 156fd99e
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      156fd99e
    • A
      OMAPDSS: SDI: Maintain our own timings field in driver data · 9b4a5716
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      9b4a5716
    • A
      OMAPDSS: SDI: Create a function to set timings · c7833f7b
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      c7833f7b
    • A
      OMAPDSS: HDMI: Add locking for hdmi interface set timing functions · ed1aa900
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      ed1aa900
    • A
      OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings · 7849398f
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      7849398f
  3. 13 8月, 2012 8 次提交
    • A
      OMAPDSS: DSI: Update manager timings on a manual update · 55cd63ac
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      55cd63ac
    • A
      OMAPDSS: DSI: Add function to set panel size for command mode panels · e352574d
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      e352574d
    • A
      OMAPDSS: DSI: Maintain own copy of timings in driver data · e67458a8
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      e67458a8
    • A
      OMAPDSS: DPI displays: Take care of panel timings in the driver itself · bdcae3cc
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      bdcae3cc
    • A
      OMAPDSS: DPI: Maintain our own timings field in driver data · c499144c
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      c499144c
    • A
      OMAPDSS: Displays: Add locking in generic DPI panel driver · e19d659b
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      e19d659b
    • A
      OMAPDSS: DPI: Add locking for DPI interface · c8a5e4e8
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      c8a5e4e8
    • A
      OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings · 27dfddc7
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      27dfddc7
  4. 10 8月, 2012 4 次提交
  5. 29 6月, 2012 13 次提交
    • T
      Merge "Apply LCD manager related parameters" from Archit · 974a6582
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      974a6582
    • A
      OMAPDSS: OVERLAY: Clean up replication checking · 6c6f510a
      Archit Taneja 提交于
      Replication logic for an overlay depends on the color mode in which it is
      configured and the video port width of the manager it is connected to.
      
      video port width now held in dss_lcd_mgr_config in the manager's private
      data in APPLY. Use this instead of referring to the omap_dss_device connected to
      the manager.
      
      Replication is enabled in the case of TV manager, the video_port_width is set to
      a default value of 24 for TV manager.
      
      Make the replication checking an overlay function since it's more of an overlay
      characteristic than a display characteristic.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      6c6f510a
    • A
      OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay manager · c47cdb30
      Archit Taneja 提交于
      The RFBI driver uses a direct DISPC register write to enable the overlay
      manager. Replace this with dss_mgr_enable() which checks if the connected
      overlay and managers are correctly configured, and configure DSS for
      fifomerge.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      c47cdb30
    • A
      OMAPDSS: DISPC: Remove a redundant function · dd88b7a6
      Archit Taneja 提交于
      dss_mgr_is_lcd() available in dss.h does the same thing as dispc_mgr_is_lcd()
      in dispc.c. Remove the function from dispc.c and replace it with the one in
      dss.h.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      dd88b7a6
    • A
      OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checks · 75bac5d1
      Archit Taneja 提交于
      APPLY needs to know at certain places whether an overlay manager is in manual
      or auto update mode. The caps of the connected omap_dss_device were used to
      check that.
      
      A LCD manager is in manual update if stallmode is enabled for that manager. TV
      managers for now always auto update.
      
      Return the value of stallmode parameter in the private data 'lcd_confg' in
      mgr_manual_update() and ovl_manual_update(), for TV managers stallmode field
      will be false by default.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      75bac5d1
    • A
      OMAPDSS: MANAGER: Check LCD related overlay manager parameters · 6e543595
      Archit Taneja 提交于
      The LCD related manager configurations are a part of the manager's private data
      in APPLY. Pass this to dss_lcd_mgr_config to dss_mgr_check and create a function
      to check the validity of some of the configurations.
      
      To check some of the configurations, we require information of interface to
      which the manager output is connected. These can be added once interfaces are
      represented as an entity.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      6e543595
    • A
      OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drivers · f476ae9d
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      f476ae9d
    • A
      OMAPDSS: SDI: Configure dss_lcd_mgr_config struct with lcd manager parameters · 37a57990
      Archit Taneja 提交于
      Create a dss_lcd_mgr_config struct instance in SDI. Fill up all the parameters
      of the struct with configurations held by the panel, and the configurations
      required by SDI.
      
      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.
      
      Create function sdi_config_lcd_manager() which fills the mgr_config parameters
      and writes to the DISPC registers.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      37a57990
    • A
      OMAPDSS: DSI: Configure dss_lcd_mgr_config struct with lcd manager parameters · 7d2572f8
      Archit Taneja 提交于
      Create a dss_lcd_mgr_config struct instance in DSI. Fill up all the parameters
      of the struct with configurations held by the panel, and the configurations
      required by DSI.
      
      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 function dsi_configure_dispc_clocks() is now called in
      dsi_display_init_dispc(), this lets all the lcd manager related configurations
      happen in the same place. The DISPC_DIVISORo register was written in
      dsi_configure_dispc_clock(), now it just fills up the dispc_clock_info parameter
      in mgr_config. The clock_info is written later in dsi_display_init_dispc().
      Signed-off-by: NArchit Taneja <archit@ti.com>
      7d2572f8
    • A
      OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parameters · bc2e60a6
      Archit Taneja 提交于
      Create a dss_lcd_mgr_config struct instance in RFBI. Fill up all the parameters
      of the struct with configurations held by the panel, and the configurations
      required by RFBI.
      
      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.
      
      Create function rfbi_config_lcd_manager() which fills up the mgr_config
      parameters and writes to the DISPC regs.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      bc2e60a6
    • A
      OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parameters · 5cf9a264
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      5cf9a264
    • A
      OMAPDSS: Add struct to hold LCD overlay manager configuration · c56fb3ef
      Archit Taneja 提交于
      Create a struct dss_lcd_mgr_config which holds LCD overlay manager related
      parameters. These are currently partially contained in the omap_dss_device
      connected to the manager, and the rest are in the interface driver.
      
      The parameters are directly written to the DISPC registers in the interface
      drivers. These should eventually be applied at the correct time using the
      shadow register programming model. This struct would help in grouping these
      parameters so that they can be applied together.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      c56fb3ef
    • A
      OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div() · f0d08f89
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      f0d08f89