The omap_dss_device type and output_type fields differ mostly for
historical reasons. The output_type field is required for all devices
but the display at the end of the pipeline, and must be set to
OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for
all devices but the internal encoder, for which it is ignored.

The only reason why the output_type field must be set to
OMAP_DISPLAY_TYPE_NONE for the display at the end of the pipeline is to
identify omap_dss_device instances corresponding to displays. This is
not documented and confusing.

Clean the code by adding a new display field to the omap_dss_device
structure to identify displays, and merge the type and output_type
fields.
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 omap_dss_device .check_timings() and .set_timings() operations
operate on struct videomode, while the DRM API operates on struct
drm_display_mode. This forces conversion from to videomode in the
callers. While that's not a problem per se, it creates a difference with
the drm_bridge API.

Replace the videomode parameter to the .check_timings() and
.set_timings() operations with a drm_display_mode. This pushed the
conversion to videomode down to the DSS devices in some cases. If needed
they will be converted to operate on drm_display_mode natively.
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 encoder .atomic_check() and connector .mode_valid() operations both
walk through the dss devices in the pipeline to validate the mode.
Factor out the common code in a new omap_drm_connector_mode_fixup()
function.
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 DISPC timings checks relate to the CRTC, but they're performed in
the encoder and connector .atomic_check() and .mode_valid() operations.
Move them to the CRTC .mode_valid() operation.
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 display isn't used by the encoder implementation, don't pass it to
the initialization function and store it internally needlessly.
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 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) bail out from their
.enable() and .disable() handlers if the dss device is already enabled
or disabled. Those safety checks are not needed when the functions are
called through the omapdss_device_ops, as the .enable() and .disable()
handlers are called from the DRM atomic helpers that already guarantee
that no double enabling or disabling can occur.

However, the handlers are also called directly from the .remove()
handler. While this shouldn't be needed either as the modules can't be
removed as long as the device is in use, it's still a good practice to
disable the device explicitly. There is currently a safety check in
.remove() in some drivers but not all of them.

Remove the safety checks from the .enable() and .disable() handlers, and
add missing ones in the .remove() handler.
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>

All .enable() and .disable() handlers for panels and connectors share
common code that validates and updates the device's state. Move it to
common locations in the omap_encoder_enable() and omap_encoder_disable()
handlers.

The enabled check in the .disable() handler is left untouched, it will
be addressed separately.
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>

Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.

To make sure I actually achieved the goal here I went through all
drivers. And indeed, all atomic drivers are now free of
drm_crtc_helper.h includes.

v2: Make it compile. There was so much compile fail on arm drivers
that I figured I'll better not include any of the acks on v1.

v3: Massive rebase because i915 has lost a lot of drmP.h includes, but
not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h
there was still one, which this patch largely removes. Which means
rolling out lots more includes all over.

This will also conflict with ongoing drmP.h cleanup by others I
expect.

v3: Rebase on top of atomic bochs.

v4: Review from Laurent for bridge/rcar/omap/shmob/core bits:
- (re)move some of the added includes, use the better include files in
  other places (all suggested from Laurent adopted unchanged).
- sort alphabetically

v5: Actually try to sort them, and while at it, sort all the ones I
touch.

v6: Rebase onto i915 changes.

v7: Rebase once more.
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: NCK Hu <ck.hu@mediatek.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: virtualization@lists.linux-foundation.org
Cc: etnaviv@lists.freedesktop.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: spice-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-tegra@vger.kernel.org
Cc: xen-devel@lists.xen.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch

Make life easier for drivers by simply passing the connector
to drm_hdmi_avi_infoframe_from_display_mode() and
drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
need to worry about is_hdmi2_sink mess.

v2: Make is_hdmi2_sink() return true for sil-sii8620
    Adapt to omap/vc4 changes

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-1-ville.syrjala@linux.intel.com

The DSI encoder sets dssdev->ops->dsi.set_config, which is stored at the
same offset as dssdev->ops->hdmi.set_hdmi_mode. The code in omap_encoder
only checks if dssdev->ops->hdmi.set_hdmi_mode is NULL. Due to the way
union works, it won't be NULL if dsi.set_config is set. This means
dsi_set_config will be called with config=hdmi_mode=false=NULL parameter
resulting in a NULL dereference. Also the dereference happens while
console is locked, so kernel hangs without any debug output without
"fb.lockless_register_fb=1" parameter.

This restructures the code, so that the HDMI mode is only configured
for HDMI output types.

Fixes: 83910ad3 ("drm/omap: Move most omap_dss_driver operations to omap_dss_device_ops")
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: NTony Lindgren <tony@atomide.com>
[tomi.valkeinen@ti.com: dropped the safeguard]
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121160916.22017-5-sebastian.reichel@collabora.com

Instead of calling the .set_timings() operation recursively from the
display device backwards, iterate over the devices manually in the DRM
encoder code. This moves the complexity to a single central location and
simplifies the logic in 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>

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>

The encoder enable operation currently performs mode fixup and mode
setting for all omap_dss_device instances in the display pipeline. There
are dedicated encoder operations for those operations (respectively
.atomic_check() and .mode_set()), but they are not used for this
purpose.

Move the mode fixup code to .atomic_check() and the mode set code
.mode_set() to better fit the KMS model. The bus flags fixup has to
happen at .mode_set() time as there is no place to store the bus flags
in the atomic state structures. This could be solved by extending one of
the state structures, but as the goal is to replace the fixup by direct
usage of bus flags through the driver, that would be pointless.
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 bus flags stored in omap_dss_device instances are used to fixup the
video mode before setting it, to honour constraints that can't be
expressed through drm_display_mode. The fixup occurs in the CRTC mode
set operation and the resulting video mode is stored internally in the
CRTC. It is then used next by omap_encoder_enable() to apply mode fixups
for the omap_dss_device instances in omap_encoder_update().

Move the hack to the omap_encoder_update() function right before
applying the omap_dss_device fixups, in order to group all fixups
together.
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 .check_timings() operation is called recursively from the display
device back to the output device. Most components just forward the
operation to the previous component in the chain, resulting in lots of
duplicated pass-through functions. To avoid that, iterate over the
components manually.
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 .check_timings() operation is present in all panels and connectors.
The fallback that uses .get_timings() in the absence of .check_timings()
is thus unneeded.

While it could be argued that the fallback implements a useful check
that should be extended to cover all fixed-resolution panels, the code
is currently unused and gets in the way of the ongoing refactoring.
Remove it, a similar feature can always be added later.
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 HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe())
operations are called recursively from the display device back to the
HDMI encoder. This isn't required, as all components other than the HDMI
encoder just forward the operation to the previous component in the
chain. Call the operations directly on the HDMI encoder.
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 drm_encoder implementation requires access to the omap_dss_device
corresponding to the display, which is passed to its initialization
function and stored internally. Clean up of the HDMI mode and infoframe
handling will require access to the output omap_dss_device. To prepare
for that, pass it to the encoder initialization function and store it
internally as well.
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 mode set implementation needs to access the omap_dss_device for
the pipeline display. To do so, it iterates over all pipelines to find
the one that contains an encoder corresponding to the CRTC, and request
the display device from the encoder. That's a very complicated dance
when the CRTC has a direct pipeline pointer already, and the pipeline
contains a pointer to the display device.

Replace the convoluted code with direct access.
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>

The structure contains function pointers that don't need to be modified.
Make all its instances const to improve security.
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>

Having the filename in the header serves little purpose and is
often wrong after renames as it is here in several places, just
drop it from all omapdrm files.

While we are here unify the copyright tags to the TI recommended style.
Signed-off-by: NAndrew F. Davis <afd@ti.com>

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
	- VIC for 4K modes for HDMI 1.4 sinks
	- S3D information for S3D modes
  As CEA-861-F has already defined VICs for 4K videomodes, this
  patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
  until the mode is 3D.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
	- Do not send VICs in both AVI-IF and HDMI-IF
	  send only one of it.
