We're missing a call to of_platform_depopulate() on errors for dsi.
Looks like dss is already doing this.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106152802.38599-1-tony@atomide.com

The internal encoders (DSI, HDMI4, HDMI5 and VENC) runtime PM handlers
attempt to manage the runtime PM state of the connected DISPC, based on
the rationale that the DISPC providing data to the encoders requires
ensuring that the display is active whenever the encoders are active.

While the DISPC provides data to the encoders, it doesn't as such
constitute a resource that encoders require in order to be taken out
of suspend, contrary to for instance a functional clock or a power
supply. Encoders registers can be accessed without the DISPC being
active, and while the encoders will not output any video stream without
being fed by the DISPC, the DISPC PM state doesn't influence the
encoders PM state.

For this reason the DISPC PM state is better managed from the omapdrm
driver, in the CRTC enable and disable operations. This allows the
encoders PM state to be handled separately from the DISPC, and in
particular at times when the DISPC may not be available (for instance at
probe due to the DSS probe being deferred, or at remove time du to the
DISPC being already removed).

Fixes: edb715df ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-5-laurent.pinchart@ideasonboard.com

The probe function performs hardware access to read the number of
supported data lanes from a configuration register and thus requires the
device to be active. Ensure this by surrounding the access with
dsi_runtime_get() and dsi_runtime_put() calls.

Fixes: edb715df ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-4-laurent.pinchart@ideasonboard.com

The bind function performs hardware access (in hdmi4_cec_init()) and
thus requires the device to be active. Ensure this by surrounding the
bind function by hdmi_runtime_get() and hdmi_runtime_put() calls.

Fixes: 27d62452 ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-3-laurent.pinchart@ideasonboard.com

The DSS DT node contains children that describe the DSS components
(DISPC and internal encoders). Each of those components is handled by a
platform driver, and thus needs to be backed by a platform device.

The corresponding platform devices are created in mach-omap2 code by a
call to of_platform_populate(). While this approach has worked so far,
it doesn't model the hardware architecture very well, as it creates
child devices before the parent is ready to handle them. This would be
akin to creating I2C slaves before the I2C master is available.

The task can be easily performed in the omapdss driver code instead,
simplifying mach-omap2 code. We however can't remove the mach-omap2 code
completely as the omap2fb driver still depends on it, but we can move it
to the omap2fb-specific section, where it can stay until the omap2fb
driver gets removed.

This has the added benefit of not allowing DSS components to probe
before the DSS itself, which led to runtime PM issues when the DSS probe
is deferred.

Fixes: 27d62452 ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-2-laurent.pinchart@ideasonboard.com

omap_connector_destroy() does:

kfree(omap_connector);
omapdss_device_put(omap_connector->output);
omapdss_device_put(omap_connector->display);

Fix this by moving the kfree after the omapdss_device_puts.

This bug was introduced in 949ea2efSigned-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: NThomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.
Signed-off-by: NThomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.
Signed-off-by: NThomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

drm_format_info table has a field 'is_yuv' to denote if the format
is yuv or not. The driver is expected to use this instead of
having a function for the same purpose.
Signed-off-by: NAyan Kumar halder <ayan.halder@arm.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.

This patch changes DMM driver to access DMM registers via sDMA. Instead
of doing a normal readl/writel call to read/write a register, we use
sDMA to copy 4 bytes from/to the DMM registers.

This patch provides only a partial workaround for i878, as not only DMM
register reads/writes are affected, but also accesses to the DMM mapped
buffers (framebuffers, usually).
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

The interrupts should be enabled after the driver initialization to avoid
early interrupts while the driver is not yet ready to handle them.

On removal the interrupts must be disabled before other resources are
released, freed up.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The driver probe would fail if the irq is not available.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

A DMM timeout "timed out waiting for done" has been observed on DRA7
devices. The timeout happens rarely, and only when the system is under
heavy load.

Debugging showed that the timeout can be made to happen much more
frequently by optimizing the DMM driver, so that there's almost no code
between writing the last DMM descriptors to RAM, and writing to DMM
register which starts the DMM transaction.

The current theory is that a wmb() does not properly ensure that the
data written to RAM is observable by all the components in the system.

This DMM timeout has caused interesting (and rare) bugs as the error
handling was not functioning properly (the error handling has been fixed
in previous commits):

 * If a DMM timeout happened when a GEM buffer was being pinned for
   display on the screen, a timeout error would be shown, but the driver
   would continue programming DSS HW with broken buffer, leading to
   SYNCLOST floods and possible crashes.

 * If a DMM timeout happened when other user (say, video decoder) was
   pinning a GEM buffer, a timeout would be shown but if the user
   handled the error properly, no other issues followed.

 * If a DMM timeout happened when a GEM buffer was being released, the
   driver does not even notice the error, leading to crashes or hang
   later.

This patch adds wmb() and readl() calls after the last bit is written to
RAM, which should ensure that the execution proceeds only after the data
is actually in RAM, and thus observable by DMM.

