[U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena

[Sean Cross <xobs@kosagi.com>]

On 15/10/2014 12:47, Nikolay Dimitrov wrote:
> Hi Marek,
>
> On 10/15/2014 12:38 AM, Marek Vasut wrote:
>> On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote:
>>> On 12/10/2014 05:04, Fabio Estevam wrote:
>>>> On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross <xobs@kosagi.com> wrote:
>>>>>> Ok, understood. Just curious: which Ethernet PHY is used on the
>>>>>> novena
>>>>>> board?
>>>>>
>>>>> It's the same Micrel PHY used on the Sabrelite, the KSZ9021.
>>>>
>>>> nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in
>>>> accordance with ksz9021 datasheet.
>>>>
>>>> Shouldn't we wait 10ms here as well?
>>>
>>> The reference manual for the PHY indicates that you should hold reset
>>> low for 10ms after the supply voltage stabilizes.  So long as it takes
>>> at least 10msto get from the point at which the CPU starts executing
>>> its
>>> ROM code  to the point at which the reset line is toggled, we will
>>> be fine.
>>
>> This definitelly is the case, so I presume we don't need the delay ?
>
> Well, here's how I see the case.
>
> After power on, the PHY unfortunately is out of reset (R20G is DNP,
> imx6 pin pulled high internally after reset). At some unknown point in
> time the CPU reaches novena_spl_setup_iomux_enet(). During all this
> time the PHY is still out of reset. Neither this complies with the
> recommended sequence, and even more doesn't comply if we remove the
> delay.
>
> If we leave the delay as it is currently implemented, the actual reset
> sequence is just delayed (by the time it takes the CPU to reach the
> PHY reset code). At this later point we enforce the proper reset
> sequence: supply rail is obviously now stable, and we keep the PHY
> reset low for the minimum specified time: 10ms.
>
> My understanding is that this is simple and efficient way to guarantee
> that for all different cases (different temperatures, different CPU
> silicon revisions, differently configured drivers/subsystems), the PHY
> reset timing is generated properly, and will be generated properly in
> the future when the code evolves.
>
> Please tell me if I'm missing something.
I generally think we'd be fine without the delay, putting it into reset
in the SPL and pulling it out of reset in U-Boot, but I can understand
the need for future-proofing and clarity.  If someone were to copy the
code from Novena to a new board, they may find the PHY behaving unreliably

If 10ms is the difference between "we ought to be fine" and "we'll
definitely be fine and not surprise anyone", then we should leave the
delay in.


Sean