The DPI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the DPI interface
driver dependent on the omap_dss_device struct.

Make the DPI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_dpi_set_data_lines() before enabling the interface.
Signed-off-by: NArchit Taneja <archit@ti.com>

The RFBI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the RFBI interface
driver dependent on the omap_dss_device struct.

Make the RFBI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_rfbi_set_data_lines() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().
Signed-off-by: NArchit Taneja <archit@ti.com>

The RFBI driver currently relies on the omap_dss_device struct to receive the
desired pixel size of the panel. This makes the RFBI interface driver dependent
on the omap_dss_device struct.

Make the RFBI driver data maintain it's own pixel format field. A panel driver
is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().
Signed-off-by: NArchit Taneja <archit@ti.com>

The DSI driver currently relies on the omap_dss_device struct to receive the
desired pixel format of the panel. This makes the DSI interface driver dependent
on the omap_dss_device struct.

Make the DSI driver data maintain it's own pixel format field. The panel driver
is expected to call omapdss_dsi_set_pixel_format() to configure the pixel format
before the interface is enabled.
Signed-off-by: NArchit Taneja <archit@ti.com>

RFBI drivers requires configuration of the update area. Since we don't support
partial updates, the size to be configures is the panel size itself.

Add a timings field in RFBI's driver data. Apart from x_res and y_res, all the
other fields are configured to an initial value when RFBI is enabled. A panel
driver is expected to call omapdss_rfbi_set_size() configure the size of the
panel.
Signed-off-by: NArchit Taneja <archit@ti.com>

Partial update suppport was removed from DISPC and DSI sometime back. The RFBI
driver still tries to support partial update without the underlying support in
DISPC.

Remove partial update support from RFBI, only support updates which span acros
the whole panel size. This also helps in DSI and RFBI having similar update
ops.
Signed-off-by: NArchit Taneja <archit@ti.com>

Create function omapdss_sdi_set_timings(). Configuring new timings is done the
same way as before, SDI is disabled, and re-enabled with the new timings in
dssdev. This just moves the code from the panel drivers to the SDI driver.

The panel drivers shouldn't be aware of how SDI manages to configure a new set
of timings. This should be taken care of by the SDI driver itself.
Signed-off-by: NArchit Taneja <archit@ti.com>

DSI command mode panels don't need to configure a full set of timings to
configure DSI, they only require the width and the height of the panel in
pixels.

Use omapdss_dsi_set_size for command mode panels, omapdss_dsi_set_timings is
meant for video mode panels. When performing rotation via chaning the address
mode of the panel, we would need to swap width and height when doing 90 or 270
rotation. Make sure that omapdss_dsi_set_size() makes the new width and height
visible to DSI.
Signed-off-by: NArchit Taneja <archit@ti.com>

The DSI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and DSI blocks accordingly. This makes the DSI interface
driver dependent on the omap_dss_device struct.

Make the DSI driver data maintain it's own timings field. A DSI video mode panel
driver is expected to call omapdss_dsi_set_timings() to set these timings before
the panel is enabled.
Signed-off-by: NArchit Taneja <archit@ti.com>

The DPI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the DPI interface driver dependent
on the omap_dss_device struct.

Make the DPI driver data maintain it's own timings field. The panel driver is
expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set
these timings before the panel is enabled.

In the set_timings() op, we still ensure that the omap_dss_device timings
(dssdev->panel.timings) are configured. This will later be configured only by
the DPI panel drivers.
Signed-off-by: NArchit Taneja <archit@ti.com>

For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC
and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and
VP_DE_POL in DSI_CTRL registers.

This information is completely internal to DSS as logic levels for the above
signals hold no meaning on the DSI bus. Hence a DSI panel driver should be
totally oblivious of these fields.

Fix the logic levels/polarities in the DISPC and DSI registers to a default
value. This is done by overriding these fields in omap_video_timings struct
filled by the panel driver for DISPC, and use the equivalent default values
when programming DSI_CTRL registers. Also, remove the redundant polarity related
fields in omap_dss_dsi_videomode_data.
Signed-off-by: NArchit Taneja <archit@ti.com>

Add a parameter called interlace which tells whether the timings are in
interlaced or progressive mode. This aligns the omap_video_timings struct with
the Xorg modeline configuration.

It also removes the hack needed to write to divide the manager height by 2 if
the connected interface is VENC.
Signed-off-by: NArchit Taneja <archit@ti.com>

omap_panel_config contains fields which are finally written to DISPC_POL_FREQo
registers. These are now held by omap_video_timings and are set when the manager
timings are applied.

Remove the omap_panel_config enum, and remove all it's references from panel or
interface drivers.
Signed-off-by: NArchit Taneja <archit@ti.com>

Some panel timing related fields are contained in omap_panel_config in the form
of flags. The fields are:

- Hsync logic level
- Vsync logic level
- Data driven on rising/falling edge of pixel clock
- Output enable/Data enable logic level
- HSYNC/VSYNC driven on rising/falling edge of pixel clock

Out of these parameters, Hsync and Vsync logic levels are a part of the timings
in the Xorg modeline configuration. So it makes sense to move the to
omap_video_timings. The rest aren't a part of modeline, but it still makes
sense to move these since they are related to panel timings.

These fields stored in omap_panel_config in dssdev are configured for LCD
panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers.

Add the above fields in omap_video_timings. Represent their state via new enums.

