* [PATCH] drm: call connector->dpms(OFF) when disabling @ 2012-09-28 7:27 Rob Clark 2012-09-28 9:56 ` Daniel Vetter 2012-09-28 12:52 ` Alan Cox 0 siblings, 2 replies; 10+ messages in thread From: Rob Clark @ 2012-09-28 7:27 UTC (permalink / raw) To: dri-devel; +Cc: Rob Clark, rogerq, patches 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; } } -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 7:27 [PATCH] drm: call connector->dpms(OFF) when disabling Rob Clark @ 2012-09-28 9:56 ` Daniel Vetter 2012-09-28 10:54 ` Rob Clark 2012-09-28 12:52 ` Alan Cox 1 sibling, 1 reply; 10+ messages in thread From: Daniel Vetter @ 2012-09-28 9:56 UTC (permalink / raw) To: Rob Clark; +Cc: Rob Clark, patches, dri-devel, rogerq 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 9:56 ` Daniel Vetter @ 2012-09-28 10:54 ` Rob Clark 2012-09-28 11:55 ` Daniel Vetter 0 siblings, 1 reply; 10+ messages in thread From: Rob Clark @ 2012-09-28 10:54 UTC (permalink / raw) To: Daniel Vetter; +Cc: rogerq, dri-devel, patches 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 10:54 ` Rob Clark @ 2012-09-28 11:55 ` Daniel Vetter 2012-09-28 12:11 ` Ville Syrjälä 2012-09-28 12:19 ` Rob Clark 0 siblings, 2 replies; 10+ messages in thread From: Daniel Vetter @ 2012-09-28 11:55 UTC (permalink / raw) To: Rob Clark; +Cc: rogerq, dri-devel, patches 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 11:55 ` Daniel Vetter @ 2012-09-28 12:11 ` Ville Syrjälä 2012-09-28 12:19 ` Rob Clark 1 sibling, 0 replies; 10+ messages in thread From: Ville Syrjälä @ 2012-09-28 12:11 UTC (permalink / raw) To: Daniel Vetter; +Cc: rogerq, patches, dri-devel, Rob Clark 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. -- Ville Syrjälä Intel OTC ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 11:55 ` Daniel Vetter 2012-09-28 12:11 ` Ville Syrjälä @ 2012-09-28 12:19 ` Rob Clark 2012-09-28 13:36 ` Alex Deucher 1 sibling, 1 reply; 10+ messages in thread From: Rob Clark @ 2012-09-28 12:19 UTC (permalink / raw) To: Daniel Vetter; +Cc: patches, dri-devel, rogerq 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 12:19 ` Rob Clark @ 2012-09-28 13:36 ` Alex Deucher 2012-09-28 14:03 ` Daniel Vetter 0 siblings, 1 reply; 10+ messages in thread From: Alex Deucher @ 2012-09-28 13:36 UTC (permalink / raw) To: Rob Clark; +Cc: rogerq, dri-devel, patches 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 13:36 ` Alex Deucher @ 2012-09-28 14:03 ` Daniel Vetter 0 siblings, 0 replies; 10+ messages in thread From: Daniel Vetter @ 2012-09-28 14:03 UTC (permalink / raw) To: Alex Deucher; +Cc: rogerq, patches, dri-devel, Rob Clark 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 7:27 [PATCH] drm: call connector->dpms(OFF) when disabling Rob Clark 2012-09-28 9:56 ` Daniel Vetter @ 2012-09-28 12:52 ` Alan Cox 2012-09-28 13:06 ` Rob Clark 1 sibling, 1 reply; 10+ messages in thread From: Alan Cox @ 2012-09-28 12:52 UTC (permalink / raw) To: Rob Clark; +Cc: Rob Clark, patches, dri-devel, rogerq 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm: call connector->dpms(OFF) when disabling 2012-09-28 12:52 ` Alan Cox @ 2012-09-28 13:06 ` Rob Clark 0 siblings, 0 replies; 10+ messages in thread From: Rob Clark @ 2012-09-28 13:06 UTC (permalink / raw) To: Alan Cox; +Cc: rogerq, dri-devel, patches 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-09-28 14:03 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-28 7:27 [PATCH] drm: call connector->dpms(OFF) when disabling Rob Clark 2012-09-28 9:56 ` Daniel Vetter 2012-09-28 10:54 ` Rob Clark 2012-09-28 11:55 ` Daniel Vetter 2012-09-28 12:11 ` Ville Syrjälä 2012-09-28 12:19 ` Rob Clark 2012-09-28 13:36 ` Alex Deucher 2012-09-28 14:03 ` Daniel Vetter 2012-09-28 12:52 ` Alan Cox 2012-09-28 13:06 ` Rob Clark
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.