All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Sebastian Reichel <sebastian.reichel@collabora.co.uk>,
	Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	devicetree@vger.kernel.org, linux-omap@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kernel@collabora.com
Subject: Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays
Date: Fri, 20 Apr 2018 07:25:33 -0700	[thread overview]
Message-ID: <20180420142533.GN5671@atomide.com> (raw)
In-Reply-To: <CAPj87rPeBim9NyBmMuDKKEwx2apLhdnZyEB9_sfbVQpUHA95+Q@mail.gmail.com>

Hi,

* Daniel Stone <daniel@fooishbar.org> [180420 10:21]:
> Hi Tomi,
> 
> On 20 April 2018 at 08:09, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > It's actually not quite clear to me how manual update displays work with
> > DRM...
> >
> > As far as I see, we have essentially two cases: 1) single buffering,
> > where the userspace must set an area in the fb dirty, which then
> > triggers the update, 2) multi buffering, which doesn't need fb dirty,
> > but just a page flip which triggers the update.
> >
> > In the 2) case (which I think is the optimal case which all the modern
> > apps should use), there's no need for delayed work or any work, and the
> > code flow should be very similar to the auto-update model.
> 
> Correct. There's been talk (and I think patches?) of adding a
> per-plane dirty property, so userspace can as an optimisation inform
> the kernel of the area changed between frames. But short of that, a
> pageflip needs to trigger a full-plane update, with no dirtyfb
> required.

For per-plane dirty property patches, which ones do you refer to?

Then for xorg, there's my second attempt on fixing the command mode
rotation at [0]. Not sure if that's enough for a fix?

It seems not very efficient to me and I don't really know where
the the per crtc dirty flag should be stored..

I can easily test patches though with a command mode LCD and normal
HDMI setup on droid 4.

Regards,

Tony

[0] https://lists.x.org/archives/xorg-devel/2018-February/055890.html

  reply	other threads:[~2018-04-20 14:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30 17:18 [PATCHv3 0/8] omapdrm: DSI command mode panel support Sebastian Reichel
2018-03-30 17:18 ` [PATCHv3 1/8] drm/omap: add framedone interrupt support Sebastian Reichel
2018-03-30 17:18 ` [PATCHv3 2/8] drm/omap: add manual update detection helper Sebastian Reichel
2018-03-30 17:18 ` [PATCHv3 3/8] drm/omap: add support for manually updated displays Sebastian Reichel
2018-04-20  7:09   ` Tomi Valkeinen
2018-04-20  7:09     ` Tomi Valkeinen
2018-04-20  8:11     ` Daniel Vetter
2018-04-20  8:11       ` Daniel Vetter
2018-04-20 10:19     ` Daniel Stone
2018-04-20 10:19       ` Daniel Stone
2018-04-20 14:25       ` Tony Lindgren [this message]
2018-04-20 14:39         ` Daniel Stone
2018-04-20 14:44           ` Tony Lindgren
2018-03-30 17:18 ` [PATCHv3 4/8] drm/omap: make omap_framebuffer_get_next_connector static Sebastian Reichel
2018-03-30 17:18 ` [PATCHv3 5/8] dt-bindings: panel: common: document orientation property Sebastian Reichel
2018-04-03 10:49   ` Pavel Machek
2018-04-09 20:29   ` Rob Herring
2018-04-09 20:29     ` Rob Herring
2018-03-30 17:18 ` [PATCHv3 6/8] drm/omap: add support for rotation hints from display drivers Sebastian Reichel
2018-03-30 17:18 ` [PATCHv3 7/8] drm/omap: panel-dsi-cm: add rotation support Sebastian Reichel
2018-04-03 10:49   ` Pavel Machek
2018-04-03 10:49     ` Pavel Machek
2018-03-30 17:18 ` [PATCHv3 8/8] ARM: dts: omap4-droid4: Add LCD panel rotation property Sebastian Reichel
2018-04-03 10:49   ` Pavel Machek
2018-04-03 10:49     ` Pavel Machek

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=20180420142533.GN5671@atomide.com \
    --to=tony@atomide.com \
    --cc=daniel@fooishbar.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.reichel@collabora.co.uk \
    --cc=sre@kernel.org \
    --cc=tomi.valkeinen@ti.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 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.