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(-)
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; } }
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->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
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
-- 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
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
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.
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
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
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
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
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
dri-devel@lists.freedesktop.org
-
Alan Cox -
Alex Deucher -
Daniel Vetter -
Rob Clark -
Ville Syrjälä