Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what is the role of Linux DRM's component framework". In daily operation, I believe many people have doubts about the role of Linux DRM's component framework. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the questions of "what is the role of Linux DRM's component framework?" Next, please follow the editor to study!

1. Introduction of component

Linux kernel component code implementation file: drivers/base/component.c.

Using the git log-p component.c command, you can view the record of the first submission of the file.

Commit 2a41e6070dd7ef539d0f3b1652b4839d04378e11Author: Russell King Date: Fri Jan 10 23:23:37 2014 + 0000 drivers/base: provide an infrastructure for componentised subsystems Subsystems such as ALSA, DRM and others require a single card-level device structure to represent a subsystem. However, firmware tends to describe the individual devices and the connections between them. Therefore, we need a way to gather up the individual component devices together, and indicate when we have all the component devices. We do this in DT by providing a "superdevice" node which specifies the components, eg: imx-drm {compatible = "fsl,drm"; crtcs =; connectors =;}; The superdevice is declared into the component support, along with the subcomponents. The superdevice receives callbacks to locate the subcomponents, and identify when all components are present. At this point, we bind the superdevice, which causes the appropriate subsystem to be initialised in the conventional way. When any of the components or superdevice are removed from the system, we unbind the superdevice, thereby taking the subsystem down.

The purpose of introducing the component framework into the Linux kernel is:

In DRM, ALSA and other subsystems, the loading sequence of multiple components (component) is managed by super device (superdevice) to ensure that all components can be used normally.

Second, super equipment

1. Super device definition

Super devices can also be called master, which generally refers to a subsystem (such as display-subsystem). Definition file: rk3399.dtsi, the content is as follows:

Display_subsystem: display-subsystem {compatible = "rockchip,display-subsystem"; ports =,; clocks =,; clock-names = "hdmi-tmds-pll", "default-vop-pll"; devfreq =; status = "disabled";}

two。 Super device loading

The super device registers the match through the component_master_add_with_match () function. The implementation file: rockchip_drm_drv.c, the content is as follows:

Static int rockchip_drm_platform_probe (struct platform_device * pdev) {... / * * Bind the crtc ports first, so that * drm_of_find_possible_crtcs called from encoder .bind callbacks * works as expected. * / for (I = 0 * *; I = 0 * * +) {. Port = of_parse_phandle (np, "ports", I);... Component_match_add (dev, & match, compare_of, port- > parent); # # 1. Bind CRTC of_node_put (port);}. / * * For each bound crtc, bind the encoders attached to its * remote endpoint. * / for (I = 0; ports +) {port = of_parse_phandle (np, "ports", I); Rockchip_add_endpoints (dev, & match, port); # # 2. Add endpoints for each port of_node_put (port);}. Return component_master_add_with_match (dev, & rockchip_drm_ops, match);} III. Component equipment

1.component device definition

Component device is used to represent vop and each display interface (such as HDMI, MIPI, etc.). The definition file: rk3399.dtsi, the content is as follows:

Vopl_out: port {# address-cells =; # size-cells =; vopl_out_dsi: endpoint@0 {reg =; remote-endpoint =;};. Vopl_out_hdmi: endpoint@2 {reg =; remote-endpoint =;};...}; vopb_out: port {# address-cells =; # size-cells =;... Vopb_out_dsi: endpoint@1 {reg =; remote-endpoint =;}; vopb_out_hdmi: endpoint@2 {reg =; remote-endpoint =;};...}

2.component device load

The component device is loaded through the component_add () function.

The vop implementation file rockchip_vop_reg.c is as follows:

Static int vop_probe (struct platform_device * pdev) {... Return component_add (dev, & vop_component_ops);}

API HDMI implements the file dw_hdmi-rockchip.c. The code is as follows:

Static int dw_hdmi_rockchip_probe (struct platform_device * pdev) {... Return component_add (& pdev- > dev, & dw_hdmi_rockchip_ops);}

Other interfaces are not introduced for the time being.

PS:

VOP (Video Output Processor) is the display controller of Rockchip series SoC. The RK3399 display features are as follows:

1. Dual VOP: one supports 4096x2160 with AFBC supported;The other supports 2560x16002, Dual channel MIPI-DSI (4 lanes per channel) 3, eDP 1.3 (4 lanes with 10.8Gbps) to support display, with PSR4, HDMI 2.0 for 4K 60Hz with HDCP 1.4 DisplayPort 2.25, DisplayPort 1.2 (4 lanes, up to 4K 60Hz) 6, Supports Rec.2020 and conversion to Rec.709

Note: this code is based on the Linux 4.4 kernel of the RockPI 4A Debian system.

At this point, the study on "what is the role of Linux DRM's component framework" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.