From: Brian Masney <masneyb@onstation.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
MSM <linux-arm-msm@vger.kernel.org>,
freedreno@lists.freedesktop.org, Dave Airlie <airlied@linux.ie>,
Daniel Vetter <daniel@ffwll.ch>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jonathan Marek <jonathan@marek.ca>, Rob Herring <robh@kernel.org>
Subject: Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
Date: Wed, 29 May 2019 05:41:52 -0400 [thread overview]
Message-ID: <20190529094152.GB13436@basecamp> (raw)
In-Reply-To: <CACRpkdZu5KxKTMqAM5rueWbrXbfPNorOOerezCAA3vgAR6cD5g@mail.gmail.com>
On Wed, May 29, 2019 at 08:23:17AM +0200, Linus Walleij wrote:
> On Wed, May 29, 2019 at 3:17 AM Brian Masney <masneyb@onstation.org> wrote:
>
> > It's in low speed mode but its usable.
>
> How low speed is that?
I don't have a number but my test with 4.17 is to run
'cat /etc/passwd > /dev/tty1' over a serial cable. The first 2-3 calls
will fill up the screen and the file contents appear to show up on the
screen immediately to the human eye. The next time that I run it
requires scrolling the entire console and there is a small fraction of
a second where I see the entire framebuffer contents scroll up. I
don't have a graphics background, but I believe that this is the
tearing effect that I'm seeing based on what I've read. I believe that
disp-te-gpios can be used to mitigate this tearing effect. I have a few
questions about this later once we get the basic display working.
> > I assume that it's related to the
> > vblank events not working properly?
>
> They are only waiting for 50 ms before timing out, I raised it
> to 100ms in the -next kernel. I'm still suspicious about this
> even though I think you said this was not the problem.
>
> For a command mode panel in LP mode it will nevertheless
> be more than 100ms for sure, the update is visible to the
> naked eye.
>
> Raise it to 10000 ms or something and see what happens.
> drivers/gpu/drm/drm_atomic_helper.c:
> msecs_to_jiffies(50)
I previously raised those timeouts as high as 5 seconds and it still
has the same issue. Writing to /dev/tty1 can take anywhere between a few
seconds to 30 seconds or more.
Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Masney <masneyb-1iNe0GrtECGEi8DpZVb4nw@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Sean Paul <sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org>,
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Jonathan Marek <jonathan-eSc4qw6YbEQ@public.gmane.org>,
Dave Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
MSM <linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"open list:DRM PANEL DRIVERS"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
Date: Wed, 29 May 2019 05:41:52 -0400 [thread overview]
Message-ID: <20190529094152.GB13436@basecamp> (raw)
In-Reply-To: <CACRpkdZu5KxKTMqAM5rueWbrXbfPNorOOerezCAA3vgAR6cD5g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, May 29, 2019 at 08:23:17AM +0200, Linus Walleij wrote:
> On Wed, May 29, 2019 at 3:17 AM Brian Masney <masneyb@onstation.org> wrote:
>
> > It's in low speed mode but its usable.
>
> How low speed is that?
I don't have a number but my test with 4.17 is to run
'cat /etc/passwd > /dev/tty1' over a serial cable. The first 2-3 calls
will fill up the screen and the file contents appear to show up on the
screen immediately to the human eye. The next time that I run it
requires scrolling the entire console and there is a small fraction of
a second where I see the entire framebuffer contents scroll up. I
don't have a graphics background, but I believe that this is the
tearing effect that I'm seeing based on what I've read. I believe that
disp-te-gpios can be used to mitigate this tearing effect. I have a few
questions about this later once we get the basic display working.
> > I assume that it's related to the
> > vblank events not working properly?
>
> They are only waiting for 50 ms before timing out, I raised it
> to 100ms in the -next kernel. I'm still suspicious about this
> even though I think you said this was not the problem.
>
> For a command mode panel in LP mode it will nevertheless
> be more than 100ms for sure, the update is visible to the
> naked eye.
>
> Raise it to 10000 ms or something and see what happens.
> drivers/gpu/drm/drm_atomic_helper.c:
> msecs_to_jiffies(50)
I previously raised those timeouts as high as 5 seconds and it still
has the same issue. Writing to /dev/tty1 can take anywhere between a few
seconds to 30 seconds or more.
Brian
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
next prev parent reply other threads:[~2019-05-29 9:41 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-09 2:03 [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support Brian Masney
2019-05-09 2:03 ` [PATCH v2 1/6] drm: msm: remove resv fields from msm_gem_object struct Brian Masney
2019-05-13 20:32 ` Bjorn Andersson
2019-05-13 22:25 ` Brian Masney
2019-05-09 2:03 ` [PATCH RFC v2 2/6] drm: msm: add dirty framebuffer helper Brian Masney
2019-05-09 2:03 ` [PATCH v2 3/6] ARM: qcom_defconfig: add display-related options Brian Masney
2019-05-09 2:03 ` Brian Masney
2019-05-09 2:03 ` [PATCH v2 4/6] ARM: dts: msm8974: add display support Brian Masney
2019-05-09 2:03 ` Brian Masney
2019-05-09 2:03 ` [PATCH v2 5/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight Brian Masney
2019-05-09 2:03 ` Brian Masney
2019-05-09 2:03 ` [PATCH v2 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display Brian Masney
2019-05-09 2:03 ` Brian Masney
2019-05-09 2:06 ` [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support Brian Masney
2019-05-09 2:06 ` Brian Masney
2019-05-28 13:46 ` Linus Walleij
2019-05-29 1:17 ` Brian Masney
2019-05-29 1:32 ` [Freedreno] " Jeffrey Hugo
2019-05-29 1:32 ` Jeffrey Hugo
2019-05-29 1:37 ` [Freedreno] " Brian Masney
2019-05-29 1:42 ` Jeffrey Hugo
2019-05-29 2:46 ` Brian Masney
2019-05-29 2:46 ` Brian Masney
[not found] ` <CAOCk7NpC93ACr4jFm7SBOKSvFJSDhq2byX6BAYPX29BuYEkWnQ@mail.gmail.com>
[not found] ` <CAOCk7NpC93ACr4jFm7SBOKSvFJSDhq2byX6BAYPX29BuYEkWnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-29 10:28 ` Brian Masney
2019-05-29 10:28 ` [Freedreno] " Brian Masney
2019-05-29 14:41 ` Jeffrey Hugo
2019-05-29 19:30 ` Brian Masney
2019-05-29 19:58 ` Jeffrey Hugo
2019-05-29 21:54 ` Brian Masney
2019-05-29 21:54 ` Brian Masney
2019-05-29 2:14 ` Rob Clark
2019-05-29 2:24 ` [Freedreno] " Jeffrey Hugo
2019-05-29 6:23 ` Linus Walleij
2019-05-29 9:41 ` Brian Masney [this message]
2019-05-29 9:41 ` Brian Masney
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=20190529094152.GB13436@basecamp \
--to=masneyb@onstation.org \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jonathan@marek.ca \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=robh@kernel.org \
--cc=sean@poorly.run \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.