05 Jan, 2012

2 commits


02 Dec, 2011

13 commits

  • Add comments specifying what ovl/mgr functions may block.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • omap_overlay_manager contains device_changed field, which no longer has
    any use. So remove the field and the few places where it is touched.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Setting overlay's output channel is currently handled at the same time
    as other overlay attributes. This is not right, as the normal attributes
    should only affect one overlay and manager, but changing the channel
    affects two managers.

    This patch moves the channel field into the "extra_info" set, handled
    together with enabled-status.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • struct omap_overlayr contains info and info_dirty fields, both of which
    should be internal to apply.c.

    This patch moves those fields into ovl_priv data, and names them
    user_info and user_info_dirty.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • struct omap_overlay_manager contains info and info_dirty fields, both of
    which should be internal to apply.c.

    This patch moves those fields into mgr_priv data, and names them
    user_info and user_info_dirty.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Overlays are currently enabled and disabled with a boolean in the struct
    omap_overlay_info. The overlay info is set with ovl->set_overlay_info(),
    and made into use with mgr->apply().

    This doesn't work properly, as the enable/disable status may affect also
    other overlays, for example when using fifo-merge. Thus the enabling and
    disabling of the overlay needs to be done outside the normal overlay
    configuration.

    This patch achieves that by doing the following things:

    1) Add function pointers to struct omap_overlay: enable(), disable() and
    is_enabled(). These are used to do the obvious. The functions may block.

    2) Move the "enabled" field from struct omap_overlay to ovl_priv_data.

    3) Add a new route for settings to be applied to the HW, called
    "extra_info". The status of the normal info and extra_info are tracked
    separately.

    The point here is to allow the normal info to be changed and
    applied in non-blocking matter, whereas the extra_info can only be
    changed when holding the mutex. This makes it possible to, for example,
    set the overlay enable flag, apply it, and wait until the HW has taken
    the flag into use.

    This is not possible if the enable flag would be in the normal info, as
    a new value for the flag could be set at any time from the users of
    omapdss.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • struct omap_overlay_manager contains "enabled"-field, used to track if
    the manager is enabled or not. This field should be internal to apply.c.

    This patch moves the field to mgr_priv_data, and applies the necessary
    locking when accessing the field.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • The current code uses dsi_video_mode_enable/disable functions to
    enable/disable DISPC output for video mode displays. For command mode
    displays we have no notion in the DISPC side of whether the panel is
    enabled, except when a dss_mgr_start_update() call is made.

    However, to properly maintain the DISPC state in apply.c, we need to
    know if a manager used for a manual update display is currently in use.

    This patch achieves that by changing dsi_video_mode_enable/disable to
    dsi_enable/disable_video_output, which is called by both video and
    command mode displays. For video mode displays it starts the actual
    pixel stream, as it did before. For command mode displays it doesn't do
    anything else than mark that the manager is currently in use.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Current way of handling overlay-manager links is a bit strange: each
    manager has a static array, containing pointers to all the overlays
    (even those used by other managers). The overlays contain a pointer to
    the manager being used.

    This patch makes the system a bit saner: each manager has a linked list
    of overlays, and only the overlays linked to that manager are in the
    list.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Overlay managers are stored in a linked list. There's no need for this
    list, as an array would do just as fine.

    This patch changes the code to use an array for overlay managers.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Add "enabled" field to struct omap_overlay_manager, which tells if the
    output is enabled or not. This will be used in apply.c in the following
    patches.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • omap_overlay_manager struct contains enable() and disable() functions.
    However, these are only meant to be used from inside omapdss, and thus
    it's bad to expose the functions.

    This patch adds dss_mgr_enable() and dss_mgr_disable() functions to
    apply.c, which handle enabling and disabling the output.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Partial update for manual update displays has never worked quite well:
    * The HW has limitations on the update area, and the x and width need to
    be even.
    * Showing a part of a scaled overlay causes artifacts.
    * Makes the management of dispc very complex

    Considering the above points and the fact that partial update is not
    used anywhere, this and the following patches remove the partial update
    support. This will greatly simplify the following re-write of the apply
    mechanism to get proper locking and additional features like fifo-merge.

    This patch removes the partial update from the dsi.c.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     

08 Nov, 2011

