drm: call connector->dpms(OFF) when disabling

Message ID 1348817238-30228-1-git-send-email-rob.clark@linaro.org
State New
Headers show

Commit Message

Rob Clark Sept. 28, 2012, 7:27 a.m.
From: Rob Clark <rob@ti.com>

When disabling unused connectors, be sure to call connector->dpms(OFF),
so if there is actually some IP to turn off (such as external bridge
chips, etc), these actually do get turned off.

Signed-off-by: Rob Clark <rob@ti.com>
Tested-by: Roger Quadros <rogerq@ti.com>

---
 drivers/gpu/drm/drm_crtc_helper.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Daniel Vetter Sept. 28, 2012, 9:56 a.m. | #1
On Fri, Sep 28, 2012 at 09:27:18AM +0200, Rob Clark wrote:
> From: Rob Clark <rob@ti.com>
> 
> When disabling unused connectors, be sure to call connector->dpms(OFF),
> so if there is actually some IP to turn off (such as external bridge
> chips, etc), these actually do get turned off.
> 
> Signed-off-by: Rob Clark <rob@ti.com>
> Tested-by: Roger Quadros <rogerq@ti.com>

I think this runs counter to the crtc helper design: connectors are pretty
much just dummy entities, and any dpms handling is done in the
encoders/crtcs. If you call connector->funcs->dpms you don't call a crtc
helper function, but actually the official dpms interface (which then
again calls down into the encoder/crtc dpms callbacks (which are again
crtc helper private). This functions are called again a few lines down in
disable_unused_functions anyway, so the only way this changes behaviour is
if you already overwrite the dpms interface and don't directly use
drm_helper_connector_dpms.

Which is imo a clear sign that the crtc helper is a misfit for your hw and
you should stop using it ;-) And adding special-case handling like this
into common code, especially if it weakens the semantic concepts in the
helper layer is a recipe for a maintainance disaster a few years down the
road. Hence

NACKed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Cheers, Daniel
> 
> ---
>  drivers/gpu/drm/drm_crtc_helper.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
> index 3252e70..000cda4 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -244,16 +244,16 @@ void drm_helper_disable_unused_functions(struct drm_device *dev)
>  	struct drm_crtc *crtc;
>  
>  	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> -		if (!connector->encoder)
> -			continue;
>  		if (connector->status == connector_status_disconnected)
>  			connector->encoder = NULL;
> +		if (!connector->encoder)
> +			connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
>  	}
>  
>  	list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
>  		if (!drm_helper_encoder_in_use(encoder)) {
>  			drm_encoder_disable(encoder);
> -			/* disconnector encoder from any connector */
> +			/* disconnect encoder from any connector */
>  			encoder->crtc = NULL;
>  		}
>  	}
> -- 
> 1.7.9.5
> 
> _______________________________________________
> dri-devel mailing list
> 
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Rob Clark Sept. 28, 2012, 10:54 a.m. | #2
On Fri, Sep 28, 2012 at 11:56 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Sep 28, 2012 at 09:27:18AM +0200, Rob Clark wrote:
>> From: Rob Clark <rob@ti.com>
>>
>> When disabling unused connectors, be sure to call connector->dpms(OFF),
>> so if there is actually some IP to turn off (such as external bridge
>> chips, etc), these actually do get turned off.
>>
>> Signed-off-by: Rob Clark <rob@ti.com>
>> Tested-by: Roger Quadros <rogerq@ti.com>
>
> I think this runs counter to the crtc helper design: connectors are pretty
> much just dummy entities, and any dpms handling is done in the
> encoders/crtcs. If you call connector->funcs->dpms you don't call a crtc
> helper function, but actually the official dpms interface (which then
> again calls down into the encoder/crtc dpms callbacks (which are again
> crtc helper private). This functions are called again a few lines down in
> disable_unused_functions anyway, so the only way this changes behaviour is
> if you already overwrite the dpms interface and don't directly use
> drm_helper_connector_dpms.

yeah, I do this.. I have my own fxn in the connector which does some
stuff, and then calls drm_helper_connector_dpms().

Maybe it just makes sense to always do connector->dpms(OFF) before
unhooking the chain, rather than directly calling dpms on the
encoder/crtc?

> Which is imo a clear sign that the crtc helper is a misfit for your hw and
> you should stop using it ;-) And adding special-case handling like this
> into common code, especially if it weakens the semantic concepts in the
> helper layer is a recipe for a maintainance disaster a few years down the
> road. Hence

