Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752466AbdLELxp (ORCPT ); Tue, 5 Dec 2017 06:53:45 -0500 Received: from smtprelay.synopsys.com ([198.182.60.111]:51216 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752149AbdLELxm (ORCPT ); Tue, 5 Dec 2017 06:53:42 -0500 From: Alexey Brodkin To: Jose Abreu CC: "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "airlied@gmail.com" , "airlied@redhat.com" , "daniel.vetter@ffwll.ch" , "linux-snps-arc@lists.infradead.org" , "l.stach@pengutronix.de" Subject: Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps] Thread-Topic: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps] Thread-Index: AQHTbQIkipqBBGWFjUqX7bL3/pGn26MzJlIAgAAOOwCAABFCAIAAAXWAgAAXkICAAAFZAIABH6mAgAAUvoA= Date: Tue, 5 Dec 2017 11:53:37 +0000 Message-ID: <1512474815.4977.90.camel@synopsys.com> References: <1512387175.4977.24.camel@synopsys.com> <86238def-82be-2ad1-63d0-b9a8dbf83db6@synopsys.com> <1512393408.4977.44.camel@synopsys.com> <1512399218.4977.48.camel@synopsys.com> <1512403237.4977.54.camel@synopsys.com> <232eae49-ddbb-fd87-2b35-6db47817e23e@synopsys.com> <1512408586.4977.73.camel@synopsys.com> In-Reply-To: Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.225.15.245] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vB5Bro4g012152 Content-Length: 4196 Lines: 100 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