From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"airlied@gmail.com" <airlied@gmail.com>,
"airlied@redhat.com" <airlied@redhat.com>,
"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"l.stach@pengutronix.de" <l.stach@pengutronix.de>
Subject: Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Date: Tue, 5 Dec 2017 11:53:37 +0000 [thread overview]
Message-ID: <1512474815.4977.90.camel@synopsys.com> (raw)
In-Reply-To: <c49275d9-6cb3-c6ab-15c8-c18e5a8bc0b0@synopsys.com>
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
next prev parent reply other threads:[~2017-12-05 11:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 11:32 UDL's fbdev doesn't work for user-space apps Alexey Brodkin
2017-12-04 11:50 ` Jose Abreu
2017-12-04 13:16 ` xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps] Alexey Brodkin
2017-12-04 14:02 ` Jose Abreu
2017-12-04 14:53 ` Alexey Brodkin
2017-12-04 15:55 ` Jose Abreu
2017-12-04 16:00 ` Alexey Brodkin
2017-12-04 17:24 ` Jose Abreu
2017-12-04 17:29 ` Alexey Brodkin
2017-12-05 10:39 ` Jose Abreu
2017-12-05 11:53 ` Alexey Brodkin [this message]
2017-12-05 12:26 ` Jose Abreu
2017-12-05 14:47 ` Alexey Brodkin
2017-12-04 17:52 ` Emil Velikov
2017-12-09 17:20 ` UDL's fbdev doesn't work for user-space apps Pavel Machek
2017-12-12 19:48 ` Alexey Brodkin
2017-12-12 21:12 ` Pavel Machek
2017-12-12 21:58 ` Noralf Trønnes
2017-12-13 21:53 ` Alexey Brodkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1512474815.4977.90.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=Jose.Abreu@synopsys.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=l.stach@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).