[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:59:03 UTC 2020
On Wed, Jun 24, 2020 at 01:50:06AM +0300, Imre Deak wrote:
> 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.
Got it thanks will update and send the next rev
Regards
Manasi
>
> > 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
More information about the Intel-gfx
mailing list