How to adjust the DSI clock rates in the 5.4.24 kernel?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to adjust the DSI clock rates in the 5.4.24 kernel?

2,292 Views
dennis3
Contributor V

Previously in 10_1.0.0, w/ the 4.x kernel, we were able to adjust clock rates to get our display to work.

With the 5.x kernel, things have changed.  Our panel driver is still calling init and running the enable code, but the display is not coming on.  I believe it's due to the same clocking issues.  I noticed the clocks don't seem to be changing based on DTS file changes.

**** original working clock tree ****
 

osc_27m                              1        1        0    27000000          0     0  50000
    video2_pll1_ref_sel               0        0        0    27000000          0     0  50000
       video2_pll_out                 0        0        0    27000000          0     0  50000
    video_pll1_ref_sel                1        1        0    27000000          0     0  50000
       video_pll1_ref_div             1        1        0     5400000          0     0  50000
          video_pll1                  1        1        0   593999997          0     0  50000
             video_pll1_bypass        1        1        0   593999997          0     0  50000
                video_pll1_out        2        2        0   593999997          0     0  50000
                   lcdif_pixel        1        1        0    74250000          0     0  50000
                   dsi_phy_ref        2        2        0    23760000          0     0  50000
                   dc_pixel           0        0        0   593999997          0     0  50000



**** new clock tree ****
(I modified this based on the imx8mq-evk-lcdif-rm67191.dts which is the panel driver our driver is based off of that works.)

&lcdif {
    status = "okay";
    max-memory-bandwidth = <221184000>; /* 720x1280-32@60.02 */

    assigned-clocks = <&clk IMX8MQ_CLK_LCDIF_PIXEL>,
              <&clk IMX8MQ_VIDEO_PLL1_BYPASS>,
              <&clk IMX8MQ_VIDEO_PLL1_REF_SEL>,
              <&clk IMX8MQ_VIDEO_PLL1>;
    assigned-clock-parents = <&clk IMX8MQ_VIDEO_PLL1_OUT>,
                 <&clk IMX8MQ_VIDEO_PLL1>,
                 <&clk IMX8MQ_CLK_27M>;
    assigned-clock-rate = <74250000>, <0>, <0>, <594000000>;

    port@0 {
        lcdif_mipi_dsi: endpoint {
            remote-endpoint = <&mipi_dsi_in>;
        };
    };
};


osc_27m                              2        2        0    27000000          0     0  50000
    video2_pll1_ref_sel               2        2        0    27000000          0     0  50000
       video2_pll_out                 1        1        0    27000000          0     0  50000
    video_pll1_ref_sel                1        1        0    27000000          0     0  50000
       video_pll1_ref_div             1        1        0     5400000          0     0  50000
          video_pll1                  1        1        0   864000000          0     0  50000
             video_pll1_bypass        1        1        0   864000000          0     0  50000
                video_pll1_out        2        2        0   864000000          0     0  50000
                   lcdif_pixel        2        2        0    72000000          0     0  50000
                   dsi_phy_ref        1        1        0    24000000          0     0  50000
                   dc_pixel           0        0        0   172800000          0     0  50000



***

Apparently, I'm not changing the right thing.  Do you have any insight into where I should make modifications to get the right clock rates for our display?

Labels (1)
0 Kudos
Reply
8 Replies

2,271 Views
joanxie
NXP TechSupport
NXP TechSupport

original working clock tree is based on 4.14.98? could you give me the dts file your original working clock tree based on? so you want to get pixel clock 74.25M for your panel, right? if yes, try to set

assigned-clock-rate = <74250000>, <0>, <0>, <297000000>; and tell me what result you get

 

0 Kudos
Reply

2,264 Views
dennis3
Contributor V

Thank you for the response.  I've made the adjusted change but it doesn't change configured clock rates. I'm not entirely sure it's the cause of the problem though.  Our old DTS file in Android 10_1.0.0 we didn't actually have to change the clock rate in the DTS file.  The clock settings picked up the requirement for our panel from the panel mode settings.  I had actually specified 76mhz but it worked fine w/ 74.25.  

