From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A1A1C433EF for ; Sat, 18 Dec 2021 09:44:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232473AbhLRJop (ORCPT ); Sat, 18 Dec 2021 04:44:45 -0500 Received: from mailgw02.mediatek.com ([210.61.82.184]:55512 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S231405AbhLRJoo (ORCPT ); Sat, 18 Dec 2021 04:44:44 -0500 X-UUID: 5bdb8e4c8b2a4ca1a2b7de8acd8cc534-20211218 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID; bh=BX/xr60YeEGkR5WPd8bZnIzzW27Ue8psX+ZM7ID81Ws=; b=IuS8ogSNs/5R2cHUpRZt1ZUhNsHJtgyOUdXWB3KKcb2gy1lbK2G0vswC97Kjt1A7JczB/nzKwnvK77PRIhX/eImjQV2qPwkXbMKbydit1WHb/wT2jLCmTIx1jEXcUj28dt5pVkl6kXEHotIU53/zxidkIkP8WLWqx/8QiWXbQQY=; X-UUID: 5bdb8e4c8b2a4ca1a2b7de8acd8cc534-20211218 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 297468601; Sat, 18 Dec 2021 17:44:39 +0800 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Sat, 18 Dec 2021 17:44:38 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Sat, 18 Dec 2021 17:44:31 +0800 Message-ID: Subject: Re: [PATCH v7 6/7] i2c: mediatek: Isolate speed setting via dts for special devices From: Kewei Xu To: Wolfram Sang , , , , , , , , , , , , , , Date: Sat, 18 Dec 2021 17:44:32 +0800 In-Reply-To: References: <20210917101416.20760-1-kewei.xu@mediatek.com> <20210917101416.20760-7-kewei.xu@mediatek.com> <1891acec7f5c417f62081a8b10249b265df7ea62.camel@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org T24gTW9uLCAyMDIxLTExLTI5IGF0IDEzOjQ5ICswMTAwLCBXb2xmcmFtIFNhbmcgd3JvdGU6DQo+ ID4gPiBzdHJldGNoaW5nLiBCdXQgaWYgdGhlIHNsYXZlIGRldmljZSBzdHJldGNoIHRoZSBTQ0wg bGluZSBmb3IgdG9vDQo+ID4gPiBsb25nDQo+ID4gPiB0aW1lLCBvdXIgZGVzaWduIHN0aWxsIGNh bm5vdCBtYWtlIHRTVSxTVEEvdEhELFNUQS90U1UsU1RPIG1lZXQNCj4gPiA+IHNwZWMuDQo+ID4g DQo+ID4gSXNuJ3QgdGhlIG5ldyBhbGdvcml0aG0gYnJva2VuIGlmIGl0IGNhbm5vdCBzdXBwb3J0 IGNsb2NrDQo+ID4gc3RyZXRjaGluZz8NCj4gPiBXaGF0IHdhcyB0aGUgcHJvYmxlbSBvZiB0aGUg b2xkIGFsZ29yaXRobSBub3QgbWVldGluZyB0aGUgc3BlYz8NCj4gPiANCj4gPiA+IEhvd2V2ZXIg aW4gdGhlIG9sZCAoZGVmYXVsdCkgdGltaW5nIGFsZ29yaXRobSBiZWZvcmUgdGhlIGNvbW1pdA0K PiA+ID4gYmU1Y2UwZTk3Y2M3ICgiaTJjOiBtZWRpYXRlazogQWRkIGkyYyBhYy10aW1pbmcgYWRq dXN0IHN1cHBvcnQiKSwNCj4gPiA+IHRTVSxTVEEvdEhELFNUQS90U1UsU1RPIGNhbiBtZWV0IHNw ZWMuIFNvIHdlIHdhbnQgdG8gZGVmaW5lIGEgbmV3DQo+ID4gPiBzZXR0aW5nICJkZWZhdWx0LWFk anVzdC10aW1pbmciIGZvciB1c2luZyB0aGUgb2xkIChkZWZhdWx0KQ0KPiA+ID4gdGltaW5nDQo+ ID4gPiBhbGdvcml0aG0uIg0KPiA+IA0KPiA+IFdoYXQgSSBzdGlsbCBkbyBub3QgZ2V0OiB0aGUg b2xkIGFsZ29yaXRobSB3YXMgYWJsZSB0byBoYW5kbGUgY2xvY2sNCj4gPiBzdHJldGNoaW5nLiBX aHkgY2FuJ3QgeW91IHVwZGF0ZSB0aGUgbmV3IG9uZSB0byBoYW5kbGUgY2xvY2sNCj4gPiBzdHJl dGNoaW5nDQo+ID4gYXMgd2VsbC4gSSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IHdo YXQgaXMgaXQ/DQo+IA0KPiBJIGFtIHN0aWxsIGludGVyZXN0ZWQuIEVzcGVjaWFsbHkgaW4gdGhl IGxhc3QgcXVlc3Rpb24uIElzIHRoZSBsYXN0DQo+IHF1ZXN0aW9uIGNsZWFyIHRvIHlvdT8gSSBj YW4gZXhwbGFpbiBzb21lIG1vcmUgb3RoZXJ3aXNlLg0KPiANCkhpLFdvbGZyYW0sDQoNCkknbSB2 ZXJ5IHNvcnJ5IHRoYXQgSSBkaWRuJ3QgcmVwbHkgdG8geW91ciBpbmZvcm1hdGlvbiBpbiB0aW1l IGR1ZQ0KdG8gbXkgbWFueSBwZXJzb25hbCBhZmZhaXJzLg0KDQpUaGUgT2xkIGFsZ29yaXRobSB3 YXMgZGVzaWduZWQgdG8gZm9jdXMgb25seSBvbiBub3JtYWwgZnVuY3Rpb25zLCBhbmQNCm5lZWQg dG8gYWRkIGFkZGl0aW9uYWwgY3VzdG9tIGNvZGUgdG8gYWRqdXN0IGFjLXRpbWluZyB3aGVuIHRo ZQ0KY29tbXVuaWNhdGlvbiB0aW1pbmcgZGlkIG5vdCBtZWV0IHRoZSBzcGVjaWZpY2F0aW9ucy4g c28gd2hlbiB0aGVyZSBpcw0Kbm8gY2xvY2sgc3RyZXRjaCwgYWMtdGltaW5nIGRvZXMgbm90IG1l ZXQgdGhlIHNwZWMsIGJ1dCB0aGUgZnVuY3Rpb24gaXMNCmFsd2F5cyBub3JtYWwuDQoNClRoZSBu ZXcgYWxnb3JpdGhtKFRoZSBjb21taXQgcGF0Y2g6IGJlNWNlMGU5N2NjNyAoImkyYzogbWVkaWF0 ZWs6IEFkZA0KaTJjIGFjLXRpbWluZyBhZGp1c3Qgc3VwcG9ydCIpIGlzIGJhc2VkIG9uIHRoZSBy ZXF1aXJlbWVudHMgb2YgaTJjIHNwZWMNCnRvIGNhbGN1bGF0ZSB0aGUgaGFyZHdhcmUtcmVsYXRl ZCBzZXR0aW5ncyBzbyB0aGF0IHRoZSBmdW5jdGlvbiBhbmQgYWMtDQp0aW1pbmcgYXJlIG5vcm1h bCBXaGVuIHRoZXJlIGlzIG5vIGNsb2NrIHN0cmV0Y2ggb3IgdGhlIGNsb2NrIHN0cmV0Y2gNCnRp bWUgaXMgc2hvcnQuIFdoZW4gdGhlIHN0cmV0Y2hpbmcgdGltZSBpcyB2ZXJ5IGxvbmcgKD42MHVz KSwgaTJjIGFjLQ0KdGltaW5nIGRvZXMgbm90IG1lZXQgdGhlIHNwZWNpZmljYXRpb25zIGFuZCBj YXVzZXMgZnVuY3Rpb24gYWJub3JtYWwuDQoNCkluIG9yZGVyIHRvIG1ha2UgdGhlIGkyYyBmdW5j dGlvbiBub3JtYWwsIHRoaXMgcGF0Y2ggd2FzIHN1Ym1pdHRlZCwNCnRoYXQgaXMsIHdoZW4gdGhl IHN0cmV0Y2ggaXMgbG9uZywgdGhlIG9sZCBhbGdvcml0aG0gaXMgdXNlZCB0byBlbnN1cmUNCnRo ZSBmdW5jdGlvbiBpcyBub3JtYWwsIGFuZCB3aGVuIHRoZSBzdHJldGNoIGlzIHNob3J0LCB0aGUg bmV3DQphbGdvcml0aG0gaXMgdXNlZCB0byBlbnN1cmUgdGhhdCB0aGUgYWMtdGltaW5nIGFuZCBm dW5jdGlvbiBhcmUgbm9ybWFsLg0KDQpXZSBmb3VuZCB0aGF0IHdoZW4gdGhlIGFjLXRpbWluZyBj YWxjdWxhdGlvbiBmb3JtdWxhIGlzIHVwZGF0ZWQsIHRoZQ0KbmV3IGFsZ29yaXRobSBjYW4gbWFr ZSBpMmMgYWMtdGltaW5nIG1lZXQgdGhlIHNwZWMgYW5kIGZ1bmN0aW9uDQpub3JtYWxseS4gU28g d2UgcGxhbiB0byByZXBsYWNlIHRoaXMgcGF0Y2ggd2l0aCBhIHBhdGNoIHRoYXQgdXBkYXRlcw0K dGhlIGNhbGN1bGF0aW9uIGZvcm11bGEuDQoNClRoYW5rc34NCktld2VpDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 42F7DC433EF for ; Sat, 18 Dec 2021 09:45:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mEy6Z/+erMAkV7NcVXLtgOgBeqFss8qQ1CYWY8B1io0=; b=iWH8uceEx4dBYJ tFdB1BK79VO0/nJbRH5tZu/qP2ND8V8Qzg1G/+3AuwUWFx6zEiFM4hmlc+zKI+YMhp4RAjx09ydJt eQMmbT4rwH2rLf5xjmPu4OKu+XPr+1TX+cjrb2J+W2aOKqusThtYOvpQQF5ZWKo5npcCMY7sAD9X4 70JahZF/HCild4Vs4YTshEEJrxx3ET49mLihcrUBMxWVmmBH277W7qDMFadkGJwXagTb0GvkmnyZa 2fR68o+tIoE0SWVcnfqc0Mb2SnBUz3BxskdUxRWktBv0eRLMSjg2i3q/szu2oduA3eOY8n1FAxEwB IUgfyyg+L/LD3DScZMYQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1myWGz-00DPC6-1k; Sat, 18 Dec 2021 09:45:01 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1myWGm-00DPAA-Cx; Sat, 18 Dec 2021 09:44:50 +0000 X-UUID: 2f9d78e48dfe454db02ca081c18f27c3-20211218 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID; bh=BX/xr60YeEGkR5WPd8bZnIzzW27Ue8psX+ZM7ID81Ws=; b=IuS8ogSNs/5R2cHUpRZt1ZUhNsHJtgyOUdXWB3KKcb2gy1lbK2G0vswC97Kjt1A7JczB/nzKwnvK77PRIhX/eImjQV2qPwkXbMKbydit1WHb/wT2jLCmTIx1jEXcUj28dt5pVkl6kXEHotIU53/zxidkIkP8WLWqx/8QiWXbQQY=; X-UUID: 2f9d78e48dfe454db02ca081c18f27c3-20211218 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 500900162; Sat, 18 Dec 2021 02:44:41 -0700 Received: from mtkmbs10n1.mediatek.inc (172.21.101.34) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 18 Dec 2021 01:44:39 -0800 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Sat, 18 Dec 2021 17:44:38 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Sat, 18 Dec 2021 17:44:31 +0800 Message-ID: Subject: Re: [PATCH v7 6/7] i2c: mediatek: Isolate speed setting via dts for special devices From: Kewei Xu To: Wolfram Sang , , , , , , , , , , , , , , Date: Sat, 18 Dec 2021 17:44:32 +0800 In-Reply-To: References: <20210917101416.20760-1-kewei.xu@mediatek.com> <20210917101416.20760-7-kewei.xu@mediatek.com> <1891acec7f5c417f62081a8b10249b265df7ea62.camel@mediatek.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211218_014448_473350_E21C86B1 X-CRM114-Status: GOOD ( 21.89 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Mon, 2021-11-29 at 13:49 +0100, Wolfram Sang wrote: > > > stretching. But if the slave device stretch the SCL line for too > > > long > > > time, our design still cannot make tSU,STA/tHD,STA/tSU,STO meet > > > spec. > > > > Isn't the new algorithm broken if it cannot support clock > > stretching? > > What was the problem of the old algorithm not meeting the spec? > > > > > However in the old (default) timing algorithm before the commit > > > be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing adjust support"), > > > tSU,STA/tHD,STA/tSU,STO can meet spec. So we want to define a new > > > setting "default-adjust-timing" for using the old (default) > > > timing > > > algorithm." > > > > What I still do not get: the old algorithm was able to handle clock > > stretching. Why can't you update the new one to handle clock > > stretching > > as well. I might be missing something, but what is it? > > I am still interested. Especially in the last question. Is the last > question clear to you? I can explain some more otherwise. > Hi,Wolfram, I'm very sorry that I didn't reply to your information in time due to my many personal affairs. The Old algorithm was designed to focus only on normal functions, and need to add additional custom code to adjust ac-timing when the communication timing did not meet the specifications. so when there is no clock stretch, ac-timing does not meet the spec, but the function is always normal. The new algorithm(The commit patch: be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing adjust support") is based on the requirements of i2c spec to calculate the hardware-related settings so that the function and ac- timing are normal When there is no clock stretch or the clock stretch time is short. When the stretching time is very long (>60us), i2c ac- timing does not meet the specifications and causes function abnormal. In order to make the i2c function normal, this patch was submitted, that is, when the stretch is long, the old algorithm is used to ensure the function is normal, and when the stretch is short, the new algorithm is used to ensure that the ac-timing and function are normal. We found that when the ac-timing calculation formula is updated, the new algorithm can make i2c ac-timing meet the spec and function normally. So we plan to replace this patch with a patch that updates the calculation formula. Thanks~ Kewei _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DAE4DC433EF for ; Sat, 18 Dec 2021 09:46:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Ate0Y6q/+KpKUy93b947pgqN4S+8mkinzH4oXSglP2I=; b=rXV8aPwL0LqKuS 9gaVn19NUpJPh3IWnK/l09kJ92VrGM+g0RkqmiAbDaD//w7ec2rzzKbSyxjGUDguuM7e0wdR1SyYj AQtLA+gQySnip/ywu0mGpnlZnBi7zyWFmkUMLMsMg1w4KjfPHXECteA2AjLi0eZ2N72Yxb4+Q9H4A BtE5tCd+bjZGHzCRyUsyjFRX4yGqXRsGcQiU30iLEzPrVnL2gRvdpX1OdS0P2GPwFSyT4gkI204SD hLJNmE9zCn+nPkj3GOk9GwmW6Ys5o09Luy8u2s4eVHMnV1HMXLw5I6dSV4+mXS3gtdRmZM2+j0G34 0rrkuHiLPv3kVf9x0aIw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1myWGq-00DPBR-En; Sat, 18 Dec 2021 09:44:52 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1myWGm-00DPAA-Cx; Sat, 18 Dec 2021 09:44:50 +0000 X-UUID: 2f9d78e48dfe454db02ca081c18f27c3-20211218 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID; bh=BX/xr60YeEGkR5WPd8bZnIzzW27Ue8psX+ZM7ID81Ws=; b=IuS8ogSNs/5R2cHUpRZt1ZUhNsHJtgyOUdXWB3KKcb2gy1lbK2G0vswC97Kjt1A7JczB/nzKwnvK77PRIhX/eImjQV2qPwkXbMKbydit1WHb/wT2jLCmTIx1jEXcUj28dt5pVkl6kXEHotIU53/zxidkIkP8WLWqx/8QiWXbQQY=; X-UUID: 2f9d78e48dfe454db02ca081c18f27c3-20211218 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 500900162; Sat, 18 Dec 2021 02:44:41 -0700 Received: from mtkmbs10n1.mediatek.inc (172.21.101.34) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 18 Dec 2021 01:44:39 -0800 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Sat, 18 Dec 2021 17:44:38 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Sat, 18 Dec 2021 17:44:31 +0800 Message-ID: Subject: Re: [PATCH v7 6/7] i2c: mediatek: Isolate speed setting via dts for special devices From: Kewei Xu To: Wolfram Sang , , , , , , , , , , , , , , Date: Sat, 18 Dec 2021 17:44:32 +0800 In-Reply-To: References: <20210917101416.20760-1-kewei.xu@mediatek.com> <20210917101416.20760-7-kewei.xu@mediatek.com> <1891acec7f5c417f62081a8b10249b265df7ea62.camel@mediatek.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211218_014448_473350_E21C86B1 X-CRM114-Status: GOOD ( 21.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 2021-11-29 at 13:49 +0100, Wolfram Sang wrote: > > > stretching. But if the slave device stretch the SCL line for too > > > long > > > time, our design still cannot make tSU,STA/tHD,STA/tSU,STO meet > > > spec. > > > > Isn't the new algorithm broken if it cannot support clock > > stretching? > > What was the problem of the old algorithm not meeting the spec? > > > > > However in the old (default) timing algorithm before the commit > > > be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing adjust support"), > > > tSU,STA/tHD,STA/tSU,STO can meet spec. So we want to define a new > > > setting "default-adjust-timing" for using the old (default) > > > timing > > > algorithm." > > > > What I still do not get: the old algorithm was able to handle clock > > stretching. Why can't you update the new one to handle clock > > stretching > > as well. I might be missing something, but what is it? > > I am still interested. Especially in the last question. Is the last > question clear to you? I can explain some more otherwise. > Hi,Wolfram, I'm very sorry that I didn't reply to your information in time due to my many personal affairs. The Old algorithm was designed to focus only on normal functions, and need to add additional custom code to adjust ac-timing when the communication timing did not meet the specifications. so when there is no clock stretch, ac-timing does not meet the spec, but the function is always normal. The new algorithm(The commit patch: be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing adjust support") is based on the requirements of i2c spec to calculate the hardware-related settings so that the function and ac- timing are normal When there is no clock stretch or the clock stretch time is short. When the stretching time is very long (>60us), i2c ac- timing does not meet the specifications and causes function abnormal. In order to make the i2c function normal, this patch was submitted, that is, when the stretch is long, the old algorithm is used to ensure the function is normal, and when the stretch is short, the new algorithm is used to ensure that the ac-timing and function are normal. We found that when the ac-timing calculation formula is updated, the new algorithm can make i2c ac-timing meet the spec and function normally. So we plan to replace this patch with a patch that updates the calculation formula. Thanks~ Kewei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel