In preparation to move the stack to use the generic videmode struct for
display timing information rename the vsw member to vsync_len.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In preparation to move the stack to use the generic videmode struct for
display timing information rename the hbp member to hback_porch.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In preparation to move the stack to use the generic videmode struct for
display timing information rename the hfp member to hfront_porch.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In preparation to move the stack to use the generic videmode struct for
display timing information rename the hsw member to hsync_len.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In preparation to move the stack to use the generic videmode struct for
display timing information rename the y_res member to vactive.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In preparation to move the stack to use the generic videmode struct for
display timing information rename the x_res member to hactive.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

All drivers to include the omapdrm/dss/omapdss.h header file. This header
includes the <video/omapdss.h>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

Use 'out->dispc_channel_connected' to check if the device is connected
to an overlay manager or not, instead of using 'out->manager'.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that omapfb has its own copy of omapdss and display drivers, we can
move omapdss and display drivers which omapdrm uses to omapdrm's
directory.

We also need to change the main drm Makefile so that omapdrm directory
is always entered, because omapdss has a file that can't be built as a
module.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Acked-by: NRob Clark <robdclark@gmail.com>

All the output drivers check for 'out' being NULL, but it can never be
NULL. Remove the check.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

omapdss kernel module contains drivers for multiple devices, one for
each DSS submodule. The probing we have at the moment is a mess, and
doesn't give us proper deferred probing nor ensure that all the devices
are probed before omapfb/omapdrm start using omapdss.

This patch solves the mess by using the component system for DSS
submodules.

The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
venc) are the same: probe & remove functions are changed to bind &
unbind, and new probe & remove functions are added which call
component_add/del.

The dss_core driver (dss.c) acts as a component master. Adding and
matching the components is simple: all dss device's child devices are
added as components.

However, we do have some dependencies between the drivers. The order in
which they should be probed is reflected by the list in core.c
(dss_output_drv_reg_funcs). The drivers are registered in that order,
which causes the components to be added in that order, which makes the
components to be bound in that order. This feels a bit fragile, and we
probably should improve the code to manage binds in random order.
However, for now, this works fine.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The following patches will add component handling to omapdss, improving
the handling of deferred probing. However, at the moment we're using
quite a lot of __inits and __exits in the driver, which prevent normal
dynamic probing and removal.

This patch removes most of the uses of __init and __exit, so that we can
register drivers after module init, and so that we can unregister
drivers even if the module is built-in.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

DISPC can drive data lines either on rising or falling pixel clock edge,
which can be configured by the user.

Sync lines can also be driven on rising or falling pixel clock edge, but
additionally the HW can be configured to drive the sync lines on
opposite clock edge from the data lines.

This opposite edge setting does not make any sense, as the same effect
can be achieved by just setting the sync lines to be driven on the other
edge compared to the data lines. It feels like some kind of backward
compatibility option, even if all DSS versions seem to have the same
implementation.

To simplify the code and configuration of the signals, and to make the
dispc timings more compatible with what is used on other platforms,
let's just remove the whole opposite-edge support.

The drivers that used OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES setting are
changed so that they use the opposite setting from the data edge.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapdss drivers cannot handle devices being unbound while the devices
are part of a connected display pipeline. Module refcounts are used to
prevent unloading the modules, but one can still manually unbind the
devices via sysfs, causing crash.

Set suppress_bind_attrs to disable the bind/unbind support via sysfs.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.

Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.

No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NRob Clark <robdclark@gmail.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.

This patch removes the code from the RFBI driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

In order to allow multiple display block in a video pipeline, we need to
give the drivers way to register themselves. For now we have
the omapdss_register_display() which is used to register panels, and
dss_register_output() which is used to register DSS encoders.

This patch makes dss_register_output() public (with the name of
omapdss_register_output), which can be used to register also external
encoders. The distinction between register_output and register_display
is that a "display" is an entity at the end of the videopipeline, and
"output" is something inside the pipeline.

The registration and naming will be made saner in the future, but the
current names and functions are kept to minimize changes during the dss
device model transition.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Setup the owner field for DSS output's omap_dss_device so that module
refcounting works.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have omap_dss_device, which represents an external display
device, sometimes an external encoder, sometimes a panel. Then we have
omap_dss_output, which represents DSS's output encoder.

In the future with new display device model, we construct a video
pipeline from the display blocks. To accomplish this, all the blocks
need to be presented by the same entity.

Thus, this patch combines omap_dss_output into omap_dss_device. Some of
the fields in omap_dss_output are already found in omap_dss_device, but
some are not. This means we'll have DSS output specific fields in
omap_dss_device, which is not very nice. However, it is easier to just
keep those output specific fields there for now, and after transition to
new display device model is made, they can be cleaned up easier than
could be done now.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omap_dss_start_device() and omap_dss_stop_device(), called by the
DSS output drivers, are old relics. They originally did something
totally else, but nowadays they increase the module ref count for panels
that are enabled.

This model is quite broken: the panel modules may be used even before
they are enabled. For example, configuring the panel requires calls to
functions located in the panel modules.

In the following patches we try to improve the ref count management for
the modules and display devices. The first step, however, is to remove
the omap_dss_start/stop_device() totally.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In the future the "dssdev" parameter passed to output drivers will
change its meaning. Instead of being a pointer to the panel device, it's
a pointer to the output instance.

To make the transition easier, some of the uses for this dssdev
parameter can be easily removed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapdss output drivers always read the platform data. This crashes when
there's no platform data when using DT.