Add these parameters to the omap_video_timings instances in the panel drivers.
Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in
omap_panel_config for now. The struct will be removed later.
Signed-off-by: NArchit Taneja <archit@ti.com>

Remove omap_lcd_display_type enum

The enum omap_lcd_display_type is used to configure the lcd display type in
DISPC. Remove this enum and always set display type to TFT by creating function
dss_mgr_set_lcd_type_tft().
Signed-off-by: NArchit Taneja <archit@ti.com>

Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.

We don't support passive matrix displays any more. Remove this flag from all the
panel drivers.

Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.
Signed-off-by: NArchit Taneja <archit@ti.com>

The support for LCD3 manager has been added into the manager module. LCD3 panel
has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and
LCD2 panels. These registers control the Display Controller (DISPC) module for
LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame
Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can
be connected through parallel output interface using DISPC and RFBI or DPI. For
serial interface DSS uses DSI.

The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL
register which has been enabled. The clock switch chooses between DSS_CLK and
DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3,
DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have
been added specific to the new manager.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

OMAP5 Display Subsystem (DSS) architecture comes with a additional LCD3 channel
with its own dedicated overlay manager. The current patch adds LCD3 channel and
basic register support for LCD3 channel. It adds register addresses for various
Display Controller (DISPC) registers like DISPC_DEFAULT_COLOR, DISPC_TIMING_H,
DISPC_DIVISORo, etc.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We have two almost the same enums: omap_channel and
omap_dss_overlay_managers. omap_channel is used almost everywhere, and
omap_channel assigns explicit values to the enum values which are needed
for proper operation.

omap_dss_overlay_managers is only used in one place, so it's easy to
remove it, which is what this patch does.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This patch adds panel_reverse variable to support reversed s6e8ax0 panel
type.
Signed-off-by: NDonghwa Lee <dh09.lee@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

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: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

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: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

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: NRicardo Neri <ricardo.neri@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.

This patch moves the configuration data to the panel's platform data,
and the data can easily be given via DT in the future. The configuration
data format is also changed to a generic one which should be suitable
for all platforms.

The new format is an array of pin numbers, where the array items start
from clock + and -, then data1 + and -, and so on. For example:

{
	0,	// pin num for clock lane +
	1,	// pin num for clock lane -
	2,	// pin num for data1 lane +
	3,	// pin num for data1 lane -
	...
}

The pin numbers are translated by the DSI driver and used to configure
the hardware appropriately.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Now that the tfp410 driver has been renamed in the code, this patch
finishes the renaming by renaming the files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The driver for the TFP410 DPI-to-DVI chip was named quite badly as "DVI
panel driver". This patch renames the code to use tfp410 name for the
driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Now that the panel-dvi driver handles the PD (power-down) GPIO, we can
remove the custom PD handling from the board files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.

This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This patch fixes max loop count in EQ(Channel Equalization) sequence
of link training. According to DP(displayport) specification,
the max loop count in this sequence should be 5.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The AUO-K190X controllers share a very similar set of commands and
can therefore also share most of the driver code.
Signed-off-by: NHeiko Stübner <heiko@sntech.de>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapdss driver needs to use the omap_pm_set_min_bus_tput(), so add a new
entry for that in omapdss's platform data, and set it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: NKevin Hilman <khilman@ti.com>

For now, it just contains the hack for cirrusfb on Amiga, which is moved
out of <video/vga.h> with some slight modifications (use raw_*() instead of
z_*(), which are defined on all m68k platforms).

This makes it safe to include <video/vga.h> in all contexts. Before it
could fail to compile with

include/video/vga.h: In function ‘vga_mm_r’:
include/video/vga.h:242: error: implicit declaration of function ‘z_readb’
include/video/vga.h: In function ‘vga_mm_w’:
include/video/vga.h:247: error: implicit declaration of function ‘z_writeb’
include/video/vga.h: In function ‘vga_mm_w_fast’:
include/video/vga.h:253: error: implicit declaration of function ‘z_writew’

or

include/video/vga.h:23:21: error: asm/vga.h: No such file or directory

depending on the value of CONFIG_AMIGA.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org

sh_mipi uses some clocks, but the method of setup depends on CPU.

Current SuperH (like sh73a0) can control all of these clocks
by CPG (Clock Pulse Generator).
It means we can control it by clock framework only.
But on sh7372, it needs CPG settings AND sh_mipi PHYCTRL::PLLDS,
and only sh7372 has PHYCTRL::PLLDS.

But on current sh_mipi driver, PHYCTRL::PLLDS of sh7372 was
overwrote since the callback timing of clock setting was changed
by c2658b70
(fbdev: sh_mipi_dsi: fixup setup timing of sh_mipi_setup()).
To solve this issue, this patch adds extra .phyctrl.

This patch adds detail explanation for unclear mipi settings
and fixup wrong PHYCTRL::PLLDS value for ap4evb (0xb -> 0x6).
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The meram_register(), meram_unregister() and meram_update() operations
check that the pointers they get from the caller are not NULL. Those
checks can be remove, as the caller already ensures that the pointers
are valid.

The platform sanity checks can also be removed, as the operations can't
be accessed without valid platform data anyway.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Remove the RGB or Y/C base address update from the meram_register()
operation, as this belongs to the meram_update() operation.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Instead of copying the whole platform data structure to struct
sh_mobile_lcdc_chan, store a const pointer to the channel platform data.

MERAM configuration information needs to be changed at runtime, so copy
it to struct sh_mobile_lcdc_chan.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>