Android 10_1.0.0 dts file for our panel:

&mipi_dsi_bridge {
	status = "okay";
    no_clk_reset;
    legacy-pll-config;

	panel@0 {
        	compatible = "brooksee,kd050";
		reg = <0>;
        pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_mipi_dsi_en>;
		reset-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
		dsi-lanes = <4>;
		panel-width-mm = <62>;
		panel-height-mm = <110>;

		display-timings {
		 	timing {
				clock-frequency = <76000000>;
				hactive = <720>;
				vactive = <1280>;
				hfront-porch = <100>;
				hsync-len = <33>;
				hback-porch = <100>;
				vfront-porch = <20>;
				vsync-len = <2>;
				vback-porch = <30>;
				hsync-active = <0>;
				vsync-active = <0>;
				de-active = <0>;
				pixelclk-active = <0>;
			};
		};

However, I should add, there was a commit I had to revert that broke our old build.  Commit: 01d0508d3b2deb956c05130d6ac88298d21fec12 moved mipi resets and removed the no_clk_reset attribute which caused our panel not to work correctly.  I believe the 5.4 kernel using the new modified behavior and I haven't figured out the correct way to configure for our panel.

Before I can solve either the clock or reset problem though, I'm not entirely sure Android is even trying to use our panel as configured.  Is the correct boot parameter for lcdif androidboot.primary_display=imx-drm still?  if I use dumpsys display with the panel configured for lcdif, I see the 720x1280 panel but the system says it's 1920x1080.  If I instead configure the panel on the dcss block, dumpsys then reports the display us 720x1280.  It seems there is some configuration changes that have also changed between versions but I wasn't able to find any documentation about it other than a short paragraph saying support was provided through the DTS files.

 

0 Kudos
Reply

2,252 Views
dennis3
Contributor V

I dug into the previous commit in the 4.x kernel that broke our display (01d0508d3b...).  Turns out, it didn't have anything to do with the clock or reset adjustments.  Instead, it looks like there was a configuration option removed in that commit.

-    if (dsi_device->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
- 		nwl_dsi_write(dsi, CFG_NONCONTINUOUS_CLK, 0x00);

 So even though the commit talks about moving the resets etc, the actual change affecting us was with this removed clock option.  Our panel had the MIPI_DSI_CLOCK_NON_CONTINUOUS mode flag set.  I'm not sure if the mode flag was set incorrectly to get it to work with the previous version or if the removed config option was a bug and the mode flag is wrong. 

In the 5.4 kernel, the new nwl bridge code handles the mode flag differently:

        if (dsi->dsi_mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {        
		nwl_dsi_write(dsi, NWL_DSI_CFG_NONCONTINUOUS_CLK, 0x01);
		nwl_dsi_write(dsi, NWL_DSI_CFG_AUTOINSERT_EOTP, 0x01);
	} else {
		nwl_dsi_write(dsi, NWL_DSI_CFG_NONCONTINUOUS_CLK, 0x00);
		nwl_dsi_write(dsi, NWL_DSI_CFG_AUTOINSERT_EOTP, 0x00);
	}

You can see that the register is set opposite from the old way.  It appears to me this is the correct behavior.  For our panel, I simple needed to remove the MIPI_DSI_CLOCK_NON_CONTINUOUS from the mode flags and the panel started working correctly with the new kernel.

So in summary, the clocks still don't configure like they used to, however, that is not the reason the panel wasn't working.  I suppose at this point it's optional to get the clocks to configure as the panel is requesting.

0 Kudos
Reply

2,263 Views
dennis3
Contributor V

FYI for kicks I took out the no_clk_reset and legacy-pll-config attributes from our original DTS file.  Our panel still configures and works properly.  without the legacy-pll-config, the clocks are configured as follows:

       video_pll1                  1        1        0   911999998          0     0  50000
             video_pll1_bypass        1        1        0   911999998          0     0  50000
                video_pll1_out        2        2        0   911999998          0     0  50000
                   lcdif_pixel        1        1        0    76000000          0     0  50000
                   dsi_phy_ref        2        2        0    24000000          0     0  50000
                   dc_pixel           0        0        0   911999998          0     0  50000

In this case, the clock was configured for 76mhz as requested.  

So there is something else in that commit I reverted that causes the panel to not configure but I haven't tracked it down.  Still unknown how to correctly configure in the 5.4 kernel. 

0 Kudos
Reply

2,231 Views
joanxie
NXP TechSupport
NXP TechSupport

"moved mipi resets and removed the no_clk_reset attribute which caused our panel not to work correctly. "

"I took out the no_clk_reset and legacy-pll-config attributes from our original DTS file. Our panel still configures and works properly."

what do they mean? these two attributes are useful or not, I checked the new 5.4 kernel, doesn't use mipi_dsi_bridge and remove the no_clk_reset, could you tell me what detailed panel you use?

0 Kudos
Reply

2,228 Views
dennis3
Contributor V

"moved mipi resets and removed the no_clk_reset attribute which caused our panel not to work correctly. "

"I took out the no_clk_reset and legacy-pll-config attributes from our original DTS file. Our panel still configures and works properly."

what do they mean? these two attributes are useful or not, I checked the new 5.4 kernel, doesn't use mipi_dsi_bridge and remove the no_clk_reset, could you tell me what detailed panel you use?

Yes sorry for the confusion.  This was a reference to the old code before commit 01d0508d3b..  in the 4.9.x kernel.  In that kernel version before that commit, those attributes were used in the DTS file to change behavior of the driver.  At that time (before the commit, our panel worked).  

Then that commit broke our panel.  Since the bulk of the change in that commit had to do with the resets and clocks, I figured that this was the reason our panel broke.  I simply reverted the commit and we continued to use our panel until present day when we are trying to port to the 5.4 kernel.

So now, in the 5.4 kernel, since the mipi bridge is all rewritten, I was going back to that previous commit to try to find out why it really broke, in order to find clues as to why it didn't work in the new kernel.  The result was what I described earlier.  Broken panel was not due to clock rate changes but due to changed behavior of the MIPI_DSI_CLOCK_NON_CONTINUOUS flag.

0 Kudos
Reply

2,233 Views
joanxie
NXP TechSupport
NXP TechSupport

I was totally confused with your questions, in the old kernel(4.9.x), could you set the display correct or not? in the first post, it seems that you can set up the panel correct, but now you said it was broken? and the reason is that the mwl settings cases the old kernel failed? I checked the nwl file, 4.9.88 and 5.4.70 both have the function like:

if (dsi->dsi_mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)

{ nwl_dsi_write(dsi, CFG_NONCONTINUOUS_CLK, 0x01); nwl_dsi_write(dsi, CFG_AUTOINSERT_EOTP, 0x01); } else { nwl_dsi_write(dsi, CFG_NONCONTINUOUS_CLK, 0x00); nwl_dsi_write(dsi, CFG_AUTOINSERT_EOTP, 0x00); }

in the "nwl_dsi_config_host" of nwl-dsi.c, 5.4 is different from 4.9.88, for 4.9.88 the clock is limited to the 

static int valid_clocks[] = {
162000,
148500,
135000,
132000,
108000,
74250,
49500,
31500,
};

for 5.4, should support more clock frequecny , I don't think customer needs to change mwl file, should  change the dts file to set the correct pll and pixel clock, refer to my first post, did you try the setting in 5.4 kernel as I posted? any different?

 

 

0 Kudos
Reply

2,227 Views
dennis3
Contributor V

Yes I mentioned earlier I did try the PLL change you suggested but I still got the same clock rate as before.  But also that changing the clock rate turned out not to be required to get the panel to work.

You had asked about our panel.  It's simply a mipi dsi panel that is very similar to the radium rm67191.  I simply had to create our own driver based on that and change the mipi init according to our vendor instruction and then modify DTS accordingly for proper panel size and timings.

0 Kudos
Reply