linux-kernel - Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1512474815.4977.90.camel@synopsys.com>
Date:   Tue, 5 Dec 2017 11:53:37 +0000
From:   Alexey Brodkin <Alexey.Brodkin@...opsys.com>
To:     Jose Abreu <Jose.Abreu@...opsys.com>
CC:     "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "airlied@...il.com" <airlied@...il.com>,
        "airlied@...hat.com" <airlied@...hat.com>,
        "daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
        "linux-snps-arc@...ts.infradead.org" 
        <linux-snps-arc@...ts.infradead.org>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>
Subject: Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work
 for user-space apps]

Hi Jose,

On Tue, 2017-12-05 at 10:39 +0000, Jose Abreu wrote:
> Hi Alexey,
> 
> On 04-12-2017 17:29, Alexey Brodkin wrote:
> > 
> > 
> > Indeed, in case of kmscube etnaviv is a renderer while UDL
> > outputs the picture on the screen.
> 
> Thats nice :)
> 
> Ok, from your logs I was not able to see anything wrong. X server
> does not error exit and Prime seems to be working in DRM ...
> 
> Lets try one more thing: Enable all debug in DRM (drm.debug=0x3f)
> and try to correlate the log with the actions. i.e.
> 
> [boot]
> [log]
> [x start]
> [log]
> [xclock start]
> [log]
> [glmark2-es2 start]
> [log]

I think I have something like that.

Below are extracts which show at least one difference I was able to find.
And that difference is presence of "[drm:udl_drm_gem_mmap] flags = 0x1"
in case of Xserver only.

kmscube:
-------------------------->8---------------------------
[drm:drm_crtc_helper_set_config] encoder changed, full mode switch
[drm:drm_crtc_helper_set_config] crtc changed, full mode switch
[drm:drm_crtc_helper_set_config] [CONNECTOR:30:DVI-I-1] to [CRTC:28:crtc-0]
[drm:drm_crtc_helper_set_config] attempting to set mode from userspace
[drm:drm_mode_debug_printmodeline] Modeline 44:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[drm:drm_crtc_helper_set_mode] [CRTC:28:crtc-0]
[drm:drm_crtc_helper_set_mode] [ENCODER:29:TMDS-29] set [MODE:44:1920x1080]
[drm] write mode info 153
[drm:drm_crtc_helper_set_config] Setting connector DPMS state to on
[drm:drm_crtc_helper_set_config]        [CONNECTOR:30:DVI-I-1] set DPMS on
[drm:udl_attach_dma_buf] [DEV:soc:gpu-subsystem] size:8355840
[drm:udl_map_dma_buf] [DEV:soc:gpu-subsystem] size:8355840 dir=0
etnaviv-gpu f0090000.gpu: virt 71040000 phys 0x00000000 free 0x00001ec0
stream link to 0x000000a8 @ 0x00002000 71042000
-------------------------->8---------------------------

X:
-------------------------->8---------------------------
[drm:udl_drm_gem_mmap] flags = 0x1
[drm:drm_mode_addfb] [FB:43]
[drm:drm_mode_setcrtc] [CRTC:28:crtc-0]
[drm:drm_mode_setcrtc] [CONNECTOR:30:DVI-I-1]
[drm:drm_crtc_helper_set_config] 
[drm:drm_crtc_helper_set_config] [CRTC:28:crtc-0] [FB:43] #connectors=1 (x y) (0 0)
[drm:drm_crtc_helper_set_config] crtc has no fb, full mode set
[drm:drm_crtc_helper_set_config] connector dpms not on, full mode switch
[drm:drm_crtc_helper_set_config] encoder changed, full mode switch
[drm:drm_crtc_helper_set_config] crtc changed, full mode switch
[drm:drm_crtc_helper_set_config] [CONNECTOR:30:DVI-I-1] to [CRTC:28:crtc-0]
[drm:drm_crtc_helper_set_config] attempting to set mode from userspace
[drm:drm_mode_debug_printmodeline] Modeline 44:"" 0 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x0 0x5
[drm:drm_crtc_helper_set_mode] [CRTC:28:crtc-0]
[drm:drm_crtc_helper_set_mode] [ENCODER:29:TMDS-29] set [MODE:44:]
[drm] write mode info 153
[drm:drm_crtc_helper_set_config] Setting connector DPMS state to on
[drm:drm_crtc_helper_set_config]        [CONNECTOR:30:DVI-I-1] set DPMS on
[drm] write mode info 153
[drm:udl_attach_dma_buf] [DEV:soc:gpu-subsystem] size:8298496
[drm:udl_map_dma_buf] [DEV:soc:gpu-subsystem] size:8298496 dir=0
etnaviv-gpu f0090000.gpu: virt 71040000 phys 0x00000000 free 0x00001ec0
stream link to 0x000001e8 @ 0x00002000 71042000
-------------------------->8---------------------------

> If that does not give any more info then maybe someone with
> better understanding of etnaviv, UDL and X can help


From my note above about udl_drm_gem_mmap() being only used in case of Xserver
I barely may conclude anything. Given my lack of knowledge of DRM guts
especially
when it comes to complicated cases with DMA buffer exports/imports I cannot say
immediately if that's just improper implementation of
udl_drm_gem_mmap() or not.
Even though I do see some differences between implementation of file_operations->mmap()
callback in UDL and
say exynos_drm_gem_mmap() or qxl_mmap() it's not clear
why this and that implementation was done.

> (maybe cc X devel list also ...)

Well at this point I think its purely a UDL driver problem because if we swap UDL to
imx-drm on Wandboard everything works perfectly fine!

-Alexey