Jump to content

Recommended Posts

Posted

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.

Posted

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!

 

 

Posted

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.

 

Posted

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.

Posted

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.

 

Posted
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?

Posted

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.

Posted
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).

Posted

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...

Posted

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

Posted
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!

Posted

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.

Posted

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

Posted
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?

Posted

My daily update :D (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

Posted
On 5/17/2020 at 1:36 AM, mix359 said:

My daily update :D (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.

Posted (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 by mix359
Posted

 

 

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.

Posted

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

Posted
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.

Posted
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.

IMB-XAt-UKs.gif

 

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

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines