The omapdrm and omapdss drivers are architectured based on display
pipelines made of multiple components handled from sink (display) to
source (DSS output). This is incompatible with the DRM bridge and panel
APIs that handle components from source to sink.

Reconcile the omapdrm and omapdss drivers with the DRM bridge and panel
model by reversing the direction of the DSS device .enable() and
.disable() operations. This completes the move to the DRM bridge model,
with the notable exception of the DSI pipelines that will require more
work.

We also adapt the omapdss shutdown handler dss_shutdown() to shut down
all active pipelines starting from the pipeline output device instead of
the display device.

As a consequence the for_each_dss_display() macro isn't used and can be
removed, and the omapdss_device_get_next() function underlying the macro
can be simplified to search for output devices only.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The displays (connectors, panels and encoders) return an error from
their .enable() handler when the dss device is not connected. They also
disconnect the dss device explicitly from their .remove() handler if it
is still connected.

Those safety checks are not needed:

- The .enable() handler is called from code paths that access the dss
  devices chain from the display device, which is set to NULL when the
  device isn't connected.

- The .remove() handler can only be called when unloading the module as
  the driver has the suppress_bind_attrs attribute set, and a reference
  to the module is taken when constructing the dss devices chain, so the
  module can only be unloaded when the dss device is disconnected.

Remove the safety checks.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The internal encoders return an error from their .enable() handler when
their are not connected to a dss manager. As the flag used is set and
cleared in the connect and disconnect handlers, this effectively checks
whether the omap_dss_device is connected.

The .enable() handler is called from code paths that access the dss
devices chain from the display device, which is set to NULL when the
device isn't connected, making it impossible to access the device in
that case.

The safety check is thus not needed, remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Instead of rolling out custom suspend/resume implementations based on
state information stored in the driver's data structures, use the atomic
suspend/resume helpers that rely on a DRM atomic state object.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The kobj field from struct omap_dss_device is not used. Remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

panel-dpi used to convey the bus-flags via the videomode, but recent
changes changed the use of videomode to DRM's drm_display_mode which
does not contain bus-flags. This broke panel-dpi, which didn't
explicitly store the bus-flags into dssdev->bus_flags.

Fix this by setting dssdev->bus_flags. Also change the bus_flags type to
u32, as that is the type used in the DRM framework, and we would get a
warning with drm_bus_flags_from_videomode() otherwise.

Fixes: 3fbda31e ("drm/omap: Split mode fixup and mode set from encoder enable")
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NH. Nikolaus Schaller <hns@goldelico.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181126092447.11864-1-tomi.valkeinen@ti.comReviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Instead of call the dispc timings check function dispc_mgr_timings_ok()
from the internal encoders .check_timings() operation, expose it through
the dispc ops (after renaming it to check_timings) and call it directly
from omapdrm. This allows removal of now empty omap_dss_device
.check_timings() operations.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Source components in the display pipeline need to configure their output
signals polarities and clock driving edge based on the requirements of
the sink component.

Those requirements are currently shared across the whole pipeline in the
flags of a videomode structure, instead of being local to each bus. This
both prevents multiple buses from having different configurations (when
the hardware supports it), and makes it difficult to move from videomode
to drm_display_mode as the latter doesn't contain bus polarities and
clock edge flags.

Add a bus_flags field to the omap_dss_device structure and move the
DISPLAY_FLAGS_DE_(LOW|HIGH), DISPLAY_FLAGS_PIXDATA_(POS|NEG)EDGE and
DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE videomode flags to bus_flags in all
external encoders, connectors and panels. The videomode flags are still
used internally for internal encoders, this will be addressed in a
second step.

The related videomode flags in the default mode of the DVI connector can
simply be dropped, as they are always overridden by the TFP410 driver.
Note that this results in both the DISPLAY_FLAGS_SYNC_POSEDGE and
DISPLAY_FLAGS_SYNC_NEGEDGE flags being set, which is invalid, but only
the former is tested for when programming the DISPC, so the DVI
connector flags are effectively overridden by the TFP410 flags.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The .set_timings() operations of the omap_dss_device instances don't
need to modify the passed timings. Make the pointer const.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable
and disable hot-plug detection at omapdrm probe and remove time. This is
required to avoid reporting hot-plug detection events before the DRM
infrastructure is ready to accept them, as that could result in crashes
or other malfunction.