well, I think by the time we start adding atomic-modeset and
common/dsi panel framework, there might be need for a new set of
helpers.. but I'm not sure that the hw is quite strange enough to need
an omap specific set of helpers.  Maybe I start w/ something in
omapdrm but then refactor into common functions once a few drivers are
converted to atomic modeset and panel framework.

BR,
-R

>
> NACKed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Cheers, Daniel
>>
>> ---
>>  drivers/gpu/drm/drm_crtc_helper.c |    6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
>> index 3252e70..000cda4 100644
>> --- a/drivers/gpu/drm/drm_crtc_helper.c
>> +++ b/drivers/gpu/drm/drm_crtc_helper.c
>> @@ -244,16 +244,16 @@ void drm_helper_disable_unused_functions(struct drm_device *dev)
>>       struct drm_crtc *crtc;
>>
>>       list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
>> -             if (!connector->encoder)
>> -                     continue;
>>               if (connector->status == connector_status_disconnected)
>>                       connector->encoder = NULL;
>> +             if (!connector->encoder)
>> +                     connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
>>       }
>>
>>       list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
>>               if (!drm_helper_encoder_in_use(encoder)) {
>>                       drm_encoder_disable(encoder);
>> -                     /* disconnector encoder from any connector */
>> +                     /* disconnect encoder from any connector */
>>                       encoder->crtc = NULL;
>>               }
>>       }
>> --
>> 1.7.9.5
>>
>> _______________________________________________
>> dri-devel mailing list
>>
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Daniel Vetter Sept. 28, 2012, 11:55 a.m. | #3
On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark <rob.clark@linaro.org> wrote:
> Maybe it just makes sense to always do connector->dpms(OFF) before
> unhooking the chain, rather than directly calling dpms on the
> encoder/crtc?

Well, that makes the entire (optional) ->disable stuff a bit more
awkward. The thing imo really is that the crtc helper assume that the
connectors do not hold any hw state, whereas you're omap driver
violates that assumption.

For the intel driver we've fixed this by doing any sink handling (e.g.
for dp) in the encoder->dpms functions. So I think the right way for
omap is to do the same (or conclude that the crtc helpers are a bad
fit and ditch them). Having connectors that are special, but only in
some of the cases imo makes squat sense for a generic helper library.

>> Which is imo a clear sign that the crtc helper is a misfit for your hw and
>> you should stop using it ;-) And adding special-case handling like this
>> into common code, especially if it weakens the semantic concepts in the
>> helper layer is a recipe for a maintainance disaster a few years down the
>> road. Hence
>
> well, I think by the time we start adding atomic-modeset and
> common/dsi panel framework, there might be need for a new set of
> helpers.. but I'm not sure that the hw is quite strange enough to need
> an omap specific set of helpers.  Maybe I start w/ something in
> omapdrm but then refactor into common functions once a few drivers are
> converted to atomic modeset and panel framework.

I see a few ways forward with the crtc helpers and atomic modeset:
- bake the assumption into the code that drivers using the crtc
helpers don't have any shared global resources and drop all these
checks. This would boil down to writing a new set_config to handle
global modeset changes (instead of changes to just one crtc).
Obviously the current possible_encoders/possible_crtcs would still be
checked.
- like above, but add a driver-global ->check callback before starting
the modeset sequence, but with the new configuration already applied
to the kms structures.
- an alternative would be a new ->global_adjust_modes after the
->adjust_mode stage that gets all the new adjusted_modes and could
check global resource constrains.

