1. 07 12月, 2012 7 次提交
    • T
      OMAPDSS: move blocking mgr enable/disable to compat layer · bb398134
      Tomi Valkeinen 提交于
      dispc_mgr_enable_sync and dispc_mgr_disable_sync are only used with the
      compat mode. Non-compat will use the simpler enable and disable
      functions.
      
      This patch moves the synchronous enable/disable code to the compat
      layer. A new file is created, dispc-compat.c, which contains low level
      dispc compat code (versus apply.c, which contains slightly higher level
      compat code).
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bb398134
    • T
      OMAPDSS: manage framedone irq with mgr ops · 1550202d
      Tomi Valkeinen 提交于
      Some of the output drivers need to handle FRAMEDONE interrupt from
      DISPC. This creates a direct dependency to dispc code, and we need to
      avoid this to make the compat code to work.
      
      Instead of the output drivers registering for dispc interrupts, we
      create new mgr-ops that are used to register a framedone handler. The
      code implementing the mgr-ops is responsible for calling the handler
      when DISPC FRAMEDONE interrupt happens. The compat layer is improved
      accordingly to do the call to the framedone handler.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      1550202d
    • T
      OMAPDSS: add manager ops · 74b65ec2
      Tomi Valkeinen 提交于
      The output drivers need some operations from the overlay managers, like
      enable and set_timings. These will affect the dispc registers, and need
      to be synchronized with the composition-side changes with overlays and
      overlay managers.
      
      We want to handle these calls in the apply.c in the compatibility mode,
      but when in non-compat mode, the calls need to be handled by some other
      component (e.g. omapdrm).
      
      To make this possible, this patch creates a set of function pointers in
      a dss_mgr_ops struct, that is used to redirect the calls into the
      correct destination.
      
      The non-compat users can install their mgr ops with
      dss_install_mgr_ops() function.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      74b65ec2
    • T
      OMAPDSS: move ovl function setup to apply.c · 6abae7a1
      Tomi Valkeinen 提交于
      Most of the functions that are assigned to the fields in ovl struct are
      in apply.c. By moving the function pointer setup into apply.c we can
      make these functions static.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      6abae7a1
    • T
      OMAPDSS: move ovl-mgr function setup to apply.c · 0c49ff74
      Tomi Valkeinen 提交于
      Most of the functions that are assigned to the fields in ovl-mgr struct
      are in apply.c. By moving the function pointer setup into apply.c we can
      make these functions static.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      0c49ff74
    • T
      OMAPDSS: add omapdss_compat_init() · 8dd2491a
      Tomi Valkeinen 提交于
      Add two new exported functions, omapdss_compat_init and
      omapdss_compat_uninit, which are to be used by omapfb, omap_vout to
      enable compatibility mode for omapdss. The functions are called by
      omapdss internally for now, and moved to other drivers later.
      
      The compatibility mode is implemented fully in the following patches.
      For now, enabling compat mode only sets up the private data in apply.c.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8dd2491a
    • T
      OMAPDSS: manage output-dssdev connection in output drivers · 486c0e17
      Tomi Valkeinen 提交于
      We currently attach an output to a dssdev in the initialization code for
      dssdevices in display.c. This works, but doesn't quite make sense: an
      output entity represents (surprisingly) an output of DSS, which is
      managed by an output driver. The output driver also handles adding new
      dssdev's for that particular output.
      
      It makes more sense to make the output-dssdev connection in the output
      driver. This is also in line with common display framework.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      486c0e17
  2. 29 11月, 2012 1 次提交
    • A
      OMAPDSS: Use only "omapdss_dss" platform device to get context lost count · bdb736ab
      Archit Taneja 提交于
      When enabling a hwmod, omap_hwmod refers to the register mentioned in the
      hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
      lost or not. It increments the context lost count for the hwmod and then clears
      the register.
      
      All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
      When DSS is enabled, the first hwmod to be enabled is the "dss_core" hwmod since
      it's corresponding platform device is the parent platform device("omapdss_dss").
      The dss_core hwmod updates it's context lost count correctly and clears the
      register. When the hwmods corresponding to the children platform devices are
      enabled, they see that the register is clear, and don't increment their context
      lost count. Therefore, all the children platform devices never report a loss in
      context.
      
      The DISPC driver currently gets the context lost count for DSS power domain from
      it's corresponding platform device instance("omapdss_dispc"). The DISPC platform
      device is one of the child devices, and it's corresponding hwmod("dss_dispc")
      doesn't report the context lost count correctly.
      
      Modify dss_get_ctx_loss_count() such that it always takes the "omapdss_dss"
      platform device as it's input, move the function to dss.c so that it has access
      to that platform device.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bdb736ab
  3. 27 11月, 2012 4 次提交
  4. 05 11月, 2012 2 次提交
    • T
      OMAPDSS: hide dss_select_dispc_clk_source() · a5b8399f
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a5b8399f
    • T
      OMAPDSS: add dss_calc_clock_rates() back · 930b027e
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      930b027e
  5. 29 10月, 2012 6 次提交
  6. 24 10月, 2012 1 次提交
  7. 18 10月, 2012 5 次提交
  8. 12 10月, 2012 4 次提交
  9. 26 9月, 2012 9 次提交
    • A
      OMAPDSS: DISPC: Add manager like functions for writeback · 0b23e5b8
      Archit Taneja 提交于
      Add functions to enable writeback, and set/check state of GO bit. These bits are
      identical in behaviour with the corresponding overlay manager bits. Configure
      them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to
      get the FRAMEDONE irq corresponding to writeback.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      0b23e5b8
    • A
      OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup() · 9e4a0fc7
      Archit Taneja 提交于
      Configure some of the writeback specific parameters in dispc_wb_setup(). The
      writeback parameters configured are:
      
      truncation: This needs to be set if the color depth input to writeback is more
      than the color depth of the color mode we want to store in memory.
      
      writeback mode: This configures whether we want to use writeback in mem to mem
      or capture mode. This information will be directly passed by APPLY later.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      9e4a0fc7
    • 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: DISPC: Add function to set channel in for writeback · d9ac773c
      Archit Taneja 提交于
      Writeback can take input from either one of the overlays, or one of the overlay
      managers. Add an enum which represents the channel_in for writeback, and maps
      to the register field programming.
      
      Add a function to configure channel in for writeback. This will be used later in
      APPLY.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      d9ac773c
    • A
      OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory mode · 8ba85306
      Archit Taneja 提交于
      The scalers of overlays and writeback do not have any constraints on downscale
      ratio when operating in memory to memory mode.
      
      This is because in memory to memory mode, we aren't connected to a display which
      needs data output at the rate of pixel clock. The scalers can perform as much
      downscaling as needed, the rate at which the scaler outputs is adjusted
      accordingly.
      
      Relax constraints related to downscaling based on whether the input overlays are
      connected to writeback in memory to memory mode. We pass a mem_to_mem boolean
      parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this
      will later be configured to the correct value based on whether the overlay is
      connected to writeback or not. Do the same later for writeback when writeback is
      configured.
      
      In the scaling calculation code, we calculate the minimum amount of core clock we
      need to achieve the required downscaling. If we are in memory to memory mode, we
      set this to a very small value(1 in this case), this value would always be
      lesser than the actual DISPC core clock value, and hence the scaling checks
      would succeed.
      
      We take care that pixel clock isn't calculated for writeback and the overlays
      connected to it when in memory to memory mode. A pixel clock in such cases
      doesn't make sense.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      8ba85306
    • A
      OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup() · 8eeb7019
      Archit Taneja 提交于
      The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure
      DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field
      was being changed in dispc_ovl_setup in the case of interlaced displays. Fix
      this and const qualifier to the omap_overlay_info argument.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      8eeb7019
    • A
      OMAPDSS: Create links between managers, outputs and devices · 32248276
      Archit Taneja 提交于
      Links between DSS entities are made in dss_init_connections() when a panel
      device is registered, and are removed in dss_uninit_connections() when the
      device is unregistered. Modify these functions to incorporate the addition of
      outputs.
      
      The fields in omap_dss_device struct gives information on which output and
      manager to connect to. The desired manager and output pointers are retrieved and
      prepared to form the desired links. The output is linked to the device, and then
      the manager to the output.
      
      A helper function omapdss_get_output_from_device() is created to retrieve the
      output from the display by checking it's type, and the module id in case of DSI.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      32248276
    • 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: 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
  10. 24 9月, 2012 1 次提交