All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	rodrigo.vivi@intel.com
Subject: Re: [PATCH] drm/i915/gmbus: fix spurious timeout on 512-byte burst reads
Date: Tue, 10 Feb 2026 18:39:43 +0200	[thread overview]
Message-ID: <aYtfT7aw5n1Dwd-Y@intel.com> (raw)
In-Reply-To: <83ad67d411502b2e2ece666745b5209dae83e4f7@intel.com>

On Tue, Feb 10, 2026 at 11:23:02AM +0200, Jani Nikula wrote:
> On Fri, 06 Feb 2026, Samasth Norway Ananda <samasth.norway.ananda@oracle.com> wrote:
> > When reading exactly 512 bytes with burst read enabled, the
> > extra_byte_added path breaks out of the inner do-while without
> > decrementing len. The outer while(len) then re-enters and gmbus_wait()
> > times out since all data has been delivered. Decrement len before the
> > break so the outer loop terminates correctly.
> 
> Nice find, and the fix looks correct. How did you figure this out? Did
> you hit the issue?
> 
> I wonder if the whole extra byte thing is a workaround for some old
> hardware that shouldn't be needed on modern hardware... Ville, thoughts?

I think it's still needed due to the weird way this is implemented
in the hardware. The byte counter rolls over at 256->1, so for that
to happen the programmed byte count must be >256 or else we'd reach
the target byte count before the rollover happens, in which case
the entire transfer would terminate already during the first 256
byte chunk.

> 
> > Also fix a typo in a nearby comment ("generata" -> "generate").
> 
> "Also" is a good hint that it should be a separate patch. ;)
> 
> BR,
> Jani
> 
> > Fixes: d5dc0f43f268 ("drm/i915/gmbus: Enable burst read")
> > Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_gmbus.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c b/drivers/gpu/drm/i915/display/intel_gmbus.c
> > index 2caff677600c..5fb3fee34af4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> > +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> > @@ -496,8 +496,10 @@ gmbus_xfer_read_chunk(struct intel_display *display,
> >  
> >  		val = intel_de_read_fw(display, GMBUS3(display));
> >  		do {
> > -			if (extra_byte_added && len == 1)
> > +			if (extra_byte_added && len == 1) {
> > +				len--;
> >  				break;
> > +			}
> >  
> >  			*buf++ = val & 0xff;
> >  			val >>= 8;
> > @@ -693,7 +695,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
> >  			goto clear_err;
> >  	}
> >  
> > -	/* Generate a STOP condition on the bus. Note that gmbus can't generata
> > +	/* Generate a STOP condition on the bus. Note that gmbus can't generate
> >  	 * a STOP on the very first cycle. To simplify the code we
> >  	 * unconditionally generate the STOP condition with an additional gmbus
> >  	 * cycle. */
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2026-02-10 16:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-06 20:30 [PATCH] drm/i915/gmbus: fix spurious timeout on 512-byte burst reads Samasth Norway Ananda
2026-02-09 15:30 ` ✓ CI.KUnit: success for " Patchwork
2026-02-09 16:05 ` ✓ Xe.CI.BAT: " Patchwork
2026-02-09 18:26 ` ✓ i915.CI.BAT: " Patchwork
2026-02-09 20:22 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-02-10  1:26 ` ✗ i915.CI.Full: " Patchwork
2026-02-10  9:23 ` [PATCH] " Jani Nikula
2026-02-10 16:39   ` Ville Syrjälä [this message]
2026-02-19 23:25   ` [External] : " samasth.norway.ananda

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=aYtfT7aw5n1Dwd-Y@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=samasth.norway.ananda@oracle.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.