- 15 Dec, 2020 40 commits
-
-
Sebastian Reichel authored
Move dsi_ops into the main structure, since all other ops are gone. Instead of checking the device type we can simply check if dsi_ops are set. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-48-tomi.valkeinen@ti.com
-
Sebastian Reichel authored
All displays are now using a drm_panel or a drm_bridge that models the connector instead of dssdev, so this field is always 0 and can be dropped. Signed-off-by:
-
Sebastian Reichel authored
The omapdss device's ops_flags field is no longer used and can be dropped. Signed-off-by:
-
Sebastian Reichel authored
Since all encoders and panels are using the bridge API now, we next pointer is no longer useful and can be dropped. Signed-off-by:
-
Sebastian Reichel authored
We no longer need to check for the DSS API, since all encoders, panels and connectors have been converted to the bridge API. Signed-off-by:
-
Sebastian Reichel authored
Remove unused code. Connectors are now created via drm_bridge_connector_init() and no longer OMAP specific. Signed-off-by:
-
Sebastian Reichel authored
All DSS devices have been converted to bridge API, so the device operations are always NULL. This removes the device ops function pointers and all code using it. Signed-off-by:
-
Sebastian Reichel authored
In order to integrate with a chain of drm_bridge, the internal DSI output has to expose its operations through the drm_bridge API. Register a bridge at initialisation time to do so and remove the omap_dss_device operations that are now unused. Signed-off-by:
-
Sebastian Reichel authored
The panel driver is no longer using any OMAP specific APIs, so let's move it into the generic panel directory. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Sebastian Reichel authored
We can simply provide the device to the omapdrm driver via pdata. omapdss_is_initialized() is no longer required (even before this patch), since omapdrm device is only registered after the pointer is initialized. Signed-off-by:
-
Sebastian Reichel authored
Do not try to reset the panel after DSI has been detached, since the DSI clocks may have been disabled at this point. The panel will be disabled and unprepared before being removed and a reset will be done when being probed again. Signed-off-by:
-
Sebastian Reichel authored
Now, that the driver implements the common DRM panel API the unbind no longer needs to be suppressed. Signed-off-by:
-
Sebastian Reichel authored
Use DEVICE_ATTR_RO helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
-
Sebastian Reichel authored
Implement check timings, which will check if it's possible to configure the clocks for the provided mode using the same code as the set_config() hook. Signed-off-by:
-
Sebastian Reichel authored
The table of compatible values needed to be prefixed with "omapdss," is empty, so all of this code is doing nothing now. Let's drop it. Signed-off-by:
-
Sebastian Reichel authored
This converts the DSI module to expect common drm_panel display drivers instead of dssdev based ones. Signed-off-by:
-
Sebastian Reichel authored
Due to previous changes the DSI encoder gets the capabilities via DSI client's mode_flags and no longer needs the omapdss specific caps. The core code now checks if the DSI encoder is actually configured into command mode instead of just checking the panel capabilities. Signed-off-by:
-
Sebastian Reichel authored
Complete the direction reversal of the DSS device enable/disable operations started by commit 19b4200d ("drm/omap: Reverse direction of the DSS device enable/disable operations"). This effectively drops the requirement of calling DSS specific code from the DSI panel driver moving it a bit further to a standard drm_panel driver. Signed-off-by:
-
Sebastian Reichel authored
This moves the panel refresh/update function from the panel driver into the DSI host driver to prepare for common drm_panel support. Signed-off-by:
-
Sebastian Reichel authored
Move ULPS handling into the DSI host controller, so that we no longer need a custom API for the DSI client. Note that for now ULPS is always disabled. Signed-off-by:
-
Sebastian Reichel authored
Create a custom function pointer for ULPS and use it instead of reusing disable/enable functions for ULPS mode switch. This allows us to use the common disable/enable functions pointers for DSI. Signed-off-by:
-
Sebastian Reichel authored
This moves the bus locking into the host driver and unexports the custom API in preparation for drm_panel support. Signed-off-by:
-
Sebastian Reichel authored
Instead of using the custom enable_te() API, this automatically enables/disables TE core support when a matching packet is sent to the panel. Signed-off-by:
-
Sebastian Reichel authored
In preparation for removing custom DSS calls from the DSI panel driver, this moves support for external tearing event GPIOs into the DSI host driver. This way tearing events are always handled in the core resulting in simplification of the panel drivers. The TE GPIO acquisition follows works in the same way as the exynos DSI implementation. Signed-off-by:
-
Sebastian Reichel authored
Integrate low-power / high-speed bus switching into transfer function and drop the omapdrm specific enable_hs() callback. Signed-off-by:
-
Sebastian Reichel authored
Use bulk regulator API to simplify the code. This also switches from _optional variant to normal variant, which will provide a dummy regulator (i.e. if some always-enabled regulator is not described in DT). Signed-off-by:
-
Sebastian Reichel authored
In order to reduce the amount of custom functionality, this moves handling of pixel format and DSI mode from set_config() to dsi attach. Signed-off-by:
-
Sebastian Reichel authored
The DSI sync() function only locks the bus and then releases it again. Currently the only invocation is directly before update(), which locks the bus anyways. Signed-off-by:
-
Sebastian Reichel authored
enable_te() is not used, so the custom API can be dropped. Signed-off-by:
-
Sebastian Reichel authored
The get_te() callback is not used, so we can drop the custom API. Signed-off-by:
-
Sebastian Reichel authored
memory_read is not used, so we can drop the code. Signed-off-by:
-
Sebastian Reichel authored
Drop local definition of common MIPI DCS 1.3 defines. Signed-off-by:
-
Sebastian Reichel authored
Use dsi->channel everywhere, which originates from DT. Signed-off-by:
-
Sebastian Reichel authored
Drop custom request_vc/release_vc callbacks by using the generic mipi_dsi_attach/mipi_dsi_detach functions. To use mipi_dsi_attach() we need to fill in the mipi_dsi_device fields, and some of these fields overlap with the fields in omap_dss_dsi_config. In later patches the latter will get dropped. Signed-off-by:
-
Sebastian Reichel authored
After converting the driver to mipi_dsi_device we can use the generic message helpers to simplify the driver a lot. Signed-off-by:
-
Sebastian Reichel authored
This moves from custom platform driver infrastructure to mipi_dsi_host and mipi_dsi_device. Note, that this is a graduate step and the driver only uses the devices types and transfer function, but not yet the new device binding style or drm_panel. Signed-off-by:
-
Sebastian Reichel authored
Simplify the DSI encoder by using mipi_dsi_msg for dsi_vc_send_long and dsi_vc_send_short. Further improvements require cleaning up the channel allocation code first. Signed-off-by:
-
Sebastian Reichel authored
Simplify the read related message handling by using the functionality provided by CONFIG_DRM_MIPI_DSI. Signed-off-by:
-
Sebastian Reichel authored
Simplify the write related messages handling by using the functionality provided by CONFIG_DRM_MIPI_DSI. Signed-off-by:
-
Sebastian Reichel authored
This drops the virtual channel logic. Afterwards DSI clients request their channel number and get the virtual channel with the same number or -EBUSY if already in use. The change here is not strictly speaking correct, as it combines the VC (DSI's "configuration block") and virtual channel ID (the ID sent in the DSI packets). But as we currently only support a single DSI command mode panel, this works fine: we always use VC0, and VC ID 0. This needs more work to support video mode panels, but that can be done after moving to DRM bridge and panel model, after which we can do that work with the proper APIs. Signed-off-by:
-