Imo anything more complicated than that has dubious value in a common
framework. I also dunno yet how (or if at all) we should bake in
handling of planes restrictions ...

For panel framework integration I don't think we need much, this is
likely just a driver internal thing.

Cheers, Daniel
Ville Syrjala Sept. 28, 2012, 12:11 p.m. | #4
On Fri, Sep 28, 2012 at 01:55:19PM +0200, Daniel Vetter wrote:
> On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark <rob.clark@linaro.org> wrote:
> > Maybe it just makes sense to always do connector->dpms(OFF) before
> > unhooking the chain, rather than directly calling dpms on the
> > encoder/crtc?
> 
> Well, that makes the entire (optional) ->disable stuff a bit more
> awkward. The thing imo really is that the crtc helper assume that the
> connectors do not hold any hw state, whereas you're omap driver
> violates that assumption.
> 
> For the intel driver we've fixed this by doing any sink handling (e.g.
> for dp) in the encoder->dpms functions. So I think the right way for
> omap is to do the same (or conclude that the crtc helpers are a bad
> fit and ditch them). Having connectors that are special, but only in
> some of the cases imo makes squat sense for a generic helper library.
> 
> >> Which is imo a clear sign that the crtc helper is a misfit for your hw and
> >> you should stop using it ;-) And adding special-case handling like this
> >> into common code, especially if it weakens the semantic concepts in the
> >> helper layer is a recipe for a maintainance disaster a few years down the
> >> road. Hence
> >
> > well, I think by the time we start adding atomic-modeset and
> > common/dsi panel framework, there might be need for a new set of
> > helpers.. but I'm not sure that the hw is quite strange enough to need
> > an omap specific set of helpers.  Maybe I start w/ something in
> > omapdrm but then refactor into common functions once a few drivers are
> > converted to atomic modeset and panel framework.
> 
> I see a few ways forward with the crtc helpers and atomic modeset:
> - bake the assumption into the code that drivers using the crtc
> helpers don't have any shared global resources and drop all these
> checks. This would boil down to writing a new set_config to handle
> global modeset changes (instead of changes to just one crtc).
> Obviously the current possible_encoders/possible_crtcs would still be
> checked.
> - like above, but add a driver-global ->check callback before starting
> the modeset sequence, but with the new configuration already applied
> to the kms structures.

That's essentially what my intel_atomic.c code does. Somewhat ironically,
since your modeset rework, that code is now more suited for other drivers
and I need to go and rewrite it for i915.
Rob Clark Sept. 28, 2012, 12:19 p.m. | #5
On Fri, Sep 28, 2012 at 1:55 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark <rob.clark@linaro.org> wrote:
>> Maybe it just makes sense to always do connector->dpms(OFF) before
>> unhooking the chain, rather than directly calling dpms on the
>> encoder/crtc?
>
> Well, that makes the entire (optional) ->disable stuff a bit more
> awkward. The thing imo really is that the crtc helper assume that the
> connectors do not hold any hw state, whereas you're omap driver
> violates that assumption.
>
> For the intel driver we've fixed this by doing any sink handling (e.g.
> for dp) in the encoder->dpms functions. So I think the right way for
> omap is to do the same (or conclude that the crtc helpers are a bad
> fit and ditch them). Having connectors that are special, but only in
> some of the cases imo makes squat sense for a generic helper library.

hmm.. well I have been thinking that some of what is currently in the
connectors needs to move into the encoders.. this would help, although
will take some time.