1 commit

  • This patch adds a custom DSS reset function used on OMAPs from OMAP2
    forward.

    The function doesn't actually do a reset, it only waits for the reset to
    complete. The reason for this is that on OMAP4 there is no possibility
    to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets
    all the other DSS modules also, thus breaking the HWMOD model where
    every DSS module is handled independently.

    This fixes the problem with DSS reset on OMAP4, caused by the fact that
    because there's no SW reset for dss_core on OMAP4, the HWMOD framework
    doesn't try to reset dss_core and thus the DSS clocks were never enabled
    at the same time. This causes causes the HWMOD reset to fail for
    dss_dispc and dss_rfbi.

    The common reset function will also allow us to fix another problem in
    the future: before doing a reset we need to disable DSS outputs, which
    are in some cases enabled by the bootloader, as otherwise DSS HW seems
    to get more or less stuck, requiring a power reset to recover.

    Signed-off-by: Tomi Valkeinen
    [paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o
    unconditionally to avoid an error when !CONFIG_OMAP2_DSS]
    Signed-off-by: Paul Walmsley

    Tomi Valkeinen
     

03 Oct, 2011

3 commits

  • Add zorder support on OMAP4, this feature allows deciding the visibility order
    of the overlays based on the zorder value provided as an overlay info parameter
    or a sysfs attribute of the overlay object.

    Use the overlay cap OMAP_DSS_OVL_CAP_ZORDER to determine whether zorder is
    supported for the overlay or not. Use dss feature FEAT_ALPHA_FREE_ZORDER
    if the caps are not available.

    Ensure that all overlays that are enabled and connected to the same manager
    have different zorders. Swapping zorders of 2 enabled overlays currently
    requires disabling one of the overlays.

    Signed-off-by: Archit Taneja
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     
  • Add support for VIDEO3 pipeline on OMAP4:
    - Add VIDEO3 pipeline information in dss_features and omapdss.h
    - Add VIDEO3 pipeline register coefficients in dispc.h
    - Create a new overlay structure corresponding to VIDEO3.
    - Make changes in dispc.c for VIDEO3

    Signed-off-by: Archit Taneja
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     
  • On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
    to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
    OMAP4, alpha blending is always enabled by default, if the above bits are set,
    we switch to an OMAP3 compatibility mode where the zorder values in the pipeline
    attribute registers are ignored and a fixed priority is configured.

    Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled" for
    more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
    FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and OMAP4
    alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2 user is
    expected to check for the ZORDER cap, if an overlay doesn't have this cap, the
    user is expected to set the parameter partial_alpha_enabled. If the overlay has
    ZORDER cap, the DSS2 user can assume that alpha blending is already enabled.

    Don't support OMAP3 compatibility mode for now. Trying to read/write to
    alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does not
    set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.

    Change alpha_enabled to partial_alpha_enabled in the omap_vout driver. Use
    overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports alpha
    blending or not. Replace this with checks for VIDEO1 pipeline.

    Cc: linux-media@vger.kernel.org
    Cc: Lajos Molnar
    Signed-off-by: Archit Taneja
    Acked-by: Vaibhav Hiremath
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     

30 Sep, 2011