Hot-plug event reporting is conditioned by both HPD being enabled
through the .enable_hpd() operation and by the HPD callback being
registered though the .register_hpd_cb() operation. We thus don't need a
separate enable operation if we can guarantee that callbacks won't be
registered too early.

HPD callbacks are registered at connector initialization time, which is
too early to start reporting HPD events. There's however nothing
blocking a move of callback registration to a later time when the
omapdrm driver calls the HPD enable operations. Do so, and remove the
HPD enable operation completely from omap_dss_device drivers.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The HPD-related omap_dss_device operations are now only called when the
device supports HPD. There's no need to duplicate that check in the
omap_dss_device drivers. The .register_hpd_cb() operation can as a
result be turned into a void operation.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When an omap_dss_device operation can be implemented in multiple places
in a chain of devices, it is important to find out which device to
address to perfom the operation. This is currently done by calling the
operation on the display device at the end of the chain, and recursively
delagating the operation to the previous device if it can't be performed
locally. The drawback of this approach is an increased complexity in
omap_dss_device drivers.

In order to simplify the drivers, we will switch from a recursive model
to an interative model, centralizing the complexity in a single
location. This requires knowing which operations an omap_dss_device
supports at runtime. We can already test which operations are
implemented by checking the operation pointer, but implemented
operations can require resources whose availability varies between
systems. For instance a hot-plug signal from a connector can be wired to
a GPIO or to a bridge chip.

Add operation flags that can be set in the omap_dss_device structure by
drivers to signal support for operations.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_dss_device instances have two ops structures, omap_dss_driver and
omap_dss_device_ops. The former is used for devices at the end of the
pipeline (a.k.a. display devices), and the latter for intermediate
devices.

Having two sets of operations isn't convenient as code that iterates
over omap_dss_device instances need to take them both into account.
There's currently a reasonably small amount of such code, but more will
be introduced to move the driver away from recursive operations. To
simplify current and future code, move all operations that are not
specific to the display device to the omap_dss_device_ops.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Various functions that need to differentiate between omap_dss_device
instances corresponding to displays and to internal encoders use the
omap_dss_device.driver field, which is only set for display instances.
This gets in the way of the omap_dss_device operations refactoring.
Replace that with a check based on the output_type field which is set
for all omap_dss_device instances but displays.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The .get_mirror() and .set_mirror() omap_dss_driver operations are
implemented by the panel-tpo-td043mtea1 driver but are never used.
Remove them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The .probe(), .remove(), .run_test(), .get_rotate() and .set_rotate()
omap_dss_driver operations are not used. Remove them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The dss_mgr .connect() and .disconnect() are implemented as no-op in
omapdrm. The operations are unneeded, remove them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The CRTC connect handler checks whether the DSS output supports the
DISPC channel assigned to it. As the channel is assigned to the output
by the output driver a failure there could only result from a driver
bug. All the output drivers have been verified and they are always
assigned a DISPC channel that is supported on the SoC they run on. The
check can thus be removed.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Replace the dss display device pointer by a pipe pointer that will allow
the omap_crtc_init() function to access both the display and the DSS
output. As a result we can remove the omapdss_device_get_dispc_channel()
function that is now unneeded.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

To simplify the pipeline disconnection handling merge the
omapdss_device_disconnect() and omapdss_output_unset_device() functions.
The device state check is now called for every device in the pipeline,
extending this sanity check coverage.

There is no need to return an error from omapdss_device_disconnect()
when the check fails, as omapdss_output_unset_device() used to do, given
that we can't prevent disconnection due to device unbinding (the return
value of omapdss_output_unset_device() is never checked in the current
code for that reason).
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The display type is validated when the display is connected to the DSS
output. We already have all the information we need for validation when
initializing the outputs. Move validation to output initialization to
simplify pipeline connection handling.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omapdrm and omapdss drivers are architectured based on display
pipelines made of multiple components handled from sink (display) to
source (DSS output). This is incompatible with the DRM bridge and panel
APIs that handle components from source to sink.

To reconcile the omapdrm and omapdss drivers with the DRM bridge and
panel model, we need to reverse the direction of the DSS device
operations. Start with the connect and disconnect operations.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The dss_mgr_connect() and dss_mgr_disconnect() functions take two
omap_dss_device pointers as parameters, which are always set to the same
value by all callers. Remove the duplicated pointer.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add a new omapdss_display_get() function to retrieve the omap_dss_device
for a given DSS output. This will be used when reversing the direction
of the DSS pipeline handling logic.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Similarly to for_each_dss_display(), the for_each_dss_output() macro
iterates over all the DSS connected outputs.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Look up the next dssdev at probe time based on device tree links for all
DSS outputs and encoders. This will be used to reverse the order of the
dssdev connect and disconnect call chains.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omapdss_of_find_source_for_first_ep() function locates the source
corresponding to the first endpoint of the first port of a device node.
We can easily extend it to locate sinks as well by passing the port
number as a parameter. This will be useful to find sinks in encoders
drivers.

Extend the function and rename it to omapdss_of_find_connected_device()
to reflect its new extended purpose.

Additionally, it is useful to differentiate between failures to return
the connected device because no link exists in the device tree for the
requested port, or because the connected device as described in the
device tree is invalid or not probed yet. Return NULL in the first case
and an error code in the second case, and update the callers
accordingly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omap_dss_device port_num field stores the DT port number associated
with the device. The field is used in different ways depending on the
device type:

- For DPI outputs, the port number is used as an identifier of the DPI
instance

- For sources, the port number is used to look up the omap_dss_device by
DT port node

As omap_dss_device instances are only looked up as sources by sinks,
setting the field to the number of the source port works for both use
cases.

However, to enable looking up sinks, we need to record all the ports
associated with an omap_dss_device. Do so by turning the port_num field
into an of_ports bitmask. For DPI outputs the port number is
additionally stored in the dpi_data structure as the output ID.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omapdss_find_output_from_display() function is only used to retrieve
the dispc channel corresponding to the display. Return the dispc channel
directly, and rename the function to omapdss_device_get_dispc_channel()
to match its new purpose.

The dssdev->id check is removed as the dssdev is guaranteed to be an
output and have a non-zero id, as proved by the lack of crash despite
the caller never checking the returned pointer before dereferencing it.

As the function is not specific to outputs anymore, move it from
output.c to base.c.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The DSS manager ops and private data pointer are specific to a DSS
instance. Store them in the dss_device structure instead of global
variable.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Storing the dss_device pointer in the omap_dss_device structure will
allow accessing the dss_device from the dss_mgr API functions.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The functions operate on any omap_dss_device, move them from display.c
to base.c. While at it rename them to match the naming of the other
functions operating on struct omap_dss_device.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The panel devices list isn't used anymore, all panel devices are
accessed through the global devices list. Remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Split the function into omapdss_display_init() to perform
display-specific initialization of the omap_dss_device, and
omapdss_register_display() to register the device. The latter will then
be replaced by more generic registration.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Despite its name, the omap_dss_get_next_device() function operates on
display devices only. Make it more generic by allowing operation on all
devices, with a parameter to specify the device type.

While at it rename the function to omapdss_device_get_next() to match
the naming of the other functions operating on struct omap_dss_device.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The macro iterates over displays only, rename it accordingly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The output devices list isn't used anymore, all output devices are
accessed through the global devices list. Remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The encoders duplicate the same omap_dss_device src and dst fields set
and checks in their connect and disconnect handlers. Move the code to
the connect and disconnect wrappers.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omap_dss_device objects model display components and are connected
at runtime to create display pipelines. The connect and disconnect
operations implemented by each component contain lots of duplicate code.
As a first step towards fixing this, create new functions to wrap the
direct calls to those operations and use them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The various types of omapdss_*_ops structures define multiple operations
that are not specific to a bus type. To simplify the code and remove
dependencies on specific bus types move those operations to a common
structure. Operations that are specific to a bus type are kept in the
specialized ops structures.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>