summaryrefslogtreecommitdiffstats
path: root/Documentation/arm/OMAP
Commit message (Collapse)AuthorAgeFilesLines
* Documentation: ARM: Add new MMC requirements for DRA7/K2GKishon Vijay Abraham I2018-05-031-0/+4
| | | | | | | | | | From 4.18 kernel, all the MMC controller instances in DRA7 are programmed using sdhci based driver (sdhci-omap.c). Document this new requirement here. Both omap2plus_defconfig and multi_v7_defconfig has CONFIG_MMC_SDHCI_OMAP enabled. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* Documentation: ARM: List new omap MMC requirementsTony Lindgren2015-10-121-0/+7
| | | | | | | | | Earlier the PBIAS regulator was optional, not so with recent omap_hsmmc changes. To make things easier for people with custom .config files, let's add minimal documentation for it as suggested by Russell King <rmk+kernel@arm.linux.org.uk>. Signed-off-by: Tony Lindgren <tony@atomide.com>
* doc: Fix typo in doucmentationsMasanari Iida2013-07-251-1/+1
| | | | | | | | Correct typo (double words) in documentations. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* OMAPFB: use dma_alloc_attrs to allocate memoryTomi Valkeinen2012-11-131-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@ti.com>
* OMAPDSS: Provide an interface for audio supportRicardo Neri2012-05-111-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@ti.com>
* OMAPDSS: VENC: allow switching venc output type at runtimeGrazvydas Ignotas2012-05-111-0/+1
| | | | | | | | | | | | | | 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 <notasas@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* omap: opp: add OMAP3 OPP table data and common initNishanth Menon2010-12-211-0/+25
| | | | | | | | | | | | 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 <thomas.petazzoni@free-electrons.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* OMAP: DSS: Fix documentation regarding 'vram' kernel parameterTomi Valkeinen2010-11-101-3/+4
| | | | | | | | The DSS documentation didn't mention the option to give the VRAM start address. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
* OMAP: DSS2: Documentation for DSS2Tomi Valkeinen2009-12-091-0/+317
| | | | Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
* OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layerPaul Walmsley2009-09-031-0/+129
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 <rnayak@ti.com> 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 <tero.kristo@nokia.com> for fixing the parameter check in omap_pm_set_min_bus_tput(). Jouni signed off on Tero's patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Tero Kristo <tero.kristo@nokia.com> Signed-off-by: Jouni Högander <jouni.hogander@nokia.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Igor Stoppa <igor.stoppa@nokia.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Anand Sawant <sawant@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Veeramanikandan Raju <veera@ti.com> Cc: Karthik Dasu <karthik-dp@ti.com>