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

[Manasi Navare <manasi.d.navare@intel.com>]

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:
> > still dont quite get it, how is usleep_range (600, 1000) providing a fixed delay?
> 
> Not sure what you mean. udelay is busy looping, while usleep_range
> sleeps instead. How to chose between udelay/usleep_range please read
> 
> Documentation/timers/timers-howto.rst
>

Yes thanks for pointing me to the documentation.
I guess I thought you were suggesting to use just usleep_range for both
fixed delay and delay with timeout so got confused.
 
> > Now if we split ino 2 functs, one for disable, for that:
> > 
> > if (BXT)
> > 	usleep_range(600, 1000)
> > else
> > 	wait_for_us(check if Idle bit set)
> > 
> > so in both functions, for the timeout part we still use the wait_for_us helper right?
> 
> 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. 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)?

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx