All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrzej Hajda <a.hajda@samsung.com>
To: Jose Abreu <Jose.Abreu@synopsys.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	Carlos Palminha <CARLOS.PALMINHA@synopsys.com>
Subject: Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback
Date: Thu, 27 Apr 2017 12:05:25 +0200	[thread overview]
Message-ID: <978d1c10-a498-eeb3-a5ab-5a417a7fb209@samsung.com> (raw)
In-Reply-To: <3e1dba0cd5fc053e56f1c9c94d0cb8789ecca4ae.1493203049.git.joabreu@synopsys.com>

Hi Jose,

On 26.04.2017 12:48, Jose Abreu wrote:
> Some crtc's may have restrictions in the mode they can display. In
> this patch a new callback (crtc->mode_valid()) is introduced that
> is called at the same stage of connector->mode_valid() callback.
>
> This shall be implemented if the crtc has some sort of restriction
> so that we don't probe modes that will fail in the commit() stage.
> For example: A given crtc may be responsible to set a clock value.
> If the clock can not produce all the values for the available
> modes then this callback can be used to restrict the number of
> probbed modes to only the ones that can be displayed.
>
> If the crtc does not implement the callback then the behaviour will
> remain the same. Also, for a given set of crtcs that can be bound to
> the connector, if at least one can display the mode then the mode
> will be probbed.

I see few possible issues/improvements here:
1. crtc can have different constraints depending on the encoder it is
connected to, theoretically reverse dependency is also possible, but I
am not aware of such hw.
2. there also could be similar dependency constrains between connector
and encoder, I guess.
3. encoders and bridges should have also possibility to validate modes,
they also have constrains, btw encoder_slave have such callback.

Regarding 1st and 2nd point, maybe it would be good to validate modes
according to topology described in drm_mode_get_connector::encoder_id
and drm_mode_get_encoder::crtc_id:
a) if connector is not connected to any encoder report to userspace
modes filtered only by connector::mode_valid,
b) if connector is connected to encoder, report modes filtered by
connector, encoder and attached bridges,
c) if full pipeline is constructed, report modes filtered by all members
of the pipeline.

Of course with this approach drm_mode_get_connector userspace should be
aware of the fact that it should re-call drm_mode_get_connector after
topology change to update supported modes.

Regards
Andrzej

WARNING: multiple messages have this Message-ID (diff)
From: Andrzej Hajda <a.hajda@samsung.com>
To: Jose Abreu <Jose.Abreu@synopsys.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	Carlos Palminha <CARLOS.PALMINHA@synopsys.com>
Subject: Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback
Date: Thu, 27 Apr 2017 12:05:25 +0200	[thread overview]
Message-ID: <978d1c10-a498-eeb3-a5ab-5a417a7fb209@samsung.com> (raw)
In-Reply-To: <3e1dba0cd5fc053e56f1c9c94d0cb8789ecca4ae.1493203049.git.joabreu@synopsys.com>

Hi Jose,

On 26.04.2017 12:48, Jose Abreu wrote:
> Some crtc's may have restrictions in the mode they can display. In
> this patch a new callback (crtc->mode_valid()) is introduced that
> is called at the same stage of connector->mode_valid() callback.
>
> This shall be implemented if the crtc has some sort of restriction
> so that we don't probe modes that will fail in the commit() stage.
> For example: A given crtc may be responsible to set a clock value.
> If the clock can not produce all the values for the available
> modes then this callback can be used to restrict the number of
> probbed modes to only the ones that can be displayed.
>
> If the crtc does not implement the callback then the behaviour will
> remain the same. Also, for a given set of crtcs that can be bound to
> the connector, if at least one can display the mode then the mode
> will be probbed.

I see few possible issues/improvements here:
1. crtc can have different constraints depending on the encoder it is
connected to, theoretically reverse dependency is also possible, but I
am not aware of such hw.
2. there also could be similar dependency constrains between connector
and encoder, I guess.
3. encoders and bridges should have also possibility to validate modes,
they also have constrains, btw encoder_slave have such callback.

Regarding 1st and 2nd point, maybe it would be good to validate modes
according to topology described in drm_mode_get_connector::encoder_id
and drm_mode_get_encoder::crtc_id:
a) if connector is not connected to any encoder report to userspace
modes filtered only by connector::mode_valid,
b) if connector is connected to encoder, report modes filtered by
connector, encoder and attached bridges,
c) if full pipeline is constructed, report modes filtered by all members
of the pipeline.

Of course with this approach drm_mode_get_connector userspace should be
aware of the fact that it should re-call drm_mode_get_connector after
topology change to update supported modes.

Regards
Andrzej

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-04-27 10:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26 10:48 [PATCH 0/2] Introduce crtc->mode_valid() callback Jose Abreu
2017-04-26 10:48 ` [PATCH 1/2] drm: " Jose Abreu
2017-04-27 10:05   ` Andrzej Hajda [this message]
2017-04-27 10:05     ` Andrzej Hajda
2017-04-27 12:34     ` Jose Abreu
2017-04-27 12:34       ` Jose Abreu
2017-04-28 11:41   ` Ville Syrjälä
2017-04-28 11:41     ` Ville Syrjälä
2017-04-28 12:30     ` Jose Abreu
2017-04-28 12:30       ` Jose Abreu
2017-04-28 12:58       ` Ville Syrjälä
2017-04-28 12:58         ` Ville Syrjälä
2017-05-02  8:48   ` Daniel Vetter
2017-05-02  8:48     ` Daniel Vetter
2017-05-02  9:29     ` Jose Abreu
2017-05-03  6:19       ` Daniel Vetter
2017-05-03  6:19         ` Daniel Vetter
2017-05-03  6:19       ` Daniel Vetter
2017-05-03  6:19         ` Daniel Vetter
2017-05-03 14:16         ` Jose Abreu
2017-05-03 15:00           ` Daniel Vetter
2017-05-03 15:00             ` Daniel Vetter
2017-05-03 15:21             ` Ville Syrjälä
2017-05-03 15:21               ` Ville Syrjälä
2017-05-04 12:49               ` Daniel Vetter
2017-05-04 12:49                 ` Daniel Vetter
2017-05-04 13:08                 ` Ville Syrjälä
2017-05-04 13:08                   ` Ville Syrjälä
2017-05-04 10:21             ` Jose Abreu
2017-05-04 11:55               ` Jose Abreu
2017-05-04 12:48                 ` Daniel Vetter
2017-05-04 12:48                   ` Daniel Vetter
2017-04-26 10:48 ` [PATCH 2/2] drm: arcpgu: Use " Jose Abreu

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=978d1c10-a498-eeb3-a5ab-5a417a7fb209@samsung.com \
    --to=a.hajda@samsung.com \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=CARLOS.PALMINHA@synopsys.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.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.