Add a check to read the platform data only if it exists.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for rfbi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the RFBI driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The DISPC channel used for each output is currently passed in panel
platform data from the board files.

To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id. This resolved channel is stored into a new field in
output, dispc_channel.

The few places where dssdev->channel was used are changed to use
output->recommended_channel. After this patch, dssdev->channel is
obsolete.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

Add name field to omapdss's outputs so that in the following patches
panels refer to the output by their name. The name also helps debugging.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

Some of the output drivers need to handle FRAMEDONE interrupt from
DISPC. This creates a direct dependency to dispc code, and we need to
avoid this to make the compat code to work.

Instead of the output drivers registering for dispc interrupts, we
create new mgr-ops that are used to register a framedone handler. The
code implementing the mgr-ops is responsible for calling the handler
when DISPC FRAMEDONE interrupt happens. The compat layer is improved
accordingly to do the call to the framedone handler.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently attach an output to a dssdev in the initialization code for
dssdevices in display.c. This works, but doesn't quite make sense: an
output entity represents (surprisingly) an output of DSS, which is
managed by an output driver. The output driver also handles adding new
dssdev's for that particular output.

It makes more sense to make the output-dssdev connection in the output
driver. This is also in line with common display framework.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Export dss_get_def_display_name() with the name of
omapdss_get_def_display_name() so that omapfb can use it after the next
patch which moves default display handling to omapfb.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

With addition of output entities, a device connects to an output, and an output
connects to overlay manager. Replace the dssdev->manager references with
dssdev->output->manager to access the manager correctly.

When enabling the RFBI output, check whether the output entity connected to
display is not NULL.
Signed-off-by: NArchit Taneja <archit@ti.com>

Add output structs to output driver's private data. Register output instances by
having an init function in the probes of the platform device drivers for
different outputs. The *_init_output for each output registers the output and
fill up the output's plaform device, type and id fields. The *_uninit_output
functions unregister the output.

In the probe of each interface driver, the output entities are initialized
before the *_probe_pdata() functions intentionally. This is done to ensure that
the output entity is prepared before the panels connected to the output are
registered. We need the output entities to be ready because OMAPDSS will try
to make connections between overlays, managers, outputs and devices during the
panel's probe.
Signed-off-by: NArchit Taneja <archit@ti.com>

We currently create omap_dss_devices statically in board files, and use
those devices directly in the omapdss driver. This model prevents us
from having the platform data (which the dssdevs in board files
practically are) as read-only, and it's also different than what we will
use with device tree.

This patch changes the model to be in line with DT model: we allocate
the dssdevs dynamically, and initialize them according to the data in
the board file's dssdev (basically we memcopy the dssdev fields).

The allocation and registration is done in the following steps in the
output drivers:

- Use dss_alloc_and_init_device to allocate and initialize the device.
  The function uses kalloc and device_initialize to accomplish this.
- Call dss_copy_device_pdata to copy the data from the board file's
  dssdev
- Use dss_add_device to register the device.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We have boards with multiple panel devices connected to the same
physical output, of which only one panel can be enabled at one time.
Examples of these are Overo, where you can use different daughter boards
that have different LCDs, and 3430SDP which has an LCD and a DVI output
and a physical switch to select the active display.

These are supported by omapdss so that we add all the possible display
devices at probe, but the displays are inactive until somebody enables
one. At this point the panel driver starts using the DSS, thus reserving
the physcal resource and excluding the other panels.

This is problematic:
- Panel drivers can't allocate their resources properly at probe(),
  because the resources can be shared with other panels. Thus they can
  be only reserved at enable time.
- Managing this in omapdss is confusing. It's not natural to have
  child devices, which may not even exist (for example, a daughterboard
  that is not connected).

Only some boards have multiple displays per output, and of those, only
very few have possibility of switching the display during runtime.
Because of the above points:
- We don't want to make omapdss and all the panel drivers more complex
  just because some boards have complex setups.
- Only few boards support runtime switching, and afaik even then it's
  not required. So we don't need to support runtime switching.

Thus we'll change to a model where we will have only one display device
per output and this cannot be (currently) changed at runtime. We'll
still have the possibility to select the display from multiple options
during boot with the default display option.

This patch accomplishes the above by changing how the output drivers
register the display device. Instead of registering all the devices
given from the board file, we'll only register one. If the default
display option is set, the output driver selects that display from its
displays. If the default display is not set, or the default display is
not one of the output's displays, the output driver selects the first
display.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We used to have all the displays of the board in one list, and we made a
"displayX" directory in the sysfs, where X was the index of the display
in the list.

This doesn't work anymore with device tree, as there's no single list to
get the number from, and it doesn't work very well even with non-DT as
we need to do some tricks to get the index nowadays.

This patch changes omap_dss_register_device() so that it doesn't take
disp_num as a parameter anymore, but uses a private increasing counter
for the display number.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Recent commit dca2b152 (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev->caps are initialized, and
the result was that every DSI display is initialized with manual-update
and tear-elim caps.

The code that sets dssdev->caps is not very good, even when fixed.
omapdss driver shouldn't be writing dssdev->caps at all.

This patch fixes the problem with video mode displays by moving the
initialization of dssdev->caps to the panel driver. The same change is
done for RFBI.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The RFBI driver currently relies on the omap_dss_device struct to receive the
rfbi specific timings requested by the panel driver. This makes the RFBI
interface driver dependent on the omap_dss_device struct.

Make the RFBI driver data maintain it's own rfbi specific timings field. The
panel driver is expected to call omapdss_rfbi_set_interface_timings() to
configure the rfbi timings before the interface is enabled.
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>

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>