All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Keith Packard <keithp@keithp.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Reset GMBUS controller after NAK
Date: Wed, 30 Mar 2011 17:59:51 +0100	[thread overview]
Message-ID: <1bdc18$k257pk@fmsmga002.fm.intel.com> (raw)
In-Reply-To: <yunvcz07dwm.fsf@aiko.keithp.com>

On Wed, 30 Mar 2011 09:48:25 -0700, Keith Packard <keithp@keithp.com> wrote:
> On Wed, 30 Mar 2011 17:07:11 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 
> > +clear_err:
> > +	I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
> > +	POSTING_READ(GMBUS1 + reg_offset);
> > +	I915_WRITE(GMBUS1 + reg_offset, 0);
> 
> Any posting read needed here?

I'm not even sure we need the first posting read. Maybe it should be a
  wait_for(I915_READ(GMBUS1 + reg_offset) & GMBUS_SW_CLR_INT, 100)
to be clearer that we are simply giving the hardware the chance to assert
the bit and reset before re-enabling.
 
> > +
> > +done:
> > +	I915_WRITE(GMBUS0 + reg_offset, 0);
> 
> What's this new write doing in the non-error path? Do we need a posting
> read after it?

No, GMBUS0 is not read until the very first phase of the data cycle. And
the very first thing we do in the next xfer is a write to GMBUS0 of the
port settings. I just thought that explicitly marking the GMBUS controller
as disabled when not in use by us would lead to less confusion in future.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2011-03-30 16:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30 16:07 [PATCH] drm/i915: Reset GMBUS controller after NAK Chris Wilson
2011-03-30 16:48 ` Keith Packard
2011-03-30 16:59   ` Chris Wilson [this message]
2011-03-30 17:22     ` Keith Packard
2011-03-30 17:42       ` Chris Wilson
2011-03-30 17:56         ` Keith Packard
2011-03-30 20:05 ` Jesse Barnes
2011-03-31 15:16   ` Steven Newbury
2011-03-31 15:20     ` Chris Wilson
2011-03-31 15:33       ` Steven Newbury
2011-04-02 21:50         ` Steven Newbury

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='1bdc18$k257pk@fmsmga002.fm.intel.com' \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=keithp@keithp.com \
    /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.