The field is only used in a safety check during device
connection/disconnection, where the src field can be easily used
instead. Remove it and use src.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The venc_device structure wss_data field is set to 0 and never otherwise
modified, remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The kobj field from struct omap_dss_device is not used. Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The omap_connector_attached_encoder() doesn't exist anymore, remove its
declaration from omap_connector.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAlxqHJYeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGWl8H/jPI4EipzD2GbnjZ
GaFpMBBjcXBaVmoA+Y69so+7BHx1Ql+5GQtqbK0RHJRb9qEPLw3FBhHNjM/N8Sgf
nSrK+GnBZp9s+k/NR/Yf2RacUR3jhz+Q9JEoQd3u9bFUeQyvE8Rf3vgtoBBwFOfz
+t7N1memYVF3asLGWB4e4sP1YVMGfseTQpSPojvM30YWM86Bv+QtSx1AGgHczQIM
kMKealR8ZPelN6JAXgLhQ5opDojBrE4YKB98pwsMDI6abz0Tz2JLFEUTTxsv5XNN
o/Iz+XDoylskEyxN2unNWfHx7Swkvoklog8J/hDg5XlTvipL/WkT66PHBgcGMNvj
BW9GgU8=
=ZizU
-----END PGP SIGNATURE-----
Merge v5.0-rc7 into drm-next
Backmerging for nouveau and imx that needed some fixes for next pulls.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since commit b4935e3a3c ("drm/omap: Store bus flags in the
omap_dss_device structure") video mode flags are managed by the omapdss
(and later omapdrm) core based on bus flags stored in omap_dss_device.
This works fine for all devices whose video modes are set by the omapdss
and omapdrm core, but breaks DSI operation as the DSI still uses legacy
code paths and sets the DISPC timings manually.
To fix the problem properly we should move the DSI encoder to the new
encoder model. This will however require a considerable amount of work.
Restore DSI operation by adding back video mode flags handling in the
DSI encoder driver as a hack in the meantime.
Fixes: b4935e3a3c ("drm/omap: Store bus flags in the omap_dss_device structure")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-5-laurent.pinchart@ideasonboard.com
Commit edb715dffd ("drm/omap: dss: dsi: Move initialization code from
bind to probe") moved the of_platform_populate() call from dsi_bind() to
dsi_probe(), but failed to move the corresponding
of_platform_depopulate() from dsi_unbind() to dsi_remove(). This results
in OF child devices being potentially removed multiple times. Fix it by
placing the of_platform_depopulate() call where it belongs.
Fixes: edb715dffd ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-4-laurent.pinchart@ideasonboard.com
Reading any of the DSI debugfs files results in a crash, as wrong
pointer is passed to the dump functions, and the dump functions use a
wrong pointer. This patch fixes DSI debug dumps.
Fixes: f3ed97f9ae ("drm/omap: dsi: Simplify debugfs implementation")
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-3-laurent.pinchart@ideasonboard.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: Harry Wentland <harry.wentland@amd.com>
Acked-by: Sam 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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Daniel 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
Move drm_can_sleep() out of drmP.h to allow users
to get rid of the drmP.h include.
There was no header file that was a good match for this helper function.
So add this to drm_util with the relevant includes.
Add include of drm_util.h to all users.
v2:
- Update comments to use kernel-doc style (Daniel)
- Add FIXME to drm_can_sleep and add note that this
function should not be used in new code (Daniel)
v3:
- Fix kernel-doc syntax (Daniel)
- Plug drm_util.h into drm-internels.rst (Daniel)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190112193251.20450-2-sam@ravnborg.org
drm-next has been forwarded to 5.0-rc1, and we need it to apply the damage
helper for dirtyfb series from Noralf Trønnes.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jani 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: 83910ad3f5 ("drm/omap: Move most omap_dss_driver operations to omap_dss_device_ops")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Tony Lindgren <tony@atomide.com>
[tomi.valkeinen@ti.com: dropped the safeguard]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121160916.22017-5-sebastian.reichel@collabora.com
After the changes from 4.20 the DSI encoder tries to find the
attached panel before populating the DSI bus. If the panel is
not found -EPROBE_DEFER is returned, so the DSI bus is never
populated and the panel never added.
Fix this by populating the DSI bus before searching for the
video sink in dsi_init_output().
Fixes: 27d624527d ("drm/omap: dss: Acquire next dssdev at probe time")
Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121160916.22017-3-sebastian.reichel@collabora.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: 3fbda31e81 ("drm/omap: Split mode fixup and mode set from encoder enable")
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181126092447.11864-1-tomi.valkeinen@ti.com
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
We're missing a call to of_platform_depopulate() on errors for dsi.
Looks like dss is already doing this.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: edb715dffd ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: edb715dffd ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: 27d624527d ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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: 27d624527d ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi 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 949ea2ef3f
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent 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: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Tomi 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: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Tomi 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: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Tomi 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: Ayan Kumar halder <ayan.halder@arm.com>
Signed-off-by: Tomi 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: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Peter 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: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The driver probe would fail if the irq is not available.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi 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: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Peter 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: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi 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: zhong jiang <zhongjiang@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
tcm-sita.h is unused since commit 0d6fa53fd8 ("drm/omap: Use bitmaps for TILER placement")
Let's remove it.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of calling the EDID read operation (.read_edid()) recursively
from the display device back to the first device that provides EDID read
support, iterate over the devices manually in the DRM connector code.
This moves the complexity to a single central location and simplifies
the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
On HDMI outputs, CEC support requires notification of HPD signal
deassertion. The HPD signal can be handled by various omap_dss_device
instances in the pipeline, and all of them forward HPD events to the
OMAP4 internal HDMI encoder.
Knowledge of the DSS internals need to be removed from the
omap_dss_device instances in order to migrate to drm_bridge. To do so,
move HPD handling for CEC to the omap_connector.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of calling the hot-plug detection callback registration
operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively
from the display device back to the first device that provides hot plug
detection support, iterate over the devices manually in the DRM
connector code. This moves the complexity to a single central location
and simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Instead of calling the .detect() operation recursively from the display
device back to the first device that provides hot plug detection
support, iterate over the devices manually in the DRM connector
.detect() implementation. This moves the complexity to a single central
location and simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
As the descriptor API handles the active-low flag internally we need to
invert the polarity of all GPIO operations in the driver. Rename the
nreset_gpio field to reset_gpio to reflect that.
The reset GPIO is mandatory, so drop conditional tests through the
driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The driver doesn't use GPIOs and thus doesn't need to include the
linux/gpio.h header.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
The reset GPIO is mandatory, so drop conditional tests through the
driver. The qvga GPIO is unused, so drop it completely.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
As the descriptor API handles the active-low flag internally we need to
invert the polarity of all GPIO operations in the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The omapdrm driver checks at suspend and resume time whether the
displays it operates on have their driver operations set. This check is
unneeded, as all display drivers set the driver operations field at
probe time and never touch it afterwards. This is furthermore proven by
the dereferencing of the driver field without checking it first in
several locations.
The omapdss driver performs a similar check at shutdown time. This is
unneeded as well, as the for_each_dss_display() macro it uses to iterate
over displays locates the displays by checking the driver field
internally.
As those checks are unnecessary, remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The omap_dss_device.dispc_channel_connect field is used by DSS outputs
to fail the .enable() operation if they're not connected. Set the field
directly from the (dis)connect handlers of the DSS outputs instead of
going through the CRTC dss_mgr operations.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The omap_crtc_output global array is used to look up the DSS output
device by channel. We can replace that by accessing the output device
from the pipeline if we store the pipeline pointer in the omap_crtc
structure.
The global array is also used to protect against double connection of an
output. This can't happen with the connection handling mechanism going
from DSS outputs to displays. We can thus drop that check, allowing
removal of the global array.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The omap_crtcs global array is used to store pointers to omap_crtc
indexed by DISPC channel number, in order to look them up in the dss_mgr
operations. Store the information in the omap_drm_private structure in
the form of an array of omap_drm_pipeline pointers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
When a DSS output is (dis)connected the omapdss_output_(un)set_device()
function performs a sanity check to ensure that the output isn't already
(dis)connected. The check is unnecessary as those situations should
never happen, but can nonetheless be useful to catch driver bugs. To
prepare for removal of the omapdss_output_(un)set_device() functions
move the connection check to the omapdss_device_connect() function. The
omapdss_device_disconnect() already contains a corresponding check.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Create an omap_drm_pipeline structure to model display pipelines, made
of a CRTC, an encoder, a connector and a DSS display device. This allows
grouping related parameters together instead of storing them in
independent arrays and thus improves code readability.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Creating all the planes in a single location instead of creating them
per-CRTC with remaining planes then created in a second step simplifies
the logic.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The crtc_idx and plane_idw variables in the main loop are always equal
to the loop counter i, use it instead. Don't unnecessarily initialize
dssdev to NULL.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Regulators for the DPI, DSI, HDMI, SDI and VENC outputs are all looked
up when connecting the output omap_dss_device. There's no need to delay
regulator handling to that time, get the regulators at probe time.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Laurent Pinchart