- 18 Mar, 2019 40 commits
-
-
Laurent Pinchart authored
Those components are supported by the drm_bridge infrastructure, remove the omapdrm-specific driver. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
The omapdss driver patches DT at runtime to prepend an "omapdss," prefix to the compatible string of all encoders, panels and connectors. This mechanism ensures they get bound to the omapdss-specific drivers instead of generic drivers. Now that we have drm_bridge support in omapdrm, we need to selectively disable this mechanism. Add a whitelist of compatible strings to patch, and fill it with all the devices we support. They will be removed one by one once corresponding drm_bridge drivers become available and get successfully tested with omapdrm. The omapdss components load check code is updated accordingly to ignore devices managed by external bridge drivers. Signed-off-by:
-
Laurent Pinchart authored
Hook up drm_panel support in the omapdrm driver. The change is relatively simply as the way has been paved by drm_bridge support already. In addition to looking up, attaching to and detaching from the panel, we only need to add panel support in the connector .get_modes() handler, take connector bus flags (set by the panel) into account, and enable/disable the panel in the encoder enable/disable operations handlers. Signed-off-by:
-
Laurent Pinchart authored
Hook up drm_bridge support in the omapdrm driver. Despite the recent extensive preparation work, this is a rather intrusive change, as the management of outputs needs to be adapted through the driver to handle both omap_dss_device and drm_bridge. Connector creation is skipped when using a drm_bridge, as the bridge creates the connector internally. This creates issues with systems that split connector operations (such as modes retrieval and hot-plug detection) across different bridges. These systems can't be supported using drm_bridge for now (their support through the omap_dss_device infrastructure is not affected), this will be fixed in subsequent changes. Signed-off-by:
-
Laurent Pinchart authored
Add support for the OSD070T1718-19TS 7" 800x480 panel from One Stop Displays to the panel-simple driver. Signed-off-by:
-
Laurent Pinchart authored
The OSD Displays OSD070T1718-19TS is a 7" WVGA (800x480) 24bit RGB panel and is compatible with the simple-panel bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Laurent Pinchart authored
OSD Displays is a panel manufacturer. It has been acquired by New Vision Displays in 2015 but continues to operate under its own brand name. Signed-off-by:
-
Laurent Pinchart authored
The TFP410 supports configurable pixel clock sampling edge and data de-skew adjustments. The configuration can be set through I2C or dedicated chip pins. Report the configuration through the drm_bridge timings. As the ti-tftp410 driver doesn't support configuring the chip through I2C, we simply use the default configuration in that case. When the chip is configured through dedicated pins, we parse the configuration from DT. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Tested-by:
-
Laurent Pinchart authored
The TFP410 has a powerdown pin that can be connected to a GPIO to control power saving. The DT bindings define a corresponding property, but the driver doesn't implement support for it. Fix that. Signed-off-by:
-
Laurent Pinchart authored
The TI TFP410 is a DVI encoder, not a full HDMI encoder. Its output can be routed to a DVI-D connector, even if in many cases embedded systems will use an HDMI connector to carry the DVI signals. Instead of hardcoding the connector type to HDMI, retrieve the connector type from its DT node. Signed-off-by:
-
Laurent Pinchart authored
The TFP410 supports configuration of several input bus parameters through either the I2C port or chip pins. In the latter case, we need to specify those parameters in DT. Two new properties are added, ti,deskew to specify the data de-skew configuration (as set through the DK[3:1] pins), and pclk-sample to specify the pixel clock sampling edge (as set through the EDGE pin). Signed-off-by:
-
Stefan Agner authored
The DRM bus flags convey additional information on pixel data on the bus. All current available bus flags might be of interest for a bridge. Remove the sampling_edge field and use bus_flags. In the case at hand a dumb VGA bridge needs a specific data enable polarity (DRM_BUS_FLAG_DE_LOW). Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Laurent Pinchart authored
The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them through the code. This effectively changes the value of the .sampling_edge bridge timings field in the dumb-vga-dac driver. This is safe to do as no driver consumes these values yet. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Laurent Pinchart authored
The DRM_BUS_FLAG_PIXDATA_POSEDGE and DRM_BUS_FLAG_PIXDATA_NEGEDGE macros and their DRM_BUS_FLAG_SYNC_* counterparts define on which pixel clock edge data and sync signals are driven. They are however used in some drivers to define on which pixel clock edge data and sync signals are sampled, which should usually (but not always) be the opposite edge of the driving edge. This creates confusion. Create four new macros for both PIXDATA and SYNC that explicitly state the driving and sampling edge in their name to remove the confusion. The driving macros are defined as the opposite of the sampling macros to made code simpler based on the assumption that the driving and sampling edges are opposite. Signed-off-by:
-
Laurent Pinchart authored
The omap_dss_device type and output_type fields differ mostly for historical reasons. The output_type field is required for all devices but the display at the end of the pipeline, and must be set to OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for all devices but the internal encoder, for which it is ignored. The only reason why the output_type field must be set to OMAP_DISPLAY_TYPE_NONE for the display at the end of the pipeline is to identify omap_dss_device instances corresponding to displays. This is not documented and confusing. Clean the code by adding a new display field to the omap_dss_device structure to identify displays, and merge the type and output_type fields. Signed-off-by:
-
Laurent Pinchart authored
The omapdrm driver initialization procedure starts by connecting all available pipelines, gathering related information (such as output and display DSS devices, and DT aliases), sorting them by alias, and finally creates all the DRM/KMS objects. When using DRM bridges instead of DSS devices, we will need to attach to the bridges before getting the aliases. As attaching to bridges requires an encoder object, we have to reorganize the initialization sequence to create encoders before getting aliases and sorting the pipelines. Signed-off-by:
-
Laurent Pinchart authored
Now that the direction of OF graph walk has been reversed, there's no need to lookup devices by port as we have no sink device connected through multiple sink ports. Simplify OF lookup of the DSS devices to look them up by node only. Signed-off-by:
-
Laurent Pinchart authored
The DPI and SDI encoders store the full videomode upon mode set, to only use the value of the pixel clock when enabling the encoder. This wastes memory. Store the pixel clock value only. Signed-off-by:
-
Laurent Pinchart authored
Replace internal usage of struct videomode with struct drm_display_mode in order to avoid converting needlessly between the data structures. Signed-off-by:
-
Laurent Pinchart authored
The omap_dss_device .check_timings() and .set_timings() operations operate on struct videomode, while the DRM API operates on struct drm_display_mode. This forces conversion from to videomode in the callers. While that's not a problem per se, it creates a difference with the drm_bridge API. Replace the videomode parameter to the .check_timings() and .set_timings() operations with a drm_display_mode. This pushed the conversion to videomode down to the DSS devices in some cases. If needed they will be converted to operate on drm_display_mode natively. Signed-off-by:
-
Laurent Pinchart authored
The encoder .atomic_check() and connector .mode_valid() operations both walk through the dss devices in the pipeline to validate the mode. Factor out the common code in a new omap_drm_connector_mode_fixup() function. Signed-off-by:
-
Laurent Pinchart authored
The mode setting handler of the VENC stores the video mode internally, to then convert it to a configuration when programming the hardware. The stored mode is otherwise unused. Cache the configuration directly instead. Signed-off-by:
-
Laurent Pinchart authored
The DISPC timings checks relate to the CRTC, but they're performed in the encoder and connector .atomic_check() and .mode_valid() operations. Move them to the CRTC .mode_valid() operation. Signed-off-by:
-
Laurent Pinchart authored
The field is only used to check whether the device is connected, and we can do so by checking the dss field instead. Remove the src field. Signed-off-by:
-
Laurent Pinchart authored
For HDMI pipelines, when the output gets disconnected the device handling CEC needs to be notified. Instead of guessing which device that would be (and sometimes getting it wrong), notify all devices in the pipeline. Signed-off-by:
-
Laurent Pinchart authored
The source pointer will be removed to the omap_dss_device structure. Store it internally in the DSI panel driver data. Signed-off-by:
-
Laurent Pinchart authored
Display pipelines based on drm_bridge are handled from the bridge closest to the CRTC. To move to that model we thus need to transition away from walking pipelines in the other direction, and from accessing the device at the end of the pipeline when possible. Remove most accesses to the display device from the omap_connector implementation, and don't store it in the omap_connector structure. - For debug messages we can simply use the connector name instead. - For type checks we can use the drm_connector type. - For operation lookup we can start at the other end of the pipeline and locate the last matching device. The display device is still passed to the connector init function in order to find its type, which requires access to the end of the pipeline. Signed-off-by:
-
Laurent Pinchart authored
The DT bindings for the OMAP DSS allow assigning numerical IDs to display outputs through display entries in the alias node. The driver uses this information to sort pipelines according to the order specified in DT, making it possible for a system to give a priority order to outputs. Retrieval of the alias ID is done when initializing display dss devices. That code will be removed when moving to drm_bridge and drm_panel. Move retrieval of the alias ID to display pipeline connection time and store it in the pipeline structure instead to keep the feature. Signed-off-by:
-
Laurent Pinchart authored
The display isn't used by the encoder implementation, don't pass it to the initialization function and store it internally needlessly. Signed-off-by:
-
Laurent Pinchart authored
The TV encoder supports both PAL and NTSC modes, but when queried for the list of modes it supports, only the currently selected mode is reported. Fix it and report the two modes unconditionally. Signed-off-by:
-
Laurent Pinchart authored
Instead of manually iterating over the dss devices in the pipeline to find the first one that implements the .get_modes() operation, add a new operation flag for .get_modes() and use the omap_connector_find_device() helper function to locate the right dss device. Signed-off-by:
-
Laurent Pinchart authored
Now that the .get_modes() operations takes a drm_connector and fills it with modes, it becomes easy to fill display information in the same operation without requiring a separate .get_size() opearation. Signed-off-by:
-
Laurent Pinchart authored
omap_dss_device operations expose fixed video timings through a .get_timings() operation that return a single timing for the device. To prepare for the move to drm_bridge, modify the API to instead add DRM modes directly to the connector. As this puts more burden on display devices, we also create a helper function for panels to add a single DRM mode from the panel video timings. Signed-off-by:
-
Laurent Pinchart authored
All the internal encoders share common init and cleanup code. Factor it out to separate functions. Signed-off-by:
-
Laurent Pinchart authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
