1. 07 12月, 2012 5 次提交
  2. 29 10月, 2012 1 次提交
  3. 24 10月, 2012 2 次提交
    • T
      OMAPDSS: get the dss version from core pdev · b2c7d54f
      Tomi Valkeinen 提交于
      The output drivers get the omapdss hw version from the platform data for
      their respective output device. This doesn't work with DT, as there's no
      platform data for them.
      
      Add a new function, omapdss_get_version(), which returns the dss version
      from the core device, which will have platform data on DT also. The
      function is exported so that users of omapdss can also use it.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b2c7d54f
    • T
      OMAPDSS: remove omap_dss_device's suspend/resume · 998c336d
      Tomi Valkeinen 提交于
      The panel drivers contain enable, disable, suspend and resume calls.
      The suspend and resume are effectively identical to disable and enable.
      
      This patch removes panel suspend and enable code from omapdss and the
      panel drivers, and replaces their use with enable and disable.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      998c336d
  4. 22 10月, 2012 1 次提交
  5. 16 10月, 2012 1 次提交
    • T
      OMAPDSS: add omapdss_version · acd18af9
      Tomi Valkeinen 提交于
      Add new enum, omapdss_version, that is used to tell which DSS hardware
      version the SoC has. This enum is initialized during platform init, and
      passed in the platform data to omapdss driver.
      
      Note that the versions are not "continuous", that is, you cannot check
      if the version is less or greater than something, but you need to check
      for exact version match. In other words, this is invalid:
      
      /* test if DSS is 3630 or earlier */
      if (ver <= OMAPDSS_VER_OMAP3630)
      	...
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      acd18af9
  6. 26 9月, 2012 7 次提交
    • A
      OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup · 749feffa
      Archit Taneja 提交于
      Create struct omap_dss_writeback_info, this is similar to omap_overlay_info,
      the major difference is that there is no parameter which describes the input
      size to writeback, this is because this is always fixed, and decided by the
      connected overlay or overlay manager. One more difference is that screen_width
      is renamed to buf_width, to give the value of stride the writeback buffer has.
      
      Call dispc_ovl_setup_common() through dispc_wb_setup() to configure overlay-like
      parameters. The parameters in dispc_ovl_setup_common() which do not hold for
      writeback are filled passed as zeroes or false, the code takes care of not
      configuring them as they won't possess the needed overlay caps.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      749feffa
    • A
      OMAPDSS: OVERLAY: Add position and replication as overlay caps · d79db853
      Archit Taneja 提交于
      Add position and replication as overlay caps, and pass overlay caps as an
      argument to the corresponding functions. Adding position and replication to
      overlay caps seems a bit unnecessary, but it allows us to use the
      corresponding functions for writeback too.
      
      These caps will be set for all overlays, but not for writeback. This is done
      so writeback can reuse dispc_ovl_setup() to the maximum.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      d79db853
    • A
      OMAPDSS: Remove old way of setting manager and device links · 3c2995ac
      Archit Taneja 提交于
      Now that an omap_dss_output can be used to link between managers and devices, we
      can remove the old way of setting manager and device links. This involves
      removing the device and manager pointers from omap_overlay_manager and
      omap_dss_device respectively, and removing the set_device/unset_device ops from
      omap_overlay_manager.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      3c2995ac
    • A
      OMAPDSS: Remove manager->device references · 794bc4ee
      Archit Taneja 提交于
      With the introduction of output entities, managers will now connect to outputs.
      Create helper ops for overlays and managers named get_device. This will abstract
      away the information on how to get the device from an overlay or an overlay
      manager. The get_device ops currently retrieve the output via a
      ovl->manager->device reference. This will be later replaced by
      ovl->manager->output->device references.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      794bc4ee
    • A
      OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager · 97f01b3a
      Archit Taneja 提交于
      Add set_output/unset_output ops for overlay managers, these form links between
      managers and outputs. Create a function in dss features which tell all the
      output instances that connect to a manager, use it when a manager tries to set
      an output. Add a constraint of not unsetting an output when the manager is
      enabled.
      
      Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for
      now to not break things. Keep the dss feature function get_supported_displays
      as it's used in some places. These will be removed later.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      97f01b3a
    • A
      OMAPDSS: output: Add set/unset device ops for omap_dss_output · 6d71b923
      Archit Taneja 提交于
      An output entity represented by the struct omap_dss_output connects to a
      omap_dss_device entity. Add functions to set or unset an output's device. This
      is similar to how managers and devices were connected previously. An output can
      connect to a device without being connected to a manager. However, the output
      needs to eventually connect to a manager so that the connected panel can be
      enabled.
      
      Keep the omap_overlay_manager pointer in omap_dss_device for now to prevent
      breaking things. This will be removed later when outputs are supported
      completely.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      6d71b923
    • A
      OMAPDSS: outputs: Create a new entity called outputs · 484dc404
      Archit Taneja 提交于
      The current OMAPDSS design contains 3 software entities: Overlays, Managers and
      Devices. These map to pipelines, overlay managers and the panels respectively in
      hardware. One or more overlays connect to a manager to represent a composition,
      the manager connects to a device(generally a display) to display the content.
      
      The part of DSS hardware which isn't represented by any of the above entities
      are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
      HDMI, VENC and so on. Currently, an overlay manager directly connects to the
      display, and the output to which it is actually connected is ignored. The panel
      driver of the display is responsible of calling output specific functions to
      configure the output.
      
      Adding outputs as a new software entity gives us the following benefits:
      
      - Have exact information on the possible connections between managers and
        outputs: A manager can't connect to each and every output, there only limited
        hardware links between a manager's video port and some of the outputs.
      
      - Remove hacks related to connecting managers and devices: Currently, default
        links between managers and devices are set in a not so clean way. Matching is
        done via comparing the device type, and the display types supported by the
        manager. This isn't sufficient to establish all the possible links between
        managers, outputs and devices in hardware.
      
      - Make panel drivers more generic: The DSS panel drivers currently call
        interface/output specific functions to configure the hardware IP. When making
        these calls, the driver isn't actually aware of the underlying output. The
        output driver extracts information from the panel's omap_dss_device pointer
        to figure out which interface it is connected to, and then configures the
        corresponding output block. An example of this is when a DSI panel calls
        dsi functions, the dsi driver figures out whether the panel is connected
        to DSI1 or DSI2. This isn't correct, and having output as entities will
        give the panel driver the exact information on which output to configure.
        Having outputs also gives the opportunity to make panel drivers generic
        across different platforms/SoCs, this is achieved as omap specific output
        calls can be replaced by ops of a particular output type.
      
      - Have more complex connections between managers, outputs and devices: OMAPDSS
        currently doesn't support use cases like 2 outputs connect to a single
        device. This can be achieved by extending properties of outputs to connect to
        more managers or devices.
      
      - Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
        as compared to overlays, managers or devices.
      
      Add a new struct to represent outputs. An output struct holds pointers to the
      manager and device structs to which it is connected. Add functions which can
      register/unregister an output, or look for one. Create an enum which represent
      each output instance.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      484dc404
  7. 08 9月, 2012 3 次提交
    • T
      OMAPDSS: Use WB fifo for GFX overlay · 66a0f9e4
      Tomi Valkeinen 提交于
      OMAP4's GFX overlay has smaller fifo than the rest of the overlays
      (including writeback "overlay"). This seems to be the reason for
      underflows in some more demanding scenarios.
      
      We can avoid the problems by using the WB fifo for GFX overlay, and vice
      versa. WB usage is not supported yet, but when it will, it should
      perform just fine with smaller fifo as there are no hard realtime
      constraints with WB.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      66a0f9e4
    • T
      OMAPDSS: DSI: calculate dsi clock · ee144e64
      Tomi Valkeinen 提交于
      Currently the way to configure clocks related to DSI (both DSI and DISPC
      clocks) happens via omapdss platform data. The reason for this is that
      configuring the DSS clocks is a very complex problem, and it's
      impossible for the SW to know requirements about things like
      interference.
      
      However, for general cases it should be fine to calculate the dividers
      for clocks in the SW. The calculated clocks are probably not perfect,
      but should work.
      
      This patch adds support to calculate the dividers when using DSI command
      mode panels. The panel gives the required DDR clock rate and LP clock
      rate, and the DSI driver configures itself and DISPC accordingly.
      
      This patch is somewhat ugly, though. The code does its job by modifying
      the platform data where the clock dividers would be if the board file
      gave them. This is not how it's going to be in the future, but allows us
      to have quite simple patch and keep the backward compatibility.
      
      It also allows the developer to still give the exact dividers from the
      board file when there's need for that, as long as the panel driver does
      not override them.
      
      There are also other areas for improvement. For example, it would be
      better if the panel driver could ask for a DSI clock in a certain range,
      as, at least command mode panels, the panel can work fine with many
      different clock speeds.
      
      While the patch is not perfect, it allows us to remove the hardcoded
      clock dividers from the board file, making it easier to bring up a new
      panel and to use device tree from omapdss.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ee144e64
    • T
      OMAPDSS: HDMI: Move GPIO handling to HDMI driver · cca35017
      Tomi Valkeinen 提交于
      We currently manage HDMI GPIOs in the board files via
      platform_enable/disable calls. This won't work with device tree, and in
      any case the correct place to manage the GPIOs is in the HDMI driver.
      
      This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
      handling is moved to the common hdmi.c file, and this probably needs to
      be revisited when adding OMAP5 HDMI support to see if the GPIO handling
      needs to be moved to IP specific files.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      cca35017
  8. 27 8月, 2012 1 次提交
  9. 16 8月, 2012 9 次提交
    • A
      OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data · 6e883324
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      6e883324
    • A
      OMAPDSS: DSI: Maintain copy of video mode timings in driver data · 0b3ffe39
      Archit Taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      0b3ffe39
    • 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
  10. 15 8月, 2012 3 次提交
    • 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: 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
  11. 13 8月, 2012 3 次提交
    • 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: 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
  12. 29 6月, 2012 4 次提交
    • A
      OMAPDSS: DSI: Fix HSYNC, VSYNC and DE polarities between DISPC and DSI · bd5a7b11
      Archit Taneja 提交于
      For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC
      and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and
      VP_DE_POL in DSI_CTRL registers.
      
      This information is completely internal to DSS as logic levels for the above
      signals hold no meaning on the DSI bus. Hence a DSI panel driver should be
      totally oblivious of these fields.
      
      Fix the logic levels/polarities in the DISPC and DSI registers to a default
      value. This is done by overriding these fields in omap_video_timings struct
      filled by the panel driver for DISPC, and use the equivalent default values
      when programming DSI_CTRL registers. Also, remove the redundant polarity related
      fields in omap_dss_dsi_videomode_data.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      bd5a7b11
    • A
      OMAPDSS: Add interlace parameter to omap_video_timings · 23c8f88e
      Archit Taneja 提交于
      Add a parameter called interlace which tells whether the timings are in
      interlaced or progressive mode. This aligns the omap_video_timings struct with
      the Xorg modeline configuration.
      
      It also removes the hack needed to write to divide the manager height by 2 if
      the connected interface is VENC.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      23c8f88e
    • A
      OMAPDSS: Remove omap_panel_config enum from omap_dss_device · 07fb51c6
      Archit Taneja 提交于
      omap_panel_config contains fields which are finally written to DISPC_POL_FREQo
      registers. These are now held by omap_video_timings and are set when the manager
      timings are applied.
      
      Remove the omap_panel_config enum, and remove all it's references from panel or
      interface drivers.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      07fb51c6
    • A
      OMAPDSS: Add some new fields to omap_video_timings · a8d5e41c
      Archit Taneja 提交于
      Some panel timing related fields are contained in omap_panel_config in the form
      of flags. The fields are:
      
      - Hsync logic level
      - Vsync logic level
      - Data driven on rising/falling edge of pixel clock
      - Output enable/Data enable logic level
      - HSYNC/VSYNC driven on rising/falling edge of pixel clock
      
      Out of these parameters, Hsync and Vsync logic levels are a part of the timings
      in the Xorg modeline configuration. So it makes sense to move the to
      omap_video_timings. The rest aren't a part of modeline, but it still makes
      sense to move these since they are related to panel timings.
      
      These fields stored in omap_panel_config in dssdev are configured for LCD
      panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers.
      
      Add the above fields in omap_video_timings. Represent their state via new enums.
      
      Add these parameters to the omap_video_timings instances in the panel drivers.
      Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in
      omap_panel_config for now. The struct will be removed later.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      a8d5e41c