linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Urja Rannikko <urjaman@gmail.com>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Sean Paul" <seanpaul@chromium.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, "Rob Herring" <robh+dt@kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Boris Brezillon" <boris.brezillon@collabora.com>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Enric Balletbò" <enric.balletbo@collabora.com>,
	"Ezequiel Garcia" <ezequiel@collabora.com>,
	"Matthias Kaehlcke" <mka@chromium.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
Date: Mon, 8 Apr 2019 08:21:14 -0700	[thread overview]
Message-ID: <CAD=FV=VK3ow3PgA9nXiE8+0UdgsGiFbAiZd-QAmCsLHK0Yi2Cg@mail.gmail.com> (raw)
In-Reply-To: <CAPCnQJmWfnBwxj8gScNzmZTGV6eU5B1vk76sQ56A2FvpSiYRaw@mail.gmail.com>

Hi,

On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote:
>
> Hi,
>
> On Mon, Apr 1, 2019 at 5:18 PM Douglas Anderson <dianders@chromium.org> wrote:
> >
> > Let's document the display timings that most veyron chromebooks (like
> > jaq, jerry, mighty, speedy) have been using out in the field.  This
> > uses the standard blankings but a slightly slower clock rate, thus
> > getting a refresh rate 58.3 Hz.
> >
> > NOTE: this won't really do anything except cause DRM to properly
> > report the refresh rate since vop_crtc_mode_fixup() was rounding the
> > pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> > exposed to userspace so it's important that the rate we're trying to
> > achieve is mostly right.
>
> I just thought it would be worth mentioning that I have picked &
> tested a close to 60Hz mode on two veyron speedys of mine, but thought
> it too much effort to try and upstream, especially as it was done as a
> change to the actual panel info:
> https://github.com/urjaman/linux/commit/23d46278911e18df138b7adde1bebc23f606baae
>
> The difference would be in this format just setting hfront-porch = 87
> and vback-porch = 14.
> Anyways the point is: I support moving this mode info into the dts,
> and I'd like to know how if at all should i go about getting a
> 60Hz(ish) mode upstreamed?

I'm a bit torn here.  I like the idea of actually getting 60 Hz and
you also increase the vblank time by a little bit (which means that if
anyone ever gets DDRFreq upstream it will work better).  ...but I'm
also slightly nervous changing something like this without a really
good motivation.  As you said in your commit message the pixels clocks
claimed by the spec don't actually all work and thus, to some extent,
we can only rely on trial-and-error here.  While your new mode works
well on your device (and you wisely gave it a bit of margin), it is
_possible_ that there could be devices out there where it doesn't work
(especially across various temperature extremes).  All devices were
tested in the factory with the old timings and presumably have been
running fine for years like that...

I will certainly admit that it's unlikely devices would be affected,
but at the same time I'd want to know how much of a difference going
from 58.3 Hz to 60 Hz made for you.  Could you actually notice any
visible difference, or was it just nice to be at 60 Hz?


-Doug

  reply	other threads:[~2019-04-08 15:21 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01 17:17 [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree Douglas Anderson
2019-04-01 17:17 ` [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel Douglas Anderson
2019-04-06  6:06   ` Rob Herring
2019-04-08  9:10   ` Boris Brezillon
2019-04-08 10:32   ` Thierry Reding
2019-04-08 14:39     ` Doug Anderson
2019-05-20 18:35       ` Doug Anderson
2019-06-28 23:47   ` Thierry Reding
2019-06-30 20:02   ` Sam Ravnborg
2019-07-01 16:59     ` Doug Anderson
2019-04-01 17:17 ` [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing Douglas Anderson
2019-04-08  9:10   ` Boris Brezillon
2019-06-28 23:49   ` Thierry Reding
2019-06-30 20:22   ` Sam Ravnborg
2019-06-30 20:55     ` Sam Ravnborg
2019-07-01 16:39       ` Doug Anderson
2019-07-08 17:56         ` Sam Ravnborg
2019-07-10 22:56           ` Doug Anderson
2019-07-11 19:16             ` Sean Paul
2019-07-01 16:39     ` Doug Anderson
2019-07-08 17:50       ` Sam Ravnborg
2019-07-10 22:39         ` Doug Anderson
2019-07-11 19:38           ` Sam Ravnborg
2019-04-01 17:17 ` [PATCH v5 3/7] arm64: dts: rockchip: Specify override mode for kevin panel Douglas Anderson
2019-07-11 21:30   ` Heiko Stübner
2019-04-01 17:17 ` [PATCH v5 4/7] drm/panel: simple: Use display_timing for Innolux n116bge Douglas Anderson
2019-06-28 23:50   ` Thierry Reding
2019-04-01 17:17 ` [PATCH v5 5/7] drm/panel: simple: Use display_timing for AUO b101ean01 Douglas Anderson
2019-06-28 23:50   ` Thierry Reding
2019-04-01 17:17 ` [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings Douglas Anderson
2019-04-07  1:15   ` Urja Rannikko
2019-04-08 15:21     ` Doug Anderson [this message]
2019-04-08 16:26       ` Urja Rannikko
2019-04-13  0:07         ` Doug Anderson
2019-07-11 21:27   ` Heiko Stübner
2019-07-11 21:52     ` Heiko Stübner
2019-04-01 17:17 ` [PATCH v5 7/7] ARM: dts: rockchip: Specify rk3288-veyron-minnie's " Douglas Anderson
2019-07-11 21:28   ` Heiko Stübner
2019-06-14 10:39 ` [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree Heiko Stuebner
2019-06-26 13:00 ` Sam Ravnborg
2019-06-26 14:41   ` Doug Anderson
2019-06-28 15:55     ` Doug Anderson
2019-06-28 16:10       ` Rob Herring
2019-06-28 17:13       ` Sam Ravnborg
2019-06-29 14:09         ` Heiko Stübner
2019-07-08 15:58           ` Doug Anderson
2019-07-11 19:35             ` Sam Ravnborg

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='CAD=FV=VK3ow3PgA9nXiE8+0UdgsGiFbAiZd-QAmCsLHK0Yi2Cg@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=boris.brezillon@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=enric.balletbo@collabora.com \
    --cc=ezequiel@collabora.com \
    --cc=heiko@sntech.de \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=mka@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=seanpaul@chromium.org \
    --cc=thierry.reding@gmail.com \
    --cc=urjaman@gmail.com \
    /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).