Jump to content

mix359

Members
  • Posts

    7
  • Joined

  • Last visited

Posts posted by mix359

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

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

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

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

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

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

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

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines