Learnincurve Posted March 31, 2020 Author Share Posted March 31, 2020 Still no dice 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted April 2, 2020 Author Share Posted April 2, 2020 I'm going to have to go through Gavinb's changes and see what needs applying to the Pine64 base build. 0 Quote Link to comment Share on other sites More sharing options...
Gavinb Posted April 7, 2020 Share Posted April 7, 2020 Hi, You'll need to remap the changes to the Pine64So device tree into the Pine64's, then you should be good to go. The only major difference between the two is the dram, which is handled at spl/u-boot level. 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted April 8, 2020 Author Share Posted April 8, 2020 Thanks Gavinb, That's a good Easter project. As I don't know my way around the sources very well, can you tell me which files(s) tool look for? Thanks very much! 0 Quote Link to comment Share on other sites More sharing options...
Reiniti Posted May 4, 2020 Share Posted May 4, 2020 Has there been any progress made on the mainline kernel? 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted May 4, 2020 Share Posted May 4, 2020 30 minutes ago, Reiniti said: Has there been any progress made on the mainline kernel? https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix 0 Quote Link to comment Share on other sites More sharing options...
Asimov Posted May 4, 2020 Share Posted May 4, 2020 Hi, where can I get this version of kernel 5.6?? Past me an URL o something to download this.. Thanks you. 0 Quote Link to comment Share on other sites More sharing options...
jeanrhum Posted May 4, 2020 Share Posted May 4, 2020 Here are a minimal 5.6 dev builds: https://dl.armbian.com/pine64/nightly/ But I don't know how to activate MIPI DSI screen from it. Maybe a specific kernel config and dtb has to be used (you can try by using armbian build scripts). 0 Quote Link to comment Share on other sites More sharing options...
Asimov Posted May 4, 2020 Share Posted May 4, 2020 Hi jeanrhum but I need are the sources to compile this version of kernel 5.6.x If someone know where find out this please share this information. 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 5, 2020 Author Share Posted May 5, 2020 Hi, If you want to compile, just follow the instructions at https://docs.armbian.com/Developer-Guide_Build-Preparation/ but it shouldn''t be necessary, as Armbian 20.05 will use it and the nightly builds already contain it. The problem is not the kernel, but the device tree bindings (DTB), which has been fixed for MIPI-DSI for the Pine64so (in this thread), but I still haven't figured out how to do it for the pine64+ and don't know if it is taken care of in the nightly builds or the sources. If it is, I still haven't figured out how to enable it at boot time. I hope that someone can explain that in this thread, as pretty much everything we need is now in the mainline kernel. 0 Quote Link to comment Share on other sites More sharing options...
Gavinb Posted May 5, 2020 Share Posted May 5, 2020 Hi I've just started work on the 5.4 kernel, will be testing that and getting relevant DTB changes into the patches. Once completed and working, I'll package things up as an overlay for those that want to use the MIPI-DSI. If I get a chance to afterwards, I'll have a look at the dev branch to get something working there. 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 5, 2020 Author Share Posted May 5, 2020 35 minutes ago, Gavinb said: Hi I've just started work on the 5.4 kernel, will be testing that and getting relevant DTB changes into the patches. Once completed and working, I'll package things up as an overlay for those that want to use the MIPI-DSI. If I get a chance to afterwards, I'll have a look at the dev branch to get something working there. Fantastic news Gavinb! Thank you very much! I'm sorry I haven't been of any help regarding creating the overlay myself. Will the overlay be available for the pine64+ as well as the sopine64? 0 Quote Link to comment Share on other sites More sharing options...
Mac_Ha Posted May 5, 2020 Share Posted May 5, 2020 @Gavinb would this also work on the original Pine64 with the LCD from the kickstarter? 0 Quote Link to comment Share on other sites More sharing options...
Gavinb Posted May 5, 2020 Share Posted May 5, 2020 The only difference between the boards is the SRAM, so the same overlay should just work on the pine64/64+, unfortunately I don't have access to a pine64+ at the moment to be able to test it. 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 5, 2020 Author Share Posted May 5, 2020 47 minutes ago, Gavinb said: The only difference between the boards is the SRAM, so the same overlay should just work on the pine64/64+, unfortunately I don't have access to a pine64+ at the moment to be able to test it. So if you have the overlay from your previous sopine build , could you just attach it here so we could test? I'd be happy to do that, as I have a working 5.6 build (apart from the device tree). 0 Quote Link to comment Share on other sites More sharing options...
Gavinb Posted May 5, 2020 Share Posted May 5, 2020 I had done it directly in the device tree itself and didn't make an overlay then. But will this time around 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 5, 2020 Author Share Posted May 5, 2020 Excellent! Thank you so much! 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 14, 2020 Author Share Posted May 14, 2020 Has anyone tries the new, 5.4.40 or 5.6.8 (dev branch) nightly builds and seen whether they contain the DT bindings for DSI? I have flashed my SD so many time's that I don't want to keep doing it (on the offchance). On the other hand, if the bindings are now there... 0 Quote Link to comment Share on other sites More sharing options...
mix359 Posted May 14, 2020 Share Posted May 14, 2020 I've flashed a 5.4 Bionic on my Pine64 (kickstarter edition) and I've switched to Nightly release & the 5.6.12 kernel, but I have no idea how to "enable" the support... (and it hasn't started working... the LCD is still off) I've tried adding both the pine64_lcd=on and the monitor=lcd row to the /boot/armbianEnv.txt (don't know if it's required) but nothing changed. 10 hours ago, Learnincurve said: Has anyone tries the new, 5.4.40 or 5.6.8 (dev branch) nightly builds and seen whether they contain the DT bindings for DSI? I have flashed my SD so many time's that I don't want to keep doing it (on the offchance). On the other hand, if the bindings are now there... Taking a first look I can't see any a64 DT overlay regarding the dsi or mipi dsi. If I search inside the "/boot/dtb/allwinner/sun50i-a64-pine64.dtb" file, I can find a reference to "sun50i-a64-mipi-dsi", but nothing more. Any suggestion of something to try, to make it work? Thanks Cheers Mix 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 15, 2020 Author Share Posted May 15, 2020 15 hours ago, mix359 said: I've flashed a 5.4 Bionic on my Pine64 (kickstarter edition) and I've switched to Nightly release & the 5.6.12 kernel, but I have no idea how to "enable" the support... (and it hasn't started working... the LCD is still off) I've tried adding both the pine64_lcd=on and the monitor=lcd row to the /boot/armbianEnv.txt (don't know if it's required) but nothing changed. Taking a first look I can't see any a64 DT overlay regarding the dsi or mipi dsi. If I search inside the "/boot/dtb/allwinner/sun50i-a64-pine64.dtb" file, I can find a reference to "sun50i-a64-mipi-dsi", but nothing more. Any suggestion of something to try, to make it work? Thanks Cheers Mix Could you send the content of the "/boot/dtb/allwinner/sun50i-a64-pine64.dtb" file? Could be that you need to do something from https://docs.armbian.com/User-Guide_Allwinner_overlays/ ? I don't think earlier versions of that file contained any reference to sun50i-a64-mipi-dsi". If there's no equivalent .dtbo file, that might indicate that the overlay is still a work in progress. Have you grepped dmesg for any mention of DSI? Cheers! 0 Quote Link to comment Share on other sites More sharing options...
jeanrhum Posted May 15, 2020 Share Posted May 15, 2020 Hi, I can confirm that dev images with kernel 5.6 does not have dsi support (tested on pine64+ ks). I will put as soon as possible the decompiled dts and the dmesg output. I think that the best way to add it is as a dtb overlay, but I'm not very familiar with that. 0 Quote Link to comment Share on other sites More sharing options...
mix359 Posted May 15, 2020 Share Posted May 15, 2020 Hi to all, Sorry but for some reason I can post only once a day... so i had to wait... I've done some other test and research. First thing, thanks to have point me to the device tree/overlay world... I've studied a bit how that work and I've decompiled the pine64+ file dtb file, to find out those paragraph: Spoiler dsi@1ca0000 { compatible = "allwinner,sun50i-a64-mipi-dsi"; reg = <0x1ca0000 0x1000>; interrupts = <0x0 0x59 0x4>; clocks = <0x2 0x1c>; resets = <0x2 0x5>; phys = <0x42>; phy-names = "dphy"; status = "disabled"; #address-cells = <0x1>; #size-cells = <0x0>; phandle = <0x88>; port { endpoint { remote-endpoint = <0x43>; phandle = <0x1e>; }; }; }; d-phy@1ca1000 { compatible = "allwinner,sun50i-a64-mipi-dphy", "allwinner,sun6i-a31-mipi-dphy"; reg = <0x1ca1000 0x1000>; clocks = <0x2 0x1c 0x2 0x71>; clock-names = "bus", "mod"; resets = <0x2 0x5>; status = "disabled"; #phy-cells = <0x0>; phandle = <0x42>; }; Haven't found a way to upload here, so if someone is interested, this is the decompiled sun50i-a64-pine64-plus.dts on pastebin: https://pastebin.com/nRkD0hep Searching around I've found that those two were disabled by the status = "disabled", so after some search I managed to create a little overlay that enable it (d-phy is a sort of dependency, without it dsi doesn't work). Here's the dts if someone are interested: Spoiler /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-a64-mipi-dsi"; fragment@0 { target = <&dsi>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&dphy>; __overlay__ { status = "okay"; }; }; }; You can compile it with something like: dtc -O dtb -o sun50i-a64-mipi-dsi.dtbo -b 0 -@ sun50i-a64-mipi-dsi.dts Now, looking into dmesg i can finally found some reference to the dsi, but sadly the screen doesn't power on. Here's a little bit of the dmesg: [ 5.606040] sun6i-mipi-dsi 1ca0000.dsi: 1ca0000.dsi supply vcc-dsi not found, using dummy regulator [ 5.627202] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffff800010ce9570) [ 5.628628] sun4i-drm display-engine: bound 1200000.mixer (ops 0xffff800010ce9570) [ 5.629099] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 5.629121] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xffff800010ce5a50) [ 5.629302] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xffff800010ce5a50) [ 5.629341] sun4i-drm display-engine: bound 1ca0000.dsi (ops sun6i_dsi_ops [sun6i_mipi_dsi]) [ 5.649211] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy) So it seam to me that it's not finding the attached lcd panel... So my doubt now is: does I need to set up something other to make it work? for example some lcd parameters? or some other parameters in the overlay? Maybe something related to lcd-controller? There's any resource somewhere when I can find some information about how to configure lcd panel in this kernel version? PS: meanwhile I've tried flashing on another SD card an old version of armian with the 3.10 kernel version, where the lcd work perfectly. Sadly the device tree files are completely different from the one in the 5.6 kernel and talk about disp and lcd0, that doesn't exist in the new dts. Thanks to all Cheers Mix 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 16, 2020 Author Share Posted May 16, 2020 10 hours ago, mix359 said: Hi to all, Sorry but for some reason I can post only once a day... so i had to wait... I've done some other test and research. First thing, thanks to have point me to the device tree/overlay world... I've studied a bit how that work and I've decompiled the pine64+ file dtb file, to find out those paragraph: Reveal hidden contents dsi@1ca0000 { compatible = "allwinner,sun50i-a64-mipi-dsi"; reg = <0x1ca0000 0x1000>; interrupts = <0x0 0x59 0x4>; clocks = <0x2 0x1c>; resets = <0x2 0x5>; phys = <0x42>; phy-names = "dphy"; status = "disabled"; #address-cells = <0x1>; #size-cells = <0x0>; phandle = <0x88>; port { endpoint { remote-endpoint = <0x43>; phandle = <0x1e>; }; }; }; d-phy@1ca1000 { compatible = "allwinner,sun50i-a64-mipi-dphy", "allwinner,sun6i-a31-mipi-dphy"; reg = <0x1ca1000 0x1000>; clocks = <0x2 0x1c 0x2 0x71>; clock-names = "bus", "mod"; resets = <0x2 0x5>; status = "disabled"; #phy-cells = <0x0>; phandle = <0x42>; }; Haven't found a way to upload here, so if someone is interested, this is the decompiled sun50i-a64-pine64-plus.dts on pastebin: https://pastebin.com/nRkD0hep Searching around I've found that those two were disabled by the status = "disabled", so after some search I managed to create a little overlay that enable it (d-phy is a sort of dependency, without it dsi doesn't work). Here's the dts if someone are interested: Reveal hidden contents /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-a64-mipi-dsi"; fragment@0 { target = <&dsi>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&dphy>; __overlay__ { status = "okay"; }; }; }; You can compile it with something like: dtc -O dtb -o sun50i-a64-mipi-dsi.dtbo -b 0 -@ sun50i-a64-mipi-dsi.dts Now, looking into dmesg i can finally found some reference to the dsi, but sadly the screen doesn't power on. Here's a little bit of the dmesg: [ 5.606040] sun6i-mipi-dsi 1ca0000.dsi: 1ca0000.dsi supply vcc-dsi not found, using dummy regulator [ 5.627202] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffff800010ce9570) [ 5.628628] sun4i-drm display-engine: bound 1200000.mixer (ops 0xffff800010ce9570) [ 5.629099] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 5.629121] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xffff800010ce5a50) [ 5.629302] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xffff800010ce5a50) [ 5.629341] sun4i-drm display-engine: bound 1ca0000.dsi (ops sun6i_dsi_ops [sun6i_mipi_dsi]) [ 5.649211] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy) So it seam to me that it's not finding the attached lcd panel... So my doubt now is: does I need to set up something other to make it work? for example some lcd parameters? or some other parameters in the overlay? Maybe something related to lcd-controller? There's any resource somewhere when I can find some information about how to configure lcd panel in this kernel version? PS: meanwhile I've tried flashing on another SD card an old version of armian with the 3.10 kernel version, where the lcd work perfectly. Sadly the device tree files are completely different from the one in the 5.6 kernel and talk about disp and lcd0, that doesn't exist in the new dts. Thanks to all Cheers Mix Just a guess, but do you see any more in the device tree referencing vcc-dsi. Could it be that the voltages are not being set?? Regarding the panel, it's a Feiyang FY07024DI26A30-D DSI panel. Do you see any references to that? 0 Quote Link to comment Share on other sites More sharing options...
mix359 Posted May 16, 2020 Share Posted May 16, 2020 My daily update (hope this post limit will disappear soon) @Learnincurve Yep, you where right, there was a parameter missing in the overlay, and there wasn't any trace of the panel in the dmesg... Looking around I've found that there is a driver for the Feiyang lcd (thanks for the model information) and also an old example of dt config: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/display/panel/feiyang%2Cfy07024di26a30d.txt So using that, I've created a user dt overlay to use the lcd, here's the code: https://pastebin.com/EAXhSjHL With that overlay enabled, the lcd backlight turned on (hurray... a sign of life!), but show random gray lines, like if the clock is wrong in any way. Also it take a very long time to complete the boot, because of an error that appear multiple times before continue the boot, that talk about vblank timeout. Here's a chunk from the dmesg: Spoiler [CRTC:41:crtc-0] vblank wait timed out [ 37.453183] Call trace: [ 37.453188] drm_atomic_helper_wait_for_vblanks.part.27+0x270/0x288 [ 37.453192] drm_atomic_helper_commit_tail_rpm+0x60/0x78 [ 37.453196] commit_tail+0x9c/0x188 [ 37.453199] drm_atomic_helper_commit+0x154/0x168 [ 37.453205] drm_atomic_commit+0x48/0x58 [ 37.453211] drm_client_modeset_commit_atomic.isra.16+0x17c/0x250 [ 37.453215] drm_client_modeset_commit_force+0x58/0x198 [ 37.453221] drm_fb_helper_pan_display+0xa8/0x1d8 [ 37.453229] fb_pan_display+0x88/0xf8 [ 37.453234] bit_update_start+0x1c/0x40 [ 37.453238] fbcon_switch+0x350/0x4f0 [ 37.453243] redraw_screen+0x140/0x268 [ 37.453248] do_bind_con_driver+0x358/0x3a0 [ 37.453252] do_take_over_console+0x140/0x200 [ 37.453256] do_fbcon_takeover+0x68/0xd0 [ 37.453260] fbcon_fb_registered+0x10c/0x120 [ 37.453263] register_framebuffer+0x1f0/0x338 [ 37.453268] __drm_fb_helper_initial_config_and_unlock+0x318/0x4a0 [ 37.453272] drm_fb_helper_hotplug_event.part.23+0xc0/0xd0 [ 37.453276] drm_fbdev_client_hotplug+0x38/0x1a0 [ 37.453280] drm_client_dev_hotplug+0x70/0xb8 [ 37.453286] drm_kms_helper_hotplug_event+0x30/0x40 [ 37.453294] sun6i_dsi_attach+0x7c/0xa0 [sun6i_mipi_dsi] [ 37.453299] mipi_dsi_attach+0x24/0x38 [ 37.453307] feiyang_dsi_probe+0xd8/0x168 [panel_feiyang_fy07024di26a30d] [ 37.453311] mipi_dsi_drv_probe+0x1c/0x28 [ 37.453315] really_probe+0xd8/0x438 [ 37.453318] driver_probe_device+0xdc/0x130 [ 37.453321] device_driver_attach+0x6c/0x78 [ 37.453324] __driver_attach+0x9c/0x168 [ 37.453329] bus_for_each_dev+0x70/0xc0 [ 37.453332] driver_attach+0x20/0x28 [ 37.453336] bus_add_driver+0x190/0x220 [ 37.453339] driver_register+0x60/0x110 [ 37.453343] mipi_dsi_driver_register_full+0x54/0x60 [ 37.453349] feiyang_driver_init+0x1c/0x1000 [panel_feiyang_fy07024di26a30d] [ 37.453355] do_one_initcall+0x74/0x1a8 [ 37.453361] do_init_module+0x50/0x218 [ 37.453364] load_module+0x1d00/0x2018 [ 37.453368] __do_sys_finit_module+0xb0/0x110 [ 37.453371] __arm64_sys_finit_module+0x1c/0x28 [ 37.453377] el0_svc_common.constprop.2+0x88/0x150 [ 37.453381] do_el0_svc+0x20/0x80 [ 37.453385] el0_sync_handler+0x118/0x188 [ 37.453388] el0_sync+0x140/0x180 [ 37.453391] ---[ end trace 748402d57a18dd1e ]--- [ 37.497672] sun4i-drm display-engine: fb0: sun4i-drmdrmfb frame buffer device [ 37.623125] sun6i-mipi-dsi 1ca0000.dsi: Attached device fy07024di26a30d [ 47.589013] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out [ 57.836372] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:50:DSI-1] flip_done timed out [ 68.068997] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:35:plane-1] flip_done timed out I've tried finding other information online (there was a similar issue mentioned by the creator of the driver with a patch, but that patch was not applied to the kernel) but I haven't found nothing more than this... Maybe it's something related to the configuration I've done in the overlay, but it's really similar to the one in the example.... I'm also trying to contact the developer that have created the lcd driver and some patch to enable the dsi on the sun50i-a64 hoping he can help me with those errors. I will let you know if it answer me... If you have some other suggestions or some other ideas to try, is really appreciated Thanks Cheers Mix 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 18, 2020 Author Share Posted May 18, 2020 On 5/17/2020 at 1:36 AM, mix359 said: My daily update (hope this post limit will disappear soon) @Learnincurve Yep, you where right, there was a parameter missing in the overlay, and there wasn't any trace of the panel in the dmesg... Looking around I've found that there is a driver for the Feiyang lcd (thanks for the model information) and also an old example of dt config: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/display/panel/feiyang%2Cfy07024di26a30d.txt So using that, I've created a user dt overlay to use the lcd, here's the code: https://pastebin.com/EAXhSjHL With that overlay enabled, the lcd backlight turned on (hurray... a sign of life!), but show random gray lines, like if the clock is wrong in any way. Also it take a very long time to complete the boot, because of an error that appear multiple times before continue the boot, that talk about vblank timeout. Here's a chunk from the dmesg: Reveal hidden contents [CRTC:41:crtc-0] vblank wait timed out [ 37.453183] Call trace: [ 37.453188] drm_atomic_helper_wait_for_vblanks.part.27+0x270/0x288 [ 37.453192] drm_atomic_helper_commit_tail_rpm+0x60/0x78 [ 37.453196] commit_tail+0x9c/0x188 [ 37.453199] drm_atomic_helper_commit+0x154/0x168 [ 37.453205] drm_atomic_commit+0x48/0x58 [ 37.453211] drm_client_modeset_commit_atomic.isra.16+0x17c/0x250 [ 37.453215] drm_client_modeset_commit_force+0x58/0x198 [ 37.453221] drm_fb_helper_pan_display+0xa8/0x1d8 [ 37.453229] fb_pan_display+0x88/0xf8 [ 37.453234] bit_update_start+0x1c/0x40 [ 37.453238] fbcon_switch+0x350/0x4f0 [ 37.453243] redraw_screen+0x140/0x268 [ 37.453248] do_bind_con_driver+0x358/0x3a0 [ 37.453252] do_take_over_console+0x140/0x200 [ 37.453256] do_fbcon_takeover+0x68/0xd0 [ 37.453260] fbcon_fb_registered+0x10c/0x120 [ 37.453263] register_framebuffer+0x1f0/0x338 [ 37.453268] __drm_fb_helper_initial_config_and_unlock+0x318/0x4a0 [ 37.453272] drm_fb_helper_hotplug_event.part.23+0xc0/0xd0 [ 37.453276] drm_fbdev_client_hotplug+0x38/0x1a0 [ 37.453280] drm_client_dev_hotplug+0x70/0xb8 [ 37.453286] drm_kms_helper_hotplug_event+0x30/0x40 [ 37.453294] sun6i_dsi_attach+0x7c/0xa0 [sun6i_mipi_dsi] [ 37.453299] mipi_dsi_attach+0x24/0x38 [ 37.453307] feiyang_dsi_probe+0xd8/0x168 [panel_feiyang_fy07024di26a30d] [ 37.453311] mipi_dsi_drv_probe+0x1c/0x28 [ 37.453315] really_probe+0xd8/0x438 [ 37.453318] driver_probe_device+0xdc/0x130 [ 37.453321] device_driver_attach+0x6c/0x78 [ 37.453324] __driver_attach+0x9c/0x168 [ 37.453329] bus_for_each_dev+0x70/0xc0 [ 37.453332] driver_attach+0x20/0x28 [ 37.453336] bus_add_driver+0x190/0x220 [ 37.453339] driver_register+0x60/0x110 [ 37.453343] mipi_dsi_driver_register_full+0x54/0x60 [ 37.453349] feiyang_driver_init+0x1c/0x1000 [panel_feiyang_fy07024di26a30d] [ 37.453355] do_one_initcall+0x74/0x1a8 [ 37.453361] do_init_module+0x50/0x218 [ 37.453364] load_module+0x1d00/0x2018 [ 37.453368] __do_sys_finit_module+0xb0/0x110 [ 37.453371] __arm64_sys_finit_module+0x1c/0x28 [ 37.453377] el0_svc_common.constprop.2+0x88/0x150 [ 37.453381] do_el0_svc+0x20/0x80 [ 37.453385] el0_sync_handler+0x118/0x188 [ 37.453388] el0_sync+0x140/0x180 [ 37.453391] ---[ end trace 748402d57a18dd1e ]--- [ 37.497672] sun4i-drm display-engine: fb0: sun4i-drmdrmfb frame buffer device [ 37.623125] sun6i-mipi-dsi 1ca0000.dsi: Attached device fy07024di26a30d [ 47.589013] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out [ 57.836372] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:50:DSI-1] flip_done timed out [ 68.068997] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:35:plane-1] flip_done timed out I've tried finding other information online (there was a similar issue mentioned by the creator of the driver with a patch, but that patch was not applied to the kernel) but I haven't found nothing more than this... Maybe it's something related to the configuration I've done in the overlay, but it's really similar to the one in the example.... I'm also trying to contact the developer that have created the lcd driver and some patch to enable the dsi on the sun50i-a64 hoping he can help me with those errors. I will let you know if it answer me... If you have some other suggestions or some other ideas to try, is really appreciated Thanks Cheers Mix Tried, and failed to send this yesterday: Well done! Sounds like you're making real progress now. Regarding the Feiyang, that driver is now included as a kernel module, so it should be enough to make sure it's loaded. The default resolution is a bit weird. 1024x600 if memory serves me right. I've no idea about the timings tho'. I'm guessing, that as this is now mainline, that the modeline, once we know what it is, can be set in xorg, or maybe needs to be specified as part of the kconfig video mode settings at https://docs.armbian.com/Hardware_Allwinner/ I'm a bit busy today, but will try to take a look when I can. 0 Quote Link to comment Share on other sites More sharing options...
mix359 Posted May 18, 2020 Share Posted May 18, 2020 (edited) I've tried something like this in my boot.cmd/boot.scr: setenv video-mode sunxi:1024x600,monitor=lcd,hpd=0,edid=1 But nothing changed... There's still the error in the dmesg and random image on the screen... Searching on the web about that message I've found this: https://patchwork.freedesktop.org/patch/334084/ This is similar to what's happening to me... but even if it have done this patch, I still get the error... Hoping that Jagan would answer to my email Edited May 18, 2020 by mix359 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 20, 2020 Author Share Posted May 20, 2020 On 5/18/2020 at 9:55 PM, mix359 said: I've tried something like this in my boot.cmd/boot.scr: setenv video-mode sunxi:1024x600,monitor=lcd,hpd=0,edid=1 But nothing changed... There's still the error in the dmesg and random image on the screen... Searching on the web about that message I've found this: https://patchwork.freedesktop.org/patch/334084/ This is similar to what's happening to me... but even if it have done this patch, I still get the error... Hoping that Jagan would answer to my email Gavinb has added DT patches (for sopine) at https://github.com/GavinBa/build/tree/Pine64-V5.4_MIPI_DSI/patch/kernel/sunxi-current You might want to look at the changes to see if anything is missing from your DT. 0 Quote Link to comment Share on other sites More sharing options...
mix359 Posted May 21, 2020 Share Posted May 21, 2020 I've checked the dt patches and I've found out something interesting about the touchscreen that I was missing, but sadly even making in my dt overlay the same change, the screen still show random gray lines... and there's still the same errors in the dmesg caused by the panel_feiyang_fy07024di26a30d driver. I would like to make a little bit of debugging of that driver, but I don't know where to start debugging C code like that.... @Gavinb does the screen work to you with the patch you have done? do you have the "vblank wait timed out" error in dmesg? can I ask you an help debugging the situation? Thanks Cheers 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted May 22, 2020 Author Share Posted May 22, 2020 11 hours ago, mix359 said: I've checked the dt patches and I've found out something interesting about the touchscreen that I was missing, but sadly even making in my dt overlay the same change, the screen still show random gray lines... and there's still the same errors in the dmesg caused by the panel_feiyang_fy07024di26a30d driver. I'm suprised if the driver is buggy as it is in mainline. Did you just load the builtin driver or did you compile Jagan's from C? If you compiled, that could be the problem. BR. 0 Quote Link to comment Share on other sites More sharing options...
mix359 Posted May 23, 2020 Share Posted May 23, 2020 On 5/22/2020 at 8:38 AM, Learnincurve said: I'm suprised if the driver is buggy as it is in mainline. Did you just load the builtin driver or did you compile Jagan's from C? If you compiled, that could be the problem. BR. No, I haven't tried compiling it myself, the driver is the one shipped with the 5.6.12 kernel and I'm surprise too it doesn't work... For that reason I was trying to find what I was doing wrong, but all the changes I'm doing at the moment doesn't seam to change anything on the result: the display always show a random/out of sync image and in the dmesg there always that vblank sync errors. I've also take a look at what as changed in the driver code from the version that is ship with the 5.4.x kernel and the 5.6.x and there's seam to be only refactor done massively to all the panel driver (but I don't know if after that changes someone have tried the driver again). So I can't directly compare with the situation of gavinb, because there's can be some untested changes in the driver that can cause the issue. If you take a look at those driver history on github you can see that the one shipped with the 5.4.x kernel is the one done by Jagan. After that there's many little modification but done massively https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c Sadly I would like to help debugging a bit but from a first look I can't understand what they're doing in the code after the initialization... I'm missing many pieces and can't find a resource online that document the function their are calling and why... Don't know if it's the case to stop trying with the 5.6.x at the moment and switch back to the 5.4.x Cheers Mix 0 Quote Link to comment Share on other sites More sharing options...
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.