[Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status
Manasi Navare
manasi.d.navare at intel.com
Tue Jun 23 22:19:41 UTC 2020
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
More information about the Intel-gfx
mailing list