From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DCE23A6B9D for ; Mon, 1 Jun 2026 09:57:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307855; cv=none; b=pLDFuffbpEVUdmEiMxT3ohyqArzck3+PIG7oRK5JOXCNMFa7FPfU43qIArT0EquQLH+IAaW2xUNZ5pU380IEksEQ6LRMqCQMrJcP/G1qQA+DEkDyoVhfqjIQY9BHymgM7F5G3FClA0XJXHqQXZqGdNGHiaSwGjq1nEgEmSnjAIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780307855; c=relaxed/simple; bh=pTjlChPJzgavu9HtH3HlamrUFdRzFwSEgvot7/KhuHc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=IVelYbMtPfZUni570w4DC/I0GXDLjKq1H6mw5rv8lLKEuI6wM7AiH5skvcn69oiUHx18MBQ6lMbORIEcYFzYdl886Dnj1WPIxKGNun/wodLlJ3EF6PMpkHLIm6e658tCXEcNTbnuEqBsfgjqPcpZEVO5OrUd7fgG8LJG38EUH60= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=O/SlszvH; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="O/SlszvH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780307847; x=1811843847; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=pTjlChPJzgavu9HtH3HlamrUFdRzFwSEgvot7/KhuHc=; b=O/SlszvHFA2rDiaY9vqS2rSBzU/JOfeFKM3GjsnVgrpaokwt2QHqYNG0 hDpiujZtm9S6lNJnGg9omrPujhMpBhz0Yoc8SiXp9CO2+NEsiSKbmu26T TKSV3KLhvc5/6oU1wirVHLssKjvRdci8JcmoDWDLAtCs7XcNrC2XBaRfc Qxh6EpycNlcxpe6F/FdbkAHc5sw7fu1bwMfkvmrXm4woXRMnUMlJ9Jg/y btX9Zl0QFmXSCapxUZAGylZtNNzJmEc4V2adosEhqT3+pwzvgbF4/vzlP vIrfuplzh/RRGJYnTrTsz28jTUA74HyuvIxI0my9a4o1PWnbMXDPWKFsc A==; X-CSE-ConnectionGUID: 7D85FOZdTymOld/PYzbReA== X-CSE-MsgGUID: Io//I9eiTIeCGpcu3VPqYA== X-IronPort-AV: E=McAfee;i="6800,10657,11803"; a="92177773" X-IronPort-AV: E=Sophos;i="6.24,181,1774335600"; d="scan'208";a="92177773" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2026 02:57:26 -0700 X-CSE-ConnectionGUID: hezSgFZWSDO5j5nynBW03A== X-CSE-MsgGUID: GnaJcyPdS1mT8OZUAUAaYg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,181,1774335600"; d="scan'208";a="248448162" Received: from amilburn-desk.amilburn-desk (HELO localhost) ([10.245.245.121]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2026 02:57:23 -0700 From: Jani Nikula To: Kunal Zodape , amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Alex Deucher , Christian =?utf-8?Q?K=C3=B6nig?= , David Airlie , Simona Vetter , Rahul Kumar , Prateek Gupta , Kunal Zodape Subject: Re: [PATCH] drm/amdgpu: use ACK polling for page-write completion In-Reply-To: <20260601093226.1255621-1-kunal.devanandzodape@amd.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland References: <20260601093226.1255621-1-kunal.devanandzodape@amd.com> Date: Mon, 01 Jun 2026 12:57:19 +0300 Message-ID: <3206d5c3e94f694b4f0a5b5db4dc1ebaaa86aac9@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, 01 Jun 2026, Kunal Zodape wrote: > 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. > > Signed-off-by: Kunal Zodape > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c | 28 +++++++++++++++------- > 1 file changed, 20 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..53be5a31c40c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c > @@ -153,15 +153,27 @@ 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). > + ktime_t timeout = ktime_add_ms(ktime_get(), 10); > + > + /* 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); > + do { > + r = i2c_transfer(i2c_adap, &msgs[0], 1); > + if (r == 1) > + break; > + usleep_range(100, 200); > + } while (ktime_before(ktime_get(), timeout)); > + > + if (r != 1) > + break; See poll_timeout_us(). BR, Jani. > } > } -- Jani Nikula, Intel