On Mon, Nov 10, 2014 at 09:21:47PM +0200, Imre Deak wrote: > On Fri, 2014-11-07 at 12:08 +0000, Damien Lespiau wrote: > > On Tue, Sep 16, 2014 at 04:19:07PM +0300, Imre Deak wrote: > > > > @@ -1233,6 +1233,9 @@ static bool edp_panel_vdd_on(struct intel_dp *intel_dp) > > > > power_domain = intel_display_port_power_domain(intel_encoder); > > > > intel_display_power_get(dev_priv, power_domain); > > > > > > > > + power_domain = intel_display_aux_power_domain(intel_encoder); > > > > + intel_display_power_get(dev_priv, power_domain); > > > > + > > > > > > The AUX power domains were added to save power when only AUX > > > functionality is needed, since then we don't need to power on the power > > > domain needed for full port functionality. > > > > Hum I'm not sure about this. It seems to me that the value of the AUX > > power domain is to be able to shutdown the AUX hardware when AUX is not > > needed. That's slightly different from what you're saying; > > Ok, I didn't describe all uses cases where the AUX domains are useful, > your description here was more complete. To summarize that for later > reference: > > 1. only AUX (output inactive, we only do a connector detection) > 2. only main lanes (most of the time when the output is active) > 3. AUX+main lanes (link training/re-training) > 4. no AUX, no main lanes (output is inactive) > > > The cases where "only AUX functionality is needed" seem very transient > > to me, while having the main lanes working and no need for AUX sounds > > like the case where it's interesting to have the AUX hw powered down. > > Of course, with PSR we can do both. > > Perhaps, if case 1. above isn't very frequent. But my arguments were > valid even for case 2. and 3. I've thought the point of case 1 is that we don't have to fire up the entire display clocks and power wells when just doing a few dp aux transactions to probe for outputs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
