msm8916-mainline / linux

Linux mainline kernel fork for various Qualcomm MSM8909/MSM8916/MSM8939 devices
https://wiki.postmarketos.org/wiki/MSM8916_Mainlining
Other
159 stars 124 forks source link

Huawei panel does not work #383

Open hicode002 opened 4 days ago

hicode002 commented 4 days ago

Hello, I have a Huawei T1-A21W tablet (msm8916) and I am currently trying to port the display, but have encountered some issues. The display screen of this tablet is boe_nt51017_10_800p_video From the downstream kernel source code, it can be seen that the display of this tablet has been processed in a very special way. There is code for "Huawei, xxx" in the device tree, and Huawei has made additional processing on its own. This is the device tree link of the downstream kernel。https://github.com/hicode002/android_kernel_huawei_hwt1a21w/blob/main/arch/arm64/boot/dts/qcom/huawei_msm8916_t110_p0_a21w/huawei_t110_p0_a21w.dts

However, it should be noted that the device tree extracted from the device does not actually include the following four lines。

qcom,platform-enable-gpio-vsp = <&msm_gpio 97 0>;
        qcom,platform-enable-gpio-vsn = <&msm_gpio 32 0>; 
        huawei,platform-tp-vcc-ctrl-by-lcd = <1>;
        huawei,platform-tp-en-vcc = <&msm_gpio 3 0>;        

But it was replaced with

huawei,platform-lcd-vcc-gpio = <0x4a 0x20 0x0>;
qcom,platform-vled-en-gpio = <0x4a 0x61 0x0>;

Then I found the code for Huawei to parse this device tree,。

https://github.com/hicode002/android_kernel_huawei_hwt1a21w/blob/7e3920f2be47387511bb4afdd5681b5895cdae42/drivers/video/msm/mdss/mdss_dsi.c

Then I discovered some interesting issues, such as Huawei using L15 to power the VDDIO of MDSS-DSI, and in fact, they use this function every time the screen is turned on。

static void hw_panel_power_en(struct mdss_panel_data* pdata, int enable)
{

    struct mdss_dsi_ctrl_pdata* ctrl_pdata = NULL;
    ctrl_pdata = container_of(pdata, struct mdss_dsi_ctrl_pdata, panel_data);

    if (gpio_is_valid(ctrl_pdata->lcd_vcc_gpio)){
        gpio_set_value((ctrl_pdata->lcd_vcc_gpio), enable);
        pr_info("%s,%d set en lcd_vcc_gpio = %d \n", __func__, __LINE__, enable);
    }
    mdelay(2);
}

it is used to open gpio 32 and 97 before opening the regulator, but they are called vreg, I'm not quite sure。

for (i = 0; i < DSI_MAX_PM; i++) {
            /*
             * Core power module will be enabled when the
             * clocks are enabled
             */
            if (DSI_CORE_PM == i)
                continue;
            ret = msm_dss_enable_vreg(
                ctrl_pdata->power_data[i].vreg_config,
                ctrl_pdata->power_data[i].num_vreg, 1);
            if (ret) {
                pr_err("%s: failed to enable vregs for %s\n",
                    __func__, __mdss_dsi_pm_name(i));
                goto error_enable;
            }
        }

So based on the information above, I believe that numbers 32 and 97 are just gpio and only need to be opened when powered on. Therefore, I used Linux mdss dsi panel driver generator to generate the panel file and made some modifications (adding gpio, vdd, and vddio)。 Here is the code I have modified https://pastebin.com/KWJ9eTFd Below is the dtsi of the downstream kernel BOE panel。 https://github.com/hicode002/android_kernel_huawei_hwt1a21w/blob/main/arch/arm64/boot/dts/qcom/huawei_msm8916_t110_p0_a21w/hw-panel-boe-nt51017-10-800p-video.dtsi But there is a problem that the dtsi of the downstream kernel is different from the BOE panel code I obtained by decompiling the original device tree in the device!! Here is the code extracted from my device。 https://pastebin.com/mw3nYTiM The descriptions of dsi_lp_mode and dsi_hs_mode inside are different

Now that I have compiled my kernel and used it for startup, my device was initially backlit, but as the display initialized, the screen completely turned off and never lit up again, and there seemed to be no major errors in the logs. The following is the dmesg log of the kernel. https://pastebin.com/RNEVgg8n

I have tried some solutions, such as deleting MIPI_DSI_CLOCK_NON_CONTINUOUS, because I found the following logs in the official lk.

[1550] mipi clk continue mode

But it doesn't work. Also, I saw someone say it's because my panel uses ESD, which is not supported. Indeed, I saw something related to saw in the downstream kernel.

/* < DTS2014080900777  niuxiangyu 20140809 begin */
/* Add qcom patch to solve black screen problem, case:01642933 */
    qcom,spm@b012000 {
        compatible = "qcom,spm-v2";
        #address-cells = <1>;
        #size-cells = <1>;
        reg = <0xb012000 0x1000>;
        qcom,name = "system-l2";
        qcom,core-id = <0xffff>; /* L2/APCS SAW */
        qcom,saw2-ver-reg = <0xfd0>;
        qcom,saw2-cfg = <0x1F>;
        qcom,saw2-spm-dly= <0x3C102800>;
        qcom,saw2-spm-ctl = <0xe>;
        qcom,saw2-pmic-data0 = <0x05030080>;
        qcom,saw2-pmic-data1 = <0x00030000>;
        qcom,saw2-pmic-data4 = <0x00010080>;
        qcom,saw2-pmic-data5 = <0x00010000>;
        qcom,vctl-timeout-us = <50>;
        qcom,vctl-port = <0x0>;
        qcom,phase-port = <0x1>;
        qcom,pfm-port = <0x2>;
        qcom,cpu-vctl-mask = <0xf>;
        qcom,saw2-spm-cmd-ret = [00 03 00 0f];
        qcom,saw2-spm-cmd-gdhs = [00 20 32 6B C0 E0 D0 42 F0 03 50 4E
                02 02 D0 E0 C0 22 6B 02 32 52 F0 0F];
        qcom,saw2-spm-cmd-pc = [00 32 B0 10 E0 D0 6B C0 42 51 11 07 01 41
                B0 50 4E 02 02 C0 D0 12 E0 6B 02 32 50 0F];
    };
/* DTS2014080900777  niuxiangyu 20140809 end > */

in https://github.com/Mustang-ssc/android_kernel_huawei_hwt1a21l/blob/android-5.X-stock/arch/arm/boot/dts/qcom/msm8916-pm.dtsi This patch is strange, is it the reason for the black screen? So what should I do next? I am completely trapped now and I need help!!!

hicode002 commented 3 days ago

I also tried 6.12.1,but I met a lot of problems,such as no remoteproc,no wcnss ,no sensors. And the display did not work either. Here is my commit. https://github.com/msm8916-mainline/linux/commit/d1b9a6432d62da0b48291fa37df7be6e7ee8fdea#diff-5cb7c3979328780f5c2f46cdc2be9e4764d0a0fb87251bef16f2385e5f07de22