13 Oct, 2015

1 commit


25 Jul, 2013

1 commit


13 Nov, 2012

1 commit

  • Use dma_alloc_attrs to allocate memory instead of omap specific vram
    allocator. After this we can remove the omap vram allocator.

    There are some downsides to this change:

    1) dma_alloc_attrs doesn't let us allocate at certain physical address.
    However, this should not be a problem as this feature of vram allocator
    is only used when reserving the framebuffer that was initialized by the
    bootloader, and we don't currently support "passing" a framebuffer from
    the bootloader to the kernel anyway.

    2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
    we don't need the ioremap when using VRFB. This patch uses
    DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
    not operational.

    3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
    changed the ioctl to return 64M for all the values, which, I hope, the
    applications will interpret as "there's enough vram".

    4) "vram" kernel parameter to define how much ram to reserve for video
    use no longer works. The user needs to enable CMA and use "cma"
    parameter.

    Signed-off-by: Tomi Valkeinen

    Tomi Valkeinen
     

11 May, 2012

2 commits

  • There exist several display technologies and standards that support audio as
    well. Hence, it is relevant to update the DSS device driver to provide an audio
    interface that may be used by an audio driver or any other driver interested in
    the functionality.

    The audio_enable function is intended to prepare the relevant
    IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
    some IP, enabling companion chips, etc). It is intended to be called before
    audio_start. The audio_disable function performs the reverse operation and is
    intended to be called after audio_stop.

    While a given DSS device driver may support audio, it is possible that for
    certain configurations audio is not supported (e.g., an HDMI display using a
    VESA video timing). The audio_supported function is intended to query whether
    the current configuration of the display supports audio.

    The audio_config function is intended to configure all the relevant audio
    parameters of the display. In order to make the function independent of any
    specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
    is to contain all the required parameters for audio configuration. At the
    moment, such structure contains pointers to IEC-60958 channel status word and
    CEA-861 audio infoframe structures. This should be enough to support HDMI and
    DisplayPort, as both are based on CEA-861 and IEC-60958. The omap_dss_audio
    structure may be extended in the future if required.

    The audio_enable/disable, audio_config and audio_supported functions could be
    implemented as functions that may sleep. Hence, they should not be called
    while holding a spinlock or a readlock.

    The audio_start/audio_stop function is intended to effectively start/stop audio
    playback after the configuration has taken place. These functions are designed
    to be used in an atomic context. Hence, audio_start should return quickly and be
    called only after all the needed resources for audio playback (audio FIFOs,
    DMA channels, companion chips, etc) have been enabled to begin data transfers.
    audio_stop is designed to only stop the audio transfers. The resources used
    for playback are released using audio_disable.

    A new enum omap_dss_audio_state is introduced to help the implementations of
    the interface to keep track of the audio state. The initial state is _DISABLED;
    then, the state transitions to _CONFIGURED, and then, when it is ready to
    play audio, to _ENABLED. The state _PLAYING is used when the audio is being
    rendered.

    Signed-off-by: Ricardo Neri

    Ricardo Neri
     
  • VENC output type (composite/svideo) doesn't have to be fixed by board
    wiring, it is possible to also provide composite signal through svideo
    luminance connector (software enabled), which is what pandora does.

    Having to recompile the kernel for users who have TV connector types
    that don't match default board setting is very inconvenient, especially
    for users of a consumer device, so add support for switching VENC output
    type at runtime over a new sysfs file output_type.

    Signed-off-by: Grazvydas Ignotas
    Signed-off-by: Tomi Valkeinen

    Grazvydas Ignotas
     

22 Dec, 2010

1 commit

  • Add OPP data for OMAP34xx and OMAP36xx and initialization functions
    to populate OPP tables based on current SoC.
    introduce an OMAP generic opp initialization routine which OMAP3
    and OMAP4+ SoCs can use to register their OPP definitions.

    Cc: Thomas Petazzoni
    Signed-off-by: Kevin Hilman
    Signed-off-by: Nishanth Menon
    Signed-off-by: Kevin Hilman

    Nishanth Menon
     

10 Nov, 2010

1 commit


09 Dec, 2009

1 commit


04 Sep, 2009

1 commit

  • The interface provides device drivers, CPUFreq, and DSPBridge with a
    means of controlling OMAP power management parameters that are not yet
    supported by the Linux PM PMQoS interface. Copious documentation is
    in the patch in Documentation/arm/OMAP/omap_pm and the interface
    header file, arch/arm/plat-omap/include/mach/omap-pm.h.

    Thanks to Rajendra Nayak for adding CORE (VDD2) OPP
    support and moving the OPP table initialization earlier in the event
    that the clock code needs them. Thanks to Tero Kristo
    for fixing the parameter check in
    omap_pm_set_min_bus_tput(). Jouni signed off on Tero's patch.

    Signed-off-by: Paul Walmsley
    Signed-off-by: Kevin Hilman
    Signed-off-by: Rajendra Nayak
    Signed-off-by: Tero Kristo
    Signed-off-by: Jouni Högander
    Cc: Tony Lindgren
    Cc: Igor Stoppa
    Cc: Richard Woodruff
    Cc: Anand Sawant
    Cc: Sakari Poussa
    Cc: Veeramanikandan Raju
    Cc: Karthik Dasu

    Paul Walmsley