From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx-relay48-hz3.antispameurope.com (mx-relay48-hz3.antispameurope.com [94.100.134.237]) (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 3B1A137BE97 for ; Wed, 14 Jan 2026 08:29:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=94.100.134.237 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768379356; cv=pass; b=noi0NqINtB4CVk46hnE+kQBZO5V9ct/4VjFRUDxa/k89kXtBsG3zS6WOYbQPVtgQCAVyuD7UdX5abcGILkQ6kBGLrdoCWb1aW5iem1o6OF8ceuU9tJR+aUa9UjiUJR48GAo6ClXCO6TuANslWNwVOmXzPQhpb+oXxNF8s1qgBsA= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768379356; c=relaxed/simple; bh=Iab4ndsrAF7+D8T7DsGLaQLWPukilR+SNny04f/NueA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=kNkGVsNVNUq3/7dFCxlN7FaA0jwISuuRtAJ65fgYv5xbp2mxNaVSfoevTVnayJDKYMXi8Nvnq0QpumegGDLFDMInW8heZxMWUmX81lZEjXLuhswfwffZpLz8egscSv9oiotiwzs5jDK/KT/PgaBRdAX1WlnX1UbLqNXsYgnOmaI= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ew.tq-group.com; spf=pass smtp.mailfrom=ew.tq-group.com; dkim=pass (2048-bit key) header.d=ew.tq-group.com header.i=@ew.tq-group.com header.b=fsmQ+HiE; arc=pass smtp.client-ip=94.100.134.237 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ew.tq-group.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ew.tq-group.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ew.tq-group.com header.i=@ew.tq-group.com header.b="fsmQ+HiE" ARC-Authentication-Results: i=1; mx-gate48-hz3.hornetsecurity.com 1; spf=pass reason=mailfrom (ip=94.100.132.6, headerfrom=ew.tq-group.com) smtp.mailfrom=ew.tq-group.com smtp.helo=smtp-out02-hz1.hornetsecurity.com; dmarc=pass header.from=ew.tq-group.com orig.disposition=pass ARC-Message-Signature: a=rsa-sha256; bh=bwSNtwuxzn6iZJ9JU/ff8xk/XC7ukkHtkWY1re96guo=; c=relaxed/relaxed; d=hornetsecurity.com; h=from:to:date:subject:mime-version:; i=1; s=hse1; t=1768379339; b=bBKsusow/mtTkciJJ6X+RyYCSqHH1wAg5B8PGiNj3bQIZXsUry0Gz4m5L5qJZwmKWNsUYVmN yk66k7sUJTclYoNzpNRPr3LRC33YBoeeGkyRl8AsZKM+env/2uQQXKicCNCHB4+wSkTAG4Sl2Ge LtKMi9cOWqBqF/UW1fqtfa8yBsars7WS/ClxMOy3puxm8FUY6u7JX6FgdeqjPm7/htVQnfMs2NP LSbP0ECf5f5WTBcPihiAMrLrCAed9VIXITN6GBAyDAolx9L+bbzOqxf6iBOJ7a3zAsR4hdIKVly +MNcCF5j16aVArmSu+5cAoS/IbWtaAb9DzklIvIcKeM9w== ARC-Seal: a=rsa-sha256; cv=none; d=hornetsecurity.com; i=1; s=hse1; t=1768379339; b=g01frRBChdKlWVtDiS0lAtN/zQEpUYQeeOYdSxEDpkVZw/RUZzJfadwDIJo3VnjMANh2LDAz 2KnYBRqhkPIP+DJohKguCV4XMFjOAc/iZwbTvhcRTPPoS/2xNNM/k3Of7gOEex07A+3fVnHTTxB 1rXyihscpiu164fy/hK/syBUSttu5cirEizyQa8V9ovgR81VU2eRLpRW0UFYBaHMC/bdDKrVAxE N8XsjA7XjL4wxztVDIwGYb51vIV5RvAEwh9r2ujdWjVWgV7t5rvSbzM8NZnrmrjBQqI9dsSguye /HmvfRwc4fCaVsKhr5VbCS6B8kArjV6YY6mFPcIHNk3eQ== Received: from he-nlb01-hz1.hornetsecurity.com ([94.100.132.6]) by mx-relay48-hz3.antispameurope.com; Wed, 14 Jan 2026 09:28:58 +0100 Received: from [192.168.153.128] (host-82-135-125-110.customer.m-online.net [82.135.125.110]) (Authenticated sender: matthias.schiffer@ew.tq-group.com) by smtp-out02-hz1.hornetsecurity.com (Postfix) with ESMTPSA id 1068B5A0A13; Wed, 14 Jan 2026 09:28:49 +0100 (CET) Message-ID: <5c535725c5e4761e6f16ff4016affe8ddcc79d88.camel@ew.tq-group.com> Subject: Re: [PATCH v2 1/2] i2c: ocores: increase poll timeout to total transfer timeout From: Matthias Schiffer To: Andrew Lunn Cc: Peter Korsgaard , Andi Shyti , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, linux@ew.tq-group.com, Wolfram Sang Date: Wed, 14 Jan 2026 09:28:48 +0100 In-Reply-To: References: <51a72ceca0154d7be85c3cc67722e7dd0b364a2e.1760000254.git.matthias.schiffer@ew.tq-group.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.3-0ubuntu1.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-cloud-security-sender:matthias.schiffer@ew.tq-group.com X-cloud-security-recipient:linux-kernel@vger.kernel.org X-cloud-security-crypt: load encryption module X-cloud-security-Mailarchiv: E-Mail archived for: matthias.schiffer@ew.tq-group.com X-cloud-security-Mailarchivtype:outbound X-cloud-security-Virusscan:CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay48-hz3.antispameurope.com with 4drfQn42Ttz1kNkWB X-cloud-security-connect: he-nlb01-hz1.hornetsecurity.com[94.100.132.6], TLS=1, IP=94.100.132.6 X-cloud-security-Digest:97731e2c4315403f6ab53d234caf3ca6 X-cloud-security:scantime:2.082 DKIM-Signature: a=rsa-sha256; bh=bwSNtwuxzn6iZJ9JU/ff8xk/XC7ukkHtkWY1re96guo=; c=relaxed/relaxed; d=ew.tq-group.com; h=content-type:mime-version:subject:from:to:message-id:date; s=hse1; t=1768379338; v=1; b=fsmQ+HiEgh5A2tiQ1KYYnBeDq+dI/XMIgQu1rISFWqGCgWo9ro8cuXIqVG/WnwmYTb80XYuU IKdNOzSo5x5WE/vq+LPQFRjqN1WCPCZ2dw05rGUTrcEZ1Z1SIb2WZt6Br/vAcOZHmaLbJkrV1Gj 7BRAsz4Q4Xv7q2UHa7gPOMie834dP1ocpp+77Sd39nrDuXiFvUvXoO0rcghLwaYuF+RkKewye+B Pg4t5ev7Jk9PPBaNrAYr+ehEL0pifNUWgEh2ltKNDXw+zdXET+oth8NCzT9CKjKdVXOq5gVH20F NfS7sMonWfEMTMBiO7JJqvcKnzK12RyR/LFjJb3j/D9DQ== On Tue, 2026-01-13 at 15:21 +0100, Andrew Lunn wrote: > On Tue, Jan 13, 2026 at 02:02:07PM +0100, Wolfram Sang wrote: > >=20 > > > The behavior in the regular case is unchanged, spinning for up to 1ms= , > > > but the open-coded poll loop is replaced with read_poll_timeout_atomi= c() > > > as suggested by Andrew Lunn. > >=20 > > Hmm, spinning 1ms is still a lot. Can't we just use read_poll_timeout() > > for the whole timeout? I can't see that it will cause a regression. But > > please correct me if I am wrong. >=20 > I've forgotten the context, but >=20 > /** > * ocores_poll_wait() - Wait until is possible to process some data > * @i2c: ocores I2C device instance > * > * Used when the device is in polling mode (interrupts disabled). >=20 > If interrupts are disabled, you cannot use read_poll_timeout(). You > have to use read_poll_timeout_atomic(). And that spins anyway. >=20 > Andrew This code does not have interrupts disabled, we could not fall back from read_poll_timeout_atomic() to read_poll_timeout() otherwise. My understandi= ng is that a sleeping wait would make it more likely for a switch to a different = task to happen after every byte, negatively impacting I2C performance; this is n= ot something I have verified however. It is spinning for 1ms because that's what the old code did (which only spu= n without fallback to sleeping). Reducing this to the time needed to transfer= 1 byte in the absence of clock stretching should not cause issues (200us for 50kHz; could also be made to depend on the clock rate, so it would be even = less spinning at higher frequencies). Best, Matthias