On Fri, 30 Sep 2011 20:47:00 +0200, Daniel Vetter <daniel@xxxxxxxx> wrote: > A cancel_work might be good here, not point in waking up the cpu for no > reason. And can you add "panel off timer: " to the deboug output? No, that's not correct, this is run before turning the panel back on and must check that enough time has elapsed since it was turned off, which may have happened in the work proc. However, you are right in saying that I could call the cancel work function when the panel is forced off synchronously. I'll add that. > Like Chris already mentioned, s/struct_mutex/mode_config.mutex/ Maybe also > move the intel_dp->want_panel_vdd check in here - we need it only here to > avoid a race with vdd_on. I've almost overlooked it and already started to > write the complaint about the race ;-) With the right mutex held, there won't be a race, we just need to check the value somewhere. Do you still see a race condition that needs to be avoided? > > @@ -1111,10 +1175,10 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode) > > intel_dp_start_link_train(intel_dp); > > if (is_edp(intel_dp)) > > ironlake_edp_panel_on(intel_dp); > > - ironlake_edp_panel_vdd_off(intel_dp); > > + ironlake_edp_panel_vdd_off(intel_dp, true); > > intel_dp_complete_link_train(intel_dp); > > } else > > - ironlake_edp_panel_vdd_off(intel_dp); > > + ironlake_edp_panel_vdd_off(intel_dp, false); > > Any reason why one vdd_off is sync while the other isn't? After the panel is turned on, I want to synchronously turn off the VDD AUX bits, as that's what the driver did before. That's 'free' because the panel is on. In the other (failure) path, I don't want to impose a delay if the application wants to try the mode set again. -- keith.packard@xxxxxxxxx
Attachment:
pgpUwIeeuxENw.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
