[Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status

[Imre Deak]

On Tue, Jun 23, 2020 at 03:19:41PM -0700, Manasi Navare wrote:
> On Tue, Jun 23, 2020 at 11:50:27PM +0300, Imre Deak wrote:
> > On Tue, Jun 23, 2020 at 01:32:50PM -0700, Manasi Navare wrote:
> > 
> > with two functions it would get:
> > 
> > intel_ddi_wait_for_ddi_buf_active(i915, port)
> > {
> > 	if (GEN <= 9) {
> > 		usleep_range(600, 1000);
> 
> The doumentation however does suggest that we use udelay to avoid the overhead
> of setting up hrtimers needed for usleep_range in atomic context.

The relevant part here is "NON-ATOMIC CONTEXT":

SLEEPING FOR "A FEW" USECS ( < ~10us? ):
	* Use udelay

	- Why not usleep?
                        On slower systems, (embedded, OR perhaps a speed-
                        stepped PC!) the overhead of setting up the hrtimers
                        for usleep *may* not be worth it. Such an evaluation
                        will obviously depend on your specific situation, but
                        it is something to be aware of.

SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
        * Use usleep_range

So, can use udelay() for 16usec and should use usleep_range() for 600 usec.

> But then checkpatch also suggests using usleep_range, why is that?
> 
> so still not clear in the context of i915 how we decide where to use jiffie based
> delay through udelay and when to use hrtimers (usleep)?

The above document should be followed.

> 
> Manasi
> 
> 
> > 		return;
> > 	}
> > 
> >  	if (wait_for_us(!(read(BUF_CTL) & IS_IDLE), 600))
> >  		drm_err("Port %c: Timeout waiting for DDI BUF to get active\n", port));
> > }
> > 
> > intel_ddi_wait_for_ddi_buf_idle(i915, port)
> > {
> > 	if (BXT) {
> > 		udelay(16);
> > 		return;
> > 	}
> > 
> >  	if (wait_for_us(read(BUF_CTL) & IS_IDLE, 600))
> >  		drm_err("Port %c: Timeout waiting for DDI BUF to get idle\n", port));
> > }
> > 
> > --Imre