99degree / android_kernel_meizu_m851q_old Goto Github PK

Hi thinhx2,

https://github.com/99degree/android_kernel_meizu_m851q/issues/1#issuecomment-601509985

Thx for your comment. My investigation shows that the older kernel tends to have in-code kernel driver init plus userland cmos init for a particular cam module. If you wanted to get more info, refer to "sdm660-camera-sensor-mtp.dtsi". Regarding to camera, and more specifically, in E3's flyme 8 rom, there is very few eeprom info in dts compared to Mi A2's. My guess is, camera is probed first
by custom in-kernel driver code.

Newer drivers of camer-V2 module, first one-third by kernel driver (for its pin ctrl and voltage) and middle third is eeprom driver init and and last third by userspace for cmos. Even through all so library are available, there are still need for extra step (ndk development) to dump off the probe procedure (mostly i2c communication in flyme) to init lens (should be less important even-through blur image of out focus), and cmos (init and calibrate info stored in camera module's eeprom) in order to put those info right, and put them (eeprom related) into dts file (like Mi A3 and other sdm660 phone does init pinctrl, regulator and eeprom in kernel driver with help of dts, ref to Mi-A2's qcom,eeprom driver). Below is extract from dtsi FYI (sdm660-camera-sensor-mtp_f7a.dtsi)

    eeprom3: qcom,eeprom@3{
            cell-index = <3>;
            reg = <0x3>;
            compatible = "qcom,eeprom";
            qcom,eeprom-name = "lavender_s5k5e8_ofilm_i";
            qcom,i2c-freq-mode = <1>;
            qcom,slave-addr = <0x30>;
            qcom,num-blocks = <27>;

            **//init4
            qcom,page0 = <1 0x0A00 2 0x04 1 1>;
            qcom,poll0 = <0 0x0 2 0 1 1>;
            qcom,mem0 = <0 0x0 2 0 1 0>;**

How is this happened? the userland driver library is old from third-party and the camera driver (lived in kernel) is more newer so there are API difference. So other developer might do a shim lib right-way. So the situ is like no kernel driver (info) available, and the userland driver is last-third partial working and the probe procedure is incomplete.

I am not sure if your phone have sufficient dts entry to init those cam system, if so, then you are lucky to go. Hope above info are clear enough to help your further progress.

Good luck and happy flashing
99degree

as title.

Current investigation result is still not enough to fix this issue.

Background
qdsp6 is a dsp and the alsa codec is built upon this block as internal codecs. the output is supposed an I2S secondary out (via pin pinctrl gpio24 to gpio27, mentioned sec-dai, not confirmed, capture from from dts)

                        qcom,msm-dai-q6-mi2s-sec {
                                compatible = "qcom,msm-dai-q6-mi2s";
                                qcom,msm-dai-q6-mi2s-dev-id = <0x1>;
                                qcom,msm-mi2s-rx-lines = <0x1>;
                                qcom,msm-mi2s-tx-lines = <0x2>;
                                pinctrl-names = "default", "sleep";
                                pinctrl-0 = <0x1d9 0x1da 0x1db>;
                                pinctrl-1 = <0x1dc 0x1dd 0x1de>;
                                linux,phandle = <0x1f3>;
                                phandle = <0x1f3>;
                        };

qdsp6 is same to s820 soc's thus its qcom,lpi also have such gpio24, so cant sure if E3's should go through tlmm's gpio24 or newer lpi's gpio24. or adsp.mbm support this?

Sony pioneer and nubia's, the sound sub-sys is eneded with stub-codec and do not observe any codec chip.

E3's setup is with an tas2560 smart-amp. in dts, its linked with sec-dai (gpio24-27) which is unlike jasmine sprout(Mi A2) having tas2557 ended in primary-dai (guess only from dts)

Nokia 7, ended with tas2560 (in tert-dai, from dts) and/or tfa9891 (external codec?).

So audio routing is a problem yet to figure out. then userland mixer control is also a problem thus it is like quadratic equation with at least 2 root of problem.

TAS2560 datasheet:
http://www.ti.com/lit/ds/symlink/tas2560.pdf

The setup for E3 can make audio jack button working but that's it. This setup use gpio4 to gpio7, thus is very confusing.

as title stated.

According to log, eeprom userspace probe success. But log shows
msm_eeprom_subdev_ioctl32->msm_eeprom_config32->case default(CFG_EEPROM_GET_MM_INFO) and thus bypass all eeprom red cal etc.

the earphone is able to do playback so it is likely the control panel is not yet integrate in good shape to dsp dai. at least the algo downloader is not available compare to nokia 7

side issue is SLIMBUS hostless DAI not available. this is a puzzle so far.

remaining issue
(1) TAS2560 not working and
(2) SLIMBUS hostless DAI not available problem caused audio open/probe so long.

some of the available sensors are working. Some are not.
Basically Accero/Gyro are not working and suspect it is related to gpio issue.
Light/Hall/Distance/Mag are working.

from thinhx2,

the source file https://github.com/pingwuu/linux-imx/blob/80db2248bc6818db8088de88ac6d5ec8ed45afd9/drivers/input/touchscreen/sec_ts/s6d6ft0_v1.10_20170918.i is missing.

Thinks for your afford. Your approach is also ok. My approach, the file is not needed. Please fetch the newer code in case you are still interested in this kernel. I had comment out the fw update logic completely to void fw upgrade on init boot (to avoid incompatible fw version to flyme8 kernel).

Please create issue ticket in case you have patches for inclusion or I might miss this.

99degree