public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: "Lazar, Lijo" <lijo.lazar@amd.com>
To: Kunal Zodape <kunal.devanandzodape@amd.com>,
	amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Alex Deucher <alexander.deucher@amd.com>,
	Christian König <christian.koenig@amd.com>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Rahul Kumar <Rahul.Kumar1@amd.com>,
	Prateek Gupta <Prateek1.Gupta@amd.com>
Subject: Re: [PATCH v2] drm/amdgpu: use ACK polling for page-write completion
Date: Mon, 1 Jun 2026 18:35:02 +0530	[thread overview]
Message-ID: <7237b5c9-f97d-408f-8fd5-15ccbc9c08d8@amd.com> (raw)
In-Reply-To: <20260601112336.2277724-1-kunal.devanandzodape@amd.com>



On 01-Jun-26 4:53 PM, Kunal Zodape wrote:
> [Some people who received this message don't often get email from kunal.devanandzodape@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> The EEPROM write path currently waits a fixed 10 ms after each page
> write to cover the maximum write-cycle time.
> 
> Replace the fixed delay with ACK polling so the driver can continue as
> soon as the EEPROM finishes its internal write cycle. Since the SMU I2C
> adapter used for these EEPROM accesses does not support zero-length
> transfers, poll readiness with an offset-only dummy write.
> 
> Keep the existing 10 ms timeout as the upper bound for the polling loop.
> 
> Tested on MI200 (ALDEBARAN) with ras_eeprom_reset confirming clean
> write/read-back with no I2C errors.

The current sleep logic may be better than sending a dummy transfter 
through firmware. That has the overhead of FW message logic and other 
clients accessing i2c bus.

The original comments in the code logic are valid for optimization only 
if driver has direct access to the i2c bus.

Thanks,
Lijo

> 
> Suggested-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Kunal Zodape <kunal.devanandzodape@amd.com>
> ---
> v2: Use read_poll_timeout() instead of open-coded ktime + do-while loop
>      as suggested
> 
>   drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c | 27 +++++++++++++++-------
>   1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c
> index 8cd69836dd99..9dc538073bb8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c
> @@ -21,6 +21,7 @@
>    *
>    */
> 
> +#include <linux/iopoll.h>
>   #include "amdgpu_eeprom.h"
>   #include "amdgpu.h"
> 
> @@ -153,15 +154,25 @@ static int __amdgpu_eeprom_xfer(struct i2c_adapter *i2c_adap, u32 eeprom_addr,
>                          break;
> 
>                  if (!read) {
> -                       /* According to EEPROM specs the length of the
> -                        * self-writing cycle, tWR (tW), is 10 ms.
> -                        *
> -                        * TODO: Use polling on ACK, aka Acknowledge
> -                        * Polling, to minimize waiting for the
> -                        * internal write cycle to complete, as it is
> -                        * usually smaller than tWR (tW).
> +                       int ret;
> +
> +                       /* Poll for ACK to detect when the self-timed
> +                        * internal write cycle has completed, as per
> +                        * Acknowledge Polling described in the AT24CM02
> +                        * datasheet, Section 7.4. The SMU I2C adapter
> +                        * used by these EEPROM paths does not support
> +                        * zero-length messages, so use an offset-only
> +                        * dummy write to probe for the ACK. The address
> +                        * pointer update is harmless because each real
> +                        * transfer reprograms it before use.
>                           */
> -                       msleep(10);
> +                       ret = read_poll_timeout(i2c_transfer, r,
> +                                                r == 1,
> +                                                200, 10 * USEC_PER_MSEC,
> +                                                false,
> +                                                i2c_adap, &msgs[0], 1);
> +                       if (ret)
> +                               break;
>                  }
>          }
> 
> --
> 2.17.1
> 


  reply	other threads:[~2026-06-01 13:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01  9:32 [PATCH] drm/amdgpu: use ACK polling for page-write completion Kunal Zodape
2026-06-01  9:57 ` Jani Nikula
2026-06-04  4:17   ` Claude review: " Claude Code Review Bot
2026-06-01 11:23 ` [PATCH v2] " Kunal Zodape
2026-06-01 13:05   ` Lazar, Lijo [this message]
2026-06-02  6:10     ` Devanand Zodape, Kunal
2026-06-02  6:31       ` Lazar, Lijo
2026-06-04  4:17 ` Claude review: " Claude Code Review Bot
2026-06-04  4:17 ` Claude Code Review Bot

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=7237b5c9-f97d-408f-8fd5-15ccbc9c08d8@amd.com \
    --to=lijo.lazar@amd.com \
    --cc=Prateek1.Gupta@amd.com \
    --cc=Rahul.Kumar1@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kunal.devanandzodape@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simona@ffwll.ch \
    /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