manual describes CONFIG_VEHICLE_POST_INIT behavior

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

manual describes CONFIG_VEHICLE_POST_INIT behavior

358 次查看
demingli
Contributor I

Software: Android Automotive 12.0.0_2.1.0 (Linux 5.15.32 BSP)​​

hardware: imx8qm-mek

There is a CONFIG_VEHICLE_POST_INIT macro defined in .config by default. And some components(LVDS2/DC1/etc) are posted to initialize until rootfs is mounted. And the description for this macro is:

393 config VEHICLE_POST_INIT
394 bool "Clock and PM domain driver for shared peripherals"
395 help
396 Shared peripherals are not accessible before other core release them
397 Initialize these peripheral clock and power after getting these resources.

And in the imx8qm-mek-car.dts shows this post init behavior is related to the

33 &vehicle_rpmsg_m4 {
34 #address-cells = <2>;
35 #size-cells = <2>;
36 status = "okay";
37 ranges;
38 fsl,resources = <&lvds2_subsys>,
39 <&dc1_subsys>,
40 <&img_subsys>;
41
42 pd_post: imx8qm-pd {
43 compatible = "fsl,imx8qm-scu-pd-post";
44 #power-domain-cells = <1>;
45 };
46
47 clk_post: clk1 {
48 compatible = "fsl,imx8qm-clk-post";
49 #clock-cells = <2>;
50 };
51 };

So my question is:

Is there any document describing this behavior? If yes, where? If no, why?

Is this behavior related to the U-Boot? I asked this because I think cortexM4 image exists in the U-Boot.

 

 

0 项奖励
回复
1 回复

333 次查看
Sanket_Parekh
NXP TechSupport
NXP TechSupport

Hello @demingli 

I hope you are doing well.

->The reason for this behavior is that some shared peripherals may not be accessible until other components release them, so U-Boot waits until it has access to these resources before initializing the clock and power management drivers for the shared peripherals.

->Yes, You are right this behavior is related to U-boot. It provides support for various hw peripherals & components.

->the macro "config_vehicle_post_init" is one of the many macros that are sued to build the U-boot it is a kind of build option.
->It will initialize certain components as mentioned in .config, clock, and power management drivers for shared peripherals after they become available.

->some shared peripherals can't be accessible until other components who are suing it release it. So, Basically, it is like shared resources are used by one at a point second has to wait until one frees it.

->There is no document describing this behavior but one can refer to U-boot peripheral initialization for more details.

Thanks & Regards.

Sanket Parekh

0 项奖励
回复