[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <581CC032.5000208@free.fr>
Date: Fri, 4 Nov 2016 18:06:58 +0100
From: Mason <slash.tmp@...e.fr>
To: Mans Rullgard <mans@...sr.com>,
Florian Fainelli <f.fainelli@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>,
Timur Tabi <timur@...eaurora.org>,
Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
Zefir Kurtisi <zefir.kurtisi@...atec.com>,
Martin Blumenstingl <martin.blumenstingl@...il.com>,
Uwe Kleine-Konig <u.kleine-koenig@...gutronix.de>,
Daniel Mack <zonque@...il.com>,
Sebastian Frias <sf84@...oste.net>
Subject: Re: Ethernet not working on a different SoC with same eth HW
On 04/11/2016 17:55, Måns Rullgård wrote:
> Florian Fainelli <f.fainelli@...il.com> writes:
>
>> On 11/04/2016 08:22 AM, Måns Rullgård wrote:
>>> Andrew Lunn <andrew@...n.ch> writes:
>>>
>>>> On Fri, Nov 04, 2016 at 03:05:00PM +0000, Måns Rullgård wrote:
>>>>> Andrew Lunn <andrew@...n.ch> writes:
>>>>>
>>>>>>>> I agree with you. But fixing it is likely to break boards which
>>>>>>>> currently have "rgmii", but actually need the delay in order to work.
>>>>>>>
>>>>>>> Does the internal delay here refer to the PHY or the MAC? It's a
>>>>>>> property of the MAC node after all.
>>>>>>
>>>>>> It is the PHY which applies the delay.
>>>>>
>>>>> Says who?
>>>>
>>>> The source code.
>>>
>>> There's source code that disagrees with that. The Broadcom GENET
>>> driver, for instance.
>>
>> Correct, and in the case where the MAC adds the delay while transmitting
>> (because it supports that) the expectation is that the PHY would remove
>> such a delay internally, conversely, the PHY would introduce a delay
>> while transmitting back to the PHY, in order to produce the desired 90
>> degrees shift on the RGMII signals, and get reproduce the correct clock
>> and data alignment internally.
>>
>>>
>>>>> Some MACs can do it too.
>>>>
>>>> I'm sure they can. But look at the code. Nearly none do, and those
>>>> that do are potentially broken.
>>>
>>> Those few drivers that do anything differently based on these values
>>> enable clock delay in the MAC. That's why I wrote the NB8800 driver the
>>> way I did.
>>>
>>
>> I don't really what is wrong with the nb8800 driver at the moment, so
>> maybe this is just a configuration issue with the Atheros PHY driver,
>> it's not like it has not given people headache judging by the recent
>> discussions...
>
> We don't even know if the problems Mason is having are caused by
> incorrect clock skew in the first place. I'd suggest not patching
> anything at all until he gets it working.
All I said was:
> Assuming that "rxid" (rx internal delay) and "rx clock delay" are
> in fact the same concept with different names, do you agree that
> it would be unexpected for "rgmii rx clock delay" to be enabled
> when a DTB specifies "rgmii" or "rgmii-txid" ?
In parallel, Sebastian changed the DT of a 8758 board
from phy-connection-type = "rgmii";
to phy-connection-type = "rgmii-txid";
and this broke the Ethernet on 8758, although the "reference"
legacy 3.4 kernel does enable tx clock delay.
Regards.
Powered by blists - more mailing lists