Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp97914imu; Mon, 26 Nov 2018 17:40:43 -0800 (PST) X-Google-Smtp-Source: AFSGD/VHQ6ZW+v4GJM8IiNyOYh3DrtKFWIDso3arx//qtclpH1g72MAE85Jg2pj9JC0zCCtO+K8F X-Received: by 2002:a63:104d:: with SMTP id 13mr27347467pgq.303.1543282843935; Mon, 26 Nov 2018 17:40:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543282843; cv=none; d=google.com; s=arc-20160816; b=Wp3uqrnLjUpse4LJ3VXeKl2r5Xojhfp8mCMPyEJaHzZH/xhqJzXckZMvQB1d5Sotrz IV7bnGX1UZFV3VJLA+CzvvBjZ2nAsOkJHYREnM9NFG0W7t9hHdLxXEM3HVbUkPHS9VFy BtrFltNmWYHxaeo8A6/aJMvBUiP/mXFjlDdv0jxeeXjOoJCxROmrnZx0QhHy67uD4x8j YsI0GVzK4qDWCMBBx35MXAvt08B897cwQqse9rny8sSsVpX8uDjaNT1VefzastDjf92l e8Jqur0ZyB4j3UuEz5AD9iElU+9uQMBWKB22uPiDvq9du0wylWSspo2lo25SMfVEMVA2 PBug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=Vtu5ZU1ziBdw/4/FhLqW3au7y+6Y9M65jg0ERqNeHLQ=; b=N4iNCXpjXm3gQDOh+kO9ACUUyxIC73qt3HnEOqFMnI85poYHzea6e9FEpZYB4enLpX YQYWF4gTYFHJ/6OgNqe9f96EQQu4SfBhX4m0C0cbk9L+6Urlws+diDDMlSxMYKodZidS Yv4CpkS+vsIYvZjczKY+ecHkbkYivvX2S/4d8QsFND8tassCdwLk6Y0MNwQ9gPHN7kYw tDBXCkYfvrjcB8qDwUJ0X7AVIYTfi2M3Tt1ku5wVwhBhPWFXWp2ujngUN3RMhXQ8FOt4 ggZeJm/QZnavoMqdOZPPdAsL+1eJHjBwmNmqBalhdsAAGAiCy9XAXhG0F4A7HJaDIeff eXuQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g8si2502251pfa.11.2018.11.26.17.40.28; Mon, 26 Nov 2018 17:40:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728039AbeK0Mfp (ORCPT + 99 others); Tue, 27 Nov 2018 07:35:45 -0500 Received: from mailgw02.mediatek.com ([1.203.163.81]:15009 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726535AbeK0Mfp (ORCPT ); Tue, 27 Nov 2018 07:35:45 -0500 X-UUID: 2ec0257fe35348d5bd44df66f1838ea3-20181127 X-UUID: 2ec0257fe35348d5bd44df66f1838ea3-20181127 Received: from mtkcas34.mediatek.inc [(172.27.4.250)] by mailgw02.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 475931140; Tue, 27 Nov 2018 09:39:32 +0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31DR.mediatek.inc (172.27.6.102) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 27 Nov 2018 09:39:30 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Tue, 27 Nov 2018 09:39:29 +0800 Message-ID: <1543282769.24219.129.camel@mhfsdcap03> Subject: Re: [v5, PATCH 2/2] dt-binding: mediatek-dwmac: add binding document for MediaTek MT2712 DWMAC From: biao huang To: Rob Herring CC: Andrew Lunn , , , , , , , , , , , , , Date: Tue, 27 Nov 2018 09:39:29 +0800 In-Reply-To: <20181126214626.GA13830@bogus> References: <1542882521-18874-1-git-send-email-biao.huang@mediatek.com> <1542882521-18874-3-git-send-email-biao.huang@mediatek.com> <20181122151932.GD15403@lunn.ch> <1542936676.24219.66.camel@mhfsdcap03> <20181126214626.GA13830@bogus> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Rob, Thanks for your comments. On Mon, 2018-11-26 at 15:46 -0600, Rob Herring wrote: > On Fri, Nov 23, 2018 at 09:31:16AM +0800, biao huang wrote: > > Dear Andrew, > > > > Thanks for you remind. > > > > Sincerely, I respect any comment from any reviewer. If I didn't reply > > for any comment, really sorry for that. > > > > As to this "tx-delay" issue, the following reply in v3 maybe ignored. > > https://lkml.org/lkml/2018/11/19/158 > > > > "the delay time in mediatek dwmac design is not so accurate, > > the current mt2712 and the following ICs will not use the > > same delay design, but will use stages to indicate different > > delay time. > > so maybe "mediatek.tx-delay" represent the delay stage is a > > good choice" > > > > And to make it clearer here. > > > > In mt2712, there are two delay macro circuit: named fine-tune and > > coarse-tune. > > a. fine-tune, 170+/-50ps per stage, total 32 stages > > b. coarse-tune, 0.55+/-0.2ns per stage, total 32 stages > > If we only consider mt2712, delay in fine-tune select a integer > > multiple of 170ps, delay in coarse-tune select a integer multiple of > > 550ps, for stage 0~31, the delay in fine-tune will not have the same > > value with that in coarse-tune. > > OK, It seems the property "fine-tune" can be eliminated . > > > > But the following ic will not have the same accuracy as mt2712, > > and maybe will not have two delay macro circuit to be selected. > > New IC will have new compatible string then. If it is different, then > likely these properties would have to change or have different meaning > unless you use time. > OK, I'll use tx-delay-ps instead of tx-delay. > > 1. assume two delay macro circuit in the following ic, > > fine-tune, 100ps per stage, coarse-tune, 0.55ns per stage, > > if we want delay 2.2ns, fine-tune will get a 22, and coarse-tune get a > > 4. We can't distinguish which delay macro we are choosing. > > Why wouldn't you just choose fine-tune for anything less than the max > range (3200ps in this example) and course for greater than 3100ps. > The fine-tune circuit and coarse-tune circuit are parallel, and fine-tuen is a select switch. It depends on users to choose which circuit is take effect. I shouldn't assume users would choose fine-tune when delay < 3200ps, and coarse for > 3100ps. so, tx-delay-ps will be chosen, and "fine-tune" boolean property should be remained as a indicator. > > 2. assume only one delay macro circuit is used, a similar case as 1 > > will also increase the complexity of driver. > > Then, we need define more flag property to know which delay macro we > > are handling. > > > > The common things for all delay macro circuit in MediaTek mac design is > > the stages, not the accuracy. so if we maintain stage info in "mediatek, > > tx-delay", we only need care which stage we should choose. > > And for each IC, we will recommend a best stage as a candidate. > > What if you had a 3rd delay circuit? > OK, tx-delay-ps will be a meaningful property. If more delay circuit is added, fine-tune property(boolean --> u32) can still be a indicator. > > Above is my personal opinion, may be my understanding is wrong, > > welcome for further discussion. > > > > Thanks a lot.