>>> Which is imo a clear sign that the crtc helper is a misfit for your hw and
>>> you should stop using it ;-) And adding special-case handling like this
>>> into common code, especially if it weakens the semantic concepts in the
>>> helper layer is a recipe for a maintainance disaster a few years down the
>>> road. Hence
>>
>> well, I think by the time we start adding atomic-modeset and
>> common/dsi panel framework, there might be need for a new set of
>> helpers.. but I'm not sure that the hw is quite strange enough to need
>> an omap specific set of helpers.  Maybe I start w/ something in
>> omapdrm but then refactor into common functions once a few drivers are
>> converted to atomic modeset and panel framework.
>
> I see a few ways forward with the crtc helpers and atomic modeset:
> - bake the assumption into the code that drivers using the crtc
> helpers don't have any shared global resources and drop all these
> checks. This would boil down to writing a new set_config to handle
> global modeset changes (instead of changes to just one crtc).
> Obviously the current possible_encoders/possible_crtcs would still be
> checked.
> - like above, but add a driver-global ->check callback before starting
> the modeset sequence, but with the new configuration already applied
> to the kms structures.
> - an alternative would be a new ->global_adjust_modes after the
> ->adjust_mode stage that gets all the new adjusted_modes and could
> check global resource constrains.
>
> Imo anything more complicated than that has dubious value in a common
> framework. I also dunno yet how (or if at all) we should bake in
> handling of planes restrictions ...
>
> For panel framework integration I don't think we need much, this is
> likely just a driver internal thing.

well.. I guess it where the panel driver fits in KMS.  I think it
would be common that we need to send a command to the panel to turn
off / disable backlight / etc.  Versus an hdmi/dp/etc monitor which
would just do this automatically when it stops receiving a signal.  So
it doesn't seem like a bad idea to not assume that your connector is
completely passive.  But I could buy the argument that this should be
part of crtc helpers v2.

BR,
-R

> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Alan Cox Sept. 28, 2012, 12:52 p.m. | #6
On Fri, 28 Sep 2012 09:27:18 +0200
Rob Clark <rob.clark@linaro.org> wrote:

> From: Rob Clark <rob@ti.com>
> 
> When disabling unused connectors, be sure to call connector->dpms(OFF),
> so if there is actually some IP to turn off (such as external bridge
> chips, etc), these actually do get turned off.

That's a fairly drastic and non-obvious API change for all the other
drivers. Have you tested this widely on other hardware ?

Alan
Rob Clark Sept. 28, 2012, 1:06 p.m. | #7
On Fri, Sep 28, 2012 at 2:52 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Fri, 28 Sep 2012 09:27:18 +0200
> Rob Clark <rob.clark@linaro.org> wrote:
>
>> From: Rob Clark <rob@ti.com>
>>
>> When disabling unused connectors, be sure to call connector->dpms(OFF),
>> so if there is actually some IP to turn off (such as external bridge
>> chips, etc), these actually do get turned off.
>
> That's a fairly drastic and non-obvious API change for all the other
> drivers. Have you tested this widely on other hardware ?

no, not yet..  just testing the waters to see how much others freak
out first ;-)

But since we disconnect the encoder first, drm_helper_connector_dpms()
should end up being a no-op so I don't think it works out to be quite
as drastic as it sounds.

BR,
-R