The read-back should not be needed. Further study is required to understand
if DMM is somehow special case and read-back is ok, or if DRA7's memory
barriers do not work correctly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/omapdrm/dss/dispc.c: In function 'dispc_ovl_setup_common':
drivers/gpu/drm/omapdrm/dss/dispc.c:2627:19: warning:
 variable 'frame_height' set but not used [-Wunused-but-set-variable]
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We prefer to use ERR_CAST to do so.
The issue is detected with the help of Coccinelle.
Signed-off-by: Nzhong jiang <zhongjiang@huawei.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

tcm-sita.h is unused since commit 0d6fa53f ("drm/omap: Use bitmaps for TILER placement")
Let's remove it.
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.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>

The video timings are stored in the CRTC structure by the
omap_crtc_dss_set_timings() function, called by dss_mgr_set_timings()
from the .enable() operation of the internal encoders. This instead
belongs to the .set_timings() code paths. Move the
omap_crtc_dss_set_timings() calls 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 VENC encoder modifies the requested video mode to match the NTSC or
PAL timings (or reject the video mode completely) in the .set_timings()
operation. This should be performed in the .check_timings() operation
instead. Move the fixup.
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 SDI encoder modifies the pixel clock of the requested video mode to
take the limitations of the PLL into account in the .enable() operation.
This should be performed in the .check_timings() operation instead. Move
the fixup.
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>

Constify many pointers to struct videomode, as well as pointers to
container structures, to ensure the video mode isn't modified after
the .check_timings() 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>

The DSI encoder modifies the passed videomode to take the requirements
of the internal DISPC-DSI bus into account in the .enable_video_output()
operation. This should be performed in the .check_timings() operation
instead. There is however no .check_timings() operation as the DSI
encoder uses a custom API, so move it to the closest match which is the
.set_config() 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>

The video mode is aleady fixed up by the .check_timings() operation,
there's no need to repeat that when enabling the DPI output.
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>

Panels drivers store their timings in a device data structure field that
is initialized at probe time, either from hardcoded values or from
firmware-supplied values. Those timings are then reported through the
.get_timings() operation to construct the panel display mode.

The panel timings are further modified by the .set_timings() operation,
which is called with the timings retrieved by .get_timings(), and
mangled by .check_timings(). The latter potentially adjusts the pixel
clock only.

Conceptually, modifying the panel timings is wrong, as the timings are
an intrinsic property of the panel and should thus be fixed.
Furthermore, modifying them this way at runtime can result in display
modes reported to userspace varying between calls, which is also wrong.

There's no actual need to store the mangled pixel clock value in the
timings. Don't modify the panel timings in the .set_timings() operation,
just forward it to the previous device in the display pipeline.
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 analog TV, DVI and HDMI connectors all report timing information
through the .get_timings() information.

For analog TV outputs the information is queried from the encoder, so
the operation is unused. Remove it.

For HDMI outputs the display pipeline provides EDID capability, so the
operation is unused as well. Remove it.

For DVI outputs the operation is also unused if the pipeline provides
EDID capability. Otherwise (when the DDC bus is not connected) we
shouldn't hardcode a single mode, but instead report no mode and let the
KMS core add default modes. This is achieved by removing the 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>

Timings for the TV output are currently reported by the analog TV
connector. This has the disadvantage of having to handle timing-related
operations in a connector omap_dss_device that has, at the hardware
level, no knowledge of any timing information.

Implement the .get_timings() operation in the venc driver, and get
timings from the first component in the pipeline that implements the
operatation. This switches the duty of reporting analog TV timings from
the connector to the 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 .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>

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 omap_dss_device .set_timings() operation for external encoders
stores the video mode in the device data structure. That mode is then
never used again. Drop 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 .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 omap_dss_device .set_timings() operations are called directly from
omap_encoder_update(), and indirectly from the omap_dss_device .enable()
operation. The latter is called from omap_encoder_enable(), right after
calling omap_encoder_update(). The .set_timings() operation it thus
called twice in a row. Fix it by removing the indirect call.
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>

Both the .check_timings() and .set_timings() handlers call
tfp410_fix_timings() to fix the timing's flags. As .check_timings() is
always called before .set_timings(), there's no need to fix the flags
twice. Remove the tfp410_fix_timings() call from .set_timings().
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The two functions implement the .set_timings() and .check_timings()
operations. Rename them to hdmi_disply_set_timings() and
hdmi_display_check_timings() respectively to match the operations names
and make searching the source code easier.
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 determining the connector type from the type of the display's
omap_dss_device and passing it to the omap_connector_init() function,
move the type determination code to omap_connector.c and remove the type
argument to the connector init function. This moves code to a more
natural location, making the driver easier to read.
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_connector implementation requires access to the omap_dss_device
corresponding to the display, which is passed to its initialization
function and stored internally. Refactoring of the timings operations
will require access to the output omap_dss_device. To prepare for that,
pass it to the connector 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>