linux/include/video, branch v3.5

Merge tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6

2012-06-01T23:57:51Z

Pull fbdev updates from Florian Tobias Schandinat: - driver for AUO-K1900 and AUO-K1901 epaper controller - large updates for OMAP (e.g. decouple HDMI audio and video) - some updates for Exynos and SH Mobile - various other small fixes and cleanups * tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6: (130 commits) video: bfin_adv7393fb: Fix cleanup code video: exynos_dp: reduce delay time when configuring video setting video: exynos_dp: move sw reset prioir to enabling sw defined function video: exynos_dp: use devm_ functions fb: handle NULL pointers in framebuffer release OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request OMAPDSS: Apply VENC timings even if panel is disabled OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC OMAPDSS: DISPC: Support rotation through TILER OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n OMAPFB: remove compiler warnings when CONFIG_BUG=n OMAPDSS: remove compiler warnings when CONFIG_BUG=n OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods OMAPDSS: DISPC: Update Accumulator configuration for chroma plane drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers video: exynos mipi dsi: support reverse panel type video: exynos mipi dsi: Properly interpret the interrupt source flags video: exynos mipi dsi: Avoid races in probe() ...

Merge tag 'omapdss-for-3.5' of git://github.com/tomba/linux into fbdev-next

2012-05-27T20:58:20Z

Omapdss driver changes for 3.5 merge window. Lots of normal development commits, but perhaps most notable changes are: * HDMI rework to properly decouple the HDMI audio part from the HDMI video part. * Restructure omapdss core driver so that it's possible to implement device tree support. This included changing how platform data is passed to the drivers, changing display device registration and improving the panel driver's ability to configure the underlying video output interface. * Basic support for DSI packet interleaving

Merge tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

2012-05-22T16:23:24Z

Pull first batch of arm-soc cleanups from Olof Johansson: "These cleanups are basically all over the place. The idea is to collect changes with minimal impact but large number of changes so we can avoid them from distracting in the diffstat in the other series. A significant number of lines get removed here, in particular because the ixp2000 and ixp23xx platforms get removed. These have never been extremely popular and have fallen into disuse over time with no active maintainer taking care of them. The u5500 soc never made it into a product, so we are removing it from the ux500 platform. Many good cleanups also went into the at91 and omap platforms, as has been the case for a number of releases." Trivial modify-delete conflicts in arch/arm/mach-{ixp2000,ixp23xx} * tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (152 commits) ARM: clps711x: Cleanup IRQ handling ARM clps711x: Removed unused header mach/time.h ARM: clps711x: Added note about support EP731x CPU to Kconfig ARM: clps711x: Added missing register definitions ARM: clps711x: Used own subarch directory for store header file Dove: Fix Section mismatch warnings ARM: orion5x: ts78xx debugging changes ARM: orion5x: remove PM dependency from ts78xx ARM: orion5x: ts78xx fix NAND resource off by one ARM: orion5x: ts78xx whitespace cleanups Orion5x: Fix Section mismatch warnings Orion5x: Fix warning: struct pci_dev declared inside paramter list ARM: clps711x: Combine header files into one for clps711x-targets ARM: S3C24XX: Use common macro to define resources on mach-qt2410.c ARM: S3C24XX: Use common macro to define resources on mach-osiris.c ARM: EXYNOS: Adapt to cpuidle core time keeping and irq enable ARM: S5PV210: Use common macro to define resources on mach-smdkv210.c ARM: S5PV210: Use common macro to define resources on dev-audio.c ARM: S5PC100: Use common macro to define resources on dev-audio.c ARM: S5P64X0: Use common macro to define resources on dev-audio.c ...

OMAPDSS: DISPC: Support rotation through TILER

2012-05-22T07:59:15Z

TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner. Physical memory can be mapped to a portion of OMAP's system address space called TILER address space. The TILER address space is split into 8 views. Each view represents a rotated or mirrored form of the mapped physical memory. When a DISPC overlay's base address is programmed to one of these views, the TILER fetches the pixels according to the orientation of the view. A view is further split into 4 containers, each container holds elements of a particular size. Rotation can be achieved at the granularity of elements in the container. For more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM. Rotation type TILER has been added which is used to exploit the capabilities of these 8 views for performing various rotations. When fetching from addresses mapped to TILER space, the DISPC DMA can fetch pixels in either 1D or 2D bursts. The fetch depends on which TILER container we are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts, and page mode sized containers require 1D bursts. The DSS2 user is expected to provide the Tiler address of the view that it is interested in. This is passed to the paddr and p_uv_addr parameters in omap_overlay_info. It is also expected to provide the stride value based on the view's orientation and container type, this should be passed to the screen_width parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is used to calculate the required row_inc for DISPC. x_predecim and y_predecim are also used to calculate row_inc and pix_inc thereby adding predecimation support for TILER. Signed-off-by: Chandrabhanu Mahapatra Signed-off-by: Tomi Valkeinen

video: exynos mipi dsi: support reverse panel type

2012-05-13T13:08:23Z

This patch adds panel_reverse variable to support reversed s6e8ax0 panel type. Signed-off-by: Donghwa Lee Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park Signed-off-by: Florian Tobias Schandinat

fbdev: sh_mobile_hdmi: add HDMI Control Register support

2012-05-13T13:07:59Z

Latest SuperH HDMI uses not only HDMI Core Register (HTOP0) but also HDMI Control Register (HTOP1). This patch adds HDMI Control Register support. Signed-off-by: Kuninori Morimoto Signed-off-by: Florian Tobias Schandinat

fbdev: sh_mobile_hdmi: 32bit register access support

2012-05-13T13:07:59Z

Latest SuperH HDMI allows 32bit access only. But the data is 8bit. So, we can keep compatibility by switching 8/32 bit access. Signed-off-by: Kuninori Morimoto Signed-off-by: Florian Tobias Schandinat

fbdev: sh_mobile_hdmi: add interrupt output option

2012-05-13T13:07:59Z

Signed-off-by: Kuninori Morimoto Signed-off-by: Florian Tobias Schandinat

OMAPDSS: Provide an interface for audio support

2012-05-11T12:13:50Z

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

OMAPDSS: clean up the omapdss platform data mess

2012-05-11T11:44:51Z

The omapdss pdata handling is a mess. This is more evident when trying to use device tree for DSS, as we don't have platform data anymore in that case. This patch cleans the pdata handling by: - Remove struct omap_display_platform_data. It was used just as a wrapper for struct omap_dss_board_info. - Pass the platform data only to omapdss device. The drivers for omap dss hwmods do not need the platform data. This should also work better for DT, as we can create omapdss device programmatically in generic omap boot code, and thus we can pass the pdata to it. - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads that the dss hwmod drivers can call. Signed-off-by: Tomi Valkeinen