All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: devicetree@vger.kernel.org, Jyri Sarha <jsarha@ti.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Rob Herring <robh+dt@kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node
Date: Fri, 20 Apr 2018 10:21:35 +0300	[thread overview]
Message-ID: <5efc8763-7ab8-5f4e-de40-95e2671e2af3@ti.com> (raw)
In-Reply-To: <20180420070025.GE31310@phenom.ffwll.local>

On 20/04/18 10:00, Daniel Vetter wrote:

(Adding Benoit back, he was dropped at some point in the thread)

> Stuff randomly not working is officially how atomic works. That's what the
> TEST_ONLY mode is for. There's a lot more than virtualized planes that
> might or might not push any given plane setup over some random hw limit:
> memory bandwidth, aggregate scaling limits (because not enough fifo),
> thermal limits, aggregate pixel clock limits. There's all kinds of cases
> where with one setup you can light up 4 planes, then move them a bit and
> only 3 work. And yes sometimes that means you can't light up all the
> outputs if you have a too fancy plane config on the other CRTC.
> 
> Only userspace which is written with intimate knowledge of the exact
> kernel driver and hw it runs on can avoid TEST_ONLY and some kind of
> fallback strategy to "render everything into the 1 single primary plane".
> Both drm_hwcomposer and weston atomic have such a fallback strategy (with
> various degrees of intermediate cleverness).

Ok, thanks. This makes sense to me, and actually makes our (driver
developers) life easier... Is "Stuff randomly not working is officially
how atomic works." mentioned in the DRM documentation? I think that
sentence summarizes it quite well =).

Does the driver still have some minimal set of functionality it always
has to allow? E.g. is enabling all the available displays with the
display's native resolution (or whatever passes the mode_valid), each
with a single non-scaled full-screen primary plane, something every
driver should ensure is always possible?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-04-20  7:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02 13:48 [Patch 0/4] drm/omap: Add virtual-planes support Benoit Parrot
2018-03-02 13:48 ` [Patch 1/4] dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt Benoit Parrot
2018-03-07 20:26   ` Rob Herring
2018-03-02 13:48 ` [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node Benoit Parrot
2018-03-02 19:19   ` Rob Herring
2018-03-09 18:27     ` Benoit Parrot
2018-03-14 11:23       ` Tomi Valkeinen
2018-03-19  0:06         ` Rob Herring
2018-03-19  7:15           ` Tomi Valkeinen
2018-03-23  1:23             ` Rob Herring
2018-03-23  7:53               ` Tomi Valkeinen
2018-04-09 18:17                 ` Rob Herring
2018-04-17 14:37                   ` Tomi Valkeinen
2018-04-19  6:34                     ` Daniel Vetter
2018-04-19  7:11                       ` Tomi Valkeinen
2018-04-20  7:00                         ` Daniel Vetter
2018-04-20  7:21                           ` Tomi Valkeinen [this message]
2018-04-20  8:08                             ` Daniel Vetter
2018-03-02 13:48 ` [Patch 3/4] drm/omap: Add virtual plane DT parsing support Benoit Parrot
2018-03-14 11:11   ` Tomi Valkeinen
2018-03-02 13:48 ` [Patch 4/4] drm/omap: Add virtual plane support to omap_plane Benoit Parrot
2018-03-14 11:56   ` Tomi Valkeinen

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=5efc8763-7ab8-5f4e-de40-95e2671e2af3@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh+dt@kernel.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 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.