On Thu, Sep 05, 2013 at 03:21:01PM +0300, Ville Syrjälä wrote: > On Thu, Sep 05, 2013 at 01:45:47PM +0200, Daniel Vetter wrote: > > On Thu, Sep 05, 2013 at 02:33:20PM +0300, Ville Syrjälä wrote: > > > On Wed, Sep 04, 2013 at 08:50:13PM +0200, Daniel Vetter wrote: > > > > On Fri, Aug 30, 2013 at 1:50 AM, <mengdong.lin@xxxxxxxxx> wrote: > > > > > + /* Wait for 2 vertical blanks */ > > > > > + intel_wait_for_vblank(dev, pipe); > > > > > + intel_wait_for_vblank(dev, pipe); > > > > > + > > > > > + /* Disable audio PD. This is optional as per Bspec. */ > > > > > + temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD); > > > > > + temp &= ~(AUDIO_OUTPUT_ENABLE_A << (pipe * 4)); > > > > > + I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, temp); > > > > > > > > If this is optional do we really need the two vblank waits above? > > > > Adding them just for fun when we generally try to rip out as many > > > > vblank waits as possible from the modeset code isn't all that great > > > > ... > > > > > > One idea I had for these kinds of vblank waits (there also one required > > > for IPS for instance) is that we might just sample a vblank counter > > > after the first step, then at the latest point we can, we'd wait for the > > > frame counter to have passed the sampled vaoue + whatever extra is > > > needed. That might allow us to do other stuff in parallel while the > > > required number of vblanks will elapese. > > > > My solution for this is to have vblank work items that we can use to chain > > off all these things. We also need them for pageflips e.g. when > > re-enabling fbc or similar stuff. The problem is a bit that for switching > > things off like in a modeset the synchronization can get hairy and will be > > little-tested. For enabling as long as we share the code with the nuclear > > pageflip code we should be fine though ... > > > > Hence why I think we should try rather hard to avoid these vblank waits in > > the first place. > > Yeah, for enabling we definitely want to execute all that stuff > asynchronously. > > The disable case is more problematic. For atomic pageflip we might get > away with returning -EAGAIN or something, but we have to block in the > full modeset case unless we want to move the entire modeset to a work > queue. So this trick would mostly be relevant for the disable during > modeset case. > > But of course we could do that stuff via some kind of > schedule_vblank_work(currentl_vbl_count + X) and synchronize_vblank_work() > just before the critical step that needs the vblank work to be done. But > the locking and bugs might be more complicated in this case. Yeah we'll end up doing a maze of what will essentially be async tasklets and callbacks. A declarative way to do that would imo be a requirement, but such fanciness is hard to pull of in C without turning into something really ugly ... -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