> Alan
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Alex Deucher Sept. 28, 2012, 1:36 p.m. | #8
On Fri, Sep 28, 2012 at 8:19 AM, Rob Clark <rob.clark@linaro.org> wrote:
> On Fri, Sep 28, 2012 at 1:55 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark <rob.clark@linaro.org> wrote:
>>> Maybe it just makes sense to always do connector->dpms(OFF) before
>>> unhooking the chain, rather than directly calling dpms on the
>>> encoder/crtc?
>>
>> Well, that makes the entire (optional) ->disable stuff a bit more
>> awkward. The thing imo really is that the crtc helper assume that the
>> connectors do not hold any hw state, whereas you're omap driver
>> violates that assumption.
>>
>> For the intel driver we've fixed this by doing any sink handling (e.g.
>> for dp) in the encoder->dpms functions. So I think the right way for
>> omap is to do the same (or conclude that the crtc helpers are a bad
>> fit and ditch them). Having connectors that are special, but only in
>> some of the cases imo makes squat sense for a generic helper library.
>
> hmm.. well I have been thinking that some of what is currently in the
> connectors needs to move into the encoders.. this would help, although
> will take some time.
>
>>>> Which is imo a clear sign that the crtc helper is a misfit for your hw and
>>>> you should stop using it ;-) And adding special-case handling like this
>>>> into common code, especially if it weakens the semantic concepts in the
>>>> helper layer is a recipe for a maintainance disaster a few years down the
>>>> road. Hence
>>>
>>> well, I think by the time we start adding atomic-modeset and
>>> common/dsi panel framework, there might be need for a new set of
>>> helpers.. but I'm not sure that the hw is quite strange enough to need
>>> an omap specific set of helpers.  Maybe I start w/ something in
>>> omapdrm but then refactor into common functions once a few drivers are
>>> converted to atomic modeset and panel framework.
>>
>> I see a few ways forward with the crtc helpers and atomic modeset:
>> - bake the assumption into the code that drivers using the crtc
>> helpers don't have any shared global resources and drop all these
>> checks. This would boil down to writing a new set_config to handle
>> global modeset changes (instead of changes to just one crtc).
>> Obviously the current possible_encoders/possible_crtcs would still be
>> checked.
>> - like above, but add a driver-global ->check callback before starting
>> the modeset sequence, but with the new configuration already applied
>> to the kms structures.
>> - an alternative would be a new ->global_adjust_modes after the
>> ->adjust_mode stage that gets all the new adjusted_modes and could
>> check global resource constrains.
>>
>> Imo anything more complicated than that has dubious value in a common
>> framework. I also dunno yet how (or if at all) we should bake in
>> handling of planes restrictions ...
>>
>> For panel framework integration I don't think we need much, this is
>> likely just a driver internal thing.
>
> well.. I guess it where the panel driver fits in KMS.  I think it
> would be common that we need to send a command to the panel to turn
> off / disable backlight / etc.  Versus an hdmi/dp/etc monitor which
> would just do this automatically when it stops receiving a signal.  So
> it doesn't seem like a bad idea to not assume that your connector is
> completely passive.  But I could buy the argument that this should be
> part of crtc helpers v2.

Thinking about modern hw, I'd probably only expose connectors and
monitors (or maybe call them displays).  You could hang backlight
controls and brightness, etc on the monitor objects.  Also you could
have a multiple monitors connected to a single connector (DP 1.2 or
virtual adapters (wireless or remote display for example)).
Everything else (crtcs, plls, encoders, etc.) would be driver
controlled and validated.

Alex
Daniel Vetter Sept. 28, 2012, 2:03 p.m. | #9
On Fri, Sep 28, 2012 at 3:36 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> Thinking about modern hw, I'd probably only expose connectors and
> monitors (or maybe call them displays).  You could hang backlight
> controls and brightness, etc on the monitor objects.  Also you could
> have a multiple monitors connected to a single connector (DP 1.2 or
> virtual adapters (wireless or remote display for example)).
> Everything else (crtcs, plls, encoders, etc.) would be driver
> controlled and validated.

Yeah, that's pretty much my idea, too. For backwards-compat we could
expose a fake encoder for each connector, but essentially ignore it in
the generic modeset code.
-Daniel

Patch

diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..000cda4 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -244,16 +244,16 @@  void drm_helper_disable_unused_functions(struct drm_device *dev)
 	struct drm_crtc *crtc;
 
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
-		if (!connector->encoder)
-			continue;
 		if (connector->status == connector_status_disconnected)
 			connector->encoder = NULL;
+		if (!connector->encoder)
+			connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
 	}
 
 	list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
 		if (!drm_helper_encoder_in_use(encoder)) {
 			drm_encoder_disable(encoder);
-			/* disconnector encoder from any connector */
+			/* disconnect encoder from any connector */
 			encoder->crtc = NULL;
 		}
 	}