All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Jyri Sarha <jsarha@ti.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node
Date: Tue, 17 Apr 2018 17:37:25 +0300	[thread overview]
Message-ID: <e125d692-62b9-936c-bd04-84e7eb0072f7@ti.com> (raw)
In-Reply-To: <CAL_JsqKm6L_66RYJ6JQJfMLA073QyBtP0U+JBkA+m0e34QJWcg@mail.gmail.com>

Hi Rob,

On 09/04/18 21:17, Rob Herring wrote:

>>> For HDMI, you can't know in advance what resolution will be. So I
>>> think you always need to reserve 2 planes. Now, if you want to reduce
>>
>> We can decide not to support 2k+ resolutions for HDMI, which, with this
>> series, happens by not reserving dual-plane for the HDMI.
> 
> Right. So turn this around. Define in DT what is the maximum
> resolution supported for HDMI and configure the planes based on that.

But the kernel cannot know what the user wants to do, so it cannot
configure the planes. If we have an HDMI output which supports 2k+ and a
-2k LCD, and 4 hw planes, we can set up the planes at least in the
following ways:

- One virtual plane on HDMI, two normal planes on LCD. Here the normal
planes can also be used on the HDMI, as long as the input width is -2k.

- One virtual plane on HDMI, one virtual plane on LCD, but sometimes
both planes on the same display (either HDMI or LCD).

- No virtual planes (and fbdev support disabled). This needs the
userspace to take care not to configure 2k+ planes. But considering that
the modes supported are still quit close to 2k in width, I believe
upscaling a 2k plane cover the whole display would provide quite ok image.

Each of those requires a different virtual plane setup.

>> But reserve how many of the planes? We have N planes and M displays. For
>> some of the displays we know they're 2k+, some are known to be -2k and
>> some are unknown. The driver can't independently make any sensible
>> static reservation of the planes for the displays, because it doesn't
>> know what the user wants to do.
> 
> After you've handled HDMI as above and any permanently attached panels
> with fixed resolutions, what is left for a user to configure? Perhaps
> only one display can support an overlay at that point because you are
> out of planes?

I think I covered this in the example use cases above.

>> So either we reserve the extra planes at runtime on demand, making it
>> difficult to manage for the userspace, or we rely on the user to give
>> the driver a static partitioning of the planes according to the user's
>> use case.
> 
> And by user, who do you mean exactly? The use case is tied to the
> board design and product or tied to the whims of an end user (e.g. I
> want to do video playback with overlay to disp 2)? You should equate
> users making DT changes with telling users to update/change their
> BIOS.

By user I mean the owner of the device, but it in some cases it could be
the vendor too.

If we have a board with HDMI that can support 2k+, then the board vendor
could provide DT files that do not specify virtual planes (so no 2k+),
but give instructions how to define them for the users who want 2k+. So
here the end user needs to deal with the static partitioning.

If we have a board with a fixed resolution 2k+ LCD, then the vendor has
to have a virtual plane defined in the DT, and the vendor has to pick a
configuration that it thinks is most useful.

And yes, it sucks to have to make changes in the DT or BIOS, but I still
don't see a (good) alternative.

I think one option is to have the detailed DT configuration optional:

We'd have a flag in the DT to mark that a display supports 2k+ (or the
max-resolution property as you suggested). Based on that, the driver
guesses what kind of setup the user wants, which probably is just to set
up planes in a way that each display has a fully functional "root"
plane, and then split the remaining ones in some way.

But the user could also have detailed DT descriptions for the planes
when he needs a more special setup.

 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-17 14:37 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 [this message]
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
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=e125d692-62b9-936c-bd04-84e7eb0072f7@ti.com \
    --to=tomi.valkeinen@ti.com \
    --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.