Learnincurve Posted May 25, 2020 Author Posted May 25, 2020 Does the screen display anything when it intitialises, early in the uboot process, or is garbage the first thing you see? Also, do you see anything in the xorg logs that would give you more information? 0 Quote
mix359 Posted May 27, 2020 Posted May 27, 2020 On 5/25/2020 at 1:14 PM, Learnincurve said: Does the screen display anything when it intitialises, early in the uboot process, or is garbage the first thing you see? Also, do you see anything in the xorg logs that would give you more information? Sadly that is what it show even during the uboot phase. About xorg, I don't have any X server installed at the moment (to keep the dmesg a bit cleaner... with Xorg installed it was really a mess...) Do you suggest to make some other try with it installed? Thanks Cheers Mix 0 Quote
Learnincurve Posted May 28, 2020 Author Posted May 28, 2020 12 hours ago, mix359 said: Sadly that is what it show even during the uboot phase. About xorg, I don't have any X server installed at the moment (to keep the dmesg a bit cleaner... with Xorg installed it was really a mess...) Do you suggest to make some other try with it installed? Thanks Cheers Mix Not really. I was just wondering whether it was an xorg issue, but if the message is from uboot, then you are right that something is wrong at a deeper level. Guess we'll just have to wait a little longer. Despite reading the Armbian Documentation many times, I'm still really hazy about applying the uboot video mode options: Quote How to reconfigure video output? This affect current kernel only. U-Boot supports HDMI and LCD output on Allwinner sunxi SoCs, LCD output requires the CONFIG_VIDEO_LCD_MODE Kconfig value to be set. The sunxi U-Boot driver supports the following video-mode options: monitor=[none|dvi|hdmi|lcd|vga|composite-*] - Select the video output to use none: Disable video output. dvi/hdmi: Selects output over the hdmi connector with dvi resp. hdmi output format, if edid is used the format is automatically selected. lcd: Selects video output to a LCD screen. vga: Selects video output over the VGA connector. composite-pal/composite-ntsc/composite-pal-m/composite-pal-nc: Selects composite video output, note the specified resolution is ignored with composite video output. Defaults to monitor=dvi. hpd=[0|1] - Enable use of the HDMI HotPlug Detect feature 0: Disabled. Configure DVI/HDMI output even if no cable is detected 1: Enabled. Fallback to the LCD / VGA / none in that order (if available) Defaults to hpd=1. hpd_delay=<int> - How long to wait for the HDMI HPD signal in milliseconds When the monitor and the board power up at the same time, it may take some time for the monitor to assert the HPD signal. This configures how long to wait for the HPD signal before assuming no cable is connected. Defaults to hpd_delay=500. edid=[0|1] - Enable use of DDC + EDID to get monitor info 0: Disabled. 1: Enabled. If valid EDID info was read from the monitor the EDID info will overrides the xres, yres and refresh from the video-mode env. variable. Defaults to edid=1. overscan_x/overscan_y=<int> - Set x/y overscan value This configures a black border on the left and right resp. top and bottom to deal with overscanning displays. Defaults to overscan_x=32 and overscan_y=20 for composite monitors, 0 for other monitors. For example to always use the HDMI connector, even if no cable is inserted, using edid info when available and otherwise initalizing it at 1024x768@60Hz, use: setenv video-mode sunxi:1024x768-24@60,monitor=dvi,hpd=0,edid=0. Parameters regarding video must be saved into U-Boot environment file since they must be read before reading boot script. You can do this by adding saveenv command at the end of boot script (boot.cmd). Remember to recompile boot.cmd to boot.scr and note that changes will come into action after second boot. Cheers! 0 Quote
Learnincurve Posted May 29, 2020 Author Posted May 29, 2020 Just looking at Gavinb's latest commit. He is compiling the panel and dsi code into the kernel, instead of loading as modules. https://github.com/GavinBa/build/commit/73850d2db3814418d865304befd2afb370865f6c Perhaps that is a solution? 0 Quote
Learnincurve Posted June 4, 2020 Author Posted June 4, 2020 So I finally tried installing the latest 5.4.43 build from Armbian. I applied your overlay, compiled and loaded from armbianEnv.txt and added the setenv video-mode sunxi:1024x600,monitor=lcd,hpd=0,edid=1 line. For me, the backlight works, but nothing else does. I decompiled the /boot/dtb/allwinner/sun50i-a64-pine64.dtb file, changed the dsi@1ca0000 { compatible = "allwinner,sun50i-a64-mipi-dsi"; reg = <0x1ca0000 0x1000>; interrupts = <0x00 0x59 0x04>; clocks = <0x02 0x1c>; resets = <0x02 0x05>; phys = <0x41>; phy-names = "dphy"; status = "disabled"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x84>; port { endpoint { remote-endpoint = <0x42>; phandle = <0x1e>; }; }; }; section to dsi@1ca0000 { compatible = "allwinner,sun50i-a64-mipi-dsi"; reg = <0x1ca0000 0x1000>; interrupts = <0x00 0x59 0x04>; clocks = <0x02 0x1c>; resets = <0x02 0x05>; phys = <0x41>; phy-names = "dphy"; status = "enabled"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x84>; port { endpoint { remote-endpoint = <0x42>; phandle = <0x1e>; }; }; }; I couldn't find any other references in that file and recompiled it. dmesg | grep dsi lists nothing, while dmesg | grep mipi [ 3.505719] vcc-mipi: Bringing 2900000uV into 3300000-3300000uV [ 6.603912] Modules linked in: cpufreq_dt zram sch_fq_codel g_serial libcomposite ip_tables x_tables autofs4 realtek axp20x_usb_power pinctrl_axp209 axp20x_regulator phy_sun6i_mipi_dphy dwmac_sun8i mdio_mux i2c_mv64xxx pwm_bl and dmesg | grep display root@pine64:~# dmesg | grep drm [ 5.394228] systemd[1]: Condition check resulted in Load Kernel Module drm being skipped. I also tried adding feiyang_fy07024di26a30 and sun6i_mipi_dsi to /etc/modules. with same result. 0 Quote
woglinde Posted June 7, 2020 Posted June 7, 2020 So we are at least some people, who still wants to get the feiyang display getting work on the pine64. @Learnincurve Looks like the kernel 5.4 has not all bits to get it work. With the 5.6 kernel we are at the same state as 2 years before. The whole DE-pipeline is recognized, but the panel remains out of order because of the vblank issue. @Gavinb Could you do us a favor an test the panel wit the 5.6 kernel? If it is working we could maybe find out the differences. I comment some findings at your github tree for the display patch. The option that I see, we are have now: Asking on irc channel of linux-sunix or the linux-sunxi mailinglist how the vblank isusse can be debugged. 0 Quote
jeanrhum Posted June 25, 2020 Posted June 25, 2020 Any improvements? If you can share a dts/dtb and current instructions, I will try to take time in the coming days to test on my board and panel. 0 Quote
Learnincurve Posted August 18, 2020 Author Posted August 18, 2020 Anyone have this working yet? I see there are new images in "archive", but no dtbo overlay. 0 Quote
jeanrhum Posted August 19, 2020 Posted August 19, 2020 I don't know if somebody make it work, but @@lex talked about that in another topic: On 8/9/2020 at 3:29 PM, @lex said: Pine64+ + LCD 7 + Touch works with mainline but it is tricky to setup. 0 Quote
@lex Posted August 19, 2020 Posted August 19, 2020 I was able to test the LCD7 with Pine64+ some time ago. I lost some work done with a 'rm *' in the wrong dir but i still have the sd card with the dtb if someone would like to 'decompile' it and compare. What i can recall from the tests are: * u-boot had hdmi and dsi disabled, so no initial display, only when kernel is up * the kernel tested had dsi support, linux-next (jan 9) [next-20200109], no patches were needed only the patch from @Clément Peron to fix that backlight dim issue. If you can fetch that specific linux-next version, only dts with dsi enabled is required. Refer to: https://groups.google.com/g/linux-sunxi/c/q-RxYnlRqog/m/PQ5pE2kEAQAJ * try to fetch that version, rebuild. If you have Pine64 LTS 1.2 , some people reported hw issue, check if that is the case.. 0 Quote
Learnincurve Posted August 20, 2020 Author Posted August 20, 2020 Hi @lex and thank you for responding! I do have a 2GB Pine64+, so would be very interested to take a look at your .dtb If you could make it available on/to this thread that would be really great! My guess is that is should also work with the latest kernel. BR. --Marius-- 0 Quote
@lex Posted August 20, 2020 Posted August 20, 2020 Attached is the working Pine64+ + LCD7 + touch dtb. pine64.dtb_5.5.0-rc5-next-20200109.tar.gz 0 Quote
Learnincurve Posted August 25, 2020 Author Posted August 25, 2020 Hmm... I do see quite a few differences in the two decompiled dts files. Will try to locate only the blocks affecting DSI /feiyang touch etc, as I don't dare just swap out the whole file. both .dts's attached sun50i-a64-pine64-plus_ORIG.dts sun50i-a64-pine64+_MIPI.dts 0 Quote
Learnincurve Posted August 25, 2020 Author Posted August 25, 2020 Here's the original file with the dsi and feiyang section transposed from @lex's .dts I'm getting ERROR (explicit_phandles): /soc/dsi@1ca0000/port/endpoint: duplicated phandle 0x1c (seen before at /soc/lcd-controller@1c0c000/ports/port@0/endpoint@1) I forced output and have a dtb. .dts file attached sun50i-a64-pine64-plus_EDITED.dts 0 Quote
Learnincurve Posted August 25, 2020 Author Posted August 25, 2020 Closer: dmesg | grep dsi [ 2.179940] OF: /soc/dsi@1ca0000: could not get #phy-cells for /soc/pinctrl@1c20800/rgmii-pins [ 2.179949] sun6i-mipi-dsi 1ca0000.dsi: Couldn't get the MIPI D-PHY Looking at the pinctrl@1c20800 section, there are quite a few differences between the original and @lex's file, so not sure how much to transpose. Transposing the whole section is giving far more duplicated phandle errors, so stopping here. dtc -f -O dtb -o sun50i-a64-pine64-plus.dtb sun50i-a64-pine64-plus_EDITED.dts sun50i-a64-pine64-plus_EDITED.dts:722.13-726.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/csi-pins: duplicated phandle 0x3e (seen before at /soc/syscon@1c00000) sun50i-a64-pine64-plus_EDITED.dts:742.14-748.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/mmc0-pins: duplicated phandle 0x21 (seen before at /soc/bus@1000000/mixer@100000/ports/port@1/endpoint@1) sun50i-a64-pine64-plus_EDITED.dts:750.14-756.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/mmc1-pins: duplicated phandle 0x24 (seen before at /soc/syscon@1c00000/sram@1d00000/sram-section@0) sun50i-a64-pine64-plus_EDITED.dts:791.17-795.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/spdif-tx-pin: duplicated phandle 0x2c (seen before at /soc/phy@1c19400) sun50i-a64-pine64-plus_EDITED.dts:815.15-819.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/uart1-pins: duplicated phandle 0x2f (seen before at /soc/dma-controller@1c02000) sun50i-a64-pine64-plus_EDITED.dts:1249.14-1252.7: ERROR (explicit_phandles): /soc/dsi@1ca0000/port/endpoint: duplicated phandle 0x1c (seen before at /soc/lcd-controller@1c0c000/ports/port@0/endpoint@1) sun50i-a64-pine64-plus_EDITED.dts:1312.15-1315.8: ERROR (explicit_phandles): /soc/hdmi@1ee0000/ports/port@0/endpoint: duplicated phandle 0x23 (seen before at /soc/pinctrl@1c20800) sun50i-a64-pine64-plus_EDITED.dts:1341.15-1350.5: ERROR (explicit_phandles): /soc/rtc@1f00000: duplicated phandle 0x2e (seen before at /soc/pinctrl@1c20800/uart0-pb-pins) sun50i-a64-pine64-plus_EDITED.dts:1417.19-1453.5: ERROR (explicit_phandles): /soc/pinctrl@1f02c00: duplicated phandle 0x35 (seen before at /soc/pinctrl@1c20800/i2c0-pins) Warning: Input tree has errors, output forced Hopefully someone who knows anything about dtb (as I know nothing), will be able to sort out the mess and post back with advice or edited file 0 Quote
Learnincurve Posted September 8, 2020 Author Posted September 8, 2020 Closer again. I'm now using the latest "Armbian Focal mainline based kernel 5.8.y" image, including the updated dtb .deb update. I have modified the dtb, changing the dsi section to "okay", and adding the vcc-dsi line and the feiyang panel subsection. This is what I'm getting: dmesg | grep dsi [ 2.263813] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.265832] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.266675] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.267313] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.271430] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.272127] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.272671] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.273211] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.318595] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360) [ 6.716321] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 6.724523] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 6.739883] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 6.752834] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 6.768429] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 6.784961] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 6.788281] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 6.856971] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 7.081487] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 7.120322] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator [ 7.838355] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator Any advice on the feiyang dvdd regulator? 0 Quote
Learnincurve Posted October 6, 2020 Author Posted October 6, 2020 I found the following code at https://mjmwired.net/kernel/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt: Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel Required properties: - compatible: must be "feiyang,fy07024di26a30d" - reg: DSI virtual channel used by that screen - avdd-supply: analog regulator dc1 switch - dvdd-supply: 3v3 digital regulator - reset-gpios: a GPIO phandle for the reset pin Optional properties: - backlight: phandle for the backlight control. panel@0 { compatible = "feiyang,fy07024di26a30d"; reg = <0>; avdd-supply = <®_dc1sw>; dvdd-supply = <®_dldo2>; reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ backlight = <&backlight>; }; In the regulatotrs section of my active dtb -> dts file I find reg_dc1sw = "/soc/rsb@1f03400/pmic@3a3/regulators/dc1sw"; reg_dcdc1 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc1"; reg_dcdc2 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc2"; reg_dcdc3 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc3"; reg_dcdc4 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc4"; reg_dcdc5 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc5"; reg_dcdc6 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc6"; reg_dldo1 = "/soc/rsb@1f03400/pmic@3a3/regulators/dldo1"; reg_dldo2 = "/soc/rsb@1f03400/pmic@3a3/regulators/dldo2"; but after editing the dts file like: panel@0 { compatible = "feiyang,fy07024di26a30d"; reg = <0x00>; avdd-supply = <®_dc1sw>; dvdd-supply = <®_dldo2>; reset-gpios = <0x23 0x03 0x18 0x00>; backlight = <0x43>; }; It won't compile, so obviously I don't understand. Any tips? 0 Quote
Learnincurve Posted October 16, 2020 Author Posted October 16, 2020 I updated the system with the new dtb package and edited the tree again, this time without the feiyang panel. Here are the the .dts snippets for dsi and d-phy: dsi@1ca0000 { compatible = "allwinner,sun50i-a64-mipi-dsi"; reg = <0x1ca0000 0x1000>; interrupts = <0x00 0x59 0x04>; clocks = <0x02 0x1c>; resets = <0x02 0x05>; phys = <0x44>; phy-names = "dphy"; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x8d>; vcc-dsi-supply = <0x04>; port { endpoint { remote-endpoint = <0x45>; phandle = <0x20>; }; }; }; d-phy@1ca1000 { compatible = "allwinner,sun50i-a64-mipi-dphy\0allwinner,sun6i-a31-mipi-dphy"; reg = <0x1ca1000 0x1000>; clocks = <0x02 0x1c 0x02 0x71>; clock-names = "bus\0mod"; resets = <0x02 0x05>; status = "okay"; #phy-cells = <0x00>; phandle = <0x44>; }; This time, dmesg is at least not displaying any mipi or dsi-related errors: # dmesg | grep dsi [ 2.318045] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360) ~# dmesg | grep mipi [ 2.275838] vcc-mipi: Bringing 2900000uV into 3300000-3300000uV so definitely closer. Now I'm going to re-visit the thread and armbian documentation to see what needs to be done to enable. 1 Quote
Learnincurve Posted October 16, 2020 Author Posted October 16, 2020 Found that this isn't going to work without the Feiyang panel. Where I am stuck now is the reset-gpios for the feiyang panel dts code extracted from @lex's dtb post earlier in this thread and modified with unique phandles for the current tree: dsi@1ca0000 { compatible = "allwinner,sun50i-a64-mipi-dsi"; reg = <0x1ca0000 0x1000>; interrupts = <0x00 0x59 0x04>; clocks = <0x02 0x1c>; resets = <0x02 0x05>; phys = <0x44>; phy-names = "dphy"; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x8d>; vcc-dsi-supply = <0x04>; port { endpoint { remote-endpoint = <0x45>; phandle = <0x20>; }; }; panel@0 { compatible = "feiyang,fy07024di26a30d"; reg = <0x00>; avdd-supply = <0x41>; dvdd-supply = <0xa5>; reset-gpios = <0x23 0x03 0x18 0x00>; backlight = <0xb2>; }; }; and the gpios and enable-gpios for the backlight and regulator: backlight { compatible = "pwm-backlight"; pwms = <0x4f 0x00 0xc350 0x01>; brightness-levels = <0x00 0x0a 0x14 0x1e 0x28 0x32 0x3c 0x46 0x50 0x5a 0x64>; default-brightness-level = <0x08>; enable-gpios = <0x23 0x07 0x0a 0x00>; Probabløy incorrect power-supply = <0xb2>; phandle = <0xb1>; }; vdd-backlight { compatible = "regulator-fixed"; regulator-name = "vdd-backlight"; regulator-min-microvolt = <0x325aa0>; regulator-max-microvolt = <0x325aa0>; gpio = <0x23 0x03 0x07 0x00>; Probably incorrect enable-active-high; phandle = <0xb2>; }; 0 Quote
p1x3l3d Posted November 11, 2020 Posted November 11, 2020 Hey @Learnincurve, have you gotten any further with this? Do I understand correctly that you can't test it because you don't have the panel? I'd be willing to test if you'd like I have a Pine64-LTS with a LCD panel from Pine64 (and the 'playbox' as well) so if you want I could test stuff? Just tell me what to do! Cheers! 0 Quote
Learnincurve Posted November 13, 2020 Author Posted November 13, 2020 On 11/11/2020 at 7:15 PM, p1x3l3d said: Hey @Learnincurve, have you gotten any further with this? Do I understand correctly that you can't test it because you don't have the panel? I'd be willing to test if you'd like I have a Pine64-LTS with a LCD panel from Pine64 (and the 'playbox' as well) so if you want I could test stuff? Just tell me what to do! Cheers! Hi p1x313d. Thank you for your support! No. The problem is not that I don't have the panel, I do. My problem is lack of understanding and knowledge regarding the Device Tree. I am at the stage where I am stuck, unable to correctly set the pins (I think) for the panel. @lex was able to do this, using an earlier kernel and device tree, but too many internal references in the later available trees have changed, and I'm not smart enough to sort them out. If you or anyone else would like to help trying to debug, I'd be very grateful, as this is holding up being able to move to a mainline kernel for anyone with the Pine64+ and the feiyang panel. Here's my latest logging output: dmesg | grep dsi [ 2.261142] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.263148] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.263985] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.264616] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.268920] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.269694] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.270269] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.270807] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 2.316217] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360) [ 5.482679] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint [ 5.482717] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get our reset GPIO [ 5.482855] feiyang-fy07024di26a30d: probe of 1ca0000.dsi.0 failed with error -22 attached, you can find my dtb and corresponding dts files, as well as the .dts of @lex's working example sun50i-a64-pine64+_MIPI.dts for patched kernel 5.3/5.4 . @lex's .dtb is attached to his earlier post in this thread, but I can re-attach it if it is no longer available to download. Note that mipi-dsi was only included in mainline from 5.6 sun50i-a64-pine64-plus.dts sun50i-a64-pine64+_MIPI.dts sun50i-a64-pine64-plus.dtb 0 Quote
Learnincurve Posted November 13, 2020 Author Posted November 13, 2020 Update: I just took out the feiyang panel section in the device tree, as that gives the clearest dmesg indication that the dsi port is working: Quote vcc-mipi: Bringing 2900000uV into 3300000-3300000uV dmesg | grep dsi [ 2.315495] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010da8a60) dmesg | grep panel [ 2.315223] sun4i-drm display-engine: No panel or bridge found... RGB output disabled Have also discovered armbianmonitor -u. Dump at http://ix.io/2E03 0 Quote
jeanrhum Posted November 13, 2020 Posted November 13, 2020 3 hours ago, Learnincurve said: Have also discovered armbianmonitor -u. Dump at http://ix.io/2E03 As I saw in these data: [ 2.285937] sun6i-mipi-dsi 1ca0000.dsi: supply vcc-dsi not found, using dummy regulator Maybe it comes from there, because after searching about this error, I found these 2 links: - https://patchwork.kernel.org/project/linux-arm-kernel/patch/20181026144344.27778-17-jagan@amarulasolutions.com/ - https://gitlab.com/pine64-org/linux/-/commit/6beba7fbeeeee35130dade8766c1797b498d0a3f And looking at your dts file with panel, I saw that the dldo1 node (phandle 0x04) is labelled as "vcc-hdmi" and it is referenced both in the dsi node (vcc-dsi-supply) and in the hdmi node (hvcc-supply). If I remember well about the legacy kernel, when you activated the panel, the hdmi didn't work anymore. So maybe you can try to deactivate the hdmi part... I'm a newbie about dts, so be careful about my analysis. 0 Quote
Learnincurve Posted November 16, 2020 Author Posted November 16, 2020 On 11/13/2020 at 3:45 PM, jeanrhum said: As I saw in these data: [ 2.285937] sun6i-mipi-dsi 1ca0000.dsi: supply vcc-dsi not found, using dummy regulator Maybe it comes from there, because after searching about this error, I found these 2 links: - https://patchwork.kernel.org/project/linux-arm-kernel/patch/20181026144344.27778-17-jagan@amarulasolutions.com/ - https://gitlab.com/pine64-org/linux/-/commit/6beba7fbeeeee35130dade8766c1797b498d0a3f And looking at your dts file with panel, I saw that the dldo1 node (phandle 0x04) is labelled as "vcc-hdmi" and it is referenced both in the dsi node (vcc-dsi-supply) and in the hdmi node (hvcc-supply). If I remember well about the legacy kernel, when you activated the panel, the hdmi didn't work anymore. So maybe you can try to deactivate the hdmi part... I'm a newbie about dts, so be careful about my analysis. Good suggestion! I did try disabling hdmi stuff earlier (without success, but not sure if it was before or after adding the panel, so will try again). I'm also a DTS-noob and finding it hard to get my head around it. Hence my spamming of this thread, which it looks like the experts are now filtering out (can't say I blame them). 0 Quote
Learnincurve Posted December 4, 2020 Author Posted December 4, 2020 : Issue is finally fixed in (at least) nightly builds ! There is now a "pine64-7inch-lcd" overlay in /boot/dtb//allwinner/overlay Just add "overlays=pine64-7inch-lcd" to armbianEnv.txt and screen magically works. A BIG thank you to the team for fixing this! Pine64 is now ready for mainline kernel goodness! 2 Quote
eminguez Posted December 4, 2020 Posted December 4, 2020 Nice!!!! Do you happen to have a link to download the latest nightly? https://minio.k-space.ee/armbian/dl/pine64/nightly/Armbian_21.02.0-trunk.7_Pine64_buster_current_5.9.11.img.xz seems to fail for me. Thanks. 0 Quote
Learnincurve Posted December 4, 2020 Author Posted December 4, 2020 2 minutes ago, eminguez said: Nice!!!! Do you happen to have a link to download the latest nightly? https://minio.k-space.ee/armbian/dl/pine64/nightly/Armbian_21.02.0-trunk.7_Pine64_buster_current_5.9.11.img.xz seems to fail for me. Thanks. I cheated and upgraded to nightly from the latest stable build, which you can do from the armbian-config - System menu. Otherwise I see that all of https://minio.k-space.ee/armbian/ is unavailable at the moment. The link will probably work again later. 1 Quote
TRS-80 Posted December 4, 2020 Posted December 4, 2020 (edited) 5 hours ago, Learnincurve said: I see that all of https://minio.k-space.ee/armbian/ is unavailable at the moment. Work is ongoing on improving infrastructure (load balancing, re-directs, etc.). And therefore it's probably best to discuss and make forum links to the "original" link, instead of whatever the redirect ends up going to, as the latter is going to vary for people based on their region and some other things. Also they may go up and down for various reasons, etc. Edited December 4, 2020 by TRS-80 add last sentence 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.