V4: Rebase
V5: Added r-b from Neil.
    Addressed review comments from Ville
    - Do not block HDMI vendor IF, instead check for VIC while
      handling AVI infoframes
V6: Rebase
V7: Rebase
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

By linking the sizeof to a variable type the code will be less prone to
bugs due to future type changes of variables.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or
something else.

The code will be easier to follow if we use consistent names.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_video_timings can be replaced with the generic videomode in omapdrm
and the omap_video_timings can be removed.

This patch will replace the omap_video_timings with videomode.
With the change we no longer need the functions to convert to/from
videomode and drm_display_mode to omap_video_timings, these can be removed
as well.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

If the panel's enable fails, omap_encoder silently ignores the failure.
omapdrm should really handle the failure, but unfortunately the whole
encoder enable codepath is expected to always succeed.

So for now, catch the enable failure and print an error.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

omap_encoder_update() assigns an overlay manager to
dssdev->src->manager. This assignment is not needed, as the connections
in the display chain have already been made at connect step.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.

@@
identifier dev, encoder, funcs;
@@
 int drm_encoder_init(struct drm_device *dev,
                      struct drm_encoder *encoder,
                      const struct drm_encoder_funcs *funcs,
                      int encoder_type
+                     ,const char *name, int DOTDOTDOT
                      )
{ ... }

@@
identifier dev, encoder, funcs;
@@
 int drm_encoder_init(struct drm_device *dev,
                      struct drm_encoder *encoder,
                      const struct drm_encoder_funcs *funcs,
                      int encoder_type
+                     ,const char *name, int DOTDOTDOT
                      );

@@
expression E1, E2, E3, E4;
@@
 drm_encoder_init(E1, E2, E3, E4
+                 ,NULL
                  )

v2: Add ', or NULL...' to @name kernel doc (Jani)
    Annotate the function with __printf() attribute (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670818-2966-1-git-send-email-ville.syrjala@linux.intel.com

Now that the driver is fully converted to atomic operations, and that
the atomic helpers call the operations in the right order, we can move
encoder setup to where it belongs, in the encoder operations.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The encoder .mode_fixup() operation is legacy, atomic updates uses the
new .atomic_check() operation. Convert the encoder driver.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The atomic connector DPMS helper implements the connector DPMS operation
using atomic commit, removing the need for DPMS helper operations on
CRTCs and encoders.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This removes the legacy mode config code. The CRTC and encoder prepare
and commit operations are not used anymore, remove them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The operations are required by the atomic helpers, implement them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use the <...> include style instead of "..." for DRM headers and sort
the headers alphabetically to ease detection of duplicates.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Make the omapdrm driver use the new HDMI ops when possible.

omapdrm will call set_hdmi_mode (when available) to tell the encoder
driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI
monitor, omapdrm will call set_hdmi_infoframe to to set the AVI
infoframe.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Rob Clark <robdclark@gmail.com>

Currently, an encoder is disabled only when an apply work is queued for the
corresponding crtc. This works fine for the paths where userspace explicitly
disables crtc, this results in disabling the omapdss device in the crtc's
pre_apply function.

However, when the omapdrm module is removed, there is no work queued to ensure
that the encoder is disabled. This can result in an enabled omapdss device when
removing omapdrm. omapdss is left in an inconsistent state, and that prevents us
from using that omapdss device being used again.

Disable enabled encoders in omap_encoder_destroy, we could consider a better
place for doing this later.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In the old panel device model we had "outputs", which were the encoders
inside OMAP DSS block, and panel devices (omap_dss_device). The panel
devices had a reference to the source of the video data, i.e. reference
to an "output", in a field named "output".

That was somewhat confusing even in the old panel device model, but even
more so with the panel device model where we can have longer chains of
display entities.

This patch renames the "output" field to "src", which much better tells
what the field points to.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>