public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/4] drm/i915: Restore GMBUS operation after a	failed bit-banging fallback
Date: Tue, 12 Apr 2016 15:17:48 +0300	[thread overview]
Message-ID: <20160412121748.GQ4329@intel.com> (raw)
In-Reply-To: <87wpo4tqx7.fsf@intel.com>

On Mon, Apr 11, 2016 at 12:50:44PM +0300, Jani Nikula wrote:
> On Mon, 07 Mar 2016, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > When the GMBUS based i2c transfer times out, we try to fall back to
> > bit-banging and retry the operation that way. However if the bit-banging
> > attempt also fails, we should probably go back to the GMBUS method for
> > the next attempt. Maybe there simply wasn't anyone one the bus at this
> > time.
> >
> > There's also a bit of a mess going on with the force_bit handling.
> > It's supposed to be a ref count actually, and it is as far as
> > intel_gmbus_force_bit() is concerned. But it's treated as just a
> > flag by the timeout based bit-banging fallback. I suppose that's
> > fine since we should never end up in the timeout fallback case
> > if force_bit was already non-zero. However now that we want to restore
> > things back to where they were after the bit-banging attempt failed,
> > we're going to have to do things a bit differently to avoid clobbering
> > the force_bit count as set up by intel_gmbus_force_bit(). So let's
> > dedicate the high bit as a flag for the low level timeout based fallback
> > and treat the rest of the bits as a ref count just as before.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/intel_i2c.c | 10 +++++++---
> >  2 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index f37ac120a29d..2348fea59592 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1043,6 +1043,7 @@ struct intel_fbc_work;
> >  
> >  struct intel_gmbus {
> >  	struct i2c_adapter adapter;
> > +#define GMBUS_FORCE_BIT_RETRY (1U << 31)
> >  	u32 force_bit;
> >  	u32 reg0;
> >  	i915_reg_t gpio_reg;
> > diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
> > index 7bf8a485e18f..5d4b3604afd2 100644
> > --- a/drivers/gpu/drm/i915/intel_i2c.c
> > +++ b/drivers/gpu/drm/i915/intel_i2c.c
> > @@ -579,7 +579,6 @@ timeout:
> >  	 * Hardware may not support GMBUS over these pins? Try GPIO bitbanging
> >  	 * instead. Use EAGAIN to have i2c core retry.
> >  	 */
> > -	bus->force_bit = 1;
> >  	ret = -EAGAIN;
> >  
> >  out:
> > @@ -597,10 +596,15 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
> >  	intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
> >  	mutex_lock(&dev_priv->gmbus_mutex);
> >  
> > -	if (bus->force_bit)
> > +	if (bus->force_bit) {
> >  		ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
> > -	else
> > +		if (ret < 0)
> > +			bus->force_bit &= ~GMBUS_FORCE_BIT_RETRY;
> > +	} else {
> >  		ret = do_gmbus_xfer(adapter, msgs, num);
> > +		if (ret == -EAGAIN)
> > +			bus->force_bit |= GMBUS_FORCE_BIT_RETRY;
> 
> Hmm, would this all be simpler if we did the first bit-banging retry
> here ourselves after all, and set ->force_bit only if bit-banging
> succeeds after gmbus -EAGAIN? I think moving the retry out of
> do_gmbus_xfer() was the right thing to do to, but maybe I went too far
> by pushing it all the way to i2c core?
> 
> Anyway, this patch looks good, but it's just a bit subtle with the
> -EAGAIN and one retry and all.
> 
> Up to you.
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>

I left it alone for now, if for no other reason than to avoid
having to redo any testing right now. We can always revisit it later.

Rest of the series pushed to dinq. Thanks for the reviews.

> 
> > +	}
> >  
> >  	mutex_unlock(&dev_priv->gmbus_mutex);
> >  	intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-04-12 12:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-07 15:56 [PATCH 0/4] drm/i915: GMBUS fixes and whatnot ville.syrjala
2016-03-07 15:56 ` [PATCH 1/4] drm/i915: Actually retry with bit-banging after GMBUS timeout ville.syrjala
2016-03-07 17:06   ` Jani Nikula
2016-03-09 15:13     ` Ville Syrjälä
2016-03-07 15:56 ` [PATCH 2/4] drm/i915: Protect force_bit with gmbus_mutex ville.syrjala
2016-04-11  9:24   ` Jani Nikula
2016-03-07 15:56 ` [PATCH 3/4] drm/i915: Restore GMBUS operation after a failed bit-banging fallback ville.syrjala
2016-04-11  9:50   ` Jani Nikula
2016-04-12 12:17     ` Ville Syrjälä [this message]
2016-03-07 15:57 ` [PATCH 4/4] drm/i915: Make GMBUS timeout message DRM_DEBUG_KMS ville.syrjala
2016-04-11  7:29   ` Ville Syrjälä
2016-04-11  8:19     ` Chris Wilson
2016-04-11 15:31       ` Ville Syrjälä
2016-03-08  7:25 ` ✗ Fi.CI.BAT: warning for drm/i915: GMBUS fixes and whatnot Patchwork
2016-03-09 15:12   ` Ville Syrjälä

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=20160412121748.GQ4329@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox