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
     

15 Oct, 2011

1 commit


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

19 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
     
  • This is a driver for N800's display, ported from the old omapfb. This is
    a slightly lighter version of the driver as not all features of the old
    driver can be ported without big changes to DSS2, and also because some
    of the HW features used in the old driver are unclear (e.g. the power
    management part).

    That said, the new driver works fine for basic use.

    Architecturally the driver is not as neat as it could be. N800's display
    HW consists of a display buffer chip and a panel, and ideally they would
    be represented by separate, independent drivers. This is not currently
    possible, and this driver contains both buffer chip and panel driver.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • Taal panel driver supports two kinds of backlight control: 1) using DSI
    commands sent to the panel to control the backlight, 2) calling function
    pointers going to the board file to control the backlight.

    The second option is a bit hacky, and will no longer be needed when the
    PWM driver supports the backlight features. After that we can use the
    standard PWM backlight driver.

    This patch removes the second backlight control mechanism, and adds a
    boolean field, use_dsi_backlight, to nokia_dsi_panel_data which the
    board file can use to inform whether the panel driver should use DSI
    commands to control the backlight.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     
  • We have currently panel-generic-dpi driver, which is a combined driver
    for dummy panels and also for DVI output.

    The aim is to split the panel-generic-dpi into two, one for fixed size
    dummy panels connected via DPI, and the other (this) for variable
    resolution output which supports DDC channel (in practice a DVI framer
    chip connected to DPI output).

    Original i2c code by: Ricardo Salveti de Araujo

    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
     

14 Sep, 2011

1 commit

  • PicoDLP is a micro projector from TI.

    DLP used in OMAP4 is dpp2600 (DLP Pico Projector) The DLP requires
    commands to be sent over i2c for configurations. To know more about
    dpp2600 commands please visit:
    https://focus.ti.com/myti/docs/extranet.tsp?sectionId=403

    The picodlp module consists of a dss driver and an i2c_client.

    To know more please visit:
    http://www.omappedia.org/wiki/PicoDLP_projector_guide

    Based on original design from Mythri P K

    Signed-off-by: Mayuresh Janorkar
    Signed-off-by: Mythri P K
    [tomi.valkeinen@ti.com: squashed commits]
    Signed-off-by: Tomi Valkeinen

    Mayuresh Janorkar
     

31 Aug, 2011

1 commit


24 Aug, 2011

1 commit

  • Fixes earlier problems where monitor would not return from blank

    Test with any DisplayLink-based USB 2.0 graphics adapter
    sudo nano /sys/class/graphics/fb?/blank
    and write out single digit FB_BLANK_* code from include/linux/fb.h

    Supports on (0), blank (1), suspend (2,3), powerdown (4)

    Signed-off-by: Bernie Thompson
    Signed-off-by: Florian Tobias Schandinat

    Bernie Thompson
     

19 Aug, 2011

1 commit


25 Jul, 2011

2 commits


01 Jul, 2011

3 commits


24 May, 2011

2 commits


23 May, 2011

4 commits

  • Since the NV24 framebuffer has a CbCr plane that is twice as wide
    as the Y plane, it needs to be handled as a special case.

    Signed-off-by: Damian Hobson-Garcia
    Signed-off-by: Paul Mundt

    Damian
     
  • Based on the patch by Takanari Hayama

    Adds support framework necessary to use Media RAM (MERAM)
    caching functionality with the LCDC. The MERAM is accessed
    through up to 4 Interconnect Buffers (ICBs).

    ICB numbers and MERAM address ranges to use are specified in
    by filling in the .meram_cfg member of the LCDC platform data

    Signed-off-by: Damian Hobson-Garcia
    Signed-off-by: Paul Mundt

    Damian
     
  • Add the support for NV12 color format.
    Configure base address for UV component of NV12 color format.
    Change the way chroma scaling is handled for YUV formats on OMAP4 by enabling
    chroma-resampling for video pipeline and hence using FIR2 register set for
    scaling UV.
    Changes to _dispc_set_scaling(), because of the reason above, are:
    - call _dispc_set_scaling_common() to handle scaling for all color formats
    except for OMAP4 where it only handles scaling for RGB or Y-component
    - call _dispc_set_scaling_uv() for special handling required for UV
    component on OMAP4.
    - dispc_set_scaling_uv() also resets chroma-resampling bit for RGB color modes.

    Contains chroma scaling (_dispc_set_scaling_uv) design and implemented by
    Lajos Molnar

    Signed-off-by: Amber Jain
    Signed-off-by: Tomi Valkeinen

    Amber Jain
     
  • Add new color formats supported by OMAP4: NV12, RGBA16, RGBX16,
    ARGB16_1555, XRGB16_1555.
    NV12 color format is defined here, its support in DSS will be added separately.

    Signed-off-by: Amber Jain
    Signed-off-by: Tomi Valkeinen

    Amber Jain
     

16 May, 2011

1 commit

  • On OMAP3, the DSI module has 2 data lanes. On OMAP4, DSI1 has 4 data lanes
    and DSI2 has 2 data lanes. Introduce function dsi_get_num_data_lanes() which
    returns the number of data lanes on the dsi interface, introduce function
    dsi_get_num_data_lanes_dssdev() which returns the number of data lanes used by
    the omap_dss_device connected to the lanes.

    Use the DSI_GNQ register on OMAP4 to get the number of data lanes, modify
    dsi.c to use the number of lanes and the extra data lanes on DSI1.

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

    Archit Taneja