From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 39C33202F79; Wed, 8 Jan 2025 19:15:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736363730; cv=none; b=FYiQkwFNBc1dI+BfrtLKb6GEygu1oRh9GTb9Oqoc0NRlPizn0YcQKfX/91qUBMT7Pv8oCKy1ByckJqsGdnln1GPfl/3ibFS58Yh9a12w1AL3qQ59v9nWWO7fzU7EZ+dWOD7c0TNbPW4o/kuEqPrdKNPbaMJlH6lLflatfY8zm6g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736363730; c=relaxed/simple; bh=EDYsfe6UozlBzNoiQ5/54t0bWotfhI8VlswZ0JuvpVg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Zyc3N7yF6RRAYrP36//gc2Ou3+AdyJLYPyaj5YKSeFO8U5q/z1g8GclpW5tffv7hq8dgowGCpgPrhslsyE4Fi6ErXNYtVy1EfI1sDHVyIzbil4uBsmd/SM6udx7+sEpNl9r8x1+PZkQinrd9a0csbdD+t6FkV1tTgOeRjuKiVAI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=aqRC2tLj; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="aqRC2tLj" Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 508EevRu007759; Wed, 8 Jan 2025 19:14:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=PE6uY0 MKch3pf0bd2qsNrj/r/z4HrfLglnEYW4wWGkA=; b=aqRC2tLjD33b44OzrTqIjW dCP2T+6z+CJPhSVON0esDt4SkcBBwZdGQNubWIUSmhFCY/a+pzxpYsMTzX1TmIUK Usy317ZYM6zxdEHxx3VgTJRYhMjNE+R9hTEq37XPFTOndQ/UiAoujh/y2oyhjTmx 2cB3dhOnRNsVy7iIXe+jiyxiJRi03l5/6bMYgRBlCUAxhw26zugVTTvbCn8y9epu 2Ir/m5cgzRAZG+2foFR+C8BioPe1XZdm2o5NCUHmottj7colK5E22KwFNg/mD5Ws PScnKZ1yDTw+FIdcHaT+ewM6To7yKhF2XcYoMRCaKg4DKGslb9q461uM7/223EAA == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 441hupv392-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jan 2025 19:14:37 +0000 (GMT) Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 508JDHR4025487; Wed, 8 Jan 2025 19:14:37 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 441hupv38x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jan 2025 19:14:36 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 508GQneT008970; Wed, 8 Jan 2025 19:14:35 GMT Received: from smtprelay03.wdc07v.mail.ibm.com ([172.16.1.70]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 43yfq01g26-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jan 2025 19:14:35 +0000 Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay03.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 508JEYUh30540288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Jan 2025 19:14:34 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8D6058055; Wed, 8 Jan 2025 19:14:34 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 25B3258043; Wed, 8 Jan 2025 19:14:33 +0000 (GMT) Received: from [9.61.139.65] (unknown [9.61.139.65]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTP; Wed, 8 Jan 2025 19:14:32 +0000 (GMT) Message-ID: Date: Wed, 8 Jan 2025 13:14:31 -0600 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 05/10] ARM: dts: aspeed: system1: Add RGMII support To: Andrew Lunn , Jacky Chou Cc: "andrew+netdev@lunn.ch" , "andrew@codeconstruct.com.au" , "conor+dt@kernel.org" , "davem@davemloft.net" , "devicetree@vger.kernel.org" , "eajames@linux.ibm.com" , "edumazet@google.com" , "joel@jms.id.au" , "krzk+dt@kernel.org" , "kuba@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-aspeed@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "minyard@acm.org" , "netdev@vger.kernel.org" , "openipmi-developer@lists.sourceforge.net" , "pabeni@redhat.com" , "ratbert@faraday-tech.com" , "robh@kernel.org" References: <0c42bbd8-c09d-407b-8400-d69a82f7b248@lunn.ch> Content-Language: en-US From: Ninad Palsule In-Reply-To: <0c42bbd8-c09d-407b-8400-d69a82f7b248@lunn.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: eBn1M_tknw6OBAQkJ7OYRtzuEbM0IDWO X-Proofpoint-GUID: GGmo5RPbLSGmIng4MpBwjIOTUBqsvtBc X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 clxscore=1011 mlxscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 bulkscore=0 impostorscore=0 mlxlogscore=988 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501080155 Hi Andrew, Thanks for the reply. On 1/8/25 11:52, Andrew Lunn wrote: >>> Does the mac0 TX clock have an extra long clock line on the PCB? >>> >>> Does the mac1 TX and RX clocks have extra long clock lines on the PCB? >>> >>> Anything but rgmii-id is in most cases wrong, so you need a really >>> good explanation why you need to use something else. Something that >>> shows you understand what is going on, and why what you have is >>> correct. >> Here I'll add some explanation. >> >> In our design, we hope the TX and RX RGMII delay are configured by our MAC side. >> We can control the TX/RX RGMII delay on MAC step by step, it is not a setting to delay to 2 ns. >> We are not sure the all target PHYs are support for RX internal delay. >> >> But ast2600 MAC1/2 delay cell cannot cover range to 2 ns, MAC 3/4 can do that. >> Therefore, when using ast2600 MAC1/2, please enable the RX internal delay on the PHY side >> to make up for the part we cannot cover. >> >> Summarize our design and we recommend. >> AST2600 MAC1/2: rgmii-rxid >> (RGMII with internal RX delay provided by the PHY, the MAC should not add an RX delay in this >> case) >> AST2600 MAC3/4: rgmii >> (RX and TX delays are added by the MAC when required) >> >> rgmii and rgmii-rxid are referred from ethernet-controller.yaml file. > O.K, so you have the meaning of phy-mode wrong. phy-mode effectively > described the PCB. Does the PCB implement the 2ns delay via extra long > clock lines or not. If the PCB has long clock lines, phy-mode is > 'rgmii'. If the PCB does not have long clock lines, 'rgmii-id' is > used, meaning either the MAC or the PHY needs to add the delays. I checked with out hardware team and they did not add any extra delay on the board. We have normal point to point clock without any delay added by line. Regards, Ninad > > The MAC driver is the one that reads the phy-mode from the DT, and > then it decides what to do. 95% of linux MAC drivers simply pass it > direct to the PHY. If the phy-mode is 'rgmii', the PHY does nothing, > because the PCB has added the delays. If it is rgmii-id, it adds > delays in both directions. This works, because nearly very RGMII PHY > on the market does support RGMII delays. > > There is however a very small number of MAC drivers which do things > differently. Renesas produced an RDK with a PHY which could not do > delays in the PHY, and so were forced to do the delays in the > MAC. Please look at how the ravb driver works. If the PCB does not add > the delays, rmgii-id, the MAC driver adds the delays. It then masks > the phy-mode it passes to of_phy_connect() back to 'rgmii', so that > the PHY does not add any delays. If the PCB did add the delays, > 'rgmii', the MAC driver does not add delays, and it passed rgmii to > the PHY driver, and it also does not add delays. > > So, your MAC driver is broken. It is not correctly handling the > phy-mode. First question is, how many boards are there in mainline > which have broken phy-modes. If this is the first board, we can fix > the MAC driver. If there are already boards in mainline we have to be > much more careful when fixing this, so as not to regress boards which > are already merged. > > Humm, interesting. Looking at ftgmac100.c, i don't see where you > configure the RGMII delays in the MAC? > > Andrew >