| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
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: 27d624527d99 ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We prefer to use ERR_CAST to do so.
The issue is detected with the help of Coccinelle.
Signed-off-by: zhong jiang <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The macro iterates over displays only, rename it accordingly.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The DSI clocks are dumped in the DSS-level debugfs clocks file. This
complicates the implementation as the DSI private data has to be looked
up through the outputs list. Simplify it by creating two debugfs files,
dsi1_clks and dsi2_clks, to dump the DSI clocks.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The dpi_init_port() and sdi_init_port() functions can return errors but
their return value is ignored. This prevents both probe failures and
probe deferral from working correctly. Propagate the errors up the call
stack.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Register the omapdrm device when we know that dss device probe going
to succeed. This avoids DSS6 and DSS2 omapdrm device registration from
colliding with each other.
Signed-off-by: Jyri Sarha <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omapdss_gather_components() function walks the OF graph to create a
list of all components part of the display device. There's no need to
delay this operation until DSS bind time as we have all the information
we need at probe time.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Change [email protected] to [email protected].
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
When compiling with CONFIG_OMAP2_DSS_DEBUGFS disabled, build fails due
to:
drivers/gpu/drm/omapdrm/dss/dss.c:1474:10: error: ‘dss_debug_dump_clocks’ undeclared (first use in this function); did you mean ‘dispc_dump_clocks’?
dss_debug_dump_clocks, dss);
^~~~~~~~~~~~~~~~~~~~~
dispc_dump_clocks
Fix this by moving the required functions outside #if
defined(CONFIG_OMAP2_DSS_DEBUGFS).
In the long term, we perhaps want to try to get all the debugfs support
left out if debugfs is not enabled.
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
This removes the need to access the global DISPC private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DISPC private data dynamically).
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
The dss_device is the top-level component in the omapdss driver. Give
the omapdrm driver access to the dss_device pointer in order to obtain
pointers to all other components from it. This requires a new global
variable in the omapdss driver that will be removed when merging the
omapdrm and omapdss drivers, but will already allow removal of several
other global variables.
As this partly duplicates the omapdss_is_initialized() API, reimplement
it as an inline function wrapping omapdss_get_dss().
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
The dss_unbind() function casts the struct device pointer to a struct
platform_device, only to later use the struct device pointer from
platform_device. Don't cast at all.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
As part of an effort to remove the usage of global variables in the
driver, store the debugfs root directory in the dss_device structure
instead of a global variable.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
To simplify implementation of debugfs seq_file show handlers, the driver
passes the pointer to the show function through the debugfs_create_file
data pointer. This prevents using the pointer to pass driver private
data to the show handler, and requires all handlers to use global
variables to access private data.
To prepare for the removal of global private data in the driver, rework
the debugfs infrastructure to allow passing a private data pointer to
show handlers.
The price to pay is explicit removal of debugfs files to free the
internally allocated memory. This is desirable anyway as debugfs entries
should be removed when a component driver is unbound, otherwise crashes
will occur due to access to freed memory when the components will be
dynamically allocated instead of stored in global variables.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
The DSS private data structure is currently stored as a global variable.
While no platform with multiple DSS devices currently exists nor is
planned, this doesn't comply with the kernel device model and should
thus be fixed.
Allocate the DSS private data structure dynamically for each DSS
instance and remove the global variable. All code that need access to
the structure now retrieves it dynamically so we can remove the global
variable.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
This removes the need to access the global DSS private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DSS device dynamically).
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
This removes the need to access the global DSS private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DSS device dynamically).
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
This removes the need to access the global DSS private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DSS device dynamically).
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
This removes the need to access the global DSS private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DSS device dynamically).
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
This removes the need to access the global DSS private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DSS device dynamically).
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
This will allow accessing the PLL data to get the DSS device pointer,
removing the need to access the global DSS private data.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
To prepare for the removal of the global variable storing DSS private
data, pass its pointer to the dss_runtime_{get,put}() functions.
As this requires getting hold of the dss_device structure in the
callers, we add a new dss_get_device() function to retrieve it. The
function currently returns a pointer to the global data structure, and
will later be updated to get the pointer from device driver data when
the DSS private structure will be allocated dynamically.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
The anoonymous dss structure in dss.c is the top-level component in the
omapdss driver. As such it should store all internal instance-specific
data that is currently stored in global variables. This however requires
both naming the structure to pass it around functions, and accessing it
from various locations in the omapdss driver. While we could implement
get and set functions for every field that needs to be accessed outside
of dss.c, that would introduce overhead and complexity that we could
avoid by exposing the structure to internal components of the omapdss
driver. Do so to prepare for removal of global variables.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
|
|
The function is unused, remove it.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
There's no reason to delay initialization of most of the driver (such as
mapping memory I/O, getting clocks or enabling runtime PM) to the
component master bind handler.
This additionally fixes a real PM issue caused enabling runtime PM in
the bind handler.
The bind handler performs the following sequence of PM operations:
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
... (access the hardware to read the device revision) ...
pm_runtime_put_sync(dev);
If a failure occurs at this point, the error path calls
pm_runtime_disable() to balance the pm_runtime_enable() call.
To understand the problem, it should be noted that the bind handler is
called when one of the component registers itself, which happens in the
component's probe handler. Furthermore, as the components are children
of the DSS, the device core calls pm_runtime_get_sync() on the DSS
platform device before calling the component's probe handler. This
increases the DSS power usage count but doesn't runtime resume the
device, as runtime PM is disabled at that point.
The bind handler is thus called with runtime PM disabled, with the
device runtime suspended, but with the power usage count larger than 0.
The pm_runtime_get_sync() call will thus further increase the power
usage count and runtime resume the device. The pm_runtime_put_sync()
handler will decrease the power usage count to a non-zero value and will
thus not suspend the device. Finally, the pm_runtime_disable() call will
disable runtime PM, preventing the pm_runtime_put() call in the device
core from runtime suspending the device. The DSS device is thus left
powered on.
To fix this, move the initialization code from the bind handler to the
probe handler.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The kernel favours 'unsigned int' over plain 'unsigned'. Replace all
occurences of the latter by the former. This avoid lots of checkpatch
complaints in patches that touch lines where a plain 'unsigned' is used.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Currently, calls into each file are used to register the various
platform drivers. Change this to a table of pointers to platform_driver
structs to allow using platform_register_drivers.
Signed-off-by: Andrew F. Davis <[email protected]>
|
|
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: Andrew F. Davis <[email protected]>
|
|
The function isn't used outside of its compilation unit, make it static.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
When merging the omapdrm and omapdss drivers the omapdrm virtual
platform device will disappear, and the omapdss platform device will be
used for DMA memory allocation. To prepare for that, set the DMA
coherent mask for the device.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The header file only contains four macros, two of which are never used.
Move the other two to dss.h and remove dss_features.h.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The supported outputs feature is specific to the DSS, move it from the
omap_dss_features structure to the dss driver.
The omap_dss_features structure is now empty and can be removed.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The FEAT_PARAM_DSS_FCK feature is specific to the DSS, move it from the
omap_dss_features structure to the dss driver.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The FEAT_LCD_CLK_SRC feature is specific to the DSS, move it from the
omap_dss_features structure to the dss_features structure.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The register belongs to the DSS, move the feature to the dss_features
structure.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
In preparation for removal of the core module, move the shutdown()
handler from core to dss.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
debugfs code is spread between the core and dss drivers. In preparation
for removal of the core driver, move it all to the dss driver.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The DSS internal features are derived from the platform device
compatible string which is available at probe time. Don't delay
initialization until bind time. This prepares for the merge of the two
DSS features structures that will be needed before the DSS is bound.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The dss driver uses the supported display types to check whether the DSS
has SDI, VENC or HDMI outputs. We can instead use the supported outputs
the provide the same information. This removes the last use of the
supported display types, that we can then remove as well.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Use the compatible string instead of the OMAP SoC revision to determine
device features. The various OMAP3-based SoCs can't be told apart using
the compatible string, use soc_device_match() to tell them apart.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The DPI code only needs to differentiate between major OMAP revisions,
which can be obtained from the DSS compatible string. Replace the OMAP
SoC model checks to prepare for removal of the OMAP SoC version platform
data.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Move the two function pointers to a new dss_ops structure. This will
allow merging the dss_features and omap_dss_features structures without
having to expose the DPI source selection and LCD clock muxing functions
in header files.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The devm_ioremap_resource() call can handle being given a NULL resource,
and prints an error message when mapping fails. Switch the remaining
devm_ioremap() calls to devm_ioremap_resource() and remove all
extraneous resource NULL checks and error messages printed manually by
the driver.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The OMAP driver has its own OF graph helpers that are similar to the
common helpers. This commit replaces most of the calls with the common
helpers. There's still a couple of custom helpers left, but the driver
needs more extensive changes to get rid of them.
In dss_init_ports, we invert the loop, looping through the known ports
and matching them to DT nodes rather than looping thru DT nodes and
matching them to the ports.
Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
|
|
When omapdss is loaded (all core components are in place) create a list of
devices used in the display graph. This list later can be used by omapdrm
via the omapdss_stack_is_ready() function to check that these components
are loaded. Based on this information, omapdrm can defer probe in case when
the omapdss stack is not ready yet.
Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omapdss_is_initialized() is used to find out if omapdss has been probed
successfully. This patch moves the related code to the common
omapdss-base module, so that the same support will be there for both
omapdss and omapdss6.
Signed-off-by: Tomi Valkeinen <[email protected]>
|