From: Manasi Navare <manasi.d.navare@intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status
Date: Tue, 23 Jun 2020 15:59:03 -0700 [thread overview]
Message-ID: <20200623225903.GE22294@intel.com> (raw)
In-Reply-To: <20200623223549.GE7681@ideak-desk.fi.intel.com>
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2020-06-23 22:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-18 0:01 [Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status Manasi Navare
2020-06-18 0:01 ` [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Wait or poll with timeout for DDI BUF non idle after enable Manasi Navare
2020-06-18 0:31 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status Patchwork
2020-06-18 0:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-06-18 1:55 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-06-22 15:49 ` [Intel-gfx] [PATCH v2 1/2] " Imre Deak
2020-06-22 17:06 ` Ville Syrjälä
2020-06-23 19:26 ` Manasi Navare
2020-06-23 19:42 ` Manasi Navare
2020-06-23 19:57 ` Imre Deak
2020-06-23 20:32 ` Manasi Navare
2020-06-23 20:50 ` Imre Deak
2020-06-23 22:19 ` Manasi Navare
2020-06-23 22:50 ` Imre Deak
2020-06-23 22:59 ` Manasi Navare [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200623225903.GE22294@intel.com \
--to=manasi.d.navare@intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.