From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 36AF4408031 for ; Fri, 10 Jul 2026 11:11:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783681913; cv=none; b=oZVDYHWNPEDfU+b6KgkGN+UnT3jUSqaxD1w3XVnhK74a0yQQ/rrvj8zCeu7lUUv7Flr0tOsF3P2K1wk6FCHKOBtHOrj36KflttLR7rysNg9PiICgcUKWQ7/Y3dyHdLlSuqHbdNu5hA5i3yUNHYZYYKt9FeeP8vjprvYZv6xH0wg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783681913; c=relaxed/simple; bh=MKPke5BUYCTUcfxDA8duezcYg48WdqfGwObsktUR5lY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jl5DsnbyT5Dw535fw0zPjLEYZS2H75b+yJjDHnDKHHlqLY7LBLoh4kVrtvFxd/SQEOHsKZgxp9Mn+5yxxkXtmdCco4l5WWEgXRSSGQ/jwdmQgloBUiqLQEpiHeqqWuC2wx6/2dD6gjTGpbpJhajOIIOXLlo7EBAnqX8j6l/4Qzg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=VCTgJ131; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=KU2uoi0I; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="VCTgJ131"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="KU2uoi0I" Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66AAmVL9615090 for ; Fri, 10 Jul 2026 11:11:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= JU6YRxZVspUNbu+VKz/3WI7sJx1qZ3NhZ7bU7qRiJXg=; b=VCTgJ131iEPM4MAE 8AYlc6FUY8uYOy4BZ+QjxJUMPxwOJP1fAdceJXbGSle3LxdPLs/ci66EsO43j6Aa aCV35X4L1GQDnSm7oi2OXuH2GTtAB8jKnxUTqGN99GkNSqHGFM8BsOCG4XOOiG+R K6P28wi4JcS9YD5PpAJvsQNwH9pOd+mbfQXlUGRMwiZ+YRyKyDMRmw6q2tyBKrg5 zcuhJAAZdqDAkWin8FUYJDLXkAYcL/t/TWBIIzqwQ9YloyN3IjqfdZdvcQWSUsJ7 wUsiP0u0b/+jxA+UfqEZAI3Hst6y/HtalCKmlTL1+NFiI8dWKz6RLaOIlWWkSug4 /z5aJQ== Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fajte2ssd-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 10 Jul 2026 11:11:51 +0000 (GMT) Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2cc5faecf01so15537485ad.1 for ; Fri, 10 Jul 2026 04:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1783681910; x=1784286710; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=JU6YRxZVspUNbu+VKz/3WI7sJx1qZ3NhZ7bU7qRiJXg=; b=KU2uoi0IuETp1dL6Tf0Wt5O73+b6emnQZRmNod6hZ8nOWeNKhPGA4ZKw8Tt7KZd2Ho 53vivZZYXn6UROqxW3RDhkDzur26XM7anpLZ8k0QE7t3VFugB1gYZKTEO64wQdzo6WZv aQHGqKYAaLvp1qgimb5b3EGsCbWnpxAraaRvMpk9Mk4KNrXpMUA2UxmkmGCoM7pYZXTr z5S2ZKzM/HTT+jSbr8ZPiXbDIyN2Xj6XNxbfCDKuwy7THPBA6yiEHo4WG+FGs6AAzjl0 LOUt8esrlVB4gVcxNejzVUhM0gteJ/t1JWWw38t9g3GFYsoYvYRVSi2hO7RNkbzvGo1y QYMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783681910; x=1784286710; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JU6YRxZVspUNbu+VKz/3WI7sJx1qZ3NhZ7bU7qRiJXg=; b=N8mriFnL5E1/IR3v0iOvZQMNjNO2vLvYOORY/ZkVKt43PULp0zpmaslLnwRYfETjhe RANwlfmvBkzWlMbQoHS9h+zBBa/asUga9WxgzAtJ+1Cs00o2DqgA013o+2ZI9eimWn5O s722l3DPJTq/VllJnah03bFFMtN85eb33au9+jbNLEbNBRhDl/pd+bcUOk+En7cDrskm aoJ2h84AI0Cbq2b2UshGsxFFPp7XweID6HnSHuLjRELaD9g2eZStJmt1HU5BNSrQ80xl SGa6jjrcifZyikTpKJBvmZ4R/POHrt+vCxYqVw436tSEW0XQfr+adZHE75Fp+FoxB4bl OYpw== X-Forwarded-Encrypted: i=1; AHgh+Ron0XBdX2sIWq2bzXNZwRudVXlo1bbIZhRHStZeZZlQNOnFwxM8JayMh1STUQWvZ55z3yVnluH5BwCWvps=@vger.kernel.org X-Gm-Message-State: AOJu0YwiG5dl1c0WS8FN7I6L/J29YVQ94EUTbcnCrEKVQx1OIxt17w6+ p8CNaY/odQqRO2EyQ4M6QWBPOwtWyxaGEEmyK8w1OqLTFDfyI6hijNN7ofTzZ1IPhNb9W/tBEcP Tjx6Q8t0TMZuAn1YewMGmLJujv3YXlC/Pa3YgdxSYzV33clIY0mjNvxG0hB9J/PZxNSE= X-Gm-Gg: AfdE7ckdolRmGwbK1jakcokzmeNJ41XKuOLYijmKRme4P6DlyDdW+iAG2B1zueTranI 9Vtft5Qh30YdRiJEvefPeQaGRxwO9E8Ui+8xBKX7KNIUau8EWC9h+ndocK1c9aaGBCnm5v1qCzt pU10vRi6hVPsZETjKZXkWNPthjbnzSaEM02x2JH9wZONcILMdlMcUStqlzdxHtDZUAaclmYCr0o UZVy9p3gbFCwKk2Vw1aS1p9pfSmQXLFTrMP46FUHHm9xsVKbf7TcaIMuX88UlblaYlThtxXyCXz YyxdfquadD182lEJjn6E13Vzlr4bL1k998uRphnDfKXvQGKxAspdklUnDXQoy3ztik3EIqRxYE8 lC+W45LyhSI/GfyBhc5ubPKYZpTYF5N32T5LchKVtqPz150pE1A== X-Received: by 2002:a17:90b:3f8c:b0:387:e0cb:7f7 with SMTP id 98e67ed59e1d1-38942b786e0mr10762382a91.43.1783681910301; Fri, 10 Jul 2026 04:11:50 -0700 (PDT) X-Received: by 2002:a17:90b:3f8c:b0:387:e0cb:7f7 with SMTP id 98e67ed59e1d1-38942b786e0mr10762344a91.43.1783681909714; Fri, 10 Jul 2026 04:11:49 -0700 (PDT) Received: from [192.168.31.103] ([152.58.31.181]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38a5516ad7asm2610062a91.3.2026.07.10.04.11.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jul 2026 04:11:49 -0700 (PDT) Message-ID: Date: Fri, 10 Jul 2026 16:41:42 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency To: Konrad Dybcio , mukesh.savaliya@oss.qualcomm.com, viken.dadhaniya@oss.qualcomm.com, andi.shyti@kernel.org, sumit.semwal@linaro.org, christian.koenig@amd.com Cc: linux-i2c@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, naresh.maramaina@oss.qualcomm.com References: <20260705135739.4038826-1-aniket.randive@oss.qualcomm.com> <4f865aaf-a400-4dc6-acaa-80dc22a36af7@oss.qualcomm.com> <6b53fa97-0fae-4ba2-a774-ae8df2c2ad4e@oss.qualcomm.com> <82326bd4-59f0-45b6-8f06-38896cf9f9bb@oss.qualcomm.com> Content-Language: en-US From: Aniket RANDIVE In-Reply-To: <82326bd4-59f0-45b6-8f06-38896cf9f9bb@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: d2y5ibj7QQWsYenxQiavIwAvVzsPe3jK X-Proofpoint-ORIG-GUID: d2y5ibj7QQWsYenxQiavIwAvVzsPe3jK X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzEwMDEwOSBTYWx0ZWRfX2r81iM9J3b/2 +lW/IiB2Cn8BbYC2ArKrX4j6NtuwIukTUAqwOg8eySxIH7hgZDHM7R/JlYimKpXEs4S7+83dI4+ ZCFXfeqUsC1BkSMMafi1LPJ2vmvgEFZ0kk8Fb/RDKlhYKlPNfyi2iOLYq4ZdZFT4RkZ2ppvKmIu u1kmzcejhldz6KdvZswJMG5/bgnfGJNgPtCGb9ENKVaoSJB6MkJsfWOeXDtjEGX5kJttM0ypa7K LxPAeDl9i7XNgydh5RdWg8qeKgmVi8L8J1MS/Q43ncjpj7ZuSDCPyTtUhUxLdsCGd5lkb9U7aYX 5bTny4R5HIU7xDglwC7/otB62wLjeCX4lOwwlHNB2c8h2Od+/SSNH/GQZJiXcSMbjZkkBZ9G4n4 oYqY8AZLBTkc5+WFvTchBg2ehuZZGkL2wut0f+Z26UpFMBQkhrg3UbFB/ZkzgY/p6F5Le2//V0m Td86GviXf2CEXrxcBCQ== X-Authority-Analysis: v=2.4 cv=N7MZ0W9B c=1 sm=1 tr=0 ts=6a50d377 cx=c_pps a=MTSHoo12Qbhz2p7MsH1ifg==:117 a=9AXozQ6IwN0d4JI31gUtBA==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22 a=52HooUGS_mQjH2t11kEA:9 a=QEXdDO2ut3YA:10 a=GvdueXVYPmCkWapjIL-Q:22 X-Proofpoint-Spam-Info: AW1haW4tMjYwNzEwMDEwOSBTYWx0ZWRfX2QG8rFH2Ze8f I36pyIqlzHl1tDjRV+yRMDrWQYqjqm4ckwnahGACc50Hkg4Nrd1WDuX242v4AuhhvRmAtjfN9cg KGrQRZcZ0Hj2sK99/szBtIfZ/Rg5gas= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-10_03,2026-07-09_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 spamscore=0 impostorscore=0 suspectscore=0 adultscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607100109 On 7/10/2026 2:57 PM, Konrad Dybcio wrote: > On 7/9/26 8:28 AM, Aniket RANDIVE wrote: >> Thanks Konrad for the review. >> >> Sorry, I missed your comments on the v2 patch and ended up posting v3. I'm happy to post a v4 incorporating your feedback once the discussion concludes. >> >> On 7/6/2026 5:11 PM, Konrad Dybcio wrote: >>> On 7/5/26 3:57 PM, Aniket Randive wrote: >>>> The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers >>>> regardless of message length or bus frequency, causing unnecessary >>>> delays on error paths. >>>> >>>> Compute the timeout dynamically from message length and bus frequency >>>> with a 10x safety margin over the theoretical wire time and a 300ms >>>> floor. For GPI multi-descriptor transfers, use the maximum message >>>> length across all queued messages as the per-completion timeout. >>> >>> What's the reason for a 0.3 s floor? >> >> The floor accounts for I2C clock stretching. The spec allows slaves to hold SCL low indefinitely during internal processing. A dynamically computed xfer time alone gives no time for that. >> 300ms value covers worst-case stretching while still detecting real hangs 3x faster than the old 1s static timeout. > > Please put that in the commit message and possibly in the code as a comment Sure. I will update the commit message accordingly and add a corresponding comment in the driver as well. Thanks, Aniket > >> >> Thanks, >> Aniket >> >>> >>> Why a 10x safety margin specifically? >>> >>> [...] >> >> The multiplier covers the gap between theoretical xfer time and actual completion time (DMA descriptor setup, interrupt latency, and scheduling jitter on a loaded system) >> Without it, short transfers would have almost no extra time before a spurious timeout. > > Likewise > > (Should there be a constant safety margin added to account for all > that? Keep in mind this driver will run on a turbofast Glymur and on > a notsofast Agatti so any numbers that depend on the processor's > speed must be reasonable for both) > > Konrad The 10x multiplier was chosen as a conservative guard band to account for the gap between theoretical transfer time and actual completion time, including DMA setup, interrupt handling, and scheduling delays. Although the value is not derived from a formal worst-case latency analysis, it provides sufficient tolerance to accommodate runtime variability and helps avoid spurious timeouts across a wide range of platforms and system load conditions. Thanks, Aniket