16 commits

  • overlay_info struct, used to configure overlays, currently includes both
    physical and virtual addresses for the pixels. The vaddr was added to
    support more exotic configurations where CPU would be used to update a
    display, but it is not currently used and there has been no interest in
    the feature. Using CPU to update a screen is also less interesting now
    that OMAP4 has two LCD outputs.

    This patch removes the vaddr field, and modifies the users of omapdss
    accordingly. This makes the use of omapdss a bit simpler, as the user
    doesn't need to think if it needs to give the vaddr.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • detect() can be used to probe if the display is connected.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • read_edid() can be used to get the EDID information from the display.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Add IRQ definitions for missing OMAP4 IRQs: FRAMEDONEWB, FRAMEDONETV,
    WBBUFFEROVERFLOW.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • regn divider is one greater than the REGN divider in TRM. Add a comment
    to point this out.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • regn divider is currently programmed to the registers without change,
    but when calculating clock frequencies it is used as regn+1.

    To make this similar to how DSI handles the dividers this patch changes
    the regn value to be used as such for calculations, but the value
    programmed to registers is regn-1.

    This simplifies the clock frequency calculations, makes it similar to
    DSI, and also allows us to use regn value 0 as undefined.

    Cc: Mythri P K
    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Add initial support for DSI video mode panels:
    - Add a new structure omap_dss_dsi_videomode_data in the member "panel" in
    omap_dss_device struct. This allows panel driver to configure dsi video_mode
    specific parameters.
    - Configure basic DSI video mode timing parameters: HBP, HFP, HSA, VBP, VFP, VSA,
    TL and VACT.
    - Configure DSI protocol engine registers for video_mode support.
    - Introduce functions dsi_video_mode_enable() and dsi_video_mode_disable() which
    enable/disable video mode for a given virtual channel and a given pixel format
    type.

    Things left for later
    - Add functions to check for errors in video mode timings provided by panel.
    - Configure timing registers required for command mode interleaving.

    Signed-off-by: Archit Taneja
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     
  • Currently, DSI pixel info is only represented by the pixel size in bits using
    the pixel_size parameter in omap_dss_device struct's ctrl member.

    This is not sufficient information for DSI video mode usage, as two of the
    supported formats(RGB666 loosely packed, and RGB888) have the same pixel
    container size, but different data_type values for the video mode packet header.

    Create enum "omap_dss_dsi_pixel_format" which describes the pixel data format
    the panel is configured for. Create helper function dsi_get_pixel_size() which
    returns the pixel size of the given pixel format.

    Modify functions omapdss_default_get_recommended_bpp() and dss_use_replication()
    to use dsi_get_pixel_size().

    Signed-off-by: Archit Taneja
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     
  • Introduce read functions which use generic Processor-to-Peripheral
    transaction types. These are needed by some devices which may not support
    corresponding DCS commands.

    Add function dsi_vc_generic_send_read_request() which can send
    a short packet with 0, 1 or 2 bytes of request data and the corresponding
    generic data type.

    Rename function dsi_vc_dcs_read_rx_fifo() to dsi_vc_read_rx_fifo() and modify
    it to take the enum "dss_dsi_content_type" as an argument to use either DCS
    or GENERIC Peripheral-to-Processor transaction types while parsing data read
    from the device.

    Signed-off-by: Archit Taneja
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     
  • Remove functions dsi_vc_dcs_read_1() and dsi_vc_dcs_read_2(), these are used
    when the panel is expected to return 1 and 2 bytes respecitvely. This was manily
    used for debugging purposes. These functions should be implemented in the panel
    driver if needed.

    Signed-off-by: Archit Taneja
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     
  • Intoduce enum "dss_dsi_content_type" to differentiate between DCS and generic
    content types.

    Introduce short and long packet write functions which use generic
    Processor-to-Peripheral transaction types. These are needed by some devices
    which may not support corresponding DCS commands. Create common write functions
    which allow code reuse between DCS and generic write functions.

    Signed-off-by: Archit Taneja
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     
  • Create an enum for DSI operation modes, use this to set the capabilities of the
    device in dsi_init_display().

    Signed-off-by: Archit Taneja
    Signed-off-by: Tomi Valkeinen

    Archit Taneja
     
  • Add OMAP_DSS_OVL_CAP_GLOBAL_ALPHA and OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA to
    overlay capabilities. Use these instead of FEAT_GLOBAL_ALPHA,
    FEAT_GLOBAL_ALPHA_VID1 and FEAT_PRE_MULT_ALPHA in code.

    Remove FEAT_GLOBAL_ALPHA_VID1 and FEAT_PRE_MULT_ALPHA which are no
    longer used. FEAT_GLOBAL_ALPHA is still used to decide if the HW has
    global alpha register.

    Signed-off-by: Tomi Valkeinen
    Acked-by: Archit Taneja

    Tomi Valkeinen
     
  • Remove support for non-DISPC overlays and overlay managers.

    The support to possibly have non-DISPC overlays and managers was made to
    make it possible to use CPU and/or sDMA to update RFBI or DSI command
    mode displays. It is ok to remove the support, because:

    - No one has used the feature.
    - Display update without DISPC is very slow, so it is debatable if the
    update would even be usable.
    - Removal cleans up code.
    - If such a feature is needed later, it is better implemented outside
    omapdss driver.

    Signed-off-by: Tomi Valkeinen
    Acked-by: Archit Taneja

    Tomi Valkeinen
     
  • Currently when changing the manager of an overlay, set_manager() directly
    calls dispc to set the overlay's destination.

    Change this to be more in line with other overlay configurations, and
    this will also remove the need to have dispc clocks enabled when calling
    set_manager().

    A new field is added to overlay struct, "manager_changed". This is
    similar to "display_changed" field in manager struct, and is used to
    inform apply that the manager has changed and thus write to the
    registers is needed.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • dsi_mux_pads() needs to know about the DSI HW module and the DSI lanes
    used. Split the function into two, enable and disable, which take
    necessary arguments, and add empty implementations for both.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     

25 Jul, 2011

2 commits


01 Jul, 2011

3 commits